2026年10月4日、nimocaの利用履歴照会サービスが第三者の不正アクセスを受け、カード番号・生年月日・登録メールアドレスの521件が漏えいしました。身に覚えのないメールを受け取って検索した人に向けて、そのメールが本物か、パスワードを変える必要があるか、どこに問い合わせればよいかを株式会社ニモカの公表文言で先に答えます。後半では、会員番号と生年月日で本人確認する照会・通知機能を持つ事業者向けに、番号単位の試行上限と送信メール数の監視をPythonで実装する例を示します。
まとめ：nimoca不正アクセスで公表された事実と利用者・事業者が取る行動
届いたメールは、利用履歴照会サービスが自動で送った本物の通知です。ニモカは利用履歴照会サービスのパスワードは漏えいしておらず、変更は不要としています。漏えいしたのはカード番号、生年月日、登録メールアドレスの3項目で、氏名・住所・電話番号・利用履歴の漏えいは確認されていません。nimocaカードはそのまま使えます。
警戒すべきは、今後届くニモカを装った偽のメールです。漏れた3項目がそろっていると、本物らしい文面を作れます。メール内のURLは開かず、問い合わせはnimocaコールセンター（050-3616-2155、8時〜20時、年中無休）へ。
照会機能を運営する側にとっての教訓は2つあります。印字された番号と生年月日だけで動く機能は、試行回数を番号単位で絞らないと推測に弱いこと。もう1つは、自動送信メールの数を見ていれば、利用者の問い合わせより早く異常に気づけることです。
利用者が最初に確かめる4点｜届いたメール・漏えいの範囲・パスワード・窓口
届いたメールの判別基準と利用履歴照会サービスが自動送信した本物の通知
10月15日の再開のお知らせは、一部の利用者に届いたメールについて「当システムから自動的にお客さまへ送信されたもので、第三者から送信されたものではございません」と説明しています。10月4日の0時頃から17時40分までの間に、登録しているアドレスへ登録情報の一部を含むメールが届いた人は、この事案の対象と考えてよいでしょう。
メールが登録先に届いているのに、第三者が何をどう得たのかは公表資料から読み取れません。ニモカはこの事象を情報漏えいと位置づけ、件数を521件としています。
漏えいはカード番号・生年月日・登録メールアドレスの3項目で521件
10月6日のニモカの公表資料によると、漏えいした情報は次の3つです。カード番号は、カード裏面に記載されたNRで始まる17桁の英数字を指します。
- 交通系ICカード「nimoca」のカード番号
- 生年月日
- 利用履歴照会サービスに登録したメールアドレス
氏名、住所、電話番号、性別、利用履歴の漏えいは確認できていないとされています。利用履歴照会サービスを使えるのはスターnimocaとクレジットnimocaの登録者だけなので、登録していない無記名のnimocaは対象外です。
パスワード変更は不要と公表され変更には登録の削除と再登録が必要
ニモカは、利用履歴照会サービスのパスワードが漏えいした事実はなく、変更の必要はないと明言しています。それでも変えたい場合は、コールセンターに連絡して登録情報を削除してもらい、改めて新規登録する手順になります。画面上でパスワードだけを変える手段は案内されていません。
同じパスワードを他のサービスでも使っている人は、そちらを変えておくと安心です。理由と手順はパスワード管理のベストプラクティスで整理しています。登録メールアドレスは、ログイン画面の「メールアドレスを変更される方」からカード番号・パスワード・新アドレスの入力で変えられます。
ニモカを装う偽メールの見分け方と不審な場合のコールセンターへの連絡
10月15日時点で、二次被害は確認されていません。ただ、カード番号と生年月日を本文に引用した偽メールは、本物との見分けが難しくなります。ニモカの案内は、メール内のURLへアクセスしない、個人情報や認証情報を入力しない、添付ファイルを開かない、の3点です。
見分けるときは、文面ではなく行動で判断してください。ニモカの公表資料には、パスワードの入力やカード情報の再登録をメールで求めるという記述はありません。判断に迷うメールはフィッシング対策協議会の事例と照らし、本物かどうかはコールセンターで確かめます。
公式発表3本で追う時系列｜10月4日0時頃の発生から15日の再開まで
不正アクセスの発生・検知・停止・公表・再開の日時と公表文書の対応表
ニモカが出した文書は3本です。10月4日のお知らせ、6日の公表資料、15日の再開のお知らせを突き合わせると、次の流れになります。
| 日時 | 出来事 | 出典 |
|---|---|---|
| 10月4日 0時頃 | 不正アクセスが始まる | 10月6日の公表資料 |
| 10月4日 9時頃 | 利用者から身に覚えのないメールの問い合わせ | 10月6日の公表資料 |
| 10月4日 17時40分 | 新規登録を含む全機能を停止 | 10月4日・6日の発表 |
| 10月6日 | 521件の漏えいを公表 | 10月6日の公表資料 |
| 10月15日 | 再発防止策を終えてサービスを再開 | 10月15日のお知らせ |
検知のきっかけは利用者からの問い合わせで、発生から約9時間後です。停止はそこから約8時間40分後でした。再開日を10月19日とする二次情報がありますが、ニモカのお知らせの日付は15日です。
手口は非公表で「自動プログラムによる不正アクセス」への対策だけが判明
公表資料は原因を「利用者の所定の入力に応じ、当該サービスから自動で送信される」メールの仕組みへの攻撃と説明しています。どの画面が使われたのか、入力値をどう得たのかは書かれていません。総当たりやリスト型攻撃と断定する根拠はないのです。
手がかりは15日の再開告知にあります。再発防止策として挙がっているのは「自動プログラムによる不正アクセスへの対策、プログラム改修等」でした。大量の入力をプログラムで送り込まれたことへの対策と読めます。他のシステムやデータベースへの不正アクセスは確認されていないとされています。
番号と生年月日で本人確認する照会・通知機能が抱える構造上の弱さ
カード裏面に印字された17桁の番号と最大36,525通りの生年月日
10月23日に確認した履歴照会サービスのログイン画面には、「パスワードを忘れた方」としてカード番号と生年月日を入れると、登録時のアドレスへメールが送られる欄があります。今回の攻撃にこの欄が使われたかは公表されていません。ここでは、同じ型の機能が一般に抱える弱さとして見ます。
カード番号は秘密情報ではありません。カード裏面に印字され、新規登録の案内でも本人確認書類として裏面のコピーを出す手順になっています。生年月日の候補は、0歳から100歳までなら36,525通りにすぎません。番号が分かっていれば、残りは数万回の試行で埋まる計算です。
OWASPのForgot Password Cheat Sheetは、秘密の質問の答えは推測・入手されやすいため、パスワード再設定の唯一の手段にしてはならないとしています。生年月日も同じ性質の情報です。
ログイン前の自動送信メールに登録情報を載せない設計と送信先の固定
今回漏えいした3項目は、どれも自動送信メールの本文に含まれていた登録情報です。通知メールに載せる情報は、受け取った本人が次の操作に必要な最小限で足ります。カード番号は下4桁、生年月日は載せない、と決めておけば、メールがどこかで読まれても被害は小さく収まります。
同じCheat Sheetは、パスワード自体をメールで送らないこと、再設定はHTTPSの一回限りのURLで行うことも求めています。再設定の仕組みをクラウドの認証サービスで組む場合の流れはCognitoのパスワードリセット実装で扱いました。
照会・再送信フォームのBot対策｜番号単位の試行上限をPythonで実装
送信元IPを250個に分散させても番号単位の上限で5回に絞る実装
送信元IPごとの上限だけでは、IPを分散させた攻撃を止められません。上限の鍵をカード番号にも置き、両方を満たしたときだけ照合へ進めます。次の例は、15分間に同じ番号で5回、同じIPで30回を上限にしたものです。履歴の保持にはPythonのcollections.dequeを使っています。
from collections import defaultdict, deque
from datetime import date
import time
WINDOW = 900 # 15分
PER_CARD = 5 # カード番号ごとの上限
PER_IP = 30 # 送信元IPごとの上限
hits = defaultdict(deque)
def allow(key, limit, now):
q = hits[key]
while q and now - q[0] > WINDOW:
q.popleft()
if len(q) >= limit:
return False
q.append(now)
return True
def send_notice(card_no, birth, ip, now, db):
ok = allow("card:" + card_no, PER_CARD, now) and allow("ip:" + ip, PER_IP, now)
if ok and db.get(card_no) == birth:
pass # ここで登録先へメールを送る（本文に登録情報を載せない）
# 一致・不一致・上限超過のどれでも同じ文言を返す
return "登録がある場合は、登録先のメールアドレスにご案内を送りました"
days = (date(2026, 10, 23) - date(1926, 10, 23)).days
db = {"NR000000000000001": "1990-04-01"}
now = time.time()
for i in range(1000):
ip = "198.51.100." + str(i % 250)
send_notice("NR000000000000001", "1990-01-01", ip, now + i, db)
print("生年月日の候補数:", days)
print("1000回のうち番号キーで通った回数:", len(hits["card:NR000000000000001"]))
print("1日に試せる回数:", PER_CARD * 86400 // WINDOW)
print("候補の半分に届く日数:", days // 2 // (PER_CARD * 86400 // WINDOW))Python 3.14.7で、架空のカード番号に対して実行した結果です。
生年月日の候補数: 36525
1000回のうち番号キーで通った回数: 5
1日に試せる回数: 480
候補の半分に届く日数: 38250個のIPから1,000回送っても、照合まで進むのは5回だけです。1日480回に絞られるので、候補の半分を試すのに必要な期間は38日です。上限なしで毎秒10回送れる状態なら、同じ量を約30分でこなせます。複数台のサーバーで動かすときは、カウンタをRedisなどの共有ストアに置きます。方式の選び方はAPIレート制限の5方式比較を参照してください。
NIST SP 800-63B-4の100回上限とOWASPの応答統一を設計へ落とす
NIST SP 800-63B-4の3.2.2は、同じ認証器での連続失敗を100回以下に制限することを求め、より低い上限も認めています。生年月日のように候補が少ない情報なら、100回では緩すぎます。上の例の15分5回は、この差を埋めるための値です。
応答の文言と処理時間をそろえることも、同じCheat Sheetが求めています。一致したときだけ「送信しました」と返すと、画面が正解を教えてしまうからです。登録の有無で応答が変わる画面の直し方は、スタディサプリの事案で解説したアカウント列挙対策にまとめています。
CAPTCHAとWAFのBot判定を足す順番と正規の利用者を締め出さない工夫
番号単位の上限には副作用があります。攻撃者が試すたびに、正規の利用者もその番号で15分間照会できなくなるのです。上限に達した番号では即座に拒否せず、CAPTCHAを挟んで人なら通す作りにすると、締め出しを減らせます。導入手順はCloudflare Turnstileの設定方法にあります。
順番は、番号単位の上限、応答の統一、CAPTCHA、WAFのBot判定です。OWASP Automated Threats to Web Applicationsの分類でいう自動化攻撃は、アプリの中で数える上限が最も確実に効きます。WAFだけに頼ると、正規のブラウザを装う攻撃を見逃します。
自動送信メールの急増で気づく監視｜問い合わせより先に検知する方法
1時間ごとの送信数を過去7日の同じ時間帯の中央値と比べる監視
今回は利用者の問い合わせで発覚するまで約9時間かかりました。照会機能が送るメールの数を1時間ごとに数えていれば、1時間目で異常に気づけた可能性があります。次の例は、架空の送信ログで過去7日の同じ時間帯の中央値と比べ、5倍以上かつ10通以上で警報を出します。
import random
from collections import Counter
from statistics import median
random.seed(7)
# 架空の送信ログ：過去7日は1時間0〜4通、当日は0時から1時間25〜35通が上乗せ
log = []
for d in range(7):
for h in range(24):
log += [(d, h)] * random.randint(0, 4)
for h in range(18):
log += [(7, h)] * (random.randint(0, 4) + random.randint(25, 35))
per_hour = Counter(log)
def baseline(h):
return median(per_hour.get((d, h), 0) for d in range(7))
for h in range(4):
n = per_hour.get((7, h), 0)
base = baseline(h)
alert = n >= max(10, base * 5)
print(f"{h:02d}時 送信{n:3d}通 平常{base:4.1f}通", "ALERT" if alert else "")00時 送信 32通 平常 2.0通 ALERT
01時 送信 28通 平常 2.0通 ALERT
02時 送信 27通 平常 3.0通 ALERT
03時 送信 33通 平常 2.0通 ALERT当日の数字は、521通がおよそ17時間に分かれたと仮定した値です。実際の時間ごとの分布は公表されていません。
送信数の急増を検知する警報の閾値と通知先の判断基準および誤報の扱い
平常時の送信数が1時間数通の機能なら、「中央値の5倍かつ10通以上」で誤報はほとんど出ません。キャンペーンやカード更新の時期は平常値そのものが上がるので、その週だけ閾値を手で上げます。警報の宛先は、夜間でも受け取れる当番の連絡手段にしてください。今回の発生は日曜の0時頃でした。
警報が鳴ったら、まず照会機能だけを止めます。カード利用や他の機能まで止める必要はありません。止めた後のログの確かめ方はAPI不正アクセス対策の実装手順で扱っています。
照会機能を止めて作り直すべき事業者と試行上限の追加で足りる事業者
番号と生年月日だけで登録情報入りのメールを送る機能を持つ事業者
会員番号や電話番号と生年月日だけで動き、本文に登録情報を載せたメールを送る機能があるなら、試行上限の追加では足りません。いったん止めて、メール本文から登録情報を外し、パスワード再設定を一回限りのURL方式に作り直してください。番号が券面や書類に載る業種では、番号を知られている前提で設計し直すしかありません。
漏えいのおそれが不正アクセスによるものなら、件数にかかわらず個人情報保護委員会への報告対象です。速報はおおむね3〜5日以内、不正目的のおそれがある事案の確報は60日以内です。段取りは個人情報保護委員会への報告義務、様式は個人情報保護委員会の「漏えい等の対応とお役立ち資料」にあります。自社の照会・通知機能に同じ弱点がないかを第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、公開画面の入力欄ごとに推測や大量送信への耐性を点検できます。
個人情報をログイン後の画面にだけ出しパスワードで守っている事業者
照会結果をログイン後の画面にだけ表示し、再設定も一回限りのURLで行っているなら、作り直しは過剰です。番号単位の試行上限と送信数の監視を足せば十分です。ログイン画面そのものへの大量試行には、パスワードリスト攻撃の検知と対策の指標がそのまま使えます。
見落としやすいのは、ログイン前に動く小さな機能です。メールアドレス変更、カード再発行後の再登録、問い合わせフォームの自動返信も、入力に応じてメールを送ります。どの画面が外部からの入力でメールを送るかを一覧にしてから、上限の置き場所を決めてください。
よくある質問
nimocaの不正アクセスについて、利用者と照会機能を運営する担当者から出やすい質問をまとめました。
nimocaから届いたメールは詐欺ですか？
10月4日に利用履歴照会サービスから届いたメールは、ニモカのシステムが自動で送った本物で、第三者が送ったものではないと公表されています。ただし、これから届くメールの中にニモカを装った偽物が混ざる可能性はあります。メール内のURLは開かず、カード番号やパスワードの入力を求められても応じないでください。気になる場合はnimocaコールセンター（050-3616-2155）で確かめます。
自分の情報が521件に含まれているか確かめる方法はありますか？
10月4日の0時頃から17時40分までに、身に覚えのない利用履歴照会サービスのメールを受け取った人が対象と考えられます。公表資料には、対象者への個別通知についての記載はありません。メールを削除してしまい確かめられない場合は、コールセンターに問い合わせてください。利用履歴照会サービスに登録していない無記名のnimocaは対象外です。
nimocaカードはこのまま使い続けて大丈夫ですか？
使い続けられます。ニモカは、カードの利用にはカードそのものが必要で、他のシステムやデータベースへの不正アクセスは確認されていないとしています。漏えいしたのはカード番号・生年月日・メールアドレスで、電子マネーの残高やチャージに関わる情報は含まれていません。カード番号だけでは電車やバスに乗ることも買い物もできません。
利用履歴照会サービスはいつ再開しましたか？
ニモカのお知らせでは、2026年10月15日に再開しています。10月19日とする二次情報がありますが、公式の日付は15日です。再開にあたって、自動プログラムによる不正アクセスへの対策とプログラムの改修を実施したと説明されています。ログインはこれまでと同じカード番号とパスワードで行えます。
番号と生年月日で照会できる機能を自社で持っている場合、最初に何をすべきですか？
ログイン前に外部からの入力でメールを送る画面をすべて書き出し、それぞれのメール本文に何が載るかを確かめます。登録情報が載っている場合に必要なのは、本文からの除外と番号単位の試行上限の設定です。並行して、送信メール数を1時間ごとに数えて平常値と比べる監視を足すと、同じ型の攻撃を数時間早く見つけられます。
関連記事
- スタディサプリの不正アクセスとメールアドレス3,687件｜アカウント列挙を防ぐ実装：登録の有無で応答が変わる画面の直し方
- パスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装：ログイン画面への大量試行の見分け方
- APIレート制限（レートリミット）とは？5方式の比較と429設計・分散実装【2026年版】：試行上限のアルゴリズムと共有カウンタ
- ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検：会員APIが返す項目の点検
- 情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】：情報漏洩を原因別に防ぐ全体像
