マルチエージェント構成の初歩 — HandoffとSupervisorを初心者向けに整理する

Posted at 2026-09-05

2026年9月6日時点の公開ドキュメントを根拠に、マルチエージェント構成の初歩を整理します。前日までの「ツール呼び出し」「Plan-and-Execute」「Human-in-the-Loop」の続きとして、1体のエージェントをいつ分割し、どうつなぐかを押さえます。

この記事のゴールは、「エージェントを増やす＝賢くなる」ではなく、**所有権（誰が最終回答を持つか）と呼び出し関係（誰が誰を呼ぶか）**で構成を選べる状態になることです。

結論：まず決めるのは「人数」ではなく「所有権」

パターン	一言で	最終回答の持ち主	向く場面
単一エージェント	分割しない	その1体	ツールが少なく、方針も1つで足りるとき
Agents as tools / Subagents（Supervisor）	管理役が専門家をツールとして呼ぶ	管理役	専門処理は委譲したいが、ユーザーへの返答は一本化したいとき
Handoffs	会話の主導権を専門エージェントへ渡す	受け取った側	分岐ごとに方針・ツール・ポリシーが違うとき
階層（Hierarchical）	管理役の上にさらに管理役	上位の設計次第	ドメインが多く、1段のSupervisorでは足りないとき

迷ったら次の一文で十分です。

まずは1体。専門性が「指示・ツール・ポリシー」のどれかを分ける必要があるときだけ増やす。増やすなら「管理役が呼ぶ（tools）」か「会話を渡す（handoffs）」かを先に決める。

なぜマルチエージェントが必要になるか

確認できる事実

OpenAIの Agents ガイド Orchestration and handoffs は、マルチエージェントを「専門家が仕事の別部分を担う」ための手段と位置づけ、最初の設計判断を 各分岐で誰がユーザー向け最終回答を持つか だと述べています。
同ガイドは、専門エージェントを足す条件を「能力の分離・ポリシーの分離・プロンプトの明確化・トレースの読みやすさ」に実質的な改善がある場合に限る、と書いています。早すぎる分割は、プロンプト・トレース・承認面が増えるだけになり得ます。
LangChainの Subagents ドキュメントは、中央の main agent（supervisor）がサブエージェントをツールとして呼び出し、結果を合成する構成を説明しています。

原文: "The first design choice is deciding who owns the final user-facing answer at each branch of the workflow."
日本語訳: 「最初の設計判断は、ワークフローの各分岐で誰がユーザー向け最終回答を持つかを決めることだ」（出典: OpenAI — Orchestration and handoffs）

原文: "Start with one agent whenever you can. Add specialists only when they materially improve capability isolation, policy isolation, prompt clarity, or trace legibility."
日本語訳: 「できる限り1つのエージェントから始めよ。専門家を足すのは、能力分離・ポリシー分離・プロンプトの明確さ・トレースの読みやすさを実質的に改善するときだけだ」（出典: 同上）

実務解釈：分割のトリガーは4つ

トリガー	例	分割しないと起きやすいこと
能力の分離	検索役と要約役で使うツールが違う	1プロンプトに全部押し込み、誤ツール呼び出しが増える
ポリシーの分離	読み取り専用と書き込み可能を分ける	危険ツールが常時見える
プロンプトの明確化	請求と技術サポートで口調・手順が違う	長いシステムプロンプトが互いに打ち消し合う
トレース可読性	誰が何をしたかをログで追いたい	1本の長い実行ログで原因特定が遅れる

逆に、ツールが数個で方針も1つなら、マルチ化はコストだけ増えます。

2大パターン：呼ぶか、渡すか

OpenAI公式ガイドは、オーケストレーションを大きく次の2つに分けています。

パターン	何が起きるか	使うとき
Agents as tools	管理役が専門家を能力として呼び、返答の所有権は管理役のまま	要約・分類など境界がはっきりした補助処理
Handoffs	専門家が会話の次の主導権を受け取る	その分岐では専門エージェントがユーザーに直接返す方が自然なとき

LangChain側でも対応する用語があります。

LangChain / LangGraph 側の呼び方	近い考え方
Subagents（supervisor が subagent を tool 呼び出し）	Agents as tools
Handoffs（状態や `Command` で次エージェントへ遷移）	Handoffs

Agents as tools / Subagents

確認できる事実

LangChain Subagents は、main agent がどのサブエージェントを呼ぶか・何を渡すか・結果をどう合成するかを決め、サブエージェントは原則ステートレスで、会話記憶は main agent が持つ、と説明しています。
特徴として、(1) ルーティングは中央通過、(2) サブはユーザーと直接会話しない（interrupt で例外可）、(3) ツール経由で呼ぶ、(4) 1ターンで複数並列呼び出しが可能、が挙げられています。
OpenAI Agents SDK では、Agent.as_tool(...) / asTool() で専門家をツール化し、外側のエージェントが最終回答の責任を持ち続けます。

原文: "In the subagents architecture, a central main agent (often referred to as a supervisor) coordinates subagents by calling them as tools."
日本語訳: 「サブエージェント構成では、中央のメインエージェント（しばしばsupervisorと呼ばれる）が、サブエージェントをツールとして呼び出して調整する」（出典: LangChain — Subagents）

最小イメージ（公開ドキュメントの骨格）:

from agents import Agent

summarizer = Agent(
    name="Summarizer",
    instructions="Generate a concise summary of the supplied text.",
)

main_agent = Agent(
    name="Research assistant",
    tools=[
        summarizer.as_tool(
            tool_name="summarize_text",
            tool_description="Generate a concise summary of the supplied text.",
        )
    ],
)

実務解釈

ユーザーへの返答は1本にしたい業務フロー向き。
サブ側の途中思考を全部メイン履歴に載せない（要約だけ返す）と、コンテキスト肥大を抑えやすい。
「Router（1回だけ振り分け）」と違い、Supervisor は複数ターンにわたり動的に呼び分けを続ける、というのが LangChain ドキュメント上の区別です。

Handoffs

確認できる事実

OpenAI Agents SDK Handoffs は、エージェントが別エージェントへタスクを委譲する仕組みで、LLMからはツールとして見える、と説明しています。例: Refund Agent への handoff はツール名 transfer_to_refund_agent になる。
受け側は既定では会話履歴を引き継ぎます。履歴を変えたい場合は input_filter 等で制御します。
LangChain Handoffs は、ツールが current_step / active_agent などの状態を更新し、それに応じて振る舞い（プロンプト・ツール・ルーティング）を変える、と説明しています。用語 handoffs 自体は OpenAI がツール呼び出しで制御を移す用法として広めた、とも明記されています。

原文: "Handoffs allow an agent to delegate tasks to another agent."
日本語訳: 「Handoffは、エージェントが別のエージェントへタスクを委譲できるようにする」（出典: OpenAI Agents SDK — Handoffs）

原文: "Handoffs are represented as tools to the LLM."
日本語訳: 「HandoffはLLMからはツールとして表現される」（出典: 同上）

最小イメージ（公開ドキュメントの骨格）:

from agents import Agent, handoff

billing_agent = Agent(name="Billing agent")
refund_agent = Agent(name="Refund agent")

triage_agent = Agent(
    name="Triage agent",
    handoffs=[billing_agent, handoff(refund_agent)],
)

実務解釈

その分岐の会話オーナーを専門側に移すときに使う。請求・返金・FAQのように窓口が分かれるサポート系が典型です。
履歴を全部渡すとトークンと混乱が増えるので、「handoff の AIMessage + ToolMessage のペア」「要約だけ」など、渡す量を設計する。
LangChainドキュメントは、多くの handoff 用途では「複数エージェントをノードにする前に、単一エージェント＋middleware で状態駆動にする方が単純」とも述べています。いきなりグラフ分割しないのが初心者向けの安全策です。

選び方の早見表

問い	Yes なら寄りやすい構成
最終回答は常に同じ窓口で返したいか	Agents as tools / Subagents
分岐ごとにユーザーへ直接返す役が変わるか	Handoffs
サブ処理はステートレスでよい（都度完結）か	Subagents
会話の段階が進むにつれ使えるツールを変えたいか	Handoffs（状態駆動）
そもそも分割が必要かまだ怪しいか	単一エージェントのまま

ユーザー要求
  ├─ 分割不要 → 単一エージェント
  └─ 分割必要
        ├─ 管理役が合成して返す → Agents as tools / Subagents
        └─ 専門役が会話を引き継ぐ → Handoffs

実装チェックリスト

設計

「今は単一で足りるか」を先に書く（分割理由が能力／ポリシー／プロンプト／トレースのどれか）
最終回答の所有権を分岐ごとに1行で決める
候補パターンを Agents as tools か Handoffs かに寄せる（両方混ぜるなら境界を明示）
各専門エージェントの担当・使ってよいツール・使ってはいけないツールを表にする

実装

handoff / サブ呼び出しの名前と説明を短く具体にする（曖昧な help 系を避ける）
受け渡すコンテキスト（全文／要約／handoffペアのみ）を決める
ルーティング失敗時（該当なし・複数候補）のフォールバックを1つ決める
トレース上で「どのエージェントが動いたか」が見えるように名前を付ける

運用

エージェント数を増やしすぎない（まずは2〜3体）
コストとレイテンシが単一構成より悪化していないか比較する
前日記事のHITLと組み合わせるなら、副作用ゲートはどのエージェント側に置くかを決める

失敗パターン

パターン1：最初から5体以上に分割する → 対策: 単一から始め、契約（指示・ツール・ポリシー）が分かれたときだけ1体足す。

パターン2：Handoffと「ツールとしての呼び出し」を混同する → 対策: 「会話オーナーが移るか／管理役が持ち続けるか」で区別する。

パターン3：専門エージェントに全履歴を無制限に渡す → 対策: 要約・必要ターンのみ・handoffメッセージペアに絞る。

パターン4：専門の説明が曖昧で、常に同じエージェントに振られる → 対策: handoffDescription / ツール説明を「いつ選ぶか」が分かる文言にする。

パターン5：Router（1回振り分け）だけで、失敗時の再ルーティングがない → 対策: Supervisor（複数ターンで呼び直し可）が必要かを確認する。

パターン6：マルチ化したのに監査ログが1本のまま → 対策: エージェント名付きで実行トレースを残す。

パターン7：書き込み可能なツールを全エージェントに渡す → 対策: ポリシー分離を分割理由にするなら、ツール権限も分ける。

参考リンク

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up