2026.08.24
RAGセキュリティで守る社内知識基盤の実践策
IT関連
RAGセキュリティは、生成AIに社内情報を参照させる企業にとって欠かせない設計課題です。便利な検索回答機能も、文書・権限・プロンプトを守れなければ、機密情報を出力する新たな入口になり得ます。
RAGは、質問に近い社内文書を検索し、その根拠をLLMへ渡して回答を生成する仕組みです。社内AIナレッジを活用しやすい一方、検索対象、ベクトルデータベース、生成モデルという複数の層に攻撃面が広がります。
本記事では、RAGの処理フローからデータポイズニング、間接プロンプトインジェクション、権限制御、RAG運用の監視までを解説します。RAG構築を安全に進め、継続的なAIセキュリティ対策へつなげる判断軸を得られます。
RAGセキュリティで最初に押さえるべき構造
RAGの安全性は検索から回答までの連鎖で決まる
RAGセキュリティの要点は、検索・生成・提示の全工程を一続きの信頼境界として扱うことです。入力だけを検査しても、検索した文書が不正なら、モデルは誤った指示や秘密情報をもっともらしく回答へ混ぜてしまいます。
基本フローは、文書を分割して埋め込み化し、質問をベクトル化して近い断片を検索し、取得結果をプロンプトへ追加して生成する流れです。したがって、文書保管庫、検索API、LLM接続、回答画面のすべてに制御が必要です。
安全な設計では、質問者のIDと所属、文書の分類、閲覧権限を検索前に照合します。回答の末尾には根拠文書と版数を示し、根拠が不足するときは推測で補わず、回答を保留するルールを設けます。
- 質問者の権限を検索フィルターへ必ず渡す
- 根拠文書・更新日・文書IDを回答とともに記録する
- 根拠不足時は無回答または担当部署への誘導を優先する
脅威モデルを定義して守る対象を明確にする
守るべき対象は、文書本文だけでなく埋め込み、メタデータ、会話履歴、プロンプト、監査ログです。最初に資産とデータ経路を洗い出すことで、どの利用者が何を読み、どこへ出力できるかを説明可能にします。
RAGの敵対者は、外部から様子を見る利用者、攻撃を理解する利用者、権限を持つ内部者などに分けられます。とくに正規の編集権限を悪用できる内部者は、信頼済みの文書経路を通って知識ベースを汚染できるため危険です。
脅威ごとに、機密性・完全性・可用性への影響と、検知方法、責任者を決めます。外部公開チャット、部署限定ボット、複数企業が共用する環境では、同じ質問でも必要な分離水準が異なる点に注意が必要です。
- 機密性：権限外の文書や個人情報を取得・出力させない
- 完全性：悪意ある文書や古い版で回答を誘導させない
- 可用性：大量問い合わせや検索負荷で業務を止めない
生成AI情報漏えいは回答画面の外でも起こる
生成AI情報漏えいは、最終回答だけを確認していても防げません。質問文に貼り付けられた機密情報、外部LLMへの送信データ、検索ログ、障害解析用のトレースにも、秘匿すべき情報が残る可能性があります。
たとえば、閲覧権限のない人事文書が検索候補に混ざれば、モデルが明示的に引用しなくても回答表現へ影響します。クロステナント漏えいを防ぐには、テナントIDを埋め込み後の検索条件ではなく、検索対象を決める段階で強制することが重要です。
保存時と通信時の暗号化、鍵のローテーション、ログのマスキングを組み合わせます。保存データにはAES-256を採用し、ハッシュ検証はSHA-256 minimumを基準にするなど、実装可能な統制へ落とし込みます。
- 会話ログに含まれる個人情報を分類・マスキングする
- 外部サービスへ渡す本文と属性情報を最小化する
- 削除要求時に原本・チャンク・埋め込み・キャッシュを追跡する
RAG構築で埋め込むべき安全設計
信頼できる文書だけを社内AIナレッジへ取り込む
安全なRAG構築は、取り込み対象の選別から始まります。共有ドライブにある全ファイルを自動投入するのではなく、所有者、用途、公開範囲、更新責任者、保持期限が判明した文書だけを社内AIナレッジの候補にします。
取り込み前には、マルウェア検査、OCR結果の確認、秘密情報と個人情報の検出、重複排除を実施します。さらに文書ID、原本URL、版数、承認者、アクセス属性をメタデータとして付与し、後から回答の根拠を追跡できるようにします。
削除済みの規程や失効した契約書が残ると、検索精度だけでなくコンプライアンスも損ないます。削除イベントを原本、チャンク、埋め込み、インデックスへ確実に伝播させ、削除要求に再現性を持って対応する設計が必要です。
- 文書ごとに所有者と承認フローを設定する
- 分類ラベルと閲覧グループをメタデータ化する
- 取り込み失敗・検査保留の文書を隔離する
チャンク設計とベクトル検索RAGを安全に最適化する
ベクトル検索RAGでは、検索精度と情報露出の範囲を同時に設計します。一般的なチャンクサイズは300〜800文字程度で、文脈を保つためのオーバーラップ（10〜20%）を設定します。ただし、機密性が高い文書では章や権限境界をまたぐ分割を避けます。
FAQのような短い文書は200〜400文字、技術文書のような長い文書は500〜1000文字を目安にすると、検索粒度を調整できます。検索時に必要以上の断片をLLMへ渡さないため、Top-K件はK=3〜10程度から評価を始めるのが実務的です。
ベクトルの類似度だけに依存せず、文書権限、更新日、部門、完全一致キーワードを組み合わせます。リランキング後にも権限検査を行い、検索候補の表示、モデルへの投入、回答の引用という各段階で漏えいを止めます。
- チャンクに文書ID・版数・権限・分類ラベルを保持する
- 検索前後の両方でアクセス権を検証する
- 類似度の高い断片でも機密区分により除外する
モデル選定と費用設計に安全性を含める
モデルの性能や単価だけでRAG構築を決めず、送信データの扱いと監査可能性を選定基準に加えるべきです。長文文脈を扱うモデルでは最大200Kトークンまで投入できても、必要最小限の根拠だけを渡す原則は変わりません。
費用は利用量と安全な評価環境の両方を見積もります。API料金はGPT-4oで入力$2.5/100万トークン、出力$10/100万トークンです。埋め込みではtext-embedding-3-small：$0.02/100万トークンという前提も、再インデックス時のコスト判断に役立ちます。
低コストな検証環境では、GPT-4o mini：$0.15/100万入力トークン、$0.60/100万出力トークンを使う選択肢があります。権限外データを本番同様に送らないよう、評価用データを匿名化し、接続先・APIキー・利用上限を分離します。
- 開発・検証・本番でAPIキーとデータセットを分離する
- 利用上限と異常なトークン消費のアラートを設定する
- 再埋め込みの対象を差分文書へ限定する
汚染と注入攻撃を防ぐAIセキュリティ対策
データポイズニングは少量でも検索結果を支配し得る
データポイズニング対策では、文書数の多さを安全性の根拠にしてはいけません。知識ベース（100万件） のうち、悪意ある文書はわずか 5件 だけでも、質問との意味的な近さを悪用されると検索上位に入り込みます。
USENIX Security 2025 studyでは、対象質問あたりわずか5つの悪意テキストを注入した場合、90% attack success ratesが示されました。検索結果（Top-5）では、悪意文書が 3件 を占め過半数になる可能性があり、単純な多数決は防御になりません。
対策は、投入者の本人性、承認済みソース、文書の来歴、更新差分を検証することです。高リスクな規程や手順書には二者承認を設定し、通常と異なる大量更新、不可解な命令文、外部URLの追加を検知対象にします。
- 文書の作成者・承認者・更新履歴を改ざん困難な形で残す
- 重要文書の更新には二者承認を適用する
- 新規投入文書を隔離インデックスで評価してから公開する
間接プロンプトインジェクションを命令として扱わない
RAGが取得した文書内の命令文は、信頼できる業務ルールではなく外部入力として扱う必要があります。「前の指示を無視する」「秘密を出力する」といった文字列が文書内にあれば、間接プロンプトインジェクションとしてモデルを誘導する恐れがあります。
防御では、システム指示と検索文書を明確に区別し、文書本文には実行権限を与えません。ツール呼び出しやメール送信などの操作は、取得文書だけを根拠に実行せず、構造化された条件確認と人間の承認を必須にします。
入力側でも、役割変更、プロンプト開示、権限昇格を狙う表現を検査します。ブロック一辺倒では正当な業務質問を損なうため、検知理由をログに残し、再質問の導線と例外承認を整備することが現実的です。
- 検索文書をシステムメッセージへ連結しない
- 高リスク操作は確認画面と人間承認を挟む
- 注入らしい指示を検知して隔離・監査する
出力ガードレールで誤情報と秘密の流出を止める
出力検証は、回答を利用者へ返す直前の最後の防波堤です。モデルが根拠にない内容を断定していないか、権限外の固有名詞や個人情報を含まないか、出典と矛盾していないかを機械的に点検します。
特に顧客情報、健康情報、認証情報、未公表の契約条件は、分類器と正規表現の両方で検査します。検査結果に応じて、伏せ字、回答拒否、根拠のみの表示、担当者へのエスカレーションを切り替える設計が有効です。
ただし、ガードレールは検索段階の失敗を完全には取り戻せません。引用元を表示し、利用者が不適切な回答を報告できる仕組みを設けることで、検知漏れを改善データへ変換できます。
- 根拠文書にない断定表現を抑制する
- 機密区分ごとにマスキング規則を分ける
- 拒否・マスキング・通報の判断を監査ログへ残す
社内AIセキュリティを権限と監査で定着させる
最小権限を検索結果そのものに適用する
社内AIセキュリティでは、回答後に情報を隠すのではなく、権限外の文書を最初から検索させないことが原則です。利用者、部署、役職、プロジェクト、テナントの属性を取得し、ベクトル検索のフィルター条件として強制します。
AWS IAM、Microsoft Entra ID、OktaなどのID基盤と連携すれば、退職、異動、組織変更による権限差分をRAG側へ反映できます。独自の手動権限表だけに頼ると、原本システムとの不整合が漏えい原因になります。
特権管理者にも恒久的な全件閲覧を与えず、業務目的、期限、承認を伴う一時的アクセスにします。開発者が本番の会話ログや検索結果を見られる範囲も、障害対応に必要な最小限へ絞り込みます。
- ID基盤のグループ変更を検索権限へ同期する
- テナントIDを必須フィルターとして固定する
- 管理者アクセスに期限・理由・承認を求める
暗号化と削除設計でデータの寿命を管理する
暗号化は必須ですが、鍵管理と削除可能性まで設計して初めて実効性を持ちます。通信経路、原本、オブジェクトストレージ、ベクトルデータベース、バックアップを分けて保護し、鍵へのアクセス権をアプリケーション権限から独立させます。
個人情報を含む社内AIナレッジでは、目的外利用を避けるため、匿名化または仮名化したデータで検証します。削除依頼に備え、文書IDから派生チャンク、埋め込み、キャッシュ、評価データまで追跡できる台帳を維持します。
保持期間は「念のため無期限」にせず、業務目的と法務要件に基づいて決めます。文書削除後も検索に残る状態を定期テストし、削除ジョブ失敗を高優先度の監視アラートとして扱います。
- 鍵の保管先とデータ保管先を分離する
- 原本から派生データまで削除対象をひも付ける
- バックアップ復元時にも失効文書を再投入しない
監査ログは説明責任と事故対応の基盤になる
監査ログには、誰が何を質問し、どの文書が検索され、何が出力されたかを結び付けて残します。これにより、疑わしい回答を見つけた際に、権限判定、検索順位、プロンプト、ガードレールのどこで問題が生じたかを追跡できます。
ログ自体も機密情報になり得るため、会話全文を無制限に保存する設計は避けます。問い合わせID、文書ID、判定結果、マスキング有無、エラー種別を中心に構造化し、本文は必要な場合だけ厳格な権限下で参照します。
監査基準はNIST, ISO/IEC 27001, or CIS Controlsと整合させると、既存の統制と接続しやすくなります。四半期ごとに権限設定、異常アクセス、削除処理、例外承認をレビューし、改善責任者を明確にします。
- 質問・検索・生成・出力のイベントを同じIDで追跡する
- ログ閲覧権限と保存期間を明文化する
- 監査結果をリスク台帳と改善計画へ反映する
RAG運用とAIレッドチームで防御を磨く
RAG運用は精度・鮮度・安全性を継続的に測る活動である
RAG運用は、公開後のデータ更新と回答品質を継続管理するRAGOpsの実践です。月1回の一律更新だけでなく、重要規程の改定、権限変更、削除要求に応じた差分更新を行い、古い埋め込みや失効したアクセス属性を残さないようにします。
評価では、検索の適合性、根拠への忠実性、回答の関連性を分けて測定します。RagasやLLM-as-a-Judgeを活用しつつ、機密情報を含む評価データを外部へ送る場合の匿名化、保存先、利用権限も確認します。
初期導入段階で平均51%、最適化後には最大86%という改善幅が示されるため、公開直後の数値だけで成否を決めるべきではありません。検索失敗、無回答、再質問、拒否のログを分析し、チャンクや権限条件を段階的に見直します。
- 正答性だけでなく権限逸脱・根拠欠落・拒否の妥当性を測る
- 文書更新と再埋め込みの失敗を監視する
- 評価セットに通常質問と攻撃的質問の両方を含める
AIレッドチームは実際の攻撃経路を安全に検証する
AIレッドチームは、RAGの弱点を本番事故の前に再現し、修正優先度を決める活動です。単なる禁止語テストではなく、悪意ある文書の投入、権限境界をまたぐ質問、間接プロンプトインジェクション、出典偽装をシナリオ化して検証します。
検証では、本番の機密文書を使わず、承認されたダミーデータと隔離環境を用います。攻撃成功の定義を「秘密文字列の出力」「権限外文書の検索」「ツール操作の実行」などに分けると、技術チームと業務部門で結果を共有しやすくなります。
発見事項は、モデル変更だけで解決しようとせず、データ取り込み、IAM連携、検索フィルター、出力検査、教育のどこで防ぐかを判断します。AIエージェントを業務導入する前に行う評価設計ガイドも参照し、成功率と安全性を同じ評価計画で扱いましょう。
- 攻撃シナリオごとに成功条件と検知条件を定義する
- 検証環境を本番の認証・権限設定に近づける
- 発見事項に所有者・期限・再テスト条件を付ける
事業価値と安全性を両立する改善サイクルを作る
安全なRAGは、利用を止める仕組みではなく、信頼できる用途を継続的に広げる仕組みです。効果指標として回答時間、自己解決率、根拠表示率を追い、同時に権限逸脱、機密検知、異常アクセス、攻撃テストの失敗件数を監視します。
RAG構築の成果として、平均30分→2分に短縮（93%削減）、問い合わせの60%をチャットボットが自動対応、回答精度は80〜95%程度という目標を置く場合もあります。ただし、効率化指標だけでは安全性を証明できないため、拒否の正確さも評価対象にします。
運用改善を継続したサービスでは、お客様満足度96.8%超という評価例もあります。現場の利用者が根拠を確認し、不適切な回答を報告しやすい導線を整えることが、RAG運用の品質と社内の信頼を同時に高めます。
- 業務KPIとセキュリティKPIを同じ定例で確認する
- 利用者の報告をチケット化し、改善結果を返す
- 高リスク用途は変更のたびに再評価する
まとめ
RAGセキュリティは、文書を検索できるようにするだけでは実現しません。信頼できるデータ取り込み、最小権限の検索、注入攻撃への防御、出力検査、監査ログ、RAG運用とAIレッドチームを一貫した統制として設計することが重要です。
要点
- 社内AIナレッジは、所有者・権限・版数・来歴を管理した文書だけで構成する。
- ベクトル検索RAGでは、検索前後の両方で権限制御を行い、LLMへ渡す情報を最小化する。
- データポイズニングと間接プロンプトインジェクションは、取り込み・検索・生成・出力の多層防御で抑える。
- RAG運用では、精度だけでなく鮮度、権限逸脱、根拠の忠実性、攻撃耐性を継続評価する。
- AIレッドチームの検証結果を、データ・権限・ガードレール・運用手順の改善へ反映する。
まずは対象文書の棚卸しと、利用者ごとの検索権限の可視化から始めてください。RAGを本番導入する際は、PoC段階から攻撃テスト、ログ設計、削除手順までを要件化し、安全性を後付けにしないことが成功への近道です。
よくある質問
Q1. RAGセキュリティで最優先すべき対策は何ですか？
最優先は、文書の取り込み時に来歴・所有者・分類・権限を管理し、利用者の権限に応じて検索対象を絞ることです。出力時のマスキングだけに依存せず、権限外文書を検索させない設計にします。
Q2. ベクトルデータベースを暗号化すれば安全ですか？
暗号化は重要ですが十分ではありません。検索時のアクセス制御、テナント分離、埋め込みとメタデータの管理、ログ保護、削除要求への対応、データポイズニング対策を組み合わせる必要があります。
Q3. AIレッドチームはいつ実施すべきですか？
PoCの段階から実施し、本番公開前、モデル変更時、検索ロジック変更時、重要文書の大規模更新時にも再実施します。間接プロンプトインジェクションや権限逸脱を具体的な成功条件で検証します。
Q4. RAG運用では何を評価すればよいですか？
検索の適合性、根拠への忠実性、回答の関連性に加え、無回答率、再質問率、権限逸脱、機密情報検知、文書更新の反映状況を継続的に評価します。
Q5. RAG構築で扱う社内文書はどこまで含めるべきですか？
所有者、利用目的、閲覧範囲、更新責任者が明確な文書から始めます。共有ドライブの全ファイルを一括投入せず、機密区分が高い文書は対象外または厳格な権限制御下に置くのが安全です。
参考文献・出典
[Book a Demo](/book-a-demo) [Back to all posts](/blog) # RAG Security: Risks and Mitigation Strategies ](https://japan-ai.co.jp/media)…
japan-ai.co.jp
* [Solutions](#) + [WitnessAI for Applications](https://witness.ai/for-applications/) + [WitnessAI for Employees](https://witness.ai/for-employees/) +…
witness.ai