長時間動くAIエージェントを一度でも運用したことがあれば、この壁にぶつかっているはずだ。ツール呼び出しと思考ログが延々と積み上がり、やがてコンテキストウィンドウが溢れる。数十ステップ前に一度だけ見たディレクトリ一覧や、とっくに解決済みのサブ課題のデバッグ出力が、いつまでも文脈に居座って場所を食う。

現場での定番の対処は「要約(コンパクション)」だ。Claude Codeの自動コンパクションのように、履歴が一定量に達したら、あるいは数ステップおきに、それまでの経緯を短い要約に畳んで置き換える。ところがこの「一定間隔で畳む」という発想そのものに落とし穴がある。ジョンズ・ホプキンス大らの研究チームが6月22日に公開した論文 Self-Compacting Language Model Agents は、そこを突いている。

なぜ「決まった間隔で要約」が下手なのか

固定間隔の要約は、要約すべき瞬間を外す。長い数式変形の途中(mid-derivation)や、答えに詰まって試行錯誤している最中にスケジュールが来てしまうと、まだ捨ててはいけない作業メモリを消してしまう。逆に、サブ課題が片付いて明らかに次へ進んでよい局面でも、間隔が来るまでは肥大した履歴を引きずり続ける。要するに、タイミングの良し悪しをカレンダーが決めていて、作業の中身を見ていない。

著者らはここに「メタ認知のギャップ」があると指摘する。何もヒントを与えないと、モデルは自分の文脈が劣化して要約が必要になった瞬間を、自分では確実に判断できない。放っておくと畳むべき時に畳まない。だが、判断の物差しさえ渡せば話は変わる、というのがこの論文の勘所だ。

SelfCompact:モデルに「頃合い」を判定させる

提案手法 SelfCompact は、追加学習をいっさい行わない。推論時に2つの部品を組み合わせるだけだ。

ひとつは、モデルが自分で呼び出せるコンパクション用のツール。もうひとつは、いつ発火させ、いつ我慢するかを示す短い**ルーブリック(判断基準)**である。論文によれば、発火(COMPRESS)するのは「サブ課題が解決した」または「軌道が収束しつつある」と判断したときだけ。逆に「行き詰まっている」「変形の途中」のときは抑制して、必要な作業メモリを早すぎるタイミングで消さないようにする。

比喩を一つだけ使うなら、机の片付けに似ている。定期清掃の業者が時間になったら問答無用で書類をファイルに綴じてしまうのが固定間隔方式。一方SelfCompactは、作業している本人が「この案件は片付いた」と感じた瞬間だけ、自分の判断で机の上をまとめる。手が止まって考え込んでいる最中には片付けない。

畳み方も素直だ。要約が発火すると、エージェントはそれまでの生の軌跡 (x, y₁:t) をそのまま引き継ぐのではなく、要約済みの前置き (x, ỹ) から続きを進める。つまり長い履歴を短い要約で置き換えて、そこから先を再開する。仕組みとしては既存のコンパクションと同じで、新しいのは「置き換える中身」ではなく「置き換える瞬間の選び方」にある。ここが従来との差分だ。

どれだけ効くのか

検証は競技数学(IMO-Answerbenchなど)とエージェント型検索(BrowseComp-Plusなど)にまたがる6つのベンチマーク、7つのモデルで行われた。数値はおおむね次の通り。

比較対象	精度	トークンコスト
要約なし(no-summarization)	基準	基準
固定間隔の要約	同等〜やや上	高い
SelfCompact	数学で最大+18.1点、検索で+5〜9点	1問あたり30〜70%削減

読み方はこうだ。まず、要約を賢く挟むこと自体が精度を上げる(要約なし比で数学は最大18.1点、検索は5〜9点の上積み)。長い文脈を抱え込むほどモデルは注意が散り、性能が落ちるからだ。そのうえでSelfCompactの本当の勝ち筋は、固定間隔方式と同等かそれ以上の精度を、1問あたり3〜7割も安いトークンコストで出す点にある。無駄な要約を打たず、必要な要約だけを打つから、当然コストが下がる。

SelfCompact matches or exceeds fixed-interval summarization at a fraction of the token cost.
（SelfCompactは固定間隔の要約に、わずかなトークンコストで匹敵、あるいは凌駕する)

より細かい数値やモデル別の内訳は Hugging Faceの論文ページと本文PDF にあたってほしい。

実務者として、どう受け止めるか

この論文の価値は、派手な新モデルではなく「既にあるエージェントに今日から効く」ところにある。追加学習が要らず、ツールと数行のルーブリックだけで成り立つのだから、自前のエージェントループにコンパクション用ツールを一つ足し、発火条件のプロンプトを「サブ課題が済んだ/収束したときだけ畳め、行き詰まりや導出の途中では畳むな」と書くだけで、思想は再現できる。論文はそのプロンプト設計とスケジューリングの当たりを、実験で裏付けてくれた形だ。

裏を返せば、多くのエージェント基盤が採っている「トークン数の閾値で自動コンパクション」という素朴な設計には、まだ改善の余地が残っているということでもある。閾値は作業の意味を見ていない。畳むかどうかの判断を、時計やトークンカウンタではなくモデル自身の状況認識に委ねる。この発想は、コンテキストエンジニアリングの次の当たり前になっていく気がする。

一点だけ留保を付けておく。ルーブリックが機能するのは、モデルに「今このサブ課題が片付いたか」をそこそこ正しく自己申告できる能力があることが前提だ。論文の「メタ認知のギャップ」という指摘は、裏を返せばこの自己申告が万能ではないことも示している。小さなモデルや、状況把握が弱いタスクでどこまで成り立つかは、自分の環境で一度測ってから本番に入れたい。それでも、要約の頻度をハイパーパラメータとして手で決めていた人には、試す価値が十分にある一本だ。