AIエージェントが幻覚を起こす原因はプロンプトではなく設計だった — Metaの「薄いオーケストレーター」パターン解説

なぜ「全部知っているエージェント」は本番で壊れるのか

AIエージェントを実務に組み込むと、誰もが同じ罠にはまります。「賢いエージェントを1つ作って、全ドメイン知識を詰め込もう」と。デモでは動きます。しかし本番に出すと幻覚（ハルシネーション）が発生し始めるのです。

Metaのデータパイプライン・チームも同じ道を辿りました。レコメンドシステムのデータカラム・オンボーディング自動化のため、3つのリポジトリ・3つの言語・最大6ステージのパイプラインを跨ぐ単一エージェントを構築しました。結果は惨憺たるものでした。あるサブシステムのフィールド命名規則を別のサブシステムに適用したり、あるデータソース向けのコード生成パターンを別のソースに使ったりする「コンテキスト汚染」が発生したのです。

原因はプロンプトではなく、アーキテクチャでした。コンテキストの閾値を超えると、知識を追加するほど性能がむしろ劣化します。実際、Mount Sinaiの研究によれば、タスクを隔離したマルチエージェント構成は80タスクのバッチで65.3%の精度を維持したのに対し、単一エージェントは16.6%まで低下しました。トークン使用量も最大65分の1に削減されています。

ここから得られる教訓は明確です。「エージェントに仕事をさせすぎるな」。本記事では、Metaが実際に適用した「薄いオーケストレーター（Thin Orchestrator）」パターンを解説します。根拠資料はMeta Engineeringブログで確認できます。

構成：決定論的ルーター + 14名の専門家

Metaのシステムの核心は2層分離です。

1) オーケストレーター：ドメイン作業を「ゼロ」に

1,300行のオーケストレーターは、20以上のワークフローを14の専門エージェントにルーティングします。このコンポーネントはコードを推論せず、設定を生成せず、コードベースに触れません。ただのルーターです。

すべてのリクエストに対して固定の7ステップ・プロトコルを踏みます。

1. 対象サブエージェントの指示ファイルを読む
2. ターゲットの存在確認（重複防止）
3. ユーザーから必須フィールドを収集
4. 推論可能な値の自動探索（リポジトリ種別、既存設定）
5. 信頼性ゲート・チェック（アクティブ警告、必須レビュアー）
6. サブエージェントに完全なコンテキストで委譲
7. 結果処理・エラー表面化、成功確認

ステップ1〜5と7は決定論的です。LLM推論はステップ6でのみ、しかも隔離されたサブエージェント内でのみ発生します。ここがポイントです。

2) サブエージェント：隔離されたドメイン専門家14名

各サブエージェントは完全なドメイン専門家であり、自分のコンテキストだけを見ます。スキーマ管理エージェントは設定レジストリを知り、ポピュレーション・エージェントは10のデータソースごとのコード生成法を知り、検証エージェントはビルドシステムと品質チェックを知っています。**誰も全体像を見ません。**これはバグではなく機能です。

ワークフロー・テンプレート：新エージェントではなく新順序

ここに真のアーキテクチャ・インサイトがあります。「何をすべきか」と「各ステップをどう実行するか」を分離したのです。オーケストレーターはワークフロー・テンプレートでフェーズ順序を定義します。

カラム・オンボーディング:     Schema → Validation → Population → Testing
イベント・オンボーディング:   Schema → Population → Validation → Testing → Event Processing
パイプライン移行:             Assessment → Planning → Population → Validation → Monitoring

各テンプレートは同じ14サブエージェントのプールを異なる順序で再利用します。パイプライン移行という全く新しいユースケースが必要になったとき、Metaは新エージェントを作りませんでした。既存エージェントを別順序で並べた新ワークフロー・テンプレートを書いただけです。新規エージェントコード0行、本番機能はフルスペックです。

サブエージェントの標準構造

15番目のサブエージェントは1番目と構造的に同一です。これが拡張性の鍵です。

- Knowledge sources: 実行時にロードするドメインファイル（通常数千トークン）
- Pre-gathering checklist: 委譲前にオーケストレーターが収集する項目
- Step-by-step workflow: ドメイン固有の実行計画
- Discovery patterns: モノレポで関連コードパターンを見つける方法
- Troubleshooting: よくある失敗へのエラー→解決マッピング

知識ファイルはビルド時ではなく実行時にオンデマンドでロードされます。25以上の知識ファイルをワークフロー・ドメイン別に管理し、ファイルが更新されれば次のセッションで自動的に最新版が使われます。オーケストレーターに手を入れる必要はありません。

結果と注意点

定量的な成果

なぜ機能するのか

薄いオーケストレーターが機能する理由は、アーキテクチャ境界と計算境界を一致させるからです。

• 決定論的判断は決定論的に保つ:「どのサブエージェントがこれを処理するか」はルーティング判断であり、推論タスクではありません。ここにLLMを使わないでください。
• コンテキスト隔離: データソースAのポピュレーション・エージェントはソースBのパターンを絶対に見ません。誤ったものを幻覚しようがありません。
• 失敗の封じ込め: サブエージェントが失敗すれば、オーケストレーターがリトライまたはエスカレーションします。失敗がオーケストレーターの状態や他サブエージェントのコンテキストを汚染しません。
• レイヤーごとの独立改善: より良いモデルは14サブエージェントを同時に改善します。知識ファイル更新は即座に反映されます。

⚠️ 注意点（批判的視点）

このパターンは万能ではありません。以下の状況では再検討が必要です。

• ワークフローが単純な場合: 単一エージェントで十分なタスクに14サブエージェントを置くのは過剰設計です。オーケストレーションのオーバーヘッドが増えるだけです。
• ドメイン境界が流動的な場合: サブエージェント間の知識共有が頻繁に必要なタスクでは、隔離がボトルネックになります。
• 決定論的ルーティング規則の維持コスト: ルーティング・ロジックが複雑化すれば、それ自体が保守負担になります。ワークフロー・テンプレートが過多になると管理が困難です。

次のステップ学習方向

• エージェント・オーケストレーション・フレームワーク比較: LangGraph、CrewAI、AutoGenなどがこのパターンをどう実装しているか確認しましょう。
• 決定論的ルーティング設計: LLMなしで意図分類器を作る方法（埋め込みベースのクラスタリング、ルールエンジン）を学びましょう。
• 評価（Eval）パイプライン: サブエージェントごとの精度を測定する評価体系なしにこのアーキテクチャは運用できません。次の学習優先度として強く推奨します。

実務適用ガイドとまとめ

Metaの事例からすぐに持ち帰れる原則5つを整理します。

1. ルーティングと推論を分離する。 オーケストレーターがドメイン判断をしているなら、それは仕事をしすぎています。ルーティングはキーワードマッチング・意図分類・フィールド収集など決定論的に処理し、すべてのドメイン推論は隔離されたサブエージェントに押し込みましょう。
2. サブエージェントは構造的に均一に設計する。 知識ソース・必須入力・実行ステップ・エラー処理をすべて同一構造に揃えれば、新機能追加はアーキテクチャ変更ではなくテンプレート作業になります。
3. 拡張は新エージェントではなくワークフロー・テンプレートで。 新ユースケースが出たらまず問いましょう。「既存エージェントを別順序で並べられないか?」再利用できなければ、エージェントがユースケースに過度に結合しています。
4. 知識はビルド時ではなく実行時にロードする。 オーケストレーターに知識を埋め込むと、すべての更新に再デプロイが必要です。
5. 決定論／確率の境界を明示的に引く。 すべてのコンポーネントについて「これはルーティング判断か、推論タスクか?」を問いましょう。オーケストレーターは一方、サブエージェントは他方に置くべきです。混ぜないでください。

最も強力な論拠は代替案の失敗モードです。重いオーケストレーターが幻覚を起こせば、エラーは下流全体に波及します。誤ったエージェントにルーティングし、誤ったフィールドを集め、信頼性チェックを飛ばすのです。薄いオーケストレーターはルーティングと信頼性ステップがLLM推論に依存しないため、幻覚の余地がほとんどありません。創造性は下流、すなわち隔離されたドメインスコープのコンテキストで発揮されます。

あわせて読みたい

• 複雑な広告メディアプランをマルチエージェント・アーキテクチャで攻略する — マルチエージェントを実務ドメインに適用した別事例
• 90日かかったインフラ構築を数時間に短縮したSantanderのプラットフォームエンジニアリング戦略 — プラットフォームエンジニアリング視点の自動化戦略