地下鉄運営の東京地下鉄株式会社（東京メトロ・東京都台東区）、委託先のサーバが不正アクセスを受け「メトポ」会員のメールアドレス約59,000件が漏えいした可能性
| 項目 | 内容 |
|---|---|
| 発生日 | メール配信サービスの不具合発生: 2026年9月20日／不正アクセスの確認: 2026年9月25日 |
| 公表日 | 2026年9月27日 |
| 対象組織・業界 | 東京地下鉄株式会社（東京メトロ／東京都台東区東上野・地下鉄9路線を運営する旅客鉄道事業者）。不正アクセスを受けたのは、同社がポイントサービス「メトロポイントクラブ（メトポ）」の会員向けサービスを委託する会社のサーバ |
| 影響件数 | メールアドレス 約59,000件。メトポ会員の登録アドレスのうち、メールを送信できず同社が配信を停止していたもの。当該サーバにメールアドレス以外の会員情報は保存されていない |
| 攻撃手法 | 委託先サーバへの第三者による不正アクセス（国外からとみられる）。侵入経路は公表されていない |
| 情報源 | ITmedia NEWS（2026年9月28日）、INTERNET Watch（2026年9月27日）、ASCII.jp（2026年9月28日）、日本経済新聞（2026年9月29日）、ScanNetSecurity（2026年10月2日）、サイバーセキュリティ.com（2026年9月29日） |
東京地下鉄株式会社（東京メトロ／東京都台東区東上野・地下鉄9路線を運営する旅客鉄道事業者）は2026年9月27日、ポイントサービス「メトロポイントクラブ（メトポ）」の会員向けサービスが第三者による不正アクセスを受け、約59,000件のメールアドレスが閲覧または取得された可能性があると公表しました。
不正アクセスを受けたのは、同社がこのサービスを委託する会社のサーバです。保存されていたのは、メトポ会員が登録したメールアドレスのうち、メールを送信できず同社が配信を停止していたもので、当該サーバにメールアドレス以外の会員情報は保存されていなかったと説明されています。氏名や住所、ポイント残高といった会員情報、決済に関する情報は対象に含まれていません。
発端は9月20日に起きたメール配信サービスの不具合でした。同社が調査を進めたところ、9月25日になって、委託先のサーバに国外からとみられる第三者による不正なアクセスがあったことが確認されています。同社は被疑箇所を特定したうえで対策を実施済みで、対象となる会員にはメールで個別に連絡するとしました。
あわせて同社は、この連絡にあたって追加の手続きを依頼したり外部のサイトへ誘導したりすることはないと明示したうえで、東京メトロを装う不審なメールに注意するよう呼びかけました。影響範囲と原因の詳細については調査が続いています。
- 2026年9月20日: メトポ会員向けのメール配信サービスで不具合が発生。同社が調査を開始
- 2026年9月25日: 調査の過程で、サービスを委託する会社のサーバに対し、国外からとみられる第三者による不正なアクセスがあったことを確認。被疑箇所を特定し対策を実施
- 2026年9月27日: 事案を公表。約59,000件のメールアドレスが閲覧または取得された可能性があると発表し、同社を装う不審なメールへの注意を呼びかけ。対象者にはメールで個別に連絡するとした
- 2026年10月3日（本記事執筆時点）: 影響範囲と原因の詳細は調査中。続報は確認されていません
侵入経路は公表されていません。以下は、会員向けのメール配信などを外部に委託している組織が、自社に当てはめて確認できることです。
1. 配信できなくなったアドレスに保持期間を決める
Section titled “1. 配信できなくなったアドレスに保持期間を決める”今回持ち出された可能性があるのは、メールを送信できず配信を停止していたアドレスでした。退会や宛先不明によって使われなくなった連絡先は、業務上はもう参照されないまま、配信システムの側に残り続けます。
送信不能として扱いを止めたアドレスについて、その時点から何か月で削除するかを決め、削除までの処理を配信システムの設定として組み込んでおきます。そうすれば、同じ侵害が起きたときに対象となる件数が、決めた期間に流入した分だけに収まります。持っていないデータは漏れません。あわせて、削除が配信システム本体だけでなく、バウンス履歴や配信ログといった付随する保管先まで及んでいるかも確認します。
2. 委託先に預けているデータの項目と件数を、自社の側で持っておく
Section titled “2. 委託先に預けているデータの項目と件数を、自社の側で持っておく”本件で侵害されたのは自社のシステムではなく委託先のサーバでした。委託先に預けたデータは、どの項目を何件渡しているのかが自社の側で分からなくなりやすく、分からないままだと、事故が起きてから委託先の回答を待つ間、影響範囲を説明できない時間が生まれます。
委託先ごとに、渡している項目・件数・保管場所・保持期間を一覧にして、内容が変わるたびに更新します。この一覧があれば、委託先から「不正アクセスがあった」という連絡を受けた時点で、自社の対象件数と情報の種類をその場で答えられます。あわせて、異常が起きたときに委託先からログの提出を受けられることを契約に書いておきます。
ヤグラの視点 — 持ち出されたのが「メールアドレスだけ」で終わるかは、次の1通を止められるかで決まります
Section titled “ヤグラの視点 — 持ち出されたのが「メールアドレスだけ」で終わるかは、次の1通を止められるかで決まります”本件の検知は、侵入の痕跡そのものではなく、メール配信サービスの不具合という業務影響から逆に辿る形で始まっています。9月20日の不具合から不正アクセスの確認までには5日が空きました。委託先のサーバは自社の監視対象から外れやすく、侵入時に何らかの記録が残っていたとしても、それを平常時から見ている人は自社にも委託先にもいない、という状態が起こりえます。委託先を含めた認証ログ・通信ログを一か所に集めて日常的に突き合わせておけば、業務の不具合として表に出るのを待たずに、異常なアクセス自体を起点に調べ始められます。ログの量は人手で見切れる規模ではないため、AIによる24時間365日の横断的な監視を置くことで、検知から初動までを数分の単位に縮められます（→ ヤグラ AI SOC）。
もう一つは、持ち出されたリストがこの先どう使われるかです。今回外部に渡った可能性があるのはメールアドレスだけですが、それは「東京メトロのポイントサービスに登録していることが確定した宛先の一覧」でもあります。同社自身が、追加の手続きを求めることはないと断ったうえで装いメールへの注意を呼びかけているのは、この性質を踏まえたものと考えられます。生成AIによって違和感のない日本語の文面を量産できるようになった以上、会員向けの案内を模したメールが届くことは想定しておくべきです。
受け取る側にできるのは、怪しい1通を自分で判断しきることではなく、早く報告することです。報告の間口をメーラー上の1クリックまで下げ、報告された1通をAIが数分で分析して、同じメールが社内の誰に届いているかまで自動で洗い出す。ここまでを仕組みにしておくと、1件目の報告が二人目以降の被害を止める材料に変わります（→ PhishAI）。
- 委託先サーバへの侵入経路と、不正アクセスが行われていた期間
- 閲覧または取得された可能性があるとされた約59,000件について、実際に持ち出されたかどうかの確定
- 委託先の社名と、当該サーバが担っていた処理の範囲
- 配信を停止していたアドレス以外のメトポ会員情報への影響の有無
- 漏えいしたアドレスを宛先とする、東京メトロを装ったフィッシングメールの発生状況
- 個人情報保護委員会への報告および同社が公表する再発防止策
判明次第、本記事に追記します。
| 日時 | 内容 |
|---|---|
| 2026-10-03 | 第一報を公開 |
