■ はじめに：RAGが便利なほど“ガバナンスの重さ”は増す
Day1〜Day14で繰り返し触れてきたように、生成AIの攻撃面は 「AI自身」だけでなく「AIが読むデータ」まで広がる のが特徴です。
特に RAG（Retrieval-Augmented Generation）は、
- AIが参照する社内文書の質
- 文書の真正性（改ざんされていないか）
- 文書へのアクセス権
- 文書の更新履歴
- AIがどの文書を使って回答したか
——これらすべてが安全性に影響します。
RAGは“検索＋生成”である前に、“ガバナンスが整備された文書システム”の上に成り立つ仕組みです。ここが弱いまま導入すると、「AIが勝手に機密を漏らす」ように見える事故が起きます。
この記事では、そのガバナンスの柱となる
- 権限管理（RBAC）
- Lineage（出典追跡）
- 監査ログ設計
を実務者の視点で整理します。
1. RAGにおけるガバナンスの重要性
RAGの構造を整理すると見えてくるのは、
“AIがアクセス可能なデータ ＝ ユーザーがアクセスできる範囲を超えることがある”
という厄介な性質です。
たとえば：
- 人事用フォルダ（給与評価など）
- 経営企画フォルダ（未公表の計画）
- 研究部門フォルダ（知財性の高い資料）
RAG ボットに“参照可能”として取り込むだけで、権限外のユーザーでも質問を通じて機密情報を引き出す可能性があります。
これは実際に海外、国内で発生している典型的な “RAG Leakage” 事故です。
したがって、RAG導入では データガバナンス＝セキュリティの中核になります。
2. RBAC（Role-Based Access Control）：誰がどの文書を検索できるか
RAGの権限管理でまず必要なのは、“検索可能な文書を、ユーザーごとに明確に制限すること”。
◆ 実務で効果が高い RBAC の実装方法
① 社内文書へのメタデータ付与
例：
| 英語キー | 日本語ラベル（現場でよく使われる表現） |
|---|---|
department: HR |
所属部門：人事部 |
confidentiality: high |
機密区分：高機密 |
access_group: sales-team |
アクセス許可グループ：営業チーム |
doc_type: policy |
文書種別：社内規程 |
このメタ情報を ベクトルインデックスに組み込み、検索時にフィルタリングします。
② インデックスの分割（高機密領域の隔離）
- 一般文書用インデックス
- 高機密文書用インデックス
- 経営層・研究部門専用インデックス
インデックス自体を物理的に分け、アクセス可能なインデックスを認可制にする。
→ RAG Leakage を最も強力に防げる。
③ SSO / LDAP / Azure AD と連携
RAGシステムは 企業の認証基盤と必ず統合すべきです。
- Active Directory のグループ属性
- Azure AD のロール
- Google Workspace のグループ
これらから “ユーザーが閲覧可能な文書タグ” を自動的に決定します。
AIが参照する文書＝人間が通常アクセスできる文書に制限するのが基本方針。
3. Lineage（出典追跡）：AIがどの文書を使って回答したか
RAGには “回答は正しいように見えるが、どの文書が根拠かわからない” という固有の課題があります。
Lineageは、この問題を解決し、
- 誤情報の発生源の特定
- 文書更新時の影響調査
- 機密情報漏洩の原因調査
- コンプライアンス監査
を可能にする“AI時代の出典管理”です。
◆ Lineage 設計の実務パターン
① 回答ごとに「参照文書ID＋バージョン」を保存
例：
answer_id: 2025-03-01-1432
sources:
- doc_id: HR-2023-Policy.pdf
version: v7
score: 0.82
- doc_id: benefits-summary-2024.md
version: v2
score: 0.65
これにより、
- どの文書が回答に影響したか
- どの程度関連度が高かったか
を後から完全に追跡できる。
② 文書更新時の“再評価”
文書を更新すると、過去の回答の前提が変わる場合があります。
Lineageを持っていれば：
- 該当回答を再生成
- 古い回答をアーカイブ
- ユーザーに修正通知
などの運用が可能。
③ セキュリティ事故時の“出典逆引き”
たとえば：
- RAGが誤って「給与レンジ」を回答した
→ その回答が参照した文書を即座に特定
→ 文書の権限設定ミスを発見
→ 再発防止へ
Lineageは AI ガバナンスのトレーサビリティを支える基盤。
4. 監査ログ：すべての問答の“証跡”を残す
監査ログは、RAG システムにおける“ブラックボックス化”を避けるための最後の砦。
◆ 記録すべき主要項目
① Who（誰が）
- ユーザーID
- 部署/ロール
② What（何を質問したか）
- ユーザー入力（必要に応じてPIIマスキング）
③ How（どう解釈されたか）
- ベクトル検索の結果
- ヒットした文書ID・スコア
- フィルタリング条件
④ Why（どの情報を使って回答したか）
- Lineage（参照文書一覧）
⑤ Result（どの回答を返したか）
- LLM 出力（機密情報は伏字またはマスク）
◆ 監査ログが役立つシーン
- 権限外アクセスの検出（“疑似情報漏洩”の早期発見）
- 誤回答の説明責任
- 内部統制・外部監査の対応
- 異常使用（シャドーAI含む）の早期発見
まとめ：RAGは“検索精度”より“ガバナンス設計”が先
RAG導入で最も多い誤解は、
「まずRAGを作って、後で権限を考える」
という順番です。
実際には、逆で 先にガバナンス（RBAC / Lineage / 監査）を確立しないと、RAGは安全に運用できない となります。
RAGは企業のナレッジを高速化する強力な武器ですが、その分、
- 誤回答が“もっともらしく”広がる
- 権限境界が曖昧になる
- 参照した情報が辿れず説明責任が果たせない
といった事故も増えています。
本記事は、ナレッジコミュニケーションによる生成AIセキュリティ支援の実務知見をもとに執筆しています。
安全にAIを活用するための導入支援・運用設計をご希望の方は、ぜひご相談ください。
👉 AIセキュリティ支援サービス