漏えいのお知らせには、よくこう書いてあります。「漏えいした可能性があるのはメールアドレスのみで、氏名・住所・クレジットカード番号は含まれていません」。読んだ側は少し安心します。しかし、この秋に公表された事例を並べると、メールアドレスだけの漏えいが、いちばん広く、いちばん長く効くことが見えてきます。本記事では、なぜ「だけ」が軽くないのか、そして自社のサービスで同じことが起きたときに何をすべきかを整理します。
この秋、「メールアドレス」は何件漏れたか
KDDIがISP事業者向けに提供しているメールシステムへの不正アクセスでは、メールアドレス12,231,954件が漏えいし、そのうち7,616,173件はパスワードも漏れました。侵入の開始は5月16日、KDDIが確認したのは6月17日です。1か月以上、気づかれないまま取得が続いていました。
出典: KDDI「ISP事業者向けメールシステムへの不正アクセスに関するご報告」（2026年7月6日、7月21日更新）
ビューカードでは、外部のメール配信サービスへの不正アクセスにより、約403万件のメールアドレスが閲覧・取得された可能性があります。氏名・住所・電話番号・カード番号は含まれていません。
出典: ビューカード「外部サービスへの不正アクセスによるメールアドレス漏えいの可能性について」（2026年10月9日）
ミスターマックスでは、アプリとオンラインストアのサーバーへの不正アクセスで、最大1,735,154人の会員ID・氏名・メールアドレス・電話番号が漏えいしました。住所・生年月日・カード情報・パスワード・購入履歴は含まれていません。
出典: ミスターマックス「不正アクセスによる情報漏えいに関するお詫びとお知らせ」（2026年10月6日）
3社とも、お詫び文に同じ趣旨の一文があります。「当社からパスワードやクレジットカード番号をお尋ねすることはありません」。各社が揃ってこれを書くのは、メールアドレスが漏れたあとに起きることを、各社がよく知っているからです。
メールアドレスは「鍵」ではなく「住所」だから厄介
パスワードやカード番号は鍵です。漏れたら変えればよく、変えれば古い鍵は使えなくなります。メールアドレスは住所です。変えるのが難しく、変えなくても使われ続ける。この違いが、被害の性質を分けます。
漏れたメールアドレスは、まず偽メールの宛先一覧になります。しかも「どの会社の顧客か」が分かった状態で漏れています。ビューカードの会員だと分かっていれば、ビューカードを装ったメールを送ればいい。ミスターマックスの会員なら、ミスターマックスを装う。本物の会社から本物のお詫びメールが届く時期に、偽物を混ぜれば、見分けはさらに難しくなります。各社が「パスワードを聞くことはない」と念を押すのは、この二次被害を見越しているからです。
さらに、メールアドレスは多くのサービスでログインIDを兼ねています。KDDIの件のようにパスワードまで一緒に漏れれば、同じ組み合わせを他のサービスで試す攻撃（パスワードの使い回しを狙うもの）が可能になります。だからKDDIとISP各社は、残っている利用者のパスワードを強制的に変更する対応を取りました。
法律は「だけ」をどう扱っているか
個人情報保護法では、漏えいが起きたときに個人情報保護委員会へ報告しなければならない場合が決まっています。要配慮個人情報が含まれる場合、財産的被害のおそれがある場合（クレジットカード番号や、決済に使えるIDとパスワードの組み合わせなど）、不正の目的による漏えい、そして本人の数が1,000人を超える場合です。報告の期限は、速報が発覚から3〜5日以内、確報が30日以内（不正目的の場合は60日以内）です。
注目すべきは、報告義務の有無に「メールアドレスだけなら軽い」という区別がないことです。1,000人を超えれば報告対象ですし、第三者による不正アクセスであれば「不正の目的」にも該当します。この秋の3件は、いずれも報告対象です。法律の側は、「だけ」を軽く扱っていません。
自社のサービスで起きたら、何をするか
ここからは、サービスを運営する側、あるいはこれからシステムを作る側の話です。漏えいは「起きないようにする」だけでなく、「起きたときに何をするか」を先に決めておくものです。起きてから考える会社は、報告の期限に間に合いません。
最低限、次の4つを平時に決めておきます。
- 誰が、何を見て、漏えいに気づくのか。KDDIは侵入から確認まで1か月かかっています。監視とログがなければ、気づくのは外部からの指摘になります。
- 気づいたら、何日目に、誰が、どこへ報告するのか。個人情報保護委員会への速報は3〜5日。社内の承認に1週間かけていたら間に合いません。報告の責任者と文面の雛形を先に用意しておきます。
- 本人への通知を、どの手段で、何を書いて出すのか。通知メールそのものが偽メールと見分けにくくなる時期です。「当社から○○を尋ねることはない」「リンクを踏まず公式サイトから操作する」を本文に入れるのは、3社の文面に共通する実務です。
- 何を漏らさずに済ませる設計になっているか。ミスターマックスの発表では、パスワードと購入履歴は漏れていません。ビューカードでは、配信サービスにメールアドレス以外を渡していませんでした。「漏れなかった項目」は、漏れる前の設計で決まります。
設計の話——「持たない」ことが最大の防御になる
4つめをもう少し掘ります。漏えい対策というと、侵入を防ぐ話になりがちです。しかし侵入は、KDDIのように開発元すら知らない脆弱性を突かれれば防げません。防げない前提で考えると、侵入されても漏れるものを減らす方向が残ります。
具体的には、集めない、残さない、分けるの3つです。会員登録で電話番号は本当に必要か。退会した人のデータをいつまで残すのか。メール配信サービスに、宛名以上の情報を渡す必要があるのか。これらは技術ではなく、サービスを作るときの決めごとです。そして決めごとは、作る前が一番安く、作ったあとに変えるのは高くつきます。
AIでシステムを速く作れるようになった分、この決めごとを飛ばして作り始める場面が増えています。バイブコーディングで作った業務アプリの調査で、認証なしでデータを削除できる状態のアプリが172件見つかった話を以前書きましたが、問題は同じ根です。「動く」ことと「漏れない」ことは別の設計で、後者は最初に決めないと入りません。
まとめ——お詫び文の「のみ」を、設計の言葉に翻訳する
「メールアドレスのみ」という一文は、読む側には安心材料として、書く側には防御線として機能しています。けれど、法律はそれを軽く扱わず、攻撃者はそれを住所録として使い、利用者は住所を変えられません。
サービスを作る側がこの一文から学ぶべきは、漏れたときに「のみ」と言える範囲を、作る前に決めておくことです。集めない項目は漏れません。渡さない相手からは漏れません。この秋の事例は、どれも「漏れなかった項目」があったからこそ、被害が限定されました。その線を引くのは、侵入を防ぐ技術ではなく、設計です。
メールアドレスをログインの手段には使わず、パスワードを忘れたときの回復にだけ使う設計の見本を、passkey-auth-starter としてコードと解説つきで公開しています。
「起きたら何をするか」を、作る前に。
JumpStackは、お客さまの現場にAIチームを配置するFDEを軸に、課題の定義から実装・運用までをご一緒しています。集めない・残さない・分ける設計と、漏えい時の手順づくりまで含めて、最初からご一緒します。
設計から相談する