長時間走るエージェントを書いたことがあれば、この気持ち悪さは分かるはずだ。ツールの出力や途中の推論がどんどん積み上がり、コンテキストウィンドウに収まらなくなる。そこで履歴を要約して圧縮する。うまく動いているように見える。でも、その要約が「次に必要になるまさにその情報」を捨てていないと、どうして言い切れるのか。捨てた証拠は要約の中には残らない。

この不安を、初めて理論として正面から扱った論文が8月2日にarXivへ出た。Context Compaction Theory(Tirmazi, Markelon, Bishop, Mitzenmacher)だ。主張は挑発的で、エージェントの文脈圧縮という現代的な問題は、実は数十年前から研究されてきた一方向通信計算量とぴったり同じものだ、という。しかも彼らはAnthropicの圧縮機能を実測し、ある種の質問には当てずっぽうに近い精度しか出ないことを示している。

「捨てる」と「言い換える」は別のゲームだ

論文はまず、実際のエージェントがやっている圧縮を2つに分ける。

ひとつは選択(Selection)。積み上がった状態の中から残す部分を選び、残りを捨てる。Anthropicのcontext editingで言えば、clear_tool_uses_20250919 ストラテジがまさにこれだ。古いツール結果を消して枠を空ける。原文をいじらず、部分集合を切り出すだけだ。

もうひとつは生成(Generation)。状態を、長さの上限だけ決めた任意のメッセージへ「言い換える」。要約による圧縮、つまりLLMに履歴をまとめさせるあれで、Anthropicが「高忠実度の要約に蒸留する」と説明するcompactionがこちら側にあたる。新しいトークンを吐いてよいし、並べ替えても、元の合計サイズより短くしてもよい。

	選択 (Selection)	生成 (Generation)
やること	部分集合を残し、残りを捨てる	任意の短いメッセージへ言い換える
Anthropicの機能	`clear_tool_uses`(ツール結果の消去)	compaction(履歴の要約)
表現力	元の断片の組み合わせだけ	自由。新しい語や指示子を作れる

直感的には生成のほうが強そうだが、実務ではどちらを選ぶべきかは自明ではなかった。論文はここに白黒をつける。ある種の質問集合に対しては、生成が選択より厳密に少ないビット数で足りる。具体的には、n個の項目それぞれが log₂(n) ビットのとき、任意の部分集合を復元する質問に対して生成は n ビットで誤りゼロを達成できるのに、選択はどうしても n·log₂(n) ビット必要になる。つまり Θ(log n) 倍の差がつく(定理3)。指示子ベクトルを一本送れば済む生成に対し、選択は全項目を抱えるしかないからだ。

なぜ通信計算量なのか

生成ゲームの核心を、メンタルモデルひとつで言い換えるとこうなる。過去の自分(全履歴を持つAlice)が、未来の自分(これから質問を受けるBob)へ、Bグラム上限のメッセージを一度だけ送る。Bobはそのメッセージだけを頼りに質問へ答える。これは教科書的な一方向通信そのものだ。

論文の定理1は、この対応が厳密な等式であることを示す。

目標誤差ϵ以内で質問群に答えられる最小の圧縮バジェットは、誘導される通信問題の一方向(ランダム化)通信計算量に等しい。

嬉しいのは、これで通信計算量の既知の下限がそっくり文脈圧縮に流用できることだ。たとえば古典的な INDEX問題。Aliceがnビット列を持ち、Bobは添字iだけを持って「i番目のビットは何か」を問う。Aliceはどのビットを聞かれるか知らないので、結局ほぼ全ビットを送るしかない。ランダム化しても下限は Ω(n) だと知られている。

これがエージェントに直結する教訓だ。未来の質問分布が分からないまま圧縮するなら、原理的に「ほぼ全部持っておく」以外に手はない。逆に言えば、圧縮が効くのは質問が偏っているときだけで、「何を聞かれるか分からない汎用エージェント」ほど圧縮の理論的余地は小さい。日々コンテキスト設計をしていて薄々感じていた壁に、名前と下限がついた。

Anthropicの圧縮を集合所属で試したら

理論だけなら机上の話で終わる。論文の面白さは、Anthropicの圧縮を実際に叩いて測った点にある。著者らは15,000項目を記録し、「これから集合所属(このIDは入っていたか?)しか聞かない」と事前に伝えたうえで圧縮させ、所属判定の正答率を測った。比較対象は同じ圧縮後サイズの Bloomフィルタだ。

結果は辛辣だ。エンドポイントの所属判定は、ほぼランダム推測並みの誤り率だったという。情報理論の下限で言えば、誤検出率ϵでN項目を保持するには約 1.44·N·log₂(1/ϵ) ビットあれば足りるのに、LLMの要約はその最適から大きく外れていた。要約は文章として自然でも、集合メンバシップという離散的で圧縮しにくい情報を、そもそも保持していない。

もうひとつ論文が釘を刺すのは、圧縮を繰り返すと品質が落ちるという点だ。要約の要約は、非可逆な再圧縮の連鎖になる。長時間エージェントでcompactionが何度も走る設計は、静かに情報を漏らし続けているかもしれない。

で、実務ではどう手を打つか

私が持ち帰った結論はシンプルだ。「要約か消去か」で迷う前に、まず未来の質問がどんな分布かを問う。質問が特定の下流タスクに偏っているなら、生成(要約)は選択より効率的になりうる。逆に、任意のIDへの所属や、後からどの依存関係を参照するか読めないなら、それはINDEXやdisjointnessの世界で、どんな圧縮スキームも救ってくれない。素直に生ログを残すか、外部ストア(Bloomフィルタ、KVS、検索インデックス)へ逃がすのが正解になる。圧縮で頑張る問題ではない。

その前提で、選択側を使うならAnthropicのcontext editingは実務的だ。サーバー側で走るのでクライアントは完全な履歴を保持でき、keep で直近を守り、clear_at_least でキャッシュ無効化が割に合う量だけ消せる。

# ベータヘッダで有効化する
anthropic-beta: context-management-2025-06-27

{
  "type": "clear_tool_uses_20250919",
  "trigger": { "type": "input_tokens", "value": 30000 },
  "keep": { "type": "tool_uses", "value": 3 },
  "clear_at_least": { "type": "input_tokens", "value": 5000 },
  "exclude_tools": ["web_search"]
}

exclude_tools で「消してはいけないツール」を守れるのは、まさに論文の教訓の実装版だ。後で参照する情報を圧縮対象から外す、これは質問分布を先に固定して圧縮バジェットを最適化する行為にほかならない。理論が言う「質問を知っていれば圧縮は安い」を、設定ファイルで手動でやっているわけだ。

一次ソースへのリンクを置いておく。理論の主張と実測はこの論文に、圧縮機能の仕様はAnthropicの公式ドキュメントに当たってほしい。

※本記事は一次情報の調査をAIが行い、事実確認のうえ執筆・公開しています。