OpenAI の Deep Research、Google の Deep Research、Claude の Research — これらは単純な 1 対 1 のチャットでは実現できない複雑な調査タスクをこなします。10 分かけて、Web を横断的に調べ、構造化されたレポートを返してくる。
実はこれ、裏で 10-30 体の AI エージェントが並列動作している マルチエージェント構成です。
Anthropic が 2025 年 6 月に公開した How we built our multi-agent research system は、この種のシステムの設計を具体的に解説した貴重な資料。本稿では、
- マルチエージェント構成がなぜ必要になったか
- Orchestrator + Sub-agents の基本アーキテクチャ
- 並列検索・結果マージの実装
- コストが 10-15 倍になっても使われる理由
- 自前で小さく実装するパターン
を整理します。
単一エージェントの限界
Research タスクの性質
「2026 年の AI コーディングツール市場を調査して、主要プレイヤーの SWOT 分析を 20 ページで書いて」のようなタスク:
- 複数の情報源（公式ドキュメント、ニュース、ブログ、学術論文、X の議論など）を横断
- 各ソースから抽出した情報を矛盾なく統合
- 時系列の変化を追う
- 定量的な比較を含める
これを単一エージェントでやると、次の問題が出ます。
1. コンテキスト窓の爆発
20 サイトを順に読むと、合計 100-500K トークンを食います。文脈窓 200K 限界で、半分も読めないか、Context Rot で忘れっぽくなる。
2. 逐次実行の遅さ
Web ページを 20 枚、順に読むと数十分。並列化しないと使い物にならない。
3. 焦点の散漫
1 体のエージェントが「ニュースを読む・論文を読む・SWOT をまとめる」を全部やろうとすると、各タスクの精度が下がる。
マルチエージェント構成の基本形
Orchestrator + Sub-agents パターン
orchestrator
│
┌────────────────┼────────────────┐
│ │ │
sub-agent 1 sub-agent 2 sub-agent 3
(情報源 A) (情報源 B) (情報源 C)
│ │ │
10,000 token 12,000 token 8,000 token
詳細調査 詳細調査 詳細調査
│ │ │
↓ 要約 1,500 ↓ 要約 1,500 ↓ 要約 1,500
└────────────────┼────────────────┘
│
orchestrator
│
最終レポート- Orchestrator: 計画立案、サブタスク分解、結果統合
- Sub-agents: 各領域の詳細作業、結果を凝縮して返す
Orchestrator が見るのは 要約だけ (3 × 1,500 = 4,500 トークン)。実際の調査は 30,000 トークンかかっているが、Orchestrator の文脈窓を食わない。
これが解決する課題
- コンテキスト分割: 各 sub-agent は独自の文脈窓を持つ、合算で 10 倍の情報を扱える
- 並列実行: 10-30 体の sub-agent が同時に動く
- 焦点の分離: 各 sub-agent は 1 つの情報源・1 つのタスクに集中
Building effective agents の Orchestrator-Workers パターン そのものです。
並列検索の設計
検索タスクの分解
ユーザのクエリ「2026 年の AI コーディングツール比較」を、orchestrator が以下のように分解:
- サブタスク 1: Cursor の公式サイト + 公式ブログ調査
- サブタスク 2: Claude Code の公式ドキュメント + Anthropic engineering blog 調査
- サブタスク 3: GitHub Copilot のドキュメント + Microsoft blog 調査
- サブタスク 4: Hacker News / Reddit / X での比較議論の収集
- サブタスク 5: GitHub Stars / downloads の定量データ収集
これを 5 体の sub-agent が並列で実行。各 sub-agent は WebSearch / WebFetch / 構造化データ API を呼び出せます。
Fan-out の制御
無制限に並列化すると:
- API のレート制限に当たる
- 情報源に負荷をかけすぎる (倫理的・技術的)
- コストが爆発
実装では 同時並列数の上限 (10-20) を設定。orchestrator は上限内で動的に sub-agent を起動・終了します。
結果マージの難しさ
単純連結の問題
Sub-agent の要約を単純に concat() して orchestrator に渡すと、以下が起きます:
- 重複: 3 つの sub-agent が同じ情報を見つけてくる
- 矛盾: ニュース記事 A と公式ドキュメント B で数値が違う
- 粒度の違い: 詳細な sub-agent と要約だけの sub-agent
Anthropic の解決
Evaluator agent を挟む構成が有効:
sub-agents → raw summaries → evaluator → cleaned summary → orchestratorEvaluator は:
- 重複を merge
- 矛盾を明示 (「情報源 A は X、情報源 B は Y と主張」)
- 粒度を揃える
- 信頼度を付与
階層化
さらに大規模なら、2 階層の集約:
30 sub-agents → 6 group evaluators → 1 orchestratorこれなら orchestrator の入力は 6 × 1,500 = 9,000 トークンで済む。
評価ループの実装
Evaluator-Optimizer パターン
Building effective agents で紹介した Evaluator-Optimizer パターンを、研究タスクに応用:
orchestrator がドラフト作成
↓
evaluator が「足りない情報は何か」を指摘
↓
orchestrator が追加の sub-agent を起動して追加情報を集める
↓
ドラフトを更新
↓
(閾値を満たすまで、または N 回ループ)Anthropic の Research 機能では、3-5 回のループ が標準。1 回目で得た情報の穴を 2 回目で埋める、という形。
終了条件
- スコア閾値: evaluator のスコアが X% を超えたら終了
- ループ回数上限: どれだけ良くならなくても N 回で終了
- コスト上限: 累計トークン消費が Y を超えたら終了
実運用では コスト上限 が最も効きます。無限ループになる失敗モードを防ぐ。
コスト 10-15 倍を正当化できるか
Anthropic は率直に書いています:
マルチエージェント構成は、単一エージェントに比べてトークン消費が 10-15 倍。
これだけ見ると「割に合わない」ように見えますが、以下のケースでは正当化されます。
1. 単一エージェントで不可能 なタスク
20 ソースを横断する調査は、単一エージェントではコンテキスト不足で不可能。10-15 倍の増加で可能になるなら、純増の価値。
2. 人間が同じ時間を費やす コストと比較
同じ調査を人間アナリストがやると数時間〜数日。時給 5,000 円 × 8 時間 = 40,000 円。マルチエージェントが $20 かかっても、70 分の 1。
3. 並列実行 で待ち時間を実質ゼロ
逐次 1 時間かかる調査が、並列化で 10 分で終わるなら、人間の時間を節約した分の価値がトークンコストを上回る。
4. 品質 が単一エージェントを超える
複数ソースの統合、Evaluator ループでの品質向上 — 単一エージェントでは達成できない水準に到達する。
使い所を選ぶ のが大事です。簡単な質問に Deep Research を使うのはオーバーキル。
自前で小さく実装する
最小構成（50 行）
TypeScript で、3 体の sub-agent を Promise.all で並列実行する最小構成:
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
async function subAgent(topic: string, source: string): Promise<string> {
const result = await client.messages.create({
model: "claude-sonnet-5",
max_tokens: 2000,
messages: [{
role: "user",
content: `${source} について ${topic} の観点で調査し、重要な事実 5 件を要約してください。`
}],
tools: [{ type: "web_search_20250828", name: "web_search", max_uses: 5 }]
});
return result.content.filter(c => c.type === "text")[0].text;
}
async function researchOrchestrator(query: string): Promise<string> {
// Step 1: Decompose
const subtasks = [
{ source: "公式ドキュメント", focus: query },
{ source: "ニュース記事", focus: query },
{ source: "コミュニティ議論", focus: query },
];
// Step 2: Parallel sub-agents
const summaries = await Promise.all(
subtasks.map(st => subAgent(st.focus, st.source))
);
// Step 3: Merge
const merged = await client.messages.create({
model: "claude-opus-5",
max_tokens: 4000,
messages: [{
role: "user",
content: `以下の 3 つの要約を統合して、重複を merge し、矛盾を明示した最終レポートを書いてください:\n\n${summaries.map((s, i) => `## ソース ${i+1}\n${s}`).join("\n\n")}`
}]
});
return merged.content.filter(c => c.type === "text")[0].text;
}これで基本的なマルチエージェント研究システム が動きます。50 行。
本番で足すべきもの
- エラーハンドリング（sub-agent が失敗したら？）
- Evaluator ループ（1 回で終わらせない）
- 並列数の制御（API レート対策）
- 中間結果のストリーミング（ユーザーに進捗を見せる）
- コスト上限
- キャッシング（同じクエリは再利用）
これらを足していくと、徐々に Anthropic Research や OpenAI Deep Research に近づきます。
MulmoTerminal での小規模マルチエージェント
MulmoTerminal の Round table 機能は、小規模な multi-agent 対話を 1 クリックで起動できる仕組みです。
- 5 セッションまで席を設定
- 発言順を自動で回す
- 各発言者は違うエージェント（Claude / Codex / Gemini など）が選べる
- 会話は Rooms に永続化
これはフルスケールのマルチエージェント研究システムではありませんが、設計検討の段階で 3 体のエージェントに違う視点から意見を言わせる 用途で効きます。Evaluator-Optimizer の人間介入版、とも言えます。
まとめ
- Deep Research は裏で 10-30 体のマルチエージェント構成
- Orchestrator + Sub-agents が基本形、各 sub-agent は要約して返す
- 並列検索、Evaluator による統合、Evaluator-Optimizer ループで品質を上げる
- コスト 10-15 倍、ただし単一エージェントで不可能なタスクをこなす
- 自前実装は 50 行で開始できる。エラーハンドリング・コスト制御を順に追加
- 小規模な multi-agent 対話は MulmoTerminal の Round table で試せる
単一エージェントの限界を超える のがマルチエージェントの価値です。小さく始めて、必要になったら足していく。
関連リンク
- 原文: How we built our multi-agent research system (Anthropic)
- Anthropic Engineering Blog の歩き方
- 「Building Effective Agents」を実務に落とす
- Context Engineering 入門
- AI エージェント並列化で開発速度 10 倍
- MulmoTerminal の Round table
- MulmoTerminal — Claude Code / Codex を並列実行
Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。
