OpenAI APIに12時間のプロンプトキャッシュが追加。AIが長く覚えるようになるのか、費用と保存の扱いを整理

何が変わったか

OpenAI APIの変更履歴では、10月20日付でResponses API（v1/responses）に12時間のプロンプトキャッシュを選べる機能が追加されました。毎回同じ指示書や参照資料を先頭に付けて送る場合、その部分の処理結果を使い回して、入力料金を割安にする仕組みです。変更履歴では、リクエストの間隔が数時間あいても割引を受けやすくする目的が説明され、12時間指定の書き込みは通常入力の2.5倍の料金とされています。

公式のプロンプトキャッシュガイドによると、GPT-5.6以降のモデルでは prompt_cache_options.ttl で保持時間を指定します。選べる値は既定の "30m"（30分）と、Responses APIでの "12h"（12時間）です。書き込み料金は通常入力に対して30分が1.25倍、12時間が2.5倍です。読み出し料金はどちらの保持時間でも同じで、多くのモデルで通常入力の0.1倍、GPT-6.1 SolとGPT-6.1 Terraでは0.05倍です。

ガイドでは、この30分・12時間を「最短の保持時間」と位置づけています。OpenAIが指定より長く残す場合があり、12時間の指定は削除期限を決めるものでも、データ保持の上限ポリシーを変えるものでもない、という説明です。また、旧モデル向けの prompt_cache_retention という別の設定には影響しないと書かれています。

• 対象：GPT-5.6以降のモデルで、Responses APIを使うリクエスト
• 設定：prompt_cache_options.ttl に "30m"（既定）または "12h"
• 料金：書き込みは30分で1.25倍、12時間で2.5倍。読み出しは保持時間にかかわらず同じ
• 対応していない値を指定すると 400 invalid_request_error が返る

「AIが覚える」こととは別の話

名前に「保持」とあるため、入力した内容をAIが覚えるようになると受け取られがちですが、仕組みは別物です。ガイドの説明では、キャッシュに入るのは元の文章（トークン）ではなく、モデルが入力を処理する途中で計算するKVテンソルという中間データです。

しかも使い回しが起きるのは、後のリクエストが同じ先頭部分（プレフィックス）をもう一度送ってきたときだけです。アプリ側が前の相談内容を送らなければ、キャッシュがあってもモデルはその内容を参照できません。ChatGPTのメモリー機能のように、利用者についての情報を次の会話へ持ち越すものではない、と整理しておくと誤解が減ります。

ガイドには、キャッシュは組織をまたいで共有されず、地域ごとの処理境界もまたげないことも書かれています。他社のリクエストが自社のキャッシュを使うことはない、という点も確認できます。

誰に関係するか

直接関係するのは、GPT-5.6以降のモデルをResponses API経由で組み込んだ社内ツールを作っている開発担当者です。何も指定しなければ既定の30分のままなので、ツールを使うだけの人の画面や操作が、この変更で自動的に変わるわけではありません。

費用の管理担当者にとっては、12時間を選ぶと書き込み単価が上がる点が判断材料になります。情報管理の担当者にとっては、12時間という数字を削除期限と読み違えないことが要点です。保持の上限は別のポリシーで決まっていて、この設定では変わらない、というのがガイドの説明です。具体的な上限の値は、自社が契約しているデータ保持の条件とあわせて、公式のデータ取り扱い文書で確かめてください。

やること（確認する設定・判断の目安）

まず、自社のツールが条件に当てはまるかを確かめます。GPT-5.6以降のモデルを使い、Responses APIで送っているか。そのうえで ttl をどう指定しているかを開発担当者に確認します。指定がなければ既定の30分です。

次に、使い回せる部分があるかを見ます。12時間が向いているのは、毎回ほぼ同じ指示書や参照資料を先頭に置き、しかも利用の間隔が30分以上あくことがある場合です。ガイドでもこの用途が例に挙がっています。内容をたびたび書き換える部分は、書き込むたびに割高な料金がかかるだけになりがちなので、30分のままにするか、キャッシュの対象から外します。キャッシュできるのは、GPT-5.6以降では1,024トークン以上の先頭部分です。

費用は、応答の usage に出る cached_tokens（読み出し）と cache_write_tokens（書き込み）の実績で比べます。公表されている倍率で単純に計算すると、朝に書き込み、30分以上あけて夕方にもう一度使う場合、30分指定では書き込みが2回で1.25倍×2＝2.5倍、12時間指定では2.5倍の書き込み1回と0.1倍の読み出し1回で2.6倍となり、ほとんど差がありません。間があく利用が1日に3回、4回と増えるほど12時間が有利になります。これはキャッシュが必ず使い回された場合の計算です。ガイドでは、最短保持時間は割引の対象になる期間を示すもので、毎回の再利用を保証するものではないとされています。

最後に、既に30分で書き込まれた部分を12時間に切り替えると、その部分は新たに12時間分の書き込み料金がかかり、先の書き込み分は差し引かれません。切り替えのタイミングも費用に影響します。

仮例：就業規則の要約を前置きにする問い合わせボット

社内の問い合わせボットが、毎回同じ就業規則の要約（数千トークン）を先頭に付けて送っているとします。問い合わせが朝と夕方に偏り、あいだが数時間あくなら、規則の部分だけを12時間、個々の問い合わせの文脈を30分にする構成が考えられます。ガイドには、リクエスト全体の既定を30分にしつつ、特定の区切り位置（ブレークポイント）だけ12時間に上書きする書き方が示されています。

逆に、規則の要約を毎日更新しているなら、更新のたびに2.5倍の書き込みが発生します。朝夕2回程度の利用であれば、前の節の計算のとおり30分とほぼ変わらないか、かえって割高になるかもしれません。どちらの場合でも、キャッシュを有効にしたことでボットが前日の相談内容を覚えるわけではありません。前日の相談を踏まえた回答をさせたいなら、それは会話履歴をどう保存して渡すかという別の設計の問題です。

確認日と出典

本記事の内容は2026年10月29日に、OpenAI APIの変更履歴とプロンプトキャッシュガイドの公式ページで確認しました。料金倍率や対応モデルは今後変わる可能性があるため、設定を変える前に最新のガイドと料金ページを確認してください。

今回の原文で確認できなかった点、たとえば12時間指定のキャッシュが実際に最長でどれだけ残るのかや、ゼロデータ保持（ZDR）契約との詳しい関係は、本記事では断定していません。社内の保持方針と照らし合わせる際は、公式のデータ取り扱い文書や契約条件を直接確認するのが確実です。