RAGセキュリティとは?検索拡張生成が機密データに与える影響

検索拡張生成(RAG)を使えば、AIモデルは学習時に得た知識だけでなく、組織が保有する文書やデータベースを参照して質問に答えられるようになります。これこそがRAGの価値であると同時に、導入前に理解しておくべきデータセキュリティ上の課題でもあります。

あらゆるRAGシステムは、本質的には言語モデルとデータソースを接続するパイプラインです。そのデータソースに顧客情報、財務情報、保護対象保健情報(PHI)、CUI(管理対象非格付け情報)といった機密データが含まれる場合、RAGシステムはそのデータへの新たなアクセス経路となり、独自の認証要件、監査証跡義務、そして攻撃対象領域を伴うことになります。RAGの仕組みを理解すること自体は難しくありません。しかし、それを安全に運用するために何が必要かという点で、多くの組織が遅れを取っています。

エグゼクティブサマリー

要点: RAGは、応答を生成する前に外部データソースから関連情報を検索することで、AIモデルの精度を高める技術です。機密情報や規制対象情報を含むデータに対してRAGを導入する組織にとって、検索(リトリーバル)層は、そのデータに触れる他のあらゆるシステムと同等の厳格さで統治すべきデータアクセス制御ポイントです。

なぜ重要なのか: RAGシステムは規制産業全体で急速に導入が進んでいます——医療機関はAIを患者記録に接続し、金融機関はAIを取引データに接続し、防衛関連企業はAIをCUIに接続しています。こうしたデータを規律するコンプライアンスフレームワーク(HIPAA、CMMC、GDPRなど)には、AIに対する適用除外は一切存在しません。RAGシステムが機密データを検索できる場合、そのパイプラインを通じたすべてのアクセスは、他の経路によるアクセスと同じ規制上の義務を負います。しかし多くの組織は、自社のRAG導入がコンプライアンス上適切かどうかを可視化できていないのが実情です。

重要ポイント

RAGは、クエリ実行時に言語モデルを外部データと接続します。 モデルが学習時に取り込んだ知識だけに頼るのではなく、RAGシステムはデータベース、文書リポジトリ、検索インデックスなどの外部ソースから関連文書やデータを検索し、その内容を応答生成前のコンテキストとしてモデルに提供します。これにより、モデルは学習データに含まれていなかった最新情報や組織固有情報、独自情報を用いて質問に答えられるようになります。
データセキュリティの境界線はモデルではなく、検索元にあります。 AIセキュリティの議論は、プロンプトインジェクションやジェイルブレイク、モデルの挙動など、モデル自体に焦点を当てがちです。しかしRAGシステムにとってより重要なセキュリティ境界は検索元です——システムがアクセスできるデータは何か、誰(何)がそれを照会できるのか、返される内容を何が統制しているのか。モデルの挙動が完璧であっても、検索層にアクセス制御がなければ機密データは露出してしまいます。
RAGは、検索対象データが持つコンプライアンス義務をそのまま引き継ぎます。 RAGシステムがPHIを含むデータソースから情報を検索する場合、そのシステムを「AIプロジェクト」と捉えているか「コンプライアンスシステム」と捉えているかに関わらず、アクセス制御、監査ログ、暗号化といったHIPAAの技術的保護要件の対象となります。同じ論理は、CMMCにおけるCUI、GDPRにおける個人データ、その他あらゆる規制対象データ区分にも当てはまります。RAGの導入はコンプライアンス上の免除を生み出すものではなく、既存の義務を引き継ぐ新たなアクセス経路を生み出すものです。
精査されていない検索元は、実質的な攻撃対象領域を生み出します。 RAGシステムが、外部ウェブサイト、検証されていない文書、アクセス制御が不統一な複数の社内リポジトリなど、厳格に精査されていないソースから検索を行う場合、悪意あるコンテンツや権限のないコンテンツを検索・出力するよう操作される可能性があります。セキュリティ研究者はこれを、検索汚染(リトリーバルポイズニング)を介した間接的プロンプトインジェクションと呼んでいます。検索元は、本番システムに供給される他のあらゆるデータソースと同様の厳格さで、信頼性を確保しアクセス制御を行う必要があります。
RAGを守るには、AI層だけでなくデータ層自体を統治する必要があります。 RAG導入を防御可能にする技術的統制は、あらゆる機密データアクセスを統治する統制と同じです。すなわち、検索元への認証済み・最小権限アクセス、基盤データの暗号化、何が・どのクエリによって検索され・誰に返されたかを記録する監査証跡、そして権限のないエンドユーザーに規制対象データ区分が届かないようにする出力フィルタリングです。

RAGの仕組み

RAGシステムは、リトリーバー(検索器)とジェネレーター(生成器)という2つの中核コンポーネントが連携して機能します。

ユーザーがクエリを送信すると、リトリーバーはベクトルデータベース、文書リポジトリ、構造化データベースなどの外部知識ソースを検索し、そのクエリに関連するコンテンツを探します。最も関連性の高い一致結果を、通常はテキストの一部や文書の抜粋として返します。次に、大規模言語モデルであるジェネレーターが、元のクエリと検索されたコンテンツの両方をコンテキストとして受け取り、学習時に得た知識だけに頼るのではなく、検索された情報に基づいた応答を生成します。

このアーキテクチャは、純粋な言語モデル単体が抱える2つの課題を解決します。第一に、知識のカットオフ問題です——特定の時点までのデータで学習されたモデルは、それ以降の出来事を一切知りませんが、RAGシステムはクエリ実行時に最新情報を検索できます。第二に、ハルシネーション(幻覚)問題をかなりの程度まで解決します——モデル内部の(時に誤った)事実表現に頼るのではなく、検索された情報源に基づいて応答を生成することで、RAGは自信満々に事実と異なる回答をする頻度を減らします。ただし、ハルシネーションを完全になくすわけではありません。

RAGがあるからこそ、AIチャットボットは企業の社内規定について正確に答えられ、カスタマーサポートシステムは最新の製品ドキュメントを参照でき、リサーチツールはインターネット全体ではなく特定の文書群から情報を統合できるのです。

なぜRAGはAIアーキテクチャの問題ではなく、データセキュリティの問題なのか

検索ステップこそが、RAGシステムのデータ露出が実際に発生する場所です。システムに送られるすべてのクエリは検索元への照会につながり、その検索元に含まれるあらゆる情報は、システムを照会できる誰に対しても潜在的に露出することになります。

これは、見過ごされがちな特有のリスクを生み出します。すなわち、基盤となるデータソースのアクセス制御は、RAGシステム自体のアクセス制御と少なくとも同等以上に厳格である必要があるということです。なぜなら、RAGシステムは実質的にそのデータへの新たなインターフェースだからです。PHIを含むデータベースへの直接照会を厳格に制限している組織であっても、その同じデータベースを検索元とするRAGシステムを同等のアクセス制御なしに導入してしまえば、同じ規制対象データへの、より統治が行き届いていない新たな経路を作り出してしまうことになります。

この問題は、RAGシステムが複数の混在したソース——規制対象データを含むものと含まないもの、それぞれアクセス制御が不統一なもの——から検索を行う場合にさらに深刻化します。統一的なガバナンスがなければ、社内の一般利用向けに構築されたRAGシステムが、意図せず権限のないユーザーに規制対象データを露出させてしまう可能性があります。検索層が、公開された社内Wikiページと、CUIを含む文書とを区別できないためです。

RAG導入のセキュリティ確保に本当に必要なこと

認証済み・最小権限による検索アクセス。 RAGシステムの検索元へのアクセスは、照会するユーザーやエージェントが実際に閲覧権限を持つ範囲に限定されるべきであり、誰が照会しているかに関わらず基盤データストア全体を検索する包括的な接続であってはなりません。アプリケーション層だけでなく検索層においても属性ベースアクセス制御(ABAC)ポリシーを適用することが、これを実効性あるものにします。

精査・無害化された検索元。 検索元は、ホワイトリスト化され、社内に限定され、アクセス制御が施されているべきであり、検索汚染によってシステムの出力を操作され得るような任意の外部コンテンツに開かれているべきではありません。信頼できる社内文書と検証されていない外部ソースを同じ検索インデックスに混在させることは、RAG導入が不要なリスクを招く最も一般的な要因の一つです。

基盤データソースの暗号化。 RAGシステムが検索を行う対象——ベクトルデータベース、文書ストア、構造化データベースなど何であれ——は、他の機密・規制対象データを保持するシステムと同じ基準で、保存時・転送時ともに暗号化されるべきです。現在の連邦政府基準は、FIPS 140-3認証済み暗号モジュールによるAES-256です。

規制対象データ区分の出力フィルタリング。 検索アクセスが適切に統治されている場合でも、規制対象フィールドや機密情報がエンドユーザーや下流システムに到達する前にブロックする追加の出力フィルタリング層を設けることで、アクセス制御の設定ミスや想定外のクエリパターンに対する多層防御を実現できます。

検索活動の完全な監査証跡。 何が照会され、何が返され、誰によって、いつ行われたかという各検索イベントは、セキュリティ監視とコンプライアンス報告の両方をサポートする形式で記録されるべきです。規制対象データを検索するRAGシステムにとって、この監査証跡こそが、アクセスが適切に範囲設定され監視されていたことを監査人や規制当局に示す証拠となります。

規制フレームワーク別に見るRAGのコンプライアンス上の考慮事項

規制対象データを検索するRAGシステムは、そのデータにアクセスする他のシステムとは異なる基準で評価されるわけではありません——フレームワークの要件はそのまま直接適用されます。

医療(HIPAA)。 ePHIを含むデータソースから検索を行うRAGシステムは、検索パイプライン自体にHIPAAセキュリティルールの技術的保護要件——アクセス制御、監査制御、暗号化——が適用されます。2025年に提案されたセキュリティルール改正がPHIにアクセスするAIシステムにどう影響するかはこちら。

防衛(CMMC)。 CUIを含むデータソースから検索を行うRAGシステムは、他のCUI取扱いシステムと同じNIST SP 800-171の管理策要件——アクセス制御、監査及び説明責任、システム及び通信の保護——を満たす必要があります。KiteworksのCMMCコンプライアンスガイダンスはこちら。

データプライバシー(GDPRなど)。 RAGシステムが個人データを検索する場合、その処理に通常適用される適法根拠、データ最小化、データ主体の権利に関する要件は、RAGの検索と出力にも同様に適用されます。

KiteworksがRAGおよびその他のAIデータアクセスパターンを保護する仕組み

Kiteworksは、実際のリスクが存在する層——応答を生成する言語モデルではなく、RAGシステムが検索を行うデータソース——でRAGセキュリティに対応します。

Kiteworks AIデータゲートウェイは、RAGパイプラインを含むAIシステムと、それらが検索する機密データとの間に統治されたアクセス層を構築します。すべての検索リクエストは属性ベースアクセス制御ポリシーに基づいて認証され、RAGシステムが照会するユーザーやエージェントが実際に閲覧権限を持つデータのみを検索できるようにします。ゲートウェイを通じてアクセスされるデータは、顧客が管理する暗号鍵を用いたFIPS 140-3認証済み暗号モジュールで暗号化され、すべての検索イベントは、Kiteworksのセキュアメール、セキュアファイル共有、マネージドファイル転送チャネルにまたがる、改ざん不可能な統合監査証跡に記録されます。

PHI、CUI、財務記録、その他の機密データ区分といった規制対象データに対してRAGシステムを構築する組織にとって、これは検索層がKiteworksの既存のコンプライアンス体制——FedRAMP Moderate認証、CMMC 2.0レベル2要件への対応、HIPAA準拠の技術的保護措置——をそのまま引き継ぐことを意味します。AIユースケース専用に別のセキュリティアーキテクチャを新たに構築する必要はありません。

貴社固有のコンプライアンス要件に対して、KiteworksがRAGおよびその他のAIデータアクセスパターンをどのように保護できるかをご覧いただくには、カスタムデモをご予約ください。

よくある質問

RAGは、AI言語モデルが応答を生成する前に、データベース、文書リポジトリ、検索インデックスといった外部データソースから関連情報を検索できるようにする技術です。学習時に得た知識だけに頼るのではなく、検索されたコンテンツをコンテキストとして利用することで、モデルは最新情報や組織固有情報、独自情報を用いて質問に答えられるようになり、自信満々な誤答の頻度も減少します。RAGがあるからこそ、AIシステムは一般的な学習知識に基づく推測ではなく、企業の社内文書や規定に関する質問に正確に答えられるのです。

RAG自体は一つの技術であり、それ自体が本質的にリスクというわけではありません。しかし、機密データにアクセスする他のあらゆるシステムと同様に保護すべき新たなデータアクセス経路を生み出します。リスクが生じるのは、検索元に規制対象データや機密データが含まれているにもかかわらず、そのデータを通常統治すべきアクセス制御と同等の対策が欠けている場合です——これは、たとえ直接アクセスする権限を持たないユーザーであっても、RAGシステムへの照会を通じて意図せずデータが露出してしまう可能性があることを意味します。また、精査されていない、あるいは信頼度が混在したソースから検索を行うRAGシステムは、検索元の悪意あるコンテンツを利用してシステムの出力を操作する検索汚染(リトリーバルポイズニング)にも脆弱です。

ファインチューニングは、追加の学習データを用いてモデルの内部パラメータを変更し、モデルの挙動を恒久的に変化させます。一方RAGはモデル自体を一切変更しません——クエリ実行時に関連する外部コンテンツを検索し、コンテキストとして提供するだけで、基盤となるモデルは変わりません。RAGは一般的に導入が速く、更新も容易(検索元を更新すれば再学習なしに即座に反映されます)、透明性も高い(検索された情報源を応答と併せて提示できます)という特長があり、これがAIシステムを組織の最新データと接続する際により一般的なアプローチとされている理由です。

RAGは新たなコンプライアンス義務を生み出すわけではなく、既存の義務を新たなアクセス経路にまで拡張するものです。RAGシステムがePHIを含むデータソースから検索を行う場合、その検索パイプラインは、そのデータにアクセスする他のあらゆるシステムと同様に、HIPAAセキュリティルールの技術的保護措置の対象となります。CUIを含むソースから検索を行う場合は、その経路にCMMCのNIST SP 800-171管理策要件が適用されます。組織はRAG導入を純粋なAI施策として扱いがちですが、AIシステムが検索を行っているからといって、データに紐づく既存の規制上の義務が消えるわけではないという点を見落としがちです。

中核的なリスクに対応する5つの対策があります。第一に、システムが照会ユーザーの権限範囲内のデータのみを検索するよう、検索元への認証済み・最小権限アクセスを実施すること。第二に、検証されていないコンテンツによる検索汚染を防ぐため、検索元を精査・無害化すること。第三に、基盤データソースを保存時・転送時ともに暗号化すること。第四に、規制対象データ区分が権限のない受信者に届かないようにする出力フィルタリングを実施すること。第五に、セキュリティ監視とコンプライアンス報告の両方をサポートする、完全で改ざん不可能な検索活動の監査証跡を整備することです。モデルレベルの保護策のみに頼るのではなく、これらの対策をデータ層で実装する組織こそが、規制当局の精査に耐えうるRAGシステムを構築できます。

リスクとコンプライアンス用語集に戻る