1. 企業規模でRAGが破綻する理由：検索は“機能”ではなく“基盤”になった
RAG（Retrieval-Augmented Generation）は、LLMを自社データで“接地”させるための定番アーキテクチャとして急速に普及しました。しかし企業規模で導入が進むほど、「検索は推論に付け足す機能」という前提が崩れます。検索はアプリの一部ではなく、複数プロダクト・複数部門・複数エージェントが共有する“基盤依存”になったからです。
初期のRAGは、社内FAQや限定ドメインのコパイロットなど、比較的静的なコーパス、人間の監督、予測しやすいアクセスパターンを暗黙に想定していました。ところが現在の企業AIは、継続的に変化するデータソース、部門横断の推論、エージェントによる自律的な取得、そして監査・規制要件と結びついたデータ利用へと拡張しています。
この環境では、検索の失敗は回答品質の劣化に留まりません。古いインデックス、誤ったスコープの権限、越境取得の暴走といった“取得の欠陥”が、意思決定・業務自動化・半自律運用のリスクとしてそのまま増幅されます。流暢な文章が返るほど、問題が発見されにくい点も厄介です。
- 検索が古い：もっともらしいが誤った判断材料を供給する
- 検索が広すぎる：権限外データを参照し、漏えい・不正利用の温床になる
- 検索が偏る：権威ある一次情報が黙って欠落し、現場が気づけない
つまり企業RAGのボトルネックは「モデルが賢いか」ではなく、「検索がインフラとして設計されているか」に移りました。ここを見誤ると、評価も改善も“的外れ”になります。
鮮度（Freshness）はチューニングではなくシステム設計で担保する
RAGの鮮度問題は、埋め込みモデルの精度やプロンプト調整の話として扱われがちです。しかし実態は、周辺システムの非同期性が生む“遅延と不整合”の問題です。ソースが更新されても、取り込み・分割・埋め込み・インデックス反映が追いつかず、利用者やエージェントが古い表現を平然と参照してしまう。これが企業で頻発する鮮度事故の典型です。
運用で問われるのは、次のような素朴だが重要な問いに答えられるかです。
- ソース変更は何分／何時間で検索に反映されるのか（SLA/SLO）
- どのアプリ／エージェントが古いインデックスを参照しているのか
- セッション中にデータが更新された場合、どの版を“正”として扱うのか
成熟した基盤では、鮮度は「定期バッチで再構築」ではなく、設計で担保します。代表例は、イベント駆動の再インデックス、埋め込みとインデックスのバージョニング、取得時に“古さ”を認識するメタデータ付与です。重要なのは、鮮度を“努力目標”ではなく“契約（保証）”に落とすこと。自律的に動くワークフローほど、古いコンテキストは静かに、しかし確実に障害と損失を増やします。
ガバナンスを検索レイヤーへ拡張する：権限・監査・越境取得の制御
多くの企業は、データ基盤側（DWH、ストレージ、業務SaaS）と、モデル利用側（API、アプリ）を別々に統制してきました。ところがRAGはその中間に位置し、検索が“抜け道”になりやすい。ストレージ上は権限が厳格でも、検索APIが広いインデックスを横断して返してしまえば、結果としてモデルが権限外情報に触れます。
検索レイヤーにガバナンスを拡張するとは、データセット単位の制御だけでなく、クエリ・埋め込み・取得結果・消費者（人/アプリ/エージェント）を結び付けてポリシーを適用することです。特にエージェントは「自分で検索して自分で次の行動を決める」ため、越境取得が“行動権限”と直結します。
検索ガバナンスで押さえるべき論点
- ドメイン分離：部門・用途ごとにインデックスを分割し、明確なオーナーと責任範囲を置く
- ポリシー認識API：呼び出し主体（ユーザー/サービス/エージェント）と目的を属性として受け取り、検索時にフィルタリングする
- 監査可能性：いつ誰が何を問い合わせ、どの断片が返り、どの回答・意思決定に影響したかを追跡できる
- 越境取得の制御：クロスドメイン検索を“デフォルト禁止”にし、例外は申請・期限・監査つきで許可する
「学習していないから安全」「プロンプトで縛っているから大丈夫」という発想は、企業統制としては弱い。検索が返す時点で、すでに情報は露出しているからです。
評価は回答品質で終わらない：リコール、鮮度ドリフト、ポリシー順守を測る
RAG評価が「最終回答が正しいか」「人が見てそれっぽいか」に偏ると、根本原因を見失います。検索の問題は上流で起き、しかも“それっぽい誤答”として下流に流れます。結果、障害が起きたときにモデルが疑われ、検索基盤の欠陥が放置されがちです。
企業で必要なのは、検索を独立したサブシステムとして評価する視点です。少なくとも次の3軸は、回答評価とは別に計測・監視されるべきです。
- リコール（制約下）：権限・ポリシーを守った上で、必要な一次情報を取りこぼしていないか
- 鮮度ドリフト：ソース更新に対して検索結果がどれだけ遅延・乖離しているか（時間差・版ズレ）
- ポリシー順守：返してはいけない情報が返っていないか、越境取得が発生していないか
特に本番では、検索経路が動的に変化します。新しいデータソース追加、インデックス再構成、エージェントの探索行動、ランキング更新などにより、静かなドリフトが蓄積します。サンプルプロンプトに対する回答採点だけでは、何が取れて何が欠けたか、なぜその文書が返ったかが見えません。評価対象を「文章」から「取得の挙動」へ拡張することが、信頼性への近道です。
参照アーキテクチャ：5層で捉える「検索をインフラ化」するRAG基盤
検索をインフラとして扱うなら、アプリごとに場当たりで組むのではなく、共通の参照アーキテクチャが必要です。ここでは企業RAGを5層で整理します。ポイントは、鮮度・ガバナンス・評価を“内製ロジック”に埋め込まず、基盤のプレーン（制御面）として分離することです。
5層モデル
- ①ソース取り込み層：構造化/非構造化/ストリーミングを扱い、来歴（provenance）と更新イベントを保持する
- ②埋め込み・インデックス層：バージョニング、ドメイン隔離、更新伝播の制御（イベント駆動/差分更新）を担う
- ③ポリシー・ガバナンス層：検索時の権限判定、セマンティック境界での制約、監査ログ、越境取得の制御を行う
- ④評価・監視層：リコール、鮮度、ポリシー違反、ランキング偏りを継続計測し、ドリフトを検知する
- ⑤消費層：人、業務アプリ、エージェントが利用。用途ごとの制約（時間、権限、根拠提示）を付与して呼び出す
この分解により、「どの層の責務か」が明確になります。たとえば鮮度事故は②と①の連携、監査不能は③と⑤の接続、回答の不安定さは④で検索挙動を切り分け、といった具合に原因究明と改善が体系化されます。結果として、RAGがプロダクトごとの“手作り”から、企業横断の“共有基盤”へ進化します。
検索がAIの信頼性を決める：自律エージェント時代のリスクと打ち手
自律エージェントや長時間稼働のAIワークフローが一般化すると、検索は「参照」ではなく「意思決定の前提」になります。モデルは与えられたコンテキスト以上に賢くなれません。つまり検索が不安定なら、AIの信頼性も不安定です。
このとき顕在化するリスクは、単発の誤答ではありません。説明不能な挙動、コンプライアンスギャップ、部門ごとの結果不一致、監査で再現できない意思決定といった“組織的な不信”です。しかも原因はモデルではなく、検索の鮮度・権限・評価の欠落であることが多い。
打ち手：検索を「運用できるインフラ」にする
- SLOを設定：鮮度（反映遅延）、可用性、監査ログ欠損率などを数値で管理する
- ポリシーを検索時に強制：アプリ側の善意に依存せず、取得APIで必ず判定する
- 評価を常時化：回答採点に加え、取得漏れ・古さ・違反を継続監視し、ドリフトを早期に潰す
- エージェントの越境を設計で抑える：探索範囲、ツール権限、ドメイン横断の許可を明示する
RAGの成否は、プロンプトやモデル選定だけでは決まりません。検索を“インフラ”として設計し、鮮度・ガバナンス・評価を第一級の要件として扱えるか。そこが企業AIの信頼性を分ける分岐点です。
