エラーログの見方とサーバートラブル時の確認ポイント

エラーログは、サーバーやPHPが検出した問題の記録です。読むときは、発生時刻、メッセージ、ファイル名や行番号が手掛かりになります。例えば「Permission denied」は権限、「Allowed memory size exhausted」はPHPのメモリ上限に関係します。

同じエラーでも原因は一つとは限らないため、設定を変える前に、問題が起きたURLや直前の更新と照合します。公開画面へ詳細を表示するのではなく、管理画面や保護されたログファイルで確認する方法です。

先にどの層のログを見るか決める

まずアクセスログで、利用者の要求が対象サーバーへ届いたかを確認します。該当する時刻に500系の状態コードがあれば、サーバー側で処理を完了できなかった手掛かりになります。404や403であれば、ファイルの有無やアクセス制限を先に確認した方が早い場合があります。

Webサーバーのエラーログには、ApacheやNginxが検出した設定・権限・接続の問題などが記録されます。PHPのエラーログには、プログラムの致命的なエラーや警告が残ります。レンタルサーバーでは二つを同じ画面で見せることもあれば、保存先を分けていることもあります。

WordPressには WP_DEBUG_LOG などのデバッグ機能がありますが、常時有効にする前提ではありません。調査が必要な場合は、可能なら検証環境で再現します。本番で一時的に記録するときは、保存先の保護と終了後に設定を戻す手順まで決めます。

一行は時刻・重大度・発生元・内容で読む

よく見かけるメッセージには、次のようなものがあります。

権限不足だから全ファイルを777にする、メモリ不足だから無制限にする、といった変更は避けます。対象ファイルや処理を特定するための手掛かりとして読みます。

エラーログの形式は環境によって異なりますが、時刻・重大度・発生元・メッセージが主要な手掛かりです。次は説明用の例であり、実際のファイルパスや形式はサーバーによって変わります。

2026-06-01 14:22:08 [error] PHP Fatal error: Uncaught Error ... in /path/to/plugin/file.php:120

この例では、発生時刻とPHPの致命的なエラーであることが分かります。末尾のファイル名と行番号は停止した場所の手掛かりですが、そのファイル自体が原因とは限りません。別の処理から不正な値を受け取った結果、最後にそこで停止することもあります。

重大度にはdebug・info・notice・warn・errorなどがあり、記録する基準を設定できます。warning が必ずサイト停止を意味するわけではなく、fatal error はPHP処理が継続できなかったことを示します。表示された英単語だけで結論を出さず、同じ要求の前後関係を読みます。

最後の行ではなく最初の異常から追う

一つの障害から複数のエラーが続くことがあります。最後の行は後続処理の失敗であり、発端は少し前に記録されているかもしれません。該当時刻の直前から読み始め、最初の致命的なエラーや接続失敗を探します。

実務では次の順番で範囲を絞ります。

1. 既存の記録から発生時刻と操作を確認する。安全に試せる場合だけテスト環境などで再現する
2. アクセスログで同じURLと状態コードを確認する
3. 同じ時刻のWebサーバーとPHPのエラーログを開く
4. 一連の記録で最初に起きた異常と発生元を特定する
5. 直前の更新・設定変更・外部サービス障害と照合する

何度も再読み込みすると同じエラーが増え、最初の記録を見つけにくくなります。データ更新を伴う操作では重複受付の危険もあります。再現は必要最小限にし、事業への影響が大きい場合は先にメンテナンス表示や切り戻しを検討します。

ログが空でも問題なしとは限らない

エラーログに該当行がなくても、問題がなかったとは断定できません。設定された重大度より軽いメッセージは記録されず、PHPが別のファイルへ出力している場合もあります。ログの保存先へ書き込む権限がないと、記録自体が失敗することもあります。

CDNやロードバランサーの手前で失敗した要求は、対象Webサーバーへ届きません。外部APIやメール配送の失敗は、WordPressとは別のサービスへ記録されることがあります。問題の経路を整理し、どこまで処理が進んだかに合わせて確認先を変えます。

Apacheでは標準のログレベルによって、一部の情報がエラーログへ残らない場合があります。Nginxも設定したレベル以上のメッセージを記録します。ログレベルをむやみに上げる前に、必要な期間・保存容量・個人情報への影響を確認します。

本番画面へエラー内容を表示しない

PHPの display_errors を有効にすると、プログラムのファイルパスや内部情報が訪問者の画面へ出ることがあります。本番環境では画面表示を無効にし、必要な情報は保護されたログへ記録します。白い画面を調べるためでも、公開画面へ詳細を出したままにしてはいけません。

WordPressの WP_DEBUG は開発時の調査に役立ちますが、本番で常用する機能ではありません。検証環境で有効にし、テーマやプラグインの更新によってエラーが消えるかを確認します。本番で一時利用した場合は、調査後に設定を無効へ戻します。

ログ設定を変更する前には、対象の設定ファイルを控えます。プログラムやDBも変更する作業なら、その範囲のバックアップも必要です。ログを増やす変更そのものが障害へ影響しないかも考えます。更新直後の障害では切り戻しも選択肢ですが、更新後の注文や問い合わせを古いDBで上書きしないよう、追加データを先に保全します。

相談用には一つの事象を切り出す

制作会社やサーバー会社へ相談するときは、ログ全体をそのまま送る必要はありません。発生日時・対象URL・行った操作・画面のメッセージを先に伝えます。該当するエラーの前後数行を切り出し、アクセスログの状態コードも添えます。

ログにはサーバー内のパス・メールアドレス・クエリ文字列・認証情報が含まれる可能性があります。共有前に秘密情報を伏せ、閲覧期限のある方法を選びます。切り出し用のコピーとは別に、元のログは変更せず保全します。

調査後は、同じ操作でエラーが再発しないことを確認します。暫定的に変更したログレベルやデバッグ設定を元へ戻し、書き出したログは公開領域から確実に削除します。長いログをすべて理解する必要はありません。発生時刻に近いエラーと、その直前に変わったものを結び付けるところから原因を絞れます。