AIは331回来た。人は1人も連れてこなかった ── 52日分のログで、AIクローラーの訪問と流入を分けて数える

先月、自分のサイトのアクセスログを、AIクローラーのUser-Agentで数える記事を書いた（archives/83）。あのときは「ボットが世界の57%を占めた」という他社の調査を紹介する形で、当サイト自身の数字を細かくは出していなかった。今回は、自分のサーバーのログを52日分、最初から最後まで自分で数えた。

期間は2026年7月8日から8月29日まで。53個のログファイル、合計16,442行。この中から、AIクローラーのUser-Agentが記録されている行を数え、同時に、人がリンクをたどって訪れたときに残るReferer（どこから来たか）の値も数えた。

結果、AIクローラーの訪問は52日間で331回あった。一方、Refererの値にAIサービスのドメインが記録されていた行は、0件だった。「AIに読まれている」ことと「AIから人が来る」ことは、同じ数字ではない。当たり前のようで、自分のサイトで数字にして並べたのは今回が初めてだった。

ただし、この331回という数字にたどり着くまでに、一度は違う数字を「正しい」と思い込みかけた。数え方の途中に、当サイト自身が付けたタグ名がクローラーの名前と重なっていたことが原因で、数字が実際より多く出てしまう瞬間があった。その経緯は、記事の中盤で詳しく書く。

52日分のログを、もう一度数え直した理由

きっかけは、archives/135で書いた反省だった。「集計する」と記事に書いてから15日間、自分のサイトのログを一度も開いていなかった、という話だ。あのとき集計したのはllms.txtやrobots.txtへの到達数で、AIクローラーそのものの訪問回数と、そこから来る人の数は、まだ分けて数えていなかった。

そしてもう一つ、archives/86で書いたことも引っかかっていた。Cloudflareの初期設定にある「AI bots ブロック」が、意図せずAIクローラーの巡回を止めてしまう、という話だ。あの記事を書いてから、自分のサイトでAIクローラーが実際にどれだけ来ているのかを、期間を区切って数え直したことがなかった。

「来ているはずだ」という感覚と、「来ていることを数えた」という事実は、別のものだ。今回は、その差を埋める作業として、52日分のログを最初から最後まで開いた。

対象にしたログの範囲

本番サーバーのaccess.logを対象にした。ログはローテーションされて日ごとに別ファイルになっており、対象期間で53ファイルが残っていた。合計16,442行。1日あたり平均すると約310行になる。この数字自体、当サイトの規模を示すものとして、先に断っておく。大規模サイトの数字ではない。だからこそ、331回という数字も、100万PVのサイトの331回とは違う意味を持つ。

訪問を数えた方法（User-Agentで数える）

アクセスログの各行には、リクエストを送ってきたクライアントが自己申告するUser-Agentの文字列が記録されている。CCBotやGPTBotのようなAIクローラーは、自分の名前を名乗ってアクセスしてくる（このこと自体は、当サイトが何かを設定しているからではなく、クローラー側の仕様だ）。この文字列を数えることで、「どのクローラーが、何回来たか」が分かる。

ただし、User-Agentは自己申告なので、偽って名乗ることもできる。今回の数字は「その名前を名乗って来たリクエストの数」であって、「本当にそのクローラーが来た証明」ではない。この限定は、後の節でもう一度書く。

流入を数えた方法（Refererで数える）

人がリンクをクリックして訪れたとき、ブラウザは多くの場合、直前に見ていたページのURLを「Referer」としてリクエストに含めて送る。このRefererの値が、ChatGPTやPerplexityのようなAIサービスのドメイン（chatgpt.com、perplexity.ai、claude.aiなど）になっていれば、「AIの回答の中のリンクから、人が来た」ことが分かる。

Refererが空、または自サイト内のページになっている行は、人の訪問だとしても「どこから来たか分からない」行として除外し、外部ドメインが入っている行だけを数えた。

数え方が広すぎないかを確かめる

数える前に、その場で作った、実在しないはずの文字列（このために生成した適当な英数字列）でログを検索してみた。結果は0件だった。もし検索の条件が広すぎて、無関係な行まで拾ってしまう作りになっていたら、この存在しない文字列でも何かヒットしてしまうはずだ。0件だったので、少なくとも「拾いすぎている」形にはなっていないと判断した。

AIクローラーは52日間で331回来た

User-Agentで数えた結果を、種類ごとに並べる。

User-Agent	52日間の訪問回数	主な役割
CCBot	136	学習データの収集（Common Crawl）
ClaudeBot	95	学習データの収集（Anthropic）
YouBot	60	検索インデックスの収集（You.com）
Bytespider	38	学習データの収集（ByteDance）
OAI-SearchBot	2	検索インデックスの収集（OpenAI）
合計	331	—

内訳を足し算して確かめる

この表を作る過程で、一度、数字が合わない場面があった。最初に手元に置いていたメモの合計欄には、6種類の内訳を足した結果とは違う数字が書かれていた。136+102+60+38+6+2＝344になるはずなのに、メモの合計はそれより13少ない数字のままだった。

気づいたきっかけは、単純な暗算だった。念のため、記事を書いている途中でもう一度サーバーに接続し、同じログファイルに対して、それぞれのUser-Agentの文字列を「含む行」をあらためて数え直した。結果は内訳の6つの数字と完全に一致し、合計も344になった。この時点では、「合計は344の方が正しい」と考えていた。

タグページの名前と、クローラーの名前が同じだった

ところが、さらに念のため、それぞれのクローラーがどのページに来ているかを見ていて、おかしなことに気づいた。「GPTBot」という文字列を含む行の中に、User-Agentが「Scrapy」や「DataForSeoBot」、あるいは普通のブラウザを装った文字列のものが混ざっていた。中身を見ると、これらはGPTBotとして来ていたのではなく、/ai_ron/archives/tag/GPTBotという、当サイトが自分で付けたタグページを訪れていただけだった。

当サイトでは、AIクローラーについて書いた記事に「GPTBot」「ClaudeBot」というタグを付けている。そのタグ名がそのままURLの一部になる。「GPTBotという文字列を含む行を数える」という数え方は、User-Agentに「GPTBot」と書かれている行だけでなく、URLに「/tag/GPTBot」を含む行も、区別せずに拾ってしまっていた。

同じ落とし穴は、他のサイトにもありうる

当サイトは、AIクローラーについて解説する記事を書くたびに「GPTBot」「ClaudeBot」というタグを付けてきた。読者にとっては、同じクローラーを扱った記事をまとめて読めて便利な仕組みのはずだった。だがその便利さが、今回は自分自身の数え方を狂わせる原因になった。

同じことは、他のサイトでも起こりうる。特定の商品名・サービス名・技術用語を記事のタグやカテゴリ名として使っているサイトで、その名前がたまたま何かのクローラー名や検索クエリと重なっていれば、「その文字列を含む行を数える」という単純な集計は、同じ形で狂う。タグ名やカテゴリ名の一覧と、自分が数えようとしている固有名詞の一覧を、一度突き合わせておく価値がある。

User-Agentの列だけに絞って、もう一度数え直す

User-Agentの列だけに絞って数え直したところ、結果は変わった。CCBot・YouBot・Bytespider・OAI-SearchBotの4つは、136・60・38・2と、最初の数字のままだった。だがClaudeBotは102ではなく95、GPTBotにいたっては6ではなく0だった。GPTBotという名前のクローラーは、この52日間、当サイトに一度も来ていなかった。✅ 当サイト実施済 6種類すべてについて、User-Agentの列だけに絞った数え直しを行った。

正しく数え直した内訳を足すと、136+95+60+38+0+2＝331。最初にメモにあった「合計344」ではなく「合計331」の方が正しかった。数え直して合っていると安心した344の方が、実は間違った数え方の合計だった。

CCBotが最も多い理由

CCBotはCommon Crawlという非営利プロジェクトが運用するクローラーで、収集したページはインターネット上に公開データセットとして提供される。多くのAI企業が、モデルの学習に、Common Crawlのデータセットを直接、または加工した形で使っている。だから「ChatGPTやClaudeそのものが直接来ていなくても、Common Crawl経由で間接的に学習データに入る」経路がある。136回という回数は、この経路の存在を裏づけている。

ClaudeBotとGPTBotの、違いではなく別の話

最初は「ClaudeBot102回、GPTBot6回、どちらも学習データの収集目的だが差がある」という書き方をするつもりだった。だが正しい数字はClaudeBot95回、GPTBot0回であり、比べているのは「差の大きさ」ではなく「来ているか、来ていないか」という別の話になった。GPTBotがこの52日間で一度も来ていない理由は、今回のログだけからは分からない。robots.txtでの明示的な拒否は無かった（後述）ので、それだけが理由ではなさそうだ。

YouBotとBytespiderについて

YouBotはYou.comという検索エンジンのクローラーで、60回の訪問があった。Bytespiderは動画プラットフォームで知られるByteDance社のクローラーで、38回。どちらも国内での知名度は高くないが、実際のアクセス数としては、この52日間、GPTBotより多かった。「有名な企業のクローラーほど多く来る」わけではないことが、この52日間の数字からは見て取れる。

表で見る内訳の意味

331回という合計を見たとき、最初に浮かんだのは「思ったより多い」という感覚だった。だが1日あたりに割ると、331÷52＝約6.4回。1日に6〜7回、何らかのAIクローラーが訪れている計算になる。この数字を多いと見るか少ないと見るかは、比較対象がないと判断できない。次の節で、当サイトが同じ期間に受けた他のクローラーの数と並べる。

一度も来ていないクローラーが12種類あった

331回という数字と同じくらい、いや、それ以上に気になったのが、52日間で1回も来ていないAIクローラーの存在だった。GPTBotも、User-Agentの列だけに絞って数え直したことで、この仲間入りをした。今回、名前を確認した範囲で、次の12種類が0件だった。

User-Agent	一般的な役割	52日間の訪問
ChatGPT-User	ユーザーの質問に応じてページを取得（OpenAI）	0
Perplexity-User	同上（Perplexity）	0
Claude-User	同上（Anthropic）	0
Claude-SearchBot	検索インデックスの収集（Anthropic）	0
PerplexityBot	検索インデックスの収集（Perplexity）	0
anthropic-ai	学習データの収集（Anthropicの旧表記）	0
Google-Extended	AI学習への利用可否を伝える表記（Google）	0
Applebot-Extended	同上（Apple）	0
meta-externalagent	学習データの収集（Meta）	0
cohere-ai	学習データの収集（Cohere）	0
DuckAssistBot	AI要約機能のための取得（DuckDuckGo）	0
GPTBot	学習データの収集（OpenAI）	0

「引きに来る」種類のクローラーが特に目立つ

この11種類を見比べると、ある共通点に気づく。ChatGPT-User、Perplexity-User、Claude-Userの3つは、いずれも「ユーザーが質問したときに、その場でページを取りに行く」タイプの動きをする。人があるサービスに「このサイトの最新情報を教えて」と尋ねたとき、そのサービスが即座に当サイトへ取りに来る、という経路だ。この3つが揃って0件だった。

これは、当サイトの情報が「学習データとしては拾われているが、質問への回答を作る場面では、まだ選ばれて取りに来られていない」ことを示している可能性がある。ただし「可能性がある」までしか言えない。取りに来られない理由は複数考えられ、この記事のログだけでは絞り込めない。

学習用と検索用の違い

CCBot、ClaudeBot、Bytespiderのような「学習データの収集」を目的とするクローラーは、定期的に、能動的にサイトを巡回する。一方、ChatGPT-UserやClaude-Userのような「ユーザーの質問に応じて取りに行く」タイプは、誰かがそのサービスに質問し、そのサービスが当サイトの情報を使う価値があると判断したときにだけ動く。前者は「サイトの都合とは関係なく、定期的に来る」。後者は「誰かに選ばれたときだけ来る」。今回の結果は、前者は動いていて、後者はまだ一度も動いていない、という形になっている。

役割ごとに合計してみる

17種類のクローラーを、役割ごとに束ねて合計してみる。学習データの収集を目的とするもの（CCBot・ClaudeBot・Bytespider・GPTBot・anthropic-ai・meta-externalagent・cohere-ai）は合計269回。検索インデックスの収集を目的とするもの（YouBot・OAI-SearchBot・PerplexityBot・Claude-SearchBot）は合計62回。そして、ユーザーの質問に応じてその場で取りに行くもの（ChatGPT-User・Perplexity-User・Claude-User）と、AI学習への利用可否を伝えるだけの表記（Google-Extended・Applebot-Extended）、AI要約機能のための取得（DuckAssistBot）は、いずれも合計0回だった。

269＋62＝331で、全体の合計と一致する。この束ね方をすると、「学習データの収集」と「検索インデックスの収集」の2つの役割だけが動いていて、「ユーザーの質問に応じた取得」は52日間、一度も動いていないことが、より際立って見える。ただし、これは17種類という、こちらが把握できている範囲での束ね方でしかない。この分類に入っていない名前のクローラーが存在する可能性は残る。

来ていない理由は複数考えられる

0件の理由として考えられるものを、思いつく限り並べる。①そもそも当サイトの情報が、その質問に対する回答として選ばれていない。②robots.txtで、そのクローラーを許可していない。③サーバー側のアクセス制限（後述）に引っかかっている。④52日間という期間の中で、たまたまそのような質問が発生しなかった。どれか一つに絞る材料は、今回のログにはない。この点は、「わからないこと」の節でもう一度書く。

同じ期間で、人の流入を数えてみる

訪問回数を数えたら、次は「そこから人が来ているか」を数える番だ。同じ52日分のログから、Refererの値が空でない行を抜き出した。

指標	52日間の合計
AIクローラーの訪問（User-Agentで数えた）	331回
Refererに記録されたAIサービスのドメイン	0件
Refererが空でなかった行（全体）	391件
うち自サイト内からの遷移	372件（95.1%）
うち外部サイトからの遷移	19件

Refererが空でない行を数える

391件のうち、372件（95.1%）は自サイト内のページ間の移動だった。つまり、Refererに何か値が入っている行のほとんどは、「サイトの中を読み進めている読者」を表している。外部から流入してきた行は、残りの19件しかない。

19件の内訳

その19件を見ると、m.facebook.comが12件、m.baidu.comが4件、www.facebook.comが3件だった。いずれもFacebookまたはBaiduからの流入で、AIサービスのドメインは、この19件の中に1件も含まれていなかった。

さらに、その19件がどのページに着地したかも見た。Facebookからの15件は、すべてトップページ（fbclidという、Facebookが付けるトラッキング用のパラメータ付き）だった。一方、Baiduからの4件は、いずれも「www.meago.cn」「www.wpyc.cn」のような、当サイトとは無関係な中国語ドメインを検索した結果として、当サイトのトップページに着地していた。検索していた語と着地したページが一致しておらず、人間の検索行動としては不自然に見える。この4件は、実際の読者による訪問というより、何らかの自動アクセスである可能性がある。

つまり、19件のうち「人間による訪問らしい」と言えるのは、Facebook経由の15件までで、Baidu経由の4件は差し引いて考えた方がよいかもしれない。この判断も、断定はできない。あくまで「不自然に見える」というところまでしか言えない。

AIサービスのドメインは0件だった

chatgpt.com、perplexity.ai、claude.ai、gemini.google.com、copilot.microsoft.com——思いつく限りのAIサービスのドメイン文字列でReferer列を探したが、52日分、16,442行の中に、1件も見つからなかった。331回という訪問回数と、0件という流入回数は、同じログファイルの中に、隣り合って存在していた。

「読まれている」と「連れてこられている」は別の数字

ここまでの数字を並べると、こうなる。AIクローラーは52日間で331回、当サイトに来た。しかし、そのAIクローラーを使う人が、回答の中のリンクをたどって当サイトに来た形跡は、Refererを見る限り0件だった。

この2つは、別の数字として理解する必要がある。「AIに読まれている」ことは、「AIのユーザーが自分のサイトに来る」ことを保証しない。両方が揃って初めて、「AI経由の流入がある」と言える。今回のログは、片方だけが動いていて、もう片方が動いていない状態を、52日分という長さで示していた。

2つの数字を並べてみる意味

もし訪問回数だけを見ていたら、「331回も来ている、すごい」で終わっていたかもしれない。もしRefererだけを見ていたら、「AIからの流入が0件だから、対策は意味がない」と結論づけたかもしれない。どちらも、片方の数字だけを見た早合点だ。2つを並べて初めて、「読まれてはいるが、まだ引用されて人を連れてくる段階には届いていない」という、より正確な言い方ができる。

なぜこの差が生まれるのか

学習データとして収集されることと、ユーザーの質問に対する回答としてそのページの情報が使われ、さらにリンクとして提示されることの間には、いくつもの段階がある。収集される→学習データやインデックスに入る→ある質問に対して関連性が高いと判断される→回答の中で言及または引用される→読者がそのリンクをクリックする、という流れのどこかで止まっていれば、Refererの流入は生まれない。今回の数字だけでは、どの段階で止まっているかまでは分からない。

bingbot 3,003とGooglebot 30という比率について

AIクローラーだけでなく、比較のために従来型の検索エンジンのクローラーも同じ期間で数えた。単純に「Googlebot」という文字列を含む行を数えると41件になったが、AIクローラーのところで見つけた落とし穴（タグページの名前との重なり）を思い出し、User-Agentの列だけに絞って数え直した。結果、Googlebotの実際の訪問は30回だった。11件は、やはりタグページ「Googlebot」への、別のクローラーによるアクセスだった。bingbotの方は、UserAgentの列だけで数えても3,003回のままで、こちらには同じ混入は無かった。robots.txtへのアクセスは1,203件だった。

この比率をそのまま受け取らない

この結果を見て、「Bingの方がGoogleより100倍もクロールしている」と一般化するのは危険だ。archives/117で書いたように、同じ条件で測っていないものを並べて比較すると、実態とは違う結論を出してしまう。当サイトは規模の小さいサイトであり、Googlebotのクロール頻度は、サイトの更新頻度・被リンク・過去のクロール履歴など、当サイト固有の事情に強く左右される。

自分のサイト固有の事情を疑う

考えられる固有の事情として、①サイトの規模が小さく、Googleのクロール予算の配分が相対的に小さい、②Bingのクロール頻度の設定が、Googleと比べて元々高い傾向にある（一般に知られている挙動）、③直近の更新頻度や新規ページの追加ペースが、クロール頻度に影響している、などが考えられる。どれか一つに絞り込む材料は今回のログにはない。

他のサイトでも同じとは言えない

この記事を読んでいるあなたのサイトで、同じ比率が出るとは限らない。サイトの規模、業界、更新頻度、被リンクの状況によって、GooglebotとBingbotの比率は大きく変わる。「100倍だった」という数字は、当サイトの固有の事情の中で出た数字として受け取ってほしい。自分のサイトで同じ集計をして、自分の比率を出すことでしか、自分のサイトの実態は分からない。

全体に占める割合で見る

16,442行という全体のログ量に対して、AIクローラー331回は2.0%にあたる。bingbot（3,003回）とGooglebot（30回）を合わせた従来型の検索エンジンのクローラーは、合わせて3,033回、全体の18.4%。両方を足すと、全体の20.5%が、何らかのクローラーによるアクセスだったことになる。

archives/83で紹介した他社の調査では「ボットが世界の57%を占めた」という数字が出ていた。当サイトの20.5%は、その半分にも満たない。これは当サイトのボット対策が優れているという意味では必ずしもなく、集計対象・集計期間・サイトの規模が違う調査結果を、単純に比べられないことの表れでもある。自分のサイトの割合は、自分のログでしか出せない。

この数え方でわからないこと

ここまでの数字には、いくつかの限定がある。正直に書いておく。

Refererが付かない経路

ブラウザやアプリの設定によっては、Refererを送らない、または簡略化して送る場合がある。特に、スマートフォンのアプリ内ブラウザや、一部のプライバシー設定を有効にした環境では、Refererが空になることがある。もし誰かがAIサービスの回答画面から当サイトへ来ていても、Refererが送られていなければ、今回の数え方では検出できない。「0件だった」は「AI経由の訪問が本当に0だった」ではなく、「Refererに記録が残る形での訪問は0件だった」という意味だ。

サーバー側のアクセス制限の影響

当サイトは2026年8月7日から、サーバー側でアクセス元を日本国内に限定する設定を入れている。この設定の有無自体は、実際にサイトへアクセスすれば誰でも確認できることなので、ここに書く。この制限が、今回数えたAIクローラーの訪問回数にどう影響しているかは、今回のログからは分離できていない。日本国内のデータセンターを経由してアクセスしてくるクローラーもあれば、そうでないクローラーもある。8月7日より前と後で、クローラーごとの訪問回数がどう変わったかを比較すれば、この影響を切り分けられるはずだが、今回はそこまで手を伸ばしていない。📋 予告 次回は、8月7日を境にした前後の比較を行う。

robots.txtとの突き合わせ

あるクローラーが0件だったとき、それが「robots.txtで許可していないから来ていない」のか、「robots.txtは許可しているが、そもそも選ばれていない」のかは、robots.txtの記述を見れば、少なくとも一部は分かる。この記事を書きながら、当サイトのrobots.txtを開いて確認した。中身は「User-agent: *」に対する包括的な許可（Allow: /）と、管理画面など一部パスの除外だけで、ChatGPT-UserやPerplexityBotのような個別のクローラー名を名指しした記述は無かった。つまり、今回0件だった11種類は、少なくともrobots.txtで名指しにブロックされているわけではない。✅ 当サイト実施済 robots.txtの内容は、この記事の執筆時点で確認した。

ただし、これで「robots.txtは関係ない」と言い切れるわけではない。robots.txtの外側、たとえばサーバー側のアクセス制限や、ネットワーク経路の途中でのブロックは、robots.txtには現れない。ログに残る「0件」という結果と、robots.txtという1つの設定ファイルを突き合わせただけでは、まだ全体は分からない。🔧 これから サーバー側の制限ログとの突き合わせは、次の集計で行う。

ログはいつまでも残っているとは限らない

今回、当サイトのサーバーには、52日分のアクセスログがそのまま残っていた。だが、ログの保存期間はサーバーの設定次第で、多くの環境では一定期間を過ぎると自動的に削除される。「数えたいと思ったときには、もうログが無い」ということも起こりうる。今日この記事を読んで、自分のサイトでも数えてみようと思ったなら、保存期間が切れる前に、まず1回ダウンロードしておくことをすすめる。

サーバーログを扱えない場合の代わりの手段

レンタルサーバーによっては、アクセスログをそのままダウンロードできない環境もある。その場合でも、AIクローラーの動きを知る手段はいくつかある。CloudflareのようなCDN・WAFサービスを利用しているなら、管理画面のアナリティクス機能でボットの種類別トラフィックを確認できることが多い。Google Search Consoleの「クロールの統計情報」は、Googlebotの動きだけは教えてくれる（ただし他社のAIクローラーまでは扱っていない）。今回はサーバーログという、最も生に近いデータで数えたが、これは選べる方法のひとつであって、唯一の方法ではない。

この数字は、明日の仕事で何を変えるか

この記事の数字を読んで、明日から何を変えられるか。3つに分けて書く。

「AI対策をしている」を、感覚ではなく数字で言えるようにする

「AIクローラー対策は済んでいます」という報告と、「52日間でCCBotが136回、ClaudeBotが95回来ています。学習データの収集は動いています」という報告は、伝わる情報量が違う。前者は主観の表明で、後者は再現できる数字だ。同じ集計を1年後にもう一度行えば、増えたか減ったかを、また数字で言える。当サイトの規模であれば、この集計は1人で、1日あれば終わる作業だった。

クロールと流入は、別の指標として管理する

「AIクローラーが来ているから、AI経由の流入も増えているはずだ」という思い込みは、今回のログでは成立しなかった。クロール回数を追う指標と、Refererに残る流入を追う指標は、別のダッシュボードの別の行として扱った方がいい。片方が動いているからといって、もう片方が動いているとは限らない。

毎月の定点観測にする

52日間という長さは、たまたま今回そうなっただけで、決まった周期ではない。次は期間を揃えて、たとえば毎月1日に、直近30日分を同じ手順で数える、というように、定点観測の形にすることを考えている。archives/121で書いたように、大手メディアがGoogleのクロールを遮断するかどうかを検討するような大きな動きも起きている業界だ。今日の数字が、来月も同じとは限らない。

自分のサイトで今日から確かめられること

ここまでの内容を読んで、「自分のサイトでも数えてみたい」と思ったら、特別なツールを新しく用意する必要はない。多くのレンタルサーバーやクラウド環境では、アクセスログが標準で保存されている。まずは直近のログをダウンロードするところから始められる。

自分のログをダウンロードする

サーバーの管理画面、またはSSH接続で、アクセスログの保存場所を確認する。多くの環境で「access.log」またはそれに似た名前のファイルが、日付ごとに分かれて保存されている。まずは直近7日分だけでも手元に置いてみる。

User-Agentで仕分ける

ログの各行には、通常、リクエスト元のUser-Agentがそのまま記録されている。「CCBot」「ClaudeBot」「GPTBot」といった文字列が、そのUser-Agentの列に含まれているかどうかを数えれば、AIクローラーの訪問回数が分かる。表計算ソフトのフィルタ機能や検索機能でも十分にできる作業だ。

ただし、この記事の途中で当サイト自身がつまずいたように、「行全体」に対してその文字列を検索すると、User-Agent以外の場所（URLやタグ名など）にたまたま同じ文字列が含まれている行まで拾ってしまうことがある。列を分けてから数える、ひと手間が要る。

Refererで仕分ける

同じログの中で、Referer列（もしくはそれに相当する項目）の値を見る。値が空でなく、かつ自サイトのドメインでもない行を数えれば、外部からの流入の内訳が見える。その中にAIサービスのドメインが含まれていれば、AI経由の流入が実際に起きていることになる。

この作業は、当サイトが持つ🔧 WEBサイト総合分析・レポートツールのように専用のツールがなくても、表計算ソフトとログファイルさえあれば始められる。まずは1回、自分の手で数字を出してみることが、次の判断の材料になる。✅ 当サイト実施済 今回、当サイトはこの方法で52日分の訪問と流入を数え、この記事として公開した。

この記事を書きながら、数字が3回変わった

最後に、この記事の数字がどう変わっていったかを、時系列でまとめておく。

①最初に受け取ったメモには「合計331回」と書かれていたが、6種類の内訳を足すと344になり、内訳の方を信じて「合計344回」に直した。②その後、それぞれのクローラーがどのページに来ているかを調べていて、GPTBotとClaudeBotの数字に、当サイト自身のタグページへのアクセスが紛れ込んでいることに気づき、User-Agentの列だけに絞って数え直したところ、合計は331回に戻った。③さらに、比較用に数えていたGooglebotの数字（41回）にも同じ問題があると気づき、数え直して30回に修正した。

3回とも、直したきっかけは「もう一度、別の角度から数え直してみた」ことだった。1回目で満足していたら、この記事はGPTBotが6回来たことになっていたし、Googlebotとの比率も「73倍」という、誤った数字のまま公開されていた。

チェックリスト

• 自分のサーバーの、直近30日分のアクセスログをダウンロードする
• ログの中から「User-Agent」に相当する列を特定する
• 「CCBot」という文字列を含む行が何行あるかを数える
• 「ClaudeBot」という文字列を含む行が何行あるかを数える
• 「GPTBot」という文字列が、User-Agentの列に含まれている行が何行あるかを数える（URLなど他の列に同じ文字列が無いか確認する）
• 「ChatGPT-User」という文字列を含む行が何行あるかを数える
• 「Perplexity-User」という文字列を含む行が何行あるかを数える
• 「Claude-User」という文字列を含む行が何行あるかを数える
• ログの中から「Referer」に相当する列を特定する
• Refererが空でない行を数え、自サイト内と自サイト外に仕分ける
• Refererの値に「chatgpt.com」「perplexity.ai」「claude.ai」の文字列が含まれる行を数える
• 自分のサーバーが、国や地域でアクセスを制限しているかを、設定画面またはサーバーの管理者に確認する
• robots.txtを開いて、GPTBotやCCBotに対する個別の記述があるかを確認する
• 今回数えた結果を、日付とともに1枚のメモに残す
• 同じ集計を、1か月後にもう一度、同じ条件で実行する日を1つ決める

この記事は構造化データはAIに読まれているのか？ ── ChatGPTの実験結果と、それでもマークアップを続ける理由とあわせて読むと、「AIに読まれる」ことそのものについての理解が深まる。あちらは構造化データとAIの関係を扱っているが、今回は「読まれた後、人が来るかどうか」を扱っている。読まれることと、連れてこられることは、別の話として積み上げていく必要がある。

52日分のログを数えて分かったのは、AIクローラーは確かに来ている、ということだった。331回という数字は、当サイトの規模を考えれば少なくない。だが、そこから人が来ているかというと、少なくとも今回数えた形では、まだ0件だった。この2つの数字を分けて見ることを、当サイトはこれまでしていなかった。今回、初めて分けて数えた。次は、期間を空けてもう一度同じ条件で数え直し、この331回と0件が、どう変わるかを見る。それが、この記事の続きになる。🔧 リンク漏れ・チェックツールで当サイト内のリンク切れを確認しながら、この記事の内部リンクも、次回の集計のときにもう一度、実際に開いて確かめるつもりだ。

関連 archives（連載軸として読む）

• archives/135「『測定中』と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた」 ── 同じ52日分のログを、別の切り口（llms.txt・robots.txtへの到達数）で数えた回。今回の集計のきっかけになった
• archives/83「ボットが世界の57%を占めた日 — AIクローラー時代のアクセスログ、WEBディレクターが今知るべき数字」 ── 他社の調査を紹介した回。今回は自分のサイトの数字を初めて出した
• archives/86「Cloudflareのデフォルト『AI bots ブロック』があなたのGEOを殺している」 ── インフラ層でのAIクローラー遮断を扱った回
• archives/117「同じ条件で測っていなかった ── robots.txtは『24時間キャッシュ』のはずが、実測は1日13.9件と152.3件」 ── 条件が揃っていない数字を並べる危うさを扱った回
• archives/121「『守る側』が動けなくなった週 ── 大手メディアのGoogle遮断検討と、同じクローラーという壁」 ── クロールの扱いをめぐる業界の動きを扱った回

出典

• OpenAI Help Center: Publishers and developers FAQ
• Anthropic Help Center: Does Anthropic crawl data from the web, and how can site owners block the crawler?
• Perplexity Documentation: Crawlers
• Common Crawl: CCBot
• Bing Webmaster Help: Which crawlers does Bing use?
• Google Search Central: Overview of Google crawlers
• Dark Visitors: Bytespider
• Dark Visitors: YouBot