マルチエージェントとは？仕組み・4つのパターン・LangGraph実装まで解説

シングルエージェントで構築したRAGやツール呼び出しエージェントが機能しているとき、次の壁にぶつかることがあります。「コンテキスト長の限界」「複数の専門スキルを1エージェントに詰め込むことの精度低下」「並列処理ができない処理速度の問題」という課題に直面した方も多いでしょう。

そこで本記事では、

• マルチエージェントシステムの定義とシングルエージェントとの設計上の違い
• Supervisor/Swarm/Pipeline/DAGの4つのオーケストレーションパターン
• LangGraphを使ったSupervisorパターンの実装（動作確認済みコード付き）
• シングルとマルチの選択判断フロー
• 実装時のエラーハンドリング・コスト・デバッグの注意点

についてわかりやすく解説します。LangGraphやマルチエージェント実装に取り組む方は、ぜひ最後までご覧ください。

⇨リベルクラフトへの無料相談はこちら

マルチエージェントシステムとは

マルチエージェントシステムの定義

マルチエージェントシステム（Multi-Agent System: MAS）とは、複数の自律エージェントが協調してタスクを実行するシステムです。

学術的には1990年代の分散人工知能（DAI: Distributed AI）研究に起源を持ちます（参考：J-STAGE：マルチエージェントシステム）。エージェントが「環境を認識し、目標に向かって行動する自律的な計算エンティティ」として定義されたのは1990年代ですが、LLMの登場によってこの概念が実用レベルで実現されるようになりました。

現在のLLMベースのマルチエージェントシステムでは、各エージェントがLLMを推論エンジンとして使い、ツール（API・データベース・コード実行環境）を介して外部と相互作用します。オーケストレーター（指揮者エージェント）が複数のサブエージェントのタスク割り当てと結果統合を担う構成が主流です（参考：Anthropic Agentic Systems）。

シングルエージェントとの違い

マルチエージェントシステムとシングルエージェントの設計上の差異を整理します。

比較軸	シングルエージェント	マルチエージェント
スケーラビリティ	低（コンテキスト長の上限に依存）	高（タスクを分割・並列処理できる）
エラー影響範囲	全体に波及	サブエージェント単位で分離可能
専門性	汎用的（1エージェントがすべてを担当）	役割別に最適化できる
実装複雑度	低	高（オーケストレーション設計が必要）
レイテンシ	低	高め（エージェント間通信のオーバーヘッドあり）

シングルエージェントが優れているのは「コンテキスト長に収まるタスク」「シンプルなフロー」「開発速度を優先したPoC」です。マルチエージェントが有効なのは「タスクが複数の専門スキルに分解できる」「並列処理が必要」「サブタスクのエラーを分離したい」場合です。設計の選択はこのトレードオフで決まります。

マルチエージェントの仕組み（処理フロー）

タスク分解とエージェント間の協調

マルチエージェントシステムの処理フローは「入力→タスク分解→サブエージェント実行→結果統合→出力」の5ステップで構成されます。

具体例として「翻訳→要約→品質評価」の3エージェント協調フローを見てみましょう。

1. ユーザーが「この英文記事を日本語に翻訳して、500字に要約し、品質を評価して」と入力
2. オーケストレーターが3つのサブタスクを識別し、エージェントに割り当てる
3. 翻訳エージェントが原文を日本語に変換（GPT-4o等を使用）
4. 要約エージェントが翻訳結果を500字に圧縮
5. 評価エージェントが翻訳精度・要約品質を採点してレポートを生成
6. オーケストレーターが3エージェントの出力を統合して最終結果を返す

シングルエージェントでも同じことは試みられますが、1エージェントが「翻訳も要約も評価も」担当すると各タスクの専門性が下がり、最終的な出力品質が低下することが多いです。

オーケストレーターの役割

オーケストレーター（Supervisorエージェント）は「どのサブエージェントを、どの順番で、どの条件で呼び出すか」を決定する指揮者です。

具体的には以下の3つの役割を担います。

1. ルーティング：入力内容を解析し、どのサブエージェントに処理を委ねるかを決定する
2. 条件分岐：サブエージェントの実行結果に応じて次の処理を分岐させる（「品質評価が60点以下なら再翻訳エージェントに差し戻す」等）
3. 結果統合：複数サブエージェントの出力を受け取り、最終的な回答としてまとめる

LangGraphではsupervisor_nodeがこの役割を担い、LLMによる関数呼び出し（Function Calling）を使ってどのサブエージェントを呼び出すかを動的に決定する仕組みになっています。

オーケストレーションパターン4種の比較

マルチエージェントシステムには複数のオーケストレーションパターンが存在します。4つの主要パターンの特性と対応フレームワークを整理します。

Supervisorパターン（集中管理型）

1つのSupervisorエージェントが全サブエージェントを管理する集中制御アーキテクチャです。Supervisorはタスクを分解し、サブエージェントに割り当て、結果を確認して次のアクションを決定します。

対応フレームワーク：LangGraph、Amazon Bedrock Multi-Agent、OpenAI Agents SDK

適した場面：複雑な意思決定・多段階の条件分岐が必要なタスク。「調査→分析→レポート作成」のような順序依存のタスクに特に有効です。

注意点：SupportやSupervisorがボトルネックになりやすいです。並列処理の最適化はSupervisorの設計に依存します。

Swarmパターン（分散協調型）

エージェント同士がピアツーピアで協調する分散型アーキテクチャです。OpenAIが2024年に公開した実験的フレームワーク「Swarm」が代表例で、エージェントが別のエージェントに処理を「ハンドオフ」することで協調します。

対応フレームワーク：AutoGen、OpenAI Swarm（実験的）

適した場面：スケールアウトが必要なケース、単一障害点を持ちたくない高可用性要件のシステム。

注意点：デバッグが難しく、エージェント間の状態管理が複雑になります。本番環境での採用には観測可能性（Observability）の設計が必須です。

Pipelineパターン（逐次処理型）

前段エージェントの出力を次段エージェントの入力とする直列処理型です。処理フローが明確で実装しやすい反面、ステップが増えるほどレイテンシが積み上がります。

対応フレームワーク：LangChain（chain構成）、Difyマルチエージェント

適した場面：「A→B→C」の順序が固定されている線形フローが明確なタスク。テキスト変換・データ変換パイプラインに向いています。

注意点：並列処理には不向きです。ステップ間でのエラーが全体を止めます。

DAGパターン（有向非巡回グラフ型）

依存関係を持つタスクを並列・順序制御しながら処理するグラフ構造です。有向非巡回グラフ（DAG: Directed Acyclic Graph）でタスク間の依存関係を表現し、依存関係のないタスクを並列実行します。

対応フレームワーク：LangGraph Graph API、Apache Airflow（AI統合版）

適した場面：複雑な依存関係を持つパイプラインで並列処理を最適化したいケース。複数の検索エージェントを並列実行して結果を統合するユースケースに有効です。

4パターン一覧比較

パターン	制御方式	対応フレームワーク	適した場面	実装難易度
Supervisor	集中管理	LangGraph・Bedrock・OpenAI Agents	条件分岐が複雑なタスク	★★★
Swarm	分散協調	AutoGen・OpenAI Swarm	スケールアウト・高可用性	★★★★
Pipeline	逐次処理	LangChain・Dify	線形フローが明確なタスク	★★
DAG	依存グラフ	LangGraph Graph API	並列最適化が必要	★★★

LangGraph Supervisorパターンの実装

LangGraphを使ってSupervisorパターンを最小構成で実装します。「Web検索エージェント」と「文書分析エージェント」を持つ2サブエージェント構成のサンプルです。

環境準備

pip install langgraph langchain-openai python-dotenv

.envファイルにAPIキーを設定します。

OPENAI_API_KEY=your_api_key_here
LANGCHAIN_TRACING_V2=true
LANGCHAIN_API_KEY=your_langsmith_key_here  # LangSmithでトレーシングする場合

StateGraphの定義

from langgraph.graph import StateGraph, END
from langchain_core.messages import HumanMessage, AIMessage, SystemMessage
from typing import TypedDict, Annotated, Sequence
import operator


# エージェント全体で共有するStateの定義
class AgentState(TypedDict):
    messages: Annotated[Sequence, operator.add]  # 会話履歴を蓄積
    next: str  # 次に呼び出すエージェント名（"web_search" / "doc_analysis" / "FINISH"）


# グラフの初期化
graph = StateGraph(AgentState)

supervisor_nodeの実装

SuoervisorはLLMが「どのサブエージェントを呼ぶか」を決定します。Function Callingを使ってエージェント名を返します。

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from pydantic import BaseModel


# Supervisorが返す出力の型定義
class RouteDecision(BaseModel):
    next: str  # "web_search" / "doc_analysis" / "FINISH"


# Supervisorが判断に使うプロンプト
SUPERVISOR_PROMPT = """あなたはエージェントを管理するスーパーバイザーです。
以下のエージェントから適切なものを選んでください：
- web_search: Web検索が必要なタスク（最新情報・外部データが必要な場合）
- doc_analysis: アップロードされたドキュメントの分析が必要なタスク
- FINISH: タスクが完了した場合、または回答に十分な情報が揃った場合

現在の会話履歴を確認し、次に呼び出すべきエージェントを選択してください。"""

supervisor_llm = ChatOpenAI(model="gpt-4o", temperature=0)
supervisor_llm_with_tools = supervisor_llm.with_structured_output(RouteDecision)


def supervisor_node(state: AgentState) -> AgentState:
    """どのサブエージェントを次に呼び出すかを決定する"""
    prompt = ChatPromptTemplate.from_messages([
        SystemMessage(content=SUPERVISOR_PROMPT),
        *state["messages"]
    ])
    result = supervisor_llm_with_tools.invoke(prompt.format_messages())
    return {"next": result.next}

サブエージェント（tool_node）の実装

from langchain_community.tools.tavily_search import TavilySearchResults
from langchain_openai import ChatOpenAI


# Web検索エージェント
search_tool = TavilySearchResults(max_results=3)
search_llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)  # コスト削減のため軽量モデルを使用

def web_search_agent(state: AgentState) -> AgentState:
    """Web検索を実行して結果をstateに追加する"""
    last_message = state["messages"][-1].content
    search_results = search_tool.invoke(last_message)
    
    # 検索結果をLLMに要約させる
    summary = search_llm.invoke([
        SystemMessage(content="以下の検索結果を日本語で簡潔に要約してください。"),
        HumanMessage(content=str(search_results))
    ])
    return {"messages": [AIMessage(content=f"[Web検索結果]\n{summary.content}")]}


# 文書分析エージェント
doc_llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

def doc_analysis_agent(state: AgentState) -> AgentState:
    """ドキュメントの内容を分析してstateに追加する"""
    last_message = state["messages"][-1].content
    analysis = doc_llm.invoke([
        SystemMessage(content="与えられたテキストを分析し、重要なポイントを箇条書きで整理してください。"),
        HumanMessage(content=last_message)
    ])
    return {"messages": [AIMessage(content=f"[文書分析結果]\n{analysis.content}")]}

実行と動作確認

# ノードの追加
graph.add_node("supervisor", supervisor_node)
graph.add_node("web_search", web_search_agent)
graph.add_node("doc_analysis", doc_analysis_agent)

# エッジの設定：supervisorの判断に基づいて条件分岐
graph.add_conditional_edges(
    "supervisor",
    lambda state: state["next"],  # stateの"next"フィールドで分岐
    {
        "web_search": "web_search",
        "doc_analysis": "doc_analysis",
        "FINISH": END
    }
)

# サブエージェントは実行後にsupervisorに戻る
graph.add_edge("web_search", "supervisor")
graph.add_edge("doc_analysis", "supervisor")

# エントリーポイントはsupervisor
graph.set_entry_point("supervisor")

# グラフをコンパイル
app = graph.compile()

# 実行例
result = app.invoke({
    "messages": [HumanMessage(content="LangGraph 0.2の主な変更点を調べてください")],
    "next": ""
})

# ストリーミング実行（デバッグ時に各ステップを確認できる）
for step in app.stream(
    {"messages": [HumanMessage(content="LangGraph 0.2の主な変更点を調べてください")], "next": ""},
    stream_mode="updates"
):
    print(step)

stream_mode="updates"を使うと各ノードの実行結果がリアルタイムで表示されるため、デバッグ時に有効です。本番環境ではLangSmithでトレーシングを設定しておくと、エージェント間のやり取りを可視化できます。

実装で詰まったら： マルチエージェントの設計・LangGraph実装について個別にご相談いただけます。無料相談フォームからどうぞ。

シングル vs マルチエージェント：選択判断フロー

マルチエージェントを選ぶべき4つの条件

以下の4条件を1つでも満たす場合は、マルチエージェントアーキテクチャを検討する価値があります。

1. タスクが複数の専門スキルに分解できる：「Web検索＋要約＋評価」「コード生成＋テスト＋セキュリティ検査」のように、異なる専門性が求められる場合
2. 並列処理でレイテンシを短縮できる：複数の独立したタスクが存在し、シングルエージェントで逐次処理するより並列実行が速い場合
3. サブタスクのエラーが全体に波及しないよう分離したい：検索エージェントがタイムアウトしても、分析エージェントや回答生成エージェントへの影響を最小化したい場合
4. スケールアウトが将来的に必要：エージェントの役割分担を維持しながら、新しい機能（エージェント）を追加できる拡張性が必要な場合

4条件すべてを満たす必要はありません。1〜2条件で「明らかにシングルでは難しい」と判断できる場合はマルチエージェントを選ぶ判断になります。

シングルエージェントで十分なケース

マルチエージェントは実装コストが高く、常に最適解とは限りません。以下のケースではシングルエージェントを選びましょう。

• コンテキスト長に収まるタスク：128K〜200Kトークンのコンテキストウィンドウで全情報が処理できる場合
• 開発速度を優先したPoC：2〜4週間のPoC段階ではシングルエージェントで動くものを先に作ります
• レイテンシ最小化が最優先：エージェント間の通信オーバーヘッドが許容できない場合（例：チャットのリアルタイム応答）

シングルエージェントから始め、「コンテキスト長の限界に当たった」「精度向上のために役割分担が必要になった」「並列処理が必要になった」タイミングでマルチエージェントに移行するアプローチが実務では多いです。

活用事例と最新動向

業務自動化への活用事例（3例）

社内ドキュメント処理

ある事業会社のDX推進チームが構築したシステムでは、3つのエージェントが連携しています。検索エージェントが社内文書DBから関連資料を取得し、要約エージェントが回答に必要な情報を抽出し、回答生成エージェントがユーザーの質問に対して最終的な回答を生成する構成です。シングルエージェントで試みた際は「検索精度と回答品質のトレードオフ」が解消できませんでしたが、役割分担によって両者を改善できました。

マーケティングリサーチ

ある製造業のお客様では、収集エージェント（競合情報のWeb収集）・分析エージェント（トレンド分析）・レポート生成エージェントが週次で自動実行されています。従来3人の担当者が分担して行っていた調査業務が、週次レポートの確認と追記のみの作業に変わりました。

コードレビュー

コード変更に対して、静的解析エージェント（lint・型チェック）・セキュリティ検査エージェント（OWASP脆弱性スキャン）・改善提案エージェントが並列実行し、レビューコメントを自動生成する構成です。エンジニアのレビュー待ち時間の削減と、セキュリティチェックの漏れ防止に効果があります。

コーディングエージェントの活用（Claude Code / Codex）

2025〜2026年にかけてコーディングエージェントのマルチエージェント活用が急速に進んでいます。Claude Codeのマルチエージェントモードでは、複数のClaude Codeインスタンスが並列でコード生成・テスト・デバッグを担い、CI/CDパイプラインに統合される事例が増えています。

OpenAI Codexも同様に、コード生成エージェント・テスト生成エージェント・ドキュメント生成エージェントが協調するパイプラインが実装されています（参考：OpenAI Agents SDK）。

これらのコーディングエージェントにおけるマルチエージェントのポイントは「各エージェントが異なるコンテキスト（コードベース・テスト・ドキュメント）を専門に持つ」設計にあります。単一エージェントがすべてを担うより、役割分担によって出力品質が高まります。

強化学習との関係（MARL）

Multi-Agent Reinforcement Learning（MARL：マルチエージェント強化学習）は、LLMエージェントとは異なるアプローチです。MARL型では複数のエージェントが報酬関数を最大化するために相互作用しながら学習します。ゲーム理論・ロボティクス分野での研究が主流で、LLMベースのマルチエージェントとは設計思想が異なります。

LLMエージェントとMARLの違いを端的に言えば、「LLMエージェントは事前学習済みモデルを推論エンジンとして使う」のに対し、「MARLは環境との相互作用で学習する」点にあります。現在の業務システムへの実装はLLMエージェントが主流ですが、MARL的な「継続的な改善」の要素をLLMエージェントに組み込む研究も進んでいます（参考：J-STAGE：マルチエージェントシステム研究動向）。

実装時の注意点・課題

エラーハンドリングと再試行設計

マルチエージェントシステムではサブエージェントが失敗する前提で設計する必要があります。LangGraphでのエラーハンドリングの基本は「エラー発生時のリトライフロー」を条件付きエッジで定義することです。

# エラー時にsupervisorに戻って再試行させる例
graph.add_conditional_edges(
    "web_search",
    lambda state: "supervisor" if "error" in state.get("last_result", "") else "supervisor",
    {"supervisor": "supervisor"}
)

指数バックオフ（1秒→2秒→4秒のリトライ間隔）を設定し、最大リトライ回数を超えた場合はフォールバックエージェント（簡易回答を返す軽量エージェント）に切り替えるパターンが実務的です。サブエージェントが外部APIに依存している場合は、APIのレートリミットとタイムアウト設定も事前に確認しておきましょう。

コスト増加への対処

マルチエージェントはシングルエージェントに比べてLLM呼び出し回数が増加します。3つのサブエージェントを順次呼び出す場合、単純に計算すると同じタスクでも3倍以上のAPIコストがかかります。

コスト最適化の有効な戦略は「中間ステップに軽量モデルを使う」ことです。

• Supervisorの意思決定：gpt-4o（精度が重要）
• Web検索エージェント：gpt-4o-mini（コスト削減）
• 文書分析エージェント：gpt-4o-mini（コスト削減）
• 最終回答生成：gpt-4o（品質が重要）

全ステップにgpt-4oを使うより、この組み合わせでコストを70%程度削減しながら最終出力品質を維持できる場合が多いです。月次でAPIコストをLangSmith等でモニタリングし、各エージェントのコスト配分を定期的に見直しましょう。

デバッグとオブザーバビリティ

マルチエージェントシステムの最大の課題の一つが「何が起きているか見えにくい」ことです。エージェント間のやり取りが複雑になるほど、どこで問題が起きているかの特定が難しくなります。

LangSmith（LangChain公式のトレーシングツール）を最初から設定することを強く推奨します。環境変数にLANGCHAIN_TRACING_V2=trueとLANGCHAIN_API_KEYを設定するだけで、各エージェントの入出力・実行時間・エラーがダッシュボードで可視化されます。

ロギング設計の基本は「各エージェントの入力・出力・実行時間・エラーを構造化ログとして記録する」ことです。中間出力をstream_mode="updates"でリアルタイム確認できる設計にしておくと、開発中のデバッグ速度が大幅に上がります。

まとめ

マルチエージェントシステムについての要点を6点でまとめます。

1. マルチエージェントとは：複数の自律エージェントが協調してタスクを実行するシステムです。シングルエージェントのコンテキスト長・専門性・並列処理の限界を解決します
2. シングルとの設計上の差異：スケーラビリティとエラー分離はマルチが優位、実装複雑度とレイテンシはシングルが優位です
3. 4つのオーケストレーションパターン：Supervisor（集中管理）・Swarm（分散協調）・Pipeline（逐次処理）・DAG（依存グラフ）。タスクの性質と開発コストで選択します
4. LangGraph Supervisorパターンの実装起点：StateGraph定義→supervisor_node（LLMによるルーティング）→tool_node（サブエージェント）→条件付きエッジの4ステップが最小構成です
5. 選択判断の軸：「複数の専門スキル分解が必要か」「並列処理が必要か」「PoCか本番か」でシングルとマルチを選びます
6. 実装上の注意点：エラーハンドリング・コスト最適化（軽量モデルの使い分け）・LangSmithによるオブザーバビリティを最初から設計することが重要です

マルチエージェント実装をハンズオンで学ぶなら

この記事でアーキテクチャと実装の起点は理解できましたが、「実際に動くシステムを作りきれない」「本番運用レベルに引き上げる部分でつまずいている」という方には、Craft College Advancedのハンズオンコースをご紹介します。

LangGraph・Agentic RAG・マルチエージェント実装をコード演習を通じて学ぶプログラムで、実務経験のあるデータサイエンティスト・エンジニアを対象としています。「授業で理解する」だけでなく「自社のプロジェクトに実際に適用できる」レベルを目指して設計されたカリキュラムです。

→ Craft College Advanced の詳細はこちら

マルチエージェント開発の相談は「リベルクラフト」

リベルクラフトでは、マルチエージェントシステムの設計からLangGraphを使った実装まで、企業のAI・データ活用を支援しています。「社内へのAIエージェント・マルチエージェント導入を検討している」「LangGraphを使った受託開発を依頼したい」という企業様のご相談を承っています。

⇨リベルクラフトへの無料相談はこちら