エラーログとは、WebサーバーやPHPなどで発生したエラー・警告・異常の情報を記録したログです。
「500エラーが出た」「WordPressが真っ白になった」「プラグイン更新後に動かなくなった」といったトラブルでは、画面だけでは原因が分からなくても、エラーログに発生時刻・エラーの種類・問題が起きたファイル・行番号などが残っていることがあります。
30秒でわかる結論
- エラーログは、サーバーやPHPで起きた異常を調べるための記録
- 500エラー、画面が真っ白、PHPエラーなどの原因確認で役立つ
- 最初に「エラーを再現した時刻」を記録し、その前後のログを見る
- ログは上から全部読むのではなく、日時・レベル・ファイル名・行番号・メッセージを見る
- アクセスログは「誰がどのURLへアクセスしたか」、エラーログは「処理中に何が問題になったか」を見るもの
- ログに警告があるだけで、すべてがサイト障害の原因とは限らない
- WordPressではPHP・Webサーバーのログと、必要に応じてWP_DEBUG_LOGを使い分ける
- 本番サイトでデバッグ情報を画面に表示し続けない
エラーログとは？
エラーログは、Webサイトやサーバーが処理を行ったときに発生した異常・警告・失敗などを記録するファイルや記録領域です。
たとえばPHPの処理に失敗した場合、エラーログには次のような情報が含まれることがあります。
説明用のエラーログ例
[2026-10-29 10:15:32] PHP Fatal error: Uncaught Error … in /example/wp-content/plugins/sample/sample.php on line 120
この例では、初心者でも次の4点を拾えます。
- 発生時刻：10:15:32
- 種類：PHP Fatal error
- 対象ファイル：sample.php
- 行番号：120
エラーメッセージの全文を理解できなくても、これだけで「10時15分ごろ、sampleというプラグイン配下のPHPファイルで重大なエラーが起きた」という候補まで絞れます。
エラーログは「原因を断定する答え」ではなく「原因を絞る証拠」
ログに書かれたファイル名が必ず犯人とは限りません。他のプラグイン、テーマ、PHPバージョン、メモリ不足などが引き金になって、その場所でエラーが表面化することもあります。
エラーログはどんなときに確認する？
エラーログは、Webサイトに異常が起きたときの原因調査で特に役立ちます。
| 症状 | エラーログで確認したいこと |
|---|---|
| 500エラー | PHPエラー、設定ミス、モジュールの異常 |
| WordPressが真っ白 | Fatal error、メモリ不足、PHP互換性 |
| プラグイン更新後に停止 | 対象プラグイン名・PHPファイル・時刻 |
| 特定ページだけ表示できない | 該当URLへアクセスした時刻のエラー |
| 403エラー | アクセス制御・Webサーバー設定の記録 |
| 画像アップロードや処理に失敗 | PHP・権限・容量などのエラー |
| 定期処理が動かない | PHPやバックグラウンド処理の失敗 |
反対に、「ページが遅い」というだけではエラーログに直接の原因が出ない場合があります。その場合はアクセスログ、CPU・メモリ使用率、TTFBなど別の情報も必要です。
アクセスログとエラーログの違い
初心者が混同しやすいのがアクセスログです。
| 項目 | アクセスログ | エラーログ |
|---|---|---|
| 主な目的 | アクセス状況を記録 | 異常・警告を記録 |
| 分かること | URL、時刻、ステータスコードなど | エラー内容、モジュール、ファイルなど |
| 500エラー時 | 500が返った事実を確認 | 500になった原因候補を確認 |
| 404エラー時 | どのURLへアクセスされたか確認 | サーバー構成によって関連情報を確認 |
| 使い方 | アクセス分析・障害範囲確認 | 原因調査 |
500エラーを調べる例
アクセスログ：10:15:32に /sample/ へアクセスし、HTTP 500が返った
エラーログ：10:15:32付近でPHP Fatal errorが発生した
このように、2つのログを時刻で照らし合わせると原因を絞りやすくなります。
エラーログには何が記録される？
記録内容はWebサーバー、PHP、レンタルサーバーの仕様によって異なりますが、一般的には次のような情報を確認できます。
- エラーが発生した日時
- エラーや警告の種類
- エラーメッセージ
- 関連するモジュール
- 対象ファイルのパス
- PHPファイルの行番号
- 接続元IPアドレス
- 権限・アクセス制御に関する情報
Apache HTTP Serverでは、ErrorLogでエラーを記録する場所を設定し、LogLevelで記録する詳細度を調整できます。PHPも設定に応じて、Webサーバーのエラーログ、指定ファイル、システムロガーなどへエラーを記録できます。
共用レンタルサーバーでは、利用者がApacheやPHPのログ保存先を自由に変更できないことがあります。管理画面に「エラーログ」「PHPエラーログ」などの閲覧機能が用意されている場合は、そちらを利用します。
初心者向けエラーログの見方
大量のログを最初から最後まで読む必要はありません。次の順番で確認すると分かりやすくなります。
問題のページや操作を1回確認します。
例：10時15分ごろ。
前後1～2分程度から確認します。
重大度や種類を確認します。
プラグイン、テーマ、PHPなどの候補を探します。
更新・設定変更・PHP変更などと一致するか確認します。
最重要ポイントは「時刻」
1日分のログからエラー文字列を無作為に探すより、「10:15に障害を再現したので10:14～10:16を見る」という方法の方が、無関係な古いエラーに惑わされにくくなります。
エラーレベルはどう読む？
ログには、エラーの重要度を示す語句が含まれることがあります。ただし、名称と意味はWebサーバーやプログラムによって異なるため、すべてを同じ基準で考えないでください。
Apacheのログレベル
Apache HTTP Server 2.4では、主なLogLevelとして次の段階があります。
| レベル | 初心者向けの意味 |
|---|---|
| emerg | システムが利用できない重大状態 |
| alert | 直ちに対応が必要 |
| crit | 重大な状態 |
| error | エラー状態 |
| warn | 警告 |
| notice | 重要な通常イベント |
| info | 情報 |
| debug | 詳細なデバッグ情報 |
| trace1～trace8 | さらに詳細な追跡情報 |
Apache 2.4のLogLevelの初期値はwarnです。VPSなどでログレベルを変更できる場合でも、本番環境で詳細ログを常時増やすとログ量や負荷が増えるため、目的を決めて設定します。
PHPのエラー
PHPでは、Fatal error、Warning、Notice、Deprecatedなどの種類を見ることがあります。
| 表示例 | 考え方 |
|---|---|
| Fatal error | 処理を継続できない重大なエラーの候補 |
| Warning | 警告。処理が続く場合もある |
| Notice | 注意すべき情報 |
| Deprecated | 非推奨機能の利用を知らせるもの |
Warningが1件ある＝サイト停止の原因、ではない
警告や非推奨通知が大量に記録されていても、今回の障害とは無関係な場合があります。「障害発生時刻と一致するか」「同じ操作で再現するか」を優先してください。
ログのファイルパスはどう読む？
WordPressのPHPエラーでは、ファイルパスが非常に重要な手掛かりになります。
説明用の例
/wp-content/plugins/sample-plugin/sample.php
→ plugins配下なので、sample-pluginというプラグインに関連する処理だと分かります。
テーマの例
/wp-content/themes/sample-theme/functions.php
→ themes配下なので、使用テーマに関連する処理だと判断できます。
WordPress本体の例
/wp-includes/…
→ WordPress本体のファイル内でエラーが表面化しています。ただし、原因がプラグインやテーマから渡された不正な処理である可能性もあります。
ファイル名だけで犯人を断定しない
「wp-includesにエラーがあるからWordPress本体が壊れた」とは限りません。プラグインがWordPress本体の関数を誤った方法で呼び出し、その結果wp-includesでエラーになることもあります。
WordPressでエラーログを確認する方法
WordPressサイトでは、まずレンタルサーバー側のエラーログ機能を確認するのが分かりやすい方法です。
レンタルサーバーの管理画面を見る
サービスによって名称は異なりますが、次のような項目を探します。
- エラーログ
- PHPエラーログ
- ログ
- アクセス解析・ログ
- サイトログ
保存期間や表示件数はサービスごとに異なるため、障害が起きたら早めに確認・保存してください。
WordPressのWP_DEBUG_LOGを使う
WordPressにはデバッグ用の仕組みがあり、WP_DEBUGとWP_DEBUG_LOGを有効にすると、通常はコンテンツディレクトリ内のdebug.logへエラーなどを記録できます。
WordPress公式は、デバッグ機能を本番サイトで常時使用することを推奨しておらず、ローカル環境やステージング環境での利用を基本としています。
本番サイトでエラーを画面表示しない
エラーメッセージにはファイルパスやシステム情報が含まれる場合があります。本番サイトでデバッグするときは、利用者の画面へ詳細エラーを表示し続けないよう注意してください。
500エラーでログを見る具体例
たとえばプラグイン更新直後から500エラーになった場合を考えます。
プラグインを更新。
サイトを開くと500エラー。
もう一度アクセスし、発生時刻を記録。
PHP Fatal errorとプラグイン配下のファイルを確認。
このように、「直前の変更」「再現時刻」「ログ」の3つを組み合わせると、原因候補を大きく減らせます。
ログに何も出ない場合は？
エラーが発生しているのに、見ているログへ何も記録されない場合もあります。
- 別のログファイルに記録されている
- PHPのログ設定が無効になっている
- Webサーバーではなく別サービスの障害である
- CDNやリバースプロキシ側でエラーになっている
- アプリケーション独自のログへ記録されている
- 表示しているログの保存期間外になっている
そのため、「エラーログにない＝エラーが起きていない」とは断定できません。
ログがないときの次の一手
発生時刻、エラー画面、HTTPステータスコード、直前の変更を記録し、アクセスログ・PHPログ・WordPressデバッグログ・サービス障害情報など確認範囲を広げます。
エラーログを見るときの注意点
古いエラーに惑わされない
数日前・数週間前のログに重大そうな文字があっても、現在の問題とは無関係かもしれません。必ず発生時刻と照合します。
ログをそのまま公開しない
ログにはIPアドレス、内部パス、ドメイン、プラグイン名などの情報が含まれる場合があります。掲示板やSNSへ全文を公開する前に、機密情報が含まれていないか確認してください。
ログを削除してから原因調査しない
容量対策でログを消す場合でも、障害調査中なら必要部分を保存してから削除します。
ログを見ただけで設定を大量変更しない
1件の警告を見てPHP、テーマ、プラグイン、.htaccessを同時に変更すると、どの変更で直ったか分からなくなります。
時刻のタイムゾーンに注意する
サーバーログの時刻が日本時間とは限りません。UTCやサーバー側タイムゾーンで記録されることがあります。実際の発生時刻とずれて見える場合は、ログのタイムゾーンを確認してください。
エラーログから原因を調べるおすすめ手順
初心者向け7ステップ
- 表示されたエラー画面を保存する
- 発生した日時を記録する
- 直前に行った変更を整理する
- 同じ操作を1回だけ再現して時刻を確認する
- その時刻前後のエラーログを見る
- エラー種類・ファイル名・行番号を控える
- 1つずつ原因候補を切り分ける
サポートへ問い合わせる場合も、この情報があると状況を伝えやすくなります。
サポートへ伝える情報の例
- 10月29日10:15ごろから発生
- /sample/ で500エラー
- 直前にプラグインAを更新
- 10:15:32のエラーログにPHP Fatal error
- 対象ファイルは /wp-content/plugins/… と表示
エラーログは普段から見る必要がある？
一般的な共用レンタルサーバーでWordPressを運営する初心者が、毎日エラーログを読む必要はありません。
個人ブログ
確認頻度：トラブル時中心
サイトが正常なら毎日確認する必要性は高くありません。更新後の不具合などで利用します。
会社サイト
確認頻度：障害時＋保守時
重要な更新後や障害時に確認できる体制を作っておくと安心です。
VPS
確認頻度：運用方針に含める
自分でWebサーバーを管理するため、ログ監視・ローテーション・保存容量も運用対象になります。
高アクセスサイト
確認頻度：監視を検討
障害影響が大きい場合は、ログを手作業で見るだけでなく監視・通知の仕組みも検討します。
教科書判定
初心者は「発生時刻の前後を見る」だけでも大きな一歩
エラーログをすべて読める必要はありません。まず、障害を再現した時刻とログの時刻を合わせ、Fatal error・error・warningなどの種類、ファイル名、行番号を確認してください。
WordPress利用者は、最初にレンタルサーバーのエラーログを確認し、必要な場合だけWP_DEBUG_LOGなどのデバッグ機能へ進むのが安全です。
VPS利用者はさらに、Webサーバー・PHP・OS・アプリケーションでログが分かれることを理解し、保存場所とログローテーションまで管理した方がよいでしょう。
FAQ
Q. エラーログにerrorがあれば必ず直す必要がありますか？
A. すべてが現在の障害原因とは限りません。まず発生日時と一致するか、同じ操作で再現するか、サイトへの影響があるかを確認してください。
Q. エラーログとアクセスログはどちらを見ればよいですか？
A. 原因調査では両方が役立ちます。アクセスログで「どのURLで何時にエラーになったか」を確認し、同じ時刻のエラーログで原因候補を探す方法が分かりやすいです。
Q. WordPressのdebug.logとサーバーのエラーログは同じですか？
A. 同じとは限りません。debug.logはWordPressのデバッグ設定によって記録するログで、サーバーのエラーログはApache・PHPなどの設定によって別の場所へ保存される場合があります。
Q. エラーログの英文が分からない場合はどうすればよいですか？
A. まず日時、Fatal errorなどの種類、ファイルパス、行番号を控えてください。それだけでもプラグイン・テーマ・PHPなど原因候補を絞れます。全文は省略せず保存してサポートへ伝えると役立ちます。
Q. エラーログが大量にあるのは危険ですか？
A. 件数だけでは判断できません。Web公開サーバーでは無関係なアクセスや警告も記録されます。現在の障害と同じ時刻・同じ処理で発生しているログを優先してください。
まとめ
エラーログは「何が壊れたか」を絞り込むための記録
- エラーログにはサーバー・PHPなどの異常や警告が記録される
- 500エラーやWordPressの不具合調査で役立つ
- 最初に障害の発生時刻を記録する
- 日時・エラー種類・ファイル名・行番号を確認する
- アクセスログと組み合わせると原因を絞りやすい
- ログに出たファイルを原因と即断しない
- WarningやDeprecatedが必ず障害原因とは限らない
- WordPressのデバッグ表示を本番環境で出し続けない
- ログを外部へ共有するときは機密情報に注意する
初心者は、ログを完全に読解することより「障害を再現した時刻の前後を見る」ことから始めてください。そこに表示されたエラー種類とファイル名を直前の変更と照合するだけでも、原因調査は大きく進みます。
次に読む
「Webサーバーのアクセスログとは？確認できる内容を解説」「サーバーログとは？種類と確認できる内容を解説」「WordPressのデバッグモードとは？有効化方法と注意点」「WordPressの500エラーとは？原因・確認手順・直し方を初心者向けに解説」もあわせて確認してください。