マルチエージェントオーケストレーションのパターン比較

このウィキには、複数の LLM エージェントの間で作業を分担する方法が数多く記録されており、それぞれが異なる出典から書き起こされている。ベンダーのガイドやエンジニアリング記事、フレームワークのドキュメント、実務者の講演やチームの報告、セキュリティのデザインパターン、そして研究文献のレビューである。これらは語彙を共有しており、「オーケストレーター」「プランナー」「ワーカー」「レビュアー」「ハンドオフ」が繰り返し現れる。しかし、制御がどこにあるか、エージェント間で何が受け渡されるか、ワーカー同士が対話するか、そもそもなぜ作業を分割するのか、各記述の背後にどのような証拠があるかは異なる。分割しないことを主張する出典もいくつかある。本ページはそうした違いが見えるように各パターンを並べて示すものである。パターンを順位付けしたり、いずれかを推奨したりはしない。

パターンの比較

委任して回収するコーディネーター

パターン	このウィキの記述の出所	役割	エージェント間での作業の受け渡し方
マネージャーパターン	OpenAI のエージェント構築ガイド	中央のマネージャーと専門エージェント	マネージャーが各専門エージェントをツールとして呼び出す。結果はマネージャーに戻り、マネージャーがユーザーとの対話を続ける
効果的なエージェントの構築 におけるオーケストレーター・ワーカー（orchestrator-workers）	顧客チーム全体で見られたパターンを Anthropic がまとめた一覧	中央の LLM とワーカー LLM	オーケストレーターが入力に基づいてタスクを分解し、委任し、結果を統合する
サブエージェントアーキテクチャ	Anthropic のエンジニアリング記事とドキュメント、採用したチーム、ハンドブックの一章	メインエージェントまたはリードエージェントと、サブエージェント	各サブエージェントは新しいコンテキストで作業し、凝縮した要約をリードに返す
フォークされたサブエージェント	Claude Code のドキュメント	メインセッションとフォーク	フォークは会話全体を引き継ぎ、最終結果だけが戻ってくる
サブエージェント駆動開発	2 つのツールキット（Context Engineering Kit と Superpowers）	オーケストレーションを担うメインエージェントと、タスクごとに 1 体の新しいサブエージェント	各タスクは新たにディスパッチされたサブエージェントに渡され、タスクの合間にレビューが入る
3 層エージェントオーケストレーション	OpenWork のあるエンジニアのコードレビューシステム	親エージェント、収集エージェントと精査エージェント、観点ごとのレビューエージェント	親がサブエージェントを並列に起動する。精査エージェントは、2 体以上のレビュアーが独立に挙げた指摘だけを残す
マルチモデルオーケストレーション	あるエンジニアによる 1 つのプロジェクトについての記事	メインエージェントとしての Claude Code、サブエージェントとしての Codex	Claude が仕様から Codex 向けのプロンプトを書き、Codex は JSON を返す。Claude が結果をレビューし、Codex が失敗を繰り返す場合は作業を引き取る

ピア間を移動する制御

パターン	このウィキの記述の出所	役割	エージェント間での作業の受け渡し方
分散型パターン	OpenAI のエージェント構築ガイド	対等なエージェント。多くの場合トリアージエージェントから始まる	一方向のハンドオフが実行と会話状態を移す。受け取ったエージェントが対話を引き継ぐ
Agent Teams	Claude Code の実験的機能。2 本の記事で説明されている	チームリード、共有タスクリスト、チームメイト	チームメイトは共有リストからタスクを自ら取得し、互いに直接メッセージを送る
並列に動く Claude のチームで C コンパイラを構築する における並列 Claude のハーネス	Anthropic のある研究者の実験	16 体のエージェント。一部は専門の役割を与えられている	オーケストレーション用のエージェントもエージェント間通信もない。各エージェントは共有 git リポジトリにロックファイルを書き込むことでタスクを確保する

最後の行の著者もこの手法を「エージェントチーム」（agent teams）と呼んでいるが、これは別個のハーネスであり、その上の行にある Claude Code の機能ではない。

専門化された役割のパイプライン

パターン	このウィキの記述の出所	役割	エージェント間での作業の受け渡し方
Planner-Worker モデル	Cursor のエンジニアリング実験。2 本の記事で報告されている	Planner、Worker、Judge	Planner がタスクを生成し（サブプランナーとして再帰的にも）、Worker がそれを実装し、Judge が目標を達成したかを評価する
Planner–Executor–Reviewer	エージェント型 AI の文献レビューと、1 つの教材用実装	Planner、Executor、Reviewer。一般に Orchestrator の下に置かれる	逐次型またはグラフ型のパイプライン。自由記述のテキストではなく、型付きの状態遷移を伴うことが多い
長時間稼働するアプリケーション開発のためのハーネス設計 におけるプランナー・ジェネレーター・エバリュエーター（planner–generator–evaluator）	Anthropic Labs のあるエンジニアの実験	プランナー、ジェネレーター、エバリュエーター	プランナーが短いプロンプトをプロダクト仕様に展開する。ジェネレーターとエバリュエーターはスプリント契約を交渉し、ファイルの書き込みと読み込みによってやり取りする
BMAD（Breakthrough Method for Agile AI-Driven Development）	プロジェクトのリポジトリ、それを引用する論文、そのドキュメントを対象とした研究	アナリスト、プロダクトマネージャー、アーキテクト、開発者、UX デザイナー、テクニカルライター	計画段階で PRD と設計を作成する。シャーディングのステップで、焦点を絞ったコンテキストを保持するストーリーファイルを作る。各役割のワークフローが次のフェーズ向けのドキュメントを生成する

作業のためではなく信頼のための分割

パターン	このウィキの記述の出所	役割	エージェント間での作業の受け渡し方
デュアル LLM パターン	Simon Willison の提案。後にそれを含む論文とあわせて再説明された	ツールを持つ特権 LLM と、信頼できないコンテンツを読む隔離 LLM	特権モデルが目にするのは、隔離モデルが読んだものや生成したものを表す記号的な変数だけである
LLM Map-Reduce パターン	LLM エージェントのセキュリティ確保に関する論文をレビューした記事	調整役のエージェントと、項目ごとのサブエージェント	各サブエージェントは信頼できない項目を 1 つ読み、真偽値のような制約された回答だけを返す

フレームワークがパッケージ化している形

3 つのフレームワークのページは、オーケストレーションの形を、組み立てるべきパターンとしてではなく組み込みの選択肢として記録している。

• Microsoft Agent Framework は、あらかじめ用意された逐次（sequential）、並行（concurrent）、グループチャット（group-chat）、ハンドオフ（handoff）のオーケストレーションを挙げている。そのドキュメントはこれらを対話性で区別する。最初の 3 つはそれ自体では自由形式のユーザー入力を待って停止しないが、ハンドオフはデフォルトで対話的であり、エージェントがハンドオフせずに応答すると制御をユーザーに戻す。
• Spring AI Alibaba は、サブエージェントがあらかじめ定義されたフローに沿って動くワークフロー（SequentialAgent、ParallelAgent、LoopAgent）と、フローの次の行き先をモデルが決めるマルチエージェントシステム（LlmRoutingAgent）を区別している。同フレームワーク自身の表では、マルチエージェント型の決定性は、単一の ReAct エージェントと事前定義フローの中間に位置づけられている。
• Agent Development Kit（ADK） は AgentTool によってエージェント全体をツールとしてラップするため、ルートエージェントがオーケストレーターまたはルーターとして振る舞う。これはマネージャーパターンと同じ形である。また、あるハンドブックの一章は ADK を、監督の階層を持つ階層型パターンに対応づけている。

一覧の枠組みを与えるページ

3 つのページは一覧に項目を加えるのではなく、その枠組みを与えている。LLM ベースのマルチエージェントシステム は総称と、そうしたシステムを記述するためのサーベイの軸を示す。すなわち協調モデル（協力型、競争型、階層型、混合型）と通信チャネル（中央型、分散型、階層型）である。コードエージェント・オーケストラ：マルチエージェントのコーディングを機能させるもの はコーディング向けに段階的に拡大する 3 つのパターンを示す。サブエージェント、エージェントチーム、そして大規模なオーケストレーションプラットフォームである。効果的なエージェントの構築 は、LLM とツールが事前定義されたコードパスを通じてオーケストレーションされるワークフローと、LLM が自らのプロセスを指揮するエージェントとの間に線を引いている。

相違点

制御がどこにあるか

OpenAI のガイドは、まさにこの点で 2 つのパターンを区別している。マネージャーパターンではマネージャーが制御を手放すことはなく、ガイドはそれをコンテキストを失わない理由として挙げている。そのエッジは戻ってくるツール呼び出しである。分散型パターンでは、エッジは戻ってこないハンドオフである。受け取ったエージェントが実行を引き継ぎ、自らユーザーに対応する。ガイドはこれを、単一のエージェントが中央で制御を保持したり結果を統合したりする必要がない場合に最適なものとして示している。

もう 1 本の線は、経路を誰が決めるかという点に引かれる。効果的なエージェントの構築 は、オーケストレーター・ワーカーと並列化（parallelization）を、トポロジーではなく柔軟性によって区別している。オーケストレーター・ワーカーでは、サブタスクは事前に定義されておらず、オーケストレーターが入力に基づいて決める。Spring AI Alibaba も、事前定義されたフローとモデルが決めるフローとの間で、自らの型を同じように切り分けている。

サブエージェントアーキテクチャはマネージャーパターンと同じようにリードに制御を残すが、その記述はこの仕組みをツール呼び出しではなくコンテキストの分離という観点で説明している。サブエージェント駆動開発では、オーケストレーターがすべてのタスクを統括する。各サブエージェントを起動し、必要なものを渡し、その作業を制御する。Agent Teams は作業を分解して結果を統合する Team Lead を残すが、タスク間の調整をリードから切り離している。チームメイトがタスクを完了とマークすると、依存するタスクはリードが仲介することなくブロックが解除される。並列 Claude のハーネスにはコーディネーターがまったくない。各エージェントが自分で何をするかを決め、ほとんどの場合は「次に最も明白な」問題に取り組む。Planner-Worker モデルは制御を階層全体に分散させる。Planner はサブプランナーを生成でき、Judge はイテレーションがいつ終わり、いつ再開するかを決める。3 層エージェントオーケストレーションは最上位に親エージェントを置くが、どのレビュアーを動かすかは変更されたファイルの拡張子から機械的に決まる。

信頼を動機とするパターンでは、制御は信頼できないテキストを決して読まないコンポーネントにある。デュアル LLM パターンの特権モデルはツールを保持し、信頼できる入力にしか触れない。Map-Reduce パターンのコーディネーターは、元のテキストを一切必要としない。

エージェント間で何が受け渡されるか

あるエージェントが別のエージェントに何を渡すかは、パターンによって大きく異なる。

• 凝縮された要約。 サブエージェントは数万トークンを探索し、多くの場合 1,000〜2,000 トークンの要約を返す。
• 会話全体。 フォークされたサブエージェントは、メインセッションのシステムプロンプト、ツール、モデル、メッセージ履歴を引き継ぐ。ドキュメントはこれを、他のサブエージェントが提供する入力側の分離を手放すものと説明している。出力側の分離は維持され、最終結果だけを返す。
• 制御を伴う会話状態。 分散型パターンは、ハンドオフそのものと一緒に会話状態を移す。
• ファイル。 サブエージェントのページにある採用チームの 1 つは、各タスクファイルを自己完結的に書き、会話ではなくファイルをエージェント間のインターフェースにしている。BMAD のストーリーファイルは、1 つのタスクのための焦点を絞ったコンテキストを保持する。プランナー・ジェネレーター・エバリュエーターのハーネスでは、ジェネレーターとエバリュエーターがファイルの書き込みと読み込みによってやり取りする。並列 Claude のエージェントは共有リポジトリ内のロックファイルを通じてのみ調整し、README と進捗ファイルを維持するよう指示されている。各エージェントはコンテキストを持たない新しいコンテナで起動するからである。
• 型付きメッセージ。 Planner–Executor–Reviewer のレビューは、自由記述のハンドオフを JSON ペイロードや LangGraph の状態グラフが置き換えていると報告している。LLM ベースのマルチエージェントシステム にあるコード生成のレビューは、オーケストレーションの失敗への対策として、構造化されたスキーマベースのプロトコルを報告している。マルチモデルオーケストレーションでは Codex が JSON を返す。成功時はタスクの出力、使用トークン、ログディレクトリ、失敗時は修正案である。
• 意図的に狭めたチャネル。 デュアル LLM パターンの特権モデルが目にするのは $var1 のような記号的な変数だけである。Map-Reduce パターンのサブエージェントは制約された回答を返す。そのページの記述によれば、真偽値が表現できるのは最悪でも 1 つのファイルについての誤った回答であり、新たな指示ではない。

どれだけ渡すべきかについて、各記述の見解は一致しない。マルチエージェントを構築するな は第一原則として、個々のメッセージだけでなくエージェントのトレース全体を共有すべきだと述べる。元のタスクを各サブエージェントにコピーするだけでは、それをどう読むべきかに関わる以前のターンやツール呼び出しが抜け落ちるからである。LLM ベースのマルチエージェントシステム にあるハンドブックの一章は、エージェント間の効率的なコンテキスト受け渡しを、比較したどのフレームワークも解決していない限界として挙げている。すべてを共有すれば遅く高くつき、要約を共有すれば詳細が失われる。マルチモデルオーケストレーションは、モデル間で同じ断片化が起きることを報告しており、Claude に仕様から Codex 向けのプロンプトを書かせることでそれを橋渡ししている。

ワーカー同士が対話するか

サブエージェントを説明する記述は、ワーカー同士は対話しないとしている。Agent Teams はこの線を明示的に引いている。サブエージェントは単一の親に報告し、互いに対話できないが、チームメイトは発見を共有し、互いのアプローチに異議を唱え、メールボックスを通じて調整する。サブエージェントのページは、Anthropic のリサーチシステムにおける同じ限界を記録している。そこではリードがサブエージェントの各セットの完了を待ち、途中で舵取りすることができず、1 体の遅いサブエージェントがシステム全体をブロックする。

2 つの記述は、互いを見られないワーカーそのものを問題として扱う。マルチエージェントを構築するな は第二原則として、行動は暗黙の決定を伴い、矛盾する決定は悪い結果をもたらすと述べる。コンテキストを共有していても、互いの作業を見られない並列のサブエージェントは、矛盾する前提に基づいて選択を行う。その例は、背景のサブタスクと鳥のサブタスクに分割された Flappy Bird のクローンであり、両者はスタイルが食い違った状態で戻ってくる。並列 Claude のハーネスにもエージェント間通信はなく、Linux カーネルで並列性が破綻したことを報告している。Linux カーネルは単一の巨大なタスクであり、すべてのエージェントが同じバグに突き当たって同じ修正をした。解決策は GCC を既知の正しいオラクルとして使うことであり、これによって異なるエージェントが異なるファイルの異なるバグを追うようになった。

ワーカーが対話しない場合は、別のものがワーカーの必要とするものを運ぶ。自己完結的なタスクファイル、型付きのペイロード、あるいは共有リポジトリ内のロックファイルである。

そもそもなぜ作業を分割するのか

複数のエージェントを持つ理由は、記述によって異なる。

• コンテキスト。 Anthropic は、サブエージェントアーキテクチャを長期にわたるタスクにおけるコンテキストウィンドウの制限を回避する方法として示している。サブエージェント駆動開発は、タスクごとに新しいサブエージェントを起動する理由として コンテキストロット（コンテキストロット）を挙げる。コードエージェント・オーケストラ：マルチエージェントのコーディングを機能させるもの は、単一エージェントの 3 つの制約の最初にコンテキストの過負荷を挙げている。
• 範囲の絞り込み。 Planner–Executor–Reviewer は認知負荷を根拠とする。範囲を狭めることで、計画・統合・検証を一度に行う 1 体の汎用エージェントよりも予測しやすくなることを意図している。3 層エージェントオーケストレーションはレビューの観点について同じ主張をする。小さく境界の定まったタスクのほうが、より正確な出力を生む。
• 調整。 Planner-Worker モデルは、より平坦な設計への答えとして報告されている。その設計では、共有ファイルロックを通じて調整する対等なエージェントが互いを待って行き詰まるか、リスク回避的になっていた。コードエージェント・オーケストラ：マルチエージェントのコーディングを機能させるもの は、サブエージェントが未解決のまま残す調整の問題を Agent Teams が解決したとしている。
• 容量。 Anthropic のリサーチシステムの記事は、BrowseComp において性能のばらつきの 80% をトークン使用量が説明するという結果を、作業を別々のコンテキストウィンドウに分散するアーキテクチャの妥当性を裏付けるものと読んでいる。
• プロバイダーをまたいだスループット。 マルチモデルオーケストレーションが採用されたのは、1 つのプロバイダーのトークン消費上限によって、並列に走らせられる作業ラインの数が頭打ちになっていたからである。
• 独立した判断。 プランナー・ジェネレーター・エバリュエーターの記事は、自分の作業を評価するよう求められたエージェントはそれを称賛しがちであり、別のエバリュエーターを懐疑的になるよう調整するほうが、ジェネレーターに自分の出力を批判させるよりも扱いやすいと論じる。批判的対話レビューは、単一のモデルが自分の出力をレビューしても視点の独立性は弱いと論じる。
• 信頼。 デュアル LLM パターンと Map-Reduce パターンは権限で分割する。危険な能力を持つコンポーネントは、攻撃者が制御しうるテキストを決して読まない。
• プロンプトとツールの肥大化。 OpenAI のガイドは、多くの条件分岐を抱え込んだプロンプトと、選択を混乱させるほど重複したツールを、分割のきっかけとして挙げている。
• 復旧。 サブエージェントのページにある採用チームの 1 つは、失敗したフェーズを実行全体ではなくそのフェーズ単独でやり直せることを付け加えている。

読み取りと書き込み

マルチエージェントシステムをどのように、いつ構築すべきか は、他の記述が別々の側から近づいている区別を示している。読み取りの行動は書き込みの行動よりも並列化しやすい。並列の書き込みには、エージェント間でのコンテキストの伝達と出力のマージの両方が必要であり、矛盾する書き込みは矛盾する読み取りよりもはるかに悪い結果を生むからである。同記事は Anthropic のリサーチシステムを例に挙げる。そこでは複数のエージェントが調査を担当し、最終レポートは単一のメインエージェントが 1 回の呼び出しで書く。Anthropic のリサーチシステムの記事は、現時点ではほとんどのコーディングタスクが適していないと述べている。サブエージェントのページにある採用チームは、各タスクファイルを自己完結的にし、各実行をそれぞれの Git ワークツリーで分離することで、このパターンをコーディングのパイプライン全体で運用している。同ページはこの 2 つをあわせて読み、限界はタスクの切り方次第であることを示すものとしているが、どちらの側も測定はされていない。

レビューがどこにあるか

ほとんどのパターンはどこかに検査の役割を置いており、その置き方はそれぞれ異なる。

• Planner–Executor–Reviewer では、Reviewer は単なる 3 番目の段階ではなく、パターンの検証可能性の仕組みとして説明されている。同ページは、このパターンが適するかどうかを、Reviewer がレビューの基準とする客観的な何かを持っているかどうかに依存させている。
• Planner-Worker モデルは、各イテレーションの終わりに Judge が全体の目標を達成したかどうかを評価する。
• プランナー・ジェネレーター・エバリュエーターのハーネスは、エバリュエーターに Playwright MCP を与え、採点の前に実際のページを操作できるようにしている。著者はエバリュエーターの価値を条件付きのものとして報告している。タスクが現行モデルが単独で確実にこなせる範囲を超えている場合にはコストに見合うが、モデルが改善するとスプリントごとの採点から最後の 1 回のパスに移された。
• サブエージェント駆動開発は、すべてのタスクの合間にレビューを置く。Superpowers では 2 段階で、まず仕様への準拠を、次にコード品質を確認する。Context Engineering Kit は、独立した判定者と、合格するまでの自動リトライループを伴うタスク実行を提供する。
• Agent Teams には、読み取り専用の「@reviewer」チームメイトという報告された実践がある。これは lint、テスト、セキュリティスキャンのツールに制限され、タスクが完了するたびに起動される。
• Claude Code のドキュメントにおけるサブエージェントアーキテクチャの 2 つ目の用途は、差分と基準だけを見る新しいコンテキストからの敵対的レビューである。同じドキュメントは、そうしたレビュアーは作業が健全であっても通常は何らかの不備を報告すると警告している。
• 批判的対話レビューは、異なるモデル上のエージェントを組み合わせる。Codex が批判し、Claude Code が各指摘を理由付きで受け入れ・却下・保留し、Codex が却下された点を再批判する。どちらのエージェントも最終的な判定者ではない。サイクル数の上限に達すると、判断は人間に戻される。
• 3 層エージェントオーケストレーションは、判定を下すレビュアーの代わりに合意を用いる。2 つのモデルファミリーから成る 4 体のエージェントが各観点をレビューし、1 体だけが挙げた指摘は破棄される。LLM ベースのマルチエージェントシステム にあるハンドブックの一章は、意見の不一致を解決する方法として、投票、確信度で重み付けした投票、信頼値に基づくルーティングを挙げている。
• マルチモデルオーケストレーションでは、メインエージェントがサブエージェントの作業を仕様への適合性についてレビューする。
• 並列 Claude のハーネスは検査をエージェントの外に置く。著者は、タスクの検証器はほぼ完璧でなければならないと報告しており、新機能が既存の機能を壊し始めたときに、より厳格な継続的インテグレーションのパイプラインを追加した。

コストと、適さない場面

コストを論じる記述はいずれも、分割を正当化が必要なものとして扱っている。

• 効果的なエージェントの構築 は一般的なルールとして、可能な限り単純な解決策を見つけ、必要なときにだけ複雑さを増すことを挙げている。それはエージェント型システムをまったく構築しないことを意味する場合もある。OpenAI のガイドは、複数のエージェントを導入する前に、単一エージェントの能力を最大限に引き出すことを推奨している。
• マルチエージェントを構築するな は、コンテキストが連続したシングルスレッドの線形エージェントを推奨し、非常に長いタスクには必要に応じて履歴を圧縮する別モデルを組み合わせるとしている。また、2025 年の時点では、エージェント同士が意見の不一致を解決する信頼性は単一エージェントを大きく上回るものではないと判断している。
• Anthropic のリサーチシステムの記事は、マルチエージェントシステムがチャットでのやり取りの約 15 倍のトークンを使うと報告している。初期のバージョンは、タスクの記述が曖昧だった場合に、単純なクエリに対して 50 体のサブエージェントを生成していた。
• プランナー・ジェネレーター・エバリュエーターの記事は、あるプロンプトが単独では 20 分で 9 ドル、完全なハーネスでは 6 時間で 200 ドルかかったと報告している。単独の結果のゲームは入力に反応せず、ハーネスはプレイ可能なものを生み出した。
• 並列 Claude の実験は約 2,000 セッションを実行し、API コストは約 20,000 ドルだった。著者は、自分でコンパイラを作ったとしたら、ましてやチームで作ったとしたらかかったであろうコストのごく一部だと判断している。
• サブエージェント駆動開発は、2 つのバリアントのトークンオーバーヘッドをそれぞれ 1.5〜3 倍、3〜5 倍と報告しており、Superpowers はより安価な代替としてインライン実行を提供している。
• Agent Teams は、各チームメイトが別個の Claude インスタンスであるためにより多くのトークンを消費する。コードエージェント・オーケストラ：マルチエージェントのコーディングを機能させるもの は、チームメイトは 3〜5 体が最適だと報告している。
• 批判的対話レビューは Claude Code を単独で動かすよりも時間とお金がかかると報告されており、重要な機能や高リスクの変更のために取っておかれている。
• Planner-Worker の出典は、この規模はまだ一般的ではなく、ほとんどのユーザーにとっては大きなスウォームよりも有能な長時間稼働エージェント 1 体のほうが実用的であることが多いと述べている。
• 3 層エージェントオーケストレーションは、多数のサブエージェントの起動に別途課金されない料金体系を前提としており、呼び出しごとの課金にはそのままでは移せない。
• デュアル LLM パターンの著者は、そうしたシステムの構築は手間がかかり、それではできないこともあると述べている。Map-Reduce パターンは、サブエージェントの結果が攻撃者の制御する文章を持ち帰れるほど豊かでなければならない場合には誤用となる。
• マルチモデルオーケストレーションは、メインエージェントが Codex への委任を避ける理由を挙げることがあると報告しており、著者はそれを完全には抑えられていない。
• LLM ベースのマルチエージェントシステム にあるハンドブックの一章は、調整のオーバーヘッドが専門化による利得を打ち消しうること、そして逐次的で密結合したタスクには複雑なフレームワークは必要ないことを警告している。
• マルチエージェントシステムをどのように、いつ構築すべきか は、万能の答えはなく、単一エージェントと複数エージェントの間のどこが適切かは問題次第だと結論づけている。

各記述の背後にあるもの

各パターンは異なる種類の証拠に基づいており、各ページはそのことを明記している。

• マネージャーパターンと分散型パターン：独立に確立された分類ではなく、1 つのベンダーが自社の顧客経験を特徴づけたものであり、コード例はそのベンダーの SDK によるものである。
• オーケストレーター・ワーカーとその他の構成要素：Anthropic のコンサルティング経験を定性的に報告したもので、どのパターンについても測定はない。
• サブエージェントアーキテクチャ：ベンダーが報告した結果。リードとサブエージェントから成るシステムが、設計が説明されていない社内のリサーチ評価において単一エージェントを 90.2% 上回ったという結果を含む。これに採用チームによる測定のない報告が加わる。
• フォークされたサブエージェント：1 つのツールが自らの機能について書いたドキュメント。
• サブエージェント駆動開発：2 つのツールキットが自らのツールについて書いた説明。トークンオーバーヘッドの数値はプロジェクト自身のものであり、独立したベンチマークではない。
• Agent Teams：実験的機能であり、セッション再開時にチームメイトが復元されないことや、タスクの状態が遅れて反映されうることなどの制限が挙げられている。
• 並列 Claude のハーネス：1 人の研究者による 1 つの実験の直接の報告で、著者自身はごく初期の研究プロトタイプと呼んでいる。
• Planner-Worker モデル：1 社が報告した実験とその本番設計を、2 本の記事が伝えたもの。
• Planner–Executor–Reviewer：あるレビューの 92 件の一次研究全体で支配的なアーキテクチャとして報告されているが、そのうち産業の文脈で評価されたのは 13 件である。教材用の実装は、このパターンがどう教えられているかの証拠であり、どう機能するかの証拠ではない。
• プランナー・ジェネレーター・エバリュエーター：1 人のエンジニアの実験であり、1 つのプロンプトに対する単独とハーネスの比較が 1 回あるだけで、繰り返しはなく、品質の判断は著者自身の好みに合わせて調整されている。
• BMAD：プロジェクト自身のドキュメントと、そのドキュメントに基づいて採点した研究。その研究は、独立した実証的評価がないものとして記録している。
• 3 層エージェントオーケストレーション：1 人のエンジニアのシステムで、本番運用され定性的なフィードバックがある。著者が示した評価基準は、達成されたとは報告されていない。
• マルチモデルオーケストレーションと批判的対話レビュー：いずれも 1 つのチームまたは 1 人のエンジニアによる自らの導入の報告であり、単一モデルとの比較は測定されていない。
• デュアル LLM パターンと Map-Reduce パターン：著者自身がひどい解決策だがそれでも利用可能な最善かもしれないと呼ぶ研究者の提案と、ここではレビュアーの記述を通じてのみ知られる論文のパターン。文献への取り込みではあっても、導入の証拠ではない。
• フレームワークがパッケージ化している形：各フレームワークのドキュメント、講座、あるいはハンドブックの一章。その章は ADK についての記述に測定を示していない。
• 分割に反対する主張：マルチエージェントを構築するな は測定を報告しておらず、自社のエージェント製品を構築している企業が書いたものである。マルチエージェントシステムをどのように、いつ構築すべきか は、Anthropic と Cognition の記事に対する LangGraph の開発元による論評である。