PeakManagerの個人情報漏えい約3300万件｜DB侵害とデータ削除の技術解説

EPARKリラク＆エステは2026年7月31日、整体院やリラクゼーションサロン向けの予約・顧客管理プラットフォーム「PeakManager」が不正アクセスを受け、顧客情報が漏えいした可能性があると公表しました。対象は約3300万レコード。氏名・生年月日・性別・住所・電話番号・メールアドレス・暗号化されたパスワード等が含まれ、クレジットカード情報とマイナンバー関連情報は含まれていないとされています。

この事案が同時期の他インシデントと違うのは、データベースに保存された顧客情報が「削除されていた」点です。読み出されただけではなく、消えていた。本記事では公表事実を整理したうえで、機密性と可用性が同時に壊れる構造、「暗号化されたパスワード」の実装上の読み方、DB権限分離と監査ログの設計、報告期限、利用店舗側の初動までを扱います。

まとめ：PeakManager個人情報漏えい事案の要点と実装側の初動

• 事案と規模：2026年7月27日に不正アクセスとデータ削除を確認、7月30日に個人情報保護委員会へ報告、7月31日に第一報を公表。漏えいの可能性は約3300万レコード（対象人数は調査後に報告予定）。
• 漏えい項目：氏名から連絡先までの基本属性と暗号化されたパスワード等。クレジットカード情報とマイナンバー関連情報は対象外。
• 技術的な本質：アプリ層の認可ロジックの穴ではなく、データベースそのものに到達され、格納データを削除された事案。機密性と可用性が同時に壊れています。
• パスワードの読み方：「暗号化された」は可逆な暗号化・無ソルトハッシュ・ソルト＋ストレッチングのいずれも指しうる表現。方式が不明な以上、利用者側は使い回しを前提に総入れ替えするしかありません。
• 設計の主戦場：アプリ用DBアカウントから削除権限を外す最小権限設計と、DB監査ログの取得・外部保全・保持期間。この2つが被害範囲と調査可否を決めます。
• 法対応：不正の目的をもって行われたおそれがある行為による漏えいは、件数にかかわらず報告対象（3号事態）。速報は概ね3〜5日以内、確報は60日以内（2026年8月時点）。
• 利用店舗の判断：SaaSの乗り換えを急ぐ必要はありません。まずパスワードと権限の総入れ替え、次に顧客への通知経路の確認。移行が要るのは、顧客DBを自社で握る必要が事業上ある店舗だけです。

PeakManager不正アクセス事案の公表事実と3300万レコードの内訳

技術的な考察に入る前に、確定した事実と未確認の主張を分けます。混ぜると対策の優先順位を誤ります。

7月27日の削除確認から7月31日の第一報公表に至るまでの時系列

公表によれば、PeakManagerのデータベースの一部に第三者による不正アクセスが行われ、保存されていた顧客情報が削除されていることを2026年7月27日に確認しました。同社は7月30日に個人情報保護委員会へ報告し、7月31日に第一報を公開しています。確認から委員会報告まで3日。この間隔は後述する個人情報保護法の速報期限（概ね3〜5日以内）に収まっており、初動の法対応は期限内に処理されたと読めます。

公表時点で実施済みとされた対応は5つです。削除データの復旧、対象データベースの運用停止と切り替え、不正利用アカウントの停止、データベースおよびサーバーの認証情報の変更、新サーバー・新データベースへの移管。問い合わせ窓口はPeakmanager事業部（0120-206-460、平日10時〜17時）が案内されています。

漏えいの可能性がある約3300万レコードの内訳と対象外となった情報

約3300万という数はレコード数であり、対象となる人数ではありません。同一の顧客が複数店舗を予約していれば行は増えます。対象人数は調査後に改めて報告するとされ、2026年8月3日時点では確定していません。

クレジットカード情報とマイナンバー関連情報は含まれていないと明示されました。カード番号が対象外であれば、決済の不正利用というもっとも直接的な金銭被害の経路は塞がれています。残るリスクは、氏名・生年月日・住所・電話番号という本人確認に使われる属性の組み合わせと、メールアドレスとパスワードの対がリスト型攻撃に転用される経路です。整体院・接骨院・鍼灸院の予約データという性質上、来店履歴から健康状態が推測されうる点も扱う必要があります。

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

報道では、ダークウェブのハッキングフォーラムに犯行声明とみられる投稿が確認されたと伝えられています。投稿側の主張は、2026年7月19日にpeakmanager.jpへ侵入し、総行数32,510,060行・圧縮状態3.14ギガバイトのデータを保持していること、データベース本体とソースコード、内部ネットワークへのアクセス権をあわせて売却する意向です。

これらは第三者による裏付けが取れていない主張であり、事実として扱ってはいけません。ただし主張された侵入日7月19日と、同社が確認した7月27日の間に8日の開きがある点は、検知設計を考えるうえで無視できない論点です。この点は後段の監査ログ設計で扱います。

顧客データの削除を伴う侵害で機密性と可用性が同時に壊れる技術的構造

「情報漏えい」という見出しで報じられる事案の多くは、データを読まれた話です。今回は読まれたうえに消えています。防御設計の観点では、この差が対策の中身を変えます。

削除された顧客情報の復旧完了という公表が示す可用性侵害の到達点

攻撃者がデータベースにDELETEやDROPを通せる状態だったということは、参照権限だけでなく更新・削除権限を持つ経路を掌握していたことを意味します。SQLインジェクションで読み出されたケースと、DBアカウントそのものを奪われたケースでは到達点が違う。前者は入力値の検証で止まりますが、後者はアプリケーションの外側で認証情報が漏れているため、コードを直しても止まりません。

同社は削除データの復旧作業を完了したと公表しています。バックアップから戻せたという事実は、運用側の準備が機能した証拠です。裏を返せば、世代管理の甘い組織なら同じ攻撃で顧客データが恒久的に失われていました。身代金要求を伴わない削除は、復旧できなければ事業継続が止まる点でランサムウェアより厄介です。

アプリケーション層の認可制御が抜けた事案とは、対処すべき層が異なります。Webの画面遷移で他人のデータが見えてしまう型については生保協会の生命保険契約照会システムで発生した認可制御不備の解説で扱っており、データベースそのものへ到達された今回の事案とは、修正すべきコードの場所が変わります。

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

バックアップが「取れている」ことと「戻せる」ことは別物です。攻撃者がDBに到達している状況では、同じ認証情報でバックアップ領域にも書き込める構成なら、バックアップごと消されます。本番DBの認証情報では触れない領域へ退避し、オブジェクトストレージのバージョニングとオブジェクトロックで保持期間中は削除不可にしてください。日次1世代の運用は、削除に気づくのが翌日以降になった時点で上書きされます。

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

公表文の「暗号化されたパスワード」という一語は、利用者リスクの見積もりを左右します。しかし実装として何を指すのかは、この表現から判別できません。

可逆な暗号化と一方向ハッシュで利用者側に残るリスクが変わる分岐点

日本語の公表文では、パスワードの保護方式を「暗号化」と総称する例が多く見られます。技術的には、鍵があれば平文に戻せる可逆な暗号化と、原理的に戻せない一方向ハッシュは別物です。DBを掌握した攻撃者がサーバー側の鍵にも到達していれば、パスワードは平文と同等に扱われます。

方式が明示されない以上、利用者側は最悪のケースを前提に動くほかありません。実装側の基準は明確です。利用者ごとに異なるランダムなソルトを付与し、計算コストの高いアルゴリズムで反復処理して保存する。2026年8月時点の新規実装ならArgon2idまたはbcryptが現実的な選択肢で、MD5やSHA-1の単純ハッシュはGPUで秒間数十億回の試行が可能なため保護として成立しません。

パスワード変更の呼びかけだけでは消えない使い回し利用者の二次被害

PeakManagerのパスワードを変更しても、同じパスワードを他サービスで使い回している利用者のリスクは消えません。攻撃者はメールアドレスとパスワードの対を、金融機関やECサイトへ順に試すリスト型攻撃に転用します。呼びかけるべきなのは「本サービスの変更」ではなく「同じパスワードを使っている全サービスの変更」です。

提供者側の実装対応としては、影響を受けたアカウントのセッションを全失効させ、次回ログイン時にパスワード再設定を強制する方式が確実です。呼びかけだけでは、実際に変更する利用者は一部にとどまる。あわせて多要素認証（MFA）の実装方式と耐フィッシングMFAの選び方を確認し、パスワード単体に依存しない認証へ移す検討を並行させてください。

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

侵入をゼロにする設計は存在しません。設計で決められるのは、侵入されたあとにどこまで被害が広がるかです。今回のようにデータ削除まで到達された事案は、権限設計と経路設計の両方で止められた可能性があります。

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

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

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

この4段階のうち、費用対効果が突出して高いのは1と2です。アプリ用アカウントからDELETEとDROPを外すだけで、保存データの削除という結果はアプリ経由の経路では起こらなくなります。

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

DBの認証情報が漏れても、そのアカウントで接続できる場所が限られていれば侵入は成立しません。管理接続は踏み台サーバー経由に一本化し、踏み台への到達をIP許可リストとMFAで二重に絞ります。クラウド環境なら、セキュリティグループの受信規則に0.0.0.0からの許可が残っていないか、まず棚卸ししてください。

見落としが多いのは開発・検証環境です。本番と同じ認証情報を検証環境で使い回している構成では、防御の弱い検証環境を踏み台にして本番DBへ到達されます。環境ごとに認証情報を分け、検証環境には本番データの複製を置かない。この2点だけでも侵入経路の本数はかなり減ります。

同社は新サーバー・新データベースへの移管を完了したと公表していますが、経路が特定されないまま移管すれば同じ経路で新環境にも到達されます。旧環境から運ぶソースコード・設定ファイル・環境変数・SSH公開鍵・APIトークンの棚卸しを、移管と同時に進めてください。

侵入主張7月19日と確認7月27日の8日間を埋める監査ログの設計

主張が正しいと仮定すれば、データ削除という派手な挙動でようやく気づいた形になります。読み出しだけなら、さらに長く気づけなかった可能性があります。

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

アプリケーションのアクセスログだけでは、DBへ直接接続された操作は記録されません。検知にはデータベース自身の監査機能が要ります。PostgreSQLならpgaudit、MySQLならエンタープライズ版の監査プラグイン、マネージドサービスなら各クラウドの監査ログ出力を有効にします。

取得しただけでは検知になりません。設定すべき検知条件は3つに絞れます。第一に、アプリ用アカウント以外からの接続。第二に、通常のアプリ処理では発生しない行数の読み出し（1クエリで数万行を超えるなど）。第三に、DELETEやTRUNCATEの実行そのものです。論理削除へ移行済みの環境なら、3つ目は発生した時点で即座に異常と判定できます。

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

DBサーバー上にしかログがない構成は、サーバーを掌握された時点で調査手段を失います。攻撃者にとって痕跡消去は基本動作であり、ログの削除も削除権限の範囲内です。ログは生成直後に別アカウント・別リージョンの保管先へ転送し、書き込み後は変更不可の設定にします。保持期間は確報の提出期限が60日であることから逆算し、最低でも90日を確保してください。

踏み台の認証ログ、アプリのアクセスログ、DBの監査ログを1か所に集めて相関させる設計についてはSIEMの仕組みとEDR・XDR・SOARとの役割の違いで整理しました。個別のログを別々に眺めているだけでは、8日間の滞留は追えません。

個人情報保護法の漏えい報告義務とテナント店舗への通知に必要な期限

技術対応と並行して走るのが法対応です。検知の時点で時計が動き始めていると考えてください。

3号事態に該当する不正アクセス漏えいの速報3〜5日と確報60日

個人情報保護法では、報告義務の対象となる事態が4つ定められています。要配慮個人情報の漏えい（1号）、財産的被害のおそれがある漏えい（2号）、不正の目的をもって行われたおそれがある行為による漏えい（3号）、1000人超の本人に係る漏えい（4号）。今回の不正アクセス事案は3号に該当し、件数にかかわらず報告対象になります。

期限は速報と確報で分かれます。速報は事態を知った時点から概ね3〜5日以内、確報は30日以内。ただし3号事態では、原因究明に時間がかかる前提が織り込まれ、確報の期限が60日以内へ延長されます。同社が7月27日の確認から7月30日に委員会報告を行った流れは、速報の期限内に収まる形です。制度の全体像は個人情報保護法の定義と基本的な概念の解説で確認できます。なお2026年に成立した令和8年改正の内容と施行時期は令和8年改正で企業対応がどう変わるかの整理にまとめており、今回の事案に適用されるのは改正前の現行規定です。

本人への通知義務とテナント店舗を経由する通知設計で詰まる2つの箇所

報告義務とは別に、本人への通知義務があります。ここでSaaS事業者が詰まるのが、連絡先を持っているのが誰かという問題です。予約・顧客管理プラットフォームでは顧客との接点は導入店舗側にあり、プラットフォーム事業者は店舗を介して顧客データを預かる構造になっています。

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

予約管理SaaSの利用側が72時間で着手する対応と移行を見送る条件

ここからは判断を書きます。PeakManagerを使っている店舗、あるいは同種のSaaSを使う事業者が、この一報を見て何をすべきか。順序を間違えると、実効性のない作業に時間を使います。

利用店舗が72時間以内に終わらせるパスワードと権限の総入れ替え作業

最初の72時間で終わらせる作業は4つです。順序も含めて固定してください。

1. PeakManagerのログインパスワードを変更する。同じパスワードを他サービスで使っていれば、そちらも同時に変更する。
2. 店舗アカウントを棚卸しする。退職者・取引終了した業者のアカウントが残っていれば削除する。
3. 顧客からの問い合わせ窓口と回答内容を決める。事業部窓口（0120-206-460）を案内先として掲示する。
4. 自店舗が別途エクスポートした顧客データの保管場所を確認する。共有フォルダや個人PCに複製が残っていないか点検する。

4つ目を落とす店舗が多く見られます。SaaS側が新環境へ移管しても、店舗にダウンロードした顧客名簿が残っていれば、そこが次の漏えい元になります。この機会に消してください。

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

結論から書きます。今回の一報だけを理由にSaaSを乗り換えるのは、大半の店舗にとって過剰です。移管と認証情報の総入れ替えを終えた直後のサービスは事案前より防御水準が上がっている可能性が高く、乗り換え先が同等以上である保証もありません。

乗り換えを検討すべき条件は3つに限定できます。第一に、顧客データを自社で保有・分析する必要が事業上あり、SaaSのエクスポート機能では要件を満たせない場合。第二に、第二報以降で原因究明の説明が示されず、再発防止策が具体化しない場合。第三に、加盟する業界団体や取引先から特定のセキュリティ基準への準拠を求められている場合です。この3つに当てはまらないなら、監視と運用の見直しで足ります。

発注時の契約に入れておくログ保全と復旧目標についての具体的な条項

同種のシステムを外注または内製するなら、今回の事案から契約と要件定義に落とせる項目があります。インシデント時の通知期限（検知から何時間以内に利用者へ通知するか）、監査ログの保持期間（最低90日）、バックアップの目標復旧時点と目標復旧時間、脆弱性診断の実施頻度です。後から追加すると費用が跳ね上がるため、初回の見積もり段階で入れておきます。

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

よくある質問

PeakManagerの個人情報漏えいについて、利用店舗と実装担当者から想定される質問に答えます。

PeakManagerを使っていた店舗の顧客に、店舗から連絡すべきですか？

2026年8月3日時点では、EPARKリラク＆エステが第一報を公開し、Peakmanager事業部が窓口を設けている段階です。本人への通知はプラットフォーム事業者側の義務ですが、顧客との接点は店舗にあります。店舗としては、独自の判断で被害範囲を推測して伝えるのではなく、公表内容と窓口を正確に案内してください。

暗号化されたパスワードなら、変更しなくても安全ではないですか？

安全とは言い切れません。「暗号化された」という公表表現は、鍵があれば復元できる可逆な暗号化と、復元できない一方向ハッシュのどちらも指しうるためです。方式が公表されていない以上、最悪のケースを前提に動く必要があります。他サービスで同じパスワードを使っているなら、そちらもすべて変更してください。

データが削除された事案なのに、なぜ漏えいと呼ばれるのですか？

削除と漏えいは別々の被害であり、今回は両方が起きた可能性があると公表されています。データベースへ到達した攻撃者は、削除する前に内容を読み出せる立場にありました。削除は可用性の侵害、外部への持ち出しは機密性の侵害であり、事業者としては両方への対応が必要です。

自社の予約システムで同じ被害を防ぐには、まず何から着手しますか？

アプリケーションが接続しているDBアカウントの権限確認からです。多くの現場では、開発初期に作った所有者権限のアカウントがそのまま本番で使われています。ここからDELETEとDROPを外し、削除を論理削除へ切り替えるだけでデータ消失は回避しやすくなる。次に着手するのはDB監査ログの取得と外部保全です。

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

個人情報保護法では、不正の目的をもって行われたおそれがある行為による漏えい（3号事態）に該当する場合、件数にかかわらず個人情報保護委員会への報告が必要です。速報は事態を知った時点から概ね3〜5日以内、確報は60日以内（通常の事態は30日以内のところ、3号事態は延長されます）。本人への通知も、事態の状況に応じて速やかに行う義務があります。

関連記事

• 生保協会の生命保険契約照会システムで情報漏えい｜認可制御不備の技術解説：アプリ層の認可が抜けた型との比較用。
• タカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのか：モバイルAPI認可という別レイヤの事案。
• SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説：ログ相関で滞留期間を縮める設計。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：権限設計と公開範囲の点検を外部に委ねる材料。
• 個人情報保護法改正とは？2026年成立の令和8年改正で企業対応はこう変わる：改正後の要求水準を見据えた設計投資の材料。