はじめに
クライアントが管理するサーバー環境（お名前.com）上のWordPressサイトにおいて、マルウェア感染が疑われる障害が発生し、フロントエンドおよび管理画面が表示不能（リダイレクトループ）に陥りました。
サイトをゼロから再構築するのではなく、投稿データや設定などのデータベース資産を保護・復元した手順を技術記録としてまとめます。
発生した障害事象
- ドメインへのアクセス時、意図しないリダイレクトが走りサイトが表示されない。
- 管理画面（
/wp-admin）へのアクセスもリダイレクトに巻き込まれ、ログイン不可。 - 同一サーバー内にクリーンなWordPressを新規インストールしても、同様のリダイレクトが発生。
通常のエラーログ調査や.htaccessの初期化だけでは特定が難しく、Webサーバーの親階層やキャッシュレイヤー、あるいは特定のリクエスト処理にマルウェアの影響が及んでいる可能性を考慮し、別環境での切り分けを行いました。
復旧手順とアプローチ
1. 検証用別サーバーによる環境の切り分け
原因が「サーバー設定や上位階層の汚染」にあるのか、「WordPress/DB単体の問題」にあるのかを分離するため、手持ちの検証サーバー（バリューサーバー）に一時環境を構築しました。
- 検証用サーバーにクリーンなWordPressを設置し、正常表示・稼働を確認。
- これにより、検証環境自体には問題がないベースラインを確保。
2. データベース（MySQL）の退避とインポート
- 感染疑いのある環境のphpMyAdminから、MySQLデータをダンプ（エクスポート）。
- 検証用サーバーのデータベースへデータをインポート。
3. AIを活用したDBおよび設定ファイルの調整
環境移行に伴うURLやシリアライズデータ、設定ファイルの整合性調整について、AIを活用してピンポイントで対応コードと修正箇所を特定しました。
-
wp-config.phpの定数定義および接続設定の調整 - DB内の環境依存値の確認・修正
- リダイレクトの原因となっていたテーマファイルやコアの依存関係の欠損チェック
外部API連携（Instagram埋め込み等）の一部表示を除き、約99%のコンテンツおよび管理画面の操作性を検証環境上で再現・復旧させることに成功しました。
4. 元環境へのフィードバック適用
検証環境で正常稼働する構成・データセットが確定したため、同様の手順を元のサーバー環境にも適用しました。
- 破損・改ざんの疑いがあるファイルをクリーンな構成に置き換え。
- 修正済みデータとの結合を行い、元環境側でもリダイレクトが解消され正常稼働することを確認。
5. マルウェアの検出と除染
正常に管理画面へアクセスできる状態を確保した直後、セキュリティプラグインを用いたスキャンと駆除を実施しました。
- Wordfence Security を導入し、ファイル整合性チェックおよびマルウェアスキャンを実行。
- 検知された不正ファイルおよび改ざん箇所の自動削除・修復を実行。
- 経過観察: マルウェアにはバックドア（Web Shell等）が残存し、数日後にcronや特定リクエストをトリガーに再感染するパターンが多いため、数日間のモニタリング期間を設定。
トラブルシューティングの知見
| 対応フェーズ | 実施内容 | 効果・メリット |
|---|---|---|
| 切り分け | 別サーバーへのDB移設・検証 | サーバー固有の要因とデータ要因を迅速に分離 |
| データ修正 | AIを用いた設定ファイル・DB調整 | 調査・検証工数の大幅削減、修正精度の向上 |
| 除染・保護 | Wordfenceによるスキャン＆経過観察 | 残存バックドアによる再感染リスクの低減 |
おわりに
未知のエラーやマルウェア感染時の復旧作業において、「外部のクリーンな環境での早期切り分け」と「AIによるコード・設定調整の高速化」の組み合わせは非常に有効でした。
経過観察でバックドアの再発がないことを確認した後、最終的な本番サーバーへの移転を完了させる予定です。