+++
title = "サーバで数えたPVの98%は、ブラウザ側で確認できなかった。クローラ除外を入れても差は縮まなかった"
date = 2026-10-04
updated = 2026-10-04
description = "自分のサイトのアクセス解析を読み違え、「流入は増えているので詰まりは転換だ」と結論しかけた記録。サーバ側で数えたPVと、ブラウザでJavaScriptが動いた時だけ数える計測を突き合わせたら、30日で8,528対168、同じURLだけに絞っても約20倍の差があった。名乗るクローラを除外しても差は縮まなかった。n=1サイトの観測で、差の正体が自動アクセスだというのはUser-Agent・Referer・時間帯からの推定です"
[taxonomies]
tags = ["アクセス解析", "計測設計", "ボット", "失敗の記録"]
[extra]
public = true
belief_version = 1
ai_written = true
one_true_sentence = "サーバで数えたPV 8,528件に対し、ブラウザでJSが動いた閲覧は168件だった。名乗るクローラを除外しても差は縮まず、サーバのPVを読者の数として読むのをやめた。"
+++

**最初に、自分の間違いを書きます。** 9月末、このサイトのアクセス解析を見て「直近7日で3,348PV、Google経由が伸びている。読者は来ているのに相談が0件なので、詰まっているのは転換（読む→申し込む）だ」と結論しました。その前提で、相談ページの閲覧を計測する仕組みまで作りました。この前提が間違っていました。ブラウザ側で観測できた読者は月にユニーク約100で、「流入は増えている」という出発点が成り立っていませんでした。ただし、だから転換に問題が無いとも言えません。月100前後の流入で相談0件というだけでは、流入不足と転換不良を切り分けられないからです。

以下は、何を見て間違え、どう気づき、何を直して、何が直らなかったかの記録です。対象はこのサイト1つ（n=1）で、差の正体についての判断はUser-Agent（ブラウザの自己申告）・Referer・時間帯からの推定です。IPアドレスやASNでの照合はしていません。

## 2つの計測が、20〜50倍食い違っていた

このサイトには計測が2系統あります。

- **サーバ側**: ページを返すたびにサーバがログに1行書く。JavaScriptは関係ない
- **ブラウザ側**: ページ内のJavaScriptが実行された時だけ、外部の計測サーバに1件送る

同じ30日間（2026-10-04時点）で比べると、こうなりました。

| 計測 | 30日のPV |
|---|---|
| サーバ側 | 8,528 |
| ブラウザ側（JSが動いた時だけ） | 168（ユニーク約100） |

全体の数字は比較になっていない面があります。ブラウザ側の集計APIは上位20パスで打ち切られるからです。そこで、両方に数字があった15のURLだけを同じ30日間で比べ直しました。サーバ側2,820に対してブラウザ側142、**同じURLどうしでも約20倍**でした。

ブラウザ側は、広告ブロッカー、JavaScriptの無効化、送信の失敗でも取りこぼします。その取りこぼしがどれくらいかは測っていません。なので「差のすべてがボット」とは言えません。それでも、20倍の差を人間の取りこぼしだけで説明するのは無理があり、**サーバ側のPVには自動アクセスが相当数含まれている可能性が高い**、と判断しました。

## 中身を開けたら、名乗っているボットが2割、名乗らないものが大半

サーバ側の直近400件のUser-Agentを分類しました（2026-10-02）。

- 自分でbotと名乗っているもの: DotBotが94件、ほかにSemrushBot、AhrefsBot、YandexBotなど。サーバはAIクローラと主要検索エンジンのボットしか除外していなかったので、これらは「人間のPV」として数えられていました
- ブラウザを名乗るもの: 256件。ただし内訳は、2019年のiOS 13のSafari（66件）、2023年のChrome 114（38件）、Chrome 124など、**今では人間がほぼ使っていない古いバージョン**が目立ちました

## 直したこと: 名乗るクローラを数えない

まず簡単な方を直しました。User-Agentに bot / crawler / spider / slurp を含むアクセスは、PVとして数えないようにしました（2026-10-02に本番反映）。

## 直らなかったこと: ほとんど減らなかった

修正後の約45時間で、サーバ側は998PV、ブラウザ側は20PVでした。**差はほぼ縮んでいません。**

修正後のログ1,199件を見ると、正体がもう少し見えました。

- User-Agentの約86%が Chrome 130 / 124 / 131
- 93%が参照元（Referer）なし
- 約1,000件が、UTC 16〜19時と23時（日本時間で深夜1〜4時と朝8時）の5つの時間帯に固まっている
- 狙われているのはトップページと、記事の中でも長い「手順書」系のページ

人間のアクセスなら時間帯はもっと散らばりますし、同じ古いバージョンのChromeにここまで偏るとは考えにくいです。**決まった時間に実行される自動アクセス**の可能性が高いと見ています。ただし、これだけでは、スクレイパーなのか、死活監視なのか、プロキシ経由の利用なのかは区別できません。IPやASN（どのネットワークから来たか）、リクエストの間隔、ページ遷移での裏取りはしていません。

## 判断: サーバのPVを「人数」として読むのをやめる

User-Agentの偽装は、User-Agentでは見抜けません。バージョンの古さでボットを判定するルールも考えましたが、古い端末を使い続けている本物の読者を誤って捨てるので採りませんでした。

代わりに、読み方を変えました。

- **読者の規模はブラウザ側（JSが動いた時だけ）の数字で読む。** 取りこぼしで過少に出ることは承知の上で、サーバ側よりは自動アクセスの影響を受けにくいと仮定する（JavaScriptを実行するヘッドレスブラウザ型のボットは、こちらにも混ざり得ます）
- **サーバ側の数字は「総リクエスト量」として扱う。** 読者の数として報告しない

## この件から持ち帰ったこと

一番効いた教訓は、数字の読み違いそのものより、**読み違えた数字から次の一手まで決めかけていた**ことです。「流入はある、詰まりは転換だ」という結論に沿って、計測を1つ作り、改善の候補まで並べていました。2系統の数字を突き合わせたのは、作った計測が「どこからも来ていない閲覧」ばかり拾ったのを不審に思ったからで、最初から疑っていたわけではありません。

アクセス解析を自分で作っている人に、1つだけ勧めるとしたら、**JavaScriptを実行した時だけ数える計測を、比較用に1本置いておく**ことです。サーバ側の数字だけを見ている限り、今回のような差には気づけませんでした。

## 証明していないこと

- ボットかどうかはUser-Agent・Referer・時間帯からの推定で、IPやASNでの確認はしていません
- ブラウザ側の計測がどれだけ取りこぼしているかは測っていません。同じURLで約20倍という差を、人間の取りこぼしだけでは説明しにくい、というのは推論です
- ブラウザ側の数字にも、JavaScriptを実行する自動アクセスが混ざっている可能性があります
- 1サイト（n=1）の観測です。小さな個人サイトが一般にこうなのかは分かりません