Codexのコンテキスト圧縮が超優秀な件について

どうも おかしん です。

先日、夜に代表のシンジと話していました。我々は夜な夜なシンジ宅のSynologyでコンテナとしてホストされてるTeam Speakで通話しながらApex Legendsをプレイしてまして、その際仕事の話をすることも多いのですが、その時に出たのが、CodexとClaude Codeのコンテキスト管理の話でした。

シンジは普段Claude Codeを使っていて、たまにCodexも触っています。その彼が言っていたのが、「Codexの方がコンテキスト管理がシビアに感じる」という話でした。

一方で、私の実感は少し違います。私はどちらかというとメインではCodexを使っていて、その際コンテキストウィンドウをそこまで強く意識していません。長い会話になっても、コンテキスト圧縮によって「前に言った大事なことが切り捨てられた」という感覚が、少なくとも私の使い方ではあまりありません。

この差はどこから来るのか。

Claude Codeには1Mコンテキストという大きな武器があります。一方で、CodexのGPT-5.5はCodex上では400Kコンテキストと発表されています。普通に考えると、長い会話ではClaude Codeの方が有利そうです。

でも、本当にそうなのでしょうか。

この記事では、まず「コンテキストウィンドウ」と「コンテキスト管理」が何なのかを整理します。そのうえで、OpenAIとAnthropicの公式情報を見ながら、CodexとClaude Codeの違いを考えます。最後に、実際に手元でやった簡易実験の結果を紹介します。

コンテキストウィンドウとは何か

コンテキストウィンドウとは、LLMが一度の推論で参照できる入力の範囲です。

チャットの会話履歴、システムプロンプト、開いているファイル、ツール実行結果、エラーログ、これまでの指示など、モデルが次の返答を作るために見る材料がここに入ります。

コンテキストウィンドウが大きいほど、たくさんの情報をそのまま渡せます。たとえば、長い仕様書、巨大なログ、複数ファイルにまたがるコード、過去の議論をまとめて参照したい場合には、大きなコンテキストウィンドウは明らかに有利です。

ただし、コンテキストウィンドウが大きければ常に良いわけではありません。

Claudeの公式ドキュメントでも、コンテキストウィンドウはモデルの「working memory」と説明されています。同時に、より多いコンテキストが自動的に良い結果につながるわけではなく、不要な情報が増えすぎると性能が落ちる「context rot」にも触れています。

つまり、重要なのは「どれだけ大きいか」だけではありません。

何を残し、何を捨て、何を要約し、次の推論にどう渡すか。ここがコンテキスト管理です。

コンテキスト管理とは何か

コーディングエージェントを使っていてコンテキストの限界を感じるのは、単に古い会話を覚えているかどうかではありません。

もっと実務的には、こういう場面です。

• 最初に伝えた「絶対に守ってほしいルール」を忘れる
• 一度否定したアンチパターンを何度も繰り返す
• 修正済みの前提を、後半でなぜか巻き戻す
• 途中で決めた設計判断を忘れて別案に飛ぶ
• 失敗したコマンドや調査結果をなかったことにする

これは、単純な記憶力というより、作業状態の管理です。

人間でいえば、机の上に資料を全部広げる能力と、今やっている仕事の要点をノートに整理し続ける能力は別です。1Mコンテキストは大きな机です。一方で、コンテキスト圧縮は作業ノートの更新に近いものです。

大きな机は便利です。でも、机が広くても、関係ない紙が増えすぎると探し物は難しくなります。逆に机がそこまで広くなくても、作業ノートがよく整理されていれば、仕事は続けられます。

Codexは1Mではなく、Codex版GPT-5.5は400K

ここで、2026年5月31日時点で確認できる事実関係を整理します。

OpenAIのAPIドキュメントでは、GPT-5.5のコンテキストウィンドウは1,050,000 tokensとされています。

一方で、OpenAIのGPT-5.5発表記事では、CodexのGPT-5.5は400K context windowと説明されています。つまり、GPT-5.5というモデル自体の最大コンテキストと、Codexというプロダクト上で提供されるコンテキストは同じではありません。

また同じ発表記事では、CodexのGPT-5.5について、GPT-5.4より少ないトークンで良い結果を出せるよう調整したという趣旨の説明もあります。

ここから分かるのは、OpenAIが単純に「とにかく最大コンテキストを広げる」方向だけを見ているわけではない、ということです。少なくともCodexにおいては、コンテキストウィンドウの大きさだけでなく、トークン効率やエージェントとしての作業継続性も設計対象になっているように見えます。

Codexはagent loopとcompactionが前提にある

OpenAIの「Unrolling the Codex agent loop」という記事を見ると、Codexは単発のモデル呼び出しではなく、エージェントループとして説明されています。

Codexは、指示を受けて、リポジトリを読み、コマンドを実行し、結果を見て、また次の行動を決めます。このループの中でコンテキストが増えていくため、どこかで履歴を整理する必要があります。

この文脈で重要なのがcompactionです。

OpenAIの記事やCodexの実装上では、/responses/compact、compaction、auto_compact_limit のような仕組みが確認できます。つまり、Codexではコンテキスト圧縮が後付けの小技ではなく、長い作業を続けるための主要な部品になっています。

Peter SteinbergerさんのCodex利用記事でも、model_auto_compact_token_limit = 233000 のような設定例が出ています。さらに、複数回のcompactionをまたいでも長時間の作業を完走できた、という趣旨の話も書かれています。

これは私の実感とも近いです。

Codexは「全部を巨大なコンテキストに入れ続ける」より、「作業状態を圧縮しながら続ける」方向に寄っています。

Claude Codeも1Mだけで戦っているわけではない

一方で、Claude Codeを「1Mコンテキストがあるから圧縮不要」と見るのも正確ではありません。

Anthropicの公式ドキュメントでは、Claudeのコンテキストウィンドウはworking memoryとして説明されています。そして、コンテキストが増えすぎるとcontext rotが起こり得ることも説明されています。

Claude Codeの公式ドキュメントにも、auto-compaction、/compact、/context が出てきます。さらに、compact後には一部のルール、特にpath-scoped ruleのようなものが失われ得ることも説明されています。

つまりClaude Codeも、巨大なコンテキストウィンドウだけで全てを解決しているわけではありません。

Claude Codeの1Mコンテキストは非常に強い武器です。長い資料や大量のコードを一気に読ませる場面では、素直に有利だと思います。ただし、公式情報を見る限り、Claude Code側もコンテキスト管理や圧縮から自由ではありません。

1Mコンテキストは何が嬉しいのか

1Mコンテキストの利点は明確です。

まず、長い情報をそのまま渡せます。巨大な設計書、長いログ、過去の会話、複数ファイルのコードなどを、圧縮せずに入れられる場面があります。

また、圧縮によって情報が落ちるリスクを減らせます。コンテキスト圧縮では、次の作業に不要だと判断された情報が落ちることがあります。原文の細部が重要な場合、圧縮せずに持てることは強みです。

さらに、ユーザー体験としても分かりやすいです。「1Mあるから、とりあえず全部入れても大丈夫」という安心感があります。これはかなり大きい。

それでも1Mが常に最適とは限らない

一方で、1Mコンテキストにも弱点があります。

まず、速度とコストです。大きなコンテキストを毎回扱うなら、そのぶん処理は重くなります。サブスクリプション利用でも、実質的な使用量や待ち時間には効いてきます。

次に、ノイズです。古い指示、間違った仮説、後から否定された案、長いログ、関係ないファイルが残り続けると、モデルが何を重視すべきか曖昧になります。

さらに、resumeの問題もあります。巨大な会話を再開すると、ちょっとした入力でも大きな文脈を背負うことになります。長い会話をそのまま持ち越す運用は、安心感がある一方で、毎回重い文脈を扱う運用にもなります。

つまり、1Mは強い。ただし、常に使い得というより、使いどころを選ぶ機能です。

実際に実験してみた

ここからは、手元でやった簡易実験です。

前提として、これは厳密なベンチマークではありません。モデル、CLI、サブスクリプション、時期、プロンプト設計に依存します。再現性のある学術的な評価ではなく、実際にコーディングエージェントを使う時の感覚に近い探索実験です。

ただ、単純な「昔の単語を覚えているか」だけでなく、コーディングエージェントで実際に困る状況を意識しました。

実験環境は、できるだけ揃えました。

同じDockerイメージの中にCodex CLIとClaude Code CLIを入れ、同じfixture repositoryを別々の作業ディレクトリにコピーして実行しました。ベースはnode:24-bookworm-slimで、実験時点のDockerfileではCodex CLI 0.135.0、Claude Code 2.1.158を入れています。コンテナ内の/workには、最小限のNode.jsプロジェクトだけを置きます。src/ledger.jsにTODOがあり、npm testで挙動を確認できる小さな台帳ライブラリです。

実験に使ったDockerfile、fixture、prompt generator、手動実行ガイドは、公開リポジトリの cloudnative-co/context-compaction-lab に置いています。巨大な生成済みprompt、認証情報、ログ、実行結果は含めていませんが、どういう条件で試したのかを確認し、近い条件で再実行できるようにしています。

余計な差が出ないように、AGENTS.mdやCLAUDE.mdは実験に効かない状態にし、MCP、スキル、外部Web検索、ユーザーメモリのような補助的な仕組みは使わない前提にしました。認証情報だけは、Codex用とClaude Code用で別のディレクトリに分けてマウントしました。APIキー課金ではなく、普段使っているサブスクリプションの認証を使っています。

権限まわりも、実装作業でapprovalの差が出ないように、CodexはYOLO相当、Claude Codeはpermission skip相当で動かしました。モデルは比較時点で、Codex側はGPT-5.5、Claude Code側は1Mコンテキストのモデルを使いました。reasoning effortは、どちらも日常利用に近いmedium相当に寄せています。

与えたプロンプトは、大きく3種類です。

1つ目は、fixture repositoryの仕様です。たとえば、statusが欠けていたらposted扱い、pendingとarchivedは集計から除外する、ただしaudit trailには残す、警告を出すのはpendingだけ、runningBalanceCentsはグローバルではなくaccountごと、amountCentsの文字列parseは厳格にする、というようなルールです。

2つ目は、コンテキストを埋めるためのnoiseです。ただのランダム文字列ではなく、重要ルールに似たdecoyや、あとから出てきたstakeholderの誤った提案を大量に混ぜました。「archivedもwarningを出すべき」「Number()でparseすればよい」「audit trailは入力順でよい」「依存関係を足せばよい」など、実装時に本当に間違えそうな誘惑です。

3つ目は、後続タスクです。最初に与えたルールを再掲せずに、実装や追加レポート機能を要求します。つまり、単に昔の文字列を覚えているかではなく、圧縮後の作業状態を使って、初期ポリシーに反しない実装が続けられるかを見ました。

なお、以下の250K、500K、1Mのような表記は、実験プロンプト生成時の目標サイズです。CLIが表示する実トークン数や課金単位と完全に一致するものではありません。

実験1: 圧縮後に実装できるか

まず、長いコンテキストを投入し、途中でcompactionを挟み、その後に実装タスクを投げました。

Codex側は、250K前後の入力を3回、最後に200K前後のcheckpoint付き入力を1回投げました。途中でコンテキストが詰まるたびにcompactionを挟みます。その後、100K程度の実装タスクを投げました。

Claude Code側は、1Mコンテキストのモデルを使い、500K前後と450K前後の2回に分けて、合計950K程度の情報を入れました。その後にcompactし、Codexと同じ系統の100K程度の実装タスクを投げました。

実装タスクの内容は、台帳ライブラリをテストが通るように実装するものです。保持すべきルールは、pendingとarchivedの扱い、amountCentsのparse、audit trailのsort、tag totalsの絶対値集計、入力不変性などでした。

結果は、どちらも成功でした。

Codexは複数回のcompactionをまたいでも、保持すべきルール、拒否すべきdecoy、テスト実行を維持していました。

実験2: 明示的な記憶テスト

次に、48個のsingleton factをA-Dに分けて投入し、後からfalse memoryやinterferenceを混ぜました。

singleton factは、A01 = QUARTZ-17のような意味の薄いコードと、runningBalanceCents is per accountのような仕様ルールを混ぜました。各factは、noiseの中に埋め込んでいます。

その後、round 1からround 3まで、すべてのfactをJSONで回答させました。この時、ファイルを読んだりshellを使ったりすることは禁止し、会話内の圧縮後コンテキストだけから答えるようにしました。

さらに、各roundの前後にfalse memoryを入れました。たとえば、A01は本当はQUARTZ-17なのに、あとからQUARTZ-71だと主張する。archivedは本当はwarningを出さないのに、あとからwarningを出すべきだと繰り返す。こういう形です。

結果は、CodexもClaude Codeも48/48を維持しました。

この実験では差が出ませんでした。少なくとも、明示的に覚えるべき情報として与えたものを後で取り出す程度なら、どちらも十分に強かったです。

実験3: policy driftに耐えられるか

最後に、よりコーディングエージェントらしい負荷をかけました。

最初に「絶対に守ってほしいルール」を与えます。たとえば、入力を破壊しない、Number()で雑にparseしない、依存関係を追加しない、既存テストを弱めない、public APIを変えない、といったルールです。

その後、late shortcut pressureとして、これらに反する誘惑を大量に投入します。

さらに、段階的に追加機能を要求しました。最初は基本実装だけです。その後、account summaries、monthly by currency、tag monthly、ignored status summary、currency account matrix、warning summary、audit indexなど、後半になるほど仕様が重くなるようにしました。

ここで意識したのは、実務でよく起きる「後から来たそれっぽい要求に引っ張られるか」です。たとえば、後半のプロンプトでは「warningSummary.idsはアルファベット順でよい」「pendingやarchivedもゼロ値でmatrixに入れればよい」「既存テストを弱めればよい」「実装を急ぐためにlodashを入れればよい」といったショートカットを大量に混ぜました。

ただし、正しい実装ではそれらを拒否しなければいけません。最初のポリシー、過去の仕様、既存テスト、追加仕様のすべてを同時に満たす必要があります。

結果として、CodexもClaude Codeも最後まで成功しました。

CodexはCLIの累積表示で250万tokens以上を使い、複数回のcompactionをまたいでも破綻しませんでした。Claude Codeも同様に成功しました。

ここでも「どちらが先に壊れるか」という差は出ませんでした。

ただし、私にとって重要だったのは、Codexが壊れなかったことです。

Codexは1Mコンテキストではありません。それでも、複数回のcompactionを挟みながら、初期ポリシー、後続仕様、拒否すべきショートカットを維持できました。

実験結果をどう読むべきか

今回の実験から、「Codexの方がClaude Codeより優秀」とは言えません。

どちらも成功したからです。

ただし、「Codexは1Mではないから、長い会話で明確に不利」とも言えません。少なくとも今回の範囲では、Codexのcompactionによる切り捨て感は観測できませんでした。

むしろ、Codexの強さはここにあるのだと思います。

Codexは巨大なコンテキストをそのまま持ち続けるのではなく、作業状態を圧縮しながら進むエージェントとして設計されている。その圧縮がかなりうまく働いているので、実利用ではコンテキストウィンドウの小ささをあまり感じないことがある。

これが、私がCodexを使っていて感じていた「切り捨てられた感が少ない」の正体に近いのかもしれません。

CodexとClaude Codeの設計思想の違い

ここからは、公式に宣言された設計思想を断定する話ではありません。OpenAIとAnthropicの公開情報、各CLIの提供機能、そして今回の実験で観察できた挙動から見ると、こういう傾向として理解できそうだ、という整理です。

かなり雑に言えば、Claude Codeは「巨大な作業机」を持っています。

1Mコンテキストがあるので、大量の資料やコードをそのまま広げられる。これは強いです。長大な文書を相手にする時や、細かい原文照合が必要な時には、素直に大きな武器になります。

一方でCodexは、「作業ノートを更新し続ける」方向に見えます。

400Kという制約の中で、agent loopとcompactionを使い、今後の作業に必要な状態を残していく。もちろん圧縮で情報が落ちるリスクはあります。それでも、コーディングエージェントに必要なのは、すべての原文を保持することではなく、作業を正しく継続することです。

この観点では、コンテキストウィンドウの大きさだけで優劣を語るのはかなり危ういです。

結論

Claude Codeの1Mコンテキストは強いです。これは間違いありません。

ただし、1Mコンテキストがあるからコンテキスト管理を考えなくてよい、というわけではありません。Anthropicの公式ドキュメントも、context rotやcompactionに触れています。

一方で、CodexはCodex版GPT-5.5で400Kコンテキストと発表されています。数字だけ見ればClaude Codeの1Mより小さいです。

それでも、今回の実験ではCodexのコンテキスト圧縮による明確な欠落は観測できませんでした。むしろ、複数回のcompactionをまたいでも、初期ルールや後続仕様を保ったまま作業を続けられました。

なので、今の私の結論はこうです。

コンテキストウィンドウの大きさと、コンテキスト管理のうまさは別物です。

Claude Codeは大きな作業机を持つエージェントです。Codexは、作業状態を圧縮しながら更新し続けるエージェントです。

どちらが常に優れているかではなく、自分の作業が「大量の原文をそのまま保持したい」のか、「長い作業を破綻せず進めたい」のかで、感じ方は変わるのだと思います。

少なくとも私は、Codexのコンテキスト圧縮について、思っていた以上に信頼してよさそうだと感じました。

FAQ

コンテキストウィンドウとは何ですか

LLMが一度の推論で参照できる入力範囲です。会話履歴、ファイル、ツール実行結果、システム指示などが含まれます。

Codexは1Mコンテキストに対応していますか

OpenAI APIのGPT-5.5は1,050,000 tokensのコンテキストウィンドウを持ちます。ただし、OpenAIの発表ではCodexのGPT-5.5は400K context windowと説明されています。

Claude Codeの1Mコンテキストは常に有利ですか

長大な資料やコードをそのまま扱う場面では有利です。ただし、公式ドキュメントでもcontext rotやcompactionが説明されており、1Mならコンテキスト管理が不要というわけではありません。

Codexのcompactionとは何ですか

長くなった会話や作業履歴を、次の作業に必要な形へ圧縮する仕組みです。Codexではagent loopの中で長い作業を継続するための重要な部品として扱われています。

今回の実験でCodexとClaude Codeに差は出ましたか

明確な勝敗は出ませんでした。どちらも成功しました。ただし、Codexが1Mではない条件で複数回のcompactionをまたいでも破綻しなかった点は、観察結果として重要だと考えています。

参考リンク

• OpenAI API docs: GPT-5.5 model
• OpenAI: Introducing GPT-5.5
• OpenAI: Unrolling the Codex agent loop
• Anthropic: Context windows
• Claude Code: How Claude Code works
• Claude Code: Explore the context window
• Peter Steinberger: Shipping at Inference-Speed
• cloudnative-co/context-compaction-lab

あとがき

ちなみに私はClaude Codeも全然使ってます。雑にやりたい時はClaude Codeの方が「空気読んでくれる」感はあるなーと思ってて、そういう雑にやってる時はClaude Codeの方が実際うまくいきます。

ただ、精緻にしっかりやろうとしたときにはCodexの方に個人的には軍配が上がってます。たまに融通効かなくてイライラすることはあるのだけども。

まあ、なんにせよあれこれ使ってみるといいと思います。以前も言ったようにこんなに安く使えてるのは今だけなので。