生成AIの情報漏えいは、どの操作で起きたのか。公表された3つの事例から
利用ルールを決めても、情報漏えいは起きています。2023〜2026年に公表された3つの事例を「誰が・何を・どの操作で・どこへ」で読み直すと、見るべきものは「サービス名」ではなく「操作」だと分かります。
はじめに
生成AIの利用ルールを作っている会社は、もう珍しくありません。それでも、情報漏えいの公表は続いています。
なぜでしょうか。ルールが守られていないから、と考えたくなります。ただ、公表された事例を読み直すと、少し違う姿が見えてきます。事故は、ルールで禁止した操作ではなく、ルールが想定していなかった場所で起きているのです。個人のアカウント、承認していないサービス、そして「貼り付け」や「アップロード」という、ごく普通の操作です。
この記事では、2023年から2026年に公表された3つの事例を「誰が・何を・どの操作で・どこへ」の順で読み直します。読み終わるころには、自社で何を見ておけばいいかを、操作の名前で言えるようになるはずです。
使う側の行動は、ルールでは変わらない
まず数字から。BCGが2025年に11の国と地域で1万人以上に行った調査では、必要なAIツールが会社から提供されない場合、半数以上の従業員が「代わりの手段を見つけて使う」と答えました1。IBMの2025年の調査では、5社に1社がシャドーAI、つまり会社の管理外で使われたAIに関わる侵害を経験しています。その侵害の65%で、顧客の個人情報が露出しました2。国内でも、希望者や特定の部署に限って社内AIを導入した企業の約7割が「ほぼ使われていない」と答えた調査があります3。
つまり、こういうことです。会社が用意したAIが使いにくければ、人は外のAIを使う。そこで事故が起きる。業種はあまり関係ありません。
公表された3つの事例
社名まで公表された事例は、多くありません。ここでは、当事者の公表と報道で確認できる3件を、古い順に並べます。書いてあるのは出典で確認できることだけで、推測は入れていません。
半導体メーカー：解禁から3週間で、社員3名がソースコードや会議の録音をChatGPTに入力
半導体設備向けデータベースのソースコード、不良機器を判定するプログラムのコード、会議の録音内容。入力欄への貼り付け、アップロード、入力で送られました。相手は社内で解禁されたChatGPTで、会社の管理は及びません。
The Register、2023.04.06拡張機能の乗っ取り：改ざんされた自動更新で、利用者のCookieや認証トークンが外部へ
データ保護製品Cyberhavenの拡張機能。開発者アカウントが乗っ取られ、悪意のある版がChromeウェブストアに公開されました。利用者側の操作はなく、同じ手口で十数個の拡張機能が改ざんされ、影響は数十万人規模とされています。
Sekoia.io、2025.01.22ヘルスケア企業：集計作業の中で、個人契約の生成AIに対象者の個人情報をアップロード
RIZAPの健康経営・保険者事業部の社員が、特定保健指導の対象者データの一部をアップロード。保険証記号番号、氏名、生年月日、メールアドレスのほか、高血圧症や糖尿病などの疾患情報が含まれていました。
CNET Japan、2026.09.04
半導体メーカーの件に共通するのは、悪意がないことです。3人とも、目の前の仕事を早く終わらせようとしただけでした4。同社はその後、1回の入力を1,024バイトまでに制限し、5月には社用端末での生成AI利用を禁止したと報じられています5。ただ、1,024バイトというのは、ソースコードの断片なら十分に収まる量です。量を制限しても、中身を見なければ同じことは起きます。
拡張機能の件は、利用者に落ち度がないタイプです。拡張機能はブラウザの中で動くので、ページに入力した内容やログイン状態に触れられます7。生成AIを名乗る拡張機能は、この1年でかなり増えました。どの端末に何が入っているか、把握できている会社のほうが少ないかもしれません。
ヘルスケア企業の件で見てほしいのは、経路です。データは「持ち出された」のではありません。集計という普通の業務の中で、アップロードされました。しかも、使われたのは会社のアカウントではなく、個人のアカウントです。同社は運営事業者に照会し、第三者に閲覧された可能性やAIの学習に使われた可能性はないと確認しています6。それでも、URLでアクセスを制御するだけでは、この操作は素通りします。
3つに共通すること
業種も規模も違う3件ですが、起き方は似ています。漏えいは、ページを開いた瞬間には起きていません。貼り付け、入力、アップロードをした瞬間に起きています。経路は、会社が契約したアカウントの外側でした。そして3社とも、事故のあとで「誰が、いつ、何を送ったか」を調べる必要に迫られています。
ここで、よくある対策を思い出してください。URLフィルタやCASBは、「どのサイトを開いたか」を見ています。3件が起きた瞬間は、その少し先です。IBMの調査でも、侵害を受けた組織の63%はAIのガバナンス方針を持たず、AIに関わる侵害を受けた組織の97%には適切なアクセス制御がありませんでした2。禁止の文言を増やしても、見えていない操作は見えないままです。
では、どの操作を見ればいいのか
3つの事例をブラウザ上の操作に分解すると、下の表になります。右の2列は、Foltaセキュアブラウザでポリシーを作るときの「イベント」と「条件」の名前です。イベントは「どの操作を見るか」、条件は「その操作のうち、どれを引っかけるか」を指します。
| 事例 | 起きた操作 | 見るべきイベント | 使う条件 |
|---|---|---|---|
| ソースコードや会議記録の入力 | ChatGPTの入力欄への貼り付け、テキスト入力 | ペースト、テキスト入力 | ファイル内容や正規表現（機密ワード、識別子の形式） |
| 個人情報を含むデータのアップロード | 個人アカウントの生成AIへファイルをアップロード | アップロード、ログイン | アカウント確認結果（外部）、ファイル内容 |
| 改ざんされた拡張機能 | 拡張機能のインストールと更新 | 拡張機能 | ブラウザ危険判定、拡張機能名 |
表を見ると、3件とも「アクセス」では捕まらないことが分かります。ChatGPTを開くこと自体は、止める理由がないからです。貼り付けやアップロードの瞬間に中身を見る。ログインしているアカウントの種類を見る。拡張機能が入る瞬間を見る。この3つが揃って、はじめて同じ経路を塞げます。
最初は「監視」だけで始める
Foltaでは、最初からブロックにすることをおすすめしていません。業務が止まりますし、何が過検知で何が未検知なのかも分からないまま、ルールだけが残るからです。
順番は3段階です。まず、止めずに記録する。個人情報や機密ワード、ファイルのアップロードなど、少し広めの条件で網を張ります。次に、記録を見ながら条件を絞り、リスクの高い操作にだけ警告を出す。警告文に理由を書いておくと、それ自体が社内への説明になります。最後に、業務で認めたAIは残したまま、機密情報の送信につながる操作だけをブロックに切り替えます。
監視の段階では、必ず過検知が出ます。過検知とは、止めなくていい操作まで引っかかることです。たとえば電話番号の形式を正規表現で拾うと、社内の識別子や日時の一部まで引っかかります。これは失敗ではなく、条件を絞り込むための材料です。この順番なら、ガイドラインの文言を大きく変えなくても、「何が起きているか」「何を止めたか」を数字で説明できます。
おわりに
ガイドラインを作ること自体は大事です。ただ、守られているかを確かめる手段がないと、事故が起きたときに説明できません。3つの事例が教えてくれるのは、見るべき単位は「サービス名」ではなく「操作」だ、ということです。
自社の状態を確認したい方は、下のチェックリストを使ってみてください。半分以上にチェックが付かなければ、まず監視だけで2〜4週間、実態を把握するところから始めるのが現実的です。Foltaでは、監視だけで始めるトライアルを受け付けています。
Sources