Meta の AI エージェントの信頼性を高める「薄いオーケストレーター」パターン

Meta のエンジニアは、ルーティングロジックとドメイン推論を分離する「薄いオーケストレーター」アーキテクチャを採用することで、本番環境の AI エージェントの信頼性を向上させました。2026 年 10 月 19 日に公開されたこのケーススタディでは、1,300 行の決定論的ルーターが現在 14 の専門エージェントにまたがる 20 以上のワークフローを管理し、コンテキスト過多によるエラーを大幅に削減していることが詳細に述べられています。

何が起きたか

Meta が初めてレコメンデーションシステム向けにデータカラムのオンボーディングを自動化しようとした際、チームは包括的なドメイン知識を読み込んだ単一の AI エージェントを構築しました。このエージェントは、3 つのコードリポジトリ、3 つのプログラミング言語、そして最大 6 つのパイプラインステージを処理する必要がありました。制御されたデモではうまくいきましたが、頻繁なハルシネーションにより本番環境では失敗しました。エージェントは概念を混同し、あるサブシステムの命名規則やコード生成パターンを別のサブシステムに誤って適用していました。

エンジニアリングチームは、コンテキストを追加することがパフォーマンスを向上させるのではなく、むしろ劣化させていることに気づきました。彼らは、タスクごとに手動のプロンプトエンジニアリングが必要となる代替案の単一エージェントアプローチを評価しましたが、人間の介入が多い場合でも成功率は 70〜80% に留まり、介入なしでは 10〜20% まで低下しました。Mount Sinai の Windreich Department of Artificial Intelligence and Human Health の研究を引用し、マルチエージェントシステムはタスクを隔離することでより高い精度を維持できる一方、単一エージェントはコンテキスト干渉に苦しむ傾向があることを指摘しました。

これを解決するために、Meta はシステムを 2 つの明確なレイヤーに分割しました。第 1 レイヤーは、意図分類、フィールド収集、信頼性チェックを担当する決定論的オーケストレーターであり、ドメイン業務は一切行いません。第 2 レイヤーは、それぞれが隔離されたコンテキストを持つ完全なドメイン専門家として機能する 14 の専門サブエージェントで構成されています。例えば、あるエージェントはスキーマ設定を管理し、別のエージェントは特定のデータソースに対するコード生成を担当します。どの単一エージェントも全体像を見ることはなく、これにより初期のモノリシック設計を悩ませていた概念の混同を防いでいます。

仕組み

薄いオーケストレーターは、すべてのリクエストに対して固定の 7 ステッププロトコルに従い、大規模言語モデル（LLM）の推論が必要な場合にのみ使用されるようにしています。ステップ 1〜5 およびステップ 7 は決定論的です。ルーターは指示ファイルを読み込み、重複を確認し、ユーザーフィールドを収集し、リポジトリタイプを自動検出し、信頼性ゲートを実行します。LLM 推論が発生するのは、タスクをサブエージェントに委任するステップ 6 のみであり、ここでは特定のドメイン知識が読み込まれた隔離されたコンテキスト内で推論が行われます。

このアーキテクチャは、操作シーケンスを定義する決定論的なステートマシンであるワークフローテンプレートに依存しています。「Column Onboarding」や「Pipeline Migration」といったテンプレートは、同じ 14 サブエージェントプールを異なる順序で再利用します。この分離により、チームは新しいエージェントを構築するのではなく、新しいワークフローテンプレートを作成することで新機能を追加できます。各サブエージェントは、定義された知識ソース、事前収集チェックリスト、エラーハンドリングプロトコルを含む標準化された構造に従うため、システムはモジュール化され、拡張が容易になります。

知識ファイルは、オーケストレーターに埋め込むのではなく、実行時にオンデマンドで読み込まれます。つまり、知識ファイルが更新されると、次のセッションではオーケストレーターのコードを変更することなく自動的に最新バージョンが使用されます。現在、システムはワークフロードメイン別に整理された 25 以上の知識ファイルを維持しており、プラットフォーム実装全体で更新が即座に反映されます。

主要な詳細

• オーケストレーターは、自身では一切ドメイン業務を行わない 1,300 行の決定論的ルーターです。
• システムは、それぞれが隔離されたコンテキストを持つ 14 の専門 AI エージェントに 20 以上のワークフローをルーティングします。
• 新しいデータカラムの設定準備時間は、手動での 3〜4 日から 1 時間未満に短縮されました。
• システム変更の約 3 分の 2 は、顕著な人手による編集なしで反映されます。
• ワークフローテンプレートにより、既存のエージェントの順序付けを変えるだけで新しいユースケースをサポートできます。
• 引用された研究によると、80 タスクのバッチにおいて、マルチエージェントシステムは 65.3% の精度を維持した一方、単一エージェントは 16.6% でした。

なぜ重要なのか

本番環境の AI システムを構築するソフトウェアエンジニアにとって、このパターンは単一のエージェントに過剰なコンテキストを読み込ませることのリスクを浮き彫りにします。コンテキストウィンドウが拡大するにつれ、利用可能なすべての知識を 1 つのプロンプトに詰め込みたくなりますが、これはしばしばパフォーマンスの低下とハルシネーションにつながります。決定論的ルーティングと確率的推論の間に明確な境界線を引くことで、チームはデバッグが容易で、スケーラブルな信頼性の高いシステムを作成できます。障害は特定のサブエージェント内に封じ込められ、単一のエラーがワークフロー全体を損なうのを防ぎます。

このアプローチは、チームのメンテナンスとアップデートの管理方法も変えます。知識は実行時に読み込まれ、エージェントは構造的に均一であるため、新機能の追加は大きなアーキテクチャの再構築ではなく、テンプレート化されたタスクとなります。このモジュール性により、システムの異なる部分が独立して改善できます。基盤となるモデルの改善はすべてのサブエージェントに同時に恩恵をもたらし、知識の更新はコアオーケストレーターの再デプロイなしで即座に有効になります。

実践できること

• オーケストレーターが意図分類などの決定論的判断のみを行うようにし、ルーティングと推論を分離してください。
• サブエージェントを一貫した入力、実行ステップ、エラーハンドリングを持つ構造的に均一な専門家として設計してください。
• 新しいエージェントを一から構築するのではなく、ワークフローテンプレートを使用して既存のエージェントを順序付け、新しいユースケースに対応してください。
• ドメイン知識をオーケストレーターに埋め込むのではなく、実行時に読み込み、即時の更新を可能にしてください。
• アーキテクチャにおいて、決定論的ルーティングタスクと確率的推論タスクの境界を明示的に定義してください。
• 各サブエージェントのコンテキストを隔離し、異なるドメインからの概念の混同を防いでください。