社内文書検索やAIアシスタントにRAG（検索拡張生成、Retrieval-Augmented Generationの略）を組み込んでいる基盤チームに向けた内容です。ベクトル検索を既存SaaS基盤に追加する際、監視設計や権限制御を後回しにすると、データ漏洩や原因不明の障害につながることがあります。運用目線での確認ポイントを整理しました。
RAGは、大規模言語モデル（LLM）に組織固有の最新データを渡すための仕組みです。文書をチャンク（小さな単位）に分割し、埋め込みベクトル化してインデックスに格納し、質問時に関連情報を検索してLLMに渡します。仕組みは単純に見えますが、既存の認証・監視・監査ログの仕組みと接続しないまま導入すると、思わぬ落とし穴にはまります。
何が起きるか
最も多い事象は、権限のないユーザーがベクトル検索経由で本来アクセスできない文書の内容を見てしまうことです。
LLM自体が悪意を持って情報を漏らすわけではありません。検索層がテナント（契約単位の顧客区分）やユーザー権限を考慮せずに「意味的に近い文書」を機械的に取得してしまうことが原因です。既存のAPIには認可チェックが入っていても、ベクトルインデックスへの直接検索にはそのチェックが漏れているケースがあります。
もう一つの事象は、インデックスの陳腐化による「事実と異なる回答」です。元データベースは更新されているのに、ベクトル索引側の再インデックスが走っていないと、古い情報が回答に混入します。これは障害と呼びにくい静かな不整合ですが、利用者からの問い合わせが増える形で表面化します。
運用面では、ベクトル検索・埋め込み生成・LLM呼び出しの3段構成のうち、どこで遅延やエラーが起きているか特定できず、障害対応が長引く事象もよく見られます。
なぜ起きるか
原因は大きく3段階に分解できます。
1段目は、AI機能を既存基盤と別の「並行アーキテクチャ」として構築してしまうことです。既存のAuth（認証）・Tenancy（テナント分離）・Audit（監査ログ）の仕組みを素通りして、AI機能専用のデータストアと権限モデルを新設すると、業務ロジックを理解するシステムが2つ存在する状態になります。片方を修正しても片方に反映されず、権限の食い違いが生まれます。
2段目は、検索層の設計がベクトル類似度だけで完結していることです。「質問→ベクトル検索→上位5件→LLM」という単純な構成では、テナントやユーザー権限、文書の種類、アクセスポリシーといった業務上の制約が検索結果に反映されません。認可コンテキストを検索の前段に置かず、後段でフィルタしようとすると、フィルタ漏れがそのまま情報漏洩になります。
3段目は、ソースデータの更新とベクトルインデックスの更新が非同期であることが運用側で意識されていない点です。インクリメンタルインデックス（差分だけ反映する更新方式）や削除の伝播が設計されていないと、データベース側は最新なのに検索結果だけ古い状態が長期間残ります。これは一般的なキャッシュの陳腐化問題と同じ構造ですが、AIの回答という形で出てくるため原因調査が一段複雑になります。
自分のプロジェクトが該当するか確認する方法
該当するかどうかは、次の観点で自分の構成を点検すると判断しやすくなります。
- ベクトル検索を呼び出すAPIのコードで、認可チェックが検索クエリの前に入っているか（後から結果をフィルタする実装になっていないか）を確認する
- インデックス更新のジョブ設定（cronやイベント駆動のトリガー）を確認し、ソースデータ更新からインデックス反映までの遅延時間を把握する
- ベクトルDB（Amazon OpenSearch、Pineconeなど）のダッシュボードで、テナントIDやユーザーIDがメタデータとして格納されているか確認する
- LLM呼び出し・埋め込み生成・ベクトル検索それぞれのレイテンシとエラー率が個別に監視されているか、監視ダッシュボードを見て判断する
設定ファイルとしては、RAGパイプラインの構成を記述したYAMLやコードのうち、retrievalやindexに関する箇所を確認すると、フィルタ条件がハードコードされているか、動的にユーザーコンテキストを受け取っているかが分かります。
retrieval:
vector_store: opensearch
filters:
- tenant_id
- user_permissions
- document_type
rerank: trueこのようにfiltersにテナントIDと権限情報が明示的に含まれているかどうかが、権限漏洩リスクの有無を判断する目安になります。含まれていない場合は要注意です。
対策の手順
対策は既存基盤の資産を検索層に「継承させる」方向で進めます。
1. 認可コンテキストを検索クエリの前段に注入する処理を追加します。ユーザーのテナントIDと権限情報を取得し、ベクトル検索のフィルタ条件として渡す実装に変更します。
2. ベクトルパイプラインを個別のAI機能から切り離し、共通の「Retrieval API」として一段抽象化します。検索・アシスタント・エージェントの各機能が同じAPIを経由することで、フィルタ漏れの発生箇所を1か所に集約できます。
3. インデックス更新をイベント駆動にします。ソースデータの更新イベント（作成・更新・削除）をトリガーにして、インクリメンタルインデックスの更新ジョブを走らせる構成にすると、陳腐化の遅延を最小化できます。
4. 監視は埋め込み生成・ベクトル検索・LLM呼び出しの3段を分けて計測します。既存のAPM（アプリケーション性能監視）ツールにこの3段をそれぞれ別のスパンとして記録すると、障害時にどの段で遅延やエラーが起きているか特定しやすくなります。
5. 運用コストの観点では、埋め込み生成とLLM呼び出しの呼び出し回数がコストの大部分を占めることが多いため、検索結果のキャッシュや、頻出クエリの再利用を検討します。
まとめ
RAGパイプラインは便利ですが、既存基盤のAuth・Tenancy・監査ログの仕組みを迂回すると、権限漏洩と障害調査の長期化という2つのリスクを同時に抱え込みます。
まず自分のプロジェクトで、検索クエリの前段に認可チェックが入っているか、インデックス更新の遅延がどの程度あるかを確認してください。
そのうえで、Retrieval APIとしての抽象化、イベント駆動のインデックス更新、3段構成の個別監視という3つの対策を順に進めると、既存基盤が持っていた信頼性をAI機能にも引き継げます。