アクセスログとは？サイト運用で確認できること

「ページが開かなかった」と連絡を受けたとき、最初の手掛かりになるのがアクセスログです。アクセスログには、Webサーバーが受け付けたHTTPリクエストと、そのとき返した状態コードなどが記録されます。問い合わせがあった時刻とURLを照合すれば、要求がサーバーまで届いたかを確かめられます。

ただし、一行だけで障害の原因や利用者本人を特定できるものではありません。CDNやプロキシを経由する構成では、サーバーへ到達しない要求や中継元のIPアドレスが記録されることもあります。アクセスログが答えられる範囲を知り、エラーログや業務側の記録と組み合わせることが大切です。

アクセスログはWebサーバーが処理した要求の記録

ApacheやNginxでは、アクセスログの記録形式を設定できます。一般的な形式には、接続元・時刻・要求されたパス・HTTPメソッド・状態コード・返したデータ量が含まれます。RefererやUser-Agentを加えた形式もありますが、項目の並びはサーバーごとに同じとは限りません。

たとえば、次のような一行が記録されます。実際のIPアドレスとURLは例示用です。

192.0.2.10 - - [31/May/2026:10:15:32 +0900] "GET /contact/ HTTP/1.1" 200 4821

この例から分かるのは、10時15分32秒に /contact/ へのGET要求を受け、サーバーがHTTP 200を返したことです。200はHTTPの応答が成功したことを示しますが、フォーム送信やメール配送まで成功した証明にはなりません。

一行は時刻・要求・状態コードから読む

長いログを見るときは、すべての項目を一度に理解しようとせず、時刻・要求・状態コードの順に確認します。問い合わせ内容と一致する行が見つかったあとで、IPアドレスやUser-Agentを補助情報として使います。

IPアドレスだけで個人を断定してはいけません。社内ネットワークでは複数人が同じアドレスを共有し、携帯回線では短時間で変わることがあります。不正アクセスの調査でも、認証ログや操作履歴と照合して判断します。

表にない項目が並んでいる場合は、推測で読み飛ばさずサーバーのログ形式を確認します。応答時間や転送先を独自に追加している環境もあり、同じ位置の数値でも意味が異なることがあります。まず正常なアクセスを一件照合し、時刻とパスが対応することを確かめてから障害時の行を読みます。

障害調査は時刻とURLを先に固定する

ログを探す前に、利用者へ「いつ・どのURLで・何をしたか」を確認します。「朝から開かない」だけでは対象が広すぎるため、可能なら分単位の時刻を聞きます。画面に出た状態コードやメッセージ、送信ボタンを押したかどうかも記録します。

時刻にはタイムゾーンの違いがあります。利用者の端末が日本時間でも、ログはUTCで記録されていることがあります。まず分かっている要求を一つ見つけ、時刻のずれを把握してから問題の時間帯を探します。

対象URLと時刻を固定できたら、その前後数分に範囲を絞ります。同じパスへ要求が届いているか、状態コードが毎回同じかを確認します。一件だけの異常か、複数の利用者へ続いている異常かで、次に確認する範囲が変わります。

状態コードは原因ではなく次の確認先を示す

2xxは、Webサーバーが要求を正常な応答として返した範囲です。画面の内容が正しいか、フォーム内部の処理が完了したかは別に確認します。3xxが繰り返されている場合は、URL転送やHTTPS化の設定で循環していないかを調べます。

4xxは、要求されたページがない場合や、認証・アクセス制限により拒否された場合に返ります。404が多くても攻撃とは限らず、古いリンクや画像の参照切れかもしれません。対象URLと遷移元を見て、意図したアクセスかを判断します。

5xxは、サーバー側で処理を完了できなかったときの分類です。アクセスログからは失敗した要求を特定できますが、PHPやWordPressのどこで止まったかまでは分かりません。同じ時刻のエラーログを確認し、直前の更新や設定変更と照合します。

ログにないアクセスは通信経路を確認する

利用者がエラー画面を見たのに、Webサーバーのアクセスログへ該当行がないことがあります。CDNのキャッシュから応答した場合や、DNS・ネットワークの途中で失敗した場合は、要求が対象サーバーまで届きません。ログがないことを「利用者がアクセスしていない証拠」にはできません。

CDNやロードバランサーを使うサイトでは、それぞれのサービスにもログがあるかを確認します。Webサーバーのログに記録されるIPアドレスが中継サーバーになる場合は、転送された接続元情報を正しく扱う設定も必要です。設定を変える前に、現在どの機器を通っているかを整理します。

Nginxでは内部リダイレクト後の処理場所に基づいてログ設定が選ばれる場合があります。特定のURLだけ別ファイルへ記録している構成もあるため、見つからないときはログの保存先と設定を確認します。

アクセスログだけでは分からないことを切り分ける

アクセスログで200を確認しても、問い合わせメールが担当者へ届いたとは判断できません。フォームの受付記録・WordPressの処理・メールサーバーの配送ログは別の情報です。利用者の質問に合わせて、必要な記録を順番に確認します。

同様に、500という結果だけでは原因を特定できません。PHPの停止・プラグインの例外・外部APIの応答待ちなど、複数の原因が同じ状態コードになります。アクセスログは問題が起きた要求を見つける入口として使い、詳細はエラーログの見方で追います。

応答時間がログへ記録される構成なら、遅いページの候補を探せます。ただし、表示の体感にはブラウザーでの描画や画像の読み込みも影響します。速度改善ではアクセスログだけに頼らず、実際のページ表示速度を測定してから作業を進めます。

共有前に必要な範囲だけを切り出す

ログにはIPアドレス・検索語・クエリ文字列・管理画面のパスなどが含まれることがあります。外部へ調査を依頼するときは、問題の時刻を中心に必要な数分だけを切り出します。秘密情報や個人情報を伏せても、時刻・URL・状態コードの対応関係は残します。

切り出したファイルとは別に、元のログを変更せず保管します。調査用のログを公開ディレクトリへ置いたり、誰でも開ける共有URLを作ったりしないようにします。保管場所・閲覧者・削除時期を決めることも、ログを扱う担当者の仕事です。