LangGraph マルチエージェント協調実践：Supervisor パターンとタスク分散

先月、チームの Agent システムをリファクタリングする機会がありました。元々 1 つの Agent に 12 個ものツールが紐付いていました：検索、コード実行、ドキュメント生成、メール送信……結果はどうだったかというと、LLM がツール選びで頻繁に迷子になり、検索すべき場面でコード実行ツールを使ってしまう事態が多発しました。デバッグ時のログを見ても、どのツール呼び出しが問題なのかさっぱり分からない——システム全体がブラックボックスになっていたのです。

その後、アーキテクチャを Supervisor + Workers モードに分割しました。統括する Agent がルーティングを担当し、3 つの専門 Agent がそれぞれの役割を果たす形です。ツール選択エラーは元の 3 分の 1 まで減少し、デバッグも各レイヤーを順にトレースできるようになり、かなり明確になりました。

要するに、Agent が 10 個以上のツールを持つようになると、単一 Agent アーキテクチャには問題が生じます。本記事では、Supervisor パターンのアーキテクチャ原理から、create_supervisor API の完全な使い方、さらに Research + Writing チームの実践例まで詳しく解説します。コードはそのまま実行可能で、GitHub リポジトリへのリンクも後ほど紹介します。

一、なぜマルチエージェントシステムが必要なのか？

単一 Agent の3つの問題点

私が経験した落とし穴は、皆さんも直面しているかもしれません。単一 Agent システムは一見シンプルですが、実は3つの致命的な問題があります。

1つ目：ツールが多すぎて、選択に迷う。

これは誇張ではありません。単一 Agent が 10 個以上のツールを持つようになると、LLM のツール選択エラー率が明らかに上昇します。「モデルはどんどん賢くなっているのでは？」と思うかもしれません。確かにその通りですが、問題は——ツールの説明がプロンプトの中でごちゃ混ぜになり、モデルが 10 個以上のツールから正しいものを選ぶ必要があるという認知負荷は、決して小さくないのです。

以前私が担当していたシステムでは、検索ツールとコード実行ツールの機能説明が少し重複していました（どちらも「情報を探す」ことができる）。その結果、モデルが両者の間を行き来し、無駄に何ラウンドも対話を消費することが頻発しました。

2つ目：コンテキスト蓄積で、ウィンドウが爆発。

全てのサブタスクの対話履歴が 1 つのコンテキストウィンドウに詰め込まれます。数ラウンド実行すると、ウィンドウが過去のツール呼び出しで埋まり、核心的な指示がどんどん薄まります。モデルが「忘れる」ようになり、ユーザーの最初のリクエストさえ見失うこともあります。

これには身に覚えがあります。ある時、20 ラウンド実行した Agent をデバッグしたのですが、コンテキストには関数呼び出しの記録がびっしりと並び、最終的にモデルが出力した内容はユーザーの当初のニーズとほとんど関係がなくなっていました。

3つ目：デバッグできず、問題追跡が困難。

問題が起きても、どのツール呼び出しが原因なのか分かりません。単一 Agent はブラックボックスであり、ログにはツール呼び出しの羅列が延々と続くだけ。問題を特定しようと思ったら、1行ずつ見ていくしかありません。

Supervisor パターンはこれらの問題を解決できます。「統括 Agent」が複数の「専門 Agent」を調整し、役割を分離して各々が職責を果たす形です。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

Supervisor パターンの核心概念

シンプルに言えば——分業です。

1 つのチームを想像してください。プロジェクトマネージャーが全体を統括・調整し、その下にリサーチャーが調査に専念し、エンジニアが実装に専念し、ドキュメント専門家がレポート作成に専念しています。それぞれに得意分野があり、プロジェクトマネージャーは何でも知っている必要はなく、「このタスクを誰に振るべきか」だけ分かっていればいいのです。

Supervisor パターンはまさにこの考え方です：

• Supervisor（統括 Agent）：具体的な作業はせず、ルーティング、調整、結果の統合のみを行う
• Worker Agents（専門 Agent）：各々が特定分野に専念し、ツールセットは最小限、役割は明確

これの何が良いのでしょうか？

ツール数が各 Worker に分散されるため、各 Agent は自分のツールセットの中だけで選択すればよくなります。コンテキストも分散され、各 Agent は自分の対話履歴だけを管理します。デバッグ時はレイヤーごとにトレースでき、Supervisor がどの Worker にタスクを割り当てたか、Worker が何を実行したかが一目瞭然です。

二、Supervisor パターンのアーキテクチャ原理

まずはアーキテクチャ図を見てみましょう。

                    ┌─────────────────┐
                    │   ユーザーリクエスト  │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │   Supervisor    │
                    │   (統括 Agent)   │
                    │                 │
                    │  ルーティング    │
                    │  + 調整        │
                    │  + 結果統合    │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
       ┌──────────┐   ┌──────────┐   ┌──────────┐
       │ Research │   │   Math   │   │ Writing  │
       │  Agent   │   │  Agent   │   │  Agent   │
       │          │   │          │   │          │
       │ 検索ツール│   │ 計算ツール│   │ 生成ツール│
       └────┬─────┘   └────┬─────┘   └────┬─────┘
            │              │              │
            │   Worker     │   Worker     │   Worker
            │   実行結果   │   実行結果   │   実行結果
            │              │              │
            └──────────────┴──────────────┘
                           │
                           ▼
                    ┌─────────────────┐
                    │   Supervisor    │
                    │   結果を統合    │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │   最終回答      │
                    └─────────────────┘

コアコンポーネントの役割

Supervisor は3つのことを行います：

1. ルーティング：ユーザーリクエストを分析し、どの Worker に割り当てるべきか判断する
2. 調整：Worker 間のタスクの流れを管理する
3. 統合：各 Worker の実行結果をまとめ、最終回答を出力する

Worker Agent は各々の役割に専念：

各 Worker は自分専用のツールセットだけを持ちます。例えば Research Agent は検索ツールとウェブスクレイピングツールだけを持ち、Math Agent は四則演算の計算機だけを持ちます。ツールが減れば、選択精度も自然と上がります。

メッセージパッシングメカニズム

ここで重要なポイント：グローバルステート（Global Graph State）です。

全ての Agent が同じステートオブジェクトを共有し、Worker がタスクを完了すると、結果をステートの messages フィールドに追加（append）します。Supervisor は新しいメッセージを見て、次に誰に割り当てるかを決定します。

これは追加専用（append-only）のメカニズムです——メッセージは増えるだけで減らないため、対話履歴の完全性が保証されます。

Fan-out / Fan-in

複雑なタスクでは、複数の Worker を並列実行する必要があるかもしれません。例えばユーザーが「製品 A と B の市場データを比較して」と聞いた場合、Supervisor は 2 つの Research タスクを同時に発行できます（1 つは A を調べ、1 つは B を調べる）。これが fan-out です。

両方の Worker が結果を返したら、Supervisor がそれらを統合します。これが fan-in です。

LangGraph はこの並列モードをサポートしていますが、基礎編では詳しくは触れず、後の応用テクニックで改めて解説します。

"LangGraph はマルチエージェントシステムを構築する方法を提供し、各 Agent が独自のツールセットと役割領域を持ち、Supervisor によって調整とタスク分散が行われます。"

三、create_supervisor API 詳解

理論は終わり、コードを書いていきましょう。

インストールとインポート

pip install langgraph-supervisor langchain-openai

from langchain_openai import ChatOpenAI
from langgraph_supervisor import create_supervisor
from langgraph.prebuilt import create_react_agent

ツールの定義

まず各 Worker 用のツールを準備します。

from typing import Annotated

# 数学計算ツール
def add(
    a: Annotated[float, "最初の数字"],
    b: Annotated[float, "2番目の数字"]
) -> float:
    """Add two numbers together."""
    return a + b

def multiply(
    a: Annotated[float, "最初の数字"],
    b: Annotated[float, "2番目の数字"]
) -> float:
    """Multiply two numbers."""
    return a * b

# 検索ツール（シミュレーション）
def web_search(query: str) -> str:
    """Search the web for information."""
    # 実際のプロジェクトでは Tavily や Serper などを統合可能
    if "population" in query.lower():
        return "北京の人口は約 2189 万人（2023年データ）"
    elif "weather" in query.lower():
        return "北京は今日晴れ、気温 15-25°C"
    else:
        return f"検索結果：{query}"

ここでは Python の Annotated 型ヒントを使用し、モデルに各パラメータの意味をより明確に伝えています。ツール関数の docstring も重要です——モデルはこれを通じてツールの機能を理解します。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

Worker Agents の作成

model = ChatOpenAI(model="gpt-4o")

# 数学専門 Agent
math_agent = create_react_agent(
    model=model,
    tools=[add, multiply],
    name="math_expert",
    prompt="あなたは数学の専門家で、数値計算に特化しています。ユーザーが数学演算を必要とする場合、ツールを使ってタスクを完了させてください。"
)

# リサーチ専門 Agent
research_agent = create_react_agent(
    model=model,
    tools=[web_search],
    name="research_expert",
    prompt="あなたはシニアリサーチャーで、情報の検索と整理に長けています。ユーザーが資料を調べる必要がある場合、検索ツールを使って回答を取得してください。"
)

いくつかのポイントがあります：

1. name フィールドは重要：Supervisor は名前で Worker を識別・呼び出しする
2. prompt でロールを定義：この Agent の専門分野を伝える
3. ツールセットは最小限：各 Agent に必要なツールだけを、多くても少なくてもなく

Supervisor の作成

# Supervisor システムを作成
supervisor = create_supervisor(
    agents=[math_agent, research_agent],
    model=model,
    prompt="""あなたはチームリーダーで、各専門 Agent の調整を担当します。

ユーザーリクエストに基づいて、タスクを誰に割り当てるかを決めてください：
- 数学計算が必要 → math_expert
- 資料の検索が必要 → research_expert
- タスク完了 → ユーザーに直接回答

複数の専門家が協力する必要がある場合、合理的な順序で順番に呼び出してください。"""
)

# 実行可能なアプリケーションにコンパイル
app = supervisor.compile()

create_supervisor は3つの主要なパラメータを受け取ります：

• agents：Worker Agent のリスト
• model：Supervisor 自身が使用する大規模モデル
• prompt：Supervisor にタスク配分の方法を指示

実行例

from langchain_core.messages import HumanMessage

# 数学問題をテスト
result = app.invoke({
    "messages": [HumanMessage(content="123 に 456 を足すといくつになりますか")]
})
print(result["messages"][-1].content)
# 出力：123 に 456 を足すと 579 です

# 検索問題をテスト
result = app.invoke({
    "messages": [HumanMessage(content="北京の人口はどれくらいですか")]
})
print(result["messages"][-1].content)
# 出力：検索結果によると、北京の人口は約 2189 万人です

Supervisor はリクエストの種類を自動判断し、正しい Worker にルーティングします。ユーザーには完全に透過的で、背後で複数の Agent が動いていることを知る必要はありません。

四、実践例：Research + Writing チームの構築

上記は最も基本的な例です。ここからは、より完全なシステムを構築します：技術記事を自動的に調査し生成するチームです。

シナリオ説明

ユーザーが技術トピックを入力すると、システムが自動的に以下を実行します：

1. 関連資料を調査
2. 記事のアウトラインを生成
3. 完全なコンテンツを執筆
4. 校正とレビュー

これには3つの専門 Agent の連携が必要です。

完全なツールセットの定義

from typing import TypedDict, List
import json

# 検索ツールのシミュレーション
def tech_search(query: str) -> str:
    """技術資料やドキュメントを検索。"""
    # 実際のプロジェクトでは Tavily や Serper を統合
    database = {
        "langgraph": "LangGraph は LangChain が提供する Agent フレームワークで、ステート管理と循環グラフ構造をサポートしています。",
        "supervisor": "Supervisor パターンはマルチエージェントシステムの中核アーキテクチャで、統括 Agent が複数の専門 Agent を調整します。",
        "multi-agent": "マルチエージェントシステムはタスク分散と協調によって、単一 Agent のツール過多とコンテキスト爆発の問題を解決します。"
    }

    results = []
    for key, value in database.items():
        if key in query.lower():
            results.append(value)

    return json.dumps(results) if results else "関連資料が見つかりませんでした。検索範囲を広げることをお勧めします"

# アウトライン生成ツール
def generate_outline(topic: str) -> str:
    """トピックに基づいて記事のアウトラインを生成。"""
    return json.dumps({
        "title": f"{topic} 完全ガイド",
        "sections": [
            "1. 概要と背景",
            "2. コア概念",
            "3. 実践例",
            "4. ベストプラクティス",
            "5. まとめ"
        ]
    }, ensure_ascii=False)

# コンテンツ生成ツール
def write_section(section_title: str, context: str) -> str:
    """タイトルとコンテキストに基づいて段落を生成。"""
    # 実際のプロジェクトでは大規模モデルを呼び出し可能
    return f"## {section_title}\n\n調査資料に基づき、{section_title} の核心ポイントは以下の通りです...\n\n"

# レビューツール
def review_content(content: str) -> str:
    """コンテンツの正確性と可読性をレビュー。"""
    issues = []
    if len(content) < 100:
        issues.append("コンテンツが短すぎます。拡充を推奨")
    if "TODO" in content:
        issues.append("未完了の TODO マークが存在")

    return json.dumps({
        "passed": len(issues) == 0,
        "issues": issues,
        "suggestion": "コンテンツの品質は良好です。公開可能" if not issues else "問題点に基づいて修正後、再提出してください"
    }, ensure_ascii=False)

Worker Agents の作成

# リサーチャー Agent
researcher = create_react_agent(
    model=model,
    tools=[tech_search],
    name="researcher",
    prompt="""あなたはシニア技術リサーチャーで、新技術の迅速な調査と理解に長けています。

役割：
1. 調査トピックを受け取る
2. 検索ツールを使って関連資料を探す
3. 構造化された調査レポートにまとめる

注意：調査のみを行い、執筆はしない。調査結果を writer に渡す。"""
)

# ライター Agent
writer = create_react_agent(
    model=model,
    tools=[generate_outline, write_section],
    name="writer",
    prompt="""あなたは技術ライティングの専門家で、複雑な概念を明確で分かりやすい記事に変換することに長けています。

役割：
1. 調査レポートを受け取る
2. 記事のアウトラインを生成する
3. 各セクションのコンテンツを執筆する

注意：初稿完成後、reviewer にレビューを依頼する。"""
)

# レビュアー Agent
reviewer = create_react_agent(
    model=model,
    tools=[review_content],
    name="reviewer",
    prompt="""あなたは厳格なレビュアーで、記事の品質と正確性を確保します。

役割：
1. コンテンツの完全性と正確性をチェックする
2. 記事の可読性と論理性を評価する
3. 修正提案または公開承認を行う

注意：問題が見つかった場合、writer に差し戻して修正させる。"""
)

Supervisor ロジックの構築

# StateGraph を使ってカスタム Supervisor を構築
from langgraph.graph import StateGraph, END
from typing import Annotated, Sequence
from langchain_core.messages import BaseMessage
from langgraph.graph.message import add_messages

# ステートの定義
class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]
    next_agent: str

# Supervisor の意思決定ロジック
def supervisor_node(state: AgentState) -> dict:
    """現在の進捗に基づいて次に実行する Agent を決定。"""
    messages = state["messages"]

    # 大規模モデルを呼び出して意思決定
    decision = model.invoke([
        {"role": "system", "content": """あなたはチームリーダーです。対話履歴に基づいて次のステップを決めてください：

- まだ調査資料がない → 'researcher' を返す
- 調査資料はあるが記事がない → 'writer' を返す
- 記事はあるがまだレビューされていない → 'reviewer' を返す
- レビュー完了 → 'FINISH' を返す

Agent 名前だけを返し、他の内容は含めない。"""},
        *messages
    ])

    next_agent = decision.content.strip()

    # 正しい Agent 名前にマッピング
    agent_map = {
        "researcher": "researcher",
        "writer": "writer",
        "reviewer": "reviewer",
        "FINISH": END
    }

    return {"next_agent": agent_map.get(next_agent, "researcher")}

# グラフの構築
workflow = StateGraph(AgentState)

# ノードの追加
workflow.add_node("supervisor", supervisor_node)
workflow.add_node("researcher", researcher)
workflow.add_node("writer", writer)
workflow.add_node("reviewer", reviewer)

# 条件付きエッジの追加（Supervisor のルーティングロジック）
workflow.add_conditional_edges(
    "supervisor",
    lambda state: state["next_agent"],
    {
        "researcher": "researcher",
        "writer": "writer",
        "reviewer": "reviewer",
        END: END
    }
)

# 全ての Agent 完了後は Supervisor に戻る
for agent in ["researcher", "writer", "reviewer"]:
    workflow.add_edge(agent, "supervisor")

# エントリーポイントの設定
workflow.set_entry_point("supervisor")

# コンパイル
app = workflow.compile()

このアーキテクチャにはループメカニズムがあります：全ての Worker がタスクを完了すると Supervisor に戻り、Supervisor が次に別の Worker に割り当てるか、終了するかを決定します。

実行フロー

result = app.invoke({
    "messages": [HumanMessage(content="LangGraph Supervisor パターンに関する技術記事を書いて")]
})

# 最終結果を確認
print(result["messages"][-1].content)

# 実行トレースを確認
for i, msg in enumerate(result["messages"]):
    print(f"{i+1}. {msg.__class__.__name__}: {msg.content[:100]}...")

実行フローは概ね以下のようになります：

ユーザーリクエスト → Supervisor が分析 → Researcher に割り当て →
Researcher が調査 → Supervisor に戻る → Writer に割り当て →
Writer が執筆 → Supervisor に戻る → Reviewer に割り当て →
Reviewer がレビュー → Supervisor に戻る → 完了確認 → 結果出力

各レイヤーをトレースでき、デバッグもはるかに明確になります。

五、応用テクニック

メッセージ転送の最適化：create_forward_message_tool

すでにお気づきかもしれませんが：Worker がタスクを完了した後、返されたメッセージは Supervisor が受信し、言い換えられる可能性があります。これはトークンの無駄であり、情報が薄まる可能性もあります。

LangGraph は create_forward_message_tool を提供してこの問題を解決します：

from langgraph_supervisor.handoff import create_forward_message_tool

# 転送ツールを作成
forward_tool = create_forward_message_tool("supervisor")

# Supervisor 作成時に渡す
supervisor = create_supervisor(
    agents=[researcher, writer, reviewer],
    model=model,
    tools=[forward_tool]  # 転送ツールを追加
)

このツールを使うと、Supervisor は Worker のレスポンスを直接ユーザーに転送でき、再要約する必要がありません。トークンを節約でき、効率も向上します。

階層チームアーキテクチャ

プロジェクトがさらに複雑な場合、複数レイヤーの Supervisor を構築できます：

                    ┌──────────────┐
                    │ Top Supervisor│
                    └──────┬───────┘
                           │
           ┌───────────────┼───────────────┐
           │               │               │
           ▼               ▼               ▼
    ┌────────────┐  ┌────────────┐  ┌────────────┐
    │Research    │  │ Writing    │  │ QA         │
    │Team        │  │ Team       │  │ Team       │
    │Supervisor  │  │ Supervisor │  │ Supervisor │
    └─────┬──────┘  └─────┬──────┘  └─────┬──────┘
          │               │               │
     ┌────┼────┐    ┌────┼────┐    ┌────┼────┐
     │    │    │    │    │    │    │    │    │
   Web  Doc  API   Out  Cont Rev   Test Code Audit
 Search Scrp Parse line ent  iew

各サブチームに独自の Supervisor がおり、その上に総 Supervisor が全体を調整します。このアーキテクチャは大規模プロジェクトに適しており、役割分担がより細かくなります。

エラー処理

Worker の実行が失敗した場合はどうすればいいのでしょうか？

from langgraph.pregel import RetryPolicy

# リトライポリシーを設定
retry_policy = RetryPolicy(
    max_attempts=3,
    initial_interval=1.0,
    backoff_factor=2.0
)

app = workflow.compile(retry_policy=retry_policy)

また、Supervisor のプロンプトにエラー処理ロジックを追加することもできます：

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

ある Agent の実行が失敗した場合：
1. エラー情報を記録
2. バックアップ Agent の呼び出しを試みる
3. 複数回失敗した場合、ユーザーに問題を報告

ステートの永続化

複数ラウンドの対話ではステートを保存する必要があります。LangGraph は Checkpointer メカニズムを提供しています：

from langgraph.checkpoint.memory import MemorySaver

# メモリストレージを使用（開発環境）
memory = MemorySaver()
app = workflow.compile(checkpointer=memory)

# 実行時に thread_id を指定
config = {"configurable": {"thread_id": "user-123"}}
result = app.invoke({"messages": [HumanMessage(content="...")]}, config=config)

# 後続の対話はコンテキストを保持
result2 = app.invoke({"messages": [HumanMessage(content="前回のタスクを続けて")]}, config=config)

本番環境では Redis や PostgreSQL を Checkpointer として使用できます。

"Hierarchical Agent Teams は複数レイヤーの Supervisor アーキテクチャを構築する方法を示し、より複雑なマルチエージェント協調システムを実現します。"

六、本番デプロイの推奨事項

監視とデバッグ

LangSmith は LangChain 公式の監視プラットフォームで、各ステップの実行詳細を追跡できます：

import os

os.environ["LANGSMITH_API_KEY"] = "your-api-key"
os.environ["LANGSMITH_TRACING"] = "true"
os.environ["LANGSMITH_PROJECT"] = "multi-agent-project"

設定後、各実行は LangSmith に完全なトレースを残します：

• 各 Agent の入出力
• ツール呼び出しのパラメータと戻り値
• トークン消費統計
• 実行時間分析

デバッグ時に特に便利で、ログを1行ずつ見る必要がありません。

トークンコストの制御

Supervisor パターンは優れていますが、マルチエージェントはトークン消費を増加させます。いくつかの最適化提案：

1. Supervisor のプロンプトを簡潔に：必要なルーティングロジックだけを含める
2. forward_message_tool を使用：重複する要約を避ける
3. ツールを適切に配分：各 Worker には必要なツールだけを
4. 対話ラウンド数を制御：最大ラウンド数の制限を設定

# 最大ラウンド数を設定
app = workflow.compile(
    checkpointer=memory,
    interrupt_after=20  # 最大 20 ステップまで実行
)

AWS Bedrock との統合

プロジェクトが AWS 上にある場合、Bedrock のモデルを使用できます：

from langchain_aws import ChatBedrock

model = ChatBedrock(
    model_id="anthropic.claude-3-sonnet-20240229-v1:0",
    region_name="us-east-1"
)

# 他のコードは変更せず、model を置き換えるだけ
supervisor = create_supervisor(
    agents=[math_agent, research_agent],
    model=model
)

ベストプラクティスのまとめ

これまで述べてきたことを、実践的な経験としていくつかまとめます：

1. 小規模から始める：最初は 2-3 個の Agent から始め、徐々に増やす
2. 役割を明確に：各 Worker の領域を明確にし、重複を避ける
3. LangSmith で監視：開発段階から統合し、デバッグを容易に
4. トークンコストに注目：マルチエージェントは消費を増幅するため、最適化が必要
5. forward_message_tool を活用：多くのトークンを節約できる
6. 公式リポジトリを参照：langgraph-supervisor-py に完全な例がある

まとめ

Supervisor パターンの本質は分業協調です——大きなタスクを小さく分割し、各 Agent が自分の得意なことに専念させることです。

単一 Agent の3つの問題点（ツール選択の迷い、コンテキスト爆発、デバッグ困難）から、Supervisor パターンのエレガントな解決策まで、この記事で完全に解説しました。create_supervisor API は実際にはそれほど複雑ではありません。重要なのはその背景にあるアーキテクチャの考え方を理解することです。

小さなプロジェクトから練習することをお勧めします。まず2つの Agent のシステム（例えば検索 + 要約）を構築し、動くようになってから徐々に拡張してください。LangSmith の監視は必ず設定してください。デバッグ時にその価値を実感できるはずです。

完全なコード例は GitHub リポジトリにあります：langgraph-supervisor-py。公式チュートリアルも読む価値があります：Hierarchical Agent Teams。

質問があればコメント欄にお願いします。見つけ次第お返事します。

参考資料

• LangGraph Supervisor Reference
• Hierarchical Agent Teams Tutorial
• LangGraph Multi-Agent Workflows Blog
• GitHub - langgraph-supervisor-py
• Build Multi-Agent Systems with AWS Bedrock