3つのファイル、3つの役割、そして混乱のコスト
最近、運用者のSlackやマーケティングのニュースレターを覗いていれば、かつてサイトマップを追加するよう勧められたのと同じ調子で「llms.txt を追加しなさい」と言われたことがあるかもしれません。その助言はたいてい詳細さも正確さも欠いています。ある人は llms.txt を入れれば ChatGPT に引用されると言い、別の人はクロールを制御できるかのように示唆します。どちらも事実ではありません。
ここ数年で、似た名前の3つのファイルが登場しましたが、それぞれが解決する問題は異なります。
- robots.txt は、クローラーがそもそもページを取得できるかどうかを制御します。1994年から存在し、正当な運用者がきちんと従うという意味で、実際の効力があります。
- ai.txt は、AIの学習を対象とした許諾とライセンスの表明です。何に同意し、何に同意しないかを運用者に伝えます。何かをブロックするものではありません。
- llms.txt は、AIコーディングエージェントなどのツール向けに整備されたインデックスです。開発者向けエージェントに、どのドキュメントが重要で、どこにあるのかを伝えます。クロール指示でも引用リクエストでもありません。
これらを混同するとコストがかかります。間違ったボットをブロックすればAI Overviews での可視性を失います。学習を止めるつもりで間違ったファイルを信頼すれば、結局誰かのデータセットに含まれてしまいます。ブログがランキングを上げると書いていたから llms.txt を追加すれば、ランキングシグナルはゼロのまま保守の手間だけが増えます。
AIクローラー向けの robots.txt:2026年に実際に機能するもの
3つのファイルのうち、主要なAIクローラー運用者から広範かつ意図的なサポートを受けているのは robots.txt だけです。OpenAI、Anthropic、Google、Meta、Common Crawl、Perplexity、Apple はいずれもユーザーエージェント文字列と、robots.txt でブロックする方法を公開しています。法的拘束力はありませんが、主要な運用者は実際に指示に従っており、違反が発覚すれば広報上の大事故になりがちです。
2026年に実際に知っておくべきユーザーエージェント一覧は次のとおりです。
| ボット名 | 運用者 | 用途 | Disallow ディレクティブ |
|---|---|---|---|
| GPTBot | OpenAI | ChatGPT の学習データ | User-agent: GPTBot |
| OAI-SearchBot | OpenAI | ChatGPT 検索結果向けのインデックス | User-agent: OAI-SearchBot |
| ChatGPT-User | OpenAI | ユーザー起点の取得(ブラウジング) | User-agent: ChatGPT-User |
| ClaudeBot | Anthropic | Claude の学習データ | User-agent: ClaudeBot |
| Claude-SearchBot | Anthropic | Claude 検索向けのインデックス | User-agent: Claude-SearchBot |
| Google-Extended | Gemini および Vertex AI の学習 | User-agent: Google-Extended | |
| CCBot | Common Crawl | 多くのモデルに供給されるオープンウェブアーカイブ | User-agent: CCBot |
| Meta-ExternalAgent | Meta | Llama および Meta AI の学習データ | User-agent: Meta-ExternalAgent |
| Bytespider | ByteDance | TikTok および Doubao の学習データ | User-agent: Bytespider |
| PerplexityBot | Perplexity | Perplexity Answers 向けのインデックス | User-agent: PerplexityBot |
| Applebot-Extended | Apple | Apple Intelligence の学習 | User-agent: Applebot-Extended |
ブロックを始める前に押さえておくべき点がいくつかあります。
学習と取得は別の仕事です。 GPTBot はモデルを学習させます。ChatGPT-User は、ユーザーが ChatGPT に明示的にページを読むよう頼んだときにそのページを取得します。GPTBot はブロックしつつ ChatGPT-User はブロックしないでおけば、学習からはオプトアウトしながら、ユーザーがあなたのリンクを ChatGPT に投げたときには読めるままにできます。
検索ボットは別物です。 OAI-SearchBot や PerplexityBot は学習ではなく検索取得のためにクロールします。これらをブロックすると、それぞれのプロダクトの検索結果から外れます。ChatGPT や Perplexity に引用されたいなら、これらのボットには手を出さないでください。
Google-Extended は Gemini の学習のみのオプトアウトです。 これを Disallow しても通常の Googlebot や Google検索のランキングには影響しません。検索流入を失わずに学習からオプトアウトできるよう、出版者向けに別のユーザーエージェントとして用意されています。
学習データになりたくはないが、AIでの可視性は確保したいコンテンツサイトにとって、妥当な初期設定は次のような形になります。
# Block training bots
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Meta-ExternalAgent
Disallow: /
User-agent: Bytespider
Disallow: /
User-agent: Applebot-Extended
Disallow: /
# Allow search and user-fetch bots
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
学習ボットはブロックしつつ取得系や検索系のボットは許可するというこのパターンは、出版者の間で一般的になりつつあります。Originality.ai のトラッキングによれば、世界のトップニュースメディアの88%が少なくとも1つの主要なAI学習クローラーをブロックしているとのことです。コマースやSaaSサイトでは計算が異なります。学習セットに入ることがモデル出力におけるブランド想起に役立つため、多くは学習ボットを開放したままにしています。
ai.txt:許諾とライセンスのレイヤー
ai.txt はまた別の存在です。Have I Been Trained を手掛けるチームである Spawning AI が、構造化された機械可読な形で学習に関する意向を表明する標準化ファイルとして提案しました。意図はクローラーをブロックすることではなく、同意を宣言することです。
最小限の ai.txt はおおよそ次のようになります。
User-Agent: *
Disallow: images/
Disallow: video/
Disallow: text/
Spawning の仕様はパスではなくコンテンツタイプを使い、「自分の画像が学習に使われることには同意しない」というシグナルを送ります。このファイルは、誠実な学習運用者、データセットのキュレーター、そして(理論的には)誰がオプトアウトしたかを知りたい監査者に読まれることを想定しています。
2026年の ai.txt について、いくつか率直な観察を挙げます。
- 採用は限定的です。 ほとんどのサイトには存在しません。読み手の中心はデータセットのキュレーターであり、メインストリームのクローラーエンジニアではないため、遵守のフィードバックループも遅くなります。
- 障壁ではなくシグナルです。 ai.txt は取得を防止しません。意向を表明するものです。ai.txt を無視するクローラーは技術的には何も間違っていません。倫理的に疑問があるだけです。
- robots.txt を補完するものです。 robots.txt は「クロールするな」と言い、ai.txt は「クロールするなら、これに使ってよい」と言います。
- クリエイター中心のサイトほど重要になります。 画像ホスト、アートポートフォリオ、音楽サイト、ストックプラットフォームでは、ライセンスの問題がより切実なため、ai.txt を使う可能性が高くなります。
「学習への非同意を表明した」と主張できることが重要なら、ai.txt を追加する価値はあります。5分で済む変更です。アクセス制御だけが目的なら、robots.txt の方が役立ちます。
llms.txt:開発者向けディスカバリーファイル
ここからは、最もハイプが大きく、最も誤解されているファイルです。
llms.txt は2024年9月に Jeremy Howard によって提案され、仕様は llmstxt.org に置かれています。その目的は狭く特定的です。ドメインのルートに置かれるマークダウンファイルで、AIコーディングエージェント(Cursor、Claude Code、Devin など)にドキュメントの整備されたマップを提供します。フォーマットは次のような形です。
# My Project
> A short description of the project so an LLM has context.
## Docs
- [Getting Started](https://example.com/docs/getting-started.md): Quick setup
- [API Reference](https://example.com/docs/api.md): Full API surface
- [Configuration](https://example.com/docs/config.md): Config options
## Optional
- [Changelog](https://example.com/changelog.md): Release notes
フォーマットは意図的にシンプルです。H1(プロジェクト名)、引用ブロック(説明)、その後にリンクのセクションが続きます。各リンクはページのマークダウン版を指します。llms.txt を読むエージェントは、HTML全体、サイドバー、ナビゲーションを解析することなく、プロジェクトが何をしていてどこに正規のドキュメントがあるかを素早く理解できます。
Mintlify と Anthropic はこれを llms-full.txt で拡張しました。これはすべてをインライン化したバージョンです。別ファイルにリンクするのではなく、llms-full.txt にはドキュメント全体のマークダウンが1つのドキュメントに収められています。Mintlify のこのファイルの解説によれば、ユースケースはこうです。コーディングエージェントがあなたのライブラリについて推論する際、1つのファイルを取得すればすべてのドキュメントをコンテキストウィンドウに入れられる、というものです。追加の取得は不要です。
さて、SEOコンテンツで誤って伝えられる部分です。
- llms.txt は引用シグナルではありません。 ChatGPT、Claude、Perplexity にあなたをより頻繁に引用するよう伝えるものではありません。
- llms.txt はクロール指示ではありません。 いかなるクローラーもブロックも招待もしません。
- llms.txt は Google に使われていません。 Google の Gary Illyes は公式に発言し、Google は使用する予定がないと述べています。
- llms.txt は AI 検索のランキングを向上させません。 ChatGPT、Perplexity、Claude Web のいずれもこれをランキング入力として読まないため、可視性に測定可能な効果はありません。
それで、何ができるのかというと、こうです。あなたの読者がコーディングエージェントでドキュメントを消費するなら、llms.txt はその体験を整えてくれます。Anthropic のドキュメントサイト、Cloudflare のドキュメント、Mintlify でホスティングされているプロジェクト、多くのオープンソース SDK が llms.txt を公開しているのは、彼らのドキュメントが統合構築中の開発者によって日常的に Cursor や Claude Code に読み込まれているからです。
それが本当のユースケースです。マーケティング機能ではなく、開発者ツール向けの機能です。
各ファイルが制御するもの、横並びで比較
| 属性 | robots.txt | ai.txt | llms.txt |
|---|---|---|---|
| 主な目的 | クロールアクセス制御 | 学習・ライセンスに関する意向 | AIエージェント向けの整備されたドキュメントインデックス |
| 読み手 | 全検索・AIクローラー | データセットキュレーター、Spawning AI ツール | AIコーディングエージェント(Cursor、Claude Code など) |
| 提案者 | Martijn Koster、1994年(RFC 9309 は2022年) | Spawning AI | Jeremy Howard、2024年9月 |
| 強制力 | 主要運用者すべてが遵守 | 任意、外部監査 | 任意、エージェント側の判断 |
| 現在の採用率 | ほぼ全面的 | 数% | クロール対象ドメインの約10%(SE Ranking) |
| AI検索の可視性への影響 | 直接的(インデックスボットを許可/ブロック) | なし | なし |
| 学習への取り込みへの影響 | 直接的(学習ボットをブロック) | シグナルのみ | なし |
| 効果が出るまでの時間 | 数時間から数日 | 数か月(データセット更新頻度に依存) | 対応エージェントには即時 |
| 保守負担 | 低 | 非常に低い | 中(ドキュメントと同期を保つ必要あり) |
この表で最も重要な行は「AI検索の可視性への影響」です。ここで実際に針を動かすのは1つだけで、それは30年前からあるファイルです。
Cloudflare の転換点:2025年7月
短い歴史のおさらいです。これからの動きを理解するうえで重要だからです。
2024年7月、Cloudflare はネットワーク上の任意のサイトに対して AIボット、スクレイパー、クローラーをブロックするワンクリック切替を導入しました。「Declaring Your AIndependence(AI独立宣言)」と銘打たれたものです。オプトイン方式で、特に出版者を中心に多くのサイトが急速に採用しました。
それから1年後の2025年7月1日、Cloudflare はデフォルトを反転させました。Cloudflare に新しく追加されたドメインは、デフォルトで AIクローラーをブロックするようになったのです。既存顧客にはワンクリックでのアップグレードが提供されました。Cloudflare はこれを「許諾ベース」モデルと呼びました。AIの運用者は、デフォルトでスクレイピングするのではなく、アクセスを交渉する必要があるという考え方です。
Cloudflare は公開ウェブの約20%の前段に位置します。彼らの動きは、AI学習向けにインターネットのかなりの部分を「デフォルトでオープン」から「デフォルトでクローズド」へと事実上転換させました。
2025年下半期の Cloudflare 自身のデータから、いくつかの数字を挙げます。
- ネットワーク全体で 4160億件のAIボットリクエストが記録されました。
- GPTBot のトラフィックは前年比147%増で、ブロックするサイトが増えてもなお OpenAI がより積極的に取得していることを示しています。
- Meta-ExternalAgent のトラフィックは前年比843%増で、彼らのデータセット内で最も大きな伸びを示したAIクローラーです。
- 250万のサイトが Cloudflare の管理 robots.txt にオプトインしており、Cloudflare がボットリストを代わりに維持しています。
「管理 robots.txt」という細部は、エコシステムの向かう先を示唆しています。ボットリストは個々のサイトが維持するには変化が速すぎるのです。新しいAIスタートアップが毎月のように立ち上がり、それぞれが独自のユーザーエージェントを持ちます。サイトは次第に、リストを集中的に維持するインフラレイヤーに任せるようになっています。
Cloudflare を使っていて、2024年以降にボット管理設定を確認していないなら、いま確認してください。あなたの知らないうちにデフォルトは変わっています。
採用の現実をチェックする
SEO Twitter を読んでいると、llms.txt がどこにでもあるように錯覚しがちです。しかし実際は違います。
SE Ranking は2026年初頭に30万以上のドメインを分析し、llms.txt の採用率は約10%にとどまることを明らかにしました(そして大きく技術系・開発者向けサイトに偏っています)。Presenc.ai の State of llms.txt 2026 レポートも同様の数字を示しており、採用は SaaS ドキュメント、AIツール企業、オープンソースプロジェクトに集中しています。
データから見えるいくつかのパターンです。
- ドキュメント中心の SaaS が採用をリードしています。 Anthropic、Cursor、Mintlify、Vercel、Cloudflare、Supabase はほぼ全社が llms.txt と llms-full.txt を公開しています。
- マーケティングやコンテンツサイトは後れを取っています。 ニュースメディア、ブログ、B2Bマーケティングサイトはほとんど llms.txt を持っていません。読者がコーディングエージェントではないため、ユースケースが弱いのです。
- 採用は緩やかに伸びています。 前年比で約2倍ですが、母数が小さいところからのスタートです。
- エージェント側の対応も部分的です。 Cursor と Claude Code は、ユーザーがドメインを参照したときに llms.txt の読み取りに対応しています。その他のエージェントの多くは読まないか、フォールバックとしてのみ使用します。
率直に言うと、llms.txt は実在の仕様で、実在する狭いユースケースを持ちます。隠れたランキング要因ではありません。良いドキュメントの代わりにもなりません。特定の読者向けの便利ファイルです。同じことが ai.txt にも、より露骨に当てはまります。クリエイター中心の業種を除けば、採用は小さいままです。スケールで何かを真に制御するファイルとしては、robots.txt だけが依然として唯一の選択肢です。
実際にやるべきこと:実用的なセットアップ
ほとんどの運用者をカバーするフレームワークです。
ステップ1:AI学習に対するスタンスを決める。 コンテンツ中心(出版者、ブログ、ニュース、教育)ですか?それなら学習ボットをブロックし、検索ボットを許可する方針が妥当でしょう。SaaS やプロダクト主導ですか?モデル出力でのブランド可視性に寄与するため、学習データに含まれていたいはずです。
ステップ2:意図を持って robots.txt を書く。 適当な gist からコピペしないでください。上のユーザーエージェント表から選び、明示的にディレクティブを書きます。curl -A "GPTBot" でテストし、適切なページがブロックされていることを確認してください。
ステップ3:ライセンスが重要なら ai.txt を追加する。 5分、コストはゼロ。学習への非同意を表明したと示す必要が出てくる可能性があるなら、ai.txt を用意しておく価値があります。気にならなければスキップしてかまいません。
ステップ4:ドキュメントとエージェントの読者がいる場合にだけ llms.txt を追加する。 オープンソースライブラリ、開発者プラットフォーム SaaS、または他人のコードに AI アシスタント経由で組み込まれるプロダクトですか?llms.txt を公開し、理想的には llms-full.txt も用意します。マーケティングサイト、コンテンツブログ、非技術系の SaaS ですか?このファイルは何ももたらしません。
ステップ5:Cloudflare を使っているなら、エッジで一度だけ設定する。 ボット管理機能を使えば、ブロックリストを集中的に維持できます。ほとんどの運用者にとって、手作業で robots.txt を維持するよりも良い選択です。
ステップ6:ログを監視する。 AIクローラーはおおむね robots.txt を尊重しますが、完璧ではありません。アクセスログから上記のユーザーエージェントを定期的に追跡し、挙動が設定と一致していることを確認してください。ブロックしたはずのボットが訪れているなら、運用者に苦情を申し立てましょう。
やる必要のないこと、それは SEO 目的で llms.txt をあれこれ悩むことです。AI検索の可視性には影響しません。ChatGPT があなたを引用するようにもなりません。
エッジケース:Cloudflare AI Audit、Pay-Per-Crawl、Verified Bots
知っておくと役立つ機能をいくつか。エコシステムの向かう先を示唆しているからです。
Cloudflare AI Audit。 どのAIボットがサイトを訪れ、どれくらいの頻度で、どこへ向かっているかを示すダッシュボードです。Cloudflare ユーザーは無料で利用できます。見たことのない新しいボットを発見したり、ブロックしたはずのボットが本当に来なくなっているかを確認したりするのに役立ちます。
Cloudflare Pay-Per-Crawl。 2025年半ばに発表されたもので、サイト所有者がAIクローラーに対して完全にブロックする代わりにリクエスト単位で料金を請求できる仕組みです。モデルはまだ初期段階で採用も限定的ですが、アクセス交渉が二者択一(ブロック/許可)ではなく自動化される未来を示唆しています。
Verified Bot プログラム。 Cloudflare と Google はいずれも、ユーザーエージェント文字列が本当にその運用者のものかを確認するレジストリを維持しています。これは重要です。なりすましはありふれているからです。スクレイパーが User-Agent: GPTBot を設定して OpenAI のふりをする、といったことができます。Verified bot プログラムは、運用者が公開している範囲に対して送信元 IP を検証します。OpenAI 以外の IP から GPTBot のトラフィックを観測しているなら、それはなりすましであり、IP でのブロックが正しい対応です。
「エージェントによるブラウジング」の問題。 ChatGPT や Claude がユーザーに代わってページを取得するとき、その取得は別のユーザーエージェント(ChatGPT-User、Claude-User)を使います。これらをブロックすると、ユーザーが貼り付けたページをモデルが読めなくなりますが、出版者が本当に望んでいるのは普通そうした状態ではありません。特定の理由がない限り、エージェントによるブラウジング用のボットは許可しておきましょう。
この先の行方
今後18か月に向けた率直な予測をいくつか。
標準が形成されつつあり、それは llms.txt ではありません。 IETF の AI Preferences Working Group(AIPREF)は、AIの学習と利用に関する意向のためのより包括的な標準を策定しています。適切な機械可読セマンティクスを備えた、ai.txt スタイルの「意向を表明する」モデルを正式化することになりそうです。RFC として固まれば、現在 ai.txt が担っているユースケースを吸収していくでしょう。
Pay-per-crawl が広がります。 Cloudflare だけが提供する仕組みではなくなります。Akamai、Fastly、各クラウド CDN も類似の仕組みを打ち出すと予想されます。あらゆる AI クローラーがあらゆるサイトと従量課金の関係を持つ世界は、2027年までに現実味を帯びてくるでしょう。
ボットリストは中央集権化していきます。 追跡すべき名前が十数程度しかなかった2023年なら、自前で AI ユーザーエージェントのリストを維持するのは妥当でした。今では40近くに迫り、増え続けています。多くの運用者は最終的に、リストを最新に保つためにインフラレイヤーを信頼することになるでしょう。
llms.txt はそのニッチで存続します。 消えはしません。同時にランキング要因にもなりません。エージェント型ツールの読者層に応え続け、十分な数のエージェントが対応するようになれば、より標準化された仕様へと整っていくでしょう。
メタ的なパターンとしては、デフォルトでオープンなウェブが、サイトごとの設定ではなくインフラプラットフォームを介した「許諾ベース」のウェブへと AI トラフィックに関して徐々に置き換えられていく、ということです。robots.txt はその世界へのレガシーインターフェースであり、ai.txt と llms.txt は、より豊かなシグナリングへの初期の試みです。IETF と CDN 業界は、実際にスケールするバージョンを静かに作り進めています。
よくある質問
Google は私の llms.txt ファイルを読みますか?
いいえ。Google の Gary Illyes は2025年に、Google はいかなるプロダクトの入力としても llms.txt を使う予定はないと公式に発言しました。llms.txt を追加しても、Google Search、Gemini、AI Overviews には影響しません。Google のAI製品に影響を与えたいなら、関係するシグナルは robots.txt 内の Google-Extended ユーザーエージェントと、標準の検索インデックスであって、llms.txt ではありません。
robots.txt ですべてのAIクローラーをブロックすべきですか?
サイトの種類によります。出版者やコンテンツ中心のサイトは、学習ボット(GPTBot、ClaudeBot、Google-Extended、CCBot、Meta-ExternalAgent、Bytespider)をブロックしつつ、検索やユーザー取得系のボット(OAI-SearchBot、PerplexityBot、ChatGPT-User)は許可することが多いです。SaaS やプロダクトサイトは通常、学習データに含まれることがブランド可視性に役立つため、すべて開放しています。非出版者にとって、すべてのAIボットを一括ブロックするのが正しいことは稀です。AI由来のディスカバリーを失うコストが大きいからです。
ai.txt は本当に誰かに対応されていますか?
Spawning AI は対応していますし、一部のデータセットキュレーターや倫理的AIプロジェクトも対応しています。主要なモデル学習者(OpenAI、Anthropic、Google、Meta)は、ai.txt ではなく robots.txt を主に遵守します。したがって、ai.txt は「非同意を表明した」というスタンスのためのシグナリング層としては有用ですが、アクセス制御として頼るべきではありません。実際のブロックは robots.txt と組み合わせて行ってください。
llms.txt と llms-full.txt の違いは何ですか?
llms.txt はインデックスファイルで、ドキュメントのマークダウン版へのリンクを短くまとめたものです。llms-full.txt はインライン化されたバージョンで、すべてのドキュメントを1つの大きなマークダウンファイルに結合したものです。トレードオフは帯域と利便性です。llms.txt は取得が軽いものの、エージェントはリンクをたどる必要があります。llms-full.txt は重いですが、エージェントが1回のリクエストでドキュメント全体をコンテキストに読み込めます。一方を公開しているプロジェクトはたいてい両方を公開しています。
robots.txt で GPTBot をブロックすると、ChatGPT のブラウジングもブロックされますか?
いいえ。GPTBot は OpenAI の学習クローラーです。ChatGPT-User は、ユーザーがウェブページを読むよう ChatGPT に明示的に頼んだときに ChatGPT が使うユーザーエージェントです。robots.txt 上では別のユーザーエージェントです。GPTBot をブロックすれば学習からはオプトアウトできます。ChatGPT-User は別途ブロックしない限り許可されたままです。多くの出版者が望むのはまさにこの切り分け、つまり学習をブロックし、ユーザー起点の取得は許可するというものです。
llms.txt は ChatGPT や Perplexity でのランキングに役立ちますか?
いいえ、引用やランキングシグナルとしては役立ちません。ChatGPT と Perplexity は、検索クローラー(OAI-SearchBot、PerplexityBot)でインデックスした内容と学習データに基づいてコンテンツを表示します。llms.txt は Cursor や Claude Code のようなコーディングエージェントが読むものであって、チャット製品が読むものではありません。ChatGPT に引用されたいなら、優先順位は次のとおりです。(1)robots.txt で OAI-SearchBot をブロックしないこと、(2)特定の問いに明確に答えるコンテンツを公開すること、(3)これらのモデルが信頼するソースからの引用を獲得すること。llms.txt はそのリストに含まれません。
おわりに
AIクローラー制御をめぐる現在の言説で私がもどかしく感じるのは、悪い助言がいかに自信たっぷりに語られているかという点です。「llms.txt を追加すれば ChatGPT でランクインする」「ai.txt ですべてをブロックしろ」「robots.txt は死んだ、llms.txt が未来だ」。それぞれが別の方向で間違っています。
真実はもっと地味で、もっと有用です。robots.txt は依然として実務を担います。ai.txt は一部の運用者が尊重する意向を表明します。llms.txt は特定の読者向けの開発者ツール上の利便性です。どれも魔法のランキングレバーではなく、そのように扱うことは、本当に重要なことに使える時間を浪費します。
ほかに何も覚えられなくても、3つの役割だけは覚えてください。robots.txt はアクセスのゲート。ai.txt はライセンスのシグナル。llms.txt は開発者向けインデックス。それぞれを本当に行うことのために設定し、それ以外のノイズは無視してください。そうすれば、理解せずにトレンドを追う多くの運用者よりも一歩先に出られます。
そして AIPREF から目を離さないでください。これからの1~2年のAIクローラー制御は、この3つのファイルよりも、IETF と CDN 業界が次に標準化するものに左右されるはずです。今の状態はあくまで暫定です。