阪急百貨店の不正アクセス：H2O ID約126万件の対象確認と本物メールの見分け方

エイチ・ツー・オー リテイリングと阪急阪神百貨店は2026年10月19日、「阪急百貨店・阪神百貨店予約サイト」を経由して顧客管理システムが不正アクセスを受け、グループ共通ID「H2O ID」の約126万件の個人情報の一部が漏えいしたと公表しました。発表で対象とされているのは、「ほぼ全てのH2O ID会員」です。本記事の前半では、自分は対象か、届いたメールは本物か、パスワードは変えるべきかという会員の疑問に、公式発表の文言に沿って答えます。後半では、1つの共通IDに複数のサービスがつながる顧客基盤で、周辺のサイト1つから全会員の情報に届いてしまう構造を整理し、接続元ごとに読める範囲を絞る実装をPythonで示します。

まとめ：阪急百貨店の不正アクセスで漏えいしたのはH2O ID会員約126万件の個人情報

漏えいしたのは、H2O ID、氏名、性別、メールアドレス、郵便番号、住所、携帯電話番号、電話番号、年齢、生年月日、H2O IDで利用しているサービスの項目です。通販の「HANKYU HANSHIN E-STORES」と「Remo Order」については、注文履歴やクレジットカード情報の一部の漏えい有無を調査中としています。ログインパスワードの漏えいは確認されていません。10月19日時点で、本件が原因と考えられる不正利用や二次被害は確認されていないとされています。

会員がやることは2つです。阪急・阪神やH2O IDを名乗るメール、SMS、電話には、リンクや折り返しで応じないこと。10月20日には実際にH2O IDを騙る詐欺メールが確認されています。もう1つは、同じメールアドレスとパスワードを使い回している他のサービスを点検することです。運営する側への教訓は、グループで共通化したIDの顧客基盤では、周辺のサイト1つが全会員への入口になりうるという点にあります。

H2O ID会員が最初に確かめること：対象かどうか、本物のメール、パスワード

漏えいした11項目と、E-STORES・Remo Orderで調査中のカード情報の一部

阪急阪神百貨店のお詫びとお知らせによると、予約サイト経由で漏えいしたのはH2O ID会員の情報です。項目はH2O ID、氏名（姓名・漢字カナ）、性別、メールアドレス、郵便番号、住所、携帯電話番号、電話番号、年齢、生年月日、H2O IDでのご利用サービス項目の11種類にのぼります。どのサービスを使っているかまで漏れているため、「予約サイトをご利用の方へ」のように利用実態に合わせた偽の連絡が作られやすくなります。

E-STORESとRemo Orderでは、漏えいの可能性を調査中です。両サービスが保持しているのは、商品注文履歴、クレジットカード情報の一部（カード種別、番号の下4桁、名義、有効期限）、ポイントカード情報の一部（種別と番号の下4桁）、アドレス帳の情報です。同社は決済情報の非保持化に対応しており、カード番号の全桁とセキュリティコードは保持していないため、不正に利用されるおそれは無いとしています。

案内メールの送信元は1つのみ：10月20日に確認された偽メールの見分け方

同社が対象のH2O ID会員へ順次送っている案内は、電子メールによる連絡です。送信元を照合する際は、表示された会社名だけでなく、次に記すメールアドレス全体を確かめてください。発表に書かれた送信元は「[email protected]」の1つだけで、これ以外の送信元からの連絡には注意するよう求めています。

10月20日には、H2O IDを騙る不審メールへの注意喚起が出ました。メール内のバナーやリンクから不審なサイトへ誘導し、クレジットカード番号や個人情報を入力させる詐欺メールが確認されたという内容です。同社は、このようなメールを送ることは一切無いと明言しています。送信元の表示は偽装できるため、アドレスが一致していても、カード番号の入力を求めるメールは偽物と判断してかまいません。確かめるときは、メールのリンクではなく、ブラウザに自分で入力した公式サイトか阪急阪神百貨店アプリを開きます。誘導の手口はフィッシング詐欺の仕組みと技術的な対策で解説しています。

店頭だけで買い物をしている人は対象か：H2O IDを登録したかどうかで分かれる

漏えいの対象は「H2O ID会員」です。H2O IDのよくあるご質問によると、H2O IDで使えるサービスはHANKYU HANSHIN E-STORES（Remo Orderを含む）、阪急・阪神ギフトモール、阪急百貨店・阪神百貨店予約サイト、阪急阪神百貨店アプリ、まちうまアプリの5つです。これらのどれかでメールアドレスを登録して会員になった人が、対象になりえます。

店頭でポイントカードを出して買い物をしているだけの人が、H2O IDとは別の形で対象に含まれるかは、発表に書かれていません。自分がH2O ID会員か分からない場合は、登録に使いそうなメールアドレスで、公式サイトからログインを試すか、窓口に問い合わせてください。9月30日に始まったアプリでポイントカードをデジタル化した人は、アプリの登録時にH2O IDを作っている可能性があります。

パスワードの漏えいは確認されていない：使い回している他のサービスは変更する

発表は「ログインパスワードの漏えいも確認されておりません」としています。同社も会員にパスワードの変更を求めてはいません。それでも、H2O IDと同じメールアドレスとパスワードを他のサービスで使っているなら、そちらは変えておく価値があります。今回は生年月日と電話番号まで漏れているため、これらをパスワードや秘密の質問に使っている場合も見直しの対象です。H2O IDのパスワード変更は、ログイン後のマイページにある「会員情報設定」から行えます。

公式発表で追う経緯：10月16日の予約サイトから10月20日の偽メール注意まで

10月16日の不正アクセス確認から10月20日まで、公表された6つの出来事

1. 10月16日（金）：予約サイトを経由した顧客管理システムへの不正アクセスを確認。不正な通信を遮断し、予約サイトのシステム全体を停止
2. 10月17日（土）：E-STORESとRemo Orderでも不正アクセスを確認し、両サイトのシステム全体を停止
3. 10月19日（月）：調査でH2O ID約126万件の漏えいが判明。個人情報保護委員会へ報告し、所轄警察署へ被害を申告
4. 10月19日：お詫びとお知らせを公表。E-STORESは14時に再開
5. 10月19日以降：H2O ID会員へ電子メールで順次連絡
6. 10月20日：H2O IDを騙る詐欺メールへの注意を公表

不正アクセスの確認から判明までは3日、公表は同じ日です。E-STORES再開のお知らせは、再発防止策と安全確認が完了したと説明しています。10月21日時点で、予約サイトはメンテナンス中の画面を出しており、Remo Orderの再開も公表されていません。

10月21日時点で未公表の原因・手口・補償と予約サイト・Remo Orderの再開時期

原因について、エイチ・ツー・オー リテイリングの発表は「詳細な原因究明およびセキュリティ脆弱性の解析・調査を進めております」と書くにとどまります。予約サイトのどの機能が使われたのか、なぜ予約サイト経由で顧客管理システムの全会員の情報に届いたのかは不明です。補償やお詫びの品についても記載は見当たりません。

本記事はこれらを推測で補いません。以降の技術章は本件の原因を特定するものではなく、共通IDの顧客基盤で周辺サイトが入口になる一般的な型を、運営者の点検項目として整理したものです。新たな事実は同社のホームページで開示するとされています。

予約サイト1つから全会員に届いた構造：グループ共通IDに集約した顧客管理システム

H2O IDは5サービスで共有、9月にアプリからEC・予約サイトへログイン不要で移動

9月9日の発表によると、H2O IDは2026年8月末に会員数100万人を超え、2030年度に1,000万会員を目標としていました。百貨店の既存顧客システムからのID移行も進めていたと説明しています。漏えいした約126万件が「ほぼ全会員」とされているのは、この会員規模と合います。

同じ日に発表された阪急阪神百貨店アプリは9月30日に始まり、主な機能に「ECサイト・予約サイトにも都度ログイン不要で簡単アクセス」を挙げています。買上情報やイベント予約などのデータをH2O IDと連携し、顧客を個別に識別するという設計です。アプリと本件の関係は公表されていませんが、1つのIDに買い物、予約、アプリがつながり、その裏の顧客管理システムに全会員の情報が集まっていた点は、発表から読み取れます。

顧客情報を広く読める周辺サイトの3つの型：OWASPのAPI1・API3・API4

予約サイトが会員の名前や連絡先を表示するには、顧客管理システムから情報を受け取る必要があります。このとき点検するのは、予約サイトのサーバーが顧客管理システムの情報を「どの会員の、どの項目を、何件まで」読める作りになっているかです。接続の許可が広すぎると、予約サイトが乗っ取られた時点で、予約を使っていない会員まで読まれます。誤りの型は主に3つです。

• API1:2023（オブジェクト単位の認可不備）：ログイン中の本人以外の会員番号を指定しても情報が返る
• API3:2023（プロパティ単位の認可不備）：予約に要らない生年月日や他サービスの利用状況まで返る
• API4:2023（資源消費の無制限）：1つの接続元が短時間に何万件でも読める

3つのうち、共通IDの基盤で最も効くのはAPI4への備えです。サーバーごと乗っ取られると、本人確認の判定は偽れてしまうからです。トークンの署名や宛先の検証は、同じ型の事案を扱ったローソンID不正アクセスの記事でコードを示しました。本記事では、接続元のサービスごとに読める範囲を分ける側を扱います。

接続元サービスごとに読める項目と件数を絞るPythonコードと実行結果

予約サイトとECで項目・対象会員・1分あたりの件数を分ける窓口のコード

次の例は、顧客管理システムの前に置く窓口を最小限の形にしたものです。接続元ごとに、返してよい項目、そのサービスの会員かどうか、1分あたりの件数上限を持たせます。予約サイトは氏名・メールアドレス・電話番号だけ、ECは住所まで読める設定です。一覧の取り出しはどの接続元にも開けません。比較用に、接続元を区別せず全項目を返す作りも置きました。追加のインストールなしで動きます。

# 共通IDの顧客管理システムの前に置く窓口で、接続元サービスごとに読める範囲を絞る最小例（Python 3.10以上・標準ライブラリのみ）
import time

# 顧客管理システムの会員台帳（例として1万件）
MEMBERS = {
    f"h2o-{i:05d}": {
        "name": f"会員{i}", "email": f"addr-{i}", "tel": f"tel-{i}",
        "address": f"住所-{i}", "birthday": "1980-01-01",
        "services": ["予約サイト", "E-STORES"] if i % 3 == 0 else ["E-STORES"],
    }
    for i in range(10_000)
}

# 接続元サービスごとの許可。項目・対象の会員・1分あたりの件数を分けて持つ
POLICIES = {
    "reserve-site": {"fields": {"name", "email", "tel"}, "service": "予約サイト", "per_min": 30},
    "estores":      {"fields": {"name", "email", "tel", "address"}, "service": "E-STORES", "per_min": 60},
}
_calls = {}


def lookup(client, member_id, session_member):
    """接続元 client が、ログイン中の会員 session_member として member_id を読みに来たときの判定"""
    policy = POLICIES.get(client)
    if policy is None:
        return 403, "未登録の接続元"
    window = int(time.time() // 60)
    count = _calls.get((client, window), 0) + 1
    _calls[(client, window)] = count
    if count > policy["per_min"]:
        return 429, "件数上限"
    if member_id != session_member:
        return 403, "ログイン中の本人以外"
    member = MEMBERS.get(member_id)
    if member is None or policy["service"] not in member["services"]:
        return 404, "このサービスの会員ではない"
    return 200, {k: v for k, v in member.items() if k in policy["fields"]}


def list_all(client):
    """一覧の取り出しはどの接続元にも開けない"""
    return 403, "一覧取得は不可"


def naive_lookup(member_id):
    """比較用：接続元を区別せず、全項目を返す作り"""
    return 200, MEMBERS[member_id]


# 1) 比較用の作りで、予約サイトのサーバーが乗っ取られた場合に読める件数
leaked = sum(1 for m in MEMBERS if naive_lookup(m)[0] == 200)
print("区別しない作りで読めた会員:", leaked, "件 / 項目:", sorted(MEMBERS["h2o-00000"]))

# 2) 窓口を通した場合
print("本人の予約:", lookup("reserve-site", "h2o-00003", "h2o-00003"))
print("他人の番号:", lookup("reserve-site", "h2o-00006", "h2o-00003"))
print("予約を使っていない会員:", lookup("reserve-site", "h2o-00001", "h2o-00001"))
print("一覧取得:", list_all("reserve-site"))
print("未登録の接続元:", lookup("unknown-app", "h2o-00003", "h2o-00003"))

# 3) 乗っ取ったサーバーから、セッションを偽って全会員を順に読もうとした場合
got, stopped = 0, None
for m in MEMBERS:
    status, _ = lookup("reserve-site", m, m)
    if status == 200:
        got += 1
    if status == 429:
        stopped = m
        break
print("窓口経由で読めた会員:", got, "件 / 上限で止まった番号:", stopped)

Python 3.14.7の実行結果：1万件中、窓口経由で読めた会員は9件

区別しない作りで読めた会員: 10000 件 / 項目: ['address', 'birthday', 'email', 'name', 'services', 'tel']
本人の予約: (200, {'name': '会員3', 'email': 'addr-3', 'tel': 'tel-3'})
他人の番号: (403, 'ログイン中の本人以外')
予約を使っていない会員: (404, 'このサービスの会員ではない')
一覧取得: (403, '一覧取得は不可')
未登録の接続元: (403, '未登録の接続元')
窓口経由で読めた会員: 9 件 / 上限で止まった番号: h2o-00027

1行目が、接続元を区別しない作りの結果です。予約サイトのサーバーから、1万件すべての会員を、生年月日や他サービスの利用状況まで含めて読めました。窓口を通すと、本人の予約でも返るのは氏名・メールアドレス・電話番号の3項目だけです。他人の番号、予約を使っていない会員、一覧の取り出しは、いずれも拒否されました。

最終行は、乗っ取ったサーバーが「ログイン中の本人」を毎回偽り、全会員を順に読もうとしたケースです。本人照合は通ってしまいますが、予約サイトの会員でない人は404で返らず、1分あたり30件の上限に達した時点で429になりました。読めたのは9件です。同じ1分の中で先に3回呼んでいるため、上限まで残り27回でした。

乗っ取られたサーバーは本人を偽れる：最後に効くのは件数上限と項目の絞り込み

上の結果が示すとおり、接続元のサーバーそのものを握られると、「ログイン中の本人だけ」という判定はサーバーの申告を信じる限り破られます。本人の判定は、予約サイトの申告ではなく、ID基盤が発行して窓口が自分で検証したトークンから取るのが本筋です。その仕組みはシングルサインオンの実現方式とIDトークン検証で扱っています。

それでも、トークンの発行側まで破られる事態は残ります。そのとき被害の上限を決めるのは、接続元ごとの件数上限と、返す項目の少なさです。実際の運用では、件数上限を超えた接続元を自動で止めて通知し、窓口のログに接続元・会員番号・件数を残します。上限値は、予約サイトの1日の実際の参照件数を測ってから、その数倍に置くと誤検知を抑えられます。レート制限の方式はAPI不正アクセス対策の実装手順にまとめました。

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

不正な目的のおそれがある漏えいは、発覚日から60日以内に確報が要る

同社は本件の確認後、直ちに個人情報保護委員会へ報告したとしています。個人情報保護委員会の案内は、漏えいが発覚したらまず速やかに報告し、不正な目的で行われたおそれがある場合は発覚日から60日以内に報告するよう求めています。不正アクセスによる漏えいは、件数にかかわらずこの対象です。本人への通知も求められるため、同社が会員へ順次メールを送っているのはこの流れに沿った対応です。報告書に何を書くかは個人情報保護委員会への報告義務の実務で整理しています。

共通IDに周辺サービスをつなぐ事業者が確かめる4項目と、作り込みが要らない場合

判断は言い切れます。1つの会員IDで、EC、予約、アプリ、キャンペーンなど複数のサービスを動かしているなら、確かめる項目は4つです。

1. 各サービスのサーバーが顧客管理システムに接続するとき、サービスごとに別の資格情報を使っているか
2. サービスごとに、返す項目がそのサービスの画面に要るものだけに絞られているか
3. そのサービスを使っていない会員の情報が返らないか
4. 1つの接続元が短時間に読める件数に上限があり、超えたら止まるか

1つでも「全サービス共通の資格情報で、全項目を、件数無制限に読める」状態なら、どれか1つのサイトの脆弱性が全会員の漏えいに直結します。グループでIDを統合する計画があるなら、統合と同時にこの4項目を設計に入れるべきです。会員基盤の設計の考え方はCIAMの顧客ID基盤の設計で、予約と顧客を同じIDで持つかの判断は予約システムの顧客管理の設計判断で扱いました。

逆に、会員IDを1つのサービスでしか使っておらず、会員情報も外部の会員基盤やSaaSに任せているなら、窓口の作り込みまでは要りません。その場合は、提供元の管理画面で接続アプリごとの権限と取得項目を確かめれば足ります。既存のサービスがID基盤に直接つながっていて、どこから手を付けるか判断がつかない場合は、認証基盤・ID管理システム開発で接続設計の見直しから相談を受け付けています。

よくある質問

阪急百貨店・阪神百貨店の予約サイトなどへの不正アクセスとH2O IDの漏えいについて、会員から出やすい質問をまとめました。

自分がH2O IDの対象か、確認する方法はありますか？

10月21日時点で、会員が自分で対象かを調べる照会ページは案内されていません。発表は「ほぼ全てのH2O ID会員」が対象としており、会員には [email protected] から順次メールで連絡しています。E-STORES、阪急・阪神ギフトモール、予約サイト、阪急阪神百貨店アプリ、まちうまアプリのどれかで会員登録した覚えがあれば、対象と考えて備えるのが安全です。

阪急・阪神を名乗るメールが届きました。本物ですか？

案内メールの正規の送信元は [email protected] ですが、送信元の表示は偽装できます。10月20日には、H2O IDを騙ってリンクから偽サイトへ誘導し、カード番号を入力させる詐欺メールが確認されました。同社はそうしたメールを送らないとしています。メール内のリンクやバナーは押さず、カード番号や個人情報は入力しないでください。

H2O IDのパスワードは変えたほうがいいですか？

ログインパスワードの漏えいは確認されておらず、同社も変更を求めていません。ただし同じメールアドレスとパスワードを他のサービスで使っているなら、そちらは変えておくと安心です。H2O IDのパスワードは、ログイン後のマイページの「会員情報設定」から変更できます。変更はメールのリンクからではなく、自分で開いた公式サイトで行ってください。

クレジットカードは止めたほうがいいですか？

予約サイト経由で漏えいした11項目に、カード情報は含まれていません。E-STORESとRemo Orderで調査中なのは、カード種別、番号の下4桁、名義、有効期限です。同社はカード番号の全桁とセキュリティコードを保持しておらず、不正に利用されるおそれは無いとしています。止める前に、明細に見覚えのない請求が無いかを確かめ、あればカード会社に連絡してください。

問い合わせ先はどこですか？補償はありますか？

本件の窓口は阪急阪神百貨店特設コールセンターで、フリーダイヤルは0120-110-256または0120-369-089、受付は毎日午前10時から午後8時までです。H2O IDのお問い合わせフォームも使えます。補償やお詫びの品については、10月21日時点で公表がありません。補償を名目に振込やカード番号の入力を求める連絡には応じないでください。

関連記事

• ローソンID不正アクセス：215万件漏えいの対象確認と本物メールの見分け方：共通の会員IDで起きた同じ月の事案と、トークンの署名・宛先・期限の検証
• CIAMとは？顧客ID基盤の設計と会員DB移行・同意管理を実装視点で解説：グループで会員IDを統合するときの基盤設計
• 予約システムの顧客管理｜予約と顧客を同じIDで持つか分けるかの設計判断：予約サイトと顧客台帳のつなぎ方
• Eストアー（ショップサーブ）情報漏えい：どの店舗が対象か・お詫びメールは本物か：通販の基盤側で起きた漏えいと案内メールの見分け方
• 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：運営者として点検する範囲の全体像