1 体の大きな AI にすべてを任せるのではなく、役割を分けた複数の AI（エージェント）を協調させる――これがマルチエージェント設計です。各エージェントは別々の指示文（システムプロンプト）・使えるツール・記憶を持ち、人間のチームのように分担します。本稿は「なぜ分けるのか」「どう組むのか」を、2026 年時点の実在フレームワークの具体例とともに、初学者でも読めるように整理します。
FIG.1 司令塔が仕事を分解し、専門エージェントへ委譲・統合する基本形
01なぜ 1 体で済ませず「分ける」のか
1 つのモデルに長大な指示を詰め込むと、文脈が膨らんで判断がぶれ、テストもしづらくなります。役割で分けると、それぞれが小さく明確になり、扱いやすくなります。主な動機は次の通りです。
- 専門化：コードレビューと営業対応を 1 体で兼ねるより、役割ごとに最適な指示文を与えるほうが精度が出る。
- コスト最適化：単純なタスクは安価で速いモデル、難しい判断だけ上位モデルへ振り分けられる。
- 並列性：複数の調査を同時に走らせ、待ち時間を縮められる。
- 権限分離：機密データを読むだけのエージェントと、外部へ書き込むエージェントを分け、事故範囲を限定できる。
- テスト容易性：「コードレビュアー」のように役割が 1 つなら、単体で入出力を検証しやすい。
02主要フレームワーク（2026 年時点の実態）
この分野は動きが速く、数年前の解説は古くなっています。2026 年 6 月時点で「いま現役か」を含めて押さえておきましょう。バージョンや料金は変わるため、採用前に必ず公式の最新情報を確認してください。
| フレームワーク | 2026 年の位置づけ |
|---|---|
| LangGraph（LangChain） | 状態遷移グラフでフローを記述。分岐・ループ・人間承認に強く、現役の主力。 |
| OpenAI Agents SDK | 軽量だった Swarm の後継として本番向けに刷新。Swarm はすでに非推奨。 |
| Claude Code サブエージェント | コーディング作業に統合された委譲機能。ファイル操作と相性が良い。 |
| Microsoft Agent Framework | AutoGen の後継。AutoGen 自体は保守モードに移行。 |
| CrewAI | 「人間のチーム」比喩でロール分担。導入の手早さが魅力。 |
LangGraph（LangChain）
エージェントの流れを状態遷移グラフ（StateGraph）として書くのが特徴。条件分岐・ループ・並列実行を明示的に組め、複雑なワークフローを「どこで何が起きているか」追いやすいのが強みです。途中状態を保存するチェックポイント機能があり、失敗箇所からの再開・人間の承認待ち（human-in-the-loop）・実行履歴をさかのぼるデバッグができます。Klarna・LinkedIn・Uber・Replit などが本番のエージェント処理に採用しています。学習曲線はやや急ですが、状態管理が明示的なぶん大規模化しても破綻しにくい構成です。
OpenAI Agents SDK（旧 Swarm の後継）
かつて OpenAI が公開した軽量フレームワーク Swarm は、エージェント同士が直接タスクを「ハンドオフ」する簡潔な設計で知られましたが、あくまで教育用の実験的プロジェクトでした。現在 Swarm は非推奨で、本番用途には後継の OpenAI Agents SDK が推奨されています（2025 年 3 月公開、2026 年時点でも活発に更新）。ハンドオフという考え方は引き継ぎつつ、本番運用に必要なツール実行・トレース・ガードレールなどが整理されています。これから新規に学ぶなら Swarm ではなく Agents SDK を選ぶのが妥当です。
Claude Code サブエージェント
Claude Code に組み込まれた委譲機能で、専門の作業を別のサブエージェントに任せられます。サブエージェントは .claude/agents/ 配下のマークダウンファイルとして定義し、それぞれに専用のシステムプロンプト・使えるツールの許可範囲・独立した文脈ウィンドウを持たせます。プロジェクト直下に置けばそのリポジトリ専用、ホーム配下に置けば全プロジェクト共通になります。コーディングのワークフローにそのまま溶け込み、ファイル操作との親和性が高いのが利点です。
その他の選択肢
- Microsoft Agent Framework：会話型で知られた AutoGen の後継。AutoGen 本体は保守モード（バグ修正中心）に移行し、Semantic Kernel と統合された新フレームワークが推奨経路。なお元の貢献者による community fork「AG2」も並行して開発されています。
- CrewAI：エージェントを「役割（ロール）」として定義し、人間のチームのように分担させる設計。短いコードで組めて導入が速い。
- 軽量・言語別の選択肢：TypeScript なら Mastra など、用途と言語に合わせた軽量フレームワークも増えています。
03代表的な構成パターン
フレームワークが違っても、組み方の「型」は共通しています。題材に応じて使い分けます。
FIG.2 代表 4 パターン：司令塔+専門家 / パイプライン / 批評ループ / 投票・合議
司令塔 + 専門家（Coordinator + Specialists）
司令塔が依頼を分解し、専門エージェントに委譲、最後に結果を統合する。役割分担の出発点として最も使いやすい。
パイプライン（Pipeline）
取得 → 分類 → 要約 → 出力、と一方向に流す。各ステップで別のモデルを使ってよく、安いモデルと上位モデルを混在させやすい。
批評ループ（Critic Loop）
1 体が出力し、別の 1 体が批評、元のエージェントが修正、を繰り返す。品質が上がる反面、停止条件を決めないと無限ループになりやすい。
投票 / 合議（Vote / Consensus）
同じ問題を複数体に解かせ、多数決や突き合わせで答えを決める。重要な意思決定で効くがコストは増える。
04設計原則
どのパターンでも、土台になる原則は変わりません。
- 役割を明確に：「コードレビュアー」「テスト書き」のように 1 体 1 役にする。兼務させると指示が曖昧になる。
- 引き渡しを構造で定義：次のエージェントに「何を・どの形で」渡すかをデータ構造（型）で決める。自然文の口伝に頼らない。
- 状態を分けて管理：会話履歴とタスクの作業メモを混ぜない。LangGraph のチェックポイントのように、状態を保存できると再開・追跡が楽になる。
- 失敗時の経路を用意：1 体が失敗したら別経路へ切り替える、リトライ上限を設ける、など。
- 権限は最小に：外部へ書き込む・課金が発生する操作は、限定したエージェントだけに許可し、重要操作は承認を挟む。
- 監査ログを残す：どのエージェントが何を判断し、どのツールを呼んだかを追跡できるようにする。
マルチエージェントの成否は、賢いモデルより 「役割分担と引き渡しの設計」 で決まる。
05過剰設計の罠と、まず単体から始める理由
「とりあえず 5 体で」と始めると、エージェント間の調整コストが急増し、デバッグも難しくなります。鉄則は、まず単一エージェントで動かし、明確に必要が出てから分割すること。役割を増やすほど、ハンドオフ漏れ（必要な情報が次に伝わらない）や役割の重複・抜けといった不具合の余地が広がります。
- 無限ループ：批評ループが永遠に修正を続ける → 反復回数の上限を必ず設ける。
- ハンドオフ漏れ：必要情報が次のエージェントに渡らない → 引き渡しを型で固定する。
- 役割の重複・抜け：誰の担当か曖昧な仕事が出る → 役割表で網羅を確認する。
- 個別最適の弊害：各自は最適でも全体は遅い・高い → 全体のコストと遅延で評価する。
06コストの考え方
マルチエージェントは便利な反面、呼び出し回数が増えるぶんコストも積み上がります。たとえば 4 体構成でそれぞれ複数ターンやり取りすれば、単純な「チャット 1 往復」の数倍に膨らむことも珍しくありません。具体的な単価は提供元の料金改定で頻繁に変わるため、必ず公式の最新料金で見積もってください。コストを抑える定石は次の通りです。
モデルを使い分ける
単純な仕分けや要約は軽量モデル、難所の判断だけ上位モデルへ。パイプラインの各段で切り替える。
文脈を要約して渡す
会話履歴を丸ごと渡さず、必要分だけ要約。入力トークンを減らせば費用も遅延も下がる。
並列化で待ちを減らす
独立した調査は並行実行。総コストは変わらなくても、体感速度と全体時間を改善できる。
Safety & Permissions
一番怖いのは「権限を持ったエージェントの暴走」
複数エージェントで現実的に怖いのは、外部に書き込めるエージェントが誤った判断で取り返しのつかない操作をすることです。下図のように、危険な操作の前に承認ゲートを挟み、書き込み権限を持つエージェントを最小限に絞ります。読むだけのエージェントと、実行するエージェントを分けるのが基本です。
FIG.3 危険操作の前に承認ゲートを置き、権限を最小化する
あわせて、ハルシネーション（もっともらしい誤り）への備えも必要です。エージェントの出力は鵜呑みにせず、一次情報や検証用エージェントで突き合わせてから次工程へ渡す設計にします。監査ログで「誰が何を判断したか」を残せば、事故時の原因究明も速くなります。
07まとめ
マルチエージェントは専門化と並列化で力を発揮しますが、調整コストとデバッグ難度は確実に上がります。だからこそ、まずは単一エージェントで動かし、必要が明確になってから分割するのが現実的です。フレームワークは、複雑なフロー制御なら LangGraph、OpenAI 系なら Agents SDK（Swarm の後継）、コーディング作業なら Claude Code サブエージェント、というように目的と土俵で選ぶのがコツです。いずれを選んでも、役割を明確にし、引き渡しを構造で定義し、権限を最小化して監査ログを残す――この土台が品質と安全を支えます。
