AIエージェントの設計とマルチエージェント

AI エージェントを 並列マルチエージェント で組むべきか、単一エージェント で済ませるべきか — これが本章の中心的な問いです。

本章は Anthropic が 2025年6月13日に公開した公式エンジニアリングブログ “How we built our multi-agent research system”²⁹ を主な一次情報源とし、業界の二次解説（Substack、ByteByteGo、Fountain City 等）を補足として整理します。

1. 適合タスクの見極め — Breadth-first か Interdependent か

並列マルチエージェントが効くのは 独立した探索ストランドに分割できる「幅優先（breadth-first）」の問題 です。逆に、コーディングのように密に相互依存するタスクには不向き です。

性能向上の本質

Anthropic のブログから直接引用：

“multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance.”

性能向上の本質は 「賢さ」ではなく「コンテキスト総量」 です。各サブエージェントが 別々のコンテキストウィンドウ を持つことで、単一エージェントが保持できる以上の総コンテキストにわたって並列推論できる。

Anthropic の社内ベンチマークでは、Claude Opus 4 をリード、Sonnet 4 をサブとした構成が、単一の Opus 4 を 90.2% 上回った（リサーチタスクで）と報告されています。

出典：Anthropic Engineering: How we built our multi-agent research system（2025/6/13）

最初に切り分けるべき問い

実装に入る前に、必ず次の問いに答えてください：

単一エージェントが頭打ちになったのは：
├ ① コンテキスト制約か？（情報量が窓に収まらない）
│   └ YES → マルチエージェントが効く可能性
└ ② プロンプトの問題か？（情報はあるが指示が悪い）
    └ YES → プロンプト改善で解決すべき

「コンテキスト制約」と答えられるタスクだけが、マルチエージェント化の対象です。

適/不適タスクの早見表

適するタスク（Breadth-first）	不適なタスク（Interdependent）
リサーチ（複数情報源の並列調査）	コーディング（密に依存する変更）
競合分析（5社を並列で深掘り）	デバッグ（前の状態の影響が連鎖）
文献レビュー（独立した文献の並列読解）	文章の長編執筆（章間の整合性が必要）
マーケット調査（地域別並列）	数学的証明（順序依存のステップ）

2. コスト前提の明確化

並列マルチエージェントは 重い。実装前にコスト構造を明示する必要があります。

15倍のトークン消費

Anthropic の直接引用：

“agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.”

形態	標準チャット比のトークン使用量
チャット（標準）	1×
単一エージェント	約 4×
マルチエージェント	約 15×

つまり、マルチエージェントは標準チャットの約15倍のコスト がかかります。成果の価値がコストを上回るタスクに限定すべきです。

性能を決める要素

Anthropic 公式記事は次のように一次情報として明示しています — “We found that 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.”（トークン使用量だけで分散の80%が説明でき、ツール呼び出し回数とモデル選択を加えた3因子で BrowseComp 評価の95%を説明）。

つまり：

• トークン予算の設計 が最も影響大
• ツール呼び出し回数の最適化 が次に重要
• モデル選択（Opus vs Sonnet vs Haiku 等）が次

「賢いプロンプト」より「リソース配分の設計」が性能を左右します。

コスト感の例

参考として、Anthropic 社内のリサーチエージェント1回の実行は、複雑なクエリで数ドル〜十数ドル規模になりうると業界解説で推定されています。1日に何百回も走らせる用途では、月額数万〜数十万円のオーダー になることを認識しておく必要があります。

試算式：1クエリのコスト ≒ リードトークン + Σ(サブトークン) + Σ(ツール呼び出しコスト) を、各モデルの単価（リード=Opus $5/$25、サブ=Sonnet $3/$15、要約=Haiku $1/$5）で掛け合わせる。

シナリオ	入力	出力	サブ数	ツール回数	概算コスト
単純調査	5K	2K	1	3	$0.10〜$0.30
比較分析	20K	10K	3	15	$1〜$3
複雑調査	100K	50K	10+	50+	$5〜$15

トークン予算配分の目安：リード 20% / サブ群 70% / CitationAgent 10%。ツール呼び出し回数を減らす具体策はバッチ検索、結果のキャッシュ、要約による中間圧縮。

3. オーケストレーター/ワーカー構成

マルチエージェントの基本形は リード（オーケストレーター）+ サブエージェント群（ワーカー） の階層構造です。

構造

        [リードエージェント]
              │
       ┌──────┼──────┐
       ↓      ↓      ↓
   [サブ1] [サブ2] [サブ3]   ← 3-5 のサブを並列起動
       │      │      │
       └──────┼──────┘
              ↓
       [CitationAgent]       ← 引用統合を別パスで
              ↓
         [最終成果物]

Anthropic の直接引用：

“a lead agent coordinates the process while delegating to specialized subagents that operate in parallel.”

役割分担の原則

役割	仕事
リード（マネージャー）	計画立案、タスク分解、サブへの委譲、成果の統合
サブエージェント（ワーカー）	担当タスクに集中、独立して並列実行
CitationAgent	引用・出典の整合性確認、検証経路の分離

同期 vs 非同期

現状の Anthropic 実装は 同期実行 です：

“our lead agents execute subagents synchronously, waiting for each set of subagents to complete before proceeding.”

非同期化（サブの完了を待たずに次を起動・サブからさらにサブ生成）はコーディネーションと状態管理の複雑さが大幅に増えるため、Anthropic は意図的に避けています。

実装初期は 同期から始める のが安全。

4. 委譲の質を上げる — 初期失敗の最大要因

マルチエージェント実装の 初期失敗の多くは委譲の質に起因 します。

よくある失敗パターン

パターン	結果
サブが「十分な結果」を得ても探索を続ける	コスト膨張、無関係な情報の混入
複数サブが互いの作業を重複させる	リソースの無駄、矛盾する成果
タスク記述が不十分で必要情報を見つけられない	失敗、または的外れな結果
サブが他のサブの存在を知らずに重複作業	全体最適にならない

各サブエージェントに明示すべき5要素

1. 目的（Objective）       — 何を達成するか
2. 出力フォーマット         — どの形式で返すか（JSON/Markdown/etc）
3. 成功条件                — 何をもって「終わり」とするか
4. 使用ツール              — 使ってよい・使うべきツール
5. 境界（Boundaries）      — やってはいけないこと、他サブとの守備範囲

これらをサブのプロンプトに 明示的に書き下す ことで、初期失敗の大半は回避できます。

委譲プロンプトの実例（5要素を埋めた競合分析サブ）

【目的】Acme社のAI領域での競合（直接3社・間接2社）を特定し、強み・弱みを構造化せよ
【出力フォーマット】
{
  "direct_competitors": [{"name": str, "strength": str, "weakness": str, "source": URL}],
  "indirect_competitors": [...]
}
【成功条件】
- 直接競合3社・間接競合2社を埋める
- 各社につき公式サイトまたは主要メディア記事の出典URLを必ず付ける
- 「不明」の項目は空欄ではなく "unknown" と明記
【使用ツール】web_search, fetch_url（公式サイト・主要メディアのみ）
【境界】価格情報の収集は不要、財務予測は禁止、他サブの担当（市場規模・規制）には踏み込まない

アンチパターン：「Acme の競合について調べて」のような曖昧指示。境界が無いとサブが市場規模・財務まで踏み込み、トークンが膨らみ、他サブと重複する。

サブ間の重複防止

「複数サブが互いの作業を重複させる」失敗を防ぐには：

• 分担マニフェスト：リードが事前に「サブA=直接競合のみ／サブB=間接競合のみ／サブC=規制動向のみ」と直交分解し、各サブのプロンプトに埋め込む
• 共有ステートストア：Redis 等で「claim & lock」方式。同一エンティティを2サブが扱わない
• リード判定の徹底：サブ起動前にリードが「このサブは何をしないか」を明示する

5. クエリ複雑度に労力を比例させる

サブエージェントの 過剰な生成を防ぐルール を、プロンプトに埋め込みます。

Anthropic の直接引用：

“Simple fact-finding requires just 1 agent with 3-10 tool calls, direct comparisons might need 2-4 subagents with 10-15 calls each, and complex research might use more than 10 subagents with clearly divided responsibilities.”

規模感の早見表

クエリの種類	サブエージェント数	サブごとのツール呼び出し
単純な事実調査	1	3〜10
直接的な比較	2〜4	10〜15
複雑な調査	10+	状況に応じて分担

リードエージェントのシステムプロンプトに、この種の 判断基準を埋め込む ことで、過剰生成と過小評価の両方を防ぎます。

6. 暴走防止（サーキットブレーカー）

リスクシナリオ

エージェントが暴走する典型パターン：

• 再帰的にさらにサブエージェントを生成：サブがサブを呼び、その入れ子が深くなる
• ツールが過大な出力を返す：1回の検索結果が数十万トークンに膨れ上がる
• 判断ループ：成功条件が曖昧で延々と検索を続ける

これらのリスクが連鎖すると、1クエリのコストが想定の10倍以上に膨れ上がる ことが報告されています。

自前で設けるべき上限機構

公開アーキテクチャには包括的なサーキットブレーカー機構が 無い ことが多いため、実装側で次の上限を必ず設けます：

上限の種類	例
合計トークン上限	1クエリ全体で N トークン超なら強制終了
サブエージェント数の上限	同時並列 N 個まで、再帰 N 層まで
ツール呼び出し回数の上限	1サブあたり N 回まで
実行時間の上限	N 分超でタイムアウト
金額の上限	N ドル/クエリで強制終了

実装言語に応じたミドルウェアやデコレーターで、リード起動の前段に組み込むのが標準的パターンです。

実装層と初期値の目安

層	役割	初期値の目安
プロキシ層	全体課金・全体タイムアウト	$10/クエリ、合計50万トークン、10分
リード起動前	サブ数の規模・再帰深度	同時並列5、再帰2層
サブ実行時	サブごとの上限	1サブあたり10万トークン、ツール20回、3分

上限到達時のフェイルセーフ：(a) 強制終了して503返却、(b) 部分成果を集約して「不完全な結果」として返却、(c) リードへエスカレーション（人間の追加承認を求める）。(c) はコスト超過 / セキュリティ違反、(b) は時間切れ、(a) は明らかな暴走時 が標準。

失敗回復とリトライ戦略

サブが失敗したときの挙動を必ず設計する：

• 冪等性：同じプロンプト＋同じツール結果なら同じ出力を返せるサブ設計（途中状態を残さない）
• リトライ：指数バックオフ + ジッター。最大3回、合計30秒以内
• 部分失敗の許容：5サブ中3成功で続行 vs 全成功必須をタスクごとに決める
• リードによる再分配：失敗したサブのタスクを別サブに割り当てるか、リードが直接処理する縮退運転

セキュリティ境界

マルチエージェント特有のセキュリティ課題：

• プロンプトインジェクション増幅：サブが汚染データを取り込みリードに毒を返す。外部入力は必ず別レイヤで検証
• ツール権限の最小化：サブごとに使えるツールを限定（リサーチサブは read のみ、編集サブは write も）
• 機密情報のコンテキスト分離：サブA（人事情報）の機密がサブB（外部公開）に渡らない設計。Credential vault でツール認証を一元化

7. 検証は別サブエージェントへ

別エージェントによる検証のメリット

業界解説によれば、検証を本処理とは別のサブエージェントに任せることで「伝言ゲーム」問題を回避できるとされます。検証は本質的に 最小限のコンテキスト移転 で済むため、構築過程の全履歴なしにブラックボックス的にテストできる、という考えです。

実装パターン

1. 本処理エージェント群が成果物を生成
2. 完了後、検証エージェントに渡すのは：
   - 成果物そのもの
   - 成功基準（明示的に）
   - 検証用ツール
3. 検証エージェントが採点・指摘
4. 必要に応じてリードへフィードバック

検証エージェントには 本処理の経緯を伝えない ことが重要。これにより、本処理側のバイアスを排除した独立評価が得られます。

Anthropic の CitationAgent

Anthropic の構成では、引用・出典の整合性を担う CitationAgent がリサーチ完了後に走ります：

“passes all findings to a CitationAgent, which processes the documents and research report to identify specific locations for citations.”

これは「検証」とは異なるものの、最終段階で別エージェントに専門タスクを委ねる という設計思想の現れです。

8. 観測可能性（Observability）

Anthropic の直接引用：

“we monitor agent decision patterns and interaction structures—all without monitoring the contents of individual conversations, to maintain user privacy.”

標準ログでは不十分

通常の API ログ・アプリケーションログだけでは、エージェントの 意思決定の流れ を追えません。何を計画し、なぜそのサブを起動し、どこで失敗したかを後から再現できる仕組みが必要です。

自前で追跡すべき要素

要素	例
意思決定の理由	リードが「なぜこのサブを起動したか」
サブ間の相互作用	サブAの出力がサブBの入力になった経路
ツール呼び出しの履歴	何のクエリで何の結果が返ったか
コスト累計	クエリごとのトークン・金額
失敗パターン	どの段階で何が失敗したか

ただし、会話の内容そのものを保存しない という Anthropic の方針は、プライバシー・コンプライアンス上で参考になります。

観測の最小スキーマ例

各イベントを次の形式で記録：

Run ID + Parent Run ID + Step Type + Token Count + Tool Call Payload + Timestamp + Cost

OpenTelemetry の Span 階層でサブエージェントツリーを再現できる。会話内容を保存しない方針 を担保するには、payload のハッシュ化やメタデータのみ記録の運用が必要。

マルチエージェントの eval 設計

エージェント全体としての評価指標：

• エンドツーエンド評価：最終成果物の正答率、引用正確性、網羅性
• プロセス評価：サブ起動数の妥当性、トークン使用量の効率、重複作業率
• A/Bテスト設計：単一 vs マルチ、サブ数3 vs 5、Opus リード vs Sonnet リード
• LLM-as-a-Judge の落とし穴：判定モデルが生成モデルと同系統だと判定が甘くなる。判定は別系統のモデルで

主要な観測ツール（業界）

• LangSmith（LangChain 系の標準）
• Helicone（API レベルのオブザーバビリティ）
• Braintrust（eval + observability 統合）
• Phoenix（Arize）（OSS、LLM トレース）
• 自前実装（OpenTelemetry ベース）

9. Managed Agents 機能との対応

Anthropic は Claude API の Managed Agents 機能 で、上記のベストプラクティスの多くを マネージド側で肩代わり できる仕組みを提供しています。

Managed Agents 機能	対応するベストプラクティス
outcomes（自己採点ループ）	検証分離（Section 7）
multiagent orchestration	オーケストレーター/ワーカー構成（Section 3）
checkpointing	暴走防止と状態保存（Section 6）
sandbox	暴走防止と権限分離（Section 6）
credential vault	認証分離（セキュリティ）

機能名・仕様は Anthropic 公式 platform.claude.com/docs/en/managed-agents/overview および multi-agent を一次出典として参照。ベータヘッダーは managed-agents-2026-04-01。これらを使えば自前実装の負担を大幅に減らせますが、ブラックボックス化・ベンダーロックイン・価格改定リスクとのトレードオフを理解した上で採用すべきです。

10. 判断フローチャート

実装に入る前に、以下のフローで判断してください。

[タスク]
   │
   ├ 単一エージェントのプロンプト改善で解けないか？
   │   └ YES → 単一で十分。マルチ化しない
   │
   ├ Breadth-first（独立した並列探索）に分解できるか？
   │   └ NO  → 単一エージェントを推奨
   │
   ├ 1クエリ約15倍のコストを正当化できる価値があるか？
   │   └ NO  → 単一を選び、プロンプト改善に注力
   │
   ├ 暴走防止機構（コスト・回数・時間上限）を実装できるか？
   │   └ NO  → 実装してから移行
   │
   └ 観測可能性を確保できるか？
       └ NO  → 実装してから移行

すべて YES なら → マルチエージェント化

11. まとめ

出典区分（本章の透明性のために）

• Anthropic 公式（一次）：90.2%、15倍トークン、サブ数の規模感、CitationAgent、同期実行、観測可能性方針、性能分散の80%＝トークン使用量（3因子で BrowseComp 評価の95%を説明）
• 業界解説（二次）：「コンテキスト制約 vs プロンプト問題」の切り分け、サーキットブレーカー、検証専用サブエージェント、「数か月かけた構成を単一エージェントで再実装したら同等になった」という具体的体験談

二次解説は Anthropic の含意を実装パターンに落とし込んだ ものとして、エンジニアリング判断に有用ですが、Anthropic 自身の主張ではない点を留意してください。

関連章

• 第6章 カスタマイズの階層 — 単一エージェントの強化、Function Calling、MCP の詳細
• 第13章 AIコーディング — コーディング領域でのエージェント実装、Vibe Coding / Agentic Engineering