公開日:
生成AIの情報漏洩は8つの経路で起こり得るため、承認環境・権限・ログ・教育・初動を組み合わせて防ぎます。
- 要点1:直接入力、誤共有、アカウント侵害、外部連携、RAGなど8経路を管理する
- 要点2:「学習に使わない」と「保存しない」を混同せず、製品・契約・設定ごとに確認する
- 要点3:承認環境、最小権限、ログ、教育、事故対応を一体で運用する
対象読者:中小企業の経営者、DX推進担当者、情報システム部門
今日やること:利用中の生成AIを棚卸しし、入力禁止情報と事故連絡先を決める
この記事の目次
- 生成AIの情報漏洩は全面禁止だけでは防げない
- 生成AIにおける情報漏洩とは何か
- 「学習される」「保存される」「公開される」は何が違うか
- 生成AIで情報漏洩が起きる8つの経路
- 生成AIに入力してはいけない情報
- 個人情報を入力するときは何を確認すべきか
- 法人向け生成AIなら情報漏洩を防げるのか
- 主要4社の法人向けデータ保護方針
- 公開事例から何を学ぶべきか
- 情報漏洩が企業に与える影響
- 対策1:承認済みサービスと用途を決める
- 対策2:社内ガイドラインを実務に落とす
- 対策3:アカウントと権限を管理する
- 対策4:DLP、CASB、ログ監視を検討する
- 対策5:RAGと外部コネクターを安全に使う
- 対策6:従業員教育とシャドーAI対策を組み合わせる
- 機密情報を入力した直後に行う初動
- 中小企業向け30・60・90日ロードマップ
- 導入前チェックリスト
- よくある質問
- まとめ
生成AIへ顧客情報や未公開資料を入力しただけで、直ちにインターネット上へ公開されるとは限りません。しかし、入力データの保存、共有設定、既存権限、外部連携、アカウント侵害などを通じて、意図しない相手が情報へアクセスする可能性はあります。
企業の対応は「全面禁止」か「法人版なら自由」の二択ではありません。情報の重要度に応じて環境・用途・入力範囲を決め、事故時に止められる運用を作ることが重要です。
生成AIの情報漏洩は全面禁止だけでは防げない
全面禁止だけでは、個人アカウントやWordPressのプラグインなど未承認利用が見えなくなります。一方、自由利用では入力先や共有範囲を追跡できません。承認済みサービスを用意し、用途・データ・権限・ログを管理します。
総務省・経済産業省の「AI事業者ガイドライン」も、安全性、プライバシー、セキュリティ、透明性などを整理しています(公式:https://www.meti.go.jp/press/2024/04/20240419004/20240419004.html )。製品機能だけでなく組織的に管理します。
生成AIにおける情報漏洩とは何か
本記事でいう情報漏洩とは、会社が管理すべき情報を、権限のない人やサービスが閲覧・取得・再利用できる状態にすることです。外部公開だけでなく、社内の権限外閲覧、委託先への不適切な送信、共有リンクの誤設定も含みます。
確認対象は、プロンプトやファイルの入力、回答生成、入出力・ログの保存、他者や連携先への共有、契約終了後の削除までです。「回答に秘密が表示されたか」だけでなく、データのライフサイクル全体を見ます。
\ AI導入の進め方を一緒に整理しませんか /
AI顧問の無料相談はこちら「学習される」「保存される」「公開される」は何が違うか
情報漏洩を考える際は、次の4概念を混同しないことが重要です。
| 概念 | 意味 | 確認すべき点 |
|---|---|---|
| モデル学習への利用 | 入出力をモデル改善や訓練に使うこと | 既定値、オプトイン、対象製品 |
| 保存・保持 | 会話履歴、ログ、ファイル等を一定期間保管すること | 保存場所、削除方法、例外、管理者設定 |
| 第三者への提供 | 委託先等を含む別主体がデータを扱うこと | 契約、サブプロセッサー、利用目的 |
| 公開・共有 | リンクや権限設定によって他者が閲覧できること | 共有範囲、検索可能性、再共有 |
法人向け製品が「入力を基盤モデルの学習に使わない」と定めていても、サービス提供、セキュリティ監視、履歴、監査、法令対応のためにデータが保存される場合があります。つまり、学習に使わない≠保存しないです。
保持条件は会社名だけでは決まりません。同じ事業者でもチャット、API、追加機能、管理者設定、契約条件によって異なるため、「一律に何日で消える」と断定せず、導入時と仕様変更時に公式文書を確認します。
生成AIで情報漏洩が起きる8つの経路
生成AIの情報漏洩は、従業員の直接入力だけではありません。NISTの「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」は、データプライバシー、情報セキュリティ、プロンプトインジェクション、第三者依存などを生成AIの管理対象として扱っています(公式:https://doi.org/10.6028/NIST.AI.600-1 )。企業では次の8経路に分けると、対策の抜けを見つけやすくなります。
| 経路 | 典型的な場面 | 主な対策 |
|---|---|---|
| 1. 直接入力 | 顧客名簿や契約書をプロンプトへ貼る | 情報分類、入力制限、承認環境 |
| 2. ファイル添付 | 会議録、表計算、画像に機密が残る | マスキング、メタデータ確認 |
| 3. 出力の誤共有 | 回答や共有リンクを誤送信する | 送信前確認、共有制限、期限設定 |
| 4. アカウント侵害 | パスワード窃取で履歴やファイルを見られる | SSO、多要素認証、端末管理 |
| 5. 権限の過剰付与 | AIが利用者の想定以上の社内文書を検索する | 最小権限、棚卸し、アクセス検証 |
| 6. 外部連携 | プラグイン、コネクター、API連携先へ送信される | 連携審査、送信範囲の限定 |
| 7. RAGの設計不備 | 検索結果に他部署・他社の文書が混ざる | 文書単位の認可、テナント分離 |
| 8. プロンプトインジェクション | 文書やWebページ内の命令で意図しない取得・送信が起きる | 入力分離、ツール制限、人の承認 |
直接入力は利用部門、認証は情報システム部門、契約は法務・購買というように、経路ごとの担当を置きます。
\ 業務自動化のお悩みをAI顧問に相談できます /
AI顧問の無料相談はこちら生成AIに入力してはいけない情報
未承認の生成AIには、原則として次の情報を入力しません。承認済み環境でも、業務上必要か、入力を最小化できるかを先に判断します。
| 情報区分 | 例 | 未承認環境 | 承認環境での考え方 |
|---|---|---|---|
| 公開情報 | 公開済みWebページ、製品カタログ | 可 | 出典・著作権を確認 |
| 社内限定情報 | 社内手順、未公開の会議メモ | 不可 | 許可用途と共有範囲内のみ |
| 機密情報 | 事業計画、設計図、ソースコード、契約条件 | 不可 | 個別承認、最小化、監査を前提 |
| 個人・顧客情報 | 氏名、連絡先、購買・相談履歴 | 不可 | 利用目的、契約、安全管理を確認 |
| 認証情報 | パスワード、秘密鍵、APIキー、復旧コード | 不可 | 原則入力しない |
| 法令・契約で制限される情報 | 秘密保持対象、要配慮個人情報等 | 不可 | 法務・責任者が個別判断 |
伏字にしたつもりでも、部署、日付、案件内容の組み合わせで個人や企業を推測できる場合があります。必要な箇所だけ抽出する、架空データに置き換える、ローカルで匿名化してから送るなど、データ最小化を徹底します。
個人情報を入力するときは何を確認すべきか
個人情報保護委員会は、個人情報取扱事業者が生成AIへ個人データを含むプロンプトを入力する場合、利用目的の範囲内かを確認し、提供事業者が機械学習に利用しないこと等を十分確認するよう注意喚起しています(公式:https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ )。
「学習するか」に加え、利用目的、入力項目の最小化・匿名化、応答生成以外の利用、国外移転、委託・再委託、保存・削除、事故通知を確認します。出力から本人に不利益な判断をしない仕組みも必要です。
個人情報の入力が直ちに一律で違法になるわけでも、利用目的内なら常に問題がないわけでもありません。適用法令、本人への通知・同意、委託か第三者提供か、契約と実際の処理によって評価が異なるため、必要に応じて専門家へ確認します。
\ AI活用の「次の一手」を一緒に考えませんか /
AI顧問の無料相談はこちら法人向け生成AIなら情報漏洩を防げるのか
法人向けサービスには、学習不使用、組織アカウント、SSO、監査ログ、管理者設定など、企業利用に必要な機能が用意されることがあります。ただし、契約しただけで安全になるわけではありません。
たとえば既存のクラウドストレージで「全社員が閲覧可能」になっていれば、AIはその権限に沿って広い範囲を検索できる可能性があります。共有設定の問題をAIが新しく作るのではなく、既存の過剰権限による影響を拡大・顕在化させる形です。
選定時は、対象契約・機能、学習利用の既定値、入出力とログの保存・削除、保存地域、暗号化、委託先、SSO、多要素認証、監査ログ、外部連携、契約終了時の処理を確認します。
主要4社の法人向けデータ保護方針
主要4社の公式情報を比較すると、対象法人サービスで顧客データを基盤モデルの学習に使わないという大原則が確認できます。ただし、これは保存ゼロを意味しません。以下は概要であり、実際には自社が契約する製品・機能・地域の最新条件を確認してください。
| 事業者 | 法人向け方針の要点 | 導入時の注意 |
|---|---|---|
| OpenAI | 対象ビジネス製品の業務データを既定でモデル学習に使わない | ChatGPT Enterprise、API、各機能の保持・管理条件を分けて確認 |
| Anthropic | 商用製品の顧客コンテンツを既定でモデル訓練に使わない | チャット製品、API、追加機能、契約上の例外を確認 |
| 対象のGoogle Workspaceサービスでは、許可なく組織外の生成AIモデルの訓練に顧客データを使わない | Workspaceの保持、共有、管理設定と一体で確認 | |
| Microsoft | Microsoft 365 Copilotのプロンプト、応答、Microsoft Graph経由データを基盤モデルの学習に使わない | 元データのアクセス権、保持、コンプライアンス設定を確認 |
公式情報は、OpenAI「Enterprise privacy」(https://openai.com/enterprise-privacy/ )、Anthropic「Commercial Terms of Service」(https://www.anthropic.com/legal/commercial-terms )、Google Workspace「Generative AI Privacy Hub」(https://workspace.google.com/security/ai-privacy/ )、Microsoft Learn「Microsoft 365 Copilot のデータ、プライバシー、セキュリティ」(https://learn.microsoft.com/ja-jp/copilot/microsoft-365/microsoft-365-copilot-privacy )で確認できます。
要点は4社とも、学習に使わない≠保存しないということです。保持期間を一律に断定せず、履歴、監視ログ、保存型機能、管理者設定、削除要求、法的義務を個別に調べます。OpenAI環境の詳細はChatGPT Enterpriseの解説、Microsoft環境はMicrosoft 365 Copilotの導入ガイドも参照してください。
自社の情報区分と利用業務に合う環境を整理したい場合は、生成AI活用の相談窓口をご利用ください。
公開事例から何を学ぶべきか
事故名を覚えるだけでは再発を防げません。公的な注意喚起から、目的外入力、契約確認不足、外部文書内の悪意ある命令、過剰権限といった原因を自社の統制へ置き換えます。
NISTの生成AIプロファイルが示すように、リスクの特定、測定、管理、統治を継続します。「従業員の不注意」で終わらせず、不注意が重大事故になりにくい仕組みへ変えることが教訓です。
情報漏洩が企業に与える影響
生成AI経由の漏洩は、顧客対応や信用低下、法令・契約上の対応、認証情報の悪用、競争上の損失、調査・復旧負担につながります。件数だけで軽重を決めず、機密性、本人への影響、回収可能性も評価します。認証情報や営業秘密は少量でも重大です。
対策1:承認済みサービスと用途を決める
最初に「誰が、どのサービスを、何の業務で、どの情報まで使えるか」を一覧化します。承認サービスを1つに固定する必要はありませんが、用途ごとの責任者を決めます。
台帳には、サービス、契約主体、管理者、部署、目的、入力可能な情報区分、連携先、確認日、停止手順を記録します。個人アカウントと会社管理アカウントは混在させません。
承認外利用を減らすには、禁止だけでなく、現場が必要とする要約・翻訳・検索などを安全に実行できる代替手段を示します。例外利用は申請期限と終了後のデータ削除まで管理します。
対策2:社内ガイドラインを実務に落とす
ガイドラインは「機密情報を入力しない」の一文では足りません。従業員が迷わず判断できるよう、具体例と手順を含めます。
- 利用可能なサービス、アカウント、端末
- 許可用途と禁止用途
- 入力できる情報・できない情報の例
- 匿名化、ファイル添付、共有リンクのルール
- AI出力を社外利用するときの確認者
- 著作権、個人情報、誤情報への対応
- 誤入力、誤共有、アカウント侵害時の連絡先
- 違反時の停止、調査、再発防止の流れ
詳しい作成手順は生成AIガイドラインの作り方で解説しています。公開後は改定日と責任者を明記し、サービス仕様や業務が変わるたびに見直します。
対策3:アカウントと権限を管理する
情報漏洩対策の土台はID管理です。会社管理のアカウントに統一し、SSOと多要素認証を有効にします。共有アカウントは利用者と操作を特定しにくいため避けます。
権限は、生成AI側だけでなく、接続するメール、ファイルストレージ、顧客管理、社内Wikiまで確認します。異動・退職時の削除、休眠アカウントの停止、管理者権限の定期レビューを行います。
特に検索型AIを導入する前は、「全員」「リンクを知る全員」といった広い共有設定を棚卸しします。AIが元システムの権限を尊重する設計でも、元の権限が過剰なら情報漏洩リスクは残ります。
対策4:DLP、CASB、ログ監視を検討する
DLP(Data Loss Prevention)は機密データの送信を検知・制御し、CASB(Cloud Access Security Broker)はクラウド利用の可視化やポリシー適用を支援します。すべての企業が同じ製品を導入する必要はありませんが、リスクに応じて検討します。
まずは組織アカウントの利用状況、管理者ログ、外部共有、連携アプリを確認できる状態にします。そのうえで、個人番号、顧客番号、秘密鍵などのパターン検知、未承認サービスへのアップロード制御、異常な大量利用の通知を設計します。
ログ自体も個人情報や機密を含み得ます。収集目的、閲覧者、保管、削除を決め、誤検知と見逃しも評価します。
対策5:RAGと外部コネクターを安全に使う
RAG(Retrieval-Augmented Generation)は、社内文書などを検索して回答生成を補う仕組みです。回答の根拠を与えられますが、RAGにすれば自動的に安全になるわけではありません。
安全な設計では、文書を取り込む時点で所有者、機密区分、閲覧権限、保存期限を付与し、検索時にも利用者の権限を確認します。部署や取引先ごとの分離が必要な場合、検索インデックスやキャッシュにも境界を反映します。
外部コネクターには必要最小限の読み取り権限を与え、書き込み・送信・削除など影響の大きい操作は人の承認を挟みます。Webページや文書に埋め込まれた指示を、システム命令として実行しない対策も必要です。取り込み元、引用元、操作履歴を追跡できるようにします。
対策6:従業員教育とシャドーAI対策を組み合わせる
従業員教育では、用語の説明より、実際の業務に近い判断練習が効果的です。「顧客名だけ消せばよいか」「共有リンクを社外へ送ってよいか」「誤入力後に会話を消せば終わりか」など、迷いやすい場面を扱います。
同時に、会社が把握していない生成AI利用であるシャドーAIを可視化します。簡易アンケート、クラウド利用ログ、経費、ブラウザー拡張、連携アプリの棚卸しを組み合わせます。発見時に直ちに処罰する運用だけでは隠れやすいため、必要な用途を聞き、安全な代替策へ移行させます。
シャドーAIの把握と抑制策はシャドーAIの解説も参考にしてください。教育は年1回で終わらせず、新機能の追加や事故事例に合わせて短い周知を継続します。
機密情報を入力した直後に行う初動
誤入力に気づいたら、本人だけで判断して会話を削除し、終わりにしてはいけません。削除操作で、監視ログ、連携先、共有済みデータまで消えるとは限らないからです。最初の24時間は次の順序で対応します。
- 利用を止める:該当会話、共有リンク、連携、必要に応じてアカウントを一時停止する
- 連絡する:上司、情報システム、セキュリティ、法務・個人情報担当へ所定経路で報告する
- 事実を保全する:日時、サービス、アカウント、入力内容、添付、回答、共有先、実施操作を記録する
- 認証情報を無効化する:APIキー、パスワード、トークン等が含まれれば直ちに失効・再発行する
- 範囲を確認する:学習利用、保存、共有、外部連携、ログ、管理者権限を契約と設定から調べる
- 事業者へ連絡する:管理者窓口から削除可否、調査協力、保全の扱いを確認する
- 影響を評価する:個人、顧客、取引先、法令・契約上の通知や報告の要否を判断する
- 再発を止める:同種データの入力制御、権限修正、周知を暫定実施する
記録保全と削除は状況によって優先関係が変わります。重大事故の可能性がある場合は、事故対応責任者の指示で進めます。個人データの漏えい等に関する報告・本人通知の要否は、個人情報保護委員会の公式情報(https://www.ppc.go.jp/personalinfo/legal/leakAction/ )と個別事情を確認してください。
中小企業向け30・60・90日ロードマップ
大規模な仕組みを一度に導入せず、利用実態の把握から始めます。
| 期間 | 目的 | 実施項目 | 完了条件 |
|---|---|---|---|
| 30日まで | 見える化と緊急ルール | 利用サービス調査、情報分類、入力禁止情報、事故連絡先、管理者指定 | 誰が何を使い、事故時に誰へ連絡するか分かる |
| 60日まで | 承認環境と統制 | 法人契約の確認、SSO・多要素認証、共有権限の棚卸し、ガイドライン公開 | 承認用途を会社管理アカウントで実行できる |
| 90日まで | 検証と改善 | ログ確認、DLP等の要否判断、事故演習、RAG・連携審査、ルール改定 | 検知から報告・停止まで実地確認できる |
経営者は許容リスクと責任者、DX推進担当者は用途、情報システム部門は認証・権限・ログを担当します。少人数でも承認者と事故連絡先は明示します。
導入前チェックリスト
生成AIを業務へ導入する前に、以下を確認してください。「いいえ」がある項目は、利用範囲を限定してから解消します。
- [ ] 利用目的と対象業務が文書化されている
- [ ] 入力可能・禁止の情報区分が具体例付きで決まっている
- [ ] 法人契約の対象機能と最新データ方針を確認した
- [ ] 学習利用と保存・保持を別々に確認した
- [ ] 個人情報の利用目的、最小化、契約上の扱いを確認した
- [ ] SSO、多要素認証、退職・異動時の処理を設定した
- [ ] 接続先の共有権限と外部コネクターを棚卸しした
- [ ] 出力の事実確認と社外送信の承認者を決めた
- [ ] 管理者ログを確認でき、閲覧権限も限定した
- [ ] 誤入力時の連絡先、停止、記録、事業者照会手順がある
- [ ] 仕様変更を再確認する責任者と日付を決めた
- [ ] 小規模な試行で漏洩シナリオを検証した
チェックリストは契約審査やリスク評価の代わりではありません。扱う情報の重要度が高いほど、セキュリティ・法務の個別レビューを追加します。
よくある質問
Q1. 生成AIに入力した情報は必ず外部に漏れますか?
必ず漏れるわけではありません。ただし、サービス側の保存、共有設定、外部連携、アカウント侵害、利用者の誤送信などの経路があります。入力情報の重要度と契約・設定を確認し、必要最小限にします。
Q2. ChatGPTに入力した内容は学習に使われますか?
製品区分と設定によって異なります。OpenAIは対象ビジネス製品の業務データを既定でモデル学習に使わないと説明していますが、それは保存しないという意味ではありません。ChatGPT Enterpriseなど、実際に契約する製品の最新公式方針と管理設定を確認してください。
Q3. 法人向けサービスなら機密情報を入力しても安全ですか?
無条件に安全とはいえません。法人向け機能があっても、既存権限の過剰設定、共有リンク、外部コネクター、誤送信は残ります。機密区分、業務上の必要性、契約、権限、ログ、事故対応を確認し、個別に許可します。
Q4. 個人情報を生成AIへ入力すると法律違反ですか?
一律には判断できません。利用目的の範囲、委託・第三者提供の関係、安全管理措置、国外移転、サービスの実際の処理などで評価が変わります。個人情報保護委員会の注意喚起を確認し、必要に応じて専門家へ相談してください。
Q5. RAGを使えば情報漏洩を防げますか?
RAGだけでは防げません。文書の登録範囲、検索時の認可、キャッシュ、引用表示、テナント分離、プロンプトインジェクションへの対策が必要です。元システムの過剰な共有権限も導入前に修正します。
まとめ
生成AIの情報漏洩は、直接入力、ファイル添付、誤共有、アカウント侵害、過剰権限、外部連携、RAG、プロンプトインジェクションという8経路から起こり得ます。全面禁止や法人契約だけに頼らず、情報分類、承認環境、最小権限、ログ、教育、初動を組み合わせることが重要です。
特に「学習に使わない」と「保存しない」は別です。OpenAI、Anthropic、Google、Microsoftの法人向け方針を確認する際も、保持日数を一律に決めつけず、契約する製品・機能・設定ごとに保存、削除、共有、法的例外を確認してください。
まずは利用中の生成AIを棚卸しし、入力禁止情報と事故連絡先を決めます。その後、30・60・90日の順で承認環境、権限、ログ、演習まで進めると、利用を止めずにリスクを下げられます。
ルール策定から利用環境の選定、定着まで整理したい企業は、生成AI活用について相談するをご確認ください。





