記事一覧に戻る
security-news2026年9月29日13分で読めます

届かなかったメールは、どこへ行く? — メトポ5.9万件で見えた「配信という別の管」

東京メトロメトポ不正アクセスメール配信バウンスDMARC外形調査委託先管理

届かなかったメールは、どこへ行く? — メトポ5.9万件で見えた「配信という別の管」

2026年9月27日、東京メトロは「メトロポイントクラブ(メトポ)」の会員向けサービスで不正アクセスがあり、約5万9,000件のメールアドレスが閲覧または取得された可能性があると公表した。

ただし、漏れた可能性があるのは全会員のメールアドレスではない。公表されているのは、**「メールの送信不能により、配信を停止していたメールアドレス」**だ。

今回の事案を読むうえで、一番気になったのはここだった。メールが届かなかったとき、そのアドレスはどこに残るのか。

公開情報と外形を追ってみると、東京メトロ本体のメールとは別に、メトポには外部のメール配信サービスを使った「別の管」がある姿が見えてきた。

9月20日の「不具合」から始まった

東京メトロの発表によると、最初の異変は9月20日。メトポが利用するメール配信サービスで不具合が発生した。

その後の調査で、9月25日に「通常とは異なる利用記録」が見つかり、国外からと思われる第三者による不正アクセスが判明した。

アクセスされていたのは、送信不能となったため配信を停止していたメールアドレスが格納されたサーバー。約5万9,000件について、第三者に閲覧または取得された可能性がある。

東京メトロは被疑箇所を特定して技術的な防御措置を実施し、「委託先を含めた原因の調査」を続けている。

  • 9月20日:メール配信サービスで不具合
  • 9月25日:通常とは異なる利用記録を発見、不正アクセスを確認
  • 配信停止中のメールアドレス約5万9,000件について閲覧・取得の可能性を確認
  • 9月27日:公表

特に気になるのが、最初の「不具合」と、5日後に見つかった「通常とは異なる利用記録」の関係だ。

不具合そのものが攻撃だったのか。攻撃の結果として不具合が起きたのか。あるいは不具合を調べたことで、以前から続いていた侵入が見つかったのか。ここはまだ公表されていない。

東京メトロ本体のメールとは違う

まず、外形から東京メトロ本体とメトポを比較した。

東京メトロ本体のドメインでは、メール受信に専用のメールセキュリティ基盤が使われ、SPFは許可した送信元以外を拒否する設定になっている。DMARCも p=quarantine が設定されている。少なくとも、本体のメールの正面はかなりきちんと固められている。

一方、メトポでは以前から別のメールドメインが使われている。現在のメトポの登録案内でも、会員登録メールなどを受信するため、旧来のメトポ用ドメインを受信許可するよう案内されている。

さらに2025年5月、メトポは新しい送信元として i.metpo@tokyometro.jp を追加した。ただし、それまで使っていたメトポ用ドメインからの配信も継続すると明記している。

利用者から見ればどちらも「メトポから届くメール」だが、裏側では複数のメール系統が併存している。

配信は、別の管だった

そこで、旧来のメール系統を公開DNSから追った。

SPF、IPアドレスの割当情報、逆引きを確認すると、配信に使われるネットワークは東京メトロ本体のネットワークではない。外部のメール配信サービス事業者側のネットワーク上に、東京メトロ向けとみられる専用の送受信ホストが配置されている構成が確認できた。

委託先がどこかに独自のメールサーバーを1台立てている、という姿とは少し違う。より自然なのは、外部事業者が提供するクラウド型のメール配信基盤を利用し、その中に東京メトロ向けの専用環境が割り当てられているという構成だ。

具体的な製品名、事業者名、IPアドレス、ホスト名はここでは記載しない。公開情報から分かるのは送信許可先とネットワークの割当先までで、それだけで「その事業者の基盤そのものが侵害された」とは言えないからだ。

東京メトロ向けに割り当てられたテナントや認証情報だけが侵害された可能性もある。その場合、配信サービス事業者は侵害された主体ですらない。名前を出すことで、逆に誤った印象を与えてしまう。

「配信停止アドレスだけ」が重要

ここまで来ると、なぜ約5万9,000件が「配信停止中のアドレス」だったのかも見え方が変わる。

大量メールの配信では、送信先のメールサーバーから「そのアドレスは存在しない」「メールボックスがいっぱい」「受信を拒否した」といった応答が返ってくる。いわゆるバウンスだ。

同じ宛先へ送り続けると送信元の評価が落ち、正常な会員にも届かなくなる。そのため配信システム側ではこうしたアドレスを記録し、以後の配信から除外する。

つまり、**「届かなかったメールアドレスの一覧」そのものが、配信サービス側に残るデータになる。**今回公表されたデータの性質とも矛盾しない。

例えば会員情報そのものは東京メトロ側のシステムに持ち、メールを送るときだけ配信システムへ宛先を渡す構成なら、配信サービス側に長く残るのは全会員名簿ではなく、エラーになったアドレスや配信停止リストだけ、ということもあり得る。

もちろん、これはまだ仮説だ。東京メトロはシステム構成や侵入経路を公表していない。ただ、「なぜ全会員ではなく、配信停止アドレスだけだったのか」を説明できる一つの構造ではある。

侵入経路の推測

外形と公表内容から、侵入経路を推測すると次のようになる。

1. 東京メトロ向けのテナント・認証情報が侵害された(約55%)

東京メトロ向けに割り当てられた配信サービスのアカウント、API認証情報、管理系の認証情報などが侵害されたケース。

この場合、影響は東京メトロ向け環境だけにとどまる可能性が高い。その環境から参照できるデータが配信停止リストだったのであれば、「約5万9,000件だけ」という公表範囲とも矛盾しない。9月20日の不具合を不正送信の結果と見るなら、こちらの方が筋が通る。

ただし、認証情報が盗まれたという事実は公表されていない。

2. 配信サービスの基盤そのものが侵害された(約30%)

配信サービス事業者側のシステムや管理基盤自体に脆弱性や設定不備があり、そこから侵入されたケース。こちらなら、同じサービスを利用する別の顧客にも影響が及ぶ可能性が出てくる。

公開情報を確認した範囲では、それを示すような広範な障害や事業者側からのセキュリティ告知は見当たらない。だからといって、基盤側の侵害を否定できるわけではない。

3. その他(約15%)

委託先の端末経由など、上の2つに当てはまらない経路。

現時点では1を第一候補と見ている。公表範囲が東京メトロの配信停止アドレスに限られていることは、テナント単位の問題と矛盾しない。

以前からメール配信障害は起きていた

今回の事案だけを見ると、メール配信は単なる「お知らせメール」の仕組みに見えるかもしれない。しかしメトポでは、メール配信システムが会員サービスそのものに深く組み込まれている。

2026年1月19日にも、メトポは「メール配信システム」の障害を公表している。そのとき影響したのは、新規入会、会員情報変更、他社ポイントへの交換、オフピークサービスの参加・解除などだった。2025年9月にもメールサーバー障害があり、新規入会用URLや各種変更手続きのメールが送れなくなっている。

メールは単なる広告配信ではない。本人確認や業務処理を最後まで成立させるための、サービスの一部になっている。メール配信基盤が止まれば、ポイントサービスの機能まで止まる。

本体を守っても「別の管」が残る

外形を追っていて一番印象に残ったのはここだった。

東京メトロ本体のメールは、専用のメールセキュリティ基盤を通し、SPFやDMARCも設定されている。しかし、利用者へメールを届ける仕組みはそれだけではない。

マーケティングメール。会員登録メール。パスワード再設定。ポイント交換。エラー通知。そして、届かなかったメールを処理する仕組み。

利用者には全部「東京メトロから届くメール」に見える。だが裏側では、それぞれが別のサービス、別の事業者、別の認証情報、別の監視系統を通っていることがある。

今回破られた可能性があるのは、会社の正面玄関ではない。外に預けていた「配信という別の管」の側だった。

漏れた後に見るべきは「なりすまし」

東京メトロ自身も、対象者に対して同社を装った不審メールへの注意を呼びかけている。これは重要だ。

漏えいした可能性があるのは、実際にメトポへ登録されていたメールアドレスだ。「送信不能」でも、キャリアメールの受信設定で弾かれただけでアドレス自体は生きている、というケースは日本では珍しくない。攻撃者がそれを取得していれば、「この人はメトポを使っていた可能性が高い」という文脈も同時に得る。無差別なフィッシングより、はるかに話を作りやすい。

一方、外形を確認すると、本体のメールドメインにはDMARCが設定されているのに対し、旧来のメトポ用メールドメインではDMARCの設定を確認できなかった。送信元の許可範囲も、本体ほど厳しくは締められていない。

だからといって、そのドメインを名乗るメールが必ず受信箱へ入るわけではない。受信側の判定、SPF、DKIMなど複数の要素がある。ただ、実在する利用者のメールアドレスが第三者に渡った可能性がある以上、旧来のメール系統についても、ドメインなりすまし対策を改めて締める意味は大きい。

注意喚起だけで終わらせず、送信ドメイン側でも守る。比較的早く着手できる対策の一つだと思う。

次の答え合わせは3つ

この事案はまだ調査中だ。次の公表で見たいのは3点ある。

  1. 9月20日の「不具合」の中身。 不正アクセスによって起きた障害だったのか、別の障害を調べていて侵入を見つけたのか。ここが分かると、侵入時期や検知の姿がかなり見える。
  2. 侵入の単位。 「配信サービス事業者の基盤」なのか、「東京メトロ向け環境」なのか。後者なら、アカウントやAPI認証情報、管理経路が次の焦点になる。
  3. 約5万9,000件以外のデータ。 東京メトロは、その他の会員情報が閲覧・取得されていないか調査を続けている。最終的にも配信停止アドレスだけで決着するなら、なぜそのデータだけがその場所に残っていたのかが、この事案の構造を理解する手がかりになる。

正面玄関だけを見ても、今のサービス全体は見えない。届いたメールだけでなく、届かなかったメールがどこへ行くのか。今回の5万9,000件は、その普段ほとんど意識されない場所から見つかった。

参考

  • 東京地下鉄「メトポ会員向けサービスにおける不正アクセス事案の発生について」(2026年9月27日)
  • メトロポイントクラブ「送信元メールアドレスの追加について」(2025年5月26日)
  • メトロポイントクラブ「メトポメール配信システム障害に関するお知らせ」(2026年1月19日)
  • メトロポイントクラブ「メトポ会員向けメール配信システム障害に関するお知らせ」(2025年9月24日)

※本記事の外形調査では、公開DNSのSPF・DMARC、IPアドレスの割当情報、逆引きDNSを確認した。具体的なIPアドレス、ホスト名、サービス事業者名は、不正アクセスされた主体が現時点で特定できないため記載していない。

キーワード

  • 東京メトロ
  • メトポ
  • 不正アクセス
  • メール配信
  • バウンス
  • DMARC
  • 外形調査
  • 委託先管理
A

Aikido Community Japan

公開日: 2026/9/29

最終更新: 2026/9/29

シェア:

ニュースを購読

セキュリティの最新情報をお届けします。

Aikido Community Japan からのお知らせの受信に同意します。詳しくはプライバシーポリシーをご確認ください。