生成AIの情報漏洩は、どこから漏れたかで5つに分けられる。社員が入力して持ち出す、AIサービスや開発側の不具合・設定ミス、AIのアカウントの乗っ取り、AIを狙う攻撃、そしてAIが攻撃する側に回るケースだ。
「生成AIは情報漏洩が怖い」という不安は、この5つを一緒くたにしていることが多い。出口が違えば、効く対策も違う。社員教育で防げるもの、契約と設定で防げるもの、権限の設計でしか防げないものがある。
ここでは、2023〜2026年に公表された8つの事例を出口ごとに整理し、それぞれ何をしていれば防げたか、または被害を小さくできたかを示す。
生成AIの情報漏洩事例8選（一覧）
| # | 年 | 事例 | 何が漏れたか | 出口 |
|---|---|---|---|---|
| 1 | 2023年 | Samsungの技術者がChatGPTにソースコードを入力 | 社内のソースコード | 社員の入力 |
| 2 | 2023年 | ChatGPTの不具合で他人の情報が見えた | 会話のタイトル、一部利用者の支払い関連情報 | サービスの不具合 |
| 3 | 2023年 | MicrosoftのAI研究チームが共有リンクを誤設定 | 38TBの社内データ（Teamsのメッセージ3万件超を含む） | 開発側の設定ミス |
| 4 | 2025年 | DeepSeekのデータベースが認証なしで公開 | 利用者のチャット履歴、秘密鍵など | サービスの設定ミス |
| 5 | 2026年 | AI議事録サービスtl;dvの脆弱性 | 18万件超の会議記録（メタデータ） | サービスの不具合 |
| 6 | 2023年 | ChatGPTのログイン情報が闇市場で売買 | 10万台超の端末に保存されたログイン情報 | アカウントの乗っ取り |
| 7 | 2025年 | Microsoft 365 Copilotの脆弱性「EchoLeak」 | Copilotが参照できる社内データ（悪用は確認されず） | AIを狙う攻撃 |
| 8 | 2026年 | Hugging FaceへのAIエージェントによる侵入 | 一部の社内データセットと認証情報 | AIによる攻撃 |
出口1：社員が入力して持ち出す
事例1：Samsungの技術者がソースコードをChatGPTに入力（2023年）
2023年4月、Samsung Electronicsの技術者が社内のソースコードをChatGPTにアップロードし、外部に出してしまった。同社は翌月、社用のパソコン・タブレット・スマートフォンと社内ネットワークで、生成AIの利用を禁止した（Bloomberg、2023年5月2日）。
漏洩の入り口は攻撃者ではなく、仕事を早く進めたかった社員だった。この出口は、2026年も最も身近なものとして残っている。Verizonの「2026 Data Breach Investigations Report」では、生成AIに送られたデータの種類で最も多かったのはソースコードだった。
- 防ぐには: 入力してよい情報の区分を決め、会社が契約した環境を用意する。禁止だけでは止まらない理由は「シャドーAIとは？禁止では防げないリスクと、現場で効く対策」で詳しく書いた
出口2：AIサービス・開発側の不具合と設定ミス
社員が正しく使っていても、AIサービスの側で漏れることがある。ここは利用企業が直接は防げない。できるのは、どのサービスを選び、何を預けるかを決めることだ。
事例2：ChatGPTの不具合で、他人の会話タイトルと支払い情報の一部が見えた（2023年）
2023年3月20日、OpenAIが使っていたオープンソースのライブラリ（Redisのクライアント）の不具合で、一部の利用者が他の利用者の会話履歴のタイトルを見られる状態になった。太平洋時間の午前1〜10時には、ChatGPT Plusの利用者の1.2%について、氏名、メールアドレス、支払い先住所、カード番号の下4桁と有効期限が他の利用者に見えた可能性があった。カード番号の全桁は漏れていない（The Hacker News）。
事例3：MicrosoftのAI研究チームが38TBの社内データを公開してしまった（2023年）
MicrosoftのAI研究チームが、AIの学習用データをGitHubで公開する際に、Azureのストレージを共有するリンク（SASトークン）の範囲を誤って設定した。その結果、公開するつもりだったデータに加えて、社員2人のパソコンのバックアップを含む38TBの非公開データにアクセスできる状態になった。バックアップには、秘密鍵、パスワード、3万件を超える社内のTeamsのメッセージが含まれていた（Wiz、2023年9月18日）。
AIの開発や検証では、大量のデータを扱い、共有する。社内でAIを作る側に回ったときも、同じ種類の事故が起きうる。
事例4：DeepSeekのデータベースが認証なしで公開されていた（2025年）
2025年1月、セキュリティ企業のWizが、中国のAI企業DeepSeekのデータベース（ClickHouse）が認証なしでインターネットから操作できる状態だったと報告した。100万行を超えるログには、利用者のチャット履歴、秘密鍵、システム内部の情報が含まれていた。DeepSeekは報告を受けてすぐに公開を止めた（Wiz、2025年1月29日）。
事例5：AI議事録サービスtl;dvで、18万件超の会議記録にアクセスできた（2026年）
AIで会議を録画・文字起こし・要約するサービスtl;dvで、全利用者の会議のメタデータを横断して18万1,874件の会議記録を取得できる脆弱性があったと、独立系のセキュリティ研究者が報告した。研究者は2026年1月に調査を始めて運営会社に報告し、6か月修正されなかったと批判したが、tl;dv側は別々の2つの脆弱性があったと説明している（GIGAZINE、2026年8月13日）。
会議の録音には、商談、採用面接、評価面談、経営会議が入る。AI議事録は、現場が自分の判断で入れやすいツールの代表でもある。
- 出口2を防ぐには: 社内で使うAIサービスを一覧にし、どのサービスに何を預けているかを把握する。新しいAIサービスを入れるときは、データの保存場所、保存期間、学習への利用、脆弱性の報告窓口と対応の実績を確認する。預ける情報は、業務に必要な最小限にとどめる
出口3：AIのアカウントの乗っ取り
事例6：10万台超の端末からChatGPTのログイン情報が盗まれ、闇市場で売買された（2023年）
セキュリティ企業のGroup-IBは2023年6月、ChatGPTのログイン情報が保存された端末10万1,134台分が、情報窃取型のマルウェアに感染し、その記録がダークウェブの市場で売買されていたと発表した。地域別ではアジア太平洋が最も多かった（Group-IB、2023年6月20日）。
AIのアカウントには、過去の会話の履歴が残る。アカウントを乗っ取られれば、そこに入力してきた社内の情報もまとめて読まれる。
- 防ぐには: 個人アカウントではなく会社のアカウント（シングルサインオンと多要素認証）で使わせ、退職・異動のときに止められるようにする。会話履歴を残す期間も決めておく
出口4：AIを狙う攻撃（プロンプトインジェクション）
事例7：Microsoft 365 Copilotの脆弱性「EchoLeak」（2025年）
2025年6月、Microsoft 365 Copilotに、利用者が何もしなくても社内データを外部に持ち出される脆弱性（CVE-2025-32711、深刻度を示すCVSSは9.3）があったことが公表された。攻撃者は、隠れた指示を仕込んだメールを送るだけでよい。利用者が普段どおりCopilotに質問すると、Copilotがそのメールを参照し、指示に従って社内のデータを外部に送ってしまう仕組みだった。Microsoftは修正済みで、悪用された形跡は確認されていない（The Hacker News、2025年6月12日）。
AIが社内のメールや文書を参照できるようになると、外から届いた文章が「AIへの命令」として働きうる。これがプロンプトインジェクションだ。
- 防ぐには: AIが参照できるデータと、AIが実行できる操作を、業務に必要な範囲に絞る。外部から届いた文書を読むAIに、外部へ送信する権限を同時に持たせない。AIの製品の更新情報を追い、修正をすぐに当てる
出口5：AIが攻撃する側に回る
事例8：Hugging Faceへの、AIエージェントによる侵入（2026年）
2026年7月、AIモデルの共有サービスを運営するHugging Faceは、本番環境の一部への侵入を公表した。侵入は、自律的に動くAIエージェントのシステムが最初から最後まで実行していた。攻撃者はデータセットの処理の仕組みの弱点を突いてコードを動かし、クラウドの認証情報を集めて、週末のうちに複数の社内のクラスターに入り込んだ。一部の社内データセットと、サービスで使う認証情報への不正アクセスが確認された（Hugging Face、2026年7月16日）。
攻撃の側がAIで速く、広くなる。人の手作業を前提にした監視の間隔では、追いつかなくなりつつある。
- 防ぐには: 認証情報を長く使い回さず、権限を細かく分ける。異常な操作を自動で検知して止める仕組みを持つ
事例から分かる、生成AIの情報漏洩の3つの原因
8つの事例を並べると、原因は3つに整理できる。
- 入れてはいけないものを入れた（出口1）。社員教育と、入力の区分、そして個人アカウントより便利な公式環境で減らせる
- 預け先が安全ではなかった（出口2・3）。利用企業が直接は防げない部分があるので、預ける先の選び方と、預ける量を絞ることが対策になる
- AIに渡した権限が広すぎた（出口4・5）。AIが読めるもの、AIができることを、業務に必要な範囲に絞る設計の問題だ
私たちは、3つ目がこれから最も重くなると考えている。AIが質問に答えるだけの道具から、社内のシステムを読み書きして仕事を進めるエージェントに変わりつつあるからだ。
生成AIに入力してはいけない情報
会社が契約した環境でも、次の情報は「入れてよい場所」を個別に決めておく。
| 区分 | 例 | 理由 |
|---|---|---|
| 個人情報 | 顧客・社員の氏名、連絡先、マイナンバー、健康情報 | 法令上の扱いが決まっている |
| 預かった情報 | 取引先の資料、契約書、秘密保持契約の対象 | 契約違反になりうる |
| 未公開の経営情報 | 決算前の数字、人事、M&A、価格の交渉 | インサイダー情報や交渉上の不利につながる |
| ソースコード | 自社製品のコード、設定ファイル | 事例1のとおり最も多く送られている |
| 認証情報 | パスワード、APIキー、秘密鍵 | 一度漏れると、別の侵入の入り口になる |
出口ごとの対策一覧
| 出口 | まずやること | 担当 |
|---|---|---|
| 1. 社員の入力 | 入力の区分を1枚にまとめる。会社が契約した環境を、個人アカウントより便利に用意する | 業務部門と情報システム部門 |
| 2. サービスの不具合・設定ミス | 使っているAIサービスの一覧を作り、預けている情報を最小限にする。導入前にデータの扱いを確認する | 情報システム部門 |
| 3. アカウントの乗っ取り | 会社のアカウント、シングルサインオン、多要素認証。退職時に止める | 情報システム部門 |
| 4. AIを狙う攻撃 | AIが読めるデータとできる操作を絞る。外部の文書を読むAIに送信の権限を持たせない | AIを導入する部門とエンジニア |
| 5. AIによる攻撃 | 認証情報の短期化、権限の分割、異常の自動検知 | セキュリティ担当 |
対策を「使われる形」で入れる
出口1と出口4の対策は、ツールを買うだけでは入らない。どの業務で、誰が、どのデータをAIに渡すのかを決めないと、入力の区分も権限の範囲も決まらないからだ。
私たちが実践しているFDE（Forward Deployed Engineer）は、エンジニアが現場に入り、業務を分解して、実際に使われるAIの仕組みを作り、定着するまで改善を回す働き方だ。権限を絞ったAIの仕組みを、現場が不便を感じない形で作るところまでを一緒に行う。FDEについては「FDEとは？Forward Deployed Engineerの意味と仕事内容」に、生成AIのセキュリティ全体と社内ガイドラインの作り方は「生成AIのセキュリティ対策ガイド」にまとめた。