10月20日にOpenAIが追加した機能
この変更は、Responses APIにおけるGPT-5.6以降のモデルに適用されます。有効期限は prompt_cache_options.ttl で設定し、デフォルトの 30m（30分）と 12h（12時間）の2つの値を受け入れます。OpenAIのガイドでは、それぞれの使い分けについて説明しています。30分の有効期限は「コンテキストを頻繁に再利用する会話やエージェントのステップ」向けです。12時間の有効期限は「より長い間隔で再利用される、安定した指示や参照資料」向けです。
有効期限は、リクエスト全体または個々のブレイクポイントに対して設定できます。ガイドには「リクエストレベルの ttl は、暗黙的なブレイクポイント、および独自の ttl を持たない明示的なブレイクポイントに適用される」と記載されています。明示的なブレイクポイントは、prompt_cache_breakpoint.ttl を使用してこれを上書きできます。
12時間キャッシュへの書き込みは、30分キャッシュよりも高い書き込みレートで課金されますが、読み取りコストはどちらも同じです。OpenAI自身のアドバイスは、比較することです。「より高い12時間の書き込みレートと、30分のカバー範囲が切れた後にプレフィックスを再書き込みするコストを比較してください。」使用するモデルの現在の料金については、OpenAIの料金ページを確認してください。
古いモデルは独自の設定を維持します。ガイドによると、これらの新しい設定は「古いモデルの prompt_cache_retention パラメータを変更しない」とのことで、移行チェックリストには、GPT-5.6以降に移行する際に「prompt_cache_retention を prompt_cache_options.ttl に置き換える」よう指示されています。
プロンプトキャッシュが実際に保持するもの
キャッシュはプロンプトをテキストとして保存するわけではありません。OpenAIの説明によると、モデルは入力を処理する際、中間的なキー・バリュー（KV）状態を計算し、「プロンプトキャッシュは、再利用可能なプレフィックス（プロンプトの先頭にある変更されていないトークン）のためにその状態を保存する」とのことです。さらに、「プロンプトキャッシュはトークンそのものではなく、キー・バリュー（KV）テンソルを保存する」と付け加えています。
これには2つの結果が伴います。第一に、一致は完全一致である必要があります。「キャッシュを再利用するには、レンダリングされたプレフィックス全体が一致する必要があります。」第二に、キャッシュはモデルがそのプレフィックスをどう処理するかを変更しません。FAQには「プロンプトキャッシュは、モデルが出力トークンを生成する方法を変更しない」とあります。
言い換えれば、キャッシュとは、モデルがすでに処理した入力に対するコストとレイテンシに関するものです。情報を保存する場所ではなく、モデルに何かを記憶させるものでもありません。
12時間の有効期限が保証することと、未解決のまま残ること
名前に含まれる数字は「最小値」です。OpenAIのガイドには「OpenAIは、要求された最小値よりも長くエントリを保持する場合がある」とあり、この設定は「削除の期限を設定したり、最大データ保持ポリシーを変更したりするものではない」とされています。データ管理ページでも同様の区別がなされており、prompt_cache_options.ttl は「最小キャッシュ有効期限を制御するものであり、この最大アプリケーション状態保持期間を制御するものではない」と説明されています。
この最小値は、再利用の保証ではなく、料金適用の資格に関するものです。「最小有効期限は、キャッシュ読み取り料金の適用資格を規定します。すべてのリクエストが保存されたKVテンソルを再利用することや、レイテンシが低下することを保証するものではありません。」また、場所も重要です。「キャッシュされた状態は個々のマシン上に存在します。」そして「リクエストがキャッシュされたプレフィックスを再利用できるのは、期限切れになっていない一致するエントリを保持しているマシンに到達した場合のみです。」キャッシュの範囲も制限されています。「キャッシュは組織間で共有されず、地域的な処理境界を越えて再利用することはできません。」
読み取りによって12時間のタイマーが再スタートすることはありません。「30分の読み取りは、その読み取りから少なくとも30分後までカバー範囲を更新します。」その読み取りが12時間のカバー範囲を持つエントリに到達した場合、そのエントリは期限が遅い方を維持し、ガイドには「12時間のタイマーを再スタートさせたり、別の書き込み料金が発生したりすることはない」と記載されています。
アップグレードには新規の書き込みコストがかかります。「有効な30分のカバー範囲を12時間にアップグレードすると、それらのトークンに対して新しい12時間の書き込み料金が課金され、以前の書き込みに対するクレジットは付与されません。」頻繁に使用されるプレフィックスを30分から12時間に切り替える場合、切り替え後の最初のリクエストで新規書き込み料金が発生します。
また、有効期限を手動で制御することはできません。「現在、手動でのキャッシュクリアは利用できません。」
12時間のブレイクポイントの後ろに配置すべきコンテンツ
OpenAIの推奨事項は、プロンプトをその構成要素が変更される頻度によって分割することです。1日を通じて再利用する素材は、12時間のブレイクポイントを設定してプロンプトの先頭に配置します。より頻繁に変更されるセッションコンテキストには、デフォルトの30分を適用します。最新の質問は最後のブレイクポイントの後に残します。明示的専用モード（explicit-only mode）では、ここには「キャッシュ書き込み料金が発生しません」。
長寿命のプレフィックスに適しているのは以下のようなものです：
- 開発者向けの指示（Developer instructions）: エージェントの役割やルールを定義するもの。
- ツール定義（Tool definitions）: ガイドではこれを安定して保つよう推奨しています。「ツールの定義、順序、スキーマを維持してください。」
- 参照資料（Reference material）: エージェントがほとんどのリクエストで参照するもの。
そこに含めるべきではないのは、ユーザーごと、または日ごとに変更されるものです。ガイドには具体的にこう書かれています。「開発者向けの指示や共有素材にタイムスタンプ、ユーザー固有のコンテンツ、またはその他の動的コンテンツが含まれている場合は、それらを先頭ではなく末尾に配置するか、以降の会話メッセージに移動してください。」
構造上の重要な詳細が2つあります。「トップレベルの instructions には明示的なブレイクポイントを含めることができない」ため、マークしたい再利用可能な指示は「開発者メッセージ内の input_text ブロック」に配置します。また、プレフィックスは最小サイズをクリアする必要があります。GPT-5.6以降の場合、ガイドではこれを1,024個の可視入力トークンに設定しています。
長寿命プレフィックスを無効化する要因
最初のトークンから完全に一致する必要があるため、ブレイクポイントより前の変更は、それ以降のすべてを無効化します。「ブレイクポイントの前にコンテンツまたは関連する設定が変更された場合、その変更以降のプレフィックスは既存のキャッシュエントリと一致しません。」
これにはテキストだけでなく、設定も含まれます。ガイドでは、キャッシュされたプレフィックスに影響を与える可能性のある設定として、model、tools、parallel_tool_calls、text.format、reasoning.effort、text.verbosity、context_management を挙げています。GPT-6モデルでは、リクエストレベルの設定を変更する代わりに、configuration_update 項目を追加して推論の取り組み（reasoning effort）を変更することを提案しています。
履歴の書き換えもキャッシュを無効化します。ガイドのアドバイスは「以前のターンを書き換えるのではなく、新しいメッセージを追加する」ことです。なぜなら「要約、圧縮（compaction）、またはコンテキストの切り捨ては、プレフィックスを変更し、キャッシュの再利用をリセットする可能性がある」からです。our guide to Claude Code's idle compaction（Claude Codeのアイドル圧縮に関するガイド）では、キャッシュが期限切れになる直前に圧縮が行われるという、逆の視点からの同じトレードオフを示しています。
メッセージの拡張（追加）だけでも無効化されることがあります。あるリクエストが1つのコンテンツブロックを含むメッセージで終了し、次のリクエストがその同じメッセージに追記する場合、古いエンドポイントはメッセージの末尾ではなくメッセージの内部になってしまいます。そこに明示的なブレイクポイントがない限り、その時点で保存されたプレフィックスは再利用されません。
エージェントが依然として忘れてしまうこと
ここからが、キャッシュが長くなっても変わらない部分です。OpenAIの会話状態（conversation-state）ガイドは、基本から始まります。「各テキスト生成リクエストは独立しておりステートレスですが、テキスト生成リクエストのパラメータとして追加のメッセージを提供することで、マルチターンの会話を実装できます。」モデルが知っておくべきことは、自分で送信するか、保存された会話状態を参照するかにかかわらず、リクエストを通じてモデルに届く必要があります。
キャッシュは、安定したプレフィックスを再度送信するコストを安くするだけです。そこに何かを追加するわけではありません。火曜日の朝、エージェントが「顧客がプランを変更した」という事実を学んだとしても、その事実は午前8時に書き込まれた12時間のプレフィックスには含まれていません。これを含めるには、会話に追加するか、プレフィックスを編集するかのどちらかが必要です。プレフィックスを編集することはブレイクポイントの前の変更を意味するため、新しい書き込みが発生します。
そのため、設計上の問いが変わってきます。長寿命のプレフィックスは、共有素材を数時間安定して保つことにメリットをもたらします。1日を通じて進化するエージェントは、別の場所（会話の中、アプリケーションが取得するストア、または更新して定期的にプレフィックスに組み込む整理されたリスト）に属する事実を蓄積していきます。会話については、OpenAIのConversations APIが一つの手段です。ガイドによると、これは「独自の永続的な識別子を持つ長期実行オブジェクトとして会話状態を永続化できる」とのことです。会話をまたいで永続する事実については、自身で管理するソースが必要です。our comparison of AI memory APIs for developers（開発者向けAIメモリAPIの比較）で、その選択肢を解説しています。
多くの人が最初に試してしまうこと
すべてを12時間のプレフィックスに詰め込む。 ユーザー名、本日の日付、最新のチケットなど。これらはすべて変更されるものであり、ブレイクポイントより前の変更はすべて新しい書き込みを強制します。
12時間というのを「正確に12時間」と仮定する。 これは料金適用の資格を得るための最小値です。エントリはそれ以上長く保持されることもありますし、エントリを持つマシンにリクエストが到達しなければ、キャッシュミスが発生することもあります。
読み取りによって12時間のウィンドウが延長されると期待する。 読み取りは、その読み取りから少なくとも30分後までカバー範囲を延長するだけであり、12時間のタイマーを再スタートさせるわけではありません。
キャッシュをエージェントの記憶（メモリ）として扱う。 キャッシュは、送信したプレフィックスの処理済み状態を保持するだけです。それ自体に事実を保持しているわけではなく、出力に変化を与えることもありません。
測定せずに設定を切り替える。 12時間の書き込みはコストが高くなります。それが報われるかどうかは、プレフィックスがどれだけ頻繁に再利用され、その間隔がどれだけ空いているかによります。
解決策：プロンプトを変更頻度で分割し、安定した部分にのみ12時間を適用し、事実は自身で管理するソースに保持する
ステップ 1: プロンプトを「安定」「セッション」「最新」に分類する
エージェントからの実際のリクエストを1つ取り上げ、各部分をマークします：
- 安定（Stable）: ユーザー間で共通しており、数時間はそのまま維持される指示、ツール定義、および参照資料。
- セッション（Session）: 次の数分間にわたって再利用される、現在の会話またはタスクのコンテキスト。
- 最新（Current）: このリクエストにおける新しい質問またはツールの実行結果。
タイムスタンプ、ユーザー識別子、またはリクエストごとのデータを含むものはすべて、安定した部分から除外します。安定した部分がキャッシュ可能な最小サイズを下回る場合、ガイドでは「それを短縮するか、有用で安定した指示、例、または参照資料で拡張する」こと、そしてその結果を測定することを提案しています。
ステップ 2: ブレイクポイントを配置して結果を測定する
安定した部分を最初に、開発者メッセージ内に配置し、明示的なブレイクポイントを 12h に設定します。その後にセッションコンテキストを配置し、デフォルトの30分を適用します。最後のブレイクポイントの後に最新の入力を残します。GPT-5.6以降では、1回のリクエストで最大4つのキャッシュ書き込みを作成できるため、いくつかのレイヤーを設ける余裕があります。
その後、測定します。usageオブジェクトは cached_tokens と cache_write_tokens を報告し、これらのモデルでは cache_write_tokens_details が書き込みを ttl_30m_tokens と ttl_12h_tokens に分割して表示します。12時間のプレフィックスがどれだけ頻繁に書き込まれているかを監視してください。1日に何度も書き換えられている場合は、その中の何かが変更されていないか確認してください。
ステップ 3: エージェントが学習した事実を自身で管理するソースに保持する
新しい知識の保存先を決定します。短寿命のコンテキストは会話内に留めます。顧客のプラン、チームが下した決定、ユーザーが行った修正など、会話よりも長持ちすべき事実は、自身で管理するストアに保存します。
再利用パターンに適したスケジュールで、すべてのリクエストが必要とする事実を安定したプレフィックスに組み込みます。これにより、書き換えはすべての新しい詳細によってトリガーされるものではなく、意図的なイベントになります。残りの情報はリクエストごとに取得し、ブレイクポイントの後に配置します。
MemoryLakeでのセットアップ
12時間のキャッシュは、プロンプトの安定した部分がエージェントのスケジュールではなく、あなたのスケジュールで変更される場合に最も効果的です。つまり、エージェントが依存する事実は、キャッシュと個々の会話の両方から切り離された場所に保管される必要があります。
MemoryLake は、これらの事実を自身で管理する1つのリストに保持し、Codex、Claude Code、ChatGPTなど、接続するアシスタントから利用できるようにするためのメモリレイヤーです。
エントリはあなた自身の言葉で、あなた自身が書き込みます。OpenAIのプロンプトキャッシュ、APIの会話、保存されたレスポンス、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。ポリシーによってシステム外への持ち出しが許可されていない機密情報や個人データは除外してください。
ステップ 1: APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーはあなたの MemoryLake ワークスペースに属し、OpenAI のAPIキーとは異なります。
ステップ 2: 最初のメモリをアップロードする
解決策のステップ3で分類した事実（エージェントが会話をまたいで知っておくべき決定、修正、参照ポイント）から始めます。前回のプレフィックス再構築以降に何が変更されたかを確認できるよう、1つのエントリにつき1つのポイントを日付付きで登録します。
ステップ 3: AIとエージェントを接続する
使用しているアシスタントやコーディングエージェントを接続します。安定したプレフィックスを再構築する際、古い会話から再構成する代わりに、1つのリストから作業を行うことができます。
実務における変化
第一の違いは、12時間のプレフィックスが安定した状態に保たれることです。ユーザーごと、日ごとのデータが除外されたため、プレフィックスが変更されるのはあなたが再構築したときだけになり、usageオブジェクト内の書き込み回数がそれを示します。
第二に、新しい知識の保存先が明確になります。それは日中にキャッシュされたプレフィックスを編集するのではなく、会話の中、または自身で管理するリストに保存されます。
第三に、コストに関する意思決定が測定可能になります。推測に頼るのではなく、実際のトラフィックに基づいて12時間と30分の書き込みコストを比較できます。プロンプトの削減とコンテキストの維持という、より広範なトレードオフについては、our guide to why shorter prompts alone aren't enough（短いプロンプトだけでは不十分な理由に関するガイド）で他の手段を解説しています。
12時間プロンプトキャッシュのベストプラクティス
12時間は、数時間にわたって完全に同一であるコンテンツにのみ使用する。 指示、ツール、および共有の参照資料など。
タイムスタンプやユーザーデータは安定したプレフィックスから除外する。 それらは末尾に配置するか、以降のメッセージに移動します。
書き換えるのではなく、追加する。 圧縮や切り捨てはプレフィックスを変更してしまいます。
再利用可能な指示は開発者メッセージに配置する。 トップレベルの instructions には明示的なブレイクポイントを保持できません。
書き込みの内訳を確認する。 ttl_12h_tokens は、長寿命のプレフィックスがどれだけ頻繁に書き換えられているかを示します。
スケジュールに沿ってプレフィックスを再構築する。 新しい事実は、1つずつではなく、意図的にまとめて組み込みます。
永続的な事実はキャッシュの外に保持する。 our guide to how much memory to give an AI agent（AIエージェントに与えるべきメモリ量に関するガイド）で、保持すべきものと除外すべきものを解説しています。
結論
OpenAIの12時間プロンプトキャッシュにより、エージェントは安定した指示、ツール、参照資料をより長い間隔を空けても、キャッシュ入力レートで再利用できるようになります。ドキュメントはその制限について慎重に説明しています。12時間は料金適用の資格を得るための最小値であり、削除の期限や再利用の保証ではありません。また、読み取りによって12時間のタイマーが再スタートすることはなく、ブレイクポイントより前の変更は一致を無効化します。
また、キャッシュは知識を保持しません。各リクエストは、モデルが知っておべきことを依然として送信する必要があります。プロンプトを変更頻度で分割し、安定した部分にのみ12時間を適用し、エージェントが学習した事実は自身で管理するソースに保持して、自身のスケジュールに沿って組み込むようにしてください。