レッスン6：マルチエージェント協調——分業と統合

このレッスンで学ぶこと

マルチエージェントの基本発想と単一エージェントとの違いを理解する
Orchestrator-Worker パターンを設計の中核として押さえる
Hierarchical（階層）・Debate（討論）など代表的なパターンを区別する
2026 年 6 月時点の主要フレームワーク（LangGraph・AutoGen・CrewAI・Claude Code の Subagent）の位置づけを把握する
マルチエージェント化のコスト・遅延・可観測性の問題を意識する
「マルチエージェントが過剰」になる場面を見分ける

前のレッスンでは、エージェントの記憶設計を扱いました。本レッスンは、エージェントを 1 体ではなく複数組み合わせるマルチエージェント協調の発想を扱います。SNS や PR では華やかに語られる領域ですが、実務では「シンプルな単一エージェントで済むことを、マルチにして失敗する」事例も多く見られます。本コースは、その両面を整理します。

マルチエージェントとは

マルチエージェント（multi-agent）は、複数のエージェントが分業し、協調して 1 つの目的を達成する設計を指します。

単一エージェントとの違い

観点	単一エージェント	マルチエージェント
ツール数	10〜20 個に集約	各エージェントが少数のツールに集中
役割	1 体が全工程を担う	役割を分担し、得意領域に特化
通信	内部の Thought のみ	エージェント間のメッセージング
デバッグ	1 体のトレースを追う	複数体のトレースを統合

なぜマルチエージェントか

専門化：1 体に全機能を持たせると判断負荷が重い。役割分担で各エージェントを「専門家」にできる
並列化：独立タスクを並列実行できる
モジュール性：エージェントの追加・変更が容易
責任分界：エラーが起きたとき、どの役割で問題が起きたかがわかりやすい

マルチエージェントが過剰になる場面

1 体で十分対応できるタスクを、無理に分割する
エージェント間通信のコストが、専門化の利益を上回る
デバッグが追いつかなくなる

💡 ポイント 「マルチエージェントは華やかだから採用したい」と感じるシニアエンジニアは少なくありません。けれど、まず単一エージェントを最小構成で動かし、限界が見えたらマルチ化を検討する、という順番が現実的です。最初からマルチを目指すと、複雑さに溺れます。

Orchestrator-Worker パターン

マルチエージェントの最も基本的なパターンが、Orchestrator-Worker です。

構造

flowchart TD
  U[ユーザー指示] --> O[Orchestrator]
  O --> W1[Worker 1<br/>専門エージェント]
  O --> W2[Worker 2<br/>専門エージェント]
  O --> W3[Worker 3<br/>専門エージェント]
  W1 --> O
  W2 --> O
  W3 --> O
  O --> R[最終結果]

Orchestrator：全体の進行を管理し、適切な Worker にタスクを振り分ける
Worker：特定の専門領域に集中する小型エージェント
Worker の結果を Orchestrator が統合し、最終結果を返す

例：マーケティング企画エージェント

Orchestrator：「キャンペーン企画の全体管理」
Worker 1：「市場リサーチ専門」（ターゲット情報・競合動向を収集）
Worker 2：「コピー作成専門」（広告文・キャッチコピーを生成）
Worker 3：「画像生成専門」（ビジュアル案を作成）

Orchestrator が「リサーチ → コピー → 画像」の順に Worker を呼び出し、結果を統合して最終企画書を出力します。

強み

設計がシンプル：階層が浅く、責任が明確
デバッグしやすい：Orchestrator のトレースを見れば全体が追える
拡張容易：Worker を追加することで機能が増える

弱み

Orchestrator がボトルネック：全 Worker を順に呼ぶと遅い（並列化で緩和可能）
Worker の独立性が高すぎる：相互参照が必要なケースに弱い

📝 補足 Orchestrator-Worker は、Anthropic が 2024 年に「multi-agent research system」の論文や設計記事で詳しく解説したパターンとしても知られます。「人間の組織で言うとプロジェクトマネージャーと専門家」のメタファーで理解すると、直感的です。

Hierarchical（階層）パターン

Hierarchical（階層）パターンは、Orchestrator-Worker を多段に重ねた構造です。

構造

flowchart TD
  U[ユーザー] --> CEO[CEO エージェント]
  CEO --> M1[マネージャー 1]
  CEO --> M2[マネージャー 2]
  M1 --> W1[Worker 1a]
  M1 --> W2[Worker 1b]
  M2 --> W3[Worker 2a]
  M2 --> W4[Worker 2b]

上位エージェントが大まかな指示を出し、下位エージェントが詳細を実行
人間の組織のヒエラルキーに似た構造

用途

非常に複雑なタスク（複数の独立サブ目標を持つ）
長期実行のエージェント（数時間〜数日かかる）

落とし穴

階層が深いほどコスト・レイテンシが膨らむ
エラーの伝播経路が複雑になりデバッグが難しい
「下位の Worker が上位の意図を取り違える」エラーが多発

⚠️ 注意 Hierarchical パターンは、本当に必要な場面以外では避けるのが現実的です。「組織のメタファーに惹かれて」採用すると、複雑さに溺れます。3 階層を超えると運用が極端に難しくなります。

Debate（討論）パターン

Debate パターンは、複数のエージェントが異なる立場で議論し、最終結論を導く設計です。

構造

エージェント A：賛成論を主張
エージェント B：反対論を主張
審判エージェント：両者の議論を聞き、最終判断を下す

用途

複雑な意思決定（複数の選択肢の比較）
品質チェック（生成物に対する批判的レビュー）
安全性検証（提案された行動の妥当性確認）

強み

単一エージェントが見落とす論点を捕捉できる
出力の品質と頑健性が向上する

弱み

コスト・レイテンシが大きい（複数 LLM 呼び出し）
議論が収束しないリスク
設定が難しい（「賛成」「反対」をどう設計するか）

💡 ポイント Debate パターンは、「重要な意思決定の品質チェック」で威力を発揮します。一方、日常的な業務エージェントには過剰です。「重大な判断のみ Debate を挟む」というハイブリッドが現実的です。

2026 年 6 月時点の主要フレームワーク

マルチエージェント構築を支援するフレームワークは、2024〜2025 年に多数登場しました。2026 年 6 月時点の主要なものを整理します。

LangGraph

LangChain ファミリーの 1 つ
グラフベースでエージェント間の遷移を定義
状態管理と永続化に強い
大規模・複雑なエージェント向け

AutoGen（Microsoft）

Microsoft Research が開発
会話ベースのマルチエージェント設計
「人間役」「アシスタント役」など役割定義が直感的
研究プロトタイプから本番運用まで対応

CrewAI

役割（Role）・目的（Goal）・タスク（Task）でエージェントを定義
シンプルさを重視
中小規模のプロジェクトに向く

Claude Code の Subagent

Anthropic の Claude Code（コーディング向け CLI）で導入された機能
1 つのメインエージェントが、子エージェント（Subagent）を起動して並列タスクを実行
コーディングタスク以外にも応用例が増えている

選定の目安

大規模・状態管理重視：LangGraph
会話メタファーが合う：AutoGen
シンプル重視：CrewAI
コーディング系・Anthropic スタック：Claude Code Subagent

⚠️ 注意 フレームワークは数か月単位で大きく変わります。「特定フレームワークの細部を覚える」より、「自社のユースケースに必要な機能が何か」を整理する方が、長期的には役立ちます。本コースは特定フレームワークの操作詳細には踏み込みません。

コスト・遅延・可観測性

マルチエージェントは強力ですが、3 つの観点で単一エージェントより重くなります。

コスト

各エージェントが独立に LLM を呼ぶため、トータルコールが増える
通信オーバーヘッド（Orchestrator から Worker へのメッセージ、その逆）
複数 LLM の組み合わせで、想定外のコスト爆発が起きやすい

遅延

順次実行なら、各 Worker の処理時間の和
並列実行でも、最も遅い Worker に律速される
ユーザー体験的に「待たせすぎる」設計に陥りやすい

可観測性（オブザーバビリティ）

各エージェントのトレースを統合する必要がある
「どこで失敗したか」「どこで時間がかかったか」を追跡する仕組みが必須
LangSmith、LangFuse、Arize、Helicone などのツールが普及

📝 補足 可観測性ツールは、マルチエージェントを本番運用する上での前提インフラです。「とりあえず動かしてみる」段階では不要ですが、本番ローンチ前には必ず整備します。レッスン 7 で評価とデバッグを深掘りします。

マルチエージェントを選ぶときの判断軸

「単一エージェントとマルチエージェント、どちらを選ぶか」を判断する観点を整理します。

判断項目	単一が向く	マルチが向く
タスクの複雑さ	単一の専門領域で完結	複数の独立した専門領域
並列化の余地	低い	高い
役割の明確さ	1 つの役割で十分	複数の明確に異なる役割
デバッグの体力	限られている	十分にある
コスト許容度	厳しい	寛容
ツール数	10〜20 個に収まる	30 個以上が必要

始めるなら単一から

本コースの推奨は、「まず単一エージェントを最小構成で作り、限界を実感してからマルチを検討する」順番です。最初からマルチを目指すと、設計の複雑さ・デバッグの困難さで挫折することが多いです。

💡 ポイント マルチエージェントは「華やかな未来の技術」ではなく、「単一エージェントの限界を補う、目的のある選択肢」と捉えるのが現実的です。「何でもマルチに」ではなく、「ここはマルチでないと無理だ」と判断したときのみ採用します。

講師の現場メモ：「5 エージェントの華麗な構成を 1 エージェントに戻した話」

私（高梨）が AI スタートアップで CTO だった頃、ある営業向け業務エージェントの設計を担当しました。要件は「顧客からの問い合わせメールに、適切な回答を下書きする」というシンプルなものでした。

私は当時、マルチエージェントへの好奇心が強い時期でした。「このプロジェクトでマルチエージェントの実力を見せよう」と意気込み、次の構成を提案しました：

Orchestrator エージェント：全体管理
分類エージェント：問い合わせの種類を判定
検索エージェント：関連 FAQ・過去事例を取得
ドラフトエージェント：回答文章を生成
レビューエージェント：トーン・正確性をチェック

合計 5 エージェント。社内のレビューでは「最先端の設計だ」と賞賛されました。実装も完了し、検証フェーズに入りました。

検証で見えてきたのは、

1 件の問い合わせ処理に、平均 40 秒かかる（5 エージェントの順次実行）
LLM 呼び出しが 1 件あたり 12〜15 回（reasoning モデルを含む）
1 件あたり API コスト 80 円程度
月間想定問い合わせ件数 5,000 件 → 月 40 万円の API コスト

ビジネス側からは「人間の営業が下書きを書けば 3 分。AI が 40 秒なら早いが、月 40 万円はちょっと……」という反応でした。

私はその場で設計を見直しました。実は、5 エージェントの大半は「重要そうに見えるが、必須ではない」役割でした。

分類エージェント：実は判定はシンプルで、Few-shot で十分
検索エージェント：これは必要（RAG ツール）
ドラフトエージェント：これが本体
レビューエージェント：人間の営業が最終確認するので、自動レビューは過剰

私は構成を 1 エージェントに統合しました：

単一の「メール対応エージェント」
ツールは 3 つ：FAQ 検索、過去事例検索、CRM 顧客情報取得
LLM 呼び出しは 1 件あたり 3〜5 回
1 件 8 秒、API コスト 12 円

新構成では、月 6 万円に収まりました。回答品質は、5 エージェント構成と比べてわずかに下がっただけ。営業担当の最終確認で十分カバーできるレベルでした。

このときに学んだのが、「マルチエージェントは強力だが、シンプルな単一エージェントで足りる場面で採用すると、複雑さに見合わない」ということです。本コースで「まず単一から始めて、限界を実感してからマルチを検討する」と繰り返すのは、この 5 エージェント構成の苦い記憶があるからです。

まとめ

このレッスンでは、以下のことを学びました。

マルチエージェントは複数のエージェントが分業・協調する設計
専門化・並列化・モジュール性・責任分界というメリットがある
Orchestrator-Worker は最も基本的なパターンで、責任が明確
Hierarchical（階層）は複雑なタスク向けだが、3 階層を超えると運用が極端に難しくなる
Debate（討論）は重要な意思決定の品質チェックに向くが、コストが大きい
2026 年 6 月時点の主要フレームワーク：LangGraph・AutoGen・CrewAI・Claude Code Subagent
マルチエージェント化はコスト・遅延・可観測性の負担増を伴う
「まず単一から始めて、限界を実感してからマルチを検討する」順番が現実的

次のレッスンでは、エージェントが「うまく動いているか」を測る評価とデバッグ——本コースの中核となる運用設計を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。