Agentが複雑なソフトウェアエンジニアリングタスクを処理する際、往々にして一種のジレンマに陥ります：対話履歴が増えるにつれて、計算コストが爆発的に増加し、応答遅延が線形に増加し、さらにモデルが過去の無関係な誤った情報に干渉され、推論能力が著しく低下します。この現象は「コンテキスト膨張」（Context Bloat）と呼ばれます。
論文は重要な洞察を提案しています：既存の解決策はほとんどが受動的な外部要約メカニズムに依存しており、Agent自身がいつ圧縮し、何を圧縮するかを制御できません。Agentが生物のように、自らの「記憶」を能動的に管理できるようにすることはできないでしょうか？
粘菌の採餌から得たインスピレーション
論文は、多頭粘菌（Physarum polycephalum）という粘菌からインスピレーションを得ました。この生物は環境を探索する際、行き止まりから物理的に戻り、同時に化学的なマーカーを残して重複探索を避けます。生物システムは迷路をナビゲートする際の筋肉運動の完全な記録を保持しません。彼らが保持するのは「学習した地図」だけです。
同様に、コードベースを探索するAgentは、10分前に実行した50行のls -Rコマンドの出力を覚えておく必要はありません。設定ファイルが/srcディレクトリにないという結論だけを覚えておけば十分です。
この類比に基づき、論文はFocus Agentアーキテクチャを提案しています。このアーキテクチャは2つのコアプリミティブを導入します：start_focusとcomplete_focus。重要な点は、Agentがこれらのツールをいつ呼び出すかについて完全な自主権を持っていることです——外部のタイマーやヒューリスティックなルールによって強制的に圧縮されることがありません。
Focusサイクルの4つの段階
Focusアーキテクチャのワークフローは4つの段階で構成されています：
(1) フォーカスの開始：Agentが調査している内容を宣言します（例：「データベース接続のデバッグ」）。これは対話履歴にチェックポイントをマークします。
(2) 探索：Agentは標準ツール（読み取り、編集、実行）を使用して作業を実行します。
(3) 統合：Agentが自然にサブタスクを完了したか、行き止まりに遭遇した場合、complete_focusを呼び出すことを決定し、何を試みたか、何を学んだか（事実、ファイルパス、バグ）、結果是什么かを含む要約を生成します。
(4) 引き戻し：システムは要約をコンテキストの上部にある永続的な「知識」ブロックに追加し、チェックポイントと現在のステップの間のすべてのメッセージを削除します。
[図2：コンテキスト成長の概念的なギザギザ模式] 論文は、Focus（青）が周期的な圧縮（下降）を示すのに対し、Baseline（赤）が単調に成長することを示しています。激しいプロンプトを使用することで、Focusは10〜15回のツール呼び出しごとに圧縮し、学習成果を永続的な知識ブロックに保持的同时にコンテキスト膨張を防ぎます。
この設計は、コンテキストを単調に増加するログから「ギザギザ」モードに変換します——探索期間中は増加し、統合期間中は収縮します。モデルはタスク構造に基づいてこのサイクルを制御し、任意のステップ数のカウントではありません。
実験設定と最適化スキャフォールド
論文はSWE-bench Liteベンチマーク上でFocusアーキテクチャを評価しています。これは、ソフトウェアエンジニアリングAgentが実際のGitHubの問題を解決するためのベンチマークです。論文はclaude-haiku-4-5-20251001モデルを使用し、N=5のコンテキスト集中型インスタンスで管理されたA/B比較実験を行っています。
Anthropicが報告するSWE-benchのベストプラクティスに従い、論文は最小限の2ツールスキャフォールドを実装しています：永続的なBash（状態を持つシェルセッション、作業ディレクトリと環境は呼び出し間で永続化）と文字列置換エディタ（正確な文字列置換によるターゲットファイルの編集、エラーの多い全ファイル書き換えを回避）。
初期実験では、受動的なFocusプロンプトは各タスクにつき1〜2回の圧縮しか生成せず、トークン節約はわずか6%でした。論文はFocusプロンプトをより指示的になるように改訂しました：ワークフローを強制し、「あらゆる探索の前に常にstart_focusを呼び出し...10〜15回のツール呼び出し後に常にcomplete_focusを呼び出す」ことを要求；15回のツール呼び出し後に圧縮がない場合、システムはリマインダーを注入；4〜6のフォーカス段階（探索→理解→実装→検証）の使用を明確に指示。
[表I：SWE-bench Lite上のA/B比較（Haiku 4.5、N=5困難インスタンス）] 論文は、BaselineとFocusを、タスク成功率、総トークン消費量、平均タスクあたりトークン、平均圧縮回数、平均破棄メッセージ数などの指標で比較しています。
核心発見：22.7%の節約と同等の正確率
実験結果は、Focusが総トークンを22.7%削減（14.9M→11.5M）し、同時にBaselineと同じ正確率（3/5 = 60%）を維持したことを示しています。これは論文の初期実験とは対照的です——当時、受動的なプロンプトは正確率の低下を示しました。重要な違いは、激しいプロンプトが頻繁で構造化された圧縮を強制することです（タスクあたり6.0回 vs 以前の2.0回）、古い探索ログによってコンテキストが汚染されるのを防ぎます。
[表II：インスタンスごとの結果：トークン節約 vs 正確率] 論文は5つのインスタンスの詳細な比較を示しています。matplotlib-26020（-57%）、seaborn-2848（-52%）、pylint-7080（+110%）、pytest-7490（-18%）、sympy-21171（-57%）のトークン変化と圧縮回数を含みます。
Focusは5つのインスタンスのうち4つでトークンを削減し、節約範囲は18%から57%です。最も強い節約は、大量の探索を必要とするインスタンスで発生しました：matplotlib-26020（-57%、4.0M→1.7M）、seaborn-2848（-52%、3.4M→1.6M）、sympy-21171（-57%、1.6M→0.7M）。
[図1：トークン消費量（Haiku 4.5、N=5困難インスタンス）] 論文は5つの困難インスタンスの総トークン消費量の比較を示しています。Focusは激しいモデル制御圧縮により使用量を22.7%削減し、同時に同等の正確率を維持しています。
ケース分析：最大節約と圧縮オーバーヘッド
matplotlib-26020では、両方のAgentがテストスイートを通過しましたが、Focusは57%のトークン節約を実現しました（4.0M→1.7M）。Focusは71回のLLM呼び出し中5回圧縮したのに対し、Baselineは102回の呼び出しを行いましたが圧縮は行いませんでした。節約は、Focusが探索段階を効率的に要約することから来ています——関連ファイルを特定し、バグを理解した後、そのコンテキストを圧縮し、直接実装に移行します。
しかし、pylint-7080では、FocusはBaselineより110%多くのトークンを使用しました（4.3M vs 2.1M）、両方のAgentがテストスイートを通過したにもかかわらずです。分析では、Focusが136回のLLM呼び出しを行ったのに対し、Baselineは63回で、8回の圧縮で80のメッセージを破棄したことが示されています。この問題は多くの試行錯誤を必要とし、Focusの圧縮は有用なコンテキストを時折破棄し、再探索を強制しました。これは、圧縮が普遍的に有益ではないことを示しています：反復的な微調整を必要とするタスクは、積極的なコンテキストの修剪によって損なわれる可能性があります。
圧縮の認知税と限界
能動的な圧縮は「認知税」を導入します——要約を生成するのにかかるトークンと、フォーカス段階を管理するオーバーヘッドです。この税があるにもかかわらず、Focusは実験で22.7%の純粋なトークン節約を実現しました。この税はタスクのライフサイクル内で償却されます：各圧縮は数百のトークンを費やしますが、古い履歴を再処理しないことで数千のトークンを節約します。
論文はいくつかの限界を指摘しています：サンプルサイズはN=5の困難インスタンスのみで、完全なSWE-bench Liteベンチマーク（N=300）で検証する必要があります；タスク依存性の利益——Focusは探索集中型タスクで50〜57%の節約を示しましたが、1つの反復微調整タスクでは110%のオーバーヘッドを示しました；Claude Haiku 4.5のみを評価し、他のモデルの性能は不明です；結果は最適化された2ツールスキャフォールドに依存しています。
最後に
論文は、激しい、モデル制御のコンテキスト圧縮が、タスクの正確率を犠牲にすることなく、顕著なトークン節約を実現できることを証明しました。現在のLLMは内在するコスト意識を欠いているようです——それらは自然にトークン効率を最適化せず、圧縮をワークフローの第一級市民にするスキャフォールドが必要です。
将来の作業方向には、完全なSWE-bench（N=300）での検証によるタスクタイプ依存性の特徴付け；明示的なプロンプトなしで圧縮ヒューリスティックを内化するための微調整または強化学習方法；自由形式の要約ではなく、特定の成果物（テスト出力、差分）を保持するための構造化圧縮；一般化を評価するためのクロスモデル評価（GPT-4、Gemini、オープンソースモデル）が含まれます。
コンテキストウィンドウが拡大し、Agentタスクがより複雑になるにつれて、能動的な圧縮は、自己回帰推論に固有の二次コスト増加を管理する上でますます価値のあるものになるでしょう。
論文タイトル：Active Context Compression: Autonomous Memory Management in LLM Agents