AIクローラー向けrobots.txt：2026年版ガイド

結論から先に

「AIボット」をひとくくりのものとして考えるのは、もうやめたほうがいい。そこには経済的な意味合いがまったく異なる三つのクラスがあり、そのすべてに一律でDisallowを一行書くという対応は、ほぼ確実に誤ったトレードオフである。

学習クローラーは、あなたのカタログから学ばせてほしいと求めている。検索インデクサーは、それを引用できるようにしてほしいと求めている。ユーザー起点のフェッチャーは、いままさに自社製品について質問している顧客そのものである。一つ目を遮断するのはライセンスに関する判断だ。三つ目を遮断するのは、電話を切るのと変わらない。

Forresterの調査によれば、法人バイヤーの94%が直近の購買プロセスでAIを利用していた。AIのユーザーエージェントを名乗って自社オリジンに届くリクエストのうち、無視できない割合はスクレイピングではない——部品表を開いたまま、意思決定の途中にいる誰かである。robots.txtはその両者を区別すべきだが、ほとんどのサイトはそうなっていない。

2026年に押さえるべきAIユーザーエージェント一覧

この表のうち五つの点は、日常的に誤解されるか見落とされている。明示しておく価値がある。

`Google-Extended`と`Applebot-Extended`はクローラーではない。 どちらも何かを取得することはない。これらは権限を示すトークンである。Google-Extendedは、Googlebotがすでにクロール済みのコンテンツを、Geminiの学習や回答のグラウンディングに使ってよいかどうかを制御する。Appleのドキュメントも、Applebot-Extendedは「ウェブページをクロールしない」ものであり、「Applebotユーザーエージェントがクロールしたデータの利用方法を判断するためだけに用いられる」と明記している。Applebot-ExtendedをDisallowにしても、Siri、SpotlightやSafariの結果から外れるわけではない。

ユーザー起点のフェッチについて、Anthropicだけが例外的である。 OpenAIはChatGPT-Userについて「これらの動作はユーザーによって開始されるため、robots.txtのルールは適用されない場合がある」と述べている。PerplexityはPerplexity-Userが「robots.txtのルールを概ね無視する」としている。Googleは自社のユーザー起点フェッチャーについて「取得がユーザーの要求によるものであるため、これらのフェッチャーは概ねrobots.txtのルールを無視する」とドキュメントに記している。AmazonはAmzn-Userが「robots.txtのすべてのディレクティブに従うとは限らない」としている。これに対してAnthropicは、自社のボットがrobots.txtを遵守すると明記し、ユーザー起点のリクエストをサイト運営者が制御するためのトークンとしてClaude-Userを挙げている。つまり、一式まとめてDisallowにすると、実際に止まるのはClaudeだけということになる——多くの人が意図しているのとは正反対の結果である。

AmazonとMetaは、いずれも用途を分けた複数のボットを運用している。 Amazonbotのほかに、AmazonはAmzn-SearchBot（AlexaやRufusを含む検索体験向け）とAmzn-User（リアルタイムのユーザー操作向け）をドキュメントに記載しており、いずれも生成AIの学習目的でクロールすることはないとしている。Metaは学習とインデックス作成にMeta-ExternalAgentを、ユーザーの要求によるフェッチにMeta-ExternalFetcherを用いており、後者はrobots.txtを迂回する場合がある。

Bytespiderはrobots.txtの問題ではなく、ポリシーの問題である。 ByteDanceはrobots.txtを尊重すると表明しているが、サイト運営者からはそうではないという報告が広く上がっている。止めたいのであればエッジで止めることであって、このファイルに頼るべきではない。

`Gemini-Deep-Research`について一言。 Googleが公開しているクローラーのドキュメントには、このトークンは主要クローラーにもユーザー起点のフェッチャーにもまだ掲載されていない。しかし実際に稼働しており、大手ディストリビューターはすでに名指しで対応している——Digi-Keyのrobots.txtは、GPTBot、ChatGPT-User、OAI-SearchBot、PerplexityBot、Perplexity-User、ClaudeBot、Claude-User、Claude-SearchBotと並べて、Google-ExtendedとGemini-Deep-Researchの双方を明示的に許可している。自社でも記載しておくとよい。robots.txtに認識されないトークンが書かれていても害はない。

各クラスを遮断すると、実際に何を失うのか

カタログがすでに公開されており、アグリゲーター各社にミラーされてもいるメーカーやディストリビューターにとって、学習クラスの遮断はほぼ象徴的な行為にとどまる。データは代理店の掲載情報やCommon Crawlを経由して、いずれにせよモデルに届くからだ。変わるのは、モデルが保持するのが誰の版のデータになるか、という点だけである。残る二つのクラスの遮断に至っては、公開カタログにとっての利点はまったくない。

そのままコピーして使えるrobots.txt

レシピA：エージェントからの可視性を最大化する

カタログが公開されており、正確に見つけられ引用されることが商業上の利益になる、そうしたメーカーやディストリビューターにとっての妥当な既定値である。

# --- Answer engines and user-triggered fetchers ---
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
User-agent: Amzn-SearchBot
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/
Allow: /

# --- Training crawlers and permission tokens ---
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Meta-ExternalAgent
User-agent: Amazonbot
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/
Allow: /

# --- Everything else ---
User-agent: *
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/

Sitemap: https://www.example.com/sitemap.xml
Sitemap: https://www.example.com/sitemap-products.xml

レシピB：検索・取得は許可し、学習は拒否する

モデルの学習には寄与しないと意識的に決めたうえで、それでも見つけられ引用されたいと考えている組織向け。ただし、その代償には注意が必要だ。Google-ExtendedをDisallowにすると、学習だけでなくGeminiのグラウンディングからも自社コンテンツが外れる。

User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
Allow: /

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Bytespider
User-agent: Meta-ExternalAgent
User-agent: Amazonbot
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /

User-agent: *
Disallow: /account/

レシピC：カタログは開放し、それ以外は閉じる

表に出したい資産がカタログとドキュメントライブラリであり、それ以外のサイト資産はノイズでしかない場合に有効である。

User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: ClaudeBot
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
Disallow: /
Allow: /products/
Allow: /catalog/
Allow: /datasheets/
Allow: /documents/
Allow: /sitemap-products.xml

RFC 9309では、パスの一致がもっとも長いルールが優先される。したがって、該当する接頭辞についてはAllowの行が一律のDisallow: /を上書きする。ただし、そうなっているはずだと決めつけず、結果を必ず検証すること——エッジケースにおけるパーサーの挙動は、いまだに実装ごとにばらつきがある。

伝わる形で「ノー」を示す：Content Signals

robots.txtが制御するのはアクセスである。バイト列がいったん配信されたあとの利用については、何も述べていない。2025年9月24日に開始されたCloudflareのContent Signals Policyは、同じファイルに機械可読な利用の意向表明を追加するもので、三つのシグナルからなる。search（検索インデックスの構築と検索結果の提供）、ai-input（コンテンツを一つ以上のAIモデルに入力すること）、ai-train（AIモデルの学習またはファインチューニング）である。

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Disallow: /account/

Cloudflareは、マネージドrobots.txtを有効にしていた380万を超えるドメインにsearch=yes, ai-train=noを適用し、ai-inputについては推測で埋めることを避けて意図的に未設定のままとした。これは表明された選好であって、強制力を持つ仕組みではない——とはいえ、明確で、日付が入り、機械が読める意思表示であり、備えておく価値はある。

なぜ「沈黙」が「ノー」になりつつあるのか

この二十年、robots.txtにルールが書かれていないことは「イエス」を意味してきた。その既定値がインフラ層で撤回されつつあり、このファイルに一度も触れたことのないメーカーが、CDNの判断によってオプトアウトさせられている。

• 2025年7月1日 — ウェブのおよそ五分の一の前段に位置するCloudflareが、主要インフラ事業者として初めてAIクローラーを既定で遮断し、新規に導入されるすべてのドメインに対して、許可するかどうかを最初に尋ねるようになった。
• 2025年9月24日 — Content Signals Policyが提供開始され、マネージド対象の380万ドメインに既定でai-train=noが適用された。
• 2026年7月1日 — Cloudflareは、2026年9月15日以降、新規ドメイン、既存顧客の新規サイト、および既存の無料プラン顧客のすべてについて、広告を表示するページではTraining（学習）とAgent（エージェント）のクローラー区分を既定で遮断すると発表した。Search（検索）は引き続き許可される。SearchとTrainingを兼ねる多目的クローラーには、もっとも制限の強いルールが適用される。

最後の項目は正確に読む必要がある。広く誤って引用されているからだ。対象は広告で収益化しているページに限られており、メーカーのカタログの大半はそれに当たらない。すでに影響が及んでいるのは2025年の変更のほうである。サイトを最近モダンなCDNに載せた、あるいは無料プランを使っているのであれば、誰もそう決めていないのにAIクローラーをすでに拒否している可能性がある。決めつける前に確認すること。

robots.txtは「お願い」にすぎない。強制するのはWAFである

善意で行われた設定の大半は、ここで失敗する。robots.txtは、それに従うクライアントだけが読む任意のプロトコルである。一方でボットマネージャーは、検証済みの送信元IPによって分類を行う強制的なゲートであり、既定のルールセットはブラウザらしく見えないものに対して日常的にチャレンジや遮断をかける。Allow: /を読んだうえでJavaScriptチャレンジを返されたクローラーは、ファイルに何が書かれていようと遮断されたのである。

主要な運営者はいずれもIPレンジを公開しており、適切に許可リストへ登録できるようになっている。

ログに記録された特定のアドレスが本当にOpenAIのものかを確認するには、次のようにする。

python3 - <<'EOF'
import ipaddress, json, urllib.request
probe = ipaddress.ip_address("132.196.86.5")
data = json.load(urllib.request.urlopen("https://openai.com/gptbot.json"))
nets = [ipaddress.ip_network(p.get("ipv4Prefix") or p.get("ipv6Prefix"))
        for p in data["prefixes"]]
print(any(probe in n for n in nets if n.version == probe.version))
EOF

エッジ側で押さえるべきルールは、次の三つでおおむね足りる。

1. 01ボットスコアのルールが発火する前に、検証済みのIPレンジを許可リストに登録する。 対象は公開カタログとドキュメントのパスだけに限定すること。
2. 02それらのパスをJavaScriptチャレンジとレート制限の対象から除外する。 ブラウザではないクライアントにチャレンジは解けないし、40,000点のSKUをインデックスするクローラーは、人間向けに調整されたレート制限に確実に引っかかる。
3. 03ユーザーエージェント文字列で許可リストを組まないこと。 これは自由記述のヘッダーにすぎない。まずIPで照合し、必要に応じてユーザーエージェントを併用する。

オリジンごとに設定は別であることを忘れないこと。製品サイト、ドキュメント用のサブドメイン、CDNのホスト名には、それぞれ固有のrobots.txtと固有のWAFポリシーが必要である。

設定が効いたことを、ログからどう確認するか

ログで検証していない設定は、仮説にすぎない。結果を判断するまでには数日みておくこと。運営者はrobots.txtをキャッシュしており、Metaのドキュメントは変更の反映に最大24時間かかる場合があると注意を促し、Amazonは自社のクローラーが直近30日以内にキャッシュした写しを使う場合があるとしている。そのうえで、次を実行する。

grep -aiE "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Gemini-Deep-Research|Applebot|Amazonbot|Bytespider|CCBot|Meta-External" access.log | wc -l

次に、エージェント別・ステータスコード別に分解する。本当に重要なのはこの数字である。

awk '/GPTBot/ {print $9}' access.log | sort | uniq -c | sort -rn

見るべきポイントは次のとおり。

1. 01エージェントごとに、リクエスト数がゼロでないこと。 公開カタログで72時間にわたりどのAIエージェントからもリクエストがゼロなら、それは人気がないのではなく、上流で遮断されているということである。
2. 02ステータスの分布が2xx中心であること。 403が並んでいれば、WAFがrobots.txtを上書きしている。404が並んでいれば、サイトマップか内部リンクが、すでに存在しないURLを指している。
3. 03製品ページのパスだけでなく、ドキュメントのパスも現れていること。 /datasheets/が一度も出てこないなら、技術資料のライブラリは見えていないということだ。
4. 04レスポンスサイズが妥当であること。 製品URLに対して4〜15 KBの200応答が並んでいる場合、たいていはクローラーがクライアント側でレンダリングされる空の外枠を受け取っている。形式上は許可されていても、実質的には無意味である。
5. 05ユーザー起点のエージェントが、そもそも現れていること。 ChatGPT-User、Claude-User、Perplexity-Userのトラフィックは、買い手の関心を示すリアルタイムのシグナルとして、手元にあるもののなかでは最も近い。個別にレポートする価値がある。

よくある失敗

• 学習クローラーを狙った一括ルールで、ユーザー起点のフェッチャーまで誤って遮断してしまう。
• robots.txtは正しく設定したのに、WAFには手をつけないまま放置する。スイッチは二つあり、その両方を入れなければならない。
• ドキュメント用サブドメイン、DAM、CDNを忘れる。RFC 9309のもとでは、これらはいずれも別個のオリジンである。
• CSSやJavaScriptのアセットへのクローラーのアクセスを遮断する。テキストしか読まないクローラーには関係ないが、GooglebotとApplebotはいずれもレンダリングを行うため、アセットを与えなければ、それらに見えている内容が劣化する。
• アグリゲーターが自社データを正確に掲載していると思い込む。そこに載っているのは、スクレイピングした時点の、スクレイピングした内容にすぎない。
• llms.txtを代替物として扱う。主要な運営者でこれを読むと表明したところはなく、ログを見てもリクエストされた形跡はまず出てこない。

Partsgraphは2026年8月、北米・欧州・アジアにわたる世界984社のディストリビューターおよびメーカーのドメインを監査した。何らかの形で明示的なAIクローラー方針を公開していたのは、わずか19%にとどまる——しかもそのなかでは、主要なAIクローラーを遮断していたサイトが、招き入れていたサイトの2倍を超えていた。MCPエンドポイントを掲げていたところは皆無だった。AI可視性スコアの中央値は100点満点中50点。この差はまだ競争上の優劣にはなっていない——だからこそ、きちんと書かれたrobots.txtは、製品データ部門が投じられる一時間あたりの効果としては、いまなお最大級のものであり続けている。

自社ドメインにAIクローラーが実際にどこまで到達できるかは、[/audit](/audit) にある無料のPartsgraphグレーダーで確認できる。