生成AIの導入は、もはや一部の先進企業だけの話ではありません。McKinseyは2024年、年商5,000万ドル超の企業を対象にした調査で、63％が生成AI導入を「高い」または「非常に高い」優先事項と見ている一方、91％は責任ある導入に「十分に準備できていない」と答えたと報告しています。さらに2025年の同社調査では、47％の組織が生成AI利用で少なくとも1つの悪影響を経験したとしています。

利用実態の拡大も速いです。Netskopeの2025年レポートでは、企業利用者のほぼ20人に1人が生成AIアプリを直接使っており、3,500社超の顧客基盤で317種類の生成AIアプリを追跡していると報告しています。しかも企業内の生成AI利用の72％は、IT部門の承認なしに個人アカウントで使う、いわゆるシャドーAIです。つまり、多くの会社では「導入するかどうか」を議論している間にも、現場ではすでに使われ始めています。

原則1 外部SaaSへ渡してよい情報だけをAIへ入れる

生成AIに入力する行為は、頭の中で考える行為ではなく、外部のシステムに情報を渡す行為です。したがって、メールやクラウドSaaSへそのままアップロードできない情報は、原則としてAIにも入れないのが基本です。役員の視点では、「AIの利用可否」を決めるより前に、「何を外部サービスへ渡してよい会社なのか」を決める必要があります。

原則2 企業契約のAIでも無制限にはしない

企業向けのChatGPT、Claude、Gemini、Copilotには強い保護があります。しかし、会話履歴、管理者による記録、接続アプリ、外部サービス連携まで含めると、入力した情報の扱いは一気に複雑になります。保護があることと、何でも入れてよいことは別です。

原則3 高機密業務は最初から閉域前提で考える

未公開の経営情報、重要顧客データ、設計資産、ソースコード、法務文書のように、漏えい時の影響が重い業務は、クラウド一択で考えない方が安全です。ローカルLLMやAI特化オンプレミスを比較対象に入れるべきです。大企業ほど、事故後の説明責任と再発防止コストが重いため、この判断は後回しにしない方が得策です。

1 顧客や社員を特定できる個人情報

氏名、メールアドレス、電話番号、社員番号、住所、履歴書、評価情報などは最初に止めるべき情報です。ICOのAIとデータ保護ガイダンスやEDPBの見解からも分かる通り、生成AIであっても個人情報を扱うなら通常のデータ保護義務がかかります。しかも生成AIは、要約、分類、検索、引用の過程で、入力時には見えなかった形で個人情報の扱いを広げることがあります。

現場では、問い合わせメールの原文、採用候補者の履歴書、クレーム対応履歴、面談メモをそのまま貼り付ける形で起きやすいです。安全な代替策は、個人名を削除したダミーデータや、属性だけを残した匿名化サンプルを使うことです。人事評価を相談したいなら、実名ではなく「営業部の中堅社員A」のような抽象化に変えるだけでもリスクは下がります。

2 要配慮個人情報や規制対象データ

健康情報、診療記録、口座情報、決済情報、未成年データ、顔画像、音声認証データ、政府関連の制限情報などは、一段重く扱うべきです。Netskopeも、生成AIへの違反入力で多いものとして、規制対象データを主要カテゴリに挙げています。こうした情報は、漏えいすると損害だけでなく、法規制や契約違反が重なります。

たとえば診断書、保険請求データ、口座明細、本人確認書類、音声認証用データはこの類型です。この類型は、一般的な企業向けAIだから大丈夫と考えない方が安全です。組織として明示的な承認がない限り、原文投入は避けるべきです。

3 パスワード、APIキー、接続情報などの秘密情報

パスワード、トークン、接続文字列、秘密鍵、VPN情報、証明書、管理画面URLは、その場で使い捨てに見えても入力してはいけません。Netskopeは、生成AIへの違反入力としてパスワードやキーも主要カテゴリに挙げています。ソースコードの一部を貼るつもりが、環境変数や鍵まで一緒に貼ってしまう事故は典型例です。

非エンジニア部門でも、設定画面のスクリーンショット、CSVの接続設定、運用手順書の中に秘密情報が混じっていることがあります。「文字列として見えていないから大丈夫」とは限りません。

4 ソースコード、設計書、構成図、内部アーキテクチャ

開発現場では最も起きやすい論点です。Netskopeは、生成AIへのポリシー違反のうち、ソースコードがほぼ半分を占めると報告しています。コードそのものだけでなく、アーキテクチャ図、データベース構造、脆弱性情報、障害対応手順も重要な設計資産です。

よくあるのは、エラー解消のためにアプリの一部だけ貼ったつもりが、設定値、顧客名、内部URL、権限構造まで一緒に渡ってしまうケースです。もちろん、承認済みの開発用AIに限定的にコードを渡すこと自体は、企業によっては合理的です。ただし、その場合でも、どのリポジトリなら許可するか、個人アカウントを禁止するか、監査ログを残すか、コード片から秘密情報を自動除去するかまで決めておかないと、現場では運用になりません。

5 契約書、法的意見、M&A、取締役会資料

法務と経営企画の情報は、機密性だけでなく、文脈依存性が高いのが難点です。契約書の一部だけを切り出しても、相手先、交渉状況、法的立場、将来の意思決定が読み取れることがあります。未公開の買収情報や取締役会資料は、内容そのものより「その案件が存在する」という事実だけでも極めてセンシティブです。

この領域では、要約したい気持ちと、入力してはいけない情報が強く衝突します。特に契約レビュー、取締役会説明資料、買収候補の概要資料は、文章としては読みやすくても、会社にとっては最重要情報です。実務では、条項を一般化したテンプレートに落とし替える、論点だけを抽象化して相談する、閉域の法務AIやオンプレミス環境を使う、といった方法に寄せるのが無難です。

6 未公開の価格、見積、利益率、入札、業績見通し

経営や営業に近い部門で見落とされがちなのが、この商流情報です。原価、値引き条件、利益率、案件別の勝ち筋、入札戦略、未公開の業績見通しは、漏れると競争上の不利に直結します。生成AIに入れる情報としては「文章」でも、本質的には経営情報です。

典型例は、見積書の原文、値引き履歴、案件ごとの利益率表、入札提案書の骨子をそのまま添削させるケースです。安全な使い方は、実数値を外し、比率や傾向だけに変えることです。たとえば「A社向けの見積を添削して」ではなく、「法人営業の見積説明文を、価格交渉に強いトーンへ直して」と依頼する方がよいです。

7 取引先から預かった秘密情報や、共有権限のない第三者データ

自社情報かどうかだけで判断するのは危険です。顧客、委託元、共同研究先、仕入先から預かった情報は、自社で自由にAIへ入れてよいとは限りません。EDPBも、AIモデルには第一者データだけでなく第三者データの論点があることを明示しています。契約上の秘密保持義務や利用目的制限があるなら、社内資料であってもAIへ投入できないケースがあります。

顧客のデータルーム資料、受託案件の設計書、共同研究先の実験データなどが典型例です。この類型は法務確認が必要です。特に受託開発、BPO、コンサルティング、医療、金融、公共では、第三者のデータを扱っている意識を組織に定着させる必要があります。

8 セキュリティ事故情報、脆弱性情報、監査ログ、内部統制の指摘

漏えい事故の報告書、脆弱性診断の結果、ペネトレーションテストの指摘、アクセスログ、SOCの検知ルール、監査部門の改善指摘は、そのまま入れない方がよい情報です。これらは単独では読みにくい文書でも、攻撃者目線では「どこが弱いか」「どこまで見えているか」を示す地図になります。NISTのGenerative AI Profileでも、GAIの情報セキュリティリスクとして、脆弱性の発見と悪用のハードル低下、さらに訓練データ、コード、モデル重みの機密性や完全性が損なわれるおそれが挙げられています。

さらに企業向けAIでは、入力内容が監査や証跡の対象になることがあります。Microsoftは2026年3月13日閲覧時点のCopilot Chat FAQで、プロンプトと応答は監査、eDiscovery、Microsoft Purviewで利用可能だと明示しています。OpenAIも2026年3月27日更新のCompliance Platformで、EnterpriseワークスペースのログとメタデータをeDiscovery、DLP、SIEMに接続でき、認証済みリクエスト自体もセキュリティとコンプライアンス目的で記録されると案内しています。つまり「学習に使われないから安全」だけでは不十分で、「どこに残るか」まで見る必要があります。現場では「文章を整えたい」「役員説明用に要約したい」という理由でAIに入れたくなりますが、要点だけでも防御状況が分かることがあります。実務では、日付、システム名、担当部署、具体的な脆弱性番号、検知ルール名を外した上で、抽象化した論点だけを扱う方が安全です。

9 会議録音、画面キャプチャ、画像、動画など文書以外の生データ

見落とされやすいのが、文字以外の入力です。会議録音、商談動画、画面キャプチャ、ホワイトボード写真、スマートフォンで撮った書類画像には、氏名、顔、声、社名、URL、通知内容、未公開の数字が一度に含まれていることがあります。ICOのガイダンスでは、音声認識や顔画像の技術的処理は生体データに当たり得て、健康情報も特別カテゴリーデータとして慎重な取り扱いが必要だとされています。人は文章よりも画像や音声の方を無害だと感じやすいですが、実際には情報量が多く、後から削り分けるのも難しいです。

加えて、最近のAIは画像やファイルの中身も読みます。そのため、見た目には普通の画像や資料でも、見えない指示や余計な情報を拾ってしまうことがあります。OWASPは、画像に埋め込まれた隠れた命令でAIの挙動が変わる例を整理しています。さらにGoogle WorkspaceのDLP説明では、動画と音声ファイルはスキャン対象外と明記されています。たとえば営業会議の録音を要約させると、顧客名、価格条件、次回提案日がそのまま含まれることがあります。会議の要約が必要なら、原音声を丸ごと渡すより、社内で先に議事メモを作り、固有名詞や数字を落としてから使う方が安全です。

ここは誤解が多いところです。OpenAIは企業向けサービスとAPIについて、入力と出力を既定では学習に使わないと明示しています。Microsoftも、Microsoft 365 CopilotとCopilot Chatについて、プロンプトや応答、Graph経由でアクセスしたデータは基盤モデルの学習に使わないとしています。Google WorkspaceのGeminiも、顧客データを顧客の許可なく学習に使わず、組織外へ共有しないとしています。Anthropicも、Claudeの商用プランでは顧客の指示に従って処理し、商用利用データを学習に使わないと説明しています。

これは非常に重要な進歩です。企業契約のAIは、個人向け無料版や個人契約より、明らかに安全です。ただし、ここから「だから何でも入れてよい」と飛ぶのは危険です。

OpenAIのGPTsに関する公式FAQでは、外部APIやアプリを使うGPTに対しては、入力の relevant parts が第三者サービスへ送られる場合があり、OpenAIはその第三者の保存や利用を監査しないと明記しています。つまり、企業契約のAIであっても、接続先が増えるほど、データの境界は広がります。

Google WorkspaceのPrivacy Hubでも、機能によっては通常の情報保護設定がそのまま当てはまらないものがあります。実際にGoogleは2025年11月19日更新のNotebookLM管理ヘルプで、Driveから取り込んだファイルはNotebookLM側に新しいコピーが作られ、組織のファイル共有設定やデータリージョン設定はNotebookLMデータには適用されないと案内しています。Microsoftも、CopilotのWeb検索クエリはBing検索サービス側の取り扱いが関わると説明しています。つまり、同じベンダーでも「どの機能を使うか」で前提が変わります。

NCSCも、プロンプトインジェクションはSQLインジェクションのように完全に片づく種類の問題ではなく、影響を減らす設計が重要だと指摘しています。つまり、AIが触る範囲が広いほど、入力した情報が意図しない形で使われる余地も広がるということです。

現場で本当に必要なのは、完璧な法律講座ではなく、迷った瞬間に止まれる判断軸です。次の3問に1つでも引っかかるなら、そのまま入力しない方が安全です。

1つでも答えに詰まるなら、方法を変えるべきです。原文ではなく要約にする、数値を幅へ変える、固有名詞を消す、ダミーデータに置き換える、閉域環境で実行する、といった代替策があります。

McKinseyが示す通り、多くの企業は生成AIを重要テーマと見ながら、責任ある運用の準備が十分ではありません。だからこそ、大きな制度を作る前に、最初の30日で最低限の統制を置くことが重要です。

高機密部門まで視野に入るなら、ここでクラウド型だけに固定しない方がよいです。経営資料、R&D、法務、基幹開発のような領域は、ローカルLLMやAI特化オンプレミスを比較対象に入れた方が、あとからのやり直しが少なくなります。特に大企業では、一度事故が起きると、監査法人、顧客、取引先、監督官庁への説明が連鎖しやすく、初期投資より事故対応コストの方が重くなりがちです。

企業が生成AIに入れてはいけない情報は、難しく見えても本質はシンプルです。人を特定できる情報、会社の競争力そのものになる情報、自社に自由な処分権限がない情報、そして攻撃や事故対応に直結する生データは、そのまま投入しない。この原則を全社共通ルールに落とせるかどうかが、事故の差になります。

生成AIを止める必要はありません。必要なのは、入力を放置しないことです。承認済みの企業向けAI、ログ、DLP、接続先制御、教育、そして高機密業務にはローカルLLMやオンプレミスを組み合わせる。この現実的な設計こそが、AIの生産性と情報保護を両立させます。