こんにちは、美空です。
OpenAIの28日連続改善チャレンジ。
Day 11では、モデル混雑によってCodexの作業が止まってしまう問題への対策が発表されました。
そしてDay 12。
今回はちょっと地味だけど、Codexを普段からガッツリ使っている人にはかなり嬉しそうなアップデートが来ました。
コンテキストの再利用とキャッシュ効率の改善です！
……え？
それって具体的に何が嬉しいの？
と思うかもしれません。
でもこれ、使い方によっては結構大きな改善になる可能性があるんです。
Day 12は「同じ利用枠で、もっと作業できる」がテーマ！
2026年10月16日（米国時間）、OpenAIの28日連続改善チャレンジでDay 12の改善が発表されました。
今回の対象は、
Codex
と
ChatGPT Work
です。
発表された改善は、主に次の3つ。
-
サブエージェント間でコンテキストを再利用
-
コンテキストキャッシュの保持時間を延長
-
リクエストの振り分けを改善してキャッシュヒット率を向上
これらによって、CodexとWorkの実質的な利用効率を改善するという内容です。
つまり、利用上限の数値をそのまま増やすのではなく、処理の無駄を減らして、限られた利用枠をより有効に使えるようにするという方向ですね。
これは個人的にかなり気になります。
そもそもコンテキストキャッシュって何？
まず、今回のアップデートを理解するために、コンテキストキャッシュについて簡単に説明しておきます。
例えばCodexに、
「UnityプロジェクトのPlayerController.csを調査して」
とお願いしたとします。
するとCodexは、ソースコードや関連する情報を読み込み、それらを元に処理を進めます。
そのあと、
「さっきのコードについて、ジャンプ処理も調べて」
と追加でお願いした場合。
前の処理ですでに参照した情報が、次の処理でも必要になることがあります。
こうしたときに、以前処理した共通部分を再利用できれば、毎回すべてを新しく処理する必要がなくなるわけです。
これが、コンテキストキャッシュの基本的な考え方です。
ただし、ファイルの読み込み結果を単純に保存しておく仕組みとは少し違います。
LLMのコンテキストキャッシュは、以前の入力から得られた内部的な計算結果を再利用する仕組みです。
そのため、キャッシュが利用できるかどうかは、入力内容やキャッシュの有効期間、処理が実行される環境などによって変わります。
改善その1：サブエージェント間でコンテキストを再利用
今回の改善で、特に気になったのがここです。
Codexでは、複数のサブエージェントに作業を分担させることができます。
例えば、Unityプロジェクト全体の調査。
ひとつのエージェントですべてを調べるのではなく、
Agent A：Runtime側のC#コードを調査
Agent B：Editor拡張を調査
Agent C：テストコードを調査
という具合に分担するわけです。
それぞれのエージェントは違うファイルを調べますが、プロジェクトの基本的な構成や共通の開発ルールなど、同じ情報が必要になることもあります。
例えば、
-
Unityのバージョン
-
Assembly Definitionの構成
-
コーディング規約
-
プロジェクト全体の設計方針
-
作業時の制約
などですね。
こうした共通情報をサブエージェント間で再利用しやすくするのが、今回の改善のひとつです。
Unity開発ではかなり便利そう！
大規模なUnityプロジェクトでは、調査対象を複数のエージェントに分担させることがあります。
例えば、
「このUnityプロジェクトのアーキテクチャを調査して、改善すべき点を洗い出して」
というタスク。
各エージェントが毎回同じ説明や設計情報を処理していると、そのぶん処理が重複する可能性があります。
共通コンテキストを再利用できれば、こうした重複した処理を減らせることが期待できます。
ただし、すべてのサブエージェントが同一のコンテキストを完全に共有するという意味ではありません。
今回の発表は再利用効率の改善についてのもので、エージェント同士が同じ記憶を持つようになるという話ではない点に注意ですね。
改善その2：キャッシュ保持時間を延長
続いては、コンテキストキャッシュの保持時間の延長です。
これは、名前の通り。
以前の処理結果を、より長い時間再利用できるようにする改善です。
例えば、CodexにUnityプロジェクトを調査させたあと、しばらく別の仕事をしていたとします。
その後、同じスレッドに戻って、
「さっき調査した処理について、今度は修正案を出して」
とお願いした場合。
以前の情報がキャッシュに残っていれば、共通部分を再利用できる可能性があります。
今回、そのキャッシュを保持する時間が延長されたわけです。
ただし、具体的に何分から何分へ延長されたのかについては、確認した発表では数値が示されていません。
また、同じスレッドだから必ずキャッシュが再利用されるとも限りません。
それでも、長時間の作業を何度も中断・再開するような使い方では、メリットが期待できそうです。
改善その3：リクエストの振り分けを最適化
3つ目は、リクエストルーティングの改善です。
ここはちょっと内部的な話になります。
LLMの処理は、OpenAI側の計算基盤で実行されています。
以前の処理結果がキャッシュに残っていても、次のリクエストでそのキャッシュを利用できなければ意味がありません。
そこで重要になるのが、リクエストの振り分けです。
今回OpenAIは、この振り分けを改善することで、キャッシュヒット率を向上させると発表しました。
簡単に言うと、
使えるキャッシュがあるなら、なるべく再利用できるようにする
という改善です。
もちろん、実際のルーティングアルゴリズムやキャッシュの配置について詳細な実装が公開されたわけではありません。
ここでは、発表内容を元に仕組みを概念的に説明しています。
Day 7の500Kコンテキスト拡張とは何が違う？
ここで、少し前のアップデートを思い出してみましょう。
Day 7では、GPT-6.1 Solの標準コンテキスト長が272Kから500Kトークンに拡張されました。
あれもコンテキストに関する改善でしたね。
でも、今回とは目的が違います。
| 比較項目 | Day 7 | Day 12 |
|---|---|---|
| 主な改善 | コンテキスト長の拡張 | キャッシュ・再利用の効率化 |
| 対象 | GPT-6.1 Sol | Codex / ChatGPT Work |
| 目的 | より多くの情報を扱う | 重複処理を減らす |
| 期待できる効果 | 大規模な情報の保持 | 実質的な利用効率の改善 |
| 効果の数値 | 272K → 500K | 具体的な改善率は未公表 |
Day 7は、いわば作業机を大きくしたような改善。
Day 12は、机の上にある資料を何度も準備し直さなくていいようにした改善。
そんなイメージでしょうか。
どちらも大事だけど、改善しているポイントは別というわけです。
利用枠はどれくらい節約できる？
さて、ここが気になるところ。
今回の改善によって、実際にどれくらい利用枠が節約できるのでしょうか。
残念ながら、具体的な削減率は発表されていません。
例えば、
「20％節約できる」
「同じ利用枠で2倍の作業ができる」
といった数字が示されたわけではありません。
キャッシュがどれくらい利用されるかは、タスクの内容や、以前の入力とどれだけ共通部分があるかによっても変わります。
そのため、実際にどれくらいメリットがあるのかは、今後の利用状況を見ていく必要があります。
とはいえ、普段からCodexを長時間使っている人には嬉しい改善になりそうです。
Unity開発ならこんな場面で期待できる
今回の改善が役立ちそうな場面を考えてみました。
1. 大規模プロジェクトのリファクタリング
複数のAssemblyにまたがるリファクタリングでは、各エージェントがプロジェクト共通の設計情報を参照することがあります。
サブエージェント間で共通コンテキストを効率的に再利用できれば、重複した処理を減らせる可能性があります。
2. 大量のログ解析
Unity Editor.logやPlayer.logを解析し、問題のある処理を特定するようなタスク。
同じログの抜粋や調査条件を複数回参照する場合には、キャッシュによる処理効率の改善が期待できます。
ただし、ログの内容が頻繁に変わる場合は、再利用できる部分が少なくなる可能性があります。
3. 長時間のエージェント作業
Codexに調査と修正を任せて、途中で何度か指示を追加するような使い方です。
以前の入力と共通する部分がキャッシュとして利用できれば、処理効率の改善につながる可能性があります。
4. 複数サブエージェントによる並列調査
例えばRuntime、Editor、Testsなどの領域を分担して調査する場合。
各エージェントが共通するプロジェクト情報を利用することで、処理の重複を減らせることが期待できます。
このあたりは、今回の発表内容と特に相性が良さそうです。
ただしキャッシュは万能ではない
今回の改善には期待していますが、注意点もあります。
まず、キャッシュの再利用は必ず発生するものではありません。
入力内容が異なれば、キャッシュを再利用できない場合もあります。
また、キャッシュが利用できたからといって、モデルの回答が必ず正しくなるわけではありません。
プロジェクトの調査やコード修正の精度は、引き続きCodexの能力や指示内容などに左右されます。
さらに、今回の改善はOpenAI側の処理効率に関するもので、Unity Editor自体のコンパイル時間やビルド時間を直接短縮する機能ではありません。
ここは混同しないようにしたいところですね。
GPT-6 Astra Proにも改善が！
Day 12では、もうひとつ別のアップデートも報告されています。
ChatGPTの上位モデルであるGPT-6 Astra Proの改善です。
発表では、応答速度やツール利用の改善に加えて、複数のサブエージェントを利用した並列作業への対応などが紹介されています。
ChatGPTの高度な調査や複数ステップの仕事を進める際に、より効率的に作業できるようになることが期待されています。
ただし、こちらはChatGPT側のGPT-6 Astra Proに関する改善であり、Codexで利用するモデルが同じ内容に更新されたことを意味するわけではありません。
今回の記事では、Codex / Workのキャッシュ効率改善とは分けて考えたいと思います。
Day 1〜Day 12を振り返ってみる
ここまでのアップデートを振り返ると、OpenAIが何を重視しているのか少し見えてくる気がします。
最初はモデルの高速化や新機能の追加が中心でした。
その後は、利用枠のリセット、コンテキスト長の拡張、保存データの軽量化、モデル混雑エラーへの対策。
そして今回のDay 12では、キャッシュ効率の改善です。
つまり、
ただモデルを賢くするだけではなく、使い続けやすくする改善が進んでいる。
ということですね。
AIエージェントにまとまった仕事を任せるようになるほど、こうした効率改善は重要になってくると思います。
まとめ：目立たないけど、かなり実用的な改善！
Day 12の改善は、新しいモデルの登場や最大8倍高速化といったニュースと比べると、ちょっと地味かもしれません。
でも、Codexを毎日使っている開発者にとっては、こういう改善こそ嬉しかったりします。
サブエージェント間でコンテキストを再利用する。
キャッシュを長く保持する。
キャッシュを使いやすいようにリクエストを振り分ける。
これらによって、同じ利用枠でもより効率的に作業できる可能性があるわけです。
特にUnityのような大規模プロジェクトでは、共通する情報を何度も参照する場面があるので、期待したいところですね。
Day 7では、扱える情報量が増えました。
そしてDay 12では、その情報をより効率的に利用する方向へ進んでいます。
大きなコンテキストを、できるだけ無駄なく使う。
今回のアップデートは、そんな改善だったと思います。
さて、28日チャレンジもDay 12まで終了。
残り16日！
この先も、どんな改善が出てくるのか追いかけていきたいと思います！
参考情報
Claude Code、ちょっと試してみたい！という人へ✨
1週間無料で試せる紹介リンクを置いておきます。私も使っているので、AIコーディングが気になっている人はぜひ試してみてください！
claude.ai※このリンクはClaudeの紹介プログラムを利用しています。条件を満たすと紹介特典が発生します。
