WEBサイト
先週、自社のアクセスログをdocs.you.comという文字列で検索したら、60件のヒットが出た。you.comは生成AIを組み込んだ検索サービスだ。「AIサービスから、当サイトに人が送られてきている」――そう読んで、一瞬うれしくなった。他の生成AIサービスのドメインでも同じように検索したところ、chatgpt.comもperplexity.aiもclaude.aiも0件だった。you.comだけが突出している。この差は何だろうと思い、60件の中身を1件ずつ確かめることにした。
結論を先に書く。60件は「AIサービスから送られてきた訪問」ではなかった。60件とも、AIクローラーが自分自身のアクセス許可ファイルを取得したり、当サイトのページを読みに来たりしたときに、自分の名前と一緒に自己紹介のリンクを書き添えていた、それだけだった。人がその60件の中に1件も含まれていない。うれしくなった数字は、AIが自分の名前を名乗った回数だった。
WEBディレクターにとって、アクセスログの数字は日々の判断材料になる。「AIサービスから流入があった」という事実は、そのまま社内の報告や、次の施策の根拠として使われる。今回のように、数字の中身を確かめずに使ってしまうと、間違った根拠の上に次の判断を積み重ねることになる。この記事では、その確認のやり方を、実際に手を動かした手順のまま書く。
「行全体を検索する」というやり方自体は、間違ってはいない。むしろ、まず何が起きているかを大まかにつかむための、正しい第一歩だ。問題は、その結果をそのまま「AIサービスからの流入60件」のような具体的な出来事として扱ってしまうところにある。行全体の検索は「その文字列が、ログのどこかに現れた」ことしか教えてくれない。どこに現れたかまでは教えてくれない。この記事は、その「どこに」を確かめる話だ。
「AIから60件、来ている」と最初は読んだ
アクセスログの1行は、ダブルクォートで区切られたいくつもの項目が並んでできている。接続元のアドレス・日時とリクエストされたページ・応答コード・そして今回問題になった「紹介元」と「訪問者の名前」だ。この2つは意味がまったく違う。紹介元は「どのページのリンクをクリックして、ここに来たか」を記録する項目で、訪問者の名前は「今アクセスしているブラウザやプログラムが、自分を何と名乗っているか」を記録する項目だ。
この2つを区別せず、ログの1行をまるごと文字列として検索すると、「紹介元にあるドメイン名」と「訪問者の名前の中に書かれた文字列」が同じ結果の中に混ざる。行全体を検索した60件は、この混ざり方の典型例だった。
アクセスログの1行には、意味が違う複数の項目が並んでいる
1行を実際に開いて、項目を数える
当サイトの本番サーバーに残っている記録を、2026年7月8日から2026年8月29日までの53ファイル・16,442行、すべて開いた。1行をダブルクォートで区切ると、どの行も同じ数の項目に分かれる。先頭から順に並べると、次のようになる。
- ①接続元のアドレスと、記録上の識別番号
- ②アクセスがあった日時と、リクエストされたページの内容（メソッド・URL・プロトコル）
- ③応答コードと応答サイズ
- ④紹介元
- ⑤訪問者の名前
この並びは自社のログ設定に固有のもので、他社のサーバーでは項目の数や並び順が違うことがある。だから「何番目が紹介元か」は、記事を読んだ人が自分のログで実際に確かめる必要がある。
紹介元と訪問者の名前は、正反対の情報を記録している
紹介元は、ブラウザが「今から開くページの前に、どのページを見ていたか」を送ってくる項目だ。リンクをクリックしたときだけ入り、URLを直接入力したときや、プログラムが機械的にアクセスしたときは空になることが多い。訪問者の名前は逆に、アクセスしてきた側が「自分はこういうソフトウェアです」と名乗る項目だ。この項目は、ブラウザが自分自身を名乗るためにも使われるし、AIクローラーが自分自身を名乗るためにも使われる。同じ項目の中に、まったく違う立場のものが同居している。
紹介元は「誰が、こちらに送ってきたか」を示す。訪問者の名前は「誰が、こちらに来たか」を示す。これは正反対の情報だ。前者はサイトの外にいる誰かの行動を記録し、後者はサイトに来た本人の申告を記録する。1行全体をひとつの文字列として検索すると、この正反対の2つが区別なく同じ結果に入り込む。
紹介元には、もう1つ注意すべき点がある。ブラウザには、紹介元を送るかどうかを制御する仕組みがあり、ページ側の指定や、閲覧者のブラウザ設定によっては、実際にリンクをクリックして来た場合でも紹介元が空になることがある。つまり紹介元が空である行の中には、「機械的なアクセス」だけでなく、「人がリンクをクリックしたが、紹介元を送らない設定だった」という行も混ざっている可能性がある。今回の記事は、この2つを区別せず、「紹介元の項目に何が記録されているか」だけを対象にしている。
you.comからの60件を、実物を見て確かめた
実物の1行を見る
60件のうち、最初の1件を開いた。
0.0.0.0 - - - [25/Jul/2026:12:36:33 +0900] "GET /robots.txt HTTP/1.1" 200 179 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; YouBot/1.0; +https://docs.you.com/youbot; env:prod) Chrome/142.0.0.0 Safari/537.36" -
（アクセス元のアドレスは伏せてある）
紹介元にあたる項目は「-」、つまり空だ。docs.you.comという文字列は、訪問者の名前の項目の中に、「YouBot/1.0; +https://docs.you.com/youbot」という形で書かれている。これは「このソフトウェアの説明はこちらのページにあります」という、AIクローラー側の自己申告だ。you.com経由でリンクを踏んで来た人の記録ではない。次に開いた1件も、その次も、同じ形だった。
docs.you.comは、リンクで送られてきた住所ではなかった
60件を全部開いて、紹介元の項目を確認した。60件とも空だった。訪問者の名前の項目には、YouBotという同じ名前と、同じ自己紹介のURLが並んでいた。you.comの検索結果に当サイトのページが表示され、それを人がクリックして来たのであれば、紹介元にはyou.comのドメインが入るはずだ。今回の60件には、その形の行が1件もなかった。
60件の日付を確認すると、7月25日・26日・27日・8月5日の4日間に集中しており、53日間の残り49日には1件も現れていない。接続元のアドレスは15種類あり、1つのアドレスから連続で叩かれた形跡ではなく、複数のアドレスから、時期をおいて訪問している。リクエストされたページも/robots.txtが29件と最も多く、残りは当サイトが公開している無料ツールのページなどに散らばっていた。これは、いわゆる巡回として自然な動き方であり、特定の1回の異常なアクセスではない。断続的に、しかし確かに、YouBotは当サイトを巡回している。ただしそれは「紹介元として人を送ってきた」動きではなく、「訪問者として自分で読みに来た」動きだった。
docs.you.comという文字列は、たしかにログの中に60回現れる。だがそれは「you.comから送られてきた60人」ではなく、「YouBotという名前のクローラーが、自分の説明書のURLを書き添えて、複数回にわたって訪れた記録」だった。同じ文字列が、行の中のどこに書かれているかによって、まったく違う出来事を指している。
フィールドを特定して、AIサービスのドメインを数え直す
引用符で区切って、項目ごとに分ける
目視での確認を、全部のログに対して機械的に確かめ直した。使ったのは、行を引用符で区切って項目ごとに取り出す、以下のような形の集計だ。
zcat -f access.log* | awk -F'"' '{ referer=$(NF-3) } index(referer,"対象のドメイン")>0 { n++ } END { print n+0 }'
この形にすると、行を引用符で区切ったうえで、紹介元にあたる項目だけを取り出して検索できる。同じ検索を、行全体に対しても行い、2つの件数を突き合わせた。
この区切り方には、ひとつ弱点がある。訪問者の名前や紹介元の中身そのものに引用符が含まれていた場合、区切る位置がずれる可能性がある。今回のログでは、そうしたずれが起きていないかを、行ごとの区切り数を数えて確かめた。53日間・16,442行のほぼすべてが同じ数の項目に分かれており、極端に少ない、あるいは多い項目数になっている行はなかった。区切り方そのものが崩れていない、という前提のうえで、今回の集計を進めている。
紹介元の欄には、AIサービスのドメインが1件もなかった
主な生成AIサービスのドメイン名を6つ選び、それぞれについて「行全体で検索した件数」と「紹介元の項目だけで検索した件数」を並べた。
| 対象のドメイン | 行全体で探した件数 | 紹介元の欄だけで数えた件数 |
|---|---|---|
| you.com | 60 | 0 |
| chatgpt.com | 0 | 0 |
| perplexity.ai | 0 | 0 |
| claude.ai | 0 | 0 |
| gemini.google.com | 0 | 0 |
| openai.com | 0 | 0 |
行全体で探すと60件だったyou.comは、紹介元の項目だけに絞ると0件になる。他の5つのドメインは、どちらの数え方でも0件のままだった。つまり53日間・16,442行の中に、生成AIサービスのページから、リンクをたどって当サイトに来た記録が、1件も残っていなかった。
検索の条件が広すぎて何でも拾ってしまっている可能性を確かめるため、その場で作った実在しない文字列でも同じ検索を試した。結果は0件だった。検索の条件は、AIサービスのドメインという狙った文字列だけを正しく拾い、それ以外は拾っていない。
本当の紹介元391件は、どこから来ていたか
95.1%が自分のサイトからだった
紹介元の項目が空でなかった行を、あらためて全部数えた。53日間で391件あった。この391件の中身を、ドメインごとに分けて集計した。
391件のうち372件、95.1%は当サイトの別のページからだった。読者がひとつの記事を読んだあと、別の記事やトップページに移動したときに記録されたものだ。外部からの紹介元は19件しかない。その内訳はFacebookが15件（モバイル版12件・パソコン版3件）、百度（Baidu）が4件だった。百度からの4件は、いずれも当サイトのトップページに向かっている。中国語圏の検索結果に、当サイトのトップページが何らかの形で表示されている可能性はあるが、今回はそこまで追っていない。生成AIサービスからの紹介元は、この19件の中にも0件だった。
全16,442行のうち、紹介元が記録されているのはわずか2.4%
391件という数字を、53日間の全行数16,442行と比べておく。391÷16,442は2.4%だ。残りの97.6%の行は、紹介元が空になっている。空である理由はひとつではない。プログラムが機械的にアクセスした場合はもちろん、人がブックマークからアクセスした場合や、URLを直接入力した場合、あるいはブラウザの設定で紹介元を送らないようにしている場合も、同じように空になる。だから「紹介元が空＝ボットのアクセス」と単純に読むことはできない。それでも、当サイトのログの大部分が、紹介元という手がかりを持たない行で占められているという事実は、archives/83で紹介した「ボットが世界の57.5%を占めた」という業界の数字を、当サイト自身の内訳として裏から支えている。
外部からの19件は、想像していたより少なかった
53日間で外部からの紹介元がわずか19件というのは、正直に書くと寂しい数字だ。1日あたり0.36件しかない計算になる。だが今回の記事の主題はここではない。「AIサービスからの紹介元が何件あるべきか」ではなく、「AIサービスからの紹介元だと思っていた数字が、本当にその意味を持っていたか」を確かめることが目的だった。答えは、持っていなかった、だ。
訪問者の名前で数えたクローラーの訪問
紹介元の話はここで一区切りとする。ここからは項目を変えて、訪問者の名前という、もう1つの項目に焦点を移す。紹介元が「送られてきたか」を示すのに対し、訪問者の名前は「来ているか」を示す。AIクローラーが当サイトを実際に読みに来ているかどうかは、こちらの項目でしか確かめられない。
主なAIクローラーを、名前ごとに数える
紹介元とは別の話として、訪問者の名前の項目だけを使い、AIクローラーが実際に当サイトを読みに来ているかを数えた。主要なクローラーの名前を17種類用意し、それぞれ何回訪問しているかを集計した。使ったコマンドは、取り出す項目を紹介元から訪問者の名前に変えただけで、形はさきほどと同じだ。
zcat -f access.log* | awk -F'"' '{ ua=$(NF-1) } index(ua,"対象のクローラー名")>0 { n++ } END { print n+0 }'
紹介元の項目が「$(NF-3)」だったのに対し、訪問者の名前は「$(NF-1)」だ。同じ行の中で、取り出す位置が2つずれている。この2つの間には、応答コードや応答サイズにあたる項目が挟まっている。位置を間違えると、まったく別の項目を検索することになる。実際に使う前に、実物の1行を目で見て、どの位置が何を意味しているかを確かめることが欠かせない。
| クローラーの名前 | 53日間の訪問回数 | 備考 |
|---|---|---|
| CCBot | 136 | Common Crawlの収集用。多くのAI企業が学習データの元として利用している |
| ClaudeBot | 95 | 下の章で数え直した値 |
| YouBot | 60 | 今回の発端になったクローラー |
| Bytespider | 38 | ByteDance社の収集用 |
| OAI-SearchBot | 2 | OpenAIの検索結果表示用。学習用のGPTBotとは別のクローラー |
| GPTBot | 0 | 下の章で数え直した値 |
| ChatGPT-User | 0 | 対話中にユーザーが開いたページを読みに来る形 |
| PerplexityBot | 0 | |
| Perplexity-User | 0 | |
| Claude-User | 0 | 対話中にユーザーが開いたページを読みに来る形 |
| Claude-SearchBot | 0 | |
| anthropic-ai | 0 | |
| Google-Extended | 0 | Google製のAIサービス学習用の名乗り |
| Applebot-Extended | 0 | |
| meta-externalagent | 0 | |
| cohere-ai | 0 | |
| DuckAssistBot | 0 |
来ているクローラーと、来ていないクローラーが、はっきり分かれる
17種類のうち、53日間で1回でも訪問があったのは6種類だけだった。CCBot・ClaudeBot・YouBot・Bytespider・GPTBot・OAI-SearchBotの6つを合わせると331回になる。全16,442行に対して331行は2.0%であり、上で見た紹介元391件の2.4%とほぼ同じ規模だ。「クローラーが訪問者として名乗っている行」と「紹介元が記録されている行」は、意味も中身もまったく別物だが、全体に占める割合はどちらも数パーセントにとどまり、大部分の1行はどちらの手がかりも持たない。残り11種類は、53日間で1回も名乗っていない。ChatGPT-UserやClaude-Userのように「対話の中でユーザーが開いたページを読みに来る」形のクローラーが0件だったことは、紹介元の欄が0件だったことと合わせて読むと、対話から当サイトへの経路が、今回の期間ではまったく発生していなかったことを示している。
331回の訪問を月ごとに分けると、7月が183回、8月が148回だった。紹介元391件も、月ごとに分けると7月が234件、8月が157件で、どちらも7月と8月の間で極端な偏りはない。特定の1日や1週間に集中した動きではなく、53日間を通してほぼ同じ調子で続いている。今回の結果が、たまたまその日だけ起きた例外ではないことの裏付けになる。
OAI-SearchBotとGPTBotの違いにも触れておく。OpenAIは、AIの学習データを集めるクローラーと、検索結果にページを表示するためのクローラーを、名前を分けて運用している。今回GPTBotが0件、OAI-SearchBotが2件だったことは、「学習のための巡回」と「検索結果に載せるための巡回」が別の頻度で動いていることを示している可能性がある。ただしこれも2件という少ない数からの推測であり、断定はできない。
数え直したら、もう2つ数字が動いた ── GPTBotとClaudeBotの正体
自社ブログにある「GPTBot」という名前のページ
上の表のGPTBotとClaudeBotには「下の章で数え直した値」と書いた。ここに、今回いちばん厄介な混ざり方があった。GPTBotという文字列で行全体を検索すると6件ヒットする。だが訪問者の名前の項目だけで検索すると0件になる。ClaudeBotも同様に、行全体では102件、訪問者の名前だけでは95件と、7件の差が出る。
差の正体を確かめるため、行全体では拾われたのに訪問者の名前では拾われなかった行を、1件ずつ書き出した。すると、リクエストされたページがすべて同じ形をしていた。
0.0.0.0 - - - [14/Jul/2026:01:30:16 +0900] "GET /ai_ron/archives/tag/GPTBot HTTP/1.1" 200 7912 "-" "Mozilla/5.0 (compatible; DataForSeoBot/1.0; +https://dataforseo.com/dataforseo-bot)" -
（アクセス元のアドレスは伏せてある）
リクエストされているのは/ai_ron/archives/tag/GPTBotというページだ。当サイトはブログ記事にタグを付けており、過去にGPTBotについて書いた記事にも「GPTBot」というタグが付いている。そのタグの一覧ページのURLに、GPTBotという文字列がそのまま含まれている。訪問者の名前を見ると、DataForSeoBotという、まったく別の巡回ツールだった。
そのページを、別のクローラーが読みに来ていた
GPTBotタグページへの6件のアクセス元を全部書き出すと、DataForSeoBot・Scrapy・jscrawler・bingbot、それに一般的なブラウザを名乗る2件だった。GPTBotという名前を持つクローラー自身が、このページに来た記録は1件もない。ClaudeBotタグページの7件も同じ顔ぶれで、jscrawlerやbingbot、Scrapy、DataForSeoBot、一般的なブラウザを名乗るものが訪れていた。
これは当サイトが用意した仕組みが原因だ。過去の記事に技術的な用語をタグとして付ける運用をしており、その中に「GPTBot」「ClaudeBot」という、クローラー自身の名前と同じ文字列が含まれるタグが存在した。そのタグページのURLを、行全体で検索すると、リクエストされたページの部分に含まれる文字列まで拾ってしまう。訪問者の名前の項目だけに絞れば、この混同は起きない。
タグそのものは、読者が過去の記事をたどるための、ごく普通の仕組みだ。GPTBotやClaudeBotについて書いた記事に、その名前のタグを付けるのは自然な運用であり、タグを付けたこと自体は間違っていない。問題は、そのタグページのURLと、確かめたいクローラーの名前が、たまたま同じ文字列を共有してしまったことにある。自社サイトの構造と、外部のクローラーの名前は、本来まったく別の管理下にある。それが1本のログの中では、区別なく並んでしまう。
Googlebotでも、同じ形が3件目として見つかった
この混同がGPTBotとClaudeBotに限った話ではないことを確かめるため、当サイトのタグ一覧をあらためて洗い出した。すると「Googlebot」「ChatGPT」「Bot」「BotBase」「Search」「SearchConsole」「robots.txt」といった、クローラーの名前や、それに似た文字列を含むタグページが他にも見つかった。試しにGooglebotで同じ検索を行うと、行全体では41件、訪問者の名前だけでは30件で、差は11件だった。/ai_ron/archives/tag/Googlebotというページへのアクセスが、その11件の正体だった。
| 対象 | 行全体 | 訪問者欄だけ | 差の正体 |
|---|---|---|---|
| GPTBot | 6 | 0 | タグページを読みに来た別のクローラー6件 |
| ClaudeBot | 102 | 95 | タグページを読みに来た別のクローラー7件 |
| Googlebot | 41 | 30 | タグページを読みに来た別のクローラー11件 |
3つとも、当サイトが自分で作ったタグページの名前が、クローラーの名前と偶然一致していたことが原因だった。CCBot・YouBot・Bytespider・OAI-SearchBotの4つについても同じ確認を行ったが、こちらは同名のタグページが存在せず、行全体と訪問者の名前で件数の差は出なかった。差が出るかどうかは、クローラーの名前そのものではなく、自社サイトの中に同じ文字列を含むページがあるかどうかで決まっていた。
タグ一覧を洗い出した際には、「ChatGPT」「Bot」「BotBase」「Search」「SearchConsole」「robots.txt」というタグページの存在も確認できた。今回はGPTBot・ClaudeBot・Googlebotの3件で実際に差が出ることを確かめたが、他のタグ名についても同じ形の混同が起きていないか、まだ全部は確かめきれていない。🔧 当サイト着手中 洗い出した一覧をもとに、残りのタグ名についても同じ確認を進める。
紹介元と訪問者の名前という2つの項目の混同が、1つ目の見落としだった。リクエストされたページのURLと訪問者の名前という、もう1つの混同が、2つ目の見落としだった。同じ「行全体を検索する」というやり方が、性質の違う2種類の見落としを、両方とも生んでいた。
同じ1行の中に、意味の違う項目が3つ混ざっていた
URLパス・紹介元・訪問者の名前
ここまでで、1行のログの中に、意味の違う3つの項目が確認できた。リクエストされたページのURL、紹介元、訪問者の名前だ。URLは「こちらのサイトの、どのページが読まれたか」を示し、当サイト自身が決めた文字列が入る。紹介元は「外部の、どのページから送られてきたか」を示す。訪問者の名前は「アクセスしてきた側が、自分を何と名乗っているか」を示す。3つとも別のことを記録しているのに、行を1本の文字列として検索すると、この3つが区別なく同じ結果に混ざる。
固有名詞で探すと、どこかに引っかかる
ドメイン名やクローラーの名前のような固有名詞は、この3つの項目のどこにでも現れうる。紹介元に現れれば「送ってきた側」の記録、訪問者の名前に現れれば「来た側」の申告、URLに現れれば「自社が公開しているページの名前」だ。同じ文字列でも、それがどの項目に書かれているかによって、指している出来事がまったく違う。今回の記事では、you.comで1種類、GPTBot・ClaudeBot・Googlebotで3種類、計2つの形の混同が、同じ「行全体を検索する」というやり方から生まれていた。自社サイトが技術的な話題を扱うほど、この2つ目の形の混同は起きやすくなる。当サイトのようにクローラーそのものを記事のテーマにしているサイトは、特に注意が必要だ。
2つの見落としは、原因がまったく違う。1つ目のyou.comの件は、AIクローラーが自分の名前を名乗るときに、自己紹介のURLを一緒に書き添えるという、AIクローラー側の実装から生まれた。2つ目のGPTBot・ClaudeBot・Googlebotの件は、当サイト自身がクローラーの名前をタグとして使ったという、こちら側の運用から生まれた。原因は違うのに、結果として起きたことは同じだった。「行全体を1本の文字列として検索する」という、いちばん手軽な確認方法が、性質の違う2つの見落としを、両方とも通してしまっていた。
業界全体の数字と、自分のログの数字は、違う位置にいる
ここまでは当サイト1つのログを対象にしてきた。ここからは、その数字を、業界全体で発表されている数字と並べて読む。並べる目的は、当サイトの数字が「正しかった」と裏付けることではない。向きが同じか、逆かを確かめることだ。
archives/83で書いた「ボットが57.5%」との関係
archives/83で、Cloudflareが2026年6月に発表した「HTMLページへのリクエストのうち57.5%がボットによるもの」という数字を紹介した。同じ記事では、Cloudflareが2025年7月に計測したクロール対参照比率――「1件の参照流入を発生させるために、そのボットが何ページをクロールしたか」――も紹介している。ClaudeBotは38,065ページをクロールして、ようやく1件の参照流入だった。
今回の当サイトの数字は、この業界全体の傾向と矛盾していない。ClaudeBotは53日間で95回（訪問者の名前で数え直した値）訪問しているのに対し、紹介元としてのAIサービスは0件だった。53日という短い期間・1サイトという小さい規模では、業界平均の比率をそのまま検証することはできない。だが「クローラーは来ているのに、そこから人が送られてきた記録がない」という向きは、archives/83で紹介した業界の数字と、同じ方向を指している。
「クロールは多いのに紹介は少ない」は、AIサービスに限らない
今回の表を見直すと、CCBotやBytespiderのように、検索エンジンやAI企業の学習データ収集を目的とするクローラーも、紹介元としては当サイトのログに1件も現れていない。これはクローラーの性質として自然なことだ。学習データを集めるための巡回と、人をサイトに送り届ける役割は、そもそも別の仕組みで動いている。今回の記事で確かめられたのは「AIサービスからの紹介元が少ない」という珍しい話ではなく、「クロールの記録と紹介の記録は、別の項目に、別の意味で記録されている」という、ログの構造そのものだった。
「AI経由の流入」という言い方は、社内の会話でもよく使われる。だがこの言い方自体が、複数の別々の出来事をひとまとめにしている。生成AIサービスの検索結果からのクリック、対話画面からユーザーが開いたリンク、AIクローラーの学習データ収集、生成AIの回答本文への引用――これらは起きる場所も、記録される項目も、すべて別だ。今回の記事で確かめられたのは、このうちの一部、「紹介元として記録される経路」と「訪問者として名乗る経路」の2つだけだ。「AI経由の流入が0件だった」とひとまとめにして報告すると、この違いが消えてしまう。
Search Consoleでも見えない経路がある
ここまでの数字はアクセスログだけを見て確かめたものだ。だが読者の中には「Search Consoleでも確認できるのでは」と思う人もいるだろう。結論から書くと、Search Consoleは検索エンジン経由の数字を示すもので、生成AIサービスの対話画面から直接訪問した経路は、そもそも計測の対象に入っていない。今回のようにアクセスログを自分で確かめる作業が必要になるのは、このためだ。
archives/125で書いた「表示回数までしか出ない」
archives/125で、Googleが提供する生成AIパフォーマンスレポートについて、「表示回数」までは分かるが、その先の実際のクリックや訪問については別の指標が必要だと書いた。今回のアクセスログの読み方も同じ限界を持つ。紹介元の項目が記録されるのは、ブラウザが紹介元情報を送ってきた場合に限られる。アプリ内のブラウザや、紹介元を送らない設定になっているブラウザ、あるいはリンクを経由せず直接URLを入力した場合は、紹介元が空になる。生成AIサービスの中には、こうした事情で紹介元を送らない実装のものがあるかもしれない。今回の記事で言えるのは「このアクセスログの紹介元には、AIサービスのドメインが1件もなかった」までであり、「AIサービス経由の訪問が、当サイトに1件もない」とまでは言い切れない。
当サイトは現時点で、生成AIサービスの入口にあたるリンクにUTMパラメータのような、別の測定手段を付けていない。🔧 当サイト着手中 紹介元だけに頼らない測定手段を用意することは、まだできていない。今回の記事で「AIサービスからの流入は0件だった」ではなく「紹介元の欄には0件だった」と書き分けているのは、この限界があるためだ。
1サイトの結果は、仮説にとどまる
archives/116で、当サイトとは別に運営している8言語サイトでも同じようにllms.txtへのアクセスを調べ、「1サイトの実測は仮説、2サイトの一致は事実」と書いた。今回の記事も、当サイト1つの、53日間という期間の結果にとどまる。同じ確認を別のサイトで行ったとき、生成AIサービスからの紹介元がやはり0件になるのか、それとも当サイトとは違う結果が出るのかは、まだ確かめていない。今回の数字は「当サイトでは、このように見えた」という報告であり、「生成AIサービスからの流入は一般に少ない」という一般化された主張ではない。
archives/134で書いた内部リンクの見落としと、同じ形
archives/134で、自社ブログの内部リンクのうち59.2%が、実際にはnoindexのページに飛んでいたと書いた。「200が返ること」と「実際に役に立っているか」は別だ、という指摘だった。今回の記事は、その外側にある話だ。「文字列が見つかること」と「その文字列が、探していた出来事を指しているか」は別だった。調べる対象は変わっても、見落とし方の形は同じだった。
読者が今日、自分のログでできること
今回の確認は、特別な計測ツールを必要としない。自社のアクセスログが手元にあれば、今日から同じことができる。✅ 当サイト実施済 今回の確認は本記事の作成時点ですでに完了している。チェックリストは2段階に分けた。前半は今すぐ手元のログを1件確かめるだけの内容で、後半は自社サイトの構造にまで踏み込んで確認する内容だ。前半だけでも、「行全体で検索した数字」を鵜呑みにする習慣は変えられる。
まず5分でできること
- 自社のアクセスログを1行開き、ダブルクォートで区切られた項目がいくつ並んでいるか数える
- そのうち「紹介元」にあたる項目が何番目か、実際の1行を見て特定する
- 「訪問者の名前」にあたる項目が何番目か、同じ行の中で特定する
- 気になる生成AIサービスのドメイン名で、ログの行全体を検索して件数を数える
- 同じドメイン名を、紹介元の項目だけに絞って、もう一度数える
- 2つの件数を並べて、差があるかどうかを確認する
継続してやるなら
- 自社ブログのタグ名やカテゴリ名の中に、クローラーの名前と同じ文字列が使われていないか、サイト内検索で探す
- 該当するページが見つかったら、そのページへのアクセスを、行全体で数えた件数から除いて数え直す
- 訪問者の名前の項目だけを使い、主要な生成AIクローラーの名前を1つずつ数える
- 検索エンジン向けのクローラーと、生成AIサービス向けのクローラーを、別の一覧として記録する
- 紹介元の項目が空でない行だけを抜き出し、外部のドメインを一覧にする
- その一覧の中に、生成AIサービスのドメインが混ざっていないかを確認する
- 当サイトが公開している「🔧 WEBサイトの状況チェック・比較ツール」で、前回測ったときとの差分を確認する
- あわせて「🔧 Google Search Console お助けツール」で、検索エンジン経由の数字も同じ期間で並べて確認する
14項目のうち、時間がかかるのは13番目だけだ。それ以外は、この記事を読み終えた5分後にでも始められる。今回の記事で見つかった見落としは、どちらも「行全体を1本の文字列として検索する」という、いちばん手軽なやり方から生まれていた。手軽なやり方を否定する必要はない。ただ、その結果を「AIサービスからの訪問」のような具体的な出来事の証拠として使う前に、どの項目から出た数字なのかを、もう一度確かめる価値がある。
📋 予告 今回は53日間・1サイトの記録で確認した。次は期間を延ばし、生成AIサービスからの紹介元がまったく現れないままなのか、それとも稀に現れるのかを、あらためて数え直す。あわせて、UTMパラメータのような別の測定手段を、当サイトの入口の一部に試験的に導入できないかも検討する。
今回の記事は「クローラーが来ているか」「紹介元として送ってきているか」を、自社のアクセスログから確かめる話だった。もう一歩先に進んで「実際にAIの回答の中で、自社のページが引用されているか」を確かめたい場合は、アクセスログとは別の確認手順が必要になる。AI検索サービスがどのようにWEBページを引用しているか、その仕組み自体についてはGoogleのAI Modeに「優先ソース」バッジ ── 自分のサイトが選ばれているかを、今日確認するで、確認できる手順を公式情報つきに整理している。あわせて確認してほしい。
この記事自体も、いずれ同じ形で見落とされる側になりうる。「AIサービスからの訪問は0件だった」という結論だけを覚えて、そこから先を確かめなくなるなら、それは今回指摘した見落としと同じ構造だ。だからこの記事では、結論よりも先に、確かめ方の手順を残した。数字は53日たてば古くなる。手順は、次に自分のログを開くときにも、そのまま使える。
次の確認は2026年10月中に行い、その回にはこの記事番号と、今日出した数字を並べて突き合わせる。
関連 archives（連載軸として読む）
- archives/83「ボットが世界の57%を占めた日 — AIクローラー時代のアクセスログ、WEBディレクターが今知るべき数字」 ── 業界全体のボット比率と、クロール対参照比率を紹介した回
- archives/125「Googleが見せたのは表示回数までだった ── 生成AIパフォーマンスレポートの『半分』と、自分で測る指標が止まっていた93日」 ── Search Consoleだけでは見えない経路について書いた回
- archives/134「『リンク切れ0本』を確認して、安心しかけた ── 自社ブログの内部リンク、59.2%はnoindexへの飛び先だった」 ── 「見つかること」と「役に立っていること」は別だと書いた回
- archives/135「『測定中』と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた」 ── 同じアクセスログを、別の対象で開いた回
- archives/86「Cloudflareのデフォルト『AI bots ブロック』があなたのGEOを殺している — robots.txt無関係のインフラ層ブロックと、WEBディレクターが今すぐ確認すべき3つの設定」 ── AIクローラーの巡回そのものを扱った回
