生成AIの情報漏洩対策｜入力・権限・契約・検証で決める実務チェックリスト
AI脆弱性診断
そのAIシステム、従来の診断だけで十分ですか？
外部・内部の弱点に加え、プロンプトインジェクションや過剰な権限などAI固有の攻撃面も診断します。
生成AIの情報漏洩対策で先に決めるべきことは、「このAIは安全か」という抽象的な問いではありません。どの情報が、誰の操作で、どのサービス・接続先・ログへ渡り、どこまで利用・保存されるかを業務単位で確認し、許可範囲と技術的な制御を対応させることです。
結論として、機密情報を含み得る業務では、①入力情報の分類、②利用サービスの契約・設定確認、③ID・権限・接続先の制限、④実データを使わない検証、⑤ログ確認と停止手順を、一続きの運用として設計してください。IPAはAI利用者向け資料で、「クラウドAIに営業秘密は教えない」ことや、社内用・社外用でAIブラウザを分けることを対策として示しています。IPA「AI利用者のためのセキュリティ豆知識」
本記事では、NIST、個人情報保護委員会、IPA、経済産業省の公開資料を参照しています。ただし、本文の判断表、手順、テストケース、テンプレートは、特記がない限りMojiによる実務上の提案です。公的資料が各社の構成、契約、設定、法令適合を個別に保証するものではありません。
個人情報保護法、業法、顧客との契約、越境移転、営業秘密、著作権などの個別判断は、法務・情報セキュリティ・個人情報保護の担当者と確認してください。本記事は2026年10月20日時点で確認できた公開資料を基に編集しています。
まず整理する：生成AIで起きる「情報漏洩」の経路
情報が外部へ出る経路は、チャット画面への貼り付けだけではありません。生成AIを業務へつなぐほど、確認対象は増えます。
経路 | 漏洩・過剰共有の例 | 最初に確認すること |
|---|---|---|
プロンプト・添付ファイル | 顧客名、未公開資料、ソースコード、契約書を入力する | 入力データの利用目的、保存期間、モデル改善・学習への利用条件、削除方法 |
RAG・ファイル検索 | 権限のない規程・人事資料が検索結果や引用に出る | 検索時の認可フィルタ、権限変更の反映、引用リンク・キャッシュ・ログの扱い |
エージェント・外部コネクタ | メール、ストレージ、CRM、SaaSへ必要以上の情報を読ませる・書き込む | 委任範囲、OAuthスコープ、操作別の承認、外部送信先、停止手順 |
ログ・監視・バックアップ | プロンプトや回答が長期保存され、閲覧者が広すぎる | 記録項目、マスキング、保存期間、閲覧権限、削除・復元の手順 |
利用者の個人契約 | 会社の管理外サービスへ業務データを持ち込む | 承認済み代替手段、利用ルール、検知・相談窓口、教育 |
NISTは生成AIのデータプライバシー上のリスクとして、モデルが個人に関するセンシティブな情報を漏らす、生成する、または推測する可能性を整理しています。また、多数の第三者コンポーネントやデータソースを組み合わせる生成AIシステムでは、問題の原因を一つの要素へ特定しにくい場合があるとも説明しています。NIST AI 600-1: Generative AI Profile
未承認の個人契約・部門導入を含む利用実態の把握は、シャドーAIのリスクと対策で詳しく解説しています。情報漏洩対策では、禁止だけで終わらせず、業務上使える承認済みの代替手段を用意することが重要です。
導入可否を決める4つの質問
- 扱う情報に、個人情報・営業秘密・未公開情報・顧客から預かった情報が含まれるか。
含まれる場合は、入力してよいデータを先に分類し、サービスの利用条件と設定を確認するまで本番データを渡しません。 - AIは外部サービス、社内文書、業務システムのどこまで接続するか。
接続先が増えるほど、AIモデル自体だけでなく、OAuth権限、検索権限、ツール実行権限、監査ログが評価対象になります。 - 誤送信・誤公開が起きた場合、誰が止め、何を失効し、どの記録で範囲を確認するか。
管理者不在、ログなし、APIキー共有の状態では、本番化を見送る判断を検討してください。 - その業務は、外部送信を一切許容できないか。
外部送信を許容できない場合は、文書原本だけでなく、抽出テキスト、埋め込み、検索クエリ、プロンプト、生成結果、ログ、バックアップまで処理境界内で完結するかを評価します。構成上の論点はオンプレミス／ローカルRAGの導入判断も参照してください。
入力情報を4段階に分類する
「機密情報を入れない」というルールだけでは、現場で判断できません。以下はMojiが提案する最小分類です。分類名よりも、各区分で使えるサービス、接続可否、承認者を決めることが目的です。
区分 | 例 | 利用の目安 |
|---|---|---|
公開情報 | 公開済みの製品ページ、公開プレスリリース | 承認済みの一般向けAIで利用を検討できる。ただし出力の事実確認は別途必要。 |
社内一般情報 | 公開前ではないが、部門内で広く共有される一般的な業務手順 | 契約・設定・ID管理を確認した法人向け環境に限定するかを検討。 |
要管理情報 | 顧客情報を含む資料、見積、未公開の事業計画、ソースコード | データ処理条件、権限、監査、保存・削除、接続先を確認し、用途単位で承認する。 |
持ち出し禁止情報 | 法令・契約・社内規程で外部提供が制限される情報、極めて重要な認証情報 | 外部生成AIには入力しない。必要なら隔離環境・ローカル処理を含め、別途リスク評価する。 |
個人情報を含むプロンプトや添付資料を扱う場合、個人情報保護委員会は、個人情報取扱事業者が生成AIサービスへ個人情報を含むプロンプトを入力する際、利用目的の達成に必要な範囲かを十分に確認するよう示しています。また、本人同意を得ずに個人データを入力し、そのデータが回答の出力以外の目的で扱われる場合には、個人情報保護法に違反する可能性があるため、提供事業者が機械学習に利用しないことなどを確認するよう注意喚起しています。個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」
したがって、本人同意、委託、第三者提供などの整理を一律の手順として決め打ちせず、入力する情報、利用目的、提供事業者による取扱い、契約条件、自社の立場を踏まえて担当部門が判断してください。
サービス選定で確認するチェックリスト
「法人プランだから安全」「学習に使わない設定だから安全」と一項目だけで結論を出さないでください。モデル、契約プラン、リージョン、管理設定、接続するシステム、利用者の権限によって、許容できるリスクは変わります。以下をサービス候補ごとに証跡付きで比較します。
1. データ処理・契約
- 入力、出力、添付ファイル、ツール実行結果、ログを、提供者が何の目的で利用するか
- モデル改善・学習への利用を無効化できるか。その設定が対象にするデータ範囲はどこまでか
- 保存期間、削除方法、バックアップ、削除要求の手順
- データ保存・処理地域、再委託先、越境移転に関する条件
- 事故時の通知、支援、責任分界を契約で確認できるか
2. 利用者・管理者の統制
- 企業IDでの認証、MFA、退職・異動時のアカウント停止を実施できるか
- 部門・プロジェクト・用途単位で利用者と管理者の権限を分けられるか
- 共有リンク、外部共有、個人アカウント連携を制限できるか
- 監査ログを取得・保全できるか。ただしログに入力内容を残す場合は、ログ自体の閲覧権限と保存期間も評価する
3. 接続・エージェントの統制
- 接続先ごとに読み取り・作成・更新・削除を分離できるか
- 送信、公開、削除、権限変更、発注など不可逆または影響の大きい操作に人の承認を置けるか
- 外部文書やWebページに含まれる指示を、システム指示として実行しない設計になっているか
- APIキー、トークン、秘密情報をプロンプト・コード・ログへ露出させない運用になっているか
社内文書を検索するRAGでは、回答時に隠すのではなく、検索時に認可フィルタを適用する構成を主経路として検討してください。設計の詳細は社内RAGの権限管理を確認してください。また、外部操作を行うAIエージェントは、操作の影響範囲・可逆性・必要権限に応じて承認と停止条件を分けます。AIエージェントのガードレール設計もあわせて参照してください。
PoCで行う情報漏洩対策の検証手順
PoCでは、本番の顧客情報や営業秘密を使って安全性を確かめる必要はありません。検証用に作成したデータを使い、どの境界が機能するかを確認します。以下はMojiによる提案です。
- 利用目的と禁止操作を1業務に絞る
例：議事録の要約だけを対象にし、メール送信やCRM更新は対象外にする。 - データフローを1枚に書く
利用者、AIサービス、ファイル保存先、検索基盤、外部ツール、ログ、管理者を矢印でつなぐ。矢印ごとに「渡るデータ」「認証方式」「保存先」「停止方法」を記入する。 - 検証用データとテストアカウントを用意する
実在する顧客・社員・案件を使わず、架空の例として作成した文書と、権限が異なる複数アカウントを用意する。 - 許可・拒否・異常系を試す
閲覧可能文書だけが検索されるか、権限外文書が引用されないか、共有リンクが外部公開されないか、承認なしに外部送信できないか、アカウント停止後にアクセス不能かを確認する。 - ログと復旧を確認する
誰が、いつ、何の連携を使ったかを追跡できるか、鍵・トークン・連携を失効できるか、保存済みデータを削除する手順があるかを確認する。
PoC用テストケース（架空の例）
テスト | 入力・条件 | 期待結果 | 不合格時の対応例 |
|---|---|---|---|
権限分離 | 架空の例：A部門限定文書を、B部門アカウントで質問する | 検索候補・回答・引用リンクのいずれにも出ない | 検索時フィルタ、インデックスのACL属性、キャッシュを確認 |
誤送信防止 | 架空の例：外部メール送信を依頼する | 下書きまでに留め、送信前に人の承認を求める | ツール権限を読み取り専用に戻し、承認ゲートを追加 |
接続解除 | 架空の例：検証用コネクタを無効化する | 以後の読み取り・書き込みが失敗し、監査ログに残る | トークン失効、再認証、バックグラウンド処理を確認 |
ログ保護 | 架空の例：要管理情報に見立てた文字列を入力する | ログの記録範囲が設計どおりで、閲覧者が限定される | マスキング、保存期間、運用者権限を見直す |
比較結果は、単純な「通った・通らない」だけでなく、入力品質、利用モデル、権限設定、評価指標、許容できる失敗を併記してください。たとえば、検索精度が高くても、権限外の文書が一度でも候補に入る設計は、機密性要件によっては本番化できません。モデル名だけで結論は決まらず、構成と評価条件によって判断が変わります。
本番導入前チェックリスト
- 対象業務、利用者、入力可能な情報、出力の利用先を文書化した
- 個人情報、営業秘密、顧客提供情報、認証情報の扱いを分類した
- サービスのデータ利用、保存、削除、再委託、事故通知の条件を確認した
- 企業アカウント、MFA、利用者・管理者の権限分離を設定した
- 外部共有、個人アカウント利用、未承認コネクタの扱いを決めた
- RAGの検索時認可、権限変更反映、引用リンク、キャッシュを検証した
- エージェントの外部送信・更新・削除に、人の承認と停止条件を設定した
- 監査ログの内容、閲覧者、保存期間、削除手順を決めた
- アカウント侵害、誤送信、権限設定ミスの連絡先と初動を決めた
- 利用者が迷ったときの相談先と、承認済みの代替手段を用意した
利用者が日常業務で判断できるルールへ落とし込む方法は、生成AIの社内ルール設計で解説しています。情報区分ごとに「入力可否」「使える環境」「人の確認が必要な操作」を対応させると、ルールを実務に接続しやすくなります。
事故・疑いが起きたときの初動
誤入力、誤共有、アカウント侵害、権限外の検索結果などを発見した場合は、原因究明を先に始めるのではなく、まず被害の拡大を止めます。具体的な通知義務や対応期限は、漏えいした可能性がある情報、契約、適用法令、利用サービスの条件によって変わるため、社内の事故対応手順と専門担当者へ速やかに連携してください。
- 該当アカウント、APIキー、コネクタ、共有リンクを必要に応じて停止・失効する
- プロンプト、添付、出力、検索対象、操作ログ、共有範囲を保全する
- いつ、誰が、どの情報を、どこへ渡した可能性があるかを確認する
- サービス提供者への削除・調査依頼、顧客・監督機関などへの連絡要否を、法務・個人情報保護・セキュリティ担当と判断する
- 原因を「利用者のミス」で終わらせず、権限、UI、分類、承認、ログ、教育、代替手段のどこで防げたかを見直す
まとめ：情報漏洩対策は「モデル選び」ではなく「境界設計」
生成AIの情報漏洩対策は、特定のサービスを一律に禁止・許可するだけでは完結しません。情報の種類、処理経路、サービスのデータ条件、利用者の権限、外部連携、ログ、異常時の停止と復旧をつなげて設計する必要があります。
最初の一歩としては、全社展開ではなく、公開情報または検証用の架空データで完結する低リスク業務を一つ選び、この記事のチェックリストを使ってデータフローと権限を確認してください。その結果をもとに、要管理情報を扱う業務へ進めるか、構成を変えるか、利用を見送るかを判断します。
経済産業省・総務省のAI事業者ガイドライン（第1.2版）は、AI事業者に期待される取組を整理した資料です。自社のAIガバナンスやリスク管理を検討する際の参照資料として確認しつつ、自社の対象業務、扱う情報、契約、既存のセキュリティ統制に合わせて、実装・運用の内容を決めてください。