社内RAGのベクターDB権限設計チェックリスト
OWASP LLM08準拠で情報漏洩を防ぐアクセス制御パターン
OWASP LLM08:2025「Vector and Embedding Weaknesses」を出発点に、RAGパイプラインのベクターDB権限設計を実務チェックリスト形式で解説。メタデータフィルタリングと出力マスキングの2段階設計を中心に、情報漏洩リスクを減らす設計パターンを整理します。
社内RAGを業務に導入するとき、多くの開発者・情シス担当者が気にするのは「精度」と「速度」です。一方で、ベクターDBの権限設計は後回しになりがちです。RAG特有のリスクは、従来のAPIアクセス制御とは設計思想が根本から違います。そこに気づかずに社内文書を大量に格納すると、ある部門の社員が、本来閲覧できないはずの別部門の機密文書を、チャットボット経由で取得できてしまう状態が生まれます。
既存の日本語記事は、OWASP LLM Top 10全体の翻訳や、プロンプトインジェクション単体の解説が中心です。本記事はRAGパイプラインのベクターDB権限設計に特化し、OWASP LLM08と2026年のarXiv論文（査読前pre-print）を根拠として、実装チェックリストに落とし込みます。
このガイドの前提条件
- LLMアプリや社内RAGの基本的な仕組み（埋め込み、ベクター検索、コンテキスト注入）を理解している
- 社内文書をベクターDBに格納し、LLMが回答生成に使う構成を前提とする
- セキュリティ観点での権限設計・レビューを担う立場（開発者・情シス・セキュリティ担当）
OWASP LLM08 が定義するRAG固有の脅威
OWASPは2025年版 LLM Top 10 で、LLM08:2025 「Vector and Embedding Weaknesses（ベクターおよび埋め込みの脆弱性）」 を重要リスクとして位置付けています（OWASP LLM Top 10 2025 公式）。
LLM08 が指摘するリスクの核心は、「ベクターDBに格納されたデータが、アクセス制御の網をくぐり抜けてLLMの出力に混入しうる」という点です（OWASP LLM08:2025 詳細）。
具体的には次の3種類の脅威が定義されています。
1. 認可不整合（Authorization Gap）
従来のアクセス制御はリクエスト単位でAPIの前段に置かれます。一方、RAGのベクター検索は「似た意味を持つ文書を取得する」という性質上、アクセス制御を検索ロジックの外に置いていると、ユーザーの権限を問わず関連文書が返ってしまうことがあります。
社内RAGでよくある失敗例は次のとおりです。
- 全社員が同じRAGエンドポイントを使う構成で、ベクターDBのコレクションが部門別に分割されていない
- 権限チェックをアプリ層だけで行い、ベクターDB側のメタデータフィルタが設定されていない
- ユーザーのロール・部門情報を検索クエリに渡していない
2. 埋め込みからの情報逆算（Embedding Inversion）
テキストを埋め込みベクターに変換する処理は不可逆に見えますが、研究では元のテキストに近い情報を復元できる手法が報告されています。ベクターDB自体がAPIとして外部に公開されている場合、埋め込みを繰り返し問い合わせることで格納された文書の断片が推測されるリスクがあります。
3. クロスコンテキスト汚染（Cross-Context Contamination）
マルチユーザー環境で共有コレクションを使う場合、あるユーザーの検索クエリに引きずられて、別のユーザー向けのコンテキストに本来無関係な文書が混入することがあります。
2026年arXiv論文が示すRAA攻撃タクソノミー
2026年3月に公開されたarXiv論文 「Towards Secure RAG: A Comprehensive Taxonomy of Threats and Mitigation Strategies」（arXiv:2603.21654） は、RAGシステムへの攻撃を体系的に分類しています。本論文は現時点で査読前のpre-printであり、今後内容が修正される可能性があります。参考にする際はその点を踏まえてください。
同論文では、RAGへの脅威を「パイプラインのどの段階で起きるか」で整理しています。
| 脅威の段階 | 代表的な攻撃パターン |
|---|---|
| 取り込み前（Pre-Ingestion） | 悪意ある文書の注入、汚染データの混入 |
| 取り込み時（Ingestion） | 埋め込みモデルへの攻撃、チャンク分割の悪用 |
| 取得時（Retrieval） | 権限の横断、クエリ操作による意図外文書の取得 |
| 生成時（Generation） | 取得文書を通じた間接プロンプトインジェクション |
同月公開の 「A Taxonomy of RAG Attacks」（arXiv:2604.08304、2026年4月、同じくpre-print） では、取得段階での権限横断を「最も検知されにくいリスク」として特徴づけており、OWASP LLM08の指摘と整合しています。
これらの論文からの実務的な示唆は「設計レビューはパイプライン全体を通じて行う必要がある」という点です。取り込み段階で適切なメタデータを付与しておかなければ、取得段階でのフィルタリングは機能しません。
2段階フィルタリング設計：取得前と取得後に分けて考える
本記事の最も重要な設計観点がここです。RAGのアクセス制御は「1箇所に挿入するのではなく、取得前と取得後の2段階で設計する」ことが効果的です。
Stage 1：取得前フィルタリング（メタデータフィルタ）
ベクターDB検索を実行する前に、検索クエリにアクセス制御条件を付与する設計です。ベクター類似度検索に加えて、メタデータの等値フィルタ（department == "HR" や access_level <= 2 など）を必ず組み合わせます。
代表的な実装パターンを示します。
# Weaviate の例（概念的なコード）
results = collection.query.near_text(
query=user_query,
filters=weaviate.classes.query.Filter.by_property("department").equal(user.department)
& weaviate.classes.query.Filter.by_property("access_level").less_or_equal(user.clearance_level),
limit=5,
)# pgvector + PostgreSQL の例（概念的なコード）
SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE department = $2
AND access_level <= $3
ORDER BY distance
LIMIT 5;Stage 2：取得後フィルタリング（後処理サニタイズ）
類似度検索が完了した後、LLMへ渡すコンテキストを再度チェックする処理です。Stage 1 が正しく実装されていれば、Stage 2 は二重の安全網として機能します。
典型的な後処理チェック項目:
- 取得文書の
access_levelが現在ユーザーのクリアランス以下か確認 - 機密フラグが立っている文書が混入していないかスキャン
- LLMへ渡すコンテキストに個人識別情報（PII）が含まれていれば、マスキングまたは除外
- チャンクサイズが想定より大きい文書（構造破損の可能性）を除外
# 取得後フィルタリングの概念的なコード
def sanitize_context(retrieved_chunks: list[dict], user: User) -> list[dict]:
safe_chunks = []
for chunk in retrieved_chunks:
if chunk["access_level"] > user.clearance_level:
continue # 権限外の文書を除外
if chunk.get("contains_pii") and not user.has_pii_access:
chunk["content"] = mask_pii(chunk["content"])
safe_chunks.append(chunk)
return safe_chunksこの2段階設計の重要な点は、Stage 1 はパフォーマンスとセキュリティを両立させ、Stage 2 はフェイルセーフとして機能するという役割分担です。Stage 1 だけに依存するのは、単一障害点を作るリスクがあります。
設計チェックリスト：社内RAGを安全に構築するための確認ポイント
以下は、情シス・開発者が社内RAGを安全に構築・レビューするための実務チェックリストです。OWASP LLM08 および arXiv:2603.21654 の推奨事項を参考に構成しています。
A. 取り込みフェーズ
- すべての文書に
department・access_level・created_by・classificationなどのメタデータが付与されているか - メタデータの値は予め定義したスキーマ（enum・数値範囲）に従って検証されているか
- 外部から取り込む文書（メール、Webクロール、外部API）はサニタイズと分類を経ているか
- チャンク分割時に文書の境界をまたいで機密情報が漏れ出さないか確認したか
B. ベクターDB・検索フェーズ
- ベクターDB自体のAPIアクセスは認証・認可されているか（誰でも直接クエリできる状態になっていないか）
- 全検索クエリに、認証済みユーザー情報から生成したメタデータフィルタが付与されているか
- フィルタ条件の組み立てはアプリ側の内部ロジックで行い、ユーザー入力で上書きできない構造になっているか
- マルチテナント環境では、テナントIDを必須フィルタとして検索ロジックに強制できているか
- ベクターDB側でRBAC（ロールベースアクセス制御）またはコレクション分離が設定されているか
C. コンテキスト生成・LLMへの渡し方
- 取得文書をLLMへ渡す前に、権限チェックを再実行しているか（Stage 2フィルタリング）
- PIIが含まれる可能性のあるフィールドはマスキングまたは除外する仕組みがあるか
- LLMへ渡すシステムプロンプトに、回答範囲を制限する指示を含めているか
- LLMが出力した回答に機密情報が含まれていないかを確認するアウトプットフィルタはあるか
D. ログ・監査
- どのユーザーがどのクエリを発行し、どの文書が取得されたかをログに記録しているか
- 通常と異なる取得パターン（大量取得・権限外フィルタの試み）を検知する仕組みがあるか
- ログは改ざん困難なストレージ（別ストレージ・読み取り専用）に保存されているか
- 定期的なアクセスログのレビューを運用フローに組み込んでいるか
E. ベクターDBのアクセス設定
- ベクターDBの管理APIエンドポイントは社内ネットワーク・VPN経由のみに制限されているか
- 埋め込みAPIへのアクセスはサービスアカウント経由で、最小権限で設定されているか
- DBの認証情報（APIキー・接続文字列）はシークレットマネージャーで管理されているか
実務での使い方：段階的な導入アプローチ
社内RAGを既に動かしている場合、全項目の実装は一度にはできません。次のような段階的なアプローチが現実的です。
フェーズ1（〜1ヶ月）：文書の分類と格納ルールの整備
まず既存のベクターDBに格納されている文書のメタデータを棚卸しします。access_level が未設定の場合は「最高機密（最も厳しい制限）」として扱い、メタデータが整備されるまで検索対象から除外する運用が安全です。
フェーズ2（〜3ヶ月）：フィルタ付き検索への切り替え
検索ロジックにメタデータフィルタを組み込みます。このタイミングで、フィルタ条件の組み立てを担うユーティリティ関数をアプリ内に共通化し、「フィルタなしでクエリを実行できるコードパス」をなくす設計にします。
フェーズ3（〜6ヶ月）：ログ監査と異常検知
フィルタが正しく機能していることを確認するために、定期的にアクセスログをレビューします。権限外フィルタのバイパスを試みているリクエストがないか確認し、検知ルールを整備します。
注意点
設計レビュー用プロンプト例
社内RAGの権限設計をレビューするときに使えるプロンプトです。攻撃手順ではなく、防御設計の抜け漏れを洗い出すことを目的としています。
あなたは社内RAGシステムのセキュリティレビュー担当者です。
以下の設計について、OWASP LLM08の観点から確認事項を整理してください。
[システム概要を記入]
- ベクターDBの種類:
- ユーザー認証方法:
- 取り込む文書の種類と機密レベル:
- 検索クエリにメタデータフィルタを付与しているか:
- 取得後のサニタイズ処理:
- ログ・監査の仕組み:
次の観点でリスクと確認ポイントを出力してください。
1. 取り込みフェーズのメタデータ設計の妥当性
2. 検索クエリのアクセス制御設計
3. LLMへ渡すコンテキストのサニタイズ
4. ログ・異常検知の実装状況
攻撃手順ではなく、防御・設定確認・リスク低減に絞ってください。よくある質問（FAQ）
RAGのベクターDB権限設計 よくある質問
設計・実装で迷いやすいポイント
ベクターDBのコレクションを部門ごとに分けるだけで十分ですか？
コレクション分離は有効な対策の一つですが、それだけでは不十分な場合があります。同一部門内でも役職や契約種別によって閲覧権限が異なる場合、コレクション分離に加えて access_level メタデータによるフィルタリングも必要です。また、コレクションのAPIアクセス自体を制御しているかも確認してください。
フィルタ付き検索は精度（リコール）に影響しますか？
メタデータフィルタによって検索対象が絞られるため、権限外の文書がヒットしなくなる分、リコール（再現率）は下がります。ただし、これはセキュリティ上の正しい動作です。精度低下として問題が出るのは、メタデータが正しく付与されていないケース（文書の分類誤りや付与漏れ）が多いため、まずメタデータの品質を確認してください。
外部公開RAG（顧客向けチャットボット）でも同じ設計が必要ですか？
はい、むしろ社内RAGより慎重な設計が必要です。外部公開の場合、悪意あるユーザーが意図的にアクセス制御の欠陥を突くことを前提に設計してください。特に、取り込むドキュメントの機密分類と、Stage 2フィルタリングによる出力のサニタイズを重点的に強化することを推奨します。
既存のRAGに後からアクセス制御を追加するのは難しいですか？
メタデータが格納時に付与されていない場合、遡及的な付与が必要になるため手間がかかります。既存システムでは、まず新規格納文書から正しいメタデータ付与を徹底し、既存文書はバッチ処理で順次整備するアプローチが現実的です。整備が完了するまでは「未分類文書は最高制限として扱う」方針を取ると安全です。
OWASP LLM08への対応状況を上司や監査に報告するには何を出せばよいですか？
本記事の設計チェックリスト（A〜Eの各項目）を社内テンプレートに転用できます。各項目に「対応済み・対応中・未対応・対象外」を記入し、未対応の項目には対応予定時期とリスクの評価（影響度・発生可能性）を付記するとレポートとして機能します。OWASPの公式ページ（LLM08:2025）も一次情報として参照先に含めてください。
参考リンク
- OWASP LLM08:2025 Vector and Embedding Weaknesses（公式）
- OWASP LLM Top 10 2025（公式）
- Towards Secure RAG: A Comprehensive Taxonomy of Threats and Mitigation Strategies（arXiv:2603.21654、2026年3月、pre-print）
- A Taxonomy of RAG Attacks（arXiv:2604.08304、2026年4月、pre-print）
- Microsoft Azure: 安全なマルチテナントRAG設計
次に読むおすすめ
この記事でベクターDB権限設計の観点をつかんだら、次は実践編として、AI活用の具体的な進め方を整理したnote記事も参考にしてください。設計の抽象論から、実際のツール選定・運用フローへの落とし込みにつながります。