Context Management for Deep Agents｜深層エージェントのためのコンテキスト管理

![image](https://blog.langchain.com/content/images/2026/01/Screenshot-2026-01-23-at-3.03.57---PM-1.png)チェスター・カームとメイソン・ドーハーティによる AI エージェントの処理可能なタスク長が継続して拡大する中、コンテキストローテーション（context rot）を防ぎ、LLM の有限なメモリ制約を管理するために、効果的なコンテキスト管理が極めて重要になっています。 Deep Agents SDK は、LangChain が提供するオープンソースで、標準機能を含むエージェントハネスです。計画立案やサブエージェントの起動、ファイルシステムとの連携による複雑で長時間実行されるタスクの実行能力を持つエージェントを構築するための容易な道筋を提供します。これらの種類のタスクは一般的にモデルのコンテキストウィンドウを超えるため、SDK はコンテキスト圧縮を促進するさまざまな機能を実装しています。 コンテキスト圧縮とは、タスク完了に関連する詳細情報を保持しつつ、エージェントの作業メモリ内の情報量を削減する技術を指します。これには、過去の対話の要約、古くなった情報のフィルタリング、あるいは何を保持し何を破棄するかを戦略的に決定することが含まれます。 Deep Agents は、ファイルの一覧表示、読み取り、書き込み、検索、パターンマッチング、およびファイルの実行などの操作をエージェントが行えるようにするファイルシステム抽象化を実装しています。エージェントは必要に応じてファイルシステムを使用してオフロードされたコンテンツを検索・取得します。 Deep Agents は、異なる頻度でトリガーされる 3 つの主要な圧縮技術を実装しています: 大規模なツール結果のオフローディング：大規模なツールの応答が発生した際には、常にそれをファイルシステムにオフロードします。 大規模なツール入力のオフロード：コンテキストサイズしきい値を超えた場合、ツール呼び出しからの古い書き込み/編集引数をファイルシステムにオフロードします。 要約処理：コンテキストサイズがしきい値を超え、さらにオフロード可能なコンテキストが存在しない場合、メッセージ履歴を圧縮するための要約ステップを実行します。 コンテキスト制限の管理のため、Deep Agents SDK はモデルのコンテキストウィンドウサイズのしきい値比率でこれらの圧縮ステップをトリガーします。（内部では、特定のモデルに対するトークンしきい値にアクセスするために LangChain のモデルプロファイルを使用しています。） 大規模なツール結果のオフロード ツール呼び出しからの応答（例：大規模ファイルの読み取りや API 呼び出しの結果）は、モデルのコンテキストウィンドウを超える可能性があります。Deep Agents が 20,000 トークンを超えるツール応答を検出すると、その応答をファイルシステムにオフロードし、代わりにファイルパス参照と最初の 10 行のプレビューで置換します。その後、エージェントは必要に応じて内容を再読み込みまたは検索できます。 ![image](https://blog.langchain.com/content/images/2026/01/Screenshot-2026-01-26-at-10.18.38---AM.png)大規模なツール入力のオフロード ファイルの書き込みおよび編集操作は、エージェントの会話履歴に完全なファイル内容を含むツール呼び出しを残します。このコンテンツはすでにファイルシステムに永続化されているため、多くの場合冗長です。セッションコンテキストがモデルの利用可能なウィンドウの 85% を超えると、Deep Agents は古いツール呼び出しを切り捨て、ディスク上のファイルへのポインタに置き換え、アクティブなコンテキストのサイズを縮小します。 ![image](https://blog.langchain.com/content/images/2026/01/Screenshot-2026-01-23-at-2.25.16---PM.png)要約 オフローディングではもはや十分なスペースが得られない場合、Deep Agents は要約に切り替えます。このプロセスには 2 つの構成要素があります。 コンテキスト内での要約：LLM が会話の構造化された要約（セッションの意図、作成されたアーティファクト、次のステップを含む）を生成し、これによりエージェントの作業メモリ内の完全な会話履歴が置き換えられます。（Deep Agents の要約プロンプトを参照してください。） ファイルシステムの維持：完全な元の会話メッセージは、標準的な記録としてファイルシステムに書き込まれます。 この二重のアプローチにより、エージェントは要約を通じて目標と進捗の認識を維持しつつ、必要に応じて特定の詳細を検索機能で復元する能力も保持されます。以前オフロードされたメッセージを取得するために read_file ツールを使用しているモデルの例については、このトレースをご覧ください。 ![image](https://blog.langchain.com/content/images/2026/01/Screenshot.png)実践における外観 上記の手法は文脈管理のための仕組みを提供しますが、実際に機能しているかどうかをどう確認すればよいでしょうか？terminal-bench などのベンチマークで捉えられた実世界のタスクでの実行では、文脈圧縮が断続的にトリガーされるため、その影響を単独で特定することが困難です。 私たちは、ベンチマークデータセット上でこれらの機能をより積極的に活用することで、ハネスの個々の機能のシグナルを増幅させることが有用であると発見しました。例えば、利用可能なコンテキストウィンドウの 10〜20% で要約をトリガーすると全体の性能が最適化されない可能性がありますが、その分はるかに多くの要約イベントが発生します。これにより、異なる構成（実装のバリエーションなど）を比較することが可能になります。例えば、エージェントに頻繁な要約を強制することで、セッションの意図と次のステップのために専用のフィールドを追加した deepagents の要約プロンプトに対する単純な変更が、どのように性能向上につながるかを特定できます。 ![image](https://blog.langchain.com/content/images/2026/01/Screenshot-2026-01-23-at-3.03.57---PM.png)図：Claude Sonnet 4.5 のターミナルベンチマーク 2（terminal-bench-2）におけるサンプル実行時のトークン使用量の推移（灰色の線はすべての実行、色のついた線は特定の 2 つの例を強調表示）。緑色の線は、要約イベントが会話履歴を圧縮するターン 20 付近で劇的なトークンの減少を示しています。オレンジ色の線は、大きなファイル書き込みツール呼び出しがコンテキストから除外されるターン 40 付近でのより小さな削減を示しています。Deep Agents のデフォルトである 85% ではなく、コンテキストウィンドウの 25% で圧縮トリガーを発生させることで、研究対象となるイベント数を増やしています。 ターゲット評価 Deep Agents SDK は、個々のコンテキスト管理メカニズムを分離して検証するために設計された一連のターゲット評価（evals）を維持しています。これらは意図的に小規模なテストであり、特定の失敗モードを明白かつデバッグ可能にするものです。 これらの評価の目的は、広範なタスク解決能力を測定することではなく、エージェントのハッチが特定のタスクの妨げにならないことを保証することです。例えば： 要約はエージェントの目標を維持したか？一部の評価では、意図的にタスク実行中に要約トリガーを発生させ、その後エージェントが継続して動作するかを確認します。これにより、要約がエージェントの状態だけでなく、その軌道（trajectory）も維持していることを保証します。 エージェントは要約によって失われた情報を回復できるでしょうか？ここでは、会話の初期段階に「干し草の山の中の針」となる事実を埋め込み、要約イベントを強制的に発生させた後、タスクを完了するためにその事実を後で思い出させる必要があります。要約後のアクティブなコンテキストにはこの事実は存在せず、ファイルシステム検索を通じて回復する必要があります。 これらのターゲット型評価は、コンテキスト管理の統合テストとして機能します。これらは完全なベンチマーク実行を代替するものではありませんが、反復回数を大幅に削減し、失敗の原因をエージェント全体の挙動ではなく、特定の圧縮メカニズムに特定可能にします。 ガイダンス 独自のコンテキスト圧縮戦略を評価する際には、以下の点を強調します： まず実世界のベンチマークから始め、個々の機能をストレステストしてください。最初に代表的なタスクでハーンネスを実行し、ベースラインパフォーマンスを確立します。その後、より積極的に人工的に圧縮トリガーを発生させます（例えば、コンテキストの 85% ではなく 10-20% で）。これにより、各実行あたりの圧縮イベント数が増加し、個々の機能からのシグナルが強調されます。その結果、異なるアプローチ（例：要約プロンプトの変異）を比較することが容易になります。 回復性をテストしてください。コンテキスト圧縮は、重要な情報が依然としてアクセス可能である場合にのみ有用です。圧縮後もエージェントが元の目標に向かって継続できること、かつ必要に応じて特定の情報を回復できることを検証するターゲット型テストを含めてください（例：重要な事実が要約されてしまうが、後で検索しなければならない「干し草の山の中の針」シナリオなど）。 ゴールのドリフトを監視する。最も危険な失敗モードは、要約後にユーザーの意図を追跡できなくなるエージェントである。これは、要約後のターンで明確化を求めるためにタスクが完了してしまう、あるいは誤ってタスク完了と宣言してしまう形で現れることがある。意図されたタスクからのより微妙な逸脱は、要約に起因するものとして特定するのが難しい場合がある。サンプルデータセットに対して頻繁な要約を強制することで、これらの失敗を表面化できる可能性がある。 Deep Agents ハーネスのすべての機能はオープンソースである。最新バージョンを試していただき、あなたのユースケースにおいてどの圧縮戦略が最も効果的か教えてほしい！

深層エージェントのためのコンテキスト管理

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

関連記事

調べる

選ぶ

サイト