WordPress「重大なエラーが発生しました」の原因と初動対応｜ログインできない500エラーの切り分けから復旧依頼まで
目次
【AIによる要約】
– 「重大なエラー」の主因はプラグイン競合・PHPバージョン不整合・テーマ不具合・メモリ不足・.htaccess破損の5つ。発生時刻と直前の作業の記録が復旧の鍵になります。
– デバッグモード確認やプラグイン無効化は、本番サーバーを直接触る作業なので、バックアップが確認できる場合だけ限定して行います。
– 自力で直せないと判断したら、コードを触らず「記録・スクリーンショット・契約情報」をそろえて専門家へ依頼するのが最短です。
はじめに: 朝出社したら、サイトが死んでいた
「このサイトは重大なエラーが発生しています。WordPressのトラブルシューティングの手順については以下をご確認ください。」
朝、自社サイトを開いたらこの一文だけが表示されている。あるいは、社内から「ホームページがエラーになる」と連絡が入る。管理画面にログインしようとしても、今度は「500 Internal Server Error」で入ることすらできない——。
Web担当者にとって、これは誰もが一度は思い描く「最悪の朝」です。当社は業界歴10年以上で300社以上の企業サイト・Webシステムを支援してきましたが、この状態からの復旧依頼は毎月のように受けています。そして実際に立ち会ってきたから言えますが、復旧の速さと成功率は、複雑な技術対応よりも「最初の1時間に何を記録できたか」でほぼ決まります。
逆に言えば、最初の1時間にやってはいけないことをやると、復旧の難易度が一段上がります。この記事では、エラー発覚から復旧依頼までの初動を、プロの現場視点で順を追って説明します。
「重大なエラー」が出るとき、裏側で何が起きているのか
まず、このメッセージの正体から押さえます。WordPressはPHPという言語で動いており、テーマやプラグインのコードで「致命的エラー（Fatal Error）」が起きると、それ以上ページを作れなくなります。
WordPress 5.2以降は、この致命的エラーを検知するとフロントと管理画面を「重大なエラーが発生しました」の一文に置き換えて保護する仕様になりました（WordPress.org 公式）。つまり真っ白画面よりは親切になったのですが、表示される情報はこれだけです。原因のプラグイン名も、行番号も、何も教えてくれません。
原因の内訳は、当社が復旧案件で見てきた限り、ほぼ次の5つに集約されます。
| 原因 | 典型的なきっかけ | 起こりやすいタイミング | 初動で見るポイント |
|---|---|---|---|
| プラグインの競合・不具合 | プラグイン更新、新規インストール | 更新作業の直後 | エラー通知メールに該当プラグイン名が書かれている |
| PHPバージョンとの不整合 | サーバー側のPHP更新（レンタルサーバーの一斉変更も） | サーバー通知後、しばらく経ってから | サーバーのコントロールパネルでPHPバージョンを確認 |
| テーマ・本体コードの不具合 | テーマ更新、functions.php編集 | 更新・編集の直後 | 更新履歴・編集履歴の確認 |
| メモリ不足（メモリ上限超過） | 画像の大量アップロード、重い一括処理 | 特定の処理の最中 | 「Allowed memory size exhausted」というエラー文言 |
| .htaccessの破損 | プラグイン設定変更、サーバー側の操作 | 設定変更の直後 | ファイルの状態確認（復旧には注意が必要） |
「誰も何も触っていないのに出た」ように見えるケースも、実はサーバー側でPHPやセキュリティパッチが自動適用されていた、というのがパターンの定番です。だから「直前の作業の有無」を最初に確認するのが初動の入口になります。
初動の記録: 依頼するにも、直すにも、まずこれだけ
エラー画面を見た瞬間から、復旧のための情報収集が始まっています。慌てて作業を始める前に、次を記録してください。所要時間は10分程度です。
- 発見時刻と、最後に確認できた時刻: 「昨日の19時には正常だった」ことが、原因の切り分けに直結します。
- 直前にやったこと・起きたこと: プラグイン更新、WordPress更新、サーバーからのメール（PHPバージョン変更通知など）、アクセス急増の有無。
- エラー画面のスクリーンショット: フロントと管理画面（ログイン画面含む）の両方。
- エラーの範囲: 全ページか一部か。フロントのみか、管理画面もか。URLごとに違いを記録します。
この記録は、自社で復旧する場合にも、外部に依頼する場合にも、必ず最初に求められます。「いつから・何をしたら・どこまで壊れたか」が伝わらないと、原因調査の時間と費用がその分増えます。
切り分けの順番: 自社で確認できる範囲と、触ってはいけない線
STEP 1. 別の環境から確認する
自宅やスマホの回線から、シークレットモードで開き直します。キャッシュやCookieの問題だった場合は、これで分かります。表示側の問題だったケースも意外と多いです。
STEP 2. サーバーで障害が出ていないか確認する
利用中のレンタルサーバーの障害情報ページや、契約メールアドレスに届いた通知を確認します。サーバー側の障害なら、待つことが正解です。
STEP 3. メールを確認する（自動復旧メール）
WordPress 5.2以降、致命的エラーが起きると、サイト管理者宛てに「技術的な詳細」を載せたメールが自動送信される仕様です。どのプラグインで・どんなエラーが出たかが書かれているので、原因特定の最も確実な手がかりになります。受信箱だけでなく、迷惑メールフォルダも確認してください。
ここから先は「本番サーバーを直接触る」作業になる
ネットの解説記事の先にあるのは、こうした対処です。
wp-config.phpにWP_DEBUGを追記してエラーの詳細を表示する- FTPやファイルマネージャで
pluginsフォルダの名前を変えて、プラグインを一括無効化する - テーマをデフォルトテーマに切り替える
確かにこれらは定番の対処です。ただし、慣れていない方が本番サーバーで行うには危険が伴います。当社が実際に見てきた二次被害は次の通りです。
たとえば、wp-config.php を編集した際に文字コードが壊れ、直前まで正常だった設定まで壊れてしまうことがあります。また、プラグインフォルダの名前を変えた直後に更新処理が走り、データベースの状態とファイルが食い違ったという事例も見てきました。さらに危険なのが、バックアップがないまま作業を進めてしまい、元に戻る手段を失うパターンです。
ですから、境界線を明確にします。デバッグやプラグイン無効化を自社で行ってよいのは、「ファイル・DB両方のバックアップが確認できていて」「直前の変更（更新・編集）が明確なとき」だけです。それ以外は、記録と依頼に徹する方が結果的に早く、安くつきます。
補足として、管理画面だけが入れる場合、プラグイン更新が原因ならエラーメールの内容から該当プラグインを特定して停止する、という比較的安全な道もあります。フロントも管理画面も真っ白・500の状態は、サーバーのファイルシステムを触る必要があり、難易度が跳ね上がります。
依頼するとき: 誰に・何を・いくらで頼むか
依頼先の候補と選び方
- 保守管理を委託している会社がいれば、まずそこに連絡します。契約内容に障害対応が含まれるか、深夜・休日の連絡先が有効かを契約書で確認します。
- サーバー会社の有償サポートです。サーバー側の設定（PHPバージョン等）の確認・変更は依頼できますが、WordPressのコード修正は対象外が普通です。
- WordPress対応を明記している制作・保守会社へスポット依頼します。「サイトが止まって復旧できない」状態からのスポット対応は、概算でも数万円〜十数万円規模になることが多い領域です。深夜・休日は割増になる点も、依頼前に確認しておくと判断が速くなります。
依頼時にそろえるもの（この3点セットで見積もりと復旧が速くなる）
- WordPressのログイン情報・サーバー管理情報（レンタルサーバーの契約者情報、コントロールパネルURL）。連絡が取れる制作会社がいる場合は、その連絡先と契約状況も。
- 初動の記録（発覚時刻・直前の作業・スクリーンショット）。
- バックアップの有無と場所。サーバー標準バックアップがあるサーバーなら、それが最強の切り札です。
依頼前にパスワード等をメールで平文送信しない、など機密の扱いには注意してください。正規の依頼先には、電話で確認した上で安全な方法で共有します。
担当者が上長に説明するために: 初動の判断基準
社内で共有するときは、次の3点に絞るのがおすすめです。まず、環境を変えての再確認、サーバー障害情報の確認、エラー通知メールの確保、記録とスクリーンショットの取得は、やってよい初動です。次に、本番サーバーへのファイル修正、データベースの直接編集、解説記事のままにしたコードのコピペ、そしてバックアップ未確認のままのいかなる作業も、やめておくべき行為です。最後に、判断の目安として、「直前の作業が分からない」「管理画面も入れない」「バックアップがない」のどれかに当てはまったら、即日で専門家へ依頼すべきと伝えてください。迷う時間こそ損失になります。
当社自身も複数のWebサービス・EC事業を運営している立場として断言できます。サイトが止まっている時間は、1時間ごとに機会損失が積み上がります。だからこそ初動で重要なのは技術的な巧拙ではなく、「早く正確な情報をそろえて、正しい依頼先に繋ぐ」ことです。
事故らないための仕組み: 「重大なエラー」は再発します
一度復旧しても、放置したサイトでは同種のエラーは再発します。プラグインは更新され、サーバーのPHPは進みますから、これ自体は避けられません。避けるべきは「毎回、偶然に頼った復旧」になることです。
再発防止の要点は3つです。
- バックアップ: ファイルとDBを世代管理し、実際に戻せるか定期的にテストする。
- 検証環境: 更新は本番でいきなり押さず、本番と同じ環境で確認してから反映する。
- 監視: 死活監視を入れて、社内より先に障害を検知する体制を整える。更新作業そのものの安全な進め方は、WordPress更新で画面が真っ白！原因の切り分け方と、絶対にやってはいけない復旧NG行為やWordPressの本体アップデートを放置してはいけない理由｜現場のプロが教える判断基準と安全な更新手順もあわせてご参照ください。
当社の保守管理では、この3つを仕組みとして提供しています。代理店を挟まない直接取引で、社内の専任エンジニアが監視・障害対応まで一貫して担当します。深夜・休日にサイトが止まったとき、「誰に連絡すればいいか分からない」という状態をなくすことが、保守契約に求められる一番の価値だというのが当社の考えです。
Webサイト保守管理サービスでは、今まさにエラーで止まっている状態からの相談も承っています。まずは現状（いつから・何をしたら・どこまで）をお聞かせください。
FAQ: 「重大なエラー」についてよくある質問
Q. 「重大なエラー」が出たまま放置すると、サイトは自然に復旧しますか？
A. ほぼ復旧しません。PHPが処理を続けられない状態は、原因（トリガー）が取り除かれない限り解消しないためです。例外はサーバー側の一時的な負荷や障害ですが、その場合もサーバー会社の障害情報で確認できることが多く、エラーが続くなら不具合として対応すべきです。
Q. エラーが出た直後に、サーバーのPHPバージョンを戻してもいいですか？
A. 「サーバー側のPHP更新の直後に出た」ことが明確なら、バージョンの確認・変更は有効な初動です。ただしPHPバージョンの変更は全プラグインの動作に影響するため、理由があいまいなまま触るのはリスクがあります。迷う場合は、記録だけ残して専門家に相談する方が安全です。
Q. 復旧依頼は、制作会社・サーバー会社・セキュリティ会社のどこに頼ればいいですか？
A. エラーの「きっかけ」で判断します。WordPress本体やプラグインの更新直後なら制作・保守会社、サーバー設定（PHPバージョン等）の変更直後ならサーバー会社のサポート、不審なファイルや改ざんの疑いがあるならセキュリティ会社が適しています。判断に迷うときは、保守管理を委託している会社にまず現状を伝えるのが最短です。
Q. WordPressの「自動復旧メール」は誰に届きますか？
A. WordPressの一般設定に登録されている「サイト管理者のメールアドレス」宛てに届きます。制作会社が管理しているサイトでは、登録アドレスが制作会社側になっているケースがあり、その場合はメールが自分の手元に届きません。「自分に届かない」ときは、登録アドレスの確認を依頼先に伝えると解決が早くなります。
まとめ
「重大なエラーが発生しました」はPHPの致命的エラーであり、主因はプラグイン競合・PHP不整合・テーマ不具合・メモリ不足・.htaccess破損の5つです。初動として安全に自社でできるのは「記録→再確認→障害情報→エラーメール確保」までです。デバッグやプラグイン無効化は本番を直接触る作業なので、バックアップ確認と直前作業の特定ができる場合に限定してください。復旧が望めないと判断したら、コードを触らず、記録・スクリーンショット・契約情報・バックアップの有無をそろえて依頼します。再発防止には「バックアップ・検証環境・監視」の仕組みが必要です。迷う部分は専門家に任せる境界線を引くのが、最も安くつく選択です。
