メインコンテンツまでスキップ

プロバイダー横断のプロンプトキャッシュ

上級

プロンプトキャッシュは本番 LLM アプリにおける単独で最大のコストレバーです——入力側で 90% 超の削減が当たり前に出ます。いまや主要プロバイダーのすべてが備えています。だからこそどこでも同じ機能だと思い込みやすいのですが、実際は違います。

仕組み自体は同一です: プロバイダーがプロンプトのプレフィックスを再読み込みせず、処理済みのものを再利用します。異なるのは、誰が決めるのか、キャッシュがどれだけ生き残るのか、対象となるにはプレフィックスがどれだけ長い必要があるのか、そして——これが刺さるのですが——書き込みにプレミアムを払うのかです。あるプロバイダーでチューニングしたワークロードは、次のプロバイダーでは静かにキャッシュされなくなったり、キャッシュしないより高くつくことすらあります。

What you'll learn
  • 2つの制御モデル——明示的なブレークポイント対自動プレフィックス検出——を見分け、それぞれのコストを理解する
  • プロバイダー横断の表を読む: 最小プレフィックス、TTL、読み取り割引、書き込みプレミアム、ヒットを証明する usage フィールド
  • 移植可能な損益分岐ルールを適用する: TTL 内に何回再利用すればキャッシュが得になるか
  • ワークロードをプロバイダー間で移すときにキャッシュを静かに殺す5つの罠を避ける
  • ドキュメントではなくレスポンスの usage から、どのプロバイダーでも実際のヒット率を検証する

Claude のみを扱うなら、まず プロンプトキャッシュとコスト最適化 を読んでください——cache_control の仕組みを詳しく解説しています。このページはその上に載る移植性のレイヤーです。

2つの制御モデル​

この領域のすべては2つの設計のいずれかであり、設計があなたの失敗モードを決めます。

明示的（Anthropic）: 最後の安定したブロックにマーカーを付けます。頼まない限り何もキャッシュされません。境界を正確に制御でき、複数置くこともできます。代わりにバグも背負います: ブレークポイントのないプロンプトは永遠に全額を払い続け、何も警告してくれません。

自動（OpenAI、Google の暗黙キャッシュ、DeepSeek）: プロバイダーがプレフィックスをハッシュ化し、再利用できるものを再利用します。設定するものは何もなく、ミスしたときに直せるものも何もありません。あなたのレバーはプロンプトのレイアウト——安定した内容を先に置く——と、OpenAI ではルーティングのヒントだけです。

どちらのモデルでも手元に残るレバー

プレフィックスの順序は、どこでも効く唯一の制御です。安定した内容を先、変動する内容を後。 明示的なシステムではブレークポイントを置ける場所を決め、自動のシステムでは制御できる唯一のものです。

プロバイダー横断の表​

Anthropic (Claude)OpenAIGoogle (Gemini)DeepSeek
制御明示的な cache_control、最大4ブレークポイント自動、プレフィックス一致既定で暗黙的、明示的なキャッシュオブジェクトも利用可自動、ディスク上
最小プレフィックスFable 5.1 / Mythos 5.1 / Opus 5.5 / Opus 5 / Fable 5 / Mythos 5 で 512 トークン、Sonnet 5 と Opus 4.8 で 1,024、旧モデルで 2,048〜4,096GPT-5.6 以降で 1,024 トークン、それ以前はリクエスト設定により変動Gemini 3.5〜3.8 Flash と 3.1 Pro Preview で 4,096 トークン、Gemini 2.5 Flash / Pro で 2,048トークン数としては非公表——キャッシュ単位はリクエスト境界、検出された共通プレフィックス、固定トークン間隔に落ちる
TTL既定で5分、任意で1時間GPT-5.6+ では prompt_cache_options.ttl 経由で既定30分、それ以前のモデルは prompt_cache_retention——インメモリ（通常5〜10分）または24時間暗黙キャッシュについて固定の公表既定値はない未使用になると「数時間から数日のうちに」自動退避
キャッシュ読み取りベース入力の 0.1 倍、Opus 5.5 で 0.05 倍、Fable 5.1 / Mythos 5.1 で 0.025 倍ベース入力の 0.1 倍キャッシュ入力レートとして別掲（Gemini 3.8 Flash で 2026-12-31 まで標準レートの 0.1 倍）キャッシュヒット入力レートが別掲、deepseek-v4-pro ではミスレートのおよそ 30 分の 1
キャッシュ書き込みプレミアム5分ティアでベース入力の 1.25 倍、1時間ティアで 2 倍GPT-5.6+ でベース入力の 1.25 倍暗黙キャッシュではなし、明示的キャッシュはストレージとして Gemini 3.8 Flash で 2026-12-31 まで 100万トークン・時あたり $0.50 を課金公表なし
ヒットの証明usage 内の cache_read_input_tokens と cache_creation_input_tokensusage 内のキャッシュ済みトークン数usage.total_cached_tokensprompt_cache_hit_tokens と prompt_cache_miss_tokens
会計 / ルーティングのヒントブレークポイントの配置prompt_cache_key——GPT-5.6+ ではキャッシュ会計の分離、それ以前はキャッシュルーティング——

セルフホストのオープンモデルでは、同じ考えが一段下のレイヤーでプレフィックスキャッシュとして存在します: vLLM と SGLang は共有プレフィックスの KV キャッシュブロックを再利用します。トークン単価がないので損益分岐を計算する必要もありません——コストは VRAM で、得られるのは請求額ではなくプリフィルのレイテンシです。vLLM は enable_prefix_caching として公開しており、V1 エンジンでは既定で有効なので、最近のビルドでは有効化よりむしろ無効化する場面のほうが多いでしょう。Ollama でモデルをローカル実行する と プライベートなローカル AI スタック を参照してください。

損益分岐ルール​

ここがプロバイダーのドキュメントが練習問題として残している部分です。明示的なシステムではキャッシュは無料ではなく、GPT-5.6 以降は OpenAI でも無料ではありません。書き込みプレミアムがあるということは、1回しか再利用しないプレフィックスは、キャッシュしないほうが安いことがあるという意味です。

P をベース入力レートでのプレフィックスのコスト、w を書き込み倍率、r を読み取り倍率、N を1つの TTL ウィンドウ内でプレフィックスを共有する呼び出し回数とします。

Without caching:  N · P
With caching:     w · P  +  (N − 1) · r · P

Caching wins when:   w + (N − 1) · r  <  N
Which solves to:     N  >  (w − r) / (1 − r)

公表されている倍率を入れてみます:

ティアwr損益分岐 N必要な再利用回数
Anthropic 5分、Opus 5.51.250.051.262回
Anthropic 5分、標準読み取りティア1.250.11.282回
Anthropic 1時間20.12.113回
OpenAI GPT-5.6+1.250.11.282回
自動、書き込みプレミアムなし10.101回——損にならない

つまり経験則は短くまとまります: TTL 内に2ヒットで黒字、1時間ティアを買うなら3ヒットを確認してから。 それ未満では、プレフィックスをキャッシュすることは小さく静かな損失です。

Pro tip
  • N は1日あたりの呼び出し回数ではなく、1つの TTL ウィンドウ内の呼び出し回数です。1日1,000回再利用されるプレフィックスでも、20分間隔のバーストで届くならバーストごとに書き込みを払い直します。
  • 1時間ティアは単純なアップグレードではありません。12倍長いウィンドウを買うために書き込みプレミアムが2倍になります——トラフィックが本当に疎なときだけ価値があります。

計算例: 5万トークンのプレフィックス、1日1,000回の呼び出し​

Claude Opus 5.5 で——ベース入力 $4/MTok、5分書き込み $5/MTok、読み取り $0.20/MTok、すべて Anthropic の料金表から:

Guided walkthrough1 of 4
  1. 50,000 トークン × 1,000 回 = 5,000万入力トークン。$4/MTok なら1日 $200、それが毎日、まったく変わらない内容に対して発生します。

教訓はステップ3とステップ2の対比です: 同じ呼び出し量、同じプレフィックスで請求額に3.3倍の差、それを決めたのは到着パターンと TTL の関係だけ。 到着パターンは、誰もスプレッドシートに入れない変数です。

ワークロードを移すときの5つの罠​

Watch out
  • TTL のギャップ: 10分ごとに走るジョブは OpenAI の既定30分ではヒットし、Anthropic の既定5分ではミスします。同じコード、同じプロンプト、ヒット率ゼロ。
  • 閾値のギャップ: 2,500 トークンのシステムプロンプトは Claude Opus 5.5（最小512トークン）と GPT-5.6（1,024）ではキャッシュされますが、Gemini 3.8 Flash（4,096）ではされません。エラーもなく静かに失敗し、ただ全額の請求が来ます。
  • 無効化要因のギャップ: プレフィックスが変わればどのプロバイダーも無効化しますが、自明でないトリガーが異なります。Anthropic ではツール定義、tool_choice、（モデル次第で）thinking と effort の設定を変えると無効化されます。OpenAI ではモデル、ツール定義、スキーマ、reasoning effort、verbosity、コンテキストのコンパクションの変更が該当します。
  • 書き込みプレミアムのギャップ: 再利用が少ないプレフィックスを自動プロバイダーから明示的プロバイダーへ移すと、キャッシュしないより高くなることがあります。ブレークポイントを付ける前に上の損益分岐ルールを回してください。
  • 可観測性のギャップ: usage のフィールド名に共通の規約はありません。あるプロバイダーのキャッシュフィールドをパースするダッシュボードは、プロバイダーごとのアダプターが必要です。さもなければ移行後にヒット率がゼロに見えます。

他に類のない Anthropic 固有の仕組みが1つ: キャッシュはブレークポイントごとに20ブロックの遡り窓で探索されます。着実に伸びていく会話はこの窓を追い越し、プレフィックスが変わっていなくてもヒットしなくなります——無効化ルールの全体は プロンプトキャッシュの経済学 を参照してください。

仮定せず、検証する​

ドキュメントは意図を説明しますが、usage は実際に課金された内容を説明します。走らせているすべてのプロバイダーで実際のヒット率を確認してください。

ワークロードのキャッシュヒット率を監査する

Audit prompt caching for this codebase.

1. List every place we call an LLM API, with the provider and model.
2. For each call site, identify the prefix that is stable across calls
 and anything volatile that appears BEFORE it (timestamps, user IDs,
 reordered tool lists, freshly serialized JSON with unstable key order).
3. Report the token length of each stable prefix and compare it to that
 provider's minimum cacheable length. Flag any prefix below it.
4. Estimate the typical gap between consecutive calls sharing each prefix
 and compare it to that provider's cache TTL. Flag any gap that exceeds it.
5. Show me where we read the cache fields back from the response usage.
 If we never read them, say so plainly — that is the finding.

Do not change any code. Give me a table of call site, provider, prefix
tokens, minimum, typical gap, TTL, and the fields we read.

名前を付ける価値のある失敗の兆候が2つあります。ダッシュボード上では同じように見えるのに、対処法が正反対だからです:

  • プレフィックスを共有すべき反復リクエストでキャッシュ済みトークンが常にゼロ → 安定した内容の前に変動する値が入っているか、プレフィックスが最小長を下回っています。2回の呼び出しでレンダリング後のプロンプトのバイト列を diff してください。
  • キャッシュ済みトークンはゼロでないのに請求額がほとんど動かない → プレフィックスはキャッシュされていますが、変動する後半部分に比べて短いのです。キャッシュは機能しています。お金が出ているのはそこではありません。代わりに出力トークンと エージェントがトークンを燃やす理由 を見てください。
用語を定着させる
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 6

理解度チェック

0/4
  1. あるプレフィックスがウィンドウ内でちょうど2回再利用されます。選んではいけないティアはどれ？
  2. 2,500 トークンのシステムプロンプトが Claude では問題なくキャッシュされ、Gemini 3.8 Flash に移したらキャッシュされなくなりました。最も可能性の高い原因は？
  3. 同じプロンプト、同じ1日1,000回の呼び出し。なぜ請求額が3倍になりうるのか？
  4. キャッシュ済みトークンはゼロでないのに、請求額がほとんど動きません。これは何を意味するか？
Key takeaways
  • 2つの設計、2つの失敗モード: 明示的キャッシュは印を付け忘れて失敗し、自動キャッシュは静かに失敗してヒットを強制できない。
  • キャッシュは自動的に無料ではない。書き込みプレミアムがあると、1つの TTL 内に N > (w - r) / (1 - r) 回の再利用が必要——5分ティアで2回、Anthropic の1時間ティアで3回。
  • 請求額を決めるのは呼び出し量ではなく到着パターンと TTL の関係: 同じ1日1,000回が Opus 5.5 で均等なら約 $10、バーストなら約 $34。
  • 最小プレフィックス長はプロバイダー間で 512 から 4,096 トークンまで幅がある——Claude でキャッシュされるプロンプトが Gemini Flash では静かにキャッシュされなくなる。
  • どのプロバイダーでもレスポンスの usage からヒット率を証明すること。フィールド名に共通規約はないので、ダッシュボードにはプロバイダーごとのアダプターが必要。
  • 安定した内容を先、変動する内容を後。セルフホストのプレフィックスキャッシュを含め、すべてのプロバイダーで効く唯一のレバー。

出典と追加資料​

次に読む​