プロンプトキャッシュが効いていない時のサイン──OpenAI公式ドキュメントが認める「キャッシュが逆に高くつく」5パターン

OpenAI APIの「プロンプトキャッシュ」は、同じプレフィックス（プロンプトの先頭部分）を使い回すリクエストで、再計算せずに済んだ分のトークンを最大90%割引するという機能である。ただし2026年8月27日にplatform.openai.com/docs/guides/prompt-cachingを一次で確認すると、公式ドキュメント自身が「キャッシュが効かない」「効いているつもりが逆に割高になる」という具体的な落とし穴を、章立てして列挙していることが分かった。本稿はその原文をもとに、体感より課金が増えるケースと直し方を整理する。

3行まとめ

1. キャッシュ対象になる最小プレフィックス長はモデルの世代で違う。GPT-5.6以降は1,024トークン、GPT-5.5・5.5 Proと、それより前のモデルは2,048トークン。これに満たない共有プレフィックスは、あえて伸ばした方が総コストが下がることがある（公式ドキュメントが「最小キャッシュ長コストの罠」と名指し）
2. キャッシュへの「書き込み」自体は、GPT-5.6系では通常の入力トークンの1.25倍の値段がつく（例：gpt-5.6-solは通常入力$4.00/M・キャッシュ書き込み$5.00/M・キャッシュ読み出し$0.40/M）。1回しか再利用されないキャッシュは、そもそもキャッシュしなかった場合より高くつく
3. 「同じプレフィックスを共有している」ことと「実際にキャッシュがヒットする」ことは別物。モデル移行時の暗黙キャッシュの挙動変化や、会話の要約（compaction）がキャッシュ再利用率を下げる要因として名指しされている

プロンプトキャッシュの基本ルール

公式ドキュメントによれば、プロンプトキャッシュは対応モデルでデフォルト有効になっており、リクエストが同じプロンプトプレフィックスを共有していると、再利用された分のトークンについてモデルの「キャッシュ済み入力レート」が適用される。メリットとして挙げられているのは3点。

• 計算効率: すでに処理済みのプロンプトプレフィックスを再計算しなくて済む
• 入力コストの削減: 再利用トークンには割引された「キャッシュ済み入力」レートが適用され、割引幅は最大90%
• 応答速度: 応答が始まるまでの入力処理時間が短くなる

キャッシュヒット率は「Prompt Caching Dashboard」で監視できるとされている。ここまでは一般的な説明で、問題は「効いているはずなのに効いていない」ケースがどう起きるかだ。

落とし穴1: 最小キャッシュ長未満だと「伸ばした方が安い」逆転が起きる

原文にはこう書かれている。

"The chart highlights the minimum cacheable length cost trap where short prefix lengths can cost more uncached than expanding to the minimum cacheable token length."

多くのリクエストが同じ開発者向け指示やツール定義を共有していても、その共有プレフィックスがモデルの最小キャッシュ長を下回っていれば、そもそもキャッシュ対象にならない。この場合の対処として公式が勧めているのは「短くする」か「安定した有用な指示・例・参考資料を追加して、あえて最小キャッシュ長を超えるまで伸ばす」の二択で、そのうえで「キャッシュ再利用が、追加した入力トークン分やキャッシュ書き込み料金を相殺できているかを実測する」ことを求めている。つまり「プロンプトは短いほど安い」という直感が、キャッシュがある世界では常には成立しない。

最小キャッシュ長はモデルの世代によって異なる。今回curlでドキュメント内の「Summary of model differences（モデル間の違いのまとめ）」という比較表を実際に確認すると、次のように整理されていた。

つまり「GPT-5は1,024トークン」という単純な言い方は不正確で、正しくは「GPT-5.6以降は1,024トークン、GPT-5.5・GPT-5.5 Proを含むそれ以前のモデルは2,048トークン」となる。OpenAI提供の非表示システムコンテンツ分のトークンはこの最小値にカウントされない。また別モデルへ切り替えた際は、この閾値も引き継がれない。原文は「モデルを変えたら、その都度この確認をやり直すべきで、前のモデルの閾値がそのまま通用すると想定してはいけない」と明記している。

落とし穴0: キャッシュへの「書き込み」自体に1.25倍の料金がかかる（GPT-5.6系）

上の比較表にある通り、GPT-5.6以降のモデルでは「キャッシュ書き込み」自体に、通常の入力トークンの1.25倍という追加料金がかかる。これは記事の他の落とし穴とは別に、独立した項目として先に押さえておくべき点だ。

実際の単価をOpenAIの価格ページ（platform.openai.com/docs/pricing）とGPT-5.6 Solのモデルページ（developers.openai.com/api/docs/models/gpt-5.6）で確認すると、次のようになっていた（100万トークンあたりの価格、Fast mode・Short context）。

GPT-5.6 Solのモデルページには「Cache writes are billed at 1.25x the uncached input token rate.（キャッシュ書き込みは、キャッシュされていない入力トークンレートの1.25倍で課金される）」と明記されている。比較としてGPT-5.5のモデルページも確認したが、こちらの単価表（入力$5.00・キャッシュ入力$0.50・出力$30.00）にはキャッシュ書き込みの追加料金についての記載自体がなく、「Summary of model differences」表の「GPT-5.5には追加のキャッシュ書き込み料金がない」という記載と一致していた。つまりキャッシュ書き込みへの追加課金は、少なくとも今回確認した範囲ではGPT-5.6系に特有の仕組みだ。つまり、あるプレフィックスを一度もキャッシュしなかった場合の入力コストが$4.00だとすると、初回にキャッシュへ書き込む際は$5.00かかり、以降そのプレフィックスを再利用するたびに$0.40で済む。1回しか再利用されないキャッシュは、そもそもキャッシュしなかった場合（$4.00＋$4.00＝$8.00相当）より、書き込み＋1回読み出し（$5.00＋$0.40＝$5.40）のほうが安いが、もし一度も再利用されなければ、キャッシュしない場合の$4.00より書き込みコストの$5.00のほうが高くつく。「キャッシュを有効にしておけば自動的に安くなる」という思い込みは、この書き込み課金の存在によって崩れる。

なお、GPT-5.6のモデルページにはもう一点、キャッシュとは別だが見落としやすい料金ルールも書かれていた。「Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.（入力トークン数が272Kを超えるプロンプトは、リクエスト全体が入力2倍・出力1.5倍の料金になる）」という規定で、超過分だけでなくリクエスト全体に2倍・1.5倍の係数がかかる点に注意が必要だ。

落とし穴2: 「同じプレフィックスを共有」と「キャッシュがヒットする」は別物

見出し「A shared prefix is not always a cached prefix（共有プレフィックスが必ずしもキャッシュ済みプレフィックスとは限らない）」として説明されているケース。特にGPT-5.6以降への移行時に暗黙キャッシュの挙動が変わったことで顕在化しやすいという。

静的な開発者メッセージの後に、リクエストごとに変わる動的なユーザーメッセージが続く構成を想定すると、最初のリクエストは動的な内容込みで書き込まれる。次のリクエストでその動的内容を変えると、より長い（動的内容込みの）キャッシュ済みプレフィックスとは一致しなくなり、静的な部分だけを再利用するための独立したブレークポイントが存在しない限り、キャッシュは効かない。

落とし穴3: 会話の圧縮（compaction）がキャッシュ再利用率を落とす

長い会話をまとめて短縮する「compaction」は、それ自体がプレフィックスを変えてしまうため、圧縮直後の最初のリクエストは、会話としては論理的に同一でも、以前のキャッシュをあまり再利用できなくなる。公式の助言は「再利用可能な指示や参照資料はできるだけ安定させたまま、以降のターンは圧縮後のコンテキストの上に積み上げる」こと。そのうえで「圧縮の前後で総入力コストを比較すること。キャッシュヒット率が下がっても、入力トークン数自体が減っていれば総コストは安くなることがある」と、ヒット率だけを指標にしないよう釘を刺している。

落とし穴4: キャッシュに影響する設定変更に気づいていない

「Which settings affect the cached prefix?（どの設定がキャッシュ済みプレフィックスに影響するか）」という項目では、リクエストを変えても既存のキャッシュエントリが必ず破棄されるわけではないとしつつ、次の設定変更はプレフィックスの一致・不一致に影響すると明記している。

• model: モデルが変われば重みもキャッシュの挙動も変わる
• tools: ツール名・説明・スキーマ・並び順・ツール固有の指示の変更
• parallel_tool_calls: 複数ツール呼び出しに関する指示が変わりうる
• text.format（Structured Outputs）: 出力フォーマットの指示とスキーマが追加される

ツール定義を頻繁に書き換えている場合、意図せずキャッシュを毎回無効化している可能性がある。ドキュメントは「ツールは追記のみで更新する（append-only）」ことも別項目で推奨している。

落とし穴5: TTLはデフォルト30分固定、延長には別設定が必要

キャッシュの寿命はprompt_cache_options.ttlで制御でき、サポートされている値は30mのみで、これがデフォルトでもある。キャッシュされたプレフィックスは、直近の利用から30分間だけ再利用対象として残る。原文には「キャッシュされたプレフィックスに再びヒットするのは、一致するエントリを保持しているマシンにリクエストがルーティングされた場合のみ。キャッシュ再利用のためには、正しいマシンへのルーティングが重要」ともあり、prompt_cache_keyを使ってリクエストのルーティングを揃えることが推奨されている（ただしキーはルーティングに影響を与えるだけで、特定マシンへの固定やキャッシュヒットを保証するものではない、と明記されている）。

なお、古いモデル向けにはprompt_cache_retentionを"24h"に設定することで保持期間を延長できるという案内もあり、これはGPT-5.6以降のttl設定とは別の仕組みとして扱われている。

「効いているか」を自分で確認する方法

ドキュメントは、キャッシュヒット率を「合計キャッシュ済みトークン数 ÷ 合計入力トークン数」として、ユーザー単位・ワークスペース単位・日単位などでグルーピングして集計する方法を挙げている。1つの目安として「約70%のキャッシュヒット率」という数字も例示されているが、これはあくまで仮の数字であり、実際のヒット率は使い方次第で変わるとドキュメント自身が注記している。

実際のダッシュボード画面や請求実例は確認していない

• 本稿はplatform.openai.com/docs/guides/prompt-cachingの記述のみを根拠にしている。実際のダッシュボード画面や、キャッシュヒット率が下がった際の請求額の実例は確認できていない
• 「Summary of model differences」表とGPT-5.6モデルページの単価は今回確認できたが、GPT-5.5・GPT-5.4など個別の旧モデルそれぞれのキャッシュ読み出し単価（「モデルごとに異なる」とだけ表に書かれている部分）までは、1モデルずつ価格ページを突き合わせておらず、この記事では確認していない
• Standard mode・Long context（すなわちFast mode以外の価格帯）の具体的な単価は、価格ページに掲載されていることは確認したが、この記事ではFast mode・Short contextの数字のみを表にしている
• 「約70%のヒット率」という例示数値は、ドキュメント自身が「仮の数字であり、実測結果ではない」と明記しているため、目安以上の意味を持たせていない

関連記事

• Claude・GPT・Gemini API料金の読み方──2026年7月16日に公式ページで確認した単価早見表
• Devin AIのACU課金は結局いくらなのか
• Devin Adaptive──タスクごとにモデルを自動選び分けるCognitionのルーター機能