生成AIの普及にともない、Webサイトのコンテンツを無断で収集する「AIクローラー」が急増しています。サーバー負荷の増大やコンテンツの無断利用といったリスクに直面するサイト運営者にとって、適切な対策は急務です。

本記事では、robots.txtの基本設定から.htaccessによる強制ブロック、Cloudflare AI Crawl Controlの活用、レンタルサーバーのワンクリック設定、さらにllms.txtによるAI向け情報提供まで、実践的な防御手法を体系的にまとめています。

AIクローラーの仕組みと従来型クローラーとの違い

AIクローラーとは、大規模言語モデル(LLM)の学習データ収集やAI検索エンジンの回答生成を目的として、Webサイトを自動巡回するプログラムです。従来の検索エンジンクローラー(Googlebotなど)がインデックス作成を目的とするのに対し、AIクローラーはモデルのトレーニングやリアルタイム情報取得に利用される点が異なります。

サイト運営者が受ける影響

AIクローラーによるアクセスは、以下の問題を引き起こす可能性があります。

  • サーバー負荷の増大: 短時間に大量のリクエストが集中し、通常のユーザーアクセスに支障が出る
  • コンテンツの無断利用: 記事や画像がAIモデルの学習素材として許可なく使われる
  • 著作権侵害のリスク: AIが生成した回答に自サイトのコンテンツが無断で含まれる場合がある
  • 広告収益の低下: AI検索が直接回答を返すことで、サイトへの流入が減少する

主要AIクローラーのユーザーエージェント一覧

対策を講じるためには、まずブロック対象となるAIクローラーを把握する必要があります。以下は2026年2月時点での主要なAIクローラーと、その運営元・用途の一覧です。

ユーザーエージェント運営元主な用途robots.txt遵守
GPTBotOpenAIモデル学習用データ収集遵守を表明
ChatGPT-UserOpenAIユーザーのリクエストによるWebブラウジング遵守を表明
OAI-SearchBotOpenAIChatGPT検索機能のインデックス遵守を表明
ClaudeBotAnthropicモデル学習用データ収集遵守を表明
Claude-UserAnthropicユーザーリクエストによるWeb取得遵守を表明
Claude-SearchBotAnthropic検索品質向上のためのインデックス遵守を表明
anthropic-aiAnthropic旧識別子(2024年7月にClaudeBotへ統合、互換性のため残存)遵守を表明
Google-ExtendedGoogleGemini等のAIモデル学習(検索順位に影響なし)遵守を表明
Applebot-ExtendedAppleApple Intelligence向けデータ収集遵守を表明
PerplexityBotPerplexity AIAI検索のインデックス遵守を表明
meta-externalagentMetaLLaMA等のモデル学習遵守を表明
CCBotCommon Crawlオープンデータセット構築遵守を表明
BytespiderByteDanceTikTok等のAI機能向けデータ収集一部不遵守の報告あり
cohere-aiCohereモデル学習用データ収集遵守を表明
SBIntuitionsBotSB Intuitions日本語LLM向けデータ収集遵守を表明

公式ドキュメント:

注意点: Google-Extendedをブロックしても、Google検索のインデックスやランキングには影響しません。AI学習への利用のみを制御するユーザーエージェントです。

対策1: robots.txtでAIクローラーを拒否する

robots.txtは、Webサイトのルートディレクトリに配置するテキストファイルで、クローラーに対してアクセス可否を伝える仕組みです。

基本的な書き方

特定のAIクローラーをブロックするには、以下のように記述します。

# OpenAIのクローラーをブロック
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

# Anthropicのクローラーをブロック
User-agent: ClaudeBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Claude-SearchBot
Disallow: /

# GoogleのAI学習用クローラーをブロック
User-agent: Google-Extended
Disallow: /

# その他のAIクローラー
User-agent: PerplexityBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: meta-externalagent
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: cohere-ai
Disallow: /

特定ディレクトリのみブロックする場合

ブログ記事など一部のコンテンツだけAI学習を拒否したい場合は、パスを指定します。

User-agent: GPTBot
Disallow: /blog/
Disallow: /articles/

User-agent: ClaudeBot
Disallow: /blog/
Disallow: /articles/

robots.txtの限界

robots.txtはあくまで**「お願い」であり、強制力はありません**。主要なAI企業はrobots.txtの遵守を公式に表明していますが、すべてのクローラーが従う保証はありません。実際にBytespiderなど一部のクローラーがrobots.txtを無視するケースも報告されています。

したがって、robots.txtは対策の第一歩として設定しつつ、後述する.htaccessやWAFによる強制ブロックと組み合わせることが推奨されます。

対策2: robotsメタタグでページ単位の制御を行う

HTMLの<head>内にメタタグを記述することで、ページ単位でAIクローラーの動作を制御できます。

<!-- 全AIクローラーに対してインデックスとAI学習を拒否 -->
<meta name="robots" content="noai, noimageai">

<!-- 特定のクローラーに対して拒否 -->
<meta name="GPTBot" content="noindex, nofollow">
<meta name="ClaudeBot" content="noindex, nofollow">
<meta name="Google-Extended" content="noindex, nofollow">

noaiはテキストコンテンツのAI学習利用を拒否し、noimageaiは画像のAI学習利用を拒否するディレクティブです。ただし、これらの非標準ディレクティブを実際にサポートしているクローラーはまだ限定的であるため、robots.txtとの併用が望ましいです。

対策3: .htaccessでAIクローラーを強制ブロックする

Apache Webサーバーを利用している場合、.htaccessファイルでUser-Agentに基づいたアクセス制御を行えます。robots.txtと異なり、サーバーレベルでアクセスを遮断するため、クローラー側の意志に関係なくブロックが可能です。

基本的な設定例

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# AIクローラーをブロック(403 Forbiddenを返す)
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|Claude-User|Claude-SearchBot|anthropic-ai|Google-Extended|PerplexityBot|Bytespider|CCBot|meta-externalagent|Applebot-Extended|cohere-ai|SBIntuitionsBot) [NC]
RewriteRule .* - [F,L]
</IfModule>

各フラグの意味は以下のとおりです。

  • [NC]: 大文字・小文字を区別しない
  • [F]: 403 Forbidden を返す
  • [L]: このルールで処理を終了する

Nginxの場合

Nginxを使用している場合は、サーバー設定ファイルに以下を追記します。

if ($http_user_agent ~* "(GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|anthropic-ai|Google-Extended|PerplexityBot|Bytespider|CCBot|meta-externalagent)") {
    return 403;
}

注意点

.htaccess による制御は User-Agent 文字列に依存しています。クローラーが User-Agent を偽装した場合はブロックできません。より強固な対策が必要な場合は、IP アドレスベースのブロックや WAF の導入を検討してください。

対策4: Cloudflare AI Crawl Controlを活用する

Cloudflareは、AIクローラーを管理するための専用機能「AI Crawl Control」を提供しています。無料プランを含むすべてのプランで利用でき、ダッシュボードから簡単に設定可能です。

設定手順

  1. Cloudflareダッシュボードにログインする
  2. 対象ドメインを選択する
  3. 「AI Crawl Control」メニューを開く
  4. クローラーごとに「Allow(許可)」「Charge(課金)」「Block(遮断)」を選択する

Block AI Bots機能(全プラン共通)

「Security」>「Settings」から「Block AI bots」を有効にすると、検証済みのAIクローラーと類似の未検証ボットを一括ブロックできます。ブロック範囲は以下から選択可能です。

  • 広告掲載ページのみブロック: 広告表示があるページだけAIボットをブロック
  • 全ページブロック: サイト全体でAIボットをブロック
  • ブロックしない: AIボットを許可

Pay-per-Crawl(課金型アクセス制御)

Cloudflareの「Pay-per-Crawl」は、AIクローラーに対してコンテンツ閲覧の対価を請求する仕組みです。HTTP 402(Payment Required)レスポンスコードを活用し、クローラーとの間で自動的に課金交渉が行われます。

仕組みの概要は以下のとおりです。

  1. AIクローラーがページをリクエストする
  2. CloudflareがHTTP 402crawler-priceヘッダーを返す
  3. クローラーが価格に同意するとcrawler-exact-priceヘッダー付きで再リクエストする
  4. コンテンツが配信され、課金イベントが記録される

最低価格は1リクエストあたり0.01ドル(USD)から設定可能です。認証にはEd25519鍵ペアとHTTPメッセージ署名が使われ、なりすましを防止しています。

参考: Cloudflare Pay-per-Crawl公式ドキュメント

対策5: レンタルサーバーの管理画面からワンクリックで設定する

最近は主要なレンタルサーバーでもAIクローラー対策機能が提供されるようになっています。

エックスサーバー「AIクローラー遮断設定」

エックスサーバーでは2026年1月7日より、管理画面から利用できる「AIクローラー遮断設定」が追加されています。サーバーパネルからドメイン単位でON/OFFを切り替えるだけで、以下のクローラーを一括遮断できます。

遮断対象クローラー(一部抜粋): GPTBot、ChatGPT-User、OAI-SearchBot、ClaudeBot、Claude-User、Claude-SearchBot、anthropic-ai、Google-Extended、meta-externalagent、CCBot、PerplexityBot、Bytespider、cohere-ai、SBIntuitionsBot

設定方法: サーバーパネル > 「AIクローラー遮断設定」 > 対象ドメインの「ON」をクリック

参考: エックスサーバー AIクローラー遮断設定マニュアル

はてなブログ「生成AIによるクロールを拒否」

はてなブログでは、管理画面の「基本設定」から「生成AIによるクロールを拒否」をONにするだけで、robots.txtにAIクローラー拒否ルールが自動追記されます。GPTBot、Google-Extended、ClaudeBot、PerplexityBot、CCBotなど12種類のユーザーエージェントが対象です。

参考: はてなブログ ヘルプ - 生成AIによるクロールを拒否する

Wix「AIクローラブロック」

Wixでは、robots.txtファイルとrobotsメタタグの両方からAIクローラーのブロック設定が可能です。Wixダッシュボードの「SEOツール」から設定できます。

対策6: llms.txtでAIに対して適切な情報を提供する

llms.txtは、2024年9月にJeremy Howard氏(Answer.AI)が提案した新しい標準で、AIクローラーに対してサイトの構造や利用条件をMarkdown形式で伝えるファイルです。robots.txtが「拒否」を伝えるのに対し、llms.txtは「どのように利用してほしいか」を伝える積極的なアプローチです。

llms.txtの構造

# サイト名

> サイトの概要説明(1-2文)

## ドキュメント
- [APIリファレンス](https://example.com/docs/api.md): APIエンドポイントの仕様
- [利用規約](https://example.com/terms.md): コンテンツ利用に関する条件

## Optional
- [ブログ一覧](https://example.com/blog/index.md): 最新記事のリスト

llms.txtとllms-full.txtの違い

項目llms.txtllms-full.txt
内容リンク集(インデックス)全コンテンツを1ファイルに集約
ファイルサイズ小さい(数KB程度)大きい(数百KB〜数MB)
用途サイト構造の概要把握詳細なコンテンツの一括取得
LLMの利用リンク先を個別にフェッチ1回のリクエストで全情報を取得

現在の対応状況

2026年2月時点で、600以上のWebサイトがllms.txtを導入しています。Anthropic、Perplexity、Stripe、Cloudflare、Hugging Faceなどが自社サイトに設置済みです。AIコーディングアシスタント(Cursor、Claude Code)がプロジェクトのドキュメント理解にllms.txtを活用する事例も増えています。

ただし、GPTBot・ClaudeBot・PerplexityBotといった主要クローラーが自動的にllms.txtを読み込む動作は、2026年に入ってから順次対応が進んでいる段階です。現時点ではrobots.txtとの併用が前提となります。

公式サイト: llmstxt.org、GitHub: AnswerDotAI/llms-txt

対策の組み合わせと優先度

単一の手法だけでは十分な防御にならない場合があります。以下の表は、サイトの規模や技術レベルに応じた推奨構成です。

サイト規模推奨対策実装難易度
個人ブログ・小規模サイトrobots.txt + レンタルサーバー機能
中規模メディア・企業サイトrobots.txt + .htaccess + Cloudflare Block AI Bots
大規模メディア・ECサイトrobots.txt + Cloudflare AI Crawl Control + WAFルール + llms.txt
コンテンツ収益化を目指すサイト上記 + Cloudflare Pay-per-Crawl

導入の順序

  1. まずrobots.txtを設定する: 主要クローラーの大半はrobots.txtを遵守するため、最初に設置します
  2. サーバー側でのブロックを追加する: .htaccessまたはNginx設定で、robots.txtを無視するクローラーにも対応します
  3. CDN/WAFで包括的に管理する: CloudflareなどのCDNを利用している場合は、AI Crawl Controlで一元管理します
  4. llms.txtで利用条件を明示する: 完全なブロックではなく、適切な利用を促したい場合に設置します

robots.txtだけに頼れない理由と多層防御の考え方

robots.txtは1994年に策定されたRobots Exclusion Protocolに基づく仕組みです。あくまでクローラー側の「善意」に依存しており、法的拘束力はありません。

多層防御が必要な理由は以下のとおりです。

  • User-Agent偽装: 一部のクローラーは正規のUser-Agentを名乗らずにアクセスする
  • Crawl-delayの無視: robots.txtのCrawl-delay指示に従わないクローラーが存在する
  • 学習済みデータの削除困難: robots.txtでブロックを開始しても、すでに学習済みのデータは削除されない場合が多い
  • 新規クローラーの出現: 新しいAI企業やサービスが次々と独自のクローラーを運用し始めている

したがって、robots.txt(意思表示)→ .htaccess/WAF(強制ブロック)→ Cloudflare AI Crawl Control(包括管理)→ llms.txt(利用条件提示)という多層的なアプローチが効果的です。

まとめ

AIクローラーへの対策は、単一の手法では完全な防御にならないため、複数の手段を組み合わせる多層防御が重要です。

robots.txtによる意思表示を基本としつつ、.htaccessやCloudflare AI Crawl Controlで強制的なブロックを実施し、llms.txtでAIに対する利用方針を明示する構成が現時点で最も実効性が高いといえます。

AIクローラーの種類は今後も増え続けることが予想されます。定期的にサーバーログを確認し、新たなクローラーのUser-Agentが検出された場合は、ブロックリストに追加するメンテナンスを継続することが大切です。