LLM プロンプトキャッシュ:2026年完全ガイド

目次
  1. どこから始めるか
  2. 第1部 — LLM プロンプトキャッシュの仕組み
  3. 第2部 — プロバイダー横断で LLM プロンプトキャッシュを比較
  4. 第3部 — 動作する Python チュートリアル
  5. 第4部 — ユースケース別の最適モデル
  6. 本シリーズの読み方
  7. 本シリーズの数値について

大規模言語モデルに対してチャットボット、RAG アプリ、AI エージェントをリリースするなら、プロンプトキャッシュは品質を一切犠牲にせずに 入力コストの 50〜90%、そして最初のトークンまでの時間(TTFT)を 3〜10 倍 取り戻せる唯一の最適化手段です。これは後付けの小手先のテクニックではなく、Transformer のアテンションが定義される仕組みそのものから直接導かれます。それを理解すれば、スタックの残りの部分(TTL、プロバイダーごとの違い、プロンプト構造)はきれいに整理できます。

このページは、理論から本番環境の意思決定マトリクスまでを案内する4部構成シリーズの索引です。すでにある知識に応じて、入る場所を選んでください。


どこから始めるか

〜したいならここから
キャッシュがなぜ存在するのか、KV キャッシュが実際に何かを理解する第1部 — KV キャッシュと TTL の仕組み
プロバイダーを選び、それぞれの違いを知る第2部 — Claude、GPT、Gemini、DeepSeek を比較
動作する Python をコピペして、自分の数値を測定する第3部 — 動作する Python チュートリアル
チャットボット / RAG / エージェントのワークロードに適切なモデルを合わせる第4部 — チャット、RAG、エージェント向けの最適モデル

各部は単独でも成立しますが、順番に読めば重複なく全体像が積み上がるように書かれています。


第1部 — LLM プロンプトキャッシュの仕組み

LLM プロンプトキャッシュ #1:KV キャッシュと TTL の仕組み →

アーキテクチャの記事です。セルフアテンションを単一の数式として解説し、安定したプレフィックスの K ベクトルと V ベクトルがなぜ数学的に再利用可能なのかを説明し、メモリと計算のトレードオフが、すべての開発者が設計の前提とせざるを得ない TTL の挙動をどのように生み出すかを示します。

要点:

  • プロンプトキャッシュは上位に重ねられた最適化ではなく、因果マスク付きアテンションの直接的な帰結です。位置 i の K/V はトークン 1…i の決定論的な関数なので、同一のプレフィックスはビット単位で完全に一致する K/V を生みます。
  • キャッシュが節約するのは Prefill(計算律速、O(N²))です。decode(メモリ帯域律速、トークンあたり O(N))は、どの推論エンジンもすでに最適化済みです。
  • TTL が存在するのは、KV キャッシュが膨大だから(70B モデルで 32K コンテキストの場合、約 10 GB)です。5 分は GPU のメモリ圧迫の限界点であり、数時間から数日が可能になるのはディスクバックされたキャッシュ(DeepSeek の MLA アーキテクチャ)に限られます。
  • キャッシュは コスト(キャッシュヒット時に入力が 50〜90% 安くなる)と レイテンシ(5〜10K トークン規模のプロンプトで TTFT が 3〜10 倍下がり、100K 超ではさらに大きく下がる)の両方で勝ちます。

第2部 — プロバイダー横断で LLM プロンプトキャッシュを比較

LLM プロンプトキャッシュ #2:Claude、GPT、Gemini、DeepSeek を比較 →

選定ガイドです。5つのプロバイダーはプロンプトキャッシュを、まったく異なる5つの形態で公開しています——明示的マーカー(Claude)、完全自動(GPT-5、DeepSeek-v4)、暗黙+明示のハイブリッド(Gemini、Qwen)、あるいはアーキテクチャ的なディスクバック(DeepSeek の MLA)。この記事では機能ごとの比較に加え、特定のワークロードに対して各社をスコアリングするための 5 次元評価フレームワーク を提供します。

要点:

  • 基本価格を比較してはいけません——自分のヒット率で重み付けした実効コストを比較しましょう(数式は §4.1)。
  • Claude は単一呼び出しで最も深い割引(約 90%)を持ちますが、明示的な cache_control マーカーが必要です。
  • DeepSeek-v4 は規模面でディスクバックのキャッシュを提供する唯一のプロバイダーです。粒度が 1,024 トークンではなく 64 トークンなので、部分的なプレフィックス一致でも割引が得られます。
  • Gemini の明示的キャッシュには時間単位のストレージ料金がかかります——損益分岐点は呼び出し頻度次第です。
  • ヒット率という変数を揃えてしまえば、実際にプロバイダーを区別するのはこの5次元です:API の使い勝手、ヒット率の予測可能性、TTL の適合度、ミス時のレイテンシ、そして移行コスト。

第3部 — 動作する Python チュートリアル

LLM プロンプトキャッシュ #3:動作する Python チュートリアル →

実践編の記事です。1つの OpenAI SDK + 1つの Anthropic SDK を単一のゲートウェイに接続し、2026-05-25 に Claude ファミリー全体(haiku-4-5 から opus-4-7)、GPT-5.x、Gemini 2.5、DeepSeek-v4、Qwen3 にわたって測定した数値を添えています。

要点:

  • cache_control マーカー付きの Claude:haiku/sonnet/opus 4-x にわたって一様に 88〜89% のコスト削減 を実測しました。Anthropic SDK を base_url="https://synthorai.io/" で使います。
  • GPT-5.4-mini 自動キャッシュ:TTFT が 5 倍改善(7K トークンのプロンプトで 3.6 秒 → 0.73 秒)、システムトークンでキャッシュヒット率 93%。
  • Gemini 2.5-flash 暗黙キャッシュ:ストリーミングの usage を捕捉した場合、キャッシュヒット時に 88% のコスト削減。
  • DeepSeek-v4-flash:74% 安く、ディスクバック(キャッシュは時間スケールのアイドルを生き延びる)。
  • TTL を意識したパターン:cron 向けの keep-alive ハートビート、プレフィックスの安定性ルール、呼び出しごとに何をログに残すか。

第4部 — ユースケース別の最適モデル

LLM プロンプトキャッシュ #4:チャット、RAG、エージェント向けの最適モデル →

意思決定編の記事です。ワークロードが違えばコスト/レイテンシのレバーの引き方も違います——チャットは本質的にキャッシュ向き、RAG はプレフィックス安定性の問題と戦い、エージェントは累積プレフィックスの規律に依存します。この記事では、ワークロードの形状ごとにモデルの推奨とコスト見積もりを提供します。

要点:

  • チャットボット:自動キャッシュを備えたどのモデルでも機能します。セッションは自然にヒットします。コスト/品質で選びましょう。gpt-5.4-nano が最安、gpt-5.4-mini がキャッシュ後の TTFT 最速、claude-haiku-4-5 がやや高めのプレミアムで指示追従性が最良です。
  • RAG:検索ドキュメントの並べ替えがプロンプト中盤のキャッシュヒットを潰します。修正策は3つ——参照を末尾に追いやる、決定論的なチャンク順序、あるいは Claude の複数 cache_control ブレークポイント。
  • エージェント:ツール呼び出しと結果は追記のみで、ステップ間でビット単位に同一でなければなりません。4つの cache_control マーカーを付けた claude-sonnet-4-5 が最も強い累積プレフィックス割引を与えます。gpt-5.4-mini はコード変更なしで 50% の節約が得られます。
  • TTL の対応:チャットには 5 分、人間が介在するステップを持つエージェントには 1 時間、散発的なバッチにはディスクバック。

本シリーズの読み方

  • このトピックに不慣れなエンジニア:順番に読みましょう。第1部のアーキテクチャによって、第2〜4部が一気に腑に落ちます。
  • ベンダー選定を行う PM やアーキテクト:第2部 + 第4部に飛んでください。チームメイトに「でも TTL はなぜ存在するの」と聞かれたら第1部を参照しましょう。
  • 今日中に特定のワークロードを出荷したいエンジニア:まず第4部(マトリクスで自分の行を探す)、次に第3部で正確なコードを取得します。
  • 既存アプリを最適化したい人:第3部 §6 のプロバイダー横断ベンチマーク——自分のプロンプトで再現してください。これは1日の作業であって、数週間に及ぶ移行ではありません。

本シリーズの数値について

すべての実測値は 2026-05-25 に Synthorai ゲートウェイに対して取得しました(OpenAI 互換は https://synthorai.io/v1、Anthropic ネイティブは https://synthorai.io/)。シングルテナント、単一の逐次実行、並行負荷なしです。あなたの数値はリージョン、時間帯、競合するテナント負荷によって変動します——出発点として扱い、引用する前に自分のトラフィックで再現してください。

価格表と TTL の挙動は、2026-05 時点でのベンダーの公開ドキュメントを反映しています。ベンダーは数か月ごとにこれらを更新します。アーキテクチャ的な推論(第1部)は安定していますが、比較数値(第2部・第3部)はドリフトします。

← ブログに戻る