OpenAI、Claude、Geminiにまたがるプロンプトキャッシング
3つのプロバイダーはプロンプトのプレフィックスをキャッシュして入力コストとレイテンシを削減するが、制御方法は異なる。自動、明示的ブレークポイント、暗黙的の実践的比較。
プロンプトが長く安定したプレフィックス、たとえば大きなシステム指示、ツールカタログ、繰り返し尋ねるドキュメントを共有しているなら、プロンプトキャッシングによってプロバイダーはそのプレフィックスの再処理をスキップし、大幅な割引で課金します。OpenAI、Anthropic、Googleの3つすべてがこれを提供しており、見返りはどこでも同じです。すなわち、より低い入力コストと、キャッシュされた部分についてのより速い初回トークンまでの時間です。異なるのは、何がキャッシュされるかを誰が決めるかです。OpenAIはプレフィックスで自動的にキャッシュします。Anthropicはキャッシュポイントを明示的にマークさせます。Geminiはデフォルトで暗黙的にキャッシュし、明示的なキャッシュオブジェクトも公開しています。この記事では、3つの制御方法、それぞれが返す使用量フィールド、そしてキャッシュが実際にヒットするようにプロンプトを構造化する方法をマッピングします。
最終確認：2026-07-15。モデルごとの最小値、TTL、価格倍率は変化します。特定の数値に頼る前に、各プロバイダーのリンクされた価格・キャッシングページと照合してください。
3つすべてが共有する唯一のルール：プレフィックスをキャッシュし、サフィックスを変える
すべてのプロバイダーはプロンプトのプレフィックスをキャッシュし、正確なバイトで一致させます。実際的な帰結はベンダー間で同一です。変わらない部分を最初に、変わる部分を最後に置きましょう。システムプロンプト、few-shot例、ツール定義、大きな参照ドキュメントは先頭に属し、ユーザーの現在の質問は末尾に属します。これらを並べ替えると「キャッシュ可能」と「不可能」の境界が動き、単一の早い編集、たとえばシステムメッセージに注入されたタイムスタンプ1つでも、それ以降のすべてを無効化します。これはできる中で最もレバレッジの高い変更であり、しかも無料です。
キャッシングには最小サイズもあります。短いプロンプトはキャッシュする価値がなく、プロバイダーは単純にキャッシュしないため、割引はキャッシュされたプレフィックスがモデルごとに異なる閾値を超えて初めて現れます。それ未満では通常の入力レートを支払い、キャッシュされたトークンはゼロと表示されます。
OpenAI：自動、プレフィックスベース、prompt_cache_key で後押し
OpenAIのキャッシングは自動で、オプトインする必要はありません。1024トークン以上のプロンプトに対してキャッシングが自動的に有効になり、一致はプロンプトのプレフィックスを基に働きます。リクエストがすでにキャッシュされたプレフィックスを再利用すると、再利用されたトークンは割引されたキャッシュ入力レートで課金され、使用量オブジェクトに cached_tokens として現れます。Chat Completionsでは usage.prompt_tokens_details の下に、Responses API では usage.input_tokens_details の下にです。閾値未満のリクエストは cached_tokens をゼロと報告します。
キャッシングを直接制御することはできませんが、prompt_cache_key でルーティングに影響を与えられます。長い共通プレフィックスを共有しつつ異なるユーザーや経路から来るリクエストは、異なるキャッシュバックエンドに着地する可能性があります。関連するリクエストに同じ prompt_cache_key を設定すると、それがプレフィックスのハッシュと組み合わされてそれらを一緒にルーティングし、ヒット率を改善します。新しいモデルでは、このキーが一致を信頼できるものにします。OpenAIは、単一のキーに毎分数千のリクエストを浴びせるのではなく、キーごとのトラフィックを控えめに保つことを推奨しています。
保持は制御可能です。新しいモデルは ttl を伴う prompt_cache_options を受け付け（30分がサポートされる最小寿命かつデフォルト）、一方で以前のモデルは prompt_cache_retention を使い、そのインメモリエントリは一般に数分の非アクティブの間アクティブなままで、最大24時間まで延長できます。最新のモデルでは、キャッシュに書き込まれたトークンは cache_write_tokens として別途報告され、キャッシュされていない入力レートの1.25倍で価格付けされます。古いモデルは書き込み手数料を追加しません。ゲートウェイは prompt_cache_key と prompt_cache_retention を上流にそのまま通すため、1つのベースURLの背後で同じつまみを保てます。
Anthropic：自動または明示的な cache_control マーカー
Anthropicは cache_control マーカーが覆う範囲だけをキャッシュしますが、すべてのブレークポイントを手作業で配置する必要はありません。モードは2つあります。自動キャッシングでは、リクエストのトップレベルに単一の cache_control フィールドを追加します。システムが最後のキャッシュ可能ブロックにブレークポイントを置き、会話が伸びるにつれて前進させるため、複数ターンのチャットで手間を抑えたい場合に向きます。明示的ブレークポイントでは、個々のコンテンツブロックに cache_control を直接置き、何をキャッシュするかを細かく制御します。以下の例は、安定したプレイブックに明示的なブレークポイントを置いています。
import anthropic
client = anthropic.Anthropic(base_url="https://your-gateway.example.com", api_key="AVE_GATEWAY_API_KEY")
client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
system=[
{"type": "text", "text": "You are a contract analyst."},
{
"type": "text",
"text": LONG_STATIC_PLAYBOOK, # the expensive, stable prefix
"cache_control": {"type": "ephemeral"},
},
],
messages=[{"role": "user", "content": "Summarize the indemnity clause."}],
)
最大4つのキャッシュブレークポイントを定義できます。自動のトップレベルマーカーもそのうち1つを消費します。これにより、めったに編集されないシステムプロンプトを1つのブレークポイントの背後に、セッションごとのドキュメントを別のブレークポイントの背後に置くなど、異なる頻度で変わるセクションをキャッシュできます。キャッシュ可能な最小長はモデルに依存し、Claude Opus 4.8やSonnet 5を含む多くの現行モデルは1,024トークンから、一部のティアは2,048または4,096トークンからキャッシュします。最小未満のプロンプトはキャッシュなしで静かに処理されます。エラーはなく、ただ割引がないだけです。
使用量の計上は明示的で、注意深く読む価値があります。応答は3つの別々のカウントを返します。cache_creation_input_tokens（新しいキャッシュエントリに書き込まれたトークン）、cache_read_input_tokens（キャッシュから提供されたトークン）、input_tokens（最後のブレークポイント以降のすべて）です。合計入力はこの3つの和であり、両方のキャッシュカウントがゼロなら何もキャッシュされていません。デフォルトのキャッシュ寿命は5分で、エントリが使われるたびに無料でリフレッシュされるため、活発にヒットするキャッシュは事実上ウォームなままです。"ttl": "1h" オプションはより高い書き込みコストでそれを延長します。価格倍率は公開されています。5分キャッシュ書き込みはベース入力の1.25倍、1時間書き込みは2倍、そしてすべてのキャッシュ読み取りはベース入力の0.1倍です。その10倍の読み取り割引こそ、手間をかける理由です。
Gemini：デフォルトで暗黙的、制御が必要なときは明示的
Googleのデフォルトは最も手間がかかりません。Gemini 2.5以降のモデルでは暗黙的キャッシングが自動的に有効になり、リクエストがキャッシュにヒットするとコスト削減が自動的に適用されます。共通コンテンツを最初にしてプロンプトを構造化し、似たプレフィックスのリクエストを時間的に近く送り、使用量メタデータからキャッシュされたトークン数を読みます。最小値もここに適用されます。現行のFlashとProのティアは数千トークン台の低い部分からキャッシュを開始し、新しい世代はより大きなプレフィックスを要求します。
保証されたキャッシングと明示的な寿命制御が必要な場合、Geminiの generateContent APIは CachedContent オブジェクトを通じて明示的コンテキストキャッシングを提供します。コンテンツを一度アップロードし、ハンドルを受け取り、TTLを設定し、後続の呼び出しでそのハンドルを参照します。明示的キャッシングは、再利用するとわかっているコンテンツ（長いPDF、動画、固定の指示セット）について、暗黙的ヒューリスティックに委ねるのではなく割引を保証します。キャッシュされたトークン数は usageMetadata に現れ（generateContent では cachedContentTokenCount として）、ゲートウェイはこれを他のプロバイダー向けに報告するのと同じキャッシュトークンフィールドに正規化します。
ゲートウェイが正規化できることとできないこと
1つのOpenAI互換エンドポイントの背後で、ゲートウェイは各プロバイダーが理解するキャッシング制御を転送し、異なる使用量フィールドを単一の計上形式にまとめます。読み取り用の cached_tokens に加えてキャッシュ作成カウントも統合されるため、上流に関係なく、キャッシュされたリクエストは使用ログ上で同じように見えます。ゲートウェイは独自の設定可能な課金比率も適用します。キャッシュされた入力を通常レートより安く課金するキャッシュ読み取り比率と、キャッシュ書き込み用のキャッシュ作成比率（デフォルト1.25倍）で、モデルごとの値は公開 料金ページ に掲載されます。
ただし限界については明確にしておきましょう。3つのプロバイダーは同じつまみを公開していないため、正規化は両方向で損失を伴います。
- 制御は1対1でマッピングされない。 OpenAIは明示的ブレークポイントという概念なしにプレフィックスをキャッシュします。一方、Anthropicは自動または最大4つの明示的な
cache_controlマーカーを必要とし、OpenAI式の暗黙的プレフィックスキャッシュはありません。prompt_cache_keyはGeminiにとって何の意味も持ちません。パススルーは上流がサポートするものを転送し、サポートしないものは無視します。 - TTLのセマンティクスが異なる。 OpenAIの
ttlは最小寿命、Anthropicのは使用時にリフレッシュされる固定の5分（または1時間）ウィンドウ、Geminiの明示的TTLはキャッシュオブジェクトごとに設定されます。「1時間」は3つすべてで同じ意味ではありません。 - 使用量の語彙が異なる。 Anthropicは5分キャッシュ作成と1時間キャッシュ作成を分けます。OpenAIは新しいモデルでのみ読み取りと書き込みを分けます。Geminiは単一のキャッシュコンテンツカウントを報告します。ゲートウェイはこれらを共通フィールドにマッピングしますが、プロバイダーが決して報告しなかった区別を発明することはできません。
ゲートウェイは、1つの課金ビューと1つのパススルー経路を提供する場所として扱い、3つの異なるキャッシング設計を同一に振る舞わせる層としては扱わないでください。疑わしいときは、ゲートウェイが記録する生の使用量を読み、プロバイダー自身のドキュメントと照合しましょう。
キャッシュを実際にヒットさせる
4つの習慣が、キャッシングが役立つか静かに何もしないかを決めます。
- 安定したコンテンツを前に配置する。 指示、ツール、参照素材を最初に、ユーザーのターンを最後に。これが最も重要な単一のルールです。
- プレフィックスをバイト安定に保つ。 キャッシュ領域内にタイムスタンプ、リクエストID、並べ替えられたツール順序を入れないこと。早い位置で1バイトでも変わると、残りが無効になります。
- 関連するリクエストを時間的に近く送る。 キャッシュは期限切れになります。TTLウィンドウ内で似た作業をバッチ化するとエントリがウォームに保たれます。アイドルなキャッシュはコールドなキャッシュです。
- 雰囲気ではなく使用量で検証する。 節約を主張する前に
cached_tokens（またはプロバイダーの等価物）が非ゼロであることを確認しましょう。想定するだけで決して測らないキャッシングは、想像上のコスト削減のよくある源です。
プロンプトキャッシングは、LLM APIコストの削減 におけるコスト作業のより広いメニューの中で最も見返りの高い項目であり、LLMコンテキストウィンドウ管理 と自然に組み合わさります。キャッシュするのと同じ安定したプレフィックスは、しばしばそうしなければ毎ターン再送信して再課金されるコンテキストなのです。
FAQ
キャッシングは出力トークンのコストも削減しますか？
いいえ。キャッシングは入力（プロンプト）トークンにのみ適用されます。プロバイダーが再利用できるプレフィックスです。出力トークンは呼び出しごとに新たに生成され、キャッシュの状態に関係なく通常の出力レートで課金されます。コストが長いプロンプトではなく長い生成に支配されているなら、キャッシングは間違った数値を動かします。代わりに出力長とモデルの選択を見ましょう。
キャッシュ読み取りとキャッシュ書き込みのカウントが両方ゼロなら、キャッシングは失敗したのですか？
そのリクエストでは何もキャッシュされなかったことを意味します。通常はプレフィックスがモデルの最小キャッシュ可能サイズを下回っていた、前回の呼び出し以降プレフィックスが変わった、または（明示的スキームの場合）ブレークポイントをマークしなかったためです。プロバイダーはキャッシュ不可能なプロンプトでエラーを出さず、標準の入力レートで課金するだけです。ヒットを仮定するのではなく、使用量フィールドを読んで確認しましょう。
まったく同じプレフィックスを再送信すれば、キャッシュヒットは保証されますか？
いいえ。キャッシュはベストエフォートで時間制限があります。エントリはTTL後に期限切れになり、ヒットはルーティングにも依存します。だからこそOpenAIは関連するリクエストを同じバックエンドに誘導するために prompt_cache_key を公開しているのです。キャッシングは、課金の当てにできる保証ではなく、たいてい役立つ最適化として設計しましょう。
1つのゲートウェイリクエストで、OpenAI、Anthropic、Geminiのキャッシングを互換的に使えますか？
キャッシング制御を1つのエンドポイント経由で送れますが、それぞれ自身の上流だけが理解します。cache_control はAnthropicに届き、prompt_cache_key はOpenAIに届き、明示的な CachedContent ハンドルはGeminiに届きます。ゲートウェイは報告された使用量を共通フィールドに正規化しますが、あるプロバイダーに別のプロバイダーのキャッシング指示を尊重させることはできません。
実際の前後差を測る
最も反復的なプロンプト、つまり最大の固定プレフィックスを持つものを選び、1分以内にゲートウェイ経由で2回実行してください。最初の呼び出しではプレフィックスがキャッシュに書き込まれ、2回目ではキャッシュから読まれるはずです。使用ログを確認し、2回目のリクエストでキャッシュトークンがゼロではなく、入力料金が1回目より低いことを確かめます。自分のトラフィックで得たこの前後比較の方が、公開されたどんな倍率よりも実際の節約を正確に示します。