公開2026.08.03更新2026.10.31 40 人が閲覧（直近 30 日）脆弱性・インシデント

PeakManager（ピークマネージャー）の個人情報漏えい｜2,218万レコードの第二報とログイン・パスワード対応、DB侵害の技術解説

EPARKリラク＆エステは2026年7月31日、整体院やリラクゼーションサロン向けの予約・顧客管理プラットフォーム「PeakManager（ピークマネージャー）」が不正アクセスを受け、顧客情報が漏えいした可能性があると第一報で公表しました。9月24日の第二報では、フォレンジック調査の結果、顧客情報を保管するデータベースの情報が外部へ転送され、その後にデータが削除されたことが確認されています。対象は精査後で約2,218万レコード。項目は氏名・生年月日・住所・電話番号・メールアドレスと、加盟店が入力した備考欄の記載（健康状態等の要配慮個人情報を一部含む）です。

本記事は2026年10月24日時点の公表内容をもとに、確定した事実、利用者が気にする「ログインできない」「パスワードを変えるべきか」「0120-206-460は本物か」への答え、外部転送と削除が同時に起きた侵害の構造、DB権限と監査ログの設計、漏えい等報告の期限と店舗側の義務までを扱います。

まとめ：PeakManager個人情報漏えいの要点と利用者・実装側の初動

事案と規模：7月27日に不正アクセスとデータ削除を確認、7月30日に個人情報保護委員会へ報告、7月31日に第一報、9月24日に第二報。外部転送が確認され、対象は約2,218万レコード（人数への換算は困難と同社は説明）。10月24日時点で第三報は出ていません。
漏えい項目：氏名・フリガナ・生年月日・性別・住所・電話番号・メールアドレスと備考欄の記載。備考欄には要配慮個人情報が一部含まれ、カード情報に該当する可能性のある記載が5件（いずれも有効期限経過）ありました。
利用者がすること：マイページのパスワードを変え、同じパスワードを使っている他サービスも変える。問い合わせは公式の事案窓口0120-206-460（平日10時から17時）。同社はメールやSMSでカード番号を聞かないと明言しています。
EPARK本体は対象外：親会社のEPARKは8月4日、不正アクセスを受けたのはPeakManagerであり、EPARKブランド各社のシステムは対象ではないと告知しています。
技術的な本質：データベースそのものに到達され、持ち出されたうえで消された事案。機密性と可用性が同時に壊れています。侵入経路と手法は非公表です。
設計の主戦場：アプリ用DBアカウントから削除権限を外す最小権限設計、自由記述欄への機微情報の流入対策、DB監査ログの取得と外部保全。この3つが被害範囲と調査の可否を決めます。
法対応：要配慮個人情報（1号）・不正目的のおそれ（3号）・1,000人超（4号）に当たりうる構図。速報は概ね3〜5日以内、確報は3号に当たれば60日以内。予約データの取扱いを委託している店舗にも、原則として報告義務が及びます。

PeakManager不正アクセス事案の第一報・第二報で確定した事実と2,218万レコード

7月27日の削除確認から9月24日の第二報までの時系列

同社のお知らせ一覧に載っているPeakManager関連の発表は、10月24日時点で第一報と第二報の2本だけです。

日付	発表主体・出来事	内容
2026年7月27日	EPARKリラク＆エステが確認	DBへの不正アクセスとデータ削除
2026年7月30日	個人情報保護委員会へ報告	個人情報保護法に基づく報告
2026年7月31日	第一報	約3300万レコード漏えいの可能性
2026年8月4日	親会社EPARKの告知	EPARKブランド各社のシステムは対象外
2026年9月24日	第二報（最新）	外部転送を確認、約2,218万に精査

第一報の時点で完了済みとされた対応は5つです。削除データの復旧、対象データベースの運用停止とバックアップデータベースへの切り替え、不正利用されたデータベース接続用アカウントの停止、データベースとサーバーの認証情報の変更、新サーバー・新データベースへの移管。「接続用アカウントが不正利用された」ことは公表されていますが、DBへの直接接続か、侵害されたアプリケーションなどを経由した操作かは、公表内容から判別できません。

約3300万から約2,218万レコードへ精査された内訳と人数換算の壁

第二報によれば、PeakManagerは各店舗が独自に顧客情報を入力する台帳で、登録時の必須項目は氏名のみ、電話番号とメールアドレスは任意入力です。同社は電話番号かメールアドレスが一致するものを同一人物とみなして名寄せし、約2,218万レコードまで絞りました。連絡先が未登録の行は、同名でも別レコードとして残っています。そのため、2,218万を人数に置き換えることは困難だと同社は判断しています。

名寄せのキーが任意項目しかない台帳では、同じ人が店舗ごとに別の行として残ります。マルチテナントのSaaSでは、店舗別の対象レコードを抽出できる設計と、本人を識別できる範囲の把握が必要です。テナント横断の名寄せは、利用目的とアクセス権限を確認したうえで検討します。この件数の不確かさは、後で述べる本人への通知の難しさに直結します。

ダークウェブ上の犯行声明が主張する3251万行という未確認の情報

セキュリティ対策Labの報道によれば、ハッキングフォーラムに犯行声明とみられる投稿がありました。投稿側は、2026年7月19日にpeakmanager.jpへ侵入し、総行数32,510,060行（圧縮状態で3.14ギガバイト）を保持していると主張しています。さらに電話番号をキーに重複を除き、宛先と電話番号が空欄の行を除いた「加工済みデータ」611万8016行を持つとし、ソースコードや内部ネットワークへのアクセス権の販売にも触れていました。

これらは裏付けの取れていない主張で、第二報も犯行声明に触れていません。投稿側の611万8016行と同社の2,218万レコードは、集計対象と重複除外の条件が一致するかを確認できないため、両者を比べて人数を推し量ることはできません。

EPARK本体の会員情報が対象かどうかと親会社の8月4日告知

「EPARK 個人情報流出」で検索する人が気にしているのは、病院や飲食店の予約に使うEPARK会員の情報まで漏れたのかという点でしょう。親会社の株式会社EPARKは2026年8月4日の告知で、不正アクセスを受けたのは連結子会社のEPARKリラク＆エステが加盟店向けに提供するPeakManagerであり、EPARKおよびEPARKブランドを展開する各事業会社のシステム・情報基盤への不正アクセスではないと説明しています。

EPARK会員であっても、PeakManagerを導入したサロンや整体院に通い、その店で顧客登録されていれば、その店舗の台帳が対象に含まれる可能性はあります。判断の軸はEPARK会員かどうかではなく、PeakManagerを使う店舗に情報を預けたかどうかです。

PeakManagerにログインできない時とパスワード変更・0120-206-460の確認

ログインできない場合の確認手順、パスワード変更の対象、公式問い合わせ窓口を整理します。公表文に書かれていることと書かれていないことを分けて答えます。

マイページのパスワード変更と第一報・第二報で異なる漏えい項目

第一報は、漏えいした可能性のある情報に「暗号化されたパスワード」を挙げ、そのパスワードはPeakManagerのマイページにアクセスするためのものだとして、利用者に変更を依頼しました。一方、第二報が「漏えいした項目」として示した一覧にパスワードは入っていません。第二報はこの差を説明していないため、パスワードが持ち出されなかったと読むことはできません。

利用者の結論は変わりません。マイページのパスワードは変更し、同じ文字列を他のサービスでも使っているなら、そちらを先に変えてください。攻撃者はメールアドレスとパスワードの組を、ECサイトや金融機関に順に試すリスト型攻撃に転用します。

ログインできないときに確かめる順番と問い合わせ先

2026年10月24日時点で、第一報・第二報ともに利用者のログイン停止やパスワードの一斉リセットには触れていません。第一報が「変更の完了」としたのはデータベースとサーバーの認証情報であり、利用者や店舗スタッフのパスワードではありません。ログインできない原因を事案と結び付けて断定できる公表情報はないため、次の順で切り分けます。

店舗スタッフ（管理画面）：PeakManagerのよくある質問は、管理画面の推奨環境をWindows・MacともにGoogle Chromeの最新版としています。iPadの標準ブラウザやスマートフォン（iOS・Android）での動作は保証外です。パソコンのChromeで開き直し、それでも入れなければ導入時に案内されたサポート窓口へ連絡します。
店舗スタッフ（権限）：同じFAQによれば、本部・オーナー・店長・スタッフ別に閲覧権限を設定できます。自分のアカウントだけ入れない場合は、事案後の棚卸しで権限が変更・停止されていないかを店舗の管理者に確認します。
来店客（マイページ・お店アプリ）：会員アプリやマイページは店舗ごとに提供されています。パスワード再設定の手順が分からなければ、通っている店舗に問い合わせます。

事案そのものについての問い合わせ先は、第一報・第二報が共通して示すPeakManager事業部（電話0120-206-460、メール[email protected]、平日10時から17時、土日祝日を除く）です。

0120-206-460は公式窓口か・不審な連絡の見分け方

0120-206-460は、EPARKリラク＆エステが第一報と第二報の両方で「本件に関するお問い合わせ先」として掲載している番号です。着信やSMSでこの番号を見かけた場合でも、折り返す前にepark-relax.co.jpのお知らせに載っている番号と一致するかを自分で確かめてください。

見分ける基準は、第二報の「お客様へのお願い」にあります。同社は本件の対応を理由に、メールやSMSでクレジットカード番号やセキュリティコードの回答・入力を求めることはないと明記しています。カード情報や暗証番号を求める連絡は、名乗りが同社でも金融機関でも応じないことです。漏えいした氏名・電話番号・住所を添えて信用させる手口が想定されるため、本人の情報を正しく言い当てたことは本物の根拠になりません。同じ型の注意喚起はイエローハット情報漏洩の第二報でも、窓口番号の確認方法として整理しています。

外部転送の後にデータ削除まで及んだ侵害で機密性と可用性が同時に壊れる構造

「情報漏えい」と報じられる事案の多くは、データを読まれた話です。今回は外へ運ばれたうえで消えています。

外部転送と削除の両方が確認された事実が示す顧客DB侵害の到達点

公表されているのはデータの外部転送と削除であり、DELETEやDROPなどの具体的な操作は明らかにされていません。SQLインジェクションでも、接続アカウントの権限次第でデータの更新や削除が可能です。侵入経路が非公表の本件では、アプリケーションとDBの両方を点検対象にします。ログインしていないゲストに参照権限が誤って付いていた型は生命保険協会の情報漏洩で、管理基盤を経由して内部に到達された型はさくらインターネットの不正アクセスで扱っています。

同社は削除データを復旧済みと公表しており、バックアップは機能しました。ただ、持ち出したうえで消す攻撃では、復旧できなければ事業が止まり、復旧できても持ち出された情報は戻りません。持ち出されて困る情報を減らすには、用の済んだデータを溜めないことが先になります。問い合わせデータの保持期限を点検して個人情報を消すPythonの例は、ヤクルトの不正アクセスで示しています。

バックアップの世代管理と復旧演習が事業継続の可否を分ける判断基準

バックアップが「取れている」ことと「戻せる」ことは別物です。本番DBと同じ認証情報でバックアップ領域にも書き込める構成なら、攻撃者はバックアップごと消せます。本番DBの認証情報では触れない領域へ退避し、オブジェクトストレージのバージョニングとオブジェクトロックで書き換えを防ぎます。そのうえで、四半期に1回は実データ量で復旧手順を通し、目標復旧時間に収まるかを測ってください。手順書があっても、2,000万行規模の復元にかかる時間を測った記録がなければ、障害時の見積もりは当て推量になります。

自由記述の備考欄に要配慮個人情報とカード情報が入り込む設計上のリスク

第二報で設計者が最も学ぶべき点は、「持っていないはず」の情報が漏えい項目に加わった経緯です。

カード入力欄がない設計でも備考欄に5件が記載された第一報訂正の経緯

第一報は、対象データベースにクレジットカード情報は含まれていないと説明していました。第二報はこれを訂正し、備考欄を精査した結果、カード情報に該当する可能性のある記載が5件あったと公表しています。PeakManagerには設計上カード情報を入力する項目がなく、備考欄に任意で書かれたもので、実在するカードかどうかは確認されておらず、いずれも有効期限は経過しています。

同じ備考欄には、加盟店が施術の申し送りとして入力した健康状態等の情報も含まれていました。整体院・接骨院・鍼灸院の申し送りとしては自然な記述ですが、個人情報保護法上は要配慮個人情報に当たりえます。スキーマ上は「備考」という1列でも、中身は事業者が想定した以上に機微です。

備考欄の入力制御と閲覧権限の分離で機微情報の露出を減らす設計

自由記述欄を持つ業務システムでは、入力時の検知、用途別の欄と権限の分離、既存データの走査を組み合わせます。

入力時の検知：カード番号らしき数字列（13〜19桁でチェックディジットが合うもの）やマイナンバーらしき12桁を保存前に検出し、保存を拒否するか警告する
用途ごとの欄の分離：健康状態の申し送りが業務上必要なら専用の欄に切り出し、閲覧できる役割を施術担当者に絞り、列単位で暗号化する
定期的な走査：既存データを月次で走査し、想定外の機微情報が入っていないかを数える

数字列の検知は対策の一部です。表記揺れによる見逃しや誤検知を検証し、健康情報など数字列では判別できない情報には、入力ルールと閲覧権限の制御を組み合わせます。欄の分離は要配慮個人情報を扱う前提で設計し直すことを意味し、手間はかかりますが、漏えい時の報告類型と影響の重さを左右します。自由記述欄は「最も機微な情報が入る欄」として権限と暗号化を決めてください。

暗号化されたパスワードという公表表現が実装上で指しうる3つの状態

第一報の「暗号化されたパスワード」という一語からは、実装として何を指すのかが判別できません。日本語の公表文ではパスワードの保護方式を「暗号化」と総称する例が多いものの、鍵があれば平文に戻せる可逆な暗号化と、戻せない一方向ハッシュは別物です。

保護方式	平文への復元	DB奪取時の実害
可逆な暗号化	鍵があれば可能	鍵の所在次第で全件露出
ソルトなしのハッシュ	不可（照合は可能）	レインボーテーブルで特定
ソルト＋ストレッチング	不可（推測・照合は可能）	攻撃費用は方式・設定・パスワード強度次第

DBを掌握した攻撃者がサーバー側の鍵にも到達していれば、可逆な暗号化は平文と同じです。方式が明示されない以上、利用者は最悪のケースを前提に動くほかありません。

実装側の基準は明確です。OWASP Password Storage Cheat SheetはArgon2idを第一候補とし、最小構成としてメモリ19MiB・反復2回・並列度1を示しています。bcryptはArgon2idやscryptを使えない既存システム向けで、ワークファクター10以上、入力は72バイトまでという制約付きです。提供者側は、影響を受けたアカウントのセッションを全失効させ、次回ログイン時にパスワード再設定を強制する方式が確実です。パスワード単体に依存しない認証へ移すなら、多要素認証（MFA）の実装方式と耐フィッシングMFAの選び方を並行して検討してください。

DBアカウントの権限分離と踏み台経路の遮断による侵入後の被害限定

侵入をゼロにする設計は存在しません。設計で決められるのは、侵入されたあとにどこまで被害が広がるかです。

アプリ用DBアカウントから削除権限を外す最小権限アカウントの設計

予約・顧客管理システムのアプリケーションが、顧客テーブルの全件削除を必要とする場面はほぼありません。開発初期に作った所有者権限のアカウントを本番の接続に使い続ける構成は、見直しの対象です。

アプリ用・バッチ用・管理用でDBアカウントを分け、アプリ用にはSELECT・INSERT・UPDATEだけを付与する。
物理削除をやめて削除フラグによる論理削除に切り替え、保持期間を過ぎたデータの物理削除はバッチ用アカウントで対象を限定して行う。
スキーマ変更の権限は移行作業のときだけ発行し、作業後に取り消す。
接続元をアプリケーションサーバーのプライベートIPに限定し、DBを公衆網に出さない。

PostgreSQLでの1の作業例です。app_userはアプリ用ロール名の例です。PostgreSQLの権限の仕様では、オブジェクトを削除・変更する権利は所有者に固有のもので、GRANTやREVOKEの対象になりません。所有者は自分の権限をREVOKEしても再付与できます。アプリ用ロールがテーブルの所有者なら、先に所有権を管理用ロールへ移してください。必ず検証環境で試してから本番に当てます。

-- 0) テーブルの所有者がアプリ用ロールになっていないか確認する
SELECT tablename, tableowner FROM pg_tables WHERE schemaname = 'public';

-- 1) 所有者なら管理用ロールへ移す（テーブルごとに実行）
ALTER TABLE customers OWNER TO app_admin;

-- 2) アプリ用ロールから削除・切り詰めの権限を外す
REVOKE DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public FROM app_user;

-- 3) PUBLICや継承ロールを含む実効権限を確認する
SELECT c.oid::regclass AS table_name,
       has_table_privilege('app_user', c.oid, 'DELETE') AS can_delete,
       has_table_privilege('app_user', c.oid, 'TRUNCATE') AS can_truncate
  FROM pg_class AS c
  JOIN pg_namespace AS n ON n.oid = c.relnamespace
 WHERE n.nspname = 'public'
   AND c.relkind IN ('r', 'p')
 ORDER BY table_name;
-- 両列がfalseであることを確認する。trueなら権限の付与元も見直す。
-- 以下はapp_userに直接付与された権限の補助確認
SELECT table_name, privilege_type
  FROM information_schema.role_table_grants
 WHERE grantee = 'app_user'
 ORDER BY table_name, privilege_type;

直接付与の一覧だけで合否を決めない理由は、PostgreSQL 18.6で再現できます。PUBLICにDELETEを付与したテーブルでapp_userからDELETEとTRUNCATEをREVOKEすると、role_table_grantsにはINSERT・SELECT・UPDATEの3行しか出ませんが、has_table_privilegeはcan_deleteをtrue（t）で返しました。PUBLICや所属ロール経由の権限は、実効権限の関数で確かめる必要があります。

所有者権限とDELETE・TRUNCATEの実効権限を外せば、それらによる削除を制限できます。ただし、UPDATEによる全件上書きや論理削除、権限付き関数の実行などによるデータ破壊は別途防ぐ必要があります。1のアカウント分離から点検し、2の論理削除は改修費用、保持期間、物理削除の運用まで確認して採否を決めます。

踏み台サーバーと管理接続経路をIP許可リストで絞り込む実装の要点

DBへの接続元を限定すれば、許可されていない場所からの接続を遮断できます。ただし、許可済みのアプリケーションサーバーや踏み台が侵害された場合は、DBへ到達される可能性が残ります。管理接続は踏み台サーバー経由に一本化し、踏み台への到達をIP許可リストとMFAで二重に絞ります。AWSなどのセキュリティグループでは、DBや管理接続用ポートに、全IPv4アドレスを許可する0.0.0.0/0や全IPv6アドレスを許可する::/0が残っていないかを確認してください。

同社は新サーバー・新データベースへの移管を完了したと公表していますが、侵入経路は10月24日時点で公表されていません。経路を特定しないまま移管すれば、同じ経路で新環境にも到達されます。旧環境から運ぶソースコード・設定ファイル・環境変数・SSH公開鍵・APIトークンの棚卸しを、移管と同じ優先度で行う必要があります。

不正アクセスの早期検知と事後調査を支える監査ログの設計

公表されているのは7月27日に不正アクセスと削除を確認したことまでで、検知のきっかけは明らかではありません。削除を伴わない持ち出しは画面上の異変として現れないため、DB側の記録がなければ気づく手段がありません。

DB監査ログで大量読み出しと削除操作を検知する設定と条件

アプリケーションのアクセスログには、DBへ直接接続された操作は記録されません。必要なのはデータベース自身の監査機能です。PostgreSQLならpgAuditを使います。pgAuditはshared_preload_librariesで読み込まないとロード時にエラーとなり、監査ログは記録されません。導入には対応するpgAuditのインストールが必要です。既存のshared_preload_librariesの値を保持してpgauditを追加し、サーバーを再起動します。その後、監査対象の各データベースでCREATE EXTENSION pgauditを実行してから、pgaudit.logを設定します。

# postgresql.conf（変更後は PostgreSQL の再起動が必要）
# 既存の値があればカンマ区切りで追加する（例：'pg_stat_statements,pgaudit'）
shared_preload_libraries = 'pgaudit'

-- 再起動後、監査対象のデータベースでスーパーユーザーとして実行する
CREATE EXTENSION pgaudit;
-- write は INSERT・UPDATE・DELETE・TRUNCATE、ddl は role 以外のDDL、role は GRANT・REVOKE とロール操作
ALTER SYSTEM SET pgaudit.log = 'write, ddl, role';
SELECT pg_reload_conf();

readクラスを加えるとSELECTとCOPYの読み出しも記録できますが、参照の多い予約システムではログ量が大きく増えます。まず書き込み系とスキーマ変更を記録し、ログ量を測ってから範囲を広げてください。

取得しただけでは検知になりません。設定すべき検知条件は3つです。第一に、アプリ用アカウント以外からの接続。第二に、通常のアプリ処理では起きない行数の読み出しです。これをpgAuditで検知するには、readクラスの監査に加えてpgaudit.log_rows = onを設定し、通常時の取得行数を測ってしきい値を決めます。第三に、DELETEやTRUNCATEの実行そのもの。論理削除へ移行済みなら、3つ目は発生しただけで異常と判定できます。

ログの外部保全と改ざん防止がインシデント調査の成否を左右する理由

DBサーバー上にしかログがない構成は、サーバーを掌握された時点で調査手段を失います。ログは生成直後に別アカウント・別リージョンの保管先へ転送し、書き込み後は変更できない設定にします。本件では第二報まで約2か月を要し、侵入経路は公表されていません。ログが残っていたかどうかは公表文から分かりませんが、外部に保全されたログがあれば調査の時間は短くなります。踏み台の認証ログ、アプリのアクセスログ、DBの監査ログを1か所に集めて相関させる体制はSOCとSIEM・SOARの役割の違いで整理しました。

個人情報保護法の漏えい等報告と本人通知で事業者・店舗が負う期限と義務

要配慮個人情報と不正目的と1,000人超が重なる報告類型と期限

個人情報保護委員会の通則ガイドラインによれば、報告義務の対象となる事態は施行規則7条の4つです。要配慮個人情報が含まれる漏えい等（1号）、財産的被害が生じるおそれがある漏えい等（2号）、不正の目的をもって行われたおそれがある行為による漏えい等（3号）、本人の数が1,000人を超える漏えい等（4号）。本件は備考欄の要配慮個人情報、第三者の不正アクセス、2,218万レコードという規模から、1号・3号・4号に当たりうる構図です。

速報は事態を知った後「速やかに」で、ガイドラインはその目安を概ね3〜5日以内としています。確報は30日以内、3号に当たる場合は60日以内で、3号と他の号が重なる場合も60日以内です。7月27日の確認から7月30日に委員会へ報告した流れは、速報の目安に収まっています。法律全体の構造は個人情報保護法の定義と事業者の義務で解説しています。

予約データの取扱いを委託した店舗にも報告義務が及ぶ委託元・委託先の関係

同じガイドラインは、個人データの取扱いを委託している場合、原則として委託元と委託先の双方が報告義務を負うとしています。連名での報告もでき、委託先が委託元へ速やかに通知した場合は委託先の報告義務と本人への通知義務が免除され、通知を受けた委託元が報告します。PeakManagerのように店舗が自店の顧客台帳を外部のSaaSに入力している形が委託に当たるなら、報告義務は店舗側にも及びます。

利用店舗が確認すべきなのは、自店に事業者から通知が届いているか、そしてPeakManagerとの契約上の位置づけです。判断に迷う場合は、個人情報保護委員会の相談窓口に契約内容を示して確認してください。自店だけで報告の要否を決めつけないことです。

連絡先のないレコードと本人への通知で詰まる箇所

報告とは別に、本人への通知義務があります。ガイドラインは、保有する個人データに本人の連絡先が含まれていない場合などを「通知が困難な場合」とし、事案の公表や、本人が自分のデータが対象かを確認できる問い合わせ窓口の公表を代替措置として挙げています。本件でも、住所を含む利用可能な連絡先を確認したうえで、本人への通知が困難な対象について代替措置を検討します。連絡可能な対象まで一律に公表だけで済ませられるわけではありません。

SaaS事業者が準備しておくべきは2点です。1つは、テナントIDで対象レコードを抽出し、店舗単位で影響範囲を切り出せるデータ構造。もう1つは店舗向けの一斉通知経路で、管理画面のお知らせ機能だけではログインしない店舗に届きません。

2026年7月17日に公布された改正個人情報保護法は、本人の権利利益の保護に欠けるおそれが少ない場合に本人通知を緩和し、代替措置による対応を認めます。緩和の具体的な対象は個人情報保護委員会規則で定められます。氏名や健康状態を含む本件について、通知を省略できると判断する根拠にはできません。施行は公布から2年を超えない範囲で政令が定める日で、10月24日時点で具体的な日付は決まっていません。改正の全体像は令和8年改正で企業対応がどう変わるかの整理を参照してください。

予約管理SaaSの利用店舗が72時間で着手する対応と乗り換えを見送る条件

利用店舗の初動対応と、継続利用・乗り換えの判断条件を示します。

利用店舗の初動対応案：72時間以内を目安に進める認証情報・権限・顧客データの点検

PeakManagerの管理画面のパスワードを変更する。同じパスワードを他サービスで使っていれば、そちらも同時に変える。
店舗アカウントを棚卸しし、退職者や取引を終えた業者のアカウントが残っていれば削除する。
顧客からの問い合わせに答える内容を決め、事案窓口（0120-206-460）を案内先として掲示する。店舗が被害範囲を推測で伝えない。
自店舗がエクスポートした顧客データの保管場所を確認し、共有フォルダや個人のパソコンに複製が残っていないかを点検する。

4つ目のエクスポート済みデータも点検対象です。SaaS側が新環境へ移管しても、店舗にダウンロードした顧客名簿が残っていれば、そこが次の漏えい元になります。あわせて、備考欄にカード番号や必要以上の健康情報を書いていないかを点検し、書き方の店内ルールを決めてください。

SaaSを乗り換えるべき3条件と乗り換えが過剰になる場面の線引き

今回の公表だけで乗り換えを即決するのではなく、再発防止策の説明、店舗への連絡状況、移行先の要件充足を比較して判断すべきです。乗り換え先が同等以上である保証もありません。

乗り換えを検討する主な条件として、次の3つを挙げます。第一に、顧客データを自社で保有・分析する必要があり、SaaSのエクスポート機能では要件を満たせない場合。第二に、再発防止策が具体化しない場合です。第二報の再発防止策は「情報管理体制およびセキュリティ対策の見直し・強化を進めております」にとどまっており、権限設計やログ保全の具体策が今後も示されなければ判断材料になります。第三に、自店に事業者から個別の連絡がなく、問い合わせても影響範囲の説明を受けられない場合です。

発注時の契約に入れておくログ保全と復旧目標の条項

同種のシステムを外注または内製するなら、契約と要件定義に落とせる項目があります。インシデント時の通知期限（検知から何時間以内に利用者へ通知するか）、監査ログの保持期間（調査に必要な期間・契約要件・保存費用から設定）、バックアップの目標復旧時点と目標復旧時間、自由記述欄に機微情報を入れさせない入力制御の有無、委託先から委託元への漏えい通知の手順です。

既存システムの権限設計や監査ログの取得状況を自力で点検しきれない場合は、外部の脆弱性診断・セキュリティ診断で、Webアプリケーションの入力値検証に加えてDB接続アカウントの権限やサーバーの公開範囲まで確認する方法があります。診断の種類ごとの違いと費用相場は脆弱性診断の種類・費用相場と外注時の判断基準で整理しています。

よくある質問

PeakManagerの個人情報漏えいについて、利用者・利用店舗・実装担当者から寄せられそうな質問に、2026年10月24日時点の公表内容で答えます。

ピークマネージャーにログインできないのは不正アクセスのせいですか？

公表文からは判断できません。第一報と第二報は、利用者のログイン停止やパスワードの一斉リセットには触れていません。店舗スタッフは管理画面の推奨環境であるパソコンのChrome最新版で開き直し、権限の変更がないかを店舗の管理者に確認してください。来店客は通っている店舗に問い合わせるのが確実です。

0120-206-460から電話がありました。本物ですか？

0120-206-460は、EPARKリラク＆エステが第一報・第二報でPeakManager事業部の問い合わせ先として掲載している番号です。ただし同社は、本件を理由にメールやSMSでカード番号やセキュリティコードを求めることはないと明記しています。カード情報を求められたら応じず、同社のお知らせに載っている番号へ自分からかけ直してください。

クレジットカード情報も漏れたのですか？

第二報で、第一報の「カード情報は含まれていない」が訂正されました。カード情報を入力する項目は設計上ありませんが、備考欄にカード情報に該当する可能性のある記載が5件あったとされています。実在のカードかは確認されておらず、いずれも有効期限は経過しています。同社は第二報の時点で、不正利用などの二次被害は確認していないとしています。

EPARKの会員情報も漏えいしたのですか？

親会社のEPARKは2026年8月4日の告知で、不正アクセスの対象は子会社のEPARKリラク＆エステが提供するPeakManagerであり、EPARKおよびEPARKブランド各社のシステムは対象ではないと説明しています。ただし、PeakManagerを導入した店舗に顧客登録していれば、その店舗の台帳が対象に含まれる可能性はあります。

不正アクセスによる漏えいは、いつまでに報告すればよいですか？

不正の目的で行われたおそれがある漏えい（施行規則7条3号）は、件数にかかわらず報告対象です。速報は事態を知ってから速やかに（目安は概ね3〜5日以内）、確報は60日以内です。要配慮個人情報が含まれる場合（1号）も件数を問わず対象で、3号に当たらなければ確報は30日以内です。取扱いを委託している場合は、原則として委託元と委託先の双方が報告義務を負います。