大規模モデルエージェントの競争は、新たな高みに達しました。
ソフトウェア工学から研究支援、日常生活からビジネス意思決定まで、何でもできるAIエージェントは、AGIへの必須経路となりつつあります。大手企業は次々と参入していますが、その多くはまだ単一インテリジェンスのパラダイムにとどまっています。
しかし、本日、Anthropicは数万字にわたる論文を発表し、社内で長年育成されてきたマルチエージェント研究システム（Multi-agent Research System）の設計原理、アーキテクチャ詳細、そしてエンジニアリングにおける苦難の歴史を初めて公開しました。
このシステムこそが、Anthropicの主力モデルであるClaudeの最新「研究」能力の裏側を支える立役者です。
驚くべきはその核となるデータです。Claude Opusが「リーダー」を務め、複数のClaude Sonnetが「部下」として働くマルチエージェントシステムでは、社内研究評価ベンチマークにおいて、最強の単一Claude Opus 4を90.2%上回る性能を発揮しました。
これは単なる量的変化ではなく、質的な変化です。
Anthropicチームは論文中で、衝撃的な見解を提示しています。「知能が一定の閾値に達すると、マルチエージェントシステムが能力を拡張するための鍵となる」と。まるで人類社会が過去数十万年間で指数関数的に発展してきたように、それは個々の知能の飛躍ではなく、集合知と協調能力の出現によるものです。
彼らは、このシステムの本質が、アーキテクチャ設計を通じて人類社会の集合知を「再現」することにあると率直に述べています。
さらに驚くべきことに、彼らは直感に反する結論を発見しました。彼らのベンチマークテストにおいて、AIエージェントの性能分散の80%が、単純で粗雑な要素、すなわちトークン消費量によって説明されるというのです。
言い換えれば、「力任せで奇跡が起こる」という言葉が、エージェントの分野では本当に有効なのかもしれません。そしてマルチエージェントシステムは、経済的コストを管理可能な範囲で、十分なトークンを賢く「消費」して複雑な問題を解決する最善の方法なのです。
この論文には膨大な情報が含まれており、アーキテクチャ設計、プロンプトエンジニアリング、ツール選択から、評価方法、エンジニアリング上の課題まで、プロダクション級のマルチエージェントシステムを構築するためのほぼすべての重要な側面を網羅しています。
早速、Anthropicのこの一次情報に目を通しましょう。すべてが中核的な内容です。
なぜマルチエージェントを使うのか？単一の大規模モデルでは不十分なのか？
アーキテクチャに深く踏み込む前に、根本的な問いに答える必要があります。なぜマルチエージェントが必要なのか？Claude OpusやGPT-4oのような強力な単一モデルでは、まだ不十分なのでしょうか？
Anthropicの答えは「オープンエンドな研究（open-ended research）」のようなタスクには、本当に不十分だ、というものです。
研究の仕事の本質は非線形で、経路依存です。人間が複雑な課題を探求する際、新たな発見に基づいて方向を絶えず調整し、予期せぬ着地点に深入りすることもあります。このような探求プロセスを固定された線形のフローでハードコードすることはできません。
これこそが単一LLMの弱点です。彼らは「一発で答える」質問には長けていますが、継続的な自律的決定や多段階の探索が必要な複雑なタスクを扱うことは困難です。
一方、マルチエージェントシステムは、このような要求に完璧に合致します。
並列圧縮と関心事の分離
研究の醍醐味は、膨大な情報から洞察を抽出することであり、本質的には圧縮プロセスです。
マルチエージェントシステムは、並列化によってこのプロセスを大幅に加速します。システムは複数の「サブエージェント」（subagent）を派遣でき、各サブエージェントは独立したコンテキストウィンドウ、ツールセット、探索軌跡を持ち、まるで研究チームの異なるメンバーが同時に様々な角度から問題に取り組むかのようです。
彼らはそれぞれ情報収集と予備分析を完了し、最も重要なトークンを「圧縮」して抽出し、「リーダーエージェント」に報告します。
このような関心事の分離設計は、効率が高いだけでなく、単一パス依存のリスクを減らし、より包括的で深遠な研究を可能にします。
性能90%向上という実証
口で言うだけでなく、データがそれを証明します。
Anthropicの内部評価によると、複数の独立した方向を同時に探索する必要がある広範優先探索（breadth-first）クエリを処理する際、マルチエージェントシステムは圧倒的な優位性を示しました。
Claude Opus 4がリーダーを務め、Claude Sonnet 4がサブエージェントを務めるシステムは、社内研究評価において、単独でClaude Opus 4を使用する単一エージェントシステムよりも90.2%高いパフォーマンスを発揮しました。
典型的な例は、「S&P 500情報技術セクターの全企業の取締役会メンバーを特定する」というものです。
• 単一エージェントシステム：緩慢で連続的な検索ループに陥り、最終的に完全な回答を見つけられませんでした。
• マルチエージェントシステム：リーダーエージェントはタスクを迅速に分解し、各企業または各企業グループにサブエージェントを割り当てて並列で検索させ、最終的にすべての正しい回答を正常に集約しました。
成功の秘密：「力任せで奇跡が起こる」
最も驚くべき発見は、AnthropicがそのBrowseComp評価ベンチマークを分析した結果から得られました。このベンチマークは、エージェントがウェブ上で見つけにくい情報を特定する能力を特別にテストするものです。
彼らは、モデル性能の分散の95%が3つの要因で説明できることを発見しました。そして、そのうちトークンの使用量だけで、分散の80%が説明されたのです！残りの2つの要因はツール呼び出し回数とモデル選択でした。
この発見は、彼らのアーキテクチャ設計の正当性を根本的に裏付けるものです。独立したコンテキストウィンドウを持つ複数のエージェントに作業を割り当てることで、システムはトークンの使用規模を効果的に拡張し、単一エージェントでは処理できない複雑なタスクに対応できます。これは、問題を解決するためにより多くの「計算能力」と「思考の深さ」を投入することに相当します。
もちろん、これには明白な代償が伴います。それは「金銭の消費」です。
データによると、エージェントのインタラクションによるトークン消費量は、通常のチャットの約4倍であり、マルチエージェントシステムではさらに最大15倍に達します。
これは、マルチエージェントシステムが経済的に成り立つのは、タスクの価値が十分に高く、その性能コストをカバーできるシナリオに限られることを意味します。
また、すべてのタスクがマルチエージェントに適しているわけではありません。例えば、ほとんどのプログラミングタスクは研究タスクよりも並列性がはるかに低く、LLMエージェントは現在のところ、リアルタイムでの調整やコーディング作業の委任があまり得意ではありません。
総じて、マルチエージェントシステムが最も得意とする領域は、高価値で、大規模な並列処理が可能で、単一のコンテキストウィンドウを超える情報量が必要で、かつ多くの複雑なツールとの対話が必要なタスクです。
アーキテクチャの秘密：指揮官＋作業員、三段階の研究プロセス
Anthropicの研究システムは、古典的な指揮官-作業員（orchestrator-worker）パターンを採用しています。リーダーエージェントが全体のプロセスを調整し、具体的なタスクを並行する専門のサブエージェントに委任します。
下記の公式アーキテクチャ図は、そのワークフローを明確に示しています。
これをいくつかの重要なステップに分解できます。
1. 起動と計画 ユーザーがクエリ（例：「2025年のAIエージェント分野のトップ企業は？」）を送信すると、システムはLeadResearcher（リーダー研究者）エージェントを作成します。まず、反復的な研究プロセスに入り、最初のステップとして思考し、策定した研究計画を「記憶」（Memory）に保存します。 これは極めて重要な詳細です。なぜなら、エージェントのコンテキストウィンドウ（たとえ200Kトークンであっても）は満杯になる可能性があり、核となる計画を外部記憶に保存することで、エージェントが長期タスク中に「記憶喪失」にならないように保証できるからです。
2. タスク分解と委任 LeadResearcherは計画に基づいて、複数の専門的なSubagent（サブエージェント）を作成します。図では2つ示されていますが、実際の数は動的に調整できます。各Subagentには、「A社の最新動向を調査する」や「B社の資金調達履歴を検索する」といった非常に具体的な研究タスクが与えられます。
3. 並列実行と動的調整 各Subagentは独立して動作し、検索などのツールを利用して情報収集を行います。重要な設計は、インターリーブ思考（interleaved thinking）です。ツール呼び出しのたびに、Subagentは思考を停止し、結果の品質を評価し、情報ギャップを発見し、次のクエリを計画します。これにより、サブエージェントはタスクに動的に適応できます。
4. 結果の統合と反復 サブエージェントがタスクを完了すると、発見をLeadResearcherに返します。LeadResearcherはすべてのサブエージェントのレポートを統合し、さらなる研究が必要かどうかを判断します。必要であれば、追加のサブエージェントを作成するか、既存の戦略を調整して、研究ループを形成します。
5. 引用と帰属 LeadResearcherが収集した情報が十分だと判断すると、研究ループは終了します。この時点で、システムはすべての研究レポートとオリジナル文書を専門のCitationAgent（引用エージェント）に渡します。 このエージェントの唯一の役割は、レポート内の各声明をその元の情報源と正確に照合し、注釈を付けることです。これにより、最終的な回答の事実の正確性と追跡可能性が大幅に保証されます。
6. 最終的な提出 最後に、完全で正確な引用が記載された研究レポートがユーザーに提示されます。
この全体のアーキテクチャは、従来のRetrieval-Augmented Generation（RAG）とは本質的に異なります。従来のRAGは静的であり、クエリに最も類似するテキストブロックを一度に検索し、それから回答を生成します。一方、Anthropicのこのシステムは動的かつ多段階であり、能動的に情報を発見し、適応し、分析することで、RAGをはるかに超える品質の回答を生成できます。
プロンプトエンジニアリングの「八つの秘訣」
アーキテクチャが骨格だとすれば、プロンプトはエージェントに魂を吹き込む呪文です。
Anthropicチームは、システム開発の初期段階では、エージェントたちの行動が混乱していたと率直に語っています。簡単なクエリで50ものサブエージェントを生成したり、存在しない情報源を際限なく検索したり、さらには互いに干渉し合ったりすることもあったそうです。
プロンプトエンジニアリングは、これらの「荒馬」を飼いならすための彼らの核心的なテコでした。彼らは八つの黄金律をまとめました。
1. エージェントのように考える：良いプロンプトを書くためには、まずエージェントになる必要があります。チームはシミュレーション環境を構築し、エージェントの行動を段階的に観察することで、すぐに失敗パターンを発見しました。例えば、すでに答えを見つけているのに検索を続けている、検索クエリが長すぎる、ツールを間違って選択している、などです。エージェントの行動に対する正確な心のモデルを構築することが、効果的な反復の前提となります。
2. 指揮官に権限委譲を教える：リーダーエージェントは、サブエージェントに明確な指示を与える必要があります。「半導体不足を調査せよ」といった単純な指示では不十分で、これではサブエージェントのタスクが重複したり、重要な情報を見落としたりする可能性があります。例えば、あるサブエージェントが2021年の自動車チップ危機を調査しているのに、別の2つが2025年のサプライチェーンの現状を繰り返し調査するといった事態です。良い指示には、明確な目標、出力形式、使用するツールとデータソースの推奨、そして明確なタスク境界を含める必要があります。
3. 複雑性に応じて作業量を調整する：エージェントは、異なるタスクにどれだけの労力を費やすべきかを自分で判断するのが困難です。そのため、チームはプロンプトに直接伸縮ルールを埋め込みました。
• 簡単な事実確認：エージェント1体、ツール呼び出し3～10回。
• 直接比較：サブエージェント2～4体、各エージェントがツール呼び出し10～15回。
• 複雑な研究：サブエージェント10体以上が必要となり、明確な役割分担が必要となる場合があります。 これらの明確なガイドラインは、リーダーエージェントがリソースを効率的に配分し、簡単な問題に過剰な投資を避けるのに役立ちました。
4. ツール設計が極めて重要：エージェントとツールのインターフェースは、人間と機械のインターフェースと同様に重要です。適切なツールを使えば、労力は半減します。もしエージェントにSlack内部にしか存在しない情報をウェブ上で検索させようとしたら、最初から失敗は避けられません。不適切なツール記述は、エージェントを全く間違った方向に導く可能性があります。そのため、各ツールには明確な目標と明確な記述が必要です。チームは、プロンプト内でエージェントにツール選択のヒューリスティックルールさえ提供しました。例えば、利用可能なすべてのツールを最初に確認し、ツールの目的とユーザーの意図を合致させ、専用ツールを優先的に選択する、などです。
5. エージェントを自己改善させる：「メタ認知」とも言える洞察ですが、Claude 4モデル自体が優れたプロンプトエンジニアであるということです。 モデルに失敗したプロンプトと失敗事例を与えると、問題点を正確に診断し、改善提案をすることができます。 チームは「ツールテストエージェント」まで作成しました。欠陥のあるツールを与えると、そのツールを使ってみて、将来の失敗を避けるためにツールの記述を書き直そうとします。数十回のテストを通じて、このエージェントは多くの微妙な違いやバグを発見しました。この自己改善プロセスにより、将来新しい記述を使用するエージェントのタスク完了時間が40%短縮されました。
6. まず広範囲に網を張り、それから正確に焦点を絞る：検索戦略は、人間の専門家の研究方法を模倣すべきであり、まず分野全体を包括的に探索し、次に詳細に深く掘り下げるべきです。エージェントはしばしば、長すぎたり具体的すぎたりするクエリをデフォルトで使用しがちで、その結果、返される情報が少なくなります。私たちは、エージェントに短く広いクエリから始めさせ、利用可能な情報を評価し、それから徐々に焦点を絞るように促すことで、この傾向を是正します。
7. 思考プロセスを導く：Claudeの「拡張思考モード」（タグ内で思考プロセスを出力する）は、制御可能なメモ帳として機能します。 リーダーエージェントは、これを使って方法を計画し、ツールを評価し、サブエージェントの数と役割を決定します。サブエージェントは、これを使ってクエリを計画し、ツール呼び出し後に結果の品質を評価します。テスト結果は、この方法が指示の順守、推論、および効率を著しく向上させることを示しています。
8. 並列実行を試す：初期のエージェントは逐次検索であり、速度は耐え難いほど遅かった。チームは2種類の並列化を導入しました。
• マクロ並列：リーダーエージェントが一度に3～5体のサブエージェントを起動し、逐次起動しない。
• ミクロ並列：各サブエージェントが一度に3つ以上のツール呼び出しを並列で実行できる。これら2つの変更により、複雑なクエリの場合、研究時間が最大90%短縮され、システムは以前数時間かかっていた作業を数分で完了できるようになりました。
効果的な評価方法とは？LLM-as-Judgeから人間のレッドチームまで
評価は信頼性の高いAIアプリケーションを構築するための基礎ですが、マルチエージェントシステムの評価は特に困難です。
従来の評価では、入力Xに対してシステムがパスYに従い、出力Zを得ると仮定します。しかし、エージェントは非決定論的であり、全く異なる有効なパスを通じて、同じ正しい目標を達成する可能性があります。
したがって、評価方法は十分に柔軟である必要があり、結果の正確性だけでなく、プロセスの妥当性も評価しなければなりません。
1. すぐに始める、少量サンプル評価 これはすべてのAI開発チームへの貴重な助言です。多くの人は、数百もの事例を含む大規模な評価セットのみが価値を持つと考え、着手せずにいます。Anthropicの経験は、少量サンプルで直ちに評価を始めるべきだというものです。開発の初期段階では、わずかなプロンプトの調整が、成功率を30%から80%にまで急上昇させることがあります。このような大きな効果量は、約20個の代表的なクエリで十分発見できます。
2. 精巧に設計されたLLM-as-Judge 研究報告は自由形式のテキストであり、プログラム的な方法で評価するのは困難です。LLMが自然と最高の「審査官」となりました。AnthropicはLLMの審査官を用い、詳細な評価基準に基づいて採点します。
• 事実の正確性：記述は情報源と一致しているか？
• 引用の正確性：引用された情報源は記述を裏付けているか？
• 完全性：要求された内容をすべて網羅しているか？
• 情報源の品質：高品質な一次情報源が使用されているか、SEOファームではないか？
• ツールの効率性：適切なツールが妥当な回数使用されているか？ 彼らは、単一のLLM呼び出しで、単一のプロンプトに基づいて0.0～1.0のスコアと合格/不合格の等級を出力する方法が、最も安定しており、人間の判断と最も一致していることを発見しました。
3. 人間による評価は不可欠 自動化された評価には常に盲点があります。人間のテスター（レッドチーム）は、予期せぬエッジケースを発見できます。 例えば、人間のテスターは、初期のエージェントが、学術論文PDFや個人ブログのような、より信頼性がありながらも検索順位が低い情報源よりも、SEO最適化されたコンテンツファームを選択する傾向があることを発見しました。チームは、プロンプトに情報源の品質に関するヒューリスティックルールを追加することで、この問題を解決しました。
プロトタイプから製品へ：血と涙のエンジニアリング教訓
開発マシン上でうまく動作していたエージェントのプロトタイプを、信頼できるプロダクション級のシステムに変えるまでの隔たりは、想像以上に広大です。Anthropicはこれを「ラストマイルが極めて重要」と呼んでいます。
1. ステートフル性とエラーの累積：エージェントは長時間実行されるステートフルなプロセスです。従来のソフトウェアにおける小さなバグが、エージェントシステムでは無限に増幅され、タスク全体が脱線する可能性があります。 そのため、単純に「エラーが発生したら最初からやり直す」ことは許容されません。これは費用がかさみ、ユーザーを苛立たせます。 彼らの解決策は次の通りです。
• 回復可能性：チェックポイントを設定することで、システムがエラーが発生した場所から回復できるようにし、再起動を避けます。
• エージェントにエラーへの適応を促す：ツールが失敗した際、直接エージェントに知らせ、エージェント自身の知能を活用して適応し、代替案を見つけさせる。この方法は驚くほど効果的でした。
2. 非決定性のデバッグ：エージェントの非決定性のため、バグの再現は極めて困難です。ユーザーからの報告はしばしば「エージェントが明白な情報を見つけられなかった」というものですが、原因を追跡するのは困難です。 解決策は、完全なプロダクショントレーシング（full production tracing）です。これにより、失敗の根本原因を診断し、系統的に修正できるようになりました。さらに、彼らはエージェントの意思決定パターンとインタラクション構造（ユーザープライバシーを保護しつつ、具体的な内容は監視しない）を監視し、予期せぬ行動を発見しています。
3. 慎重なデプロイ：エージェントシステムは、プロンプト、ツール、実行ロジックから構成され、ほぼ継続的に稼働する高度なステートフルネットワークです。アップデートをデプロイする際、稼働中のエージェントを単純に中断することはできません。 彼らは「レインボーデプロイメント」（rainbow deployments）戦略を採用し、新旧バージョンのシステムを同時に稼働させ、トラフィックを徐々に旧バージョンから新バージョンへ移行させることで、実行中のタスクに影響を与えないようにしています。
4. 将来：非同期実行：現在、システムは同期型です。リーダーエージェントは、次のステップに進むために、一連のサブエージェントがすべて完了するのを待つ必要があります。これは調整を簡素化しますが、ボトルネックも生じます。 将来の方向は非同期実行であり、エージェントは並行して作業し、必要に応じて新しいサブエージェントを随時作成できます。これは結果の調整や状態の一貫性において大きな課題をもたらしますが、モデルがより長く、より複雑なタスクを処理できるようになるにつれて、この性能向上は価値のあるものとなるでしょう。
まとめと展望：AI「仮想企業」の夜明け
Anthropicのこの論文は、深い現実を明らかにしています。プロダクション級のAIエージェントを構築する上で、ラストワンマイルが極めて重要であると。プロトタイプから製品への隔たりは、エージェントシステム内でエラーが累積し続けるという特性から生じています。
数々の課題があるにもかかわらず、マルチエージェントシステムは既に大きな価値を示しています。ユーザーからのフィードバックによると、Claudeの研究機能は、彼らがこれまで考慮していなかったビジネス機会を発見し、複雑な医療保険の選択肢をナビゲートし、厄介な技術的なバグを解決し、研究間の深い関連性を明らかにすることで、数日間の作業量を節約するのに役立っているとのことです。
ユーザーの利用状況分析を通じて、Anthropicは、現在のこの機能の最も一般的な用途が以下のようなものであることを発見しました。
• 特定分野のソフトウェアシステム開発
• 専門技術コンテンツの開発と最適化
• 事業成長および収益創出戦略の策定
• 学術研究および教育資料開発の補助
• 人物、場所、または組織に関する情報の調査と確認
その背後には、綿密なエンジニアリング設計、包括的なテスト、細部にわたるプロンプトとツールの磨き上げ、堅牢な運用実践、そして研究、製品、エンジニアリングチーム間のエージェントの現在の能力に対する深い理解と緊密な連携が必要です。
エージェントの「iPhoneモーメント」はまだ来ていないかもしれませんが、Anthropicの探求は間違いなく私たちにその灯台の方向を示しています。リーダーエージェント（CEO）、サブエージェント（専門社員）、ツール（部署能力）、そして記憶（知識ベース）からなる「AI仮想企業」が、地平線上にまさに姿を現しつつあります。
人類の集合知は、全く新しいデジタル形式で「再現」され、「加速」されています。これこそが、マルチエージェントシステムにおける最も胸躍る未来なのかもしれません。
参照リンク：https://www.anthropic.com/engineering/built-multi-agent-research-system