■ はじめに：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セキュリティ支援サービス