chicchi.work

Article

⚡ Codex Day 16徹底解説：12時間プロンプトキャッシュとWorkの長期再利用、料金・実装・損益分岐点

codex, openai, chatgpt, ai, api

OpenAI・Codexの28日間アップデートを毎日、一次情報に基づいて詳しく解説しています。Day 17以降の新機能やリセットも見逃したくない方は、ぜひフォローしてください。

2026年10月20日（米国時間）、OpenAIの28日間アップデート Day 16 が公開されました。今回の発表は、大きく分けてAPIの12時間プロンプトキャッシュと、Codex / ChatGPT Workで過去の会話を再開するときの長期キャッシュ再利用の2つです。

Tibo Sottiaux氏は、APIで12時間のキャッシュを選択できるようになり、ログイン済みのCodex / Workユーザーについては、過去の会話を数時間後に再開してもキャッシュがヒットし、再処理によるペナルティがなくなると案内しました。

Day 16：Tibo Sottiaux氏の公式投稿

OpenAI Developer Community：28 days of Shipping at OpenAI

さらにOpenAI APIの公式変更履歴にも、2026年10月20日付でResponses APIの12時間キャッシュ対応が掲載されています。

OpenAI API Changelog

ただし、APIのキャッシュヒットは全リクエストで保証されるわけではありません。また、APIでは12時間の書き込みが通常入力の2.5倍に設定されています。

この記事では、KVキャッシュの仕組み、API設定と実装、キャッシュの最低保持期間、料金の損益分岐点、測定方法、長い会話での挙動、データ保護の注意点、Day 12との違いを詳細に説明します。

調査時点：2026年10月21日（日本時間）。 公式告知・API変更履歴・Prompt cachingガイド・料金表を照合しています。Codex / Work内部のキャッシュ保存方式、削除ポリシー、モデルやプランごとの効果測定値は公表されていません。「永久」を無期限のGPUメモリ占有や削除不能と同一視しないでください。

1. Day 16の変更点を比較

項目 OpenAI API Codex / ChatGPT Work
今回の改善 Responses APIで最低12時間のキャッシュ保持を選べる ログイン済みユーザーが過去の会話を再開した際のキャッシュ再利用を保証
利用条件 対応モデル・対応エンドポイント Codex / Workにログインして使用
設定 prompt_cache_options.ttl: "12h" 公式発表で手動設定は案内されていない
保持期間の表現 最低12時間。それ以上の保持もあり得る 発表では「期限なく保持」
キャッシュヒット 個々のAPI要求では保証されない 古い会話を再開するときのヒットを公式が保証すると表明
料金 12h書き込みが通常入力の2.5倍、読み取りは割引 APIとは異なる、プランの利用量体系
Day 16のリセット 追加発表なし 追加発表なし

同じ「キャッシュ」という言葉でも、APIの明示的なTTL設定と、Codex / Workが内部で行う再利用は別のサービス仕様です。

2. そもそもプロンプトキャッシュとは？

LLMは長い入力を毎回処理する

大規模言語モデル（LLM）は、入力を**トークン（token）**という単位に分け、各トークンを処理して回答を生成します。

例えば、Javaのバックエンド開発で、次の共通情報を毎回入力しているとします。

  • プロジェクトの共通ルール
  • APIとDBの仕様
  • リポジトリのファイル構成
  • 過去の会話履歴
  • 利用できるツールの定義

これらの内容が変わらなければ、同じ部分を繰り返し計算するのは無駄になり得ます。

そこで使うのが**Prompt caching（プロンプトキャッシュ）**です。

KVキャッシュとは？

OpenAIの公式ドキュメントでは、モデルが入力を処理するときの中間状態をKey-Value（KV）状態と説明しています。

これを再利用可能な形で保持することで、後続のリクエストでは同じ入力部分を処理し直すコストを抑えられます。

1回目
[ 共通指示 ][ ツール定義 ][ 長い仕様書 ][ 質問A ]
           ↓
   共通prefixのKV状態を保存

2回目
[ 同じ共通指示 ][ 同じツール定義 ][ 同じ仕様書 ][ 質問B ]
                 ↓
       一致するprefixを再利用
                 ↓
       新しい部分を計算して回答

**prefix（プレフィックス）**とは、入力の最初から連続して一致する部分です。

途中に変わった指示や日時が入ると、それ以降のprefixが一致せず、再利用できる範囲が短くなる場合があります。

キャッシュするのは過去の回答そのものではなく、再利用できるモデルの中間計算状態です。同じ質問を送っても、回答が固定されるわけではありません。

OpenAI公式：Prompt caching

3. APIの12時間キャッシュ：設定は1つ

以前は通常30分、今回は12時間を選択可能に

GPT-5.6以降の対応モデルでは、Responses APIのデフォルトの最低保持期間は30分です。

Day 16では12時間を選べるようになりました。

設定 最低保持期間 キャッシュ書き込み料金
"30m"（デフォルト） 30分 通常入力の1.25倍
"12h"（Day 16） 12時間 通常入力の2.5倍

ここで重要なポイントは3つあります。

① 12時間は「最低保持期間」である

必ず12時間ちょうどで破棄されるという意味ではありません。OpenAIがそれ以上保持する場合もあります。

② 2.5倍は追加課金ではなく書き込みそのものの単価

通常入力料金の1倍に2.5倍を加算して3.5倍になるわけではありません。

③ 保持期間が長いことと、必ずヒットすることは違う

キャッシュが利用可能でも、共通prefixが変わったり、モデルの条件が変わったりすればヒットしない場合があります。

4. Responses APIでの実装例

最小構成（JSON）

Day 16の12時間キャッシュを使うための主要な設定は以下です。

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": {
    "ttl": "12h"
  },
  "input": [
    {
      "role": "developer",
      "content": "共通の開発仕様とガイドライン（ここに長い固定情報を配置）"
    },
    {
      "role": "user",
      "content": "既存APIとの互換性について確認して"
    }
  ]
}
項目 意味
model 実行するモデル
prompt_cache_options.ttl キャッシュを書いたときの最低保持期間
input 入力メッセージ
developer アプリケーション側から与える指示
user 今回の質問・依頼

この短いサンプルをそのまま送ってもキャッシュ対象になるとは限りません。 GPT-5.6以降では、キャッシュ可能なprefixが少なくとも1,024トークン必要です。実際には長い共通仕様・ツール定義などを渡す場面で効果が出ます。

JavaScript（Node.js）での呼び出し例

Node.js 18以降の組み込みfetchを使う例です。

const apiKey = process.env.OPENAI_API_KEY;

if (!apiKey) {
  throw new Error("OPENAI_API_KEY を設定してください");
}

const sharedSpec = `
あなたはJavaのバックエンド開発を支援するエージェントです。
ここへ毎回参照する長いAPI仕様・設計ルール・コード例を配置します。
（実際は1,024トークン以上の共通prefixが必要）
`;

const response = await fetch("https://api.openai.com/v1/responses", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "gpt-6.1-sol",
    prompt_cache_options: { ttl: "12h" },
    input: [
      { role: "developer", content: sharedSpec },
      { role: "user", content: "この設計の問題点を3つ教えてください" },
    ],
  }),
});

const body = await response.json();

if (!response.ok) {
  throw new Error(`API request failed: ${response.status} ${JSON.stringify(body)}`);
}

console.log(JSON.stringify(body.usage, null, 2));

この例では、毎回内容が変わる質問を最後に置き、同じsharedSpecを使い続けることを意図しています。

本番では、認証情報をコードに直書きせず、入力長とコストを計測してください。

また、ttlが設定できるのは対応モデルのResponses APIです。すべての旧モデルやChat Completions APIへそのまま適用できるわけではありません。

実際にキャッシュできたか見る方法

レスポンスのusageから、キャッシュ関連の情報を確認します。

{
  "usage": {
    "input_tokens": 12000,
    "input_tokens_details": {
      "cached_tokens": 4000,
      "cache_write_tokens": 7000,
      "cache_write_tokens_details": {
        "ttl_30m_tokens": 3000,
        "ttl_12h_tokens": 4000
      }
    }
  }
}

上の数値は公式ガイドの料金計算を説明する例で、実行結果の実測値ではありません。

  • cached_tokens：キャッシュから読み取って課金された入力トークン
  • cache_write_tokens：新しく書き込んだトークン数
  • ttl_30m_tokens：30分の書き込みとして請求されたトークン
  • ttl_12h_tokens：12時間の書き込みとして請求されたトークン

通常入力トークン数はinput_tokens - cached_tokens - cache_write_tokensで計算できます。内訳の12h・30m書き込みを足した後に、cache_write_tokensをもう一度足さないように注意しましょう。

5. 12時間キャッシュは本当に安い？ 損益分岐点

12時間キャッシュは長時間保持できる一方、最初の書き込みが高いため、使い方によっては割高です。

例えば、GPT-6.1 Solのキャッシュ読み取り料金は、通常の入力の0.05倍です。

ここでは同じ長いprefixを完全に再利用するという単純化した仮定で、相対コストを計算します。料金は入力部分のみで、回答の出力費用は含みません。

2時間ごとに共通prefixを使う場合

09:00  共通仕様を読み込む
11:00  同じ仕様で質問
13:00  同じ仕様で質問
15:00  同じ仕様で質問

2時間おきなので、30分のデフォルトキャッシュは、それぞれ期限切れになると仮定します。

方法 相対入力コスト（4回）
毎回すべて通常入力で処理する場合 4.00
30分キャッシュを毎回書き直す場合 5.00
12時間キャッシュを1回書き、残り3回読み取る場合 2.65

内訳は、

12時間キャッシュ：
初回書き込み      2.50
2回目の読み取り   0.05
3回目の読み取り   0.05
4回目の読み取り   0.05
─────────────────
合計               2.65

2.65という値は公式の実測値ではなく、料金倍率から計算した例です。

実際のモデル実行では、prefixの一致範囲、新しい質問のトークン、出力、途中の追加コンテキスト、キャッシュのヒット可否により変動します。

何回使えば12時間が有利？

前提を「30分ごとにキャッシュが失効し、その度に1.25倍で書き直す」「12時間側は1回書いて以後すべて0.05倍で読める」と単純化した場合、

  • 1回利用：12h書き込み2.50は、30m書き込み1.25より高い
  • 2回利用：12hの2.55は、30m書き込み2回の2.50より少し高い
  • 3回利用：12hの2.60は、30m書き込み3回の3.75より安い

この条件では、3回以上の利用で12時間キャッシュが有利になります。

ただし、30分以内に高頻度で使うならデフォルトの30分キャッシュでも読み取りが発生します。その場合、12時間保持へ切り替えるメリットは小さくなり得ます。

6. 料金設定で誤解しやすいこと

キャッシュ読み取りも完全無料ではない

GPT-5.6以降のAPIでは、キャッシュ読み取りにモデルごとの割引単価が適用されます。

モデル例 通常入力に対する読み取り料金
GPT-6.1 Sol 0.05倍
GPT-6 Astraなど多くの対応モデル 0.10倍

12時間キャッシュにしても、読み取り単価そのものは30分キャッシュと同じです。

書き込み倍率は二重請求しない

一部の誤解として、通常入力1倍にさらにキャッシュ書き込み2.5倍を加える説明が見られますが、公式仕様は2.5倍が合計書き込み単価です。

APIのレート制限は消えない

キャッシュされた入力トークンも、**TPM（Tokens Per Minute：1分当たりのトークン制限）**には引き続き計上されます。

Prompt cachingによってAPIのRate Limitが無制限になるわけではありません。

コストは価格表とモデルに依存

実際のUSD料金は、モデル、Standard / Fast / Ultrafast、入力長、リージョンなどによって変わります。

最新の具体的な金額はOpenAI公式API料金表を参照してください。上の表の「2.5倍」「0.05倍」は、設定の比較に使うための倍率です。

7. キャッシュの置き方を自分で指定する：Explicit breakpoint

Day 16のAPI仕様では、GPT-5.6以降のモデルで自動（implicit）と明示的（explicit）なキャッシュ境界を使えます。

Implicit：自動でprefixの終端を決める

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": {
    "ttl": "12h"
  },
  "input": "長い共通コンテキストと質問"
}

この方式では、モデル側がキャッシュ可能なメッセージ境界に対して自動で候補を決めます。

Explicit：長く使うところだけ12時間にする

共通のプロジェクト仕様は12時間、セッション固有の情報は30分で保持したい場合があります。

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": {
    "mode": "explicit",
    "ttl": "30m"
  },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "長く使う共通API仕様・プロジェクトの説明...",
          "prompt_cache_breakpoint": {
            "mode": "explicit",
            "ttl": "12h"
          }
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "このセッションの背景...",
          "prompt_cache_breakpoint": {
            "mode": "explicit"
          }
        },
        {
          "type": "input_text",
          "text": "今回の質問..."
        }
      ]
    }
  ]
}

この例の意図は、

  1. 最初の長い共通仕様を12時間保持する
  2. セッション固有の文脈は30分保持する
  3. 最後の毎回変わる質問には不要なキャッシュ書き込みを行わない

というものです。

ただしbreakpointは直前の入力だけでなく、その位置までのprefix全体を対象にします。また、後の長いTTLの書き込みが前の短いTTLを覆う場合、課金方式に影響します。

30分の既存キャッシュを12時間へ更新するとき、以前払った書き込み料金が差し引かれるわけではありません。 公式ガイドはTTL混在時の課金例を掲載しています。

公式：Prompt caching / Mix lifetimes in one request

8. Codex / Workの「期限なくキャッシュ」はどういう意味？

Tibo氏のDay 16投稿では、ログイン済みのCodex / Workユーザーについて、過去の会話を再開してもキャッシュがヒットすると保証すると明言しています。

例えば、

09:00  既存Javaバックエンドの調査開始
         ↓
      長いコードやテスト結果を読む
         ↓
12:00  別の仕事で中断
         ↓
17:00  同じCodexスレッドへ戻る
         ↓
      キャッシュを再利用して作業を再開

ここでは長い既存コンテキストを扱うほど、最初から計算し直す無駄を減らせることが期待されます。

Day 16の「guaranteed to hit the cache」は、このスレッド復帰時の製品体験について述べたものです。

「永久」はGPUメモリの永久占有？

内部実装は公表されていません。

そのため、例えば、

  • 全会話のKVテンソルを永遠にGPU上へ置く
  • 会話を削除してもキャッシュが残り続ける
  • 何年後でも古いスレッドが同じモデル・同じコンテキストのまま利用できる
  • あらゆるモデル・全クライアントで同じ保証が適用される

といった主張は、Day 16の短い発表からは導けません。

「期限なく」というのは、ユーザーが過去の会話へ戻る際、キャッシュ失効による利用上のペナルティを避けるというサービス側の保証として理解するのが適切です。

コンテキストウィンドウが無限になるわけではない

コンテキストウィンドウは、モデルが一度の処理で取り扱える情報量の上限です。

キャッシュの保持期間とは別の概念です。

  • Day 7：GPT-6.1 Solの標準コンテキスト容量を272Kから500Kへ拡大
  • Day 12：サブエージェント間でのコンテキスト再利用とルーティング改善
  • Day 16：時間が空いても同じ会話のコンテキストキャッシュを利用しやすくする

Day 16でコンテキストウィンドウが無限大になったわけではありません。

AIが過去のすべてを必ず覚えるという意味？

これも違います。

プロンプトキャッシュは処理の効率を上げる機能です。ユーザーの長期記憶、会話検索、過去ログの保存、情報の正確な想起と同じものではありません。

9. APIの「保証されない」とCodexの「保証」が両立する理由

APIの公式Prompt cachingガイドには、次の趣旨の注意事項があります。

キャッシュ保持の設定は再利用の機会を提供するが、個別APIリクエストのキャッシュヒットや低遅延を無条件に保証するものではない。

一方、Day 16のCodex / Work向け発表は、古い会話へ戻るときのキャッシュ再利用を製品体験として保証すると述べています。

これは矛盾ではありません。APIの一般契約と、Codex / Workの内部サービス動作について、対象範囲が違うからです。

誤解 正しい整理
APIで"12h"にすれば毎回必ずヒットする 必ずではない
Codexの長期再利用はAPIの12時間設定と同じ 別の仕様
キャッシュ保持で入力が無限に扱える モデルのコンテキスト上限は残る
キャッシュがあるからAIが必ず過去を正しく覚える 再利用と記憶は別
キャッシュされたらAPI Rate Limitを消費しない TPMは引き続き計上

10. 旧モデルのprompt_cache_retentionとの違い

APIを既に使っている場合、以前からprompt_cache_retentionというパラメーターを使っているかもしれません。

しかし、GPT-5.6以降の新しい仕組みは次のように変わっています。

項目 GPT-5.6以降の新方式 旧モデル方式
APIパラメーター prompt_cache_options.ttl prompt_cache_retention
主な保持設定 "30m" / "12h" "in_memory" / "24h"等、モデルによる
キャッシュ書き込み 30mは1.25倍、12hは2.5倍 モデルの旧仕様に従う
Explicit breakpoint 対応 非対応
prompt_cache_key 主に顧客ごとのキャッシュ会計分離へ利用 同じprefixへのルーティング最適化で重要

以前から旧モデル向けに最大24時間のextended retentionが存在したケースもあります。

従って、「OpenAI APIで長時間のキャッシュが初めて可能になった」という説明は誤りです。今回新しいのは、GPT-5.6以降のResponses API向けに課金と保持時間を明示して選べる12時間TTLが追加された点です。

設定値の"12h"を旧モデルのprompt_cache_retentionにそのまま渡すことはできません。

11. セキュリティ・データ保持の注意点

12時間は削除期限ではない

ttl: "12h"は最低保持期間であり、データの削除期限やログの保持ポリシーを変更する設定ではありません。

コンプライアンス上「必ず12時間以内にキャッシュを消す」必要がある場合、今回のTTLを削除保証として使うことはできません。

Zero Data Retention（ZDR）も確認

OpenAIのAPIには、組織ごとのデータ保持設定があります。

キャッシュは、暗号化されたKV状態が一時的にGPU付近の保存領域などへ保持される場合があり、対象モデルや組織のデータ保持条件によって選択できるキャッシュ方式が異なります。

特にZDRを利用している場合は、利用可能な保持モードと組織の契約条件を最新の公式資料で照合してください。

「12時間キャッシュを有効にすれば、すべての企業の保持ポリシーを必ず満たせる」とは言えません。

顧客をまたいでキャッシュしてよい？

顧客ごとの権限境界を維持することが先決です。

共通prefixであっても、他社の機密情報や権限の異なる情報を意図せず混ぜないようにしてください。

新方式ではprompt_cache_keyが任意で、顧客・ユーザー・ワークスペース単位のキャッシュ会計を分ける目的に使えます。ただし、このキーだけをアクセス制御の代わりにしてはいけません。

12. 実運用で効率を測る方法

Day 16の恩恵があるかどうかは、キャッシュヒット率・書き込みコスト・応答時間を合わせて測る必要があります。

例えば、同じAPI設計資料を使うタスクを、短い間隔と長い間隔で比較します。

グループA：30分のTTL
  - 同じ長いprefix
  - 10分後と数時間後に再利用

グループB：12時間のTTL
  - 同じ長いprefix
  - 10分後と数時間後に再利用

比較
  - cached_tokens
  - ttl_30m_tokens
  - ttl_12h_tokens
  - レスポンス開始時間
  - 課金された入力コスト
  - 同じタスクの回答品質

時間が空いてもキャッシュが使えることが、常に最安・最速になるとは限りません。

モデル、入力、出力長を揃え、複数回測ることが重要です。

JavaScriptで入力コストを計算する例

function inputCostUSD(usage, inputPricePerMillion, cachedReadMultiplier = 0.1) {
  const d = usage.input_tokens_details;
  const readTokens = d.cached_tokens ?? 0;
  const writes = d.cache_write_tokens_details ?? {};
  const write30m = writes.ttl_30m_tokens ?? 0;
  const write12h = writes.ttl_12h_tokens ?? 0;
  const ordinary = usage.input_tokens - readTokens - write30m - write12h;

  if (ordinary < 0) {
    throw new Error("入力トークンの内訳が不正です");
  }

  const weighted =
    ordinary +
    readTokens * cachedReadMultiplier +
    write30m * 1.25 +
    write12h * 2.5;

  return (weighted * inputPricePerMillion) / 1_000_000;
}

// GPT-6.1 Solの場合、cachedReadMultiplierは通常0.05

この計算式は、GPT-5.6以降の両TTLの内訳があるレスポンス向けです。実際にはモデルの入力料金、使用モード、リージョン、出力料金なども加えて総額を評価します。

13. よくある質問

Q. Day 16はフルリセットだった？

いいえ。2026年10月21日時点の公式Day 16はキャッシュ改善の発表で、追加のフルリセットは確認されていません。 前日のDay 15にはライブ配信の後から追加リセットが発表されています。

Q. APIのキャッシュは永久になった？

いいえ。APIではResponses APIで最低12時間の保持を選べる仕様です。 Codex / Work向けの「期限なく」という表現と混同しないでください。

Q. GPT-6.1 Solの12時間キャッシュ料金は高い？

最初の書き込みは通常入力の2.5倍ですが、同じprefixの再利用時は0.05倍です。長い間隔を空けて何度も使うケースで有利になる可能性があります。

Q. 12時間後にキャッシュが消される？

必ず消えるわけではありません。 12時間は最低保持期間です。

Q. 5分後や30分後でも12時間を指定すべき？

必須ではありません。 高頻度の連続利用ではデフォルトの30分TTLの方が、書き込み料金が安くなる可能性があります。

Q. Codexで過去のスレッドに戻ると利用量が無料になる？

無料になるという発表ではありません。 再処理の無駄やキャッシュ失効のペナルティを避けるという改善であり、タスクの新しい処理や出力の利用量は引き続きかかり得ます。

Q. キャッシュが永久なら、何年前の会話でも完全に覚えている？

モデルが無限の文脈を理解できるわけではありません。 キャッシュ、会話履歴の保存、長期記憶、コンテキスト上限を分けて考えてください。

Day 1〜16：最近の変更との関係

Day 変更点
Day 7 GPT-6.1 Solの標準コンテキストを272K→500Kへ拡大
Day 11 モデル混雑エラーを減らし、自動継続しやすく
Day 12 サブエージェント間でコンテキストを再利用、保持期間・ルーティングを改善
Day 13 グローバルリセット
Day 14 Codexデスクトップで過去メッセージを編集可能に
Day 15 COOKED公式配信＋後から追加フルリセット
Day 16 Responses APIの12時間TTL、Codex / Workの長期キャッシュ再利用を保証

Day 12はキャッシュ効率の改善、Day 16は時間が空いた後の再利用とAPIの保持期間を扱う変更という違いがあります。

まとめ

Day 16のポイントは、**「長い間隔を空けて再開する作業でも、共通コンテキストを効率的に扱える」**ことです。

  • APIではResponses APIにprompt_cache_options.ttl: "12h"が追加
  • 12時間は最低保持期間であって削除期限ではない
  • GPT-5.6以降の対応モデルでは、30m書き込み1.25倍、12h書き込み2.5倍
  • キャッシュ読み取りは多くのモデルで0.1倍、GPT-6.1 Solでは0.05倍
  • 同じprefixを長い間隔で再利用するほど、12hが有利になる可能性がある
  • APIリクエストのキャッシュヒットは無条件には保証されない
  • ログイン済みのCodex / Workでは、過去スレッド再開時のキャッシュヒットを公式が保証
  • Codexの長期キャッシュは、APIの12時間設定やモデルの無限記憶とは異なる
  • Day 16の追加フルリセットは公式トラッカーに記録されていない

長い仕様書、リポジトリ調査、複数エージェントの並列作業、数時間中断するタスクなどでは、キャッシュを再利用できるかどうかが速度と実質利用量に影響します。

APIを使う場合は、まず30mと12hの両方でcached_tokensと実際の請求額を比較するのが確実です。

参考資料・一次情報

Day 17以降もOpenAI・Codexの28日間アップデートと追加リセットを毎日調査し、記事にまとめて発信します。今後の更新を追いたい方は、ぜひフォローしてください。