マルチエージェント AI アーキテクチャ実践：設計パターンから本番運用まで

• コンテキストウィンドウの限界：複雑タスクの中間結果がコンテキストを埋め尽くし、後続の推論品質が急落します。
• 専門性の希薄化：検索・コード生成・意思決定監査を一人のエージェントが担うと、どれも中途半端になります。
• 直列実行の非効率：全サブタスクが順次実行され、総所要時間は各ステップの合計になります。
• 単一障害点：一つのエージェントが失敗すると、ワークフロー全体が停止します。

MLflow 2026 年レポートによると、Google 内部 Agent Bake-Off 実験では分散型マルチエージェント採用後、処理時間が 1 時間から 10 分に短縮され、6 倍以上の改善が確認されています。AdaptOrch（2026 年論文）は、マルチエージェントではオーケストレーショントポロジの選択が基盤モデル選択よりシステム性能への影響が大きいことを証明し、SWE-bench 等で正しいトポロジにより 12〜23% の向上を示しました。

引用データ 1：Google Agent Bake-Off で処理時間 60 分 → 10 分（約 6 倍高速化）。

引用データ 2：AdaptOrch がトポロジ優位を実証、ベンチマーク 12〜23% 向上。

引用データ 3：MAST 研究が 1,642 実行トレースを分析：57% の組織が本番稼働、8% のみ LLM オブザーバビリティを完了。

マルチエージェントシステム（MAS）は、複数の独立した AI エージェントが明確な通信プロトコルとオーケストレーション機構で協調し、単一エージェントでは効率的に処理できない複雑タスクを達成するシステムです。

三つの制御モード：集中型（Orchestrator が統括、監査可能だがボトルネック化しやすい）、分散型（P2P 通信、高弾性だがデバッグ困難）、階層型（トップオーケストレーター + サブチームリード、制御と拡張のバランス）。本番では階層型または集中型 + 並列ファンアウトのハイブリッドが最も多く採用されます。

以下の六パターンで本番マルチエージェントシステムの 95% 以上をカバーできます。

パターン一：順次パイプライン（Sequential Pipeline）

エージェント 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: PipelineState):
    docs = search_knowledge_base(state["query"])
    return {"retrieved_docs": docs}

def analysis_agent(state: PipelineState):
    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()

パターン二：並列ファンアウト／ファンイン（Parallel Fan-out / Fan-in）

複数エージェントが独立サブタスクを同時処理し、集約ノードで結果をマージします。総所要時間は max(T1, T2, ..., Tn) となります。LangGraph の Send API と Annotated[list, operator.add] Reducer で真の並列実行と自動集約が可能です。

パターン三：階層型スーパーバイザー・ワーカー（Hierarchical Supervisor-Worker）

スーパーバイザーが意図認識・タスク分解・ルーティングを担当し、専門ワーカーにサブタスクを割り当てます。二層ルーティング（キーワード高速パス <1ms + LLM 精密ルーティング）を推奨します。Replit 型コーディングアシスタントやエンタープライズ CS に適します。

パターン四：スウォーム協調（Swarm / Network）

中央コーディネーターなしでエージェントが P2P でタスクを受け渡し、ラウンド数・合意・タイムアウトで停止します。多ラウンド討論（コードレビュー、提案評価）向けですが、非決定性が高く本番では慎重に。必ず max_round の硬性上限を設定してください。

パターン五：ブラックボード アーキテクチャ（Blackboard）

全エージェントが構造化された共有ワークスペース（ブラックボード）を読み書きし、前提条件が満たされたときに自律的に実行します。時間単位〜日単位の長時間非同期タスクや異種サービス協調に適します。

パターン六：ハイブリッド（Hybrid）

複数パターンを同一システムで組み合わせます。典型的には「Intent ルーター + 階層スーパーバイザー + 並列リサーチファンアウト + 品質保証パイプライン」。エンタープライズコンテンツ生成では、単純クエリは直接回答、複雑レポートはマルチエージェント編成を使い分けます。

LangGraph を選ぶ場合：金融・医療など規制業界、複雑な状態永続化、精緻な Human-in-the-Loop。CrewAI：1〜2 日でアイデア検証、ロール制コンテンツ生成。AutoGen：Microsoft/Azure スタック、多ラウンド討論と反復推論の実験。

2026 年、マルチエージェント通信は Linux Foundation Agentic AI Foundation 管理の二層補完アーキテクチャに標準化されました。MCP（垂直層）はエージェント ↔ ツール／外部システム、A2A（水平層）はエージェント ↔ エージェントのタスク委譲・能力発見・状態同期を担います。

MCP は Anthropic 主導で「一度書けばどこでも使える」ツール統合を実現します。A2A は Google が 2025 年 4 月に開始し、2026 年初頭に v1.0 をリリース。Atlassian、Salesforce、SAP など 50 社以上が参加しています。各 A2A エージェントは /.well-known/agent.json の Agent Card を公開し、Orchestrator は JSON-RPC 2.0 でタスクを委譲します。詳細は MCP 徹底解説を参照してください。

async def discover_and_delegate(agent_url: str, task: str):
    card = (await httpx.get(f"{agent_url}/.well-known/agent.json")).json()
    skills = [s["id"] for s in card["skills"]]
    if "web_research" not in skills:
        raise ValueError(f"Agent {card['name']} は web_research 非対応")
    payload = {
        "jsonrpc": "2.0",
        "method": "message/send",
        "id": "task-001",
        "params": {"message": {"role": "user", "parts": [{"type": "text", "text": task}]}}
    }
    return (await httpx.post(card["url"], json=payload)).json()

• 状態永続化とチェックポイント再開：LangGraph PostgresSaver で thread_id によるプロセス跨ぎ復旧。
• Human-in-the-Loop：interrupt() で高リスク操作を一時停止し、人間の確認後に再開。
• サーキットブレーカーとリトライ：CLOSED / OPEN / HALF_OPEN の三状態で障害エージェントの連鎖を防止。
• トークン予算管理：TokenBudgetManager でタスク単位の上限を設定し、超過時は拒否。

from langgraph.types import interrupt

def high_risk_action_agent(state):
    proposed_action = plan_action(state)
    human_decision = interrupt({
        "proposed_action": proposed_action,
        "risk_level": "HIGH",
        "message": "本番 DB を変更します。実行を確認してください"
    })
    if human_decision["approved"]:
        return execute_action(proposed_action)
    return {"status": "cancelled"}

各エージェント呼び出しに correlation_id を付与し、OpenTelemetry で完全な呼び出しチェーンを構築します。核心指標：E2E タスク成功率（目標 >85%）、P95 レイテンシ（<30s）、エージェント別エラー率（<5%）、タスクあたりトークンコスト。品質次元には LLM-as-a-Judge による自動評価（完全性・正確性・関連性・幻覚検出）を適用します。

• コンテキスト汚染：エージェント A の幻覚が B・C に伝播し、HTTP 200 でも出力は誤り。対策：各引き渡し点で Schema 検証と信頼度閾値（<0.7 で拒否）。
• 無限ループとコスト爆発：MAX_ITERATIONS=10、MAX_TOOL_CALLS_PER_AGENT=20、MAX_TOTAL_TOKENS=50_000 の硬性上限を必ず設定。
• 過剰エンジニアリング：二ステップ LLM チェーンを八エージェントに分割。原則：まず順次パイプライン、具体的根拠がある場合のみ拡張。本番の最適エージェント数は通常 3〜8 個。
• デモと本番のギャップ：入力長制限、プロンプトインジェクション検出、PII フィルタ、有害コンテンツ分類は必須です。

タスクに明確な線形依存がありますか？はい → サブタスクは並列可能？いいえ → 順次パイプライン；はい → 並列ファンアウト + パイプライン混合。いいえ → 決定権を持つエージェントはいますか？はい → 規模にサブチームが必要？いいえ → Supervisor-Worker；はい → 多層階層型。いいえ → 長時間非同期ですか？はい → ブラックボード；いいえ → エージェント ≤5 かつ終了条件が明確？はい → Swarm（硬性上限付き）；いいえ → 階層型へ再設計。

1. オーケストレーショントポロジ > モデル選択：エージェントの協調方法の方が基盤モデルより影響が大きい。
2. シンプルから始める：まず順次パイプラインで核心価値を検証し、必要に応じて並列・階層を導入。
3. MCP + A2A は将来の標準：新規プロジェクトでは直接採用を推奨。
4. オブザーバビリティは必須：57% 本番稼働 vs 8% オブザーバビリティ完了のギャップが事故の温床。
5. 本番エージェント数 3〜8 個が最適：これを超えると調整コストが利益を上回りやすい。

2026 年のトレンド：連合型オーケストレーション（複数チームのサブオーケストレーターがルーティング戦略を共有）、マルチモーダルマルチエージェント、適応型トポロジ選択（AdaptOrch 方向）、EU AI Act による完全な意思決定監査チェーンの義務化。

1. 01
   編成フレームワークとトポロジを決定：規制・長時間タスクは LangGraph + Postgres チェックポイント；迅速なプロトタイプは CrewAI。まずデシジョンツリーでパイプラインか階層型かを確定します。
2. 02
   コンソールでクラウド Mac を起動：NUKCLOUD コンソールにログインし、16 GB 以上のメモリ（マルチエージェント並行時は 32 GB 推奨）を選択。料金ページで時間課金の試運転が可能です。
3. 03
   MCP Server とエージェントノードをデプロイ：MCP Server 開発ガイドに従いツール層を公開；各ワーカーエージェントは MCP 経由で DB・API にアクセスします。
4. 04
   オブザーバビリティを接続：OpenTelemetry + correlation_id；トークン予算、サーキットブレーカー、MAX_ITERATIONS 硬性上限を設定します。
5. 05
   Human-in-the-Loop と本番ガードレール：高リスク操作は interrupt()；入力インジェクション検出、PII フィルタ、引き渡し点 Schema 検証を実装します。
6. 06
   launchd 常駐と月額固定：LaunchAgents plist で 7×24 運用を維持。試運転後は 注文ページでスペックを確定。NUKCLOUD 本番運用 Runbookも参照してください。

ローカル Mac や共有 VPS でマルチエージェント編成を動かすと、フタ閉じによるスリープで長時間タスクが中断、帯域揺らぎによる A2A 接続断、複数開発者によるプロセス競合が頻発します。LangGraph ワークフロー、MCP ツール層、OpenTelemetry コレクターを安定して 7×24 稼働させるには、NUKCLOUD 多地域ベアメタル Mac／クラウド Mac ノードの専用テナント境界とスペック柔軟性がマルチエージェントアーキテクチャと整合しやすくなります。詳細は ヘルプセンターもご覧ください。