GVATECHブログ
💐

Anthropicのリサーチエージェント開発の工夫が知見の塊だった

に公開

2025年6月13日にAnthropicが How we built our multi-agent research system というブログ記事を公開しました。

ClaudeのResearch機能の開発の中で得られた、AIエージェント開発における実践的な知見が詰まったものとなっており大変興味深い内容でした。ClaudeのResearch機能とは、ChatGPTやGeminiのDeep Researchに相当する機能です。

また、このブログの公開と合わせて、anthropic-cookbookにてこのリサーチエージェントで利用されていると想定されるプロンプトが公開されています。(実際のプロダクト環境のプロンプトは、ここで公開された内容とは少し異なっているかもしれません。しかし、ブログ記事を読む限り、概ね公開された内容のプロンプトが稼働しているものと推測できます。)

https://www.anthropic.com/engineering/built-multi-agent-research-system
https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents/prompts

本記事では、Anthropicのブログ記事とプロンプトのサンプルも合わせて、特に勉強となった部分に焦点を絞り、その内容を記載します。

特に以下の3つの観点からポイントを整理します。

  • プロンプト設計
  • アーキテクチャ
  • 評価

Claude Researchエージェントの構成概要

先ずは前提となるClaude Research機能のエージェント構成についてです。

以下の図の通り、リードエージェントがサブエージェントを従えて、調査タスクを並列で実行するオーケストレーターワーカーパターンによるマルチエージェント構成となっています。


画像引用: Anthropic - How we built our multi-agent research systemより

リードエージェントは複数のサブエージェントに対する指示と調査の委譲を、サブエージェントはWeb検索などのToolを利用した調査を、それぞれ行うような構成となっています。

より具体的には、「引用エージェント」も加えた3つのエージェントで構成されているようです。これらのエージェントは調査プロセスのフローにおいて以下のように機能しています。


記事内容から筆者にて作成した調査プロセスのワークフロー(概要)

まずリードエージェントが指揮を取り、サブエージェントは各種調査タスクを実行、最後に引用エージェントがリードエージェントがまとめた調査結果へ引用元を付与する流れとなっています。

上述のanthropic-cookbookでは、それぞれ3つのエージェントのプロンプトが公開されています。

ここからはプロンプトの内容も踏まえて、AnthropicのResearchエージェントシステム開発における具体的な知見を紹介していきたいと思います。

プロンプト設計

anthropic-cookbookで公開されたプロンプトからは勿論、ブログ記事からもエージェントを構成するプロンプトに対する工夫が多数見受けられました。

ここでは、大きく分けて以下2つの観点からこれらの工夫を見ていきます。

  • 優れたリサーチャーの経験則を再現
  • エージェント動作の適切な制御

優れたリサーチャーの経験則を再現

プロンプトについて、厳格なルールを記述するのではなく、優れたリサーチャーの経験則を再現することに重点をおいて設計されているようです。

質問タイプに応じた検索を行う

リードエージェントのプロンプトでは、ユーザーの質問の種類に応じて検索アプローチを使い分けるように指示されています。

最初に、リードエージェントはユーザーの質問について、以下のいずれの質問タイプに該当するかを判断します。

No 質問タイプ 説明 質問例
1 深さ優先型質問 同一の問題に対して多角的な視点からの検討が必要な質問 2008年の金融危機の真の原因は何か?
2 幅優先型質問 問題が明確かつ独立した複数のサブ質問に分解可能な質問 北欧3ヵ国の経済システムを比較せよ
3 直接的な質問 単一の焦点に絞った調査または単一リソースの取得によって回答可能な質問 現在の東京の人口は何人か?

続いて、質問タイプに応じた調査方法をサブエージェントに指示します。

1. 深さ優先型質問

深さ優先型質問の場合は、異なる視点から調査を走らせることが指示されています。
以下、実際のプロンプト本文からの抜粋です。

* **深さ優先クエリの場合**- 3~5種類の異なる方法論的アプローチまたは視点を定義します。
- 分析を充実させるための具体的な専門家の見解や根拠となる情報源を列挙します。
- 各視点が中核となる質問に対してどのように独自の洞察をもたらすかを計画します。
- 異なるアプローチから得られた知見をどのように統合するかを明示します。
- 例:「肥満の原因は何か」という質問に対しては、遺伝的要因、環境的影響、心理的側面、社会経済的パターン、生物医学的証拠といった観点から調査するエージェントを設計し、これらの情報を統合して優れた回答を作成する方法を概説します。

2. 幅優先型質問

幅優先型質問の場合は、明確に分離された内容の調査を複数走らせることが指示されています。

* **幅優先クエリの場合**- クエリに答えるために独立して調査可能なすべての異なるサブ質問またはサブタスクを列挙します。
- クエリを包括的に回答するために最も重要なサブ質問や視点を特定します。クエリが明確に分かれている構成要素があり、少数のエージェントでは効率的に処理できない場合にのみ追加のサブエージェントを作成します。あらゆる可能性に対してサブエージェントを作成するのではなく、本質的に重要なものに焦点を当てます。
- これらのサブタスクを重要度と予想される調査の複雑さに基づいて優先順位付けします。
- サブトピック間の重複を防ぐため、各サブトピックの境界を極めて明確かつ簡潔に定義します。
- 得られた知見をどのように統合して一貫性のある全体像を構築するかを計画します。
- 例:「EU加盟国の税制を比較する」という質問に対しては、まずEU加盟国の現行リストを取得するサブエージェントを作成し、次に各国の税制を比較する際に有効な指標や要因を検討します。その後、バッチ処理ツールを使用して、北欧、西欧、東欧、南欧の主要国についてこれらの指標と要因を調査する4つのサブエージェントを実行します。

3. 直接的な質問

直接的な質問の場合は、シンプルに直接的に調査することが指示されています。

* **単純なクエリの場合**- 回答に至る最も直接的で効率的な道筋を特定します。
- 基本的な事実調査が必要か、それとも軽微な分析が必要かを判断します。
- 回答に必要な具体的なデータポイントや情報を明示します。
- サブエージェントが参照すべき最も関連性が高い情報源を特定し、このクエリの事実確認に複数の情報源が必要かどうかを検討します。
- 回答の正確性を確保するための基本的な検証方法を計画します。
- サブエージェントがこの質問をどのように調査すべきかを詳細に記述した、極めて明確なタスク説明を作成します。

質の良い情報源を優先する

回答の情報源については、 原典を重視すべきであり、信頼性の低い情報の扱いには注意するよう記載されています。

例えば、リードエージェントのプロンプトではニュースまとめサイトよりも原典を優先してくださいと指示されています。

また、サブエージェントのプロンプトでは、以下のような情報については質が劣る可能性があり、取り扱いに注意すべきであると明記されています。

  • ニュースまとめサイト - 原典ではなく二次情報
  • 推測記事 - 「〜かもしれない」「〜の可能性がある」という表現が多い
  • マーケティング色の強い記事
  • 匿名情報や未確認の報告
  • 恣意的に選択されたデータ

柔軟にアプローチを変更する

リードエージェントおよびサブエージェントの双方において、調査から得られた結果を基に柔軟で適切なアプローチを行うことが指示されています。

リードエージェントのプロンプトでは、以下のようにタスク実行から得られた知見を元に柔軟に検索計画を変更することが指示されています。

* 実行過程全体を通じて:
- ユーザーのクエリ回答に向けた進捗状況を継続的に監視します。
- タスクから得られた知見に基づき、検索計画とサブエージェント委任戦略を適宜更新します。
- 新たな情報に柔軟に対応します - 結果を分析し、ベイズ推定を用いて事前分布を更新した上で、次の行動を慎重に検討してください。
- 時間制約と効率性に応じて調査深度を調整します - 時間制限が迫っている場合や調査プロセスが既に長時間かかっている場合は、さらなるサブエージェントの配備を避け、直ちに出力レポートの作成作業を開始してください。

ベイズ推定を用いて事前分布を更新した上で という表現は、MLエンジニアらしい良い表現ですね。

また、時間制限が迫っている場合には、追加のエージェントの配置を抑制しています。
プロンプトからは読み取れないため推測ではありますが、実際の実装では、プロセスの中でリードエージェントが呼び出される度に経過時間が渡されている可能性が考えられます。

一方、サブエージェントのプロンプトでは、OODAループの中で柔軟に検索行動を行うべきであることが記載されています。

優れたOODA(観察、状況判断、決定、行動)ループを実行する:
(a) これまでに収集された情報、タスクを達成するためにまだ収集する必要がある情報、現在利用可能なツールを観察する
(b) どのツールとクエリが必要な情報を収集するのに最適かを判断し、これまでに学んだことに基づいて信念を更新する
(c) 特定の方法で特定のツールを使用するという情報に基づいた十分に検討された決定を下す
(d) このツールを使用して行動する

ここでは、「PDCA(Plan-Do-Check-Act)」ではなく「OODA(Observe-Orient-Decide-Act)」が利用されている点が面白いと感じました。

PDCAは「PLAN(計画)」から始まりますが、OODAは「Observe(観察)」から始まります。試行のループをPDCAで表現する場合と、OODAで表現する場合を比較した際に、精度の差があるのかは分かりませんが、「状況をよく見てから柔軟に行動する」という表現を行うにあたっては、OODAを利用した方が自然に表現できるものと思います。

エージェント動作の適切な制御

ブログ記事によると、開発初期のエージェントは、簡単なクエリに対して50個のサブエージェントを生成したり、存在しないソースを延々と探し回ったり、様々な問題行動を起こしていたようです。

これらに対する対策もプロンプトやブログ記事から読み取ることができます。

サブエージェント・Toolの実行数制御

サブエージェントおよびToolの実行数の制限が、プロンプト内では明確に制限されています。

プロンプトの実装戦略について「厳格なルールを記述するのではなく、優れたリサーチャーの経験則を再現する」と前述しましたが、エージェントの暴走を制御する部分に関しては、厳しくルールで制限している印象を受けました。

サブエージェント数の制御

リードエージェントのプロンプトでは、通常は3つのサブエージェントをデフォルトとして使用することを明示しつつも、 質問の複雑さに応じて具体的な推奨数を明示しています。

質問の複雑さ 推奨サブエージェント数 質問例
簡単/直接的 1つ 今年の税務申告締切はいつ?
標準的 2-3つ トップ3のクラウドプロバイダーを比較(各プロバイダーに1つずつ)
中程度 3-5つ AIのヘルスケアへの影響を分析(規制、臨床、経済、技術の各側面)
高い 5-10つ(最大20) フォーチュン500のCEOの出身地と年齢(10のサブエージェントで各50人を担当)

合わせて、20以上のサブエージェントを作成してはいけないということも注記されています。プロンプトは、多数のエージェントより、少数でもより能力の高いサブエージェントを優先するように誘導しています。

Tool実行数の制御

サブエージェントのプロンプトでは、Toolの実行数についても上限がしっかりと定められています。

項目 制限数 詳細
最大 20回 絶対的な上限
最小 5回 推奨値。複雑な質問の場合でも最大10個ほどを推奨。

また、Toolの実行数15回、もしくは情報源が100個を超えた時点で、 直ちに検索を終了することが指示されています。

加えて、「同じToolに対して全く同じクエリを繰り返し使用してはならない。これはリソースの無駄遣いであり、新しい結果は返されない。」と厳しい言葉で、Toolが無駄に実行されることを防いでいます。

プロンプト自体もエージェントに改善させてエラー低減

ブログ記事からは、Claude 4で構成されたテスト用エージェントをプロンプト自動修正器として利用することで、Tool利用時の失敗を低減する試みを行っていることも読み取れます。

Claude 4モデルは、優れたプロンプトエンジニアとして機能することが確認されました。適切なプロンプトと失敗したことを伝えると、エージェントの不具合原因を診断し、改善策を提案することが可能です。

Toolのテスト用エージェントがToolを様々な観点からテストしつつ、発生したエラーに応じてMCPサーバーが提供するToolのdescriptionを修正するようなことを行っているようです。

さらに私たちは、不具合のあるMCPツールが与えられた場合、そのツールを使用しようと試みた後、失敗を回避するためにツールの説明を書き換える「ツールテストエージェント」を開発しました。このエージェントが数十回にわたってツールをテストした結果、重要なニュアンスの違いやバグを発見することができました。

アーキテクチャ

記事内ではエージェントのプロンプト設計に留まらず、アプリケーションやインフラ層における工夫が書かれている点も非常に印象的でした。

サブエージェントとToolの並列実行による速度向上

開発初期のエージェントは全て逐次処理で検索を実行しており、非常に時間を要することが課題になっていたようです。そこで以下のような並列化の対策を行うことで最大90%の時間短縮に繋がったとのことです。

  1. リードエージェントが3~5個のサブエージェントを並列に起動
  2. サブエージェントが3個以上のToolを並列して利用

リードエージェントのプロンプトでは use_parallel_tool_calls というセクションが設けられており、サブエージェントを並列で実行するよう強調されています。

<use_parallel_tool_calls>
処理効率を最大化するため、複数の独立した操作を実行する必要が生じた場合、各ツールを逐次的に呼び出すのではなく、可能な限り同時に実行してください。
サブエージェントを同時に動作させるには、ツール呼び出しを並列化してください。
研究開始時に複数のサブエージェントを作成する場合(通常は3つのサブエージェントを同時に稼働させる場合)には、並列ツール呼び出しを必ず使用してください。
単純な問い合わせの場合を除き、その他のすべての問い合わせについては、必要な初期計画や調査はご自身で実施した後、複数のサブエージェントを並列実行してください。
複雑なツール呼び出しはサブエージェントに任せ、代わりにサブエージェントの並列実行を効率的に行うことに注力してください。
</use_parallel_tool_calls>

サブエージェントのプロンプトでも同じく use_parallel_tool_calls というセクションが設けられており、Toolを並列して実行することを優先するよう強調されています。

<use_parallel_tool_calls>
最大限の効率性を確保するため、複数の独立した操作を実行する必要がある場合は、逐次的にではなく同時に2つの関連ツールを呼び出すこと。
ウェブ検索などのツールは、個別に使用するのではなく、並列で呼び出すことを優先すること。
</use_parallel_tool_calls>

また、記事内からはサブエージェントの非同期実行化に対する意欲も記述されていました。現在、リードエージェントは走らせたサブエージェント群の処理完了を待つ同期実行を行っているようですが、非同期化して更に並列度を上げることも考えているようです。

メモリ活用によるトークン上限に制限されない処理継続

長期的な会話ターンが続く場合、LLM実行におけるコンテキストウィンドウが上限に収まらなくなります。

このような状態を回避するために、外部記録媒体(メモリ)で各処理フェーズで出力された結果の管理を行っているようです。具体的には以下の記述が記事内にありました。

エージェントが完了した作業フェーズを要約し、重要な情報を外部メモリに保存してから次のタスクに進むパターンを実装しました。
コンテキスト制限が近づくと、エージェントはクリーンなコンテキストを持つ新しいサブエージェントを生成しながら、慎重なハンドオフによって継続性を維持できます。

詳細なロジックは分かりませんが、処理の中でコンテキスト量が多くなってきた場合には、サブエージェントにこれまでのコンテキストをそのまま渡さず、メモリから要約された内容を取得するような実装が行われているのではないかと推測できます。

また、以下の記述からサブエージェントの出力についても、原則的にメモリに記録してリードエージェントには、軽量な参照(要約と記録の保管場所のことか?)のみを渡すようにしているようです。

サブエージェントの出力をファイルシステムに分散させることで「伝言ゲーム」を最小限に抑えます。

サブエージェントはツールを呼び出して作業を外部システムに保存して、軽量な参照をコーディネータに返します。

レインボーデプロイメントによるサービス継続性の担保

エージェントシステムは、ステートフルな状態で長い時間の処理が継続します。
そのため、既に走っているプロセスを停止することなく基盤をアップデートする必要があり、レインボーデプロイメントを採用することで、新旧バージョンを同時に稼働させながら段階的に移行するデプロイを行っているようです。

https://brandon.dimcheff.com/2018/02/rainbow-deploys-with-kubernetes/

Extended Thinkingの活用

テストの結果、Extended Thinkingモードの利用は、エージェントの指示の遵守、論理的思考の精度、効率性を向上させることが分かったようです。

https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking

プライバシー保護下で可観測性を実現

一般的に、エージェントは動的な判断を行いながら行動するため、同じプロンプトであっても実行ごとに異なる結果を返すことがあります。そのため、エラー時の原因究明に備えて、トレースを記録して可視化することが重要になります。

Anthropicではユーザーとエージェントの会話を閲覧することができないプライバシーが担保された状態で、エージェントの意思決定パターンやエージェント間のインタラクションを監視できるような環境を設けていることが記事から読み取れます。

評価

リサーチエージェント開発における評価方法についても、ブログ記事内では言及されています。

少ないサンプルから評価を始めること

エージェントの開発の初期段階においては、簡単に成果が得られる施策が豊富にあり、プロンプトの細かい調整だけでも非常に効果的な影響を与えることが多い傾向にあるとのことです。

そのため、最初から数百のテストケースを用意して評価に時間をかけるのではなく、わずか数個のテストケースから開発を始めて迅速に調整を行う開発方法が適しているとのことです。

ClaudeのResearch機能では、約20個のクエリセットから開発を開始したようです。

LLM-as-judgeの活用

リサーチエージェントの評価においては、LLMによる評価(LLM-as-judge)も利用したとのことです。
具体的な評価の指標は以下の通りです。

項目 説明
factual accuracy(事実の正確性) 主張は情報源と一致しているか
citation accuracy(引用の正確性) 引用された情報源は主張と一致しているか
completness(完全性) 要求されたすべての側面が網羅されているか
source quality(情報源の質) 低品質の二次情報源ではなく一次情報を利用しているか
tool efficiency(Tool効率性) 適切なToolを適切な回数利用しているか

複数のLLMで構成された審査員で各要素を評価する実験も行ったようですが、結局のところ0.0~1.0のスコアリングと合否評価を出力する単一のプロンプトを用いた単一のLLM呼び出しによる評価が最も一貫性があり、人間の判断と一致していたとのことです。

終わりに

本記事では、AnthropicがClaude Research機能の開発を通じて得られたマルチエージェントシステムの知見について、プロンプト設計、アーキテクチャ、評価の3つの観点から整理しました。

直近、私もプロダクト機能開発において、AIエージェントを解決手段として検討することが多くなっています。こちらのAnthropicの工夫を参考にしたいと思います。

GVATECHブログ
GVATECHブログ

Discussion