レッスン4: オーケストレーター・ワーカー: 分解そのものを動的にする

学習目標:

• オーケストレーター・ワーカーを定義し、並列化との決定的な違いを言語化する: 形は似ているが、サブタスクは事前定義されず、オーケストレーターが具体的な入力に基づいて決める
• すべてのディスパッチに4要素（目的、出力フォーマット、使うツールとソースの指針、タスクの境界）を配り、「いくつ起動するか、それぞれいくら使ってよいか」というスケーリングルールをプロンプトに書き込む
• 実運用システムの完全な収支表を読む: 90.2% の改善はどの条件下で現れるのか、15× の請求書がなぜ同じメカニズムのもう半分なのか、同期実行は何を塞いでいるのか、非同期化は新たにどの3つのコストを背負わせるのか

前提: レッスン1〜3を修了していること（本レッスンはレッスン3の末尾で答えを保留した問いを引き継ぎます） | 前: << レッスン3 | 次: レッスン5 >>

レッスン3が残した穴

レッスン3ではセクショニングを書きました。タスクを独立したサブタスクに切り分け、同時に走らせ、結果をコードで集約する、というものです。あのコードを振り返ってみてください。分割のロジックはどこに置かれていたでしょうか。あなたがハードコードした配列の中です——SECTIONS = ['security', 'performance', 'readability']。3つのブランチはコードを書いた時点で決まっており、実行時はそれをなぞるだけです。

このやり方は、ある硬い前提のもとで成立します。タスクの分け方を、書く時点ですでに知っているという前提です。コードレビューはその前提に当てはまります。レビューの観点は安定していて、別のリポジトリに差し替えても見る側面は同じだからです。

では、別のタスクを考えてみましょう。

「このコードベースのパフォーマンス問題を調査してください。」

いくつに分けますか。どう分けますか。ハードコードできません。ボトルネックはデータベースクエリにあるかもしれず、その場合は ORM の呼び出し箇所を洗う担当を出すことになります。ホットパスのループかもしれず、その場合はプロファイラの出力を読む担当を送ることになります。実行時とは無関係に、ビルド成果物のサイズが原因かもしれません。どのファイルを変えるのか、どの方向を調べるのか——この具体的なリポジトリ、この具体的な問題記述を見てからでないと分かりません。

言い換えると、分解そのものを実行時に計算しなければならないということです。あなたのコードはもう「どの断片に切るか」という決定を抱えていません。抱えているのは「どう配って、どう回収して、どう合成するか」というメカニズムだけです。ではその決定を下すのは誰か。LLM です。

これが4つ目のパターンです。

定義と、並列化との違い

公式の情報源は一文で定義しています。オーケストレーター・ワーカーのワークフローでは、中央の LLM がタスクを動的に分解し、それをワーカー LLM に委任し、その結果を合成します¹。

3つの動作、すなわち分解・委任・合成です。真ん中の「委任」はレッスン3ですでに書きました。ファンアウトのコードはほぼ同じです。本当に新しいのは最初の動作です。分解がコードからモデルの手に移ります。

適用条件の記述はもっと具体的です。このワークフローは、必要なサブタスクを予測できない複雑なタスクに適しています。公式が挙げる例はコーディングです。変更が必要なファイルの数と、各ファイルでの変更の性質は、タスクそのものに依存する可能性が高いからです¹。

そして、覚えておくべき比較が続きます。原典はこう言います。並列化とは形の上では似ている（topographically similar）が、決定的な違いは柔軟性である。サブタスクは事前定義されるのではなく、具体的な入力に基づいてオーケストレーターが決定する¹。

使われている語は "topographically similar"（形状の上で似ている）です。この言い回しは一拍置いて考える価値があります。レッスン3のセクショニングと、本レッスンのオーケストレーター・ワーカーを図にすると、ほとんど同じ形が描けます。1つのノードが3つに扇状に広がり、それがまた1つに畳まれる。形は人を騙します。違いは図の中にはなく、その決定がいつ下されるかにあります。

最後の行に、エンジニアリング上の痛みが集約されています。セクショニングでは各ブランチのプロンプトを手で磨けます。繰り返し調整でき、観点ごとに例を足すこともできます。オーケストレーター・ワーカーではそれができません。ディスパッチのプロンプトはオーケストレーターがその場で生成するので、あなたが制御できるのはそれを生成するときに従うルールだけです。次の2つのセクションは、そのルールに何を含めるべきかを説明します。

まずはメカニズムを骨組みとして書き出しておきましょう。以下のコードは本レッスンが独自に用意した図解です。一次資料に公式のオーケストレーション用スクリプトは存在しないので、標準的な実装として扱わないでください。

これをレッスン3のファンアウトのコードと1行ずつ比べてみてください。増えているのはステップ1だけだと分かります。その1ステップが、システム全体の予測可能性と引き換えになっている——だからこそ、後半のセクションで勘定を1つずつ立てる必要があるのです。

実運用システムはどう見えるか

パターンの定義を暗記していても、それが本番でどう見えるかを知らないままということはあり得ます。本レッスンには有利な材料があります。Anthropic が自社の Research 機能についてエンジニアリングの振り返りを公開しており、これは実運用中のオーケストレーター・ワーカーシステムだからです。このセクションと続く数セクションは、その収支表から引いています。

アーキテクチャに関する記述はこうです。彼らの Research システムはオーケストレーター・ワーカーパターンによるマルチエージェントアーキテクチャを採用しており、リードエージェントがプロセスを調整しつつ、並列に動作する専門サブエージェントに委任します²。

動いている様子はこうです。ユーザーがクエリを送信すると、リードエージェントがそれを分析し、戦略を立て、異なる側面を同時に探索するサブエージェントを起動します²。

"analyzes it, develops a strategy"（分析し、戦略を立てる）に注目してください。前のセクションで述べた実行時の決定がこれです。ユーザーが何かを尋ね、リードエージェントがその場で、いくつの方向を追うか、それぞれ何を調べるかを割り出します。

もう1つ、定義として抜き出しておく価値のある記述があります。マルチエージェントシステムとは、複数のエージェント（ツールをループの中で自律的に使う LLM）が協働するものです²。

この括弧の中は聞き覚えがあるはずです。ワーカーは新しいものではありません。本シリーズのコース7で書いた、あのハーネスのループです。 オーケストレーター・ワーカーは新しい実行単位を導入するのではなく、「1つのループが別のひとまとまりのループを起動する」ことを導入します。そのループの書き方はもう知っています。本レッスンが教えるのは、それらをどうつなぐかです。

同じ振り返りは、なぜファンアウトが効くのかも説明しています。検索の本質は圧縮であり、膨大なコーパスから洞察を蒸留することです。サブエージェントはそれぞれ自分のコンテキストウィンドウを持って並列に動作し、問いの異なる側面を同時に探索したうえで、最も重要なトークンをリードのリサーチエージェントに向けて凝縮します。これが圧縮を助けます。加えて各サブエージェントは関心の分離ももたらします——異なるツール、プロンプト、探索の軌跡を持つことで経路依存性が減り、徹底した独立の調査が可能になります²。

「独立したコンテキストウィンドウ」については、レッスン3ですでに数字を計算しました。ここでは別の役回りで再登場します。単なる容量ではなく、隔離としてです。3つの調査は互いの中間過程を見られないので、相手の誤りに引きずられて進路を外れることがありません。

収支表の表側: 90.2% と、あの 80%

この振り返りでいちばん有名な数字は、いちばん誤引用されやすい数字でもあります。完全な形はこうです。彼らの内部評価では、マルチエージェントのリサーチシステムは、複数の独立した方向を同時に追う必要がある幅優先型のクエリでとりわけ優れていました。Claude Opus 4 をリードエージェント、Claude Sonnet 4 をサブエージェントとするマルチエージェントシステムが、単体エージェントの Claude Opus 4 を、社内のリサーチ評価で 90.2% 上回りました²。

この数字は、以下の条件をすべて添えずには引用できません。

• 彼らの社内リサーチ評価上での話——公開ベンチマークではなく、再現もできず、あなたのタスク分布に似ているかどうかも分かりません。
• Opus 4 のリード + Sonnet 4 のサブエージェント——その特定の組み合わせでの結果です。別のモデル構成については何も約束されていません。
• とりわけ幅優先型のクエリで優れる——複数の独立した方向を同時に必要とするクエリです。依存が深いタスク（各ステップが前の結論を待つもの）は、この記述の射程に入っていません。

もう1つ、決定的に重要な規律があります。この数字はマルチエージェント対シングルエージェントの比較であって、「構造化されたオーケストレーション対ループ」の比較ではありません。 「制御フローをコードに移すほうが、モデルにループを回させるより優れている」という主張の根拠にはできません。それは別の主張であり、本レッスンの一次資料はどれもその比較をしていません。本レッスンは "who holds the plan"（誰が計画を持つか）という軸を繰り返し使いますが、その軸上のベンチマークデータは一次資料に存在せず、あるのはエンジニアリング上のトレードオフだけです。

では、なぜマルチエージェントは一般に効くのでしょうか。振り返りはもっと散文的な説明を与えています。なお、その裏付けとなる分析は 90.2% を出したものとは別の評価から来ている点に注意してください。マルチエージェントシステムが機能する主な理由は、問題を解くのに十分なトークンを費やす助けになるからです。BrowseComp 評価（探しにくい情報をブラウジングエージェントが見つけられるかを測るもの）の分析では、3つの要因が性能のばらつきの 95% を説明し、そのうちトークン使用量だけで 80% を説明しました。残りの2つの説明要因はツール呼び出しの回数とモデルの選択です²。この発見は、別々のコンテキストウィンドウを持つエージェントに作業を分散させて並列推論の容量を増やす、という彼らのアーキテクチャを裏付けるものだと述べています²。

95% と 80% という数字は BrowseComp の分析についてのみ成立します。一般的な結論として他所へ持ち出さないでください。

ただし、このメカニズムの説明には実用上の使い道があります。あなたのタスクがそこまで多くのトークンを必要としないなら、オーケストレーター・ワーカーの利得の根拠は消えます。（これはメカニズムの記述から推論したエンジニアリング上の判断であって、95%/80% という数字から直接導かれる帰結ではありません。）ドキュメントを1回引けば答えられる問いは、ワーカーを3つ出したところで正確になるわけではなく、ただ高くつくだけです。

収支表の裏側: 4× と 15×

この2つの数字はレッスン1で登場しました。ここでは完全な形を示します。同じ振り返りは直後にこう続けます。ただし欠点がある——実際のところ、この種のアーキテクチャはトークンを猛烈な勢いで消費します。彼らのデータでは、エージェントはチャットでのやり取りに比べておよそ 4× のトークンを使い、マルチエージェントシステムはチャットのおよそ 15× を使います。経済的に成立させるには、マルチエージェントシステムは、その性能向上の対価を払えるだけタスクの価値が高い場面を必要とします²。

2つのセクションの数字を並べてみてください。片側に 90.2%（特定の条件下で）、もう片側に 15×。性能の利得は主にトークンを費やすことから来ると前のセクションで確認したので、請求書が膨らむのは副作用ではありません。同じメカニズムのもう半分です。

「タスクの価値が見合っていなければならない」を、どう運用に落とすのでしょうか。これは実は、技術の問いの前にビジネスの問いに答えることを求めています。この調査が成功したら、それはいくらの価値があるのか。答えが「エンジニアの30分が浮く」なら、15× の請求書はおそらく割に合いません。答えが「本番障害を1件防げる」なら、話は別です。

振り返りはもっと厳しい境界も引いています。すべてのエージェントが同じコンテキストを共有する必要があるドメインや、エージェント間の依存が多いドメインは、今日のマルチエージェントシステムには適しません。たとえば大半のコーディングタスクは、リサーチに比べて真に並列化できるタスクが少なく、LLM エージェントはまだリアルタイムに他のエージェントと調整・委任するのが得意ではありません²。逆に、重い並列化を伴い、単一のコンテキストウィンドウを超える情報を扱い、多数の複雑なツールとやり取りする価値の高いタスクでは、マルチエージェントシステムが優れていることを彼らは見出しています²。

ここでは2つの文をセットで読まないと誤解します。公式のパターン原典は「サブタスクを予測できない」例としてコーディングを挙げており¹、マルチエージェントの振り返りは大半のコーディングタスクはリサーチより真に並列化できるタスクが少ないと言っています²。両者は矛盾しません。別のことを言っているのです。前者は分解を動的に計算しなければならないと言い、後者は計算されたサブタスクが必ずしも全部同時に走るとは限らないと言っています。動的な分解は並列性を必然的に伴うわけではありません。オーケストレーターが5つのサブタスクを計算し、そのうち3つを順に、2つを並列に走らせることは何ら問題なく起こり得ます。

委任プロンプトの4要素

本レッスンでいちばん覚えて帰るべきエンジニアリングの規律がこれです。原文は短いものです。

"Teach the orchestrator how to delegate. In our system, the lead agent decomposes queries into subtasks and describes them to subagents. Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information"².

4つの要素、どれも省略不可です。

目的——このワーカーがどんな結論を出すべきか。「パフォーマンスを調査する」ではなく、「self-time が最も大きい実行時 CPU ホットスポットを3つ見つける」です。目的は、達成できたかどうかを判定できるくらい狭くなければなりません。

出力フォーマット——返ってくる成果物がどんな形をしているか。フィールド、件数の上限、並び順。この項目は、オーケストレーターの合成段階をどれだけ書きやすくするかを直接決めます。3つのワーカーが3つの散文段落を返してくるなら、合成はモデルにもう一度読ませるしかありません。同じスキーマに従う JSON を返してくるなら、合成の半分はコードでできます。

ツールとソースの指針——どのツールを使ってよいか、どこを見るか。この項目はコスト制御であると同時にドリフト防止でもあります。Web 検索ツールを渡さなければ、存在しないものを検索しに行くこともできません。

タスクの境界——やってはいけないことを明示します。この項目はいちばん抜けやすく、そしてワーカー同士が衝突するかどうかを最も直接的に決めます。「src/server/ は見るな、そこは別のワーカーの担当だ」——この一文は、事後の重複排除より効きます。

振り返りが挙げる失敗例はほとんど教科書的です。たとえば、あるサブエージェントが 2021 年の自動車向け半導体危機を調べている一方で、他の2つは 2025 年現在のサプライチェーンを調べて作業を重複させており、有効な分担がありませんでした²。

3つのワーカーのうち2つが重複し、1つが無関係な年に走っていった——これがまさに "duplicate work, leave gaps"（作業が重複し、抜けが残る）の具体的な姿です。

すでに学んだこととの橋渡しをしておきます。本シリーズのコース6はマルチエージェントコラボレーションを扱う際に、この4項目をすでに分解して説明しました（そこでの呼び方は目的、スコープ、情報源、出力フォーマットです）。レッスン2でも言及しました。 本レッスンはその2箇所がやらなかったことをします。4要素を、オーケストレーターがその場で生成するディスパッチという位置に戻すのです。あなたが制御するのはもはや各ディスパッチの中身ではなく、オーケストレーターがそれを生成するときに従うルールだけです。4要素はそれでもチェックリストとして機能します。ディスパッチを1つ書き終えたら、4項目が揃っているかを1つずつ数えて確認してください。

複雑さに応じた労力のスケーリング: 配分ルールをプロンプトに書き込む

4要素は「各ワーカーが何をするか」を解決します。残る問いが1つあります。いくつ起動するか、それぞれいくら使ってよいかです。

この一連の数字はコース6の冒頭で登場しました。ここでの使い方は違います。マルチエージェントを使うかどうかの判断材料としてではなく、オーケストレーターのプロンプトに書き込んで、オーケストレーター自身に配分させるためのものです。振り返りの診断は率直です。エージェントはタスクごとに適切な労力を判断するのが苦手なので、彼らはスケーリングルールをプロンプトに埋め込みました。単純な事実確認ならエージェント1体でツール呼び出し 3-10 回、直接比較なら 2-4 体のサブエージェントでそれぞれ 10-15 回、複雑なリサーチなら責務を明確に分けた 10 体超のサブエージェントを使うこともある、というものです²。

これらの数字についての引用規律を1つ。その正体は「彼らが自分たちのプロンプトに埋め込んだルール」であって、業界標準でもなければ、あなたがそのまま写すべき目盛りでもありません。 あなたのタスク分布、ツールの速度、モデルは彼らのものとは違います。本当に移植できるのは実践そのもの、すなわち配分ルールをオーケストレーターのプロンプトに明示的に書き込むこと、オーケストレーターの自制に期待しないことです。

書かなかったらどうなるか。振り返りがその光景を提供しています。マルチエージェントシステムはシングルエージェントシステムと重要な違いがあり、その1つが調整の複雑さの急激な増大です。初期のエージェントは、単純なクエリに 50 体のサブエージェントを起動する、存在しない情報源を求めて延々と Web を漁る、過剰な更新で互いの注意を逸らす、といった誤りを犯しました²。

"spawning 50 subagents for simple queries"（単純なクエリに 50 体のサブエージェントを起動する）——これを前セクションの収支表で換算すれば分かります。彼らのデータではマルチエージェントはチャットのおよそ 15× のトークンです²。この種の暴走したファンアウトは、その倍率をさらに大きく押し上げます。配額のルールはケチ臭さの問題ではありません。コストとタスク価値を同じオーダーに保つための手段です。

このルールを自分のオーケストレータープロンプトにどう書くか。彼らの形をなぞって、自分の目盛りを埋めてください。タスクをいくつかの段階に分け、段階ごとにサブエージェント数の上限とサブエージェントあたりのツール呼び出し上限を定め、そこに「上限を超えたら現時点の発見を返し、続行しない」という条項を足します。これで暴走の確率は下げられますが、それでもプロンプトにすぎません。非決定的なモデルに対して、プロンプトに書かれた上限は常に助言でしかありません。本当のゲートはコード側にあります。骨組みの pool に渡す LIMIT です。プロンプト層は「モデルの自覚」を担当し、コード層は「最後の砦」を担当します。両方が必要です。

同期のボトルネックと、非同期の代償

このセクションは、このアーキテクチャが今日まだ解決していない問題を扱います。原文は2つの段落から成ります。

第1段落、現状について。同期実行はボトルネックを生みます。現在、彼らのリードエージェントはサブエージェントを同期的に実行し、ひとまとまりのサブエージェントが完了するのを待ってから先へ進みます。これは調整を単純にしますが、エージェント間の情報の流れにボトルネックを作ります。たとえば、リードエージェントはサブエージェントの舵を切れず、サブエージェント同士は調整できず、1体のサブエージェントの検索完了を待つ間、システム全体がブロックされ得ます²。

3つの「できない」があり、それぞれが現実の損失に対応します。

• リードエージェントが途中で軌道修正できない——2分の時点でワーカーC の方向が誤っていると分かっていても、そのまとまりが終わるまで何もできません。
• サブエージェント同士が調整できない——ワーカーA が何かを見つけても、ワーカーB はそれを知らず、いままさに同じものを調べ直しているかもしれません。
• まとまり全体が最も遅い1体に足を引っ張られる——3分で終わった2体は、25 分でタイムアウトする1体と一緒に、25 分まで待たされます。

第2段落、もう一方の道の代償について。非同期実行はさらなる並列性を可能にします。エージェントが同時に作業し、必要に応じて新しいサブエージェントを作れるようになります。しかしこの非同期性は、結果の調整、状態の一貫性、そしてサブエージェントをまたぐエラーの伝播という課題を追加します²。

この一文のトーンに注目してください。一次資料はこの3項目を課題として列挙しており、解決済みの問題としては扱っていません。したがって本レッスンは「公式推奨の非同期オーケストレーション方式」を提示しません。そんなものは存在しないからです。自分で非同期化するなら、この3項目はあなたが背負うものです。

• 結果の調整: ワーカーはばらばらに返ってきます。「どこまで揃ったら合成を始めてよいか」は、あなたが定義しなければならない判断です。
• 状態の一貫性: リードエージェントが途中で調査範囲を変えたのに、走行中のワーカーは古い範囲のまま動いており、両者の前提が分岐しています。
• エラーの伝播: あるワーカーが失敗したが、その中間出力はすでに新しいワーカーの起動に使われていました。その連鎖の中で誰が再実行すべきで、誰の結果が無効になるのか——ここには明示的なルールが要ります。

本レッスンのレベル2の演習では、具体的なタイムライン上でこの3項目それぞれの具体例を1つずつ挙げてもらいます。

創発的な振る舞いと、ラストマイル

同じ振り返りから、エンジニアリング上の教訓をもう少し拾います。どれも短いですが、どれも本番障害1件分の価値があります。

マルチエージェントシステムには創発的な振る舞いがあり、それは明示的にプログラムしなくても現れます。たとえば、リードエージェントへの小さな変更が、サブエージェントの振る舞いを予測不能に変えることがあります。成功には、個々のエージェントの振る舞いだけでなく、相互作用のパターンを理解することが必要です²。同じ振り返りはさらに厳しい一文を添えます。従来のソフトウェアでは、バグは機能を壊し、性能を劣化させ、あるいは障害を起こす程度です。エージェント的システムでは、些細な変更が大きな振る舞いの変化へと連鎖し、長時間走るプロセスの中で状態を保たなければならない複雑なエージェントのコードを書くことを著しく難しくします²。

日々の作業への影響はこうです。オーケストレーターのプロンプトを変えたら、評価スイート全体を再実行しなければなりません。オーケストレーター自身の出力だけを確認して済ませることはできません。 コース10の評価の滑走路がここで効いてきます。小さな変更がサブエージェントを進路から外していないかを見るための、唯一の計測器だからです。

ラストマイルが旅の大半になることが多い——AI エージェントを作るとき、ラストマイルが旅の大半になることがよくあります。開発者のマシンで動くコードベースを、信頼できる本番システムにするには相当のエンジニアリングが必要です。エージェント的システムにおけるエラーの複合的な性質は、従来のソフトウェアなら些細な問題がエージェントを丸ごと脱線させ得ることを意味します²。

付随する実践が2つあります。彼らは Claude の上に構築された AI エージェントの適応性を、リトライロジックや定期的なチェックポイントといった決定的なセーフガードと組み合わせています²。また、走行中のエージェントを妨げないために、レインボーデプロイを用いています。新旧のバージョンを同時に走らせたまま、トラフィックを徐々に移していく方式です²。

レインボーデプロイ——これはコース9の冒頭で、デプロイ更新をクラッシュのシナリオとして扱ったときに触れた問題につながります。通常の Web サービスなら、再起動してもユーザーが一度リトライすれば済みます。20 分走り続けていたエージェントが再起動で中断されれば、20 分の作業と、すでに使ったトークンを失います。長時間走るタスクのデプロイは、ステートレスなサービスのデプロイとは違います。

較正: これは5つのパターンの中でいちばん高い

ここまでで、5つのパターンのうち4つを見ました。コスト順に並べると、オーケストレーター・ワーカーはここまでで最も高価です。並列化のオーバーヘッドに加えて、「モデルに分割を計算させる」呼び出しが1つ増え、さらに「分割が誤って計算されるかもしれない」というリスクも増えるからです。

だから着手する前に、次の3つを順番に問うてください。

第一に、分割はハードコードできないか。 できるなら、レッスン3に戻ってセクショニングを使ってください。セクショニングでは各ブランチのプロンプトを手で磨けます。オーケストレーター・ワーカーのディスパッチはモデルがその場で生成したものです。前者のほうが品質の上限が高く、デバッグもしやすい。事前定義できるなら、動的にしないでください。

第二に、このタスクはそれだけの金額に見合うか。 彼らのデータではマルチエージェントはチャットのおよそ 15× のトークンであり²、経済的に成立させるには、その増分を支払えるだけタスクの価値が高くなければなりません²。これは技術ではなくビジネスの判断ですが、コードを書く前に下さなければならない判断です。

第三に、確信が持てないなら、まず測る。 パターン群全体に対する公式の締めくくりの姿勢はこうです。これらのビルディングブロックは規範ではありません。成功の鍵は性能を測定し、実装を反復することであり、複雑さを足すのは、それが結果を改善すると実証できる場合に限るべきです¹。コース10がその滑走路を用意してくれました。まず実際のタスク集合を単一のループで走らせてベースラインを取り、それからオーケストレーター・ワーカーがそれを押し上げるかを判断してください。ベースラインがなければ、「良くなった気がする」と「15× 払って同じ結果になった」は、あなたには見分けがつきません。

本レッスンが扱ったのは「出して、回収する」までです。返ってきた成果物の品質が低かったらどうするか、別のエージェントにレビューさせるべきか、そしてこの4つのパターンをどう組み合わせるか——それはレッスン5の内容です。

💻 演習

まとめ

• オーケストレーター・ワーカーは、中央の LLM がタスクを動的に分解し、ワーカー LLM に委任し、その結果を合成するワークフローです。必要なサブタスクを予測できない複雑なタスクに適しています¹
• 並列化とは形の上で似ていますが、決定的な違いは柔軟性です。サブタスクは事前定義されず、具体的な入力に基づいてオーケストレーターが決定します¹——形は同じ、決定のタイミングが違うのです
• ワーカーは新しいものではありません。マルチエージェントシステムとは「ツールをループの中で自律的に使う LLM」が複数協働するもので、リードエージェントがプロセスを調整し、並列に動作する専門サブエージェントに委任します²
• 90.2% はその完全な文脈の中でのみ成立します。彼らの社内リサーチ評価、Claude Opus 4 のリード + Claude Sonnet 4 のサブエージェント、とりわけ幅優先型のクエリで優れる、という条件です²。メカニズムの説明は、マルチエージェントが主に十分なトークンを費やす助けになるというもので、BrowseComp の分析では3つの要因がばらつきの 95% を説明し、トークン使用量だけで 80% を占めました²
• 請求書は同じ収支表の裏側です。彼らのデータでは、エージェントはチャットのおよそ 4× のトークン、マルチエージェントはおよそ 15× であり、経済的に成立させるにはその対価を払えるだけタスクの価値が高くなければなりません²
• 各サブエージェントには、目的、出力フォーマット、使うツールとソースの指針、明確なタスクの境界が必要です。詳細なタスク記述がなければ、エージェントは作業を重複させ、抜けを残し、必要な情報を見つけられません²——コース6の「自己完結した委任プロンプト」は、この4項目へと展開されます
• エージェントは適切な労力を判断するのが苦手なので、配分ルールをプロンプトに書き込んでください。彼らの目盛りは、単純な事実確認はエージェント1体で 3-10 回、直接比較は 2-4 体でそれぞれ 10-15 回、複雑なリサーチは責務を明確に分けた 10 体超、というものです²。ルールを書かなかった場合の帰結も彼らは見ています——単純なクエリに 50 体のサブエージェントを起動する、存在しない情報源を求めて延々と Web を漁る、過剰な更新で互いの注意を逸らす²
• 同期実行は調整を単純にしますが、情報の流れを塞ぎます。リードエージェントは途中で軌道修正できず、サブエージェント同士は調整できず、システム全体が1体のサブエージェントにブロックされ得ます²。非同期はより多くの並列性を可能にしますが、その代償は結果の調整、状態の一貫性、サブエージェントをまたぐエラーの伝播です——この3つは一次資料では課題であって、解決済みの解ではありません²
• マルチエージェントシステムには創発的な振る舞いがあり、リードエージェントへの小さな変更がサブエージェントの振る舞いを予測不能に変えることがあります。個々のエージェントだけでなく相互作用のパターンを理解することが重要です²。ラストマイルが旅の大半になることが多く、開発者のマシンで動くコードベースを信頼できる本番システムにするには相当のエンジニアリングが必要です²。付随する実践は決定的なセーフガード（リトライロジック、定期的なチェックポイント）²と、レインボーデプロイ——両バージョンを走らせたままトラフィックを徐々に移し、走行中のエージェントを妨げない方式です²
• これはここまでに学んだ4つのパターンの中で最も高価です。着手する前に、分解が本当に事前定義できないことを確認し（できるならレッスン3のセクショニングに戻る）、次にタスクの価値が 15× を支えられることを確認してください。確信が持てないなら、まずコース10の滑走路でベースラインを測ること——複雑さを足すのは、それが結果を改善すると実証できる場合に限ります¹

>> レッスン5: レビュー回路と、パターンをグラフに組み上げる

Footnotes

1. Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴ ↩³⁵ ↩³⁶ ↩³⁷ ↩³⁸