数か月前、私は コンテキスト・エンジニアリング について書きました。長時間のセッション中にAIエージェントが正気を失わないように保つ、目に見えないロジックです。私は外から見える形で、そのパターンを説明しました。最新のファイルバージョンを維持する、ターミナル出力を削る、古いツール結果を要約する、システムプロンプトをガードする、といったことです。
また私は予測もしました。素朴なLLMによる要約はバンドエイドである、と。実際に必要だったのは決定的なキュレーション（選別）作業でした。要約は最後の手段であるべきです。
そしてClaude Codeのリポジトリが公開されました。私はClaudeに、自分自身のコンパクション（圧縮）ソースコードを分析してもらいました。
予測は当たりました。そして実装は、私が期待していたよりもずっと思慮深いものでした。
Three Tiers, Not One
Claude Codeのコンパクションシステムは単一の仕組みではありません。3つのティアを、最後まで順番に適用していくのです。いずれも前のものより重い仕組みです。
Tier 1 は、毎回のAPI呼び出しの前に実行されます。軽量なクリーンアップです。古いツール結果をクリアし、最新の5つだけを残し、残りを [Old tool result content cleared] に置き換えます。高速で安価で、モデルは一切関与しません。
Tier 2 はAPIレベルで動作します。サーバー側の戦略で、トークン閾値に基づいて思考ブロックとツール結果のクリアを処理します。
Tier 3 は、完全なLLM要約です。意図、技術的概念、触れたファイル、エラーと修正、すべてのユーザーメッセージ、保留タスク、現在の作業、という構造化された9セクションの要約。モデルは、要約をコミットする前に会話全体を推論します。つまり、要約後に削除されるチェーン・オブ・ソート（思考過程）のためのスクラッチパッドです。これは洗練されています。しかし、最後の手段です。
このアーキテクチャは、最初の記事で主張したことをまさに裏づけています。要約は高価で情報を失いやすい（ロッシー）ということです。要約に頼るのは、ほかのすべてがすでに実行された後だけです。
But Here's the Problem
Tier 1 に関する記事を読んだとき、私の最初の直感はこうでした。会話がキャッシュされているなら、古いメッセージを削除することはキャッシュを無効化してしまうのではないか、と。キャッシュ無効化は非常にコストが高い。トークンに対して90%の割引が効くどころか、キャッシュへの書き込みに対して1.25倍を支払うことになります。つまり、コンパクションのコストが、節約できたトークン以上になってしまう。そういうことです。
ではClaude Codeはどうやって解決しているのでしょう？答えには cache_edits という仕組みが関わっています。これはキャッシュ済みのプレフィックスに触れずに、ツール結果だけを手術のように取り除くものです。さらに、要約の呼び出しがメインの会話のキャッシュキーに便乗します（代替案では98%のミス率だった）。そして、コンパクション後にセッション全体の状態を再構築するプロセスがあります。
完全な投稿では次の内容を扱っています：
cache_editsが、クリーンアップ中にプロンプトキャッシュをどのように保持するか- なぜ要約の呼び出しがあなた自身のキャッシュキーを再利用するのか（そして再利用できない場合に何が起きるか）
- コンパクション後の完全な再構築プロセス
- キャッシュ経済（キャッシュのコストと効果）が、システム内のあらゆる設計上の判断にどう影響したか
