Webサイトでエラーが起きると、サーバーのエラーログには原因へ近づく情報が残ることがあります。しかし、長いログの末尾だけを見ても、関係のない警告や復旧後の記録を拾うことがあります。最初に必要なのは、問題が起きた時刻・URL・直前の操作です。

その情報をアクセスログと照合し、同じ時間帯のエラーログへ範囲を絞ります。Webサーバー・PHP・WordPressは異なる場所へ記録する場合があるため、どの層まで処理が進んだかを順に見ます。ログを本番画面へ表示するのではなく、管理された保存先で確認することも重要です。

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

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

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

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

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

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

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

設定を変更する前には、対象ファイルとデータベースをバックアップします。ログを増やす変更そのものが障害へ影響しないかも考えます。更新直後の障害で、戻せるバックアップがある場合は、調査を長引かせず切り戻す判断も必要です。

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

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

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

調査後は、同じ操作でエラーが再発しないことを確認します。暫定的に変更したログレベルやデバッグ設定を元へ戻し、書き出したログは公開領域から確実に削除します。原因・対応・確認時刻を作業記録へ残せば、似た障害が起きたときに最初の確認を早められます。