Codexが長時間のコーディング作業でも比較的文脈を保ちやすい理由は、会話履歴を単純に削るのではなく、作業を再開するための「状態」へ変換しているからです。
本記事では、Qiitaの「Codexのコンテキスト圧縮はなぜ優秀なのか」をもとに、OpenAIが公開しているCodexのソースコードも確認しながら、コンテキスト圧縮の仕組みと、LLMエージェント開発に応用できる設計原則をわかりやすく整理します。実装は更新され続けるため、具体的なファイル名や定数は2026年6月15日時点の情報です。
なぜコンテキスト圧縮が必要なのか
LLMが一度に扱えるコンテキストには上限があります。一般的なチャットでは会話文が中心ですが、コーディングエージェントはファイル内容、検索結果、コマンド出力、テストログなども履歴に追加します。
そのため、ユーザーとの会話が短くても、裏側では大量のトークンが消費されます。履歴が長くなるほど、次のような問題が起こります。
- コンテキスト上限へ到達する
- 毎ターン再送する入力が増え、コストと待ち時間が大きくなる
- 重要な情報が長い履歴の中に埋もれる
- 古い情報や巨大なツール出力がノイズになる
単純に古い履歴から削る方法もありますが、タスクの目的、ユーザーの制約、初期の設計判断は会話の前半に置かれることが多く、最も重要な情報から失われる危険があります。
Codexが残すのは「会話」ではなく「作業状態」
Codexのコンパクションが重視するのは、過去のやり取りを逐語的に保存することではありません。次のモデルが作業を続行できる状態を残すことです。
- 何を達成しようとしているか
- どこまで完了したか
- どのような判断をしたか
- 守るべき制約やユーザーの希望
- 残っている作業と次の手順
- 続行に必要なデータや参照先
数万トークンのログを抱え続ける代わりに、作業のチェックポイントを作り、次のモデルへ引き継ぐイメージです。
ローカルとリモートの2つの圧縮経路
Codexには、大きく分けて2種類のコンパクション経路があります。
| 経路 | 概要 | 役割 |
|---|---|---|
| ローカルコンパクション | 通常のモデル呼び出しで履歴を要約する | 専用機能を利用できない環境でも動作するフォールバック |
| リモートコンパクション | 専用のサーバー側処理で履歴を圧縮する | より高度な圧縮処理や将来的な改善をサーバー側で提供できる |
高機能なリモート経路だけに依存せず、利用できない場合でもローカル経路へ退避できる点が重要です。エージェントの中核機能を止めない、堅実なフォールバック設計になっています。
圧縮を「いつ・なぜ・どこで」実行したか記録する
Codexはコンパクションを単なる1種類の処理として扱いません。実装では、主に次の3軸で分類しています。
- Trigger：手動で実行されたか、自動で実行されたか
- Reason：ユーザー要求、コンテキスト上限、モデル変更など、なぜ必要になったか
- Phase：独立したターン、ターン開始前、ターン処理中のどこで発生したか
この分類により、「圧縮が発生した」という結果だけでなく、発生条件と効果を後から分析できます。
ターンの途中でも圧縮できる
一般的な実装では、次のユーザー入力を受け取る前にコンテキスト量を確認します。しかしコーディングエージェントは、1回の依頼の中でファイルを読み、コマンドを実行し、結果を調べながら何度もモデルを呼び出します。
つまり、ユーザーとのターン境界では余裕があっても、タスク実行中にコンテキストが上限へ達する可能性があります。Codexはターン開始前だけでなく、ターンの途中でも自動圧縮できるよう設計されています。
また、大きなコンテキストを持つモデルから小さなモデルへ切り替える場合には、切り替え後に履歴が収まらなくなる可能性を考慮し、旧モデル側の設定を使って事前に圧縮します。
圧縮後の履歴は3層で再構成される
ローカルコンパクションでは、圧縮後の履歴をおおむね次の構造で組み立て直します。
- 初期コンテキスト：システム設定、開発環境、リポジトリ情報など
- 直近のユーザーメッセージ：トークン予算内で原文を優先的に保持
- 作業の要約：進捗、判断、制約、残タスクをまとめた引き継ぎ情報
要約だけに任せると、直前の細かな指示や表現が丸められる可能性があります。そこで、全体像は要約で小さくしながら、直近のユーザー指示は原文に近い形で残します。
現在の公開コードでは、ローカル経路のユーザーメッセージ保持上限は20,000トークン、リモートV2経路では64,000トークンの予算が設定されています。ただし、この値は将来変更される可能性があります。
要約は「次のモデルへの引き継ぎメモ」
コンパクション用の指示は、単なる短縮要約を作らせるものではありません。別のLLMが作業を再開することを前提に、進捗、重要な判断、制約、残作業、必要な参照情報を整理させます。
さらに、要約はアシスタントの過去発言ではなく、次のモデルが受け取る入力として扱われます。これにより、要約を「自分が以前回答した内容」ではなく、「前任のモデルから受け取った申し送り」として解釈できます。
ターン途中で圧縮する場合は、初期コンテキストや最後のユーザー指示、要約を置く順番も調整されます。これは単なる文字列の要約ではなく、モデルが理解しやすい履歴構造まで含めた設計です。
巨大なツール履歴は捨て、必要なら再取得する
長時間セッションで特に大きくなるのは、ファイル内容やコマンド出力などのツール応答です。これらをすべて保持し続けると、履歴の大部分が過去の生ログになります。
Codexは、必要な結論や重要な値を要約へ残し、生のツール履歴は積極的に削減します。ファイルやコマンドの状態は会話履歴とは別に存在するため、必要になれば再度読み取りや実行が可能です。
この履歴と外部状態の分離が、「大量のログを捨てても作業そのものは続けられる」仕組みを支えています。
なぜ圧縮後も比較的破綻しにくいのか
- ターン前だけでなく、処理途中のコンテキスト超過にも対応する
- タスクの目的と進捗を、再開可能な状態として残す
- 要約と直近メッセージの原文保持を組み合わせる
- モデルとクライアントが要約の位置や意味を共有している
- ローカルとリモートの二経路で可用性を確保する
- 圧縮の理由、タイミング、前後のトークン量を計測する
なお、圧縮は完全に無損失ではありません。現在のCodexのソースコードでも、長いスレッドや複数回のコンパクションは精度低下につながる可能性があるため、可能なら小さく目的を絞った新しいスレッドを始めるよう警告する実装が確認できます。
LLMエージェント開発へ応用できる3つの原則
1. 会話ログと実行状態を分ける
ファイル、データベース、ツールの実行状態まで会話履歴だけで管理しないことが重要です。外部状態を再取得できれば、古いログを大胆に削れます。
2. 要約だけに依存しない
全体像は要約しつつ、直近の指示や重要な識別子は原文で残します。抽象化された状態と具体的な情報を組み合わせることで、引き継ぎ時のズレを減らせます。
3. 圧縮処理を観測可能にする
圧縮前後のトークン量、発動理由、所要時間、失敗率を記録しなければ、効果を改善できません。コンパクションを裏側の処理として隠すのではなく、計測対象として設計する必要があります。
まとめ
Codexのコンテキスト圧縮が優れている理由は、要約モデルが単に高性能だからではありません。履歴から作業状態を抽出し、直近の指示と組み合わせ、適切な位置へ再配置し、その効果を計測するという複数の仕組みが連携しているためです。
コンテキストウィンドウを大きくするだけでは、長時間動くエージェントの問題は解決しません。必要な情報を見極め、再開可能なチェックポイントへ変換する設計こそが、長期タスクを安定させる鍵になります。
コメント