無印良品を展開する良品計画は2026年10月30日、公式アプリ「MUJIアプリ」で外部からの不正なアクセスを検知し、メールアドレス・生年月日・性別が最大約2,726万件流出した可能性があると公表しました。対象には退会した人の情報も含まれます。氏名・住所・電話番号・クレジットカード情報は含まれていません。前半では公表文をもとに、自分が対象かどうか、届くおそれのあるなりすましメールと窓口を整理しました。後半では、会員アプリのAPIに認可の漏れがあったとき、退会者のデータの残し方で抜ける件数がどう変わるかをPythonで確かめます。
まとめ：MUJIアプリの情報漏洩で利用者に起きたことと起きていないこと
良品計画のニュースリリースによると、同社はMUJIアプリへの不正なアクセスを検知し、該当箇所へのアクセスを遮断して修正を適用しました。流出の可能性がある項目は3つで、件数は退会者を含めて最大約2,726万件です。これは「おそれ」の上限で、2,726万件が実際に持ち出されたと確定した数ではありません。
ダークウェブ等への流出と、情報を悪用した被害は確認されていないとしています。MUJIアプリと無印良品ネットストアは今も普通に使えます。利用者が今すぐ気をつけるべきなのは、無印良品を名乗るメールのリンクを開かないことです。
| 項目 | 公表内容（2026年10月30日時点） |
|---|---|
| 対象 | MUJIアプリの会員情報の一部 |
| 件数 | 最大約2,726万件（退会者を含む） |
| 項目 | メールアドレス・生年月日・性別 |
| 含まれない | カード情報・氏名・住所・電話番号等 |
| 対応 | アクセスの遮断と修正の適用 |
| 悪用被害 | 確認されず |
| 知らせ方 | 対象者へ順次連絡 |
| 未公表 | 検知日・侵入経路・原因 |
利用者が確かめること：退会者を含む対象範囲となりすましメールの見分け方
退会済みでも対象になる最大約2,726万件の範囲と含まれない4項目
対象はMUJIアプリに登録したことのある人で、すでに退会した人も含まれます。アプリを消して何年もたつ人も、退会の手続きをした人も、対象から外れているとは言えません。一方で、アプリを使わず店頭で買い物をしただけの人や、アプリに登録していない人は、公表文の書き方では対象に入りません。
含まれないと明記されたのは、クレジットカード情報・氏名・住所・電話番号です。メールアドレスと生年月日だけでは、カードの不正利用や郵便物・電話による詐欺にはつながりにくいと言えます。自分が対象かどうかを確認する手がかりは、会社から順次届く連絡です。ただし、その連絡を装った偽のメールが混ざる点は次の項で扱います。
メールアドレスと生年月日をそろえて送られる、なりすましメールの型
公表文は、流出した情報を悪用したなりすましメールが届く可能性があるとして、記載されたURLを開いたり個人情報を入力したりしないよう呼びかけています。危ないのは、本物の会員しか知らないはずの生年月日を本文に入れたメールです。「〇月〇日生まれのお客さまへ、誕生日特典のポイント」「情報流出のお詫びとして500円分のクーポン」といった文面だと、本物だと思いやすくなります。
会社からの連絡かどうかは、メールのリンクからではなく、自分でアプリを開くか、公式サイトをブックマークや検索から開いて確かめてください。偽のメールが通る仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しています。送信元の偽装を受け取り側で弾く仕組みはDMARCの仕組みとレコードの書き方にまとめました。
パスワードは3項目に入っていない、変更の要否とお客様相談室の窓口
流出の可能性がある項目として挙がっているのは3つで、パスワードは挙がっていません。公表文もパスワードの変更は求めていません。ただし、MUJIアプリと同じメールアドレスとパスワードをほかのサービスでも使い回しているなら、そちらのパスワードは別のものに変えておくと安心です。メールアドレスが分かると、使い回しを狙ったログインの試行の対象にされやすくなるからです。
問い合わせ先は、良品計画のお客様相談室のフリーダイヤル0120-64-0772です。受付は月曜から土曜の9時30分から17時までで、日曜と年末年始は休みです。メールに書かれた別の番号には電話せず、公表文に載っているこの番号を使ってください。
公表文から読む事案の構造：退会者を含む件数と報告義務、過去の障害との違い
2,726万件に退会者が含まれる意味と、会員基盤に退会者が残る仕組み
件数に退会者が含まれるのは、退会の手続きをしても、会員基盤のデータベースから行が消えていなかったことを意味します。退会を受け付けたときに「ログインできない状態」にするだけで、メールアドレスや生年月日は残しておく作りは珍しくありません。再登録の重複を見分けたり、問い合わせに答えたりするためです。
ただ、その残し方だと、読まれたときの件数は「いま使っている会員」ではなく「これまでに登録した全員」になります。2,726万件という数字の大きさは、この累積を映しています。退会者と現役の内訳は公表されていません。同じ論点は、任意項目と退会者データを減らす観点で大起水産の不正アクセスの点検でも扱いました。
不正な目的の漏えいは件数を問わず報告の対象、施行規則7条と本人通知
個人情報保護法施行規則の第7条は、不正の目的をもって行われたおそれがある行為による漏えいを、件数にかかわらず委員会への報告の対象にしています。外部からの不正なアクセスはこれにあたり、1,000人を超える漏えいとしても報告の対象です。第8条により、知った後に速やかに速報を出し、この類型では60日以内に確報を出します。
本人への通知は、個人情報保護法の第26条第2項が求めています。公表文の「順次ご連絡」は、この通知にあたると読める記述です。退会者のメールアドレスが今も届くとは限らないので、届かない人には今回の公表が代わりの措置になります。手続きの全体は個人情報保護委員会への報告義務の実務で解説しました。委員会の案内は漏えい等の対応とお役立ち資料にまとまっています。
2025年10月のネットストア停止とは別の事案、ローソン・バーガーキングとの比較
無印良品では2025年10月にも、ネットストアの受注と出荷が止まりました。これは配送業務を委託していたアスクルのグループ会社がランサムウェアの被害を受けた影響で、経緯はアスクルのランサムウェア攻撃の経緯で追っています。今回はMUJIアプリそのものへの不正なアクセスで、委託先の被害とは別の出来事です。
2026年10月には、会員アプリの事案が続いています。ローソンIDの不正アクセスは215万件、バーガーキングの情報漏洩は約1,118万件でした。無印良品の件は項目が3つと少ない一方、件数は桁が1つ大きい事案です。同じ10月には、飲食チェーンでも公式アプリの管理システムへの不正アクセスで利用者2,377,127件の情報が漏えいしています（松屋の不正アクセス：237万件の対象確認と窓口、漏れたパスワードの守り方）。
開発側の教訓：会員APIの認可漏れと退会者データの最小化をPythonで確認
原因は未公表、IDを変えるだけで他人の情報が返る認可漏れから疑う
ここから先は、MUJIアプリの原因を推測するものではありません。原因は公表されていないので、会員アプリ全般の話として書きます。メールアドレスと生年月日と性別という、会員のプロフィール画面に出る項目だけが大量に取られた形は、プロフィールを返すAPIの認可漏れでよく起きます。
OWASPはAPI1:2023 Broken Object Level Authorizationとして、リクエストに含まれるオブジェクトのIDについて、利用者がそれに触れてよいかを確かめない不備を1番目のリスクに挙げています。ログインできる正規のアカウントを1つ持っていれば、IDの数字を1つずつ変えて送るだけで他人の情報が返る状態です。短時間に大量の呼び出しを許す不備はAPI4:2023 Unrestricted Resource Consumptionにあたり、2つが重なると全件が抜ける状態です。10項目の全体はOWASP API Security Top 10 2023の全10項目で解説しています。
連番IDの会員API・呼び出し上限・退会者のハッシュ化を再現するPython
次のコードは標準ライブラリだけで動きます。Pythonのsqlite3で架空の会員2,000件を作り、45%前後を退会済みにしました。攻撃者が自分の正規アカウント1つで会員IDを1から順に送ったとき、他人の平文のメールアドレスが何件取れるかを、APIの修正前後と、退会者のデータを置き換えた後で数えています。
# 会員APIの認可漏れ（BOLA）と退会者データの残し方で、1つの正規アカウントから
# 抜ける件数がどう変わるかを比べる（Python 3.8以上・標準ライブラリのみ）
# 使い方: python member_api.py
import hashlib
import hmac
import random
import sqlite3
rnd = random.Random(1030)
PEPPER = b"kms-managed-secret" # 実運用では鍵管理サービスから取得し、DBと同じ場所に置かない
db = sqlite3.connect(":memory:")
db.execute("""CREATE TABLE member (id INTEGER PRIMARY KEY, email TEXT, birth TEXT,
gender TEXT, withdrawn INTEGER)""")
for i in range(1, 2001): # 連番IDの会員2,000件。45%前後が退会済みという想定
db.execute("INSERT INTO member VALUES (?,?,?,?,?)",
(i, f"user{i}.example", f"{rnd.randint(1950, 2008)}-01-01",
rnd.choice("FMN"), int(rnd.random() < 0.45)))
def get_profile_vulnerable(session_id, member_id):
# 認証済みかだけを見て、要求されたIDが本人のものかを確かめない
return db.execute("SELECT email, birth, gender FROM member WHERE id = ?",
(member_id,)).fetchone()
calls = {}
def get_profile_fixed(session_id, member_id, limit=60):
calls[session_id] = calls.get(session_id, 0) + 1
if calls[session_id] > limit: # 1セッションあたりの呼び出し上限（429相当）
return None
if member_id != session_id: # 本人以外のIDは403相当で返さない
return None
return db.execute("SELECT email, birth, gender FROM member WHERE id = ? AND withdrawn = 0",
(member_id,)).fetchone()
def harvest(handler, attacker_id=777):
# 攻撃者は自分の正規アカウント1つで、IDを1から順に送るだけ
# 数えるのは、他人の平文メールアドレスが取れた件数（鍵付きハッシュに置き換えた行は数えない）
got = [handler(attacker_id, i) for i in range(1, 2001) if i != attacker_id]
return sum(1 for r in got if r and not r[0].startswith("h:"))
withdrawn = db.execute("SELECT COUNT(*) FROM member WHERE withdrawn = 1").fetchone()[0]
print("[members] total 2000 / withdrawn", withdrawn)
print("[vulnerable] harvested:", harvest(get_profile_vulnerable))
print("[fixed] harvested:", harvest(get_profile_fixed))
# 退会者は再登録の照合に使う鍵付きハッシュだけを残し、生年月日・性別は消す
for mid, email in db.execute("SELECT id, email FROM member WHERE withdrawn = 1").fetchall():
h = hmac.new(PEPPER, email.encode(), hashlib.sha256).hexdigest()[:16]
db.execute("UPDATE member SET email = ?, birth = NULL, gender = NULL WHERE id = ?",
("h:" + h, mid))
print("[minimized] harvested via vulnerable API:", harvest(get_profile_vulnerable))Python 3.14.7（SQLite 3.50.4・Windows）で実行した結果です。乱数のシードを固定しているので、同じ版なら同じ数字になります。
$ python member_api.py
[members] total 2000 / withdrawn 892
[vulnerable] harvested: 1999
[fixed] harvested: 0
[minimized] harvested via vulnerable API: 1107実行結果の読み方、1,999件が抜けるAPIは本人確認の1行で0件になる
2行目は、認可の漏れがあるAPIです。攻撃者は自分以外の1,999件すべてのメールアドレスと生年月日と性別を取れました。このうち892件は退会者で、もう使われていない会員の情報まで一緒に出ていきます。
3行目は、要求されたIDが本人のものかを確かめる1行と、1セッションあたりの呼び出し上限を入れた版で、他人の情報は1件も返りません。4行目は、APIの漏れは残したまま、退会者の行だけを置き換えた状態です。取れる件数は現役の1,107件に下がりました。認可の修正が本筋で、退会者の置き換えは修正が漏れたときに被害を小さくする二段目の守りです。入口のレート制限やトークン失効まで含めた手順はAPI不正アクセス対策の実装手順で扱っています。
使わない個人データを消す努力義務と、再登録の照合に残す鍵付きハッシュ
個人情報保護法の第22条は、利用する必要がなくなった個人データを遅滞なく消すよう努めることを求めています。退会者の生年月日や性別は、退会した時点で使い道がほぼ無くなります。残す理由として多いのは、同じメールアドレスでの再登録を見分けることと、退会後の問い合わせへの対応です。
再登録の照合だけなら、メールアドレスそのものは要りません。Pythonのhmacで鍵付きハッシュにすれば、同じアドレスかどうかは照合でき、ハッシュから元のアドレスには戻せません。鍵をデータベースと同じサーバーに置くと、両方を読まれたときに総当たりで戻される余地が残るので、鍵は別の鍵管理サービスに置いてください。問い合わせ対応の期間を社内で決め、それを過ぎた退会者は行ごと消すのが次の段階です。
事業者の判断：会員アプリを外部診断で優先して見るべき条件と見送れる条件
会員アプリは、画面の見た目は診断しても、アプリが裏で呼ぶAPIは診断の範囲から外れていることがあります。ブラウザのWebサイトと違い、通信の中身が利用者の目に触れないため、IDを書き換えたリクエストを誰も試していないまま公開されている例があるということです。
次のどれかに当てはまるなら、会員アプリのAPIを外部の脆弱性診断で優先して見てもらってください。プロフィールや注文履歴のAPIが、会員IDをURLやリクエストの中にそのまま受け取ること。会員IDが連番で、1つのアカウントからの呼び出し回数に上限が無いこと。退会者のメールアドレスや生年月日が、現役の会員と同じテーブルに平文で残っていることです。どれにも当てはまらず、APIの認可を自動テストで毎回確かめているなら、年1回の定期診断で足ります。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準で解説しています。
自社の会員アプリやAPIに同じ弱点が残っていないかを第三者に確かめてもらいたいなら、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
MUJIアプリの情報漏洩について、利用者から出やすい質問をまとめました。
MUJIアプリを退会していても対象になりますか？
対象になる可能性があります。良品計画の公表文は、最大約2,726万件の対象に退会したお客さまの情報を含むという内容です。退会の手続きをしても、メールアドレスや生年月日が会社のデータベースに残っていた場合は、流出の可能性がある範囲に含まれるということです。対象かどうかは会社から順次届く連絡で分かりますが、退会時のメールアドレスを今は使っていない人には届かないこともあります。
クレジットカードを止めたりパスワードを変えたりする必要はありますか？
クレジットカード情報は含まれないと公表されているので、カードを止める必要はありません。パスワードも流出の可能性がある項目には挙がっておらず、公表文は変更を求めていません。同じメールアドレスとパスワードをほかのサービスで使い回している場合だけ、そちらのパスワードを別のものに変えておくと、使い回しを狙ったログインを防げます。
無印良品から届いたメールが本物か見分ける方法はありますか？
メールの見た目だけで見分けるのは難しいので、メール内のリンクは開かないのが基本です。生年月日や誕生日特典に触れていても、本物とは限りません。今回流出の可能性がある項目に生年月日が入っているからです。内容を確かめたいときは、自分でMUJIアプリを開くか、お客様相談室のフリーダイヤル0120-64-0772に電話してください。
補償やお詫びのポイントはもらえますか？
10月30日の公表文には、補償やお詫びのポイント・クーポンについての記載はありません。外部への流出が確認された場合は速やかに知らせるとしています。「お詫びのクーポン」をうたうメールやSMSが届いても、リンクは開かず、良品計画の公式サイトのニュースリリースに同じ内容が載っているかを先に確かめてください。
原因や不正アクセスの経路はもう分かっていますか？
公表されていません。公表文は、外部からの不正なアクセスを検知し、該当箇所へのアクセスの遮断と修正の適用を行ったという事実だけを書いています。いつ検知したのか、アプリのどの機能が狙われたのかは、10月31日時点で追加の発表がありません。同社は開発会社・関係会社の協力のもと、セキュリティ対策と監視体制を強めるとしています。
関連記事
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：会員アプリのAPIの入口を固める手順
- OWASP API Security Top 10 2023の全10項目｜APIセキュリティのガイドラインと対策：認可漏れと呼び出し上限の不備を含むAPIの10のリスク
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：不正目的の漏えいで求められる報告と本人通知の手順
- ローソンID不正アクセス：215万件の漏えい項目と本物メールの見分け方：同じ10月に起きた会員アプリの事案
- フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：流出したメールアドレスに届く偽の連絡が通る仕組み
