イープラスの不正アクセスと払戻し口座情報1,463件｜払戻し機能の保管と監視の点検手順

チケット販売プラットフォーム「イープラス」を運営する株式会社イープラスは2026年9月29日、電子チケット「スマチケ」の払戻し情報を管理するシステムが第三者の不正アクセスを受け、1,463件の情報が漏えいしたと公表しました。銀行振込で返金を受けた751件には、金融機関名から口座番号、口座名義までの振込先口座情報が含まれます。本記事は公表文の事実を時系列で整理し、払戻しを申請した人が確かめることを示したうえで、払戻しや返金の機能を持つ事業者向けに、返金済みの口座情報を消すSQLと、払戻し記録の大量読み出しを見つけるPythonを紹介します。

まとめ：イープラスの不正アクセスで公表された事実と払戻し申請者がまず行う対応

公表文で確定しているのは、2026年9月11日19時58分から12日2時44分にかけて不正アクセスが複数回あったこと、14日から15日にかけて事実を確認し、15日中にセキュリティ設定を見直して遮断したことです。漏えいしたのは2022年6月30日から2026年9月11日までにスマチケから払戻しを申請した一部の人の情報で、会員情報やチケット購入情報のデータベースとは別のシステムでした。クレジットカード情報とパスワードは含まれていません。

侵入の手法や脆弱性の種類は公表されていません。申請した覚えがある人は、9月29日から順次届いているイープラスからの個別メールの有無を確かめ、口座名義や公演名を添えた返金案内が届いても公式窓口で確認してから動いてください。払戻し機能を自社で持つ事業者が見直すのは、返金が終わった口座情報を残していないか、払戻し記録をまとめて読む動きに気づけるか、の2点です。

漏えい件数1,463件の内訳は、銀行振込751件・カード返金644件・郵便振替68件です。返金方法によって漏えいした項目が異なるため、各方法の項目は後述の表で確認してください。

公式発表を時系列で確認する｜9月11日夜の不正アクセスから9月29日の公表まで

9月11日19時58分から約7時間の複数回アクセスと遮断までの4日間

イープラスの公表文（2026年9月29日）によると、不正アクセスを受けたのは、スマチケ管理システムのうち公演中止・延期などに伴う払戻し情報を管理するシステムです。アクセスは9月11日（金）19時58分から9月12日（土）2時44分までの間に複数回発生しました。金曜の夜から土曜の未明にかけての約7時間です。

同社が不正アクセスと漏えいの事実を確認したのは9月14日（月）から15日（火）にかけてで、15日中に該当システムのセキュリティ設定を見直し、アクセスを遮断しています。その後、同様の事象は起きていないとしています。発生から確認まで3日、遮断まで4日かかった計算です。以降は管理下の全システムの再検査を進め、個人情報保護委員会へ報告済み、所轄の警察署への届出を準備中と記しています。

返金方法ごとに異なる漏えい項目と銀行振込751件に含まれた口座情報

漏えいした情報は、申請者が選んだ返金方法によって変わります。どの方法でも、払戻し対象となった公演名、会場、開催日時が含まれます。

表中の振込先口座情報は、金融機関名・支店名・口座種別・口座番号・口座名義です。証書の送付先には、郵便番号・住所・氏名が含まれます。

カード返金の644件にカード番号が含まれないのは、同社がカード情報をシステム内に保持していないためです。返金処理を決済代行側に任せる設計なら、払戻しシステムにはカード番号を置かずに済みます。一方、銀行振込は振込先を自社で受け取るしかなく、口座情報がそのまま払戻しシステムに残っていました。紙チケットなどスマチケ以外の受取方法で払戻しをした人の情報は対象外です。

会員データベースと独立していた点と公表されていない侵入経路の扱い

公表文は、該当システムがイープラスの会員情報やチケット購入に関する情報を保管するデータベースとは独立していると明記しています。管理下の他システムでも漏えいや不正アクセスは見つからず、データベースやファイルの改ざんも確認されていません。

原因については「第三者から不正アクセスが行われたことによるもの」とあるだけで、侵入経路、脆弱性の種類、遮断のために見直した設定の中身は書かれていません。本記事も、それらを推測で補うことはしません。以降の章で扱う点検項目は、今回の原因を言い当てるものではなく、同じ種類の機能を持つ事業者が確かめておく項目として読んでください。

払戻し申請者が今やること｜口座情報を知る相手からの連絡を公式窓口で確かめる

口座名義と公演名を添えた返金案内や追加手続きの依頼を疑う基準

漏えいした組み合わせは、氏名、メールアドレス、払戻しを受けた公演の名前と日時、銀行振込の人なら口座情報です。この材料があれば「〇〇公演の払戻しに不備がありました。口座名義の確認のため、こちらから再登録してください」といった、本人しか知らないはずの内容を含む連絡が作れます。

判断の基準は、内容が合っているかではなく、どの経路で届いたかです。イープラスのアプリからの払戻申請は、公式の払戻案内に沿ってアプリの中で進める手続きです。メールやSMSのリンクから口座情報や暗証番号を入力させる連絡は、届いた時点で疑ってください。イープラスは公表文で、不審な連絡に心当たりがあれば同社のお客様対応窓口に連絡するよう案内しており、対象者には専用のフリーダイヤルを個別に知らせています。

銀行口座で確かめる入出金明細と不審な取引に気づいたときの連絡順

銀行振込で返金を受けた人は、該当口座の入出金明細を確かめます。口座番号と名義だけで預金を引き出すことはできず、出金には暗証番号やインターネットバンキングの認証が要るのが通常です。それでも、心当たりのない少額の入金や、身に覚えのない口座振替の登録がないかは見ておく価値があります。

不審な取引を見つけたら、最初に口座のある金融機関へ連絡し、次にイープラスの窓口へ伝えます。偽サイトに暗証番号やネットバンキングのパスワードを入れてしまった場合は、金融機関への連絡と並行してパスワードを変えてください。受け取った偽のメールやSMSは、警察庁のフィッシング対策ページにある相談窓口から報告できます。

払戻しデータが4年分たまる構造｜返金が終わった口座情報を残さない設計

2022年6月30日以降の申請が一つのシステムに残り続けた意味

今回の漏えいは、2022年6月30日から2026年9月11日までの申請にまたがっています。少なくとも4年以上前の申請の口座情報が、払戻しシステムの中で読める状態にあったことになります。公演中止に伴う払戻しは、振込が終われば口座情報を使う場面がほとんど残りません。

払戻しや返金の機能は、本体の会員基盤とは別のチームが急ぎで作ることが多く、データの保存期間が決められないまま運用に入りがちです。会員の退会時に消す仕組みはあっても、払戻しの記録は「会計の記録だから」と一括で残されます。退会した会員のデータを残さない設計はタイムズカーの不正アクセスと免許証画像の保管設計で扱いました。払戻しの口座情報は、それより短い期間で消せる種類のデータです。

返金完了から90日で口座番号と住所を消すSQLと事前の件数確認

払戻しの記録そのものは残し、返金が終わって一定期間が過ぎた行から、口座情報と送付先だけを空にする方法が扱いやすい形です。次は、返金済みで90日を過ぎた行を対象にする例です。1本目で返金方法ごとの対象件数を確かめ、2本目で消します。

-- 消す前に、返金方法ごとの対象件数を確かめる
SELECT method, COUNT(*) AS targets
FROM refund_requests
WHERE status = 'paid'
  AND paid_at < datetime('now', '-90 days')
  AND purged_at IS NULL
GROUP BY method;

-- 口座情報と送付先だけを空にし、消した日時を残す
UPDATE refund_requests
SET bank_name = NULL, branch_name = NULL, account_type = NULL,
    account_number = NULL, account_holder = NULL,
    postal_code = NULL, address = NULL,
    purged_at = CURRENT_TIMESTAMP
WHERE status = 'paid'
  AND paid_at < datetime('now', '-90 days')
  AND purged_at IS NULL;

SQLite 3.53.1で、返金済みで90日を過ぎた行（銀行振込・郵便振替・カード返金の各1件）、返金から10日の行、未返金の行を入れたテストデータに実行し、件数確認が方法別に1件ずつを返し、UPDATEの後は対象の3行だけ口座番号と住所が空になることを確かめました。datetime('now', '-90 days')はSQLiteの書き方です。PostgreSQLでは日付時刻関数のnow() - interval '90 days'に置き換えます。UPDATE文の構文はSQLiteのUPDATEの説明のとおりで、WHERE句を外すと全行が対象になる点に注意してください。

夜間のバッチで毎日流せば、口座情報が残るのは最長で返金後90日と翌日分になります。バックアップに古い口座情報が残る点は別に扱いが要るため、バックアップの保存世代もあわせて決めます。

消去までの期間を決めるときに照会対応と会計の記録を分ける判断

90日は例であって、決め方は「振込が失敗したときの再振込」と「申請者からの問い合わせ」に口座情報が要る期間です。組戻しや口座相違の連絡が落ち着く期間を自社の実績で確かめ、その長さに余裕を足します。

会計や税務で残す記録と、口座情報は分けて考えます。残すべきは、いつ、誰に、いくら払ったかの記録です。振込先の口座番号を払戻しシステムに何年も持ち続ける理由にはなりません。保存の要否は社内規程と顧問の税理士に確かめたうえで、払戻しシステムからは消し、必要な記録は会計システム側に寄せます。問い合わせ対応の記録に口座番号が書き込まれる経路は大和証券の不正アクセスと口座番号を委託先に残さない設計で、伏せ字に置き換える実装を紹介しています。

払戻し機能への大量読み出しを見つける｜深夜の連続アクセスをログで洗い出す

発生から確認まで3日かかった点と払戻し記録の読み出しを数える考え方

今回のアクセスは金曜19時58分から土曜2時44分までで、確認は週明けの月曜から火曜でした。払戻し機能は公演中止のときに申請が集中し、普段は利用が少ない機能です。普段の利用が少ない機能ほど、まとまった読み出しは目立つはずですが、誰も数えていなければ週末をまたいで気づけません。

数える対象は、ログイン回数ではなく、払戻し記録を何件読んだかです。本人が自分の払戻し状況を見るなら、1回の利用で読むのは数件です。1時間に数十件、数百件の異なる記録を読む接続元は、正規の利用者ではありません。見るべきログの種類と保存先は不正アクセスのログ確認・解析方法にまとめています。

アクセスログから1時間ごとの読み出し件数と深夜帯を抽出するPython

次は、1行に1件のJSONで書き出したアクセスログから、払戻し記録のAPIを読んだ件数を接続元と1時間ごとに数え、上限を超えた時間帯と深夜帯を出力する例です。読み込みには標準ライブラリのjsonモジュール、集計にはcollectionsのdefaultdictを使います。

import json
import sys
from collections import defaultdict
from datetime import datetime

THRESHOLD = 50          # 1時間に読んだ払戻し記録の件数の上限
NIGHT = range(0, 7)     # 0時〜6時台は件数に関係なく要確認

reads = defaultdict(set)
with open(sys.argv[1], encoding="utf-8") as f:
    for line in f:
        e = json.loads(line)
        if e["status"] != 200 or not e["path"].startswith("/api/refunds/"):
            continue
        ts = datetime.fromisoformat(e["ts"])
        key = (e["ip"], e.get("user") or "-", ts.strftime("%Y-%m-%d %H:00"))
        reads[key].add(e["path"].rsplit("/", 1)[-1])

for (ip, user, hour), ids in sorted(reads.items(), key=lambda kv: kv[0][2]):
    night = int(hour[11:13]) in NIGHT
    if len(ids) > THRESHOLD or night:
        print(f"{hour} ip={ip} user={user} records={len(ids)}" + (" [深夜]" if night else ""))

Python 3.14.6で、通常の本人照会3件、20時台に1つの接続元が読んだ120件、深夜2時台の5件、404だけが返った80件、別のパスへの深夜アクセスを含むテストログを入力し、20時台の120件と深夜2時台の5件の2行だけが出力されることを確かめました。成功した応答だけを数えるのは、実際に情報が出た量を見るためです。404が大量に並ぶ接続元は、記録の番号を総当たりしている兆候なので、別の条件で拾います。上限の50件は例です。過去の公演中止の日のログで最大値を測り、それを超える値に置いてください。

申請者本人の記録しか返さない認可条件と管理画面の接続元の絞り込み

読み出しを数えるのは気づくための仕組みで、読ませないための仕組みは別に要ります。払戻し記録を返すAPIは、記録の番号だけで行を引かず、WHERE id = ? AND applicant_id = ?のようにログイン中の申請者の識別子を必ず条件に入れます。番号を書き換えれば他人の記録が読める状態は、認可の不備の典型です。仕組みと止め方は認可バイパスとIDORの実装対策で解説しています。

払戻しの処理担当者が使う管理画面は、全件を一覧できる権限を持ちます。インターネットからの接続を許さず、社内の拠点やVPNの接続元に絞ってください。イープラスが遮断のために見直したのが「セキュリティ設定」だった点からも、アプリの改修より先に、接続元と公開範囲の設定を棚卸しする価値があります。

本体から切り離された周辺システムの教訓｜払戻し・問い合わせ用の台帳を作る

独立したシステムだったことで会員情報に被害が及ばなかった点と残った弱点

払戻しシステムが会員データベースと独立していたことで、会員のパスワードやカード情報、購入履歴には被害が及びませんでした。周辺機能を本体から切り離す設計は、被害の範囲を限る点で効いています。

残った弱点は、切り離した側に口座情報という重いデータを長く置いていたことです。本体には手厚い監視と診断が入っていても、払戻しや問い合わせ、キャンペーン応募のような周辺システムは、作った後に誰も見直さないことがあります。イープラスが再発防止策に、全システムの総点検とセキュリティ診断の実施サイクルの短縮を挙げているのも、この種の周辺システムまで診断の対象に入れる趣旨と読めます。

周辺システムの点検順と外部の脆弱性診断に出すかどうかを決める基準

点検は次の順で進めます。最初の台帳作りを飛ばすと、残りの点検の対象から周辺システムが漏れます。

1. 個人情報を持つシステムを、本体・周辺を問わず一覧にする（払戻し、問い合わせ、応募、アンケートなど）
2. 各システムが持つ項目に、口座情報・住所・本人確認書類があるかを書き出す
3. 重い項目を持つシステムごとに、保存期間と消去の仕組みがあるかを確かめる
4. 管理画面とAPIの接続元の制限、本人以外の記録を返さない認可、読み出し件数の記録を確かめる

外部の診断に出すかどうかの基準は明確です。口座情報や住所を持つ周辺システムがあり、最後に診断を受けた時期を誰も答えられないなら、出す価値があります。周辺システムが無いか、持つ項目がメールアドレス程度に限られるなら、上の4項目を自社で確かめる対応で十分です。診断の種類と進め方は脆弱性診断とはに、払戻しや問い合わせの機能を含めた確認を依頼する場合は脆弱性診断・セキュリティ診断にまとめています。

よくある質問

イープラスの不正アクセスについて、払戻しを申請した人と、同じ種類の機能を持つ事業者から出やすい質問をまとめました。

イープラスの不正アクセスでクレジットカード情報は漏れましたか？

漏れていません。イープラスはクレジットカード情報をシステム内に保持しておらず、今回の漏えい対象に一切含まれないと公表しています。会員のパスワードも対象外です。カード返金を選んだ644件で漏えいしたのは、メールアドレス、カナ氏名、公演名・会場・開催日時です。カード会社を名乗って番号の再入力を求める連絡が来ても、応じずにカード裏面の番号へ問い合わせてください。

自分が対象かどうかはどうすれば分かりますか？

対象者には、9月29日から順次、イープラスが個別にお詫びとお知らせのメールを送っています。対象は、2022年6月30日から2026年9月11日までにスマチケで受け取ったチケットの払戻しを、スマチケから申請した人の一部です。紙チケットなど他の受取方法で払戻しをした人は含まれません。メールが届かず不安な場合は、イープラスの公式サイトにあるお客様対応窓口から確かめます。

イープラスの会員ではない同行者の情報も対象になりますか？

対象になる場合があります。公表文で個別メールの送付対象として明記されているのは、会員に加え「イープラス会員ではない同行者様」です。スマチケは同行者にチケットを分けて渡せるため、受け取った同行者が自分で払戻しを申請していれば、その申請の情報が払戻しシステムに残ります。同行者にチケットを分けた人は、相手にも今回の件を伝えておくと、不審な連絡への備えになります。

口座番号と名義が知られると預金を引き出されますか？

口座番号と名義だけで預金を引き出すことはできず、出金には暗証番号やインターネットバンキングの認証が必要なのが通常です。注意すべきは、その情報を添えて信用させ、暗証番号やログイン情報を聞き出そうとする連絡です。金融機関やイープラスが、メールやSMSで暗証番号を尋ねることはありません。不審な取引を見つけたら、まず口座のある金融機関に連絡してください。

自社の払戻し機能で同じ漏えいが起きたら委員会への報告は必要ですか？

不正アクセスによる漏えいは、個人情報保護法施行規則第7条第3号の「不正の目的をもって行われたおそれがある行為」による漏えいに当たり、件数にかかわらず報告の対象です。本人が1,000人を超える場合は第4号にも当たります。速報と確報の期限や様式は個人情報保護委員会の案内に、実務の流れは個人情報保護委員会への報告義務の解説にまとめています。

関連記事

• タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計：保存期間を決めずに重いデータを残した同型の事例
• 大和証券の不正アクセスと約11万人分の口座番号：問い合わせ管理の委託先に残さない設計：口座番号を伏せ字にして渡す実装の比較に
• 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説：本人以外の記録を返さない認可の実装に
• PeakManagerの個人情報漏えい｜DB侵害・外部転送とデータ削除の技術解説：DB監査ログで大量読み出しを検知する設定の補足に
• Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し：同時期に起きた利用者側の点検手順の比較に