マルチエージェントリサーチシステムの構築方法

原文: How we built our multi-agent research system (Anthropic Engineering Blog, 2025年6月13日)

著者: Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford

概要

本記事では、Anthropicが開発したClaudeのResearch機能について詳細に解説します。これは、Web、Google Workspace、各種インテグレーションを横断して複雑な情報収集を可能にするマルチエージェントシステムです。

主要パフォーマンス指標

アーキテクチャとシステム設計

マルチエージェント構造

システムはオーケストレーター・ワーカーパターンを採用しています：

• リードリサーチャーエージェント: クエリを分析し、戦略を立て、サブエージェントを生成
• 専門サブエージェント: 並列で動作し、異なるリサーチ側面を探索
• 引用エージェント: ドキュメントを処理し、具体的な引用箇所を特定

リードリサーチャーのワークフロー

1. アプローチを検討し、計画をメモリに保存
2. 特定のリサーチタスクを持つ専門サブエージェントを作成
3. サブエージェントの進捗を監視
4. 結果を統合し、追加リサーチの必要性を判断
5. 発見に基づいて戦略を洗練

サブエージェントのワークフロー

1. 独立したWeb検索を実行
2. インターリーブ思考を使用してツール結果を評価
3. 発見をリードリサーチャーに返却

コンテキスト管理戦略

• コンテキストウィンドウが200,000トークンを超える前に、エージェントはリサーチ計画を外部メモリに保存
• マルチターン会話中の情報損失を防止
• 連続性を維持しながらクリーンなコンテキストで新しいサブエージェントを生成可能

プロンプトエンジニアリングの8つの原則

1. エージェントのように考える

「プロンプトを反復改善するには、その効果を理解する必要がある」

チームはAnthropicのコンソールを使用してシミュレーションを構築し、ステップバイステップでエージェントの動作を観察しました。これにより以下のような失敗モードが明らかになりました：

• 十分な結果があるにもかかわらず継続するエージェント
• 冗長なクエリ
• 不適切なツール選択

2. オーケストレーターに委任を教える

各サブエージェントには以下が必要です：

• 明確な目標
• 出力フォーマットの仕様
• ツールとソースのガイダンス
• タスク境界の定義

失敗例: 「半導体不足を調査せよ」という単純な指示ではサブエージェントが誤解し重複が発生。あるサブエージェントは2021年の自動車チップ危機を探索し、他のエージェントは2025年のサプライチェーン検索を重複して行いました。

3. クエリの複雑さに応じて労力をスケール

リソース配分の明示的なガイドライン：

4. ツール設計と選択の重要性

「エージェント・ツールインターフェースは、人間・コンピュータインターフェースと同様に重要である」

実装要件：

• まず利用可能なすべてのツールを確認
• ユーザーの意図に合わせてツール使用をマッチング
• 汎用ツールよりも専門ツールを優先
• 明確で区別可能なツール説明

MCPサーバーはツールの可視性に課題をもたらし、明示的なヒューリスティックが必要です。

5. エージェントに自己改善させる

Claude 4モデルは障害を診断し、プロンプトの改善を提案できます。ツールテストエージェントを作成し：

• 欠陥のあるツールの使用を試行
• 障害を避けるためにツール説明を書き換え
• ニュアンスを特定するためにツールを数十回テスト
• 結果: タスク完了率が40%向上

6. 広く始めてから絞り込む

検索戦略は熟練した人間のリサーチを模倣します。まず全体像を把握し、それから具体的に掘り下げます。

エージェントは自然と過度に長く具体的なクエリをデフォルトとし、結果がほとんど返ってきません。

解決策: 広いクエリから始め、発見を評価し、徐々に焦点を絞るようにエージェントをプロンプト。

7. 思考プロセスをガイドする

拡張思考モードは以下のための制御可能なスクラッチパッドとして機能：

• アプローチの計画
• ツール適合性の評価
• クエリの複雑さとサブエージェント数の決定
• サブエージェントの役割定義

サブエージェントはツール結果の後にインターリーブ思考を使用して品質を評価し、ギャップを特定します。

8. 並列ツール呼び出し

2つの並列化アプローチ：

1. リードエージェントが3〜5のサブエージェントを同時に起動（逐次ではなく）
2. サブエージェントが3つ以上のツールを並列で使用（順次ではなく）

結果: 複雑なクエリで最大90%の時間削減

戦略的アプローチのまとめ

「私たちは熟練した人間がリサーチタスクにどうアプローチするかを研究し、これらの戦略をプロンプトにエンコードしました。難しい質問を小さなタスクに分解する、ソースの品質を慎重に評価する、新しい情報に基づいて検索アプローチを調整するといった戦略です。」

評価手法

3つの評価戦略

1. 少数サンプルテストアプローチ

• 実際の使用パターンを代表する約20のテストクエリから開始
• 初期開発の変更で30〜80%の成功率向上という劇的な効果
• 大きな効果サイズにより最小限のテストケースで検出可能
• 推奨: 遅らせずに即座に評価を開始

2. LLM-as-Judge評価

単一のLLM呼び出しで評価するルーブリック基準：

出力: 0.0〜1.0のスコアと合格/不合格の評価。特に明確な答えがあるテストケース（例：「R&D予算トップ3の製薬会社をリスト」）で人間の判断と最も一致。

3. 人間による評価

自動化では見逃されるエッジケースを捕捉：

• 珍しいクエリでの幻覚回答
• システム障害
• 微妙なソース選択バイアス

発見: 初期のエージェントは、学術PDFや個人ブログなどの権威あるソースよりもSEO最適化されたコンテンツファームを一貫して選択していました。

解決策: プロンプトにソース品質ヒューリスティックを追加。

パフォーマンス分析

トークン使用量の内訳

「BrowseComp評価（ブラウジングエージェントが見つけにくい情報を特定する能力をテスト）において、3つの要因がパフォーマンス分散の95%を説明しました。」

要因の寄与：

• トークン使用量: 80%
• ツール呼び出し回数: 寄与要因
• モデル選択: 寄与要因

「最新のClaudeモデルはトークン使用の大きな効率乗数として機能します。Claude Sonnet 4へのアップグレードは、Claude Sonnet 3.7でトークン予算を2倍にするよりも大きなパフォーマンス向上をもたらします。」

トレードオフと制限

マルチエージェントシステムが優れる場面:

• 高度な並列化タスク
• 単一コンテキストウィンドウを超える情報
• 多数の複雑なツールとの連携

適さない場面:

• すべてのエージェントがコンテキストを共有する必要があるタスク
• 高度に依存するエージェント間調整
• ほとんどのコーディングタスク（並列化可能なコンポーネントが少ない）
• リアルタイムのエージェント調整と委任

運用と本番環境の課題

状態管理

「エージェントは長期間実行され、多くのツール呼び出しにわたって状態を維持できます。」

必要な要素：

• 耐久性のあるコード実行
• 完全な再起動なしのエラー回復
• グレースフルな障害処理のためのモデルインテリジェンス
• 決定論的なセーフガード（リトライロジック、チェックポイント）

デバッグアプローチ

「エージェントは動的な決定を行い、同一のプロンプトでも実行間で非決定論的です。」

解決策: 障害を体系的に診断するための完全な本番トレーシング。高レベルの観測性で監視：

• エージェントの決定パターン
• インタラクション構造
• ユーザープライバシーの維持（会話内容の監視なし）

デプロイ戦略

「レインボーデプロイメント」アプローチで実行中のエージェントへの影響を防止：

• 古いバージョンから新しいバージョンへ徐々にトラフィックを移行
• 両バージョンを同時に実行
• コード変更による既存エージェントの破損を防止

同期 vs 非同期実行

現在のアプローチ: 同期（リードエージェントがサブエージェント完了を待機）

制限:

• 情報フローのボトルネック
• リードエージェントは実行中のサブエージェントを制御できない
• 単一サブエージェントの遅延がシステム全体をブロック

システム比較：シングルエージェント vs マルチエージェント

例：S&P 500 IT取締役会メンバータスク

動的検索の優位性

ユースケースの分布

Clioエンベディング分析による上位のResearch機能使用カテゴリ：

付録：追加の実装パターン

状態変更エージェントのエンドステート評価

ターンごとの検証ではなく、正しい最終状態が達成されたかを評価。エージェントが同じゴールへの代替パスを見つける可能性を認識。複雑なワークフローでは、すべての中間ステップを検証するのではなく、離散的なチェックポイントを使用。

長期会話管理

エージェントは完了したワークフェーズを要約し、進む前に外部メモリに情報を保存。コンテキスト制限に近づくと、ハンドオフを通じて連続性を維持しながらクリーンなコンテキストで新しいサブエージェントを生成。

サブエージェント出力アーティファクトシステム

特定の結果タイプについて、サブエージェント出力がメインコーディネーターをバイパスし、忠実性とパフォーマンスを向上。専門エージェントが軽量なコーディネーター参照付きで独立して永続する出力を作成。

利点:

• マルチステージ処理中の情報損失を防止
• 会話履歴コピーからのトークンオーバーヘッドを削減
• 構造化出力（コード、レポート、可視化）に特に効果的

主要な洞察と結論

コアな発見

「マルチエージェントシステムが機能するのは、主に問題を解決するのに十分なトークンを消費するのに役立つからです。」

プロダクションギャップ

「AIエージェントを構築する際、最後の1マイルがしばしば旅路の大部分になります。開発者マシンで動作するコードベースは、信頼性の高いプロダクションシステムになるために大幅なエンジニアリングを必要とします。」

エラーの複合

「エージェントシステムにおけるエラーの複合的性質は、従来のソフトウェアでは軽微な問題がエージェントを完全に脱線させる可能性があることを意味します。1つのステップの失敗により、エージェントはまったく異なる軌道を探索し、予測不可能な結果につながる可能性があります。」

実世界への影響

ユーザーは、Claudeが以下の点で役立ったと報告：

• 考慮していなかったビジネス機会の発見
• 医療の複雑さのナビゲート
• 技術的なバグの解決
• 発見されたリサーチの繋がりによる数日分の時間節約

技術インフラストラクチャに関する注記

使用ツール

• Anthropic Console（プロンプト反復/観察）
• MCPサーバー（Model Context Protocol）
• 拡張思考モード
• インターリーブ思考
• 外部メモリ/ファイルシステム

モデル構成

参考文献とドキュメント

本記事で参照されているリソース：

• BrowseComp評価フレームワーク（OpenAI）
• オープンソースプロンプトを含むAnthropic Cookbook
• 拡張思考ドキュメント
• インターリーブ思考ドキュメント
• Model Context Protocol入門

この記事はAnthropic Engineering Blogからの翻訳です。