マルチエージェント・パイプラインの廃止を決定した理由 | ZS アソシエーツ

マルチエージェント・パイプラインが失敗した理由：ZS アソシエーツが教える AI 設計の教訓

医薬品業界の分析業務を AI で自動化しようとした際、複数のエージェントを連携させる「マルチエージェント・パイプライン」は文脈の断絶や推論の不整合により機能不全に陥りました。ZS アソシエーツはこの失敗から学び、決定論的プロセスの分離と単一エージェントによる統制、そして知識グラフを制御プレーンとして活用する新たな設計へとシステムを再構築しました。

分析業務の自動化における「マルチエージェント」の罠

ZS アソシエーツは医薬品メーカー向けに商業分析サービスを提供しており、アナリストの業務プロセスを AI エージェントで模倣しようと試みました。典型的な分析フローは以下の4段階です。

1. 信号検出: 処方箋数の急落など、異常なデータ（シグナル）を検知する。
2. 原因特定: なぜその信号が起きたのか、競合の参入や保険適用範囲の変更などを突き止める。
3. アクション策定: 原因に基づき、営業担当の配置変更などの具体的な対策を提案する。
4. 展望予測: その対策を実行した場合、将来の販売成績がどうなるかを予測する。

当初、私たちはこの各ステップごとに専用のエージェント（信号検出用、ソース特定用、ドライバー帰属分析用、合成用）を用意し、オーケストレーターがそれらを繋ぐマルチエージェント構成を採用しました。システムは確かに「処方箋数が18%減少した」「保険の適用階級が下がったため患者負担が増えた」といった事実を出力します。

しかし、よく見ると重大な矛盾が生じていました。原因分析では「保険の問題」を特定しながらも、提案されるアクションは「営業担当を増やせ」というものであり、展望予測もその間違った前提に基づいて算出されていました。

「各レベルで事実が導き出されていても、全体像を理解し責任を持つエージェントが存在しないため、推論の整合性が保てなかったのです」

この失敗は、LLM（大規模言語モデル）自体の性能不足ではなく、「仕事を分割する仕組み」に根本的な欠陥があったことが原因です。

解決策1：決定論的プロセスをエージェント外へ分離

最初の課題は、「信号検出」のような定型的なデータ処理を LLM に任せていた点でした。LLM は確率的に動作するため、単純な統計処理においてノイズを検知したり、単なる変動を異常と誤認したりするリスクがありました。

私たちはこれを解決するために、決定論的（Deterministic）なワークフローへ移行しました。信号検出は LLM の領域から外し、統計手法を用いた自動化パイプラインで処理します。ここで閾値や優先順位を設定し、確実な異常のみをキューに投入します。

「エージェントの役割は『信号を見つけること』ではなく、『見つかった信号の原因を調査すること』に限定すべきです」

これにより、LLM が不要なノイズに振り回されることを防ぎ、信頼性の高い入力だけを分析プロセスへ送り込むことができました。

解決策2：単一主要エージェントによる統制と動的サブエージェント

二つ目の課題は、複数のエージェント間で文脈（コンテキスト）が失われる「手渡し」の問題でした。原因を特定するエージェントの判断が、次のアクション策定エージェントに正しく伝わらないため、整合性の取れない回答が生成されていました。

この問題を解決するため、私たちは全責任を持つ単一の主要エージェント（Main Agent）を採用しました。主要エージェントは推論と意思決定を一貫して行い、必要に応じて特定の調査タスク（例：特定地域の営業活動分析）のみをサブエージェントに動的に委託します。

重要なのは、サブエージェントから得られるのは「結果」であり、「判断や推論の権限」ではない点です。主要エージェントが全体の文脈を保持し、サブエージェントからの情報を統合して最終的な結論を導き出します。このアーキテクチャにより、分散した推論による不整合を解消しつつ、並列処理による効率性も維持しています。

解決策3：知識グラフを「制御プレーン」として活用

最後の課題は、ドメイン（医薬品商業分析）特有の複雑な関係性を AI が理解できていなかった点です。エージェントがデータテーブルから無理やり関係を推測しようとすると、存在しない相関関係を発見したり、スケーラビリティに欠けたりしました。

そこで、長年の業界経験とドメインエキスパートの知見を元に構築した知識グラフ（Knowledge Graph）を導入しました。これは単なる参照データベースではなく、エージェントが取るべき経路や仮説を検証するための「制御プレーン」として機能します。

例えば、「処方箋数（TRX）の全国規模での減少」という問題に対し、知識グラフは以下のような探索パスを定義します。

• 地理的な領域に集中していないか？
• 特定の保険者（ペイヤー）や顧客アカウントに偏っていないか？
• KPI の二次・三次の指標との関連性はどうか？

「知識グラフは、エージェントがどこを調べ、どのような仮説を検証すべきかを厳密に定義する羅針盤となります」

これにより、無秩序な探索を防ぎ、ドメインの論理構造に沿った効率的で正確な分析が可能になりました。

まとめ：AI エージェント実装における設計原則

ZS アソシエーツの事例は、複雑なビジネスドメインにおいて「マルチエージェント＝高性能」という単純な考え方が通用しないことを示しています。成功のカギは、決定論的プロセスを分離し、推論の責任を単一のエージェントに集中させ、ドメイン知識を構造化して制御プレーンとして機能させることにあります。

企業レベルでの AI 導入においては、推論の整合性とスケーラビリティを確保するために、この3つの要素が不可欠な戦略となります。