Context Management for Deep Agents｜深層エージェントにおけるコンテキスト管理 | AIニュース最前線

*チェスター・カームとメイソン・ドーハーティによる* AI エージェントの処理可能なタスク長さが[継続的に拡大している](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/?ref=blog.langchain.com)中、[コンテキストローテーション](https://research.trychroma.com/context-rot?ref=blog.langchain.com)を防ぎ、LLM の有限なメモリ制約を管理するために、効果的なコンテキスト管理が極めて重要になっています。 [Deep Agents SDK](https://docs.langchain.com/oss/python/deepagents/overview?ref=blog.langchain.com)は、LangChain が提供するオープンソースで、必要な機能がすべて備わった[エージェント・ハネス](https://blog.langchain.com/agent-frameworks-runtimes-and-harnesses-oh-my/)です。これは、計画を立てたり、サブエージェントを起動したり、ファイルシステムと連携して複雑で長時間実行されるタスクを実行する能力を持つエージェントを構築するための容易な道筋を提供します。これらの種類のタスクは一般的にモデルのコンテキストウィンドウを超えるため、この SDK はコンテキスト圧縮を促進するさまざまな機能を実装しています。 コンテキスト圧縮とは、タスク完了に関連する詳細情報を保持しつつ、エージェントの作業メモリ内の情報量を削減する技術を指します。これには、過去の対話の要約、古くなった情報のフィルタリング、あるいは何を保持し何を破棄するかを戦略的に決定することが含まれます。 Deep Agents は、エージェントがファイルのリスト表示、読み取り、書き込み、検索、パターンマッチング、およびファイル実行などの操作を実行できるようにする [ファイルシステム抽象化](https://docs.langchain.com/oss/python/deepagents/middleware?ref=blog.langchain.com#filesystem-middleware) を実装しています。エージェントは必要に応じてファイルシステムを使用してオフロードされたコンテンツを検索・取得します。 Deep Agents は、異なる頻度でトリガーされる 3 つの主要な圧縮技術を実装しています: - 大規模なツール結果のオフロード: 大規模なツールの応答が発生するたびに、それらをファイルシステムにオフロードします。 - 大規模なツール入力のオフロード: コンテキストサイズが閾値を超えると、ツール呼び出しからの古い書き込み/編集引数をファイルシステムにオフロードします。 - 要約: コンテキストサイズが閾値を超え、さらにオフロード可能なコンテキストが存在しない場合、メッセージ履歴を圧縮するために要約ステップを実行します。 コンテキスト制限を管理するため、Deep Agents SDK はモデルのコンテキストウィンドウサイズの閾値分数でこれらの圧縮ステップをトリガーします。(内部では、特定のモデルに対するトークン閾値にアクセスするために LangChain の [モデルプロファイル](https://docs.langchain.com/oss/python/langchain/models?ref=blog.langchain.com#model-profiles) を使用しています。) ## ツール結果のオフローディング ツール呼び出しからの応答（例：大規模ファイルの読み取りや API 呼び出しの結果）は、モデルのコンテキストウィンドウを超えることがあります。Deep Agents は、20,000 トークンを超えるツール応答を検出すると、その応答をファイルシステムにオフロードし、代わりにファイルパス参照と最初の 10 行のプレビューで置換します。その後、エージェントは必要に応じて内容を再読したり検索したりできます。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cba9fe649e3ebd9d134fdd_Screenshot-2026-01-26-at-10.18.38---AM.png) ## ツール入力のオフローディング ファイルの書き込みおよび編集操作は、エージェントの会話履歴に完全なファイル内容を含むツール呼び出しを残します。このコンテンツはすでにファイルシステムに永続化されているため、多くの場合冗長です。セッションコンテキストがモデルの利用可能なウィンドウの 85% を超えると、Deep Agents は古いツール呼び出しを切り捨て、ディスク上のファイルへのポインタで置換して、アクティブなコンテキストのサイズを削減します。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cba9fe649e3ebd9d134fda_Screenshot-2026-01-23-at-2.25.16---PM.png) ## 要約 オフローディングではもはや十分なスペースが得られない場合、Deep Agents は要約に切り替えます。このプロセスには 2 つの構成要素があります： - コンテキスト内サマリー：LLM が会話のセッション意図、作成されたアーティファクト、および次のステップを含む構造化された要約を生成し、エージェントの作業メモリ内の完全な会話履歴を置き換えます。（Deep Agents 要約プロンプトを参照） - ファイルシステム保存：完全な元の会話メッセージは、正真正銘の記録としてファイルシステムに書き込まれます。 この二重のアプローチにより、エージェントはサマリーを通じて目標と進捗の認識を維持しつつ、必要に応じて特定の詳細を検索して回復する能力（ファイルシステム検索経由）も保持されます。モデルが read_file ツールを使用して以前オフロードされたメッセージを取得している例については、[こちらのトレース](https://smith.langchain.com/public/0e3f59e0-7278-4a7a-80fd-99d4fb7fa912/r?ref=blog.langchain.com) をご覧ください。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cba9fe649e3ebd9d134fcd_Screenshot.png) ## 実践における様子 上記の手法は文脈管理のための機械装置を提供しますが、実際に機能しているかどうかをどう確認すればよいのでしょうか？[terminal-bench](https://www.tbench.ai/?ref=blog.langchain.com) などのベンチマークで捉えられた実世界のタスクでの実行では、文脈圧縮が断続的にトリガーされる可能性があり、その影響を単独で特定することが困難です。 ハネスの個々の機能のシグナルを高めるために、ベンチマークデータセット上でより積極的に関与させることが有用であることがわかりました。例えば、利用可能なコンテキストウィンドウの 10〜20% で要約トリガーを発動すると全体の性能が最適化されない可能性がありますが、それによって要約イベントが大幅に増加します。これにより、異なる構成（例：実装のバリエーション）を比較することが可能になります。例えば、エージェントに頻繁な要約を強制することで、セッション意図と次のステップのために専用のフィールドを追加した DeepAgents の要約プロンプトに対する単純な [変更](https://github.com/langchain-ai/langchain/pull/34754?ref=blog.langchain.com) がパフォーマンス向上にどのように寄与するかを特定できます。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cba9fd649e3ebd9d134faa_Screenshot-2026-01-23-at-3.03.57---PM-1.png) 図：terminal-bench-2 における Claude Sonnet 4.5 のサンプル実行時のトークン使用量の推移（灰色の線はすべての実行、彩色された線は特定の 2 つの例を強調表示）。緑色の線は、要約イベントによって会話履歴が圧縮されるターン 20 付近で劇的なトークンの減少を示しています。オレンジ色の線は、大きなファイル書き込みツール呼び出しがコンテキストから除外されるターン 40 付近でのより小さな削減を示しています。Deep Agents のデフォルトである 85% ではなく、コンテキストウィンドウの 25% で圧縮トリガーを発動させることで、研究対象となるイベントをより多く生成できます。 ## ターゲット型評価 Deep Agents SDK は、個々のコンテキスト管理メカニズムを分離して検証するために設計された一連のターゲット型評価（evals）を維持しています。これらは意図的に小規模なテストであり、特定の失敗モードを明白かつデバッグ可能にするものです。 これらの [evals](https://www.langchain.com/resources/llm-evals) の目的は、広範なタスク解決能力を測定することではなく、エージェントのハネス（harness）が特定のタスクの実行を妨げないことを保証することです。例えば： - 要約（summarization）はエージェントの目標を維持したか？一部の評価では意図的にタスク実行中に要約トリガーを発生させ、その後エージェントが継続して動作するかを確認します。これにより、要約がエージェントの状態だけでなくその軌跡も維持していることが保証されます。 - エージェントは要約によって失われた情報を回復できるか？ここでは会話の初期段階に「干し草の中の針（needle-in-the-haystack）」と呼ばれる事実を埋め込み、要約イベントを強制的に発生させた後、タスク完了のためにその事実を後で想起することを要求します。要約後のアクティブなコンテキストにはこの事実は存在せず、ファイルシステム検索を通じて回復する必要があります。 これらのターゲット型評価は、コンテキスト管理のための統合テスト（integration tests）として機能します。これらは完全なベンチマーク実行を代替するものではなく、反復時間を大幅に短縮し、失敗の原因がエージェント全体の動作ではなく特定の圧縮メカニズムに帰属することを可能にします。 ## ガイダンス ご自身のコンテキスト圧縮戦略を評価する際には、以下の点を強調いたします： - 実際の現実世界ベンチマークから始め、個々の機能をストレステストしてください。まず代表的なタスクにハネスを実行してベースラインパフォーマンスを確立します。その後、圧縮をより積極的にトリガーするように人工的に調整します（例：コンテキストの 85% ではなく 10-20% で）。これにより、実行あたりの圧縮イベント数が増加し、個々の機能からのシグナルが強調されるため、異なるアプローチ（要約プロンプトの変異など）を比較しやすくなります。 - 回復可能性をテストしてください。コンテキスト圧縮は、重要な情報が依然としてアクセス可能である場合にのみ有用です。圧縮後もエージェントが元の目標に向かって継続できること、かつ必要に応じて特定の情報を回復できることを検証するターゲット型のテストを含めてください（例：重要な事実が要約されても後で検索しなければならない「干し草の針」シナリオなど）。 - ゴールドリフトを監視してください。最も厄介な失敗モードは、要約後にユーザーの意図を追跡できなくなるエージェントです。これは、要約後のターンで明確化を求めるためにタスクが完了してしまう、または誤ってタスク完了と宣言してしまう形で現れることがあります。意図されたタスクからのより微妙な逸脱は、要約に起因するものとして特定するのが難しい場合があります。サンプルデータセットに対して頻繁な要約を強制することで、これらの失敗を表面化できる可能性があります。 [Deep Agents](https://github.com/langchain-ai/deepagents?ref=blog.langchain.com) ハネスのすべての機能はオープンソースです。最新バージョンを試して、どの圧縮戦略があなたのユースケースに最も適しているか教えてください！

深層エージェントにおけるコンテキスト管理

背景や根拠まで確認しますか？

調べる

選ぶ

サイト