マルチエージェントの6つの型

先に結論を書きます。マルチエージェントの型は、名前ではなく「段取りを決めるのは誰か（コードか、AI か）」と「仕事をどう渡すか」で見分けると、各社の呼び名の違いに迷わなくなります。 そして、どの会社の資料も、型を選ぶ前に「本当に複数の AI が要るか」を確かめるよう勧めています。実際に、担当が最初から分かる問い合わせで引き継ぎ型を動かすと、決まった振り分けより崩れました。

型の整理は、公式の資料を読んでまとめたものです。 資料はすべて2026年10月17日に読みました。名前や型の数は、資料の更新で変わることがあります。自分で動かして測ったのは、後半の「測ってみた」の節だけです。

見分ける軸は2つ

1. 段取りを決めるのは誰か。 人が前もってコードで決めるか、AI がその場で決めるか。OpenAI の Agents SDK の資料は、これを「コードで指揮する」と「AI で指揮する」と呼び分け、コードで指揮するほうが「速さ・費用・出来が予測しやすい」と書いています（Orchestrating multiple agents）
2. 仕事をどう渡すか。 順に渡す、最初に振り分ける、引き継いで戻らない、呼び出して戻る、同時にやる、往復する

この2つの軸で、各社の型は6つにまとまります。

6つの型と、各社の呼び名

型の名前は、この記事で付けた日本語です。

• ① 直列：決まった順に、前の結果を次へ渡す
• ② 振り分け：最初に1回分類して、決まった担当へ送る
• ③ 引き継ぎ：担当している AI が、その場で別の AI に渡す。制御は戻らない
• ④ 並列：同じ入力を複数の AI が同時に処理し、まとめる
• ⑤ 管理役：管理役の AI が仕事を分けて担当を呼び、結果は管理役に戻る
• ⑥ 作る役と確かめる役：作る AI と確かめる AI が、合格するまで往復する

各社の呼び名は、次のとおりです（— は、その資料に当たる型が無いもの）。

型	Microsoft	Anthropic	OpenAI	LangChain	Google ADK
① 直列	Sequential	Prompt chaining	（コードで指揮）	Custom workflow	Sequential pipeline
② 振り分け	（deterministic routing を勧める）	Routing	—	Router	Coordinator / Dispatcher
③ 引き継ぎ	Handoff	—	Handoffs	Handoffs	（Coordinator が近い）
④ 並列	Concurrent	Parallelization	—	Router（複数に送る場合）	Parallel fan-out / gather
⑤ 管理役	Magentic	Orchestrator-workers	Agents as tools	Subagents	Hierarchical decomposition
⑥ 作る役と確かめる役	Group chat（maker-checker）	Evaluator-optimizer	—	—	Generator and critic、Iterative refinement

出典：Microsoft は AI Agent Orchestration Patterns と Agent Framework の orchestrations、Anthropic は Building effective agents（2024年12月19日）、OpenAI は Orchestrating multiple agents、LangChain は Multi-agent、Google は Developer’s guide to multi-agent patterns in ADK（2025年12月16日）。

6つに入れなかったもの

• 道具を持った AI 1つ（単独のエージェント）。 Anthropic の Agents、Microsoft の Single agent with tools、LangChain の Skills。マルチエージェントの一つ手前の段階です
• 人の承認。 Google は Human-in-the-loop を型の1つにしていますが、Microsoft は、どの型にも付けられる機能として書いています。型というより、どの型にも足せるものです
• Microsoft の Group chat のうち、複数の AI が話し合う使い方。 表では、往復して確かめる使い方（maker-checker）だけを⑥に入れました

取り違えやすい3つの点

どの段階から始めるか

Microsoft の資料は、型を選ぶ前に、こう勧めています。「要件を確実に満たす中で、いちばん単純な段階を使う」（AI Agent Orchestration Patterns）。

段階	中身	資料に書かれていること
AI を1回呼ぶだけ	分類、要約、翻訳などを1回で	プロンプトで解けるなら、エージェントは要らない
道具を持った AI 1つ	AI が道具を選びながら繰り返す	企業の用途では、多くの場合これが最初の選択。繰り返しの上限を決める
複数の AI	担当の違う AI が協力する	調整の手間、遅れ、失敗の種類が増える。1つの AI では確実にこなせない理由があるときに使う

さらに、Handoff（③）を避けるべき場面として、**「どの担当に渡すかが、最初の入力から分かるとき」**を挙げ、そのときは決まった振り分け（②）を使うよう書いています。

このサイトでは、2つ目の段階（道具を持った AI 1つ）までは測っています。お客様の問い合わせメール7通で、手順を組んだ版と比べると、AI Agent の版は費用が約3倍で、空き枠があるお客様を4回中3回断りました（AI Agent に任せるか、手順を組むか）。1つ目の段階で足りる仕事を2つ目でやると、悪くなったという結果で、Microsoft の勧めと同じ向きです。

測ってみた：振り分けと引き継ぎを、同じメール7通で比べた

ここからは、自分で動かして測った内容です（2026年10月18日、n8n 2.36.8、Claude Haiku 4.5）。

家具店への問い合わせメール7通に、返信の文を作る仕事で、3つの作り方を比べました。7通、在庫と来店枠のデータ、返信のルール、モデルは、3つとも同じです。「今日」の日付は、2026年10月2日（金）に固定しました。

作り方	型	中身
A	② 振り分け	AI が用件を1回分類し、決まった手順で在庫や来店枠を調べ、返信を書く
B	道具を持った AI 1つ	在庫と来店枠を調べる道具を、AI Agent が自分で選んで使う
C	③ 引き継ぎ	受付の AI が、在庫係の AI か来店係の AI に引き継ぐ。係の AI は自分の道具で調べ、用件が残っていれば、もう一方の係に引き継ぐ（2回まで）。最後の係が返信を書く

7通は、在庫の質問が3通、来店の相談が2通、不具合の相談が1通、「3人掛けのソファを見たいので、今度の日曜日に行きたい」という用件が2つのものが1通です。各版を4回ずつ流しました（28通ずつ）。

7通あたり（4回の幅）	A 振り分け	B AI Agent 1つ	C 引き継ぎ
費用	$0.019〜0.020（1通 約0.4円）	$0.028〜0.040（1通 約0.6〜0.9円）	$0.029〜0.034（1通 約0.6〜0.7円）
AI の呼び出し	19回	12〜18回	19〜20回
かかった時間	25〜28秒	24〜31秒	31〜38秒
お客様に送れない文	0 / 28	0 / 28	5 / 28
空きの有無を、間違えて案内した	0 / 28	1 / 28	1 / 28

費用は、Claude Haiku 4.5 の料金（入力100万トークンあたり1ドル、出力5ドル、1ドル150円）で計算しました。

要る場面では、引き継ぎませんでした。 用件が2つある「3人掛けのソファを見たい＋日曜に行きたい」では、受付が4回とも来店係に渡しました。来店係は3回「その日は満席」と答えて完了にし、1回は日付を確かめたいという内部向けの文を返しました。在庫係への引き継ぎは一度も起きず、ソファの在庫には4回とも触れていません（A と B も、ソファの在庫には触れていません）。

引き継いだあとに、日付を取り違えた回もありました。 「今週の土曜日の午後」の問い合わせで、来店係が1回、10月4日を土曜日として調べ、空きがある（10月3日の16時）お客様に「満席です」と答えました。

B（AI Agent 1つ）の誤りは1回で、来店枠が1件も無い10月7日に「11時のご来店をお受けすることができます」と書きました。ベッドの問い合わせは、B は4回とも答えずに人に回しました。A は4回とも「取り扱いがない」と答えています。

空きの有無以外の誤りもありました。A は1回、在庫切れのソファを「お取り扱いが終了」と書きました（在庫切れと11月中旬の入荷予定は正しく書いています）。C は1回、引き継ぎのあとで在庫の情報が抜け、「在庫状況は担当者から改めてご連絡いたします」とだけ書きました。

このサイトの実例に当てはめると

このサイトの自動化の実例は、どれも「AI は1つ、ほかはコードか人」です。それでも、型の形はいくつも出てきます。

型	実例	型との違い
① 直列	法令の改正ウォッチ（コードが差分を出す → AI が説明する → コードが照合する）	前後の担当は、AI ではなくコード
② 振り分け	在庫・来店メールの返信下書き（AI が仕分けて、決まった手順へ）	送り先は、AI ではなく決まった手順
③ 引き継ぎ	LINE×Slack 問い合わせ対応（AI から人の担当者へ渡す）	受け手は、AI ではなく人
④ 並列	なし	—
⑤ 管理役	n8n AI Agent ノード（道具を呼んで、結果が戻る）	呼ぶ相手は、AI ではなく道具
⑥ 作る役と確かめる役	領収書の突合、議事録、翻訳（コードが確かめる）	確かめる役は、AI ではなくコード。往復せず、合わなければ止めるだけ

担当を AI にすると、それがマルチエージェントになります。逆に言えば、担当をコードや人にできるところは、AI を増やさずに同じ形を作れます。 確かめる役をコードにした理由は、AI に「送る」を任せない設計に書きました。

確認していないこと

• ②と③以外の型。 測ったのは、振り分け（②）と引き継ぎ（③）、それに道具を持った AI 1つだけです。直列、並列、管理役、作る役と確かめる役は、資料を読んだだけです
• 引き継ぎ型に向く仕事。 担当が途中で分かる仕事や、別のモデル、別のプロンプトでは試していません。4回ずつの試験なので、割合は目安です
• 資料の新しさ。 各社の SDK は更新が速く、型の名前や数は変わることがあります。どれも2026年10月17日に読んだ内容です
• OpenAI の Handoffs の細部。 「渡した先の AI が、その回の残りを引き受ける」までは資料にありますが、そのあと最初の AI に戻せるかは、資料からは読み取れませんでした

次に読む

• 道具を持った AI 1つと、手順を組んだ版の比較は AI Agent に任せるか、手順を組むか
• AI の周りの仕組み（ハーネス）の違いは エージェントハーネスとは
• AI に任せる範囲の決め方は AI 導入は、手作業から始める