コンテキストのコンパクションは学習目標になりつつある

長いエージェントセッションは、いつも同じ終わり方をします。コンテキストが埋まり、要約が走り、それ以前に起きたことの圧縮された記憶の上で実行が続いていきます。Claude Codeでは、そのトリガーは/compactか、ウィンドウの上限に近づくと自動で走るパスです。オペレーターはこの瞬間を、管理すべき摩擦として扱います。重要な状態を守り、要約がそれを保ってくれることを祈り、先へ進む、というわけです。しかし最近の一連の研究は、その直感がまもなく古びることを告げています。コンパクションは、あなたが回避策を組む推論時のパッチから、モデルが直接最適化する学習時の目標へと移りつつあるのです。自らの圧縮を生き延びる軌跡を生成することにモデルが報酬を与えられるようになると、コンテキスト管理はもはやあなたのお守り仕事ではなくなり、あなたが選び取る性質になり始めます。 {.answer-block}

TL;DR

• 現在、コンテキストのコンパクションは推論時に存在しています。Anthropic自身も、これをコンテキストエンジニアリングの技法として位置づけています。ウィンドウの上限に近づいた会話を要約し、その要約で初期化し直す、というものです。² その周辺のランタイムツールキット、つまり/compact、自動コンパクション、context editing、memory toolはいずれも、自分がコンパクションされていると知らないモデルを包んでいるにすぎません。³⁴
• CompactionRLは、コンパクションを見込むようモデルを学習させます。タスクの実行と要約の生成を強化学習で同時に最適化するため、エージェントはコンパクションに中断されるのではなく、コンパクションされた軌跡から学ぶのです。¹
• その数字は本物です。GLM-4.5-Airでは、SWE-bench VerifiedのPass@1で66.8%、7.0ポイントの向上を達成し、Terminal-Bench 2.0では24.5%に達しています。¹ これらのベンチマークは議論の的でもあり最新でもあって、おもちゃではありません。⁸⁹
• これは1本の論文の話ではありません。Memory-R1はADD/UPDATE/DELETEというメモリ操作を強化学習で学習させ、MemActはコンテキストのキュレーションをポリシーが取る行動として扱い、それらをエンドツーエンドで最適化します。⁶⁷ 独立した3つのグループが、同じ一手に手を伸ばしたのです。
• オペレーターにとっての教訓は、どちらに転んでも変わりません。コンパクションの継ぎ目を、偶然の産物ではなく設計対象として扱うこと。何を永続的なメモリに置き、何を一時的なコンテキストに置くかを決め、その境界をPreCompactフックで守り、そしてモデルの学習されたコンパクション能力を、脚注ではなく仕様の1行として読み始めることです。⁵

誰もがすでに管理しているパッチ

コンテキストは有限の資源であり、長いセッションを回すオペレーターは誰もが、それを節約することを学んできました。Anthropic自身のエンジニアリング記事は、その失敗モードを的確に名指ししています。トークン数が増えていくにつれて想起の精度が落ちていく、この劣化を彼らはcontext rotと呼びます。² 同じ記事は、その対策も平易な言葉で定義しています。コンパクションとは、コンテキストウィンドウの上限に近づいた会話を取り上げ、その内容を要約し、新しいコンテキストウィンドウをその要約で初期化し直す営みです。²

その定義をもう一度読み、作業がどこで起きているかに目を向けてください。作業はモデルの周りで、推論時に、モデルが関与していない仕組みによって行われます。Claude Codeは、その仕組みを具体的な形にしています。/compactコマンドはこれまでの会話を要約することでコンテキストを解放し、要約に何を残すかを操るためのフォーカス指示を渡すこともできます。⁴ 自動コンパクションは、コンテキストが上限に近づくと同じパスを自動で走らせます。これはautoCompactEnabled設定によりデフォルトで有効になっており、それが発動する実効ウィンドウはCLAUDE_CODE_AUTO_COMPACT_WINDOWで設定し、DISABLE_AUTO_COMPACTで無効化できます。⁴ プラットフォーム側では、context editingがトークンの上限に近づくと古くなったツール呼び出しとその結果を自動で消去し、ファイルベースのmemory toolはモデルがウィンドウの外に情報を丸ごと保存できるようにします。³

これらは優れたツールです。Anthropicの報告によれば、context editing単体で長期タスクのエージェント評価が29%向上し、memory toolと組み合わせると100ターンの実行でトークン消費を84%削減できたといいます。³ 論点は、ランタイムのアプローチが弱いということではありません。論点は、それが何を前提にしているかです。これらの技法はどれも、コンテキストをセッションの外的な性質として管理し、コンパクションされていない軌跡で学習され、デプロイ時になって初めてコンパクションに出会うモデルに適用されます。モデルは、これまでどおり長い軌跡を生成します。いつ要約するか、何を残すか、どう再開するかは、別の何かが決めます。そしてモデルは、自分が書いたのでもなく、見込むよう学習されたこともない圧縮されたコンテキストの中で目を覚ますのです。

モデルがどう学習されたかと、どう動かされるかとの間にあるこの隔たりこそ、新しい研究が閉じようとしている継ぎ目なのです。

CompactionRLが実際に変えるもの

ZhipuのGLMチームによるCompactionRLは、同じ問題設定から出発しつつ、その解き方を反転させます。コンパクションを推論に後付けするのではなく、コンパクションをモデルが学習して行うことの一部にするのです。この手法は、タスクの実行と要約の生成を同時に最適化します。トークンレベルの損失正規化と軌跡横断の一般化アドバンテージ推定を用いることで、エージェントはコンパクションされた長期の軌跡に脱線させられるのではなく、そこから学べるようになります。¹

仕組みを取り払えば、この転換は簡単に言い表せます。ランタイムのアプローチでは、要約器はポリシーの外に座り、モデルはそれが生み出すものを何であれ受け入れます。CompactionRLでは、要約はタスクを行うのと同じポリシーが生成し、その両方がまとめて報酬を受けます。モデルは、自分が行動できる要約を書き、自分が書いた要約の上でうまく行動するよう学習されるのです。コンパクションは中断であることをやめ、エージェントが練習してきた一手になります。

その結果は、最新のベンチマークで実を結びます。オープンなGLM-4.5-Airモデルの上に構築されたCompactionRLは、SWE-bench VerifiedのPass@1で66.8%、7.0ポイントの絶対的な向上を達成し、Terminal-Bench 2.0では24.5%に達します。¹ より小さなGLM-4.7-Flashでは、2つのベンチマークでそれぞれ5.5ポイントと6.8ポイントを上乗せします。¹ どちらのベンチマークも本物で、難易度も高いものです。SWE-bench Verifiedは実際のGitHubのissueを解決するための、人手で検証された500件のサブセットであり、Terminal-Bench 2.0は人手で検証された89のコマンドラインタスクで、フロンティアのエージェントでもまだ3分の2に届きません。⁸⁹ SWE-bench Verifiedには但し書きが必要です。OpenAIが2026年初頭、テストの欠陥と汚染を理由に、これをフロンティア指標として公に一歩引いたためです。したがって、これは非の打ちどころのない指標というより、最も多く引用されるエージェント型コーディングのベンチマークとして扱うのがよいでしょう。⁸ それでもこの向上は但し書きを生き延びます。というのも、これらはモデル内部の差分だからです。同じベースモデルが、コンパクションを学習して、自分自身に勝っているのです。

この論文で最も物語っている一文は、ベンチマークではありません。CompactionRLは、次のオープンなGLMモデルを学習させる強化学習パイプラインに投入されています。¹ コンパクションは、あなたがモデルに対して行うことから、モデルがそれを用いて作られるものへと移ったのです。

一度きりの話ではない

1本の論文は、一つの結果です。独立した3つのグループが同じ一手に手を伸ばすのは、一つの方向です。CompactionRLと並んで、2025年の別の2本の論文も、コンテキスト管理を包み込むものではなく学習させるものとして扱っています。

Memory-R1は、ADD、UPDATE、DELETE、NOOPという構造化された操作を強化学習で学ぶメモリマネージャーをエージェントに備えさせます。これにより、何を覚え何を捨てるかという判断は、固定的なヒューリスティックではなく、学習されたポリシーになります。⁶ しかもわずか152件の学習事例でその結果に到達しており、この能力は高くつくものというより潜在的なものに近いことを示唆しています。⁶ MemActは、本エッセイが主題とする枠組みへとさらに踏み込みます。コンテキスト管理を、削除と挿入というインプレース編集の操作として定式化し、情報の保持とタスクの遂行をエンドツーエンドの強化学習で同時に最適化するのです。⁷ 彼らの言葉を借りれば「行動としてのメモリ」であり、作業中のコンテキストのキュレーションは前処理の一段階ではなく、ポリシーの一部なのです。

3本を合わせて読むと、それらは一つの移行を描き出します。ランタイムのツールキット、すなわちcontext editing、外部メモリ、スケジュールされた要約は、有限のウィンドウに対する現在の答えです。学習時のアプローチは、同じふるまいをモデルに内在するものにし、実際に意味を持つ報酬、つまりタスクを完遂することに対して学習させます。同じ発想が、メモリ操作でも、context editingでも、軌跡のコンパクションでも、たった1年のうちに現れるとき、個々の論文よりも、それらが共有するベクトルのほうが重要になるのです。

これが今、あなたの作り方にとって意味すること

これらのどれも、明日あなたのハーネスに届くわけではありません。誠実なオペレーターの問いは、それが到来するまでの間に何をするか、です。答えは、待つことではありません。この移行は、あなたがすでにコンテキストの周りで行っている作業の値付けを変えるものであり、いくつかの一手が、これからやってくる版に向けてあなたを位置づけてくれます。

コンパクションの境界を、設計対象として扱いましょう。今のところ、ほとんどのオペレーターは自分のコンパクションのふるまいを偶然に発見し、要約が3ターン目の決定を落としてしまったことに後から気づきます。それを意図的なものにしてください。どんなリセットも生き延びる永続的なメモリに属するもの、つまりあなたのルール、プロジェクトの慣習、タスクの契約と、要約が圧縮してよい一時的なコンテキストとを、前もって決めておくのです。Claude Codeでは、永続的な層はあなたのCLAUDE.mdとルールファイルであり、これらはInstructionsLoadedイベントを通じてコンパクションの後に再読み込みされます。加えて、ウィンドウより長く生き残らなければならない状態のためのファイルベースのメモリストアもあります。³⁵ それ以外はすべて、要約器の手に委ねてよいものです。

継ぎ目を、祈りではなくフックで守りましょう。Claude Codeは、コンパクションの前に発火してそれを操ったりブロックしたりできるPreCompactフックと、その後の後始末のためのPostCompactフックを公開しています。⁵ ある種の状態を決して要約で消し去られてはならないなら、フォーカス指示が守られることを当てにするのではなく、PreCompactフックこそが、それを確定的に強制する場所です。この規律は、常に実行されなければならない何かにとってフックが正しいツールである理由と同じものです。つまり、保証をプロンプトの外へ、コードの中へと移すのです。

学習されたコンパクション能力を、仕様の1行として読み始めましょう。CompactionRLの方向が成熟していくにつれ、モデルはコンテキストウィンドウのサイズだけでなく、圧縮された状態で働くようどれだけうまく学習されたかによっても違ってくるでしょう。ウィンドウサイズは、この2年ずっと見出しを飾る数字でした。あらゆるモデルカードを支える200K対1Mの比較です。その数字は、もっと静かな数字と舞台を分かち合おうとしています。すなわち、自分自身を要約しなければならなくなったとき、モデルがどれだけ優雅に劣化するか、です。長期タスクのためにモデルを評価するときは、本当に長いタスク、少なくとも1回はコンパクションを強いるようなタスクを目の前に置き、何が生き残るかを見てください。そのふるまいは、選び取るに値する性質になりつつあります。

長い作業を、継ぎ目がきれいな場所に落ちるように構成しましょう。コンパクションを学習したモデルでも、書きかけのサブタスクをまたぐより、終わったサブタスクをまたぐほうがうまくコンパクションできます。学習があらゆる場所で追いつくまでは、自然なチェックポイント、つまり通過したテスト、コミットされた変更、閉じられたサブタスクが、コンパクションが発火しそうな場所と揃うように作業を形づくるだけで、その恩恵のほとんどをタダで手に入れられます。それはいずれにせよ良いハーネス設計であり、まさに学習済みのモデルが見込むよう学びつつある構造なのです。

立場

コンテキストウィンドウのサイズは、ハーネスのアーキテクチャを規定する制約であることをやめます。この2年、設計の議論はトークンの予算から始まってきました。どれだけ収まるか、何を追い出すか、いつ要約するか、です。その枠組みは、モデルを固定された器として、コンテキストを慎重に注ぐ資源として扱います。CompactionRLの方向は、その器を溶かします。モデルが自らの圧縮を管理するよう学習されると、ウィンドウはあなたが対抗して設計する硬い壁であることをやめ、モデルが下っていくよう教えられた緩やかな勾配になるのです。

ランタイムのツールキットが消えるわけではありません。context editing、memory tool、そして手動の/compactは、コンテキスト管理のうち本当にあなたのものである部分、つまりどの事実が正典なのか、どのファイルが真実の源なのか、タスクが実際には何なのか、を扱うための正しい制御手段として残ります。この移行は、完全な自動化よりも狭く、そしてより興味深いものです。コンテキスト管理の機械的な半分、すなわち要約して再開する配管をモデルの中へ移し、編集的な半分、すなわち何が重要かを決めることをあなたの手元に残します。コンテキストエンジニアリングは、モデルが担うものと、あなたが依然として所有するものへと二分され、その両者の境界こそが、良いハーネス設計が息づく新しい場所なのです。

その兆しは、すでにCompactionRLの論文の中にあります。コンパクションは、コーディングと推論のための報酬信号の隣に、フロンティアモデルの学習パイプラインの中で場所を勝ち取りました。学習ループに到達した能力が、そこから去ることはたいていありません。次の1年を制するオペレーターは、コンパクションを生き延びるべき偶然として扱うのをやめ、設計すべき契約として扱い始める人たちです。

要点

• コンパクションは推論時から学習時へと移りつつあります。 CompactionRL、Memory-R1、MemActは、それぞれ独立に強化学習を用いて、コンテキスト管理を外側のラッパーではなく学習されたふるまいにしています。¹⁶⁷
• ランタイムのツールは現在の答えであって、最終的な答えではありません。 /compact、自動コンパクション、context editing、memory toolは、圧縮を見込むよう学習されていないモデルの周りでコンテキストを管理します。³⁴
• 永続的なメモリと一時的なコンテキストを、意図的に切り分けましょう。 ルール、慣習、タスクの契約は、リセットを生き延びる層に置き、それ以外はすべて圧縮可能にしておくのです。³⁵
• 境界はPreCompactフックで強制しましょう。 要約してはならないという保証は、フォーカス指示の外へ、確定的なコードの中へと移すのです。⁵
• コンパクション能力を、仕様の1行として読みましょう。 候補となるモデルを、コンパクションを強いるのに十分な長さのタスクで試し、何が生き残るかを見てください。ウィンドウサイズは、もはや重要な唯一の数字ではありません。

FAQ

コンテキストのコンパクションとは何ですか？

コンパクションとは、コンテキストウィンドウの上限に近づいた会話を要約し、その要約から新しいウィンドウを初期化し直すことです。これにより、長時間動くエージェントは、生の履歴なら溢れてしまう地点を越えて続行できます。² 一字一句の履歴を、収まる圧縮された表現と引き換えにするわけです。

Claude Codeはコンテキストを自動でコンパクションしますか？

はい。自動コンパクションはデフォルトで有効になっており、コンテキストが上限に近づくと走ります。実効ウィンドウはCLAUDE_CODE_AUTO_COMPACT_WINDOWで操ることができ、DISABLE_AUTO_COMPACTで無効化したり、/compactで手動でパスを起動したりできます。その際、要約のためのフォーカス指示を任意で渡せます。⁴

CompactionRLとは何ですか？

GLMチームによる強化学習の手法で、タスクの実行と要約の生成を同時に最適化することで、長期タスクのエージェントがコンパクションと共に働けるよう学習させ、モデルがコンパクションされた軌跡から学ぶようにするものです。GLM-4.5-AirをSWE-bench Verifiedで7.0ポイント向上させ、次のGLMモデルの学習パイプラインに投入されています。¹

モデルに自分自身のコンテキストを管理するよう学習させることはできますか？

それこそ、最近の研究が示していることです。Memory-R1は明示的なメモリ操作を強化学習で学習させ、MemActはcontext editingをポリシーの行動として扱い、CompactionRLは軌跡のコンパクションを直接学習させます。この3つはいずれも、コンテキスト管理をランタイムの付け足しではなく、モデルに内在するものにしています。¹⁶⁷

モデルにコンパクションを学習させれば、コンテキストウィンドウは無関係になりますか？

いいえ。ただし、その数字の意味は変わります。より大きなウィンドウは依然として役立ちますが、うまくコンパクションするよう学習されたモデルは、デプロイ時になって初めてコンパクションに出会うモデルよりも、どんなウィンドウの中でも遠くまで行けます。学習されたコンパクション能力が、生のウィンドウサイズと並ぶ第2の軸になるのです。

エージェントのコンテキストのコンパクションについて、今何をすべきですか？

コンパクションの継ぎ目を、発見するのではなく設計しましょう。何を永続的なメモリに置き、何を一時的なコンテキストに置くかを決め、その境界をPreCompactフックで守り、コンパクションが終わったサブタスクをまたいで落ちるように長いタスクを構成し、そして新しいモデルを、要約を強いるのに十分な長さのタスクで評価するのです。⁵

出典