RAGにおける「コンテキストの過剰共有」問題—個人データが他人の回答に混入するリスク

社内Q&Aボットや FAQ の回答精度を上げるために RAG を導入すると、「個人データの過剰共有」が起こりうる。OWASP Top 10 for LLM Applications 2025 の LLM02:2025（Sensitive Information Disclosure：機微情報の漏洩）に該当し、LLM08:2025（Vector and Embedding Weaknesses）でも RAG 固有のリスクとして挙げられているこのリスクは、設計時の予防が圧倒的に有効だ。本記事ではインシデントの典型的な構造、なぜ既存の ACL では止められないのか、3 つの設計パターンとそれぞれのトレードオフ、そして AITB が実務で勧める「ハイブリッド構成」を、データフローの図解付きで解説する。

1. 何が起きているか — インシデント構造

典型的なシナリオ：

1. 社内向けナレッジ検索ボットを構築
2. RAG のソースとして、過去の問い合わせ履歴・顧客対応メール・社内 Slack ログを投入
3. ベクトル DB（Pinecone / Qdrant / Weaviate 等）にチャンクで格納
4. 別の従業員からの無関係な質問（例：「Java の例外処理について」）の回答に、なぜか他社員の人事評価コメントや顧客の個人情報が引用として混入

これがコンテキストの過剰共有。検索精度を上げるためにチャンクを増やし、関連度の閾値を下げるほど、リスクが高まる設計上の罠がある。

OWASP は Top 10 for LLM Applications 2025 で、出力を通じた PII 等の漏洩を LLM02:2025 — Sensitive Information Disclosure（機微情報の漏洩）として分類している。さらに RAG 固有のリスクとして、同じベクトル DB を複数のユーザー層が共有する環境での文脈漏洩（Cross-Context Information Leaks）を LLM08:2025 — Vector and Embedding Weaknesses に挙げている（2026年8月公開の 2026 年版では、それぞれ LLM02:2026 Sensitive Information Disclosure と LLM09:2026 Vector and Embedding Weaknesses に整理されている）。

実際の発生メカニズム

[ユーザー]: 「Java の例外処理について教えて」
    │
    ▼
[Embedding 化] → ベクトル化
    │
    ▼
[ベクトル DB 検索] → 類似度トップ 10 を取得
    │
    │  ヒット例：
    │  - 「Java の例外処理ベストプラクティス」（FAQ・関連度 0.82）
    │  - 「先日の Java 研修参加者リスト」（人事メモ・関連度 0.71）  ← 漏洩源
    │  - 「Java エンジニア採用面接フィードバック」（人事評価・関連度 0.68）  ← 漏洩源
    ▼
[LLM プロンプトに全て注入] → 「以下の文脈を参考に回答せよ」
    │
    ▼
[LLM 出力] → FAQ 内容を答えつつ、参考に「研修参加者の山田さんが…」と引用

問題は「LLM がたまたま漏らした」ではなく、人事メモが類似度 0.71 で確実にヒットする構造になっていたこと。

2. なぜ既存のアクセス制御で防げないのか

伝統的なファイルストレージなら ACL（アクセス制御リスト）で「誰がどのファイルを見られるか」を制御できる。しかしベクトル DB は次の特性を持つ：

• データはチャンク単位（数百トークン）で格納される
• 元ファイルのアクセス権・分類情報は、投入時に明示しないと失われる
• 類似度検索のため、意図せぬ情報が「セマンティックに近い」と判定される
• LLM のコンテキスト窓に入った瞬間、ロールの区別なく出力に影響する

つまり「RAG のレイヤーは元のセキュリティ境界を貫通する」性質がある。これがファイルレベル ACL がそのままでは効かない理由。

3. 3 つの設計パターン

パターン A：投入前の匿名化（PII Tokenization）

ベクトル DB に投入する前に、PII（個人識別情報）をプレースホルダー化する。回答時に必要なら復元（De-masking）する。

[原文]
山田太郎さん（社員番号 12345）は2026年3月の研修に参加。
評価は B 判定。
    │
    ▼ [匿名化エンジン]
    │
[匿名化後（DBに格納）]
さん（社員番号 ）は2026年3月の研修に参加。
評価は B 判定。
    │
    ▼ [回答生成時、必要なら復元]

メリット：構造変更不要、既存ベクトル DB で動く。 デメリット：すべての PII を漏れなく検出する精度が必要。匿名化の精度がそのまま安全性を決める。

匿名化エンジンの例として、Microsoft 発の OSS である Presidio（現在はコミュニティ運営の Data Privacy Stack へ移管中）がある。格納時ではなく LLM に渡る経路でマスキングする製品もあり、DataSign の AI MONBAN はプロンプトや MCP レスポンスに含まれる PII を AI に渡る前に自動マスキング（復元可能なトークン化を含む）する。

パターン B：チャンク単位の ACL

各チャンクに「誰が見られるか」のメタデータを付与し、検索時にユーザー権限でフィルタする。

# ベクトル DB クエリの例（疑似コード）
results = vector_db.query(
    embedding=query_emb,
    top_k=10,
    filter={
        "$or": [
            { "acl_users": user.id },
            { "acl_groups": { "$in": user.groups } },
            { "acl_public": True }
        ]
    }
)

メリット：ファイル ACL に近い厳密な制御。 デメリット：実装コストが高い、組織変更時のメタデータ更新が困難、フィルタ後に top_k が足りなくなる場合がある。

Pinecone / Qdrant / Weaviate などはメタデータフィルタ機能を持つので、技術的には可能。

パターン C：ユーザー別 / 部署別インデックス分離

「全社共通」「部署別」「個人別」とインデックスを物理分離する。

[ベクトル DB の構成]
├─ index:public-faq         ← 全社員アクセス可
├─ index:dept-sales         ← 営業部のみ
├─ index:dept-hr            ← 人事部のみ
├─ index:user:alice         ← Alice のみ
└─ index:user:bob           ← Bob のみ

検索時に、ユーザー権限に応じて検索対象インデックスを動的に選択。

メリット：シンプル、誤りが起きにくい。 デメリット：データ重複、運用コスト、組織横断の検索ができなくなる。

4. パターン比較表

5. AITB 推奨：ハイブリッド構成（A + C）

実務では次のハイブリッドが最もバランスが良い：

[ユーザー質問]
    │
    ▼
[ユーザー権限を判定]
    │
    ├─ 全社共通インデックス（パターンA：匿名化済み）
    ├─ 所属部署インデックス（パターンC：物理分離）
    └─ 個人インデックス（パターンC）
    │
    ▼ [複数インデックスを並列検索]
    ▼
[結果のリランキング → LLM 入力]
    ▼
[出力時に、必要なら De-masking で PII 復元]

• 全社共通の知識（FAQ、製品マニュアル、技術ドキュメント）はパターン A で匿名化済みで持つ
• 部署別・個人別のセンシティブ情報はパターン C で物理分離
• パターン B は組織変更時の更新コストが大きいため、本当に必要なケース（外部公開ドキュメント DB 等）でのみ採用

6. 設計時のチェックリスト

新しい RAG プロジェクトを評価する際、最低限以下を確認する：

• 投入予定のデータソース全てについて、含まれる PII の種類を洗い出したか
• 匿名化エンジンの再現率（recall）と精度（precision）を測定したか
• チャンク化の前後でメタデータ（出所・分類・所有者）が保持される設計か
• ベクトル DB のメタデータフィルタ機能を確認したか
• 検索結果のログにユーザー ID・取得チャンク ID が残るか
• 組織変更（人事異動・退職・統合）時のデータ更新フローが定義されているか
• PII 漏洩検出時の対応プロセス（インシデントレスポンス）が決まっているか
• LLM の出力側にも PII フィルタ（Outbound Guardrail）を入れているか

7. 既に運用中の RAG の救済

すでに過剰共有のリスクを抱えた RAG が稼働中の場合、止めずに改善する手順：

1. ログ分析：直近 30 日のクエリと取得チャンクを分析、PII 含有チャンクのヒット率を測定
2. 緊急ガード：高リスクチャンク（人事・顧客個別データ）を一時的にインデックスから除外
3. 匿名化バッチ：既存データを匿名化バージョンで再投入（並行運用）
4. 段階切替：クエリを新インデックスに段階的に切替、品質劣化を測定
5. 旧インデックスの削除

「全停止して作り直す」を避けつつ、2 〜 3 週間で安全な構成に移行できる。

AITB への RAG 関連相談の半数以上は、このコンテキスト過剰共有が原因です。設計段階での介入が圧倒的に有効ですが、運用中システムの救済支援も承ります。無料相談 よりご連絡ください。