晴れる屋2で2.8万件が閲覧可能 設定不備の7時間

【更新 2026-08-21】本記事を見直し、修正しました。主な修正点:出典に挙げた株式会社晴れる屋の公表文タイトルを実際の表記(「個人情報の閲覧可能状態に関するお詫びとご報告」)に修正し、IPA「中小企業の情報セキュリティ対策ガイドライン」のリンク先を同ガイドラインのページ(第4.0版・付録一式の掲載ページ)に差し替えました。あわせて、サービス名の公表状況に関する記述に要確認の注記を追加しています。

ポケモンカード専門店「晴れる屋2」を運営する株式会社晴れる屋は、抽選販売に応募した顧客の個人情報2万8490件が、外部から閲覧可能な状態になっていたと公表しました。原因は「設定の不備」。閲覧可能だったのは2026年7月23日の約7時間で、実際に外部からのアクセスが4件確認されています。

攻撃を受けたわけではありません。脆弱性を突かれたわけでもありません。「想定していない操作」をされたら見えてしまう状態で公開されていた、それだけです。そして情シスにとって厄介なのは、この種の応募フォームや当落確認ページが、多くの組織で情シスの資産台帳にも点検対象にも載っていないことです。

この記事でわかること

  • 晴れる屋2で何が起きたのか(公表された事実の整理)
  • 「設定の不備」で一覧データが見えてしまう典型的な3つの型
  • 抽選・キャンペーンフォームが情シスの盲点になる構造的な理由
  • 「アクセスは4件」と言い切れたことの実務的な意味
  • 個人情報保護法上の報告義務と、参照すべき公的指針

何が起きたのか

公表された事実を整理します。

公表者 株式会社晴れる屋(ポケモンカード専門店「晴れる屋2」運営)
公表日 2026年7月30日
対象 2026年7月20日~23日実施「スタートデッキ100 バトルコレクション」購入抽選の応募者
件数 2万8490件
閲覧可能だった情報 氏名、メールアドレス、電話番号、会員番号、抽選の申込店舗・当落結果
対象外の情報 クレジットカード情報、パスワード
閲覧可能だった期間 2026年7月23日 15時20分~22時28分(約7時間)
外部からのアクセス 4件(操作記録上、ダウンロードや複製は行われていない)
原因 「設定の不備」により、同社が想定していない操作を行うと閲覧できる状態だった
当局対応 発覚後ただちに個人情報保護委員会へ速報
顧客対応 対象者へメールで案内、500ポイントを付与

クレジットカード情報とパスワードが含まれていない点は、被害の質としては軽い部類です。ただし「氏名+電話番号+メールアドレス+当落結果」という組み合わせは、フィッシングや転売勧誘の標的リストとしてそのまま使える密度を持っています。「落選した人だけに追加販売を案内する」形の詐欺は、この情報があれば極めて自然に成立します。件数の少なさではなく、組み合わせの精度を見るべき事案です。

「設定の不備」とは具体的に何だったのか

具体的なサービス名・設定項目は公表されていません。 【要確認 2026-08-21:本記事が出典に挙げる Security NEXT は「応募はGoogleフォームで実施した」とサービス名を挙げて報じており、「まったく公表されていない」と言い切れるかは確認できていません。一方で株式会社晴れる屋の公表文にサービス名の記載はなく、Security NEXT の当該記載が同社の説明に基づくものか同誌の取材によるものかも確認できていません。確認すべき出典:晴れる屋の公表文(2026年7月30日)/Security NEXT「抽選販売の応募者情報が外部から閲覧可能に – トレカショップ」】公式発表は「設定の不備により、応募されたお客様の個人情報が、弊社が想定していない操作を行うことで」閲覧可能になった、と記載するにとどまります。ここは推測で断定すべきではないため、本記事でも特定のサービス名は挙げません。

一方で、応募データが一括で外部から見えてしまう事故には、実務上よく知られた型があります。自社を点検するうえでは、この3つを疑うのが現実的です。

  • 共有範囲の設定ミス:回答が蓄積される表計算ファイルや集計シートを「リンクを知っている全員が閲覧可」にしてしまう。URLさえ分かれば誰でも全件見える。
  • 認可チェックの欠落(いわゆるIDOR):当落確認ページで、URLのパラメータ(会員番号や連番のID)を書き換えると他人の結果が表示される。本人確認をURLの推測困難性だけに頼っている設計。
  • 公開領域へのファイル配置:当落一覧のCSVやPDFを、認証のかからないWeb公開領域に置いてしまう。検索エンジンに拾われることもある。

いずれも攻撃者の高度な技術を必要としません。ブラウザのアドレスバーを触れる程度の知識で到達できるのが、この種の事故の共通点です。だからこそ発覚が「善意の利用者からの指摘」になりがちで、その前に何人が見たかは分からないまま終わることも珍しくありません。

なぜ抽選フォームが情シスの盲点になるのか

答えは単純で、情シスを通らずに現場が立てるからです。販促の抽選、セミナー申込、採用エントリー、社内アンケート、健康診断の受診希望。これらはノーコードのフォームサービスを使えば数十分で作れます。稟議も要らず、サーバも借りず、開発チームも介在しません。

結果として次の状態が生まれます。

  • 資産台帳に載らない → 脆弱性診断や定期点検の対象にならない
  • 公開時の承認フローがない → 第三者の目でアクセス制御を確認する機会がない
  • 担当者が異動・退職すると管理者が不在になる → 止め方が分からないまま放置される
  • 個人情報を扱っている自覚が薄い → 保管期限も削除ルールもない

晴れる屋の再発防止策が「データアクセス制御の厳格化」に加えて「システム公開・設定変更における承認フローの徹底」「事前アクセス検証の義務化」「権限設定の定期監査」を挙げているのは、まさにこの構造に手を入れる内容です。技術の話ではなく、誰が公開してよいかを決める仕組みの話だと読み取れます。

自社に置き換えるなら、まず「この1年で現場が立てた、個人情報を集めるフォーム」を洗い出すことから始まります。外部から見えている自組織の資産を継続的に把握する考え方については、EASM(外部攻撃対象領域管理)の解説記事も参考にしてください。

「アクセスは4件」と言い切れたことの意味

この事案で実務的にもっとも注目すべきは、同社が「対象データへのアクセスが4件」「ダウンロードや複製は操作記録上、行われていない」と具体的に述べている点です。

これはアクセスログが残っていて、事後に読めたことを意味します。逆にログが無ければ、報告書はこう書くしかありません。「閲覧された可能性は否定できない」。この一文になった瞬間、対象2万8490人全員が「漏えいしたかもしれない人」になり、通知の範囲も、その後の問い合わせ対応の量も跳ね上がります。

設定ミスを完全には防ぎきれない前提に立つなら、ログの保全は「被害を小さくする」ためではなく「被害の範囲を確定できる」ための投資です。フォームサービスやクラウドストレージを業務で使う際、アクセスログが取得・保存できる設定になっているかを導入時点で確認しておくことをおすすめします。契約プランの都合でログが見られず影響範囲不明に陥る、という結末は避けたいところです。

外部からの指摘で初めて発覚した類似事案としては、生保協会で3.7万件が閲覧可能になっていた件も併せて読むと対比が分かりやすいはずです。

個人情報保護法上、報告義務はどうなるのか

1000人を超える個人データの漏えい等が発生した場合、個人情報保護委員会への報告と本人への通知が義務づけられます。2万8490件は当然これに該当します。

報告対象となる事態 要配慮個人情報の漏えい等/財産的被害のおそれがあるもの/不正の目的によるおそれがあるもの/1000人を超える漏えい等(いずれかに該当)
速報 事態を知った時点から概ね3~5日以内
確報 原則30日以内(不正の目的によるおそれがある場合は60日以内)
本人への通知 速やかに行う(個人情報保護法上の義務)

晴れる屋は発覚後ただちに速報を実施し、対象者へメールで案内しています。ここは手順どおりです。実務で問題になるのは「事態を知った時点」を組織として確定できるかどうかで、現場が気づいてから情シス・法務に上がるまでに数日溶けると、速報の3~5日はあっという間に消えます。第一報の受け口と、受けた時刻をその場で記録する運用を先に決めておく必要があります。報告実務の流れはJSTの不正アクセス事案の記事でも触れています。

現場目線の所感:止められたのは、誰かが気づいたから

15時20分に露出が始まり、22時28分に止まっています。約7時間。日中に始まり夜に停止されたこの時間差からは、自動検知の仕組みが鳴ったというより、人が気づいて手で止めた気配を感じます。実際の経緯は公表されていないので断定はできませんが、この規模の小売事業者で、フォームの公開範囲を常時監視する仕組みを持っているところは多くないはずです。

正直なところ、情シスの立場で一番つらいのはここです。現場が善意と熱意で立てた仕組みは、たいてい速い。速いから止められない。そして情シスが存在を知るのは、たいてい事故のあとです。「勝手にフォームを作るな」と通達を出しても、業務のスピードには勝てません。現実的な落としどころは禁止ではなく、「個人情報を集めるなら、この決まった作り方で」という道を先に用意しておくことだと考えています。承認フローを1枚のチェックリストにして、公開前に第三者が実際にURLを叩いて確認する。それだけで今回の型の事故はかなり減ります。手順の曖昧さがそのまま事故につながった例は、デジタル庁の150人分漏えいの件でも見たとおりです。

情シスはどうすべきか

自前で長大なチェックリストを作るより、公的機関がすでに整理した指針を土台にするほうが確実です。以下を出発点にしてください。

  • IPA「中小企業の情報セキュリティ対策ガイドライン」:付録の各種様式に、情報資産の洗い出しとリスク分析の雛形があります。「現場が立てたフォーム」を資産として登録する作業の下敷きに使えます。
  • 個人情報保護委員会「漏えい等の対応」:報告義務の判断と、速報・確報の様式はここが一次情報です。事故が起きてから読むのでは間に合わないので、平時に一度目を通しておく価値があります。
  • IPA「対策のしおり」:現場部門への啓発資料として配りやすい形式です。「個人情報を集めるフォームを作る前に情シスへ相談する」という文化は、通達より地道な啓発のほうが定着します。

そのうえで、今日から手を動かせることを1つだけ挙げるなら、「公開前に、社内アカウントからログアウトした状態でURLを開いてみる」の徹底です。設定の不備の多くは、作った本人がログイン済みのブラウザで確認しているために見逃されます。シークレットウィンドウで開く、スマートフォンの回線で開く。これだけで「リンクを知っていれば誰でも見える」状態はかなり発見できます。

まとめ

  1. 攻撃ではなく設定の不備で2万8490件が約7時間、外部から閲覧可能になった。氏名・電話番号・メールアドレス・当落結果という組み合わせは、標的型のフィッシングにそのまま使える精度を持つ。
  2. 抽選・申込フォームは情シスの台帳に載らないまま個人情報を集めている。公開前の承認と、第三者による実アクセス検証を仕組みとして持つことが、この型の事故に最も効く。
  3. アクセスログが残っていたから「4件」と言い切れた。ログが無ければ全件が「漏えいの可能性あり」になる。ログの保全は影響範囲を確定するための投資である。

出典

タイトルとURLをコピーしました