WordPressの致命的エラー(Fatal Error)を素早く安全に解決する最良の方法は、まずサイトを復旧させ、その後エラーの原因となるプラグインを1つずつ隔離して特定することです。多くの場合、問題は互換性のないプラグイン更新、PHPバージョンの不一致、テーマとプラグイン間の関数競合、メモリ不足などが原因です。管理画面にアクセスできない場合は、FTPやファイルマネージャ、ホスティングのコントロールパネルからプラグインフォルダを一時的に停止し、エラーログを調査することで、どのプラグインがサイトを落としているか正確に把握できます。
本ガイドでは、WordPressサイトで発生するFatal Errorを慌てず冷静に分析し、原因となるプラグインを見つけ、再発防止のための恒久的な対策まで、段階的に詳しく解説します。技術知識が限られたサイトオーナーでも実践できるように、かつ開発者や制作会社のチェックリストとしても使えるように、実用的かつ詳細にまとめています。
WordPressのFatal Error(致命的エラー)とは?
WordPressのFatal Errorとは、PHP側で極めて重大なエラーが発生し、処理を続行できなくなった時に表示されるサイトの停止状態です。エラーは「真っ白な画面」や「重大なエラーが発生しました」というメッセージ、あるいは特定のPHPファイルを指す技術的なエラー出力として現れることがあります。WordPressのコア、テーマ、プラグインはすべてPHPで動作するため、たった1行の不適合コードがサイト全体の表示を妨げることもあります。
例えば、プラグインがPHP 8.2に対応していない場合、ホスティング側でPHPバージョンを上げるとサイトがFatal Errorとなります。また、複数のプラグインが同じ関数を定義しようとした場合、WordPressは同じ関数を二重に読み込めず動作を停止します。エラーメッセージ内のファイルパスが重要で、wp-content/plugins/プラグイン名と表示されていれば、ほぼプラグインが原因です。
Fatal Errorの症状と初期チェックポイント
Fatal Errorは必ずしも同じ画面に現れません。WordPress 5.2以降では多くの重大なエラーが管理者へメールで「リカバリーモード」のリンク付きで通知されます。しかしメールが届かない、あるいはエラーが起動直後の場合は手動対応が必要です。下記の症状はプラグイン由来のFatal Errorの可能性を高めます:
- サイトのフロントが完全に白画面になる
- 管理画面ログイン時に「重大なエラーが発生しました」と表示される
- 特定ページ(例:決済ページ、問い合わせフォーム)でサイトが落ちる
- 最近プラグインを更新した直後からエラーが始まった
- エラーメッセージにwp-content/pluginsフォルダ以下のファイル名が表示される
- サーバーエラーログにPHP Fatal errorの行が繰り返し記録されている
初期確認時には、直近24時間で何が変わったかメモしましょう。新しいプラグインの導入、既存プラグインの更新、PHPバージョンの変更、テーマのアップデート、セキュリティプラグインの新規ルール追加など。最も多いケースは、自動更新されたプラグインが使用しているテーマやPHPバージョンと合わなくなることです。
クイック診断表:エラー原因の見極め方
| 症状 | 推定原因 | 初期アクション |
|---|---|---|
| エラーメッセージにwp-content/plugins表示 | プラグイン競合やコードエラー | 該当プラグインを無効化 |
| エラーメッセージにwp-content/themes表示 | テーマファイルや機能の問題 | デフォルトテーマへ切り替え |
| Allowed memory size exhausted表示 | PHPメモリ不足 | メモリ制限を増やす |
| Call to undefined functionエラー | 依存関係不足やバージョン不一致 | プラグインとPHPバージョンを確認 |
| Parse errorやsyntax error表示 | コード編集ミス | 直前のファイル変更を戻す |
この表は素早く方向性を決めるためのものです。最終的にはエラーログを必ず調査し、問題のプラグインを慎重にテストしましょう。特にECサイトでは無計画なファイル削除が注文処理や決済連携に影響することがあります。
作業開始前の安全準備
Fatal Error時に最も危険なのは、慌ててファイルを削除したり、データベースを無計画に操作することです。まず復旧可能性を確保しましょう。特にWooCommerceや会員システム、予約モジュールなど動的データを扱う場合は、ライブサイトでの操作がデータ損失リスクとなります。
- 1. フルバックアップ:ファイルとデータベース両方をバックアップ。public_htmlフォルダだけでは不十分です。
- 2. エラー発生時刻の記録:問題発生の時間をメモしておくと、サーバーログの該当行を探しやすくなります。
- 3. 最近の変更リスト:更新したプラグイン、PHPバージョン、テーマ変更、追加コードなどを書き出す。
- 4. 可能ならステージング環境でテスト:本番サイトの代わりにコピー環境で検証する方が安全です。WordPressホスティング
- 5. 管理者アクセスの確認:FTP、ホスティングパネル、データベースアクセスをすぐ使える状態に。
プロ向けのホスティングでは、日次バックアップ、簡単なファイル管理、PHPバージョン切り替えやエラーログアクセスが数分で可能です。WordPressサイトではストレージ容量だけでなく管理ツールや技術サポートの質にも注目しましょう。ウェブホスティング
WordPress Fatal Error解決ステップ
1. WordPressリカバリーモードメールを確認
WordPressが重大なエラーを検知すると、管理者登録メールアドレスにリカバリーモードのリンクを送ります。このリンクから問題のプラグインを管理画面で無効化できます。受信トレイやスパムフォルダ、メール転送設定も確認しましょう。メールには通常、どのプラグインがエラー原因かも記載されています。
リカバリーモードが動作すれば手順は簡単です:リンククリック→WordPress管理画面へ→プラグインページで問題プラグインを無効化→サイト復旧を確認。その後、すぐ再有効化せず、更新履歴やサポートフォーラム、PHP互換性を調査します。
2. 管理画面に入れない場合はプラグイン全停止
管理画面にアクセスできない場合、wp-content/pluginsフォルダ名を一時変更するのが最も簡単です。FTPクライアントやSSH、ホスティングのファイルマネージャでpublic_html/wp-contentフォルダへ移動し、pluginsフォルダ名を「plugins-off」などに変更します。WordPressはフォルダが見つからないため、全プラグインを停止します。
この操作はデータベース上のプラグイン設定を消しません。プラグインの読み込みだけを止めます。サイトが復旧すれば、Fatal Errorはプラグインが原因である可能性が高いです。次にフォルダ名を元のpluginsに戻し、プラグインフォルダを1つずつ名前変更または管理画面から個別に有効化し、問題のプラグインを特定します。
- wp-content/pluginsをplugins-offに変更
- サイトをシークレットウィンドウでテスト
- 復旧したらフォルダ名をpluginsに戻す
- プラグインを1つずつ有効化
- エラーが再発したら最後に有効化したプラグインを記録
シンプルですが効果的な隔離テストです。特に20以上のプラグインを利用している場合、アルファベット順ではなく、直近更新されたものから順にテストすると効率的です。
3. 問題プラグインを個別に隔離
全プラグイン停止時にサイトが復旧し、特定プラグイン有効化後に再度落ちるなら、そのプラグインが原因です。ただし、2つ以上のプラグインが同時動作時にのみエラーが出る場合もあるため、ペアでの競合も検証しましょう。
例:セキュリティプラグインとキャッシュプラグインが同じファイル権限に干渉する場合や、WooCommerce更新後に決済ゲートウェイプラグインが古いままでFatal Errorになる場合。表面上はWooCommerceのエラーでも、根本は決済プラグインが原因ということも。
- まずコアプラグイン(WooCommerce、SEO、フォーム等)を有効化
- 次に補助プラグイン(キャッシュ、セキュリティ、リダイレクト、ギャラリー、SNS等)を順次有効化
- 各有効化後、フロントと管理画面をテスト
- 決済、カート、問い合わせ、会員ログインなど重要ページもチェック
- エラー再発時は最後に有効化したプラグインとエラーメッセージを記録
この段階ではサイト復旧だけでなく、根本原因の特定が重要です。誤ったプラグインに責任を押し付けると数日後に再発しかねません。
4. エラーログから確定証拠を集める
サーバーのエラーログはFatal Error解決の最強証拠です。ホスティングコントロールパネルに「Error Log」「エラーログ」などの項目があるはずです。また、WordPress側でwp-config.phpにデバッグ設定を追加するとwp-content/debug.logが生成されます。
診断用にはWP_DEBUGを有効化し、エラー出力を画面ではなくログファイルに記録し、サイト再テストします。画面出力は本番サイトではセキュリティリスクとなるため避けましょう(ファイルパスやユーザー名、サーバー構成等が外部に漏れる可能性)。
ログで「PHP Fatal error」「Uncaught Error」「require_once failed」「allowed memory size exhausted」「call to undefined function」「cannot redeclare」などを探し、続くファイルパスや行番号を確認。例:wp-content/plugins/example-plugin/includes/class-loader.php on line 214ならexample-pluginが原因です。
ログ読解は最初難しそうですが、多くの場合パス内のプラグイン名が直接ヒントになります。Hostragonsパネルではエラーログ閲覧、PHPバージョン管理、ファイル操作を一括でできます。ホスティングコントロールパネル
5. PHPバージョンとメモリ制限の確認
Fatal Errorは必ずしも壊れたプラグインが原因ではありません。プラグインが現在のPHPバージョンに非対応のことも。2026年時点では最新PHPバージョンが推奨ですが、古いプラグインは新しいPHP仕様に未対応の場合もあります。逆に古いPHPバージョンでは新プラグインの必要関数が使えずエラーになることも。
PHPメモリ不足も頻発原因です。特に多言語サイト、WooCommerceショップ、ページビルダーや重いセキュリティスキャンはメモリ消費が大きくなります。ログに「Allowed memory size exhausted」とあれば、プラグイン自体が破損しているとは限らず、リソース不足が主因かもしれません。
- 小規模企業サイトならPHP memory_limit 256MBで十分なことが多い
- WooCommerceや会員サイトは512MBが安心目安
- 高トラフィックや多数プラグイン利用サイトはリソース計画を要検討
- PHPバージョン変更は事前にステージング環境でテストを
リソース不足が頻発する場合、memory_limit増加だけでなく、プラグイン数やDBクエリ、ホスティングプラン全体を見直すことが効果的です。WordPressホスティングパッケージ
管理画面に入れない場合の代替方法
FTPやファイルマネージャでプラグインフォルダ名変更
最も確実な手動方法はプラグインフォルダ名の変更です。問題プラグインが特定できていれば、pluginsフォルダ全体を停止するのではなく、該当プラグインだけフォルダ名を変更します。例:wp-content/plugins/critical-pluginをcritical-plugin-offに変更するだけで、WordPressはそのプラグインを読み込めずエラーが消えることがあります。
この操作後、管理画面のプラグインページを開くとWordPressが該当プラグインを「停止中」と認識します。フォルダ名を元に戻す前に、プラグインの最新バージョンや開発者ノート、サポートトピックを調べ、必要なら安定版へダウングレードしましょう。
WP-CLIでプラグイン無効化
SSHアクセス可能ならWP-CLIがプロ向けの高速解決策です。コマンドラインから全プラグインの一覧、個別停止、全体停止・有効化が数分で可能。全プラグイン停止→サイトテスト→個別有効化も短時間で済みます。
WP-CLI使用時は必ず正しいWordPressディレクトリで実行しましょう。誤った場所でコマンドを打つと結果が出ないか、他のWordPressインストールに影響する場合も。制作会社や開発者は複数サイトの標準診断手法として使うべきです。
データベースからactive_plugins値リセット
最終手段として、データベースのactive_plugins値を編集できます。通常phpMyAdminでwp_optionsテーブルを操作します。ただし、シリアル化データ構造を壊すと新たなエラーが発生するため、バックアップ取得と十分な知識がある場合だけ実施してください。
技術知識が限られている場合は、データベース操作よりフォルダ名変更の方が安全です。ファイルシステムでの一時停止はほとんどのサイトオーナーにとってリスクが低い方法です。
問題プラグイン特定後の対応

Fatal Errorのプラグインを停止すればサイトは復旧しますが、恒久対応にはプラグインがエラーになった原因分析が必要です。再度有効化や自動更新時に同じエラーが起きる可能性があります。
- プラグインの最新リリースノートを読む。開発者が互換性やバグ修正を公開している場合があります。
- WordPressコアのバージョンを確認。古いコアでは新しいプラグインが動作しないことも。
- PHPバージョン要件を調査。プラグインページに最低PHPバージョンが記載されていることが多い。
- 代替プラグインを検討。長期間更新されていないプラグインはセキュリティリスクも。
- ステージング環境で同じエラーを再現。ライブサイトで試行錯誤は避ける。
- 開発者にログ行とともにサポート依頼。単に「サイトが落ちた」ではなく具体的な証拠を。
例:フォームプラグインがFatal Errorを出し、PHP 8.3のみで発生している場合は、暫定的にPHP 8.2でサイトを動かしつつ、開発者の互換性アップデートを待つ方法もあります。ただし、こうした暫定対応がセキュリティアップデートを長期間妨げることは避けましょう。
Fatal Error再発防止策
WordPressサイトでエラーリスクをゼロにすることは不可能ですが、適切なメンテナンスルーチンで大幅に低減できます。特にビジネスサイトでは、更新管理を無計画に行うのではなく、慎重にコントロールしましょう。
- ステージング環境利用:プラグイン、テーマ、PHPアップデートはまずテスト環境で検証
- 自動更新を選別して利用:重要プラグインは自動ではなく手動更新が安全な場合も
- バックアップ頻度増加:頻繁にコンテンツや注文があるサイトは毎日バックアップでは不十分なことも
- プラグイン数削減:プラグイン1つごとにコード追加、セキュリティリスク、互換性問題が増える
- 未更新プラグインの削除:1年以上更新がないものは慎重に見直し
- SSLやセキュリティチェックを徹底:安全な通信は管理画面やユーザーデータの基本 SSL証明書
- ドメイン・DNS管理の定期確認:緊急時に素早くドメイン・DNS操作できる体制を ドメイン検索
もう一つの良い習慣は「更新履歴の記録」です。簡単なドキュメントに日付、更新プラグイン、旧バージョン、新バージョン、テスト結果を記録しておけば、将来のトラブル発生時に原因追及が容易になります。制作会社ではクライアントへの透明性確保にも役立ちます。
ライブサイトでやってはいけないこと
Fatal Error時に逆効果となる対応もあります。特に検索で見つかる古いアドバイスは全てのサイトに適用できるとは限りません。下記の誤りを避けることで、データ損失や長期ダウンタイムを防げます。
- バックアップなしでデータベース編集しない
- エラーのプラグインフォルダを直接削除せず、まず名前変更で停止
- 本番サイトでデバッグエラーを訪問者に表示しない
- 全プラグインを一度に再有効化しない
- PHPバージョンを何度も変えて無計画テストしない
- 信頼できないソースからプラグインをダウンロードしない
- エラーメッセージを記録せずに対応しない
特に「nulled」やライセンス無効プラグインはFatal Errorだけでなく、セキュリティ脆弱性や悪意コード、情報漏洩のリスクもあります。正規ライセンスで利用し、更新・サポートチャネルを確保しましょう。
ホスティングサポートへ相談すべきタイミング
状況によってはWordPress管理画面だけで解決できないこともあります。サーバーエラーログにアクセスできない、PHPバージョン変更不可、ファイル権限が壊れている、サイトが完全に500エラーの場合は、ホスティングサポートに相談すると迅速な対応が可能です。サポートへ連絡時は以下の情報を準備しましょう:
- エラー発生日時・おおよその時間
- 直近の更新やインストール履歴
- 画面上のエラーメッセージ
- debug.logやerror_logの該当行(あれば)
- これまで試した対応と結果
これらの情報があれば、サポートがログを正しい時間帯で調査でき、一般的な確認よりも根本原因への迅速なアプローチが可能です。Hostragonsでは、WordPress専用ホスティングでファイル管理、PHPバージョン選択、SSL設定、リソース監視などの機能があり、問題解決がよりスムーズに進みます。Hostragonsサポートセンター
まとめ・総括
WordPress Fatal Errorの解決は、正しい手順を踏めば複雑な作業ではありません。まずバックアップ、エラーメッセージやログの調査、安全にプラグインを停止し、問題のプラグインを1つずつテスト。次にPHPバージョン、メモリ制限、プラグイン互換性、更新履歴を総合的に評価し、恒久対応を行います。
もしサイトが頻繁にFatal Errorになる、更新時に落ちる、リソース制限が多い場合は、インフラ全体の見直しも検討しましょう。HostragonsのWordPress特化ホスティングなら、管理しやすく、バックアップも安全、安定した環境を構築できます。WordPressホスティング
よくある質問
WordPress Fatal Errorでサイトデータは消えますか?
基本的には消えません。Fatal ErrorはPHPコードが動作しないという意味で、コンテンツ自体を直接削除することはありません。ただし、無計画なファイル削除やバックアップ無しのDB操作はデータ損失につながります。
どのプラグインがサイトを落としたかどうやって分かる?
エラーログでwp-content/pluginsの後に表示されるプラグイン名が最も強いヒントです。ログが無ければ全プラグイン停止→個別有効化→エラー再発時に最後に有効化したものを特定できます。
管理画面に入れない場合どうやってプラグインを停止できる?
FTP、SSH、ホスティングファイルマネージャでwp-content/pluginsフォルダ名を一時変更すれば全プラグイン停止となり、ほとんどの場合管理画面再アクセスが可能になります。
PHPバージョン変更でFatal Errorは解決できる?
場合によっては解決します。プラグインが現在のPHPバージョンと非互換の場合、適切なバージョンへ切り替えれば一時的または永久的な解決になることも。ただし、最も安全なのは最新・互換性のあるプラグインを利用することです。
Fatal Error再発防止には何をすべき?
定期バックアップ、更新前のステージングテスト、不要プラグインの削除、WordPressやPHPのバージョンを常に最新に保つ、信頼できるホスティング利用が効果的です。