コーディングエージェントを長時間回していると、ある瞬間から挙動が鈍ることがある。原因を追うと、たいてい文脈ウィンドウが限界に近づき、それまでの作業ログを自動で要約して「畳んだ」直後だったりする。ここで素朴な疑問が湧く。その要約を書いたのは誰で、出来は良かったのか。

7月に公開された論文「CompactionRL: Reinforcement Learning with Context Compaction for Long-Horizon Agents」(arXiv:2607.05378、GLMを開発するチームによる)は、この問いを正面から扱っている。主張はシンプルだ。エージェントが文脈を圧縮するときに書く要約は、動けばいい固定機能ではなく、タスクの成功に向けて訓練できる方策(policy)である、というもの。

🧩 いまの圧縮は「要約の質」を測っていない

長時間タスクで文脈が溢れるのを防ぐ仕組みは、もう実務に入っている。Anthropicのcompaction機能は、入力トークンがしきい値(デフォルト15万、最小5万)に達すると会話を自動で要約し、要約ブロックに差し替えて続きを生成する。有効化はMessages APIにフラグを足すだけだ。

response = client.beta.messages.create(
    betas=["compact-2026-01-12"],
    model="claude-opus-5",
    max_tokens=4096,
    messages=messages,
    context_management={"edits": [{"type": "compact_20260112"}]},
)

（出典: Anthropic Compaction docs）

便利だが、ここで生成される要約はベースモデルの素の要約能力に丸投げされている。その要約がタスクに効いたかどうかは、その場では一切測られない。仮に「この関数はスレッドセーフでない」といった制約や、バグの再現手順を要約が落としていれば、以降の推論は静かに劣化する。しかも発火はリアクティブで、文脈がすでに古い情報で飽和してから慌てて畳む。CompactionRLが突くのは、まさにこの空白だ。

要約をRLの最適化対象に入れる

CompactionRLの発想は、圧縮をエージェントの「行動の一部」として扱うことにある。残り文脈が一定の余白 T_comp を割ったら(論文の条件は C - |h_t| < T_comp)要約指示を差し込み、モデル自身に要約を書かせ、システムプロンプトと要約と直近k手(既定は k=2)だけで文脈を再構成して続行する。ここまでは通常のcompactionと変わらない。違うのは、その要約トークンにも報酬勾配を流し、最終的なタスクの成否から逆算して「良い要約とは何か」を学習させる点だ。

厄介なのは、これが素朴なグループRL(GRPOのような、複数ロールアウトを束にして相対比較する方式)の帳簿を壊すことにある。本来は1本のロールアウトを1サンプルとして扱いたいのに、途中で圧縮が起きると文脈が組み替わり、1本の軌跡が複数のセグメントに分割される。圧縮回数が多い軌跡ほどセグメント数が増え、学習で過剰に重み付けされてしまう。

著者らの対処は二段構えだ。ひとつはトークン単位の損失正規化で、サンプルやセグメント単位ではなく生成トークンの総数で割ることで、圧縮回数の偏りを打ち消す。もうひとつが軌跡位置を考慮したGAE補正で、各セグメントの局所アドバンテージに (γλ)^(N_>s) を掛け、そのセグメント以降に生成されたトークン数 N_>s に応じて終端報酬を減衰させる。バラバラに切ったログを、元の一本のタスクとして正しく縫い直すイメージに近い。切り口ごとに報酬をそのまま置き直す素朴なやり方だと、まだ結果を知らない序盤の行動まで過大評価してしまう。

📉 小さいモデルほど効く、という結果

同じベースモデルにCompactionRLを適用した前後を並べると、効き方が見えてくる。

モデル	ベンチ	Base	CompactionRL
GLM-4.5-Air (106B)	SWE-bench Verified	59.8%	66.8%
GLM-4.5-Air (106B)	Terminal-Bench 2.0	21.4%	24.5%
GLM-4.7-Flash (30B)	SWE-bench Verified	50.5%	56.0%
GLM-4.7-Flash (30B)	Terminal-Bench 2.0	13.4%	20.2%

30Bの小型モデルがターミナル系エージェントタスクで最大 +6.8ポイント伸びているのは示唆的だ。文脈が窮屈なモデルほど、何を残し何を捨てるかの巧拙がそのまま成否を左右する、ということだろう。論文によれば、この手法はフラッグシップである750B級のGLM-5.2の訓練パイプラインにも組み込まれたという。研究のための小実験ではなく、量産モデルに乗った技術だという点は押さえておきたい。

要約はプロンプトではなく方策だ

正直に書くと、CompactionRLそのもののコードは公開が確認できない(実装は既存のオープンソースRLフレームワーク slime の上、とだけ記されている)。いますぐ手元で再現できる類のものではない。

それでも実務への含意ははっきりしている。自前のエージェントで走る「要約プロンプト」を、動けばよい固定部品として放置するのはもったいない。要約は方策であり、評価も最適化もできる対象だ。今日からできる第一歩は、圧縮の前後でタスク成功率を測る計器を入れることだと思う。要約が実際に何を落としているかが数字で見えて初めて、それを直す議論が始められる。しきい値をいじって発火タイミングを調整するより、そちらの方がずっと本質に近い。