WordPressから顧客情報が流出した疑いがある時は、復旧作業だけを急いではいけません。最初に証拠を保存し、対象データと影響範囲を調査し、必要な相手へ正確に連絡する順序が重要です。
サイトを直せば問題が終わるわけではありません。注文情報、問い合わせ内容、会員情報などが第三者に見られた可能性があるなら、技術対応と事業者としての説明責任を同時に進める必要があります。
20年以上ITエンジニアとして、WordPressの制作・保守・復旧に携わっている、よこやま良平です。現場では「直す」「調べる」「伝える」を混ぜず、証拠が残る順番で対応します。
- 発覚直後に止める作業と、先に保存する証拠が分かる
- 顧客情報、流出経路、期間、対象人数の調べ方が分かる
- 封じ込めと復旧を、証拠を壊さず進められる
- サーバー会社、専門家、関係機関、顧客への連絡順を整理できる
- 未確認情報を断定せず、信頼を損なわない説明を準備できる
結論から言うと、対応順序は「保存→体制確保→調査→封じ込め→判断→連絡→再発防止」です。顧客へ早く伝えることは大切ですが、根拠がないまま人数や原因を断定すると訂正が増え、かえって不安を広げます。
一方で、調査が終わるまで何も知らせない判断も危険です。期限や報告義務は事案、情報の種類、影響、契約、地域によって変わるため、技術調査と並行して法務・個人情報保護の専門家へ確認してください。
WordPress顧客情報流出の疑いが出た直後の対応順序
最初の結論は、サイトを触る人と判断する人を絞り、時刻付きの対応記録を開始することです。担当者が各自の判断で更新、削除、パスワード変更をすると、原因と影響範囲を示す証拠が失われます。
最初の60分で責任者と連絡経路を一本化する
技術担当、経営責任者、顧客対応担当を決め、誰が何を承認するかを明文化します。外注先や制作会社が関係する場合も、個別の電話やチャットに情報を散らさず、決めた記録場所へ集約します。
発覚時刻、発見者、最初に見た画面、通知メール、異常な注文や問い合わせ、サーバー会社からの連絡をそのまま記録してください。「昨日から変だった」のような表現は、後で調査期間を決める時に役立ちません。
- 発見時の画面、メール、URL、日時、操作した端末を保存する
- サイト、サーバー、決済、メール、顧客対応の担当者を決める
- 通常更新、プラグイン追加、ログ削除、自動クリーンアップを一時停止する
- 緊急連絡先と承認者を一つの対応表へまとめる
- 以後の操作を「誰が・いつ・何を・なぜ」で記録する
- バックアップ世代を上書きする通常運用
- ログローテーションやキャッシュ削除の手動実行
- 感染ファイルや不審ユーザーの証拠保存前の削除
- 原因未確認のままのWordPress再インストール
ただし、被害が進行中で顧客情報へ継続アクセスされている場合は、完全な保存を待ってはいけません。保存できる範囲を確保したうえで、メンテナンス化、公開経路の制限、侵害された認証情報の無効化など、被害を止める措置を優先します。
ここで重要なのは、通常の障害対応と情報流出対応を分けることです。表示を戻すだけの復旧では、攻撃者の入口、顧客データへの到達、持ち出しの有無、残った認証手段を説明できません。
WordPress顧客情報の証拠を変更前に保存する
調査の土台は、変更されていない原本を複製して保存することです。WordPress本体だけでなく、データベース、アクセスログ、管理操作、メール、決済・フォーム連携の履歴まで、同じ基準時刻で集めます。

ファイルとデータベースを別々に保全する
WordPressのファイルには侵入経路や不正プログラムの痕跡が残りますが、顧客情報そのものはデータベースや外部サービスにあることが多いです。ファイルだけをダウンロードして「バックアップ完了」と判断してはいけません。
データベースでは、ユーザー、注文、問い合わせ、コメント、フォーム保存、プラグイン独自テーブルを確認します。テーブル名だけで判断せず、利用中のEC、会員、予約、問い合わせプラグインがどこへ何を保存するかを設定と仕様から特定してください。
サーバー外にある証拠も同時に確保する
流出経路はWordPress内に限りません。メール配送、CRM、決済代行、アクセス解析、CDN、WAF、バックアップ、SFTP、ホスティング管理画面のログにも、異常な認証や大量取得の手掛かりがあります。
保存時は元ファイルを読み取り専用として扱い、調査用コピーを別に作ります。取得日時、タイムゾーン、対象期間、ファイル名、サイズ、SHA-256などのハッシュ値を記録すれば、後から同一性を説明しやすくなります。
案件ID: 2026-incident-001
発覚日時: YYYY-MM-DD HH:MM JST
保存日時: YYYY-MM-DD HH:MM JST
対象: access.log / database.sql / wp-content
保存元: server-name / account-name
保存担当: 担当者名
対象期間: YYYY-MM-DD 00:00〜YYYY-MM-DD 23:59 JST
SHA-256: 取得したハッシュ値
備考: 原本は変更せず調査用コピーを使用- 消えやすいアクセスログ、WAFログ、管理画面ログ、監査ログ
- WordPressファイル、データベース、設定ファイル、環境情報
- 不審通知、顧客からの申告、決済・メール・外部連携の履歴
- バックアップ一覧、復元履歴、保守会社や担当者の作業記録
個人情報を含む証拠は、普段の共有フォルダへ無制限に置かないでください。閲覧者を必要最小限にし、暗号化、アクセス履歴、保管期限、削除手順を決めます。調査資料そのものが新たな漏えい源になるのを防ぐためです。
WordPress顧客情報の範囲・経路・期間を調査する
調査では「何件漏れたか」を先に数えるのではなく、データ、経路、期間、権限の四つを順番に確定します。この枠組みなら、ログが不足していて断定できない範囲も明示できます。
対象データを業務単位で棚卸しする
氏名やメールアドレスだけが顧客情報ではありません。住所、電話番号、注文内容、問い合わせ本文、会員ID、IPアドレス、Cookie識別子、添付ファイル、請求情報、管理メモを含め、保存場所と件数を一覧化します。
決済カード番号をWordPressへ保存していない構成でも、決済画面の改ざんにより入力中の情報が外部送信された可能性は残ります。「データベースに番号がない」ことと「カード情報が安全だった」ことを同一視しないでください。
- 情報の種類と機密性
- 保存場所と管理主体
- 通常アクセスできる役割・アカウント
- 対象期間内の最大件数
- 外部サービスへの送信有無
- ログから確認できることと確認できないこと
侵入経路とデータ到達経路を分けて調べる
侵入経路は脆弱なプラグイン、漏えいパスワード、SFTP、ホスティング管理画面などです。データ到達経路はWordPress REST API、管理画面のエクスポート、データベース接続、バックアップ取得、フォーム通知メールなどで、別の経路として追います。
管理者権限を奪われた事実があっても、ただちに全顧客データの持ち出しが確定するわけではありません。一方でダウンロード履歴がなくても、WebShellやSQL実行権限があれば、ログに残りにくい取得が可能だった範囲を評価する必要があります。
調査期間は最初の異常より前へ広げる
顧客からの申告日や改ざん発見日を侵入日と決めつけないでください。最初に確認できた異常なログイン、ファイル作成、権限変更、プラグイン追加より前へさかのぼり、通常状態を示す比較期間も確保します。
タイムゾーンはJST、UTC、サーバー設定が混在しやすいため、原文の時刻と換算後の時刻を両方残します。時刻を上書きすると、アクセスログ、WordPress操作、メール送信、決済履歴の前後関係を誤る原因になります。
調査結果は「流出を確認」「流出の可能性が高い」「痕跡は確認できない」「ログ不足で評価不能」のように証拠強度で表します。痕跡がないことを安全の証明にせず、どこまで確認できたかを添えるのが正確です。
WordPress顧客情報へのアクセスを封じ込めて安全に復旧する
封じ込めの結論は、攻撃者の入口と残存経路を閉じてから、信頼できる状態へ復旧することです。不審ファイル一つを削除して公開を再開すると、別の管理者、APIキー、予約タスクから再侵入されます。
進行中の被害を止める最小措置を選ぶ
サイト全停止が必要とは限りません。管理画面とAPIの制限、フォーム・会員登録・注文受付の一時停止、WAFルール、侵害アカウントの無効化、外部連携トークンの停止など、顧客への追加被害を止める措置を選びます。
ただし証拠保存前の一括パスワード変更は、ログアウト時刻やセッション状況を変えます。現在の侵害が継続している場合は変更を優先しつつ、変更者、対象、時刻、理由、無効化したセッションを必ず記録してください。
- WordPress管理者・編集者・顧客アカウント
- ホスティング、ドメイン、DNS、CDN、WAFの管理者
- SFTP・SSH・データベース・バックアップの認証情報
- Application Passwords、APIキー、Webhook、決済連携トークン
- メール、CRM、チャット、保守会社の共有アカウント
クリーンな基準から復旧して再侵入を検証する
正規配布元のWordPressコア、テーマ、プラグインと照合し、未知のファイル、改変箇所、mu-plugins、uploads内PHP、予約タスク、データベース内の不正スクリプトを確認します。バックアップも侵入後に作られていれば安全とは限りません。
復旧後は、顧客データへの到達経路が閉じたことを再テストします。管理者一覧、API、フォーム、ファイルアップロード、外部通信、メール送信、決済画面、ログ出力を確認し、監視期間を決めて異常が再発しないか追跡します。
公開再開の判断は「画面が表示できた」では足りません。侵入原因の除去、認証情報の更新、顧客データ経路の封鎖、監視、問い合わせ窓口、連絡方針がそろって初めて、事業として再開できる状態です。
WordPress顧客情報流出の報告・相談先を判断する
連絡先と期限は、流出した可能性のある情報、本人への影響、事業者の所在地、契約、業種によって異なります。技術担当だけで決めず、経営、法務、個人情報保護、保険、委託契約の担当を早期に参加させてください。
事実・推定・未確認を分けた状況票を作る
相談時には、発覚日時、対象システム、情報の種類、対象期間、最大対象人数、侵入経路、流出を示す証拠、継続被害の有無、実施済み対策を一枚にまとめます。数字が未確定なら、無理に確定値を置かず算定方法と上限を示します。
顧客情報を外部の制作会社、決済会社、予約サービスが管理している場合は、契約上の事故連絡条項、共同利用、委託、再委託、責任分界を確認します。自社のWordPressだけ調べても、通知に必要な全体像はそろいません。
- サーバー会社・クラウド会社へログ保全と不正利用状況を照会する
- WordPress復旧・フォレンジックの専門家へ証拠を保った調査を依頼する
- 法務・個人情報保護の専門家へ報告義務と通知内容を確認する
- サイバー保険、決済会社、委託元など契約上の連絡先を確認する
- 必要に応じて関係機関・警察の相談窓口へ証拠を整理して相談する
- 不要な顧客データ本体や平文のパスワード
- 本番APIキー、Cookie、セッショントークン
- 契約上共有できない第三者情報
- 調査に不要な従業員や顧客の私的情報
報告制度や法令の適用判断は、この記事だけで確定できません。日本の個人情報保護委員会など関係機関の最新案内を確認し、国外顧客や特定業種が関係する場合は、対象地域・業法に詳しい専門家の判断を受けてください。
WordPress顧客情報流出を顧客へ連絡する時の書き方
顧客への連絡は、早さと正確さの両立が必要です。原因を断定する文章ではなく、現時点で確認できた事実、影響の可能性、顧客が取る行動、事業者の対応、次回更新時期を明確にします。
初報は短く、顧客が今やることを先に示す
顧客が知りたいのは、自分のどの情報が関係し、何をすべきかです。対象者へ個別連絡できるなら、一般告知だけで済ませず、なりすましメール、パスワード再利用、カード利用明細など具体的な注意点を案内します。
「念のため全員パスワードを変更してください」と書く場合も、自社サイトだけか、同じパスワードを使う他サービスも対象か、再設定リンクはどのドメインから届くかを示してください。偽の事故通知を使うフィッシング対策にもなります。
- 何が起きたかと発覚日時
- 現時点で対象と判断している情報・期間・利用者
- 確認済み事実と調査中の事項
- 顧客にお願いする具体的な行動
- 実施済みの封じ込めと再発防止の進行状況
- 問い合わせ窓口と次回更新予定
原因や件数を更新する時は変更点を残す
調査の進展で対象件数や期間が変わることはあります。初報を黙って書き換えず、更新日時、変更した項目、新しく判明した根拠を残します。以前の説明との差を示すことで、隠蔽と受け取られるリスクを減らせます。
避けるべき表現は「流出はありません」と根拠なく断定すること、「詳細はセキュリティ上説明できません」と全部を伏せること、技術用語だけで責任範囲を曖昧にすることです。説明できない部分は、その理由と代わりに確認した範囲を示します。
件名: 顧客情報に関する重要なお知らせ
1. 発生・発覚した事実
2. 対象となる可能性がある情報と期間
3. 現在確認できていない事項
4. お客様にお願いしたい対応
5. 当社が実施した封じ込めと調査
6. 問い合わせ窓口
7. 次回の情報更新予定問い合わせ窓口には、回答してよい範囲、本人確認方法、エスカレーション先、脅迫や補償要求への対応、記録方法を用意します。担当者ごとに説明が変わると、顧客の不安と二次被害が広がります。
WordPress顧客情報流出後の再発防止と記録の残し方
再発防止は、原因となった一か所だけを塞ぐ作業ではありません。顧客情報を持つ理由、保存期間、権限、外部連携、監視、バックアップまで見直し、同じ被害が起きても早く検知して影響を小さくする設計へ変えます。
保存する顧客情報を減らし権限を最小化する
使っていない問い合わせ履歴、退会済み会員、古い注文データを無期限に残すほど、事故時の対象は増えます。法令や会計・契約上必要な保管期間を確認し、削除・匿名化・別保管の基準を定めます。
管理者権限も同じです。退職者、制作会社、広告担当、プラグイン連携へ恒久的な管理者権限を渡さず、役割ごとの最小権限、個別アカウント、多要素認証、定期棚卸しを運用します。
ログと通知を保存しているだけから使える状態へ変える
ログは保持期間、時刻、検索方法、改ざん防止、アラート条件を決めて初めて役立ちます。大量ログイン、管理者追加、プラグイン変更、データエクスポート、異常なAPIアクセス、外部送信を監視対象にします。
事故後の振り返りでは、検知から保存、封じ込め、判断、通知までの所要時間を確認します。止まった承認、取得できなかったログ、連絡先の不備を次の手順書へ反映し、机上訓練で実行できるか確かめてください。
- 侵入原因と顧客データ到達経路の両方を閉じた
- 不要データ・不要権限・不要連携を削減した
- 重要操作と異常アクセスを検知できる
- 復旧後の監視期間と担当者を決めた
- 証拠保存・連絡・顧客対応の手順書を更新した
セキュリティプラグインは対策の一部です。クイックレスキュー365は不正ログイン防止、XML-RPC遮断、ログインURL変更、uploads内PHP動作禁止などに使えますが、マルウェアをスキャンする機能はありません。感染調査が必要ならWordfenceなどのスキャンと専門調査を使い分けます。
プラグイン設定だけでなく、更新・バックアップ・緊急復旧まで継続して任せたい場合は、
保守サービス「クイックレスキュー365」の内容も確認してください。
WordPress顧客情報流出対応のよくある質問
結論として、迷いやすい場面でも「証拠を残す」「被害を止める」「不確かなことを断定しない」の三原則は変わりません。個別事情で判断が変わる項目は、専門家へ早めに引き継ぎます。
影響の大きさ、継続被害、情報の種類、報告義務を踏まえて判断します。調査中でも顧客がすぐ取るべき対策があるなら、確定を待たず「疑い」「調査中」と明示した初報が必要になる場合があります。
技術担当だけで保留せず、経営・法務・個人情報保護の担当と期限を決めて判断してください。
初期化だけでは安全になりません。証拠が消え、データベースの不正ユーザー、外部APIキー、SFTP、ホスティング管理画面など別の侵害経路が残ることがあります。
先に保全し、侵入原因と残存経路を確認したうえで、クリーンな構成から復旧します。
流出なしとは断定できません。ログに記録されないデータベース接続、管理画面操作、外部送信、不正プログラムの通信があり得ます。ログの保持不足や欠損も評価してください。
契約、委託条件、秘密保持、保管場所、アクセス権、削除方法を確認し、調査に必要な最小範囲へ絞ります。顧客データ本体ではなく、まずスキーマ、件数、匿名化したサンプル、ログで調査できる場合もあります。
WordPress顧客情報流出の疑いは保存・調査・連絡の順で対応する
WordPressから顧客情報が流出した疑いがある時は、サイト修復だけで終わらせず、証拠保存、体制確保、範囲調査、封じ込め、報告判断、顧客連絡を一つのインシデント対応として進めます。
特に重要なのは、流出を確認できた範囲と、ログ不足で確認できない範囲を分けることです。断定を急がず、しかし被害を止める判断は遅らせないという二つの原則を両立させてください。
- 発覚時の証拠と消えやすいログを保存した
- 顧客情報の種類・保存場所・最大対象件数を棚卸しした
- 侵入経路とデータ到達経路を別々に調査した
- 継続アクセスを封じ込め、クリーンな状態へ復旧した
- 報告義務と契約上の連絡先を専門家と確認した
- 顧客へ事実・影響・取るべき行動・更新予定を伝える準備をした
担当者だけで抱えると、証拠消失、連絡遅延、説明の食い違いが起きます。顧客情報が関係する可能性を認識した時点で、技術、経営、法務、顧客対応をつなぎ、記録を残しながら進めるのが正解です。
WordPressの顧客情報流出対応が自分で進められない時は

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。
- WordPressが真っ白画面
- WordPressがログインできない
- ホームページのマルウェアや乗っ取り
- サイトの表示くずれ
- エラーが表示されている
これらでお悩みなら最短30分ですぐに解決します!
いまなら期間限定で
・万一改善されない場合は全額返金保証で安心!
・30日間動作保証で安心!
・初期費・調査料 0円で安心!







