Meta、ルーターを「薄く」してAIエージェントの精度を改善 14の専門エージェントに委譲

発表された仕組み

Metaのエンジニアリングブログは2026年10月19日、データパイプライン向けAIエージェントの構成を刷新したと報告した。中心となるのは「シン・オーケストレーター(薄いオーケストレーター)」と呼ぶ設計で、ルーティング役のオーケストレーターがドメイン固有の作業を一切行わない点が特徴である。1,300行のオーケストレーターが、20以上のワークフローを14の専門エージェントに振り分ける。

対象となったのは、推薦システム向けにデータカラムをオンボーディングする作業だ。3つのコードリポジトリ、3つのプログラミング言語、最大6つのパイプラインステージにまたがり、設定レジストリ・バックエンドサービス・データパイプラインを同期させる必要がある。当初はこの知識を1つの賢いエージェントに集約する、多くのチームが採る構成をとっていた。

単一エージェントが破綻した理由

単一エージェントはデモでは動作したが、本番環境でハルシネーションを起こし始めた。あるコンテキスト量のしきい値を超えると、知識の追加は性能を改善するどころか悪化させた。エージェントはあるサブシステムのフィールド命名規則を別のサブシステムに適用したり、別のデータソース向けのコード生成パターンを使ったりと、概念を混線させた。

原文はこの現象を裏づける研究として、Mount SinaiのWindreich Department of Artificial Intelligence and Human Healthのプレプリントを引いている。オーケストレーションされたマルチエージェント構成が80タスクのバッチで65.3%の精度を保ったのに対し、単一エージェントは16.6%まで低下し、トークン使用量も最大65分の1に減ったという内容である。

別案として検討した単一エージェント構成では、タスクごとに手作業でプロンプトを設計すれば成功率70〜80%だったが、その調整なしでは10〜20%に落ちた。原文はこれをプロンプトエンジニアリングの問題ではなく、アーキテクチャの問題と位置づけている。

7ステップと14の専門家

オーケストレーターは全リクエストに対して固定の7ステップ手順を踏む。サブエージェントの指示ファイルを読み、対象の重複を確認し、ユーザーから必要項目を集め、推測できる項目を自動検出し、警告やレビュアーを確認する信頼性ゲートを通し、文脈を渡してサブエージェントに委譲し、結果を処理する。

このうちLLMの推論が入るのは委譲のステップだけで、残りは決定論的に処理される。14のサブエージェントはそれぞれ独立したコンテキストを持ち、スキーマ管理、10のデータソース向けコード生成、検証といった領域を分担する。システム全体を見渡すエージェントは存在しない設計だ。

機能追加はワークフローテンプレートで行う。カラムオンボーディング、イベントオンボーディング、パイプライン移行というテンプレートは、同じ14のサブエージェントを異なる順序で並べたものだ。パイプライン移行という新しいユースケースは、新しいエージェントを書かずにテンプレートの追加だけで実現した。知識ファイルは25以上あり、実行時に読み込まれるため、更新してもオーケストレーター側の変更は不要だという。

成果と位置づけ

新規カラムの設定準備にかかる時間は、手作業で3〜4日、以前の構成駆動型システムで約1日だったものが、シン・オーケストレーターでは1時間未満になった。変更の約3分の2は、大きな人手修正なしで反映されるという。

原文はこの設計の利点を3点に整理している。決定論的に決められる判断をLLMに任せないこと、コンテキストを分離して混線を防ぐこと、失敗をサブエージェント内に閉じ込めることである。モデルが良くなれば14のサブエージェントすべてが同時に改善し、知識ファイルの更新は即座に反映される。

現時点の留意点

数値はMeta社内のデータパイプラインにおける結果であり、他社の環境で同じ効果が得られるかは原文に示されていない。14のサブエージェントがどのモデルで動いているか、ベンダーやバージョンの記載もない。

今後の取り組みとしては、新しいパイプラインドメインへの拡大と、本番利用のデータから自動フィードバックループで改善案を出す仕組みの検討が挙げられている。後者は必ず人間のレビューを経由するとされており、現時点では探索段階とみられる。