ローソンID不正アクセス：215万件漏えいの対象確認と本物メールの見分け方

株式会社ローソンは2026年10月8日、アカウントサービス「ローソンID」と「ローソンアプリ予約」が第三者から不正アクセスを受け、会員の個人情報が漏えいしたと公表しました。ローソンIDの対象は215万5,345件、ローソンアプリ予約は26件です。本記事の前半は、自分は対象か、届いたメールは本物か、パスワードは変えるべきかという会員の疑問に、公式発表に沿って答えます。後半では、原因とされた「本人に情報を表示するためのセキュリティ機構」が破られるときの型を整理し、表示する会員をトークンの検証結果だけで決める実装をPythonで示します。

まとめ：ローソンID不正アクセスで漏えいしたのは215万5,345件の会員情報

ローソンIDで漏えいしたのはメールアドレスと氏名で、会員が入力していた場合は性別、電話番号、住所、メルマガの受け取り設定も含まれます。ローソンアプリ予約の26件では、氏名、電話番号、クレジットカード番号の一部が漏れました。10月13日の更新時点で、本件が原因と考えられる不正利用や二次被害は確認されていないとされています。

会員がやることは2つです。ローソンを名乗るメール、SMS、電話にはリンクや折り返しで応じず、公式アプリか公式サイトから自分で確かめること。もう1つは、同じメールアドレスとパスワードを使い回している他のサービスを点検することです。開発者が受け取る教訓は、本人の画面に情報を出すための仕組みそのものが入口になりうるという点にあります。

会員が最初に確かめること：漏れた範囲、案内メールの真偽、パスワード

ローソンIDで漏れた項目：メールアドレスと氏名、入力していれば住所や電話番号

ローソンのお詫びとお知らせによると、ローソンIDで漏えいした情報はメールアドレスと氏名です。性別、電話番号、住所、メルマガ取得情報は「ローソンIDを使用したプレゼントの応募などで入力されている場合」に限って対象になります。キャンペーンに応募したことがなく、住所や電話番号を登録していない会員なら、漏れたのはメールアドレスと氏名までと読めます。

ローソンアプリ予約は、季節の催事商品をアプリから事前に予約・決済するサービスです。こちらの26件では、クレジットカード番号の一部が含まれます。発表は「一部」とだけ書いており、何桁が漏れたのか、有効期限やセキュリティコードが含まれるかについては触れていません。カードの明細に見覚えのない請求がないか、念のため確認しておくと安心です。

案内メールの送信元は2つ：10月13日に追加されたアドレスと送信元偽装の注意

ローソンは対象の会員へ、メールで順次、個別に案内しています。公表された送信元は「ローソンIDメール」の[email protected]と、10月13日に追記された[email protected]の2つです。後から追加されたため、2つ目のアドレスから届いたメールを偽物と疑った会員もいたはずです。

ただし、送信元の表示だけで本物と決めるのは避けたほうが無難です。同社は10月1日に、別の事案としてメールサーバーの不正利用による不審メール送信を公表しており、そこでは送信元アドレスの表示が第三者に見えるよう偽装されたケースがあったと説明しています。表示名やアドレスは偽装できる、という前提で動くのが安全です。

見分けるときは、メール内のリンクを押さずに、ローソンアプリを開いて本件のお知らせを確かめます。同社は対応の1つとして、ローソンアプリ上で会員へのお知らせを出しています。メールの文面とアプリのお知らせが食い違う場合や、パスワード、カード番号、本人確認書類の入力を急がせる場合は、開かずに削除してください。手口の全体像はフィッシング詐欺の仕組みと技術的な対策で解説しています。

9月25日からの英文の不審メールは別の事案：メールサーバーの不正利用

9月25日15時頃から27日17時15分頃にかけて、ローソンのメールサーバーから約70万件の不審な英文メールが送られました。件名は「Mutual Benefit」または「RE」で、金銭の取得をほのめかし、連絡や個人情報の提供を求める内容です。同社は10月1日時点で、この件による個人情報の流出やデータセンターへの侵入は確認されていないとしています。

この英文メールと、10月8日公表の個人情報漏えいは、発表上は別の事案です。両者の関係について、同社は触れていません。英文メールを受け取った人は、返信やURLのアクセス、金銭の支払いをせずに削除するよう求められています。

パスワード変更は求められていない：使い回している他サービスは変更する

漏えいした情報の一覧に、パスワードは挙がっていません。同社も会員にパスワードの変更を求めていない状況です。それでも、ローソンIDと同じメールアドレスとパスワードを他のサービスで使っているなら、そちらは変えておく価値があります。漏れたメールアドレスと、別のサイトから過去に漏れたパスワードが組み合わされると、他のサービスへのログインを試される材料が増えるからです。変更は、届いたメールのリンクではなく、公式アプリか、ブラウザに自分で入力した公式サイトから行います。

公式発表で整理する経緯：9月12日の不正アクセスから10月13日の追記まで

9月の不正アクセスから10月13日の更新まで、公表された7つの出来事を並べる

1. 9月12日〜14日：ローソンIDへの不正アクセス
2. 9月17日：ローソンアプリ予約への不正アクセス
3. 10月7日：同社の調査で上記の不正アクセスが判明
4. 判明後：不審なアクセス元をブロックし、ローソンアプリ予約の機能を停止
5. 10月8日：お詫びとお知らせを公表（個人情報保護委員会へも報告済み）
6. 以降順次：アプリ上のお知らせと、対象会員への個別メール
7. 10月13日：案内メールの送信元アドレスを1つ追記

不正アクセスから判明までに3週間ほど空いている点は、運営者として見ておきたいところです。同社は本件以外の不正アクセスやマルウェア感染は無いことを確認済みとし、再発防止策として、対象システムのセキュリティ対策強化、監視体制の強化、インシデント対応体制の強化の3つを挙げています。ローソンアプリ予約は10月中旬の再開を予定しています。

10月14日時点で公表されていない手口・漏えいの経路・補償の有無

原因は「ローソンアプリに関連するシステムが不正に利用された」「本来、アプリ上で利用者本人に対し情報を表示するためのセキュリティ機構が第三者による不正アクセスを受けた」と書かれているだけです。どの機能がどんな手順で破られたのか、なぜ本人以外の情報が取得できたのかは公表されていません。補償やお詫びの品についても記載は見当たりません。本記事はこれらを推測で補わない方針です。以降の技術章は本件の原因を特定するものではなく、本人向けの表示機能が大量流出の入口になる一般的な型を、開発者の点検項目として整理したものです。

本人に情報を表示する仕組みが破られる3つの型：OWASP API Top 10で整理

会員アプリの「マイページ」や「会員情報の確認」画面は、裏でAPIを呼び、ログイン中の会員の情報を受け取って表示します。APIが「誰の情報を返すか」をどう決めているかが、この仕組みの急所です。決め方の誤りは、主に次の3つの型に分かれます。

トークンの署名・宛先・期限を確かめない型：API2の認証の不備

OWASP API Security Top 10のAPI2:2023は、認証の仕組みの誤りを挙げています。トークンの署名を検証しない、有効期限を確かめない、といった実装がこれに当たる典型です。共通IDを複数のアプリやWebで使う構成では、もう1つ見落としやすい点があります。別のサービス宛てに発行されたトークンを、本人表示のAPIがそのまま受け付けてしまうことです。宛先（audience）を確かめていないと、ある機能で手に入れたトークンで別の機能の会員情報を読めてしまいます。

会員番号を書き換えると他人の情報が返る型：API1のオブジェクト単位の認可不備

API1:2023は、リクエストの会員番号を他人のものに書き換えると、他人のデータが返る欠陥です。ログインしているかどうかしか確かめず、その番号を読む権限があるかを見ていないと起こります。同じコンビニの会員アプリで起きた事案の点検手順は、セイコーマートの不正アクセスと会員アプリAPIの認可点検で、会員IDを書き換えるテストと検知SQLまで扱いました。

短時間に大量の会員を読ませてしまう型：API4の回数制限の不在

上の2つの型があっても、1つのクライアントが読める件数に上限があれば、被害は少数で止まります。API4:2023が求めるのは、クライアントごとの呼び出し回数や1回で返すレコード数の制限です。ローソンIDの不正アクセスは3日間とされ、その間に215万件規模の情報が漏れた計算です。本件で回数制限がどう設定されていたかは公表されていませんが、大量取得を件数で止める仕組みの有無は、どの型でも被害の規模を左右します。制限方式の比べ方はAPIレート制限の5方式の比較と分散実装にまとめています。

表示する会員をトークンだけで決めるPythonコードと5つの攻撃パターンの実行結果

署名・宛先・期限を検証し、クエリの会員番号を読まない本人表示APIのコード

次の例は、本人表示APIの処理を最小限の形にしたものです。トークンの中身をPython標準のhmacモジュールで署名検証し、宛先が自分のAPIか、期限が切れていないかを確かめます。誰の情報を返すかはトークン内の会員番号（sub）だけで決め、リクエストに付いてきた会員番号は読みません。追加のインストールなしで動きます。

# 本人表示APIで、表示する会員をトークンの検証結果だけから決める最小例（Python 3.10以上・標準ライブラリのみ）
import base64
import hashlib
import hmac
import json

SECRET = b"replace-with-secret-from-kms"  # 本番は鍵管理サービスから読み込む
AUDIENCE = "profile-api"                  # このAPI宛てに発行されたトークンだけを受け付ける
MEMBERS = {
    "m-1001": {"name": "会員A", "email": "addr-1001", "tel": "tel-1001"},
    "m-1002": {"name": "会員B", "email": "addr-1002", "tel": "tel-1002"},
}


def b64(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()


def unb64(text):
    return base64.urlsafe_b64decode(text + "=" * (-len(text) % 4))


def issue(sub, aud, exp):
    body = b64(json.dumps({"sub": sub, "aud": aud, "exp": exp}).encode())
    sig = b64(hmac.new(SECRET, body.encode(), hashlib.sha256).digest())
    return body + "." + sig


def verify(token, now):
    try:
        body, sig = token.split(".")
        expected = b64(hmac.new(SECRET, body.encode(), hashlib.sha256).digest())
        if not hmac.compare_digest(sig, expected):
            return None, "署名不一致"
        claims = json.loads(unb64(body))
    except ValueError:
        return None, "形式不正"
    if claims.get("aud") != AUDIENCE:
        return None, "宛先違い"
    if claims.get("exp", 0) <= now:
        return None, "期限切れ"
    return claims, "OK"


def get_my_profile(token, query, now):
    claims, reason = verify(token, now)
    if claims is None:
        return 401, reason
    # query の member_id は読まない。誰の情報かはトークンの sub だけで決める
    return 200, MEMBERS[claims["sub"]]


now = 1_000_000
ok = issue("m-1001", "profile-api", now + 300)
body, sig = ok.split(".")
forged_claims = {"sub": "m-1002", "aud": "profile-api", "exp": now + 300}
forged = b64(json.dumps(forged_claims).encode()) + "." + sig

cases = [
    ("正規のトークン", ok, {}),
    ("別会員の番号をクエリに付ける", ok, {"member_id": "m-1002"}),
    ("中身のsubを書き換える", forged, {}),
    ("別サービス宛てのトークン", issue("m-1002", "reserve-api", now + 300), {}),
    ("期限切れのトークン", issue("m-1002", "profile-api", now - 1), {}),
]
for label, token, query in cases:
    print(label, "->", get_my_profile(token, query, now))

Python 3.14.6の実行結果：他人の情報が返ったのは5パターン中0件

正規のトークン -> (200, {'name': '会員A', 'email': 'addr-1001', 'tel': 'tel-1001'})
別会員の番号をクエリに付ける -> (200, {'name': '会員A', 'email': 'addr-1001', 'tel': 'tel-1001'})
中身のsubを書き換える -> (401, '署名不一致')
別サービス宛てのトークン -> (401, '宛先違い')
期限切れのトークン -> (401, '期限切れ')

2行目に注目してください。クエリで会員Bの番号を指定しても、返ってくるのは会員A本人の情報です。APIがクエリの番号を読んでいないため、番号を書き換える攻撃はそもそも成り立ちません。3行目は、トークンの中身を会員Bに書き換えたケースです。署名が合わなくなるので401で止まります。4行目は予約サービス宛てに発行されたトークンを本人表示APIに送ったケースで、宛先違いとして拒否されました。

署名の比較にhmac.compare_digestを使っているのは、比較にかかる時間の差から正しい署名を推測されないようにするためです。実際のサービスでは、自前の形式ではなくJWTとOpenID Connectの検証ライブラリを使い、署名アルゴリズムを固定したうえで、宛先、発行者、期限の3つを必ず検証させます。鍵はコードに書かず、鍵管理サービスから読み込みます。

トークンを直しても残る穴：アプリ専用APIを外から直接呼ばれる場合

会員アプリが呼ぶAPIは、アプリの画面からしか使われない前提で作られがちです。しかし通信を中継すれば、APIは外から直接呼べます。アプリ側で表示項目を絞っていても、APIの応答に他の項目が入っていれば取得されてしまうでしょう。点検は画面ではなくAPIの応答そのもので行い、返す項目を本人表示に必要なものだけに絞ります。応答項目の許可リストと件数制限のコードはバイトル不正アクセスの記事で実行結果つきで示しました。

共通の会員IDを複数サービスで使う事業者が点検する順番と委員会への報告

漏えいを知ってから3〜5日以内の速報と60日以内の確報が要る理由

ローソンは個人情報保護委員会へ報告済みとしています。個人情報保護委員会の案内では、不正アクセスのように不正の目的をもって行われたおそれがある漏えいは、件数にかかわらず報告の対象です。速報は事態を知った日から3〜5日以内、確報は60日以内とされています。本人への通知も求められるため、ローソンが対象会員へ個別メールを送っているのはこの流れに沿った対応です。報告の段取りは個人情報保護委員会への報告義務の実務にまとめています。

会員IDを共有する事業者が確かめる3項目：トークンの宛先・番号の権限・件数

判断は言い切れます。1つの会員IDでアプリ、Web、予約、キャンペーンなど複数のサービスを動かしているなら、確かめる項目は3つです。1つ目は、各サービスのAPIが自分宛てのトークンだけを受け付けているか。別サービス宛てのトークンを送って拒否されるかを試すと分かります。2つ目は、会員番号を他人のものに書き換えたリクエストが拒否されるかどうかです。3つ目に、1つのクライアントが短時間に読める会員数に上限があるかを見ます。3つとも問題が無ければ、本人表示の仕組みから大量流出が起きる入口はかなり狭まります。

逆に、会員IDを1つのサービスでしか使っておらず、認証も外部の会員基盤やSaaSに任せているなら、トークン検証の作り込みまでは要りません。その場合は、提供元の設定で宛先の検証が有効か、応答に余計な項目が出ていないかを確かめれば足ります。自社で判断がつかない場合や、連携しているサービスが多く手で確かめきれない場合は、脆弱性診断・セキュリティ診断でトークン検証と認可の点検を受け付けています。

よくある質問

ローソンIDとローソンアプリ予約の不正アクセスについて、会員から出やすい質問をまとめました。

ローソンIDに登録していますが、自分が対象か確認する方法はありますか？

10月14日時点で、会員が自分で対象かを調べる照会ページは案内されていません。ローソンは対象の会員へ、[email protected] または [email protected] からメールで順次案内し、ローソンアプリ上でもお知らせを出しています。分からない場合は、メール内のリンクを使わず、公式アプリか問い合わせフォームから確かめてください。

ローソンを名乗るメールが届きました。本物ですか？

送信元が上の2つのアドレスでも、表示は偽装できるため、それだけでは本物と言い切れません。ローソンの別の発表でも、送信元表示を偽装した不審メールが確認されています。メール内のリンクは押さず、ローソンアプリのお知らせと内容が一致するかを見てください。パスワードやカード番号の入力を急がせるものは削除するのが安全です。

ローソンIDのパスワードは変更したほうがいいですか？

漏えいした情報の一覧にパスワードは含まれておらず、ローソンも変更を求めていません。ただし同じメールアドレスと同じパスワードを他のサービスで使い回しているなら、そちらを変えておくと安心です。変更は公式アプリか、自分で入力した公式サイトから行います。

クレジットカード番号は漏れていますか？

カード番号の一部が漏れたのは、ローソンアプリ予約の26件だけです。ローソンIDの215万5,345件の対象情報には、カード番号は挙がっていません。予約サービスを使っていた人は、カードの明細に見覚えのない請求がないかを確認し、不審な請求があればカード会社に連絡してください。

ローソンの問い合わせ先はどこですか？補償はありますか？

本件の窓口はローソンカスタマーセンターの専用受付フォームです。電話窓口は発表に記載がありません。補償やお詫びの品については、10月14日時点で公表がありません。補償を名目に振込や手数料、カード番号の入力を求める連絡があっても応じないでください。

関連記事

• セイコーマートの不正アクセスと会員アプリAPIの認可点検手順：同じコンビニの会員アプリで起きた事案と会員IDを書き換えるテスト
• バイトル不正アクセス：388万件のメールアドレス漏えいの対象確認と不審メール対策：同時期に公表されたメールアドレスの大量流出と応答項目の許可リスト
• ブックオフ不正アクセス：約638万人の対象確認と本物メールの見分け方：同じ週に公表された会員情報の大量流出と大量取得の検知
• APIセキュリティとは？OWASP API Top 10の主要リスクと実装対策：本記事で扱ったAPI1・API2・API4を含む10項目の全体像
• 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：運営者として点検する範囲の全体像