2026年10月19日、Metaのエンジニアリングチームは公式エンジニアリングブログで、データパイプライン向けエージェントのアーキテクチャ刷新を振り返った。司令塔層は約1300行のコードからなるシン・オーケストレータ（薄い編成層）となり、ルーティングと信頼性チェックだけを担い、ドメイン推論は一切行わない。20を超えるワークフローは、文脈が互いに隔離された14の専門サブエージェントへ振り分けられる。刷新後、新しいデータ列の設定準備は手作業の3〜4日、旧システムの約1日から、1時間以内に短縮された。
万能の司令塔が先に失敗した理由
Metaの出発点は多くのチームと同じで、設定スキーマ、コード生成規則、検証要件、10を超えるデータソースの投入パターンを1つの文脈に全て詰め込んだ単一エージェントだった。デモでは動いたが、本番では幻覚を起こし始めた。文脈がある閾値を超えると、知識を足すほど性能が落ち、異なるサブシステムの命名規則や生成パターンが互いに混ざり合った。チームの測定では、エンジニアがタスクごとに専用のプロンプトを手作りした場合の成功率は70〜80%で、手助けがなければ10〜20%まで落ちた。引用されたプレプリント研究でも同じ構図が見られ、編成されたマルチエージェント方式は80タスクのバッチで65.3%の正確さを維持したのに対し、単一エージェントは16.6%まで低下し、トークン使用量は最大で65分の1に抑えられた。
7ステップのうち大規模モデルを使うのは1つだけ
シン・オーケストレータは全リクエストに固定の7ステップを実行する。対応するサブエージェントの指示ファイルを読む、対象が既に存在するか確認する、ユーザーから必須項目を集める、推測できる情報を自動で発見する、信頼性ゲートを通す、完全な文脈とともにサブエージェントへ委譲する、結果とエラーを処理する、という流れだ。1〜5番目と7番目は決定的な処理であり、大規模モデルの推論が関わるのは6番目だけ、それも自領域の知識だけを読み込んだ隔離されたサブエージェントの中で起きる。各サブエージェントの構造は統一されており、知識ソース、事前収集チェックリスト、実行手順、コード探索のパターン、障害対応表を持つ。25を超える知識ファイルは必要時に読み込まれるため、更新は次のセッションから自動で反映され、オーケストレータの変更は要らない。サブエージェントが失敗しても、オーケストレータが再試行や上位へのエスカレーションを行い、失敗が他のサブエージェントの文脈を汚すことはない。
新しい場面は新規エージェントではなくテンプレートで足す
列のオンボーディング、イベントのオンボーディング、パイプライン移行という3つのワークフローは、同じ14のサブエージェントを異なる順序で使い回す。パイプライン移行は後から加わった全く新しい用途だったが、チームは新しいエージェントのコードを書かず、既存のエージェントを並べ替えるワークフローテンプレートを1つ書くだけで本番能力を実現した。現在、変更の約3分の2は大きな人手修正なしに反映されている。Metaの同業者への助言は明快だ。ルーティングは決定的な判断であり、大規模モデルに任せてはいけない。ドメイン推論は全て隔離された専門エージェントへ落とすべきだ。これは本サイトが以前報じた Anthropicがエージェントのルールを弁護士に相談した件 と同じ方向を向いている。エージェントが本番で通用するかどうかは、単一モデルの賢さではなく、境界とルールを先に定めたかで決まる。
