■ はじめに：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＋バージョン」を保存

例：

これにより、

• どの文書が回答に影響したか
• どの程度関連度が高かったか

を後から完全に追跡できる。

---

② 文書更新時の“再評価”

文書を更新すると、過去の回答の前提が変わる場合があります。

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セキュリティ支援サービス