Codex、DAY15は改善なく使用量リセット｜DAY16は中断後に効くキャッシュ改善

朝に進めた記事やコードを、別の用事でいったん止める。夕方に同じ会話へ戻り、「続きからお願い」と頼む。AIを仕事に使うと、こうした中断と再開は日常的に起こります。そこで気になるのが、時間を空けたあとも、それまでの作業の土台を効率よく使えるかという点です。

Codexの「28日間、毎日改善かリセットか」の企画は、DAY15では新たな改善に至らず、使用量リセットへ。続くDAY16では、APIの12時間キャッシュと、ログインして使うCodex／Workでのキャッシュ保持が案内されました。 1 4 5

前回のDAY13・DAY14は、過去の指示を編集しやすくする更新でした。今回は、同じ仕事に時間を空けて戻るときの改善です。投稿の全文訳を確認したうえで、使いどころ、ClaudeやGeminiとの違い、APIで費用が下がる条件まで見ていきます。

---

---

DAY15は改善なく、使用量リセットへ

日本語訳

上段：Tibo氏の続報

15日目／やっぱり、さっきのはなしで。まだ仕込み中です……。そしてリセット。楽しんでください。

上段の引用カードと下段のTibo氏の初報（同じ文面）

15日目／もうお手上げです。

下段で引用されているOpenAI Developersの投稿

Codexで、こんなものを作っています。

動画の表題

COOKED：第1回。

図1：DAY15の初報とリセットの続報。2026年10月21日取得。出典：Tibo氏、OpenAI Developersの投稿。 1 2 3

DAY15では、Tibo氏がまず「We're cooked」と投稿し、その後に「まだ仕込み中……そしてリセット」と続けました。今回のDAY15は、改善を提供した日ではなく、使用量リセットの日として整理できます。 1 2

「cooked」には、俗語で「もうだめだ」「お手上げだ」といった意味があります。料理の映像を使った「COOKED」の告知に、「まだ仕込み中」という言葉を重ねたやり取り、と読むと分かりやすいでしょう。ここでの表現だけから、具体的な新機能の提供まで読み取ることはできません。 18

利用者として押さえたいのは、リセットの対象が、この連載で追っている使用量の枠だということです。会話やプロジェクトを消す操作として案内されたものではありません。また、このリセットと、後で取り上げる不具合の修正・クレジット付与は、別の話です。

---

DAY16は、時間を空けて同じ仕事に戻るためのキャッシュ改善

プロンプトキャッシュは、同じ入力の先頭部分に対して行った処理を、次の要求でも利用する仕組みです。 17

DAY16の発表は、利用方法によって説明が分かれます。アカウントにログインしてCodex／Workを使う場合と、プログラムからAPIを呼び出す場合です。この2つを分けると、「ずっと保持」と「12時間」が同じ投稿に出てくる理由を理解しやすくなります。

ログインして使うCodex・Workでは、古い会話への復帰を改善

Tibo氏は、Codex／Workにログインして使うユーザーについて、古い会話に戻ったり、数時間空けて再開したりするときのキャッシュの扱いを説明しています。 4

日本語訳｜Tibo氏のDAY16投稿

16日目。

APIでは12時間のキャッシュが使えるようになりました。また、ログインしてCodexやWorkを使うユーザーについては、キャッシュをずっと保持します。古い会話に戻ったり、数時間空けて再開したりしても不利になることはなく、今後はキャッシュにヒットすることが保証されます。

図2：Tibo氏によるDAY16の告知。本投稿の全文を掲載。2026年10月21日取得。出典：Tibo氏の投稿。引用元のAPI告知は図3に全文を掲載。 4

「キャッシュにヒットする」とは、以前の処理を再利用するためのキャッシュが見つかることです。投稿の「ずっと保持する」「ヒットが保証される」という表現は、時間を空けて同じ会話へ戻る場面についての説明として受け取れます。

たとえば、朝の作業をいったん止め、午後に同じ会話を開く。今回の改善は、そのような人間の予定に合わせた使い方に関わります。休憩や別の仕事を挟むこと自体で、不利にならないようにする方向です。

APIでは12時間のキャッシュを選べる

一方、OpenAI Developersは、APIで12時間のプロンプトキャッシュを選べると案内しました。Tibo氏の投稿で引用されているのが、次の投稿です。 5

日本語訳｜OpenAI Developersの投稿全文

APIで、12時間のプロンプトキャッシュを選べるようになりました。

dotsのように継続して動くエージェントは、一日を通してコンテキストを再利用します。

共通の指示、ツール、コンテキストをより長くキャッシュに保持し、リクエストの間が数時間空いても、低いキャッシュ済み入力の料金で利用できます。

図3：APIの12時間キャッシュを案内する公式投稿。2026年10月21日取得。出典：OpenAI Developers。 5

10月20日付のAPI変更履歴でも、この追加を確認できます。 対象はGPT-5.6以降のモデルをResponses APIで使う場合で、既定の30分に加えて、12時間を選択できます。 6 7

ここでいう12時間は、公式文書上の最低保持時間です。「最長12時間」や「12時間後に必ず削除」と読み替えないことが大切です。また、この最低時間はキャッシュ読取料金の適用条件を定めるもので、毎回の処理で保存済みの計算状態が再利用され、応答が必ず速くなることまで保証するものではありません。 7

「ずっと保持」と、AIの記憶力・利用上限は分けて考える

コードの背景資料や共通指示を繰り返し使う場面では、以前の入力処理を再利用できると、その都度すべてを同じように処理し直す負担を抑えられます。OpenAIは、今回より前からこの仕組みをAPIで提供してきました。 17

ここでは、似て見える3つの話を分けると整理できます。

DAY16で説明されたのは、主に1つ目の再利用です。投稿の「ずっと保持」を、すべての会話を無限に思い出せる、以後の処理が無料になる、と広げることはできません。モデルにはコンテキストの上限があり、入力・キャッシュ済み入力・出力には、それぞれの料金や利用条件があります。 9 10

---

どんな場面で役立つ？中断と再開の具体例

今回の改善が身近になるのは、「同じ仕事を、少しずつ進める場面」です。以下は、発表された内容を日常の作業へ当てはめた例です。改善前後の速度や使用量を測った結果ではありません。

午前にコードを直し、午後に確認と追加修正を頼む

Webサイトを修正するとき、午前にコードを変更し、午後に動作を確認して、もう一度直してもらうことがあります。途中で別の会議に入ったり、自分で画面を確認したりすれば、会話の間隔は自然と空きます。

そのたびに、サイトの目的、変更してはいけない部分、これまでの作業経緯が共通の背景になります。今回のキャッシュ改善は、こうした背景を再利用する余地を広げるものとして捉えられます。

一方、手元のファイルが変わっていれば、現在の内容を読む作業は必要です。「前の処理を再利用できること」と「最新のファイルを確かめること」は両立させたいところです。再開時には「前回の続き。現在の変更を確認してから、残りを進めて」と伝えると、作業の目的を共有しやすくなります。

記事の下書きを作り、時間を置いて推敲する

記事制作も、1回のやり取りでは終わりません。最初に資料を集め、構成を決め、下書きを読み、少し時間を置いて見直すことがあります。共通するのは、読者像、記事の目的、表記ルール、参照している基礎資料などです。

こうした長い背景を使いながら、「導入を読みやすくする」「比較表を見直す」「結論が本文と合っているか確認する」と進める仕事では、同じ会話へ戻る意味があります。

ただし、以前の会話で参照した資料が、その後も最新とは限りません。キャッシュの有無にかかわらず、ニュースや料金を扱う記事では、再開時に更新された情報を取り直し、以前の資料との違いを確認します。再利用したい土台と、新しく調べる内容を分けることが、読みやすさと正確さの両方につながります。

なお、翌日に戻るCodex／Workの説明と、APIの12時間という設定は同一ではありません。APIで12時間を超える間隔の再利用まで、この新設定だけで保証されたと扱うのは避けたいところです。

一日を通して、同じルールで動くエージェント

OpenAI Developersが例に挙げたのは、dotsのように継続して動くエージェントです。 5

たとえば、共通の確認基準を使って、朝・昼・夕方に新しい情報を整理する仕事を考えてみます。毎回変わるのは新着情報ですが、「何を重要とみなすか」「どういう形式でまとめるか」といったルールは共通です。

このような設計では、共通部分を長く再利用できることに意味があります。APIで作る場合は、変わりにくい指示や基礎資料を先頭に置き、その後に新しい入力を足す構成が考えられます。OpenAIのキャッシュは先頭部分の一致を使うため、冒頭から毎回内容を作り変えると、再利用の条件が変わります。 17

反対に、効果を大きく見込みすぎないほうがよい作業

毎回違う短い質問をする場合は、再利用する共通部分が多くありません。今回のAPI方式では、キャッシュ対象となる共通部分が1,024トークン以上あることも条件です。 新しい長文を大量に生成する仕事では、出力の処理も残ります。したがって、キャッシュが使える入力の割引率を、そのまま仕事全体の削減率に置き換えることはできません。 7 8

さらに、再利用できるかどうかと、正しい答えが出るかどうかは評価する軸が違います。背景を効率よく扱えても、前提が間違っていれば、前提の修正が必要です。キャッシュのために必要な訂正を我慢するより、正しい条件に直したうえで作業を進めるほうが大切です。

---

APIの12時間キャッシュは、再利用の回数と費用をセットで見る

APIの発表で見落としたくないのは、保存を長くする際の書き込み料金です。公式の変更履歴では、12時間キャッシュへの書き込みは通常入力の2.5倍と案内されています。この2.5倍は、通常入力にさらに足す追加分ではなく、書き込む入力に適用する料金倍率です。 6 8

アプリを利用する立場では、ここをそのままCodexの契約内利用へ当てはめないでください。Codexの料金案内は、クレジット課金に別建てのキャッシュ書き込み料金はないと説明し、APIキーによる利用はAPI料金に従うと区別しています。 10

共通の入力10万トークンを再利用すると、どう違う？

例として、GPT-6.1 SolのStandard料金で考えます。100万トークン当たり、通常入力は2ドル、12時間キャッシュへの書き込みは5ドル、キャッシュからの読取は0.10ドルです。トークンはAIが情報を処理する単位で、日本語の文字数と1対1で対応するものではありません。 8 9

ここでは、変わらない共通部分10万トークンだけを計算します。最初の1回で12時間キャッシュへ書き込み、あとの要求では同じ部分をすべて再利用できると仮定します。比較対象は、その共通部分を毎回通常入力として処理した場合です。

この条件では、再利用が1回だけだと、12時間キャッシュのほうが高くなります。再利用が2回になると、初回の書き込み負担を取り戻せます。長く保持することの価値は、実際に同じ部分へ何回戻るかで変わるわけです。

計算条件：2026年10月21日確認のStandard・入力全体が272Kトークン以下の場合の米ドル料金。追加の入力、出力、ツール、地域処理などの料金は含みません。キャッシュの途中変更・再書き込みはなく、12時間の保持範囲内で全量を読み取れる想定です。実測値でも、Codexの利用枠の換算でもありません。また、既定の30分キャッシュと比較した表ではありません。 8 9

作業が短時間に集中するなら、長い保持が得とは限らない

短時間で何度もやり取りを終える仕事では、30分の設定でも再利用できる場合があります。その場合に、保持時間だけを長くしても、長く保持するための書き込み負担に見合わないことがあります。

一方、数時間おきに同じ資料へ戻る設計なら、12時間の選択肢が意味を持ちます。APIの利用者が確認したいのは、次の3点です。

• 同じ共通部分を、どれくらいの間隔で再利用するか。
• その部分を、保持している間に何回使うか。
• 入力だけでなく、出力やツールを含めた全体の費用がどう変わるか。

公式資料を読むときも、「キャッシュ読取は安い」という部分と、「最初に書き込む料金」をセットで見ると、判断を間違えにくくなります。

---

ClaudeやGeminiは？保持期間と課金の仕組みを比べる

同じ入力を再利用して、処理や料金の負担を抑える仕組みは、ClaudeやGeminiにもあります。ただし、期間の意味、期限の更新、料金の付け方が違います。「何時間残るか」だけで並べると、重要な条件が抜けてしまいます。

API同士で比べると、期間と保存費用の設計が違う

次の表は、2026年10月21日に確認したAPIの説明です。Codex、Claude Code、Geminiアプリの月額プランや利用回数を比較した表ではありません。

出典：OpenAI、Anthropic、Googleの公式文書・料金表。OpenAIとClaudeの「最低保持時間」を、「最長の保持時間」と読み替えないこと。Geminiの明示キャッシュは、キャッシュを作って参照する方式です。 7 8 13 14 15 16

Geminiでは、Interactions APIとGemini 4 Argon以降は暗黙キャッシュのみで、明示キャッシュは使えないと現行ガイドに記載されています。「Geminiなら、どのモデルでも保存時間を指定できる」という説明は避ける必要があります。 15

また、Claudeの読取料金も一律ではありません。現行の料金表では、Opus 5.5とSonnet 5.5は通常入力の5％、Fable 5.1は2.5％です。古い解説の「キャッシュは一律90％引き」を、そのまま全モデルへ当てはめるとずれが出ます。 14

Claude Codeにも、中断後のキャッシュについて公式説明がある

開発ツールとして比較すると、Claude Codeはキャッシュを自動管理します。既定では、Claudeサブスクリプションの付属利用枠内で使う主会話は1時間、APIキーや追加使用クレジットなどで使う場合は5分という区別があります。サブエージェント等には別の扱いがあり、主会話の設定を全処理へ広げることはできません。 12

公式文書は、長く中断して期限を過ぎたあとには入力の再処理が起こり、戻った最初の応答が遅くなり得るとも説明しています。保持時間は、開発者向けの数字に見えて、休憩後や別作業から戻るときの体験に関わるものです。 12

この観点で読むと、DAY16のCodex／Workの告知は、時間を空けて古い会話へ戻る利用者の負担を、正面から取り上げたものと分かります。ただし、今回の発表と各社の仕様だけから、同じ課題での実際の速度や総費用の順位までは決められません。

選ぶときは、自分の作業の間隔を基準にする

人が確認しながら何時間もかけて進める仕事、短時間でまとめて処理する仕事、同じ資料を複数日にわたって参照する仕事では、合う設定が変わります。

APIなら、保持期間に加えて書き込み・読取・保存時間の費用を見ます。アプリなら、自分の契約での使い勝手と利用枠を見ます。さらに、出力の正確さや修正の少なさも大切です。キャッシュの条件だけを、AI全体の性能評価にしてしまわないほうが、選び方が実用的になります。

---

約4万アカウントの使用量不具合は、別に修正・補償

同じ時期に、使用量が想定より速く減る問題についても説明がありました。Tibo氏の投稿によると、選択したプランと利用上限・使用量の適用に不整合があった、約40,000アカウントを特定したとしています。 11

日本語訳｜使用量の不具合についての投稿全文

週末、一部のユーザーから、使用量の残りが想定よりも速く減るという報告がありました。

利用上限の扱いに不整合があり、実際に適用されていた使用量の扱いが、選択しているプランに対応していなかった約40,000のアカウントを特定しました。

該当するすべてのユーザーへ個別に連絡しており、問題は修正済みです。この問題の影響を受けた方には、アカウントにクレジットを追加します。

私たちの対応に誤りがあり、申し訳ありません。

図4：約40,000アカウントについての修正・補償の説明。2026年10月21日取得。出典：Tibo氏の投稿。 11

この投稿では、問題は修正済み、個別連絡は進行中、クレジット追加は影響を受けた人への対応として説明されています。全対象者への連絡や付与が完了した、とまでは書かれていません。また、現金での返金や、すべてのユーザーへの一律付与を案内したものでもありません。

今回の話を、目的ごとに並べると次のようになります。

出典：各投稿。 1 4 11

「使用量が減りにくくなる」「残量が戻る」といった見え方が似ていても、理由は異なります。自分がこの不具合の対象かどうかは、個別の案内で確認する必要があります。今回のキャッシュ改善だけで、不自然な消費の原因まですべて解決したと判断することはできません。

---

これまでの改善を振り返ると、仕事を続けるための変化が見える

ここまでの連載では、モデルの速さだけでなく、人が指示を出し、作業を確かめ、また続きへ戻るまでの変化を追ってきました。公開済みの10記事を、当時取り上げた内容で振り返ります。

各行は過去記事で扱った発表の要約です。当時の数値や対象条件を、すべてのモデル・現行プランへ広げるものではありません。なお、DAY2には改善もあったため、「改善なしのリセット日」にまとめないようにしています。

DAY12から、何が具体的になったのか

DAY12では、共通の文脈を再利用し、キャッシュの保持と振り分けを改善することで、実質的に使える量を増やすと案内されました。その時点では、具体的な保持時間や、プランごとの改善幅は示されていませんでした。

DAY16は、その話題の続きとして、時間を空けて戻る場合の扱いが具体的になった発表です。ログイン利用のCodex／Workへの説明と、APIの12時間という選択肢が示されました。 4 5

DAY7は「一度に扱う量」、DAY16は「時間を空けた再利用」

DAY7で増えたのは、GPT-6.1 SolをCodex／Workで使う際の標準コンテキスト長でした。今回の保持改善と組み合わせて考えると、長い背景を扱うことと、その背景に時間を空けて戻ることの両方が、長い仕事に関係していると分かります。

さらに、DAY11は混雑による中断、DAY14は指示の修正、DAY16は時間を空けた再開に関わります。これは、連載を振り返った筆者の整理です。OpenAIがこの順番を製品設計の方針として公表した、という意味ではありません。

見た目の大きな新機能だけでなく、作業を止めたあとにどれだけ自然に戻れるか。その積み重ねに、今回の連載を追う面白さがあります。

---

まとめ：自分の作業では、再開後の進み方を見ていく

DAY15は改善なく使用量リセット、DAY16はキャッシュ改善でした。今回、注目したいのは、AIを一気に使い切る場面だけでなく、人が確認や休憩を挟みながら進める仕事に、改善が向けられていることです。

実際の使い方では、次の3点を見ていくと意味をつかみやすくなります。

• 同じ仕事へ戻ったとき、どこまで進められたか。 会話を継続する使い方で、必要な確認と修正を終えられるかを見る。
• モデルや作業条件がそろっているか。 出力の長さ、推論の設定、ツール利用などが変われば、キャッシュ以外でも消費量は変わる。
• APIを使うなら、全体の費用で得になっているか。 書き込みと読取だけでなく、新しい入力や出力を含めて比べる。

Codexの現行料金案内でも、利用量はモデル、文脈、推論、ツール、検索、キャッシュなどに左右されると説明されています。契約内で使う場合は利用状況画面を確認し、APIの割引率をそのまま利用回数へ換算しないことが大切です。 10

長い仕事には、人が考える時間や、別の作業を進める時間も含まれます。そのあとに同じ会話へ戻り、続きを進めやすくする。DAY16は、そうした日常の作業に関わる改善として受け止めたいところです。

---

参考資料・出典

2026年10月21日確認。投稿の日本語訳は、提供された4枚の画像内の原文に基づきます。機能・料金・対象モデルは、以下の公式文書と照合しました。連載の振り返りに使った公開済み10記事は、本文の一覧表から開けます。

1. Tibo：DAY15のリセット続報
2. Tibo：DAY15の初報「We're cooked」
3. OpenAI Developers：COOKEDの告知
4. Tibo：DAY16のキャッシュ改善
5. OpenAI Developers：APIの12時間プロンプトキャッシュ
6. OpenAI API Changelog：2026年10月20日の更新
7. OpenAI API：Prompt caching
8. OpenAI API：Pricing
9. OpenAI API：GPT-6.1 Solのモデル・料金説明
10. ChatGPT Learn：Codexの料金と利用量の説明
11. Tibo：約40,000アカウントの使用量不具合と対応
12. Claude Code：How Claude Code uses prompt caching
13. Claude API：Prompt caching
14. Claude API：Pricing
15. Gemini API：Context caching
16. Gemini Generate Content API：Context caching
17. OpenAI：Prompt Caching in the API（2024年の導入記事） — 基本的な仕組みの説明に参照。現在の料金・保持時間の根拠には使用していません。
18. Merriam-Webster：「cooked」の俗語の意味