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

Surya Pratap
By Surya Pratap

2026年10月21日

8 min read

AI & Technology
2つに分かれた図。左側は、GPT-5.6以降のOpenAIのプロンプトキャッシュ料金を、通常の入力料金に対する倍率で示したものです。30分キャッシュへの書き込みは1.25倍、12時間キャッシュへの書き込みは2.5倍、キャッシュからの読み取りは0.1倍(GPT-6.1 Solでは0.05倍)。12時間オプションは2026年10月20日にResponses APIで提供が始まり、1,024トークン以上のプレフィックスが必要です。右側は、2万トークンのプレフィックスを30分を超える間隔で12時間に8回使う場合の計算例で、課金されるトークン換算です。キャッシュなしは16万、30分キャッシュは毎回期限切れで書き直されるため20万、12時間キャッシュは6.4万。計算上、プレフィックスがその時間内に3回以上再利用されれば12時間キャッシュが有利になります。3回使えば元が取れるHover to explore
長いキャッシュでお金が浮くのは、リクエストの間隔がデフォルトのキャッシュの持続時間より長いときだけです。書き込み料金を払う前に、間隔を測りましょう。

プロンプトキャッシュは、品質に手を付けずにAIプロダクトの請求額を下げられる数少ない手段の1つです。OpenAIの新しいオプションでは、キャッシュへの書き込み料金が上がる代わりに、キャッシュがずっと長く持つようになります。それでお金が浮くかどうかは、ほとんどのチームが測ったことのない1点にかかっています。同じプロンプトを共有するリクエストどうしの間隔が、どれくらい空いているかです。

本記事は、OpenAIのプロンプトキャッシュのガイドと変更履歴、そしてRuntime Wireの記事に基づいています。料金は、OpenAIがGPT-5.6以降について公表している倍率です。第3節と第4節の損益分岐の数字は、それらの倍率から、そこで示す単純化した前提に基づいて筆者が計算したもので、OpenAIによるものではありません。

1. OpenAIが発表したもの

OpenAIは2026年10月20日、Responses APIで、既存のデフォルトである30分のキャッシュに加え、12時間のプロンプトキャッシュを開発者が選べるようにしました。OpenAIは、これを常駐型のエージェント向けとして打ち出しています。開発者向けアカウントは「dotsのような常駐型のエージェントは、1日を通してコンテキストを再利用する」と述べています。

GPT-5.6以降では、prompt_cache_options.ttlをデフォルトの"30m"ではなく"12h"に設定します。どちらも最低限の保持時間です。

2. 料金

GPT-5.6以降について、通常(キャッシュなし)の入力トークン料金に対する倍率で示すと次のとおりです。

料金
書き込み(30分キャッシュ)1.25倍
書き込み(12時間キャッシュ)2.5倍
キャッシュからの読み取り0.1倍(GPT-6.1 Solでは0.05倍)

ほかにも重要なルールが3つあります。

  • 最小サイズ: キャッシュされるのは、見える入力トークンが1,024以上あるプロンプトだけです。
  • プロンプト全体ではなくプレフィックス: キャッシュはリクエストの先頭部分を照合します。タイムスタンプ、ユーザー名、ツールの並び順など、プロンプトの前のほうで何かが変わると、それ以降はすべて一致しなくなります。
  • 個別の集計: 任意のprompt_cache_keyを使うと、顧客やユーザーごとにキャッシュを分けられます。

以前のモデルでは、キャッシュへの書き込みに追加料金はかからず、保持のオプションも異なります。

3. 計算してみる

システムプロンプト、ツール定義、参考資料からなるサイズPのプレフィックスが、12時間にN回再利用されるとします。出力トークンや、プロンプトのうち毎回変わる部分は、どの場合でもコストが同じなので除外します。

  • キャッシュなし: 各リクエストが1.0 × Pを払います。合計:N × P。
  • 30分キャッシュで、リクエストの間隔が30分を超える場合: リクエストの合間にキャッシュが期限切れになるため、毎回1.25 × Pで書き込み直します。合計:1.25 × N × P。
  • 30分キャッシュで、リクエストの間隔が数分の場合: 1回書き込み、あとは読み取り。合計:(1.25 + 0.1 × (N − 1)) × P。
  • 12時間キャッシュ: 1回書き込み、あとは読み取り。合計:(2.5 + 0.1 × (N − 1)) × P。

12時間キャッシュがキャッシュなしより安くなる条件を解くと、N > 2.7です。期限切れを繰り返す30分キャッシュと比べると、N > 2.1です。つまり、この単純化した前提では、同じプレフィックスを12時間以内に3回使った時点から、12時間キャッシュが有利になります。ただし、デフォルトのキャッシュが期限切れになる程度に、間隔が空いていることが条件です。

数分おきにリクエストが来るなら、デフォルトのキャッシュは切れることがなく、12時間オプションは時間枠ごとに1.25 × Pを余分に払うだけになります。

長いキャッシュでお金が浮くのは、リクエストの間隔がデフォルトのキャッシュの持続時間より長いときだけです。

4. 具体例

例として、指示、ツールのスキーマ、製品マニュアルからなる2万トークンのプレフィックスを持つサポートエージェントを考えます。ある顧客がこれを1日の業務時間中に、1〜2時間に1回くらいのペースで8回使います。プレフィックス部分で課金される入力をトークン換算すると、次のとおりです。

  • キャッシュなし: 8 × 20,000 = 160,000
  • 30分キャッシュ: 毎回期限切れ、8 × 1.25 × 20,000 = 200,000
  • 12時間キャッシュ: 2.5 × 20,000 + 7 × 0.1 × 20,000 = 64,000

プレフィックス部分では、キャッシュなしと比べて60%の削減です。そして、もう1つの見落としやすい点も浮かび上がります。このように利用間隔が空くトラフィックでは、読み取りが一度も起きないまま書き込みの割増料金だけを払うため、デフォルトのキャッシュはキャッシュをまったく使わない場合より25%高くなりえるのです。

顧客ごとにプレフィックスに独自の参考資料が入るなら、顧客ごとに書き込みが必要です。節約効果は顧客単位で生まれますが、時間枠の中で3回以上戻ってくる顧客に限られます。

5. 効果が出る場合と出ない場合

効果が出やすい。 長く安定した指示や資料を持ち、顧客1人あたり1日に数回使われるアシスタントやエージェント。社内コパイロット、アカウント担当のアシスタント、1〜2時間ごとに起動する定期実行のエージェント、業務時間中に断続的に使われるB2Bツールなどです。

効果が出にくい。 同じプレフィックスが数分おきに使われる、トラフィックの多い機能。デフォルトのキャッシュがすでに有効なままです。単発のリクエスト、1,024トークン未満のプロンプト、呼び出しのたびに先頭部分が変わるプロンプトも同様です。

まずプレフィックスを直す。 指示、ツール定義、参考資料など変わらないものは先頭に、変わるものは末尾に置きましょう。システムプロンプトの1行目にタイムスタンプがあるだけで、どんなキャッシュ期間も気づかないうちに無効になります。

切り替える前に測る。 プレフィックスごとに、何回再利用されるか、利用の間隔はどれくらいかを記録し、APIが返すキャッシュ済みトークン数を確認します。12時間はすべてではなく、そのパターンに本当に当てはまるプレフィックスにだけ適用しましょう。

デフォルトのキャッシュのコストを確認する

GPT-5.6以降に移行していて、プレフィックスごとのトラフィックの間隔が空いているなら、今すぐ請求書を確認してください。デフォルトのキャッシュの1.25倍の書き込み料金は見落としやすく、30分以上間隔の空いたリクエストでは純粋な余計なコストです。12時間について何かを決める前から、すでに払っているかもしれないコストです。

1回のリファクタリングにトークン代が14.29ドルかかった例で見たように、長く繰り返されるコンテキストは、エージェントを使うプロダクトで最大の隠れたコストです。キャッシュは最も安い対策ですが、それはユーザーの実際の使い方に合っている場合に限られます。

6. 筆者が言い切らないこと

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

Want to build with AI — not just read about it?

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.

Explore the Academy →
Share this post :