目次

前回のマルチエージェントとは？で「複数AIの協調」の概念を押さえたら、次は実際にどう作るかだ。本記事は、2026年の事実上の標準であるスーパーバイザー型（司令塔型）を題材に、5ステップの実践手順を初心者向けに解説する。

難しいフレームワークの話に入る前に、最重要の原則を先に言う——「まず単一エージェントで作り、限界にぶつかってから最小構成で増やす」。最初から多人数で組むのは、たいてい過剰設計だ。コードは特定フレームワークに依存しない擬似コードで示すので、MCPや各種SDKのどれを使う場合にも応用できる。

マルチエージェントの作り方 · 5ステップ

小さく作って、測ってから増やす

— スーパーバイザー型を最小構成から

1課題を分解する
2ワーカーを定義する（3〜5体まで）
3スーパーバイザーを設計する
4ハンドオフと文脈共有を決める
5計測し、上限を設けて運用する

※本記事の手順・数値は各種公表資料・実務ガイド・研究報告の引用（2026年6月時点）。コードは概念を示す擬似コードで、実際のAPIは各フレームワークの公式ドキュメントを確認のこと。

1. 作る前に：本当にマルチが必要か

最初の関門は技術ではなく判断だ。マルチエージェントは強力だが、約8割の用途は単一エージェントで足りる。次のいずれにも当てはまらないなら、まずは単一エージェントで作るのが正解だ。

マルチにすべき3つのサイン

  • 専門性の分離：1つのプロンプトに知識を詰め込みきれない（調査・法務・コードなど領域がまたがる）
  • 並列性：複数の作業を同時に進めれば明らかに速くなる
  • 判断の分離：「実行役」と「検証役」を分けたほうが品質が上がる

逆に、一本道の単純な処理にマルチを使うと、前回触れたとおりコストが3〜10倍に膨らみ、逐次タスクではむしろ精度が落ちる（Google研究で単一比 −39〜70%の報告）。「複数にすれば賢くなる」わけではない、を出発点に置こう。

2. 基本形＝スーパーバイザー型（2026の標準）

どのパターンで作るか迷ったら、スーパーバイザー型（司令塔型）一択でよい。Claude Codeのサブエージェント、LangGraphのSupervisor、OpenAI Agents SDKのハンドオフ——主要な実装が軒並みこの形に収束している。理由は明快だ。

対応FWが最も広い

主要フレームワークがネイティブ対応。参考実装が豊富。

失敗モードが既知

主な失敗は「過剰委任」。反復回数の上限で抑えられる。

監査しやすい

「誰が何をしたか」が明確で、デバッグが容易。

仕組みはシンプルだ。スーパーバイザー（司令塔）が全体タスクを受け取り、サブタスクに分解し、専門ワーカーに委任し、結果を統合する。司令塔はワーカーの中身を知る必要はなく、「どのワーカーを・どんな出力フォーマットで呼ぶか」だけを判断する。専門知識はワーカー側が持つ。

3. 5ステップで作る

最小構成のスーパーバイザー型を、5つのステップで組み立てる。最初はワーカー2〜3体から始め、計測しながら必要に応じて増やすのが鉄則だ。

STEP 1. 課題を分解する

「最終ゴール」と「必要な専門役」を紙に書き出す。例：市場調査レポート作成なら「①情報収集→②分析→③執筆→④ファクトチェック」。分解は前もって明確に——ここが曖昧だと全体が崩れる。

STEP 2. ワーカーを定義する（3〜5体まで）

各ワーカーに1つの役割・必要なツール・出力フォーマットを与える。最初は欲張らず最大3〜5体。各ワーカーは独立し、自分のツール（検索・コード実行など）だけを持つ。

STEP 3. スーパーバイザーを設計する

司令塔のプロンプトに「呼び出してよいワーカー名」を明示的に列挙（ハードキャップ）。個々のワーカーより司令塔の設計に最も時間をかけるのがコツ。ここが全体の質を決める。

STEP 4. ハンドオフと文脈共有を決める

ワーカー間で何を・どの形式で受け渡すかを定義。全文脈を全員に渡すとトークンが膨張するので、必要な情報だけを選んで渡す。エージェント間連携の標準規約がA2Aだ。

STEP 5. 計測し、上限を設けて運用する

エージェントを増やす前に、すべてのハンドオフを計測する（可観測性は必須）。反復回数・トークン・コストに上限を設定。評価（Evals）とガードレールも同時に整える。

4. 最小コード例（擬似コード）

スーパーバイザー型の本質は驚くほど短い。フレームワーク非依存の擬似コードで、司令塔がワーカーを選んで回すループを示す（実際のAPIは各SDKの公式ドキュメントを参照）。

# ワーカー（専門役）を定義：1役割＋専用ツール
workers = {
  "researcher": Agent(tools=[web_search]),
  "writer":     Agent(tools=[]),
  "factcheck":  Agent(tools=[web_search]),
}

# スーパーバイザー（司令塔）：呼べるワーカー名をハードキャップ
supervisor = Agent(
  instructions="ゴールを分解し、次に呼ぶワーカーを1つ選ぶ。"
               "完了したら 'DONE' を返す。",
  allowed_workers=["researcher", "writer", "factcheck"],
)

# 実行ループ（反復上限でover-delegationを防ぐ）
state = {"goal": "AI市場レポートを作成", "history": []}
for step in range(MAX_STEPS):          # ← 上限は必須
  next_worker = supervisor.decide(state)
  if next_worker == "DONE":
    break
  result = workers[next_worker].run(state)
  state["history"].append({next_worker: result})   # 必要な文脈だけ共有
  log_handoff(next_worker, result)     # ← 全ハンドオフを計測

ポイントは3つ。①ワーカーは1役割＋専用ツール ②司令塔は呼べる相手を限定 ③ループには必ず反復上限を置く。この骨格に、計測・ガードレール・評価を足していけば本番品質に近づく。Claude Agent SDKやClaude Codeのサブエージェントも、考え方は同じだ。

5. よくある落とし穴と対策

マルチエージェント開発でつまずきやすいポイントは、ほぼ決まっている。先回りして対策しておこう。

落とし穴 対策
過剰委任（司令塔が延々と回す） 反復回数の上限＋呼べるワーカーの限定
トークン肥大（コスト3〜10倍） 全文脈共有をやめ、必要分だけ渡す＋キャッシュ
不安定・非決定的な挙動 ワーカー数を絞る（3〜5体）＋出力フォーマット固定
逐次タスクで精度低下（−39〜70%） 一本道なら単一エージェントに戻す
どこで失敗したか分からない 増やす前に全ハンドオフを計測（可観測性）

共通する教訓は「フレームワークより、プロンプト・ツール設計・評価ハーネスが成否を決める」。派手な構成より、小さく作って計測し、割に合うときだけ増やす規律が、結局いちばん速い。

まとめ

マルチエージェントの構築は、スーパーバイザー型を最小構成から始めれば怖くない。要点を振り返ろう。

この記事の要点

  • 🚦 まず単一で。 専門分離・並列・判断分離のサインが出てから増やす。
  • 🧠 基本形はスーパーバイザー型（2026の標準）。司令塔の設計に最も時間をかける。
  • 🔢 5ステップ：分解→ワーカー定義(3〜5体)→司令塔設計→ハンドオフ→計測。
  • ⚠️ 落とし穴：過剰委任・トークン肥大・不安定さ。上限・必要分共有・計測で対策。
  • 📏 規律：フレームワークより、プロンプト・ツール・評価が成否を決める。

「小さく作って、測ってから増やす」。この規律さえ守れば、マルチエージェントは複雑な仕事を任せられる強力な相棒になる。概念の整理はマルチエージェントとは？、単体の作り方はAIエージェントの作り方へ。

FAQ

Q. どのパターンから作ればいい？

A. スーパーバイザー型（司令塔型）一択で問題ありません。主要フレームワークが対応し、失敗モードも既知で、参考実装が最も豊富です。慣れてから他パターンを検討しましょう。

Q. ワーカーは何体くらいから始める？

A. 最初は2〜3体、多くても3〜5体までに抑えましょう。数が増えるほど不安定になり、トークンも膨らみます。計測しながら、必要が証明できたときだけ増やすのが定石です。

Q. フレームワークは必須ですか？

A. 必須ではありません。本記事の擬似コードのように、ループとプロンプトだけでも最小構成は作れます。ただし状態保存・可観測性・復旧を本番で求めるなら、対応フレームワークを使うと近道です。

Q. コスト爆発を防ぐには？

A. ①反復回数に上限を置く ②全文脈を渡さず必要分だけ共有する ③プロンプトキャッシュを使う、の3点が効きます。マルチ化でコストは単一の3〜10倍になりうるため、上限設定は最初から必須です。