解説

RAGとセキュリティ ― 社内文書をAIに読ませる時のリスク

admin · · 最終更新 2026年5月17日 · 16 min read

Picsum ID: 630

RAG（Retrieval-Augmented Generation）は、LLMに社内文書を検索・参照させて回答精度を高める実装パターンとして、2020年のLewisらの論文[1]以降、急速に企業導入が進んだ。しかし「社内の全文書をAIに読ませる」という設計は、アクセス制御・個人情報保護・秘密情報管理の観点で新たな攻撃面を生む。Microsoft 365 CopilotのOversharing問題[2]、OWASP LLM Top 10 v2.0が新設した「Vector and Embedding Weaknesses（LLM08:2025）」[3]、MITRE ATLASのRAG関連テクニック[4]——これらは、RAG導入が単なる精度問題ではなく、経営レベルの情報統制課題であることを示している。本稿ではCISO・情シス・経営層が押さえるべきRAGセキュリティの論点を整理する。

RAGの基本構造と権限の落とし穴

RAGの基本パイプラインは、(1)社内文書をチャンク分割しEmbeddingモデルでベクトル化、(2)ベクターDBに格納、(3)ユーザープロンプトを同様にベクトル化して類似検索、(4)ヒットした文書片をコンテキストとしてLLMに渡し回答生成、という4段構成である[1]。この構造の致命的な落とし穴は、「検索結果のフィルタリングが権限モデルを超える」点にある。元のSharePointやGoogle Driveでは、ユーザーごとにACLが効いて閲覧不可だった文書も、ベクターDBに一括取り込みした瞬間、Embeddingベクトルとしてテナント全体に露出する可能性がある。Microsoftは公式にこの問題を「Oversharing」と呼び、Copilot導入前にPurviewによる機密ラベル付与と、SharePointのサイト権限棚卸しを強く推奨している[2][5]。特に「社内全員」「Everyone except external users」共有の文書がCopilotで自動的に検索対象になる挙動は、多くの日本企業で想定外のインシデントを誘発してきた[6]。

代表的な攻撃・事故パターン

RAG特有の脅威は4系統に大別される。第一にOversharing / Permissions Inheritance failure——元文書の権限境界がRAGパイプライン内で保持されず、給与表・M&A資料・懲戒記録が検索結果に混入する事故[2][6]。第二にRAG poisoning（間接プロンプトインジェクション）——攻撃者が社内Wikiや共有フォルダに悪意ある指示文を仕込み、RAGが読み込んだ瞬間にLLMが従う攻撃[7][8]。OWASPはLLM01（Prompt Injection）とLLM08（Vector and Embedding Weaknesses）として分類する[3]。第三にEmbedding Inversion——漏洩したEmbedding値から元の平文を再構成する攻撃がMorrisらにより実証されており、短文なら高精度で復元可能[9]。「ベクトルは暗号化の一種」という誤解は危険である。第四にData exfiltration via retrieval——類似検索の挙動を利用しキーワード総当たりで機密文書の断片を推測する攻撃で、MITRE ATLASがRAG固有TTPとして整理している[3][4]。

実被害事例

Microsoft 365 Copilotでは、導入企業において「人事評価シート」「役員報酬リスト」「M&A交渉メモ」が一般従業員にCopilot経由で引用される事象が多数報告され、Microsoft自身が「導入前のOversharing対策」を繰り返し警告している[2][5]。2024年にはVaronis等が顧客調査を公開し、Microsoft 365テナントあたり平均数十万件の機密ファイルが過剰共有状態で、Copilot導入直後にインシデントが顕在化するパターンを報告した[6][10]。Black Hat USA 2024でMichael Bargury氏は「Living off Microsoft Copilot」発表で、Copilotを悪用した社内データ窃取・フィッシング・間接プロンプトインジェクションを実証[7]。ChatGPTでも2023年3月、Redisクライアントライブラリのバグで他ユーザーの会話履歴と支払情報の一部が露出する事故が発生している[11]。いずれも「LLMが賢くなりすぎた」事件ではなく、周辺の権限設計とインフラ運用の失敗である。

ベクターDBのセキュリティ要件

主要ベクターDBのセキュリティ機能には明確な差がある。PineconeはSOC 2 Type II/HIPAA/GDPR準拠、AES-256・TLS暗号化、Namespace論理分離、RBACをマネージド提供する[12]。Weaviateはマルチテナンシーを正式機能として持ち、テナント単位で物理シャード分離が可能、OIDCとAPIキー認証をサポート[13]。QdrantはJWTベースのアクセス制御とペイロードフィルタをサポートし、Qdrant Cloudで暗号化とSOC 2準拠を提供[14]。ChromaはOSS起点で認証・マルチテナンシーが軽量なため、本番採用には前段のAPI Gateway・RBAC実装が前提[15]。選定時の必須確認項目は、(1)保存時/転送時暗号化、(2)テナント分離粒度、(3)メタデータフィルタによるACL強制、(4)監査ログ、(5)キー管理（CMK/BYOK）、(6)削除要求（GDPR第17条）対応の6点。特に「検索時にユーザー権限でフィルタをかける」責任はベクターDBではなくアプリ層にあることを明示的に設計に落とし込む必要がある[12][13][14]。

権限継承の設計論

SharePoint / Box / Google Drive → LLMの権限継承には3パターンある。(A) Index-time filtering：インデックス作成時に公開範囲の広い文書のみを取り込む。実装は容易だが機密文書を活用できない。(B) Query-time filtering：検索実行時にユーザーの所属・権限をメタデータフィルタに変換しベクターDBに渡す。Microsoft Graph、Microsoft 365 Copilotの実装はこの方式で、Microsoft Search Indexの権限情報をクエリ時に評価する[5][16]。(C) Post-retrieval re-check：検索後にソースシステムへ都度権限確認APIを叩く。最も堅牢だがレイテンシが悪化する。LangChain・LlamaIndexはいずれも公式ドキュメントで「RetrieverにAuthorizationを組み込む」ことを推奨しており、ユーザーIDをメタデータフィルタに伝搬する設計例を提示している[17][18]。実運用ではBとCのハイブリッド——平常時はメタデータフィルタ、機密ラベル付き文書のみPost-retrievalチェック——が現実解となる。

チェックリスト

  • RAG対象ドキュメントのACL棚卸しと「社内全員共有」ファイルの機密分類を完了しているか[2][6]
  • ベクターDBのEmbedding値がEmbedding Inversion攻撃で平文復元されうる前提で、保存時暗号化・アクセス制御を設計しているか[9][12]
  • Query-time filteringでユーザーIDと権限メタデータがベクター検索に確実に伝搬する実装になっているか[5][16][17]
  • RAGが読み込む文書に対して、間接プロンプトインジェクションの検出・サニタイズ層（区切りマーカー・コンテンツ検査）を設けているか[3][7][8]
  • 個人情報・機密情報を含む文書の「AI学習・検索からの除外」要求に対応できる、削除・再インデックスの運用フローがあるか[19]

打ち手

第一に、RAG導入の前工程として情報資産の棚卸しと機密ラベリングを行う。Microsoft PurviewやGoogle Drive DLP、Box Shieldなど既存のDLP基盤で機密分類を付与し、RAGインジェスト対象から高機密文書を除外するポリシーを先に確立する[2][5]。第二に、Query-time filteringの強制——Retriever層でユーザーIDと権限クレームを必ずメタデータフィルタに変換する設計パターンを標準化する[17][18]。第三に、プロンプトインジェクション対策として、RAGで取得した文書を「信頼できない入力」として扱い、システムプロンプトと明確に区切り、出力にガードレール（Microsoft Prompt Shields、Llama Guardなど）を挟む[3][20]。第四に、監査とレッドチーム——RAG経由の情報露出を定期的にテストし、MITRE ATLASのシナリオで評価する[4]。

RAGの怖さは、AIが賢いことではなく、権限が甘いこと。

Omamori AI の結論

  1. 事実：RAGはLLM本体ではなくベクターDB・Embedding・権限継承設計が攻撃面であり、OWASP LLM Top 10 v2.0もLLM08として新設した[3]。Microsoft 365 CopilotのOversharing事例は、設計ではなく運用——ACL棚卸し不足——が主因である[2][6]。
  2. 判断軸：RAG導入の可否は「モデルの精度」ではなく「現時点の情報分類とアクセス権限がLLMに委ねるに足るか」で判断する。機密ラベリングが未整備ならRAGはまだ早い。
  3. 打ち手：(a)DLPによる機密分類、(b)Query-time filteringの強制、(c)間接プロンプトインジェクション対策、(d)MITRE ATLAS準拠のレッドチーム、の4点セットを導入前チェックリストとして制度化する[3][4][5]。

経営者視点で考えるべきこと

RAGは情シス・セキュリティ部門だけの問題ではなく、経営層の監督責任に直結する。個人情報保護法第23条は個人データの安全管理措置を義務づけ、ガイドライン通則編は従業者・委託先監督を含む組織的安全管理措置を求める[19]。RAGに個人情報を含む文書をインデックスすれば、LLMプロバイダ・ベクターDBベンダーへの委託先管理責任が発生する。M&A交渉資料・役員報酬・懲戒情報など「組織内でも閲覧権限が分かれる機密」がRAG経由で越境した場合、善管注意義務違反・インサイダー情報管理違反・労務上の不利益取扱いといった多層の法的リスクに発展しうる。経営者は「RAG導入の責任者」「機密分類ポリシーの承認者」「インシデント時の対外説明責任者」を明確化し、技術選定を現場任せにしない体制を構築する必要がある。

参考文献・出典

  1. Lewis, P., et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS 2020. https://arxiv.org/abs/2005.11401
  2. Microsoft. “Microsoft 365 Copilot data protection and oversharing.” Microsoft Learn, 2024. https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-ai-security
  3. OWASP. “OWASP Top 10 for LLM Applications 2025 (v2.0).” 特にLLM01 Prompt Injection, LLM06 Excessive Agency, LLM08 Vector and Embedding Weaknesses. https://owasp.org/www-project-top-10-for-large-language-model-applications/
  4. MITRE. “ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems).” RAG関連テクニック含む. https://atlas.mitre.org/
  5. Microsoft. “Data, Privacy, and Security for Microsoft 365 Copilot.” Microsoft Learn. https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacy
  6. Varonis. “The Great SaaS Data Exposure” / “Microsoft 365 Copilot Security Report.” 2023-2024. https://www.varonis.com/blog/microsoft-365-copilot
  7. Bargury, M. “Living off Microsoft Copilot.” Black Hat USA 2024. https://www.blackhat.com/us-24/briefings/schedule/#living-off-microsoft-copilot-39113
  8. Greshake, K., et al. “Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection.” AISec ’23. https://arxiv.org/abs/2302.12173
  9. Morris, J. X., et al. “Text Embeddings Reveal (Almost) As Much As Text (vec2text).” EMNLP 2023. https://arxiv.org/abs/2310.06816
  10. Concentric AI. “2024 Data Risk Report: The Oversharing Crisis.” https://concentric.ai/
  11. OpenAI. “March 20 ChatGPT outage: Here’s what happened.” 2023. https://openai.com/index/march-20-chatgpt-outage/
  12. Pinecone. “Security and Compliance at Pinecone.” https://www.pinecone.io/security/
  13. Weaviate. “Multi-tenancy” & “Authentication and Authorization” Documentation. https://weaviate.io/developers/weaviate/concepts/data#multi-tenancy
  14. Qdrant. “Security” Documentation (JWT, RBAC, Qdrant Cloud). https://qdrant.tech/documentation/guides/security/
  15. Chroma. “Chroma Deployment & Auth Documentation.” https://docs.trychroma.com/
  16. Microsoft. “Microsoft Graph connectors and Copilot grounding.” https://learn.microsoft.com/en-us/graph/connecting-external-content-connectors-overview
  17. LangChain. “Security” & “Retrieval with per-user access control” Documentation. https://python.langchain.com/docs/security/
  18. LlamaIndex. “Privacy and Security” Documentation. https://docs.llamaindex.ai/en/stable/module_guides/storing/vector_stores/
  19. 個人情報保護委員会. 「個人情報の保護に関する法律についてのガイドライン（通則編）」. https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
  20. Microsoft. “Prompt Shields in Azure AI Content Safety.” https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection
SHARE 𝕏 in f
編集部
Omamori AI 編集部
CISO・情シス・経営層向けに、AIセキュリティの一次情報を編集視点で整理

あわせて読みたい

記事の論点を、自社のリスク評価に

90秒の自己診断 or CISO/情シス向け月次レビュー（顧問契約）でアクションに繋げます。

無料 90秒 自己診断 顧問契約 詳細