この記事で扱うこと
「データはある。あとはAIエージェントに渡すだけ」——この考えが、本番運用で最も頻繁に失敗する原因です。
本記事では、AIエージェントが安全かつ正確に動作するために必要なデータプロダクトの設計原則を解説します。具体的には以下の4点にフォーカスします。
- データの「意味」を明示するセマンティックコントラクト
- 実行時に評価するパーミッションアウェア検索
- 品質・鮮度に基づく停止判断機構
- これらを支えるアーキテクチャ上の責務分担
対象読者は、AIエージェントをPoCから本番に移行しようとしているエンジニア、アーキテクト、SREです。
なぜ「データがある」では不十分なのか
多くのチームは「データレイクがある」「ウェアハウスにデータが揃っている」「BIダッシュボードが動いている」という理由で、AIエージェントの準備ができたと考えます。
しかし、従来の分析とAIエージェントの間には決定的な違いがあります。
- 人間のアナリストは曖昧さを許容できる。3つのダッシュボードを開き、定義をクロスリファレンスし、暗黙知で補完する。
- AIエージェントはそれができない。与えられたフィールド名だけを頼りに推論し、しばしば「もっともらしく間違う」。
具体例を挙げます。
- 財務チームが月次決算エージェントを導入しようとしたが、試算表に「暫定値」と「確定値」が混在していた。
- 購買エージェントが「承認済みベンダー」を参照しようとしたが、調達システムとERPで定義が異なっていた。
- カスタマーサポートエージェントが「アクティブ顧客」を判定しようとしたが、部門ごとに定義がバラバラだった。
データは存在する。しかし、エージェントが正しく使える形でパッケージされていない。
このギャップこそが、デモと本番運用を分ける最大の壁です。
エージェントが本当に必要としているもの：データプロダクト
データをプロダクトとして扱うという発想は、マイクロサービスやデータメッシュの文脈で広く知られています。AIエージェント向けには、さらに厳格な契約が必要です。
最低限、エージェント対応データプロダクトに必要な要素は以下の通りです。
| 要素 | 説明 |
|---|---|
| 安定したスキーマ | 後方互換性のある変更管理 |
| セマンティックコントラクト | 各フィールドのビジネス上の意味 |
| オーナーシップ | ビジネスオーナー＋テクニカルオーナー |
| 鮮度期待値 | 更新頻度と有効期限 |
| 品質しきい値 | 許容される欠損率や異常値の範囲 |
| 基本系列 | データの発生源と変換履歴 |
| アクセスポリシー | 実行時に評価可能なルール |
| 利用ルール | 許可される操作と禁止される操作 |
これらが揃っていないデータは、エージェントにとって「文脈のないフィールドの山」です。
セマンティックコントラクト：形式ではなく意味を定義する
スキーマレジストリやAPIドキュメントは既にあるかもしれません。しかし、エージェントが必要としているのはフィールド名だけではありません。
例えば revenue というフィールドがあった場合、エージェントは以下のどれを指すのかを知る必要があります。
- 受注売上（booked revenue）
- 請求売上（billed revenue）
- 認識売上（recognized revenue）
- 純売上（net revenue）
同様に margin が粗利なのか、貢献利益なのか、特定の配賦後の利益なのか。
active customer が「過去90日間の取引あり」なのか「有効な契約あり」なのか「正式な解約手続きなし」なのか。
このセマンティックコントラクトは、以下の情報を明示的に定義するレイヤーです。
- 各フィールドのビジネス上の意味
- そのフィールドを使用すべき/すべきでない条件
- 暗黙に含まれている前提条件
- 定義の変更履歴と変更責任者
エンタープライズでは、このセマンティックレイヤーをBI、業務アプリケーション、AIエージェント、ビジネスユーザー全体で統一する必要があります。なぜなら、多くのデータコンフリクトは「技術的な品質問題」ではなく「定義の問題」だからです。
特に以下の領域では、セマンティックコントラクトを厳格にすべきです。
- 複数機能横断で使われるデータ
- トランザクションや承認に触れるデータ
- アクションを実行するエージェントが参照するデータ
- HR、財務、法務、顧客データなど規制対象領域
パーミッションアウェア検索：アクセス権は実行時に評価する
「インデックスにあるから」「ベクターストアにあるから」という理由でエージェントがデータを取得してはいけません。
アクセスは以下のコンテキストに依存して評価される必要があります。
- 誰が（ユーザーID、役割）
- どのチャネルで（Slack、Web、API）
- どのワークフローのどの段階で（申請中、承認済み、監査中）
- 何のために（パフォーマンスレビュー、報酬調査、例外処理）
- データの機密性は（公開、社内限定、要許可）
多くのRAG実装は「すべてをインデックスし、意味的に最も関連するものを取得する」という単純なパターンから始まります。しかしエンタープライズでは、これが危険です。
- 最も関連性の高い文書が、最も許容された文書とは限らない
- HRオンボーディングエージェントが「福利厚生」に関連する報酬文書を見つけてしまう
- 法務契約アシスタントが別の事業部の契約を参照してしまう
よくある誤りは、アクセス制御をインデックス時にだけ適用することです。
しかし、権限は呼び出し元のコンテキストによって変化するため、実行時に評価しなければなりません。
エージェントシステムでは、ロールベースのアクセス制御（RBAC）だけでは粗すぎることが多いです。
- 同じ役割の2人のマネージャーが、同じデータを異なる目的で使うべきではない
- マネージャーはチームデータをパフォーマンスレビューには使えるが、報酬調査には使えない
- 財務エージェントは請求書の例外処理のために詳細を読めるが、クロスエンティティのベンダーサマリーを勝手に集計してはいけない
この複雑さに対応するには、メタデータのリッチ化、IAM/ポリシーエンジンとの緊密な統合、レイテンシの許容、インデックス設計の工夫が必要です。
しかし、HR、財務、法務、顧客データ、規制対象業務では、これは最低要件です。これを怠ると、エージェントが新たなデータ漏洩経路になります。
品質と鮮度：エージェントは「止まる」ことを知らなければならない
AIエージェントの実務上の最大のリスクは、ハルシネーションではありません。
古いデータ、不完全なデータ、過渡期のデータを自信満々に使ってアクションを起こすことです。
実際の障害例を挙げます。
- 購買エージェントが、デューデリジェンスの承認ステータスが未同期のベンダーを推薦した
- 財務クローズエージェントが、暫定値からコメントを生成した（確定値は別にあった）
- カスタマーサービスエージェントが、未更新の注文ステータスに基づいて返金を約束した
- ITインシデントエージェントが、CMDBが古いままのシステムに復旧ルーティングを指示した
いずれもモデルの問題ではなく、データプロダクトが品質・鮮度のシグナルを適切に伝えていなかったことが原因です。
エージェント対応データプロダクトには、最低限4つの仕組みが必要です。
- 品質チェック：フィールドの欠損チェック、スキーマ一致確認、参照整合性検証
- 鮮度インジケーター：最終更新時刻、期待されるリフレッシュサイクル、有効期限内かどうか
- 異常検知：スパイクや異常パターンが発生した場合、エージェントはデータを無条件に信用しない
- フォールバック動作：品質や鮮度がしきい値を下回った場合の行動——停止、代替データソースの利用、人間へのエスカレーション
最も見落とされがちなのは、エージェントが 「データが足りない」と言える能力です。
- AP例外エージェントは、入庫が未登録なら不一致の分類をすべきではない
- HRエージェントは、給付資格データが確定していなければ質問に答えるべきではない
- サプライチェーンエージェントは、出荷フィードが未更新ならルート変更を推奨すべきではない
ガバナンスの観点では、「いつ止まるかを知っているエージェント」は、「いつも自信満々なエージェント」よりもはるかに価値があります。
アーキテクチャへの示唆
データとナレッジをエージェント向けプロダクトとして扱うことは、アーキテクチャ全体に影響を与えます。
1. オーナーシップを明示する
すべてのデータプロダクトに以下を割り当てます。
- ビジネスオーナー：定義と利用ルールの決定責任者
- テクニカルオーナー：配信と品質の実装責任者
- リスク/コンプライアンスオーナー（機密領域の場合）：規制対応の責任者
オーナー不在のままでは、エージェントは利用可能なデータを何でも使うようになりますが、定義が変わったり品質が低下したときに責任を取る人がいません。
2. カタログをコントロールプレーンにする
データプロダクトの存在場所だけでなく、以下を追跡するカタログが必要です。
- セマンティックコントラクト
- 鮮度期待値と品質ステータス
- アクセスポリシー
- リスク階層
これにより、エージェントプラットフォームはデータプロダクトを管理可能な依存関係として扱えます。アドホックな接続ではなくなります。
3. エージェント評価にデータプロダクトの評価を含める
エージェントが失敗したとき、まずモデルを疑うのではなく、以下を確認します。
- データプロダクトは適切だったか？
- セマンティックコントラクトは十分に明確だったか？
- 品質低下時にフォールバックは正しく動作したか？
- 検索はポリシーを尊重していたか？
評価パイプラインにこれらの観点を組み込むことで、モデル起因の問題とデータ起因の問題を切り分けられます。
まとめ：最も重要な問いかけ
AIエージェントのエンタープライズ導入を成功させる鍵は、モデルでもオーケストレーションでもツール呼び出しでもありません。
エンタープライズデータを、エージェントが使えるプロダクトとしてパッケージする規律です。
この理解がある組織は、印象的なデモから、実際に信頼できる運用へと素早く移行できます。
あなたのチームに持ち帰ってほしい問いは、これです。
「あなたのエージェントは、データが信頼できないときに停止することを知っていますか？」
もし答えが「はい」でなければ、本番運用の準備はまだできていません。