コンテキストの圧縮はしきい値ではなく判断である

長く続いたエージェントの実行がコンテキストの上限に達し、スキャフォールドがそれまでの内容をすべて簡潔なメモへと要約すると、その要約が中途半端な証明の途中に着地してしまう。エージェントは4つの補題のうち3つを手にしていました。それが今や「証明に取り組んでいた」と述べる1段落と、再発見しなければならない4つの補題だけになってしまうのです。圧縮が失敗したのは、要約が悪かったからではありません。作動したタイミングが悪かったのです。

ほとんどのコーディングエージェントは、固定されたトリガーでコンテキストを圧縮します。蓄積されたトークンがしきい値を越えたら要約して続行する、というものです。トリガーは数値ですが、圧縮のコストは構造的なものです。導出の途中で作動すると、モデルが再構築しなければならない部分的な結果が捨てられてしまいます。これは忘れるのに最も高くつく瞬間なのです。 2026年6月の論文「Self-Compacting Language Model Agents」は、いつどのように圧縮するかをモデル自身が判断すべきだと主張し、判断ベースの方式がしきい値方式に匹敵あるいは凌駕しながら、そのトークンコストのほんの一部で済むことを示しています。¹

この結果は、私が配管の細部のように扱ってきた問題の捉え方を変えてくれます。コンテキストの圧縮は、カウンターによって作動するメモリ管理の雑務ではありません。いつ忘れることが安全なのかという判断の問題であり、その判断を下すにはトークン予算よりもエージェントのほうがふさわしい立場にいるのです。

TL;DR

• Claude Code を含むエージェントのスキャフォールドは、ウィンドウの上限に近づくとコンテキストを圧縮します。トリガーはトークン数なので、エージェントが作業のどの地点にいるかに関係なく作動します。
• 導出の途中や探索の途中で作動するのは最悪のケースです。要約は、モデルが計算するために費やし、その後また計算し直さなければならない部分的な結果を捨ててしまいます。
• 「Self-Compacting Language Model Agents」（2026）は、モデルが呼び出せる圧縮ツールと、いつ作動すべきか（サブタスクが解決した、実行が収束しつつある）と、いつ控えるべきか（導出の途中、行き詰まり）を伝えるルーブリックを組み合わせます。どちらか一方だけでは機能しません。
• この手法はファインチューニングも外部の監督も必要としません。6つのベンチマークと7つのモデルにわたって、要約なしのベースラインを数学で最大18.1ポイント、エージェント探索で5〜9ポイント上回り、しかも問題あたりのコストは30〜70パーセント低くなりました。
• 教訓は要約の話を越えて一般化されます。忘れることの正しいトリガーは意味的なもの（作業は安全な区切りにあるか）であって、数値的なもの（バッファは満杯か）ではないのです。

しきい値は誤ったトリガーである

圧縮が存在するのは、長い実行が腐敗するからです。思考の連鎖やツール呼び出しが積み重なり、古びた内容が後続の生成を引きずり、やがてトレースがウィンドウを超えて膨らみます。標準的な対処法は、トークンの合計がしきい値を越えたときに作動する、固定された間隔での要約です。¹ これは明白なエンジニアリング上の選択であり、セッションが長く続いたときに本番のスキャフォールドが実際に行うことでもあります。Claude Code は、自らのドキュメントによれば「上限に近づくにつれて自動的に圧縮する」のです。²

問題は、しきい値がコンテキストのサイズは知っていても、その形状については何も知らないことです。トークンカウンターは、サブタスクをきれいに片付けたばかりの実行と、5ステップの導出のうち3ステップ目にいる実行とを区別できません。どちらもカウンターには同じに見えます。一線を越えた数字でしかないのです。だからスキャフォールドは両方を同じように圧縮し、後者の場合はエージェントが完了するのに必要なまさにその中間結果を要約で消し去ってしまいます。

私は自分の自律ループでこれが起きるのを目にしてきました。長い実行が複数ファイルにまたがるリファクタリングの最中に上限に達し、スキャフォールドが圧縮し、エージェントはどのファイルをすでに編集したかを忘れて戻ってきます。何か破滅的な意味で作業が失われたわけではありません。エージェントはそれを再導出しました。しかし再導出こそがコストであり、それはしきい値が盲目的に課すコストなのです。なぜなら、しきい値にはそのタイミングが悪かったことが見えないからです。

この失敗は、私がコンテキストの複利について書いたものとは異なります。複利とは、プロジェクトがセッションをまたいで保持するもの、つまりセッション500をセッション1より速くする規約やフック、記憶についての話です。圧縮とは、単一のセッションがその内部で何を捨てるかについての話です。この2つは反対方向に引っ張り合い、圧縮のほうは誰も調整しません。しきい値がそれを自動的なものに感じさせるからです。

SelfCompact が変えること

この論文の提案である SelfCompact は、判断をスキャフォールドからモデルへと移します。推論時の2つの要素を組み合わせるのです。¹

圧縮ツール。 モデルには、蓄積したコンテキストを要約するために呼び出せるツールが与えられます。これは他のツールを呼び出すのと同じやり方です。圧縮は、ランタイムが課す割り込みではなく、エージェントが取る行動になります。

いつ作動すべきかのルーブリック。 軽量な指示が、圧縮が適切なとき（サブタスクが解決した、または実行が収束しつつある）と、抑制すべきとき（モデルが導出の途中、または行き詰まっている）をモデルに伝えます。このルーブリックこそ、トークンカウンターに欠けている判断なのです。

論文は両方の要素が必要だと率直に述べており、その理由が興味深いところです。オープンウェイトのモデルはツールを不均一に使います。役に立たない瞬間に呼び出したり、まったく省略したりするのです。自分の本能に任せると、モデルは自身のコンテキストの腐敗に気づくのが当てになりません。ルーブリック単体では何もできません。それは行動に移す仕組みを持たない、ただの指示にすぎないからです。両者を組み合わせることで、ファインチューニングも外部の監督もなしに適応的な圧縮が生まれます。¹ モデルはすでに上手に要約する能力を持っています。欠けているのは、いつ要約することが損失に見合うかというメタ認知的な感覚なのです。ルーブリックがその感覚を補います。

この捉え方が重要なのは、人々が混同しがちな2つの能力を切り分けるからです。実行をどう圧縮するかを知ることは生成のスキルであり、フロンティアモデルはそれが得意です。いつ圧縮することが安全かを知ることは自己監視のスキルであり、モデルは促されなければそれが苦手です。SelfCompact は、モデルを要約においてより賢くしようとはしません。本来なら誤ってしまうタイミングの判断について、モデルにチェックリストを与えるのです。

数字

評価は、競技数学とエージェント探索にまたがる6つのベンチマークを、7つのモデルにわたってカバーしています。¹ 比較対象は、要約なしのベースラインと、固定間隔のしきい値方式です。

要約なしと比べて、SelfCompact は結果を数学で最大18.1ポイント、エージェント探索で5〜9ポイント改善し、しかも問題あたりのコストは30〜70パーセント低くなりました。¹ その差こそがコンテキストの腐敗のコストです。自分の古びたトレースに溺れたモデルは、賢く剪定するモデルよりも測定可能なほど成績が悪く、より多くのコストを払うのです。

固定間隔の要約と比べると、見出しになるのは効率です。SelfCompact は、しきい値方式の品質に匹敵あるいは凌駕しながら、そのトークンコストのほんの一部で済ませました。¹ 時計ではなく判断に基づいて圧縮するということは、エージェントが圧縮する回数は少なく、しかもより良い瞬間に行うということです。だから要約の処理回数も少なく済み、捨てられた結果の再構築も少なくて済みます。しきい値方式は時折タイミングを外したのではありません。同等あるいは劣る品質に対して、体系的により高くついていたのです。

長期的なタスクにおける30〜70パーセントのコスト削減は、丸め誤差ではありません。エージェントを大量に運用する人にとって、圧縮のポリシーは費目の一項目であり、論文によれば、ほとんどのスキャフォールドが出荷時に採用しているデフォルトのポリシーは、必要のない要約処理に対してコストを払っているのです。

エージェントを運用する人にとっての意味

実践的な教訓は「今すぐ SelfCompact を実装しよう」ではありません。ほとんどの運用者は、自分のエージェントの圧縮トリガーを直接制御できません。教訓は、圧縮が品質とコストに実際の影響を及ぼす調整可能なポリシーであり、しきい値というデフォルトは疑ってみる価値があるということです。

圧縮の区切りを数値的ではなく意味的なものとして扱う。 長いタスクを組み立てるときは、エージェントに自然な区切り、つまりファイルを完成させる、サブタスクを閉じる、チェックポイントに到達する、といった地点を与えましょう。サブタスクの区切りで圧縮するエージェントは、必要なものを何も失いません。トークンの区切りで圧縮するエージェントは、たまたま手にしていたものを何でも失います。運用者の仕事の一部は、安全な瞬間と圧縮の瞬間が揃うように実行を形作ることなのです。

再導出を症状として注視する。 エージェントが圧縮から戻ってきて、すでに済ませた作業をやり直すなら、トリガーは誤った場所で作動したのです。再導出はタイミングを外した圧縮が観測できる兆候であり、探そうとすればトレースの中に見えるコストなのです。

トリガーがモデルの中へ移っていくことを予期する。 SelfCompact はファインチューニングを必要としません。つまり、どんなスキャフォールドでも採用できるプロンプトとツールのパターンだということです。オープンウェイトのモデルでのきれいな結果は、これがデフォルトになることを示唆しています。ランタイムに強制されるのを待つのではなく、自身の圧縮を自ら判断するエージェントです。しきい値は振り返ってみれば、コンテキストを管理すべきワーキングメモリではなく、フラッシュすべきバッファとして扱ったことの名残のように見えるでしょう。

より広いパターンは、私がエージェントで繰り返し出くわすものです。難しいのは能力であることはめったにありません。フロンティアモデルは実行を上手に要約できます。難しいのはメタ認知、つまりすでにやり方を知っていることを、いつ行うべきかを知ることなのです。圧縮のタイミングは、いつ確認を求めるべきかやいつ調査ループを止めるべきかを知ることと同じく、自己監視の判断であり、自己監視こそ現行世代が最も弱いところです。あらゆる場合における対処法は、SelfCompact が用いるのと同じ形をしています。モデルが気づくことを期待するのをやめ、その判断のための明示的なルーブリックを手渡すのです。

重要なポイント

エージェントの運用者へ: - スキャフォールドがいつ圧縮するかを監査しましょう。トークンしきい値で作動するなら、エージェントがタスクの途中かどうかに関係なく作動しているのです。 - 圧縮の区切りが恣意的な瞬間ではなく安全な瞬間に落ちるように、長いタスクを明示的なチェックポイントを軸に組み立てましょう。 - 圧縮後の再導出を、モデルの癖ではなくトリガーのバグとして扱いましょう。

スキャフォールドを構築する人へ: - 圧縮ツールに作動／抑制のルーブリックを加えたものは、ファインチューニングを必要とせず、より低いコストで固定間隔を上回ります。 - 2つの能力を切り分けましょう。モデルは上手に要約しますが、タイミングの判断は下手です。設計の労力は要約器ではなくタイミングのルーブリックに注ぎましょう。

エージェントの実行に予算を組む人へ: - 圧縮のポリシーはコストの費目です。判断ベースのトリガーは、研究において問題あたりのコストを30〜70パーセント削減し、しかも品質は同等あるいはそれ以上でした。

FAQ

コンテキストの圧縮とは何ですか？

コンテキストの圧縮とは、エージェントが蓄積した実行（思考の連鎖とツール呼び出し）を、トレースがモデルのコンテキストウィンドウを超えて膨らまないように、より短い形へと要約することです。詳細を犠牲にして余地を得るのです。うまく行えば、エージェントがまだ必要とするものを保ちつつ、古びた内容を取り除きます。誤った瞬間に行えば、エージェントが再計算しなければならない部分的な結果を捨ててしまいます。

なぜトークンしきい値は悪い圧縮トリガーなのですか？

トークンしきい値はコンテキストのサイズを測りますが、その構造は測りません。エージェントがサブタスクを終えたばかりなのか、導出の途中なのかを区別できないのです。後者の場合に作動すると、モデルが計算するために費やした中間結果を捨て去り、高くつく再導出を強います。トリガーはエージェントが作業のどの地点にいるかを反映すべきですが、それはカウンターには見えないものなのです。

SelfCompact はいつ圧縮するかをどう判断するのですか？

モデルが呼び出せる圧縮ツールと、いつ作動すべきか（サブタスクが解決した、実行が収束しつつある）と、いつ抑制すべきか（導出の途中、または行き詰まり）を指定するルーブリックを組み合わせます。モデルはすでに上手に要約します。ルーブリックは、促されなければ欠けているタイミングの判断を補うのです。この手法はファインチューニングも外部の監督も必要としません。

これは特別なモデルを必要としますか？

いいえ。論文はオープンウェイトのものを含む7つのモデルを評価し、このパターンはプロンプトとツールの利用だけで機能します。そのため再訓練なしに、どんなスキャフォールドでも採用できます。

判断ベースの圧縮はどれくらい節約できますか？

研究では、SelfCompact は固定間隔の要約に匹敵あるいは凌駕しながら、問題あたり30〜70パーセント少ない費用で済み、要約なしのベースラインを数学で最大18.1ポイント、エージェント探索で5〜9ポイント上回りました。

出典

• Tianjian Li, Jingyu Zhang, William Jurayj, Xi Wang, Chuanyang Jin, Mehrdad Farajtabar, Eric Nalisnick, Daniel Khashabi、「Self-Compacting Language Model Agents」、arXiv、2026年6月22日: arxiv.org/abs/2606.23525
• Anthropic、「Explore the context window」、Claude Code ドキュメント、コンテキスト上限付近での自動圧縮について: code.claude.com/docs/en/context-window
• 自律ループとコンテキスト管理に関する関連の本番経験: Ralph エージェントアーキテクチャ、コンテキストの複利、そしてエージェント運用者のハンドブック