RAGパイプラインがデータ流出の経路になる可能性は？セキュリティチームが見落としているリスク

Retrieval Augmented Generation（RAG）は、エンタープライズAIを本当に役立つものにするアーキテクチャです。AIが学習データだけに頼るのではなく、組織独自のリポジトリから関連ドキュメントを検索し、それを根拠に回答を生成します。

ビジネス面での導入効果は明確です。RAGパイプラインはAIアシスタントの精度と最新性を高め、知識集約型業務における価値を大幅に向上させます。一方で、セキュリティ面の課題も現実的であり、多くのRAG導入環境では十分な対策が取られていません。RAGパイプラインは本質的に、高スループットなドキュメント検索システムであり、AIがその内容を要約・統合し、提示します。リクエスト単位のアクセス制御や機密ラベルの強制、リアルタイム監視がなければ、これはデータ流出ツールの正確な説明にもなり得ます。本記事は、RAGパイプラインがどのようにしてデータ流出経路となるのか、そしてそれを防ぐためのセキュリティアーキテクチャについて理解したいCISOやコンプライアンス担当者向けです。

エグゼクティブサマリー

主なポイント： クエリの関連性に基づいてドキュメントを検索し、ユーザー単位のアクセス制御や機密ラベル評価、リアルタイム監視がないRAGパイプラインは、組織のセキュリティ境界内で動作するデータ流出経路となります。しかも自然言語インターフェースにより、従来の攻撃ツールよりも体系的なデータ抽出が容易です。RAGパイプラインが流出を可能にする5つの経路は、いずれも適切なアーキテクチャで防止可能ですが、どのRAGフレームワークのデフォルト設定でも防止されていません。

なぜ重要か： RAGパイプラインは生産性向上ツールとして導入・承認されており、データアクセスシステムとしての観点で評価されていません。仮にセキュリティレビューが行われる場合でも、AI層（モデル、プロンプト設計、出力フィルタリング）に焦点が当たり、実際に機密データに大規模にアクセスする検索層には、新たなファイルアクセスシステムと同等のセキュリティレビューが行われないことが多いのです。このギャップこそが流出リスクの温床となっています。

5つの重要なポイント

1. RAGパイプラインの検索コンポーネントは高スループットなデータアクセスシステムです。 機密エンタープライズデータに大規模にアクセスする他のシステムと同様、同じアクセス制御、データ分類強制、監査ログ要件が適用されるべきですが、多くの組織ではそうなっていません。
2. 過剰な権限付与による検索が、RAGによるデータ流出シナリオの構造的な脆弱性です。 検索コンポーネントが広範なリポジトリアクセス権を持つサービスアカウントで動作し、検索層でユーザー単位の認可が行われていない場合、すべてのユーザークエリが実質的に全データにアクセスできてしまいます。これは、他のチャネルではアクセスできないドキュメントも含みます。
3. 検索されたコンテンツを介した間接的なプロンプトインジェクションは、RAG特有の攻撃手法であり、多くのセキュリティチームを驚かせます。 攻撃者はAIシステムへのアクセスを必要とせず、RAGパイプラインがインデックスするリポジトリに悪意あるドキュメントを配置するだけでよいのです。そのドキュメントが正規のクエリで検索されると、埋め込まれた指示がAIのコンテキスト内で実行されます。
4. RAGパイプラインへのバルク列挙攻撃は、クエリ単位の監視だけでは検知が困難です。 各クエリ自体は正当なものに見えるためです。検知には、ユーザー単位の検索ボリュームのベースライン設定、セッションをまたいだ集約分析、全クエリ履歴を横断的に分析できるリアルタイムSIEM連携が必要です。
5. 防止と検知の両方が不可欠です。 防止策（リクエスト単位のRBAC/ABAC、機密ラベル強制、レート制限）は被害範囲を限定します。検知策（リアルタイムSIEM連携、検索ボリュームアラート、クエリパターン分析）は、防止策だけでは止めきれない流出試行を捕捉します。どちらか一方だけでは不十分です。

RAGがデータに実際に何をしているか — なぜセキュリティチームは見落とすのか

Retrieval Augmented Generationは、ドキュメントコーパスをベクターデータベースにインデックス化し、クエリをベクトル埋め込みに変換し、インデックス内で最も意味的に近いドキュメントを検索し、それらをクエリとともにAIのコンテキストウィンドウに渡します。AIは検索された内容に基づいて回答を統合・生成します。ユーザー体験としては、組織のドキュメントを熟知したスマートアシスタントのように見えます。

データアクセスの観点では、ユーザーのクエリが検索パターンに変換され、そのパターンがインデックス化されたコーパスに照合され、最も関連性の高いドキュメントが抽出され、生成AIモデルに渡されて内容が統合・返却される、という流れです。このパイプラインのすべての段階で機密データにアクセスしています。ベクターインデックスにはインデックス化された全ドキュメントの意味的表現が含まれ、検索ステップではドキュメント内容にアクセス・転送し、AIのコンテキストウィンドウには回答生成中その内容が保持されます。最終的な回答には、ユーザーが本来アクセス権のないドキュメントの内容が反映される場合もあります。

AI層（モデル、レスポンスフィルタリング、プロンプト設計）だけをレビューし、検索層をインフラとして扱うセキュリティチームは、システムの危険性の低い部分しか見ていません。検索層こそがデータガバナンスの有無を左右する場所です。AIが機密情報の出力を拒否しても、すでに検索層でデータが取得されAIのコンテキストに渡っていれば、ガバナンスの失敗はその時点で発生しています。

RAGパイプラインが流出経路となる5つのパターン

RAGパイプラインがデータ流出を可能にする経路は、すべてのデフォルト導入に影響する構造的設計上の欠陥から、意図的な攻撃者による高度な攻撃まで多岐にわたります。いずれも正しいアーキテクチャで防止可能ですが、主要なRAGフレームワークのデフォルト設定では防止されていません。

多くのRAGパイプラインに共通する構造的欠陥

5つの流出経路のうち、過剰な権限付与による検索は最も蔓延しており、それがデフォルトとなっています。広範なリポジトリアクセス権を持つサービスアカウントでRAGパイプラインを構築し、ユーザーの認可に関係なく最も意味的に近いドキュメントを返す関連性ベースの検索は、追加設定不要ですぐに動作し、検索品質も高くなります。なぜなら、ユーザーごとのサブセットではなく全コーパスを検索するからです。

しかしその分、アクセス制御が犠牲になります。ユーザー単位の認可強制がない関連性ベース検索システムは、ユーザーが閲覧を許可されているドキュメントではなく、クエリに関連するドキュメントを検索します。両者は一致しません。「Q3の業績」で検索すれば、ユーザーが本来求めていた要約だけでなく、取締役会レベルの機密文書も同様にヒットする可能性があり、検索システムはその区別ができません。

対策には、検索層でリクエスト単位のRBAC/ABACを強制する必要があります。これは事後フィルタリングではなく、ユーザークエリごとに検索システムが返してよい範囲を制約するものです。事後フィルタリング（すべて取得してからユーザーが閲覧できないものを除外）は、フィルタ適用前に機密ドキュメント内容がAIのコンテキストウィンドウに渡ってしまいます。事前認可スコープ（ユーザーが閲覧可能なものだけを検索）は、そもそも機密ドキュメントがAIのコンテキストに入らないようにします。この違いはアーキテクチャ上極めて重要です。事後フィルタリングは出力制御、事前認可スコープはアクセス制御です。

間接プロンプトインジェクション：自社ドキュメント経由で届く攻撃

直接的なプロンプトインジェクション（ユーザーが自分のクエリでAIを操作しようとする）はよく知られており、入力バリデーションやシステムプロンプト設計で比較的よく対策されています。一方、RAGの検索層を介した間接プロンプトインジェクションは理解が進んでおらず、対策も困難です。なぜなら、攻撃経路が組織が信頼しているデータソースそのものだからです。

攻撃の仕組みはこうです。RAGパイプラインがインデックスするリポジトリ（共有ドライブ、ドキュメント管理システム、コラボレーションプラットフォームなど）に、AIが指示として解釈するような埋め込み命令を含むドキュメントを攻撃者が作成します。正規ユーザーのクエリでそのドキュメントが検索されると、埋め込み命令が他の正規コンテンツとともにAIのコンテキストウィンドウに到達し、AIがそれを実行してしまう場合があります。これにより、他の検索ドキュメントの出力や外部エンドポイントへのデータ送信、ユーザーが意図しないアクションが実行される可能性があります。AIから見れば、信頼されたデータソース経由で命令が届いたことになるため、指示に従ってしまうのです。

この攻撃のデータ損失防止上のインパクトは大きく、AIシステムや検索インフラ、ユーザーアカウントを侵害する必要はありません。インデックス対象リポジトリにドキュメントを追加できる権限があれば十分であり、多くの組織でこの権限は広く分散しています。SharePointにアクセスできる契約社員、共有コラボレーションスペースにアクセスできる顧客、処理キューにドキュメントを提出できるベンダーなど、すべてが潜在的なインジェクション経路となります。

コーパス整合性管理（ドキュメントソースの検証や埋め込み命令パターンのインデックス前スキャン）は、このリスクを大幅に低減します。また、取得コンテンツに基づいてAIが実行できる命令を制限するゼロトラストデータ交換アーキテクチャも有効です。しかし、いずれもリスクを完全には排除できません。そのため、異常な出力パターン（生データのダンプ、base64エンコード、疑わしい構造化データなど）を監視することが必須の検知レイヤーとなります。

従来型DLPがRAG流出を見逃す理由

成熟したデータ損失防止（DLP）プログラムを持つ組織は、これらのコントロールがRAGパイプラインの出力にも有効だと考えがちですが、実際には多くの場合、最も明白なケースしか検知できず、体系的な流出は見逃しています。

従来型DLPは、正規表現やキーワードマッチング、ファイルタイプ識別、コンテンツフィンガープリントなどのデータパターンに基づいて動作します。たとえば「CONFIDENTIAL」とラベル付けされたファイルの外部メール添付や、社会保障番号パターンの外部送信などは検知できます。しかしRAGパイプラインの出力はこれとは異なります。AIが検索コンテンツを自然言語で要約・分析・解説として統合するため、機密文書の情報がパラフレーズされた文章や提案、複数段落に分散して含まれることがあります。構造化された機密データを探すパターンマッチング型DLPでは、こうした統合コンテンツの可視性は限定的です。

特にバルク列挙攻撃は、各クエリ・レスポンスが完全に正当なものに見えるため、DLPを回避します。攻撃を示すパターンはコンテンツではなく行動（クエリ数、クエリ語句の体系的変化、複数セッションにまたがる累積データアクセス）です。これを検知するには、検索層での監査ログ分析、ユーザー単位のベースラインモデル化、セッション横断のSIEM連携など、DLPより上流の機能が必要です。

検知コントロール：リアルタイム監視が捕捉すべきもの

RAG流出が通知義務を引き起こすタイミング

CISOやコンプライアンス担当者がRAG関連インシデントで最も誤解しやすい規制上の論点は、「AIパイプライン経由のデータアクセスが従来型データ侵害と同じ通知義務を引き起こすか」です。HIPAAとGDPRのいずれにおいても、保護対象データへの不正アクセスが発生した場合、アクセス経路に関係なく通知義務が発生します。AIパイプラインは免責にはなりません。

より実務的に重要なのは、組織がアクセス範囲を特定できるかどうか、つまり「どの記録が、誰のセッションで、どの期間に取得されたか」を把握できるかです。ここでRAGの監査証跡のギャップが通知リスクとなります。HIPAAの侵害通知では、該当するPHIと、可能であればアクセスされた個人を特定する必要があります。GDPR通知では、侵害の性質、該当データ記録のカテゴリと概算件数の説明が求められます。RAGパイプラインがサービスアカウント単位のログしか残しておらず、ユーザー・ドキュメント単位の検索履歴がなければ、最大範囲で過剰通知するか、不完全なデータで過少通知するかの選択を迫られます。いずれも規制上許容されませんし、後者のコンプライアンスリスクは重大です。

AIシステムID・認証ユーザーID・取得ドキュメントをすべて記録する完全な監査ログ（二重帰属）は、正確な通知を可能にする基盤であり、通知義務不履行に対する規制対応の根拠にもなります。コンプライアントな監査ログを生成するRAGパイプラインは、単なる優れたセキュリティツールではなく、ガバナンス可能性が証明できるシステムです。

KiteworksによるRAG検索層のセキュリティ対策

多くのRAG導入環境でのセキュリティギャップはAI層ではなく、ドキュメントがアクセス・抽出されAIのコンテキストに渡される検索層にあります。このギャップを埋めるには、RAG検索コンポーネントをガバナンスされたデータアクセスシステムとして扱い、大規模な機密データに触れる他のシステムと同じく、リクエスト単位の認可、機密ラベル強制、レート制限、完全な帰属情報付きリアルタイム監視を適用する必要があります。

Kiteworks AI Data Gatewayおよびプライベートデータネットワークは、RAGパイプライン向けに各流出経路に直接対応するガバナンスされた検索層を提供します。リクエスト単位のRBAC/ABAC認可は検索層で強制され、事後フィルタリングではなく事前のアクセス制約として機能します。

ドキュメントがAIのコンテキストに入る前に、Kiteworks Data Policy Engineが認証ユーザーのアクセス権を評価します。認可されない場合、そのドキュメントは検索されませんし、取得後に除外されることもありません。データ分類ラベルや機密ポリシーも同じ層で評価され、「Restricted」とマークされたドキュメントは、必要な認可を持たないユーザーのクエリには、意味的関連性が高くてもAIコンテキストに到達しません。

データゲートウェイで強制されるレート制限により、ユーザー・セッション単位の検索ボリュームが上限設定され、バルク列挙攻撃は運用後検知ではなくアーキテクチャ上で制限されます。すべての検索操作（クエリ、取得ドキュメント、ユーザーID、認可判断、タイムスタンプ）はKiteworks監査ログに記録され、SIEMとリアルタイム連携されます（バッチ処理や遅延なし）。

セキュリティチームは、AIシステムと人間ユーザーの二重帰属で、すべてのRAG検索イベントをリアルタイムで把握できます。ファイル共有、マネージドファイル転送、セキュアメールなど全社的なゼロトラストデータ交換フレームワークは、すべてのRAG検索にも拡張され、AIアシスタントを駆動するパイプラインも他のデータチャネルと同じセキュリティポスチャーでガバナンスされ、特別扱いされることはありません。

RAGパイプラインが流出経路として悪用できないことを、取締役会・監査人・規制当局に証明する必要があるCISOやコンプライアンス担当者には、Kiteworksがその証明を可能にするガバナンスされた検索層を提供します。実際の動作をご覧になりたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  手頃なAIプライバシー保護のためのゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：91%の中小企業が2025年にデータセキュリティでロシアンルーレットをしている理由
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」を問うのをやめた。今は「機能している証拠」を求めている。