WEBサイト
2026年6月4日、当サイトは177行の全URL羅列だった/llms.txtを、59行のキュレーション版に書き直した（archives/68）。1ヶ月後の答え合わせでは、HTTPログだけを見て「4件しかない」と誤り、独立監査に差し戻されたうえでHTTP・HTTPS統合の41件を数え直した（archives/99）。あれから、さらに20日あまり。今日、Google Search Centralのガイダンスが更新されたのを見て、腰を据えてもう一段深い答え合わせを書くことにした。
今回は、6月4日の設置から7月24日までの51日間、本番サーバーのaccess.logとssl_access.log（ログローテーションによる圧縮ファイル・未圧縮ファイルを全て含む）を、日付境界を厳密に指定して統合し、/llms.txtへの全アクセスをもう一度数え直した。そのうえで、サイト全体のAIクローラー流入と、robots.txtへのアクセス実績も同じ期間・同じUA基準で並べてみた。結論から言うと、タイトルの通りだ。Googleは「効かない」と言った。そして、それを確かめる過程で、Google以外の名前の知れたAIクローラーも、51日間ほとんど/llms.txtを読みに来ていなかったことが分かった。
51日間の実測 ── /llms.txtへの実アクセスは89件
2026年6月4日から2026年7月24日までの51日間、/llms.txt（および誤って残っていたバックアップファイル1件を含む）への全アクセスは、サーバーログの実測で89件だった。archives/99で数えた「41件・36日間」から日数はおよそ1.4倍に伸び、アクセス数は約2.2倍になっている。単純な日割りでは説明がつかない増え方だ。理由は次の章で見えてくる。
この集計は一度、日付範囲の取り違えで訂正している。ログのローテーションファイルは「その日にローテーションされたファイル名＝前日分の中身」という命名規則になっており、最初のgrepではファイル名だけで範囲を判断した結果、6月3日分を余計に含み、7月24日分（未圧縮のローテーション直後ファイル）を取りこぼしていた。今回は各ログ行のタイムスタンプを直接パースし、2026-06-04〜2026-07-24の日付境界を厳密に指定して再集計した。
内訳を仕分けると ── 「読みに来た」の大半は自分自身とスキャナーだった
89件のUser-Agentを一件ずつ仕分けると、次の5カテゴリに分かれた。
- 内部監視・自作ツール（24件）: 当サイト自身の死活監視ツール「WebsiteSupport-HealthChecker/1.1」が22件、sitemap生成ツール「SitemapMaker/1.0」が1件、誤って残っていたバックアップファイルへのアクセス（自分自身の手動リバート作業分）が1件。これは外部からの「読了」ではなく、当サイト自身の運用ログだ。
- スキャン・SEOツール系UA（25件）: curl（12件）・Scrapy（3件）・jscrawler（2件）・SERankingBacklinksBot（2件）・AwarioBot（2件）・LinkupBot（2件）・MJ12bot（1件）・ShapBot（1件）。バックリンク調査ツールやSNS言及監視ツールが機械的に全URLを踏んでいる部類で、「AIが読んで理解した」とは性質が異なる。
- 汎用ブラウザUA相当・出所不明（33件）: iPhone Safari 13系を名乗るUAが同系統のIPレンジから12件、Windows Chrome系の汎用UAが個別に6件、そして「Mac Chrome 142」を名乗りながら実際の送信元IPがTor出口ノードのレンジ（185.220.x.x等）だったものが15件。ブラウザを装った自動化・スキャン行為である可能性が高いが、断定はできないため「出所不明」として区分した。
- 検索エンジン公式（3件）: Googlebotが1件、bingbotが2件。
- 公式AIクローラー実測（4件）: GPTBot（1件）・Bytespider（1件）・Amazonbot（1件）・Claude-User（1件）。合計してもわずか4件だ。
この最後の4件のうち、Claude-Userは自律的なクロールではなく、人間がClaude Codeを操作した際に発生したリクエスト（UA文字列にclaude-code/2.1.205と明記）だ。純粋に「AIが自動で巡回してきて読んだ」と言えるのは、GPTBot・Bytespider・Amazonbotの3件のみになる。
サイト全体のクロール規模と比べると、0.0X%という数字が見える
「51日間で3件は少ない」という感覚を、数字で裏付ける。同じ51日間、サイト全体で観測された主要AIクローラーのアクセス数は次の通りだった（同一UA基準・本番ログ実測）。
ClaudeBotはサイト全体で3,921件クロールしているが、/llms.txtへの到達は0件。GPTBotは2,242件クロールして1件、Amazonbotは2,866件クロールして1件、Bytespiderは2,702件クロールして1件。もっとも多くクロールしているClaudeBotの数を分母にすると、/llms.txt到達率は0.00%（0/3,921）だ。PerplexityBot（218件）・Google-Extended（3件）・OAI-SearchBot（518件）・CCBot（534件）・Applebot（2,423件）に至っては、51日間で/llms.txtへの到達が1件もない。
robots.txtは読みに来る。llms.txtは、読みに来ない
この差が単に「AIクローラーがファイルを読まない習性」だと考えるのは早計だ。同じクローラーたちの/robots.txtへのアクセスを見ると、様子が違う。ClaudeBotは704件、Bytespiderは244件、OAI-SearchBotは221件、PerplexityBotは47件、CCBotは11件——合計すると1,227件が主要AIクローラーによるrobots.txt読了だ。当サイトのrobots.txtはUser-agent: *を基本としたシンプルな370バイトのファイルで、AIクローラー個別の指定は一切書いていない。それでも各クローラーは、標準的な巡回作法として律儀にrobots.txtを取得しに来る。
つまり「AIクローラーはファイルを読みに来ない」のではない。robots.txtという標準化された仕組みには来て、llms.txtという未標準の仕組みには来ない——これが51日間の実測が示す構造だ。
Googleが公式に「効かない」と言った日（2026年7月10日更新）
この実測を書き始めた同じタイミングで、Google Search Centralの「Google's Guide to Optimizing for Generative AI Features on Google Search」ページが2026年7月10日（UTC）付けで更新されているのを見つけた。原文はこう書いている。
"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検索自体がそれらを使用しないからだ。）
さらに続けて、こう明記されている。
"Doing so will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them."
（日本語訳: そうしても〔＝llms.txt等を作成・維持しても〕、Google検索でのあなたのサイトの可視性や順位を害することも助けることもない。Google検索はそれらを無視するからだ。）
Search Engine Journal（Roger Montti、2026年6月17日）の報道によれば、この見解自体は6月にも一度示されており、7月10日の更新は「Google検索は使わないが、他のAIサービス向けに作成・維持すること自体は問題ない」という位置づけを、より明確な文言に整理したものだ。つまりGoogleの立場は「llms.txtはGoogle検索には効かない。ただし禁止でも推奨でもない、中立」という一貫したものだった。
「効かない」と「読みに来ない」は別の話 ── 本稿が確かめたかったこと
ここが本稿の芯だ。Googleの「効かない」という言葉は、あくまでGoogle検索のランキング・生成AI機能への影響についての公式見解であって、「他のAI企業のクローラーがそのファイルを読みに来るかどうか」については何も語っていない。archives/99の時点では「HTTPS込みで数え直したら41件あった、読まれ方は期待と違ったが、読まれてはいた」という着地だった。だが今回、Google以外の主要AI企業（Anthropic・OpenAI・Perplexity・ByteDance・Common Crawl）の名の知れた公式クローラーを個別に数えると、51日間の合計はわずか3件（Claude-Userの人間操作分を除く）。Googleが公式に「効かない」と言った以上に、他のAIも構造的に読みに来ていなかった、というのが今回の実測が示す答えだ。
他社5社のllms.txtと、当サイトの40KBを並べてみる
当サイトの/llms.txtは現在106行・40,496バイト。これが世間的にどの水準なのか、実際に他社のURLへ直接curlを打って確かめた。
| 企業・サービス | URL | 状態 | サイズ |
|---|---|---|---|
| Vercel | vercel.com/llms.txt | 200 | 約195KB |
| Stripe | stripe.com/llms.txt | 200 | 約64KB |
| Cloudflare | www.cloudflare.com/llms.txt | 200 | 約16KB |
| Anthropic（docs） | docs.anthropic.com/llms.txt | 200 | 約56KB |
| Zapier | zapier.com/llms.txt | 200 | 約12KB |
| Supabase | supabase.com/llms.txt | 200 | 約2.8KB |
当サイトの40KBは、この6社の中では中位——Cloudflareより大きく、Stripeより小さい水準だった。
developer向け企業の採用パターン
並べてみて分かったのは、実際にllms.txtを整備している企業は、ほぼ例外なく開発者向けサービス（Vercel・Stripe・Zapier・Supabase・Cloudflareの開発者向けドキュメント）だということだ。Digital Applied（2026年6月24日公開）の分析では、上位1,000サイトのうち実装はわずか3件（0.3%）、より広い30万ドメイン規模の調査では採用率約10%とされ、主な採用者は「開発者向け企業」だと整理されている。当サイトのようなWEBディレクター向け情報サイトは、この統計の主流からは外れた立ち位置にいる。
Anthropic自身は？ ── ルートドメインには無い、という発見
llms.txt構想を最初に提唱したのはAnthropicの関係者だ（archives/68で言及済み）。当然anthropic.com自体にもあるだろうと思ってcurlを打ったところ、anthropic.com/llms.txtはリダイレクト先のwww.anthropic.com/llms.txtで404だった。実在するのはdocs.anthropic.com・claude.com・claude.aiという、開発者ドキュメントやプロダクトサブドメイン側だった。提唱企業本体のコーポレートサイトのルートには置かれていない、という事実は、llms.txtが「サイト全体の顔」ではなく「特定のドキュメント/プロダクト領域の道案内」として使われている実態を裏付けている。
Chrome Lighthouseの「Agentic Browsing」監査 ── 別の入口が実在する
実測とは別に、もう一つ見つけた事実がある。Digital Appliedの記事によれば、Chrome Lighthouse 13.3（2026年5月7日リリース）が、デフォルト設定の監査項目に「Agentic Browsing」カテゴリの一部としてllms.txtチェックを追加している。同記事の説明では、ファイルが存在しない場合の結果は「失敗」ではなく「N/A」——これは検索ランキングの監査ではなく、AIエージェントがそのサイトをブラウジングする際の準備状況を測る、Googleの検索評価とは別系統の指標だという。加えて、コーディング支援ツール（Cursor・GitHub Copilot・Continue等）はllms.txtをドキュメント探索に実際に利用しているとも報告されている。「検索エンジンのクローラーには読まれないが、ブラウザに搭載されたエージェントや開発ツールには使われる可能性がある」——これが、llms.txtの現在地としてより正確な理解に近そうだ。
それでも当サイトはllms.txtを削除しない、3つの理由
ここまでの実測は、正直に言えば「llms.txtの費用対効果は低い」ことを裏付けるものだ。それでも当サイトは/llms.txtを削除しない。理由は3つある。
①コストがほぼゼロ: 59行から106行に育てた現在の運用でも、追記の手間は既存のCMSワークフローに乗る程度。Googleが明言する通り「害はない」。維持コストが実質ゼロなら、下げる理由がない。
②「今後読まれない」の証明にはならない: 51日間の実測は、あくまで2026年6月〜7月時点でのAIクローラー実装状況のスナップショットだ。Chrome Lighthouse監査の追加（5月）やGoogleガイダンスの複数回更新（6月・7月）を見ても、この領域はまだ動いている最中で、半年後に同じ結果になる保証はない。
③self-proof-loopの精神として、途中でやめない: archives/68で「設置した」、archives/99で「41件、期待と違う読まれ方だった」、そして本稿で「89件、公式クローラーはほぼ来ていなかった」——この3本の答え合わせを続けること自体が、当サイトの連載の芯だ。効果が薄いと分かった施策を正直に開示し続けることに価値がある、という立場を本稿でも維持する。
WEBディレクターが今週見るべき3点
①robots.txtとの役割分担を明確にする
本稿の実測が示す通り、AIクローラーが実際に律儀に読みに来るのはllms.txtではなくrobots.txtだ。AIクローラー個別のアクセス許可・拒否を制御したいなら、まずrobots.txtのUser-agent別ディレクティブを点検するのが優先順位が高い。当サイトのrobots.txtは現状User-agent: *のみで個別クローラー指定を持たない——これは次の点検候補として記録しておく。
②Chrome Lighthouse監査で自分のサイトを見る
llms.txtの有無をGoogle検索目的で気にする必要はない、というのがGoogle公式の立場だ。一方でChrome Lighthouseの「Agentic Browsing」カテゴリは、ブラウザに搭載されたAIエージェントがサイトをどう扱うかという、検索ランキングとは別の評価軸を持っている。両者を混同せず、「ランキングのための対策」と「エージェント対応のための対策」を分けて考えるべきタイミングに来ている。
③削除するかどうかは「読者」でなく「目的」で決める
「AIクローラーがほとんど読みに来ないなら削除すべきか」という問いには、目的次第で答えが変わる。検索順位のためなら、Googleは既に「無視する」と明言している——削除しても失うものはない。一方、開発者向けドキュメントサイトやコーディング支援ツールとの接点を持ちたいサイトなら、費用対効果がほぼゼロである限り残す判断に合理性がある。当サイトは後者の立場を取り、③の理由で維持を選んだ。
当サイトのself-proof状況（正直な自己開示）
✅ 実施済み: HTTP・HTTPS統合ログでの51日間実測（本稿・access.log + ssl_access.log統合集計、内部/スキャン/検索エンジン/AIクローラーの5カテゴリ仕分け）
✅ 実施済み: robots.txtとの比較実測（同一51日間・同一UA基準で、主要AIクローラーのrobots.txt到達1,227件 vs llms.txt到達4件を確認）
✅ 実施済み: 他社6社のllms.txt実在・サイズ確認（curl実測、Anthropicコーポレートサイトのルートには存在しないという発見を含む）
🔧 着手中: robots.txtへのAIクローラー個別ディレクティブ追加の検討（現状はUser-agent: *のみ。追加するかどうかは次回の判断材料として持ち越す）
三部作の系譜 ── archives/68 → 99 → 115
archives/68で設置し、archives/99で「HTTPSを見落として悲観的な結論を出し、独立監査で差し戻された」経緯ごと公開し、本稿で「Google公式の『効かない』宣言」と「他のAIも構造的に読みに来ていない」という二段の裏付けを重ねた。3本を通して見えるのは、施策の効果を追い続けることそのものが、記事のコンテンツになるという構造だ。答えが「効果は薄い」であっても、それを隠さず書き続けることが、self-proof-loopという連載の存在理由になっている。
まとめ ── 「読まれない」を受け止めた上で、何を残すか
51日間・89件のアクセスログを数え直して分かったのは、Googleが公式に「効かない」と言った以上のことだった。Google以外の主要AIクローラー（ClaudeBot・GPTBot・Bytespider・Amazonbot・PerplexityBot・OAI-SearchBot・CCBot）も、サイト全体では数千件規模でクロールしていながら、/llms.txtにはほとんど到達していない。一方で同じクローラーたちは、robots.txtという標準化された仕組みには律儀にアクセスしている。llms.txtは、検索ランキングにも、AIクローラーの自動巡回にも、今のところほとんど効いていない——それが51日間の正直な答え合わせだ。それでも当サイトはコストがほぼゼロであることと、Chrome Lighthouseが示すような別の入口（Agentic Browsing）が今後育つ可能性を理由に、削除ではなく維持を選ぶ。次の答え合わせは、robots.txtへのAIクローラー個別ディレクティブを追加した後か、あるいはAgentic Browsing関連の動きがもう一段進んだタイミングで書く。
関連 archives
- archives/68: llms.txtを当サイトで実際に設置した
- archives/69: AI Agentに引用される準備 ── llms.txtの次にやること
- archives/76: AIに表示された回数を知っているか ── GSC・GA4・Bing、3ツール立体計測
- archives/93: Cloudflareが「検証」の定義を変えた日
- archives/98: 1,238記事の8割が「土俵に上がっていない」ことに気づいた日
- archives/99: llms.txtを置いた1ヶ月後、正直に答え合わせ
一次情報出典
- Google Search Central「Google's Guide to Optimizing for Generative AI Features on Google Search」（Google、最終更新2026-07-10 UTC）
- Search Engine Journal「Google's Updated Guidance Now Says It's "Fine" To Use llms.txt For AI SEO」（Roger Montti、2026-06-17）
- Digital Applied「Google Says llms.txt Does Nothing for SEO Rankings」（2026-06-24）
