「サイトに重大なエラーが発生しました」が出たときの切り分け手順

ある日突然、サイトを開くと「このサイトで重大なエラーが発生しました」と表示され、管理画面にも入れない。WordPressを運用していれば、一度は遭遇するトラブルです。画面が真っ白になる「ホワイトスクリーン（WSOD）」と並んで、制作者を最も焦らせる症状といえます。

しかし、このエラーは「PHPの致命的エラーをWordPressが検知して、画面表示を止めている」というだけの話で、原因は意外とパターン化されています。闇雲にファイルを触るのではなく、正しい順番で切り分ければ、ほとんどの場合は短時間で復旧できます。

この記事では、エラーが出たときに何から確認し、どの順で原因を絞り込むかを、実際の作業手順に沿って解説します。

まず知っておきたい：このエラーの正体

「このサイトで重大なエラーが発生しました。サイト管理者宛のメールボックスで手順を確認してください。」というメッセージは、WordPress 5.2から追加された「致命的エラー保護機能」によるものです。以前は何も表示されない白い画面になっていたものが、このメッセージに置き換わりました。

つまり、画面が変わっただけで、原因はこれまでのホワイトスクリーンと同じです。主な原因は次のとおりです。

  • プラグインのPHPエラー（更新失敗、PHPバージョンとの非互換、プラグイン同士の競合）
  • テーマのPHPエラー（functions.phpの記述ミス、構文エラー）
  • PHPバージョンの変更によるエラー（サーバー側でPHPを上げた直後に多い）
  • メモリ不足（memory_limitの超過）
  • WordPress本体の更新が途中で止まった状態
  • データベース接続の問題（この場合は別のエラー画面になることも多い）

実務で圧倒的に多いのは、「プラグイン・テーマの更新または編集の直後」と「サーバーのPHPバージョン変更の直後」です。まず「直前に何をしたか」を思い出すことが、最短の近道になります。

切り分けの全体像

手順は次の順で進めます。上から順に試し、直った時点で止めてください。

  1. 直前の作業を確認し、通知メールを見る
  2. デバッグログを出力して、エラー内容を読む
  3. リカバリーモードで管理画面に入る
  4. プラグインを全停止して原因を絞る
  5. テーマを標準テーマに切り替える
  6. PHPバージョン・メモリ上限を確認する
  7. 最終手段：本体ファイルの再配置・バックアップからの復元

手順1：直前の作業と通知メールを確認する

致命的エラーが起きると、WordPressは管理者メールアドレスに「サイトでの技術的な問題」という件名のメールを送ります。このメールには、エラーの原因になったプラグインやテーマの名前と、リカバリーモード用のリンクが書かれています。

メールが届いていれば、原因の大半はそこで分かります。迷惑メールフォルダに入っていることもあるため、あわせて確認しましょう。メールが見つからない場合や、管理者メールが使われていないアドレスの場合は、次のデバッグログで調べます。

また、次の質問に答えられるようにしておくと、原因の見当がつきます。

  • エラーが出る直前に、プラグインやテーマを更新・追加・編集したか
  • サーバー側でPHPのバージョンを変更したか
  • エラーはサイト全体か、特定のページだけか
  • 管理画面には入れるか

特定のページだけがエラーになる場合は、そのページで使っているプラグインやショートコード、テンプレートファイルが怪しいと絞り込めます。

手順2：デバッグログを出力してエラー内容を読む

原因を推測で探すより、エラーメッセージそのものを見るほうが確実です。wp-config.phpに次の設定を追加して、ログをファイルに出力します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

この記述は、wp-config.phpの中の「/* 編集が必要なのはここまでです ! */」より上に書きます。下に書いても反映されません。

ポイントは WP_DEBUG_DISPLAY を false にしておくことです。本番サイトでエラーを画面に直接出すと、サーバーのパスなどの情報が訪問者に見えてしまいます。ログファイルに出すだけにしておけば、訪問者には影響しません。

設定後にもう一度エラー画面を表示させると、wp-content/debug.log が生成されます。FTPやファイルマネージャーで開くと、次のような行が見つかります。

PHP Fatal error:  Uncaught Error: Call to undefined function xxxx() in /home/example/public_html/wp-content/plugins/sample-plugin/sample.php:123

見るべきところは、次の3点です。

  • Fatal error の種類：未定義の関数、構文エラー、メモリ不足など
  • ファイルのパス：/plugins/○○/ ならプラグイン、/themes/○○/ ならテーマが原因
  • 行番号：直前に編集した箇所と一致するか

パスにプラグインのフォルダ名が出ていれば、原因はほぼ特定できたことになります。そのプラグインのフォルダ名を変更（例：sample-plugin を sample-plugin_off に）すれば、WordPressはそのプラグインを読み込まなくなり、サイトが復旧することが多いです。

なお、原因の調査が終わったら、デバッグの設定は必ず元に戻すか削除してください。debug.log もブラウザから見える場所にあるため、確認後に削除しておくのが安全です。

手順3：リカバリーモードで管理画面に入る

通知メールに「リカバリーモード」のリンクがあれば、それを開いてログインします。リカバリーモードでは、エラーの原因になっているプラグインやテーマだけが停止された状態で管理画面に入れます。

画面の案内に従い、原因として表示されたプラグインを「無効化」するか、必要ならテーマを切り替えてください。その後リカバリーモードを終了すれば、通常の状態に戻ります。

この方法は便利ですが、メールが届かない環境や、リンクの有効期限が切れている場合は使えません。その場合は次の手順に進みます。

手順4：プラグインを全停止して原因を絞る

管理画面に入れる場合は、プラグイン一覧からすべてを選択して「無効化」します。入れない場合は、FTPで wp-content/plugins フォルダの名前を plugins_off などに変更します。これでWordPressはすべてのプラグインを読み込まなくなります。

なお、wp-content/mu-plugins フォルダに置かれたファイル（mu-plugin）は、この方法では停止できません。サイト固有の機能をmu-pluginとして置いている場合は、手順5のあとに、このフォルダの名前も一時的に変更して確認してください。

この状態でサイトが表示されれば、原因はプラグインにあると確定します。次の流れで犯人を探してください。

  1. フォルダ名を plugins に戻す
  2. 管理画面のプラグイン一覧で、すべて「停止中」になっていることを確認する
  3. 1つずつ有効化して、そのたびにサイトの表示を確認する
  4. エラーが再現したプラグインが原因

数が多い場合は、半分ずつ有効化して二分探索すると早く見つかります。原因のプラグインが分かったら、次のどれかで対応します。

  • プラグインを最新版に更新する（更新で直る場合が多い）
  • PHPバージョンとの互換性を確認し、必要なら代替プラグインに乗り換える
  • 他のプラグインとの競合なら、組み合わせを見直す

プラグインを停止すると、設定値は多くの場合データベースに残るため、再有効化すれば元に戻ります。ただし、ウィジェットやショートコードで表示していた部分は、停止中は表示が崩れます。本番サイトで行う場合は、アクセスの少ない時間帯に短時間で済ませましょう。

手順5：テーマを標準テーマに切り替える

プラグインを全停止しても直らない場合は、テーマを疑います。管理画面に入れるなら「外観」から標準テーマ（Twenty Twenty-Fiveなど）を有効化します。入れない場合は、FTPで現在使用中のテーマのフォルダ名を変更します。

使用中のテーマのフォルダが見つからなくなると、WordPressは自動的に標準テーマへ切り替えようとします。標準テーマがインストールされていないとエラーになるため、事前に標準テーマを1つ入れておくと安心です。

自動で切り替わった場合は、フォルダ名を元に戻しただけでは元のテーマに戻らないことがあります。管理画面の「外観」から元のテーマを再度有効化し、メニューやウィジェットの割り当てが崩れていないか確認してください。

標準テーマでサイトが表示されれば、原因は元のテーマ、特に functions.php です。次のような原因が多く見られます。

  • 括弧やセミコロンの閉じ忘れ（構文エラー）
  • 同じ名前の関数を二重に定義している
  • 新しいPHPで廃止された関数を使っている

functions.phpを直前に編集していたなら、編集前のファイルに戻すのが最も早い対処です。ログに出ている行番号を手がかりに、該当箇所を確認してください。

なお、functions.phpの末尾の閉じタグ ?> のあとに空白や改行があると、「headers already sent」といった警告の原因になります。これは致命的エラーとは別の症状ですが、画面が崩れる原因になるため、PHPだけのファイルでは閉じタグを書かないのが一般的です。

手順6：PHPバージョンとメモリ上限を確認する

プラグインとテーマに問題がなければ、サーバー環境を確認します。

PHPバージョン

レンタルサーバーのコントロールパネルでPHPを上げた直後にエラーが出た場合は、いったんバージョンを元に戻して様子を見ます。古いプラグインやテーマは、新しいPHPで非推奨・廃止された書き方を使っていると、致命的エラーを起こすことがあります。

元に戻して直るなら、原因は古いコードとの非互換です。放置せず、該当のプラグインやテーマを更新してから、改めてPHPのバージョンを上げましょう。古いPHPのまま使い続けると、セキュリティ更新が受けられなくなります。

メモリ上限

ログに「Allowed memory size of ○○ bytes exhausted」とあれば、メモリ不足です。wp-config.phpに次を追加して上限を引き上げます。

define( 'WP_MEMORY_LIMIT', '256M' );

ただし、サーバー側の上限が低いと反映されません。その場合は、レンタルサーバーの設定でmemory_limitを上げるか、サーバーのプランを見直します。また、メモリを大量に消費するプラグインが原因のこともあるため、上限を上げて終わりにせず、重いプラグインがないかも確認しておくと再発を防げます。

手順7：最終手段として本体の再配置・復元を行う

ここまでで直らない場合は、WordPress本体のファイルが壊れている可能性があります。更新の途中でサーバーとの接続が切れた場合などに起こります。

対処は、公式サイトから同じバージョンのWordPressをダウンロードし、手動で更新する手順に沿って入れ直すことです。公式の手順では、サーバー上の古い wp-admin と wp-includes の2フォルダをいったん削除してから、新しいものをアップロードします（上書きだけだと、古いファイルが残ることがあります）。ルート直下のファイルも新しいものに置き換えます。

このとき、wp-config.php と wp-content フォルダは削除したり、フォルダごと置き換えたりしないでください。wp-contentには、記事の画像やテーマ、プラグインが入っています。なお、ダウンロードしたZIPに含まれるのは wp-config-sample.php で、wp-config.php は含まれません。作業の前には、必ずバックアップを取りましょう。

それでも直らなければ、バックアップからの復元を検討します。レンタルサーバーの自動バックアップや、バックアッププラグインのデータが使えるか、普段から確認しておくことが大切です。

再発を防ぐための運用ポイント

復旧できたら、同じ事故を繰り返さないための準備もしておきましょう。

  • 更新前にバックアップを取る：特にPHPバージョンの変更、本体やプラグインの一括更新の前は必須です。
  • 本番でいきなり更新しない：可能ならステージング環境やローカルで先に更新を試します。
  • functions.phpを本番で直接編集しない：構文エラー1つでサイト全体が止まります。ローカルで確認してからアップロードします。
  • 管理者メールを受信できるアドレスにする：通知メールが届かないと、リカバリーモードが使えません。
  • 不要なプラグインは削除する：停止中のままのプラグインも、脆弱性の原因になります。
  • 標準テーマを1つ残しておく：緊急時の切り替え先として役立ちます。

まとめ

「このサイトで重大なエラーが発生しました」は、焦る表示ですが、原因を順に切り分ければ落ち着いて対処できます。要点を振り返ります。

  • まず、直前の作業と通知メールを確認する
  • デバッグログを出して、エラーのファイルパスから原因のプラグイン・テーマを特定する
  • プラグイン全停止、標準テーマへの切り替えで原因の範囲を絞る
  • PHPバージョン、メモリ上限などサーバー側も確認する
  • 最終手段は本体の再配置とバックアップ復元（wp-configとwp-contentは上書きしない）

何より大切なのは、更新前のバックアップです。バックアップさえあれば、どんな原因でも最後は元に戻せます。ぜひ日頃の運用に取り入れてください。

コメント

タイトルとURLをコピーしました