WEBサイト
先週、アクセスログを52日分、はじめて全部開いた。2026年7月8日から8月29日までの53個のログファイル、合わせて16,442行。今まで「クローラーが何回来たか」はUser-Agent（アクセスしてきたブラウザやツールが名乗る名前）で数えてきたが、「人がどこから来たか」を示すはずの「参照元」の欄は、一度もまとめて数えたことがなかった。
結果は、想像していたものとかなり違った。「参照元」が付いていた行は391件。そのうち372件、95.1%は、外部サイトからではなく、自分のサイトの中の別ページから移動してきた記録だった。外部サイトから来た記録は、残りの19件だけ。そのうち検索エンジンからの参照は0件、話題のAIサービスからの参照も0件だった。
この記事は、その52日分のログを実際にどう数えたか、何が分かって何が分からなかったかを、そのまま書く。数えている途中で見つけた、想定していなかった動きの話も含めて。
「参照元」という言葉は、Search ConsoleやGA4の画面にも出てくるので、すでに見慣れている人も多いはずだ。だが、その画面に表示される「参照元」と、サーバーに残っている生のログの「参照元」が、同じものを数えているとは限らない。この記事の後半では、その違いと、実際にログを読むときに起きやすい技術的な落とし穴も、そのまま書く。
アクセスログを、はじめて全部 開いた
アクセスログはサーバーの中に、毎日ずっと残り続けている。KUSANAGI環境では標準で日次ローテーションされ、古いものから順に圧縮されて溜まっていく。今回開いたのは、圧縮済みの過去分と、まだ圧縮されていない当日分を合わせた53ファイルだった。
最初の1行は2026年7月8日00時40分、最後の1行は2026年8月29日08時36分。ちょうど52日間、途切れず記録が残っていた。ファイルは合計しても600キロバイトに満たない容量で、決して開くのが大変な量ではない。
52日という期間の意味
52日分残っていたのは、偶然ではなく、ログローテーションの保持設定がそうなっているからだ。逆に言えば、それより古い記録はもう存在しない。「参照元を今度確かめよう」と先延ばしにするほど、確かめられる期間の始まりが後ろへずれていく。今回この記事のために開いたのは、52日という期間の、ちょうど終わりぎりぎりのタイミングだった。
これまで「クローラーが読みに来ているか」はUser-Agentで確かめてきた。だが「人がどこから来たか」を示す欄——Referer（参照元）——は、一度もまとめて数えたことがなかった。理由は単純で、必要になる場面がこれまでなかったからだ。今回、サイト全体の導線を見直す作業の一環で、初めて数えることにした。
「参照元」という言葉が、何を指しているか
「参照元」という言葉は、複数の場所で使われている。だが、それぞれが指しているものは同じではない。
Referer ヘッダーの技術的な定義
アクセスログに残る「参照元」の正体は、ブラウザがリクエストのたびに送ってくるRefererヘッダーという情報だ。「このリンクを、どのページから踏んで来たか」を表す。技術仕様はIETF（インターネット技術の標準化団体）が発行するRFCという文書に定義されている。
"The 'Referer' [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained."
（日本語訳: 「Referer」ヘッダーフィールドは、ユーザーエージェントが、対象のURIを取得した元となるリソースのURI参照を指定することを可能にする）
ここでのポイントは2つある。1つは、Refererを送るかどうかも、何を送るかも、最終的にはブラウザ側の判断だということ。もう1つは、送られてくる値は「ページのURL」であって、「どこの誰か」ではないということ。サーバー側のログは、送られてきたものをただ記録しているだけで、送られてこなければ何も残らない。「参照元が無い」は「誰も来なかった」を意味しない。この違いは、後の見出しでもう一度出てくる。
Search Console・GA4が見せている「参照元」との違い
普段よく見る「参照元」という言葉は、他のツールでも使われている。だが、それぞれ見ているものが違う。
| ツール | 「参照元」が指すもの | 集計の単位 |
|---|---|---|
| Search Console | Google検索結果からのクリック（検索の「参照元」はGoogle検索そのもの） | 検索経由のクリックのみ |
| GA4 | 計測タグが動いた際の参照元・メディア（サイト内の移動は原則、別のセッションとして扱わない設計） | タグが動いたページビュー |
| サーバーの生ログ（今回） | ブラウザが送ってきたRefererヘッダーそのもの（サイト内の移動も含む） | HTTPリクエスト1件ごと |
この3つは、同じ「参照元」という言葉を使いながら、数える対象がそもそも違う。GA4は基本的にサイト内の移動を独立した「参照元」として数えない設計になっているのに対し、生ログはブラウザが送ってきたRefererをそのまま数える。だから今回のように生ログを初めて数えると、「参照元の95.1%が自分のサイト」という、GA4の数字だけを見ていた人には意外な結果が出る。
この「同じ言葉なのに、ツールによって指しているものが違う」という構造は、以前競合サイトの数値をどう読むかでも書いた「推定値と実際に測った値の違い」と根が同じだ。複数のサイトを運用している場合、サイトAではGA4の数字を、サイトBではサーバーログの数字を、同じ意味だと思って並べて比較してしまうことがある。数字を比べる前に、まず何を数えているかを揃える必要がある。
391件のうち、372件は「外から来た人」ではなかった
実際に数えた結果を、そのまま出す。
| 参照元 | 件数 | 割合 |
|---|---|---|
| 自分のサイト内の移動（website.usersupports.com） | 372件 | 95.1% |
| Facebook（モバイル版） | 12件 | 3.1% |
| Baidu | 4件 | 1.0% |
| Facebook（www版） | 3件 | 0.8% |
| 合計 | 391件 | 100% |
95.1%という数字をどう読むか
95.1%という数字だけを見ると、「参照元の情報はほとんど役に立たない」と思うかもしれない。だがそれは正確ではない。この52日間で本当に外部から来た記録は19件しかなかった、というのが正しい読み方だ。母数（391件）の大部分を占めているのが「サイト内の移動」であって、「外部からの参照」を実際より多く見せているわけではない。むしろ、外部からの参照を「参照元あり」の件数（391件）だけで見てしまうと、実際の20倍近く多く見積もることになる。
報告書に「参照元」の件数だけを書くと起きること
この数字の読み違いは、思っている以上に起きやすい。「今月、参照元のあるアクセスが391件ありました」という書き方だけを社内やクライアントへの報告書に載せると、391件のほとんどがサイト内の移動であることが伝わらない。極端な場合、外部からの導線がほぼ機能していない状態を、391件という見た目の大きな数字で覆い隠してしまう。
複数のサイトを同時に運用している場合、この読み違いはさらに起きやすくなる。サイトごとにログの保持期間、フォーマット、集計方法が違うと、「サイトAの参照元は500件、サイトBは50件だから、Aの方が外部からの流入が多い」という比較そのものが成立しないことがある。件数を並べる前に、その件数が何を数えたものかを、サイトごとに確認する必要がある。
この確認は、大がかりな仕組みを新しく作らなくても、今あるログを開けばできる。特別な集計ツールや外部サービスの契約は必要ない。必要なのは、Refererという欄が何を数えているかを正しく理解した上で、実際に手元のログを開いて数えることだけだ。
372件の中身をもう少し覗いてみる
「サイト内の移動だった」で終わらせず、参照元のURLと移動先のURLを1件ずつ突き合わせてみた。すると、372件のうち352件（94.6%）は、参照元のURLと移動先のURLが完全に同じだった。「あるページにアクセスした記録の参照元が、そのページ自身」というかたちだ。通常、人がブラウザでリンクをクリックして移動する場合、あるページの参照元がそのページ自身になることはない。
この352件の移動先を数えると、/robots.txtが37件でもっとも多く、次いで/seo_article/index/page:Nという、ページ送りされた一覧ページへのアクセスが多数を占めた。その多くには?ct=GEO%7CAIや?ct=SEOというカテゴリ絞り込みのパラメータが付いており、1ページずつ順番に、機械的にめくっているような形に見える。/seo_article/1263（10件）や/seo_article/1271（9件）のように、特定の個別記事だけが集中して同じパターンを繰り返している例もあった。
User-Agent（ブラウザやツールが名乗る名前）を確認すると、372件のうち368件（98.9%）は「Mozilla」という、一般的なブラウザが名乗る文字列を含んでいた。だが、これは「人が操作している証拠」にはならない。自動化ツールの多くは、意図的に一般的なブラウザのUser-Agent文字列を名乗る。実際、明らかにツール名を隠さず名乗っている行（「Scrapy/2.16.0」など）も4件見つかった。/members/signin（参照元は/mypage）への移動の中に、このScrapyという、プログラムでWebページを自動取得するためのフレームワーク名を含む行があった。
つまり372件という数字は、「人がサイト内を移動した記録」だけでできているわけではない。94.6%が参照元と移動先が同じURLという、通常の人の操作では起きにくい形をしており、User-Agentがブラウザらしく見えることも、それだけでは人による操作の証拠にならない。372件のうち何件が実際の人の移動なのかは、今回はここまでしか確認していない（「当サイトの現在地」で正直に書く）。
この「参照元と移動先が同じURL」というパターンが、何によって起きているのかは、今回は特定できていない。ページ送りされた一覧ページを順番にめくっている点、カテゴリ絞り込みのパラメータが付いている点からは、当サイト自身が過去に動かした確認用のツールなのか、外部のSEO分析ツールやAI関連のクロールなのか、複数の可能性が考えられる。一般的な話として、Webサイトの状態を機械的に調べるツールの中には、Refererを厳密に管理せず、簡易的に「アクセスするURL自体」をRefererとして送るものが存在する、とされている。だが、それが今回の352件の原因だと断定するだけの根拠は、今の段階では持っていない。ここで大事なのは、原因を推測で断定しないことだ。「参照元と移動先のURLが一致する行が352件ある」という事実と、「その原因はまだ特定できていない」という事実を、分けて書く。
残り19件の中身
19件という数字を、期間で割ってみる。52日間で19件ということは、1日あたり平均0.37件、単純計算では3日に1件を少し下回るペースだ。この密度を「多い」と見るか「少ない」と見るかは、サイトの目的や規模による。ただ、少なくとも「毎日何件も来ている」という状態ではない、ということは言える。
Facebookモバイル経由が12件
もっとも多かったのはFacebookのモバイル版（m.facebook.com）からの12件だった。すべてトップページ（/）への移動で、URLの末尾にfbclidというパラメータが付いていた。これはFacebook上でリンクがクリックされたときに自動で付与される識別子で、Facebook for Developers公式ドキュメントにも記載がある仕組みだ。リンクカード（サムネイル画像とタイトルを表示する形式）を生成するためのクローラーアクセスとは別に、実際にユーザーがFacebook上でリンクをタップしてサイトに来た記録が、この12件になる。
Facebookからの参照12件が、有料広告によるものか、自然な投稿・シェアによるものかは、今回のアクセスログだけでは分からない。fbclidパラメータはFacebook上のリンククリック全般に付くもので、広告限定の識別子ではない。「Facebookからの参照が12件あった」という事実と、「その12件が何によって生まれたか」は、別の情報源（Facebook側の管理画面など）を確認しないと分からない。ここでも、分かることと分からないことを分けて書く。
Baiduからが4件、Facebook（www）からが3件
中国の検索エンジンBaiduから4件、Facebookのデスクトップ版（www.facebook.com）から3件。件数としては小さいが、「参照元が0件ではない」という事実そのものに意味がある。少なくともこの52日間、当サイトへの外部からの導線がまったく機能していなかったわけではない。
検索エンジン（Google・Bing）からの参照は0件だった
今回の集計でもっとも意外だったのはここだ。GoogleやBingの検索結果を経由した参照は、Refererとして1件も記録されていなかった。これは「検索から来た人が0人だった」という意味ではない。次の見出しで書く通り、Refererという情報そのものが付かない経路が非常に多いため、検索経由の訪問がRefererに記録されない設計になっている場合がある。ここは「参照元」の数字だけを見て判断してはいけない領域だ。
AIサービスからの参照は、ゼロ件だった
確認した6つのAIサービス名
ChatGPT（chatgpt.com）、Perplexity（perplexity.ai）、Claude（claude.ai）、Gemini（gemini.google.com）、Copilot（copilot.microsoft.com）、You.com。この6つのドメイン名で、391件のReferer欄をそれぞれ検索した。結果は、すべて0件だった。
AIサービスの回答画面から当サイトへのリンクをクリックした記録は、この52日間のログには1件も残っていない。念のため書いておくと、これは「AIサービスに引用されていない」という意味ではない。AIサービスの中には、リンクを踏んだ際にRefererを送らない設計のものがある。そこは区別して読む必要がある。
Refererが送られるかどうかは、リンクの実装方法にも左右される。単純な<a href>タグで書かれた通常のリンクであれば、多くの場合Refererが送られる。一方、JavaScriptによるページ遷移や、外部リンクを一度中継サーバー経由に変換する仕組みを挟んでいる場合、Refererの値が変わったり、失われたりすることがある。AIサービスの回答画面のリンク実装がどちらの形になっているかは、当サイト側からは確認できない。「0件だった」という事実の裏に、こうした実装上の要因が隠れている可能性がある、ということも合わせて書いておく。
「無い」ことを確かめる方法
「0件だった」という結果は、検索の仕組み自体が壊れていて何も拾えていない場合と、見分けがつかない。そこで、その場で作った、絶対に存在しないはずの文字列（今回の集計時にだけ作った適当な文字の並び）で同じ検索をかけた。結果は同じく0件。検索の仕組み自体は正常に動いていて、その上でAIサービスからの参照が0件だった、ということを確認できた。
この「存在しないはずのもので試してから、本命の0件を信じる」という手順は、数えるたびに必ず入れている。0件という結果は、本当に無いのか、探し方が壊れているのか、見た目だけでは区別できないからだ。
クローラーが読みに来ることと、人がリンクをクリックすることは別
AIサービスからの参照が0件だったという結果は、「AIサービスのクローラーが当サイトを読みに来ていない」ことを意味しない。この点は分けて考える必要がある。archives/121「『守る側』が動けなくなった週」で書いたように、当サイトはAI関連のクローラーを一律に遮断せず、検証してから個別に許可する立場をとっている。実際、今回の52日間でもClaudeBotやCCBotなど、AI関連のクローラーは合わせて数百件、巡回に来ていた。
「クローラーが記事を読みに来る」ことと、「AIサービスの回答画面で当サイトが引用され、その先のリンクを人がクリックする」ことは、まったく別の現象だ。前者はUser-Agent（クローラー名）で数える。後者はReferer（参照元）で数える。今回0件だったのは後者だけであり、前者について何かが変わったわけではない。この2つを混ぜて「AIには読まれていない」と結論づけると、実態とは違う話になる。
AI検索やAIO（AI最適化）という言葉が広まる中で、「AI経由の流入が増えている」という主張と、「AIのクローラーが増えている」という主張が、同じ意味で語られている場面をよく見かける。今回のように52日分を実際に数えると、この2つは同じ52日間の同じサイトの中でさえ、まったく違う数字を示すことがある。片方だけを見て、もう片方も同じように動いていると考えるのは、早い。
全体の97.6%には、「参照元」という情報そのものが無い
ここまでの391件は、あくまで「Refererが付いていた行」の話だ。全体を見ると、話はもっと大きい。391件は、全体16,442行のうちのごく一部でしかない。「参照元」というものさしだけでサイトへのアクセス全体を語ろうとすると、残り97.6%が最初から視野の外に置かれることになる。
| 区分 | 行数 | 割合 |
|---|---|---|
| Refererが付いている行 | 391行 | 2.4% |
| Refererが空（"-"）の行 | 16,051行 | 97.6% |
| 総行数 | 16,442行 | 100% |
「参照元なし」に混ざる4つの経路
16,051行という数字を「直接URLを入力してきた人」と読むのは早い。この中には、少なくとも次の4種類が混ざっている。
- クローラー（GoogleやBing、AIサービスの巡回ロボットなど）による自動巡回のアクセス
- ブックマークからのアクセス（ブラウザによってはRefererを送らない）
- アプリ内ブラウザ経由のアクセス（アプリによってはRefererを送らないものがある）
- ブラウザやサイト側のReferrer-Policy設定によって、意図的に送信を制限されているアクセス
MDN Web Docsの解説によれば、Referrer-Policyという設定によって、Referer送信そのものを「まったく送らない」「オリジンだけ送る」など、段階的に制限できる。何も設定していない場合、現在の主要ブラウザの既定値は「strict-origin-when-cross-origin」というもので、同一サイト内の移動では詳細なURLを送るが、外部サイトへ移動する際はドメイン名までしか送らない、という挙動になる。この既定値そのものが、Referer情報が失われやすい方向に働いている一因でもある。当サイト自身がリンク元になっている場合の設定は、まだ確認していない（後述の「当サイトの現在地」参照）。
URLの末尾（パラメータ）からも、手がかりが拾える
Refererヘッダーが空でも、URLの末尾に付くパラメータが手がかりになることがある。同じ52日間で、URLにutm_（多くのマーケティングツールが使う計測用パラメータ）を含む行が11件、fbclid（Facebook由来のリンクに付く識別子）を含む行が33件あった。fbclidの33件は、Referer欄が実際にFacebookになっていた12件よりも多い。つまり、Referer欄だけでは拾いきれないFacebook経由のアクセスが、パラメータの形では別に残っていたことになる。gclid（Google広告のクリックに付く識別子）を含む行は0件だった。
Refererとパラメータは、どちらも「単独では完全ではない」計測方法だ。Refererはブラウザやポリシー次第で送られてこないことがあり、パラメータはリンクを貼る側が意図的に付けていなければ最初から存在しない。1つの情報源だけで「参照元」を語ろうとすると、どちらの方法でも取りこぼしが生まれる。
クローラーの訪問数と比べると、97.6%の内訳がより見える
同じ52日間、User-Agent（クローラーが名乗る名前）で数えると、bingbotだけで3,000件を超えるアクセスがあった。Googlebot、ClaudeBot、CCBotなど、当サイトが把握しているクローラー名を合わせても、人の訪問（参照元があった391件、および参照元がない中の一定割合の直接・ブックマーク訪問）と比べて、機械的な巡回の方がはるかに多い。
| User-Agent | 件数（52日間） |
|---|---|
| bingbot | 3,003件 |
| CCBot | 136件 |
| ClaudeBot | 95件 |
| Bytespider | 38件 |
| Googlebot | 30件 |
| OAI-SearchBot | 2件 |
参照元(391件)とクローラー(この表だけでも3,304件)を単純に足して「アクセスがあった」と一括りにすると、実態を見誤る。今回の集計で分けて数えたことで、「サイト内を人がどれだけ回遊しているか」と「機械がどれだけ巡回しているか」は、別の指標として扱う必要があると、あらためて確認できた。この比率は、以前archives/117「同じ条件で測っていなかった」で書いた、サイトごとのクローラー到達件数のばらつきの話ともつながる。
この表を作る途中でも、記事の本題と同じ形の勘違いを1つ踏んだ。クローラー名を数える際、最初は行全体を対象に文字列を検索した。すると「ClaudeBot」という文字列が、User-Agentの欄ではなく、当サイト自身のタグページのURL（/ai_ron/archives/tag/ClaudeBotなど）の中に含まれていて、そのページを別のクローラーが読みに来た行まで、まとめて数えてしまっていた。行全体を検索すると、User-Agentの欄とURLの欄が混ざる。Referer（参照元）を数えるときに引用符で区切って位置を確定させたのと同じように、User-Agentも欄を確定させてから数え直す必要があった。
ここで注意したいのは、この表の3,304件と、Refererが空だった16,051件は、そのままイコールではないということだ。クローラーの中にも、まれにRefererを送ってくる例外的な挙動をするものが混ざっていた可能性はある（今回はUser-Agent単位でしか突き合わせていない）。「Refererが空の行=すべてクローラー」と単純化すると、それもまた別の思い込みになる。数える軸（User-Agentで数えるか、Refererで数えるか）を混ぜないことが、ここでも重要になる。
ログの1行を、位置で読むと必ず外す
ここからは、数える作業そのものの話をする。「Refererは何列目にあるか」を決め打ちで数えると、正しい答えが出ないことがある。
1列目は数字で、IPには見えなかった
実際のログの1行はこういう形をしている（サンプル、IPアドレスは記事用に一部置き換えている）。
947662 - 52.167.144.173 - - [29/Aug/2026:00:11:35 +0900] "GET /ai_ron/archives/84 HTTP/1.1" 200 43521 "-" "Mozilla/5.0 ... bingbot/2.0 ..." -
スペースで区切った1列目は「947662」という数字だった。一般的なアクセスログの解説では、1列目に接続元のIPアドレスが入ると説明されることが多い。だが実際にこのサーバーで確認すると、1列目はIPアドレスの形をしていない数字で、実際の接続元IPアドレスは3列目に入っていた。おそらく、サーバー構成上、手前にプロキシやロードバランサーのような中継が挟まっていて、その内部処理で付与された識別子だと思われる。ここを確認せずに「1列目がIP」という前提でスクリプトを書くと、まったく別の値をIPアドレスとして扱ってしまうことになる。
この違いは、Referer（参照元）を数えるだけなら大きな問題にはならない。だが「同じIPから何回アクセスがあったか」のような、IPアドレスそのものを使う集計をしようとした場合、1列目をそのまま使うと、まったく実態と違う結果になる。今回の記事はReferer（参照元）の集計が中心なので実害はなかったが、このサーバーで別の集計をする際には、同じ落とし穴を踏む可能性が残っている。
2つの「ハイフンだけの列」も、意味を持っている
4列目と5列目は、どちらも「-」（ハイフン1文字）だった。よく知られたアクセスログの標準的な書式（Common Log Format）では、この位置にはRFC 1413で定義された「identプロトコル」による識別情報と、Basic認証を使っている場合のユーザー名が入ることになっている。現在ではidentプロトコルはほとんど使われておらず、この2列は実質的に常に「-」になる。「-」だからといって、その列が無意味だとは限らない。「この情報源は、今は使われていない」という状態を表す「-」であって、行の構造そのものが崩れているわけではない。
実際の接続元IPは2〜3列目にあった
スペース区切りでは、この「1列目がずれている」問題にすぐ気づけない。列の意味は、サーバーの設定（ログフォーマットの定義）によって変わる。Apache HTTP Server公式ドキュメント（mod_log_config）には、ログフォーマットは自由に定義できると明記されている。つまり「1列目はこうなっているはず」という思い込みは、サーバーごとに裏切られる可能性がある。複数のサイトを横並びで運用している場合、サイトAのログの読み方を、そのままサイトBに使い回すと、同じ落とし穴を踏むことになる。
引用符で区切って、後ろから数える
Refererと User-Agentは、どちらもダブルクォート（"）で囲まれている。今回は、スペース区切りではなく、引用符（"）で行を区切り、後ろから数える方法をとった。
zcat -f access.log* | awk -F'"' '{ print $(NF-3) }'
これで、行の末尾から数えて4番目の引用符区切りブロック（Referer）を、行の長さに関係なく取り出せる。User-Agentは同じ方法で$(NF-1)になる。実際、今回のログは200行を確認したところ、引用符区切りのフィールド数がすべて7つで揃っていた。数が揃っていることを先に確認してから、位置で取り出す。この順番を逆にすると、たまたま合っているだけの結果を「正しく数えた」と勘違いすることになる。
過去に測った数字と、今回の数字を並べる
archives/76が測った、3つのツールの違い
archives/76「AIに表示された回数を知っているか」では、Search Console、GA4、Bing Webmaster Toolsという3つの公式ツールが、それぞれ違う数字を見せていることを確認した。今回のサーバーログは、その3つとはまた別の、4つ目の測り方になる。ツールが増えるほど「本当の数字」に近づくのではなく、「何を数えているか」の違いが増えていく。
archives/125が見つけた「表示回数までしか見えない」という壁
archives/125「Googleが見せたのは表示回数までだった」では、Google公式の生成AIパフォーマンスレポートが、AI OverviewやAI Modeでの「表示回数」までは見せてくれるが、その先のクリックは見せてくれないことを書いた。参照元の集計も同じ構造を持っている。Refererが付いている391件は「移動した記録」であって、なぜその人が移動したか、その先で何をしたかまでは分からない。どの測り方にも、見える範囲と見えない範囲がある。
「集計する」と決めてから測るまでの遅れ
archives/135「『測定中』と書いてあると、誰も測らなくなる」では、「まだ有効になっていない」と書かれた手順書が、実際にはすでに動いていたという話を書いた。今回の話は、その逆に近い。「アクセスログを一度まとめて確認する」ことは、以前から必要だと分かっていたのに、実際に開くまでに時間が空いていた。データそのものは52日分、サーバーにずっと残り続けていた。ログは書かれ続けていたのに、読まれていなかった。
archives/129「『自分のサイトに、同じ記事が2本ないか』を5分で確かめる」で書いたのと同じで、確かめる方法自体は難しくない。確かめる、と決めてから実際に確かめるまでの間に、時間の差ができる。今回の記事は、その差を埋める作業そのものでもある。
この「差」を埋めるコストは、期間が長くなるほど大きくなるわけではない。今回、52日分のログを結合してReferer欄を数えるのにかかった時間は、コマンドを組み立てる試行錯誤を含めても数十分だった。「52日分もあるから大変だろう」と後回しにする理由と、実際にかかる作業量は、必ずしも一致しない。後回しにする理由の多くは、「大変そうだから」という見た目の印象であって、実際に手を動かしてみるまでは検証されていない。
明日、自分のサイトで確認できること
ここまでの内容を、実際に手を動かして確認できる形に落とし込む。自分のサイトのアクセスログにアクセスできる人向けのチェックリストだ。ログファイルの展開にかかる時間を除けば、13項目すべてを通しでやっても、おおむね1時間ほどで一通り終わる規模の作業だ。
- 直近30日分のアクセスログを、圧縮ファイルも含めてすべて展開し、1つのファイルに結合する
- ログの1行を引用符（"）で区切り、全行でフィールド数が同じかどうかを確認する
- Refererの列が、自分のドメインで始まる行の件数を数え、全体に対する割合を出す
- Refererが空（"-"）の行の件数を数え、全体に対する割合を出す
- Refererに含まれる外部ドメインを、出現回数の多い順に上位10件、一覧で書き出す
- ChatGPT・Perplexity・Claude・Geminiなど、主要なAIサービスのドメイン名でReferer欄を検索し、それぞれ件数を数える
- その場で作った、存在しないはずの文字列でも同じ検索をかけ、結果が0件になることを確認する
- ログの1行を実際に1本開き、引用符で区切った各ブロックが何を表しているか、目で1つずつ確認する
- User-Agentに含まれるクローラー名を5種類以上選び、それぞれの件数を数える
- 参照元のURLと移動先のURLが完全に同じになっている行を探し、件数を数える
- URLに含まれる
utm_やfbclid、gclidなどのパラメータの件数を数え、Refererの件数と突き合わせる - Search ConsoleとGA4に表示されている「参照元」の数字を、同じ期間のサーバーログの数字と並べて突き合わせる
- 自分のサイトのページのReferrer-Policy設定を確認し、noreferrerやsame-originになっていないか調べる
- 「集計する」と社内やブログで書いた過去の記述を探し、実際に集計した日付との差を日数で出す
Search Consoleの見方に迷ったら、🔧 Search Consoleの見方に迷ったらこちらの解説ツールで用語や画面の見方を確認できる。サイト全体の状態をまとめて見たいときは、🔧 サイト全体を数値でチェックできる総合分析ツールも使える。
当サイトの現在地
self-proof-loopの規律に従って、当サイト自身の実施状況を正直に書く。
✅ Refererヘッダーを、位置ではなく引用符区切りで正しく特定して数えた
✅ 372件を参照元URLと移動先URLで1件ずつ突き合わせ、352件（94.6%）が参照元=移動先の同一URLだったことを見つけた
✅ 存在しないはずの文字列で試してから「0件」を確認する手順を、毎回入れた
🔧 372件から機械的なアクセスを除いて「人だけ」を数え直す作業は、まだやっていない
🔧 Search Console・GA4の「参照元」の数字と、今回のサーバーログを、まだ突き合わせていない
🔧 当サイトのページのReferrer-Policy設定を、まだ確認していない
今回できたのは「391件を正しく数え、その中身を一段掘る」ところまでだ。その先の「372件のうち何件が実際の人の移動か」「Referrer-Policyの設定が意図通りか」は、次の宿題として残っている。Search Consoleに重大エラー、インプレッションが約1年間も過大表示で確認したように、公式ツールの数字も、当てにする前に確かめ直す対象になる。自分のサーバーの生ログも、その例外ではない。
もう1つ正直に書いておく。今回の集計は本番サーバーの52日分を対象にしており、テスト環境のログは対象に含めていない。当サイトはtest環境とprod環境の2つを持って運用しているが、test環境向けのアクセスは別の認証（Basic認証）で保護されており、そもそも外部から直接参照元付きでアクセスされる経路がほとんど無い。だから今回はprod環境だけに絞った。この前提も、書いておかないと読む人には伝わらない。
まとめ ── 「参照元」が教えてくれること、教えてくれないこと
52日分、16,442行のアクセスログを開いて分かったのは、次のことだ。
- 「参照元」が付いていた391件のうち、95.1%（372件）は自分のサイト内の移動だった
- 外部サイトから実際に来た記録は、19件だけだった
- 検索エンジンとAIサービスからの参照は、この52日間で0件だった
- 全体16,442行のうち、97.6%にはそもそも「参照元」という情報が付いていなかった
- 372件の内訳を覗くと、352件（94.6%）は参照元と移動先が同じURLで、通常の人の操作では起きにくい形だった
- ログの1行は、思い込みの位置で読むと、実際とは違う値を拾うことがある
「参照元がゼロだった」という事実は、それだけでは「誰も来ていない」ことの証明にはならない。Refererを送らない経路がある以上、これは下限の数字でしかない。だが「391件のほとんどが実は自サイト内の移動で、しかもその一部は人の動きではなさそうだ」という事実は、これまで漠然と眺めていた数字の中身を、はっきりさせてくれた。
次に確認するのは、Search ConsoleとGA4の数字との突き合わせと、Referrer-Policyの設定、そして372件のうち機械的なアクセスを除いた実際の人の移動の割合だ。数字を出して終わりにせず、次に何を確認するかまで書く。それが、この記事のself-proof-loopとしての続きになる。
今回、最初に立てていた見出しの候補は「参照元の95.1%は自分のサイトからだった」で終わるものだった。だが実際に1件ずつ突き合わせてみると、その95.1%の中にも、もう一段掘るべき数字が隠れていた。数字は、1回数えて終わりにすると、その1回の粒度でしか見えない。同じデータをもう一段掘ると、また別の姿が出てくる。この記事自体が、その実例になっている。
関連 archives（連載軸として読む）
- archives/76「AIに表示された回数を知っているか」 ── Search Console・GA4・Bingという3ツールの立体計測（2026年6月）
- archives/125「Googleが見せたのは表示回数までだった」 ── 自分で測る指標が93日間止まっていた回
- archives/121「『守る側』が動けなくなった週」 ── 検証してから個別にallowする立場と、クローラー統計の話
- archives/129「『自分のサイトに、同じ記事が2本ないか』を5分で確かめる」 ── 数え方を変えると、同じデータから違う数字が出る回
- archives/135「『測定中』と書いてあると、誰も測らなくなる」 ── 「集計する」と書いてから15日間、集計していなかった回
- archives/117「同じ条件で測っていなかった」 ── サイトごとのクローラー到達件数のばらつきを確認した回
