Anthropicのマルチエージェント研究システム — Claude Researchを支える分業設計と9割向上の内訳

Anthropicのエンジニアリングブログに「How we built our multi-agent research system」という長尺記事が公開されました。Claude.aiの「Research」機能を支えるマルチエージェント構成を、設計判断・プロンプト原則・評価方法・本番運用の4軸で解剖した内容です。著者はJeremy Hadfield氏、Barry Zhang氏、Kenneth Lien氏、Florian Scholz氏、Jeremy Fox氏、Daniel Ford氏ら。Anthropicのアプリケーションエンジニアリングチームを横断した記事になっています。

ここではAnthropicの主張を一次引用で押さえつつ、Claude Codeや自前のエージェント基盤を組むときに「どこを真似て、どこを警戒すべきか」を日本語の判断材料に翻訳します。

マルチエージェントが必要だった理由 — リサーチは経路が決められない

リサーチの仕事は、最終形を最初に決められない点でほかのエージェントタスクと性格が違います。記事はこの性質を次のように表現しています。

"Research work involves open-ended problems where it's very difficult to predict the required steps in advance. You can't hardcode a fixed path for exploring complex topics, as the process is inherently dynamic and path-dependent."

固定の手順をプロンプトに焼き込んでもうまくいかないため、中間結果を見ながら方向を切り替える自走能力が求められます。同時に、コンテキスト窓に詰め込めない情報量も問題で、検索結果・参考資料・推論ログを単一のエージェントに集約すると、すぐに窓が破裂するか、ノイズで精度が落ちるかのどちらかになります。

この2つの圧力を同時に解くために選ばれたのが、オーケストレーター・ワーカー型のマルチエージェント構成です。Anthropicは検索のエッセンスを「圧縮(compression)」と捉え、サブエージェントを並列で走らせて、それぞれが自分の窓で探索したうえで、要点だけをリードエージェントに返す形を取りました。

従来のRAG(Retrieval Augmented Generation)との違いも明示されています。静的に上位N件を取り出して詰め込むのではなく、動的に次の探索を決めながら検索を多段に重ねる点が、リサーチ用途では効くという立場です。

アーキテクチャ — リードエージェントとサブエージェント、Citation担当の3層

Anthropicが公開している構成は、ざっくり次の3層に分かれます。

処理の流れは以下のとおりです。ユーザーがクエリを投げると、LeadResearcherがまず戦略を組み、必要なサブテーマを分解します。続いて3〜5本のサブエージェントを並列に生成し、それぞれが検索ツールとinterleaved thinking(ツール結果を見るたびに挟む思考ステップ)で探索します。Lead側はサブエージェントの返答を見て、追加の探索が必要かを判断し、満足したらリサーチループを抜けてCitationAgentに引き渡す、という構造です。

加えて、コンテキストが20万トークンを超える局面に備えて、研究計画を外部に保存するメモリ機構も組み込まれています。リード側が長尺の会話を続けても、戦略の整合性が失われないようにする仕掛けです。

このパターンの利点をAnthropicは次のようにまとめています。

"Subagents facilitate compression by operating in parallel with their own context windows, exploring different aspects of the question simultaneously before condensing the most important tokens for the lead research agent."

サブエージェントごとにツール・プロンプト・探索軌道が分離されているため、リード側の経路依存性が減り、独立した深い探索が並列で進む構図です。

Anthropicがエージェント設計の各層をどう論じているかは、エージェント向けツール設計の原則とAnthropicのContext Engineering論もあわせて読むと立体的になります。本記事の「サブエージェントを情報圧縮装置として使う」発想は、Context Engineering論で挙げられている4戦略の1つと地続きです。

9割向上の内訳 — トークン消費・ツール呼び出し・モデル選択の3因子

実数値で目を引くのは、Claude Opus 4をリード、Sonnet 4をサブエージェントに据えた構成が、単独のOpus 4より内部リサーチevalで90.2%上回ったという結果です。記事内で次のように記述されています。

"We found that a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval."

加えてBrowseCompベースの分析からは、性能のばらつきの95%が3因子で説明できることが判明しました。内訳はトークン消費80%、ツール呼び出し回数、モデル選択の順です。

"Token usage by itself explains 80% of the variance, with the number of tool calls and the model choice as the two other explanatory factors."

ここから引き出される結論はやや直球で、「マルチエージェントが効くのは、問題を解くのに十分なトークンを消費できるから」というものです。チャットUIの体験を1倍とすると、単独エージェントで約4倍、マルチエージェント構成では約15倍のトークンを使うという目安が示されています。

この数字が示しているのは、マルチエージェントは「賢さを増やす」のではなく「使えるトークン量を実質的に増やす」装置だという見方です。タスクの価値がそのトークン代を上回らない領域では費用対効果が崩れる、という制約が同時に立ちます。

並列化の効果ももう一段細かく言及されていて、Lead側のサブエージェント生成を並列にする層と、サブエージェント内でのツール呼び出しを並列にする層の二重並列を導入したことで、複雑クエリの所要時間が最大9割短縮したという報告も出ています。「数時間かかっていたリサーチが数分で済むようになった」という表現です。

プロンプト設計の8原則 — 「エージェントの気持ちで読む」が最初に来る

Anthropicが内部で固めたプロンプト設計の原則は、ヒューリスティック寄りで実装可能な粒度です。日本語で再構成すると次のとおりです。

3つ目の「クエリ複雑度に労力を合わせる」は実務的に重要です。記事では次のような目安が示されています。

• 事実調査:1エージェント+ツール呼び出し3〜10回
• 直接比較:2〜4サブエージェント+各10〜15回
• 複雑研究:10以上のサブエージェント

初期のLead側は、簡単なクエリにまで50本のサブエージェントを立ち上げたり、存在しないソースを延々と探したり、互いに過剰な更新通知を出して気を散らしたりといった失敗を起こしていたといいます。「クエリの重さに応じて手の広げ方を変える」というルールが、こうした暴走の制御に使われています。

4つ目の「ツール設計が成否を決める」点は、Anthropicが過去に書いたエージェント向けツール設計の原則とも噛み合っています。記事内では、ツールの説明文を改善したことで将来のエージェントのタスク完了時間が4割短縮した事例も挙がっています。

"This process for improving tool ergonomics resulted in a 40% decrease in task completion time for future agents using the new description."

5つ目に挙がっている「エージェント自身がプロンプトエンジニアを担う」は、Claude 4世代の特徴として目を引きます。失敗のtranscriptを読ませて、その上で改善プロンプトを書かせるサイクルが内部で回っているとのことです。

評価の組み立て方 — 小さく始める、LLM-as-judge、それでも人が要る

評価方法は「初手から作り込まない」立場が貫かれています。Anthropicは20件程度のクエリから始め、LLM-as-judgeで採点しつつ、人間テスターでエッジケースを探る三層体制を取っています。

人間テスターが拾った典型例として、初期エージェントが権威性の低いSEO最適化されたコンテンツファームを、より権威ある低ランクのソースより優先してしまう挙動が挙げられています。LLM-as-judge単体では検出しづらい品質欠陥で、人間の介入がいまだに金標準であることを補強する事例です。

評価の難しさそのものについても踏み込んだ記述があります。

"Even with identical starting points, agents might take completely different valid paths to reach their goal."

同じ入力でも経路が割れるため、「正解の手順」を事前に書いておく単純な比較は機能しません。同じテーマでのeval設計の議論は、AIエージェントのEval設計で別記事として書いています。今回のマルチエージェント記事の評価論は、その「採点者3類型・非決定性のpass@k」の議論と地続きで読むと整理がしやすいです。

本番運用の5つの落とし穴 — 状態を持つこと自体がリスク源

エージェントが本番に出てから初めて顕在化する問題が、5項目にまとめられています。

3つ目の「デプロイ調整」では、rainbow deployment(レインボーデプロイ)を採用しているという具体名が出ています。新旧バージョンを並走させながら、トラフィックを徐々に新版へ寄せるパターンです。

"We use rainbow deployments to avoid disrupting running agents, by gradually shifting traffic from old to new versions while keeping both running simultaneously."

普通のWebアプリと違って、エージェントは数分から数時間のセッションを抱えているため、ローリングアップデートでセッションを切ると進行中の調査が無に帰ります。レインボー戦略は、長時間の自走状態を前提にした運用判断として読めます。

4つ目の「同期ボトルネック」は、現在のLead側がサブエージェントの完了を待ってから次に進む同期実行を取っているという告白です。協調が単純化される反面、終わったエージェントが次のスタートまで遊んでしまう構図で、将来は非同期化が必要だと記事は認めています。

5つ目の「創発的挙動」は、マルチエージェント特有の難点です。明示的にプログラムしていない振る舞いが現れるため、リードのプロンプトを微修正しただけで全サブエージェントの動作プロファイルが変わる、ということが起きます。デバッグの基準点が動いてしまうため、評価のregression検出が一段重要になります。

この種の「本番に出てから直面する設計の罠」は、長時間エージェント向けハーネス設計でも別の角度から扱われています。マルチエージェント記事を読んだ後にハーネス側の議論に降りると、状態管理と再開可能性の話がより具体に落ちます。

マルチエージェントが向く / 向かないタスクの判別軸

記事はマルチエージェント信奉に走らず、適用範囲を慎重に区切っています。判断軸は次のとおりです。

"Multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools."

逆に、コーディングのように密な依存関係が連続するタスクは、現状ではマルチエージェントの恩恵が出にくいとも明言されています。

"Most coding tasks involve fewer truly parallelizable tasks than research."

Claude Codeを「並列のサブエージェント10本で書き散らす」運用に飛びついたチームが、思ったほど精度が上がらない、というケースをよく聞きます。Anthropic自身がコーディングの並列化はリサーチほど効かないと書いている事実は、Claude Code運用の判断材料として直接効きます。

「エージェントの最後の1マイルが旅程の大半」をどう読むか

記事中で印象に残るフレーズの1つが、

"When building AI agents, the last mile often becomes most of the journey."

という一行です。プロトタイプを動かす段階と、本番でユーザーに使わせる段階のあいだに横たわる「最後の1マイル」が、実際にはプロジェクト全体の大部分を占めるという主張です。マルチエージェント記事の文脈で読むと、これは次のような意味に翻訳できます。

• 動くプロトタイプは数日で組める。並列ツール呼び出しとリード・サブエージェントの分業を真似るだけならテンプレートでも書ける
• 本番に出すと、状態管理・デプロイ・観測性・regression検出・コスト制御の問題が一気に立ち上がる
• これらは個別のエンジニアリング課題で、研究的なブレイクスルーで一括解決できる類いではない

Anthropicがこの記事を「研究の発表」ではなく「エンジニアリングの発表」として出している点も、メッセージとして読めます。/research/ 配下ではなく /engineering/ 配下に置かれているのは偶然ではなく、エージェント運用の難所はすでに研究より工学に移っているという編集判断と読めそうです。

社内では「リサーチエージェントを動かしたい」という需要が広がる一方で、本番の運用に必要な観測性・rainbow deploy・regression evalを備えたチームは多くありません。プロトタイプの先で起きる「最後の1マイル」を、誰がどの順序で踏むかは、これからのチームが個別に解いていく問題になるはずです。

加えて、リードを賢いモデル(Opus 4)、サブエージェントを安いモデル(Sonnet 4)に振る構成は、コスト最適化の観点でも示唆的です。タスク全体を最上位モデルで通すよりも、合議の戦略策定だけ高価なモデルに任せ、実働は安いモデルに分散させる方が、性能とコストの両方で有利になり得る、という構図が90.2%の数字の裏に見えます。

ツール設計 / 評価 / 運用に降ろすときのチェックリスト

最後に、自社のエージェント基盤にマルチエージェント要素を入れるかを検討するときの判断材料を、記事から抽出して並べておきます。

全部にチェックが入る必要はありませんが、「タスク価値」「並列分解可能性」「観測性」の3つが揃わない場合は、マルチエージェント化の前にまず単独エージェントの精度を上げた方が費用対効果が出やすい、というのが記事の含意です。

まとめ

• Anthropicのマルチエージェント研究システムは、リードエージェントが戦略を組み、3〜5のサブエージェントが独立コンテキストで並列探索する構成で、Claude.aiの「Research」を支えています
• 内部評価ではClaude Opus 4をリード、Sonnet 4をサブエージェントに据えた構成が単独Opus 4を90.2%上回り、性能のばらつきの95%はトークン消費・ツール呼び出し回数・モデル選択の3因子で説明できます
• マルチエージェントは「賢さを増やす」のではなく「使えるトークン量を15倍に伸ばす」装置で、タスク価値がトークン代を上回る用途で初めて費用対効果が立ちます
• 本番では状態の累積・デバッグ困難・デプロイ調整・同期ボトルネック・創発的挙動の5つが落とし穴で、Anthropicはrainbow deploymentと長時間セッションを前提とした観測性で対処しています
• 適用範囲はリサーチ系・幅広探索系の高価値タスクに偏り、コーディングのような密な依存関係を持つタスクには現状フィットしません。Claude Code運用への安易な転用を抑える材料としても読めます