検索・推論・生成・監査を単一 LLM エージェントに詰め込み、スケール時にコンテキスト溢れ・直列タイムアウト・単一障害点に直面している方へ——本稿はアーキテクチャレビューにそのまま書ける完全パスを示します。① 単一エージェントでは足りない理由と MAS（マルチエージェントシステム）の三つの制御モード；② 本番シーンの 95% をカバーする六大オーケストレーション設計パターン（LangGraph / AutoGen コード付き）；③ LangGraph vs CrewAI vs AutoGen 選定マトリクスと MCP+A2A 二層通信プロトコル；④ 状態永続化、可観測性、五大落とし穴と選定決定木。MCP プロトコル解説、MCP Server チュートリアルと補完関係です——本篇はマルチエージェントオーケストレーション → フレームワーク選定 → 本番導入に焦点を当てます。
MLflow 2026 年レポートによれば、Google 社内 Agent Bake-Off 実験では、分散マルチエージェントアーキテクチャ採用後、処理時間が 1 時間から 10 分に短縮され、6 倍以上の改善が確認されています。AdaptOrch（2026 年学術論文）はさらに示しています。マルチエージェントシステムでは、オーケストレーション・トポロジの選択が基盤モデル選択より性能への影響が大きいこと、SWE-bench 等のベンチマークで正しいトポロジが 12–23% の性能向上をもたらすことが分かっています。
マルチエージェント協調システム（Multi-Agent System、MAS）とは、複数の独立した AI エージェントが、明確な通信プロトコルとオーケストレーション機構を通じて協調し、単一エージェントでは効率的に完了できない複雑タスクを遂行するシステムです。
エージェント A の出力がそのままエージェント B の入力となり、厳密に線形実行されます。適用例：ステップ間に厳密な依存関係があり、フローが固定で動的ルーティングが不要な場合（記事制作パイプライン、コードレビューフロー）。
from langgraph.graph import StateGraph, START, END
from typing import TypedDict
class PipelineState(TypedDict):
query: str
retrieved_docs: str
analysis: str
final_report: str
def retrieval_agent(state):
return {"retrieved_docs": search_knowledge_base(state["query"])}
def analysis_agent(state):
result = llm.invoke(f"分析：{state['retrieved_docs']}")
return {"analysis": result.content}
builder = StateGraph(PipelineState)
builder.add_node("retriever", retrieval_agent)
builder.add_node("analyzer", analysis_agent)
builder.add_edge(START, "retriever")
builder.add_edge("retriever", "analyzer")
builder.add_edge("analyzer", END)
pipeline = builder.compile()
長所・短所：実装が単純で挙動が予測可能、コンプライアンス監査に適します。一方、総所要時間は各ステップの合計となり、単一ステップ失敗で全体がブロックされ、動的分岐には対応できません。
複数エージェントが独立サブタスクを同時処理し、集約ノードで結果をマージします。総所要時間は max(T1, T2, ..., Tn) となり、合計ではありません。適用例：サブタスクが互いに独立している場合（多ソース調査、多次元リスク評価）。
from langgraph.types import Send
from typing import Annotated
import operator
class ResearchState(TypedDict):
query: str
research_results: Annotated[list, operator.add]
final_synthesis: str
def supervisor(state):
return [Send("research_worker", {"query": state["query"], "source": s})
for s in ("academic", "industry", "news")]
def research_worker(state):
return {"research_results": [search_by_source(state["query"], state["source"])]}
技術ポイント：LangGraph の Send API は Send オブジェクトのリストを返し、サブグラフが真に並列実行されます。Annotated[list, operator.add] Reducer と組み合わせると、並列ブランチの結果が自動集約され、手動ロックや同期ロジックが不要です。
スーパーバイザーエージェントが意図認識・タスク分解・ルーティング決定を担い、サブタスクを専門 Worker に割り当て、最後に集約します。適用例：異なる専門領域に分解できる作業（リサーチャー、ライター、コーダー）、多様なタスクタイプに動的ルーティングが必要な場合（Replit コードアシスタント、カスタマーサポート）。
二層ルーティング最適化：第一層はキーワード高速チャネル（応答 <1ms、LLM 不要）；第二層は LLM 精密ルーティングで複雑・曖昧な意図を処理します。
エージェント間が P2P でタスクを直接受け渡し、中央コーディネーターは存在せず、ラウンド数・合意・タイムアウト等の終了条件で停止します。適用例：多ラウンド交渉・議論（コードレビュー、案の評価）。注意：非決定論性が高く、本番環境では慎重に使うべきです。階層型モードへの置き換えを推奨します。 AutoGen GroupChat 例では max_round=6 の硬性終了条件を設定し、無限ループを防ぎます。
全エージェントが構造化された共有ワークスペース（ブラックボード）を持ち、前提条件を満たしたときに能動的に読み書きします。明示的スケジューリングは不要です。適用例：長時間非同期タスク（数時間〜数日）、異種サービス協調、ワークフロー条件が複雑で事前ルーティングが困難な場合。
同一システム内で複数パターンを組み合わせ、通常は「スーパーバイザーモード + パイプライン」です。実例：Intent Agent がルーティング → 単純クエリは直接回答；複雑レポート → Supervisor 階層 → 並列調査ファンアウト + 品質保証パイプライン（監査 → 人手監査 → 公開）。
| 次元 | LangGraph | CrewAI | AutoGen（Microsoft） |
|---|---|---|---|
| アーキテクチャパラダイム | ステートマシングラフ | ロール制チーム | 対話型マルチエージェント |
| プログラミング言語 | Python / JS/TS | Python | Python / .NET |
| 学習曲線 | やや急 | 緩やか | 中程度 |
| 状態管理 | ネイティブ対応 | 自前実装が必要 | 限定的 |
| Human-in-the-Loop | ネイティブ対応 | 自前実装が必要 | 対応 |
| 可観測性 | LangSmith（商用） | 限定的 | Azure Monitor |
| 本番運用適性 | 最高 | 中 | 高 |
| 迅速プロトタイプ | 中 | 最高 | 高 |
| Azure 統合 | 中 | 低 | 最高 |
| 適したシーン | 複雑なステートフルワークフロー | ロール制コンテンツパイプライン | 対話型協調 |
LangGraph を選ぶ場合：本番級信頼性（金融・医療）、複雑な状態管理と永続化、Human-in-the-Loop の精密制御、条件分岐とループの正確な表現が必要なときです。
CrewAI を選ぶ場合：1–2 日で Idea を迅速検証したい、チームが「ロール」で直感的にエージェントを理解できる、コンテンツ生成・調査レポート等のロール制シーンです。
AutoGen を選ぶ場合：Microsoft/Azure 技術スタック、エージェント多ラウンド議論と反復推論が必要、研究や対話モードの迅速実験です。
2026 年現在、マルチエージェントシステムの通信プロトコルは二層の補完アーキテクチャに標準化され、いずれも Linux Foundation Agentic AI Foundation の管理下にあります。
各 A2A エージェントは Agent Card（/.well-known/agent.json）を公開し、Orchestrator は JSON-RPC 2.0 で発見・委任します。詳細はMCP プロトコル解説とMCP Server 開発チュートリアルをご参照ください。
PostgresSaver を LangGraph チェックポイントストレージとして使うと、プロセス再起動後も前回状態から復旧できます（thread_id でセッション横断）。
LangGraph interrupt() は高リスク操作前に一時停止し、人手確認を待ちます（例：本番 DB 変更）。
外部エージェント呼び出しに Circuit Breaker（CLOSED / OPEN / HALF_OPEN）を適用し、失敗閾値で遮断し、カスケード障害を防ぎます。
TokenBudgetManager は各エージェント呼び出し前に残予算を確認し、超過時に BudgetExceededException を送出、エージェント単位で使用量を記録します。
MAST 研究チームによる 1642 件の実行トレース分析では、マルチエージェントシステムの障害分布は次のとおりです。
| 障害タイプ | 割合 | 説明 |
|---|---|---|
| システム設計問題 | 41.77% | ステップ重複、ツール選択誤り、コンテキスト溢れ、終了条件欠如 |
| エージェント間非整合 | 36.94% | 引き渡し時のコンテキスト喪失、一エージェントの幻覚が次の「事実」になる |
| タスク検証失敗 | 21.30% | 早期終了、不完全な検証 |
さらに懸念すべき点：57% の組織がすでに本番でエージェントを稼働させていますが、LLM 可観測性を完了したのは 8% のみです。大量のエラーが HTTP 200 で返り、監視ダッシュボードは緑なのに、実際の出力は誤りという状態が起きています。
分散トレーシング：各エージェント呼び出しに correlation_id を付与し、OpenTelemetry span で agent.name、tokens_used、status を記録します。
主要監視指標：エンドツーエンドタスク完了率（目標 >85%）、P95 遅延（<30s）、各エージェントエラー率（<5%）、リトライ回数、Token コスト、LLM-as-a-Judge 出力品質スコア。
エージェント A が幻覚を生成し、誤結果が B・C に伝播すると、システム全体が誤った前提で出力しますが、HTTP ステータスは 200 のままです。対策：各エージェント引き渡し点で Schema 検証、信頼度閾値（<0.7 は拒否）、必須フィールドチェックを行います。
エージェントがリトライループに入ると、数分で Token 費用が想定の百倍に膨らみます。対策：硬性上限 MAX_ITERATIONS=10、MAX_TOOL_CALLS_PER_AGENT=20、MAX_TOTAL_TOKENS=50_000；LangGraph interrupt_before で高コスト操作前に一時停止します。
単純な二段 LLM チェーンを 8 エージェントに分割すると、デバッグ難度が指数関数的に上がります。原則：まず順次パイプラインから始め、並列要件・コンテキスト超過・専門能力の独立アップグレード等の具体証拠がある場合のみエージェントを増やします。本番システムの最適エージェント数は通常 3–8 個です。
社内デモは良好でも、本番投入後にエッジ入力で頻繁に失敗します。対策：入力長制限、プロンプトインジェクション検出、PII フィルタ、有害コンテンツ検出——ProductionGuardrails を初日から配置します。
Send API で並列ブランチを dispatch した後、Supervisor が遅いブランチ完了前に再実行され、重複実行が起きます。対策：builder.add_node("supervisor", supervisor_node, defer=True) で明示的同期バリアを作成します。
thread_id でチェックポイント再開と Human-in-the-Loop をサポートします。核心要点：① オーケストレーション・トポロジ > モデル選択；② 単純な順次パイプラインから始める；③ MCP + A2A が将来標準；④ 可観測性はオプションではない；⑤ 本番エージェント数 3–8 個が最適、超過時は階層化を検討。
2026 年の注目点：連邦型オーケストレーション（複数チームのサブオーケストレーターがルーティング戦略を共有）、マルチモーダルマルチエージェント（視覚・音声とテキストの混合）、適応型トポロジ選択（AdaptOrch 方向）、EU AI Act コンプライアンスによる完全な意思決定監査チェーン。
ただし LangGraph オーケストレーション、MCP Server、A2A Gateway をスリープするノート PC や共用開発マシンで動かすと、三つの隠れコストが発生します。チェックポイントとセッションがフタ閉めで中断、環境ドリフトによるエージェント引き渡し失敗、7×24 多段階ワークフローを維持できないことです。安定したマルチエージェントオーケストレーションと MCP/A2A 長時間接続が必要な本番環境では、Gateway と状態ストレージを MACCOME Mac mini（M4 / M4 Pro）専有ノードに置く方が、ローカルでスリープ戦略と戦うより総コストが低いことが多いです。公開プランはレンタル料金ページをご参照ください。
よくある質問
LangGraph、CrewAI、AutoGen はどう選べばよいですか？
本番級状態管理、Human-in-the-Loop、複雑分岐には LangGraph；ロール制の迅速プロトタイプには CrewAI；Microsoft/Azure スタックで多ラウンド議論には AutoGen。詳細は上記比較マトリクスをご参照ください。
MCP と A2A はマルチエージェントシステムでそれぞれ何を担いますか？
MCP は垂直層（エージェント ↔ ツール）、A2A は水平層（エージェント ↔ エージェント）です。詳細はMCP プロトコル解説をご覧ください。
本番環境ではエージェントをいくつ用意すべきですか？
実証上のスイートスポットは 3–8 個です。超過すると調整オーバーヘッドが利益を上回ることが多く、サブチームへの階層化分解を検討してください。