この記事で扱うこと
- AIエージェントが実運用で失敗する本当の原因（モデルではなくデータ）
- 「もっともらしい誤り（operational hallucination）」の正体とその影響
- 構造化データ・非構造化データそれぞれに求められる6つの特性
- ランタイムで実行されるガバナンスと権限制御の設計
- プロトタイプから本番スケールに移行する前に確認すべきチェックリスト
デモでは完璧だったエージェントが、本番でなぜ壊れるのか
ある企業の財務チームが、決算業務を支援するAIエージェントを開発した。ERPに接続し、仕訳を読み取り、照合作業のドラフトを生成する。デモではすべてが美しく動いた。
ところが、実際の月次決算が始まると事態は一変する。エージェントは請求書のステータスを誤読し、誤った勘定科目を推奨し、すでに解決済みの例外をエスカレーションした。チームは週末を費やして、すべてをゼロから再確認することになった。
何が悪かったのか？モデルではない。エージェントフレームワークでもない。問題はデータだった。
多くの企業は「どのモデルを選ぶか」「どのエージェントプラットフォームを採用するか」「ワークフローをどうオーケストレーションするか」に注力する。しかしエンタープライズの文脈では、モデルはますますコモディティ化している。買うこともコピーすることもできないのは、自社のコンテキストだ。「顧客」の定義、承認チェーンの構造、ポリシー例外の扱い、ビジネスエンティティ間の関係性——これらはすべてデータ基盤に依存する。
強固なデータ基盤がなければ、エージェントは自信満々に、そして間違った答えを返す。もっともらしく見えるが、実際のビジネスルールを無視した推奨を行う。これはモデルの幻覚（hallucination）ではない。運用にとってはるかに危険な、オペレーショナル・ハルシネーション（operational hallucination） だ。
デモ用エージェントと本番用エージェントを分ける3つの層：データ基盤、実行層、ガバナンスランタイム
オペレーショナル・ハルシネーションの本当のコスト
AIの幻覚（hallucination）についてはよく議論される。モデルが事実に基づかない情報を生成する問題だ。しかしエンタープライズ環境では、より厄介な問題が発生する。それがオペレーショナル・ハルシネーションである。エージェントの出力はもっともらしいが、実際のビジネス状態に対して間違っている。
- 財務エージェントが「請求書は未払い」と報告する——しかしERPのステータスはすでに変更済み
- HRエージェントが6ヶ月前に廃止された休暇ポリシーを引用する
- サプライチェーンエージェントが実際の在庫制約を理解せずに輸送ルートを変更する
問題は単なる正確性だけではない。エージェントが行動、優先順位、意思決定に影響を与え始めることだ。間違った回答のたびに、手戻り、遅延、コンプライアンスリスクが発生する。
これが、成功したパイロットと失敗した本番ロールアウトの差が、ほとんど会話品質ではなくデータ準備性にある理由である。
構造化データ：運用のバックボーン
エージェントがエンタープライズシステムで行動する——ステータスを確認し、条件を検証し、ワークフローをトリガーする——ためには、構造化データに依存する。顧客レコード、注文、請求書、サプライヤマスタ、従業員プロファイル、契約、チケット。
しかし、ERPやCRMを導入しているからといって、データがエージェント対応済みとは限らない。構造化データには以下の6つの特性が必要である。
1. 一貫したビジネス定義
「アクティブ顧客」とは何か？注文が「完了」するのはいつか？機能や国によって定義が異なれば、エージェントは一貫性のない判断を下す。
2. 明確なデータオーナーシップ
すべてのデータドメインに、単なる技術管理者ではなくビジネスオーナーが必要である。オーナーシップがなければ、データ品質の問題は「システムの問題」とラベル付けされ、エージェントは失敗し続ける。
3. トレーサブルな系列（Lineage）
エージェントはデータの出所を知る必要がある。ダッシュボードのフィールドが多層的な変換を経ている場合、エージェントが現在のビジネス状態を正しく読んでいることを保証できるか？
4. 監視されたデータ品質
完全性、一意性、一貫性、適時性——これらは仮定してはならない。重複したベンダーマスタや時代遅れの組織図は、エージェントのワークフローを破壊する。
5. 強力なセマンティクス
データにはシステム間で伝わる意味が必要である。ここでエンタープライズデータモデルとマスタデータ管理（MDM）が重要になる。
6. セキュアなアクセス
エージェントはコアテーブルに直接アクセスすべきではない。権限を強制し、監査証跡を維持し、安定したスキーマを提供するインターフェースが必要である。
# 悪い例：エージェントが直接テーブルをクエリ
agent.query("SELECT * FROM invoices WHERE status = 'unpaid'")
# 良い例：APIゲートウェイ経由で権限と監査を強制
agent.call_api("/api/v1/invoices?status=unpaid&user_context=current_user")
非構造化データ：コンテキストが実際に存在する場所
多くの組織は、エージェントを構築し始めて初めて非構造化データの価値に気づく。ポリシー、契約、メール、通話記録、SOP、ナレッジ記事——これらは受動的なアーカイブだった。エージェンティックAIにおいて、これらはアクティブなコンテキスト層となる。
顧客のチケットステータスはCRMにあるが、実際のコンテキスト——顧客に約束した内容、感情的なトーン、根本原因——は通話記録やチャット履歴にある。サプライヤマスタデータはクリーンでも、商取引条件や契約例外はPDFにある。従業員データはHRISにあるが、ローカルポリシーやFAQの例外はポータルやメールにある。
非構造化データには、単なる「ベクターストアへのドキュメントアップロード」ではない、規律あるパイプラインが必要である。
- 信頼できるソースからの制御された取り込み
- ポリシーとドラフトを分離する分類
- メタデータ付きのインテリジェントチャンキング
- 権限とコンテキストを尊重する検索
- 期限切れドキュメントをアクティブにしないライフサイクル管理
誘惑は「とにかく全部突っ込む」ことだ。それに抵抗せよ。公式SOP、アクティブな契約、検証済みナレッジ記事、キュレーションされたポリシードキュメント——高価値で権威あるコーパスから始めること。会社がこれまで作成したすべてのファイルを対象にしてはならない。
ガバナンス：ポリシードキュメントからランタイムへ
従来のデータガバナンスは、ドキュメント、委員会、手動制御で止まっていた。エージェンティックAIでは、ガバナンスはランタイムで実行されなければならない。
問いは「誰がこのデータにアクセスできるか？」から「誰がエージェントを通じて、どの目的で、どのワークフローで、どのレベルの自律性でこのデータにアクセスでき、そのアクセスがインサイトかアクションか？」に変わる。
ランタイム権限制御の設計ポイント
- 権限は検索時にチェックする。回答生成後ではない。HRエージェントは許可されていないユーザーに報酬データを引き出してはならない。
- 監査証跡は「何がアクセスされたか」だけでなく、「どのデータが、どのソースから、どの権限で、どのワークフローで、どのようにエージェントの判断に影響したか」を説明する。
- エージェントが誤った推奨をしたとき、問題がデータ品質、誤った検索、欠落したメタデータ、未実施のポリシーのいずれにあるかをトレースできなければならない。
# ガバナンスランタイムの設定例（概念）
governance_rules:
- data_domain: "employee_compensation"
allowed_roles: ["hr_manager", "compensation_analyst"]
retrieval_permission: "user_scope_only"
audit_level: "full_trace"
workflow_restriction: ["salary_review", "bonus_calculation"]
スケールする前に確認すべきチェックリスト
パイロットと本番の違いはデータ準備性にある。エージェンティックAIのフットプリントを拡大する前に、以下を確認せよ。
構造化データ
- 優先データドメインに一貫したビジネス定義があるか
- 顧客、サプライヤ、従業員、請求書データに明確なオーナーがいるか
- データ品質（完全性、一貫性、適時性）が監視されているか
- エージェントは権限を強制するインターフェースを通じてデータにアクセスしているか
非構造化データ
- コーパスはキュレーションされ、ドラフトと区別されているか
- バージョン、有効日、地域、分類などのメタデータが存在するか
- 検索はソースシステムと一貫した権限を尊重しているか
- ドキュメント、トランスクリプト、インタラクション履歴の保持ポリシーがあるか
ガバナンス
- エージェントが推奨を行うために使用したデータをトレースできるか
- ランタイムで権限がチェックされているか
- 監査証跡が「何を」「なぜ」を説明できるか
警告サイン
- 「データは後でクリーンにする」と言っている
- コアマスタデータがまだ機能間で議論されている
- エージェントが権限が不明確なドキュメントから回答を引き出している
- サービスアカウントが過度に広いアクセス権を持っている
- ポリシーにバージョンメタデータがない
- 検索がユーザー権限を無視している
これらは技術的負債ではない。スケーリングのブロッカーである。
まとめ：エージェントを増やす前に聞くべき最も正直な質問
「どのモデルを使うか？」ではない。
「どのデータが我々の真実のソースか？それを誰が所有しているか？エージェントが現実にのみ基づいて行動することをどう保証するか？」
これが、プロトタイプを本番運用に変える唯一の問いである。