「ある日突然、WordPressの画面に『このサイトで重大なエラーが発生しました。対応手順については、サイト管理者のメールアドレスに送信された手順を確認してください。』と表示されて管理画面にも入れなくなった」――そんな切迫したトラブルに直面していませんか？
この「重大なエラー」画面は、WordPress 5.2以降に導入された「致命的エラー保護機能（WSOD保護・リカバリー機能）」によるものです。従来の「画面が真っ白になる（White Screen of Death）」現象とは異なり、システムが致命的なPHPエラーを検知してサイトを保護している状態を示しています。
🚨 重大なエラーに直面した時の緊急初動チェック
- 管理者メールを最優先で確認：管理者宛てに「サイトで技術的な問題が発生しています」というメールが届いていれば、専用リンクから「リカバリーモード」で安全にログインして1分で復旧できます。
- メールが届かない場合も自力復旧可能：
wp-config.phpでデバッグモード（WP_DEBUG）を有効化し、エラーログ（debug.log）を確認することで、原因となっているプラグインやテーマを即座に特定・無効化できます。 - パニックによる再インストールは厳禁：焦ってWordPressを再インストールしたりファイルを削除したりするとデータ消失のリスクがあります。本ガイドの手順通りに進めれば、データを安全に保持したまま確実に復旧できます。
本記事では、WordPressの「重大なエラー」が発生する5大原因、管理者メールの有無に応じた最短復旧フローチャート、FTPを用いたプラグイン・テーマの強制停止手順、PHPバージョンの見直し、そして復旧後の必須セキュリティ後片付けまで、初心者にもわかりやすく徹底解説します。
—
WordPress「このサイトで重大なエラーが発生しました」とは？発生する仕組みと5大原因
まずは、なぜこのエラー画面が表示されているのか、その仕組みと代表的な原因を把握しましょう。
従来の「画面真っ白（WSOD）」との違いと致命的エラー保護機能
WordPress 5.1以前の環境では、PHPプログラムに致命的なエラー（Fatal Error / Parse Errorなど）が発生すると、ブラウザ上にエラーメッセージがそのまま露出するか、あるいは何も表示されない「画面真っ白（White Screen of Death / WSOD）」や「500 Internal Server Error」になっていました。
しかしWordPress 5.2以降、「Fatal Error Protection（致命的エラー保護機能）」が標準実装されました。これにより、致命的エラーが発生した瞬間にWordPressがそれをインターセプト（捕捉）し、訪問者には一律で「重大なエラーが発生しました」という安全な通知画面を表示した上で、サイト管理者へエラー詳細と復旧用の専用URLをメール送信する仕組みに進化しました。
重大なエラーが発生する5大原因一覧
「重大なエラー」が引き起こされる根本的な原因は、ほぼ100%がPHPプログラムの実行失敗（Fatal Error）です。具体的には以下の5つのパターンに大別されます。
| 発生原因 | 主な発生シチュエーション | 解決難易度・対処の方向性 |
|---|---|---|
| 1. プラグインの競合・不具合 | プラグインの新規有効化、一括アップデート、PHPバージョンとの非互換 | 【低〜中】リカバリーモードまたはFTPで該当プラグインフォルダを無効化 |
| 2. functions.phpの構文エラー | テーマの functions.php を直接編集した直後（全角スペース、タイポ、セミコロン抜け） |
【低】FTPでファイルをダウンロードし直前の追記行を修正・削除 |
| 3. テーマの更新失敗・不具合 | 親テーマ・子テーマの更新後、テンプレートファイルの読み込みエラー | 【中】FTPでテーマフォルダ名を変更しデフォルトテーマへ強制切替 |
| 4. PHPバージョンのミスマッチ | サーバーパネルでPHP 8.1 / 8.2 / 8.3に切り替えた直後の非互換エラー | 【低】サーバー管理画面でPHPバージョンを一時的に戻す |
| 5. PHPメモリ上限（memory_limit）不足 | 高機能プラグイン（Elementor、WooCommerce等）や画像一括処理の実行時 | 【低】wp-config.php で WP_MEMORY_LIMIT を256M以上に拡張 |
—
【最短復旧フローチャート】メールが届いているか・届かないかで分岐する2大対処法
重大なエラーが発生した際、復旧のアプローチは「サイト管理者宛てに技術通知メールが届いているかどうか」で大きく2つに分かれます。
⚡ あなたはどちら？最速復旧ルート判定
🅰️ 管理者メールに「サイトで技術的な問題が発生しています」が届いている場合
👉 最速1分復旧ルート：メール内の「リカバリーモード用URL」からログインし、問題のプラグインをワンクリックで停止します（【パターンA】へ進む）。
🅱️ 管理者メールが届かない・管理画面にも一切入れない場合
👉 デバッグモード調査ルート：FTPで wp-config.php を開きデバッグログを出力、原因ファイルを特定してリネーム停止します（【パターンB】へ進む）。
—
【パターンA】管理者メールが届いている場合：リカバリーモードでの安全な復旧手順
WordPressの管理者用メールアドレス（「設定」>「一般」に登録されたメール）の受信ボックスを確認し、件名「[サイト名] サイトで技術的な問題が発生しています」というメールが届いている場合は、公式のリカバリーモード機能を使って安全に復旧できます。
1. 管理者メールに記載された「リカバリーモード用リンク」をクリック
届いたメールの本文には、エラーが発生した原因のプラグイン/テーマ名、エラー箇所のファイル名・行番号、そして以下のようなリカバリーモード専用リンクが記載されています。
https://example.com/wp-login.php?action=enter_recovery_mode&rm_token=XXXXXXXX&rm_key=YYYYYYYY⚠️ 注意：リカバリーモードURLの有効期限
リカバリーモード用リンクの有効期限は発行から24時間（または1回使用するまで）です。期限が切れた場合は、ブラウザで再度エラー画面を表示させるか、Cookieを削除して再アクセスすることで新しいメールが発行されます。
2. リカバリーモードで管理画面にログインする
リンクをクリックすると、WordPressの通常のログイン画面が表示されます。普段お使いの管理者ユーザー名とパスワードを入力してログインしてください。
ログインに成功すると、管理画面の最上部に赤いバナーで「リカバリーモード中」と表示されます。この状態では、エラーを引き起こしているプラグインやテーマが管理者自身にのみ一時的に無効化されており、安全に管理画面を操作できます。
3. エラー原因となっているプラグイン・テーマを停止・修復
管理画面の「プラグイン」または「外観 > テーマ」メニューを開くと、エラーを引き起こしている項目に「1個以上のプラグインがエラーを引き起こしました」という警告が表示されます。
- プラグインが原因の場合：該当プラグインの下に表示される「停止」リンクをクリックします。
- テーマが原因の場合：別のテーマ（WordPress標準の Twenty Twenty-Four など）を「有効化」して切り替えます。
4. リカバリーモードを終了して通常表示を確認
原因のプラグインを停止したら、管理画面の右上（管理バー）にある「リカバリーモードを終了」ボタンをクリックします。
その後、ブラウザのシークレットウィンドウ等でサイトのトップページおよび管理画面にアクセスし、重大なエラー画面が消えて正常にサイトが表示されることを確認してください。
—
【パターンB】メールが届かない場合：wp-config.php でデバッグモード（WP_DEBUG）を有効化して原因を特定する
「迷惑メールフォルダを探してもメールが届いていない」「サーバーのメール送信機能（sendmail/SMTP）が未設定だった」「管理画面にそもそもログインできない」という場合は、WordPressのデバッグモード（WP_DEBUG）を利用して原因を突き止めます。
1. FTPまたはサーバーファイルマネージャーで wp-config.php を開く
FileZillaなどのFTPソフト、またはレンタルサーバー（エックスサーバー、ConoHa WING、ロリポップ、さくらのレンタルサーバ等）の「ファイルマネージャー」機能を使って、WordPressのインストールディレクトリ（ルートディレクトリ）にアクセスします。
ルート直下にある wp-config.php ファイルをPCにダウンロードし、バックアップ用として複製（コピー）を保存した上で、テキストエディタで開きます。
2. デバッグモード有効化コードを記述（本番用の安全設定）
wp-config.php 内で /* 編集が必要なのはここまでです ! */ または define( 'WP_DEBUG', false ); と書かれている部分を探します。
既存の WP_DEBUG の記述を、以下の本番環境用安全デバッグ設定コードに書き換えて上書き保存し、サーバーへアップロードします。
// === デバッグモード有効化（本番安全設定） ===
define( 'WP_DEBUG', true ); // デバッグモードを有効化
define( 'WP_DEBUG_LOG', true ); // エラー内容を wp-content/debug.log に記録
define( 'WP_DEBUG_DISPLAY', false ); // 訪問者の画面にはエラーを表示させない
@ini_set( 'display_errors', 0 ); // PHPエラーの画面出力を確実に抑制
// ==========================================💡 なぜ WP_DEBUG_DISPLAY を false にするのか？
WP_DEBUG_DISPLAY を true にすると、サイト訪問者の画面上にサーバーの絶対パスやデータベース構造などの機密情報が露出してしまい、セキュリティ上の深刻なリスク（情報漏洩）に繋がります。本番環境では必ず false に設定し、ログファイル（debug.log）に出力させるのが鉄則です。
3. サイトを再読み込みして wp-content/debug.log を確認する
wp-config.php をアップロードしたら、ブラウザでエラーが発生しているWordPressサイト（トップページまたは管理画面）にアクセスし、ページを1〜2回再読み込み（リロード）します。
次に、FTPソフトで /wp-content/ フォルダ内を確認すると、新たに debug.log というログファイルが生成されています。このファイルをダウンロードして開きます。
4. エラーログから問題のファイル名・行番号を特定する読み解き方
debug.log の最下部（最新のログ）付近を確認すると、以下のような Fatal error や Parse error の記述が見つかります。
[30-Aug-2026 06:40:12 UTC] PHP Fatal error: Uncaught Error: Call to undefined function example_broken_function() in /home/user/example.com/public_html/wp-content/plugins/seo-custom-pack/seo-custom-pack.php on line 142このログから以下の情報が即座に特定できます：
- エラー種別：
Fatal error（未定義関数の呼び出し） - 原因箇所：
/wp-content/plugins/seo-custom-pack/（＝「seo-custom-pack」というプラグインが原因） - 該当ファイルと行番号：
seo-custom-pack.phpの 142行目
原因がプラグイン、テーマ、あるいは functions.php のいずれであるかが判明したら、次の章の「原因別の直し方」を実行します。
—
【原因別】重大なエラーの具体的な直し方・トラブル解決手順
ログや直前の操作から特定した原因に応じて、以下の適切な復旧手順を実行してください。
原因1：プラグインが原因の場合（FTPでフォルダ名リネームによる強制停止）
エラーを引き起こしているプラグインが特定できた場合、FTPを使ってそのプラグインフォルダの名前を変更（リネーム）することで、WordPress側で「強制的にプラグインを停止（無効化）」させることができます。
- FTPで
/wp-content/plugins/ディレクトリを開きます。 - エラー原因のプラグインフォルダ（例:
seo-custom-pack）の名前を変更します。
例：seo-custom-pack➔seo-custom-pack_disabled - ブラウザでサイトを再読み込みします。これでプラグインが無効化され、サイトが正常に表示されるようになります。
- 管理画面にログインし、該当プラグインを削除するか、最新版へアップデートして互換性を確認します。
📌 どのプラグインが原因かわからない場合の一括停止テクニック
原因プラグインが特定できない場合は、/wp-content/plugins フォルダ自体の名前を一時的に plugins_temp にリネームしてください。全プラグインが一括停止されサイトが復旧します。その後フォルダ名を plugins に戻し、管理画面から1つずつ有効化して原因プラグインを特定できます。
原因2：functions.php の編集ミス（構文エラー・全角スペース・タイポ修正）
テーマの functions.php にカスタマイズコードを追記した直後にエラーが発生した場合は、PHPの構文エラー（Parse error / Syntax error）が原因です。
- FTPで現在使用中のテーマフォルダ（
/wp-content/themes/使用中テーマ名/）を開きます。 functions.phpをPCにダウンロードし、テキストエディタ（VS Codeなど）で開きます。- 直前に追加・変更したコードを削除するか、末尾のセミコロン（
;）抜け、カッコの閉じ忘れ（}）、誤って混入した全角スペースを修正します。 - ファイルを上書き保存し、FTPでサーバーへアップロード（上書き）します。
- ブラウザをリロードしてエラーが解消されたか確認します。
原因3：テーマの不具合（デフォルトテーマへの強制切り替え）
使用しているテーマ自体にバグがある、またはテーマ更新に失敗した場合は、WordPress公式のデフォルトテーマに強制切り替えを行います。
- FTPで
/wp-content/themes/を開きます。 - 現在有効化しているテーマフォルダの名前を変更します（例:
my-theme➔my-theme_old）。 - WordPressは現在のアクティブテーマが見つからない場合、自動的にインストールされているデフォルトテーマ（Twenty Twenty-Four等）にフォールバック（自動切替）します。
- サイトが表示されたら、テーマ作者への問い合わせや子テーマの記述見直しを行ってください。
原因4：PHPバージョンの互換性問題（サーバーパネルでのバージョン切替）
レンタルサーバーのコントロールパネルでPHPのバージョン（例: PHP 7.4からPHP 8.2/8.3へ）を変更した直後に重大なエラーが発生した場合、利用中の古いプラグインやテーマが最新のPHP仕様に対応していません。
- レンタルサーバーの管理画面（サーバーパネル）にログインします。
- 「PHPバージョン切替」メニューを開きます。
- PHPバージョンを変更前の安定していたバージョン（または推奨互換バージョン）に一時的に戻します。
- サイトが正常復旧することを確認した上で、古いプラグインの代替品への乗り換えや更新を進めます。
※PHPバージョンの選び方と安全なアップグレード手順の詳細は、「WordPressとPHPバージョンの互換性・推奨対応表と安全なバージョンアップ手順」をご参照ください。
原因5：PHPメモリ上限不足（wp-config.phpでメモリ割り当て拡張）
エラーログに Fatal error: Allowed memory size of XXXXX bytes exhausted と記録されている場合、WordPressに割り当てられているPHPメモリの上限を超過しています。
wp-config.php の /* 編集が必要なのはここまでです ! */ の直前に以下のコードを追記し、メモリ上限を拡張してください。
// WordPressのPHPメモリ上限を256MBに拡張
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );—
【復旧後の必須作業】デバッグ停止とログ削除によるセキュリティ対策
サイトが無事に復旧したら、必ず以下のセキュリティ後片付けを実施してください。これを怠ると、サイトが重大なセキュリティリスクに晒されます。
1. wp-config.php のデバッグモードを無効（false）に戻す
wp-config.php を再度開き、デバッグ設定を無効化します。
// デバッグモードの無効化（通常運用状態）
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );2. wp-content/debug.log を必ずサーバーから削除する
調査のために生成された /wp-content/debug.log ファイルは、FTPを使ってサーバーから完全に削除してください。
🚨 警告：debug.log の放置は情報漏洩の温床
debug.log にはサーバーの内部ディレクトリ構造、データベースクエリ、インストール済みプラグイン一覧などの機密情報が含まれています。Webブラウザから https://example.com/wp-content/debug.log へ直接アクセスされると、悪意のある攻撃者にサイトの脆弱性情報をすべて渡してしまう危険性があります。
3. 管理者通知用メールアドレスと送信設定（SMTP）の点検
今回「重大なエラーの通知メールが届かなかった」場合は、次回以降に備えてメール送信環境を整えておきましょう。
- 「設定 > 一般」の「管理者メールアドレス」が正しく受信可能なアドレスになっているか確認する。
- 「WP Mail SMTP」などのプラグインを導入し、サーバー標準の
mail()関数ではなく正規のSMTPサーバー経由で確実にメール配信されるように設定する。
—
WordPress重大なエラーの再発を防ぐ予防チェックリスト＆MozCheck無料診断
重大なエラーによるサイト停止は、売上損失やSEO評価の下落に直結します。トラブルを未然に防ぐため、以下の運用ルールを習慣化しましょう。
🛡️ 重大なエラーを二度と起こさないための5大予防策
- 1. 更新前の定期バックアップ自動化：プラグインやテーマの更新前には、必ずデータベースとファイル全体のバックアップを取得する（バックアップと復元ガイド参照）。
- 2. プラグインの一括更新を避ける：複数プラグインの更新は1つずつ実施し、どのプラグインが不具合の原因かを即座に特定できるようにする。
- 3. functions.phpの直接編集をやめる：「Code Snippets」プラグイン等を活用し、万一構文エラーがあっても管理画面全体がクラッシュしない仕組みを導入する。
- 4. 最終更新が古いプラグインを削除・厳選する：2年以上更新が停止しているプラグインはPHP 8系で致命的エラーを引き起こすだけでなく、脆弱性の標的になります。
- 5. 定期的なセキュリティ・脆弱性診断を実施する：改ざんやマルウェアによるコード不正書き換えが原因で重大なエラーが発生するケースも増加しています。
🔒 あなたのWordPressサイト、知らずに脆弱性を抱えていませんか？
重大なエラーを引き起こす古いプラグインやテーマには、不正アクセスや改ざんの原因となる深刻なセキュリティ脆弱性が潜んでいるケースが少なくありません。
MozCheckなら、URLを入力するだけでWordPressのコア・プラグイン・サーバー設定のセキュリティリスクを完全無料・即座に診断できます。
—
よくある質問（FAQ）
Q1. リカバリーモードのリンク有効期限が切れた場合はどうすればいいですか？
A. リカバリーモードリンクは発行から24時間で無効になります。ブラウザで再度エラー画面を表示させるか、ブラウザのCookie（wp_recovery_mode 関連）を削除してサイトに再アクセスすると、新しい通知メールとリンクが再発行されます。それでも届かない場合は、本記事の「【パターンB】デバッグモード調査」をお試しください。
Q2. 重大なエラーが出ている間、一般の訪問者にはどのように見えていますか？
A. 一般の訪問者画面にも「このサイトで重大なエラーが発生しました」という標準エラー画面（HTTPステータス500）が表示され、コンテンツは閲覧できない状態になっています。放置するとユーザー離脱や検索エンジンのインデックス順位低下の原因となるため、速やかな復旧が必要です。
Q3. 自力で復旧できない場合はどこに相談すべきですか？
A. データベースの破損やコアファイルの改ざんなど、自力での解決が困難な場合は、契約しているレンタルサーバーのサポート窓口や、WordPress専門の保守・復旧サービス（WordPress保守・復旧サービスの選び方参照）に相談することをおすすめします。
—
📚 あわせて読みたい関連記事
2026/08/30/wordpress-403-forbidden-cause-solution-guide/”>WordPressの403 Forbiddenエラー原因と直し方完全ガイド｜管理画面・記事保存時のWAF解除から.htaccess・パーミッション復旧まで
コメントを残す