WordPressで「重大なエラーが発生しました」と出たとき、何が起きているか
WordPress の管理画面を開いたら「このサイトで重大なエラーが発生しました。」とだけ表示され、そこから先に進めない。何をどう触ればいいのか分からず、とりあえずページを再読み込みしてみる——という状況で読まれることを想定した記事です。
先に結論
- この画面は「壊れた」ではなく「WordPress が異常を検知して安全に止めた」状態です。データが消えたわけではありません
- 原因のほとんどはプラグインかテーマで、直前に何かを更新・追加・編集していれば、それがほぼ答えです
- 管理者のメールアドレス宛に復旧用のリンクが届いているはずです。まずメールを確認してください
- 管理画面にログインできない状態でも、ファイルの操作だけで復旧できます
この画面は「壊れた」ではなく「安全に止めた」
WordPress 5.2 以降には、致命的なエラーを検知するとその先の処理を止める仕組みが入っています。以前のバージョンでは同じ状況で真っ白な画面（いわゆるホワイトスクリーン）になり、何が起きているのか手がかりが一切ありませんでした。「重大なエラーが発生しました」という表示は、その改善版です。
つまり、この画面が出ているということは、WordPress が「このまま続けると危ない」と判断して自分で止まったということです。投稿も画像も設定も、データベースの中に残っています。慌てて再インストールしたり、バックアップから丸ごと戻したりする前に、原因を1つ特定するほうが早く、確実です。
まず確認する3つ
1. 表側のサイトは表示されているか
管理画面とは別のブラウザ、あるいはシークレットウィンドウで、サイトのトップページを開いてください。表側が普通に表示されているなら、訪問者から見たサイトは動いています。緊急度が1段階下がるので、まずここを確認してください。
表側は無事で管理画面だけが落ちる、というのは珍しいことではありません。管理画面でしか実行されない処理の中にエラーがあると、この状態になります。逆に表側も同じ画面になっているなら、共通して読み込まれる部分に原因があります。
2. 直前に何をしたか
プラグインを追加した、テーマを更新した、PHP のバージョンを上げた、管理画面のエディタでコードを保存した。心当たりが1つでもあれば、それが原因である可能性がかなり高いです。自分で操作していなくても、自動更新が動いた可能性があります。
「昨日まで動いていたのに、何もしていないのに壊れた」と感じる場合でも、サーバー側の設定変更や自動更新など、自分の操作以外の変化が起きていることがあります。自動更新をどこまで任せるかについては別の記事で整理しています。
3. 復旧用のメールが届いていないか
WordPress は重大なエラーを検知すると、管理者のメールアドレス宛に、技術的な問題が起きたことを知らせるメールを自動送信します。このメールには「リカバリーモード」に入るためのリンクが含まれていて、そこから管理画面に入れます。迷惑メールフォルダも含めて確認してください。
リカバリーモードで復旧する
メール内のリンクを開くと、エラーの原因になっているプラグイン（またはテーマ）を一時的に停止した状態で管理画面に入れます。原因のプラグイン名も画面上に表示されます。
あとは、そのプラグインを停止したまま運用するか、削除するか、提供元の更新を待つかを判断するだけです。停止しても、そのプラグインが保存したデータがすぐ消えるわけではありません（削除した場合は消えることがあります）。まず停止して復旧させ、判断はそのあとで構いません。
メールが届かない — 管理画面にログインできないとき
次のような場合、リカバリーモードは使えません。
- 管理者のメールアドレスがすでに使われていないアドレスになっている（担当者の退職後によくあります）
- サイトからのメール送信そのものが機能していない
- リンクの有効期限が切れている（既定では発行から1日）
いずれの場合も管理画面にログインできないままなので、FTP かサーバーのファイルマネージャーでファイルを直接操作します。wp-content/plugins の中にあるプラグインのフォルダ名を変えると、WordPress はそのプラグインを見つけられなくなり、自動的に停止した扱いになります。どれが原因か分からないときは plugins フォルダごと名前を変えれば全部が止まるので、まず管理画面に入れる状態を作り、そこから1つずつ戻して原因を絞り込めます。
テーマが原因の場合も同様で、テーマのフォルダ名を変えると WordPress は既定のテーマに切り替わります。
原因を特定する — エラーログを見る
プラグイン名まで分かれば十分なことが多いのですが、「停止したら直ったが、なぜ落ちたのか分からない」という状態は、同じことを繰り返します。原因を文字で確認したいときはエラーログを見ます。
WordPress 側でログを取るには、wp-config.php に次の3行を書きます。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );🚨 3行目を省略しないでください。これを true にすると、エラーの内容が訪問者の画面にそのまま表示されます。ファイルの場所や使っているソフトウェアの構成が外から読めてしまうため、公開中のサイトでは必ず false にします。
この設定では wp-content/debug.log にログが書かれます。調査が終わったら3行とも消してください。ログファイルが公開ディレクトリに残ったままだと、内部の情報を外部から読める状態になります。
ログには、エラーの種類・メッセージ・発生したファイル名と行番号が記録されます。ファイル名を見れば、どのプラグインやテーマの中で止まったかが分かります。
原因の型は、だいたい4つ
プラグインやテーマの更新
最も多い型です。更新自体は正常に完了していても、他のプラグインとの組み合わせや、そのサイト固有の設定で落ちることがあります。「更新が成功した」ことと「サイトが正常に動いている」ことは別です。
PHP のバージョン変更
サーバーの PHP を新しくすると、古い書き方で作られたプラグインやテーマが動かなくなることがあります。PHP では過去に廃止された関数がいくつもあり、それを使っているコードは新しい PHP では実行された瞬間に停止します。
この型には特徴があります。PHP を切り替えた日ではなく、その機能を初めて使った日に発症します。管理画面の特定のページでしか動かないコードなら、そのページを開くまで誰も気づきません。「先週バージョンを上げたが問題なかった」ことは、安全である証明になりません。
コードの直接編集
管理画面のテーマエディタやプラグインエディタでコードを保存した直後に発生する型です。書き間違いがそのまま反映されるため、保存した瞬間に落ちます。この経路で壊した場合、管理画面に入れなくなるので同じ画面から直せません。ファイルを直接戻すことになります。
サーバー側の制限
PHP が使えるメモリの上限に達した場合も同じ画面になります。この場合はログに「メモリを使い果たした」旨が記録されるので、判別できます。プラグインを増やしたあとや、大きな画像を扱ったときに起こりやすい型です。
直したあと、再発させないために
復旧できたら、次の3つだけは確認しておく価値があります。
- 管理者のメールアドレスが、今も届くアドレスになっているか。ここが切れていると、次に同じことが起きたときの復旧手段が1つ失われます
- 直前の状態に戻せるバックアップがあるか。取れていることと戻せることは別です。この違いについては別の記事で書きました
- 同じ更新を、いきなり本番に当てない仕組みがあるか。更新を止めるのではなく、当たり方を管理するという考え方です
「重大なエラー」は、それ自体が異常なのではなく、異常を検知して止まった結果です。止まらずに動き続けて、フォームの送信だけが静かに失敗しているほうが、発見が遅れるぶん損害は大きくなります。この画面が出たということは、少なくとも異常には気づけたということです。
