ニトリの情報漏洩：最大3,762万件の対象確認となりすまし連絡の見分け方

ニトリホールディングスは2026年11月9日、同社が管理するシステムへの第三者の不正アクセスにより、個人情報が最大3,762万件外部に流出した可能性があると公表しました。氏名・住所・電話番号・生年月日に加え、法人会員の担当者情報やECモールの注文情報も対象です。ログインパスワードとクレジットカード情報は含まれていません。前半では公表文をもとに、自分が対象かどうか、届くおそれのある不審な連絡と窓口を整理しました。後半では、顧客データを少しずつ読み出す攻撃を3種類の検知ルールで見つけられるかをPythonで確かめます。

まとめ：ニトリの情報漏洩で確定していることと調査が続いていること

ニトリホールディングスのお知らせによると、不正アクセスが判明したのは11月6日で、同社は直ちにアクセスを遮断し、外部の専門機関と調査を始めました。その後のログ解析で、10月中旬から下旬にも第三者のアクセスがあった可能性が見つかっています。最大3,762万件は「流出した可能性」の上限です。3,762万件が持ち出されたと確定した数ではありません。

対象の人にはメールか郵送で順次連絡が届きます。利用者がいま気をつけるのは、ニトリや配送事業者、ECモールを名乗る連絡のリンクや添付を開かないことです。氏名と住所と電話番号がそろって対象になっているので、メールだけでなく電話やSMS、郵便にも注意が要ります。

利用者が確かめること：対象の範囲と不審な連絡の見分け方、相談窓口

ニトリネットとECモール公式ショップの注文者まで広がる対象範囲の読み方

対象として挙がっているのは、ニトリグループの個人会員、ニトリグループで商品を買った人、法人会員、そしてニトリネットとECモールのニトリ公式ショップで注文した人です。会員登録をしていなくても、ECモールの公式ショップで注文した人は対象に入る書き方になっています。モールの名前は公表文に出ていません。

店頭だけで買った人が含まれるのか、グループ内のどのブランドや店舗までが範囲なのかも、公表文の記述だけでは判別できません。情報の組み合わせは人ごとに異なるとされているので、表に挙げた項目のすべてが全員に当てはまるわけではありません。確実な手がかりは、会社から順次届くメールか郵便です。件数と範囲は変わる可能性があると明記されています。

住所と電話番号がそろうときの、配送事業者やECモールを装う連絡の手口

公表文は、当社や配送事業者、ECモール等を装った連絡に注意するよう呼びかけています。家具や家電は配送の日程調整があるので、「お届け日の確認」「再配達の手続き」といった連絡は疑いにくい内容です。氏名と住所を正しく書いた連絡が来ても、それだけで本物の証拠にはなりません。今回はその2つが対象項目に入っているからです。

同社は、メールや電話でパスワード、クレジットカード番号、暗証番号などを聞くことはないと説明しています。聞かれた時点で偽物と判断してください。不審な連絡には返信せず、書かれた番号にもかけず、公式サイトに載っている窓口から確かめるのが同社の案内です。メールの偽装が通る仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しました。送信元の偽装を受け取り側で弾く方法はDMARCの仕組みとレコードの書き方にまとめています。

ログインパスワードとカード情報は対象外、変更の要否とお客様相談室の受付時間

ログインパスワードとクレジットカード情報は、流出した可能性のある情報に含まれていないと明記されています。カードを止める必要はなく、公表文もパスワードの変更は求めていません。ニトリと同じメールアドレスとパスワードをほかのサービスでも使っている人は、そちらを別のパスワードに変えておくと、使い回しを狙ったログインを防げます。

問い合わせ先は、ニトリホールディングスのお客様相談室のフリーダイヤル0120-209-993です。受付は平日と土日祝の10時から20時までです。お問い合わせフォームも案内されています。

法人会員の担当者が確かめること：請求や配送の連絡を別経路で照合する手順

会社名と担当者名がそろう法人会員情報で狙われる請求書と配送の連絡

法人会員で対象になっているのは、会社名、部署名、代表者氏名、会社の住所と電話番号、担当者の氏名・メールアドレス・電話番号です。誰がどの部署で家具を発注しているかが分かると、その担当者あての請求や納品の連絡を作りやすくなります。

IPAのビジネスメール詐欺の解説は、偽のメールで従業員をだまして攻撃者の口座へ送金させる手口と説明しています。今回の項目には役職のある代表者の氏名も入っているため、取引先を装う連絡だけでなく、社長名の連絡にも警戒してください。音声の偽装まで含む手口はBECと音声クローンの検知・防御で取り上げています。

振込先の変更依頼を受けたときに社内で確認する3つの手順と記録の残し方

実務では、次の順で確かめれば足ります。

1. 振込先や請求先の変更は、届いたメールの返信ではなく、以前から控えている電話番号で相手に確かめます。
2. 確認した相手の氏名と日時を、経理の申請に書き残します。
3. 10月中旬以降に届いた変更依頼は、すでに処理した分も同じ方法で見直します。

3番目を入れるのは、10月中旬からアクセスの可能性があると公表されたためです。公表前に届いた連絡も、確認の対象から外せません。

公表文から読む事案の構造：ログで遡った期間と件数の上限、報告の期限

11月6日の判明より前、10月中旬から下旬のアクセスをログ解析で確認した意味

公表された時系列では、11月6日に判明してアクセスを遮断したあと、ログ解析で10月中旬から下旬のアクセスの可能性が見つかっています。最初のアクセスの可能性は、判明より1週間から3週間あまり前になります。この間の詳細は調査中です。

開発者が読み取るべきなのは、この順番です。遮断が先で、過去の分は後からログで見つかりました。ログが残っていたから期間をさかのぼれたとも言えますし、そのログを見ていても当時は通知が出なかったとも読めます。どちらだったかは公表されていません。検知の遅れを短くする手段は、後半のコードで試します。

最大3,762万件は調査途中の上限、人数と同じとは書かれていない数え方

公表文は件数を「最大3,762万件」とし、ログ解析とデータ照合が続いているので変わる可能性があると書いています。単位は「件」で、人数とは書かれていません。個人会員と注文データの両方に同じ人が入っていれば、1人が複数の件数に数えられている可能性もありますが、重複の有無は公表されていません。

注文データが対象に入るのは、会員基盤だけでなく注文の履歴も同じ経路で読めた可能性を示します。古い注文データをいつまで同じ場所に置くかは、対象の件数を左右する設計です。同じ論点はPFUダイレクト本店の情報漏洩と移行済みEC基盤に残る旧データでも扱いました。同じ小売の大規模な事案としては、無印良品の最大2,726万件の情報漏洩があります。

個人情報保護委員会への報告と本人通知、不正目的の確報は60日以内

個人情報保護法施行規則の第7条は、不正の目的をもって行われたおそれがある行為による漏えいを、件数にかかわらず委員会への報告の対象にしています。個人情報保護委員会の案内によると、速報は発覚日から3〜5日以内が目安で、不正の目的によるおそれがある場合の確報は60日以内です。ニトリは委員会と警察等への報告・相談を進めていると公表しています。

本人への通知は個人情報保護法の第26条第2項が求めています。公表文の「メールまたは郵送にて順次」は、この通知にあたると読める記述です。手続きの全体は個人情報保護委員会への報告義務の実務で解説しました。業績について同社は、同日の適時開示で連結業績への影響は限定的と見込むとしています。

2022年のニトリアプリ約13万2,000件は別事案、手口と対象の違い

ニトリでは2022年9月にも、ニトリアプリへの不正ログインが公表されました。当時の報道によると手口はパスワードリスト型攻撃で、約13万2,000アカウントが閲覧された可能性があるとされています。外部から入手したIDとパスワードで利用者の口座に入る攻撃でした。

今回は「当社が管理するシステム」への不正アクセスで、パスワードは対象外です。検索で2022年の記事が先に出ることがありますが、件数も手口も別の話です。

開発側の教訓：顧客データの大量読み出しを検知する3ルールをPythonで比較

原因は未公表、再発防止策のアクセス制御と権限管理と監視から点検を逆算

ここから先は、ニトリの原因を推測するものではありません。原因と侵入経路は調査中です。手がかりになるのは、同社が再発防止策として挙げた「アクセス制御、認証・権限管理、監視体制等の見直し」という項目で、顧客データを持つシステムならどこでも点検できます。

読み出しの監視については、MITRE ATT&CKのT1213が、通常は使わない利用者によるデータベースなどへの大量のアクセスを監視する分析を挙げています。OWASP Top 10:2025のA09は、ログが不審な活動について監視されていないことや、アラートの閾値が機能していないことを不備として列挙しました。ログを取るだけでは足りず、通知の条件まで決めて初めて検知になります。

固定上限・平常値との比較・閲覧人数の3ルールを架空ログで試すPython

次のコードは標準ライブラリだけで動きます。Pythonのsqlite3に架空の閲覧ログを40日分作りました。担当者5人と夜間バッチが普段どおり読むなか、攻撃者は担当者1人のアカウントで17日目から12日間少しずつ読み、39日目にまとめて3万件を読みます。平常値の計算にはstatisticsモジュールの中央値を使いました。

# 担当者アカウントでの少しずつの読み出しを、3種類の検知ルールで比べる
# （Python 3.8以上・標準ライブラリのみ・データはすべて架空）
# 使い方: python detect_bulk_read.py
import random
import sqlite3
import statistics

DAYS = 40                    # 観測する日数（0日目から39日目）
ATTACK_DAYS = range(17, 29)  # 少しずつ読み出す期間
FINAL_DAY, FINAL_ROWS = 39, 30000  # 最後にまとめて読み出す日と件数
STAFF = ["cs_01", "cs_02", "cs_03", "cs_04", "cs_05"]
ACCOUNTS = ["batch_export"] + STAFF


def simulate(attack_rows):
    db = sqlite3.connect(":memory:")
    db.execute("CREATE TABLE read_log (day INT, account TEXT, customer_id INT, by_attacker INT)")
    rnd = random.Random(1106)
    rows, next_id = [], 50001
    for day in range(DAYS):
        # 夜間バッチは毎日ほぼ同じ1.2万人分を読む
        for cid in rnd.sample(range(1, 12001), rnd.randint(11400, 12000)):
            rows.append((day, "batch_export", cid, 0))
        # 窓口の担当者は、問い合わせのあった3,000人の範囲を1日300件ほど読む
        for account in STAFF:
            rows += [(day, account, rnd.randint(1, 3000), 0) for _ in range(rnd.randint(240, 360))]
        # 攻撃者は担当者1人のアカウントで、会員番号の順に読む
        n = attack_rows if day in ATTACK_DAYS else (FINAL_ROWS if day == FINAL_DAY else 0)
        rows += [(day, "cs_03", next_id + i, 1) for i in range(n)]
        next_id += n
    db.executemany("INSERT INTO read_log VALUES (?,?,?,?)", rows)
    return db


def daily_counts(db):
    result = {account: [0] * DAYS for account in ACCOUNTS}
    for day, account, n in db.execute(
            "SELECT day, account, COUNT(*) FROM read_log GROUP BY day, account"):
        result[account][day] = n
    return result


def rule_fixed(db, limit=20000):
    # 1アカウント1日あたりの件数が固定の上限を超えたら通知する
    return [(d, a) for a, c in daily_counts(db).items() for d, n in enumerate(c) if n > limit]


def rule_baseline(db, k=6):
    # 過去14日の中央値とばらつき（MAD）から大きく外れた日を通知する
    hits = []
    for account, counts in daily_counts(db).items():
        for d in range(14, DAYS):
            past = counts[d - 14:d]
            med = statistics.median(past)
            mad = statistics.median(abs(x - med) for x in past)
            if counts[d] > med + k * max(mad, 1):
                hits.append((d, account))
    return hits


def rule_distinct(db, ratio=1.3):
    # 直近7日に読んだ顧客の人数が、その前の7日の1.3倍を超えたら通知する
    def people(account, start, end):
        return db.execute("""SELECT COUNT(DISTINCT customer_id) FROM read_log
                             WHERE account = ? AND day BETWEEN ? AND ?""",
                          (account, start, end)).fetchone()[0]
    return [(d, a) for a in ACCOUNTS for d in range(14, DAYS)
            if people(a, d - 6, d) > people(a, d - 13, d - 7) * ratio]


def leaked_until(db, day):
    # 最初の通知が出た日までに攻撃者が読んだ人数
    return db.execute("""SELECT COUNT(DISTINCT customer_id) FROM read_log
                         WHERE by_attacker = 1 AND day <= ?""", (day,)).fetchone()[0]


for label, attack_rows in [("fast 1200 rows per day", 1200), ("slow 60 rows per day", 60)]:
    db = simulate(attack_rows)
    print(f"[{label}]")
    for name, rule in [("fixed", rule_fixed), ("baseline", rule_baseline), ("distinct", rule_distinct)]:
        hits = rule(db)
        day = min(d for d, a in hits if a == "cs_03")   # 乗っ取られた担当者への最初の通知
        false_alerts = sum(1 for d, a in hits if a != "cs_03")  # 正規の利用への誤報
        print(f"  {name:9} first hit day={day} leaked={leaked_until(db, day)} false alerts={false_alerts}")

Python 3.14.10（SQLite 3.50.4・Windows）で実行した結果です。乱数のシードを固定しているので、同じ版なら同じ数字になります。

$ python detect_bulk_read.py
[fast 1200 rows per day]
  fixed     first hit day=39 leaked=44400 false alerts=0
  baseline  first hit day=17 leaked=1200 false alerts=1
  distinct  first hit day=17 leaked=1200 false alerts=0
[slow 60 rows per day]
  fixed     first hit day=39 leaked=30720 false alerts=0
  baseline  first hit day=39 leaked=30720 false alerts=1
  distinct  first hit day=23 leaked=420 false alerts=0

実行結果の読み方、少しずつ読む攻撃に固定の上限が反応しない理由

fixedは「1日2万件を超えたら通知」という固定の上限です。どちらの攻撃でも、まとめて読まれた39日目まで反応しませんでした。通知が出た時点で、攻撃者は3万人以上を読み終えています。夜間バッチを誤検知しないように上限を上げると、担当者のアカウントは上限から遠くなるからです。

baselineは、アカウントごとの過去14日の平常値と比べます。1日1,200件の攻撃は初日に見つかり、抜かれた人数は1,200人で止まりました。ただ1日60件まで薄めると、普段の日ごとのばらつきに隠れて39日目まで反応しません。正規のバッチへの誤報も1回出ています。

distinctは件数ではなく、読んだ顧客の人数を週ごとに比べるルールです。担当者は同じ客を何度も開きますが、攻撃者は会員番号の順に別人を読むので、人数だけが増えます。1日60件の攻撃でも23日目に反応し、抜かれた人数は420人でした。固定の上限の30,720人と比べて約73分の1です。実運用では、まずdistinctとbaselineを担当者アカウントに入れ、セールや月末の集計で増える日は除外の条件を足します。なお架空データの設定で数字は変わるので、この比率そのものを自社の見込みに使わないでください。

本番のログへ持ち込むときの記録項目と、個人情報を残さない書き方

OWASP Logging Cheat Sheetは、機密データへのアクセス、データのインポートとエクスポート、管理者権限の使用、認可の失敗を記録の対象に挙げています。このルールに要るのは、日時、アカウント、対象の顧客ID、操作の種類、取得件数の5項目です。氏名や電話番号、メールアドレスは同シートでも特別な扱いが要るデータとされているので、ログには顧客IDだけを書きます。

顧客IDを1件ずつ残すと量が増えるので、読み出しAPIとデータベースの監査ログのどちらで取るかを先に決めてください。欠損や改ざんを防ぐ転送と保管はFluentdで作る監査ログ基盤で、大量ダウンロードを監査ログから調べる手順はサントリーの不正アクセスとM365の監査ログ調査で扱っています。読み出しのAPI側で呼び出しを絞る手順はAPI不正アクセス対策の実装手順にまとめました。

事業者の判断：顧客データの読み出し経路を外部診断で優先する条件と見送れる条件

次のどれかに当てはまるなら、管理画面と読み出しAPIを外部の脆弱性診断で優先して見てもらってください。担当者のアカウントで顧客の検索と一覧の出力が件数の上限なしにできること。退職者や委託先のアカウントの棚卸しが年に1回もないこと。顧客データの読み出しログはあるものの、誰も通知の条件を決めていないことです。

どれにも当てはまらず、権限の棚卸しと読み出しの通知を実際に運用していて、発火した通知の記録も残っているなら、年1回の定期診断で足ります。毎月の診断まで増やすのは、この状態では過剰です。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準で解説しました。

自社の管理画面やAPIに同じ弱点が残っていないかを第三者に確かめてもらいたいなら、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

ニトリの情報漏洩について、利用者から出やすい質問をまとめました。

自分が対象かどうかはどうやって確認できますか？

対象の人には、メールまたは郵送で順次連絡が届くと公表されています。ニトリネットや会員アプリの画面で確認できるとは、11月9日の公表文に書かれていません。連絡を待てない場合は、お客様相談室の0120-209-993に電話してください。受付は平日と土日祝の10時から20時までです。届いたメールのリンクからは手続きをせず、公式サイトから窓口を開いてください。

クレジットカードを止めたりパスワードを変えたりする必要はありますか？

クレジットカード情報とログインパスワードは対象に含まれないと公表されているので、カードを止める必要はありません。公表文はパスワードの変更も求めていません。同じメールアドレスとパスワードをほかのサービスで使い回している場合だけ、そちらのパスワードを別のものに変えておくと、使い回しを狙ったログインを防げます。

ニトリや配送業者を名乗る連絡が本物か見分ける方法はありますか？

氏名や住所が正しくても、本物とは限りません。今回はそれらが対象の項目に入っているからです。同社はメールや電話でパスワード、カード番号、暗証番号を聞くことはないと説明しているので、聞かれたら偽物です。不審な連絡には返信せず、書かれた番号にもかけず、公式サイトに載っている窓口から確かめてください。配送の連絡は、配送事業者の公式アプリや公式サイトを自分で開いて確認できます。

補償やお詫びのポイントはもらえますか？

11月9日の公表文には、補償やお詫びのポイント、クーポンについての記載はありません。同社は新たに公表すべき事項が判明した場合は速やかに知らせるとしています。「お詫びのクーポン」や「補償金の受け取り」をうたうメールやSMSが届いても、リンクは開かず、ニトリの公式サイトの重要なお知らせに同じ内容が載っているかを先に確かめてください。

原因や侵入経路はもう分かっていますか？

公表されていません。同社は外部の専門機関と連携し、原因、侵入経路、影響範囲、二次被害の有無を調査していると説明しています。攻撃者のアクセスは遮断を続けていて、脆弱な箇所への対応と監視体制の強化は完了したとしています。ただし、どのシステムのどの部分だったのかは、11月10日時点で追加の発表が確認できません。

関連記事

• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：読み出しAPIの入口を固める手順
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：不正目的の漏えいで求められる報告と本人通知の手順
• 無印良品の情報漏洩：リスト型攻撃で再開延期、ログインできない理由と2,726万件の対象確認：同じ小売の大規模事案
• PFUダイレクト本店の情報漏洩：第2報で漏えい対象データ78,873件。対象期間・確認先と移行済みEC基盤に残る旧データ：注文データの残し方を見直す事案
• フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：流出した連絡先に届く偽の連絡が通る仕組み