RAGセキュリティと情報漏洩対策2026｜権限設計・RAGポイズニング・OWASP LLM08への実務対応

RAG（検索拡張生成）で起きる情報漏洩は、大きく2系統に分けると対策の当たりがつく。第一は検索層の権限漏れ（オーバーシェアリング）で、権限をアプリ層でしか掛けず検索時に認可が効かないため、閲覧権のない文書が回答に混入する。第二はベクトル・埋め込み層への攻撃で、汚染データを仕込むRAGポイズニングや、保存ベクトルから原文を復元する埋め込み反転が該当する。OWASPは2025年にこれらを LLM08「Vector and Embedding Weaknesses」 として新設した（出典: OWASP LLM08:2025・参照2026-07-18）。

対策の核は、retrieval-time authorization（検索時認可）で権限を検索段階に前倒しし、機密がプロンプトに入る前に遮断することだ。本記事は、RAG特有の脅威・対策・規制を公開一次ソースから独自にマッピングして中立に整理する。RAGの仕組みそのものはRAGとは何かに譲り、ここでは「どこから漏れ、どう止めるか」に絞る。

なお本記事は特定のベクトルDB・RAGセキュリティ製品を勝たせず中立に整理し、各対策の制約（実装コスト・検索レイテンシ・運用負荷）も利点と同じ粒度で示す。特定ツールや当社サービスへの送客・トライアル訴求は一切しない。当社（YDAIコンサルティング AI編集部）は複数事業で社内RAGを構築・運用してきた立場だが、知見は定性の範囲で述べ、空権威で断定はしない。

RAGの情報漏洩は 検索層の権限漏れ（オーバーシェアリング） と 埋め込み層への攻撃（ポイズニング・埋め込み反転） の2系統に分かれる。前者の主対策は retrieval-time authorization（検索時認可）と row-level security で、権限を検索段階に前倒しする。後者は取り込み検証・保存時暗号化・監査ログで守る。これらは OWASP LLM08:2025「Vector and Embedding Weaknesses」 に整理でき、EU AI Actの高リスク義務（Annex III標準システムは2027年12月2日へ延期）とも接続する（出典: OWASP LLM08:2025／EU AI Act高リスク期限延期分析・参照2026-07-18）。

RAGの情報漏洩は「検索層の権限漏れ」と「埋め込み層への攻撃」の2系統

RAGセキュリティとは何か（定義）

RAGセキュリティとは、検索拡張生成（RAG）の各層——取り込み・ベクトル化・保存・検索・生成——で、機密情報の漏洩とデータの汚染を防ぐ取り組みを指す。LLM単体のセキュリティと異なるのは、「外部知識ソース＋検索」という追加の攻撃面が生まれる点だ。モデルが安全でも、引いてくる文書や保存・検索の経路が弱ければそこから漏れるため、検索と保存の設計まで含めて守る必要がある。具体的には、取り込み（誰のどの文書を入れるか）、ベクトル化・保存（何がどこに残るか）、検索・生成（誰の権限で何を引くか）の各段が、それぞれ独立した点検対象になる。

2系統の脅威マップ早見表（オーバーシェアリング vs ポイズニング／反転）

RAG特有の脅威は、性質の違う2系統に整理できる。系統Aは情報漏洩（本来見えない文書が見える）、系統Bはデータ完全性への攻撃（データを汚す・盗む）だ。

系統	代表脅威	主な発生層	主対策
A：情報漏洩	オーバーシェアリング、クロステナント漏洩	検索・権限	retrieval-time authorization、row-level security
B：完全性攻撃	RAGポイズニング、埋め込み反転、類似度攻撃	取り込み・保存（ベクトル）	取り込み検証、保存時暗号化、監査ログ

系統Aは検索と権限の設計で、系統Bは取り込みと保存の設計で守る。守る場所が違うため、片方だけでは穴が残る。

従来の情報セキュリティ対策では防ぎきれない理由

ネットワーク境界やファイル権限だけでは、RAGは守りきれない。検索がベクトルの類似度で文書を引く構造上、元のドキュメント権限が検索時に自動反映されないからだ。「部長以上のみ閲覧可」の文書でも、ベクトル化してストアに入れた時点で権限情報が切り離されれば、誰の質問にも引かれてしまう。生成AI全般のリスクは生成AIのセキュリティリスクと社内対策に譲り、本記事は検索・埋め込み層に固有の漏洩に絞る。

OWASP LLM08:2025「Vector and Embedding Weaknesses」の5サブ脅威

LLM08:2025が新設された背景とRAGとの関係

OWASP Gen AI Security Projectは、RAGとベクトルDBの普及を受け、2025年版のLLM Top 10で LLM08 を「Vector and Embedding Weaknesses（ベクトルと埋め込みの弱点）」 として新設した（出典: OWASP LLM08:2025・参照2026-07-18）。RAG／ベクトルストア固有の脆弱性に、初めて公式カテゴリが割り当たった。弱点を突かれると、有害コンテンツの注入、出力操作、機密アクセスにつながるというのが公式の位置づけだ。

LLM08が挙げる5つのサブ脅威

公式が列挙するサブ脅威は5類型ある。各1行の定義と、2系統マップのどちらに属するかを添える。

サブ脅威	内容	属する系統
不正アクセス・データ漏洩	権限不備でベクトル／埋め込みに不正アクセスされ機密が漏れる	A：情報漏洩
クロスコンテキスト情報漏洩	マルチテナント共有環境で他利用者の文脈・文書が混入	A：情報漏洩
埋め込み反転	保存ベクトルから原文が復元される	B：完全性・機密
データポイズニング	汚染データを混入し検索結果・出力を操作	B：完全性攻撃
挙動変化	外部知識の統合で基盤モデルの挙動特性が変わる	B：完全性

系統A（情報漏洩）は権限設計で、系統B（完全性）は取り込みと保存の設計で対処する。

オーバーシェアリング対策の核はretrieval-time authorization（検索時認可）と権限設計

オーバーシェアリングとは（アプリ層でしか権限を掛けない失敗）

オーバーシェアリングとは、検索エンジンが本来閲覧権のない文書を回答に出してしまう構造的な失敗だ。権限をアプリ層（UIやAPIの手前）にだけ置き、検索層まで伝播させないために起きる。検索は権限を知らないまま類似文書を引き、生成はそれをそのまま要約する。マルチテナント環境では、これがクロステナント漏洩——他社・他部門の文書混入——に直結する。

retrieval-time authorization（検索時認可）とrow-level securityとは

対策の核が retrieval-time authorization（検索時認可）だ。検索の段階でユーザー権限に応じて文書を絞り込み、機密がプロンプトに入る前に遮断する。実装は row-level security、メタデータフィルタ、アイデンティティ伝播などで行う。OWASPも緩和策として「きめ細かなアクセス制御と権限対応のベクトル／埋め込みストア」を挙げる（出典: OWASP LLM08:2025 緩和策・参照2026-07-18）。ただし権限を検索ごとに評価するため実装コストがかかり、フィルタ条件が増えれば検索レイテンシも伸びる。

権限設計の実装オプションと制約（中立比較）

検索時認可の実装は複数あり、どれも一長一短だ。特定製品を勝たせず、方式ごとの利点と制約を並べる。

実装方式	利点	主な制約
メタデータフィルタ	既存ベクトルストアに追加しやすい	権限更新の反映に遅延、付与漏れで漏洩リスク
セグメント化インデックス（権限単位で分離）	テナント・権限境界が物理的に明確	インデックス数が増え運用・コスト負荷
permission-aware vector store（権限対応ストア）	検索時に認可を一元適用できる	対応製品が限られ移行コスト
ABAC・RBAC（属性／ロールベース制御）	組織の既存権限体系と接続しやすい	設計・維持の運用負荷、細粒度化でレイテンシ増

共通の落とし穴は「権限更新の反映遅延」だ。異動や退職で権限が変わっても、インデックスやフィルタの更新が遅れれば隙に漏れる。ツール権限をエージェントに渡す際の類似の落とし穴はAIエージェントの権限設計の落とし穴に整理した。

RAGポイズニングと埋め込み反転——埋め込み層への攻撃と防御

RAGポイズニング（データ汚染）の仕組みと対策

RAGポイズニングは、汚染文書を知識ソースに紛れ込ませ、検索結果やモデル出力を操作する攻撃だ（出典: OWASP LLM08:2025・参照2026-07-18）。侵入経路は主に三つ——悪意あるインサイダー、出所未検証の外部データ提供元、プロンプト経由の間接注入（Webや文書に仕込まれた指示を検索で取り込む）である。対策は入口で止めることに尽きる。取り込み時の検証パイプライン、出所検証、分類タグ付けで、信頼できないデータを本番インデックスに入れない。

埋め込み反転・類似度攻撃（ベクトルから原文復元）

埋め込み層はデータそのものではないから安全、という思い込みは危うい。埋め込み反転攻撃では、保存済みベクトルから相当量の原文が復元されうると指摘される（出典: OWASP LLM08:2025・参照2026-07-18）。類似度攻撃では、細工クエリで本来意図しない文書を引き出せる。含意は明快で、ベクトルストアも原文と同等の機密として扱う必要がある。ベクトルDB選定の比較観点はベクトルデータベース比較にまとめたが、セキュリティ面ではアクセス制御と暗号化の有無が軸になる。

埋め込み層の防御（アクセス制御・データ検証・監査ログ）

OWASPが挙げる緩和策は系統Bにも一貫している（出典: OWASP LLM08:2025 緩和策・参照2026-07-18）。きめ細かなアクセス制御と権限対応ストア、堅牢なデータ検証パイプライン、検索活動の不変（immutable）な監査ログ、保存時暗号化だ。ただし暗号化は鍵管理と性能の負荷を、監査ログはストレージ増を招く。すべてを完璧にするより、機密度の高いデータから優先適用するのが現実的だ。鍵は定期的に更新し、ストアやログへのアクセスも最小権限に絞ると、万一の際の被害範囲を初手から狭められる。

脅威×対策×規制の独自マッピングとEU AI Act対応（2026年時点）

【独自マッピング表】RAG脅威→OWASP LLM08サブ脅威→対策

ここまでを一枚に統合する。RAGの代表脅威を、OWASP LLM08のサブ脅威・発生層・主対策に対応づけた独自整理だ（公開一次ソースの横断整理・新規実測値ではない）。

RAG脅威	対応するOWASP LLM08サブ脅威	主な発生層	主対策
オーバーシェアリング	不正アクセス・データ漏洩	検索・権限	retrieval-time authorization、RLS
クロステナント漏洩	クロスコンテキスト情報漏洩	検索・保存（マルチテナント）	テナント分離、権限対応ベクトルストア
RAGポイズニング	データポイズニング	取り込み・保存	取り込み検証、出所検証、分類タグ
埋め込み反転	埋め込み反転	保存（ベクトル）	保存時暗号化、アクセス制御
類似度攻撃	不正アクセス・データ漏洩	検索	クエリ監視、不変の監査ログ

（出典: OWASP LLM08:2025 Vector and Embedding Weaknesses・参照2026-07-18／本表はYDAIコンサルティング AI編集部が公開一次ソースを横断整理）。自社のRAGで「どの脅威が未対策か」を左列で確認し、右列の対策が入っているかを点検すればよい。

EU AI Actの適用フローと期限（Digital Omnibusで2027-12-02延期）

規制面では、まず自社の立場を判定する。RAGを自ら開発・提供するなら provider（提供者）、外部システムを業務利用するだけなら deployer（利用者）で義務の重さが変わり、高リスク用途（Annex III）該当かも判定する。施行期限はDigital Omnibusで後ろ倒しされた。

システム区分	当初の適用開始	Digital Omnibus後
Annex III 単独型の高リスクシステム	2026年8月2日	2027年12月2日
Annex I 規制対象製品への組込システム	製品規制に準拠	2028年8月2日

（出典: EU AI Act高リスク期限延期分析・Gibson Dunn／EU AI Act高レベルサマリー・参照2026-07-18）。当初2026年8月2日だったAnnex III標準システムの義務は2027年12月2日へ、Annex I組込製品は2028年8月2日へ延期され、2026年6月にEU理事会が最終承認した。Article 12のログ保持義務はRAGの監査ログ要件と直結するため、猶予は設計前倒しの時間として使いたい。

日本企業が2026年時点で着手すべき最小限のチェック

規制の細部を待たずとも、今すぐ点検できる項目は3つだ。第一に権限を検索時に適用しているか、第二にベクトルストアにアクセス制御と保存時暗号化があるか、第三に取り込みデータの出所検証と検索の監査ログがあるか。ルール整備は生成AIの社内利用ルールの作り方、実装は社内RAGチャットボットの作り方を土台にできる。いずれも特定製品への依存を前提とせず、自社のスタックに合わせて選べばよい。3点は一度に完璧を目指すより、機密度の高い領域から順に潰すのが、投資対効果の高い進め方になる。

まとめ｜RAGセキュリティは「権限を検索時に前倒し」が要

RAGの情報漏洩は、検索層の権限漏れ（オーバーシェアリング）と、埋め込み層への攻撃（RAGポイズニング・埋め込み反転）の2系統に分かれる。前者の要は retrieval-time authorization（検索時認可）で、権限をアプリ層から検索段階へ前倒しすることに尽きる。後者は取り込み検証・保存時暗号化・不変の監査ログで守る。これらは OWASP LLM08:2025「Vector and Embedding Weaknesses」 に整理でき、EU AI Actの高リスク義務（Annex III標準システムは2027年12月2日へ延期）とも接続する。どの対策にも実装コストや運用負荷の制約があるため、機密度の高いデータから順に、権限を検索時に効かせる設計へ寄せるのが現実的な第一歩だ（本記事は2026年7月18日時点の公開一次ソースにもとづく）。

---

RAGの基礎はRAGとは何か、生成AI全般のリスク整理は生成AIのセキュリティリスクと社内対策、社内の運用ルールは生成AIの社内利用ルールの作り方、実装に踏み込むなら社内RAGチャットボットの作り方もあわせてどうぞ。