2026.10.05 セキュリティ

東京メトロ（メトポ）の不正アクセスと約5.9万件のメールアドレス｜配信停止リストを残さない設計

東京地下鉄（東京メトロ）は2026年9月27日、ポイントサービス「メトロポイントクラブ（メトポ）」の会員向けサービスで第三者による不正アクセスがあり、メールアドレス約59,000件が閲覧または取得された可能性があると公表しました。狙われたのは、メールが届かないため配信を止めていたアドレスを格納したサーバーです。本記事では公式発表をもとに経過と対象を整理し、メールアドレスだけが漏れた場合に何が起きるか、会員が今日やる点検をまとめます。後半では、送れないアドレスを平文で持ち続けない配信停止リストの作り方を、そのまま試せるコードと設定で示します。

まとめ：東京メトロの不正アクセスで確定した事実と利用者・開発者が今やること

公式発表で確定しているのは、メトポ会員が登録したメールアドレスのうち、送信不能で配信を停止していたアドレスを格納したサーバーに不正アクセスがあったこと、件数が約59,000件であること、当該サーバーにメールアドレス以外の会員情報は含まれていなかったことです。被疑箇所は特定済みで、不正アクセスを防ぐ対策も実施したとされています。一方、侵入の手口、サーバーを運用していた事業者、原因の詳細はまだ明らかになっていません。

会員がまず備えるのは、東京メトロやメトポを装う不審なメールへの対応です。開発者の側で見るべき論点は別にあります。もう送らないと決めたアドレスの一覧が、平文のまま独立したサーバーに残っていた点です。配信停止リストをどう持つかという設計の問題として、自社の配信基盤に引き寄せて点検できます。

項目	公表されている内容
公表日	2026年9月27日
対象サービス	メトポ会員向けサービス
件数	約59,000件
流出の可能性	メールアドレスのみ
対象サーバー	配信停止中のアドレスの格納先
侵入の手口	未公表
運用事業者	未公表

公表内容を時系列で確認する｜9月20日の配信不具合から9月27日の公表まで

メール配信の不具合から国外とみられる不正アクセスの判明までの経過

報道各社が引用しているメトポ公式サイトのお知らせによると、発端は2026年9月20日に起きたメトポのメール配信サービスの不具合でした。調査を進めるなかで9月25日に通常とは異なる利用記録が見つかり、国外からとみられる第三者による不正なアクセスがあったことが分かったと説明されています。

侵害の発見が、監視のアラートではなく配信の不具合をきっかけにしている点は押さえておきたいところです。不具合の発生から不正アクセスの確認までに要した期間は5日です。配信基盤の異常を障害として扱うだけでなく、侵害の兆候として利用記録までさかのぼる手順を持っていたかどうかで、発見の早さは変わります。ログのどこを見るかは不正アクセスのログ確認・解析方法で整理しています。

東京地下鉄の9月27日付の公表文で確定した不正アクセスの対象と件数

東京地下鉄の公表文（2026年9月27日）は、メトポ会員が登録しているメールアドレスのうち、メールの送信不能により同社が配信を停止しているアドレスを格納したサーバーへの不正アクセスを確認したと記しています。件数は約59,000件で、表現は「閲覧または取得された可能性」です。当該サーバーにメールアドレス以外の会員情報が含まれていないことも確認済みとしています。

対象者には同社からメールで連絡し、別途の手続きや外部サイトへの遷移は求めないと明記されました。案内の送信元は「メトロポイントクラブ事務局」のアドレスに限るとされ、問い合わせ窓口として専用フォームと電話（0120-162-837・9時から17時）が設けられています。影響範囲と原因の詳細は調査を継続中です。

手口と運用事業者が未公表の段階で公式発表から書けることと書けないこと

公表文が示すのは、配信停止中のアドレスを格納したサーバーへの不正アクセスと、そのサーバーの中身がメールアドレスだけだったという事実です。どの経路から入られたか、どの脆弱性が使われたか、サーバーをどの事業者が運用していたかには触れていません。

そのため本記事では、特定の製品や委託先に結び付けた推測はしません。読み取れるのは構図だけです。配信できないアドレスの一覧が、会員DBとは別のサーバーに、照合に使える形のまま蓄積されていました。後半で扱う設計の話は、この構図を前提にしています。

流出したのは配信停止中のメールアドレス｜単体の漏えいで起きる悪用の型

メールアドレスだけでも個人情報に当たる場合と東京メトロの会員という属性

メールアドレスは氏名や住所に比べて軽く見られがちですが、単体でも個人情報に当たる場合があります。個人情報保護委員会のガイドライン（通則編）2-1の事例5は、[email protected] のように、どこの誰のアドレスか分かる場合を個人情報の例に挙げています。

今回のアドレスには、もう一つの情報が付いています。メトポの会員として登録されていたという属性です。攻撃者から見れば、東京メトロを日常的に使う人の一覧として扱えます。差出人を東京メトロやメトポに偽装したメールは、無差別に送るメールより開かれやすくなります。

配信不能のアドレスが混ざる一覧で攻撃者に残る価値と悪用の範囲

格納されていたのは送信不能で配信を止めたアドレスなので、すでに使われていないものも含まれるはずです。その分だけ悪用の効率は下がります。ただし、送信不能の理由は廃止だけとは限りません。受信箱の容量超過や受信側サーバーの一時的な障害で届かなかったアドレスが、配信停止のまま残っていることもあります。

想定される悪用は、偽のログイン画面に誘導するフィッシング、ポイント失効や補償を名目にした詐欺、他サービスでの使い回しパスワードを狙った不正ログインの足掛かりです。パスワードは今回の対象サーバーに含まれていないため、メトポのアカウントがそのまま乗っ取られる状況ではありません。手口の全体像はフィッシング詐欺とはで解説しています。

想定される悪用	きっかけ	利用者側の防ぎ方
偽ログイン画面	メトポを装うメール	メールのリンクを使わない
補償名目の詐欺	お詫びを装う連絡	公式サイトで確認する
不正ログイン	パスワードの使い回し	他サービスを変更する
迷惑メール増加	名簿の転売	受信設定で振り分ける

メトポ会員が今日やる点検手順｜東京メトロを装うメールの見分け方と受信設定

公式の案内が届く送信元と東京メトロが対象者に求めないと明言した操作

公表文は、対象者への案内をメールで送るとしたうえで、別途の手続きや外部サイトへの遷移は求めないと書いています。リンクを押してログインやカード情報の入力を求めるメールは、この公表文の説明に照らせば偽物です。迷惑メール対策で案内が届かない場合に備え、メトロポイントクラブ事務局のアドレスからのメールを受信できるよう設定してほしいとも呼びかけています。

判断は、メールの中のリンクや電話番号を使わず、自分でメトポの公式サイトや東京メトロの公式サイトを開いて確かめる、の一点に絞ると迷いません。送信元の表示名やアドレスは偽装できるため、それだけで本物と決めないことも大切です。不審なメールを受け取ったら、フィッシング対策協議会のサイトで同じ文面の事例が出ていないかを確認できます。

同じメールアドレスで登録した他サービスを優先度に沿って確認する順番

メールアドレスが知られても、それだけで他サービスに入られることはありません。危ないのは、同じアドレスと同じパスワードの組み合わせを複数のサービスで使っている場合です。過去に別のサービスから漏れたパスワードと今回のアドレスが突き合わされると、不正ログインを試される材料になります。

変更の優先度は、パスワード再設定の受け口になるメールアカウント、決済や送金に関わるサービス、交通系やポイント系のサービスの順です。あわせて二要素認証を有効にしておくと、パスワードが知られても単独では入れなくなります。自分のアドレスが過去の流出に含まれていないかを調べる方法は、流出チェックの方法でまとめています。

配信停止リストはなぜ狙われるか｜送れないアドレスを持ち続ける設計の盲点

配信停止リストが削除されずに増え続ける運用上の理由と保管の実態

メール配信の基盤は、届かなかったアドレスや苦情が来たアドレスへ再送しないための一覧を持ちます。送り続けると送信元の評価が下がり、正常な宛先にも届きにくくなるためです。この一覧は、会員が退会したあとも、アドレスを変えたあとも、同じアドレスへ誤って送らないために残し続けるのが一般的です。

たとえばAmazon SESのアカウントレベルのサプレッションリストは、ハードバウンスと苦情（BOUNCEとCOMPLAINT）のアドレスを自動で追加し、公式ガイドには、リストのアドレスは削除するまで残り続けると書かれています。送信を一時停止されたアカウントで90日後に自動削除される例外を除けば、運用者が消さない限り減りません。今回のサーバーが配信停止中のアドレスだけを約5.9万件抱えていたのも、この性質と合っています。

会員DBと分けたはずの配信停止リストが侵害の入口と出口になる構図

配信停止リストは、会員DBと切り離された配信基盤側に置かれることが多くあります。会員の氏名や住所を持たないため、扱いが軽くなりやすい場所です。しかし中身は平文のメールアドレスで、しかも特定のサービスの利用者という属性が付いています。会員DBほど厳しく守られていない場所に、名簿として使える一覧が置かれている状態です。

削除済みのはずのデータが別の場所に残り、侵害でまとめて持ち出される構図は、Gyazoの不正アクセスや、退会者の本人確認書類まで流出したタイムズカーの不正アクセスとも共通しています。消さなくてよいと判断した一覧ほど、その中身を平文で持つ必要があるかを問い直す価値があります。

配信停止リストをHMACで持つ｜平文アドレスを保存せず照合する実装例

送る前の照合だけなら平文は不要｜HMAC-SHA256で照合用トークンを作るコード

配信停止リストの用途は、送ろうとしているアドレスが一覧に含まれるかどうかの判定です。判定だけなら、アドレスそのものを持たずに、鍵付きハッシュの値を持てば足ります。RFC 2104で定義されたHMACは、秘密鍵を知らない者には同じ値を計算できない方式です。次はPythonの標準ライブラリhmacで、アドレスから照合用のトークンを作る例です。

# 配信停止リスト用の照合トークンを作る（Python 3）
import hashlib
import hmac
import os

# 鍵はDBと別の場所（Secrets ManagerやKMSなど）から読み込む
KEY = os.environ["SUPPRESSION_HMAC_KEY"].encode("utf-8")

def normalize(address: str) -> str:
    # 前後の空白を除き、小文字にそろえてから計算する
    return address.strip().lower()

def suppression_token(address: str) -> str:
    return hmac.new(KEY, normalize(address).encode("utf-8"), hashlib.sha256).hexdigest()

def is_suppressed(address: str, tokens: set[str]) -> bool:
    return suppression_token(address) in tokens

if __name__ == "__main__":
    t = suppression_token(" [email protected] ")
    print(t)                      # 64桁の16進文字列
    print(is_suppressed("[email protected]", {t}))  # True

小文字にそろえる正規化を入れているのは、大文字小文字の違いで照合漏れを起こさないためです。SESのサプレッションリストも、送信時は大文字小文字を同一に扱う一方で、管理APIでは登録時の表記と完全一致を求めると公式ガイドに注意書きがあります。正規化の規則は、トークンを作る全ての処理で共通にしてください。

照合トークンだけを保存する配信停止テーブルの定義と送信前の判定SQL

保存するのはトークンと停止理由、登録日時だけです。PostgreSQLでの定義と、送信前の判定は次のとおりです。

-- 配信停止リスト：平文のアドレスは保存しない（PostgreSQL）
CREATE TABLE email_suppression (
  addr_token  CHAR(64) PRIMARY KEY,         -- HMAC-SHA256の16進
  reason      VARCHAR(16) NOT NULL,          -- BOUNCE / COMPLAINT / UNSUBSCRIBE
  added_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- 送信前の判定：1行返れば送らない
SELECT 1 FROM email_suppression WHERE addr_token = $1;

このテーブルが丸ごと持ち出されても、鍵がなければアドレスは復元できません。ただし鍵まで奪われた場合は、攻撃者が手元のアドレス一覧から同じ計算をして、一覧に含まれるかを確かめられます。鍵は配信停止リストと別の場所に置き、読み出せる権限を送信処理だけに絞ることが前提です。平文で一覧を持つ方式と比べ、DBだけを抜かれた場合の被害が名簿の流出から照合不能な値の流出に変わる点が、この方式の効き目です。ハッシュと暗号化の違いはハッシュ化とはで整理しています。

HMAC方式の配信停止リストを採用する条件と平文が必要になる場面の見極め

会員数が数万を超える、配信停止リストが会員DBと別の基盤に置かれている、または委託先が配信基盤を運用している場合は、HMAC方式へ移す価値があります。一覧が漏れたときの被害を、運用の手間をほとんど増やさずに小さくできるためです。

一方で、停止中のアドレスを担当者が目で見て解除する運用や、宛先のドメイン単位で傾向を分析する運用がある場合、トークンだけでは足りません。その場合は平文を暗号化して別テーブルに置き、閲覧を問い合わせ対応の担当に限ります。いずれの方式でも、一定期間を過ぎた停止記録を見直す期限を決めておくと、件数が無制限に増えるのを防げます。配信基盤を自前で組む場合の全体設計はメール配信システムの自作・構築とはを参照してください。

Amazon SESのサプレッションリストを点検する｜残り続けるアドレスの棚卸し

登録日時で古い停止アドレスを抽出して件数と内訳を把握するCLI

SESを使っている場合、自社でHMAC方式を組む前に、SES側のリストに何件たまっているかを確認しておくと状況がつかめます。次のAWS CLIのコマンドは、公式ガイドに載っている一覧取得の操作です。終了日時を指定すると、それより前に追加されたアドレスだけを返します。

# 全件を一覧する（NextTokenが返れば続きを取得する）
aws sesv2 list-suppressed-destinations

# 2025-10-01より前に追加されたアドレスだけを一覧する（UTCのUnix時刻で指定）
aws sesv2 list-suppressed-destinations --end-date 1759276800

# 誤って停止された宛先を個別に解除する
aws sesv2 delete-suppressed-destination --email-address [email protected]

出力にはアドレス、停止理由、最終更新日時が並びます。古い停止記録が大量にある場合は、その一覧がどこに複製されているかも確かめてください。SESのリストをCSVに書き出して配信システム側のDBへ取り込んでいる運用では、平文の一覧がもう一か所に増えています。

SES側とアプリ側で配信停止の記録を二重に持つときの役割の分け方

SESのリストは、誤送信を防ぐ最後の安全装置として残します。アプリ側では、HMACトークンで判定して送信要求そのものを出さないようにします。こうすると、平文のアドレスを持つのはSESの中だけになり、自社のDBやエクスポートしたファイルに名簿が散らばりません。

SESのリストへの一括追加は100,000件、一括削除は10,000件がAPI呼び出し1回あたりの上限と公式ガイドに記載されています。大量の棚卸しを行う場合は、この単位で分けて処理してください。

自社ドメインのなりすましを止める｜SPF・DKIM・DMARCの設定とRFC 9989

流出したアドレス宛ての偽メールを受信側で弾くためのDMARCレコード

流出したアドレスに届く偽メールの多くは、差出人を東京メトロのような実在の事業者に見せかけます。差出人に自社ドメインそのものを使われる偽装は、送信側のDMARC設定で受信側に拒否させられます。DMARCの仕様は2026年5月にRFC 9989として標準化され、従来の段階適用に使われていたpctタグは廃止されました。代わりにt=yで試験運用を示します。

; 試験運用：受信側はpより1段階弱く適用する（RFC 9989のt=y）
_dmarc.example.jp. 3600 IN TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected]"

; 本番：存在しないサブドメインも含めて拒否させる
_dmarc.example.jp. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:[email protected]"

# 反映を確認する
dig +short TXT _dmarc.example.jp

t=yを付けたp=quarantineは、受信側では1段階弱いnone相当として扱われます。集計レポートで正規の送信元が全て認証を通っていることを確かめてから、t=yを外し、rejectへ進めてください。各ポリシーの差はDMARCの仕組みとnone・quarantine・rejectの差で詳しく比べています。

会員向けに大量配信する事業者がGmailの送信者要件で満たす項目

会員向けのお知らせを大量に送る事業者には、受信側の要件もかかります。Gmailの送信者のガイドラインは、1日5,000件以上を送る送信者に、SPFとDKIMの設定、DMARCの設定（ポリシーはnoneでも可）、Fromヘッダーのドメインの整合、ワンクリックの登録解除、迷惑メール率0.3%未満の維持を求めています。

要件上はnoneで足りますが、なりすましを実際に止めるのはquarantine以上です。名簿が漏れた直後は偽メールが増えるため、noneのまま運用している事業者は、移行の計画を前倒しする理由になります。SPFレコードの書き方はSPFとはで解説しています。

委託先が運用するメール配信基盤の監督｜契約・把握・漏えい時の報告の段取り

個人情報保護委員会のガイドラインが求める委託先監督の三つの要素

メール配信は外部のサービスや委託先に任せることが多い業務です。ガイドライン（通則編）3-4-4は、委託先に対する必要かつ適切な監督として、適切な委託先の選定、委託契約の締結、委託先における個人データの取扱状況の把握の三つを挙げています。契約には、委託元が委託先の取扱状況を合理的に把握できることを盛り込み、定期的な監査などで実施の程度を確かめるよう求めています。

配信基盤について把握しておきたいのは、配信停止リストを含めてどのデータをどこに何件持っているか、どの形式で保存しているか、保存期限をどう決めているかの三点です。委託先の範囲まで含めた事故対応の枠組みは、サイバー対処能力強化法とはやサプライチェーン攻撃とはでも扱っています。

メールアドレスの漏えいで報告対象になる事態と速報・確報の提出期限

個人情報保護委員会の案内では、報告の対象は要配慮個人情報の漏えい等、財産的被害のおそれがある個人データの漏えい等、不正の目的をもって行われたおそれがある行為による漏えい等、本人の数が1,000人を超える漏えい等（民間事業者）の四類型です。速報は発覚から3〜5日以内、確報は30日以内、不正目的の場合は60日以内とされています。

個人データに当たるメールアドレスが第三者の不正アクセスで漏れたおそれがあれば、件数が少なくても不正目的の類型に当たりえます。委託先で起きた事故でも、委託元が報告の主体になる場面がある点に注意が必要です。類型の見分け方と速報の書き方は個人情報保護委員会への報告義務で詳しく解説しています。

次の侵害に備えて自社のメール配信基盤の保存先・形式・権限を点検する順番

点検は三つの順で進めます。最初に、配信停止リストや送信履歴など、会員DBの外にあるメールアドレスの保存先と件数を洗い出します。次に確認するのは、それぞれが平文か、HMACや暗号化で守られているかという保存形式です。最後に、委託先を含めて、保存先へ届く権限と、異常な利用記録を検知する仕組みがあるかを確かめます。会員のアプリやAPI側の認可まで含めた点検手順は、セイコーマートの不正アクセスの解説が参考になります。

外部からの入口と、破られた後に何が読めるかを第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断で、Webアプリから配信基盤や会員DBまでの経路を含めて点検できます。

よくある質問

東京メトロの不正アクセスについて、利用者と開発者から出やすい質問をまとめました。

メトポ会員のどの情報が流出した可能性がありますか？

公表文によると、流出の可能性があるのはメールアドレスのみで、件数は約59,000件です。対象は、送信不能のため配信を停止していたアドレスを格納したサーバーで、このサーバーにはメールアドレス以外の会員情報は含まれていなかったと確認されています。氏名やパスワード、ポイント残高が漏れたとは公表されていません。

自分が対象かどうかはどうすれば分かりますか？

東京メトロは対象者にメールで連絡するとしています。案内はメトロポイントクラブ事務局のアドレスから届き、別途の手続きや外部サイトへの遷移は求めないと明記されています。不安な場合は、メールのリンクを使わず、公表文に記載された問い合わせフォームか電話窓口（0120-162-837・9時から17時）で確認してください。