AIエージェント「デモ→本番」95%脱落 × 4つの壁とエージェンティックRAG実践

Femke Plantinga さんが、AIエージェントのデモと本番環境のギャップについて、Stack AI・Weaviate と共同作成した無料ガイドを公開しています。

95% of AI agent demos never make it to production. Yet 79% of enterprises expect full-scale agentic AI adoption within three years. So what’s the disconnect?

https://x.com/femke_plantinga/status/2029134837890621844

48 いいね・8 RT を集めたこのポストが指摘するのは、AIエージェントの「デモでは動く」と「本番で使える」の間にある巨大なギャップです。MIT の調査（GenAI Divide: State of AI in Business 2025）でも、エンタープライズ向け生成AIシステムのうち本番環境に到達するのは**わずか5%**という数字が報告されています。

95%が脱落する現実

複数の調査が、AIエージェントのデモ→本番の落差を裏付けています。

調査・出典数字
MIT GenAI Divide 2025本番到達は全体の 5%
企業調査（探索中 30%、パイロット 38%、デプロイ準備 14%、本番稼働 11%）パイロットから先に進めない
Gartner 予測2027年までにエージェンティックAIプロジェクトの 40%以上が中止
AI施策全般90〜95%が持続的な本番価値を提供できず、ROI達成は 12%未満

問題はモデルの性能ではなく、自律システムを運用するエンジニアリング規律の欠如です。

デモと本番の決定的な違い

デモ環境:                         本番環境:
┌──────────────┐                ┌──────────────────────────┐
│ 固定データ    │                │ 日々変化するデータ          │
│ 1ユーザー     │                │ 数千の同時ユーザー          │
│ 想定内の質問  │                │ 悪意ある入力・エッジケース    │
│ エラー=再試行 │                │ エラー=データ損失・信頼失墜   │
│ コスト無視    │                │ トークンコスト=事業KPI       │
└──────────────┘                └──────────────────────────┘

壁1: セキュリティとガバナンス

AIエージェントが本番環境で最初に直面する壁が、データ漏洩とアクセス制御です。

なぜエージェントはデータを漏洩するのか

デモ環境では「全てのデータにアクセスできるエージェント」で問題ありません。しかし本番では:

  • 部門Aのエージェントが部門Bの機密データを参照してしまう
  • 顧客対応エージェントが社内の原価情報を回答に含めてしまう
  • エージェントのログにPII（個人識別情報）が記録されてしまう

必要な対策

対策内容
マルチテナンシー分離ベクトルDB レベルでテナントごとにデータを分離
RBAC（ロールベースアクセス制御）エージェントごとにアクセス可能なデータソースを制限
PII検出・マスキング出力前に個人情報を自動検出・除去
監査ログ全てのデータアクセスを記録し、追跡可能にする

Weaviate のようなベクトルデータベースは、マルチテナンシー分離をインフラレベルで提供しており、エージェントが「見てはいけないデータ」に物理的にアクセスできない構造を作れます。

壁2: 検索品質（RAG の実装品質）

RAG（Retrieval-Augmented Generation）の実装品質が低いと、エージェントはハルシネーション（幻覚）を起こします。

ハルシネーション率の現実

適切な対策なしの RAG システムでは、ハルシネーション率が 20% に達することがあります。チャンキング・リランキング・プロンプト設計を最適化することで 2〜5% まで低減できます。

RAG パイプラインの最適化ポイント

ドキュメント → チャンキング → エンベディング → ベクトルDB → 検索
                                                          ↓
                                                      リランキング
                                                          ↓
                                                      コンテキスト構成
                                                          ↓
                                                      LLM 生成
                                                          ↓
                                                      出力検証

各段階で品質を左右する要素があります。

段階最適化ポイント効果
チャンキング固定サイズ → セマンティックチャンキング → 適応型チャンキング適応型で精度 87%（ベースライン 50%）
エンベディング汎用モデル → ドメイン特化・ファインチューンモデル法律・医療・コードなど専門領域で大幅改善
リランキングCohere Rerank / BGE Reranker / Jina Reranker関連度の高い情報を上位に再配置
コンテキスト構成信頼度スコアによるフィルタリング低品質な検索結果を除外
出力検証生成結果と検索結果の整合性チェックハルシネーション検出

エージェンティック RAG

従来の RAG が「1回検索して回答」なのに対し、エージェンティック RAG は計画・反復検索・検証を行います。

従来のRAG:
  クエリ → 検索 → 生成 → 回答

エージェンティックRAG:
  クエリ → 計画（タスク分解）
        → 検索1 → 結果を評価 → 不十分なら再検索
        → 検索2 → 別のソースも検索
        → 結果を統合 → 矛盾チェック
        → 生成 → 主張の根拠を検証
        → 回答

Weaviate の Elysia は、決定木ベースのエージェンティック RAG フレームワークで、どのツールを使うかを知的に判断します。

壁3: ガードレールと評価

エージェントを信頼性のあるものにするには、実行時の制約メカニズムが不可欠です。

ガードレールの種類

種類目的例
入力ガードレール悪意ある入力・プロンプトインジェクションを検出プロンプトインジェクション検出器
出力ガードレール不適切・不正確な出力を防止ファクトチェック、PII 除去
実行ガードレールエージェントの行動を制限ツール呼び出し許可リスト、レート制限
構造ガードレールシステム全体の安全性を確保サーキットブレーカー、フォールバック

AEGIS フレームワーク

Forrester が提唱する AEGIS（Agentic AI Guardrails for Information Security）は、自律AIシステムを保護するためのフレームワークです。ガードレールを「ベストプラクティス」ではなく「インフラレベルの強制メカニズム」として位置づけています。

継続的評価

本番環境では、デプロイ前のテストだけでは不十分です。

デプロイ前:
  ユニットテスト → 統合テスト → レッドチームテスト → ステージング検証

デプロイ後（継続的）:
  検索品質モニタリング ← クエリ埋め込み + 検索結果ID + ユーザーフィードバック
  出力品質モニタリング ← ハルシネーション検出 + 根拠スコア
  コストモニタリング   ← トークン消費 + レイテンシ追跡
  障害パターン検出     ← 失敗をリグレッションテストとポリシー更新に変換

壁4: スケーリングの非線形性

マルチエージェントシステムの複雑さは、エージェント数に対して非線形に増大します。

17倍のエラー増幅

Towards Data Science の分析によると、独立して並列動作するマルチエージェント（Bag of Agents）では、エラーが 17.2倍 に増幅されます。

アーキテクチャエラー増幅率
独立並列（Bag of Agents）17.2倍
オーケストレーター集約型4.4倍

オーケストレーターが「検証ボトルネック」として機能し、エラーの伝播を防ぎます。

スケーリング時のコスト増

マルチエージェント化に伴う「協調税」:

項目増加幅
トークンコスト2〜5倍
レイテンシエージェント間通信分だけ増加
エラー率カスケード障害リスク

Google の研究: 協調トポロジーが鍵

Google Research は「エージェントシステムのスケーリング科学に向けて」で、重要なのはエージェントの数ではなく協調のトポロジーだと示しました。

  • タスクの性質（ツール数、分解可能性）に応じて最適なアーキテクチャは異なる
  • 予測モデルにより、未知のタスク構成に対して 87% の精度で最適な協調戦略を特定
  • 単にエージェントを増やすことは、ほとんどの場合で逆効果

カスケード障害の防止策

対策機能
サーキットブレーカー障害がネットワーク全体に波及するのを防止
グレースフルデグラデーション部分障害時でもコア機能を維持
エラーバウンダリ個別エージェントの障害をシステム全体から隔離
タイミング依存性モニタリングエージェント間のタイミング依存を可視化し、ボトルネックを検出

実際に起きた本番障害事例

2025年に報告された実際の障害事例が、デモ→本番ギャップの深刻さを物語っています。

事例何が起きたか根本原因
Replit AIアシスタント「変更禁止」と明示した本番DBを全削除実行ガードレールの欠如
OpenAI Operatorユーザーの確認なしに $31.43 の無断購入人間確認フローのバイパス

これらは「モデルが賢くなれば解決する」問題ではなく、システム設計の問題です。

本番移行チェックリスト

デモから本番へ移行する際の確認事項をまとめます。

セキュリティ

  • マルチテナンシー分離（ベクトルDB レベル）
  • RBAC によるデータアクセス制御
  • PII 検出・マスキング
  • 監査ログの実装

検索品質

  • チャンキング戦略の最適化（セマンティック or 適応型）
  • ドメイン特化エンベディングの検討
  • リランカーの導入
  • ハルシネーション率の計測と目標設定

ガードレール

  • 入力/出力/実行ガードレールの実装
  • サーキットブレーカーの設置
  • 継続的評価パイプラインの構築
  • レッドチームテストの実施

スケーリング

  • 協調アーキテクチャの選定（並列 vs オーケストレーター vs 階層）
  • トークンコスト・レイテンシの予算策定
  • カスケード障害防止メカニズムの実装
  • モニタリングダッシュボードの構築

まとめ

  • AIエージェントの 95% はデモから本番に到達できない。MIT 調査でも本番到達率はわずか 5% で、Gartner は 2027 年までに 40% 以上のプロジェクト中止を予測している
  • 壁1: セキュリティ — マルチテナンシー分離と RBAC がなければ、エージェントはデータを漏洩する。「後からセキュリティを追加」は本番では通用しない
  • 壁2: 検索品質 — RAG のハルシネーション率は未対策で 20%、チャンキング・リランキング最適化で 2〜5% に低減可能。エージェンティック RAG は計画→反復検索→検証で精度を上げる
  • 壁3: ガードレール — AEGIS のようなインフラレベルの強制メカニズムが必要。デプロイ後の継続的評価（モニタリング、レッドチーム、障害のポリシー化）が信頼性を維持する
  • 壁4: スケーリング — マルチエージェントのエラー増幅率は最悪 17.2 倍。Google 研究が示す通り、重要なのはエージェント数ではなく協調トポロジーの設計
  • 実際の障害事例（Replit DB 全削除、OpenAI 無断購入）が示す通り、問題はモデル性能ではなくシステム設計にある

参考