# CodexのCompactionは「暗号化サマリー」だった――セッション引き継ぎの設計論 > Author: Tony Lee > Published: 2026-03-05 > URL: https://tonylee.im/ja/blog/codex-compaction-encrypted-summary-session-handover/ > Reading time: 1 minutes > Language: ja > Tags: claude-code, codex, context-window, compaction, ai-coding, session-management ## Description Claude CodeのCompactionで起きる文脈喪失の問題と、CodexのAES暗号化サマリーやJSONLセッションログを活用したセッション引き継ぎパターンの詳細解説。 ## Content Claude Codeをある程度使い込んでいると、「Compacting conversation...」という表示に出くわす。それ以降、回答がずれ始め、レスポンスも遅くなる。200Kトークンのコンテキストウィンドウは、思っているよりずっと早く埋まる。 「OpenAIのCodexはこの問題をもっとうまく処理している」という話が流れていたので、公開されている分析を片っ端から掘り下げてみた。 ## 要約しても、忘れることに変わりはない 会話が長くなるにつれてAIが初期の文脈を失うのは、構造的な制約だ。コンテキストウィンドウは200Kトークンが上限で、ひとつの大きなコーディングセッションだけで軽くオーバーする。要約を挟んだとしても、元の会話は消えている――精度の低下は避けられない。 「さっきのあの関数について聞きたいんだけど」をCompaction後に投げると、全然関係ない答えが返ってくる。そういう経験を何十回も繰り返してきた。 - Claude Codeのデフォルト200Kトークンウィンドウは、大規模リファクタリング一回で使い切れる - サマリーが元の会話を置き換える → 詳細な文脈が失われる → 回答品質が落ちる - ツール呼び出しの結果がサマリーで平坦化されるのは、特にダメージが大きい ## CodexのCompactionは「暗号化サマリー」だった KraftonのCAIO、Kangwook Leeがプロンプトインジェクションを2回使ってCodexの内部パイプラインをリバースエンジニアリングしており、その結果が非常に興味深い。 Codexモデルの`compact()` APIが呼ばれると、サーバー上の別のLLMが会話を要約し、その結果をAES暗号化して返す。次のターンでこの暗号化ブロブが復号され、「前の会話のサマリーです」という引き継ぎプロンプトをプレフィックスとしてモデルに渡される。 - オープンソースのCodex CLIが非codexモデルに使うCompactionプロンプトとほぼ同じ内容 - 暗号化している理由は不明――ツール呼び出しの復元データが含まれている可能性がある - Kangwook Leeが公開したスクリプトで35行のPythonで再現可能 - OpenAIの公式APIは`compact_threshold`設定によるサーバーサイド自動Compactionに対応 ## 本質的な差はセッション引き継ぎの設計にある Compaction自体よりも興味深いのは、セッションをまたいだコンテキストの受け渡し方だ。あるデベロッパーの自動化の仕組みが秀逸で、私は「セッション引き継ぎパターン」と呼んでいる。 Compaction直前にwriteツールをブロックし、JSONLのセッションログからユーザーメッセージとthinkingブロックだけを抽出する。これだけで元のデータ量の98%を削減できる。そのうえで3つのサブエージェントが元のログを検索してサマリーの欠落を見つけ、すべてを`resume-prompt.md`にまとめる。 VS Codeのファイルウォッチャーがこのファイルを検知すると、新しいセッションが自動的に立ち上がり、前の文脈を継承した状態でスタートする。 - pre-compactフックがCompaction前にwriteをブロック → 不完全な状態でコードが変更されるのを防ぐ - JSONL → MD変換でユーザーメッセージ・システムメッセージ・thinkingブロックだけを残す - サブエージェントがギャップ分析を行い、元のログから不足情報を補完 - ビルド効率が10倍改善したと報告されている ## 勝負はセッションログの検索とKV cache セッションデータはJSONLとして蓄積されていくため、必要な文脈をどれだけ正確に引き出せるかが決め手になる。答えは要約の精度ではなく、過去セッションをまたいだ検索ベースの取得だ。 KV cacheのヒット率を考慮すれば、同じプロンプトプレフィックスを再利用することでコストとレスポンスレイテンシを同時に削減できる。自分のセッションフォルダ構成を設計したとき、セッションIDベースのアーカイブが検索速度に最も大きく効いた。昨日紹介したQMDを使った事前インデックス化も、有望な方向性に見える。 - 生のJSONLを保持しておくことで、必要なときに精密な検索が可能になる - `resume-prompt.md`には前セッションのサマリー・ギャップ分析結果・変更ファイル一覧が含まれる - システムプロンプトと引き継ぎプロンプトのプレフィックスを固定してKV cacheヒット率を最大化 - セッションアーカイブの自動化により、数十の連続セッションにわたって文脈を維持できる ## AIコーディングの本当のボトルネックはコンテキスト管理 AIコーディングツールの真のボトルネックはモデルの性能ではなく、コンテキスト管理にある。忘れた情報を取り出せる検索パイプラインを設計することは、要約の精度を磨くことよりも重要だ。 Compactionは必ず情報を失う。大切なのは、失われた情報を取得できる検索パイプラインと、セッションをまたいで文脈を途切れなく渡すハンドオーバーアーキテクチャを両立させることだ。 *[Kangwook Lee, CAIO](https://lnkd.in/gPw8uipE)による分析をもとにまとめました。* --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/ja/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.