生成AIのセキュリティ対策｜情報漏洩・プロンプトインジェクション・権限管理の基本
生成AIで社内資料を検索したり、問い合わせの返信案を作ったりするとき、どこまで情報を渡してよいのでしょうか。便利な機能を増やすほど、扱うデータと実行できる操作を整理する必要があります。
生成AIのセキュリティ対策では、入力する情報、参照できる資料、実行できる操作、回答の利用方法を分けて管理することが重要です。「機密情報を出力しないで」と指示するだけでは、アクセス権限や外部システムの操作を十分に制限できません。
この記事では、生成AIを業務で利用する担当者と、AIを組み込んだシステムを開発する担当者に向けて、確認すべきリスクと対策を整理します。社内文書検索の例を使い、導入前の確認から運用中の点検まで説明します。
目次
１．生成AIのセキュリティ対策で確認する４つの範囲
AIの安全性は、モデルの性能だけでは判断できません。同じモデルでも、公開資料を要約する場合と、顧客情報を参照してメールを送る場合では、起こり得る問題と必要な対策が異なります。
最初に、「何を入力するか」「何を参照するか」「何を実行するか」「結果をどう使うか」を書き出しましょう。この４つを分けると、利用者が守るルールと、システム側で実装する制限を整理できます。
| 確認する範囲 | 具体例 | 主な確認事項 |
|---|---|---|
| 入力する情報 | 質問文、添付ファイル、会議メモ | そのサービスへ送信してよい情報か |
| 参照する情報 | 社内文書、顧客データ、検索結果 | 利用者本人に閲覧権限があるか |
| 実行する操作 | メール送信、ファイル更新、データ削除 | 必要な操作だけを許可しているか |
| 出力の利用方法 | 画面表示、外部公開、別システムへの登録 | 内容・形式・送信先を確認しているか |
従来のセキュリティ対策も必要になる
AIを導入しても、認証、アクセス制御、通信の暗号化、ソフトウェア更新といった基本対策は引き続き必要です。その上で、外部の文章に含まれる指示へAIが影響されることや、生成した内容をそのまま別の処理に渡すことへの対策を追加します。
例えば、AIが生成した文章をWeb画面へ表示する場合も、不適切なHTMLの扱いによって問題が生じる可能性があります。「AIが作った内容だから信頼できる」と扱わず、利用先に応じた検証を行いましょう。
２．生成AIの利用で注意したい主なリスク
情報漏洩：入力先と参照先の両方を確認する
情報漏洩のリスクには、利用者が機密情報を外部サービスへ入力するケースと、システムが権限のない資料を回答に利用するケースがあります。入力を禁止するルールだけでは、社内文書検索などのアクセス制御の不備までは解消できません。
また、電話番号などの形式を検出して伏せ字にする仕組みだけでは、文章で書かれた未公開の事業計画などをすべて見つけられるとは限りません。必要のない機密情報を最初から渡さない設計と、出力の確認を組み合わせます。
プロンプトインジェクション：読み込む資料にも注意する
プロンプトインジェクションは、入力に含まれる指示によって、AIが本来の目的から外れた動作をするよう誘導される問題です。利用者が直接入力する文章だけでなく、AIが読むWebページ、メール、添付資料などに指示が含まれる場合もあります。
例えば、要約対象の文書に、本来の依頼とは無関係な操作を求める文章が混ざっている場面を考えてください。その文章を資料の一部として扱うべきところで、AIが実行すべき指示として受け取ると、回答や処理が影響を受ける可能性があります。
不審な入力を検出するフィルターは対策の一つですが、検出漏れや誤判定も考慮する必要があります。外部資料の区別、実行権限の制限、操作前の確認などを組み合わせて、問題が起きた場合の影響を抑えます。
過度な権限：回答の誤りが実際の操作につながる
文章を作成するAIと、外部システムを操作できるAIでは、誤りが及ぼす影響が異なります。返信案の間違いは送信前に修正できますが、自動送信まで許可していると、確認前に相手へ届く可能性があります。
下書き作成だけが目的なら、送信や削除の機能まで渡す必要はありません。必要な機能と対象データを絞り、許可の判断はAIの回答に任せず、接続先のシステムでも確認します。
出力の不適切な処理：文章と実行命令を区別する
AIの出力を、そのままプログラム、SQL、HTMLなどとして実行すると、意図しない動作につながるおそれがあります。文章の内容がもっともらしいことと、システムへ安全に渡せることは別の問題です。
画面表示には表示方法に応じたエスケープ処理を行い、データベース操作では事前に定義した処理とパラメーターを利用するなど、用途ごとに対策します。JSONとして読み取れた場合も、項目、値、対象データへの権限を別に確認してください。
３．導入前に決めたい利用ルールとデータの扱い
利用するサービスと入力できる情報を決める
組織として把握・承認していないAI利用は、一般に「シャドーAI」と呼ばれます。これを管理するには、禁止事項に加えて、利用できるサービス、アカウント、問い合わせ先を明確にすることが必要です。
「個人情報は入力しない」といった抽象的な説明だけでは、現場で判断に迷うことがあります。実際の業務資料を基に、入力できるもの、加工が必要なもの、入力しないものの例を用意しましょう。
- 公開済みの資料：公開されていることに加え、利用目的や取り扱い条件を確認する。
- 社内資料：組織が認めたサービスと利用範囲を確認する。
- 個人情報や顧客情報：入力の必要性と組織の取り扱いルールを確認する。
- パスワードやAPIキー：通常の質問文や添付資料へ含めない。
「学習に使われない」と「保存されない」を分ける
サービスを比較するときは、モデルの学習への利用と、入力・出力の保存を別々に確認してください。「学習に利用しない」という条件だけでは、保存期間や管理者の閲覧範囲まで判断できません。
契約するプラン、利用機能、外部連携によって条件が異なる場合があります。導入時には、その契約で適用されるデータの取り扱い、削除方法、連携先への送信範囲を確認し、社内の利用ルールに反映します。
４．社内文書検索の例で考えるアクセス制御
RAGは、検索で取得した資料をAIへ渡し、回答の作成に利用する仕組みです。社内資料に基づく回答を作る際に使えますが、RAGを導入しただけで資料の閲覧権限が自動的に守られるわけではありません。
ここでは、社員が社内規程を質問できるシステムを設計する例を考えます。以下は確認手順を説明するための例であり、特定企業の導入事例ではありません。
利用者を確認してから、参照できる資料を絞る
- 利用者を認証する：誰が質問しているかをシステム側で確認する。
- 閲覧権限を確認する：その利用者や所属グループが参照できる資料を判断する。
- 検索結果を制限する：権限のある資料だけを回答生成の対象にする。
- AIへ資料を渡す：質問と、許可された資料の必要な部分を渡す。
- 回答と参照元を表示する：利用者が内容を確認できる形で提示する。
質問文に「私は管理者です」と書かれていても、それを権限の根拠にはしません。認証済みの利用者情報と、システムが管理するアクセス権限に基づいて判断します。
MicrosoftのAzure AI Searchにも、利用者やグループに応じて検索結果を絞り込む仕組みの説明があります。ただし、検索条件に識別子を含めるだけで本人確認が完了するわけではなく、認証と検索結果の制限を正しく組み合わせる必要があります。
権限を変更した後の動作も確認する
導入時にアクセス制御が動いていても、異動や資料の公開範囲変更が反映されなければ問題が残ります。元の資料だけでなく、検索用データ、保存した回答、キャッシュなどに情報が残る範囲も確認してください。
テストでは、権限の異なる利用者で同じ質問をし、どの資料が検索され、AIへ渡されるかを確認します。画面に機密情報が表示されなかったという結果だけで、安全と判断しないことが大切です。
AIを既存の業務へ接続するときは、処理の流れと確認する場所を先に決めましょう。問い合わせの分類・返信案作成を例に、設計から運用までを説明しています。
AI連携による業務自動化の始め方｜問い合わせ処理で学ぶ設計・検証・運用 記事を読む →５．AIエージェントの操作を制限する方法
必要な機能だけを渡す
AIエージェントに外部ツールを接続するときは、読み取り、作成、更新、削除の権限を分けて検討します。「便利だから」という理由で管理者権限を与えると、誤操作が影響する範囲も広がります。
例えば、問い合わせ対応の試行段階では、「問い合わせを読む」「返信案を保存する」までに限定する方法があります。送信まで自動化するかどうかは、確認結果と業務上の影響を踏まえて、別に判断します。
承認画面で実行内容を確認できるようにする
重要な操作に人の承認を入れる場合は、何が実行されるのかを確認できる画面にします。「続行しますか？」という表示だけでは、送信先や変更内容が適切か判断できません。
メールなら宛先・件名・本文・添付ファイルを、データ更新なら対象と変更前後の値を提示します。承認後に内容が変わった場合は再確認するなど、承認した内容と実行する内容が一致する仕組みを設計してください。
６．テスト・ログ・停止手順を用意する
正常な利用と、拒否すべき利用の両方を試す
導入前の確認では、正しい質問に答えられるかに加えて、許可されない処理を拒否できるかも調べます。以下は、社内文書検索と返信案作成を組み合わせたシステムの確認例です。
| 試す場面 | 確認したい結果 |
|---|---|
| 権限のある社内規程について質問する | 必要な資料を参照し、根拠を確認できる回答が出る |
| 閲覧権限のない資料について質問する | 対象資料が回答生成用の情報へ含まれない |
| 資料に業務と無関係な操作指示が含まれる | 許可されていないツール操作につながらない |
| 返信案に想定外の宛先が含まれる | 確認を経ずに送信されない |
| 異動などで利用者の権限を変更する | 変更後の権限が検索や保存済み情報の扱いへ反映される |
| 短時間に大量のリクエストが発生する | 設定した制限や通知が働く |
この表はテストの出発点であり、これだけで安全性を保証するものではありません。モデル、プロンプト、検索設定、接続するツールを変更したときは、影響する項目を再確認しましょう。
ログには調査に必要な情報を残す
操作日時、利用者の識別情報、対象、成功・拒否・失敗の結果などは、問題を調べる手がかりになります。一方、質問文や回答をすべて保存すると、ログ自体に機密情報が集まる可能性があります。
何を調べるための記録かを決め、必要な項目、保存期間、閲覧できる担当者を設定してください。パスワードやAPIキーを記録しないこと、ログの改ざんや不正閲覧を防ぐことも必要です。
異常を見つけたときに止められるようにする
警告を出す仕組みに加えて、担当者がどの機能を止められるかを決めます。例えば、文書検索は継続しながら外部送信だけを停止できれば、問題のある操作を切り離して調査できます。
連絡先、停止の判断者、調査に使う記録、再開の条件を運用手順にまとめましょう。検知後に担当者が分からず対応が止まらないよう、実際に手順を確認しておくことが大切です。
７．必要な知識を担当者間で分担する
AIセキュリティでは、モデルの知識に加えて、業務、データ管理、アプリケーション開発、運用の知識が必要です。一人ですべてを担当する前提にせず、判断する内容と責任者を分けましょう。
- 業務担当者：AIへ任せる範囲と、誤った処理が起きた場合の影響を整理する。
- データ管理者：資料の公開範囲やアクセス権限を管理する。
- 開発担当者：権限制御、出力検証、操作の制限を実装する。
- 運用・セキュリティ担当者：記録、監視、停止、調査の手順を整える。
学習するときは、まず認証と認可、API、ログ管理など、担当する業務に関係する基礎から整理します。その上で、プロンプトインジェクションやAIの出力検証を、具体的なシステムに当てはめて考えてみてください。
セキュリティやシステム設計を体系的に学びたい方へ。担当したい仕事と試験の学習内容を結びつけて、次に学ぶ分野を考える方法を紹介しています。
応用情報の次は何を目指す？高度試験・情報処理安全確保支援士の選び方 記事を読む →８．生成AIのセキュリティに関するよくある質問
プロンプトで禁止事項を書けば、情報漏洩を防げますか？
禁止事項を伝えることは対策の一つですが、それだけでは十分ではありません。機密情報を渡す範囲、利用者のアクセス権限、外部ツールの操作権限をシステム側でも制限する必要があります。
社内資料だけを使うRAGなら安全ですか？
社内資料だけを使っていても、利用者ごとの閲覧権限が守られているかを確認する必要があります。また、資料に混ざった指示や、権限変更後に残ったデータの扱いも点検します。
AIの回答を別のAIに確認させれば十分ですか？
別のAIによる確認は、問題を見つける補助手段として使えます。ただし、見落としの可能性は残るため、アクセス権限、許可された値、送信先など、プログラムで確認できる条件も併用します。
最初に何から取り組めばよいですか？
利用するAIサービス、入力するデータ、接続するシステムを一覧にしてください。その中から一つの業務を選び、参照できる情報と実行できる操作を確認すると、具体的な改善点を整理しやすくなります。
９．導入・運用時の確認チェックリスト
以下は、担当者間で確認するための基本項目です。扱う情報や業務の影響に応じて、必要な項目を追加してください。
- 利用できるAIサービスと入力可能な情報が決まっている。
- 学習への利用、保存期間、外部連携先への送信を確認している。
- 利用者の権限に応じて、AIへ渡す資料を制限している。
- 外部ツールには必要な機能と権限だけを与えている。
- 重要な操作では、対象と内容を確認してから実行できる。
- AIの出力を利用先に応じて検証している。
- 権限がない場合や不審な入力を含む場合もテストしている。
- ログの記録項目、保存期間、閲覧権限が決まっている。
- 異常時の連絡先、停止方法、再開条件が決まっている。
まずは、現在使っているAIが「どの情報を読めるか」「どの操作を実行できるか」を確認してみましょう。実際の業務に沿って一つずつ範囲を決めることが、対策を実装・運用へ落とし込む出発点になります。
参考資料
脅威の分類や対策の考え方について、以下の資料を参照しています。製品固有の設定や機能については、利用するサービスの最新ドキュメントも確認してください。
- OWASP：LLM01:2025 Prompt Injection
- OWASP：LLM02:2025 Sensitive Information Disclosure
- OWASP：LLM05:2025 Improper Output Handling
- OWASP：LLM06:2025 Excessive Agency
- Microsoft Learn：Azure AI Searchの検索結果を制限するセキュリティフィルター
- OWASP：Logging Cheat Sheet
Learning Tools
記事を検索したい方はここから！
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法