コンテキスト圧縮は、AIエージェントが長期タスクを実行する上で避けられない問題だ。ウィンドウが埋まれば、どこかを削らなければならない。問題は「何を削るか」ではなく「何を守るか」にある。

Source によれば、Claude Code・Codex CLI・OpenCode・Cline・Cursor・Ampの6エージェントを実際に使い込んだ観察として、各システムが「階層的プログレッシブ圧縮（layered progressive compression）」に収束しつつあることが指摘されている。しかし、何を第一級資産として保護するかについては、各エージェントで判断が分かれている。

6エージェントが「守るもの」の共通点と相違点

まず共通点から整理する。ほぼすべてのエージェントが「直近のユーザーメッセージ」を最優先で保護する。理由は明快だ。ユーザーの発言は指示の根拠であり、真実の源泉（source of truth）である。これを失えば、エージェントは何のために動いているかを見失う。同様に、状態を持つツール出力（stateful tool outputs）も多くのシステムで保護対象となっている。

相違点は「古いアシスタントメッセージ」の扱いに現れる。Artifactsは直近のツール呼び出しをそのまま保持する一方、古いコンテキストを積極的に削除する。Cursorはウィンドウが満杯に近づくと、過去の設計判断から刈り込みを始める。Codex CLIはモデル自身にサマリー層で何を保持するかを決定させる。三者三様だ。

この違いは実用上の差異を生む。設計判断の経緯を保持するか否かは、長期リファクタリングや複数ファイルにまたがる変更で顕著に影響する。Cursorが早期に設計判断を刈り込む戦略を採るなら、セッション後半でエージェントが「なぜこの構造を選んだか」を参照できなくなる可能性がある。

透明性の軸：モデルは自分が圧縮されたことを知るべきか

観察者が特に注目しているのが「透明性」の問題だ。コンテキストが圧縮されたとき、モデルにそれを伝えるか否か。

一方の戦略は「サイレント置換」だ。古いツール結果をプレースホルダーで静かに差し替える。モデルは自分のコンテキストが劣化していることを知らないまま推論を続ける。これは「何も起きなかったかのような錯覚の下で推論している」状態だ。

もう一方は明示的な通知だ。「直前の40回のツール呼び出しは以下に要約されています」と明記する。観察者はこちらを支持している。モデルが自分のコンテキストが劣化していることを認識していなければ、不確かな根拠の上で確信を持って推論するリスクがある。

これはプロンプト設計の問題でもある。モデルに「あなたは完全な情報を持っていない」と伝えることは、出力の信頼性に直結する。サイレント圧縮は短期的にはコストを下げるが、モデルの自己認識を歪める。

圧縮戦略の構造：snip → prune → summarize

観察者が参照するVerdentのエージェントループは、圧縮の順序を明確に定義している。まず「snip（切り取り）」、次に「prune（剪定）」、最後に「summarize（要約）」だ。そして、ユーザーメッセージ・状態を持つツール出力・ユーザーが明示的にフラグを立てたコンテキストには「絶対に触れない赤線」を引く。

この構造はトレードオフを明示している。積極的な圧縮はトークンコストを削減するが、計画の精度を劣化させる。圧縮が不十分ならウィンドウが溢れ、「コンテキスト腐敗（context rot）」が起きる。どちらも失敗モードだ。最適点はタスクの性質によって変わる。短期的な一問一答なら積極圧縮でよい。長期的な設計タスクなら、設計判断の経緯を保持するコストを払う価値がある。

結論：プロンプトエンジニアの視点から

コンテキスト圧縮はエージェント内部の問題に見えるが、実態はプロンプト設計の問題だ。何を保護するかの判断は、最終的にはシステムプロンプトかエージェントループのロジックに書かれている。

筆者が注目するのは「透明性」の軸だ。モデルに自分の認識限界を伝えることは、出力品質の安定に寄与する。「あなたは過去の40ステップの要約しか持っていない」と明示することで、モデルは不確かな領域で断定を避ける可能性がある。これはシステムプロンプトに一行加えるだけで実装できる判断だ。

自前のエージェントループを設計する読者は、まず「何を絶対に削らないか」のリストを定義することから始めるべきだ。保護対象が決まれば、残りの圧縮戦略は自ずと決まる。