はじめに
2025年6月、Anthropicが公式エンジニアリングブログで「How we built our multi-agent research system」を公開した。Claudeの「Research」機能の裏側にあるマルチエージェントアーキテクチャを解説した記事である。
この記事が面白いのは、理論ではなく実装の話に踏み込んでいる点にある。プロトタイプで50体のサブエージェントが暴走した失敗談や、トークン使用量がパフォーマンスの80%を説明するという定量データなど、現場で使える知見が詰まっている。
本記事では、原文の内容を整理し、マルチエージェントシステムを構築する際に参考になるポイントを抽出する。
対象読者
- AIエージェントの設計・開発に取り組んでいるエンジニア
- マルチエージェント構成を検討しているチーム
- MCPサーバーやツール設計に関わっている方
この記事で得られること
- Anthropicが採用したオーケストレーター＋ワーカー構成の全体像
- プロンプト設計、ツール設計、評価方法の具体的な知見
- プロトタイプから本番環境への移行で直面した課題と対策
システム概要
ClaudeのResearch機能は、Web、Google Workspace、各種インテグレーションを横断して情報を収集する。単一のエージェントではなく、複数のエージェントが並列に動く構成を採用している。
なぜマルチエージェントなのか
リサーチは本質的に予測困難なタスクである。調査の途中で方針が変わることは日常的に起きる。固定パイプラインでは対応できない。
Anthropicはマルチエージェント構成を選んだ理由を3つ挙げている。
| 理由 | 説明 |
|---|---|
| 並列探索 | 複数の方向を同時に調べられる |
| コンテキスト分離 | 各サブエージェントが独自の文脈窓を持ち、関心の分離を実現する |
| スケーラビリティ | 知性が一定水準に達すると、集団で動く方が個体より成果が出る |
定量的な成果
原文には具体的な数値が複数登場する。
- マルチエージェント（Claude Opus 4リード＋Claude Sonnet 4サブエージェント）は、単体のClaude Opus 4と比較して内部評価で 90.2%の性能向上 を達成
- BrowseComp評価において、トークン使用量だけでパフォーマンス分散の 80% を説明可能。ツール呼び出し数とモデル選択を加えると 95% を説明
- Claude Sonnet 4へのアップグレードは、トークン予算を2倍にするよりも大きな性能向上をもたらした
エージェントはチャットの約4倍、マルチエージェントはチャットの約15倍のトークンを消費する。経済的に見合うのは「タスクの価値がトークンコストを上回る場面」に限られる。
アーキテクチャ
Anthropicが採用したのはオーケストレーター・ワーカーパターンである。リードエージェントが全体を統括し、サブエージェントに作業を委譲する。
処理の流れ
ユーザークエリ
│
▼
LeadResearcher（リードエージェント）
│ 1. 思考・計画策定
│ 2. 計画をMemoryに保存
│ 3. サブエージェントを生成（複数・並列）
│
├──▶ Subagent A（Web検索）
├──▶ Subagent B（特定領域の深掘り）
└──▶ Subagent C（別の観点で調査）
│
▼ 各サブエージェントが結果を返却
│
▼
LeadResearcher（結果を統合・追加調査の判断）
│
▼
CitationAgent（引用元の特定・付与）
│
▼
最終レポート（引用付き）→ ユーザーへ
従来のRAGとの違い
従来のRAG（Retrieval Augmented Generation）は静的な検索を行う。クエリに類似するチャンクを取得し、それをもとに回答を生成する。
Anthropicのアーキテクチャは動的な多段階検索を行う。検索結果に応じて次の検索クエリを変え、必要に応じてサブエージェントを追加で生成する。調査の進行に合わせて戦略を更新できる点が根本的に異なる。
コンテキスト管理の工夫
リードエージェントのコンテキスト窓が20万トークンを超えると切り詰められる。そのため、計画をMemoryに保存する設計を採用している。コンテキスト上限に達しても、外部メモリから計画を読み戻せる。
サブエージェントはクリーンなコンテキスト窓で起動する。完了した作業フェーズを要約して外部メモリに保存し、必要に応じて新しいサブエージェントに引き継ぐ。
プロトタイプから本番への道のり
原文が最も強調しているのは「プロトタイプと本番の間にある溝」の深さである。
初期の失敗パターン
Anthropicのチームが実際に経験した問題を以下にまとめる。
| 失敗パターン | 詳細 |
|---|---|
| サブエージェントの暴走 | 単純なクエリに対して50体のサブエージェントを生成 |
| 無限検索 | 存在しないソースをWeb上で延々と探し続ける |
| 作業の重複 | 複数のサブエージェントが同一の検索を実行 |
| 曖昧な指示 | 「半導体不足を調べて」だけでは、2021年の自動車チップ危機を調べるエージェントと、2025年のサプライチェーンを調べるエージェントが重複 |
| 低品質ソースの選択 | SEO最適化されたコンテンツファームを学術PDFや個人ブログより優先 |
エラーの複合性
原文はこう述べている。従来のソフトウェアでは、バグは機能の破損やパフォーマンス低下として現れる。しかしエージェントシステムでは、小さな変更がカスケードして大きな行動変化を引き起こす。1ステップの失敗がエージェント全体を別の軌道に乗せ、予測不能な結果を生む。
エージェントシステムでは「ラストマイル」がしばしば旅程の大半を占める。開発者のマシンで動くコードベースを、信頼性の高い本番システムにするには相当なエンジニアリングが必要になる。
本番運用の対策
| 課題 | 対策 |
|---|---|
| 長時間実行中のエラー | 再開可能な設計。チェックポイントの定期保存。モデルにツール障害を伝え、適応させる |
| 非決定的な動作 | 本番トレーシングの導入。エージェントの意思決定パターンを構造レベルで監視（会話内容は監視しない） |
| デプロイ中の既存エージェント | Rainbow Deploymentの採用。旧バージョンと新バージョンを同時稼働させ、トラフィックを段階的に移行 |
| 同期実行のボトルネック | 現時点ではサブエージェントを同期的に待機。非同期化は今後の課題 |
ツール設計の知見
原文はツール設計に多くの紙面を割いている。エージェントとツールのインターフェースは、人間とコンピュータのインターフェースと同じくらい重要だと述べている。
ツール設計の原則
- 各ツールに明確な目的を持たせる。曖昧な説明はエージェントを誤った方向に導く
- ツールの説明を具体的に書く。悪い説明はエージェントを完全に間違った経路に送り込む
- 利用可能なツールを最初に確認させる。エージェントには「まずツール一覧を確認し、ユーザーの意図に合ったツールを選べ」という指示を与える
- 専用ツールを汎用ツールより優先させる。Webで調べるべきか、Slackを検索すべきかはタスクによって異なる
ツール説明の自動改善
Claude 4モデルにツールの説明を改善させる手法が紹介されている。
1. テスト用エージェントにMCPツールを渡す
2. エージェントがツールを数十回使い、不具合やニュアンスを発見する
3. エージェントがツールの説明を書き直す
4. 新しい説明を使った後続エージェントのタスク完了時間が40%短縮
MCPサーバーを公開している場合、ツールの説明文をLLMに改善させるプロセスを一度試す価値がある。エージェントが実際にツールを使うことで、人間には見えないエッジケースを発見できる。
検索戦略
リサーチタスクの精度はクエリの質に直結する。原文が挙げている検索の知見を整理する。
広くから狭くへ
エージェントは長く具体的なクエリを投げがちである。その結果、検索結果が少なくなる。Anthropicのチームはこの傾向をプロンプトで矯正した。
推奨する検索フロー:
1. 短く広いクエリで全体像を把握する
2. 得られた情報をもとに方向性を評価する
3. 段階的に焦点を絞り込む
これは人間のリサーチと同じ手順である。最初から詳細を狙うのではなく、まず地図を描いてから目的地に向かう。
思考モードの活用
リードエージェントはExtended Thinkingを使い、以下を計画する。
- どのツールがタスクに適しているか
- クエリの複雑さとサブエージェントの数
- 各サブエージェントの担当範囲
サブエージェントはInterleaved Thinkingを使い、ツールの結果を受け取るたびに以下を評価する。
- 結果の品質は十分か
- 情報にギャップはないか
- 次のクエリをどう修正すべきか
努力量のスケーリング
クエリの複雑さに応じたリソース配分ルールをプロンプトに埋め込んでいる。
| クエリの種類 | サブエージェント数 | ツール呼び出し数 |
|---|---|---|
| 単純な事実確認 | 1 | 3-10回 |
| 比較・対照 | 2-4 | 各10-15回 |
| 複雑なリサーチ | 10以上 | 明確な分担で並列実行 |
明示的なガイドラインがないと、単純な質問にも大量のリソースを投入してしまう。初期バージョンで頻発した問題である。
並列化の効果
初期のエージェントは逐次的に検索を実行していた。Anthropicは2種類の並列化を導入した。
- リードエージェントが3〜5体のサブエージェントを同時に起動する
- 各サブエージェントが3つ以上のツールを同時に呼び出す
この変更により、複雑なクエリのリサーチ時間が最大90%短縮された。
評価手法
マルチエージェントシステムの評価は、従来のAI評価と異なる難しさがある。同じ入力でも、エージェントが異なる経路を辿って正解に到達することがある。「正しい手順」を事前に定義できない。
小さく始める
Anthropicのチームは約20件のクエリでテストを開始した。初期段階ではプロンプトの変更が30%から80%への成功率向上をもたらすほどのインパクトを持つ。数百件の大規模評価を構築する前に、少数で十分に傾向がつかめる。
「大規模な評価セットがないとテストできない」と思い込み、評価の構築自体を先延ばしにするチームは多い。20件でも始めれば、低い果実を確実に拾える。
LLM-as-Judge
リサーチの出力は自由形式テキストであり、プログラム的な正誤判定が難しい。Anthropicは以下の基準でLLMジャッジを使っている。
| 評価基準 | 内容 |
|---|---|
| 事実の正確性 | 主張がソースと一致しているか |
| 引用の正確性 | 引用元が主張と対応しているか |
| 網羅性 | 要求された側面をすべてカバーしているか |
| ソースの質 | 一次情報を二次情報より優先しているか |
| ツール効率 | 適切なツールを妥当な回数使ったか |
単一のLLM呼び出しで0.0〜1.0のスコアとPass/Failを出力させる方式が、複数ジャッジ方式よりも一貫性が高く、人間の判断と整合したと報告している。
人間による評価
自動評価では発見できない問題も存在する。Anthropicの人間テスターは、初期バージョンでSEO最適化コンテンツファームを優先し、学術PDFや個人ブログを軽視する傾向を発見した。この発見に基づき、プロンプトにソース品質のヒューリスティクスを追加して対処した。
実務への示唆
原文の知見を、自分のプロジェクトに適用する観点で整理する。
すぐに取り入れられること
- MCPサーバーを運用しているなら、LLMにツールを使わせて説明文を改善させる手法は低コストで試せる
- エージェントに「簡単な質問には少ないリソース、複雑な質問には多いリソース」というガイドラインを与えるだけで、過剰なリソース消費を防げる
- 20件のテストケースでもプロンプト改善のフィードバックループを回せる
アーキテクチャ上の考慮点
- マルチエージェントが有効なのは、並列化可能・大量の情報源・複雑なツール連携が必要なタスクに限られる
- コーディングのように依存関係が多いタスクには、現時点では不向きである
- トークンコストが15倍になることを前提に、費用対効果を見積もる必要がある
プロンプト設計で意識すべきこと
- 厳格なルールよりもヒューリスティクスを植え付ける
- 人間の熟練研究者の手順をプロンプトに符号化する
- 副作用を事前に想定し、ガードレールを明示的に設定する
マルチエージェントシステムでは、リードエージェントへの小さな変更がサブエージェントの挙動を予測不能に変えることがある。変更の影響範囲は単一エージェントの場合よりも広い。
まとめ
Anthropicのブログ記事から得られる主要な教訓を整理する。
- マルチエージェントはリサーチのように並列性が高いタスクで真価を発揮する。単体エージェント比で90.2%の性能向上という数値がそれを裏付ける
- トークン使用量がパフォーマンスの80%を説明する。マルチエージェント構成は「トークンを効果的に使い切る仕組み」でもある
- ツール設計はエージェントの性能に直結する。LLMによるツール説明の改善でタスク完了時間が40%短縮された
- 評価は小さく始める。20件のテストケースで十分にフィードバックループを回せる
- プロトタイプと本番の間には大きな溝がある。エラーの複合性、ステートフルな実行、デプロイ戦略といったエンジニアリング課題が待っている
- プロンプト設計は「厳格なルール」ではなく「協働のフレームワーク」として考える