第6章 — オーケストレーションの基本

LLM Primer IV: MCPで設計するAI認知 のウォークスルー第6回です。マルチ・エージェント・システムは分散システムである — その枠が受け入れられると、この章の設計選択のほとんどは見慣れた話になり、2024年と2025年の高くついた失敗の多くは「謎」ではなくなります。

なぜこの章があるのか

エージェント型システムを取り巻くマーケティング言語は、「エージェントが多いほど本質的に良い」と示唆します — 認知の馬力が増え、専門性が増え、創発的な能力が増える、と。多くの場合、工学の現実は逆向きです。エージェントを足すたびに、ラウンドトリップが増え、シリアライズ点が増え、あるエージェントの出力が別のエージェントの入力になる場所が増え、会話が脱線する新しい機会が生まれます。最初に問うべきは「これをどうエージェント間に分散するか」ではなく「適切なツールを持つ単一モデルが一度の呼び出しでこれをできないか」です。

この章では、2つの最も単純なオーケストレーション形 — 逐次と並行 — を歩き、どちらに行く前にも問うべき前提の問いを置きます。直近2年の本番での最も高くついた失敗の多くは、オーケストレーションの失敗ではありません。マルチ・エージェントとして組まれたシステムが、単一のよく装備されたエージェントなら1/10のレイテンシで、調整バグなしでこなせた仕事だった、という失敗でした。

6.1 マルチ・エージェントが本当に効くとき

ツール付きの単一エージェントが最も強いのは、タスクが少数の明確に定義された操作と明確に定義されたデータソースに分解できるときです。差分を読み、リンタを走らせ、慣習を引き、コメントを書くコードレビュー・アシスタントは、1回のモデル呼び出しと4つのツールで作れます。2つ目のエージェントを足すのは、能力を増やさずレイテンシを足す行為です — モデルはすでに計画している。違う計画をする2つ目のモデルは協調コストで、改善ではありません。

マルチ・エージェントが報われるには、3つの性質のどれかが要ります。コンテキストの異質性 — 2つのフェーズが大きく違うシステムプロンプト、ツール、参考資料を必要とするとき、両方を1つのウィンドウへ押し込むとモデルの注意が希薄化します。research-then-writeが典型: 検索は広さと検索ツールを求め、執筆は散文とツール無しを求める。外部チェックに対する反復的な精錬 — 出力をレビューし、必要なら書き直すなら、作る側とチェックする側はそれぞれ自分のコンテキストとプロンプトを欲しがります。独立した下位タスクの並列性 — 要約する文書ソースが5つ、集める観点が3つ、解析するファイルが10 — 因果依存のない仕事を直列に流すのは時計時間の無駄。

マルチ・エージェントに踏み切る前に、エンジニアはそれを動機づけている性質を名指せるべきです。2025年のある大手物流企業の振り返りで、7エージェントの顧客サポート・オーケストレーションが、Claudeエージェント1つと6つのMCPツールに置き換えられました。単一エージェント版のほうが速く、安く、解決品質も高い。「これを畳めないか」は、どんなオーケストレーション・レビューでも常設の問いになるべきです。

6.2 逐次オーケストレーション: パイプラインと段階的精錬

逐次オーケストレーションは最も単純なマルチ・エージェント形です。あるエージェントの出力が次の入力になります。本番の「マルチ・エージェント」システムのほとんどは、変装した逐次パイプラインです。強みは可読性: パイプラインはホワイトボードに描け、ステージごとにテストでき、入出力契約の連なりとして推論できます。ステージ間の契約こそ鍵の成果物 — 各ステージは入力スキーマを宣言し、オーケストレータは信頼ではなくコードで強制し、検証失敗は静かに伝播するのではなくリトライやフォールバックを引きます。

典型例はresearch-then-writeです。Web検索と検索ツールを持つリサーチ・エージェントが構造化ブリーフを作り、ツールを持たず散文プロンプトのライティング・エージェントがブリーフを記事に変える。ライティング・エージェントは失敗した試行、捨てたソース、長い推論連鎖を見ません。ブリーフを見ます。両ステージは別モデルでよく — リサーチに強い推論、執筆に強い散文 — コストはそれぞれが必要とする場所だけで発生します。段階的精錬は近い親戚: ドラフト、編集、ファクトチェック、再フォーマット。専門化されたオペレータは、全部を1パスで通そうとするジェネラリストに勝ちます。

正直なコストは3つ。レイテンシ — Nステージのパイプラインは下限が各ステージの実行時間の和。長いパイプラインは、定義上、会話レイテンシの土俵を降ります。誤差増幅 — 4ステージで各95%は、エンドツーエンド81%。8ステージなら66%。ステージごとの検証と境界付きリトライが、計算を運用可能に保ちます。ステージ間の情報損失 — 各出力は作業コンテキストより必然的に狭く、ライティング・エージェントが後から必要だと気づく情報は、ブリーフのスキーマが厳密に必要な以上にリッチでなければ失われています。

6.3 並行オーケストレーション: スキャッタ・ギャザー、多視点

並行オーケストレーションは複数のエージェントを並列で走らせ、出力を統合します。定義上の性質は、作業中は因果依存がない — 統合ステップでのみ依存が出る、ということ。スキャッタ・ギャザーとも呼ばれ、エージェント版map-reduceとも呼ばれます。トポロジは同じです。

3つの用途が動機づけます。独立下位タスクの並列性 — 5つのソースを並列で読み、シンセサイザを1つ。時計時間は最遅の読み手+シンセサイザで、和ではない。多視点分析 — 同じ入力を金融アナリスト・プロンプト、法務レビュアー・プロンプト、製品戦略家プロンプトに与え、出力が化粧違いではなく本当に異なる枠付け。信頼性のためのアンサンブル — 同じプロンプトを複数エージェントで実行し、投票か平均で出力を決める。誤答のコストが3倍のトークン代より遥かに高い場面で正当化されます。

統合ステップは工学的努力が報われる場所です。長くて矛盾する入力を与えられた素朴なシンセサイザはボトルネックになります。3つのパターンが効きます: 構造化された中間出力 — シンセサイザが散文を読み直すのではなくフィールドを決定的にマージする。階層的縮約 — ファンアウトが増えても、各統合エージェントが見る入力数を有界に保つ。対立の表面化 — シンセサイザが不一致を静かに片方に決めず、ラベルする。

スキャッタ・ギャザーが正解かを診る問い: ある並列エージェントに、もう一方が今何を作っているかを伝えたら、出力が変わるか。Yes なら作業は独立ではなく、パターンが間違いです — 逐次依存か、第7章の動的パターンが必要です。

6.4 協調の正直な計算

どのオーケストレーション・パターンも、実行時は信頼できないワーカー上の分散ワークフローです。質の高いモデルでも呼び出しごとの失敗率は1〜5%が普通 — JSONパース失敗、契約違反、幻覚のツール名、静かなスキップ。パイプラインを通じて掛け算すると、8ステージで各2%はエンドツーエンド85%。緩和は構造的: 境界付きリトライを引くステージごとの検証、入出力・レイテンシ・トークン消費・通過した検証ゲートを記録するステージごとの可観測性、リトライ予算を使い切ったら全体崩壊ではなく上品に劣化する境界付きフォールバック。

レイテンシ予算には床だけでなく天井が要ります — ユーザーは平均ではなくロングテールを気にします。コスト予算は事前にモデル化: 2ステージは1ステージのおよそ1.5倍、5枝のスキャッタ・ギャザーは5〜8倍、ラウンドテーブルは10倍以上。一部のシステムが規模で成り立たないのは、対話あたりのコストが対話の価値を超えるから。請求書が来てからではなく、設計時に算術しましょう。

この章を踏まえて

逐次と並行は積み木です。タスクのトポロジが事前に分かっていて、ワーカーの役割が固定されているマルチ・エージェントの用途を、ほぼ捌けます。両方とも前提があります: 誰かが設計時にエージェントが何で、どう繋がるかを決めた、という前提。オーケストレーションは静的で、パイプラインはユーザー要求が届く前に描かれています。第7章はこの前提を外します。

次回 — 第7章: 高度な協働・動的パターン。 ラウンドテーブル、ハンドオフ・ルーティング、マジェンティック — トポロジが設計ではなくリクエストごとに組み立てられるときに何が起きるか、そして単純なパターンが避ける失敗モード(終わらない、誤ルーティング、暴走する計画)。