このテーマを今提示する理由
社内RAG1は、社内文書を検索して生成AIの回答に反映できる便利な仕組みです。一方で、導入時にデータ境界や権限設計を曖昧にしたまま進めると、検索基盤が機密文書を横断してしまうリスクがあります。OWASP Top 10 for LLM Applications 2025では、RAGやベクトルDB2に関するリスクがLLM08 Vector and Embedding Weaknessesとして独立項目になりました。OWASP LLM Top 10は、アクセス制御不備、テナント間漏えい、埋め込みからの復元、データポイズニングを主要リスクとして整理しています。
社内RAG構築前の10の設計観点
| 層 | 見るもの | 失敗例 |
|---|---|---|
| データ | 文書区分とオーナー | 共有フォルダを丸ごと投入 |
| 権限 | ユーザー本人の取得権限 | 全員が同じ検索結果を見る |
| 監査 | 根拠表示とログ | 回答だけ残り追跡できない |
以下は、RAG基盤を作る前にCISO・情シス・法務・データオーナー3でそろえておきたい10観点です。単なる機能一覧ではなく、後から直しにくい設計判断をどの順番で固めるか、というレビューの流れとして読みます。
1. データ境界: まず、RAGに投入する文書群を部門・職位・契約・個人情報の区分で分けます。確認するものは、対象フォルダ一覧、機密ラベル、共有範囲、文書オーナーです。共有フォルダを丸ごと取り込む運用は、最初の実証実験では速くても本番化の負債になります。
2. 取得権限: 次に、検索時にユーザー本人の権限で文書を取得する設計にします。確認するものは、SSOグループ、文書取得APIの権限判定、テストユーザー別の検索結果です。OWASPはLLM06 Excessive Agencyで、下流システムの認可判断をLLMに委ねないことを重視しています。
3. ベクトルDB分離: 部署別・顧客別・機密区分別に、ベクトルDBのパーティションを分ける前提を置きます。言い換えると、人事文書と営業資料を同じ検索箱に入れない設計です。確認するものは、索引の分割単位、テナントID、検索時のフィルタ条件です。LLM08が指摘するCross-Context Information Leaksは、マルチテナントや権限差のある社内検索で起きやすい論点です。
4. 投入前レビュー: 学習・索引化してよい文書の基準を、データオーナーが承認する流れにします。確認するものは、投入申請、承認者、除外文書の基準、更新時の再承認ルールです。NIST AI RMFのMAP機能は、AIシステムの文脈、利用目的、リスク許容度を先に特定する考え方です。NIST AI RMFのGOVERN/MAPを社内RAGにも当てはめます。
5. 個人情報と秘密情報: 個人情報、営業秘密、契約上の秘密、未公開財務情報は、投入前処理と取得時の権限判定で扱います。確認するものは、個人情報を含む文書、契約上の秘密保持条項、未公開情報の保管場所です。機密情報はプロンプトで隠すのではなく、取得対象から外すか、取得時に止める設計が現実的です。
6. 毒性混入対策: 白文字、隠し指示、古い手順書、外部から持ち込まれたPDFは、索引化前に検査します。確認するものは、外部由来文書、更新停止した手順書、不可視テキスト、文書内の命令文です。OWASPはLLM01 Prompt Injectionで、外部文書から指示が混入するIndirect型を明示しています。
7. 回答根拠表示: 回答には、参照文書名・版・更新日・抜粋範囲を表示します。確認するものは、回答画面の出典表示、文書ID、版番号、更新日、引用範囲です。根拠を出せないRAGは、便利な会話UIであっても監査可能な業務基盤にはなりにくいです。
8. ログと追跡性: 誰が、いつ、何を検索し、どの文書が回答に使われたかを記録します。確認するものは、ユーザーID、質問文、取得文書ID、回答ID、管理者の閲覧権限、保存期間です。NIST SP 800-53 Rev.5のAUファミリーは監査ログ、ACファミリーはアクセス制御、SCファミリーは通信・境界保護を扱います。NIST SP 800-53 Rev.5の考え方を、RAGの検索・生成ログにも引き寄せます。
9. 出力検証: 回答をそのまま業務実行に使わせず、重要操作では人間承認や二重確認を入れます。確認するものは、回答の利用禁止事項、承認が必要な業務、誤回答時の報告先です。OWASPのLLM05 Improper Output Handlingは、LLM出力を信頼済み入力として扱う危険を指摘しています。
10. 停止と退役: 誤回答、漏えい疑い、文書更新、権限変更が起きたときに、索引の再作成や一時停止ができる状態にします。確認するものは、停止権限者、連絡先、索引再作成手順、影響範囲の確認方法です。NIST AI RMFのMANAGE機能は、残余リスクの文書化、対応、復旧、コミュニケーションを扱います。
どう活用するか
最初の会議では、10観点を一度に完璧に決め切るより、判断を保留している領域を見える化するのが現実的です。データ境界、取得権限、ログの3点は後から直すと設計変更が大きくなります。PoCの段階でも、この3点だけは先に決めておくと、経営層への説明がかなり楽になります。
実務では、RAGの文書登録を情シスだけで抱えないことも重要です。人事文書は人事、契約書は法務、設計資料は開発部門がデータオーナーとして責任を持ち、情シスはアクセス制御と監査ログの仕組みを提供する分担が望ましい状態です。RAGは検索体験の改善に見えますが、実態は社内データガバナンスの再設計です。
一枚要約
- 何が起きているか: 社内RAGは、社内文書の利活用を進める一方で、権限差のある情報を横断検索してしまうリスクを持ちます。
- 自社への影響: 情報漏えいだけでなく、古い手順書や毒性混入文書による誤った業務判断にも及びます。
- 打つべき手: データ境界、取得権限、監査ログをPoC前に決め、RAGを業務検索ではなく統制対象のAIシステムとして扱います。
今日着手できる3アクション
- 文書棚卸し: 最初の対象フォルダを1つ選び、文書オーナー、機密区分、更新日、閲覧可能ロールを表にします。Microsoft 365ではPurviewの機密ラベルが利用できる環境か、Google Workspaceでは共有設定とDrive監査ログを確認できる権限があるかを見ます。
- 権限テスト: 一般社員、管理職、法務、人事など3〜5ロールのテストユーザーを作り、同じ質問で取得文書が変わるかを確認します。変わらない場合は、RAG側ではなく文書取得APIやベクトルDBの分離設計を見直します。
- 根拠表示の必須化: 回答UIに参照文書名、版、更新日、該当抜粋を表示する要件を追加します。出典を出せない回答は、業務判断ではなく参考回答として扱うルールにします。
AI×セキュリティの観点
RAGは「AIが社内文書を読めるようになる」だけではありません。攻撃者の視点では、文書に隠し指示を混ぜるIndirect Prompt Injection4、古い手順書を参照させるデータポイズニング、権限差を越えた検索結果の漏えいが狙い目になります。承認外の個人アカウントで社内文書を読み込ませるシャドーAIも、同じデータ境界の問題として扱う必要があります。防御側はモデルの賢さよりも、取得前の権限判定、根拠表示、ログ追跡、停止手順を設計できているかで安全性が決まります。
用語ミニ解説
- RAG — Retrieval-Augmented Generationの略です。生成AIが回答前に社内文書や外部データを検索し、その結果を根拠として回答する構成です。 ↩
- ベクトルDB — 文書を数値ベクトルに変換して類似検索するデータベースです。権限境界を無視して索引化すると、検索結果から機密情報が漏れるリスクがあります。 ↩
- データオーナー — 文書やデータの利用可否、保持期間、共有範囲に責任を持つ部門・役割です。RAGでは情シスだけでなく業務部門の関与が欠かせません。 ↩
- Indirect Prompt Injection — ユーザーが直接入力するのではなく、AIが読む文書やWebページに攻撃指示を埋め込む手口です。RAGでは取り込み文書が攻撃面になります。 ↩
次に読むべきトピック
- OWASP LLM Top 10のLLM08 Vector and Embedding Weaknessesを確認すると、RAG固有の漏えい・毒性混入リスクを整理できます。
- NIST AI Risk Management FrameworkのGOVERN/MAP/MANAGEを読むと、PoCから本番化へ進むときの責任分界を設計しやすくなります。
- OWASP Generative AI Security Projectは、RAGがエージェントやツール実行とつながる場合の次の論点を追う入口になります。
コメント