2025年6月13日にAnthropicが How we built our multi-agent research system という記事を公開しました。Claudeの「Research」機能の開発過程で得られたマルチエージェントシステムの重要な知見をまとめている非常に有用な記事でした。

私自身も最近マルチエージェント構成の Deep Research 機能を実装する機会があり、この記事から多くのヒントを得ることができました。本記事では特に参考になった部分をまとめました。意訳している部分も多いので正確な内容を把握したい方はぜひ原文も確認していただければ幸いです。

本記事の構成

原文記事の構成とは少し違いますが以下の流れでまとめています。

前提条件: Research機能の基本構造
マルチエージェントシステムの強みと限界
Prompt Engineering のコツ
エージェントの効果的な評価方法
その他のトピックを簡単に

前提条件: Research機能の基本構造

まず最初に、Anthropicが実際に構築したマルチエージェントシステムがどのような仕組みなのかを少し説明します。この基本構造を把握することで、後述する実践的な知見やテクニックがなぜ重要なのか、どのような文脈で生まれたのかが理解しやすくなるかと思います。

AnthropicのResearch機能は、1人のリーダーエージェントが複数のサブエージェント (リサーチャーエージェント) を指揮する「オーケストレーター・ワーカーパターン」を採用しています。

リーダーエージェントがユーザーの質問を適切なサイズのサブタスクに分解し、サブエージェントに指示し調査させた上で、最後に調査内容を取りまとめて最終的な回答を生成します。

動作の流れをシンプルにまとめると以下の通りです。

ユーザー「2025年のAIエージェント企業について調べて」
    ↓
リーダー「了解しました。3つのチームに分けて調査します」
    ↓
サブエージェントA「スタートアップを調査」
サブエージェントB「大手企業の動向を調査」  ← 同時並行で動作
サブエージェントC「技術トレンドを調査」
    ↓
リーダー「各チームの結果を統合し、包括的な回答を作成します」

この構造は、私が以前紹介したDeerFlowに近いアプローチです。リーダーエージェントもサブエージェントも自律的に行動するため、真の意味でのマルチエージェントシステムとなっています。

https://github.com/bytedance/deer-flow

マルチエージェントシステムの強みと限界

マルチエージェントシステムは万能ではありません。特定のタスクでは驚異的な性能を発揮する一方で、明確な限界も存在します。Anthropicの記事では、実際の開発・運用経験を通じて見えてきた、マルチエージェントシステムの強みと限界について詳しく述べられていました。まずはそれらを見ていきましょう。

得意なタスクと苦手なタスク

マルチエージェントシステムには明確に得意なタスクと苦手なタスクが存在します。「多数の独立した調査を同時実行する」タスクでは圧倒的な強みを発揮する一方、「全員で1つの成果物を作り上げる」タスクにはまだ課題があります。

得意なタスク

並列処理可能な作業 (10社の財務分析を同時実行など)
膨大な情報量を扱うタスク (単一のコンテキストウィンドウでは処理不可能な量)
多様なツールを駆使する必要がある作業 (Google Drive確認、Slack検索、Web調査の組み合わせなど)

苦手なタスク

コーディング作業
- 本質的に並列化できる部分が限定的
- AIエージェント間のリアルタイム連携がまだ未成熟
全エージェントが同一情報を参照しながら進める必要がある作業
- 各エージェントが独立して動作するため、情報共有が困難

得意なタスクで強みを発揮する理由は、各サブエージェントが完全に独立して動作できるからです。各エージェントは他の進捗を気にすることなく担当タスクに集中でき、異なるツールや検索方法を使えるため、より多角的な調査が可能になります。

Anthropicの社内リサーチ評価では、リーダーにClaude Opus 4、サブエージェントにClaude Sonnet 4を使用したマルチエージェントシステムが、シングルエージェントのClaude Opus 4を90.2%上回るパフォーマンスを示しました。例えば「S&P500のIT企業の取締役を全員リストアップせよ」というタスクでは、マルチエージェントシステムがタスクをサブエージェントに分割して正しい答えを見つけた一方、シングルエージェントは (1人で検索を行う必要があり) 規定の時間内に正しい答えに辿り着けなかったとのことです。

パフォーマンス向上の本質 = トークン量

マルチエージェントシステムが機能する主な理由は「問題を解決するために十分なトークンを費やすことを促すから」とのことです。

BrowseCompベンチマーク (ブラウジングエージェントが見つけにくい情報を探す能力を測定する評価基準) におけるパフォーマンス差の95%は以下の3つの要因で説明できるとAnthropicは報告しています。

80%: トークン使用量の差 (≒どれだけ思考したか)
15%: ツール使用回数と使用モデル

この発見は、Anthropicのアーキテクチャの妥当性を証明しています。作業を別々のコンテキストウィンドウを持つエージェント間で分散することで、並列推論のための容量を追加できるのです。つまり、複数のAIが同時に思考することで、単独では不可能な規模の思考を実現しています。

最大の課題: トークン消費量

マルチエージェントシステムの代償は大量のトークン消費です。

シングルエージェント: 通常のチャットの約4倍
マルチエージェント: 通常のチャットの約15倍

そのため「このタスクに投資する価値があるか」という費用対効果の判断が極めて重要になります。

なお、最新のClaudeモデルは同じトークン数でもより効率的に動作します。Anthropicによると、Claude Sonnet 4へのアップグレードは、Claude Sonnet 3.7でトークン数を2倍にするよりも大きなパフォーマンス向上をもたらしました。コスト最適化の観点では、トークンを増やすより新モデルへの移行が推奨されます。

実践的なPrompt Engineeringの8つのコツ

マルチエージェントシステムは、シングルエージェントシステムと比べて調整の複雑さが急速に増大します。この複雑さゆえに、初期のエージェントは単純なクエリに50ものサブエージェントを生成したり、存在しないソースを求めて無限にWeb検索を続けたり、過度な更新で互いに混乱させたりといった問題を抱えていました。

Anthropicは主にPrompt Engineeringによってこれらの課題を克服しました。各エージェントはプロンプトによって動作が決まるため、プロンプトの改善が行動の改善に直結したようです。記事ではその改善からAnthropicが学んだ8つのコツを紹介しています。(だいぶ意訳したので一応原文の見出しもつけておきます)

1. エージェントの気持ちになって考えよう (Think like your agents)

効果的なプロンプト改善には、AIがどのように考えて動作するかを理解する必要があります。Anthropicは実際のプロンプトとツールを使用してシミュレーションを作成し、以下のような典型的な失敗パターンを発見しました。

すでに十分な答えが得られているのに「念のため」と検索を継続する
シンプルな検索で済むところで、過度に長い検索ワードを使用する
状況に適さないツールを選択する

良いプロンプトを書くコツは「このプロンプトを読んだAIがどのように動作するか」を頭の中でシミュレーションできるようになることです。エージェントの「癖」や「思考パターン」を理解することで、改善すべきポイントが自然に見えてきます。

2. リーダーエージェントに仕事の振り方を教えよう (Teach the orchestrator how to delegate)

Anthropicのマルチエージェントシステムでは、リーダーエージェントが大規模タスクを分割し、サブエージェントに仕事を割り振ります。初期の実装では「半導体不足について調べて」のような簡潔な指示でしたが、これでは曖昧すぎて、1人は2021年の自動車チップ危機を調査し、残り2人は同じ2025年のサプライチェーンを調査するという非効率な重複が発生していました。

リーダーエージェントには、サブエージェントに対して以下を明確に伝える必要があることを理解させる必要がありました。

目的
出力フォーマット
使用すべきツール
担当範囲

3. タスクの規模に応じた適切な人員配置をさせよう (Scale effort to query complexity)

エージェントは「どの程度の戦力を投入すべきか」の判断が苦手です。そこでAnthropicは明確なルールを設定することで、簡単な質問に大規模なチームを投入するような無駄を排除しました。

簡単な事実確認 → AI 1人、ツール使用3〜10回
比較検討が必要 → AI 2〜4人、各自10〜15回のツール使用
複雑なリサーチ → AI 10人以上、明確な役割分担

4. ツールの設計と選択は非常に重要 (Tool design and selection are critical)

適切なツールの使用は非常に重要で、誤った選択は時に致命的な結果をもたらします。例えば、Slackにしか存在しない情報をWeb検索で探すエージェントは、最初から失敗が確定しています。

MCPサーバーによる外部ツールの増加により、この課題はさらに複雑化しました。Anthropicは以下の判断基準を設定しています。

最初に利用可能なツールを全て確認させる
ユーザーの意図に適合するツールを選択させる
広範な調査にはWeb検索を使用する
専門的なツールが存在する場合は優先的に使用させる

ツールの説明文が不適切な場合、AIは完全に誤った方向に進んでしまうため、各ツールには明確な用途と分かりやすい説明が不可欠です。

5. エージェントに自己改善をさせよう (Let agents improve themselves)

Claude 4は優秀なプロンプトエンジニアとして機能します。プロンプトと失敗例を提示すると、エージェントが失敗している理由を診断し、改善提案を生成できます。Anthropicはこの特性を活かして「ツールテストエージェント」を作成し、欠陥のあるMCPツールの改善を行わせました。

ツールテストエージェントは欠陥のあるMCPツールを実際に使用してみて、失敗を回避できるようツールの説明文を書き直します。数十回のテストを通じて、このエージェントがMCPツールの説明文を改善した結果、その説明文を使用した他のエージェントは、ほとんどのミスを回避できるようになり、タスク完了時間が40%短縮されました。

6. 広く始めて、徐々に絞り込ませよう (Start wide, then narrow down)

検索のやり方は研究のプロと同じように進めさせるのが良いでしょう。まず全体像を掴んでから、詳細を調べるという流れです。

当初のエージェントは「2025年第3四半期における東南アジア地域の半導体製造装置市場シェア」のような過度に具体的なクエリを使いがちでしたが、Anthropicは「半導体市場」→「アジア半導体」→「東南アジア製造装置」のように段階的に進めるよう指導しました。

7. AIに思考する時間を与えよう (Guide the thinking process)

拡張思考モードは、AIの思考プロセスを可視化し、より良い判断へと導くための強力なツールです。これを活用することで、エージェントが単に機械的に作業を繰り返すのではなく、戦略的に考えながら行動できるようになります。

リーダーエージェントの場合、作業開始前に戦略を練る時間を与えることが重要です。以下のような点を事前に考えさせます。

どのツールを使うべきか
何人のサブエージェントが必要か
役割分担をどうするか

サブエージェントの場合、インターリーブ思考機能を活用します。これはツールの実行結果が出るたびに立ち止まって考える機能で、結果が出るたびに以下を振り返ってから次の行動に移ります。

この結果の質はどうか
何が足りないか
次はどう進めるべきか

単純に次々とツールを使うのではなく、各ステップで思考を挟むことで、より適切な判断ができるようになるのです。

テストの結果、拡張思考の導入により指示への理解力、推論能力、効率性がすべて向上し、サブエージェントがあらゆるタスクにより効果的に適応できるようになりました。

8. 並列処理で高速化しよう (Parallel tool calling transforms speed and performance)

複雑なリサーチタスクでは、多数の情報源を調査する必要があります。しかし初期のエージェントは順次検索を行っていたため、処理速度が著しく遅くなっていました。そこでAnthropicは2種類の並列化を導入しました。

リーダーエージェントが3〜5人のサブエージェントを順番ではなく同時に起動
各サブエージェントが3つ以上のツールを同時に使用

従来は「検索1→結果待ち→検索2→結果待ち」という具合に時間がかかっていましたが、並列処理により複数の検索や調査を同時に実行できるようになりました。この変更により、複雑な調査の所要時間が最大90%短縮され、数時間を要していた作業が数分で完了するようになりました。

全般的なプロンプト戦略: 厳格なルールより良いヒューリスティクスを重視

Anthropicのプロンプト戦略は、厳格なルールではなく、良いヒューリスティクス (経験則) を教え込むことに焦点を当てています。

まず、熟練した人間がリサーチタスクにどのようにアプローチするかを研究し、これらの戦略をプロンプトに組み込みました。

難しい質問を小さなタスクに分解する
情報源の質を慎重に評価する
新しい情報に基づいて検索アプローチを調整する
深さ (1つのトピックを詳細に調査) と広さ (多くのトピックを並列に探索) のバランスを認識する

同時に、エージェントが制御不能になることを防ぐため、明示的なガードレールを積極的に設定しました。さらに、観察可能性とテストケースを備えた高速な反復ループに焦点を当てることで、継続的な改善を実現しました。

このアプローチにより、エージェントは固定的なルールに縛られることなく、状況に応じた柔軟な判断ができるようになりました。

エージェントシステムの効果的な評価方法

優れた評価は信頼性の高いAIアプリケーション構築に不可欠であり、マルチエージェントシステムでも例外ではありません。以下、Anthropicがマルチエージェントシステム開発で学んだ、実践的な評価方法を3つ紹介します。

小規模でもいいから今すぐ開始しよう

よくある誤解:「評価システムには数百個のテストケースが必要」

多くのAI開発チームは、大規模な評価システムでなければ意味がないと考えて、評価の作成を遅らせてしまいます。しかし、エージェント開発の初期段階では、小さな変更でも劇的な改善を生む可能性があります。改善余地が豊富にあるため、プロンプトの調整ひとつで成功率が30%から80%に向上することもあります。

このような大きな効果は、わずか数個のテストケースでも明確に観察できます。Anthropicも実際の使用パターンを代表する約20個のクエリから始めました。これらのクエリを頻繁にテストすることで、変更の影響を明確に確認できたのです。

100点の評価システムを作るのを待つより、60点でも今日から始めることが重要です。

LLM-as-judgeを活用しよう

リサーチの出力結果は自由形式のテキストであり、単一の正解が存在することはめったにないため、プログラムによる評価は困難です。このような場合、LLMによる評価 (LLM-as-judge) が適しています。

Anthropicは、LLM-as-judgeが以下のような基準に照らして各出力を評価する方式を採用しました。

事実の正確性 (主張が情報源と一致しているか)
引用の正確性 (引用された情報源が主張と一致しているか)
網羅性 (要求されたすべての側面がカバーされているか)
情報源の質 (二次情報源よりも一次情報源を使用しているか)
ツールの効率性 (適切なツールを合理的な回数使用したか)

複数の判定者で各要素を評価する実験も行いましたが、最終的には単一のLLM呼び出しで0.0〜1.0のスコアと合格 / 不合格の判定を出力する方法が、最も一貫性があり人間の判断と一致することが分かりました。

人間による評価も不可欠

自動評価がどれほど優秀でも、人間の「何か変だ」という直感は貴重です。

実例として、初期のエージェントは権威ある学術論文や個人ブログよりも、SEO最適化されたコンテンツファームを選択することがありました。人間のテスターがこの問題を発見し、プロンプトに情報源の品質に関するヒューリスティクスを追加することで解決しました。

このように、自動評価と人間の洞察を組み合わせることで、システムの盲点を発見できます。

その他のトピックを簡単に

Anthropicの記事にはこの他にも多くの有益なトピックが含まれていました。以下、要点のみを簡潔に紹介します。

本番環境での課題

エラーの複合的増大: 中断箇所からの再開機能で対処
デバッグの困難さ: 本番環境の完全トレースで解決
デプロイメント: レインボーデプロイメント (段階的展開) を採用
同期実行の限界: 将来は非同期実行へ

開発の現実

「最後の1マイル」問題: プロトタイプから本番環境への道のりは想像以上に遠い
成功の条件: 慎重なエンジニアリング、徹底的なテスト、細部へのこだわり、堅実な運用、チームの連携

追加テクニック

状態変更の評価: 最終結果のみ確認、中間ステップは問わない
長時間会話の管理: フェーズごとの要約とメモリへの保存
伝言ゲーム問題: サブエージェントが直接ファイルに出力

まとめ

Anthropicの記事で何度も述べられていましたが、マルチエージェントシステムは複雑で、多くの課題を抱えています。

しかし適切な設計と運用により、人間では不可能な規模の調査や分析を実現できる強力なツールとなることもまた事実です。

本記事で紹介したAnthropicの知見が皆様のAIエージェント開発の一助となれば幸いです。最後までお読みいただきありがとうございました😇

それではまた！

'25/06/17 追記

実際に使われているPromptとは違うかもしれませんが、以下のレポジトリにサンプル版のPromptを公開してくれているようです。

Discussion