マルチエージェントAIとは？設計パターンから実装・運用の勘所まで

AIエージェントが自律的にタスクをこなせるようになったとはいえ、1つのエージェントに全てを任せるのには限界がある。

たとえば「競合分析レポートを作成して」という指示を考える。Web検索、データ収集、分析、文章作成、図表生成、レビュー、修正——これらを1つのエージェントが一気通貫で行うと、コンテキストウィンドウの消費が激しく、途中のミスが最終成果に波及し、どこで間違えたかの特定も難しい。

人間のチームが自然にやっているように、役割を分けた方がうまくいく。調査担当、分析担当、執筆担当、レビュー担当。各担当が自分の専門に集中し、成果物をリレーする。マルチエージェントアーキテクチャはこの発想をAIシステムに適用したものだ。

マルチエージェントシステムのロール設計は用途によって千差万別だが、多くの実装に共通する4つの基本ロールがある。まずはPlannerとExecutorから押さえておこう。

PlannerはユーザーのゴールをIssueに分解して実行順序を決める司令塔だ。Executorはそのサブタスクを実際に実行する。Web検索、API呼び出し、コード実行など外部ツールとのインタラクションを担当し、タスクの種類ごとに専門化したExecutorを複数用意することもある。この2つは役割が明確で、導入時に迷うことは少ない。

問題はCritic（批評者）の設計だ。CriticはExecutorの出力を評価し、品質が基準を満たしているかを判定してフィードバックを返す。人間のコードレビュアーに相当する役割だが、ここで「何をもって合格とするか」をプロンプトに明示しないと、ExecutorとCriticが延々と修正ループを繰り返す事態に陥る。判定基準が曖昧なままCriticを投入すると、Executorが「これでどうですか」→ Criticが「まだ不十分です」を永遠に繰り返し、トークンだけが消費されていく。Criticの判定基準は、具体的な合格条件（「コードがテストを通過する」「3つ以上の根拠を含む」等）としてプロンプトに書き出すのが鉄則だ。

Verifier（検証者）はCriticと混同されやすいが、視点が異なる。Criticが個々のサブタスクの品質を見るのに対し、Verifierは最終成果物が当初のゴールを満たしているかを確認する。分析レポートであれば「依頼者の問いに答えているか」「結論と根拠が整合しているか」といった全体の一貫性を検証する役割だ。

ロールの組み合わせ方によって、いくつかの定番パターンが存在する。どれを選ぶか迷ったら、まずパイプライン型から始めることを勧める。

パイプライン型

Planner → Executor → Critic → Verifier と一方向にデータが流れる最もシンプルな構成。レポート生成やドキュメント作成のように、工程が明確に順序立てられるタスクに向く。実装が簡単で、デバッグもしやすい。ただし途中で大きな方針変更が必要になると、最初からやり直しになるリスクがある。

ループ型（Critic-in-the-loop）

ExecutorとCriticが品質基準を満たすまで繰り返しやり取りする構成。コード生成のユースケースでよく使われる。Executorがコードを書き、Criticがレビューし、問題があればExecutorが修正する。3〜5回のイテレーションで収束することが多いが、無限ループを防ぐために最大イテレーション数の上限設定は必須だ。

階層型（Hierarchical）

上位のPlannerが複数の下位エージェントチームを管理する構成。大規模なプロジェクト——たとえばアプリケーション全体の開発——では、フロントエンドチーム、バックエンドチーム、テストチームそれぞれにPlanner + Executorの組を持たせ、統括Plannerが全体を調整する。Claude CodeのAgent Team機能やCrewAIがこのパターンを採用している。

議論型（Debate / Ensemble）

同じ問題に対して複数のエージェントが独立に解答を生成し、それを比較・統合する構成。正解が一意に定まらない問題（戦略策定、創造的タスク）で有効。多数決、スコアリング、別のエージェントによる統合などの手法で最終回答を決定する。ただしコストが他パターンの2〜3倍になるため、精度向上の明確な根拠がない限り、最初から採用するのは避けた方がいい。

前のセクションで4つの設計パターンを紹介したが、どのパターンを選んでも、エージェント間の通信設計を後回しにすると後から必ず詰まる。見落とされがちだが、ここが最も重要なポイントだ。

各エージェントが自由形式のテキストでやり取りすると、解釈の齟齬が発生する。Plannerが「ユーザー一覧を取得して」と指示したとき、Executorは全件取得するのか、アクティブユーザーだけなのか、どのフィールドを含めるのか——曖昧さが品質のばらつきを生む。

実務では、エージェント間メッセージに構造化スキーマ（JSON Schema等）を定義することが推奨される。Google の A2A（Agent-to-Agent）プロトコルは、異なるベンダーのエージェント同士が通信するための標準仕様として策定が進んでいる。Anthropic の MCP（Model Context Protocol）はエージェントと外部ツールの接続を標準化するもので、すでに主要なIDEやLLMクライアントへの統合が進んでいる。一方のA2Aはまだ早期導入者が試している段階で、本番投入の事例はこれからだ。

とはいえ、小規模なシステムであればこうしたプロトコルを導入するまでもなく、JSON Schemaで入出力の型を定義するだけで十分なことも多い。大事なのは「エージェント同士が何を期待しているか」を明文化することであって、使うツールの格式ではない。

マルチエージェントシステムは強力だが、まず伝えたいのは「最初からフル構成を組まないこと」だ。Planner + Executor × 5 + Critic + Verifierのような構成を最初から組んで、保守コストで自滅するケースは珍しくない。まず単一エージェントでタスクを実行し、品質が不十分な工程を特定してから、その工程だけロールを分離する。これが最も失敗しにくいアプローチだ。

その上で、運用に入ったときに直面する課題を3つ挙げておく。

1つ目はコストの増幅だ。エージェントが増えるほどLLM API呼び出し回数が増える。Critic-in-the-loopを3エージェント構成で5回イテレーションすると、1タスクあたりGPT-4クラスのモデルで数百円に達することもある。見積もりは最悪ケース（最大イテレーション × エージェント数）で行い、月間の想定タスク数を掛けて予算感を確認しておくべきだ。

2つ目はデバッグの困難さ。問題が起きたとき、どのエージェントのどのステップで間違いが混入したかを特定するのが難しい。各エージェントの入出力を構造化ログとして記録することが不可欠で、特にCriticが「OK」と判定したのに最終成果物がおかしい場合は、Criticの入力ログから遡ると原因に辿り着きやすい。LangSmithやBraintrustのような観測ツールを使えばトレース全体を可視化できる。

3つ目は暴走の防止。Plannerが際限なくサブタスクを生成したり、Executor同士が互いにタスクを投げ合って無限ループに陥ったりするリスクがある。タイムアウト、最大ステップ数、予算上限——この3つのガードレールは、どれほど小規模なシステムでも最低限設定しておくことを勧める。

マルチエージェントが有効な業務シナリオとして、ここではカスタマーサポートの自動化を掘り下げてみる。

典型的な構成は、Triage Agent（問い合わせの分類）→ Research Agent（ナレッジベース検索）→ Draft Agent（回答案作成）→ Review Agent（品質チェック）の4段構成だ。人間のオペレーターは最終確認のみ行う。一見すっきりした構成に見えるが、実際に動かすと最初につまずくのはReview Agentだ。判定基準が甘いと、Draft Agentが生成した事実誤認を含む回答がそのまま通過してしまう。「顧客向け回答に事実誤認があってはならない」という当たり前のルールも、Review Agentのプロンプトに具体的なチェック項目として書き出さないと機能しない。

この構成はソフトウェア開発にも応用されている。Planning Agent → Coding Agent → Testing Agent → Review Agentの流れで、Claude CodeやDevinがこのパターンの実用例だ。市場調査レポートでも、Data Collection → Analysis → Writing → Fact-Checkの流れで、手作業なら数日かかるプロセスを数時間に短縮できる。

いずれのケースでも、完全自律のマルチエージェントシステムは技術的には構築できる。しかしビジネス上の判断が絡む場面では、エージェントが最適解とした回答が、組織の文脈や慣習、ステークホルダーの感情を無視していることが少なくない。「技術的に正しい」と「ビジネスとして適切」は別の話だ。だからこそ、人間のレビューポイントをシステムに組み込んでおくことが、現時点では最も現実的な運用方針になる。