WP-Rescue No.002

WordPress「重大なエラー」を再現し、SFTPから原因プラグインを切り離して復旧

概要

WordPressでは、

プラグインの不具合によって「このWebサイトに重大なエラーが発生しました」と表示され、

管理画面へアクセスできなくなる場合があります。

今回は検証用WordPress環境に障害再現用プラグインを用意し、

意図的に重大なエラーを発生させました。

そのうえで、

WordPress管理画面を使用できない状況を想定し、

SFTPからプラグインディレクトリを操作して原因箇所を切り離し、

WordPressを復旧できるか実地検証しました。

※本記事は検証環境で実施した障害再現・復旧記録です。

実運用サイトで障害を発生させたものではありません。

---

1. 検証前の正常状態

障害を発生させる前に、WordPressの公開ページが正常に表示されていることを確認しました。

図1：障害再現前の正常なサイト表示（検証環境）

この時点では公開ページに異常はなく、WordPressが正常に動作していました。

これにより、以降に発生するエラーが障害再現操作によって生じたものであることを比較できる状態にしました。

---

2. 障害再現用プラグインを準備

検証用環境に、今回の障害再現専用プラグインを配置しました。

通常運用中のプラグインとは区別し、検証用プラグインを原因として障害を意図的に発生させる構成としました。

これにより、実際のWordPress障害対応に近い形で、

障害発生 → 切り分け → 原因箇所の隔離 → 復旧確認

という一連の作業を検証します。

---

3. WordPressの「重大なエラー」を再現

障害再現用プラグインを動作させたところ、WordPressが正常に表示されなくなり、次のメッセージが表示されました。

「このWebサイトに重大なエラーが発生しました。」

図2：障害再現用プラグインによって発生したWordPressの「重大なエラー」

これにより、WordPress側で重大なエラーが発生した状態を再現できました。

このような状況では、

WordPress管理画面からプラグインを停止する通常の方法が使用できない可能性があります。

そこで、WordPress管理画面の外側から原因箇所を切り離す方法を検討しました。

---

4. SFTPからプラグインディレクトリを確認

SFTPクライアントを使用してサーバーへ接続し、

WordPressのプラグインディレクトリを確認しました。

障害再現用として配置した、

wp-rescue-failure-test

ディレクトリが存在することを確認しました。

図3：SFTPから確認した障害再現用プラグインディレクトリ

この段階では、

障害の原因として想定しているプラグインのディレクトリが通常の名称で存在しています。

---

5. 原因プラグインをSFTPから切り離し

WordPress管理画面を使用せず、

SFTP上で障害再現用プラグインのディレクトリ名を変更しました。

変更前：

wp-rescue-failure-test

変更後：

wp-rescue-failure-test-disabled

図4：障害再現用プラグインのディレクトリ名を変更して切り離した状態

プラグイン本体を削除するのではなく、

ディレクトリ名を変更することで、WordPressから対象プラグインを読み込めない状態にしました。

この方法には、元のファイルを残したまま原因候補を切り離せるという利点があります。

---

6. WordPress管理画面の復旧を確認

原因プラグインを切り離した後、WordPress管理画面へ再度アクセスしました。

図5：原因プラグイン切り離し後に正常表示されたWordPress管理画面

ダッシュボードが正常に表示され、管理画面へ再びアクセスできる状態になったことを確認しました。

これにより、

SFTP側で行ったプラグインの切り離し後にWordPressの管理機能が復旧したことを確認できました。

---

7. プラグインの状態をWordPress側でも確認

WordPress管理画面のプラグイン一覧を確認しました。

障害再現用の「WP-Rescue Failure Test」には

「有効化」と表示されており、現在は有効状態ではないことを確認しました。

図6：WordPress管理画面から障害再現用プラグインが無効状態であることを確認

SFTP側でのディレクトリ変更だけで判断せず、WordPress側からも状態を確認しました。

---

8. 公開サイトの最終確認

最後にWordPressの公開ページへアクセスし、サイトが正常に表示されることを確認しました。

図7：原因プラグイン切り離し後に正常表示されたWordPress公開サイト

障害発生前と同様に公開ページが表示され、

「重大なエラー」が解消されていることを確認しました。

これをもって復旧確認完了としました。

---

今回実施した切り分けの流れ

正常状態を確認

↓

障害再現用プラグインで重大なエラーを発生

↓

WordPress管理画面に依存しない復旧方法へ切り替え

↓

SFTPからプラグインディレクトリを確認

↓

原因プラグインのディレクトリ名を変更して切り離し

↓

WordPress管理画面の復旧を確認

↓

プラグインが無効状態になったことを確認

↓

公開サイトの正常表示を確認

---

技術的に学んだこと

今回の検証では、WordPress管理画面が利用できない場合でも、サーバー上のファイルへアクセスできれば、SFTPを利用してプラグインを切り離せることを実地確認しました。

特に重要だったのは、障害発生時にいきなりファイルを削除するのではなく、原因候補を切り分けながら復旧を進めることです。

今回は原因が分かっている検証用プラグインを使用しましたが、実際の障害では原因が最初から判明しているとは限りません。

そのため実案件では、バックアップと証拠保全を優先したうえで、エラーログ、直前の変更内容、プラグイン・テーマ・PHP環境などを確認し、原因候補を絞り込んでから切り離す必要があります。

また、復旧作業では「管理画面が開いた」だけで終了せず、

• 管理画面の正常表示

• プラグイン状態

• 公開ページの正常表示

まで確認することが重要だと学びました。

---

使用した主な技術・ツール

• WordPress
• SFTP
• WinSCP
• WordPressプラグイン管理
• サーバー上のディレクトリ操作
• 障害再現・切り分け
• 復旧後の動作確認