何が起きたか
UC BerkeleyのBAIRが、LLMエージェントの長時間タスクを効率化する枠組み「ABBEL」を提案しました（arXiv:2512.20111, cs.CL）。数百〜数千ステップに及ぶタスクでは、対話履歴をすべてコンテキストに保持し続けることが非現実的になります。かといってモデルに自己要約（コンテキスト圧縮／compaction）をさせると、簡潔で解釈しやすい文脈は得られる一方、性能が明確に落ちる——特に協働コード生成のように良質な学習データが乏しい領域で顕著、という課題がありました。
ABBELの核心は、要約を「信念状態」として扱う点にあります。逐次ベイズ推定に着想を得て、新情報が入るたびにモデルへ信念の更新を促し、行動選択は「現在の事後信念」だけを条件に行います。全履歴の代わりに、この自然言語の信念状態が作業コンテキストになります。
なぜ重要か
単に要約させるだけでは、モデルは「タスク遂行」と「良い要約作成」を同時に学ぶことになり、学習問題が複雑化します。ABBELは「良い信念とは何か」をヒューリスティクスで報酬化する補助的なRLタスク（belief grading）を導入し、信念の中身を直接監督します。著者らは、現在のLLM自身をエンコーダ兼デコーダとみなし、「その信念から直近の観測をどれだけ再構成できるか」で採点する、オートエンコーダ着想の汎用採点関数を提案しました。コーディングなら「信念は短いほど良いが、git diffを再構成できるほど良い」という両者のバランスが良い信念、というわけです。
具体的な成果
Sweet-RL由来の協働コーディング環境CollabBench（エージェントが質問で要件を明確化し、隠れたユニットテストで採点される関数を提出）で、汎用の再構成ベース採点を用いたABBELは、フルコンテキスト型との性能差を約50%縮め、採点なしで要約学習する場合より50%少ないステップで学習しました。数値では、Full Contextのテスト合格率0.52・成功率0.39・ピークトークン約1,408に対し、ABBEL-rec-BGは0.48・0.36・約601（学習ステップは半分の50）。メモリ（ピークトークン長）を大きく削減しています。
Wordle風の「Combination Lock」（最大16手）では、履歴の統計量を計算し信念から再構成できるか検証する、ドメイン知識を活かした採点を使うと、フルコンテキスト型を上回る学習効率も示されました。MEM1由来の多目的QAでは、Peak Belief length Penaltyがほぼ性能を落とさずメモリを削減——推論長へのペナルティで見られがちな劣化とは対照的です。
現場との接点
この研究は実運用の悩みと直結しています。Cursorのcomposer 2.5は学習時にcompactionを使い性能を高め、効率的なアテンションを使うGrandcodeですら文脈要約が必要でした。一方でCursorのようなモデルサーバは、タスクの途中でのcompactionを避けるよう推奨し続けています。ABBELは「要約は性能を落とす」という通念に、監督の仕方次第で差を半減できる、という反証を提示します。
なお著者らは、線形アテンションと全アテンションを交互配置する新世代モデル（gpt-oss、DeepSeekv4）では、アテンションのFLOP削減が効き、50%削減に至るトークン数がむしろ大きくなる点にも触れています。コンテキスト圧縮・剪定・外部メモリなど他手法は競合ではなく補完的だとしています。
出典: BAIR (Berkeley)
💼 事業会社視点：これは自社にどう効くか
受託開発・SaaS・社内AIエージェントを運用する事業会社にとって、これは「長時間タスクのコスト構造」を変えうる話です。エージェントに大量のツール往復をさせるプロダクトでは、コンテキスト長がそのまま推論コストとレイテンシに跳ね返ります。ABBELの示唆は「要約=性能劣化」ではなく「監督次第で差は半減できる」こと。ピークトークンを約1,408から約601へ落としつつ合格率を0.52→0.48に留めた事例は、コード生成SaaSやAIカスタマーサポートで、精度をほぼ保ったまま原価を削る余地があることを意味します。
事業責任者が今すべきは3点です。第一に、自社エージェントの「途中要約」を精度実測で評価する体制を作ること（Cursorが途中compactionを非推奨とする通り、無監督の要約は危険）。第二に、コスト評価にトークン総量だけでなく「ピークコンテキスト長」を指標として加えること。第三に、社内タスクにはgit diffや業務KPIなどドメイン固有の再構成基準を持たせる余地がある点を、R&Dの検討テーマに載せることです。