マルチエージェントのオーケストレーションとスーパーバイザー制御

85%の確率で正しい答えを出す個々のAIエージェントは優秀に聞こえます——5つを連鎖させてエンドツーエンドの成功率が44%に落ちるまでは。10個連鎖させれば20%です。この複利的に悪化する失敗の数学こそが、デモ段階を越えたマルチエージェントプロジェクトを頓挫させる原因であり、その原因はほぼ決してモデルの質の悪さではありません。それはガバナンスの効いていないオーケストレーションです。私たちのアプローチは、オーケストレーション層こそが製品であるマルチエージェントシステムを構築し、混乱させられたりジェイルブレイクされたりしうる別のLLMではなく、決定論的なスーパーバイザーによってそれを統制することです。

誰も警告してくれないマルチエージェントの信頼性問題

上記の複利的な数学は、システムがデモを離れて初めて表面化する失敗モードです。7つのオープンソースエージェントフレームワークにわたる1,642件の実行トレースを分析した研究では、失敗率は41%から86.7%の間であり、全失敗の36.9%が協調の破綻によるものでした。Gartnerは、2027年までにエージェント型AIプロジェクトの40%以上が中止されると予測しており、その主な原因は質の悪いモデルではなく——ガバナンスの効いていないオーケストレーションです。

私たちが設計するシステムでは、スーパーバイザーは混乱させられたりジェイルブレイクされたりしうる別のLLMではなく、決定論的なポリシーエンジンです。すべてのエージェントは、形式的に規定されたエンベロープの内側で動作します——定義された入出力スキーマ、許可されたツールアクセス、トークン予算、API呼び出しのクォータ、実行時間の上限です。スーパーバイザーは、あらゆるエージェントのアクションが効力を持つ前に、これらの制約に照らして検証します。これは「ガードレールを追加する」ことではありません——協調層において安全でない振る舞いをアーキテクチャ的に不可能にすることであり、その手法を詳しく解説したのが LLMラッパーを越えた真実のアーキテクチャに関する私たちのリサーチです。

フレームワークだけでは目的地に到達できない理由

2026年のマルチエージェントフレームワークの状況は、破られた約束の地雷原であり、その差異は表面的なものではありません——動作するシステムと、静かに失敗したり過剰にコストを費やしたりするシステムとの違いです。

最も本番運用に耐えうる選択肢であるLangGraphでさえ、鋭い落とし穴を抱えています。デフォルトの ToolNode はグラフ状態の読み書きを必要とするツールを扱えず、暴走する自己修正サイクルを防ぐために手動のループカウンターを必要とし、そのチェックポインター実装は大規模での並行ブランチ解決に苦しみます。これらは解決可能な問題ですが、フレームワークのREADMEではカバーされない類のエンジニアリングを要します。

私たちは、レイテンシ予算、エージェント数、ツールの複雑さ、コンプライアンス要件といった、お客様の実際の要件に照らしてフレームワークを評価します——そのうえで、どのフレームワークも標準では提供しないスーパーバイザー制御、コストガバナンス、可観測性を提供する、フレームワークの上位に位置するオーケストレーション層を構築します——そのレジリエントなオーケストレーション層を解説したのが、こちらの レジリエントなエンタープライズAIのアーキテクチャに関する私たちのホワイトペーパーです。

スーパーバイザーが実際に行うこと

私たちが選ぶパターンは、エッジでLLM推論を用いる決定論的オーケストレーションです。LLMは判断を担います——意図の解釈、構造化パラメータの抽出、どの専門エージェントを呼び出すかの決定です。ステートマシンはフローを担います——ルーティング、シーケンス制御、並列ファンアウト、コンセンサス集約、エラー回復です。Pydanticによる検証が、エージェント間のあらゆるハンドオフを型付きでスキーマ強制されたペイロードに取り込むため、エージェント間に自由形式のテキストが渡ることはありません——これにより、チャットベースのエージェントアーキテクチャを苦しめるプロンプトインジェクションの経路と意味的ドリフトが排除されます。

スーパーバイザーは、4種類の制御を強制するよう設計されています:

• エージェントごとのリソース予算 ——トークン上限、API呼び出しのクォータ、実時間タイムアウト。
• エージェントごとのツールアクセス制限 ——ファイルシステムのディレクトリ、ネットワークエンドポイント、データベースのスコープ。
• アクション承認ゲート 外部システムに影響を与える書き込み操作に対する。
• コストサーキットブレーカー 支出のしきい値を超えると実行を停止する。

統制されたシステムの推奨SLO:成功率95%超、ハンドオフのレイテンシ30秒未満、ツール呼び出しの忠実度80%超。

文書化された惨事を、防止可能に

これらの制御は、よく知られた大惨事を数分で捕捉できる事象へと変えるよう設計されています——同じ決定論的な安全アプローチが機能しているのが、こちらです 私たちの決定論的な安全制御の実動デモ:

• あの $47,000のAPI請求 は、11日間続いた再帰的なエージェントループによるもので——トークン支出の上限と意味的ループ検出(連続する出力間の95%類似度しきい値)によって、数日ではなく数分で捕捉されます。
• あの 月$60,000のオートスケーリング事故 は、エージェントがノードを12から500へと跳ね上がらせたもので——スケーリングコマンドの実行前にスーパーバイザーの承認を要求するインフラアクションゲートによって停止されます。
• Amazonの 630万件の失われた注文 は、エージェントが古いwikiのガイダンスに従ったことによるもので——スーパーバイザーのアクション前チェックにおけるソース鮮度検証とナレッジカットオフの強制によって防止されます。

エージェントの境界を越えて失敗を追跡する可観測性

マルチエージェントシステムで最も難しいデバッグ問題は、失敗がグラフ状であることです。エージェントAのツール呼び出しでの幻覚がエージェントBの入力コンテキストとなり、それがエージェントCの自信満々だが誤った出力となります。従来のモニタリングはエージェントCの失敗を見ても、根本原因が2ホップ上流にあることに気づきません。私たちは、エージェント間の相互作用を、各ノードで完全な来歴を持つ有向非巡回グラフとして可視化する可観測性を設計します。あらゆるエージェント間メッセージ、ツール呼び出し、状態遷移、スーパーバイザーの判断は因果的な連鎖とともにログ化されるため、何かが壊れたときには症状から発生源となったエージェントのアクションへと、数時間ではなく数秒で遡って追跡できます。

私たちはお客様のスタックに応じてLangfuse、LangSmith、またはArizeと統合し、これらのプラットフォームがネイティブには捕捉しない指標のためにカスタム計装を重ねます:

• エージェント横断のトークン帰属 ——どのエージェントが予算を燃やしているか。
• 協調オーバーヘッド比率 ——支出のうち、どれだけがエージェント同士の対話で、どれだけが実際の作業かの割合。
• スーパーバイザー介入頻度 ——決定論的な層がエージェントの振る舞いをどれだけ頻繁に上書きするか。

プロトコルスタック:MCP、A2A、そしてその間に位置するもの

AnthropicのModel Context Protocol(2026年3月時点で9,700万インストール、現在はLinux Foundation傘下)は、エージェントが外部ツールに接続する方法を標準化します。GoogleのAgent2Agentプロトコルは、50社以上の業界パートナーとともにベンダー横断のエージェント協調を扱います。AWS Bedrockは、階層的なスーパーバイザールーティングを備えたマネージド型のマルチエージェントホスティングを提供します。これらは実在する能力であり、ベーパーウェアではありません。

しかし、そのいずれもガバナンス層を提供しません。MCPはツールアクセスを定義しますが、エージェントごとのツール認可は定義しません。A2Aはベンダー横断のメッセージングを定義しますが、コスト予算管理やアクション承認は定義しません。Bedrockのスーパーバイザーはタスクをルーティングしますが、エージェントの振る舞いに決定論的な制約を強制しません。「エージェントがツールや互いに対話できる」ことと「エージェントが統制され、監査可能で、コスト管理されたオーケストレーションの下で動作する」ことの間のギャップこそ、私たちのカスタムエンジニアリングが存在する場所であり、その深いシステムの取り組みを解説したのが、こちらです ラッパーから深いAIシステムへ、GenAIの隔たりを越えることに関する私たちのリサーチ。

マルチエージェントが誤ったアーキテクチャである場合

単一のエージェントでワークロードを処理できるのであれば、私たちはマルチエージェントシステムを構築しないよう助言します。Microsoft自身のガイダンスは直截的です:「デフォルトは単一エージェント。追加の複雑さが相応の価値をもたらすという証拠がある場合にのみ、マルチエージェントアーキテクチャを導入せよ」。単一エージェントはエージェント間のオーバーヘッドがない分30〜50%速く応答し、マルチエージェントシステムは単一エージェントのソリューションよりも8〜14か月遅れてROIの損益分岐点に達します。

単一のよく作り込まれたエージェントの方が優れた投資となるのは、次の場合です:

• タスクが単一の論理的パスで解決する。
• 処理量が1日あたり10,000オペレーション未満で、予測可能な成長である。
• 明確なエラー分離を伴う、シンプルな監査証跡が必要である。

マルチエージェントがその複雑さに見合うのは、異なるツールアクセス、異なるモデル選択、または異なるレイテンシ予算を必要とする、真に別個の能力がある場合、独立したサブタスク間で並列実行が必要な場合、あるいは狭く十分にテストされたスキルセットを持つ専門エージェントが、肥大化したプロンプトを持つ単一エージェントを上回る場合です。技術の選択よりも意思決定のフレームワークが重要であり、私たちはオーケストレーションのコードを書く前にそれを適用します。

私たちが提供するもの

エンゲージメントは、次を生み出すようスコープされます:

• ​ フレームワーク評価 お客様固有の要件に照らした——汎用的な比較チャートではなく。
• ​ スーパーバイザーアーキテクチャ コンプライアンスチームがレビューできる決定論的なポリシー仕様を伴う。
• エージェントごとのサンドボックス化 ツールアクセス制御とリソース予算を伴う。
• コストガバナンス トークン支出の上限とサーキットブレーカーを伴う。
• 可観測性の計装 エージェント横断の因果トレースを伴う。
• ​ シミュレーション環境 フォールト注入によるマルチエージェントワークフローのテスト用。
• 運用ランブック 本番で文書化された失敗シナリオ用:エージェントのタイムアウト連鎖、出力の衝突、リソース枯渇、スーパーバイザーのポリシー違反、そしてフレームワークが文書化しない協調のデッドロック。

マルチエージェントシステムを社内で構築するには6〜18か月と、本番グレードのオーケストレーション層を得るまでにおよそ$500,000のシニアエンジニアリングの人件費がかかります。私たちのアプローチはそれを数週間のアーキテクチャと構築へと圧縮し、上でカタログ化したフレームワークの失敗モードを、お客様の負担で再発見するのではなく活用します。