独立サイトのログ分析：Nginx/Apacheログでクローラー・エラー・流入を読み解く
1. なぜ「総アクセス数」だけを見てはいけないのか
多くのサイト運営者はログを開くとまず「今日は何件のリクエストがあったか」を見て、それで商売の良し悪しを判断します。これが最初の落とし穴です。Nginxのデフォルトのaccess.logでは、1レコードが1回のHTTPリクエストです。人間がトップページを1回開くと8〜15件のリクエストが発生し（HTML・CSS・JS・画像がそれぞれ1件）、悪意あるクローラーは1分で千件以上を叩き込みます。総量は意思決定にはほとんど役立ちません。
直感に反する結論はこちらです。アクセス数が「急増」したとき、その8割はどこかのクローラーがあなたのサイトを激しくクロールし始めただけで、顧客が来たわけではありません。判断基準はシンプルです。ログをUser-Agentで重複排除し、上位20件のリクエスト元が誰かを見ます。半分以上がbot系UAなら、この急増はあなたのビジネスとは何の関係もありません。これはAIクローラーログ分析の考え方と同じです。まず「誰が読んでいるか」を切り分け、それから「どれだけ読まれたか」を語ります。
| ログフィールド（Nginx combined） | 意味 | 分析での用途 |
|---|---|---|
| $remote_addr | 参照元IP | データセンターIP・悪意あるスキャン・クローラーの帰属を識別 |
| $request | リクエストメソッド+パス+プロトコル | 実際にどのURLがアクセスされ、どのファイルが叩かれたかを見る |
| $status | HTTPステータスコード | 200は正常、301はリダイレクト、404はリンク切れ、5xxは障害 |
| $body_bytes_sent | 返却バイト数 | 空レスポンスやブロックされた異常ダウンロードを識別 |
| $http_referer | 参照元ページ | 人間がどのリンクから来たか |
| $http_user_agent | クライアント識別子 | ブラウザ・検索エンジンクローラー・AIクローラーを区別 |
2. どう読むか：クローラー・エラー・実訪問者の3つのシグナル
推奨する分析順序は「エラー → クローラー → 実訪問者」で固定し、逆にしないでください。理由は、エラーは実訪問者の体験に直結するため優先度が最も高く、クローラー量はクロール予算と帯域コストを左右し、実訪問者は最後にようやく細かく見る価値がある部分だからです。これもサイト監視とアラートで可用性とエラー率を最優先に置いている理由です。
クローラー判定はUAだけで判断してはいけません。悪意あるクローラーはUAを偽装してGooglebotになりすますからです。標準的な方法は双方向検証です。Googlebotを名乗るIPに対して逆引きDNSを行い、本当にgooglebot.comのネットワークから来ているかを確認し、さらに正引きして照合します。偽装クローラーはこの段階で弾かれます。
| シグナル種別 | 健全レンジ | 対応が必要なしきい値 | アクション |
|---|---|---|---|
| 5xxエラー率 | 0.5%未満 | 10分連続で1%超 | PHP-FPMとバックエンドのログを確認、即対応 |
| 404の割合 | 3%未満 | 単一URLの404が1日100回超 | 301を追加するか内部リンクを修正 |
| 不審なクローラーリクエストの割合 | 20%から40% | 60%超かつ帯域が逼迫 | robotsまたはWAFで制限 |
| 実ユーザーセッション数 | 前週比で横ばい | 2週連続で20%超の減少 | インデックス状況と広告出稿を確認、サーバー問題ではない |
| AIクローラーの読み取り割合 | 5%から15%が正常 | 3倍以上の急増 | 一括収集・学習されていないか確認 |
三、具体的な進め方：コマンド1つから週次レポートまで
一人チームに高価なログ分析ツールは不要です。最小構成のツールは3つ。GoAccessで可視化した週次レポート、awkで時間別集計、月1回の人手による全量監査です。以下はすぐ使える2つの場面です。
場面1：今日最もエラーが多いURLを洗い出す。Nginxのログディレクトリで実行：awk ‘$9 ~ /^5/ {print $7}’ access.log | sort | uniq -c | sort -rn | head -20。すべての5xxリクエストのパスを取り出し、出現回数順に並べます。上位20件が今日最優先で直すべきページです。
場面2：GoogleとAIクローラーが今日それぞれ何回来たか見る。awk ‘BEGIN{IGNORECASE=1} /Googlebot|GPTBot|ClaudeBot|bingbot/ {print $http_user_agent}’ access.log | sort | uniq -c | sort -rn。結果をUAごとに分ければ、Googleの通常のインデックス用クローラーと各社AIの読み取りクローラーの比率がわかります。CDNサイトはエッジログではなくオリジンログを取得してください。この点はCDNグローバル高速化のオリジンとキャッシュの違いを参照。
場面3：サイト運営者自身のために週次レポートを出す。GoAccessを起動して週単位でHTMLレポートを生成し、4つの数字に注目します。ステータスコード分布で4xxと5xxがそれぞれ何割か、リクエスト上位10URL、時間別のトラフィック曲線、UA別のクローラー割合です。このレポートを毎週月曜の午前に見る習慣をつければ、その場でログを漁るよりはるかに効率的です。見つけた異常を小さな表に記録する習慣をつけておくと、3か月後に振り返ったときに傾向が見えてきます。
| 頻度 | アクション | 成果物 | 所要時間 |
|---|---|---|---|
| 毎日 | 5xxエラー率のダッシュボードをざっと確認 | 障害の有無の判断 | 2分 |
| 毎週 | GoAccessで先週のレポートを出力 | 上位パス、上位クローラー、ステータスコード分布 | 10分 |
| 毎月 | 404と異常UAを全量監査 | リンク切れリスト、ブロックすべきIPリスト | 1 時間 |
| 四半期ごと | ログの保持とローテーション方針を調整 | ディスクがあふれず履歴を追えることを確認 | 30分 |
四、落とし穴：最も多い3つの誤読
最初の落とし穴は、200 をそのまま正常とみなすことです。悪意あるスキャナに叩かれた一部のプラグインは、200 と偽装ページを返します。ステータスコードは正常でも中身が差し替えられています。これは「返却バイト数が異常に小さい」または「URL に本来ありえないパラメータが付いている」を組み合わせて判断し、深刻な場合はサイトが攻撃を受けた後の手順で処理します。
二つ目の落とし穴は、リアルタイムだけを見て履歴を残さないことです。ログをローテーションと保持ポリシーで管理しないと、ディスクがあふれるか、三か月後に「三月のあの障害はいつ始まったのか」を調べたくても、たどれません。日単位でローテーションし、ホットデータを 90 日保持し、超過分は圧縮してアーカイブすることをおすすめします。
三つ目の落とし穴は、クローラのアクセスを SEO の成果とみなすことです。Googlebot が一万回来ても、順位が良いわけではありません。繰り返しクロールしているだけです。本当に SEO と関係するのは「重要なページが正常にクロールされているか」であり、これはインデックス状況と照らし合わせて見るべきで、クロール数だけを褒めるものではありません。パフォーマンスとクロールの関係は、Core Web Vitalsがスパイダーのクロール完了度に与える影響をご覧ください。
| 誤読 | 表面的な現象 | 本当の原因 | 正しい確認方法 |
|---|---|---|---|
| アクセス急増は良いこと | リクエスト数が三倍 | あるクローラが急に大量クロール | UA で重複を除き実ユーザー比率を見る |
| 全部 200 なら健全 | ステータスコードはすべて正常 | 改ざんされ偽装ページを返す | 異常に小さいレスポンスと不審なパラメータを抜き取り確認 |
| Google のクロールが多い=順位が良い | Googlebot のリクエストが多い | 低品質ページを繰り返しクロールしている | インデックス数と実際の順位を照合 |
| 404 は放置でよい | 比率は高く見えない | 古い被リンクが重みを失い続ける | TOP 404 を対応する新ページへ 301 |
FAQ よくある質問
Nginx と Apache のログ形式は何が違い、分析方法は共通ですか？
本物の Googlebot と偽装クローラはどう見分けますか？
ログはどのくらい保持すれば十分ですか？
404エラーはすべて対処すべき？
CDNを使うとサーバーログはまだ正確？
ログでGPTBotやClaudeBotがクロールしているのは良いこと？悪いこと？
最後に
ログ分析の価値は「アクセスを見る」ことではなく「トラブル対応と人を見分ける」ことにあります。1人で運営する個人サイトなら、週に10分レポートを1回実行し、月に1時間かけて全体監査を1回行えば、よくある問題の90%はカバーできます。どこでエラーが出ているか、どこにリンク切れがあるか、どのクローラーが帯域を食っているか、人間は実際どこから来ているか。
実行は3ステップ。第一に、ログ形式をcombinedに統一し、日単位で分割して90日間保持する。第二に、まず5xxエラー率が1%を超えたらアラートを出し、その後TOP 404に対処する。第三に、クローラーと人間を分けて集計し、総アクセス数で自分を騙すのはやめる。関連するサイト保守のリズムは、公式サイト保守期間の毎月6つのタスクのチェックリストと一緒に組み立てるとよいでしょう。
覚えておきたい一言。サーバーログはトラフィックのダッシュボードではなく、事故現場の映像です。まずどこに車がぶつかったかを探し、それから道路を何台の車が走ったかを数えましょう。