エックスサーバーのエラーログとは?見方・読み方・使い所を初心者向けに解説【2026年版】

始め方・運用

エックスサーバー 機能解説

エックスサーバーのエラーログとは?見方・読み方・使い所を初心者向けに解説【2026年版】

「エラーログって何が書いてあるの?」「英語だらけで意味がわからない……」そんな方に向けて、この記事ではエラーログの仕組み・読み方・実際に役立つ使い所・アクセスログとの違いまで初心者にわかりやすく解説します。

先に結論

  • エラーログは普段は確認しなくていい。「画面が真っ白」「サイトが開かない」など異常が起きたときに開く調査ツール。
  • 確認方法はサーバーパネルから2クリックで完了。ダウンロード不要でブラウザ上で確認できる。
  • ログは毎日AM3時にクリアされるため、エラーが出たら当日中に確認するのが鉄則。
  • ログの中身がわからなくてもAIにコピペして聞くだけで原因を特定できる。

1. エラーログとは?アクセスログとの違い

エラーログは、サーバーやWordPressで発生した「エラー」だけを記録したファイルです。アクセスログが「全リクエストの記録」なのに対し、エラーログは「問題が起きた記録」のみが残ります。

機能 アクセスログ エラーログ
記録する内容 すべてのリクエスト(正常・異常問わず) エラーが発生した記録のみ
主な用途 不審なアクセス・クロール状況の調査 プログラムの不具合・設定ミスの特定
クリアのタイミング 過去30日分を保持(設定変更可) 毎日AM3時に自動クリア
使う頻度 セキュリティ異常を感じたとき サイトが正常に動かないとき

アクセスログが「来訪者の記録」なら、エラーログは「トラブルの記録」です。サイトが何らかの原因で正常に動かないとき、まず開くべきはエラーログです。

結論:エラーログはWordPressの不具合・プラグインエラー・.htaccessの設定ミスなどを調べるためのツールです。普段は見なくて構いませんが、「何かおかしい」と感じたら真っ先に確認する場所と覚えておきましょう。

2. エラーログの確認方法|2クリックで完了

エックスサーバーのエラーログは、サーバーパネルから2クリックで確認できます。ダウンロードなしでブラウザ上でそのまま表示できるため、トラブル発生時でも素早く確認可能です。

  1. 1

    サーバーパネルにログインし「アクセス解析」→「エラーログ」を開く

    左メニューの「アクセス解析」をクリックすると「アクセス解析」「アクセスログ」「エラーログ」の3項目が展開されます。「エラーログ」を選んでください。

  2. 2

    対象ドメインの「表示」または「ダウンロードする」をクリック

    ドメイン一覧が表示されます。確認したいドメインの「表示」をクリックするとブラウザ上でエラーログが表示されます。手元に保存したい場合は「ダウンロードする」を使います。

エックスサーバー サーバーパネルのエラーログ画面。左メニューのエラーログと、pegasus-note.comの表示・ダウンロードするボタンが赤枠でハイライトされている(筆者撮影・2026年4月)
エラーログ画面。対象ドメインの「表示」ボタンでブラウザ上でそのまま確認できる(筆者撮影・2026年4月)

注意:エラーログは毎日AM3時に自動クリアされます。「昨日サイトがおかしかった」という場合、翌日には前日のログが消えている可能性があります。異常を感じたら当日中に確認するか、ダウンロードして保存しておきましょう。

結論:操作はシンプルで2ステップのみ。ただし毎日AM3時にクリアされる仕様のため、エラーが出たら当日中に確認するのが鉄則です。

3. エラーログの読み方|英語の羅列が何を意味するか

エラーログは英語と記号の羅列に見えますが、構造は決まっています。全部読む必要はなく、いくつかのキーワードを知っておくだけでトラブルの原因を特定できます。

エックスサーバーの公式マニュアルに掲載されているログの表示例はこのような形式です。

⚙️ ログの記載例(公式マニュアルより)

[Fri Nov 02 11:56:17.072078 2018] [core:error] [pid 100956] [client ***.***.***.***:58482] AH00124: Request exceeded the limit of 10 internal redirects…

項目 意味
日時 [Fri Nov 02 11:56:17 2018] エラーが発生した日時
エラーレベル [core:error] / [autoindex:error] エラーの種類と重大度。「error」は要確認
プロセスID [pid 100956] サーバーのプロセス番号。基本的に無視してOK
クライアントIP [client ***.***.***.***] エラーを引き起こしたアクセス元のIPアドレス
エラーコード AH00124 / AH01276 エラーの識別番号。検索するとすぐ意味がわかる
エラー内容 Request exceeded… エラーの詳細。ここを読むか、AIに聞くと原因がわかる

💬 初心者が注目すべき2つのポイント

全部読もうとしなくて大丈夫です。まずこの2点だけ確認しましょう。

  • エラーレベル:「error」や「crit」が並んでいれば要確認。「notice」「info」は参考情報なので無視OK
  • エラー内容(末尾の英文):ここをまるごとコピーしてAIに「これはどんなエラーですか?」と聞くだけで原因がわかります

結論:ログを完全に読み解く必要はありません。「error」という文字が多ければ何か問題が起きているサイン。エラー内容の英文をAIにコピペするだけでも原因特定が可能です。

4. よく見るエラーの種類と意味

WordPressを運営していると、同じようなエラーが繰り返し記録されることがあります。代表的なエラーの意味と、対応が必要かどうかを整理しました。

🏆 AH01276:autoindex:error(ディレクトリ一覧の表示禁止)

最もよく見るエラーの一つです。攻撃スクリプトが /wp-includes//wp-content/uploads/ などのディレクトリを直接開こうとしたときに記録されます。

AH01276: Cannot serve directory /home/…/wp-includes/html-api/: No matching DirectoryIndex found, and server-generated directory index forbidden by Options directive

対応:これはエックスサーバーが正常にディレクトリリスティングを禁止している証拠です。エラーとして記録されますが、実害はなく対応不要です。サーバーのセキュリティが正しく機能しています。

⚡ AH00124:内部リダイレクトの上限超過

.htaccessの設定ミスや、WordPressのパーマリンク設定と実際のディレクトリ構造が合っていないときに発生します。

AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error.

対応:サイトがリダイレクトループに陥っている可能性があります。WordPressのパーマリンク設定(管理画面 → 設定 → パーマリンク)を一度保存し直すと解決することが多いです。

⚙️ PHP Fatal error / PHP Warning

WordPressのプラグインやテーマのPHPコードに問題があるときに発生します。プラグインを更新した後に画面が真っ白になった場合、このエラーが記録されていることがほとんどです。

PHP Fatal error: Uncaught Error: Call to undefined function… in /home/…/wp-content/plugins/…

対応:エラー内容に記載されているファイルパスを確認します。wp-content/plugins/プラグイン名 が含まれていれば、そのプラグインが原因です。FTPまたはサーバーパネルのファイルマネージャーでプラグインフォルダを一時リネームすることで無効化できます。

🏢 File does not exist / Not Found

存在しないファイルへのアクセスが発生したときに記録されます。リンク切れ・プラグインが参照するファイルが見つからない・favicon.icoが設置されていないなど、様々な原因で発生します。

対応:大量に同じURLへの「File does not exist」が出ている場合は、そのURLのリンク切れを修正します。散発的であれば対応不要なことが多いです。

結論:「autoindex:error」は攻撃をブロックしている正常動作なので無視でOKです。「PHP Fatal error」はプラグインやテーマの問題なので要対応。エラーコードや英文をAIに渡すと対処法を教えてもらえます。

5. 実際のエラーログで確認したこと——このサイトの事例

実際にエラーログを確認してみると、WordPress運営サイトへの攻撃の実態が見えてきます。ここでは今日のエラーログに記録されていた内容を紹介します。

⚠️ 1日に何度も「ディレクトリ探索」が繰り返されている

午前9時から午後10時にかけて、複数の異なるIPアドレス(Azureのクラウド環境)から、以下のようなディレクトリへのアクセス試行が繰り返し記録されていました。

  • /wp-includes/html-api/
  • /wp-content/uploads/
  • /wp-includes/PHPMailer/
  • /wp-includes/images/
  • /wp-includes/rest-api/

これらはすべて autoindex:error として記録されており、エックスサーバーがディレクトリリスティングを禁止することで正常にブロックされています。WordPressサイトを狙った自動スキャンは毎日当たり前のように来ており、エラーログを見るとその実態がよくわかります。

💬 「エラーが出ている=危険」ではない

エラーログを初めて見ると、大量にエラーが記録されていて驚くかもしれません。しかし autoindex:error のように、サーバーが正常にブロックした結果もエラーとして記録されます。「エラーが記録されている=問題がある」ではなく、「どんな種類のエラーか」を確認することが重要です。

確認すべきは「PHP Fatal error」「500 Internal Server Error」など、サイトの動作に直接影響するエラーです。

注意:エラーログには別ドメインの情報や、他サイトのパスが含まれることがあります。自分のサイトのドメイン名が含まれるエラーのみを確認するようにしましょう。

結論:エラーログを見ると「攻撃スクリプトが毎日来ている」という現実がわかります。ただしエックスサーバーが正常にブロックしていれば心配不要です。「PHP Fatal error」が出ていない限り、基本的に放置で問題ありません。

6. エラーログが実際に役立つ場面

エラーログを開くタイミングは決まっています。この3つの場面に当てはまったら、真っ先にエラーログを確認しましょう。

🏆 場面① サイトが真っ白になったとき(WSoD)

WordPressの「白い画面(White Screen of Death)」はエラーログで原因が特定できることがほとんどです。プラグインを更新した直後に発生した場合、エラーログに PHP Fatal error とともに問題のあるプラグインのパスが記録されています。

エラーログを確認 → 問題のプラグインを特定 → FTPまたはファイルマネージャーでそのプラグインフォルダをリネーム(例:plugin-name → plugin-name_bak)→ サイト復旧という流れで対処できます。

🏆 場面② .htaccessを編集した後に動作がおかしくなったとき

.htaccessを手動編集した後にサイトが表示されなくなった場合、エラーログに AH00124(リダイレクトループ)や 500 Internal Server Error が記録されます。エラーログで原因の行を特定し、.htaccessを修正することで解決できます。

🏆 場面③ 特定のページだけ表示されないとき

サイト全体は表示されるのに特定のページだけ404や500になる場合、エラーログにそのURLへのエラーが記録されていることがあります。テーマファイルの読み込みエラーや、ショートコードのプラグインが無効化されているなどの原因を特定できます。

結論:エラーログが役立つのは「サイトが動かない」「表示がおかしい」という明確な症状があるとき。それ以外は定期確認しなくて問題ありません。

7. ログを読めなくてもOK|AIを使った原因特定の方法

エラーログの英文が読めなくても問題ありません。エラーログの内容をそのままAIにコピペするだけで、原因と対処法を教えてもらえます。

💬 ChatGPT・Claudeへの聞き方

エラーログをコピーして、以下のように質問するだけです。

「エックスサーバーのエラーログに以下の内容が記録されていました。これはどんなエラーで、どう対処すればいいですか?

(エラーログの内容をここにコピペ)」

数十行あっても構いません。AIが内容を整理して、対処が必要なものとそうでないものを分けて教えてくれます。

⚙️ エラーコードを直接検索する方法

ログに含まれる「AH00124」「AH01276」などのエラーコードをそのままGoogleで検索すると、公式ドキュメントや解決事例がすぐ見つかります。エラーコードは世界共通の識別子なので、英語の解説も含めて豊富な情報が出てきます。

結論:英語が読めなくてもAIに任せれば解決できます。大切なのは「エラーが出たときにログを開く習慣」を持つことです。

8. 個人的な結論|エラーログは「トラブル時の地図」

エラーログは毎日確認するものではありません。「何かおかしい」と思ったときに開く地図のような存在です。場所と開き方を知っておくだけで、トラブル解決の速度が大きく変わります。

実際にエラーログを活用した体験として、プラグイン更新後にサイトが真っ白になったケースがあります。エラーログを確認したところ PHP Fatal error とともに問題のあるプラグインのファイルパスが記録されており、そのプラグインを無効化することで10分以内に復旧できました。

エラーログがなければ、どのプラグインが原因かを特定するために全プラグインを一つずつ無効化していく作業が必要になります。地図があるかどうかで、復旧時間に大きな差が生まれます。

毎日AM3時にクリアされる仕様は少し不便ですが、裏を返せば「異常が起きたら当日中に確認する」という習慣を作るきっかけになります。気になることがあったらすぐ確認する、これだけで十分です。

よくある質問

Q エラーログは普段から確認する必要がありますか?

通常は不要です。サイトが正常に動いている間はエラーログを見る必要はありません。「サイトが真っ白になった」「特定のページが表示されない」「プラグイン更新後に動作がおかしい」などの問題が起きたときに初めて開きましょう。

Q エラーログが大量に出ていたら危険ですか?

必ずしも危険ではありません。たとえば「autoindex:error(AH01276)」は外部からのディレクトリ探索をサーバーが正常にブロックした記録です。エラーとして記録されますが実害はありません。注意が必要なのは「PHP Fatal error」「500 Internal Server Error」などサイトの動作に影響するエラーです。

Q エラーログはいつまで確認できますか?

エックスサーバーのエラーログは毎日午前3時に自動クリアされます。前日以前のログを保存する機能はありません(アクセスログとは異なります)。エラーが発生したら当日中に確認するか、「ダウンロードする」でファイルを保存しておくことをおすすめします。

Q 英語のエラーメッセージが読めません。どうすればいいですか?

エラーログの内容をそのままChatGPTやClaudeなどのAIにコピペして「これはどんなエラーですか?」と聞くだけで、わかりやすく解説してもらえます。また、「AH00124」などのエラーコードをそのままGoogleで検索するのも有効です。英語が読めなくても問題ありません。

Q アクセスログとエラーログ、どちらを先に確認すればいいですか?

目的によって使い分けてください。「サイトが動かない・表示がおかしい」場合はエラーログを先に確認します。「不審なアクセスが来ている・攻撃を受けている疑いがある」場合はアクセスログを確認します。両方を組み合わせることで、より正確な原因特定ができます。

まとめ|エラーログは「異常なし」が理想、「何かあれば即確認」が鉄則

エックスサーバーのエラーログは、サーバーやWordPressで発生した問題を記録した調査ツールです。普段は開かなくて問題ありませんが、場所と開き方を覚えておくことで、トラブル発生時の対応速度が格段に上がります。

最終結論:

エラーログは「サイトが動かなくなったとき」に開く調査ツール。
毎日AM3時にクリアされるため、異常を感じたら当日中に確認する。
内容がわからなければAIにコピペするだけで対処法がわかる。

アクセスログと合わせて使いこなせるようになると、セキュリティの異常もプログラムの不具合も、素早く原因を特定できるようになります。まずはサーバーパネルでの場所を確認しておきましょう。

エラーログ・アクセスログなど充実した管理機能が標準搭載。現在キャンペーン期間中で最大30%オフで始められます。

エックスサーバー

コメント

タイトルとURLをコピーしました