ハーネスの4つの構成要素
エージェントハーネスの構成要素を、より具体的に説明します。
LangChainが公開しているDeepAgentsは、エージェントハーネスの機能をプリセットしたオープンソースのSDKです。計画の立案、ファイルシステムの活用、サブエージェントの生成、コンテキストの圧縮といった機能が標準で組み込まれています。そのため、開発者はエージェント固有のロジック定義に専念できます。
DeepAgentsでは、以下の4つの要素を中核として定義しています。
計画（Planning）
複雑なタスクに対して、即座に作業を開始するのではなく、まず計画を立てる機能です。
DeepAgentsでは、TODOリストの作成・参照ツール（write_todos）をエージェントに提供しています。Claude Codeを利用した際、複雑な指示に対してまずTODOリストを書き出す挙動を目にしたことがあるかもしれません。
エージェントはタスクを小さなステップに分解し、1ずつ進めます。計画を立てることで、実行が長時間に及んでも「現在どの地点にいて、次に何をすべきか」というコンテキストを見失いにくくなります。OSにおけるプロセスの生成とスケジューリングに近い役割です。
ファイルシステム（Filesystem）
コンテキストウィンドウに収まりきらない情報の「退避先」として機能します。
ファイルの読み書き（read_file,write_file,edit_file）、検索（glob,grep）、一覧取得（ls）といったツールをエージェントに提供し、調査結果や中間成果物をファイルに書き出すことでコンテキストを節約します。
必要なタイミングで情報を再ロードできるため、RAMに収まらないデータをディスクに退避する「スワップ領域」に近い概念といえます。
サブエージェント（Sub-agents）
1つのエージェントでは処理しきれない作業を、専門化された子エージェントに委譲する仕組みです。
子エージェントは独立したコンテキストウィンドウを持ちます。そのため、メインのエージェントのコンテキストを消費することなく、調査や分析を平行して進められます。子エージェントによる処理結果のみをメイン側に返すことで、全体の情報量を圧縮する効果も得られます。
これはOSにおける「fork」による子プロセスの生成に相当します。
コンテキスト管理（Context Engineering）
長時間の対話によるコンテキストの膨張を自動的に抑制します。
会話の長さ（トークン数）を継続的に監視し、閾値を超えた場合に古いやり取りを自動で要約文へと置き換えます。また、サイズの大きなツール出力はファイルに保存し、プレビューのみをコンテキストに返します。数百回におよぶツール呼び出しを経てもコンテキストウィンドウが溢れずに動作を継続できるのは、この機能があるためです。
OSのメモリ管理におけるキャッシュの破棄やスワップアウトに近い役割を果たしています。
DeepAgentsのコンテキスト管理を掘り下げる
4つの構成要素の中でも、コンテキスト管理はエージェントハーネスの中核です。LangChainのブログ記事をもとに、DeepAgentsが実装するコンテキスト管理を掘り下げます。
3段階のコンテキスト圧縮
DeepAgentsでは、実行タイミングの異なる3つの圧縮技術を実装しています。
ファイル読み込みやAPI呼び出しの応答が20,000トークンを超える場合、そのレスポンスをファイルシステムへ退避させます。コンテキストには、ファイルパスへの参照と先頭10行程度のプレビューのみを残します。エージェントが退避した情報が必要と判断したタイミングで、改めてそのファイルを読み直す設計です。この処理はツール実行のたびに判定されます。
2段階目、「大きなツール入力の退避」です。ファイルの書き込みや編集を行うと、ファイル内容の全体を含むツール呼び出しが、エージェントのコンテキストに残ります。しかし、その内容はすでにファイルシステムに保存されているため、履歴として保持し続けるのは冗長です。セッションのコンテキストがモデルウィンドウの85％を超えた際、古いツール呼び出し履歴を切り詰め、ディスク上のファイルへのポインタに置き換えます。
最後の3段階目は、「会話の要約」です。退避処理だけでは十分な空き容量を確保できない場合に実行されます。LLMが会話の構造化された要約を生成し、セッションの目的、成果物、ネクストアクションなどを含む要約文で履歴を書き換えます。元の会話メッセージはファイルシステムに書き出されるため、要約だけでは情報が不足する場合はファイル検索を通じて詳細情報を復元することが可能です。
なぜ段階的なのか
これら3つの段階は、それぞれ処理コストが異なります。第1段階はサイズチェックのみの軽量な処理、第2段階はコンテキスト監視に伴う中程度の処理、第3段階はLLMによる要約生成を伴う重い処理です。通常は負荷の低い処理で対応し、必要に応じて強力な圧縮を行うという、効率的な設計になっています。
OSのメモリ管理に例えると、第1段階・第2段階はデータをディスクにへ移す「スワップアウト」にあたり、第3段階は退避に加えてデータそのものを圧縮する処理にあたります。段階が上がるほど処理は重くなりますが、より多くの空き容量を確保できます。
要約の課題「目標のドリフト」
要約は有効な手段ですが「目標のドリフト（Goal Drift）」と呼ばれる課題も存在します。これは、要約プロセスを経てエージェントがユーザーの本来の意図を見失い、不必要な確認を求めたり、タスク完了を誤認したりする現象です。
DeepAgentsチームは、この問題に対し、圧縮の発動閾値を意図的に低く設定するアプローチを採用しています。例えば、ウィンドウの85％ではなく10〜20％で要約を発動させることで、1回の実行あたりの要約回数を増やし、問題を早期に顕在化させます。
また、テスト手法として「needle-in-the-haystack」テストが紹介されています。会話の初期段階で特定の事実を伝えておき、強制的に要約を発生させた後、エージェントがその事実を想起できるかを検証します。要約後のアクティブなコンテキストから情報が消えているため、エージェントはファイルシステムから情報を復元する必要があります。これにより、要約と復元の連携が正しく機能しているかを評価できるのです。
