Syncedによる報道
Synced編集部
マルチエージェント研究の必読ガイド。
「Anthropicは、複数のClaude AIエージェントを使用してマルチエージェント研究システムを構築した方法について、素晴らしい説明を公開しました。マルチエージェントシステムを構築するすべての人にとって、これは必読のガイドです。」つい先ほど、Xの有名ブロガーであるRohan Paulは、Anthropicの新しい研究を強く推薦しました。
最近、エージェントに関する研究が次々と発表されています。しかし、これは多くの研究者に、どのようなタスクにマルチエージェントが必要なのか、複数のAIエージェントがどのように連携するのか、コンテキストやメモリの問題をどのように解決するのか、といった疑問をもたらしました。
これらの問題に直面したら、Anthropicのこの記事を読んでみてください。おそらく答えが見つかるでしょう。
記事URL：https://www.anthropic.com/engineering/built-multi-agent-research-system
マルチエージェントシステムの利点
一部の研究はオープンエンドな問題を扱い、そのような問題では必要な手順を事前に決定することが困難な場合が多いです。複雑な問題の探索において、人間は固定されたパスを厳密に定めることはできません。なぜなら、そのプロセスは本質的に動的でパス依存性があるからです。人々が研究を進める際には、発見に応じて方法を継続的に調整し、調査の過程で現れる手がかりに沿って進んでいきます。
この予測不可能性により、AIエージェントは研究タスクの実行に特に適しています。研究作業には柔軟性が求められ、調査の進展に応じて方向転換したり、関連する内容を探索したりできる必要があります。モデルは、中間的な発見に基づいて、さらなる探索の方向を決定するために、自律的に多段階の推論を行うことができなければなりません。線形の一回限りのプロセスでは、このようなタスクをこなすことはできません。
研究の本質は圧縮です。膨大なコーパスから価値ある洞察を抽出することです。サブエージェントは並行して動作し、それぞれが独立したコンテキストウィンドウを持つことで、この圧縮プロセスを支援します。彼らは問題の異なる側面を同時に探索し、最も重要な内容を抽出し、主研究エージェントに渡します。各サブエージェントは、関心事の分離という役割も果たします。彼らは異なるツール、プロンプト、探索経路を使用することで、パス依存性を減らし、研究プロセスがより包括的で相互に独立していることを保証します。
一旦知能が一定の閾値に達すると、マルチエージェントシステムはパフォーマンスを向上させるための重要な手段となります。例えば、過去10万年間で個々の人間の知能は向上しましたが、情報時代における私たちの集合的な知能と協調能力のおかげで、人類社会全体の能力は指数関数的に成長しました。汎用知能を持つエージェントであっても、個体としてタスクを実行する際には限界があります。しかし、複数のエージェントが協力することで、より複雑なタスクを達成できます。
Anthropicの内部評価によると、マルチエージェント研究システムは「幅優先」のクエリタスクにおいて特に優れた性能を発揮し、これらのタスクは通常、複数の相互に独立した方向を同時に探索する必要があります。彼らは、Claude Opus 4を主エージェント、Claude Sonnet 4をサブエージェントとするマルチエージェントシステムが、単一のClaude Opus 4エージェントよりも90.2%高いパフォーマンスを示したことを発見しました。
マルチエージェントシステムの核心的な利点は、十分なトークン消費を通じて問題を解決できることにあります。分析によると、BrowseComp評価（閲覧型エージェントが高度な情報を見つける能力を測定するテスト）において、3つの要素が共同でパフォーマンスの差異の95%を説明していることが示されました。研究で明らかになったのは、
トークン消費量が単独で差異の80%を説明。
ツール呼び出し回数とモデル選択が、残りの2つの主要な要因でした。
この発見は、Anthropicが以前に採用していたアーキテクチャ、すなわち、独自のコンテキストウィンドウを持つ異なるエージェントにタスクを分散させることで、並列推論の容量を増やすというアプローチを裏付けています。最新のClaudeモデルはトークン使用効率において強力な乗数効果を発揮します。例えば、Claude Sonnetをバージョン4にアップグレードすることで得られるパフォーマンス向上は、Claude Sonnet 3.7のトークン予算を2倍にした場合よりもさらに大きいです。単一エージェントの処理限界を超えるタスクに対しては、マルチエージェントアーキテクチャがトークン使用を効果的に拡張し、より強力な処理能力を実現できます。
もちろん、このアーキテクチャには欠点もあります。実際のアプリケーションでは、トークンを非常に速く消費します。Anthropicの統計によると、エージェントは通常、通常のチャットインタラクションの約4倍のトークンを使用し、マルチエージェントシステムのトークン消費量はチャットの約15倍にもなります。
したがって、経済的な実現可能性を達成するためには、マルチエージェントシステムは、その性能向上によってもたらされるコストを上回るだけの十分な価値があるタスクに利用される必要があります。さらに、すべてのエージェントが同じコンテキストを共有する必要があるタスクや、エージェント間に多数の依存関係が存在するタスクなど、一部の分野は現在のマルチエージェントシステムには適していません。
例えば、ほとんどのプログラミングタスクにおいて、真に並列化可能な部分は比較的少なく、現在の大規模言語モデルエージェントは「リアルタイムでのタスク調整と割り当て」の能力がまだ十分ではありません。
したがって、マルチエージェントシステムが最も得意とするシナリオは、大量の並列処理が必要であること、情報量が単一のコンテキストウィンドウを超えること、そして多数の複雑なツールとの連携が必要であること、という特徴を持つ高価値なタスクです。
アーキテクチャ
Anthropicの研究システムは、マルチエージェントアーキテクチャを採用しており、「オーケストレーター・ワーカー（orchestrator-worker）」パターンを使用しています。これは、主導エージェントが全体の調整を担当し、同時に複数の並列動作する専門的なサブエージェントにタスクを割り当てるものです。
マルチエージェントアーキテクチャの実際の動作：ユーザーのクエリはまず主導エージェント（lead agent）を介し、それが複数の専門サブエージェントを作成し、それぞれがクエリの異なる側面を並行して検索します。
上図のワークフローは次のとおりです。ユーザーがクエリを送信すると、システムはLeadResearcherという名前の主導研究エージェントを作成し、それが反復的な研究プロセスに入ります。LeadResearcherはまず研究方法を検討し、その計画をMemory（記憶モジュール）に保存してコンテキスト情報を永続化します。なぜなら、コンテキストウィンドウが200,000トークンを超えると内容が途切れてしまうため、研究計画の保持は後続の推論にとって非常に重要だからです。
その後、LeadResearcherは複数の専門サブエージェント（Subagents）（図中では2つが示されていますが、実際には任意の数を作成可能）を作成し、各サブエージェントに具体的な研究タスクを割り当てます。各サブエージェントは独立してウェブ検索を行い、ツールから返された結果をインターリーブ思考方式で評価し、研究結果をLeadResearcherにフィードバックします。
LeadResearcherはこれらの結果を総合的に分析し、さらなる研究が必要かどうかを判断します。必要であれば、追加のサブエージェントを作成したり、既存の研究戦略を最適化したりすることができます。
十分な情報が収集されると、システムは研究ループを終了し、すべての研究結果をCitationAgent（引用注釈エージェント）に渡します。CitationAgentはすべての文書と研究報告を処理し、各論述に対応する具体的な引用位置を特定することで、すべての意見が明確な情報源に裏付けられていることを保証します。
最終的に、完全な引用情報を含む研究成果がユーザーに返されます。
研究エージェントのプロンプトエンジニアリングと評価方法
マルチエージェントシステムと単一エージェントシステムの間には重要な違いがあり、その一つは調整の複雑さが急速に増大することです。初期段階では、エージェントはしばしば誤った行動を示すことがあります。例えば、簡単な問題に対して50個ものサブエージェントを生成したり、ネットワーク上で存在しないリソースを際限なく探し続けたり、互いに頻繁に干渉し合い、過度に無関係な更新を送信したりすることです。
各エージェントの動作はプロンプト（prompt）によって駆動されるため、プロンプトエンジニアリングは研究者がこれらの動作を最適化するための主要な手段となります。以下はAnthropicがエージェントのプロンプト設計過程でまとめた原則の一部です。
効率的なプロンプト設計。プロンプト（prompt）を最適化するには、その実際の影響を理解する必要があります。このため、Anthropicはコンソールを介してシミュレーション環境を構築しました。システム内のプロンプトとツール設定を完全に再現し、エージェントの作業プロセスを段階的に観察しました。この方法はすぐに典型的な失敗パターンを露呈させました。冗長な実行、つまり十分な結果が得られた後も操作を続行すること。非効率なクエリ、つまり冗長で曖昧な検索指示を使用すること。そしてツール誤用、機能モジュールの誤った選択です。したがって、効率的なプロンプト設計は、エージェントの行動について正確な心理モデルを構築することに依存します。一度深く理解すれば、最も効果的な改善方向も一目瞭然となります。
コーディネーターに適切な分担方法を教える。Anthropicが採用しているシステムでは、主導エージェントがユーザーのクエリを複数のサブタスクに分解し、それらのタスクをサブエージェントに割り当てます。各サブエージェントには、明確な目標、出力形式、使用すべきツールと情報源に関する指示、そして明確なタスク境界が必要です。タスク記述が不十分だと、エージェント間で重複した作業、タスクの欠落、あるいは必要な情報を見つけられないといった問題が発生します。
Anthropicはかつて深い教訓を得ました。彼らが初期に「チップ不足を調査せよ」といった大まかな指示を採用した際、これらの指示が往々にして曖昧すぎ、サブエージェントがタスクを誤解したり、他のエージェントとまったく同じ検索を実行したりすることが判明しました。例えば、3つのサブエージェントが示し合わせたように2025年のサプライチェーンデータに焦点を当て、そのうちの1つは2021年の自動車チップ危機に逸れて製造側のボトルネックをカバーせず、最終的にレポートの重複率が60%に達し、ウェーハ工場の生産能力分析が欠落していました。
クエリの複雑性に応じて投入レベルを調整する。エージェントは異なるタスクに必要な適切な投入量を判断するのが難しいため、Anthropicはプロンプトに段階的な投入ルールを組み込みました。単純な事実検索には1つのエージェントが3〜10回ツールを呼び出すだけで済みます。直接比較するようなタスクには2〜4つのサブエージェントが必要で、それぞれが10〜15回ツールを呼び出す可能性があります。一方、複雑な研究タスクでは10個以上のサブエージェントを使用し、それぞれの役割が明確に割り当てられる場合があります。
これらの明確なガイドラインは、主導エージェントがリソースをより効果的に割り当て、単純なクエリに過剰な投入を避けるのに役立ちます。
ツールの設計と選択が極めて重要です。エージェントとツールの間のインターフェースは、人間とコンピュータのインタラクションインターフェースと同じくらい重要です。適切なツールを使用することで、効率が大幅に向上します。多くの場合、これは最適化手段であるだけでなく、必要不可欠な条件でもあります。例えば、あるエージェントがウェブ検索を通じてSlackにのみ存在するコンテキスト情報を取得しようとした場合、最初から成功する見込みはありません。
MCPサーバーによってモデルが外部ツールにアクセスできるようになるにつれて、この問題はさらに複雑になりました。エージェントはこれまで使用したことのないツールに遭遇する可能性があり、これらのツールの説明の品質はまちまちです。
このため、Anthropicはエージェント向けに明確なヒューリスティックルールを設計しました。例えば、まず利用可能なすべてのツールを確認する、ツールの用途をユーザーの意図と一致させる、ウェブ検索を使用して広範な情報探索を行う、汎用ツールよりも専用ツールを優先するなどです。
劣悪なツールの説明は、エージェントを完全に誤った道に導く可能性があります。そのため、各ツールは明確な用途と分かりやすい説明を持つ必要があります。
エージェントの自己改善を可能にする。Anthropicは、Claude 4シリーズモデルがプロンプトエンジニアリングにおいて非常に優れたパフォーマンスを示すことを発見しました。プロンプトとそれに対応する失敗パターンが与えられると、エージェントの失敗原因を診断し、改善策を提案することができます。
Anthropicはさらに、ツールテストエージェントを構築しました。このエージェントは、問題のあるMCPツールを受け取ると、そのツールを使用しようと試み、その後、同様の失敗が起こるのを避けるためにツールの説明を書き直します。このツールを数十回テストすることで、このエージェントは重要な使用詳細と潜在的なバグを発見できます。
このツールインタラクション体験を最適化するプロセスにより、新しい説明を使用する後続のエージェントのタスク完了時間が40%短縮されました。なぜなら、彼らがほとんどの一般的なエラーを回避できるようになったからです。
最初は広く、その後狭く、段階的に進める。検索戦略は、人間の専門家の研究方法を模倣すべきです。まず包括的に探索し、次に深く掘り下げて詳細化するのです。しかし、エージェントは往々にして最初から冗長で具体的なクエリワードを使用する傾向があり、その結果、返される内容は非常に限られてしまいます。
この問題を解決するため、Anthropicはプロンプトにおいて、エージェントが簡潔で広範なクエリから開始し、まず利用可能な情報を評価し、その後徐々に研究方向を絞り込み、深掘りするように誘導しています。
思考プロセスを導く。「拡張思考モード」（Extended Thinking Mode）は、Claudeがその出力において目に見える思考プロセスを示すことを可能にし、これは制御可能な「下書き帳」に相当します。主導エージェントは、この思考プロセスを利用して全体戦略を計画します。これには、現在のタスクに適したツールを評価すること、クエリの複雑さと必要なサブエージェントの数を判断すること、そして各サブエージェントの責任を明確にすることなどが含まれます。
テストにより、拡張思考はエージェントの指示遵守能力、推論能力、実行効率を著しく向上させることが示されています。
サブエージェントも同様に、まず計画を立て、その後ツール呼び出し後にインターリーブ思考（Interleaved Thinking）を使用して結果の品質を評価し、情報の不足を発見し、次のクエリを改善します。これにより、サブエージェントは異なるタスクに直面した際に、より高い適応能力を持つことになります。
並列ツール呼び出しは、研究タスクの速度と性能を根本的に変えました。複雑な研究タスクは、本質的に大量の情報源を参照する必要があります。Anthropicの初期のエージェントは逐次検索を採用しており、実行効率が極めて低かったのです。
この問題を解決するため、彼らは2つの並列メカニズムを導入しました。
主導エージェントが、順番に生成するのではなく、3〜5個のサブエージェントを同時に作成する。
各サブエージェントが、個別に呼び出すのではなく、同時に3つ以上のツールを使用する。
これらの改善により、複雑なクエリの研究時間が最大90%短縮され、研究システムは元々数時間かかっていた作業を数分で完了できるようになり、同時にカバーする情報範囲も他のシステムをはるかに上回りました。
効果的な評価方法
信頼性の高いAIアプリケーションを構築するためには、優れた評価メカニズムが不可欠であり、エージェントシステムも例外ではありません。しかし、マルチエージェントシステムの評価には特有の課題があります。
従来の評価では、AIは毎回同じ手順に従うと仮定されています。つまり、入力Xが与えられた場合、システムは経路Yを実行し、結果Zを出力するというものです。しかし、マルチエージェントシステムはそうではありません。出発点が同じであっても、エージェントは目標を達成するために全く異なるが同様に有効な経路を辿る可能性があります。あるエージェントは3つの情報源しか参照しないかもしれませんし、別のエージェントは10個参照するかもしれません。また、異なるツールを使用して同じ答えを導き出すこともあります。
私たちはどの操作手順が正しいのか常に知っているわけではないため、通常、事前に設定されたプロセスに従ったかどうかだけをチェックするだけではエージェントのパフォーマンスを評価することはできません。代わりに、エージェントが正しい結果を達成したかどうかだけでなく、その実行プロセスが合理的であったかどうかを測る、より柔軟な評価方法が必要です。
小規模サンプル評価から始める。エージェント開発の初期段階では、どんな変更でも顕著な影響をもたらすことが多いです。例えば、プロンプトを少し調整するだけで、成功率が30%から80%に向上する可能性があります。このような影響が大きい段階では、少数のテストケースで変更の効果を明確に把握できます。
Anthropicは当初、実際の使用パターンを代表する約20のクエリのセットを使用していました。これらのクエリをテストするだけで、変更の効果を明確に判断するには通常十分でした。
AI開発チームが評価メカニズムの作成を遅らせるとよく聞かれるのは、数百ものテストケースを含む大規模な評価だけが価値があると考えているからです。しかし実際には、最善の方法はすぐに小規模なテストから始め、いくつかの例を用いて直ちに評価に着手することであり、完全な評価システムが構築されるまで待つことではありません。
適切に利用すれば、「LLMを評価者とする（LLM-as-judge）」評価方法も良い選択肢となります。
研究系の出力は、通常自由形式のテキストであり、唯一正しい答えが存在することはほとんどないため、プログラムによる評価は困難です。LLMは、このような出力の評価者として自然に適しています。
Anthropicは「LLM評価者」を使用し、ルーブリック（採点基準）に基づいて各出力を評価しました。具体的には以下の次元が含まれます。
事実の正確性：記述は引用元と一致しているか？
引用の正確性：引用された内容が対応する記述を実際に裏付けているか？
網羅性：要求されたすべての内容をカバーしているか？
情報源の品質：質の低い二次資料ではなく、質の高い一次資料を優先的に使用しているか？
ツール使用の効率性：関連ツールは適切に選択され、適切に使用されたか？
Anthropicは複数のLLMを使用して各次元を個別に評価することを試みましたが、最終的には、LLMを1回だけ呼び出し、単一のプロンプトでモデルに0.0〜1.0のスコアと「合格/不合格」の判断を出力させる方法が、最も安定しており、人間の評価基準に最も合致する方法であることを見出しました。
この方法は、テストケース自体に明確な答えがある場合に特に有効です。例えば、「研究開発投資が最も高い製薬会社3社を正確に挙げたか？」といった問題は、答えが正しいかどうかを直接判断できます。
LLMを評価者として活用することで、数百の出力結果を効率的に評価することが可能となり、評価システムの拡張性と実用性が大幅に向上しました。
人間による評価は、自動評価では見落とされる問題を発見できます。実際にエージェントをテストする人々は、評価システムでは捉えきれないエッジケースを発見します。例えば、異常なクエリから生じる幻覚的な回答、システム障害、あるいは微妙な情報源選択の偏りなどです。自動評価が普及している今日においても、手動テストは依然として不可欠です。
生産信頼性とエンジニアリングの課題
従来のソフトウェアでは、プログラムの欠陥は機能不全、性能低下、またはシステムダウンを引き起こす可能性があります。しかし、エージェントシステムでは、わずかな変化が巨大な行動変化を引き起こす可能性があり、長時間実行中に状態を維持する必要がある複雑なエージェントのためにコードを書くことは非常に困難になります。
エージェントは状態を持つため、エラーは蓄積されます。エージェントは長時間動作し、複数回のツール呼び出し中に状態を維持することがあります。これは、コードを永続的に実行し、その過程でエラーを処理する必要があることを意味します。効果的な緩和策がなければ、わずかなシステム障害でもエージェントにとっては壊滅的なものとなりかねません。エラーが発生した際、単純に最初から再起動することはできません。再起動はコストがかかり、ユーザーを苛立たせます。代わりに、Anthropicは、エージェントがエラーに遭遇した状態から実行を継続できるシステムを構築しました。
デバッグ。エージェントは実行時に動的な意思決定を行い、同じプロンプトを使用しても結果は非決定的であるため、デバッグはより困難になります。完全な本番追跡を追加することで、Anthropicはエージェントの失敗原因を体系的に診断し、問題を修正できます。
デプロイには慎重な調整が必要です。エージェントシステムは、プロンプト、ツール、実行ロジックの高度なステートフルネットワークであり、ほぼ継続的に動作しています。これは、更新をデプロイするたびに、エージェントが実行プロセスのどの段階にある可能性もあることを意味します。すべてのエージェントを同時に新しいバージョンに更新することはできませんが、Anthropicはレインボーデプロイメントを採用しており、古いバージョンから新しいバージョンへ徐々にトラフィックを移行させつつ、両方を並行して実行することで、稼働中のエージェントへの干渉を避けています。
同期実行はボトルネックを引き起こす。現在、Anthropicの主制御エージェントはサブエージェントタスクを同期的に実行し、各バッチのサブエージェントが完了するまで次のステップに進みません。これは調整プロセスを簡素化しますが、エージェント間の情報フローにおいてボトルネックも形成します。例えば、主エージェントはサブエージェントをリアルタイムで誘導できず、サブエージェント間も協調できず、システム全体が特定のサブエージェントの検索完了を待つことでブロックされる可能性があります。
一方、非同期実行はより多くの並列性をもたらします。エージェントは同時に作業でき、必要に応じて新しいサブエージェントを作成できます。しかし、この非同期性も、結果の調整、状態の一貫性、エラー伝播といった課題をもたらします。モデルがより長く複雑な研究タスクを処理できるようになるにつれて、Anthropicは性能向上がこれらの複雑性の増加を相殺するのに十分であると予測しています。
まとめ
AIエージェントを構築する際、「最後の1マイル」が旅全体の大部分を占めることがよくあります。開発者のマシンで実行できるコードベースから、信頼性の高い本番システムへと移行するには、大量のエンジニアリング投資が必要です。エージェントシステムにおけるエラーの複合的な特性は、従来のソフトウェアにおける些細な問題が、エージェントの動作を完全に混乱させる可能性があることを意味します。あるステップで失敗すると、エージェントはまったく異なるパスを探索することになり、予測不能な結果を生む可能性があります。この記事で述べられている様々な理由に基づくと、プロトタイプと本番環境の間のギャップは、通常予想よりも大きくなります。
これらの課題にもかかわらず、マルチエージェントシステムはオープンエンドな研究タスクにおいて大きな価値を示しています。細部にわたるエンジニアリング設計、包括的なテスト、プロンプトとツール設計への細心の注意、健全な運用実践、そして研究、製品、エンジニアリングチーム間の密接な協力と、現在のエージェント能力への深い理解があれば、マルチエージェント研究システムは大規模なシナリオで安定して動作できます。私たちは、これらのシステムが複雑な問題を解決する方法を変革しているのをすでに目にしています。
© THE END
転載は本公式アカウントに許可を得てご連絡ください
投稿または報道依頼：liyazhou@jiqizhixin.com