生成AIの情報漏洩対策ガイド｜社内ルール・学習させない設定・PIA【2026年最新】

生成AI特有の3つのリスク構造

生成AIの情報漏洩には、 従来のITにはない3つの特有リスクがあります。 これらを理解しないまま「ChatGPTは便利だから使おう」 と展開すると、 統制不能な漏洩が起こります。

• 入力データの学習利用リスク: 入力した情報がAIモデルの再学習に使われ、 将来の出力として他者に再現される可能性
• サーバー保存リスク: 入力・出力の履歴が提供者のサーバーに保存され、 提供者側の漏洩・不正アクセスで流出する可能性
• 正規利用の死角リスク: 社員が「便利だから」 と自発的に機密情報を入力するため、 攻撃検知の仕組みでは捕捉できない

とくに1つ目の「学習利用リスク」 は誤解が多い領域です。 結論を先取りすると、 法人向けプランや適切な設定では、 入力データは学習に使われません。 「生成AI＝入力した情報が全部学習される」 という認識は古く、 後述する第4章・第5章で正確に整理します。

「禁止」 が最悪手である理由

情報漏洩を恐れて生成AIを全面禁止する企業は少なくありません。 しかし、 これはセキュリティ的に最悪手になりがちです。 理由は、 禁止しても社員の業務上のニーズは消えず、 個人スマホ・個人アカウント・自宅PCで無許可利用（シャドーAI）が始まるからです。 会社が管理できない環境での利用が増えれば、 漏洩リスクはむしろ上がります。

実際、 各種調査では「会社が生成AI利用を禁止している」 にもかかわらず「業務で生成AIを使っている社員」 が相当数存在することが繰り返し報告されています。 禁止は「使われていない」 を意味せず「会社が把握できていない」 を意味する だけです。 正しい対策は「安全に使わせる環境を整える」 ことであり、 本記事はその実装手順を扱います。

経路1・2: 提供者側に残る「学習」 と「保存」

経路1（学習利用）と経路2（サーバー保存）は、 提供者側に情報が残る 系統です。 学習利用は「入力がAIモデルの賢さの素材として再利用される」 リスク、 サーバー保存は「学習されなくても入出力ログが提供者のサーバーに残る」 リスクで、 両者は別物です。 「学習されない＝サーバーに何も残らない」 ではない 点に注意が必要です。

この2経路は、 契約形態とサービス設定でほぼ構造的に潰せます。 法人向けプラン（学習に使わないことが規約で保証される）を契約し、 データ保持期間をゼロまたは最小に設定し、 必要に応じてDPA（データ処理契約）を締結すれば、 提供者側に残るリスクは実務水準まで下がります。 詳細は第4章・第5章で解説します。

経路3・4: 人とルールに起因する「誤入力」 と「シャドーAI」

経路3（プロンプト誤入力）と経路4（シャドーAI）は、 人とルールに起因する 系統です。 これらは技術設定では塞げません。 どんなに安全なサービスでも、 社員が「入れてはいけない情報」 を入れてしまえば、 また会社が把握していないツールを使えば、 統制は効きません。

この2経路は、 利用規程（ガイドライン） × 教育 × 公式環境の提供で潰します。 「何を入れて良いか・何を入れてはいけないか」 を明文化し、 社員に周知し、 公式の安全な生成AI環境を提供して『これを使ってください』 と示す ことが、 シャドーAIを防ぐ最も確実な方法です。 詳細は第6章・第9章で扱います。

経路5: 見落とされがちな「連携・拡張」

経路5（連携・拡張）は最も見落とされやすい経路です。 生成AIを外部サービスと連携（プラグイン・カスタムGPT・API・自動化ツール）させると、 連携先の管理が甘ければそこから情報が漏れます。 APIキーの流出、 検証されていないサードパーティ拡張、 自動化フローを介した社外データ送信などが典型です。

対策は「連携先の事前審査」 と「権限の最小化」です。 業務で使う連携先を限定し、 APIキーは権限を絞って発行し、 ログを残す。 高度な活用ほどこの経路のリスクが上がるため、 連携を増やす段階では必ずセキュリティレビューを挟む 運用が必要です。

類型1: ソースコード・設計情報の貼り付け流出

エンジニアが不具合のあるソースコードや社内システムの設計情報を、 デバッグ目的でそのまま生成AIに貼り付けた事例です。 自社の競争力に直結する技術情報が、 提供者のサーバーに渡る・履歴に残るという問題が指摘され、 一部企業では生成AI利用を一時全面禁止する措置に至りました。

この類型の教訓は、 「便利だから」 という現場判断が、 経営レベルの情報資産流出につながる ことです。 対策は、 法人プランでの学習オフ運用に加え、 「コード・設計情報のうち何を入れて良いか」 を規程で明確化することです。 禁止ではなく、 安全に使える境界線を引くアプローチが有効です。

類型2: 個人情報・顧客リストの要約依頼

営業・事務担当者が顧客リストや個人情報を含む資料を、 要約・整形・分析のために生成AIに入力した事例です。 個人情報保護法上、 個人データを外部サービスに渡す行為は「第三者提供」 や「委託」 に該当しうるため、 同意取得や委託先監督の観点で問題になります。

この類型は法令リスクが直結します。 対策は、 個人情報は原則入力禁止とし、 やむを得ず扱う場合はマスキング（氏名・住所等を伏字や記号に置換）してから入力する ルールを徹底することです。 また、 個人データを扱う業務に生成AIを組み込む場合は、 後述するPIA（第8章）の実施が推奨されます。

類型3: 提供者側の不具合による他ユーザーへの露出

生成AIサービス提供者側のシステム不具合により、 一部ユーザーの会話履歴やタイトル・課金情報が、 別ユーザーに一時的に表示された類型です。 利用者側に落ち度がなくても、 提供者側の障害で情報が露出するリスクがあることを示しました。

この類型は利用者側で完全には防げないため、 「そもそも提供者に残す情報を最小化する」 ことが対策の軸になります。 データ保持期間をゼロに設定する、 機密度の高い情報は入力前にマスキングする、 提供者のセキュリティ認証（SOC 2・ISO/IEC 27001等）を契約時に確認する、 といった多層的なリスク低減が必要です。

類型4: シャドーAIによる無管理流出

会社が生成AI利用を明確に許可も禁止もしていない状態で、 社員が個人アカウントの無料版を業務利用し続けていた類型です。 会社は利用実態を把握できず、 どの情報がどのサービスに入力されたかも追跡不能。 漏洩が起きても検知・対応ができないという、 最も統制が効かない状態です。

この類型の教訓は、 「許可も禁止もしない曖昧な状態」 が最も危険 ということです。 対策は明快で、 公式の生成AI環境を用意し、 利用規程で「公式環境を使うこと・個人アカウントの業務利用は禁止」 を明文化し、 周知することです。 シャドーAIの統制は第9章で詳しく扱います。

基本の考え方｜「学習オフ」 と「データ保持」 を分けて設定する

設定で最も重要なのは、 「学習に使わせない設定」 と「履歴・データを保持させない設定」 は別物として両方を確認することです。 学習をオフにしても、 入出力のログが一定期間サーバーに保存される場合があります。 機密度が高い用途では、 学習オフに加えてデータ保持期間の最小化まで設定するのが原則です。

• 学習利用のオフ: 入力をモデル改善に使わせない設定。 個人版は手動オフ、 法人版は標準で対象外が多い
• データ保持の最小化: 入出力ログの保存期間を短縮・ゼロ化。 法人プランで選択可能なケースが多い
• 組織アカウントでの統一: 個人任せにせず、 管理者が組織全体に設定を強制適用する
• 定期的な再確認: 規約・設定UIは更新されるため、 半年に一度は設定状態を点検する

注意点として、 設定UIや規約の名称・場所は提供者のアップデートで変わります。 本記事で具体的なボタン名を断定すると陳腐化するため、 ここでは「学習オフ」 と「データ保持最小化」 の2軸を必ず確認する、 という原則を示します。 最新の正確な設定手順は各サービスの公式ヘルプで確認してください。

個人任せにしない｜管理者による組織統制が前提

最大の落とし穴は、 設定を社員個人の手作業に委ねることです。 「各自で学習オフにしてください」 と通知するだけでは、 必ず設定し忘れる社員が出ます。 情報漏洩対策としては、 管理者が組織アカウントで一括して設定を強制適用できる法人プランを選ぶことが前提になります。

法人プラン（ChatGPT Enterprise / Team、 Claude の法人契約、 Microsoft 365 Copilot、 Gemini の業務向け契約 等）では、 管理者コンソールから組織全体のデータ取扱いポリシーを統一できます。 個人の設定ミスに依存しない構造を作ることが、 漏洩対策の信頼性を一段引き上げます。

API利用は「学習されない」 が標準だが保存に注意

自社システムに生成AIを組み込むAPI利用では、 主要提供者は入力データを学習に使わないことを標準としています。 ただし、 不正利用監視のために一定期間ログを保持する場合があり、 「学習されない＝何も残らない」 ではない点は変わりません。 機密用途では、 ゼロ保持オプションやリージョン指定の可否を契約時に確認します。

また、 API経由でも自社アプリ側のログにプロンプトが平文で残ると、 そこが新たな漏洩点になります。 API利用時は、 提供者側の設定だけでなく、 自社実装側のログ・保存設計までセットでセキュアにする必要があります。

コスト差はわずか、 リスク差は致命的

法人プランは無料版に比べて1名あたり月数千円のコストがかかりますが、 情報漏洩が1件起きたときの損害（賠償・信用失墜・対応コスト）と比べれば、 投資対効果は明らかです。 機密情報を扱う業務で生成AIを使うなら、 「無料版で済ませる」 という選択肢自体が経営リスクになります。

中小企業では「まず無料版で試して、 効果が出たら法人プランへ」 という段階導入も現実的ですが、 その場合でも「無料版の試用段階では機密情報・個人情報は一切入力しない」 という線引きを最初に規程化しておく必要があります。 試用と本番のセキュリティ基準を曖昧にしないことが肝心です。

プラン選定で確認すべき5項目

法人プランを選定する際は、 価格や機能だけでなく、 以下のセキュリティ観点を契約前に必ず確認します。

• 学習利用: 入力データを学習に使わないことが規約で明記されているか
• データ保持: 入出力ログの保持期間・保存場所・削除方法が選べるか
• 認証・契約: SOC 2 / ISO/IEC 27001、 DPA（データ処理契約）の締結可否
• アクセス管理: SSO・権限管理・退職者の即時アカウント遮断
• 監査ログ: 誰がいつ何を利用したかを可視化・出力できるか

この5項目は、 後述する第11章の導入前セキュリティチェックリストにも組み込んでいます。 プラン選定は「いちばん安い」 でも「いちばん有名」 でもなく、 自社の情報資産の機密度に見合うセキュリティ要件を満たすか、 で判断します。

利用規程に必ず盛り込む7項目

生成AI利用規程には、 最低限以下の7項目を盛り込みます。 これらが揃っていれば、 中小企業の実務には十分です。

• 目的と適用範囲: 誰が・どの業務で・どのツールを使えるか
• 使用を許可するサービス: 公式に契約した法人プランのみを指定（個人アカウント禁止）
• 入力禁止情報の定義: 個人情報・機密情報・知的財産・未公開情報等の具体例
• 出力物の取扱い: 生成物の検証義務・著作権・責任の所在
• 禁止行為: シャドーAI・無断連携・機密の貼り付け等
• インシデント報告義務: 漏洩の疑い時の報告先と手順
• 違反時の対応: 就業規則との連動・罰則

とくに重要なのが「入力禁止情報の定義」です。 「機密情報を入れないでください」 だけでは抽象的で守られません。 「顧客の氏名・連絡先」 「未公開の財務数値」 「ソースコード全文」 「契約書原本」 のように、 自社の業務に即した具体例を列挙することで、 現場が判断できる規程になります。

雛形｜入力可否ルールの条文イメージ

利用規程の核となる「入力可否ルール」 は、 以下のような条文イメージで作成できます。 自社の情報分類に合わせて調整してください。

（入力禁止情報）従業員は、 会社が許可した生成AIサービスであっても、 次の各号に掲げる情報を入力してはならない。 (1) 個人情報（氏名・住所・連絡先・マイナンバー等）。 (2) 顧客・取引先から守秘義務を負って受領した情報。 (3) 未公開の財務・経営情報。 (4) 自社の営業秘密・技術情報・ソースコード。 (5) 契約書その他の法的文書の原本。 ただし、 個人を特定できないようマスキングした場合はこの限りでない。

（許可ツール）従業員は、 会社が指定し契約した生成AIサービス（以下「公式環境」 という）のみを業務に使用するものとし、 個人アカウントによる生成AIの業務利用を禁止する。 公式環境以外のツールを業務に利用する場合は、 事前に情報システム部門の承認を得なければならない。 — このような形で、 「何を入れてはいけないか」 と「どのツールを使うか」 を明文で固定します。

規程は「配って終わり」 にしない

最も多い失敗が、 規程を作って配布しただけで運用が形骸化することです。 規程は「読まれ・理解され・守られて」 初めて機能します。 配布と同時に、 短時間の説明会・eラーニング・確認テストをセットにし、 「なぜ入れてはいけないのか」 を腹落ちさせる ことが、 規程を生きたものにします。

また、 規程は一度作って終わりではなく、 生成AIの進化・新サービスの登場・インシデントの発生に応じて更新が必要です。 半年〜1年に一度の見直しサイクルを最初から組み込んでおくと、 規程が陳腐化して守られなくなる事態を防げます。 ガイドライン整備に不安があれば、 AIコンサルティング の活用で雛形作成から運用設計まで支援を受けられます。

マスキングの実務｜伏字・記号化・ダミー置換

「取扱注意」 区分の情報を生成AIで扱う際の鍵がマスキング（匿名化・仮名化）です。 個人名を「A様」 に、 会社名を「X社」 に、 具体的な金額を「○○万円」 に置き換えてから入力すれば、 要約・整形・分析といった生成AIのメリットを享受しつつ、 漏洩リスクを大きく下げられます。

• 氏名・連絡先: 「A様」 「担当者B」 等の記号に置換
• 企業名・固有名詞: 「X社」 「Y製品」 等に抽象化
• 数値・金額: 必要な桁感だけ残しダミー値に
• 識別子: 顧客ID・契約番号等は削除またはダミー化

ただし、 マスキングが甘いと「他の情報と組み合わせて個人が特定できる」 再識別リスクが残ります。 「A様・港区在住・40代・年商2億の会社経営」 のように属性を並べると特定されうるため、 マスキングは「単独で特定できない」 だけでなく「組み合わせでも特定できない」 水準を目指します。

機密・極秘は「閉域・オンプレ・RAG」 で別設計

「機密・極秘」 区分の情報は、 公開のクラウド型生成AIに入れるべきではありません。 これらを業務で活用したい場合は、 外部に情報を出さない閉じた環境での別設計が必要です。 具体的には、 自社データを社外に出さずに参照させるRAG（検索拡張生成）構成、 プライベートクラウドやオンプレミスでのLLM運用、 業務専用のセキュア環境構築などが選択肢になります。

AIBUILDERZ では、 機密度の高い社内文書を扱うカスタマーサポートで、 社内データを外部に出さないRAG構成を最短2週間で立ち上げた実績があります。 「機密情報は使えない」 と諦めるのではなく、 機密度に応じて環境を分けるのが、 セキュリティと活用を両立させる設計思想です。 機密データのAI活用設計は AI導入の費用相場ガイド で費用感も確認できます。

「迷ったら入れない」 を最終ルールにする

どれだけ分類を整備しても、 現場では「これはどの区分か判断に迷う」 ケースが必ず出ます。 そのための最終安全弁が「迷ったら入れない・上長か情シスに確認する」 という原則です。 この一文を規程の末尾に置くだけで、 グレーゾーンでの漏洩を大幅に減らせます。

逆に言えば、 判断に迷ったときに気軽に相談できる窓口を用意しておくことが、 「迷ったら入れない」 を機能させる前提です。 相談窓口がないと、 社員は「面倒だから自己判断で入れてしまう」 方向に流れます。 ルールと相談体制はセットで設計します。

なぜ生成AIでPIAが重要なのか

生成AIは、 個人情報を「外部のサービスに送信する」 「学習や保存の可能性がある」 「出力が予測しづらい」 という、 プライバシー上の論点が重なる技術です。 通常のシステム導入以上に、 「どの個人情報が・どこへ・どう流れ・どう保護されるか」 を事前に棚卸しする必要があります。 PIAはこの棚卸しを構造化する手続きです。

PIAを実施することで、 導入後に「実は個人情報が外部に流れていた」 という事後発覚を防ぎ、 さらに「リスクを評価したうえで導入した」 という説明責任（アカウンタビリティ）を果たせます。 個人情報保護委員会もPIAの活用を推奨しており、 取引先や顧客への信頼性確保にもつながります。

PIAの5ステップ（簡易版）

中小企業でも実施できるPIAの簡易ステップは以下の通りです。 完璧な大企業版を目指す必要はなく、 要点を押さえた簡易版で十分にリスクを可視化できます。

• STEP1 対象の特定: 生成AIで扱う個人情報の種類・量・対象者を洗い出す
• STEP2 データフロー図化: 個人情報が「取得→入力→処理→保存→出力」 でどう流れるか図にする
• STEP3 リスク評価: 各段階で漏洩・目的外利用・再識別のリスクを洗い出す
• STEP4 対策の決定: マスキング・学習オフ・保持最小化・契約整備等の対策を割り当てる
• STEP5 文書化と承認: 評価結果と対策を文書化し、 責任者が承認・記録する

このプロセスで最も価値が高いのがSTEP2のデータフロー図化です。 個人情報の流れを図にすると、 「ここで外部に出ている」 「ここに残っている」 という漏洩点が視覚的に明らかになり、 対策の優先順位が一目で分かります。

PIAと利用規程・契約の連動

PIAは単独で完結するものではなく、 利用規程（第6章）・データ取扱いルール（第7章）・法人プラン契約（第5章）と連動させて初めて実効性を持ちます。 PIAで洗い出したリスクを、 規程の禁止条項・マスキングルール・契約上の保証条項に落とし込むことで、 「評価して終わり」 を防げます。

また、 PIAは業務やサービスが変わるたびに再実施するのが原則です。 新しい業務に生成AIを広げる・新サービスに乗り換える・扱う個人情報が増える、 といった変化のたびに簡易PIAを回すことで、 漏洩リスクの管理が継続的なものになります。

なぜシャドーAIは生まれるのか

シャドーAIが生まれる根本原因は2つです。 1つは「会社が生成AIを禁止しているが、 業務上のニーズは消えない」 こと。 もう1つは「公式環境が用意されているが、 使いにくい・遅い・許可が面倒」 なことです。 どちらも、 社員が「自分のアカウントで使った方が早い」 と判断する状況を作ります。

つまりシャドーAIは、 社員の悪意ではなく「業務を進めたい」 という善意と、 環境整備の不足から生まれます。 だからこそ、 取り締まりだけでは解決しません。 「使いやすい公式環境を提供する」 ことと「無許可利用の検知体制を持つ」 ことの両輪が必要です。

検知の手段｜技術と運用の両面から

シャドーAIを検知する手段には、 技術的なものと運用的なものがあります。 企業規模やセキュリティ成熟度に応じて組み合わせます。

• ネットワーク監視: 社内ネットワークから生成AIサービスへの通信を可視化（CASB・プロキシログ等）
• アクセス制御: 許可した法人サービス以外の生成AIへのアクセスを制限・警告
• 利用調査・ヒアリング: 定期的なアンケートや1on1で実際の利用実態を把握
• 申告窓口: 「使いたいツール」 を気軽に申告できる窓口で潜在ニーズを吸い上げる

中小企業では高度な監視ツールの導入が難しい場合もあります。 その場合は、 「正直に申告すれば咎めない・むしろ公式化を検討する」 という心理的安全性のある文化づくりが、 実は最も効果的なシャドーAI検知策になります。 罰則で締め上げると、 利用が地下に潜るだけです。

統制の本質は「便利な公式環境」 の提供

シャドーAI対策の本質は、 検知や取り締まりではなく「社員が公式環境を使いたくなる状態を作る」 ことです。 公式の法人プラン環境が、 個人アカウントより使いやすく・速く・許可なくすぐ使えるなら、 社員はわざわざリスクを冒して個人アカウントを使いません。 公式環境の利便性がシャドーAIへの最大の抑止力です。

具体的には、 全社員に法人プランのアカウントを配布し、 よく使うプロンプトをテンプレ化し、 申請なしですぐ使える状態にする。 これにより「安全な環境で・便利に・堂々と使える」 を実現すれば、 シャドーAIは自然に消えていきます。 禁止と監視の発想から、 「公式環境への誘導」 の発想へ転換することが鍵です。

事前準備が初動を決める

このフローは、 インシデントが起きてから作るのでは遅すぎます。 報告窓口・連絡体制・法務の連絡先・判断基準を、 平時のうちに文書化しておくことが重要です。 「誰に・何を・いつまでに報告するか」 が明確になっているだけで、 初動の混乱が大幅に減ります。

とくに中小企業では、 専任のセキュリティ部門がないことが多く、 インシデント時に「誰が指揮を執るか」 が決まっていないと対応が空転します。 小規模でも「インシデント時の責任者と連絡フロー」 を1枚にまとめておくことが、 実効的な備えになります。

チェック結果の読み方

12問のうち、 チェックの数で自社のセキュリティ成熟度を簡易判定できます。 重要なのは「いくつ付いたか」 だけでなく「どこが欠けているか」 です。 1つでも未チェックがあれば、 そこが優先的に塞ぐべき漏洩点になります。

• 10〜12個: 十分な対策水準。 定期的な見直しで維持する
• 6〜9個: 基本は押さえているが穴がある。 未チェック項目を早急に補完
• 3〜5個: リスクが高い状態。 法人プラン契約と規程整備を最優先で着手
• 0〜2個: 無防備な状態。 全社展開を一時停止し、 基盤整備から始める

このチェックリストは、 経営会議やセキュリティ委員会の議題としてそのまま使えます。 各項目の担当者と期限を割り当てれば、 漏洩対策のロードマップになります。 「なんとなく不安」 を「どこが未対応か」 という具体に変えることが、 対策の第一歩です。

「禁止から入らない」 のが成功の鍵

この5ステップの順序で最も重要なのは、 STEP1（実態把握）とSTEP2（公式環境）を、 ルール整備より先に置くことです。 多くの企業が「まず禁止・まず規程」 から入って失敗します。 安全に使える環境を先に用意してから、 ルールで使い方を定める 順序が、 シャドーAIを生まず・現場に受け入れられる対策になります。

中小企業はリソースが限られるからこそ、 外部の知見を活用して立ち上げを加速するのも有効です。 規程の雛形作成・法人プラン選定・機密データ用のセキュア環境（RAG）構築までを伴走支援するサービスを使えば、 自社だけで試行錯誤するより短期間で安全な運用に到達できます。 中小企業向けの進め方は 中小企業向けAIコンサル活用ガイド もご参照ください。

最も多い失敗｜「禁止」 と「丸投げ」 の両極端

7つのうち、 経営判断として最も多い失敗が「全面禁止」（パターン1）と「無策のまま現場任せ」（パターン2・3の複合）という両極端です。 禁止しすぎてシャドーAIを生むか、 放任しすぎて誤入力を生むか。 正解は両極端の中間にある「安全な環境を用意して、 明確なルールで使わせる」 という設計です。

この中間設計こそが本記事全体の主張です。 「禁止か放任か」 の二択で考えるのをやめ、 「学習させない設定 × 社内ガイドライン × 法人プラン契約」 の3点セットで、 安全と活用を両立させる。 これが、 失敗パターンの大半を一気に回避する根本対策になります。

「対策疲れ」 で形骸化させない工夫

もう一つの隠れた失敗が、 対策が複雑すぎて現場が疲弊し、 結局守られなくなる「対策疲れ」 です。 セキュリティを厳格にしすぎると、 業務が回らなくなり、 社員は抜け道を探します。 守れる水準のルールを、 守れる量だけ課す のが、 形骸化を防ぐ実務の知恵です。

完璧な対策を100%課して20%しか守られないより、 必要十分な対策を80%課して90%守られる方が、 実際の漏洩リスクは低くなります。 中小企業ほど、 「現場が無理なく守れる現実的な対策」 を設計することが、 結果的に最も安全になります。