OpenAI APIのプロンプトキャッシュ活用法｜自動で効く条件と料金設計

OpenAI APIでプロンプトキャッシュを有効化する設定画面を探して、結局見つからずに諦めた経験はないだろうか。結論から言うと、公式ガイドが明記している通り、対応モデルではプロンプトキャッシュは追加のスイッチなしに既定で有効になっている。効くかどうかを左右するのは有効化の手続きではなく、リクエストのプレフィックス（プロンプトの先頭から変化しない部分）をどう設計するかという1点に絞られる。本記事では公式ドキュメントの記述にもとづいて、キャッシュが自動で効く仕組みと外れる条件、モデルごとの料金差、Batch APIとの役割分担までを整理する。仮の例として、社内FAQボットのように毎回同じシステムプロンプトとツール定義を送り、ユーザーの質問部分だけが変わるリクエストを想定しながら読み進めてほしい。

プロンプトキャッシュとは何か（結論と3つのメリット）

プロンプトキャッシュとは、複数のリクエストが同じプロンプトの先頭部分（プレフィックス）を共有しているときに、モデル側の計算結果を再利用してコストと待ち時間を削減する仕組みのことを指す。

公式ガイドは、プロンプトキャッシュの効果を3点で説明している。1つ目は計算の効率化で、モデルがすでに処理したプロンプトの先頭を再計算せずに済む。2つ目はコストで、再利用されたトークンにはキャッシュ済み入力の割引レートが適用され、最大90%まで割引されると案内されている。3つ目は応答速度で、レスポンス開始までの入力処理時間が短くなる。これらは対応モデルで既定で有効になっており、利用者側でオン・オフを切り替える設定項目はない。公式ガイドには、Agents API経由の呼び出しもResponses APIと同じキャッシュ挙動に従うとの記載があり、セッション内でコンテキストを使い回すことは共有プレフィックスの維持に役立つが、セッションを維持すること自体がキャッシュヒットを保証するわけではないと明記されている。

キャッシュが「自動で効く」仕組み：プレフィックスとキャッシュブレークポイント

キャッシュブレークポイントとは、OpenAI側が保存・再利用できるプロンプトのプレフィックスの終端を示す区切りのことで、最初のリクエストが対象区間をキャッシュへ書き込み、後続のリクエストは長い一致から順に遡って一致するブレークポイントを探す。

モデルは入力トークンを処理する際にキー・バリュー（KV）状態と呼ばれる中間状態を計算しており、プロンプトキャッシュはこの状態そのものではなく、変化しない先頭部分（プレフィックス）に対応するKVテンソルを保存する仕組みだと公式ガイドは説明している。後続のリクエストが同じプレフィックスを持ち、一致するキャッシュエントリが見つかった場合にだけ、その部分の再計算が省略される。キャッシュの対象になるには、プレフィックスがモデルごとの最小キャッシュ可能トークン長を満たす必要があり、GPT-5.6以降はこの下限が1,024トークンと明記されている。GPT-5.6より前のモデルでは、ツールの有無や画像・出力スキーマ・reasoning.effort・verbosityなどのリクエスト設定によって下限が変動するとされ、固定値は示されていない。仮の例として、システムプロンプトとツール定義だけで900トークン程度しかない社内ボットを考えると、GPT-5.6系モデルでは1,024トークンの下限に届かず、キャッシュ自体が発生しない可能性がある。

自動で効かなくなる7つの設定変更（キャッシュが外れる条件）

キャッシュが外れる条件とは、リクエストの中でモデルへ渡す実際のレンダリング済みプレフィックスを変化させてしまう設定変更のことで、値を変えた瞬間に既存のキャッシュが破棄されるわけではないが、後続リクエストが同じ一致点を見つけられなくなる。

公式ガイドは、プレフィックスへ影響する主な設定として次の7つを挙げている。

このうちtext.formatはStructured Outputsの利用時に、toolsはFunction callingの利用時に発生する変更であり、構造化出力の使い方やFunction callingの使い方で作り込んだ定義を途中で変更すると、意図せずキャッシュ範囲が縮む点に注意したい。公式ガイドによれば、設定が変わったからといって既存のキャッシュエントリが即座に破棄されるわけではなく、変化点より前のプレフィックスは引き続き一致対象になりうる。仮の例として、reasoning.effortを毎ターン切り替える実装では、対応モデルであれば設定更新（configuration_update）を使うことで、リクエストレベルのreasoning.effortを変えずにプレフィックスを保ったまま推論強度だけを切り替えられる。

モデル世代で変わるキャッシュの挙動：GPT-5.6以降と旧世代の違い

モデル世代差とは、GPT-5.6以降とそれより前のモデルとでキャッシュの制御方法・課金倍率・保持時間の指定方法が異なっていることを指し、移行時にはコードとパラメータの両方を見直す必要がある。

最新モデルの立ち位置はGPT-6 Astraとは｜GPT-5.6との違い・料金・使い分け、モデル全体の選び方はChatGPT最新モデルの違いと使い分けであわせて確認しておくと、どの世代のキャッシュ仕様に従うべきか判断しやすい。公式ガイドは、24時間までの拡張保持に対応するモデルとしてgpt-5.5・gpt-5.5-pro・gpt-5.4・gpt-5.2・gpt-5.1系・gpt-5・gpt-5-codex・gpt-4.1を挙げている。仮の例として、gpt-5.1で動かしていたバッチ処理をgpt-5.6-solへ移行する場合、prompt_cache_retentionの指定をprompt_cache_options.ttlへ置き換える作業が発生する。

明示モード（explicit）と暗黙モード（implicit）の使い分け

explicitモードとは開発者がキャッシュ書き込みの区切りを明示的に指定する方式、implicitモードとはOpenAI側が直近の対象メッセージの末尾へ自動的にブレークポイントを置く方式のことで、GPT-5.6以降だけがexplicitモードに対応する。

GPT-5.6以降では、prompt_cache_options.modeでexplicitかimplicitかを選び、explicit時は対象のコンテンツブロックにprompt_cache_breakpointを付けて区切りを指定する。公式ガイドによれば、明示的なブレークポイントを置かないリクエストはキャッシュの書き込みも読み取りも発生せず、1リクエストあたり最大4か所までキャッシュ書き込み用のブレークポイントを作成できる。implicitモードを併用している場合はそのうち1枠が暗黙のブレークポイントに使われ、残り3枠を明示的な区切りに使える。トップレベルのinstructionsパラメータには明示的なブレークポイントを置けず、再利用したい開発者向け指示はdeveloperメッセージ内のinput_textブロックに入れる必要がある。

{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Judge whether the completed interaction provides evidence that the user is satisfied. Return true or false. Full grading rubric and labeled few-shot examples...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "user",
      "content": "Completed interaction to evaluate..."
    }
  ]
}

公式ガイドが紹介する単発型LLM-as-a-Judgeの例では、固定の採点基準と例示（few-shot）を先頭に置き、直後にexplicit-onlyのブレークポイントを設定し、評価対象の会話をその後ろに置くことで、ブレークポイント以降の会話部分をキャッシュ書き込みの対象から外している。あるデプロイ例ではトークンのキャッシュヒット率が約70%だったと紹介されているが、これは1つの事例の結果であり、実際に得られるヒット率の上限は利用状況によって変わるとガイド自身が注記している。このコード例が使っているResponses APIの基本構造はResponses APIとChat Completionsの違いと使い分けであわせて確認できる。

prompt_cache_keyで会話・ユーザー単位にキャッシュ精度を上げる

prompt_cache_keyとは、リクエストのキャッシュ利用状況をユーザーやワークスペース単位で分けて集計・ルーティングするための任意のキー文字列で、GPT-5.6以降では主に会計の分離に、それより前のモデルではキャッシュヒット率を上げるためのルーティング最適化に使われる。

キャッシュの実体は個々のマシン上に保持されており、1分あたり15リクエストを超えるトラフィックはオーバーフロー用のルーティングに回されうると公式ガイドは説明している。GPT-5.6より前のモデルでは、同じ再利用可能なプレフィックスを持つリクエストに安定したprompt_cache_keyを付けることで、関連リクエストを同じキャッシュへ寄せやすくする。トラフィックが多いグループでは、すべてのプレフィックスを合わせて1キーあたり概ね15リクエスト/分を目安に、複数のキーへ安定的かつ決定的な方法で分散させることが案内されている。GPT-5.6以降ではキーは省略可能で、顧客やユーザーごとにキャッシュ利用量や請求を追いやすくする目的で使う。公式ガイドが紹介するマルチターンエージェントの例では、agent_123_v1:user_456のようなキーをユーザー単位で固定し、同じユーザーのセッションやフォークで使い回すことで、あるデプロイ例ではトークンのキャッシュヒット率が90%を超えたと紹介されている。ここでも、この数値は一例の結果であり上限を保証するものではないと明記されている点は変わらない。仮の例として、社内向けチャットボットでユーザーIDごとにキーを分ける設計にすれば、ユーザーAとユーザーBのキャッシュ会計を分けて集計しやすくなる。

previous_response_idと会話履歴の保持でプレフィックスを伸ばす

previous_response_idとは、直前のレスポンスIDを次のリクエストに渡すことで会話の文脈をサーバー側に保持させ、毎回すべての履歴を手動で組み立て直さずにスレッド化された会話を続けられるパラメータのことを指す。

公式ガイドは、previous_response_idを使ってレスポンスを連結する方法と、role・contentの配列を自分で組み立てて過去のやり取りを手動で再現する方法の2通りを紹介している。プロンプトキャッシュの観点では、プロンプトキャッシュのガイドが推奨する「過去のメッセージやツール結果を書き換えずに追記する」という運用と相性がよく、会話履歴を保持し続けるほど再利用できるプレフィックスが伸びていく。一方で、要約やcompaction（圧縮）、文脈の切り詰めはプレフィックスを変化させ、キャッシュの再利用をリセットしうるとも説明されている。仮の例として、手動で履歴配列を組み立てる実装で、過去のユーザーメッセージの文言を後から修正してしまうと、その修正より前の部分までしかプレフィックスが一致しなくなる。previous_response_idで連結する方式であれば、過去のメッセージを書き換える操作自体が発生しにくく、このミスを避けやすい。

Batch APIとの違いと料金の位置づけ

Batch APIとは、即時応答を必要としないリクエストをまとめて非同期処理する仕組みで、同期エンドポイントに比べて50%のコスト割引と24時間以内の処理という条件で提供されるが、プレフィックスの再利用によってコストを下げるプロンプトキャッシュとは仕組みが異なる。

公式ガイドによれば、Batch APIは.jsonlファイルにまとめたリクエストを一括投入し、同期APIより高いレート制限枠を使いながら24時間以内（多くの場合はそれより早く）に結果を受け取れる仕組みで、同期エンドポイントに比べて50%のコスト割引が適用される。これは「同じプレフィックスを再利用したときだけ」安くなるプロンプトキャッシュとは別の軸の値引きであり、OpenAI Batch APIとは｜50%安い非同期処理の使い方と料金で解説している非同期処理の仕組みそのものを変えるものではない。料金ページ（2026年9月21日時点、Standard/Batch各tier、米ドル建て・1Mトークンあたり）を見ると、Batch pricing dataの表にもモデルごとのcached input列が用意されており、例えばgpt-5.6-solのShort context inputはStandardで4.00ドル・Batchで2.00ドル、cached inputはStandardで0.40ドル・Batchで0.20ドルと、どちらの表でもキャッシュ入力側に個別の単価が割り当てられている。Batch APIの解説ページ本文にはキャッシュとの併用可否を明言する一文は見当たらないため、実装時はレスポンスのusage.input_tokens_details.cached_tokensを自社のバッチジョブでも確認し、断定せずに実測で判断することを勧める。

この表からは、GPT-5.6系とgpt-5.5はキャッシュ入力が通常入力の0.1倍（=90%割引）になっているのに対し、gpt-4.1のキャッシュ入力は通常入力の0.25倍（=75%割引）にとどまり、キャッシュ書き込み側にも追加課金がない、という世代差がそのまま料金へ表れていることが読み取れる。仮の例として、深夜バッチで大量のレビュー文章を同じ分類ルーブリック（採点基準）付きで処理する場合、ルーブリック部分をexplicitモードのキャッシュ対象にしつつリクエスト自体をBatch APIへ投入すれば、プレフィックス再利用とBatchの非同期割引という2つの軸でコストを抑える設計になる。

料金試算の考え方：cached_tokensとcache_write_tokensの読み方

cached_tokensとcache_write_tokensとは、レスポンスのusage.input_tokens_detailsに含まれるフィールドで、入力トークンのうちキャッシュから読み取られた分とキャッシュへ新たに書き込まれた分をそれぞれ表す実測値のことを指す。

公式ガイドは、usage.input_tokens_details.cached_tokensとusage.input_tokens_details.cache_write_tokens、入力トークン数、レイテンシ、実際のコストを継続的に計測することを勧めており、キャッシュヒット率はキャッシュ済みトークン合計を入力トークン合計で割って、ユーザー・ワークスペース・日付などの単位で集計する方法を示している。入力コストの算出例として、次のような考え方が紹介されている。

function calculateInputCost(
  usage,
  inputPricePerMillion,
  cacheInputMultiplier = 0.1,
  cacheWriteMultiplier = 1.25
) {
  const inputTokens = usage.input_tokens;
  const cachedTokens = usage.input_tokens_details.cached_tokens;
  const cacheWriteTokens = usage.input_tokens_details.cache_write_tokens;
  const ordinaryInputTokens = inputTokens - cachedTokens - cacheWriteTokens;

  const weightedInputTokens =
    ordinaryInputTokens +
    cachedTokens * cacheInputMultiplier +
    cacheWriteTokens * cacheWriteMultiplier;
  const inputCost = (weightedInputTokens * inputPricePerMillion) / 1_000_000;
  return inputCost;
}

この式が示す通り、入力コストは「通常レートで課金される分」「キャッシュ読み取りレートが適用される分」「キャッシュ書き込みレートが適用される分」の3つに分けて計算する構造になっている。仮の例として、あるリクエストのinput_tokensが50,000、cached_tokensが40,000、cache_write_tokensが0だったとする。GPT-5.6系のようにcacheInputMultiplierが0.1の場合、この式に当てはめると通常入力扱いになるのは10,000トークン分だけで、残り40,000トークン分は0.1倍の単価で計算される。実際に使う単価は料金ページのモデルごとの金額を参照する必要がある。

移行・運用でつまずきやすい5つの落とし穴

落とし穴とは、プレフィックスの文字列自体は変わっていないように見えても、ブレークポイントの位置やモード設定の違いによってキャッシュが再利用されなくなる典型的な失敗パターンのことを指す。

公式ガイドの「Gotchas」の章は、次の5つを典型例として挙げている。

• 共有プレフィックスがあっても、静的な内容の直後に明示的なブレークポイントを置いていなければ、implicit-onlyのキャッシュ書き込みだけでは短い共有プレフィックスが再利用可能になるとは限らない
• あるリクエストがimplicitモードでメッセージ末尾までキャッシュを書き込んだ後、次のリクエストでexplicit-onlyモードに切り替えると、そのリクエストは自分自身の明示的ブレークポイントしか確認しないため、前回書き込んだimplicitなプレフィックスを再利用できない
• 両方のリクエストがimplicitモードでも、直前のリクエストで末尾だったメッセージに新しい内容を追記して1つのメッセージとして伸ばすと、その旧末尾はメッセージの途中になってしまい、明示的なブレークポイントがない限り再利用されない
• implicitモードでは、最初にまとまって並ぶdeveloperメッセージ群より後ろにあるdeveloperメッセージは自動的なキャッシュ照合の境界にならないため、再利用したい場合は明示的なブレークポイントを追加する必要がある
• compaction（圧縮）は過去の会話内容を短い表現へ置き換えるため、会話としては同じ内容でも圧縮直後の最初のリクエストは前回までのキャッシュを以前ほど再利用できないことがある

公式ガイドはこれらを踏まえ、圧縮前後で入力コストの合計を比較し、ヒット率が下がってもトークン数自体が減ることでコストが下がる場合があると説明している。OpenAI Codex 使い方のようなCLIエージェントも、内部的には長い会話履歴とツール定義を繰り返しモデルへ渡す仕組みで動いているため、同じ落とし穴が当てはまりやすい。OpenAI Codexの提供形態の違いのようにCLI・IDE・クラウドのどの形態で使う場合でも、ツール定義や指示文をターンの途中で書き換えない設計を意識すると、キャッシュ効率を保ちやすい。モデルの移行やコスト管理を組織的に進める際は、OpenAI Codex企業導入ガイド｜モデル・コスト・移行計画にある移行計画の考え方もあわせて参考になる。

よくある質問（FAQ）

Q1. プロンプトキャッシュは追加設定なしで有効になりますか

対応モデルでは既定で有効です。ただし実際にキャッシュが再利用されるかどうかは、プレフィックスが変化していないことと、直近の書き込みからモデルごとの保持時間内であることの両方に左右されると公式ガイドは説明しています。有効化の作業でヒットそのものが保証されるわけではありません。

Q2. どのモデルでも同じ割引率になりますか

いいえ。GPT-5.6以降はキャッシュ読み取りが通常入力の0.1倍、書き込みが1.25倍という共通ルールですが、料金ページによるとgpt-4.1のキャッシュ入力単価は通常の4分の1で、書き込み側の追加課金もありません。モデルごとの料金表を個別に確認する必要があります。

Q3. prompt_cache_keyは必須ですか

GPT-5.6以降では省略できます。主に顧客やユーザー単位でキャッシュ利用量の会計を分けたいときに使う任意項目です。5.6より前のモデルでは、キャッシュのルーティング精度を上げるために安定したキーを使うことが公式ガイドで案内されています。

Q4. 手動でキャッシュを消すことはできますか

公式ガイドには、手動でのキャッシュクリアは現時点で提供されていないと明記されています。エントリはモデルごとのキャッシュ保持時間（lifetime）と保持設定にしたがって自然に失効する仕組みです。

Q5. Batch APIと併用できますか

Batch APIのガイド本文にキャッシュとの併用可否を明記した一文はありませんが、料金ページのBatch pricing dataの表にも各モデルのcached input列が用意されており、Standard料金表と同様の構造でキャッシュ入力向けの単価が示されています。断定は避け、実装時は自社のバッチジョブでcached_tokensを確認することをおすすめします。

Q6. キャッシュのヒット率はどのくらい期待できますか

公式ガイドは、単発型LLM-as-a-Judgeの事例とマルチターンエージェントの事例という2つの導入例を挙げ、それぞれ約70%・90%超のトークンキャッシュヒット率が観測されたと紹介しています。ただしこれらは特定の実装での結果であり、どの程度まで再現できるかは扱うプロンプトの構造やトラフィックのパターンに左右されるとされています。

まとめ

プロンプトキャッシュは対応モデルで既定で有効になっており、有効化そのものより、変化しない先頭部分をどう設計し、どの設定変更でプレフィックスが崩れるかを把握することが節約の分かれ目になる。GPT-5.6以降ではexplicitモードとprompt_cache_options.ttl、それより前のモデルではimplicitモードとprompt_cache_retention・prompt_cache_keyという、世代ごとに異なる制御方法を押さえたうえで、usage.input_tokens_details.cached_tokensとcache_write_tokensを実測しながら、Batch APIとの役割分担も含めてコスト設計を組み立てていきたい。