OpenAIの12時間プロンプトキャッシュは書き込みが2.5倍。計算上は3回目のリクエストから元が取れます

2026年10月21日
8 min read

2026年10月21日
8 min read
プロンプトキャッシュは、品質に手を付けずにAIプロダクトの請求額を下げられる数少ない手段の1つです。OpenAIの新しいオプションでは、キャッシュへの書き込み料金が上がる代わりに、キャッシュがずっと長く持つようになります。それでお金が浮くかどうかは、ほとんどのチームが測ったことのない1点にかかっています。同じプロンプトを共有するリクエストどうしの間隔が、どれくらい空いているかです。
本記事は、OpenAIのプロンプトキャッシュのガイドと変更履歴、そしてRuntime Wireの記事に基づいています。料金は、OpenAIがGPT-5.6以降について公表している倍率です。第3節と第4節の損益分岐の数字は、それらの倍率から、そこで示す単純化した前提に基づいて筆者が計算したもので、OpenAIによるものではありません。
OpenAIは2026年10月20日、Responses APIで、既存のデフォルトである30分のキャッシュに加え、12時間のプロンプトキャッシュを開発者が選べるようにしました。OpenAIは、これを常駐型のエージェント向けとして打ち出しています。開発者向けアカウントは「dotsのような常駐型のエージェントは、1日を通してコンテキストを再利用する」と述べています。
GPT-5.6以降では、prompt_cache_options.ttlをデフォルトの"30m"ではなく"12h"に設定します。どちらも最低限の保持時間です。
GPT-5.6以降について、通常(キャッシュなし)の入力トークン料金に対する倍率で示すと次のとおりです。
| 料金 | |
|---|---|
| 書き込み(30分キャッシュ) | 1.25倍 |
| 書き込み(12時間キャッシュ) | 2.5倍 |
| キャッシュからの読み取り | 0.1倍(GPT-6.1 Solでは0.05倍) |
ほかにも重要なルールが3つあります。
prompt_cache_keyを使うと、顧客やユーザーごとにキャッシュを分けられます。以前のモデルでは、キャッシュへの書き込みに追加料金はかからず、保持のオプションも異なります。
システムプロンプト、ツール定義、参考資料からなるサイズPのプレフィックスが、12時間にN回再利用されるとします。出力トークンや、プロンプトのうち毎回変わる部分は、どの場合でもコストが同じなので除外します。
12時間キャッシュがキャッシュなしより安くなる条件を解くと、N > 2.7です。期限切れを繰り返す30分キャッシュと比べると、N > 2.1です。つまり、この単純化した前提では、同じプレフィックスを12時間以内に3回使った時点から、12時間キャッシュが有利になります。ただし、デフォルトのキャッシュが期限切れになる程度に、間隔が空いていることが条件です。
数分おきにリクエストが来るなら、デフォルトのキャッシュは切れることがなく、12時間オプションは時間枠ごとに1.25 × Pを余分に払うだけになります。
長いキャッシュでお金が浮くのは、リクエストの間隔がデフォルトのキャッシュの持続時間より長いときだけです。
例として、指示、ツールのスキーマ、製品マニュアルからなる2万トークンのプレフィックスを持つサポートエージェントを考えます。ある顧客がこれを1日の業務時間中に、1〜2時間に1回くらいのペースで8回使います。プレフィックス部分で課金される入力をトークン換算すると、次のとおりです。
プレフィックス部分では、キャッシュなしと比べて60%の削減です。そして、もう1つの見落としやすい点も浮かび上がります。このように利用間隔が空くトラフィックでは、読み取りが一度も起きないまま書き込みの割増料金だけを払うため、デフォルトのキャッシュはキャッシュをまったく使わない場合より25%高くなりえるのです。
顧客ごとにプレフィックスに独自の参考資料が入るなら、顧客ごとに書き込みが必要です。節約効果は顧客単位で生まれますが、時間枠の中で3回以上戻ってくる顧客に限られます。
効果が出やすい。 長く安定した指示や資料を持ち、顧客1人あたり1日に数回使われるアシスタントやエージェント。社内コパイロット、アカウント担当のアシスタント、1〜2時間ごとに起動する定期実行のエージェント、業務時間中に断続的に使われるB2Bツールなどです。
効果が出にくい。 同じプレフィックスが数分おきに使われる、トラフィックの多い機能。デフォルトのキャッシュがすでに有効なままです。単発のリクエスト、1,024トークン未満のプロンプト、呼び出しのたびに先頭部分が変わるプロンプトも同様です。
まずプレフィックスを直す。 指示、ツール定義、参考資料など変わらないものは先頭に、変わるものは末尾に置きましょう。システムプロンプトの1行目にタイムスタンプがあるだけで、どんなキャッシュ期間も気づかないうちに無効になります。
切り替える前に測る。 プレフィックスごとに、何回再利用されるか、利用の間隔はどれくらいかを記録し、APIが返すキャッシュ済みトークン数を確認します。12時間はすべてではなく、そのパターンに本当に当てはまるプレフィックスにだけ適用しましょう。
デフォルトのキャッシュのコストを確認する
GPT-5.6以降に移行していて、プレフィックスごとのトラフィックの間隔が空いているなら、今すぐ請求書を確認してください。デフォルトのキャッシュの1.25倍の書き込み料金は見落としやすく、30分以上間隔の空いたリクエストでは純粋な余計なコストです。12時間について何かを決める前から、すでに払っているかもしれないコストです。
1回のリファクタリングにトークン代が14.29ドルかかった例で見たように、長く繰り返されるコンテキストは、エージェントを使うプロダクトで最大の隠れたコストです。キャッシュは最も安い対策ですが、それはユーザーの実際の使い方に合っている場合に限られます。
12時間キャッシュが必ず12時間持つとも、キャッシュからの読み取りが保証されるとも言えません。 OpenAIはどちらの保持時間も最低限のものとしており、キャッシュが外れることもあります。実際の節約額は、計算より多少小さくなるでしょう。
損益分岐の数字がOpenAIのものだとも言えません。 公表されている倍率から、同一のプレフィックスを前提とし、部分一致を考慮せずに筆者が計算したものです。
この料金がすべてのモデルに当てはまるとも言えません。 これはGPT-5.6以降の料金です。以前のモデルには書き込みの追加料金がなく保持のオプションも異なり、GPT-6.1 Solの読み取りは0.05倍です。
機密データに対しても、確認せずにキャッシュを使ってよいとは言えません。 OpenAIは、キャッシュされたデータがGPUのローカルストレージに保持されることがあるとしています。データの保持について約束していることがあるなら、キャッシュを長くする前に、それとどう整合するかを確認してください。
OpenAIは、Responses APIで12時間のプロンプトキャッシュを提供し始めました。GPT-5.6以降では、書き込みは入力料金の2.5倍で、デフォルトの30分キャッシュの1.25倍より高く、読み取りは0.1倍です。単純化した計算では、同じプレフィックスを12時間以内に3回再利用した時点から、12時間キャッシュはキャッシュなしにも、期限切れを繰り返す30分キャッシュにも勝ちます。ただし、リクエストの間隔が30分を超える場合に限られます。頻繁なトラフィックではコストが増えるだけで、間隔の空くトラフィックでは、デフォルトのキャッシュがすでにキャッシュなしより高くついている可能性があります。
判断を左右するのは機能そのものではありません。あなたのトラフィックのパターンです。
今週、長いプレフィックスごとに再利用の頻度と間隔を記録してください。変わらない内容をプロンプトの先頭に移しましょう。そのうえで、1日に3回以上、長い間隔を空けて戻ってくるプレフィックスにだけ、12時間を有効にしてください。
出典:OpenAI「プロンプトキャッシュのガイド」— デフォルトの30分キャッシュと12時間オプション、GPT-5.6以降のprompt_cache_options.ttlパラメーター、書き込み1.25倍と2.5倍、読み取り0.1倍(GPT-6.1 Solでは0.05倍)の料金、1,024トークンの最小値、プレフィックスの照合、prompt_cache_key、以前のモデルに書き込みの追加料金がないこと、GPUのローカルストレージに関する注意。OpenAI「APIの変更履歴」— 2026年10月20日の提供開始。Runtime Wire— Responses APIが対象であること、常駐型エージェントを想定していること、dotsに関するOpenAI Developersの発言。損益分岐の計算とサポートエージェントの例は、第3節と第4節に示した前提に基づく筆者の計算です。
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.