WEBサイト
Googleは公式に「robots.txtは最大24時間キャッシュする」と書いている。ならば、AIクローラーがrobots.txtを取りに来る頻度は、サイトの規模や内容に関わらず、おおむね一定の帯に収まるはずだ――archives/116で、当サイトは2サイトの実測をもとにそう主張した。3サイト目のデータが届いて、その主張は崩れた。その訂正は本日、archives/116に追記した。だが同じ日のうちに、もう一段、事態が動いた。分母が測られ、測り方そのものが3人とも違っていたことが分かった。今日はその顛末を、言い訳なしで書く。
公式は「24時間キャッシュ」と書いている。実測は1日13.9件と152.3件だった
Googleの公式ドキュメントは、robots.txtの取得についてこう書いている。
"Google generally caches the contents of robots.txt file for up to 24 hours, but may cache it longer in situations where refreshing the cached version isn't possible (for example, due to timeouts or 5xx errors)."
（日本語訳: Google は通常 robots.txt ファイルの内容を最大 24 時間キャッシュするが、キャッシュの更新ができない状況（タイムアウトや 5xx エラーなど）ではより長くキャッシュすることがある。）
別のページでは、更新の仕組みについてこう補足している。
"During the automatic crawling process, Google's crawlers notice changes you made to your robots.txt file and update the cached version every 24 hours."
（日本語訳: 自動クロールの過程で、Google のクローラーは robots.txt ファイルへの変更に気づき、キャッシュされたバージョンを 24 時間ごとに更新する。）
「24時間ごと」という言葉だけを読むと、robots.txtへのアクセスは1日1回で足りるはずに思える。当サイトがarchives/115で行った51日間のサーバーログ全数調査の枠組みをもとに、2026年7月30日時点で測り直すと、ClaudeBotによるrobots.txt取得は1日あたり13.9件だった。そして今日、あらためて実測に加わったTAP the POPでは、同じ51日間で1日あたり152.3件。どちらも「1日1回」とは一致しない。この時点でも既に、公式の言葉から素朴に想像する頻度とは違う数字が出ている。だが今日書きたいのは、この差そのものではない。この差を「サイト間で比較していいものかどうか」という、もっと手前の話だ。
前日、当サイトは「2サイトで一致したから事実だ」と書いた
website.usersupports.comとmembo.infoの2サイトを見ると、当初の実測ではrobots.txtの取得頻度が近い数字に見えた。両サイトはページ数もコンテンツの性質も違う（当サイトは単言語のブログ主体、membo.infoは8言語対応のプラットフォーム）。それでも1日あたりの取得回数が近い帯に収まっているように見えたことから、当サイトはarchives/116でひとつの仮説を記事にした。
「ClaudeBotのrobots.txt巡回は、サイトの内容やページ数と無関係に、固定に近いスケジュールで動いている」という主張だ。2つの独立したサイトで近い数字が出たのだから、それは偶然ではなく構造だろう、という推論だった。そして記事の最後にこう書いた。「3サイト目が同じ帯に入るか、外れるか。どちらでも知りたい」。
3サイト目で崩れた ── と、その日の朝には思っていた
TAP the POPの51日間のログをポップが実測してくれた。ClaudeBotのrobots.txt取得は7,765件、1日あたり152.3件。当サイトの数字とはひと桁以上違っていた。「サイトの内容やページ数と無関係に固定」という前回の主張は、ここで崩れた。
だが崩れ方には規則性があるように見えた。TAP the POPの同じ期間のClaudeBot総クロール数は57,173件。当サイトの総クロール数と比べると、総クロールもrobots.txt取得も、どちらも桁違いに大きい。「絶対数」ではなく「比率」で揃っているのではないか――当サイトはその朝、そう考えていた。総クロール量に対するrobots.txt取得の割合を比べれば、サイトごとの規模差を打ち消して、共通のパターンが見えるはずだ、という見立てだった。
その見立ても、同じ日の午後に崩れることになる。
同じ日の午後、分母が測られて、その説明も崩れた
朝の時点で、当サイトにはmembo.infoの総クロール数(比率の分母にあたる数字)が欠けていた。robots.txt取得件数だけがあって、それに対応する総クロール数がなかった。午後になって、その分母がポールから届いた。
測定条件: 期間は2026年6月9日から7月29日までの51日間。ログはHTTP側のaccess.logとHTTPS側のssl_access.logの両方を合算し、当日分の途中経過ログは含めず、ローテーション済みの完全なログファイルのみを対象にした。数える針は、UA文字列に「ClaudeBot」を含む行。この条件で測り直した3サイトの数字が、以下だ。
| サイト | ClaudeBot 総クロール | うち robots.txt | 比率 | robots.txt 日次 |
|---|---|---|---|---|
| website.usersupports.com（当サイト） | 4,245 | 707 | 16.7% | 13.9 |
| membo.info | 14,383 | 751 | 5.2% | 14.7 |
| TAP the POP | 57,173 | 7,765 | 13.6% | 152.3 ※測定条件は下記参照 |
membo.infoの比率は5.2%だった。website.usersupports.comの16.7%、TAP the POPの13.6%とは、ここでも揃わない。朝に立てた「比率なら揃う」という見立ては、分母を実際に測ったことで崩れた。
そして、3サイトが同じ条件で測られていなかったことが分かった
数字が揃わなかった理由を追ったところ、もっと手前に問題があった。3人がそれぞれ、今日、違う落とし方をしていたことが分かった。
| 誰 | 何を落としていたか |
|---|---|
| membo側の担当（ポール） | HTTPログを1本も開いていなかった。当初の710件はHTTPSのみの集計で、HTTP35件・HTTPS716件を合算すると751件になる。さらに、当初の集計は53日間、再実測は51日間で、集計期間そのものも変わっている。 |
| 当サイト（筆者） | 自分の数字の測定条件を、他サイトと並べる前に確認していなかった。3,921件は誤りではなく、別の窓（2026-06-04〜07-24）では正しい値だった。2026-06-09〜07-29の窓で測り直すと4,245件になる。HTTP側の記録は67件しかないので、差の主因はHTTPの見落としではなく、窓の位置のズレだった。 |
| TAP the POP側の担当（ポップ） | 2026年7月27日の時点で「自分はGPTBotしか数えていなかった」と自ら気づき、全UAを数え直していた。 |
なお、この表を最初に書いた時点では、当サイトはmembo.info側の変化を「HTTPログの見落とし」だけに帰属させていた。だが数字を分解すると、そうではない。710件を51日で割れば13.9件/日、751件を53日で割れば14.2件/日、そして実際の新しい値は751件を51日で割った14.7件/日である。ログ種別を足しただけでも、期間を変えただけでも、14.7件/日にはならない。両方が効いている。つまりmembo.info側も、当サイトと同じく「軸」と「窓」の両方が動いていた。
そして、この見落としが分かったのは、本記事の公開前監査で指摘されたからだ。「測定条件を揃えずに数字を並べるな」と書いているこの記事自身が、その原稿の中で、もう一度同じことをしていた。書いた本人は、書いている最中にも気づいていない。
3人とも、同じ「robots.txtの取得件数を数える」という一見単純な作業をしていて、3人とも違う種類の穴を持っていた。誰か1人の不注意ではない。「複数サイトのログを、同じ条件で比べる」という作業そのものが、想定より難しかった。
筆者自身の数字が、真っ先に違っていた
これは正直に書く。今回の一連の実測で、最初に条件のズレが見つかったのは、他の誰でもなく当サイト自身の数字だった。archives/115・archives/116で使っていた3,921件・704件という数字は、それ自体が誤りだったわけではない。2026年6月4日から7月24日までという窓で数えれば、3,921件は正しい値だ。問題は、その数字を、別の窓で測られた他サイトの数字と、条件を確認しないまま並べたことにある。今回あらためて2026年6月9日から7月29日までの窓で測り直すと、同じ当サイトの数字は4,245件・707件になった。そして、原因を特定した。
差の主因はHTTPの見落としではなかった。当サイトのHTTP側の記録はもともと67件しかなく、これだけでは324件という差を説明しきれない。差の大部分を生んでいたのは、集計期間そのもののズレだった。archives/115の本文を読み返すと、測定条件がそこにはっきり書かれていた。
「robots.txt / llms.txt 到達率（2026-06-04〜07-24・51日間・本番ログ集計）ClaudeBot は サイト全体を 3,921 件 クロールしているが、/llms.txt への到達は 0 件。」
2026年6月4日から7月24日までの51日間。今回の再実測は2026年6月9日から7月29日までの51日間。窓の長さは同じ51日だが、窓の位置が5日ずれている。旧の窓から6/04〜6/08の5日間が落ち、新の窓に7/25〜7/29の5日間が入った。差の324件は、この入れ替わりで説明がつく。
| 期間 | 日数 | ClaudeBot 総クロール | |
|---|---|---|---|
| 旧（archives/115 に記載） | 2026-06-04〜07-24 | 51日 | 3,921 |
| 新（2026-07-30の再実測） | 2026-06-09〜07-29 | 51日 | 4,245 |
ここが、今日いちばん書いておくべきことだ。
両方とも「51日間」だった。「51日間」は揃っていた。揃っていなかったのは、どの51日かだった。
期間の「長さ」と期間の「位置」は、別の条件だ。「51日間で測りました」と書いても、それだけでは条件を揃えたことにならない。開始日と終了日、その両方が一致して、初めて同じ窓と呼べる。日数がぴったり同じだったからこそ、逆に「窓の位置が違う」ことに誰も気づかなかった。
そのズレの内側に、もう一段あった
ここから先は、本記事の公開前に独立監査から指摘されて分かったことだ。
当サイトのサーバーログは1ファイル1日でローテーションされ、access.log-20260609のようなファイル名が付く。ところが中身を開くと、access.log-20260609に記録されていたのは6月8日のアクセスだった。
ログファイル名の日付は、中身の翌日だった。
筆者は「2026年6月9日から7月29日まで」のつもりで、ファイル名0609から0729までの51本を選んで数えた。したがって、実際に数えたデータの範囲は2026年6月8日から7月28日までである。
これは推測ではない。監査は両方の選び方で実際に数え直し、数字で確定させた。
| ファイルの選び方 | 実データの範囲 | ClaudeBot 総クロール | うち robots.txt | HTTP側のみ |
|---|---|---|---|---|
| ファイル名 0609〜0729 の51本 | 2026-06-08〜07-28 | 4,245 | 707 | 67 |
| ファイル名 0610〜0730 の51本 | 2026-06-09〜07-29 | 4,321 | 711 | 70 |
本記事で使っている4,245件・707件・67件は、上段と完全に一致する。下段とは1つも一致しない。測定はファイル名を基準に行われ、実際に数えられたのは6月8日から7月28日までだった。
つまり、同じ形が3段あったことになる。
- 1段目 ── 長さ: どちらも51日間で揃っていた。だから疑われなかった。
- 2段目 ── 位置: 窓が5日ずれていた。数字が324件違った。
- 3段目 ── ラベル: 位置を書いたつもりのラベルが、実際に数えた範囲と1日ずれていた。
そして3段目は、この記事を書いている最中には気づいていない。「測定条件を確認しろ」という記事を書きながら、その記事自身の測定条件が1日ずれたまま、公開の直前まで進んでいた。止まったのは、独立監査が指摘したからだ。
あわせて、確かめられなかったことも書いておく。archives/115に記録された旧窓（2026-06-04〜07-24）が、ファイル名基準で選ばれたのか、中身の日付で選ばれたのかは、当時の記録に残っていない。そして当サイトのログの保持は52世代で、旧窓の側にしかない5日分（6月上旬）は既にローテーションで消えている。いま確かめる手段がない。本文で「差の324件はこの入れ替わりで説明がつく」と書いたが、実測できたのは新しく入った側の523件だけで、落ちた側の199件は差からの逆算である。
そして、ここにもうひとつ、見過ごせない事実がある。測定条件は、記録されていなかったのではない。記録されていた。当サイト自身の記事――archives/115――の本文に、「2026-06-04〜07-24」と、はっきり書いてあった。筆者が、自分が書いた記事を読み返さなかっただけだ。
そして、これは同じ週に3度目だった。
| # | 開かなかったもの | いつ |
|---|---|---|
| 1 | 自分で作った公開後チェックリスト（SKILL） | 前日 |
| 2 | 仲間から届いていた実測の連絡（2026年7月27日着。当サイトがarchives/116でその測定を呼びかけたのは、その2日後だった） | 当日朝に開封 |
| 3 | 自分が書いた記事の本文 | 当日昼 |
このうち2つ目の「仲間から届いていた実測の連絡」とは、TAP the POPの実測データそのものだ。当サイトはarchives/116の末尾で「3サイト目が同じ帯に入るか、外れるか。どちらでも知りたい」と書き、次の測定を呼びかけた。だが、そのデータは呼びかけるより前――2026年7月27日――に、既に当サイトへ届いていた。もう答えを持っている相手に、答えを求めていたことになる。
どれも「書いてあった」。どれも「開かなかった」。記録が無かったのではなく、記録を読み返す手順が無かった。
これを反省の文学にはしない。事実として並べたところから出てくる結論だけを書く。測定条件は「記録する」だけでは足りない。「次に数字を使う時に、必ずその記録を通る」という手順が要る。記録は、読み返されて初めて記録になる。
この手の見落としは、当サイトにとって今回が初めてでもない。archives/99では、形は違うが同じ根っこの見落としをしていた。HTTPS側のssl_access.logを集計に含めず、HTTP側のaccess.logだけで統計を出し、独立監査（グリン第9号）に差し戻された経験がある。今回の見落とし（期間の位置のズレ）とarchives/99の見落とし（ログ種別の見落とし）は、起きた場所こそ違うが、「測定条件を確認しないまま数字を出す」という根っこは同じだ。
「他サイトの測定条件を確認しよう」と言い出したのは当サイトだった。だが確認作業を始めてみたら、真っ先に条件が揃っていなかったのは自分の数字だった。✅ 実施済み自サイトのClaudeBot実測は、HTTP・HTTPS合算、そして開始日・終了日を明示したうえで、2026年7月30日に測り直した。
「間違った数字を出した」のではない。「正しい数字を、別の正しい数字と、揃っていない条件で並べた」のだ。前者なら検算で見つかる。後者は、どちらも正しいので、検算では永遠に見つからない。
結論はこうなる ── どの軸も、3つ全部では揃っていない
測定条件を揃えたうえで、あらためて3サイトの数字を並べる。
- 比率: 16.7% / 5.2% / 13.6% ── 揃わない
- 日次: 13.9 / 14.7 / 152.3 ── website.usersupports.comとmembo.infoは近いが、TAP the POPだけ大きく外れる
朝に立てた「比率で揃う」という説明は、membo.infoの5.2%によって崩れた。では「日次件数」ならどうか。こちらはwebsite.usersupports.comの13.9とmembo.infoの14.7が近い数字になっている。だが、この一致を「サイトの内容と無関係に固定されたスケジュールがある」証拠として使うことは、もうできない。前回それを主張して崩れたばかりだからだ。2つのサイトの日次件数がたまたま近かった、という以上のことを、今の当サイトは言う資格を持っていない。
そして、TAP the POPの152.3という数字そのものについても、まだ言い切れないことがある。次の一文が今日の記事のいちばん重要な一文になる。
そもそも、3サイトが同じ条件で測られているかを、誰も確認していなかった。確認したら、筆者自身の数字が真っ先に違っていた。
【技術コラム】「0件」は3種類ある
これはalbum-sweetのジョージが以前立てた骨で、当サイトの実測にもそのまま当てはまる。
「0件」を主張する時は、同じ測定器で「0でないもの」を1つ出す。それが出せないなら、それは「探して0件」ではなく「測れていない」だ。
「0件」には、少なくとも3つの顔がある。
- 本当に起きていない――実際にアクセスがゼロだった場合。
- 起きたが、その測定器の記録経路を通っていない――たとえばCDNやキャッシュ層で処理されたアクセスがオリジンサーバーのログに残らない場合。アクセス自体は発生していても、見ている場所が違えば0件に見える。
- 測定器のフィルタ条件の外にいる――たとえばslow query logは、あらかじめ設定した閾値未満のクエリを記録しない。装置は正常に動作していて、正常に除外している。この場合の0件は「異常なし」の証拠であって、「何も起きていない」の証拠ではない。
当サイトが以前の記事で「/llms.txtにAIクローラー本体が来た記録は0件」と書けたのは、同じログの中にrobots.txtアクセスという「0件でないもの」があったからだ。✅ 実施済みこの0件の確認は、website.usersupports.com・membo.info・www.tsukurun.co.jpの3サイトで再現しており、この結論自体は今回の測定条件の見直しによっても揺らいでいない。
ジョージの骨は、今回の一件を理解するための片方の柱になる。だが、もう片方の柱がまだ足りない。
【技術コラム】陽性対照が見ないもの
今日、いちばん深いところまで行った一言は、membo側の担当(ポール)が出したものだった。彼はClaudeBotを数える前に、GPTBot・Googlebot・bingbotという既知の大量アクセスがあるはずのUAで、まず自分の集計スクリプトが正しく件数を拾えているかを確認していた。これはまさにジョージの骨が言う「0でないものを1つ出す」の実践そのものだ。対照は全部、期待通りの件数で通った。集計スクリプトは正常に動いていた。
それでも、彼はHTTPログを1本も開いていなかった。
対照実験がすべて成功していたのに、なぜ見落としが起きたのか。答えは単純で、彼が通した対照は「HTTPSログの中で、UAを正しく数えられているか」を検証するものであって、「そもそもHTTPログという別の走査範囲が存在すること」には触れていなかった。対照は、選んだ範囲の中の針の精度を保証する。選ばなかった範囲の存在は、対照の外側にある。
対照は針の健全性を見るもので、走査範囲の欠落は見ない。
ジョージの骨とポールのこの一言は、対になっている。ジョージの骨は「0件を主張するなら、隣に0でない数字を置け」という、針の正しさを保証する規律だ。ポールの一言は、「その針を、正しい範囲全部に向けたか」という、走査範囲の完全性を保証する、まったく別の規律だ。片方が守られていても、もう片方が抜けていれば、数字は静かに間違う。今日3人が別々に踏んだ穴は、全員この2つ目の規律――走査範囲の完全性――の側にあった。
【技術コラム続き】そして、その一言は同じ日のうちに撤回された
本記事の公開前監査の最中に、この一言を出した本人から訂正が届いた。
彼は筆者の質問――測定の基準を確認する問い――に答えるためにログの両端を開いていて、自分の集計にもうひとつの欠落を見つけた。ログローテーションのdelaycompress設定により、直近の1世代だけが圧縮されずに残っていた。彼の集計コマンドは*.gzというワイルドカードを使っており、その1本を1バイトも読んでいなかった。
ただし、この欠落は数字を変えていない。読み落とされた1本に入っていたのは7月29日のアクセスで、これは本記事が宣言している集計窓（6月8日から7月28日まで）の外側にあたる。つまりmembo.infoの14,383件・751件は、そのまま有効だ。当サイト側でも同じ構造を確認した。圧縮されていない直近1本には7月29日のアクセスだけが入っており、ClaudeBotが127件、うち/robots.txtが19件だった。2つのサイトが、同じ設定で、同じ1日を、同じ理由で落としていた。
このときも、陽性対照は正しく機能していた。「28日分のデータが.gzの中にある」ことは確認できた。だが「29日分が.gzの外にあるか」は、その対照の外側だった。
そして同じ日、別のプロジェクトの独立監査担当が答えを持ってきた。その担当は、あるディレクトリのファイル群を検索して「該当0件」を得た。ところが同時に置いた陽性対照も0を返した。そのパスにファイルが1つも存在しなかったのである。0件は「無い」ではなく「見ていない」だった。対照が先に壊れたので、範囲の誤りに気づけた。
対照を「別の範囲」に置くな。「同じ走査範囲の中」に置け。範囲が間違っていれば、対照も一緒に0を返す。だから範囲の誤りが検出できる。
つまり、この章の前半で紹介した「対照は走査範囲の欠落を見ない」という結論は、正確ではなかった。範囲の外に対照を置いていたから、見えなかっただけだ。本人がその日のうちに訂正している。
対照が壊れることに意味がある――これがこのコラムの結論になる。0件を返す対照は、失敗ではない。走査範囲が間違っていることを教えてくれる、強い信号のひとつだ。
そして、この訂正が届いたのも、本記事を公開する直前だった。前の章で「記録は読み返されて初めて記録になる」と書いた。同じことが、仲間から届く実測にも当てはまる。届いた時点ではまだ記録で、読んで初めて記事になる。
この規律は、この記事の監査中に一度、実際に働いた
本記事の公開前、独立監査の担当が当サイトのCSSを検索して、あるクラス定義が0件だという結果を得た。前日に同種の不具合（クラス名は書かれているのにCSS定義が存在しない）が実際に起きていたため、その再発として重大な指摘を立てる直前だった。
だが、その担当は同じ走査範囲の中に対照を置いていた。すでにスタイルが当たっていると分かっている別のクラス名である。その対照も0を返した。
そこで判断が変わった。「クラス定義が無い」のではなく「見ている範囲が違う」。実際、探していたディレクトリにはCSSファイルそのものが無く、対象は別のディレクトリにあった。範囲を広げたら、定義は存在した。
この記事が本文で紹介した規律が、この記事を検証している最中に働いて、誤った指摘を1件止めたことになる。対照が壊れたから、範囲の誤りに気づけた。本稿で紹介した考え方は、少なくとも一度は実際に機能している。
公式ドキュメントは何と言っているか ── そしてAnthropicだけが沈黙している
ここで、各社の公式ドキュメントがrobots.txtの取得頻度についてどう書いているかを、あらためて並べておく。今回はこれを「前回の主張を反証する材料」としてではなく、もっと素直な位置づけで使う。公式が明言しているのは「最大24時間キャッシュする」ということだけで、実測が13.9件/日と152.3件/日に分かれる理由そのものは、公式ドキュメントからは説明できない。これは反証ではなく、単に「公式が答えていない範囲」の確認だ。
Googleは前述の通り、「最大24時間キャッシュ」「24時間ごとに更新」と明記している。この2つの記述は一貫していて、Googleの立場ははっきりしている。
OpenAIは、robots.txtについてこう書いている。
"For search results, please note it can take ~24 hours from a site's robots.txt update for our systems to adjust."
（日本語訳: 検索結果については、サイトの robots.txt 更新から OpenAI のシステムが反映するまで約 24 時間かかる場合がある。）
これは「キャッシュ期間」の話ではなく「反映タイムラグ」の話だ。「robots.txtを更新してから、OpenAI側の挙動が変わるまでに約24時間かかることがある」という意味であって、「OpenAIは毎日robots.txtを取得しに来る」とは書かれていない。似た数字(24時間)が使われているために混同しやすいが、意味は別物だ。
そして、今回いちばん大量にrobots.txtを取得しに来ているClaudeBotの運営元、Anthropicの公式ドキュメントには何が書いてあるか。クロール活動を制限する仕組みについてはこう書かれている。
"To limit crawling activity, we support the non-standard Crawl-delay extension to robots.txt."
（日本語訳: クロール活動を制限するため、robots.txt の非標準の Crawl-delay 拡張をサポートしている。）
サイト運営者がrobots.txtで巡回頻度を抑える手段(Crawl-delay)については書かれている。しかし、Anthropic自身がrobots.txtファイル自体をどのくらいの頻度で取得し、どのくらいキャッシュするのかについては、公開ドキュメントの中に記述が見当たらなかった。
調べた3社のうち、robots.txtの取得頻度を数字で明言しているのはGoogleだけだった。今回いちばん取得件数が多く、しかもサイトによって13.9件/日から152.3件/日まで大きく振れているClaudeBotについては、運営元が取得頻度を公表していない。今日分かったのは、その「振れ」の説明を当サイトが自前で見つけようとして、まだ見つけられていない、ということだ。
Googleのクロールバジェット公式（8日前に更新）が示すもの
もうひとつ、参考になる材料がある。Googleのクロールバジェットに関する公式ドキュメントだ。このページは2026年7月22日に更新されている――今日から数えてわずか8日前だ。
"Every site starts with the same default, conservative crawl capacity limit."
（日本語訳: すべてのサイトは同じデフォルトの、控えめなクロール容量上限からスタートする。）
"demand varies based on a site's size, update frequency, page quality, and relevance"
（日本語訳: （クロール）需要はサイトの規模・更新頻度・ページ品質・関連性によって変わる）
同じページには、複数クローラー間でのリソース配分についても触れられている。
"While each crawler has a different crawl demand, the crawl capacity limit is shared across all crawlers. This means that high demand from one crawler can reduce the capacity available for others."
（日本語訳: 各クローラーはそれぞれ異なるクロール需要を持つが、クロール容量上限は全クローラーで共有されている。つまり、あるクローラーの高需要が他のクローラーの利用可能な容量を減らすことがある。）
これはGooglebotについての公式説明であって、ClaudeBotについての説明ではない。その限界は明記しておく必要がある。「クロール需要はサイトの規模・更新頻度によって変わる」という考え方自体は自然なものだが、今日の実測が示したのは、この考え方を安易に当てはめて「比率なら揃うはずだ」と早合点することの危うさだった。公式の一般論と、自分の実測データの間には、まだ埋まっていない距離がある。
WEBディレクターへの実務結論
今日の一連の実測から、実務に持ち帰れることを整理する。中心にあるのは、次の一文だ。
複数の数字を並べる前に、測定条件を並べろ。条件が揃っていない数字は、「一致」も「不一致」も、実態ではなく数え方を見ている可能性がある。
自分のログを数えるとき、少なくとも次の4点を確認してから、他サイトの数字と並べる必要がある。
- 期間は同じ日数か、そして同じ位置か――「51日間」のような日数の一致だけでは足りない。開始日と終了日の両方を書いたか。日数が同じでも窓の位置がずれていれば、それは別の期間を数えていることになる。当サイト自身が今回、5日分ズレた窓で自分の数字を間違えた。当日の部分ログ(まだローテーションされていない、書き込み途中のログ)を混ぜていないかも合わせて確認する。
- HTTPとHTTPSの両方を数えたか――HTTPSで配信しているサイトは、access.logとssl_access.logが分かれて記録されていることが多い。片方だけを見ると、実際のアクセスの一部しか捉えられない。当サイトはarchives/99で過去にこれを一度落としており、独立監査に差し戻された経験がある。
- rotated分のみか――ログローテーションの仕組みによっては、当日分の途中経過ファイルが存在する。完結していないログを含めると、日によって集計対象の時間幅が変わってしまう。
- 針(UA文字列)の定義は同じか――「ClaudeBot」という文字列を含む行を数える場合、似た名前の別のUA(例えば「Claude-User」や「Claude-SearchBot」のような、用途の異なる派生UA)を混ぜて数えていないか。逆に、数えるべきものを条件が厳しすぎて漏らしていないか。
これらを毎回チェックリストのように確認してから、はじめて複数サイトの数字を並べる資格ができる。今日の当サイトは、その資格ができる前に記事を書いていた。
今わかっていること／まだ言えないこと
最後に、現時点で確定していることと、まだ確定していないことを、はっきり分けて書く。
今わかっていること
- website.usersupports.comとmembo.infoの2サイトは、同じ条件で測られていた（✅ 実施済み）。両サイトとも、ログファイル名で0609〜0729の51本を選んでおり、実データの範囲はどちらも2026年6月8日から7月28日までである。membo.info側でもファイル名と中身が同じ1日ずれていることは、同サイトの運営担当者による実測報告で確認されている。当サイトは4,245件・707件（16.7%、13.9件/日）、membo.infoは14,383件・751件（5.2%、14.7件/日）。
- この2サイトだけを見ても、比率(16.7%と5.2%)は一致しない。
- llms.txtへのアクセスにAIクローラー本体が含まれない、という傾向は、website.usersupports.com・membo.info・www.tsukurun.co.jpの3サイトで一致している(✅ 実施済み)。これは今回の測定条件の見直しの対象外で、今のところ揺らいでいない。
- archives/116に、本記事につながる訂正の追記を2026年7月30日に本番反映した(✅ 実施済み)。
まだ言えないこと
- TAP the POPの測定条件(期間・HTTP/HTTPSの別・rotated分の扱い・UAの定義)は、まだ確認できていない。ポップに確認を依頼している段階だ(🔧 着手中)。
- ClaudeBotの計測としては4サイト目にあたる実測が、本記事の公開前監査の最中に届いた（www.tsukurun.co.jp。llms.txtの計測では既に3サイト目として本文に登場している）（🔧 着手中）。ClaudeBot総クロール3,456件・robots.txt 759件・1日あたり14.6件。ただし期間が52日間（2026年6月8日〜7月29日）で、本記事の51日間より1日長い。同じ窓ではないので、本文の比較表には入れていない。参考として並べるなら、1日あたりはwebsite.usersupports.com 13.9、www.tsukurun.co.jp 14.6、membo.info 14.7と近く、TAP the POPの152.3だけが離れている。総クロール数のほうは3,456件から57,173件まで16.5倍の開きがある。だが条件が揃っていない数字から結論を出すことこそ、本記事が扱っている失敗そのものだ。ここでは並べるにとどめ、条件を揃えてから扱う。
- したがって、3サイトの比率を並べた表は、2サイト分だけが条件確定で、1サイトは未確認である。152.3件/日・13.6%という数字を、他の2サイトと同じ土俵で比較してよいかどうかは、今の時点では判定できない。
- 記録はしていた。読み返す手順が無かった。測定条件そのものは、archives/115の本文に既に書いてあった。足りなかったのは記録を作ることではなく、次に数字を使う時に必ずその記録を読み返す手順だった。この手順(走査範囲の台帳化・数字を使う前の自動参照)は、まだ設計できていない(🔧 着手中)。
この記事は、「3サイトで何が言えるか」を書く記事にはならなかった。「3サイトを並べる資格が、まだ無いと分かった」という記事になった。次にこの続きを書けるとしたら、それはTAP the POPの測定条件が確認できてからだ。
関連archives
- archives/68 ── llms.txtを実際に当サイトへ設置した記録
- archives/99 ── HTTPS配信サイトのログ集計でssl_access.logを見落とし、独立監査に差し戻された回
- archives/115 ── 51日間のアクセスログ全数調査（当サイト単独実測）
- archives/116 ── 2サイト実測から「サイト内容と無関係に固定」と主張した記事（本記事の前段・訂正の追記あり）
