EPARK予約基盤侵害、3300万レコード漏えいか

【更新 2026-08-06】本記事を見直し、修正しました。主な修正点：同社第一報の「対応状況」に記載されている削除データの復旧作業完了・バックアップDBへの切替え等を追記しました。

株式会社EPARKリラク＆エステは2026年7月31日、同社が提供する予約・顧客管理プラットフォーム「PeakManager」のデータベースが不正アクセスを受け、約3300万レコードの個人情報が外部に漏えいした可能性があると公表しました。同社は7月27日に、不正アクセスに加えてデータベース上の顧客情報が削除されていることも確認したとしています。

PeakManagerは導入実績2000店舗を超えるサロン向けの業務基盤です。つまりこれは1社のサイトが落ちた話ではなく、多数の事業者が顧客データを預けている共有基盤が丸ごと侵害された事案です。自社でSaaSに顧客情報を預けている情シスにとって、他人事にできる構図ではありません。

この記事でわかること

  • 公表された事実と、まだ公表されていないことの切り分け
  • 「3300万レコード」を人数として読んではいけない理由
  • 委託先（SaaS事業者）で漏えいが起きたとき、報告義務は誰が負うのか
  • 「暗号化されたパスワード」という公表表現の読み方
  • 自社のSaaS利用について、今日確認できること

何が起きたのか

同社の第一報（2026年7月31日付）にもとづく経緯は次のとおりです。

日付 内容
2026-07-27 PeakManagerの一部データベースへの不正アクセスと、保存されていた顧客情報が削除されていることを確認
2026-07-30 個人情報保護委員会へ報告
2026-07-31 第一報を自社サイトで公表、利用者にパスワード変更を要請
2026-08-03〜05 各社が報道

漏えいした可能性がある情報は、氏名、生年月日、性別、住所、電話番号、メールアドレス、暗号化されたパスワード等です。クレジットカード情報とマイナンバーは含まれていないと明記されています。対象人数は「改めて調査後に報告」とされ、執筆時点では未公表です。侵入経路も公表されていません。

発覚から公表までの日数はどう評価すべきか

発覚（7月27日）から委員会報告（7月30日）まで3日、公表まで4日です。個人情報保護委員会は速報の期限を「速やか（概ね3〜5日以内）」としており、少なくとも速報のタイムラインは指針の範囲に収まっています。国内インシデントでは発覚から公表まで1か月以上かかる例も珍しくないため、この点は評価できます。

「3300万レコード」は3300万人ではない

報道では「3300万件の個人情報」という見出しが並びますが、同社が公表しているのはレコード数であり、人数ではありません。予約管理システムのテーブル構造上、1人の顧客が来店のたびにレコードを持つ設計であれば、レコード数は実人数の何倍にもなります。同社が対象人数を別途調査中としているのは、まさにこの理由からです。

なお、セキュリティ関連メディアは、攻撃者を名乗る人物がハッキングフォーラム上で「約3251万行を取得し、重複除去後は約611万行」と主張していると報じています。これは第三者の裏付けが取れていない未確認の主張であり、同社は言及していません。数字を鵜呑みにはできませんが、レコード数と実人数が大きく食い違いうるという点だけは押さえておく価値があります。

この違いは実務に直結します。個人情報保護法の報告対象4類型のうち「1000人を超える漏えい等」は人数基準ですが、今回は「不正の目的をもって行われたおそれがある事態」にも該当すると考えられ、人数の確定を待たずに報告義務は発生します。人数基準はあくまで4類型のうち1つに置かれているにすぎません。

データが「削除されていた」ことの意味

今回の公表で見落とされがちなのが、持ち出しだけでなくデータベース上の顧客情報が削除されていたという記述です。報道の見出しは漏えいに寄っていますが、削除を伴う侵害は情報漏えいと事業継続の問題が同時に起きている状態です。予約と顧客履歴が消えれば、加盟店の当日の営業そのものが止まります。

削除の意図（恐喝目的か、痕跡消しか）は公表されておらず、外部から断定はできません。なお同社は第一報の「対応状況」で、削除されたデータの復旧作業が完了し、対象データベースの運用停止とバックアップデータベースへの切替え、新サーバー・新データベースへの移管も完了したと公表しています。ただし情シスの教訓としては明確で、「侵害＝データが読まれる」だけを想定した対策では足りないということです。バックアップが同じ権限で到達できる場所にあれば、同時に消されます。復旧手順を持っているか、そのバックアップは攻撃者から隔離されているかは、今日自社で確認できる項目です。

委託先で漏えいが起きたら、報告義務は誰にあるのか

SaaSに顧客データを預けている企業の担当者が最初に確認すべき論点がここです。個人情報保護委員会のFAQは明快で、委託先で漏えいが発生した場合、原則として委託元と委託先の双方が報告義務を負います。そのうえで、委託先が委託元へ事態の発生を通知した場合には、委託先の報告義務は免除されます（個人情報保護法第26条第1項ただし書、施行規則第9条）。連名での報告も可能とされています。

読み替えると次のようになります。

  • SaaS事業者が公表したから自社の対応は不要、とはならない。自社が委託元にあたるなら、委員会への報告と本人への通知は自社の義務として残る
  • そのためには委託先からの一報が必要になる。委員会は委託時に報告連絡体制を整備しておくことを求めている
  • 原因調査と、必要に応じた委託先への改善要求も委託元の責務に含まれる

ただし、その事業者が法的に「委託先」なのか、それとも自ら個人情報を取得している別の個人情報取扱事業者なのかは、契約と実態で決まります。今回の件についても、加盟店との関係がどちらに整理されているかは公表情報からは確認できません。自社が使っているSaaSがどちらなのかは、契約書と個人情報の取得経路を見れば判断できます。インシデントが起きてから調べる項目ではありません。

報告期限の目安

速報は概ね3〜5日以内、確報は発覚日から30日以内（不正の目的をもって行われたおそれがある場合は60日以内）です。今回は後者に該当すると考えられるため、続報が出てくるのは2026年9月下旬ごろが一つの目安になります。取引先やサービス提供元がインシデントを公表したときは、この期限を手帳に書いておくと、詳細が判明する続報を取りこぼしません。

「暗号化されたパスワード」をどう読むか

公表文には「暗号化されたパスワード」とあります。ここは注意が必要で、暗号化（復号できる）とハッシュ化（原則復号できない）は別の処理です。公表文の表現だけでは、実際にどちらの方式で保管されていたのか、ソルトやストレッチングが施されていたのかは判別できません。第一報の段階で技術的な詳細まで求めるのは酷ですが、利用者側から見れば「安全だ」と読み取れる材料にはなっていません。

実務上の帰結は変わりません。同じパスワードを他サービスで使い回していれば、その他サービスが危険にさらされます。従業員が業務用メールアドレスでこの種のサービスに登録している可能性もあるため、社内向けには「同一パスワードを社内システムで使っていないか」という観点での注意喚起が有効です。パスワードの使い回しがなぜ根絶できないのかについては、パスワード使い回しの心理を扱った記事も参考にしてください。

現場目線の所感

この手の事案でいつも重いのは、自社が把握していないSaaSに顧客データが載っているという現実です。予約システムや顧客管理ツールは、情シスではなく事業部門や店舗運営側が契約することが多く、稟議に情シスの押印欄がないまま本番運用に入っていることがあります。今回の構図でいえば、2000店舗を超える導入先の情シス担当者のうち、何割が「自社の顧客データがどこに、どんな形で置かれているか」を即答できるでしょうか。

そして、こうした基盤は侵害されても自社側のログには何も残りません。データは相手先のクラウドにあり、監視も認証もこちらの手が届かない場所で動いています。契約書の中の「セキュリティに関する事項」という一節が、実質的に唯一の統制点になっている——という状態は、決して珍しくないはずです。だからこそ、平時に棚卸しと連絡体制の確認をしておくしかない、というのが率直な実感です。

情シスは何をすべきか

個別の対策リストを一から作るより、公的機関の枠組みに沿って整理するのが早道です。委託先管理と漏えい時の初動については、次の一次情報が実務でそのまま使えます。

そのうえで、今日中にできる確認は次の3点です。

  1. 顧客の個人データを預けている外部サービスを列挙する。情シス契約分だけでなく、事業部門・店舗・広報が契約したものを含める
  2. 各サービスの契約書で、インシデント時の通知義務と連絡先を確認する。「速やかに通知する」としか書かれていなければ、期限の明記を次回更新時の交渉項目にする
  3. そのサービスが委託先なのか、別の事業者なのかを整理する。報告義務の所在が変わるため、法務・個人情報保護責任者と共有しておく

あわせて、利用者・従業員向けの啓発も地道に続ける価値があります。パスワードの使い回しをやめる、公表元を名乗る不審なメールや電話に応じない、といった基本の徹底が、この種の大規模漏えい後の二次被害を確実に減らします。

まとめ

  1. EPARKリラク＆エステの予約・顧客管理基盤「PeakManager」が不正アクセスを受け、約3300万レコードが漏えいした可能性がある。データベース上の顧客情報が削除されていたことも確認されており、漏えいと事業継続の問題が同時に発生している
  2. 公表されているのはレコード数であり人数ではない。人数の確定を待たずに報告義務は発生しうるため、「人数がわからないから待つ」という判断は成り立たない
  3. 委託先で漏えいが起きた場合、原則として委託元と委託先の双方が報告義務を負う。SaaS事業者が公表しても委託元の義務は消えない。平時にサービスの棚卸しと連絡体制の確認をしておく

関連記事

出典

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