CONTENTS / ARTICLE MAP目次20項目
WordPressで「500 Internal Server Error」が出たとき、500という表示だけでは原因を特定できません。まず発生時刻、対象URL、直前の変更、同じサーバー上の他ページ、サーバーログを保全し、プラグイン・テーマ・PHP・サーバー設定・資源不足を一層ずつ切り分けます。
ANSWER FIRST
最初にすることは「直す操作」ではなく「証拠を残して影響範囲を分けること」です。
無差別な更新、プラグイン全削除、ログ消去、連続リロードは原因を見えにくくします。売上、会員、予約、決済、個人情報に関わるサイトは、変更を止めて保守画面や専門調査へ切り替えてください。
500エラーとは何か
HTTP 500は、サーバー側で要求を正常に処理できなかったことを示す一般的な応答です。ブラウザに同じ「500」と出ても、PHPの致命的エラー、メモリ不足、設定ファイル、権限、プラグインやテーマの競合、データベース接続、ホスティング側障害など原因は異なります。
したがって「500エラーの直し方」は一つではありません。いつから、どこだけ、何をした直後に、どのログが出たかを揃えるほど、復旧の試行回数と二次障害を減らせます。
最初の10分で記録する情報
- 時刻と対象URL
タイムゾーンを含む発生時刻、トップだけか管理画面も同じかを記録します。 - 画面とHTTP状態
スクリーンショットを撮り、別回線やシークレットウィンドウでも同じか一度だけ確認します。 - 直前の変更
更新、インストール、コード編集、PHP変更、移行、DNS・SSL、サーバー設定を時系列で書きます。 - 影響範囲
特定ページ、WordPress全体、同じサーバーの別サイト、管理画面、REST APIを分けます。 - ログの保存
対象時間帯のWebサーバー、PHP、WordPress、ホスティング管理画面のログをコピーして保全します。
DO NOT DESTROY EVIDENCE
ログローテーション前に対象時間帯を保存してください。エラーを隠すためだけに設定を戻したり、キャッシュやログを一括削除したりすると、原因を特定できなくなる場合があります。
よくある原因と見分ける手掛かり
| 原因層 | 手掛かり | 最初に確認するもの |
|---|---|---|
| プラグイン | 更新・有効化直後、特定機能だけ失敗 | 変更履歴、エラーログ、Recovery Mode通知 |
| テーマ・独自コード | テーマ更新、functions.php編集、特定テンプレートだけ失敗 | PHP致命的エラーのファイル名と行番号 |
| PHP・資源 | 処理量が多い時、アップロードや一括処理で発生 | memory exhausted、timeout、プロセス制限 |
| サーバー設定 | .htaccess、WAF、PHP切替、移行直後 | サーバーログ、設定変更日時、ホスト障害情報 |
| データベース | 接続エラー、特定クエリ、容量逼迫 | DB接続、容量、遅いクエリ、破損の記録 |
安全な原因切り分けの順番
1. サーバー全体かWordPressだけかを分ける
ホスティング会社の障害情報、同一サーバーの別URL、静的ファイル、管理画面を比較します。サーバー全体の問題であれば、WordPress内の変更を重ねても解決しません。
2. 直前の変更とログを対応させる
「更新したからプラグインが原因」と決めつけず、エラーログの時刻、ファイルパス、関数名、メモリ・権限等の文言を確認します。本番画面へ詳細エラーを表示するのではなく、権限を限定したログへ記録します。WordPress公式のデバッグ資料も、本番表示とログ記録を分ける重要性を示しています。
3. Recovery Modeの通知を確認する
WordPressは通常ページ読み込み時の致命的なPHPエラーを検知すると、管理者メールへRecovery Mode用リンクを送る場合があります。問題のプラグインやテーマを管理セッション内だけ一時停止し、管理画面へ入れることがあります。ただし、メール未達や対象外のエラーもあるため、届かないことだけで原因を否定できません。
4. 原因候補を一つだけ隔離する
ログが特定のプラグインを示す場合、バックアップと戻し方を確保してから、その一つだけを停止して再確認します。すべてのプラグインを同時に無効化すると、依存関係や決済・フォーム・セキュリティ機能まで止まり、別の障害を作る可能性があります。
5. 修正後は「表示」以外も確認する
トップが表示された後も、ログイン、投稿、フォーム、予約、会員、決済、メール、定期処理、APIを確認します。エラー表示が消えても、処理の一部だけ失敗していることがあります。
自分で作業を続けない方がよい条件
- 復元できるバックアップがない
- どの変更が本番へ入ったか分からない
- FTP、SSH、データベース、サーバーログの扱いに慣れていない
- 会員、注文、決済、予約、個人情報が関係する
- 改ざん、未知の管理者、見覚えのないファイルがある
- 復旧しても短時間で再発する
- 複数サイトやメールまで同時に影響している
この条件では、試行回数を増やすほど復旧点が不明になりやすいため、現状を保存して調査へ渡します。
修正を依頼するときに送る情報
HANDOFF DATA
- 発生URLと最初に確認した時刻
- 表示文言とスクリーンショット
- 直前24時間の更新・設定変更・デプロイ
- 再現する操作と、再現しない画面
- 利用中のサーバー、PHP、WordPress、テーマ、関連プラグインの版
- バックアップ日時と復元可否
- 対象時間帯のログ（秘密情報はマスク）
- 復旧の優先順位と止められない業務
管理者パスワードやAPIキーをメール本文へ貼らず、必要な権限だけを期限付き・個別アカウントで渡す方が安全です。作業後は権限を無効化し、変更記録を受け取ります。
500エラーについてよくある質問
画面を再読み込みし続ければ戻りますか？
一時的な負荷なら戻る場合もありますが、連続リロードは負荷を増やし、ログを大量に流すことがあります。一度確認したら時刻を記録し、状態確認へ切り替えます。
プラグインを全部削除すれば直りますか？
削除は復元や原因確認を難しくします。ログと変更履歴から候補を絞り、一時停止と削除を区別してください。
デバッグ表示を有効にしても大丈夫ですか？
公開画面へ詳細エラーを出すと、パスや構成等の情報が利用者へ見える恐れがあります。ログへ記録し、閲覧権限と保存期間を管理します。
復旧したらそれで完了ですか？
原因の修正、影響機能のテスト、ログ監視、再発条件、バックアップ、変更記録まで揃えて完了とします。
まとめ：500を消すのではなく、原因を限定して再発を防ぐ
500エラー対応の品質は、復旧の速さだけでなく、データを失わないこと、原因を説明できること、関連機能を壊さないこと、再発時に判断できることに表れます。最初に証拠と影響範囲を残し、最小の変更で確認してください。
ERROR INVESTIGATION
症状と変更履歴から、調べる順番を整理します。
500画面、発生URL、時刻、直前の変更をお送りください。サイト内のテキストメッセージで必要なログと安全な復旧範囲をご案内します。
参考にした公式情報
- WordPress Developer Resources「Common WordPress errors」
- WordPress.org「Recovery Mode」
- WordPress Developer Resources「Debugging in WordPress」
- WordPress Developer Resources「Backups」
公式情報の最終確認日：2026年8月26日。サーバー固有の操作は利用中のホスティング会社の公式手順も確認してください。
