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

エラーログとは？アクセスログとの違い

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

アクセスログが「来訪者の記録」なら、エラーログは「トラブルの記録」です。サイトが何らかの原因で正常に動かないとき、まず開くべきはエラーログです。WordPressの不具合・プラグインエラー・.htaccessの設定ミスなどを調べるためのツールと覚えておきましょう。

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

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

1. サーバーパネルにログインし「アクセス解析」→「エラーログ」を開く——左メニューの「アクセス解析」をクリックすると「アクセス解析」「アクセスログ」「エラーログ」の3項目が展開されます。「エラーログ」を選んでください。
2. 対象ドメインの「表示」または「ダウンロードする」をクリック——ドメイン一覧が表示されます。確認したいドメインの「表示」をクリックするとブラウザ上でエラーログが表示されます。手元に保存したい場合は「ダウンロードする」を使います。

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

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

エラーログは英語と記号の羅列に見えますが、構造は決まっています。全部読む必要はなく、いくつかのキーワードを知っておくだけでトラブルの原因を特定できます。エックスサーバーの公式マニュアルに掲載されているログの表示例はこのような形式です。

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

全部読もうとしなくて大丈夫です。まずこの2点だけ確認しましょう。エラーレベルは「error」や「crit」が並んでいれば要確認です。「notice」「info」は参考情報なので無視してOKです。エラー内容（末尾の英文）はまるごとコピーしてAIに「これはどんなエラーですか？」と聞くだけで原因がわかります。

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

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

AH01276：autoindex:error（ディレクトリ一覧の表示禁止）——最もよく見るエラーの一つです。攻撃スクリプトが /wp-includes/ や /wp-content/uploads/ などのディレクトリを直接開こうとしたときに記録されます。これはエックスサーバーが正常にディレクトリリスティングを禁止している証拠です。エラーとして記録されますが、実害はなく対応不要です。

AH00124：内部リダイレクトの上限超過——.htaccessの設定ミスや、WordPressのパーマリンク設定と実際のディレクトリ構造が合っていないときに発生します。サイトがリダイレクトループに陥っている可能性があります。WordPressのパーマリンク設定（管理画面 → 設定 → パーマリンク）を一度保存し直すと解決することが多いです。

PHP Fatal error / PHP Warning——WordPressのプラグインやテーマのPHPコードに問題があるときに発生します。プラグインを更新した後に画面が真っ白になった場合、このエラーが記録されていることがほとんどです。エラー内容に記載されているファイルパスを確認します。wp-content/plugins/プラグイン名 が含まれていれば、そのプラグインが原因です。

File does not exist / Not Found——存在しないファイルへのアクセスが発生したときに記録されます。リンク切れ・プラグインが参照するファイルが見つからない・favicon.icoが設置されていないなど、様々な原因で発生します。大量に同じURLへの「File does not exist」が出ている場合は、そのURLのリンク切れを修正します。散発的であれば対応不要なことが多いです。

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

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

実際にエラーログを確認してみると、WordPress運営サイトへの攻撃の実態が見えてきます。

1日に何度も「ディレクトリ探索」が繰り返されています。複数の異なるIPアドレスから、以下のようなディレクトリへのアクセス試行が繰り返し記録されていました。

• /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」など、サイトの動作に直接影響するエラーです。

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

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

エラーログを開くタイミングは決まっています。この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へのエラーが記録されていることがあります。テーマファイルの読み込みエラーや、ショートコードのプラグインが無効化されているなどの原因を特定できます。

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

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

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

ChatGPT・Claudeへの聞き方はシンプルです。エラーログをコピーして「エックスサーバーのエラーログに以下の内容が記録されていました。これはどんなエラーで、どう対処すればいいですか？」と続けてログの内容を貼り付けるだけです。数十行あっても構いません。AIが内容を整理して、対処が必要なものとそうでないものを分けて教えてくれます。

ログに含まれる「AH00124」「AH01276」などのエラーコードをそのままGoogleで検索するのも有効です。エラーコードは世界共通の識別子なので、公式ドキュメントや解決事例が豊富に出てきます。英語が読めなくてもAIに任せれば解決できます。大切なのは「エラーが出たときにログを開く習慣」を持つことです。

エラーログは「トラブル時の地図」

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

実際にエラーログを活用した体験として、プラグイン更新後にサイトが真っ白になったケースがあります。エラーログを確認したところ PHP Fatal error とともに問題のあるプラグインのファイルパスが記録されており、そのプラグインを無効化することで10分以内に復旧できました。エラーログがなければ、どのプラグインが原因かを特定するために全プラグインを一つずつ無効化していく作業が必要になります。

毎日AM3時にクリアされる仕様は少し不便ですが、裏を返せば「異常が起きたら当日中に確認する」という習慣を作るきっかけになります。気になることがあったらすぐ確認する——これだけで十分です。アクセスログの確認方法についてはエックスサーバーのアクセスログ確認方法を解説した記事もあわせてご覧ください。

よくある質問

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

アクセスログと合わせて使いこなせるようになると、セキュリティの異常もプログラムの不具合も素早く原因を特定できるようになります。まずはサーバーパネルでの場所を確認しておきましょう。定期的にキャンペーンを実施しており、エックスサーバーをこれから始める方はタイミングを見て公式サイトを確認してみてください。

エックスサーバー公式サイトを見る

1. アクセスログとは？アクセス解析との違い

アクセスログは、サーバーに届いたすべてのリクエストをファイル単位で記録したものです。「誰が・いつ・どのファイルに・どのようにアクセスしたか」をテキスト形式で記録しています。

アクセス解析が「サイト全体の健康診断レポート」なら、アクセスログは「カルテの生データ」です。普段は不要ですが、何か問題が起きたときに掘り下げる手がかりになります。日常的にチェックするのはアクセス解析で十分で、アクセスログは「何かおかしい」と感じたときに初めて開く場所と覚えておけばOKです。

2. アクセスログの確認方法

サーバーパネルのアップデートで、ダウンロードせずにブラウザ上でそのままログを確認できる「表示」ボタンが追加されました。手順は以下の通りです。

1. サーバーパネルにログインし「アクセス解析」→「アクセスログ」を開く
   左メニューの「アクセス解析」をクリックすると「アクセス解析」「アクセスログ」「エラーログ」の3項目が展開されます。「アクセスログ」を選んでください。
2. 対象日を選択して「表示」または「ダウンロードする」をクリック
   ドメイン一覧が表示されます。対象のドメインで日付を選び「表示」をクリックするとブラウザ上でログが確認できます。手元に保存したい場合は「ダウンロードする」を使います。

3. ログの読み方——英数字の羅列が何を意味するか

アクセスログは最初に見ると英数字の羅列で戸惑いますが、構造は決まっています。実際のログはこのような形式で記録されています（公式マニュアルの記載例）。

example.com 192.0.2.0 - - [11/Jul/2013:12:09:17 +0900] "GET /?action=hoge HTTP/1.0" 200 2602 "-" "Mozilla/5.0..."

全項目を読む必要はありません。トラブル調査では主にこの3つを確認します。

• IPアドレス：同一IPから大量のアクセスが来ていれば攻撃の疑いあり
• ステータスコード：404が大量に出ていればリンク切れや不正アクセスの可能性
• ユーザーエージェント：Googlebotならクロール、見慣れない文字列ならボットや攻撃ツールの疑い

4. アクセスログが実際に役立つ場面

アクセスログは「何か問題が起きたとき」に開くものです。具体的にどんな場面で役立つかを知っておくと、いざというときに迷わず対応できます。

使い所① 外部からの攻撃・不審なアクセスを調査するとき

サイトが重くなった・WordPressの管理画面に身に覚えのないアクセスが来ているなど、攻撃の疑いがある場合にIPアドレスを確認します。同一IPから短時間に大量のリクエストが来ていれば、そのIPをサーバーパネルの「アクセス拒否設定」でブロックできます。

実際のログでも、1つのIPが数秒以内にトップページ確認→WordPress検出→xmlrpc探索→ログインページ攻撃と連続アクセスしてくるパターンがよく見られます。すべて403で弾かれているため実害はありませんが、こうした動きをIPアドレスで追いかけられるのがアクセスログの強みです。

使い所② Googlebotのクロール状況を確認するとき

「記事を公開したのにGoogleにインデックスされない」と感じたとき、ユーザーエージェントに「Googlebot」が含まれるアクセスを探すことで、Googlebotが実際にサイトに来ているかどうかを確認できます。アクセス解析のロボット別レポートと合わせて使うと、より詳しい状況が把握できます。

使い所③ 404エラーが大量発生している原因を特定するとき

ステータスコード「404」が大量に出ている場合、どのURLへのアクセスで404が出ているかをログで確認できます。記事を削除したあとの内部リンク切れ、プラグインが参照しているファイルが見つからないなど、原因の絞り込みに使えます。

使い所④ 他社サーバーからの移行後に動作確認するとき

さくらやConoHa WINGなどから移行してきた方は、移行直後にアクセスログを確認すると「ファイルが正しく転送されているか」「リダイレクトが正常に機能しているか」を確かめる手がかりになります。ステータスコードが200で返っているページと、404や301が出ているページを比較することで、移行漏れや設定ミスを早期発見できます。

なお、アクセスログのデータは生のテキスト形式のため、量が多いと読み解くのに時間がかかります。量が多い場合はAIにログの一部をコピペして「この中で怪しいアクセスを教えて」と聞く方法が効率的です。

5. 保存設定——デフォルトは「ログを残さない」になっている

デフォルトでは「ユーザー領域への保存」はOFFです。過去30日分のログはサーバーパネルから確認できますが、それ以上を保存したい場合は保存設定を変更する必要があります。

保存設定の変更手順は「アクセスログ」画面の「ユーザー領域への保存設定」タブをクリック → 対象ドメインの編集アイコンをクリック → 保存期間を選択して保存、の順です。設定後は翌日午前4時以降から指定した期間のログが自動で蓄積されていきます。

保存設定をONにするとサーバーのディスク容量を消費します。アクセスが多いサイトではログファイルが大きくなりやすいため、容量に余裕があることを確認してから設定してください。通常のWordPressブログなら保存設定の変更は不要です。「数週間前に起きたトラブルを遡って調べたい」「セキュリティ監査のためにログを長期保持したい」という場合のみ設定してください。

6. 実際のログを見て気づいたこと

実際にサイトの当日分ログを確認してみると、いくつかの特徴的なパターンが見えました。

WordPress攻撃スクリプトの定番パターンが丸見え

あるIPアドレスが数秒以内に次の順序でアクセスしてくるパターンがよく見られます。トップページでWordPressサイトかどうかを確認し、wp-includes/wlwmanifest.xmlにアクセスしてWordPressを特定し、xmlrpc.phpとwp-login.phpへのアクセスを試みる——これは自動化されたWordPress攻撃ツールの典型的な動きです。すべて403で弾かれているため問題ありませんが、こうしたパターンを確認できるのはアクセスログだけです。

AIクローラーが積極的にコンテンツを収集している

GPTBot・OAI-SearchBot・ClaudeBot・ChatGPT-User・PerplexityBotなど、複数のAIサービスのクローラーが1日に何度も訪問するケースが確認できます。AIへのコンテンツ流通が既に始まっていることがログから読み取れます。

自分のWordPress管理画面操作も全部記録される

管理者がWordPressにログインして記事を編集した時間帯は、wp-admin・wp-json・admin-ajax.phpへのリクエストが大量に記録されます。「自分のアクセスも除外できない」という点を念頭に、数値を分析するときは自分の作業時間帯のアクセス数は差し引いて読む必要があります。

ログを1日分見るだけで「攻撃は毎日来ている」「AIクローラーが動いている」「自分の作業も記録されている」という実態が把握できます。異常を察知したときにログを開く習慣をつけておくと、対応が早くなります。

7. 個人的な結論｜アクセスログは「場所だけ知っておけばいい」

アクセスログは毎日確認するものではありません。「何かあったときにここを開く」という場所を覚えておくことが大切です。

実際にアクセスログを開いて役に立つ場面は、WordPressの管理画面ログインページへの不審なアクセスが続いていたときです。IPアドレスを確認してアクセス拒否設定をすることで、余計なサーバー負荷を減らせます。

読み方がわからなくても、ログをAIにコピペして「怪しいアクセスがあるか教えて」と聞くだけでも十分役立ちます。完全に読み解けなくてもツールとして使えることを覚えておいてください。エックスサーバーのエラーログについてはエックスサーバーのエラーログ解説も参考にしてください。

よくある質問

アクセスログは普段から確認する必要がありますか？

通常は不要です。日常的なアクセス状況の確認にはアクセス解析を使い、アクセスログは「サイトが重い」「不審なアクセスがある」「404エラーが多発している」などの問題が起きたときに開く調査ツールと考えてください。

ログをダウンロードせずにブラウザで確認できますか？

はい、サーバーパネルのアップデートで「表示」ボタンが追加され、ダウンロードなしでサーバーパネル上でそのままログを確認できるようになりました。クリックひとつで確認できます。

何日前のログまで確認できますか？

デフォルトでは過去30日分のログをサーバーパネルから確認できます。それ以上遡りたい場合は「ユーザー領域への保存設定」で最長9週間まで保存設定を変更できます。ただし通常のブログ運営では30日で十分です。

ログを読んでも意味がわかりません。どうすればいいですか？

ログの一部（数十行）をAIにコピペして「このログで不審なアクセスや問題のある箇所を教えて」と聞くと、わかりやすく解説してもらえます。完全に読み解けなくても、AIを使ってトラブルの原因を特定することは十分可能です。

他社サーバーからの移行後にアクセスログは確認すべきですか？

確認しておくことをおすすめします。移行直後のアクセスログでステータスコードを確認することで、404エラーが多発しているURL（転送漏れや設定ミス）を早期発見できます。移行後数日間は定期的にチェックすると安心です。

まとめ

エックスサーバーのアクセスログは、サーバーに届いたすべてのリクエストをファイル単位で記録したテキストデータです。普段は開かなくても問題ありませんが、使い所と場所を知っておくことで、トラブル時の対応が格段に早くなります。

普段はアクセス解析で十分。アクセスログは「不審なアクセス」「大量404」「移行後の確認」で使うと覚えておいてください。読み方がわからなければAIにコピペするだけでも役立ちます。まず場所を把握しておき、必要なときにすぐ開けるようにしておきましょう。

エックスサーバーは定期的にキャンペーンを実施しており、10日間の無料お試しもあります。エックスサーバーの公式サイトを確認する