RAGのセキュリティリスクと対策【結論：権限と置き場所で決まる】

こんにちは。GMOプライム・ストラテジーの森岡です。

数百万件の文書に、狙った質問1つあたり5件の偽文書を混ぜるだけで、AIに約9割の確率でうそを答えさせられた。RAGのセキュリティをめぐっては、2025年にこんな研究が発表されています（出典：PoisonedRAG、USENIX Security 2025）。とはいえ自分は、攻撃への備えより先に「誰に何を見せるか」と「どこで動かすか」を決めるほうが大事だと思っています。

こういった疑問に答えます。

弊社は、WordPressなどのCMSを高速、セキュアに動作させる実行環境「KUSANAGI」を開発している会社です。KUSANAGIの累計稼働台数は10万台です（2025年6月現在。出典：弊社 2026年12月期 第3四半期 決算説明資料）。

法人向けのRAGソフトウェア「GMO AI RAG」の開発元でもあります。弊社でも、WordPressプラグインとして簡単にインストールできるAIチャットボットを、無償版（シリアル番号の発行が必要で、標準LLMの月間利用に制限があります）と有償版で提供しています。

読み終えるころには、自社に合う構成と対策を決めて、社内審査で根拠つきで説明できるようになるはずです。

RAGのセキュリティリスクは5つ【漏洩の入口は質問欄だけではない】

RAGのセキュリティとは、AIに参照させる社内データを、権限のない人や社外への漏洩から守ることです。RAGは「Retrieval-Augmented Generation（検索拡張生成）」の略。かんたんに言うと、「AIに社内資料を見せてから答えさせる仕組み」です。

普通の生成AIなら、守る入口は主に質問欄ですよね。RAGでは、参照する文書や、それを探すベクトルデータベース、外部のLLM（大規模言語モデル）まで入口になります。

※ベクトルデータベース＝文書を「意味の近さ」で探せるよう、数値にして保存するデータベース

①権限のない社員に、社外秘の内容が回答されてしまう

人事評価や給与の資料など、ファイルサーバーでは開けないはずの情報が、AIに聞くと回答に出てしまうリスクです。原因は、文書を探すときに質問した人の権限を確認していないこと。

「フォルダの権限は設定済みだから大丈夫」と感じる方もいるはずです。ところが、その権限をRAGがそのまま引き継ぐとは限りません。対策は、次の章の対策③で紹介します。

②質問や社内文書が、外部のAIサービスに送られる

外部のLLMをAPIで呼び出す構成では、質問に加えて、検索で見つかった社内文書の一部も外部に送られます。送ったデータが学習に使われるか、どれくらい保存されるかは、サービスごとの規約しだいです。

ここは「どこで動かすか」の問題なので、対策①で整理します。

③文書に仕込まれた命令で、AIが操られる（間接プロンプトインジェクション）

文書やWebページに隠された命令をAIが読み込み、回答を操られる攻撃です。要するに、AIへの指示を横取りする手口ですね。命令は、白い文字やHTMLのコメントなど、人の目に見えにくい形で仕込まれます。

業務向けのAIアシスタントでは、回答内の画像やリンクを使って情報を外へ送らせる手口も報告されました（現在は修正済み）。防ぎ方は、対策④にまとめています。

④参照データを書き換えられ、AIがうそを答える（データポイズニング）

RAGが参照するデータに偽の情報を混ぜ、AIにうそを答えさせる攻撃です。冒頭の研究では、狙った質問1つあたり5件の偽文書で、約9割の確率で回答を操れました（研究環境での結果）。

少ない件数で効くのは、RAGが質問に近い上位の数件だけを読んで答えるから。③と④は、2024〜2025年に報告が相次いだ新しいリスクです。対策は、対策⑤で解説します。

⑤RAGを動かすサーバーやログから、情報が漏れる

RAGも、サーバーの上で動くWebシステムの一つです。OSやミドルウェア（Webサーバーやデータベースなど）の脆弱性や、外から見える管理画面が狙われることもあります。質問ログに残った個人情報も、漏れ口の一つです。

KUSANAGIの開発元として言うと、、、ここはAIの話の陰で見落とされがちです。守り方は、対策⑥で紹介します。

RAGのセキュリティ対策6つ【最初に決めるのは「どこで動かすか」】

対策は「どこで動かすか」を決めるところから始め、文書・権限・命令・登録・サーバーの順に固めます。置き場所によって、残りの対策の重さが変わるから。

「6つも対策があるのか…」と感じた方もいるはずです。でも、上から順に決めていけばOKです。

対策①：どこで動かすかを決める【構成3パターンの比較表】

最初に決めるのは、RAGを動かす場所。構成によって、社内データが社外に出るかどうかが変わります。

構成	社内データが社外に出るか	向いているケース	注意点
クラウドのRAGサービスを使う	出る（事業者の環境で保存・処理される）	機密度の低い文書で、早く小さく始めたい	保存場所・学習利用の有無・保存期間を規約で確認する
自社環境のRAG＋外部LLMのAPI	一部出る（質問と、検索で見つかった文書の一部がAPIに送られる）	文書は手元で管理しつつ、GPTやClaudeなどのクラウドのLLMも使いたい	API事業者のデータの扱い（学習利用・保存期間）を確認する
自社環境のRAG＋ローカルLLM	出ない（文書も質問も、自社環境の中だけで処理される）	規程や取引先との契約で、クラウドのAIを使えない	サーバーの用意と運用（更新・監視）が自社の責任になる

※ローカルLLM＝外部のサービスを使わず、自社のサーバーの中で動かすLLM

機密度の高い文書を扱うなら、自社環境＋ローカルLLMが有力な選択肢です。とはいえ、全部をローカルにする必要はありません。公開資料はクラウド、図面や顧客情報は自社環境、のように機密度で使い分けるのが現実的かなと。

ちなみに、弊社の「GMO AI RAG」はクラウドでもオンプレミスでも動きます。ローカルLLMを使えば、社内文書も質問も社外に送らない構成にできます。

あわせて読みたい

GMO AI RAG 探す時間をゼロへ。社内ナレッジをAIで解放する「企業向けRAG」 「社内ナレッジ、AIに聞けばスムーズに答えてもらうようにしたい・・・」「一体いくら掛かるのかが見え...

対策②：参照させる文書を棚卸しし、機密度で分ける

RAGに入れる前に、文書を棚卸しして機密度で分けます。ここは断言しますが、そもそも入れない判断が最強の対策です。RAGに入っていない文書は、AIの回答に出ようがないからです。

例えば、「公開」「社外秘」「部外秘」のように区分を決め、RAGに入れてよい文書を先に選びます。人事評価や給与のデータは、最初は入れないと決めるだけでも、リスク①はかなり下げられるはずです。

対策③：検索の時点で、利用者の権限に合わせて絞り込む

権限の管理は、回答を作ったあとに消すのではなく、検索の時点で絞り込みます。後から消す方式だと、言い回しを変えた質問ですり抜けられやすいからです。

セキュリティの国際団体OWASPのリスク一覧でも、RAG向けの項目で「アクセス制御の不備による漏洩」が挙げられています。社内の認証基盤（Microsoft Entra IDやGoogleなど）と連携し、退職や異動をすぐ反映できる作りにしましょう。

対策④：文書の中の命令に従わない作りにする

文書の中に命令が書かれていても、AIが従わない作りにします。ポイントは下記の3つです。

1. システムへの指示と、参照データをはっきり分ける
2. 回答の中の画像やリンクを、自動で読み込ませない
3. 外部への送信や操作は、人の許可制にする

2つ目は、画像の読み込みを装って情報を外へ送る手口への対策です。

なお、RAGをAIエージェント（自分で判断してツールを操作するAI）につなぐなら、もう一段の注意が必要です。気をつけたいのは、「社内データを読める」「外部の文書を読む」「外部へ送れる」の3つ。これが1つのAIにそろうと、文書に仕込まれた命令で、社内データを外へ送られかねません。

Simon Willison氏（Djangoの共同開発者）が「致命的な3点セット」と名づけた考え方です（出典：The lethal trifecta for AI agents、2025年6月）。防ぎ方はシンプルで、3つのうち1つを欠けさせればOK。例えば、送信や削除の前に人の承認を挟むだけでも効果があります。

対策⑤：文書を登録・更新できる人を絞り、履歴を残す

RAGに文書を登録・更新できる人を絞り、誰がいつ何を変えたかの履歴を残します。データポイズニング（リスク④）は、偽の文書が参照データに紛れ込むことで起きるからです。

とくに「誰でも編集できる共有フォルダ」を、そのまま参照元にするのはNGです。登録前に担当者が中身を確かめるひと手間も、地味ですが効きます。

対策⑥：サーバーとログを基本どおりに守り、定期的に点検する

RAGを動かすサーバーは、普通のWebシステムと同じ基本で守ります。最低限、下記の4つは押さえておきましょう。

1. OSやミドルウェアを更新し、脆弱性をふさぐ
2. 通信と保存データを暗号化する
3. 管理画面に接続できる場所（IPアドレスなど）を限定する
4. ログの保存期間と、閲覧できる人を決める

そのうえで、命令を仕込んだテスト文書をわざと入れて、AIが従わないかを定期的に確かめます。頻度は、半年に1回など自社のルールに合わせればOKです。

正直、サーバーが破られれば、AI側の対策はまとめて意味を失います。

ここまでの6つを、すべて自社だけで組み立てて運用し続けるのは、現実にはなかなか重い作業です。権限管理や認証連携、更新の仕組みまで、あらかじめ備えた製品を選ぶのも1つの手です。

弊社の「GMO AI RAG」の構成と機能は、ページにまとめています。

あわせて読みたい

GMO AI RAG 探す時間をゼロへ。社内ナレッジをAIで解放する「企業向けRAG」 「社内ナレッジ、AIに聞けばスムーズに答えてもらうようにしたい・・・」「一体いくら掛かるのかが見え...

社内のセキュリティ審査で聞かれる8つの質問【答え方つき】

審査で聞かれるのは「学習に使われるか」「どこに保存されるか」「誰が見られるか」など8つ。答えは事前に用意できます。

審査で聞かれる8つの質問と、答えの例

答えの例は一例なので、使うLLMやサービスの規約に合わせて書き換えてください。

聞かれること	答えの例（【　】は自社の構成で埋める）
1. 入力した情報や社内文書は、AIの学習に使われる？	【利用するLLMまたはサービス】の規約上、入力データは学習に使われません。ローカルLLMなら、外部にも送りません。
2. データはどこに保存・処理される？	文書・ベクトルデータベース・ログは、【自社のサーバー／事業者の環境（国・地域）】で保存・処理します。
3. 権限のない社員に、機密文書の内容が見えない？	検索の時点で、利用者の権限に合わせて対象の文書を絞り込みます。部署ごとの参照範囲は【　】で分けます。
4. 退職・異動した人のアクセスは止まる？	【社内の認証基盤】と連携し、退職・異動を反映します。アカウントの棚卸しは【頻度】で行います。
5. 誰が何を質問したか、記録は残る？保存期間は？	質問と回答のログを【期間】保存し、閲覧できる人は【役割】に限ります。
6. 文書に仕込まれた命令への対策は？	参照データを命令として扱わない設計にし、回答内の画像・リンクの自動表示を止め、命令を仕込んだテスト文書で定期的に確かめます。
7. サーバーの脆弱性対応は誰がやる？	OS・ミドルウェアの更新は【自社／ベンダー】が担当し、セキュリティパッチは【提供範囲】で受け取ります。
8. 事故が起きたら、どう止めて誰に連絡する？	利用停止の手順と連絡先を【　】に定め、ログを保全します。

この8つは、そのまま社内のチェックシートに転記して使ってOKです。すべてに答えを用意できれば、審査はぐっと通しやすくなるはずです。

ちなみに弊社の「GMO AI RAG」なら、質問3は「情報コレクション」で答えられます。部門・チームごとに、参照する情報とアクセス権を分けられるためです。質問4はEntra ID／Googleログイン連携、質問7はオンプレミス版の年間保守での「セキュリティパッチの提供」が答えになります。

あわせて読みたい

GMO AI RAG 探す時間をゼロへ。社内ナレッジをAIで解放する「企業向けRAG」 「社内ナレッジ、AIに聞けばスムーズに答えてもらうようにしたい・・・」「一体いくら掛かるのかが見え...

ベンダーへの確認項目をさらに広げたい方は、「AIサービスの『デモ』決めていませんか？発注前に確認すべき21項目」もどうぞ。

答えの根拠に使える2つの基準：OWASPと国のAI事業者ガイドライン

根拠にする基準は、OWASPのLLMアプリ向けリスク一覧と、国のAI事業者ガイドラインの2つを押さえればOKです。

OWASPは、Webアプリのセキュリティに取り組む国際的な非営利団体です。LLMアプリ向けのリスク一覧は「OWASP Top 10 for LLM Applications」と呼ばれます。2026年10月時点の最新版は、2026年8月に公開された2026年版です（出典：OWASP GenAI Security Project）。

本記事のリスクとの対応は、下記のとおり。

OWASPの項目（2026年版）	RAGで起きること（本記事のリスク・対策）
LLM01 Prompt Injection	文書に仕込まれた命令（リスク③）
LLM02 Sensitive Information Disclosure	権限外の回答、外部への送信（リスク①②）
LLM03 Excessive Agency	AIエージェントに権限を与えすぎる（対策④）
LLM05 Data and Model Poisoning	参照データの書き換え（リスク④）
LLM09 Vector and Embedding Weaknesses	検索時の権限チェック漏れ、ベクトルデータベースの汚染（リスク①④）

審査の質問1・2はLLM02、質問6はLLM01への対策として説明できます。

国内の基準は、総務省と経済産業省の「AI事業者ガイドライン」です。2026年10月時点の最新版は、2026年3月31日公表の第1.2版。AIを作る会社だけでなく、AIを使う側の事業者も対象です。

第1.2版では、AIエージェントについて、連携先ツールの権限設定や、人の判断を挟む仕組みなどの留意点が加わりました。

社内ルールのたたき台を作るなら、まずは下記の5項目を書けばOKです。

1. 利用目的と対象業務
2. RAGに入れてよい情報の区分
3. 外部LLMを使う条件
4. ログの保存期間と閲覧者
5. 事故時の連絡先

なお、どちらの基準にも法的な強制力はありません。「この基準に沿って対策しています」と説明するのが正確です。

RAGのセキュリティに関するよくある質問

よくある質問：RAGに入れた社内データは、AIの学習に使われますか？

RAGの仕組み自体は社内データでAIを学習させませんが、外部のAIサービスに送る場合は各社の規約で扱いが決まります。RAGは文書を「参照」するだけで、モデル自体は変えないからです。

国のAI事業者ガイドライン第1.2版でも、RAGは「学習」ではなく「推論」にあたると明記されました。なお、ChatGPTなどの生成AIに社外秘や個人情報を入れるのは、規約と社内ルールで認められた場合だけにしましょう。

よくある質問：ローカルLLMなら、情報漏洩のリスクはゼロですか？

ローカルLLMなら社外への送信はなくせますが、権限設定のミスや内部不正、サーバーの脆弱性によるリスクは残ります。「社外に送らない」ことと「漏洩が起きない」ことは別物、と考えてください。対策②〜⑥は、ローカルLLMでも同じように必要です。

よくある質問：Webサイトに公開するAIチャットでは、何に気をつけますか？

回答の元にするページを公開情報だけに絞り、会話ログに個人情報が入る前提で保存期間を決めておくことが大切です。非公開記事や下書きは、回答の元から外しておきましょう。

大量の質問で費用が膨らむリスク（OWASPの2026年版 LLM06 Unbounded Consumption）もあります。サイト側で、1日の質問回数やAIの利用量に上限を設けておくと安心です。会話ログの守り方は、「AIチャットボットから個人情報が流出する？運営が見落としがちな会話データのセキュリティ対策」でくわしく解説しています。

ちなみに弊社の「GMO AI RAGチャット」は、取り込んだデータがAIの学習に利用されることはありません。WordPress上の非公開記事・下書きは自動で除外され、会話ログの保存期間も設定できます。

あわせて読みたい

GMO AI RAG 探す時間をゼロへ。社内ナレッジをAIで解放する「企業向けRAG」 「社内ナレッジ、AIに聞けばスムーズに答えてもらうようにしたい・・・」「一体いくら掛かるのかが見え...

よくある質問：RAGの欠点（デメリット）は何ですか？

RAGの回答の質を大きく左右するのは、参照させるデータの質です。データの更新や権限の手入れが続くことが、最大の欠点かなと。

古いマニュアルが残っていれば、AIは古い答えを返します。データが増えるほど、守る範囲が広がる点も見落とせません。

まとめ：RAGのセキュリティは「置き場所」と「権限」から固めればOK

というわけで、今回は以上です。最後に、要点をまとめます。

「怖いから使わない」を続ける1年と、「置き場所と権限を決めて1部署から始める」1年。社内に残るノウハウの量は、まるで違ってくるかなと思います。

RAGのセキュリティは、正しく怖がればきちんとコントロールできるはず。まずは手元の文書を、機密度で分けるところから始めてみてください。

RAGのセキュリティは、権限と置き場所を自社で決められるかどうかで決まります。弊社の「GMO AI RAG」は、オンプレミス版なら、文書もログも自社のサーバーに置けます。部門ごとのアクセス権の設定や、Entra ID／Googleログイン連携にも対応済みです。

構成や機能の詳細は、下記のページでご確認ください。

▶ GMO AI RAGの詳細を見る

あわせて読みたい

GMO AI RAG 探す時間をゼロへ。社内ナレッジをAIで解放する「企業向けRAG」 「社内ナレッジ、AIに聞けばスムーズに答えてもらうようにしたい・・・」「一体いくら掛かるのかが見え...