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倍のコスト がかかります。成果の価値がコストを上回るタスクに限定すべきです。

性能を決める要素

業界解説（ByteByteGo、Fountain City 等の整理）によれば、エージェント性能の分散の 80% はトークン使用量で説明 でき、残りは ツール呼び出し回数とモデル選択 という分析もあります。

つまり：

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

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

コスト感の例

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

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. クエリ複雑度に労力を比例させる

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

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 ドル/クエリで強制終了

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

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 の方針は、プライバシー・コンプライアンス上で参考になります。

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

• 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	認証分離（セキュリティ）

これらを使えば自前実装の負担を大幅に減らせます。ただし、ブラックボックス化するリスクとのトレードオフを理解した上で採用すべきです。

10. 判断フローチャート

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

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

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

11. まとめ

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

• Anthropic 公式（一次）：90.2%、15倍トークン、サブ数の規模感、CitationAgent、同期実行、観測可能性方針
• 業界解説（二次）：「コンテキスト制約 vs プロンプト問題」の切り分け、サーキットブレーカー、検証専用サブエージェント、性能分散の80%＝トークンの定量化

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

関連章

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