AIクローラーを制御する方法｜仕組みと設定を解説

AIクローラーとは、ChatGPTやGeminiといった生成AIが学習・回答生成のためにWebサイトを巡回するボットのことです。従来の検索エンジンクローラーとは目的が異なり、対応を誤るとコンテンツを無断で学習されるリスクがあります。

この記事では、AIクローラーの仕組みと主要ボットの種類を整理したうえで、ブロックすべきケースと許可すべきケースの判断基準、そしてrobots.txtやllms.txtを使った具体的な制御方法まで解説します。自サイトへの影響を正しく把握し、適切な対応を取るための知識をまとめました。

AIクローラーの仕組みと動作原理

AIクローラーとは、生成AIの学習・検索・回答生成を目的として、Webサイトを自動巡回するプログラムのことです。従来の検索エンジンクローラーがページを収集して「検索順位付けのためのインデックス生成」を行うのに対し、AIクローラーは「AIモデルの訓練データ取得」や「ユーザーへの回答・引用のためのコンテンツ収集」を目的としている点が本質的に異なります。

2023年8月にOpenAIがGPTBotを公開したことを起点に、Google・Anthropic・Perplexityなど主要AI企業が相次いで独自クローラーを展開しました。現在では複数のAIクローラーが日々あなたのサイトを訪問しており、その目的・挙動・対応方法を把握することが、Webサイト運営者にとって欠かせない知識になっています。

OpenAIの公式ドキュメント（OpenAI Crawlers）や、Googleの公式ガイド（Google Search Central – AI Features and Your Website）では、各クローラーの詳細な仕様と制御方法が公開されています。

AIクローラーはWebページを巡回してテキストやメタデータを収集し、AI モデルの学習またはリアルタイムの回答生成に活用します。仕組みを正しく理解しておくことで、自社サイトへの対応方針が立てやすくなります。

Webページを取得・解析して回答生成に使う流れ

AIクローラーは大きく4つのステップでコンテンツを収集します。まずURLを発見し、次にHTTPリクエストでHTMLを取得。その後テキストやメタデータを抽出・構造化し、最終的に学習データセットまたは回答生成のコーパスへ格納します。

• URLの発見（サイトマップ・被リンク・前回クロール履歴）
• HTTPリクエストによるHTML取得
• テキスト・メタデータの抽出と構造化
• 学習データまたはリアルタイム回答コーパスへの格納

クローラーの種類によって用途が異なります。学習用クローラー（GPTBotなど）は取得データをモデル訓練に使用し、検索用クローラー（OAI-SearchBotなど）はユーザーの質問に対する引用・回答生成に即時利用します。この2種類を混同しないようにしましょう。

動作の順序としては、「robots.txtの確認→許可パスへのアクセス→コンテンツ取得」という流れが基本です。なお、OpenAIの公式ドキュメントでは「GPTBotがクロールしたページは将来のモデル改善に使われる可能性がある」と明記されています。(出典: OpenAI公式ドキュメント – Crawlers)

JavaScriptレンダリングへの対応状況

AIクローラーの多くはJavaScriptを実行できません。Vercelとデジタルマーケティング調査会社MERJの調査によると、AIクローラーの約69%はJavaScriptを実行できないとされています。クライアントサイドレンダリング（CSR）のサイトでは、HTMLのみを返す静的な状態しか取得されません。

Next.jsやNuxtなどのSSR（サーバーサイドレンダリング）またはSSG（静的サイト生成）を採用していれば、AIクローラーがコンテンツを正しく取得できる可能性が高まります。一方でSPAやReact単体構成では、AIクローラーに「空ページ」が見える状態になりうる点に注意が必要です。

各AIクローラーのJavaScript対応状況は公式に公開されていないものが多く、自サイトのアクセスログを確認してどの範囲が正しく取得されているか把握することをおすすめします。

robots.txtをどの程度遵守するか

OpenAI・Anthropic・Google・Perplexityなどの主要AI企業は、robots.txtの遵守を公式に表明しています。しかし実態は異なる面もあります。TollBitの2025年Q2レポートによると、AIボットリクエストの13.26%がrobots.txtの指示を無視しており、2024年Q4の3.3%から大幅に増加しています。

そもそもrobots.txtは技術的な強制力を持たない「お願い」です。法的拘束力もないため、悪意ある・小規模な不明クローラーは無視することがあります。主要クローラー間の遵守状況には以下のような差があります。

クローラー	robots.txt遵守	備考
GPTBot（OpenAI）	遵守宣言あり	独立検証でも逸脱確認なし
ClaudeBot（Anthropic）	遵守宣言あり	公式ドキュメントで明記
Bytespider（ByteDance）	遵守しない報告あり	複数サイト運営者が無視を報告
xAI Grok関連	一部で偽装の指摘	iPhoneのUAを偽装してアクセスとの個人検証レベルの情報あり

robots.txtだけでは完全な防御にはなりません。遵守しないクローラーへの対策としては、IPブロックやCloudflareなどのWAF（Web Application Firewall）の活用を検討することが現実的です。

AIクローラーの主な種類と代表的なユーザーエージェント一覧

AIクローラーは「目的」によって大きく3種類に分けられます。まず各種類の役割を整理したうえで、代表的なユーザーエージェント（UA）を一覧表にまとめます。

Cloudflareの2024年5月〜2025年5月の調査では、AIと検索クローラーのトラフィックが年間18%増加。2025年5月時点ではGPTBotがAIクローラーシェア約30%でトップに立っており、AIクローラーの存在感は急速に高まっています。(出典: Cloudflare Blog – From Googlebot to GPTBot: who’s crawling your site in 2025)

学習用クローラー：基盤モデルの訓練データ収集に使われる

学習用クローラーの目的は、LLM（大規模言語モデル）の学習データセットを構築することです。クロールしたコンテンツはモデルの重みに反映されるため、AIが「何を知っているか」に直接影響します。

代表的なUAには以下があります。

• GPTBot（OpenAI）
• ClaudeBot / anthropic-ai（Anthropic）
• Google-Extended（Google）
• Applebot-Extended（Apple）
• CCBot（Common Crawl）
• Bytespider（ByteDance）
• meta-externalagent（Meta）
• cohere-ai（Cohere）

Cloudflare調査（2025年5月）では、GPTBotのリクエスト数が2024年5月比で約305%増を記録。meta-externalagentも新規参入ながらシェア約19%を占めるまで急拡大しました。(出典: Cloudflare Blog)

robots.txtでブロックすることでAIモデルの訓練データから除外できます。ただし、すでに学習済みのデータは残るため、ブロックは「今後の収集を止める」措置である点に注意してください。また学習用UAは検索用UAとは別のため、ブロックしても検索順位への影響はありません。

検索用クローラー：AI検索の回答生成・引用に使われる

検索用クローラーは、ユーザーが質問した際にリアルタイムまたは準リアルタイムで参照するWebコンテンツを収集します。収集したコンテンツはAI検索の回答・引用元として表示されます。

代表的なUAは次の3つです。

• OAI-SearchBot（OpenAI／ChatGPT Search用）
• PerplexityBot（Perplexity AI）
• Claude-SearchBot（Anthropic）

OAI-SearchBotをブロックするとChatGPT Searchの回答・引用から除外されるとOpenAI公式が明言しています。同様に、Claude-SearchBotをブロックするとClaudeの検索インデックスに登録されなくなります。(出典: OpenAI Crawlers 公式ドキュメント／Anthropic クローラーサポートページ)

PerplexityBotはCloudflare調査でリクエスト数が+157,490%という爆発的な成長を記録しており、AI検索市場での存在感が際立っています。

ユーザー主導フェッチャー：ユーザー操作に応じてURLを取得する

ユーザー主導フェッチャーは、ユーザーが会話中にURLを貼るなどの操作を行ったとき、そのページをAIがリアルタイムで取得して回答に活用します。自律的にWebを巡回するクローラーとは異なり、ユーザーのアクションを起点とします。

代表的なUAは以下です。

• ChatGPT-User（OpenAI）
• Claude-User（Anthropic）
• Perplexity-User（Perplexity AI）

OpenAI公式は「ChatGPT-Userはユーザーに代わって直接アクションを実行するためにのみ使用され、自動的にWebをクロールするためには使用されない」と明記しています。(出典: OpenAI Crawlers 公式ドキュメント)

ChatGPT-Userのリクエスト数は2024年5月比で+2,825%と急増しており、ユーザーがAIを使ってサイトを参照する機会が急速に増えていることがわかります。Claude-Userをブロックすると、ユーザー指向のWeb検索でサイトの可視性が低下する可能性があります。(出典: Cloudflare Blog／Anthropic クローラーサポートページ)

主要AIクローラーの一覧表

ここまで解説した3分類の主要クローラーを一覧表に整理します。robots.txtへの対応可否と推奨対応も合わせて確認してください。

UA名	運営元	分類	主な用途	robots.txt対応	推奨対応
GPTBot	OpenAI	学習用	LLM訓練データ収集	○	学習を許可しない場合はブロック
OAI-SearchBot	OpenAI	検索用	ChatGPT Search引用	○	AI検索に表示されたい場合は許可
ChatGPT-User	OpenAI	フェッチャー	ユーザー指定URLの取得	○	基本的に許可推奨
ClaudeBot	Anthropic	学習用	Claude訓練データ収集	○	学習を許可しない場合はブロック
Claude-SearchBot	Anthropic	検索用	Claude検索インデックス	○	AI検索に表示されたい場合は許可
Claude-User	Anthropic	フェッチャー	ユーザー指定URLの取得	○	基本的に許可推奨
Google-Extended	Google	学習用	Gemini等の訓練データ	○	学習を許可しない場合はブロック
PerplexityBot	Perplexity AI	検索用	Perplexity回答生成	○	AI検索に表示されたい場合は許可
Perplexity-User	Perplexity AI	フェッチャー	ユーザー指定URLの取得	○	基本的に許可推奨
meta-externalagent	Meta	学習用	Metaモデルの訓練データ	○	学習を許可しない場合はブロック
FacebookBot	Meta	フェッチャー	SNSシェア時のOGP取得	○	基本的に許可推奨
Applebot-Extended	Apple	学習用	Apple AI機能の訓練	○	学習を許可しない場合はブロック
Applebot	Apple	検索用	Spotlight・Safari検索	○	基本的に許可推奨
Bytespider	ByteDance	学習用	TikTok等モデルの訓練	○	ポリシー確認のうえ判断
CCBot	Common Crawl	学習用	公開データセット構築	○	多くのLLM訓練に利用。許否を検討
cohere-ai	Cohere	学習用	Cohereモデルの訓練	○	学習を許可しない場合はブロック

OpenAI・Anthropic・Googleはクローラーが使用するIPアドレス範囲を公式JSONファイルで公開しています。robots.txtを無視して巡回する「偽装クローラー」の判定にも活用できます。

自社サイトへのAIクローラーアクセスを確認する方法

「AIクローラーが来ているのかどうか分からない」という方に向けて、最も確実な方法はサーバーログを直接確認することです。GA4などのアクセス解析ツールには通常ボットのアクセスが記録されないため、ログ確認が唯一の現状把握手段になります。

サーバーログのUser-AgentでGPTBotやClaudeBotを特定する

ApacheやNginxのアクセスログには、各リクエストのUser-Agent（UA）文字列が記録されています。grepコマンドで主要AIクローラーのUA名を一括検索するのが最速の確認方法です。

# Nginx / Apache 共通で使えるgrepコマンド例
grep -i 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|PerplexityBot|Google-Extended|Bytespider|meta-externalagent' /var/log/nginx/access.log

確認すべき主なUA文字列は以下のとおりです。各社の公式ドキュメントに基づいています。

• GPTBot・OAI-SearchBot・ChatGPT-User（OpenAI）
• ClaudeBot・Claude-SearchBot（Anthropic）
• PerplexityBot（Perplexity AI）
• Google-Extended（Google Gemini等の学習用）
• Bytespider（ByteDance）・meta-externalagent（Meta）

cPanelやPleskなどの共有ホスティング環境では、管理画面の「Raw Access Logs」機能からログファイルをダウンロードして同様に確認できます。GoAccessやAWStatsといったログ解析ツールを使えば、ボットごとのトラフィックをグラフで可視化することも可能です。

GA4にはボットトラフィックの自動フィルタリングが適用されているため、AIクローラーのアクセスはGA4のレポートには通常反映されません。AIクローラーの実態把握はサーバーログで行ってください。

IPアドレス・逆引きDNSで偽装クローラーを見分ける

User-Agent文字列は誰でも偽装できます。たとえばターミナルからcurl -A "GPTBot"と入力するだけで、GPTBotを名乗ったリクエストを任意のサイトに送ることが可能です。そのため、UA名だけで正規クローラーと判断するのは危険です。

正規クローラーかどうかを確認するには、「FCrDNS（Forward Confirmed rDNS）」と呼ばれる二段階の名前解決を使います。手順は以下のとおりです。

• ログに記録されたIPアドレスを取得する
• 逆引きDNSでIPからホスト名を確認する
• そのホスト名を正引きDNSで解決し、元のIPと一致するか照合する

# ① 逆引きDNS（IPからホスト名を確認）
host 23.98.XX.XX
# 例: 23.98.XX.XX.domain.pointer openai.com

# ② 正引きDNS（ホスト名からIPを確認）
host openai.com
# 返ってきたIPが ① のIPと一致すれば正規クローラー

また、OpenAI・Anthropic・Googleはそれぞれ正規クローラーのIPレンジをJSON形式で公開しています。ログのIPをこのリストと照合することで、より効率的に正規・偽装を判別できます。

CloudflareのWAF機能「Control AI Crawlers」（セキュリティ→ボット管理）を使うと、UI操作だけで主要AIクローラーの制御とアクセスログの確認が一括でできます。コマンド操作が難しい環境では有力な選択肢です。

クロール頻度・転送量でサーバー負荷を把握する

AIクローラーのアクセス総量は増加傾向にあります。Cloudflareの調査（2024年5月〜2025年5月）によると、AI・検索クローラーの総トラフィックは年間18%増加し、2025年4月には2024年5月比で+32%のピークに達しました。（出典：Cloudflare Blog – From Googlebot to GPTBot: who’s crawling your site in 2025）

ログから特定UAのリクエスト数と転送量を集計するには、以下のコマンドが役立ちます。

# GPTBotのリクエスト数を時間帯別に集計（Nginxログの例）
grep -i 'GPTBot' /var/log/nginx/access.log 
  | awk '{print $4}' 
  | cut -d: -f1-2 
  | sort | uniq -c | sort -rn

# GPTBotの総転送量（バイト）を合計
grep -i 'GPTBot' /var/log/nginx/access.log 
  | awk '{sum += $10} END {print sum " bytes"}'

同一UAから数秒間隔で連続リクエストが来ている場合は、偽装または悪意あるクローラーの疑いがあります。その場合はIPブロックやWAFのレート制限（一定時間内のリクエスト数を上限設定する機能）で対処しましょう。

robots.txtにCrawl-delayディレクティブを記述することで、対応クローラーにアクセス間隔を指示できます。ただし、主要AIクローラーがこのディレクティブを遵守するかどうかは各社の実装次第であるため、過度な期待は禁物です。

AIクローラーが自社サイトに与える影響

AIクローラーへの対応は、メリットとデメリットの両面があります。すべてを一律に拒否するのではなく、クローラーの種別と自社サイトの状況に応じて判断することが重要です。

メリット：AI検索からの引用・認知・送客の機会を得られる

ChatGPT SearchやPerplexity、Google AI Overviewsといったサービスで自社コンテンツが引用されると、ブランド認知や専門性の訴求につながります。AIクローラーを受け入れることは、こうした新しい流入チャネルを獲得する機会でもあります。

AI経由の流入はコンバージョン率（CVR）や滞在時間が高い傾向が報告されています。通常の検索流入と比較して転換率が高く、滞在時間も長いとの試算があります。また、Googleは公式サイトで「AI Overviews経由のクリックはより長い滞在を示す」と言及しています。
(出典: Google Search Central – AI Features and Your Website)

Google AI Overviewsの表示シェアは2025年時点で全検索の25%以上に拡大しており、AI検索経由の露出機会は今後さらに増える見込みです。

デメリット：サーバー負荷の増大

AIクローラーの増加はサーバーへの負荷を直接押し上げます。AI＋検索クローラーの総トラフィックは2024年5月から2025年5月の1年間で18%増加し、ピーク時（2025年4月）には前年比で32%増を記録。GPTBotのリクエスト数は同期間で約305%増と急増しています。
(出典: Cloudflare Blog – From Googlebot to GPTBot: who’s crawling your site in 2025)

クローラーの高頻度アクセスは帯域やCPU負荷を圧迫し、通常ユーザーへのレスポンスタイムに影響する可能性があります。

Cloudflare・AkamaiなどのWAF（Web Application Firewall）のデフォルトのレート制限により、GPTBotがHTTP 429やHTTP 403を受けて意図せずブロックされるケースも確認されています。意図しないブロックが発生していないか、定期的にサーバーログを確認しましょう。

デメリット：コンテンツの無断学習・著作権上のリスク

AIクローラーに取得されたコンテンツが、著作権者に無断で訓練データに組み込まれることへの懸念は無視できません。The New York TimesやCNNなど上位100サイトのうち30社超がGPTBotをブロック済みです。また、2025年12月の調査では、上位ニュースサイトの79%が少なくとも1つのAI訓練ボットをブロックしていると報告されています。

著作権法上の解釈は各国・各ケースで異なり、現時点では法的グレーゾーンが多い状況です。権利保護の観点でブロック対応を検討する場合は、専門の法律家への確認を推奨します。

robots.txtでクローラーをブロックしても、すでに学習済みのコンテンツには遡って適用されません。ブロック設定は「今後のクロール」にのみ有効です。（参考: OpenAI公式ドキュメント）

デメリット：アクセス解析データへの混入

GA4（Google Analytics 4）はボットフィルタリングを自動適用しているため、主要なAIクローラーは通常GA4の数値には混入しません。ただし、サーバーログにはすべてのリクエストが記録されるため、ログベースの分析はAIクローラーのアクセスを含んだ数値になる点に注意が必要です。

非公式のUser-Agentを使う偽装クローラーは、GA4のフィルタリングをすり抜けてセッション数や直帰率に影響する可能性があります。また、AIクローラーが原因で異常なクロールバジェット消費が発生している場合は、Google Search Consoleのクロール統計からも確認できます。

AIクローラーをブロックすべきか許可すべきかの判断基準

「全部ブロック」か「全部許可」かで悩む必要はありません。クローラーの種別（学習用・検索用）とサイトの種別を組み合わせた2軸のマトリクスで、個別に許可・拒否を設定するのが基本方針です。

OpenAI公式ドキュメントでは「OAI-SearchBotとGPTBotの設定は独立しており、個別に制御できる」と明言されています。（出典: OpenAI Crawlers 公式ドキュメント）。クローラーをまとめて扱うのではなく、目的ごとに使い分ける発想が重要です。

許可を推奨するケース：BtoB・サービスサイト・メディア

AI検索への引用が、認知拡大やリード獲得に直結するサイトは、積極的に許可を検討すべきです。

• BtoBサービスサイト：AI検索（ChatGPT Search・Perplexity等）に製品・サービスが引用されることがブランド認知とリード獲得に直結するため、OAI-SearchBot・PerplexityBotの許可を推奨
• オープンメディア・ニュースサイト（広告収益型）：AI検索からの引用で認知拡大・送客が期待できる。ゼロクリック（※AIが回答を完結させてサイトへの流入が発生しないリスク）にも注意しつつ許可を検討
• 開発者向けドキュメント・技術ブログ：CursorやGitHub CopilotなどAI搭載のコーディングアシスタントが参照するため、llms.txtを整備したうえで許可が有利
• SEO強化を目的とする場合：OAI-SearchBot・Claude-SearchBotをブロックするとAI検索の引用から外れ、長期的な可視性に影響する可能性がある

ブロックを推奨するケース：有料コンテンツ・機密情報・独自データ

コンテンツの無断利用が収益モデルや情報優位性を損なうリスクがあるサイトは、学習用クローラーのブロックを優先すべきです。

• 有料会員向けコンテンツ・サブスクリプションメディア：GPTBot・ClaudeBot・Google-Extended（※Geminiなど生成AI向けの学習クローラー）のブロックを推奨。コンテンツが無償で学習・引用されると収益モデルを毀損する懸念がある
• 機密情報・社内ドキュメント・法務・財務情報：robots.txtによるブロックに加え、サーバーレベルのIP制限も併用して多重に防御する
• 独自調査データ・一次調査レポート：競合やAIに無断利用されることで情報の優位性が失われるリスクがあるためブロックを検討
• ECサイトの価格・在庫データ：競合他社がAIを活用して収集・分析するリスクを考慮し、部分的なブロックまたはCrawl-delay設定を検討

Crawl-delayとは、クローラーのアクセス間隔を遅らせる指示です。完全ブロックではなく、サーバー負荷の軽減や過剰なデータ収集の抑制に使われます。

学習用と検索用で許可・拒否を使い分けるのが基本方針

クローラーは「学習用」「検索用」「フェッチャー」の3種に大別できます。サイト種別と掛け合わせた2軸のマトリクスで考えると、設定の方針が整理しやすくなります。

OpenAI公式は「GPTBotを拒否しながらOAI-SearchBotを許可することで、学習には使われないがChatGPT Searchには表示される」と明記しています。（出典: OpenAI Crawlers 公式ドキュメント）。また、Google-ExtendedをブロックしてもGooglebotによる通常のインデックスとAI Overviewsへの表示は維持されます。（出典: Google Search Central – Googleの一般的なクローラー）

以下のテーブルで、サイト種別ごとの推奨設定をまとめます。

サイト種別	学習用クローラー （GPTBot・ClaudeBot・ Google-Extended）	検索用クローラー （OAI-SearchBot・ Claude-SearchBot）
BtoBサービスサイト	許可（モデルへの認知）	許可（AI検索への引用）
オープンメディア・技術ブログ	許可	許可
有料サブスクリプションメディア	拒否	状況次第（有料導線への誘導が可能なら許可）
ECサイト	拒否 or Crawl-delay	許可（集客目的）
機密・社内ドキュメント	拒否＋IP制限	拒否＋IP制限

AIクローラーをブロック・制御する具体的な方法

AIクローラーの制御手段は、robots.txt・メタタグ・サーバー設定・WAFなど複数のレイヤーに分かれており、それぞれ適用範囲と強制力が大きく異なります。robots.txtはあくまで「お願い」であり、すべてのクローラーが遵守するわけではありません。複数の手段を組み合わせた多層防御が現実的なアプローチです。

robots.txtでUser-Agentごとに許可・拒否を設定する

robots.txtはもっとも基本的な制御手段です。ただし、TollBitの2025年Q2データでは13.26%のクローラーがrobots.txtを無視しているとされており、万能ではありません。まずは書き方の基本を押さえておきましょう。

全AIクローラーを一括拒否する書き方

主要AIクローラーを個別に列挙してブロックするのが、もっとも誤爆リスクの低い方法です。以下のサンプルを参考にしてください。

# OpenAI
User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

# Anthropic
User-agent: ClaudeBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Claude-SearchBot
Disallow: /

User-agent: Claude-User
Disallow: /

# Google
User-agent: Google-Extended
Disallow: /

# Perplexity
User-agent: PerplexityBot
Disallow: /

User-agent: Perplexity-User
Disallow: /

# ByteDance
User-agent: Bytespider
Disallow: /

# Common Crawl
User-agent: CCBot
Disallow: /

# Meta
User-agent: meta-externalagent
Disallow: /

User-agent: FacebookBot
Disallow: /

# Cohere
User-agent: cohere-ai
Disallow: /

# Apple
User-agent: Applebot-Extended
Disallow: /

User-agent: * に Disallow: / を書くと全クローラーをまとめて拒否できますが、GooglebotやBingbotまでブロックされるリスクがあります。SEOへの影響を避けるために、AIクローラーは個別に指定する方法を推奨します。

robots.txtはクロールの「お願い」にすぎません。悪意あるクローラーや遵守しないボットには効果がない点を念頭に置いてください。

特定クローラーのみを個別に制御する書き方

「学習データ収集はブロックしつつ、AI検索への表示は維持したい」という場合は、クローラーごとに制御を分けられます。OpenAI公式ドキュメントでは、GPTBotとOAI-SearchBotの設定は独立しており個別に制御できると明記されています。

# 学習クローラーをブロック・検索用クローラーは許可（OpenAIの例）
User-agent: GPTBot
Disallow: /

# OAI-SearchBot は記述しない → デフォルトで許可

# 特定ディレクトリのみ制御する例
User-agent: ClaudeBot
Allow: /blog/
Disallow: /premium/

# アクセス頻度を制限する（Crawl-delay）
User-agent: PerplexityBot
Crawl-delay: 10

Crawl-delay でアクセス頻度の制限を試みることもできますが、主要AI企業がCrawl-delayを遵守するかどうかは各社によって異なります。また、robots.txtの変更がChatGPT Searchの表示に反映されるまで約24時間かかるとOpenAI公式が記述しています。

(出典: OpenAI Crawlers 公式ドキュメント)

メタタグ（noindex・noai）でページ単位に制御する

robots.txtがサイト全体・ディレクトリ単位の制御であるのに対し、メタタグはページ単位できめ細かく制御できます。有料会員ページや個人情報を含む動的ページなど、特定ページだけ保護したい場合に有効です。

• 有料会員向けコンテンツページ
• 個人情報・問い合わせフォームを含むページ
• 社内資料・ダウンロードコンテンツ
• AI Overviewsへのスニペット表示を制限したいページ

Googleは公式ドキュメントで、nosnippet・max-snippet・data-nosnippet タグを使ってAI Overviewsなどへのスニペット表示を制限できると記述しています。

<!-- インデックスと引用を制限 -->
<meta name="robots" content="noindex">

<!-- スニペット表示を制限（Google AI Overview等） -->
<meta name="robots" content="nosnippet">
<meta name="robots" content="max-snippet:0">

<!-- 一部ツールが参照する画像AI向けタグ -->
<meta name="robots" content="noai">
<meta name="robots" content="noimageai">

noai や noimageai は一部の画像生成AIが参照するとされていますが、主要LLMクローラーが遵守するかは未確認です。robots.txtほど広く認識されていない点に注意してください。

(出典: Google Search Central – AI Features and Your Website)

.htaccessやサーバー設定でIPレベルで遮断する

OpenAI・AnthropicなどはIPアドレスのレンジをJSON形式で公開しています。これを.htaccessやNginxの設定・ファイアウォールルールに追加することで、robots.txtに依存しない強制ブロックが実現できます。

Apacheの場合（.htaccess）:

<RequireAll>
    Require all granted
    Require not ip 23.102.140.112/28
    Require not ip 13.65.240.240/28
</RequireAll>

Nginxの場合（server{}ブロック）:

server {
    deny 23.102.140.112/28;
    deny 13.65.240.240/28;
    # 他のIPレンジを追加
}

OpenAIを含む各社のIPレンジは定期的に更新されます。設定を放置すると新しいIPからのクロールを見逃すため、公式ドキュメントを参照しながら定期的なメンテナンスが必要です。また、IPを変えたり偽装したりする悪意あるクローラーには対応できない点も覚えておきましょう。

WAF・CDNで高負荷・悪質クローラーを防ぐ

WAF（Webアプリケーションファイアウォール）やCDNを活用すると、UIベースで細かなクローラー制御が可能になります。CloudflareのBot Managementや「Control AI Crawlers」機能では、GPTBot・ClaudeBot等をUIで個別に許可・ブロック・チャレンジ設定できます。

CloudflareなどWAFのデフォルトのレート制限が、robots.txtで許可しているにもかかわらずGPTBotをHTTP 429・403でブロックするケースが多発しています。AI検索への可視性を意図せず失う「意図しないブロック」問題です。AI検索への露出を維持したい場合は、WAFのホワイトリストに正規AIクローラーのIPレンジを登録してください。

Akamai・AWS WAF・Imperva・Fastlyなどにも同様のデフォルトルールが存在します。ある調査では、約27%のBtoBサービス・ECサイトがCDNレベルで意図せず主要LLMクローラーをブロックしていると報告されています。CDN・WAF設定とrobots.txtが矛盾していないか、定期的に監査することが重要です。

AIクローラーに引用・参照されるためのコンテンツ最適化（GEO・LLMO対策）

AIクローラーを「制御する」だけでなく、AIに積極的に引用される側になるという視点が、これからのWeb運営では重要です。GEO（Generative Engine Optimization）・LLMO（Large Language Model Optimization）とは、生成AIや大規模言語モデルの回答に自社コンテンツを引用・参照させるための最適化手法です。従来のSEOが「検索順位」を目指すのに対し、GEO・LLMOは「AI回答への登場回数」を成果指標とする点が大きく異なります。

AI検索経由の訪問者は、特定の疑問を解決しようとして来訪するため、コンテンツとの親和性が高い傾向があります。対策の投資対効果を考えるうえでも、引用獲得を意識したコンテンツ設計は取り組む価値があります。

結論ファーストで回答に使われやすい文章構造にする

AIは「質問→直接的な回答」の構造を好みます。冒頭の1〜2文で明確な答えを述べ、その後に根拠や詳細を続ける「結論ファースト」の構成が、AI回答への引用率を高める基本です。

FAQセクション・箇条書き・定義ブロックなど、AIが回答として切り取りやすいフォーマットを積極的に活用しましょう。Google AI Overviewsは検索1位のページだけでなく、特定のサブトピックに強い下位ページも引用することがあります。順位が低くても、特定の問いに対して明確に答えているページは引用対象になり得ます。

また、ロングテールクエリ（検索ボリュームは少ないが具体的な検索語句）への詳細な回答を含む情報密度の高いコンテンツは、AI Overviewsに引用されやすいという傾向があります。GEOにおける「成功の指標」は、クリック数から「AIによる引用・参照回数」へとシフトしつつある点も押さえておきましょう。

一次情報・統計・専門家の見解で信頼性を高める

LLMは信頼性の高い情報源を優先して引用する傾向があります。独自調査・一次データ・実体験など、E-E-A-T（経験・専門性・権威性・信頼性）の「経験」要素を含むコンテンツは、AIに引用されやすい情報源として評価されます。

Googleは引き続きE-E-A-Tを重視しており、著者情報・出典リンク・組織情報のスキーママークアップが信頼シグナルになるとAI検索ガイドラインで言及しています。統計・数値・日付付きのファクトを含むコンテンツは、LLMが回答生成で参照しやすい構造になります。

具体的には、専門家の引用・監修クレジット・著者ページへの内部リンクを設置することでE-E-A-Tを強化できます。「誰が書いたか」「いつ更新されたか」が明示されているコンテンツほど、AIに信頼される傾向があります。

• 独自調査・一次データの掲載
• 著者名・監修クレジットの明示
• 数値・統計・更新日の記載
• 著者ページへの内部リンク設置

構造化データとセマンティックHTMLで機械可読性を上げる

AIクローラーがコンテンツの意味を正確に解釈できるよう、schema.orgの構造化データを実装することが効果的です。Article・FAQPage・HowTo・Organization・Personなどのスキーマは、コンテンツの種類や文脈をAIに伝える役割を果たします。

Google公式（Google Search Central）は、AI Overviewsへの表示にFAQスキーマや特別なAI向けファイルは必須ではないと述べています。一方で、クロール許可・有用なコンテンツ・適切な内部リンクというSEOの基本は引き続き重要だと明示しています。（出典: Google Search Central – AI Features and Your Website）

セマンティックHTML（適切なh1〜h6・article・section・main要素）を正しく使うことで、クローラーがコンテンツの階層構造を正確に把握できます。加えて、XMLサイトマップを最新の状態に保ち、robots.txtのSitemap:ディレクティブで場所を明示することで、AIクローラーへのページ発見を促せます。

構造化データを実装したページはAI回答に引用・参照される可能性が高まるとの調査報告もあります。既存ページへの後付け実装でも効果が期待できるため、優先度の高いページから順に対応を進めましょう。

llms.txtでAIに読ませる情報を整理する

llms.txtはサイトルートに置くMarkdown形式のファイルで、AIが参照すべき重要ページや情報を整理して案内するための補助的なナビゲーションファイルです。2024年9月にJeremy Howard（Answer.AI）が提唱し、llmstxt.orgでコミュニティ仕様として公開されています。

SEMrushの実証実験では、2025年8月〜10月の期間にGPTBot・Google-Extended・PerplexityBot・ClaudeBotのllms.txtページへのアクセスがゼロだったと報告されています。現時点で効果が確認されている主な用途は、CursorやGitHub Copilotなどのコーディングアシスタントへの情報提供にとどまっています。

robots.txtとの違いを端的に整理すると、次のとおりです。

ファイル	目的	強制力
robots.txt	クロールの許可・拒否を指示するプロトコル	あり（遵守しないクローラーも存在）
llms.txt	AIへのコンテンツ構造のナビゲーション案内	なし（任意参照）

llms.txtは「AIに自サイトを正しく理解させる情報整理ツール」として捉えるのが現実的です。クローラー制御が目的なら、robots.txtやサーバー設定を優先してください。

(出典: SEMrush Blog – What Is LLMs.txt & Should You Use It?)

よくある質問

AIクローラーへの対応方針を決めるうえで、現場でよく浮かぶ疑問を5つに絞って回答します。設定前に確認しておきたいポイントを押さえておきましょう。

まとめ：クローラー種別×サイト種別で「制御と活用」を両立する

AIクローラーへの対応は、「全拒否」でも「全許可」でもありません。学習用クローラーと検索用クローラーを使い分け、サイトの性質に合わせて制御することが、2025〜2026年時点での最適解です。

Cloudflareの調査では、AI・検索クローラーのトラフィックが年間18%増加しています。(出典: Cloudflare Blog「From Googlebot to GPTBot: who’s crawling your site in 2025」)

「何も対応しない」こと自体が、今やリスクになりうる状況です。

学習用・検索用クローラーを分けて考える

この記事で繰り返し強調してきた通り、クローラーには大きく2つの役割があります。

GPTBot・ClaudeBot・Google-ExtendedはAIモデルの学習データ収集が目的です。一方、OAI-SearchBot・Claude-SearchBot・PerplexityBotはAI検索への回答生成に使われます。

後者を拒否すると、AI検索エンジンの回答から自社コンテンツが除外される可能性があります。両者を混同せず、目的別に許可・拒否を判断することが重要です。

今すぐ取るべき2つのアクション

難しく考える必要はありません。まず以下の2ステップから始めましょう。

• robots.txtを開き、GPTBot・ClaudeBot・Google-Extendedなど主要AIクローラーのUser-Agent設定を確認・更新する
• サーバーログでGPTBot・ClaudeBot等のアクセス頻度・対象URLを確認し、意図しないページへのクロールがないか把握する

robots.txtの設定変更だけでは完全な制御はできません。WAFやCDNのボットフィルタリング設定とあわせて整合性を確認することを推奨します。

「ブロック」と「最適化」の二刀流で臨む

学習データとして使われたくないコンテンツは適切にブロックし、AI検索で引用・参照されたいコンテンツはLLMO（Large Language Model Optimization）の観点で最適化する。この二刀流の発想が、これからのWeb運営には求められます。

制御と活用を両立する視点を持つことで、AIクローラーの増加という環境変化を、自社サイトの露出拡大につなげることができます。