第7章 — 高度な協働・動的パターン
LLM Primer IV: MCPで設計するAI認知 のウォークスルー第7回です。トポロジが設計時に描けないとき — 次の正しいステップが前のステップが何を見つけたかに依存するとき — 第6章のパターンは十分でなくなります。
なぜこの章があるのか
第6章のパターンには、難しいタスクでは負債になる構造的特徴があります: トポロジが設計時に固定される。エンジニアはパイプラインを描き、ステージに名前を付け、誰が誰に渡すかを決め、ランタイムは再考しません。形が事前に分かるタスクには、これが強み。形が本当に立ち上がりながら決まる — 正しい専門家がユーザーの要求の中身に依存し、計画自体が作業の進行と共に組み立てられねばならない — タスクには、固定トポロジは檻になります。
この章は動的パターンを歩きます: ラウンドテーブルでは複数エージェントが合意に向けて反復し、ルーターは実行時に選ばれた専門家へ委ね、マジェンティックはタスクが進むにつれて計画を作ります。それぞれ、単純なパターンが提供できない能力を買います。それぞれ、単純なパターンが避ける失敗モード — 終わらない、誤ルーティング、暴走する計画 — を持ち込みます。
7.1 グループチャットとラウンドテーブル: メイカー・チェッカー、多者合意
グループチャット・オーケストレーションは、共有された会話コンテキストに複数のエージェントを置き、順に話させます。最も単純な形は2エージェントのメイカー・チェッカー・ループ: メイカーが候補を作り、チェッカーがルーブリックに照らして評価し、フィードバックでメイカーが修正し、承認かターン予算でループが終わる。言語モデルは、両者を正しく枠付けると、生成より評価で測定可能に強くなります — 同じ呼び出しの中で書いて自己評価するよう頼まれたモデルは最初の試みを擁護しがちで、同じ出力を明確なルーブリックとともに新鮮なコンテキストで渡された同じモデルは、明らかに批判的になります。
正直な失敗モードは3つ。結託 — メイカーとチェッカーが同じモデルとプロンプトを共有すると、チェッカーは何でも承認する。守りは本物の役割分化、できれば違うモデル。終わらない — 厳しいチェッカーがどの候補も拒否する。オーケストレータは「最良見」を受け入れるか、エスカレートする必要がある。チェッカーのドリフト — 共有ラウンドテーブル・コンテキストでは、メイカーの正当化が積み上がるにつれてチェッカーが以前なら拒否していたものを承認しはじめる。2025年後半の現場発見は反直感的: 最も信頼できるメイカー・チェッカー・システムは、チェッカーに候補の作られ方を見せないことです。ステートレス・チェッカー — 候補とルーブリックだけ与えられる — は、正しい拒否を30〜50%増やします。共有コンテキストは道具で、既定ではありません。
多者ラウンドテーブルは、複数の専門家とモデレータでパターンを拡張します。コストは速く伸びます: トークン消費は共有トランスクリプトと共に伸び、レイテンシはターン数と共に伸び、エージェントが脱線して動かなくなる事象が本番で観察されます。効かせる規律 — ターンあたりトークンの上限、構造化されたターン出力、明示的な終了ルーブリック — が、生産的な会議と「メールで済んだ会議」を分けます。
7.2 ハンドオフとルーティング: 動的委任
ハンドオフ・オーケストレーションは別の道を行きます: 一度に1つのエージェントが会話を扱い、現在のエージェントは仕事が終わったときや要求が違う専門に移ったときに引き渡せます。ルーター — 通常はそれ自身LLM — が会話状態を読み、ルーティング判断を出力する: 「現状維持」か「専門家Xにこのコンテキスト要約付きでハンドオフ」。要約が、ルーティング層と専門家のあいだの契約です。
最も難しい工学問題は「いつハンドオフが必要かを認識すること」です。誤ルーティングは最も一般的な失敗: ルーターが請求の質問をテクニカル・サポートへ送り、サポートは最善を尽くし、ユーザーはどの懸念にも答えない混乱した答えを受け取る。守りは層を成します: ルーターが人間に委ねる信頼度閾値、専門家が取れる明示的な「これは私の分野ではない」アクション、すべてのルーティング判断のレビュー用ログ。
本番設計を形作る失敗モードがもう2つ。ハンドオフ・ループ — 専門家AがBへ送り、BがAへ送り返す — 繰り返しのハンドオフを検知して別の解決を強制することで守る。コンテキストの喪失 — 各ハンドオフ要約は損失的で、次の専門家はユーザーが既に提供した情報を求めるかもしれない — 完全な会話を専門家のコンテキストの外に保管し、要約をプライマリのペイロードとして使い、必要なら完全履歴を取り寄せられるようにする。専門家数が増えるとフラットなルーターは脆くなります。2025年に現れたパターンは階層的ルーティング — 粗いルーターがカテゴリを選び、カテゴリ別ルーターが専門家を選ぶ。本番では2階層が最適点です。
7.3 マジェンティック・オーケストレーション: 進めながら計画を作る
分解が開始時に分からないタスク — なぜDBが遅いのかを調査する、未知のシステムをデバッグする、複雑なトピックを調査する — に対して、上記のパターンはどれも足りません。マイクロソフトのMagentic-Oneフレームワークにちなんで名付けられたマジェンティック・オーケストレーションは、マネージャー・エージェントがタスク台帳を持ち、作業の進行と共に更新するパターンの総称です。台帳には明示的な枠があります: 元の目標、現在の理解(精緻化されうる)、優先度付きの未完了下位タスク、結果付きの完了済み下位タスク、計画修正を要しうる発見、停止条件。マネージャーは各ステップで台帳を読み、次の派遣を決め、結果を統合します。
強みは本物の自由度です。「DBが遅い理由を調査」は事前に分解できません — 次の下位タスクは、ボトルネックがネットワークか、クエリプランか、ホット・ローかによります。固定パイプラインでは扱えず、どの専門が関連するか事前に分からないので静的ハンドオフ・トポロジでは正しくルーティングできません。
コストはこの章で最も厳しく、あらゆる軸で: レイテンシ、トークン、工学労力、運用リスク。台帳は各ターンで読まれるので、トークン消費は超線形に伸びます。カタログ化された失敗モードは鋭い。暴走する計画 — マネージャーが閉じるより速く下位タスクを開け、台帳が無限に伸びる。目標のドリフト — マネージャーが学ぶにつれ、目標をユーザーの意図から再定式化する。計画の振動 — どの新発見も計画修正を引き、進捗を出すほど長く持続するコミットメントがない。現れたパターンは 境界付きマジェンティック・ループ: 未完了下位タスク、ワーカー呼び出し総数、時計時間の予算と、どれかの境界に当たったときのエスカレーション。境界のない本番マジェンティック・システムは、マネージャーが現実的な予算では解けないタスクで数百ドルのトークンを焼くことがあります。
7.4 パターンの選び方
3つの問いで選びます。トポロジは事前に分かりますか。Yes なら第6章の静的パターンに留まる。仕事は外部チェックに対する反復から利益を得ますか。Yes ならメイカー・チェッカー・ループを足す — どのパターンの内側にも埋め込めます。計画はどれくらい開いていますか。境界が明確ならハンドオフか逐次で扱える。本当に立ち上がりながら決まるならマジェンティックが必要なパターン、そのコストを受け入れて。
2025年の金融サービス会社の事例が教訓的: フレームワークの柔軟性に興奮してマジェンティックを選んだカスタマー・オンボーディング・ワークフローは、固定の逐次パイプラインに置き換えられました。オンボーディングあたりのコストは約7ドルから80セントに落ち、完了率は改善。「もっと特化したツールで足りるのに最も一般的なツールへ手を伸ばす」パターンはソフトウェア工学では新しくありませんが、マルチ・エージェント・オーケストレーションでは鋭く現れます。一般性はトークンで払うからです。
この章を踏まえて
第6章と第7章は、エージェントがどう協調するかを規定しました。エージェントがどこで走るか、言語モデルがツールとどう同所配置されるか、プロセス・マシン・ネットワーク境界レベルでデプロイ・トポロジがどう見えるかには触れていません。同じオーケストレーション・パターンの2つのシステムが、劇的に違う形でデプロイされうる — 違うレイテンシ・プロファイル、違うコスト構造、違うセキュリティ姿勢。第8章はその次元を扱います。
次回 — 第8章: デプロイメント・レイアウト。 MCPが物理的にデプロイされる3つの大きく異なる形 — モデル付きサーバー、クライアント内モデル、ハイブリッド — と、レイテンシ・コスト・運用複雑性・各構成が起こしやすい失敗の現実的トレードオフ。
