エグゼクティブサマリー
前回のレポートが立てたのは、ポリシーそのものをめぐる問いでした。世界で最も訪問されるサイトのうち、AI クローラーに対して「何が許され、何が許されないか」を実際に明示しているのはどれだけあるのか——そういう問いです。
今回の続編が見つめるのは、その一段下にある運用の問いです。そもそも、いまやポリシーを載せる土台として期待されている robots.txt は、どこまで当てにできるのでしょうか。
正直なところ、答えはあまり気分のいいものではありません。robots.txt が今も機能しているのは、公開されていて、低コストで、機械が読めて、クローラー側もすでに理解しているからです。とはいえ、当初の想定をはるかに超える役割まで背負わされてもいます。2026年には、SEO のクロール制御、サイトマップのインデックス、古い検索エンジン向けの拡張、AI 学習の拒否、Cloudflare が差し込むポリシー語彙、著作権の留保、そして将来の紛争を見据えた法的文言。これらすべてが、たった1枚のプレーンテキストの中に同居していることがあるのです。
これが、構成負債の正体です。
本レポートの土台になっているのは、元の AI クローラー調査で使った Tranco Top 10,000 のクロール結果です。10,000 ドメインのうち、読み取り可能な robots.txt を返したのは 6,638 ドメイン。別に 610 ドメインが 404 を返しました。プロトコル上、404 は暗黙の許可と解釈されます。したがって、ボットのアクセス可否を論じる母集団は 7,248 サイト、構成の複雑さを論じる対象は実ファイル 6,638 件、ということになります。
そこから浮かび上がった、とりわけ目を引く発見が6つあります。
-
ほとんどの
robots.txtは小さい。けれども右の裾は途方もなく複雑です。 中央値はわずか 834 バイト、31 行。それでも 1,005 ファイルは 5 KB 以上、273 ファイルは 20 KB 以上、28 ファイルは 100 KB 以上あり、サンプル中の最大は 248 KB に達します。 -
上位サイトの何百件もが、ポリシーのメモというより本番設定そのものに近いファイルを抱えています。 中央値のファイルに含まれる
Disallowディレクティブは 9 個。ところが 707 サイトはDisallowルールを 100 個以上、13 サイトは 1,000 個以上抱え、240 サイトはユーザーエージェント名を 50 個以上、110 サイトは 100 個以上も並べています。 -
プロトコルの逸脱は、机上の空論ではありません。 読み取り可能な 6,638 ファイルのうち、685 件に
Crawl-delay、303 件にHost、200 件にClean-param、9 件にRequest-rate、5 件にVisit-time、271 件に Cloudflare 風のContent-Signalが含まれます。これらは1つの整然とした標準の構成要素などではありません。積み重なったクローラーの慣習です。 -
Googlebot は別格扱いです。 分析対象 562 ドメインが、少なくとも1つの従来型検索クローラーをブロックしています。そのうち 404 件では、Googlebot は通しつつ、他の検索クローラーを少なくとも1つ閉め出していました。AI クローラーへの差別は中立的な生態系に突如現れたわけではなく、
robots.txtにはすでに検索エンジンの序列が刻み込まれていたのです。 -
AI ポリシーが、その負債をいっそう可視化します。 読み取り可能なファイル 1,377 件に AI ポリシー関連の文言があり、719 件に著作権・利用規約・ライセンス・許可に関する文言があり、501 件はその両方を備えています。ファイルは機械とのインターフェースであると同時に、法的なアーティファクトにもなりました。便利ですが、そのぶん脆いのです。
-
最もリスクの高いファイルが、必ずしも最も反 AI 的なファイルとは限りません。 EC、旅行、ソーシャル、金融、学術、ニュースは、それぞれ別の理由で複雑なファイルを生みます。クロール予算の制御、レガシーなパス、ユーザー生成コンテンツ、権利の留保、ボット別の例外。AI ルールは、もともと混み合っていた土台の上に、さらに重ねられているにすぎません。
主たる結論は、こうまとめられます。robots.txt は今も公開ウェブで最も重要なクローラーポリシーの表面である。だが、クローラーの識別、AI 利用の語彙、ポリシーの監査可能性がエコシステム全体で標準化されない限り、リスクの高い AI ガバナンスの土台としては心もとないままだ。
方法論
本レポートは、Tranco Top 10,000 ドメインの AI クローラーポリシーを分析した、元の Thunderbit 調査のデータセットをそのまま再利用しています。
入力資料は次のとおりです。
tranco_top10k.csv— 元の Tranco Top 10K ドメイン一覧。out/fetch_meta.csv— フェッチ状態、バイト数、スキーム、リダイレクト結果、エラーメタデータ。out/sites.csv— ドメイン、順位、カテゴリ、言語、robots.txtの状態。out/site_meta.csv— サイトごとの分析行。テンプレート分類、AI ブロックフラグ、ファイルサイズ、ボットポリシー要約フィールドを含みます。out/bot_status.csv— ドメインとクローラーごとの 1 行。各ボットがブロックされているか、特定ルールが存在するかを含みます。raw_robots/— ステータス200を返した 6,638 サイトのrobots.txt本文をキャッシュしたもの。
そのうえで今回の続編では、読み取り可能な robots.txt ファイルを1件ずつ、次の観点でスキャンしました。
- ファイルサイズと行数
- アクティブな非コメント行
User-agent、Disallow、Allow、Sitemapのディレクティブ数Crawl-delay、Host、Clean-param、Request-rate、Visit-timeなどのレガシーまたは非コアのディレクティブContent-Signal、llms.txt、AI、LLM、機械学習、TDM、2019/790を含む AI 時代の語彙- 著作権、利用規約、ライセンス、許可、権利留保の文言といった法的語彙
- Googlebot、Bingbot、DuckDuckBot、Slurp、Baiduspider、YandexBot に対する検索クローラーの扱い
さらに本レポートでは、トリアージ用の簡易な構成負債スコアも定義しました。ファイルサイズ、ユーザーエージェント数、Disallow 数、Allow 数、非標準ディレクティブ数、そして AI ポリシー文言と法的文言の混在を組み合わせたものです。これは正しさを測る普遍的な物差しを狙ったものではありません。保守・レビュー・解釈が難しくなりそうなファイルを拾い上げるための道具です。
派生テーブルとチャートは、すべて納品フォルダに収めてあります。
発見 1: 中央値のファイルは単純だが、裾はそうではない
上位ウェブに置かれた典型的な robots.txt は、今でも小ぶりなままです。
読み取り可能な 6,638 ファイル全体では、次のようになります。
| 指標 | 中央値 | P90 | P95 | P99 | 最大値 |
|---|---|---|---|---|---|
| ファイルサイズ | 834 バイト | 6.7 KB | 15.8 KB | 76.0 KB | 248.3 KB |
| 行数 | 31 | 238 | 332 | 1,008 | 4,998 |
| アクティブ行数 | 23 | 198 | 282 | 837 | 4,998 |
User-agent ディレクティブ | 1 | 21 | 39 | 137 | 823 |
Disallow ディレクティブ | 9 | 103 | 176 | 422 | 4,997 |
Allow ディレクティブ | 1 | 17 | 33 | 69 | 890 |
この分布がなぜ大事なのか。それは、robots.txt がしばしば、こんな短い宣言だと思い込まれているからです。
User-agent: *
Disallow: /private/
ところがその思い込みは、トラフィックの多いウェブのかなりの部分では、現実と食い違っています。
このデータセットで具体的に見てみましょう。
| 複雑度のしきい値 | サイト数 |
|---|---|
robots.txt が 5 KB 以上 | 1,005 |
| 20 KB 以上 | 273 |
| 100 KB 以上 | 28 |
User-agent ディレクティブが 50 個以上 | 240 |
User-agent ディレクティブが 100 個以上 | 110 |
Disallow ディレクティブが 100 個以上 | 707 |
Disallow ディレクティブが 1,000 個以上 | 13 |
Allow ディレクティブが 100 個以上 | 40 |
最も大きく、最も入り組んだファイルは、研究室の標本のような珍品ではありません。実際にトラフィックの集まる資産が、その正体です。
| ドメイン | 順位 | カテゴリ | バイト数 | User-agent | Disallow | Allow |
|---|---|---|---|---|---|---|
linkedin.com | 17 | social | 114,341 | 76 | 4,184 | 281 |
runescape.com | 5,226 | unknown | 113,393 | 1 | 4,997 | 0 |
academia.edu | 832 | academia | 57,384 | 63 | 2,044 | 227 |
etsy.com | 286 | ecommerce | 51,320 | 3 | 1,621 | 120 |
thepaper.cn | 9,395 | news | 56,867 | 1 | 1,496 | 0 |
opentable.com | 4,137 | unknown | 70,494 | 32 | 1,683 | 176 |
alfabank.ru | 2,625 | finance | 73,158 | 2 | 1,566 | 133 |
これらはもはや、ポリシーのスローガンというより本番のルーティング表です。何年分もの製品公開、レガシーなパス、ブロックされたパラメータパターン、クローラー例外、SEO 実験、CDN の判断、そして今や AI クローラーのルールまで——その一切が、まるごとエンコードされています。
裾が太いのは、AI のせいばかりではありません。20 KB 以上の 273 ファイルを見ても、AI ポリシー文言があるのは 131 件、ないのは 142 件です。Disallow ディレクティブを 100 個以上持つ 707 ファイルでさえ、AI ポリシー文言があるのはたった 207 件。つまり、大きなファイル問題を生んだ犯人は AI ではないのです。何年も前から続く普通のウェブ運用が、パスルールやサイトマップ参照、クローラー例外でファイルを膨らませてきた。それが真相です。
ここで押さえたいのは、保守のしやすさを決めるのは意図だけではなく、ファイルの形でもある、という点です。直接的な AI ブロックしか書いていない小さなファイルなら、監査も楽でしょう。逆に、AI について一言も触れていない 70 KB の EC や旅行のファイルは、それでも読み解くのに骨が折れることがあります。本当のリスクは「巨大ファイルがすべて間違っている」ことではありません。実際に効いているポリシーが、担当者の手に負えないほど入り組んでしまうことなのです。
運用上のリスクは、はっきりしています。robots.txt が膨れ上がるほど、公開者も、プラットフォームエンジニアも、法務も、SEO リードも、いちばん基本的な問いに答えにくくなります。このファイルは、結局のところ何を許可しているのか。
その問いは、もう自明ではなくなりました。RFC 風のパースでは、クローラーは User-agent: * よりも具体的なユーザーエージェントグループを優先してマッチさせることがあります。より長いパスの一致が短い一致を上書きしうるため、Allow と Disallow は優先順位の上で互いに干渉します。広く網をかけた全面禁止ルールが、そのファイルを書いた当時はまだ存在しなかった新しいクローラーを、知らぬ間に巻き込んでしまうこともあります。
30 行のファイルなら、人間の頭でも追えるでしょう。けれど、数十もの名前付きボットが並ぶ 4,000 行のファイルとなれば、誰一人としてそれを追うべきではありません。
発見 2: robots.txt はクロール規則以上のものを背負っている
AI クローラーをめぐる論争で robots.txt は政治的に脚光を浴びましたが、その下にあるファイルは、とっくに無関係な責務を積み上げていました。
いまどきの主要サイトの robots.txt には、こんなものが入りえます。
- クローラーパスの制御
- サイトマップの発見
- 検索エンジン固有の拡張
- クロール速度のヒント
- ホスト正規化のヒント
- URL パラメータ整理のヒント
- CDN が注入したポリシー語彙
- 著作権留保の文言
- AI 学習の拒否
- 人間向けの法的コメント
このレイヤーの積み重なりを、データセットがくっきり映し出しています。
| シグナル | ファイル数 | 読み取り可能ファイルに占める割合 |
|---|---|---|
Crawl-delay | 685 | 10.3% |
Host | 303 | 4.6% |
Clean-param | 200 | 3.0% |
Content-Signal | 271 | 4.1% |
Request-rate | 9 | 0.1% |
Visit-time | 5 | 0.1% |
llms.txt への言及 | 83 | 1.3% |
| 著作権、利用規約、ライセンス、許可に関する文言 | 719 | 10.8% |
| AI ポリシー文言 | 1,377 | 20.7% |
これらのディレクティブの素性はばらばらです。特定のクローラーには広く認識されているものもあれば、レガシーな慣習もあり、ベンダー固有のものもあります。さらに言えば、実態はクローラーディレクティブですらなく、コメントに紛れ込んだ法務文言や製品文言にすぎないものまで混じっています。
これが、プロトコルの逸脱というやつです。
わかりやすい例が Crawl-delay でしょう。多くのサイト運営者にはなじみがある一方で、大手クローラー間での対応はばらばらです。Host と Clean-param は、歴史的に Yandex の挙動と結びついてきました。Content-Signal は Cloudflare の AI 時代向けポリシー語彙の一部です。llms.txt は隣接する探索フォーマットとして提案されたもので、誰もが尊重する標準ではありません。それでもこれらは、古典的な User-agent と Disallow ルールの隣に、しばしば同じファイル内に並んで現れます。
数字もまた、古い慣習と新しい慣習がいま同居していることを物語ります。Crawl-delay は 685 ファイルに見られ、Content-Signal の 271 ファイルの2倍以上です。Host は 303 ファイル、Clean-param は 200 ファイルにあり、おおむね検索時代の名残を映しています。AI 検索界隈であれほど話題にのぼる llms.txt でさえ、言及されている読み取り可能ファイルは 83 件しかありません。生きたウェブは1つの語彙へ収束しているのではなく、語彙を積み重ねているのです。
問題は、どれか1つの拡張が間違っていることではありません。そのファイルが、複数の重なり合うガバナンス体系を詰め込む、版管理されていない器になってしまっていることです。
そこから、3種類の負債が生まれます。
- 意味論的負債。 クローラーによって、同じファイルの読み方が変わることがあります。
- 所有権の負債。 SEO、法務、インフラ、セキュリティ、プロダクトの各チームに編集する理由はあっても、ポリシー全体を所有するチームが誰もいない、ということが起こります。
- 監査の負債。 サイトはいかにも意図的に見えるポリシーを掲げていても、実際の挙動を決めるのは結局パーサーだけです。
AI がこれをいっそう重くするのは、賭け金が引き上げられたからです。レガシーなクロール速度のヒントが無視されたところで、せいぜい余分なトラフィックが増える程度でしょう。ところが AI 学習の拒否が曖昧だと、それは著作権やライセンスをめぐる紛争で、証拠として持ち出されかねないのです。
発見 3: このファイルは機械とのインターフェースであると同時に法的アーティファクトになった
元の AI クローラーレポートでは、分析可能なサイトの 17.0% が AI 専用の明示的ルールを書いていることが示されました。今回の続編では、それらのポリシーが上乗せするテキスト上の負担に目を向けます。
読み取り可能な robots.txt ファイル 6,638 件のうち、
- 1,377 件に AI ポリシー文言があり
- 719 件に著作権、利用規約、ライセンス、権利、許可に関する文言があり
- 271 件に
Content-Signalがあり - 83 件に
llms.txtへの言及があります
重なり方を見ると、話はさらに面白くなってきます。
| テキストパターン | ファイル数 |
|---|---|
| AI ポリシー文言と法的/権利文言の両方 | 501 |
| 法的/権利文言はあるが AI ポリシー文言はない | 218 |
| AI ポリシー文言はあるが法的/権利文言はない | 876 |
法的/権利文言を伴う Content-Signal | 242 |
| 明示的な AI ブロックと法的/権利文言 | 424 |
これは、新しい種類のファイルです。
従来の robots.txt の宛先は、クローラーでした。ところが法的な前文を含む robots.txt は、少なくとも4つの相手に、同時に語りかけています。
- 機械可読なディレクティブを必要とするクローラー運営者
- ポリシーのシグナルを必要とする検索・AI ベンダー
- 権利留保をはっきり示したい法務担当者
- 意図の証拠としてコメントを読むかもしれない、将来の監査人、裁判所、記者
この多重オーディエンス設計こそが、一部のファイルをいまやポリシー文書のように読ませる理由です。けれど同時に、クローラーが解析できるものと、人間の法務担当者が宣言したいものとの、きれいな線引きをも曖昧にしてしまいます。
AI ポリシー文言はあるが法的語彙はない 876 ファイルの多くは、機械向けのポリシーファイルです。中身はボット名、Disallow ブロック、テンプレート文言が中心。一方、AI と法的文言の両方を備える 501 ファイルは別物で、クローラーへの指示と権利の留保を、一度に済ませようとしています。法的文言はあるが AI 語彙はない 218 ファイルは、このパターンが LLM から始まったものではないことを示します。robots.txt は以前から、利用条件、許可の境界、権利の主張を書き込む場所として使われていたのです。
たとえば、コメントには「機械学習を禁止する」と書いてあるのに、実際のディレクティブブロックは既知のユーザーエージェントの一部しか禁じていない、ということがあります。あるサイトは全体として権利を主張しつつ、挙げているクローラー名はほんの数個だけ、ということも。CDN のテンプレートが、運用者が手で書いた覚えのない法的文言に、AI 関連語彙を勝手に注入することもあります。広い User-agent: * ルールを書いた結果、新しいクローラーをうっかり閉め出してしまう、ということまで起こります。
ガバナンスの視点で見れば、robots.txt は公開されていて機械可読であるがゆえに魅力的になりました。しかし、そこに乗るポリシーが増えるほど、その限界が問題として顔を出してきます。
- ある特定のポリシーが、権利者によって確認されたものなのか、インフラから継承されたものなのかを示す、認証の層がありません。
- ネイティブな版管理がありません。
- 学習、取得、検索インデックス、要約、キャッシュ、モデル評価といった、意図された用途を示す構造化フィールドがありません。
- AI クローラーの識別子に関する、誰もが参照できるレジストリがありません。
- 強制力がありません。
だからといって、このファイルが無意味になるわけではありません。脆くなる、というだけのことです。
より正確な見立ては、robots.txt が通知レイヤーになりつつある、というものでしょう。好みと意図を公開し、誰でも検査できる形で示す層です。それ自体で完結する権利管理システムでは、決してありません。
発見 4: AI が来る前から、検索はすでに平等ではなかった
元のレポートで最も強かった発見の1つは、多くの公開者が AI 学習クローラーと検索クローラーを区別している、という事実でした。CCBot、GPTBot、Google-Extended はブロックしつつ、Google 検索での見え方は守る、というやり方です。
今回の続編は、そこにもう1点を付け加えます。従来の検索クローラー同士でさえ、平等には扱われていない、という点です。
確認した検索クローラーは6つです。
- Googlebot
- Bingbot
- DuckDuckBot
- Slurp
- Baiduspider
- YandexBot
分析可能な 7,248 サイト全体では、こうなります。
| 検索クローラーの扱い | サイト数 |
|---|---|
| 少なくとも 1 つの検索クローラーをブロック | 562 |
| Googlebot は許可しつつ、少なくとも 1 つの他の検索クローラーをブロック | 404 |
| 確認した 6 つすべての検索クローラーをブロック | 152 |
ブロックされたボットの数にも、はっきりした偏りがあります。
| 検索クローラー | ブロックしているサイト数 |
|---|---|
| Baiduspider | 424 |
| YandexBot | 393 |
| Slurp | 255 |
| DuckDuckBot | 231 |
| Bingbot | 204 |
| Googlebot | 158 |
このセットで、最もブロックされにくいクローラーは Googlebot です。Baiduspider と YandexBot ははるかに頻繁に閉め出されており、その多くで Googlebot は通したまま。Googlebot は許可しつつ別の検索クローラーをブロックしている 404 サイトのうち、269 件は Baiduspider を、240 件は YandexBot を閉め出しています。
知名度の高い例も並べておきましょう。
| ドメイン | Googlebot は許可しつつブロックされている検索クローラー |
|---|---|
facebook.com | Baiduspider, YandexBot |
apple.com | Baiduspider |
twitter.com | DuckDuckBot, Slurp, Baiduspider, YandexBot |
netflix.com | DuckDuckBot, Slurp |
x.com | DuckDuckBot, Slurp, Baiduspider, YandexBot |
tiktok.com | Baiduspider |
baidu.com | Bingbot, DuckDuckBot, Slurp, YandexBot |
washingtonpost.com | YandexBot |
wsj.com | YandexBot |
bilibili.com | DuckDuckBot, Slurp, YandexBot |
temu.com | Slurp |
t-mobile.com | Baiduspider, YandexBot |
これが AI 論争にとって重要なのは、LLM クローラーが現れるよりずっと前から、robots.txt が中立で普遍的なアクセスのプロトコルなどではなかったことを示すからです。公開ウェブには、最初から序列が存在していました。
- Googlebot は、Google 検索トラフィックを失う痛手が大きすぎるため、多くの場合守られます。
- 地域別や競合のクローラーは、もっと気軽にブロックされます。
- 一部のサイトは、検索クローラーへのアクセスを市場別・ベンダー別の判断として扱っています。
AI クローラーは、差別化されたアクセスがとっくに当たり前になっていた生態系へ、後から足を踏み入れたわけです。
だからこそ、このポリシー転換は腑に落ちます。公開者が「Google-Extended はブロック、Googlebot は許可」と書くとき、新しい差別の形を発明しているのではありません。配信は守り、抽出は抑えるという古いパターンを、新しいクローラー種別に当てはめているだけなのです。
未解決なのは、その古いパターンがどこまで通用するのか、という点でしょう。検索の世界では、経済的に重要なクローラーは数えるほどしかいませんでした。AI では、クローラーの識別がモデルベンダー、検索取得ボット、データブローカー、学術クローラー、合成ブラウザエージェント、インフラ層のフェッチャーへと細かく枝分かれしています。目的ベースのシグナルではなく名前付きユーザーエージェントに頼り続ける限り、その数はこの先も増え続けるでしょう。
これこそが、構成負債の複利というものです。
発見 5: 複雑さはセクターによって異なるが、AI ブロック率の違いとは一致しない
元のレポートでは、AI ブロックに大きなセクター差があることが示されました。ニュースは高い割合でブロックし、通信、政府、SaaS は低い割合だった、というものです。
構成の複雑さは、これとは別の切り口でウェブを分けます。
読み取り可能な robots.txt が十分にあり、比較に耐える主要カテゴリで見ると、こうなります。
| カテゴリ | n | 中央値バイト数 | P90 バイト数 | 中央値 Disallow | P90 Disallow | 中央値 User-agent | P90 User-agent |
|---|---|---|---|---|---|---|---|
| ecommerce | 215 | 1,738 | 10,388 | 37 | 164 | 3 | 49 |
| travel | 63 | 2,074 | 27,368 | 41 | 779 | 5 | 34 |
| news | 647 | 1,534 | 7,039 | 19 | 114 | 6 | 68 |
| finance | 121 | 1,002 | 8,337 | 17 | 132 | 2 | 23 |
| academia | 253 | 839 | 3,959 | 14 | 75 | 1 | 11 |
| government | 151 | 1,227 | 3,263 | 13 | 46 | 1 | 4 |
| SaaS | 368 | 485 | 12,606 | 4 | 56 | 1 | 10 |
| dev tools | 119 | 273 | 9,255 | 3 | 58 | 1 | 10 |
カテゴリ別 P90 Disallow のチャートをここに挿入<<<<<<<<<<<<<<<<<<<<<<<<<
ニュースが複雑なのは、明示的な AI ルールと法的文言を書き込むという、政治的な理由からです。一方で ecommerce と travel が複雑になるのは、大量の商品/施設カタログ、ファセットナビゲーション、検索結果ページ、フィルター、アカウント用パス、パラメータ付き URL を抱え込むという、運用上の理由からです。
この違いが、ここで効いてきます。
最もわかりやすい例が、旅行です。このカテゴリで切り出せた読み取り可能ファイルは 63 件しかありませんが、P90 の robots.txt は 27.4 KB、P90 の Disallow 数は 779 と、ニュースを大きく上回ります。旅行サイトの AI ポリシーが成熟している、という話ではありません。日付検索、空室/空席ページ、レビューのページ分割、予約フロー、フィルターの組み合わせ、地域別在庫パス——クローラー運営者がうっかりクロール予算を浪費しやすい面が、それだけ多いということなのです。
SaaS は、逆の意味で意外でした。中央値のファイルはわずか 485 バイトなのに、P90 のファイルは 12.6 KB へと跳ね上がります。大半の SaaS サイトは開放的で軽量ですが、一部は長いパス制御ファイルを抱えています。ドキュメント、ログイン面、アプリのルート、マーケティングページが、同じドメイン下に同居しているためです。
ニュースは、運用上は中間に位置しつつ、政治的には上位です。この表では P90 の User-agent 数が 68 で、ecommerce、travel、finance、academia、government、SaaS、dev tools のどれより高い値です。これは単なるパス整備ではなく、ボット固有ポリシーが存在することの表れです。
公開者の robots.txt は、権利ポリシーのために複雑になることがあります。マーケットプレイスのファイルは、クロール予算管理のために複雑になります。大学のファイルは、何千ものレガシーなパスが1つのドメイン下に積み上がった結果として複雑になります。ソーシャルプラットフォームのファイルは、桁外れの規模で一部の面を公開し、他を抑えなければならないために複雑になります。
そして AI ポリシーは、そのすべての上に重なります。既存の複雑さの理由を、置き換えるものではありません。
ここから、AI 時代の robots.txt ガバナンスが、万能のブロックリストでは片づかない理由も見えてきます。土台となるファイルの役割そのものが、違うからです。
- ecommerce サイトは、重複パスと在庫面を管理します。
- travel サイトは、一覧、カレンダー、レビュー、動的検索ページを管理します。
- news サイトは、著作権、アーカイブ、ライセンスの姿勢を管理します。
- SaaS と開発ツールのサイトは、しばしば AI による可視性を歓迎します。
- 政府機関は、公開アクセスを確保しつつ、排除すべき機微なシステムを抱えていることもあります。
- ソーシャルプラットフォームは、ユーザー生成コンテンツ、プロフィール面、悪用対策を管理します。
同じ AI クローラールールでも、置かれた環境しだいで意味は変わってくるのです。
発見 6: 構成負債インデックスは、道徳的失敗ではなくレビューリスクを示す
この分析では、レビューが難しそうな robots.txt ファイルを拾い上げるために、簡単な構成負債スコアを組みました。
このスコアが重く見るのは、次の要素です。
- ファイルサイズ
User-agentディレクティブ数Disallowディレクティブ数Allowディレクティブ数- 非コアディレクティブ数
- AI ポリシー文言の有無
- 明示的な AI ブロックと法的または著作権文言の混在
これは正しさのスコアではありません。複雑なファイルが完璧に意図どおりであることもあれば、単純なファイルが間違っていることもあります。狙いはあくまでトリアージ。大きく、ポリシー色が強く、ボット固有で、例外だらけのファイルほど、より丁寧なレビューが要る、ということです。
スコア分布は急峻です。読み取り可能ファイルの中央値スコアは 1.74、P90 は 13.29、P95 は 15.00、P99 は 27.57。スコアが 15 以上のファイルは 366 件、25 以上は 80 件、30 以上はわずか 41 件です。これが実際のレビューキューになります。すべてのサイトにガバナンスプロジェクトが要るわけではありませんが、上位の裾には必要です。
カテゴリ別に見ても、「AI ブロッカー」という単一のラベルが、いかに平板すぎるかがわかります。
| カテゴリ | 中央値スコア | P90 スコア |
|---|---|---|
| travel | 4.92 | 28.94 |
| search | 2.97 | 24.23 |
| social | 2.25 | 15.00 |
| news | 4.91 | 14.92 |
| finance | 1.67 | 12.61 |
| SaaS | 0.98 | 11.85 |
| ecommerce | 3.88 | 10.87 |
| government | 1.57 | 6.38 |
travel と search の P90 スコアが最も高いのは、少数のファイルが極端に大きく、ルールだらけになるからです。news が中央値スコアで上位に食い込むのは、カテゴリ全体にわたってポリシー文言とボット固有の扱いが多いから。ecommerce は Disallow の中央値こそ高いものの、P90 の負債スコアは travel より低めです。複雑さが、混在したポリシー/法務シグナルではなく、パスルールに集中しているためです。
このデータセットで最もスコアの高いファイルには、こんなものがあります。
| ドメイン | 高スコアの理由 |
|---|---|
linkedin.com | 非常に大きいファイル、何千ものパスルール、多数の名前付きユーザーエージェント、明示的な AI ポリシー文言 |
lnkd.in | LinkedIn の短縮リンク基盤と同じポリシー面 |
fragrantica.com | 何百もの名前付きユーザーエージェントブロックと AI ポリシー文言 |
sovcombank.ru | 何百ものユーザーエージェントブロックと法的/ポリシー文言 |
academia.edu | 大規模な allow/disallow マトリクスと明示的な AI ブロックポリシー |
opentable.com | 大規模なパスルールセット、多数のサイトマップディレクティブ、AI 関連ポリシー面 |
etsy.com | 1,600 件超の Disallow ルールを持つ大規模な ecommerce パス制御ファイル |
runescape.com | 1 つのユーザーエージェントグループ下にほぼ 5,000 個の Disallow ディレクティブ |
複雑だからといって、これらのファイルを嗤うべきではありません。その複雑さは、たいてい本物のビジネス上の要請を映しています。とはいえ、こうも言えるのです。robots.txt ポリシーにも、他の本番設定と同じエンジニアリングの規律が要る、と。
- 所有権を明示すること
- 変更をレビューすること
- 生成セクションにはラベルを付けること
- できる限り、法的コメントを機械ディレクティブから分離すること
- 重要なクローラーについて、期待どおりのボットアクセスをテストで検証すること
- 版履歴を残すこと
- 古いボット名は廃止するか、文書化すること
- AI 学習、AI 取得、検索インデックス、アーカイブを、それぞれ別の目的として扱うこと
なかでも最後の点が、いちばん重要です。現在の文法はユーザーエージェント先行——つまり、サイト運営者にボット名を挙げさせる方式です。けれど AI 時代に求められるのは目的先行、すなわち、どの用途を許すのかを示させる方式なのです。
この2つは、同じではありません。
そのズレこそが、長いブロックリストが長持ちしない理由です。公開者は今日、GPTBot、ClaudeBot、CCBot、Google-Extended、Bytespider、Applebot-Extended、PerplexityBot を書き足せます。けれど、次のクローラー名、取得エージェント、データセットブローカーは、明日にも現れる。目的ベースのポリシーであれば、robots.txt をボットのアドレス帳に変えてしまうことなく、「検索インデックスは可、AI 学習は不可、ユーザー起点の取得は場合による」と伝えられるのです。
AI ガバナンスにとって何を意味するか
公開された議論では、robots.txt は意味があるか、もはや時代遅れか、その二択で語られがちです。データが指し示すのは、もっと実用的な答えです。
robots.txt は意味がある。けれど、役割を背負いすぎている。
意味があるのは、主要サイトが現に使っていて、クローラーが解析でき、研究者、記者、ベンダー、裁判所にとってポリシーの選択が目に見えるからです。元のレポートでは、分析可能な上位サイトの 17.0% が意図的な AI 専用ルールを持っていました。これは象徴的なノイズなどではありません。
役割を背負いすぎているのは、このファイルがボットのアクセス以上のことを、表現しなければならなくなったからです。
- 「このコンテンツで学習しないでください」
- 「このコンテンツは検索インデックスに使ってもよい」
- 「このコンテンツはライブ取得に使ってもよい」
- 「キャッシュ済みデータセットは作成してはいけない」
- 「この法的留保は EU のテキスト・データマイニング法の下で適用される」
- 「この CDN 管理サイトは
Content-Signal: ai-train=noを送る」 - 「このサイトは Googlebot は欲しいが YandexBot は欲しくない」
- 「このサイトには、クロールしてほしくない旧 URL パスが 1,000 本ある」
この文法は、そこまで多くの役割を背負うようには、設計されていませんでした。
負債を減らすには、3つの変更が要ります。
-
クローラー識別子にレジストリが必要です。 サイト運営者が、
GPTBot、ClaudeBot、anthropic-ai、CCBot、Google-Extended、Applebot-Extended、Bytespider、OAI-SearchBot、ChatGPT-Userといった増え続ける一覧を、自前で追いかけ続ける必要があってはなりません。レジストリがなければ、ポリシーはいつまでもクローラーの挙動に後れを取ります。 -
AI 利用には構造化された語彙が必要です。 学習、取得、インデックス、要約、データセット再販、モデル評価、ユーザー起点のブラウジングは、それぞれ別の用途です。ベンダー固有のユーザーエージェント名で言い表すのは、脆すぎます。
-
ポリシーには監査可能性が必要です。 ウェブには、権利者が確認した手書きの権利留保と、継承された CDN デフォルト、生成された CMS テンプレート、古いレガシー規則、うっかり紛れ込んだ catch-all ブロックとを、見分ける仕組みが要ります。その違いは、信頼にも訴訟にもかかわってきます。
これは、robots.txt をすぐに置き換えるべきだという意味ではありません。より良い道筋は、階層化です。robots.txt は発見と互換性の表面として残しつつ、AI 専用の用途向けに、隣接する機械可読ポリシーを標準化していくのです。
llms.txt はその試みの1つですが、このデータセットでの採用はまだごくわずかで、読み取り可能ファイルで言及されているのは 83 件にとどまります。Content-Signal は Cloudflare がインフラ経由で配布できるぶん、より目立ちます。このスキャンで Content-Signal を含む 271 ファイルは、すべて AI ポリシー文言とも一致していました。それでも、配布されていることと、合意されていることは別物です。持続する解決策には、地味な標準化の仕組みが要るでしょう。明確なフィールド、明確な意味、クローラーのコミットメント、公開テストスイートです。
結論
AI クローラーをめぐる争いによって、robots.txt はガバナンスのアーティファクトになりました。それは便利でもあり、危うくもあります。
便利なのは、このファイルが公開されているからです。研究者は監査でき、公開者は変更でき、クローラーは従え、裁判所は読め、インフラ提供者は大規模に展開できます。
危ういのは、背負いすぎているからです。
Tranco Top 10K における中央値の robots.txt ファイルは、今でも人間が理解できるほど小さいままです。けれど高トラフィックなウェブの裾には、大きく、古く、多層で、ベンダー固有で、法的含意の重いファイルがあふれています。何百ものサイトが、単純なクローラーヒントというより、本番のポリシーシステムとして robots.txt を回しているのです。
中心的な教訓は、robots.txt が失敗した、ということではありません。ウェブが、それをリファクタリングしないまま昇格させてしまった、ということです。
AI アクセス・ポリシーを機械可読な公開宣言に委ねるなら、次に必要なのは、さらに長いブロックリストではありません。より良いポリシー基盤です。目的ベースの許可、安定したクローラー識別、レビュー可能なテンプレート、監査ログ——それらこそが要るのです。
それまでのあいだ、公開ウェブの AI ガバナンス層は、これほどの重さを運ぶようには作られていなかった1枚のテキストファイルの上に、置かれ続けることになります。
再現性に関する注記
納品フォルダには、次のものが含まれます。
source_data/analysis.json— 元の集計指標。source_data/site_meta.csv— 元のサイト別分析テーブル。source_data/bot_status.csv— 元のドメイン×ボットのポリシーテーブル。source_data/fetch_meta.csv— 元のフェッチメタデータ。source_data/sites.csv— 元のドメイン/カテゴリ/状態テーブル。derived_data/robots_complexity_by_site.csv— このレポートのために生成したサイト別複雑度指標。derived_data/search_bot_treatment.csv— 検索クローラーの扱いマトリクス。derived_data/category_complexity_summary.csv— カテゴリ別複雑度サマリー。derived_data/top_config_debt_sites.csv— 上記のトリアージスコアで上位のサイト。derived_data/summary_metrics.json— このレポートで引用したすべての主要指標。
方法論の修正、データセットの問題、追加分析の提案は support@thunderbit.com までお寄せください。歓迎します。このレポートは、Thunderbit が持ついかなる商業的立場からも独立して公開されています。私たちは AI 搭載のウェブスクレイパーを開発しており、公開ウェブ上で robots.txt が意味のある機械可読な契約として生き続けることに、構造的な利害を持っています。本レポートのデータは、それ自体で完結しています。— Thunderbit 研究チーム、2026年5月。
AIウェブスクレイピングに Thunderbit を試す Get Started Free
