2026年6月4日にllms.txtを設置し(archives/68)、1ヶ月後に一度集計を誤って独立監査に差し戻され(archives/99)、51日目にHTTP・HTTPSを統合してもう一度数え直した(archives/115)。3本を通して、当サイト自身のログを何度も掘り直してきた。だが、どれだけ丁寧に数えても、それは「website.usersupports.comというサイトで起きたこと」の記録でしかない。今回は、チームの仲間が運用する8言語対応サイト・membo.infoの実サーバーログを同じ手法で独立に測り、archives/115の結論が「このサイト固有の現象」なのか、それとも「もっと一般的な現象」なのかを確かめた。
なぜ、もう一つのサイトで測る必要があったのか
archives/115で確立した集計手法は、本番サーバーのaccess.logとssl_access.logを、ログローテーションの圧縮ファイル・未圧縮ファイルを含めて日付境界を厳密に指定して統合し、User-Agent単位で仕分けるというものだった。この手法自体には自信が持てるようになった。しかし手法の正確さと、結論の一般性はまったく別の話だ。「51日間・89件」という数字がどれほど正確でも、それがllms.txtという仕組み全体について言えることなのか、それとも当サイトの規模・言語構成・更新頻度に固有の現象なのかは、1サイトの観測だけでは判定できない。
そこで、性質のまったく違うサイトでの独立した実測を用意した。今回比較したのは、membo.info(バンドメンバー募集・スタジオ/ライブハウス情報、8言語対応)と、website.usersupports.com(当サイト、単言語)。運営会社は同じだが、言語構成・想定読者・更新頻度が大きく異なる2サイトだ。観測期間はmembo側が取得可能な最大期間である53日間、当サイト側はarchives/115と同一の51日間。どちらも同じ集計手法(本番ログの日付境界厳密指定・User-Agent単位の仕分け)で数えている。
① llms.txtへのアクセス ── 多言語サイトの方が、読まれていなかった
まず/llms.txtそのものへのアクセス数を並べる。
| サイト | 言語数 | 観測期間 | llms.txt アクセス | 1日あたり |
|---|---|---|---|---|
| membo.info | 8言語 | 53日間 | 25件(+ llms-full.txt 1件) | 0.47件/日 |
| website.usersupports.com | 単言語 | 51日間 | 89件 | 1.7件/日 |
8言語対応のmemboの方が、単言語の当サイトよりも1日あたりのアクセス数が約1/4しかなかった。「対応言語が多いサイトほど、多様な言語のAIが積極的に読みに来る」という直感は、この2サイト比較では裏付けられなかった。むしろ逆の結果が出ている。もっとも、この数字だけでは「なぜ少ないのか」までは分からない。理由を知るには、誰が読みに来ているのかを見る必要がある。
② 最重要発見 ── llms.txtに来ていたのは、AIクローラーではなく観測ツールだった
membo.infoの/llms.txt・/llms-full.txtへの合計26件のアクセスを、User-Agent単位で一件ずつ仕分けた。結果は次の通りだ。
| User-Agent | 件数 | 正体 |
|---|---|---|
| BuiltWith/1.4 | 7件 | SEO調査bot |
| curl/8.10.1 | 6件 | 手動チェック/スクリプト |
| HeadlessChrome | 4件 | 自動化ツール |
| WebPageTest(PTST) | 4件 | 性能計測ツール |
| Dataprovider.com | 2件 | クローラー |
| PipericBot / SiteAuditBot | 2件 | SEO監査ツール |
| llms.txt crawler bot(llmstxtscan.org) | 1件 | llms.txt専用スキャナー |
ClaudeBot・GPTBot・PerplexityBot・Google-Extended ── 名前の知れたAIクローラー本体は、26件中0件だった。人間らしいアクセス(一般的なブラウザUAで、かつ他の巡回パターンと矛盾しないもの)も0件。26件の内訳は、SEO調査ツール・性能計測ツール・手動確認・そしてllms.txt専用のスキャナーサービスで占められていた。
この最後の1件が象徴的だ。llmstxtscan.orgは「どのサイトがllms.txtを設置しているか」を集計・可視化するサービスで、当サイトも同種のスキャナーがarchives/115の集計に登場している。「llms.txtを巡回している」と主張する側の観測ツールが、llms.txtへのアクセスの実態の大半を占めていたということだ。これは、llms.txtというエコシステムの外側から実際のAI利用者が読みに来ているのではなく、エコシステムの内側で数字が回っているだけに見える、という厳しい見方も成り立つ。
③ 2サイト一致の物証 ── ClaudeBotのrobots.txt巡回頻度がほぼ同じだった
ここが本稿でもっとも強い発見だ。llms.txtとは対照的に、標準化されたrobots.txtへのアクセスを見ると、まったく違う姿が見えてくる。
| 指標 | membo.info(8言語・53日) | WUS(単言語・51日) | 差 |
|---|---|---|---|
| ClaudeBot の robots.txt アクセス | 710件(13.4件/日) | 704件(13.8件/日) | 約3% |
| robots.txt 全体アクセス | 7,226件(136.3件/日) | ── | ── |
言語数・サイト規模・更新頻度がまったく違う2サイトで、ClaudeBotのrobots.txt巡回頻度が1日あたり13.4件と13.8件、ほぼ一致していた。llms.txtが約4倍のばらつきを見せたのとは対照的だ。この一致は、ClaudeBotのrobots.txt巡回が、サイトの内容やページ数と強く連動せず、比較的固定に近いスケジュールで回っている可能性を示唆する。
ここは慎重に書く必要がある。これはAnthropicが公表した仕様ではなく、あくまで2サイトの実測から示唆される傾向であって、断定はできない。1サイトの観測だけなら「たまたま13件台だった」で片付いてしまう数字が、性質の異なる2つ目のサイトでも同水準に収まったことで、初めて「サイト固有の偶然ではなさそうだ」と言えるようになる、という話だ。
読みに来る経路は、別にある
membo.infoの数字を並べ直すと、llms.txtがどれほど小さな入口かが分かる。llms.txt(25件)は、robots.txt全体(7,226件)の約1/290に過ぎない。一方でsitemap.xmlへのアクセスは2,163件(40.8件/日)あり、そのうちClaudeBotだけで696件を占めている。llms.txtへのClaudeBotアクセスが0件だったのとは対照的だ。
AIクローラーは、llms.txtではなく、robots.txtとsitemap.xmlでサイト構造を把握している。これが2サイトの実測から見える運用の実態だ。archives/93でCloudflareの「Verified AI Agent」区分の話を書いたが、今回の実測はその話とは別の層 ── クローラーが「巡回の設計図」として実際に何を読んでいるか、という層の話になる。
「1サイトの実測は仮説、2サイトの一致は事実」という方法論
Googleは公式ドキュメントで、llms.txtについてこう明言している。
"You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its Generative AI capabilities), as Google Search itself doesn't use them."
(日本語訳: Google検索(生成AI機能を含む)に表示されるために、新しい機械可読ファイル、AIテキストファイル、マークアップ、Markdownを作成する必要はない。Google検索自体がそれらを使用しないからだ。)
この公式見解を紹介するだけなら、archives/115で既にやったことの繰り返しになる。本稿の意味は別のところにある。1サイトの実測は、どれだけ丁寧にやっても仮説にしかならない。「当サイトでは読まれていなかった」という結果は、サイトの規模・分野・鮮度のどれかが原因かもしれず、他のサイトでは違う結果になる可能性を常に残す。だが、言語数も規模も更新頻度も違う2つのサイトで、独立に測った実測が一致したとき、それは初めて「事実」と呼べる強さを持つ。今回、llms.txtの低アクセス率とAIクローラー本体の不在は2サイトで再現され、ClaudeBotのrobots.txt巡回頻度もほぼ一致した。これは公式見解を裏付ける、当サイト自身の手による2件目の独立証拠になる。
WEBディレクターへの実務結論
2サイトの実測から、明日から使える結論を4つにまとめる。
- llms.txtを磨き込む時間があるなら、robots.txtとsitemap.xmlを正しく保つ時間に回す方が、実測上は合理的。AIクローラーが実際に読みに来ているのは、こちらの2つだからだ。 ✅ 当サイト実施済
- ただし「llms.txtを置くな」ではない。設置コストは数十分程度で、将来この仕組みが普及した場合の保険にはなる。優先度を下げてよい、という話であって、削除を推奨する話ではない。 ✅ 当サイト実施済(維持を選択)
- 「効果がなかった」という実測も、立派な知見である。「やらなくていい」と判断できる材料があれば、限られた時間を本当に効くところに割ける。
- 自サイトのアクセスログを、実際に見ているか?本稿の数字はすべて、自分たちのサーバーの
access.log/ssl_access.logから出ている。特別なツールは要らない。今日、自分のサイトでも同じ集計はできる。 🔧 未計測なら、まず51日分の集計から
当サイトのself-proof状況(正直な自己開示)
✅ 当サイト実施済 membo.infoとの2サイト独立実測(本稿・同一手法・同一期間帯での並行集計)
✅ 当サイト実施済 ログの日付境界を厳密指定したHTTP・HTTPS統合集計(archives/115の手法を踏襲・membo側にも同一基準で適用)
🔧 これから membo.info側のより長期間(3ヶ月以上)データでの再現性確認。今回の53日間はmembo側のログ保持期間の制約で取得できる最大値であり、期間を伸ばした際に数字が動くかは未検証
🔧 これから 3サイト目(album-sweet等、チーム内の別プロジェクト)での追試。2サイトの一致は事実に近づく強い根拠だが、3サイト目が加われば再現性はさらに強まる
連載の系譜 ── archives/68 → 99 → 115 → 116
archives/68でllms.txtを設置し、archives/99でHTTPログのみを見て悲観的な結論を出し独立監査に差し戻された経緯ごと公開し、archives/115でHTTP・HTTPS統合という手法の正確さを積み上げた。本稿はその手法を当サイトの外に持ち出し、membo.infoという別サイトで独立に再現させることで、「このサイトだけで起きたこと」から「複数サイトで再現される事実」へと結論の強度を一段引き上げた。self-proof-loopという連載の意味は、施策の効果を追い続けること自体がコンテンツになる、という点にあるが、本稿はさらにその先 ── 実測の一般性を、自分のサイトの外に出て確かめるという段階に進んでいる。
まとめ ── 「読まれない」の再現性を、自分の手で確かめる
membo.info(8言語・53日間)とwebsite.usersupports.com(単言語・51日間)、性質の違う2サイトの実測を並べた結果、3つのことが分かった。第一に、多言語対応のmemboの方が、単言語の当サイトよりllms.txtへのアクセスが約1/4しかなかった。第二に、その少ないアクセスの中身は、AIクローラー本体ではなくSEO調査ツールや観測サービスがほとんどで、ClaudeBot・GPTBot・PerplexityBot・Google-Extendedは0件だった。第三に、これがもっとも強い発見だが、ClaudeBotのrobots.txt巡回頻度は2サイトでほぼ一致しており、AIクローラーがllms.txtではなくrobots.txtとsitemap.xmlを実際の巡回経路として使っていることが、1サイトの観測では言えなかった強さで裏付けられた。Googleが公式に「効かない」と言った以上のことを、今回もう一段確かめられたことになる。次の答え合わせは、3サイト目での追試か、membo側のより長期間のデータが揃ったタイミングで書く。
関連 archives(連載軸として読む)
- archives/68「llms.txtを当サイトで実際に設置した」 ── 連載の起点(2026-06-04)
- archives/99「llms.txt を置いた1ヶ月後、正直に答え合わせ」 ── HTTPのみ集計で悲観的結論、独立監査で差し戻し
- archives/115「llms.txt を置いて51日、正直に答え合わせ第2弾」 ── HTTP・HTTPS統合手法の確立(本稿の手法の土台)
- archives/93「Cloudflareが『検証』の定義を変えた日」 ── AIクローラーの区分・検証という別の層の話
- archives/76「AIに表示された回数を知っているか」 ── GSC・GA4・Bing、3ツール立体計測との接続
WEBサイト