【2026年版】LangGraph マルチエージェント入門

中央の発光する司令ノードから5方向へ細い光のスポークが伸び、先端の小さな衛星ノードへ役割を委譲していく階層型の構図

【2026年版】LangGraph マルチエージェント入門

2026年のAIエージェント実装は、単一エージェントの限界を埋めるためマルチエージェント協調へ舵を切りました。ツール数やドメインが増えると単一エージェントの性能が急落するというLangChain公式ブログのベンチマークもあり、「役割を分割して協調させる」設計が現場の標準になりつつあります。

本記事では2026年5月26日リリースのLangGraph 1.2.2を前提に、公式ライブラリlanggraph-supervisorlanggraph-swarmの2系統をコピペで動かします。読者の皆さんは、使い分け早見表と本番運用4ポイントまでを30分で押さえ、読了直後に手元のPythonで動くサンプルを再現できる状態を目指せます。

目次

LangGraph マルチエージェントの2系統 – Supervisor と Swarm

縦の境界線を挟んで左に中央太陽と周回する小惑星のSupervisor型、右に連結リングを成すピア群のSwarm型を対比配置した二分の構図
中央集権型と分散ハンドオフ型を一枚で対比

LangGraphは、状態を持つ長時間実行エージェントを構築するための低レベルなオーケストレーション・ランタイムです(PyPI公式ページ)。その上に乗るマルチエージェント公式ライブラリはSupervisorとSwarmの2系統に整理でき、違いは「中央に司令塔を置くか」の一点に尽きます。

Supervisorは中央のスーパーバイザーエージェント(司令塔となる単一エージェント)が、専門ワーカーへタスクを委譲する階層型(hierarchical)アーキテクチャです(langgraph-supervisor README)。ルーティング精度が高く第三者エージェントの混在にも強い反面、中央を経由するぶんLLM呼び出しが増えやすい構造です。

Swarmは中央コーディネータを持たず、エージェント同士が直接ハンドオフ(処理担当の引き継ぎ)し合う分散制御型(decentralized)アーキテクチャです(langgraph-swarm README)。LLMホップが少なく低レイテンシですが、各エージェントが他のエージェントを把握している必要があります。エンタープライズ規模での選定基準は自律型AIエージェントのエンタープライズ導入動向も参考になります。

開発環境の準備(3分)

LangGraph 1.2.2はPython 3.10以上が必須要件で、CPythonとPyPyの両方で動作します。2026年5月時点で動作確認が取れている組み合わせは下表のとおりです。

パッケージ バージョン 用途
langgraph 1.2.2 コアランタイム
langgraph-supervisor 0.0.31 中央制御型
langgraph-swarm 0.1.0 分散制御型
langchain-openai 最新 LLMクライアント

インストールと環境変数設定はそれぞれ1コマンドで完了します。観測性を上げる場合はLangSmithのキーも併せて設定します。なお、pip install ではハイフン区切りのパッケージ名を、Python の import 文ではアンダースコア区切りのモジュール名を使う点に注意してください(例: pip install langgraph-supervisorfrom langgraph_supervisor import ...)。


pip install langgraph==1.2.2 langgraph-supervisor==0.0.31 langgraph-swarm==0.1.0 langchain-openai
export OPENAI_API_KEY="sk-..."
export LANGSMITH_API_KEY="lsv2_..."   # 任意
export LANGSMITH_TRACING=true         # 任意

30分で実装する Supervisor 構成

「調査担当」と「計算担当」の2ワーカーを、スーパーバイザーが質問内容に応じて呼び分ける典型例から入ります。下記がそのまま動く全文です。


from langchain_openai import ChatOpenAI
from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.memory import InMemorySaver
from langgraph_supervisor import create_supervisor

model = ChatOpenAI(model="gpt-4.1-mini")

def web_search(query: str) -> str:
    """ダミー検索ツール(本番は Tavily 等に差し替え)。"""
    return f"検索結果: {query} に関する2026年の最新情報..."

def add(a: float, b: float) -> float:
    return a + b

research_agent = create_react_agent(
    model=model, tools=[web_search], name="research_agent",
    prompt="あなたは調査担当です。検索のみを行います。",
)
math_agent = create_react_agent(
    model=model, tools=[add], name="math_agent",
    prompt="あなたは計算担当です。計算のみを行います。",
)

workflow = create_supervisor(
    agents=[research_agent, math_agent],
    model=model,
    prompt="質問内容に応じて research_agent / math_agent に委譲してください。",
    output_mode="last_message",
)
app = workflow.compile(checkpointer=InMemorySaver())

config = {"configurable": {"thread_id": "demo-1"}}
result = app.invoke(
    {"messages": [{"role": "user", "content": "2026年のGPU相場と、12.5+7.5は?"}]},
    config=config,
)
print(result["messages"][-1].content)

create_supervisor()公式APIリファレンスのとおりagentsmodelが必須で、戻り値は未コンパイルのStateGraphです。output_modeのデフォルト'last_message'はワーカーの中間メッセージを除去してログを綺麗に保ち、'full_history'に切り替えるとデバッグ用に全履歴を保持できます。InMemorySaverは短期メモリ用のチェックポインタ(対話状態のスナップショットを保存する仕組み)で、thread_id(会話セッションを識別する一意なID)をキーに会話履歴を保持します。本番では後述のPostgresSaverに差し替えます。

30分で実装する Swarm 構成

Swarmは handoff ツールでアクティブなエージェントを会話の途中で切り替える仕組みです。create_handoff_tool()が返すツールを各エージェントに持たせ、create_swarm()でラップします。


from langchain_openai import ChatOpenAI
from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.memory import InMemorySaver
from langgraph_swarm import create_swarm, create_handoff_tool

model = ChatOpenAI(model="gpt-4.1-mini")

def add(a: float, b: float) -> float:
    return a + b

def multiply(a: float, b: float) -> float:
    return a * b

transfer_to_bob = create_handoff_tool(
    agent_name="bob", description="掛け算が必要なときは bob に引き継ぐ。")
transfer_to_alice = create_handoff_tool(
    agent_name="alice", description="足し算が必要なときは alice に引き継ぐ。")

alice = create_react_agent(
    model=model, tools=[add, transfer_to_bob], name="alice",
    prompt="あなたは alice。足し算と必要時の bob へのハンドオフを担当。")
bob = create_react_agent(
    model=model, tools=[multiply, transfer_to_alice], name="bob",
    prompt="あなたは bob。掛け算と必要時の alice へのハンドオフを担当。")

workflow = create_swarm(agents=[alice, bob], default_active_agent="alice")
app = workflow.compile(checkpointer=InMemorySaver())

config = {"configurable": {"thread_id": "swarm-1"}}
result = app.invoke(
    {"messages": [{"role": "user", "content": "(3+5)×4 を計算して。"}]},
    config=config,
)
print(result["messages"][-1].content)

default_active_agentはユーザーの最初の入力を受け取るエージェントを指定する必須引数です(Swarm公式APIリファレンス)。create_handoff_tool()nameを省略した場合はツール名がtransfer_to_に、descriptionを省略した場合は既定の文言になります。

参考として、create_handoff_tool()が内部で生成しているのは次のようにCommandオブジェクトを返すだけのツールです(以下は仕組み解説のための参考実装で、上の例で直接書く必要はありません)。


from langgraph.types import Command
from langchain_core.tools import tool

@tool
def transfer_to_bob_inner(reason: str) -> Command:
    """掛け算が必要なときに bob へハンドオフする(内部実装イメージ)。"""
    return Command(goto="bob", graph=Command.PARENT)

外部ツールを増やす際はMCPサーバーで外部ツールをLangGraphエージェントに接続する方法を介して集約しておくと、エージェント間のツール共有が綺麗に保てます。

Supervisor vs Swarm の使い分け早見表

中心から5方向に伸びる軸の上に色付きの目盛りドットが等間隔に並ぶ五角形レーダーホイールで、評価軸ごとの比較を抽象化した構図
5つの評価軸で2系統を一望する見取り図

どちらを採用すべきかは下記5軸で判断しやすくなります。数値はLangChain公式ブログのベンチマークFocused Labの実測レポートが出典です。

評価軸 Supervisor Swarm
制御性(ルーティング精度) 約94%(専用ルーター) 約91%
拡張性 高(中央に追加するだけ) 中(他者の把握が必要)
デバッグ性 高(中央ログで意思決定追跡可) 中(分散ログ横断)
コスト(LLM呼び出し回数) 1ドメイン2回 1ドメイン1回
推奨ユースケース 第三者混在・高精度要件 低レイテンシ・対話跨ぎ

レイテンシは Focused Lab の実測で、single-domain は Supervisor 約4.2秒 / Swarm 約2.8秒、multi-domain は Supervisor 約9.1秒 / Swarm 約5.4秒という差が報告されています。コストとレイテンシ優先ならSwarm、汎用性とトレース容易性優先ならSupervisorが初手の安全な選択になりやすい傾向です。

本番運用で押さえる4ポイント

横長の安定した基盤の上に高さの揃った4本の太い円柱が等間隔で並び立ち、上部で薄いアーチを支えている運用基盤を象徴する構図
状態管理・メモリ・例外・観測を支える4本柱

本番運用で重要なのは状態管理・メモリ・エラー処理・モニタリングの4点です。

第1に状態管理(Checkpointer)。LangGraph公式PersistenceドキュメントのとおりCheckpointerはスーパーステップごとにスナップショットを取り、thread_idをキーに保存します。公式実装はInMemorySaver(開発)・SqliteSaver(ローカル)・PostgresSaver(本番)の3種類です。

第2にメモリ。スレッドを跨いで情報を保持するならStoreインターフェイス(InMemoryStore / PostgresStore)で名前空間付きタプルに格納します。本番では下記のようにPostgresSaverを使います。


from langgraph.checkpoint.postgres import PostgresSaver
from langgraph_supervisor import create_supervisor

DB_URI = "postgresql://user:pass@localhost:5432/langgraph?sslmode=disable"

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # 初回のみマイグレーション
    workflow = create_supervisor(
        agents=[research_agent, math_agent],
        model=model,
    )
    app = workflow.compile(checkpointer=checkpointer)

第3にエラー処理。LLM呼び出しはタイムアウトやレート制限で失敗する場合があるため、handoff ツール内で例外を握り、最終的に起点エージェントへ戻す設計が安全です。第4にモニタリング。LangSmithに@traceableデコレータをエージェントごとに付与し、パターン種別タグでA/B比較を取る構成が推奨されています。RAGと組み合わせるならLangChainでRAGを30分で実装する手順と合わせて設計すると、データパイプラインまで一気通貫で観測できます。

ハマりどころは3点あります。第一に handoff ツールは必ずCommandを返す必要があり、文字列を返すとルーティングが効きません。第二にthread_idはユーザーIDとセッションIDを連結するなど一意性を厳格に管理しないと、別会話の状態が混入します。第三に Swarm の循環参照対策として、ハンドオフ回数を最大3ホップに制限する方針が現場では一般的です。コストを抑えたい場合はOllamaでローカルLLMを動かしてマルチエージェントのコストを下げるを併用すると、開発環境のLLM費用を実質ゼロにできます。

FAQ

Q1. LangGraph と LangChain の違いは? LangChainはLLMアプリの汎用フレームワーク、LangGraphは状態を持つ長時間実行エージェントを Pregel ベースのグラフで記述する低レベルなオーケストレーション・ランタイムです。LangChainがコンポーネントの集合体であるのに対し、LangGraphは実行モデルそのものを規定し、CheckpointerやStoreといった永続化プリミティブを公式に持ちます。

Q2. マルチエージェントは単一エージェントより本当に賢い? LangChain公式ベンチマークでは、distractor(関連しないノイズ)ドメインが2つ以上で単一エージェントの性能が急落する一方、SupervisorとSwarmはトークン使用量がフラットで安定すると報告されています。単純タスクでは単一が有利な場合もあるため、ドメイン数とツール数で判断するのが妥当です。

Q3. OpenAI 以外のモデル(Claude / Gemini)でも動く? 動きます。create_supervisor()create_swarm()LanguageModelLikeを受け取るため、langchain_anthropic.ChatAnthropiclangchain_google_genai.ChatGoogleGenerativeAIをそのまま渡せます。マルチモーダルやツール呼び出しの仕様差は、モデル側ドキュメントで個別確認してください。

Q4. 本番運用での Checkpointer は何を選べばいい? 開発時はInMemorySaver、シングルプロセスのローカル運用はSqliteSaver、本番のマルチプロセス運用はPostgresSaverが公式の推奨パスです。詳細はLangGraph公式Persistenceドキュメントを確認してください。

まとめ

2026年5月時点で LangGraph 1.2.2 / supervisor 0.0.31 / swarm 0.1.0 が揃い、マルチエージェントは「30分でコピペ実装」できる段階に到達しました。Supervisorは中央制御で汎用性とデバッグ性に強く、Swarmは分散ハンドオフで低レイテンシに強い、というのが本稿の結論です。

次のアクションは2つあります。第1に本稿の両サンプルを手元で動かしてレイテンシ差を体感すること、第2に本番投入前にPostgresSaverとLangSmithを組み込み、thread_id設計とハンドオフ上限を運用ルール化することです。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次