先日開催したボットアクセスの実態に関するウェビナーでは、まったく同じ質問を2名の参加者からいただきましたが、時間の都合上、その場でお答えすることができませんでした。
その質問は、「llms.txtを設置すれば、AIボットによる大量アクセスを防げるのか」というもの。
この答えは、単純な「はい」でも「いいえ」でもありません。というのも、そもそもllms.txtは、多くの人が期待しているような用途を想定して作られたものではないからです。今年はllms.txtに関する情報が数多く公開されていますが、その内容から「AIボット対策として有効」と受け取られるケースも少なくありません。
こうした誤解は、llms.txtだけに限ったものではありません。ウェビナーに寄せられた質問を振り返ると、robots.txt、llms.txt、AIクローラー、ボット対策を、あたかも同じ設定を別の方法で行うものと捉えている方が少なくありませんでした。
しかし実際には、それぞれ役割はまったく異なります。リクエスト処理のどの段階で機能するかも、動作の仕組みも異なり、llms.txtはアクセスを制御するための仕組みですらありません。これらを混同すると、やるべき対策はすべて行ったつもりでも、AIボットによる大量アクセスを防げないという状況に陥りかねません。
しかも、これは机上の空論ではなく、すでに現実に起きている問題です。Kinstaが公開した「AI・ボット時代におけるトラフィックの実態」レポートでは、KinstaでホスティングされているサイトへのAIボットアクセスは、この1年で200リクエストに1件から31リクエストに1件へと急増していることがわかりました。これほど多くのボットがアクセスするようになると、入口に「立ち入り禁止」の札を掲げるだけでは、十分な対策にはなりません。
要点
- robots.txtはアクセスを制御する仕組みではなく、クローラーへの「リクエスト」。OpenAI、Anthropic、Google、Perplexityなどの主要なAIクローラーは一般的にこれに従うが、ByteDanceのBytespiderのように、過去には従わなかったクローラーも存在する。
- llms.txtはアクセス制御を行うものではない。AIツール向けのコンテンツ索引であり、権限を管理するファイルではありません。導入率は約9〜10%にとどまり、主要なAIクローラーの多くは現時点でllms.txtを取得していない。
- 実際にアクセスを制御できるのはボット対策のみ。robots.txtやllms.txtは、あくまでクローラーに従ってもらうことを期待する仕組みであり、設定を無視するクローラーに対してブロックや検証、レート制限を実施できるのは、Kinstaのボット対策機能やCloudflareのAI Crawl Controlなど。
4つの仕組み、それぞれの役割
| レイヤー | 実際の役割 | 悪意のあるアクセスを止められるか |
| robots.txt | robots.txtを読み取るクローラーに対してクロールの希望を伝える | ❌ |
| llms.txt | AIツール向けにコンテンツの索引を提供する | ❌ |
| AIクローラー | サイトにリクエストを送信するボットそのもの | ―（制御する対象であり、制御する仕組みではありません） |
| ボット対策（Kinsta / Cloudflare） | インフラレベルでリクエストを検知・分類し、ブロックや検証などの対策を実行する | ⭕️ |
このように整理すると、ウェビナーで寄せられた多くの質問の回答は、自然と見えてきます。それぞれの役割を詳しくご紹介します。
robots.txt
robots.txtは、RFC 9309で標準化されたファイルで、クローラーに対して「クロールしないでほしいページやディレクトリ」を伝えるためのものですが、robots.txt自体にアクセスを制御する機能はありません。あくまでクローラーが自主的に内容を尊重することを前提とした仕組みです。
幸い、OpenAI、Anthropic、Google、Perplexityなど、主要なクローラーは、利用するユーザーエージェントを公開しており、robots.txtの標準的なディレクティブにも従っています。
よくある誤解が、「各社にはAIボットが1種類しかない」です。多くのAIサービスは学習用と検索用でクローラーを分けており、この違いを理解することが、AIボットとの付き合い方を考えるうえで重要なポイントになります。
- GPTBot（OpenAI）：基盤モデルの学習に使用され、クロールを拒否すると、コンテンツは今後のモデル学習に利用されなくなる。
- OAI-SearchBot（OpenAI）：ChatGPTの検索機能で引用するためにページを収集。クロールを拒否すると、ChatGPTで引用されなくなるが、モデル学習には影響しない。
- ClaudeBot（Anthropic）：モデル学習用
- Claude-SearchBot（Anthropic）：Claudeの検索インデックスを作成するために使用される。
- Google-Extended：AIモデルの学習やAI Overviewでの利用を制御。通常のGooglebotによるインデックスやGoogle検索順位には影響しない。
- PerplexityBot：Perplexityの回答生成エンジンで利用されるクローラー
つまり、本当に考えるべきなのは、「AIにアクセスを許可するか、それとも拒否するか」という二択ではなく、「コンテンツをAIモデルの学習に利用してほしいのか、AIの回答で引用してほしいのか、その両方を許可するのか、それともどちらも許可しないのか」ということです。robots.txtを使えば、こうした方針を細かく設定できます。サイト運営者の多くは、このような視点でrobots.txtを活用できることを、まだ十分に認識していません。
例えば、「AIモデルの学習には利用されたくないが、ChatGPTやClaudeの回答では引用してほしい」という場合は、以下のように記述します。
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /一方、「特定のディレクトリだけをAIモデルの学習にも検索にも利用されたくない」場合は、サイト全体ではなく、対象のパスに対してDisallowを設定します。
User-agent: GPTBot
Disallow: /premium-reports/
User-agent: ClaudeBot
Disallow: /premium-reports/注意点として、robots.txtへの準拠は義務ではなく、あくまでクローラー側の自主的な判断に委ねられます。実際、Disallowの指定を無視することが確認されているクローラーも存在します。
さらに最近では、ChatGPTなどのAIアシスタントに対して、ユーザーが特定のページをその場で読み取るよう指示した場合、そのページへのアクセスは通常のクローリングとは異なる方法で処理されることがあります。そのため、このようなリクエストには、robots.txtのルールが必ずしもそのまま適用されるとは限りません。
llms.txt
2026年に入り、llms.txtを「アクセス制御の仕組み」や「SEO対策」として紹介する記事が数多く公開されています。しかし先に触れた通り、llms.txtはそうした用途のために設計されたものではありません。
llms.txtは、サイトのルートディレクトリに配置するMarkdown形式のファイルです。AIツールに対して重要なページを案内する目次のような役割を果たし、AIモデルがページ全体を解析しなくても、サイトの内容を把握しやすくすることを目的としています。これがllms.txtの仕様のすべてで、クローラーによるアクセスを許可するか拒否するかを制御する機能は含まれていません。
一般的なllms.txtは、以下のような内容です。
# Acme Analytics
> Acme Analytics is a WordPress plugin for tracking site performance and uptime.
## Docs
- [Getting Started](https://example.com/docs/getting-started): Install and configure the plugin
- [API Reference](https://example.com/docs/api): Full REST API documentation
## Pricing
- [Plans](https://example.com/pricing): Current plans and feature comparison注目してほしいのは、AllowやDisallow、ユーザーエージェントの指定など、クローラーの動作を制御するための記述が一切ない点です。つまり、llms.txtには、クローラーに「何をしてよいか」「何をしてはいけないか」を指示する仕組みはありません。
現在わかっていることは、以下のとおりです。
- 導入はまだ限定的：導入すべきという情報が広まってから1年以上経った現在でも、導入しているサイトは、ウェブ上の大規模サイトを含めても約9〜10%にとどまっている。
- 主要なAIクローラーの多くは取得していない：数億件規模のAIボットトラフィックを分析した結果、GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot、Google-Extendedの多くは、llms.txtを取得せず、そのままHTMLページをクロールしていることがわかっている。
- Googleも利用を否定している：Googleの検索担当者は、llms.txtをランキングやクロールのシグナルとして利用していないことを明言しており、かつて使われていたものの現在はほとんど意味を持たない
keywordsメタタグと比較している。 - 主要なAI企業もアクセス制御には利用していない：現時点で、学習用・検索用を問わず、llms.txtをアクセス制御のシグナルとして扱うことを表明している主要なAI企業はない。
llms.txtが役立つ場面として、たとえばClaude CodeやCursorのようなコーディング支援ツールや開発者向けツールでは、ドキュメントサイトの構造化された索引として利用できるため、有用性があります。
つまり、llms.txtを設置しても、AIボットによる繰り返しのクロールを防ぐことはできません。 llms.txtはコンテンツを見つけやすくするための仕組みであり、アクセス数を制限する仕組みでも、アクセスを遮断する仕組みでもありません。
AIクローラー
「AIクローラー」という言葉は、実際には少なくとも次の3種類をまとめて指すのが一般的です。これらの違いを理解していないことが、判断を誤る原因になり得ます。
- 学習用クローラー：AIモデルの学習データを収集するため、定期的にコンテンツをクロールする。代表例は、GPTBot、ClaudeBot、Google-Extended、Bytespider、CCBot。
- 検索・回答用クローラー：AI検索サービスや回答エンジンで引用するためのインデックスを作成する。代表例は、OAI-SearchBot、Claude-SearchBot、PerplexityBotなど。
- リアルタイム取得：ユーザーがChatGPTなどのAIアシスタントに「このページを読んで」と指示すると、その場で特定のページだけを取得する。
前者2つは従来のウェブクローラーと同じように動作し、通常はユーザーエージェントを公開しているため、robots.txtによる制御が可能です。
一方、3つ目のリアルタイム取得は、人がリンクをクリックしてページを開く動作に近い形で行われます。そのため、一部のAIブラウジング機能は、サーバーログ上では通常の訪問者と区別がつかないことがあります。また、ボットを一律にブロックする設定では、人間の指示による正当なアクセスまで遮断してしまう可能性があります。
これは、先日のウェビナーでCTOのDaniel Patakiも触れていたポイントで、現在のAIクローラーによるアクセスの多くは、悪意があるというよりも、とにかく大量にアクセスしてくることが問題です。
AIクローラーは見つけたリンクを次々とたどります。動的に生成されるWordPressやWooCommerceのサイトでは、同じ内容でもURLのバリエーションが数多く存在するため、それらをすべてクロールしようとします。その結果、実際には攻撃ではないにもかかわらず、まるで攻撃を受けているかのような大量アクセスが発生します。AIクローラー自身は、同じページを何千回も取得していることを認識していません。
こうしたアクセスが、なぜWooCommerceサイトに特に大きな負荷を与えるのかについては、『WooCommerceサイトでボットアクセスが問題になりやすい理由』で詳しくご紹介しています。
実際にAIボットを制御できるのはボット対策機能だけ
robots.txtがあくまでクローラーへのリクエストであり、llms.txtもアクセスを制御する仕組みではないことを踏まえると、設定を無視するクローラーに実際に対処できるのは、ボット対策機能だけになります。Cloudflareなどのソリューションが有名ですが、Kinstaでも最近ボット対策機能を全プランに導入しました。
Cloudflareは近年、AIボット対策の機能を急速に強化しています。Kinstaでは、WordPressサイト向けに特化したアプローチを採用しています。例えば、AIクローラーをブロックを有効にすると、検証済みのAIクローラーを含むAIクローラーをブロックしながら、GooglebotやBingbotには影響を与えません。さらに、「過剰アクセスAIクローラー」という分類も用意されています。これは、正規のAIクローラーであっても、通常のクロールを大きく上回る頻度でアクセスし、サイトに負荷をかけているものを検知するためのものです。
KinstaのエンジニアリングディレクターであるLaszlo Farkasは、マネージド型のボット対策と、自分でルールを作成・管理する方法のどちらが適しているかは、利用者の知識や運用体制によって変わると説明しています。十分な知識があり、自分で細かく調整する時間も確保できるのであれば、自前で運用する方法が適しており、そうでない場合は、WordPress向けに最適化され、Kinstaが継続的に管理・調整を行うボット対策がおすすめです。
KinstaとCloudflareのボット対策機能の違いはこちらで詳しくご紹介しています。
実際に寄せられた質問とその回答
Q. LLMクローラーは受け入れたいものの、過剰なアクセスは防ぎたい場合はどうすればよいですか？
学習用クローラーと検索・回答用クローラーを分けて考えるのがポイントです。AI検索で見つけてもらい、回答で引用されたいのであれば、検索・回答用クローラーへのアクセスは許可します。一方、AIモデルの学習には利用されたくないのであれば、robots.txtで学習用クローラーのみを対象にクロールを拒否します。そのうえで、検証済みかどうかにかかわらず、通常を大きく上回る頻度でクロールするボットについては、ボット対策機能で制御することができます。
Q. AIに自社を見つけてもらいたいので、トラフィックはブロックしたくないのですが、どうすればよいですか？
AIに見つけてもらうことと、サイトを過剰なアクセスから守ることは両立できます。ポイントは、クローラーの種類ごとに対応を分けることです。AIモデルの学習用クローラーや大量アクセスを行うクローラーはチャレンジまたはブロックし、検索・回答用クローラーへのアクセスは許可しましょう。
Q. ペイウォールを導入すれば、AIボットによるスクレイピングを防げますか？
ある程度は防げますが、通常のクローラーとして動作するAIボットに限定されます。ログインが必要なページであれば、有効な認証情報を持たないAIボットは、人間の訪問者と同じようにアクセスできません。しかし、実際のユーザーのようにブラウジングするAIツールや、キャッシュ、RSSフィードなど、ペイウォールを経由しない経路からコンテンツを取得するケースには効果がありません。有効な対策のひとつではありますが、ボット対策の代わりにはなりません。
Q. AIクローラーがWooCommerceの絞り込みや並び替えを延々とクロールし続けるのを防ぐにはどうすればよいですか？
これは一見するとボット対策の問題に思えますが、本質的にはキャッシュやURL設計の問題です。クローラーは見つけたリンクをすべてたどるため、絞り込み条件や並び替えパラメータによって大量のURLが生成されると、人間にとっては同じページであっても、それぞれ別のページとしてクロールしてしまいます。まずは、こうしたURLパターンをrobots.txtでクロール対象から除外することをおすすめします。
User-agent: *
Disallow: /*?*filter_
Disallow: /*?*orderby=こうした設定を無視するクローラーも存在するため、そのようなケースでは、ボット対策機能のレートベースのルールが、実際に過剰なアクセスを抑える役割を果たします。
まとめ
結論として、これら4つを互いに代わりになる選択肢として考えるのではなく、それぞれ異なる役割を持つ仕組みとして組み合わせることが重要です。
- robots.txt：サイト運営者の意図を伝える仕組み。AIモデルの学習用クローラーと検索・回答用クローラーを分け、それぞれに対して希望する動作を指定できる。
- llms.txt：対応しているAIツールに、サイトの構造や重要なコンテンツを伝えるための仕組み。クロール量を減らしたり、アクセスを制御したりするものではない。
- AIクローラー：学習用クローラー、検索用クローラー、リアルタイム取得など、複数の種類があり、それぞれに応じた対応が必要。
- ボット対策：実際にアクセスを制御できるのはこのレイヤーのみ。設定を無視するクローラーに対しても、ブロックや検証、レート制限などの対策を実施できる。
AIクローラーをどのように「制御」するかではなく、どのように「見つけてもらう」かについては、別の解説記事『AEOとは？WordPressのAEO対策でインフラが重要な理由』や『【SEO・AEO・GEO】各概要と違い、WordPress最適化を解説』をご覧ください。また、Kinstaのボット対策機能のの詳細はこちらでご紹介しています。
