2026.09.03

WordPress「重大なエラーが発生しました」の原因特定と管理者の初動 ― ログインできない500エラーの切り分け方

執筆者情報

中村圭介

株式会社カジヤ/代表取締役　男性向けファッション通販サイト運営の会社を経験し、現職に至る。デザインや開発から、ECやメディアのコンサルティングまでを一貫して行う。お付き合いのあるお客様の事業を成功に導けるように、再現性のある成長支援ができる会社を目指す。

【AIによる要約】
– 「重大なエラー」の主因はプラグイン競合・PHPバージョン不整合・テーマ不具合の3つで、発生時刻と直前の作業の記録が復旧の鍵になります。
– デバッグモード確認やプラグイン無効化は、本番サーバーを直接触る作業なので、バックアップが確認できる場合だけ限定して行います。
– 自力で直せないと判断したら、コードを触らず「記録・スクリーンショット・契約情報」をそろえて専門家へ依頼するのが最短です。

アイキャッチ:WordPressの重大なエラーと初動対応

はじめに: 朝出社したら、サイトが死んでいた

「このサイトは重大なエラーが発生しています。WordPressのトラブルシューティングの手順については以下をご確認ください。」

朝、自社サイトを開いたらこの一文だけが表示されている。あるいは、社内から「ホームページがエラーになる」と連絡が入る。管理画面にログインしようとしても、今度は「500 Internal Server Error」で入ることすらできない——。

Web担当者にとって、これは誰もが一度は思い描く「最悪の朝」です。当社は業界歴10年以上で300社以上の企業サイト・Webシステムを支援してきましたが、この状態からの復旧依頼は毎月のように受けています。そして実際に立ち会ってきたから言えますが、復旧の速さと成功率は、複雑な技術対応よりも「最初の1時間に何を記録できたか」でほぼ決まります。

逆に言えば、最初の1時間にやってはいけないことをやると、復旧の難易度が一段上がります。この記事では、エラー発覚から復旧依頼までの初動を、プロの現場視点で順を追って説明します。

「重大なエラー」が出るとき、裏側で何が起きているのか

まず、このメッセージの正体から押さえます。WordPressはPHPという言語で動いており、テーマやプラグインのコードで「致命的エラー（Fatal Error）」が起きると、それ以上ページを作れなくなります。

WordPress 5.2以降は、この致命的エラーを検知するとフロントと管理画面を「重大なエラーが発生しました」の一文に置き換えて保護する仕様になりました（WordPress.org 公式）。つまり真っ白画面よりは親切になったのですが、表示される情報はこれだけです。原因のプラグイン名も、行番号も、何も教えてくれません。

原因の内訳は、当社が復旧案件で見てきた限り、ほぼ次の3つに集約されます。

原因	典型的なきっかけ	起こりやすいタイミング
プラグインの競合・不具合	プラグイン更新、新規インストール	更新作業の直後
PHPバージョンとの不整合	サーバー側のPHP更新（レンタルサーバーの一斉変更も）	サーバー通知後、しばらく経ってから
テーマ・本体コードの不具合	テーマ更新、functions.php編集	更新・編集の直後

「誰も何も触っていないのに出た」ように見えるケースも、実はサーバー側で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）。連絡が取れる制作会社がいる場合は、その連絡先と契約状況も。
初動の記録（発覚時刻・直前の作業・スクリーンショット）。
バックアップの有無と場所。サーバー標準バックアップがあるサーバーなら、それが最強の切り札です。

依頼前にパスワード等をメールで平文送信しない、など機密の扱いには注意してください。正規の依頼先には、電話で確認した上で安全な方法で共有します。

担当者が上長に説明するために: 初動の判断基準

社内会議でそのまま使える形で言い切ります。

やってよいこと: 環境を変えての再確認、サーバー障害情報の確認、エラー通知メールの確保、記録とスクリーンショット。
やめておくべきこと: 本番サーバーへのファイル修正、DBの直接編集、解説記事のままにしたコードのコピペ。バックアップ未確認のままのいかなる作業も不可。
依頼の判断: 「直前の作業が分からない」「管理画面も入れない」「バックアップがない」のどれかに当てはまったら、即日で専門家に依頼する。迷う時間こそ損失です。

当社自身も複数のWebサービス・EC事業を運営している立場として断言できます。サイトが止まっている時間は、1時間ごとに機会損失が積み上がります。だからこそ初動で重要なのは技術的な巧拙ではなく、「早く正確な情報をそろえて、正しい依頼先に繋ぐ」ことです。

事故らないための仕組み: 「重大なエラー」は再発します

一度復旧しても、放置したサイトでは同種のエラーは再発します。プラグインは更新され、サーバーのPHPは進みますから、これ自体は避けられません。避けるべきは「毎回、偶然に頼った復旧」になることです。

再発防止の要点は3つです。

バックアップ: ファイルとDBを世代管理し、実際に戻せるか定期的にテストする。
検証環境: 更新は本番でいきなり押さず、本番と同じ環境で確認してから反映する。
監視: 死活監視を入れて、社内より先に障害を検知する体制を整える。更新作業そのものの安全な進め方は、プラグイン更新のリスクと手順を解説した記事もあわせてご参照ください。

当社の保守管理では、この3つを仕組みとして提供しています。代理店を挟まない直接取引で、社内の専任エンジニアが監視・障害対応まで一貫して担当します。深夜・休日にサイトが止まったとき、「誰に連絡すればいいか分からない」状態をなくすことが、保守契約の一番の価値だと考えています。

当社のWebサイト保守管理サービスでは、今まさにエラーで止まっている状態からの相談も承っています。まずは現状（いつから・何をしたら・どこまで）をお聞かせください。