何が起きているか
AIエージェントが自信満々に間違える。しかもモデルもプロンプトも変えていないのに、公開から3カ月後には利用者の質問の約3分の1で誤答が起きる——VentureBeatの寄稿はこの現象から始まります。理由は単純で、価格・ポリシー・製品仕様は日々変わるのに、エージェントが参照する知識ストアが古いまま取り残されるからです。
問題は「見えない」ように設計されている点にあります。一般的な検索(retrieval)パイプラインが採点するのは関連性(relevance)や利用可能性であって、正確性(correctness)ではありません。古い文書や、フィールドが静かに欠落したレコードも、最新で完全なデータと同じ高スコアで通過してしまう。結果、ダッシュボードは緑のまま、システムだけが間違え続けます。
なぜ重要か——誤診を2回繰り返す
寄稿者は、同型の障害を過去にfintechのパイプラインで目撃したと述べます。上流システムが通知なしにフィールドを変更したが、ジョブは「完走」したためパイプラインは落ちず、誤った値がそのままダッシュボードへ伝播。顧客が矛盾に気づいて初めて発覚しました。ジョブが走ったかは監視していても、運んだデータが今も正しいかは誰も見ていなかったのです。
チームはたいてい二度誤診します。まずモデルを疑い(別のLLMを試す、プロンプトを直す)、次に検索・コンテキスト層を疑って「より良いもの」を買う。ベンダーもこの層で応えており、AWSはエージェント利用から学ぶナレッジグラフで「コンテキスト層」競争に参入、SnowflakeはHorizon ContextとCortex Senseで自信満々の誤答を標的にしました。しかしナレッジグラフも、それを養うデータ次第。真の問題はひとつ下、データエンジニアリング層にあります。
処方箋——データ観測性と4つの指標
欠けているのは「データ観測性」で、鍵となる指標はカバレッジ——重要データセットのうち、来歴(lineage)を誰かの頭の中ではなくクエリ可能な形で持っている割合です。UberはRAG登場以前にUnified Data Quality platformを構築し、2,000超の重要データセットを支え、データ品質インシデントの約9割を下流到達前に検知。Netflixは Kafkaトピック・MLモデル・実験をまたいで依存関係を辿れる全社データ来歴システムを作り、人間向けだったものがAI/LLM時代にいっそう重要になりました。
寄稿者は測定可能な4次元を提示します。正確性(型・想定外のnull無し・値域——Great ExpectationsやSodaで検証し、実行ごとの合格率を追う)、鮮度(ソース基準でどれだけ新しいか——一律閾値でなくデータセット別SLAで最終更新からの経過を測る)、一貫性(同じ事実がどこでも同じに読めるか——下流間の定期クロスチェックで不一致率を検知)、来歴(出力を源泉と全変換まで遡れるか——Netflixが答えようとした問い)。
Socureでは顧客データが不揃い・時に誤った形で届いたため、著者は取り込み時のスキーマ/値域検証(Great Expectations)、ソース別の鮮度SLA、クロスシステム一貫性チェック、ファイル単位の来歴を、write-audit-publish(ステージングに着地→検証→合格分のみ下流へ)の枠組みで実装。結果、同じデータ上のレポート・MLモデル・AI検索すべてで下流精度が向上しました。
本番の検索型AIには4つの診断的問いが有効です。データは消費者基準で検証されているか。高い確信度で提供している最古のコンテンツは何か。同一ソースの2つのチャンクが同じ検索結果内で食い違うことはあるか。誤っていたとき出所を辿れるか。答えられないなら、それはモデル差し替えやベンダー移行ではなく、源泉システムとエージェントが読む先の間の配管を直すデータエンジニアリングの課題です。AIは、データエンジニアリングに元々あった弱点を露わにしているにすぎません。
💼 事業会社視点：これは自社にどう効くか
日本企業がAIチャットボットや社内RAGを「導入して終わり」にしがちなのは危険です。公開直後の精度検証で合格しても、価格改定・規約変更・仕様更新のたびに知識ストアは静かに腐り、3カ月後には約3分の1が誤答という数字が現実味を帯びます。とりわけECのFAQ自動応答、SaaSのサポート回答、受託開発で顧客に納品したAI機能は、「ジョブが完走したか」しか見ていない監視だと、緑のダッシュボードの裏で顧客に誤情報を出し続け、気づくのはクレームが来た時です。経営者・事業責任者が今動くべきは、モデルやベンダーの乗り換え検討の前に、源泉データの観測体制を持つこと。具体的には(1)重要データセットのうち来歴をクエリで辿れる割合(カバレッジ)を可視化し、(2)データセット別の鮮度SLAを設定、(3)Great ExpectationsやSodaで取り込み時に検証しwrite-audit-publishで不合格データを下流に流さない、の3点です。受託側はこれを保守契約の付加価値・継続収益にできます。