同じ「compact」でも中身は別物──Claude CodeとCodexのコンテキスト圧縮を公開ソースで比較する¶

対象 / ポイント

対象: Claude CodeやCodex CLIを数時間単位のセッションで使い、「compact後に何が失われるのか」を実装レベルで把握したいエンジニア。

ポイント:

Claude Codeはツール結果の退避、部分消去、全量要約を組み合わせる
Codexは直近ユーザー発話と要約を軸に、履歴を作り替える
圧縮で守る対象が違うため、失われやすい情報の置き場所も違う

長いリファクタリングセッションの途中で「Context compacted」と表示される。その直後、エージェントが少し前に合意した方針を忘れる。 Claude CodeでもCodex CLIでも起きる現象だが、何が消えたのかは同じではない。

この記事の問いは、Claude CodeとCodexのcompactは、圧縮後の履歴に何を残し、何を捨てるのかである。 Codex側はOSSのcompact.rsと設定定義で直接確認できる¹²。 Claude Code側は公式ドキュメントに加え、2026年3月末にnpmパッケージへ誤って同梱されたTypeScriptソースを読んだ複数の公開解析を参照する⁶⁷⁸。つまり、Codexは一次ソース中心、Claude Codeの内部定数は公開解析中心という非対称な根拠で読む必要がある。

Claude Codeは「捨てる」前に温存策を挟む¶

Claude Codeの特徴は、いきなり会話全体を要約しない点にある。公開解析によれば、文脈が膨らむと、まず大きなツール出力をディスクへ逃がし、次に古いツール結果を部分的に消し、それでも足りない場合に全量要約へ進む⁶⁷。

最初の一手は、要約ではなく参照化だ。巨大なコマンド出力や検索結果をそのまま会話へ積む代わりに、本体をファイルへ保存する。文脈には短いプレビューとファイルパスを残し、必要になればReadツールで原文を取り直す。

公開解析では、各ツールにmaxResultSizeCharsという上限があり、既定値は5万文字と説明されている⁶。しきい値を超えた出力は、約2KBのプレビューと保存先パスへ置き換わる。ただしReadツールは例外で、Readの出力をファイル化して再びReadで読む循環を避けるため、退避対象から外されている⁶。

この段階では、情報はまだ失われない。原文は会話の外へ移動しただけで、ファイルとして残る。圧縮というより、実体と参照の分離に近い。

古いツール結果は部分的に消される¶

退避だけで足りなくなると、Claude Codeは古いtool_resultの本文を消す。ここで重要なのは、消す対象が会話全体ではなく、主に古いツール結果だという点である。

公開解析は、この段階をmicrocompactionとして説明している⁷。キャッシュが温かい場合はcache_edits系の仕組みで、キャッシュ済みプレフィックスをなるべく壊さずに古い結果を落とす。キャッシュが冷えた場合は、維持する価値が薄いためインラインで直接消す。

AnthropicのClaude Platformにも、同じ問題意識の公式機能がある。 Context editingは、ツール利用が重いエージェントワークフロー向けにtool result clearingを提供し、古いツール結果を消して文脈を管理する¹²。 Claude Code内部の実装と完全に同一とは断定できないが、プラットフォーム側でも「古いツール結果を消す」という設計が標準化されていることは確認できる。

この段階では、情報が落ちることがある。第1段でディスク退避された大型出力なら追跡できるが、退避されなかった小さな結果は本文が消えれば会話内には残らない。 Claude Codeの強みは「何も失わない」ことではなく、全量要約へ進む前に、失う範囲をツール結果側へ寄せることにある。

全量要約は最後の手段になる¶

Claude Codeでも、最後は会話全体の要約に進む。公開解析では、200Kコンテキストのモデルなら、おおむね全体の8割台でauto-compactが発動すると説明されている⁸。この数字は内部実装に依存するため、固定仕様ではなく、2026年春時点の解析値として扱うべきだ。

全量要約では、別の要約用プロセスが親セッションの情報を読み、作業内容を構造化してまとめる。その後、直近ファイル、計画、スキルなどを戻すリハイドレーションが走ると公開解析は述べている⁷⁸。要約だけを渡して終わりではなく、作業再開に必要な材料を再注入する設計である。

公式ドキュメントも、compactが万能ではないことを示している。 Claude Codeのベストプラクティスは、auto compaction時にコードパターン、ファイル状態、重要な決定が要約されると説明している。より制御したい場合は/compact <instructions>を使うよう案内している⁹。さらにメモリの公式ドキュメントは、プロジェクトルートのCLAUDE.mdは/compact後に再読込される一方、会話だけで伝えた指示は失われうると説明する¹⁰。

/compact 認可まわりの設計判断、対象ファイルパス、未完了タスクを必ず残す

つまり、Claude Codeでは「残してほしいもの」を会話中に言うだけでは弱い。長期に守るべき制約はCLAUDE.mdや設計メモへ書き、節目では手動/compactで要約方針を明示するほうが安定する。

Codexは履歴を「ユーザー発話+要約」へ作り替える¶

Codexのcompactは、Claude Codeより直線的だ。しきい値に到達すると、会話全体から要約を作り、旧履歴を破棄し、直近ユーザー発話と要約を中心に履歴を再構築する¹。

ソースコードには、ユーザー発話を守るための上限が定数として明記されている。

const COMPACT_USER_MESSAGE_MAX_TOKENS: usize = 20_000;

collect_user_messagesはユーザー発話だけを抽出し、build_compacted_historyは新しい発話から順に2万トークン分まで詰める¹。枠を超えた発話は切り詰められ、それより古いものは落ちる。またSUMMARY_PREFIXで過去の要約を識別するため、圧縮要約が何層にも蓄積する構造にはなっていない¹。

裏を返すと、assistant発話やtool_resultの原文は、この再構築後の履歴には残らない。設計判断がAI側の提案やツール結果の読み解きとしてだけ存在していた場合、次のウィンドウへ届くかどうかは要約品質に依存する。 Codexが強く守るのは、AIの中間思考ではなく、ユーザーが明示した意図である。

Codexにはサーバー側compact経路がある¶

Codexの実装を読むときは、ローカル要約だけを見て終わらせると不十分だ。 OpenAIのAPIリファレンスはPOST /responses/compactを公開しており、会話をcompactしたresponse objectとして返すと説明している³。 Codex Prompting Guideも、コンテキストが大きくなったら/compactを呼び、新しい圧縮済み文脈を作れると説明する⁴。

Codex CLIのソース側にも、remote compactionを使うかどうかの分岐と、/responses/compactエンドポイント名が実装されている¹。 Simon Zhou氏の検証は、サーバー側compactが暗号化ブロブを返し、後続リクエストで復号された文脈として使われる可能性を、プロンプト注入実験で推定している⁵。この検証は独立解析なので、記事では「推定」として扱うのが妥当だ。

設定で触れるノブもある。 config/mod.rsには、auto compactの発動しきい値に関わるmodel_auto_compact_token_limitと、ツール出力の文脈保持上限であるtool_output_token_limitが定義されている²。

model_auto_compact_token_limit = 150000
tool_output_token_limit = 16000

ただし、tool_output_token_limitはClaude Codeのディスク退避とは違う。ツール出力を復元可能な参照へ変える仕組みではなく、文脈へ入れる量を制限するノブとして読むべきである。

守る対象が逆を向いている¶

Claude CodeとCodexの差は、圧縮アルゴリズムの細部だけではない。どの情報を「原文で残す価値がある」と見るかが逆を向いている。

Claude Codeは、ツール結果の実体をなるべく会話の外に逃がす。ファイル、計画、スキル、CLAUDE.mdのように、再読込できる材料を重視する。作業の正しさは、会話本文だけでなく、ファイルシステム側の状態にも宿るという前提だ。

Codexは、ユーザー発話を直近2万トークンまで優先して残す。 assistant発話とツール結果は要約へ吸収される。作業の正しさは、まずユーザーの意図にあるという前提で履歴を作り替える。

観点	Claude Code	Codex CLI
圧縮の形	退避、部分消去、全量要約を組み合わせる⁶⁷	要約と直近ユーザー発話を軸に履歴を再構築する¹
最初に守る対象	大型ツール結果の実体	ユーザー発話の原文
原文で残りにくいもの	古い小型ツール結果、会話だけの暗黙指示	assistant発話、tool result、古いユーザー発話
キャッシュ配慮	公開解析では`cache_edits`経路が説明される⁷	全置換に近く、過去プレフィックスは維持しにくい
要約の可視性	クライアント側で誘導しやすい⁹	サーバー経路では暗号化ブロブを含む³⁵
実務上の対策	`CLAUDE.md`、設計メモ、手動`/compact`	設計判断のファイル化、しきい値調整

この表から見えるのは、どちらが「安全」かではない。危険な置き場所が違うということだ。

Claude Codeでは、会話だけで伝えた制約や、全量要約前の暗黙合意が落ちやすい。 Codexでは、assistantが提案して採用された設計判断や、ツール結果から得た根拠が、原文としては残りにくい。長時間セッションでは、どちらのツールでも重要判断をファイルへ落とす必要がある。

「Claude Codeの方が記憶が持つ」とは断定できない¶

長時間セッションの体感だけで、Claude Codeのほうが記憶が強い、Codexのほうが忘れやすい、と言い切るのは危うい。両者を同一タスク、同一予算、同一モデル品質で比較した公開ベンチマークは確認できない。

設計から言えるのは、得意な保存対象が違うことまでだ。ユーザーが明文化した要求は、Codexのほうが構造的に残りやすい。直近2万トークン分のユーザー発話を守る設計だからである¹。

一方、ツール呼び出しが密で、AI側の提案や中間判断が会話に多く積み上がるセッションでは、Claude Codeの段階的な圧縮が有利に見える可能性がある。ただしClaude Codeも、最終的な全量要約では同種の損失を免れない。「記憶が持つ」ではなく、「何をどこに置けば残りやすいか」と考えるほうが実務的だ。

実務上の共通解は単純である。

守りたい決定は会話ではなく、AGENTS.md、CLAUDE.md、設計メモへ書く
圧縮直後に、方針、対象ファイル、未完了タスクをエージェントに復唱させる
長い出力はログや分析ファイルとして保存し、会話の中だけに置かない
自動発動を待たず、タスクの節目で手動compactを使う

OpenAIとAnthropicのAPI側でも、compactionは独立した機能になりつつある。 OpenAIは/responses/compactを提供し³、Anthropicはbetaのサーバー側compactionを公開している¹¹。さらにOpenAIのCodex Prompting Guideは、近年のCodexモデル改善としてfirst-class compaction supportを挙げ、長時間推論と長い会話を支える機能だと説明している⁴。

つまり、compactはCLIハーネスだけの小技ではなくなっている。実装の主戦場は、クライアント側の履歴加工から、APIとモデル側の文脈管理へ移っている。だからこそ、ハーネス内部の定数を丸暗記するより、公式ドキュメントで保証される保存範囲と、自分のプロジェクトでファイル化すべき判断を分けておくほうが長持ちする。

まとめ¶

Claude Codeのcompactは、ツール結果の退避、古い結果の部分消去、全量要約を組み合わせる。要約は最後の手段に近く、ファイルやCLAUDE.mdの再読込で作業の連続性を保とうとする。

Codexのcompactは、直近ユーザー発話と要約を中心に履歴を作り替える。ユーザーの意図を原文で守る一方、assistant発話やtool resultの原文は残りにくい。

この違いから導ける運用方針は明確だ。 Claude CodeではCLAUDE.mdと手動/compact指示が効きやすい。 Codexでは、設計判断をユーザー発話かファイルへ明文化することが効きやすい。どちらでも、長時間タスクの記憶は会話欄に任せきらない。