【ITニュース解説】จัด Context ใน Multi-Agent Harness ให้ถูกวิธี, บทเรียนจาก Forked Subagents ของ LangChain

AIが複数のタスクを協力してこなす「マルチエージェントシステム」を構築する際、それぞれのAIエージェント、特に主となるエージェント（通称「親エージェント」または「スーパーバイザー」）から指示を受けて特定の専門的な作業を行う「サブエージェント」に対して、どの程度の情報（「コンテキスト」と呼ぶ。これは、状況や背景情報、これまでの会話履歴など、AIが判断を下すために必要なあらゆる情報を指す）を与えるべきかという問題は、システムの効率やコストに大きく影響する。しかし、多くの開発チームがこの点を深く考慮せずにシステムを構築し、予期せぬ無駄や非効率に直面することがある。

従来のマルチエージェントシステムでは、「supervisor-subagent（親・子エージェント）」という一般的なアーキテクチャが採用されてきた。この方式では、親エージェントが全体の計画を立て、個々の専門的な作業をサブエージェントに割り振る。サブエージェントは指示された作業を実行し、結果だけを親エージェントに報告する。この際、サブエージェントは通常、親エージェントからの指示のみを受け取り、それまでの親エージェントの思考プロセスや、親エージェントが既に収集した情報、つまりコンテキストはほとんど与えられない。サブエージェントはあたかも白紙の状態から作業を開始するようなものだ。

この「コンテキストがない状態」が引き起こす問題は深刻である。例えば、親エージェントがバグの原因を特定するために複数のファイルを詳細に分析した後、サブエージェントにそのバグの修正とテストコードの作成を指示したとしよう。サブエージェントは、親エージェントが既に読み込んだ同じファイルを、バグに関するコンテキストがないため最初から読み直し、分析し直さなければならない。これは、時間とリソースの無駄であり、AIの処理にかかるコスト（「トークン」、AIが情報を処理する際の最小単位で、コストに直結する）の増大を招く。多くのチームが、簡単な作業にもかかわらずAIの利用コストが膨大になる原因を見つけられないのは、サブエージェントが無駄な重複作業をしていることに気づいていないからである。

この問題を解決するために、LangChainチームが開発したオープンソースライブラリ「deepagents」の最新バージョンでは、「コンテキストモード」という新しい機能が導入された。これには主に二つのモードがある。

一つは「Isolatedモード」である。これは従来のサブエージェントの挙動と同じで、サブエージェントは完全に独立した新しいコンテキストウィンドウ（作業空間）で作業を開始し、親エージェントからの指示だけを受け取る。このモードは、サブエージェントに完全に偏りのない、クリーンな視点で作業を行わせたい場合に特に適している。

もう一つは「Forkモード」である。これは新しいアプローチで、サブエージェントは親エージェントの会話履歴を含む全てのコンテキストを「引き継ぐ」。これはまるで、親エージェントの会話スレッドが途中で分岐（フォーク）し、その続きからサブエージェントが会話を始めるようなイメージだ。サブエージェントは作業完了後、最終的な結果を親エージェントに返す。このForkモードの最大の利点は、コストと時間の節約にある。親エージェントが既に収集した情報をサブエージェントが再収集する必要がなくなるため、AIの処理を高速化し、コストを削減する「プロンプトキャッシング」（以前に実行したプロンプトとその応答を記憶しておき、同じプロンプトが来た際に再利用する技術）が最大限に機能する。

この二つのモードをいつどのように使い分けるかが、効率的なマルチエージェントシステム設計の鍵となる。LangChainチームはサブエージェントの役割を大きく二つに分類し、それぞれの役割に応じたモード選択の指針を示している。

まず「Worker（作業の継続者）」と呼ばれる役割のサブエージェントだ。これは、親エージェントが既に何らかのコンテキストを収集し、ある程度の意思決定を行った上で、その作業の続きを任せる場合を指す。例えば、親エージェントがバグを特定した後、その修正とテストの作成をサブエージェントに指示するようなケースだ。この場合、親エージェントが既に把握している情報から作業を継続するため、Forkモードが圧倒的に優れている。もしここでIsolatedモードを使うと、サブエージェントは親エージェントが既に行った調査をすべてやり直さなければならなくなる。

次に「Verifier（独立した検証者）」と呼ばれる役割のサブエージェントがある。これは、既に完了した作業や提案された解決策を、公平で客観的な視点から評価・検証する場合を指す。この場合、サブエージェントが親エージェントの思考プロセスや期待を知ってしまうと、その情報に引きずられてしまい、公平な判断ができない可能性がある。したがって、VerifierにはIsolatedモードが適している。作業内容と評価基準だけを与え、親エージェントが過去にどのような議論や決定を行ったかは伝えないことで、サブエージェントは純粋に提示された内容の検証に集中できる。

これらの原則は、具体的なサブエージェントの種類にも当てはまる。例えば、親エージェントから短い質問を受け取り、それに対する調査結果を要約して返す「Researcher（研究者）」タイプのサブエージェントには、Isolatedモードが適している。質問自体が独立しており、親エージェントの過去の会話履歴全体が不要であるためだ。特に複数のResearcherを並行して実行する場合、それぞれが親エージェントの履歴全体をコピーするのは無駄が多い。

一方、会話履歴の中から記憶すべき重要な情報（例えば、ユーザーの好みや特定の事実など）を抽出して、後で参照できるように保存する「Memory agent（記憶エージェント）」タイプには、Forkモードが適している。この場合、会話履歴そのものがMemory agentが分析すべき「素材」であるため、コンテキスト全体を引き継ぐ必要があるのだ。

このコンテキスト管理のアプローチは、単なる技術的な選択に留まらず、組織における情報の共有方法にも通じる考え方と言える。上司が部下に、過去の議論の全てを記した資料を渡すか、それとも要点だけをブリーフィングして独自の判断を促すか、という状況に似ている。どちらの方法も正しい場合があり、重要なのは状況に応じて適切に使い分けることだ。

多くのシステム開発現場では、サブエージェントを生成する際に、デフォルト設定であるIsolatedモードが使われがちである。そのため、不必要なトークン消費や時間の浪費が発生しているケースは少なくない。もし現在構築中のマルチエージェントシステムで、サブエージェントが親エージェントが行ったばかりの作業を繰り返しているように感じるなら、そのサブエージェントのコンテキストモードをForkに切り替えることを検討すべきだろう。これだけで、システムの運用コストが大幅に削減される可能性がある。

ただし、Forkモードも万能ではない。全てのサブエージェントに親エージェントのコンテキスト全体を無制限にコピーすることは、不要な情報伝達によるコスト増加を招く可能性がある。それ以上に重要なのは、サブエージェントが親エージェントの思考や判断に強く影響され、結果として多様な視点や独立した発想が失われてしまう危険性があることだ。サブエージェントを導入する本来の目的の一つは、異なる専門性や視点を持つAIにタスクを分担させることで、より包括的でロバストなソリューションを得ることにある。Forkモードを不適切に使用すると、この本来の目的が損なわれる可能性があるので、注意が必要である。

deepagentsライブラリは、PythonとTypeScriptの両方で利用できるオープンソースプロジェクトであり、これらのコンテキストモードを実際に試すことが可能だ。システムエンジニアを目指す上で、このようなAIシステムの効率的な設計手法を理解することは、今後のAI開発において非常に重要なスキルとなるだろう。