AIエージェント（公式の記事では agentic systems）の型は、いちばん単純なものから選ぶ
AI エージェントの話で、「マルチエージェント」や「オーケストレーター」という言葉をよく見かけるようになりました。複数の AI に役割を分けて、まとめ役が指示を出す、という組み方です。
私は一人会社を Claude で運用していて、統括役・相談役・持ち場ごとのメイン・無人の定期タスクに役割を分けています。なので、型の名前が公式ではどう書かれているかを確かめました。2026年10月12日に、Anthropic の記事を2本開いて読んでいます。
結論は3つです。
1本目の記事は、決まった手順で流すもの（workflows）と、自分で手順を決めるもの（agents）を分けていて、両方をまとめて agentic systems と呼んでいます
オーケストレーター（公式の記事では orchestrator-workers）は、その記事では workflows の型の1つとして載っています
いちばん強く書かれているのは、型の選び方より「単純なものから始める」ことでした
公式の区別
もとになる記事は「Building effective agents」（2024年12月19日）です。
エージェントという語は人によって指すものが違う、という前置きのあとで、2つが分けられています。
workflows：LLM と道具を、あらかじめ決めたコードの経路でつなぐもの
agents：LLM が自分で手順と道具の使い方を決め、どう進めるかの主導権を持つもの
日本で「AIエージェント」と呼ばれているものは、この両方を含んでいることが多いと思います。
なお、この記事の冒頭には、道具まわりの事情は2024年12月から変わった、という注記が付いています。
よく知られた型
記事は、検索・道具・記憶を足した LLM を土台にして、単純なものから順に型を並べています。見出しに Workflow と付いているのは5つです。
プロンプトチェーン（公式の記事では prompt chaining）：仕事を決まった段に分け、前の出力を次へ渡す。途中に検査を挟める
振り分け、ルーティング（公式の記事では routing）：入力を分類して、それぞれ専用の処理へ回す
並列化（公式の記事では parallelization）：独立した小分けの仕事を同時に走らせるものと、同じ仕事を何度も走らせて票を取るものの2種類
オーケストレーター（公式の記事では orchestrator-workers）：中心の LLM が仕事を分けて担当に渡し、結果をまとめる
書き手と評価役を分ける型（公式の記事では evaluator-optimizer）：1つが書き、もう1つが評価して返す、をループで回す
その次に agents が来ます。中身は、環境から返ってくる結果を見ながら、ループで道具を使う LLM だと説明されています。
オーケストレーターは「決まった手順」の側に載っている
並列化との違いは、小分けの仕方を前もって決めていないことです。中心の LLM が入力を見てから仕事を分けます。それでも、この記事では見出しが Workflow のほうに付いています。
もう1本の「How we built our multi-agent research system」（2025年6月13日）では、同じ形が、マルチエージェントの組み方として出てきます。Claude の調査機能を、マルチエージェント（公式の記事では multi-agent system）として、orchestrator-worker pattern で組んだ話です。まとめ役のエージェントが計画を立て、調べる担当のサブエージェントを並列に走らせます。1本目では担当は LLM の呼び出し、2本目では担当それぞれが道具をループで使うエージェントです。
私の読みでは、「オーケストレーター」と「マルチエージェント」は、いつも同じものを指すとは限りません。どちらの話なのかは、前後で確かめる必要があります。
いちばん単純なものから始める
1本目の記事でいちばん強く書かれているのはここでした。LLM でアプリを作るなら "finding the simplest solution possible"、つまりできるだけ単純な解き方を探し、要るときだけ複雑にする。agentic systems をそもそも作らない、という答えもありうると書かれています。
こうした仕組みは、多くの場合、速さと費用を払って出来を上げるものだからです。多くの用途では、1回の呼び出しを検索や例示で磨けば足りる、とも書かれています。
メリットとデメリット
型に名前があると、どこで分けてどこで確かめるかを言葉で指せます。
デメリットは、複雑にした分の費用です。1本目の記事は、agents は自律的なぶん費用が高く、誤りが積み重なりやすいと書いています。2本目にも、初期のエージェントが互いに更新を送りすぎて邪魔し合った、という失敗が出てきます。
費用の数字はサブエージェントの記事で扱ったので、ここでは繰り返しません。その話は別に書いています。
https://note.com/bebsite/n/n081d0f5ebb0e
BEBSITE の実例：役を減らした
うちの実例は、足したほうではなく減らしたほうです。
2026年9月22日に、統括役のまわりに役を4つ足しました。調査の補佐、進捗と詰まりの取り次ぎ役、監査役、私への問いを集める窓口です。統括役は持ち場へ直接は送らず、取り次ぎ役を通す決まりにしました。
記録では、立てた役はどれも、私が読む量を増やしていました。同じ日に統括役が私へ上げた問いは4つで、そのうち3つは私が「今やることではない」と差し戻しています。
9月25日に、取り次ぎ役と監査役を廃止しました。統括役の仕事は「権限の監視・審査」と「私への問い」の2つに絞り、各持ち場が自分で決めて実行する形にしました。詰まりは止めずに進め、無人タスクの報告と同じ1行の形で出します。
その日、止まっていたものが4件ありました。どれも、書いたものを読む席や読み手がいない形で、役を足して閉じたものは1つも無く、毎日無人で走るタスクに読ませるか、空いた席を立て直すかで閉じています。
なので、いまの統括役は、公式の orchestrator のように仕事を分けて配る役ではありません。仕事を分けて配るのは、各持ち場のメインがサブエージェントを使うときです。
効果は比べられる形で測っていないので、まだ数字では言えません。
BEBSITE の実例：無人タスクは workflow 寄り
無人の定期タスクの指示書は、手順を番号で決めています。毎晩のタスクには「何を打つかは決めません」と書き、合格条件が無ければ何もせずに終える、と止まる条件も並べています。
ここからは私の読みです。手順の自由を指示書で狭めているので、無人タスクは workflow 寄りです。対話のメインは、話を聞きながら手順を自分で決めるので agent 寄りです。
ただ、公式の workflows は決まったコードの経路です。うちは LLM の手順を文章で縛っているだけなので、厳密には agent に手順を渡している形だと思います。
朝に打ち手を決め、夜に1つだけ実行する輪の話は、別に書いています。
https://note.com/bebsite/n/n3d71c8b4c5c6
合う使い方
記事の「いつ使うか」に、私の読みを添えて書きます。
まず、1回の呼び出しで足りないかを見る
段が決まっているならプロンプトチェーン、入力の種類で扱いが分かれるなら振り分け
小分けの仕方が前もって決まらないならオーケストレーター
評価の基準がはっきりしていて、指摘で良くなる仕事なら、書き手と評価役を分ける
何手かかるか読めない仕事だけ agents にする。閉じた環境で試してから使う
4つ目は、うちでも解説記事で使いました。書いた者とは別のサブエージェントに、一次資料と照合させています。ただ照合は1往復で、ループにはしていません。
確かめた日付
この記事に書いた型の名前と説明は、2026年10月12日に本文を読んで確かめた範囲のものです。記述は版で変わるので、日付を入れています。
1本目の記事には、これらの型は決まりではなく、組み合わせて使うものだとも書かれています。うちで先に問うようにしたのは、どの型を足すかより、どの層を外せるかのほうでした。
この記事の仕組みを、業務に合わせて組むところまでをココナラで引き受けています。
