AIの情報漏洩事例｜起きた原因から学ぶ社内の対策

この記事でわかること

• 公表されたAIの情報漏洩事例と、それぞれが起きた経路
• 社員がAIに業務の情報を入力した事例と対策
• 共有や公開の設定から情報が見えた事例と対策
• 外から仕込まれた指示でAIが情報を持ち出せる状態だった事例と対策
• 提供会社側の不具合で起きた事例と対策
• 事例を社内の対策に置き換える4つの層と、この記事で解けないこと

AIの情報漏洩事例とは｜公表された事例を原因で3つの経路に分ける

AIの情報漏洩事例とは、AIの開発や利用の中で、社外に出す予定の無かった情報が、外部のサーバーや第三者から見える状態になった事例を指します。本記事では、企業や提供会社が自ら公表したものと、複数の報道で確かめられるものに絞り、6件を取り上げます。

事例は、社名や被害の大きさで並べると「大企業の話」「海外の話」として読み流されやすくなります。原因で分けると、自社のどこに同じ穴があるかを確かめる材料になります。本記事では、冒頭で紹介した記事の3つの経路に、提供会社側の不具合という外側の枠を1つ足して振り分けます。

表の経路の分け方は本記事の整理で、各社や公的機関が定めた分類ではありません。1つの事例が2つの経路にまたがることもあり、ここでは事例の起点になった経路に置いています。

公表されたAIの情報漏洩事例は、社内から見ると、人が入れる・設定が緩い・外から仕込まれるの3つの経路と、その外にある提供会社側の不具合に振り分けられます。

ファクトボックス｜本記事で取り上げる事例の出典

AIの情報漏洩事例は、何が漏れたかより先に、どの経路で起きたかを見ると、自社の対策に置き換えられます。

経路1 人が入れる｜社員が業務の情報を生成AIに入力した事例

人が入れる経路の事例は、社員が仕事を早く進めるために、業務の情報をそのまま生成AIに入力し、その情報が社外のサーバーに渡ったものです。悪意のある行動ではなく、通常の業務の延長で起きる点が、この経路の事例に共通しています。

事例｜サムスン電子の社内ソースコードの入力（2023年）

2023年5月2日、韓国のサムスン電子が、主要な部門の1つに向けた通知で、社員による生成AIの利用を制限したと、Bloombergの報道をもとに各社が伝えました。報道によると、社内向けの通知には、同年4月にエンジニアが社内のソースコードをChatGPTにアップロードし、誤って外部に出したことが書かれていました。

制限の範囲は、報道では会社の端末と社内のネットワークでの生成AIの利用とされ、私物の端末で使う場合も会社の情報を入力しないよう求められました。同社の広報担当者は、利用を禁じる通知を送ったことを認めています。入力されたソースコードの中身や、社外の誰かが見たかどうかは、報道では明らかにされていません。

この事例から読み取れるのは、入力した社員が規則を破ろうとしていたわけではないことです。社内のコードの不具合を早く直したいという、業務としては自然な動機から起きています。

経路1の事例から、社内で先に打てる対策

人が入れる経路は、注意喚起だけでは止まりにくい経路です。入力する場面で、目の前の資料が入れてよいものかを社員がその場で判断できないと、忙しいときほど入力する側に倒れます。打てる手は3つです。

1. 使うAIのサービスと契約を会社で決める。個人のアカウントで使われていると、入力した情報がどの条件で扱われるかを会社が確かめられません
2. 入れてよい情報の範囲を、種類ごとに表にする。「機密を入れない」の1行で終えず、入れてよいもの・加工すれば入れてよいもの・入れないものを例つきで並べます
3. 迷ったときに聞く相手を決める。判断できない資料を入力の前に相談できる窓口を、名前で決めておきます

入れてよい範囲を決めるときに、顧客の氏名や問い合わせの文面のような個人情報を、法律の面からどう扱うかは、生成AI 個人情報の入力範囲を扱う記事「生成AIと個人情報」で扱っています。

人が入れる経路の事例は、社員の不注意より先に、入れてよい範囲がその場で分かる形になっていたかを問います。

経路2 設定が緩い｜共有や公開の設定から情報が見えた事例

設定が緩い経路の事例は、共有や公開の設定が想定より広く、意図しない相手から情報が見える状態になったものです。入力した内容そのものは業務に必要なものでも、渡した先の公開範囲で事故になります。ここでは、AIのサービスの共有機能と、AIの研究チームのデータ共有の2つの事例を取り上げます。対策の記事では認証情報が記録に残る形を中心に扱っています。Microsoftの事例はその認証情報が公開の場に出た例です。

事例｜ChatGPTの共有リンクが検索結果に表示された（2025年）

ChatGPTの会話を共有するときの選択肢から、共有した会話が検索エンジンの結果に表示される状態が見つかり、2025年8月1日までに報道されました。会話を共有するときに、検索エンジンに表示されることを許すチェックボックスを利用者が選んだ場合に起きるもので、機能は利用者が自分で選ぶ方式でした。

OpenAIの最高情報セキュリティ責任者は、会話を検索エンジンで見つけられるようにする機能をChatGPTから削除したと公表し、意図しない共有が起きる余地が大きすぎたことを理由に挙げました。同社は検索エンジンに表示された内容の削除にも取り組むとしましたが、検索エンジン側の一時的な保存によって、しばらく表示が残ることがあるとも報じられています。

事例｜Microsoftの研究チームの共有URLから社内データが見えた（2023年）

2023年9月18日、Microsoftは、AIの研究チームの社員が公開のGitHubのリポジトリに載せたストレージのURLに、広すぎる権限のアクセス用の文字列が含まれていたと公表しました。リポジトリは、画像認識のAIモデルをオープンソースとして配るためのものでした。

発見したセキュリティ企業Wizの報告では、このURLからはストレージのアカウント全体に、読むだけでなく削除や上書きもできる権限で入れる状態で、38TBのデータに届いたとされています。Wizは、社員2人の業務用パソコンのバックアップに、パスワードや秘密鍵、359人の社員による3万件を超えるTeamsのメッセージが含まれていたと報告しました。

Microsoftの公表では、見えたのは元社員2人のパソコンの設定のバックアップと、その2人と同僚のTeamsのメッセージで、顧客のデータは含まれていなかったとしています。Microsoftは2023年6月24日にアクセス用の文字列を無効にし、広すぎる権限や有効期限の文字列を検知する仕組みを広げました。

経路2の事例から、社内で先に打てる対策

2つの事例に共通するのは、共有した本人は業務として必要なものを共有したつもりで、公開範囲の広さに気づいていなかった点です。設定が緩い経路は、共有の操作をした瞬間には事故に見えないため、後から気づける仕組みが要ります。打てる手は3つです。

1. AIのサービスの共有機能を、会社のアカウントでどこまで使えるかを管理者が決める。共有の範囲を管理者が決められるかは契約やプランで変わるため、使う前に管理画面で確かめます
2. 共有リンクや共有URLを作ったら、作った人と期限を記録する。消す担当と見直す日を決めておくと、残り続ける共有を減らせます
3. パスワードやアクセス用の文字列が共有物に入っていないかを、機械で検査する。人の目で探すより、Microsoftが事後に広げたような検知の仕組みに任せるほうが漏れを拾いやすくなります

設定が緩い経路の事例は、共有した瞬間には事故に見えないため、共有の範囲と期限を後から確かめられる形にしておくことが対策の起点になります。

経路3 外から仕込まれる｜外部サービスとの連携から情報を持ち出せる状態だった事例

外から仕込まれる経路の事例は、AIが読みに行った外部のメールや文書に指示が埋め込まれていて、AIがその指示に従うことで情報が外に出る状態になったものです。この手口は、プロンプトインジェクションと呼ばれます。プロンプトインジェクションとは、AIへの指示を、読ませる資料の中に紛れ込ませる攻撃のことです。

この経路の特徴は、社員が何も入力していなくても起点になる点です。AIをメールや社内の文書とつなぐほど、AIが読む範囲が広がり、外から届いたものを読む機会も増えます。

事例｜Microsoft 365 CopilotのEchoLeak（2025年）

2025年6月11日、Microsoftは、Microsoft 365 Copilotの情報漏えいの脆弱性をCVE-2025-32711として公表しました。CVEとは、公表された脆弱性に付ける共通の識別番号です。記録の説明は、Microsoft 365 CopilotでのAIへの指示の注入によって、権限の無い攻撃者がネットワーク越しに情報を開示できる、というものでした。深刻度は10点満点で9.3と評価されています。

発見したAim Securityはこの脆弱性をEchoLeakと名付け、攻撃者がメールを送るだけで、利用者の操作なしに、Copilotが届く範囲のデータを持ち出せる状態だったと説明しています。範囲には、Copilotとの会話の記録や、OneDrive・SharePoint・Teamsの内容が含まれるとされました。

Microsoftはサービス側でこの脆弱性を修正し、利用者が対応する必要は無いとしました。CVEの記録に付いた米国のサイバーセキュリティ・インフラストラクチャ安全保障庁の2025年6月14日時点の評価では、悪用は確認されていない扱いです。この事例は、実際に情報が漏れた事故ではなく、漏れうる状態が見つかって塞がれた事例として読みます。

外から仕込まれる経路では、社員が何も入力しなくても、AIが読んだメールや文書の中の指示が起点になります。

経路3の事例から、社内で先に打てる対策

外から仕込まれる経路は、社員の注意では見分けられません。埋め込まれた指示は、人には見えない形で書かれていることがあり、読ませた社員に落ち度は無いからです。打てる手は3つです。

1. AIにつなぐ先を、業務に要る分だけにする。メール・ファイル置き場・チャットのどれをAIが読めるかを、部署や用途ごとに決めます
2. 社外から届いたものをAIに読ませる範囲を決める。社外のメールや文書を、社内の機密と同じ場でAIに扱わせるかを、先に線引きします
3. AIが外へ送る操作の前に、人の承認を置く。送信・共有・外部のURLへの書き出しのように、外に出る操作を承認の対象にします

AIが自分で手順を選んで動くAIエージェントでは、つなぐ先と権限の決め方がさらに大事になります。手口と権限の決め方は、AIエージェント特有のセキュリティ｜プロンプトインジェクションと権限管理の実務で扱っています。

外から仕込まれる経路の事例で止められる範囲は、AIをどこにつなぎ、何を読ませるかの設定で決まります。

3つの経路の外｜提供会社側の不具合で利用者の情報が見えた事例

提供会社側の不具合による事例は、AIのサービスを提供する会社の仕組みや設定に原因があり、利用者の会社では止められなかったものです。社内の3つの経路とは原因の場所が違うため、本記事では外側の枠に分けて扱います。

事例｜ChatGPTの不具合で、他の利用者の会話の題名と支払い情報が見えた（2023年）

2023年3月20日、ChatGPTで、一部の利用者に他の利用者の会話の題名が見える不具合が起きました。OpenAIが同年3月24日に公表した説明では、原因はオープンソースのライブラリ「redis-py」の不具合で、同じ時間帯に使っていた利用者どうしでは、新しく始めた会話の最初の発言が見えた可能性もあるとしています。

同じ不具合で、有料プランのChatGPT Plusの契約者の1.2%について、特定の9時間に利用していた人の氏名・メールアドレス・支払い先の住所・カード番号の下4桁・有効期限が、他の利用者から見えた可能性があるとされました。カード番号の全桁は見えていません。OpenAIは、実際に他の人に見られた利用者の数は極めて少ないと考えているとしたうえで、対象の契約者にメールで知らせています。

この1.2%は、ChatGPT Plusの契約者のうち、その9時間に利用していた人の中から出た数字で、無料の利用者や他の期間の利用者を含む割合ではありません。それでも、提供会社側の不具合でも利用者の情報が見えうることを示した事例として、契約前の確認項目に持ち帰れます。

事例｜Wizが報告したDeepSeekのデータベースの公開（2025年）

2025年1月29日、セキュリティ企業のWizは、生成AIを提供する中国のDeepSeekのデータベースが、認証なしで外部から読める状態だったと公表しました。中身は100万行を超える記録で、会話の履歴や秘密の鍵、システムの内部情報が含まれていたと報告されています。Wizの報告では、DeepSeekは連絡を受けてすぐに公開を止めました。

提供会社側の事例から、社内でできること

提供会社側の不具合は、社内の設定や運用ルールでは止められません。社内でできるのは、漏れたときに被害が広がらない形を、使う前に作っておくことです。

1. 提供会社が不具合や漏洩をどう知らせるかを、契約前に確かめる。通知の方法と、会社の管理者に届くかを見ます
2. 入れる情報の範囲を、提供会社側で見えても困らない範囲に寄せる。経路1で決めた入れてよい範囲が、ここでも被害の大きさを決めます
3. 会社のアカウントで使い、利用者の一覧を管理者が持つ。通知が来たときに、誰が影響を受けたかをすぐに確かめられます

提供会社側の不具合による漏洩は社内の設定では止められないため、契約の確認と入れる範囲の線引きで、漏れたときの範囲を小さくします。

AIの情報漏洩事例を社内の対策に置き換える｜止める場所を4つの層で書き出す

AIの情報漏洩事例を社内の対策に置き換えるときは、事例ごとに、自社ならどの層で止めるかを書き出します。当社は、法人がClaude Codeを導入するときのセキュリティ設計を、端末・環境、ツールの設定、運用ルール、人の4つの層に分けています。対策の記事の②コード設定にあたる層を、本記事ではツールを問わない形で「ツールの設定」と呼びます。当社のセキュリティ設計での各層の役割は、次のとおりです。

当社の設計では、決める・強制する・教えるを別の仕事として分業させています。決めるのは運用ルール、仕組みで強制するのはツールの設定、なぜその線なのかを教えるのは人の層、土台が端末・環境という分担です。同じテーマが複数の層に出てくるのは、担当する仕事が違うためです。

事例ごとに、止める層を1行で書き出す

本記事で取り上げた事例を、自社に置き換えたときに見る層で並べると次のようになります。この表は、自社で同じことが起きたときに止める場所を書き出すためのもので、各社の社内の体制を評価したものではありません。

表の「自社で止める層」は、4つの層の役割に事例を当てはめた本記事の整理です。1つの事例に2つの層が並ぶのは、決める層と強制する層の分業を書いているためです。

事例を自社に置き換えるときは、4つの層のどこで止めるかを、事例ごとに1行ずつ書き出します。

書き出した後に、教える層を足す

表で止める層を決めた後に、人の層で、なぜその線なのかを社員に伝えます。共有リンクの事例なら「共有する前に公開範囲を見る」、メールに仕込まれた指示の事例なら「外へ送る操作の承認を求められたら中身を読む」のように、事例と行動を1組で伝えると、社員が自分の業務に当てはめやすくなります。

事例ごとに止める層を、自社の業務とツールの設定に合わせて決めたい方は、自社で使えるヒントを、20の実例から探すもご利用ください。

自社で使えるヒントを、20の実例から探す

AIの情報漏洩事例で、この記事で解けないこと｜国内の事例と法令上の報告

本記事で取り上げた事例は、海外の企業と提供会社が公表したもの、または複数の報道で確かめられるものに限っています。国内の企業がAIの利用で起こした漏洩は、社名や経緯が公表されることが少なく、出典を示して書ける事例が当社の手元にありません。

同じ理由で、事例の件数や、どの経路の事故が多いかの割合も示していません。公表される事例は大きな被害か、研究者が見つけた脆弱性に偏るため、公表された件数を数えても、社内で起きている事故の割合とは一致しないからです。

漏洩が起きた後に、個人情報保護委員会への報告や本人への通知が要るかは、漏れた情報の種類と件数で変わります。AIの利用に関わる法律やガイドラインが、社内のルールと研修に何を求めるかは、同じ日に公開したAI 法規制と社内ルールを扱う記事「AIの法規制」で扱っています。個別の事故で報告が要るかの判断は、弁護士や社内の法務の担当部門に確認してください。

当社の制作側でも、AIに業務ツールの書き込みの権限を渡していたことで起きたヒヤリがあります。そのときに何が起き、どの層が抜けていたか、今どう運用しているかは、冒頭で紹介した生成AIの情報漏洩リスクと対策の記事に書いています。

AIの情報漏洩事例に関するよくある質問

Q. AIの情報漏洩事例は、大企業や海外の話ではありませんか

A. 事例の多くは海外の大企業や提供会社のものですが、起きた経路は、会社の規模や国に関係なく同じ形で起こりえます。 社員が業務の情報を入力する、共有の範囲を広く設定する、AIを社内のメールや文書につなぐ、といった操作は、生成AIを使う会社ならどこでも行われています。

Q. 生成AIの利用を禁止すれば、情報漏洩の事例と同じことは起きませんか

A. 利用を禁止しても、社員が私物の端末や個人のアカウントで使うと、会社から見えない場所で同じ経路が開いたままになります。 禁止で止められるのは会社の端末とアカウントでの利用までで、私物での利用は確かめられません。禁止した後の扱いは、「生成AI禁止」が一番危ない｜シャドーAIが生まれる構造と、禁止を解除する順番で扱っています。

Q. 法人向けのプランを使えば、AIの情報漏洩は防げますか

A. 法人向けのプランは、入力した情報の扱いや管理者の設定を会社で決めやすくしますが、それだけで3つの経路がすべて閉じるわけではありません。 共有の設定や、AIにつなぐ先、社員が入力する情報の範囲は、プランを選んだ後に会社が決める項目として残ります。

Q. 事例を社内研修で使うときは、何を伝えればよいですか

A. 事例を伝えるときは、何が漏れたかと一緒に、自社ならどの操作の前に何を見るかを1組で伝えます。 被害の大きさだけを伝えると「使わないほうが安全」という受け止めになりやすく、業務での使い方が変わりません。

AIの情報漏洩事例｜総括表

経路の分け方と「社内で先に打てる対策」は本記事の整理で、どの事例にも同じ対策で足りるという意味ではありません。

事例から決めた入れてよい範囲や止める層を、社内ルールの文書にまとめる形は、生成AI社内ルールのサンプル｜禁止事項リストにしない4層のガイドラインで扱っています。

まとめ｜AIの情報漏洩事例は、どんな原因で起きているか

本記事で取り上げたAIの情報漏洩事例をたどると、原因の起点は、社員の入力、共有や公開の設定、外から届いた指示の3つの経路に振り分けられ、提供会社側の不具合がその外側にあります。同じ経路の事例は止める場所も共通しているため、事例を1つずつ覚えるより、経路と止める層の組で社内に持ち帰るほうが、次の事故を防ぐ手に変わります。

事例を社内の対策に置き換えるなら、次の3つから始められます。

1. 今日：社内で使っているAIのサービスを書き出し、それぞれ会社のアカウントか個人のアカウントかに印を付ける
2. 今週中：AIのサービスで作られた共有リンクと、AIがつながっているメールやファイル置き場を、管理者の画面で確かめる
3. 今週中：本記事の事例を1つ選び、自社で同じことが起きたら4つの層のどこで止めるかを1行で書く

最後に、社内で自分に問える1問を置きます。御社で社員がAIに業務の情報を入れる前に、その情報を入れてよいかを、その場で確かめられる表がありますか。

• 公表されたAIの情報漏洩事例は、社内から見ると、人が入れる・設定が緩い・外から仕込まれるの3つの経路に振り分けられます。提供会社側の不具合による事例は、3つの経路の外に分けて扱います
• 同じ経路の事例は、社名や業種が違っても、止められる場所が共通しています。事例を読むときは、何が漏れたかより先に、どの経路で起きたかを確かめます
• 事例を社内の対策に置き換えるときは、端末・環境、ツールの設定、運用ルール、人の4つの層のどこで止めるかを、経路ごとに書き出します。4つの層は当社が導入支援で使う分け方で、公的な分類ではありません

事例をもとに、自社でAIに渡してよい情報と止める仕組みを整理するなら、自社で使えるヒントを、20の実例から探すからご確認いただけます。

自社で使えるヒントを、20の実例から探す

AIの使い方と守り方を、業務の画面で見てから決めたい場合は、初回無料体験講座もあります。

無料体験講座を申し込む ▶

この記事について

本記事は、法人向けにClaude Codeの研修と導入支援を提供するDAIJOBUが、公表されたAIの情報漏洩事例を原因の経路ごとに読み解き、社内で先に打てる対策をまとめたものです。