この記事は、Zennに投稿した完全版
AIクローラーを一括りにするな：学習・検索・ユーザーfetch・AIエージェントを分けて制御するAIO Bot Governance
の要点整理です。

完全版では、OpenAI / Google / Apple / Amazon / Anthropic / Meta / Perplexity / xAI / ByteDance / Common Crawl などを横断し、公式資料・観測レポート・robots.txt例・ログ観測項目まで含めて整理しています。

Qiita版では、まず実務で使うためのエッセンスに絞ります。

先に結論

AIクローラーを「AI bot」と一括りに扱うと、robots.txt設計を誤ります。

これからのWeb運用では、少なくとも以下を分けて考える必要があります。

分類	代表例	基本方針
学習系	GPTBot, ClaudeBot, Applebot-Extended	許可 / 拒否を明示する
検索・引用系	OAI-SearchBot, PerplexityBot, Applebot	AI検索露出を狙うなら許可候補
ユーザー起点fetch	ChatGPT-User, Google user-triggered fetchers	robots.txtだけで考えない
SNS / OGP系	facebookexternalhit	雑に止めない
広域アーカイブ系	CCBot	収録可否を判断する

重要なのは、会社名ではなく用途で分けることです。

「OpenAIを許可する / 拒否する」では粗すぎます。
同じOpenAI系でも、GPTBot と OAI-SearchBot では意味が違います。

GPTBot：モデル学習系
OAI-SearchBot：ChatGPT検索・引用系
ChatGPT-User：ユーザー起点fetch系

つまり、AI学習には使わせたくないが、AI検索には出したいという設計が成立します。

なぜ従来のrobots.txt感覚では足りないのか

従来のWeb運用では、クローラー対応の主役は検索エンジンでした。

たとえば、

Googlebotを許可する
不要なパスをrobots.txtで閉じる
sitemap.xmlを出す
検索結果に載る
検索流入が返ってくる

という比較的単純な関係でした。

しかし、AI時代にはbotの役割が分岐しています。

同じ「クロール」に見えても、実際には以下のように目的が違います。

目的	例
将来のAIモデル学習	GPTBot, ClaudeBot, Applebot-Extended
AI検索・回答生成の引用元	OAI-SearchBot, PerplexityBot
ユーザーがURLを投げた時の取得	ChatGPT-User, Google user-triggered fetchers
SNSリンクカード生成	facebookexternalhit
広域Webアーカイブ	CCBot
広告・LP検証	OAI-AdsBot, Google AdsBot
ブラウザ操作型AIエージェント	ChatGPT Operator, Google-Agent等

これらをすべて同じ User-agent: * で扱うと、意図しない副作用が出ます。

たとえば、AI学習を拒否したいだけなのに、AI検索・SNSプレビュー・ユーザーfetchまでまとめて潰してしまう可能性があります。

GPTBotとOAI-SearchBotは別物

OpenAI公式は、OpenAI Crawlers の中で、複数のcrawler / user agentを説明しています。

ここで重要なのは、GPTBot と OAI-SearchBot が分けられていることです。

bot	主な分類	役割
GPTBot	学習系	OpenAIの生成AIモデル改善・学習用
OAI-SearchBot	検索・引用系	ChatGPT検索でWebサイトを表示・引用するため
ChatGPT-User	ユーザー起点fetch	ユーザーやGPT Actions等の指示に基づく取得
OAI-AdsBot	広告・検証系	広告LPの安全性・関連性確認

つまり、GPTBot を止めることと、OAI-SearchBot を止めることは違います。

AI学習には使わせたくない。
しかし、ChatGPT検索では引用されたい。

この場合、概念的には以下のような設計になります。

# ChatGPT検索には出したい
User-agent: OAI-SearchBot
Allow: /

# OpenAIの学習には使わせたくない
User-agent: GPTBot
Disallow: /

もちろん、実運用ではUser-Agentだけを信じるのではなく、IPレンジ、rDNS、ASN、アクセス頻度、レスポンスコードも合わせて見るべきです。

Googleは「分類して考える」ための良い教材

Google公式は、Google crawlers and fetchers で、Googleのcrawler / fetcherを複数分類で説明しています。

特に重要なのは、以下です。

Common crawlers
Special-case crawlers
User-triggered fetchers

Google公式は、user-triggered fetchers について、ユーザー要求によって起動するため、一般にrobots.txtを無視すると説明しています。

ここから分かることは、単純です。

ユーザー起点fetchは、通常の自動クロールと同じではありません。

そのため、

User-agent: *
Disallow: /

を書いたからといって、すべてのAI経由アクセスを制御できるとは限りません。

robots.txtは重要です。
しかし、それはアクセス統治の第一層にすぎません。

ApplebotとApplebot-Extendedも別物

Apple公式は、Applebotについてで、ApplebotがSpotlight、Siri、SafariなどAppleエコシステム内の検索技術に使われると説明しています。

一方で、Appleは Applebot-Extended も説明しています。

Applebot-Extended は、Apple Intelligenceなど生成基盤モデルのトレーニング利用を制御するための指定です。

つまり、Appleでも以下を分けて考える必要があります。

bot	主な分類	役割
Applebot	検索・発見系	Spotlight / Siri / Safariなど
Applebot-Extended	学習制御	Apple基盤モデル学習への利用を拒否する指定
iTMS	特殊fetch	Apple Podcasts等

概念的には、以下のような設計ができます。

# Apple検索系は許可
User-agent: Applebot
Allow: /

# Apple基盤モデル学習は拒否
User-agent: Applebot-Extended
Disallow: /

ここでもポイントは同じです。

検索露出とAI学習を分ける。

SNSプレビューbotを雑に止めてはいけない

Meta公式の Web Crawlers では、FacebookExternalHitなどのcrawlerが説明されています。

facebookexternalhit は、Facebook / Instagram / MessengerなどでURLが共有された時のリンクプレビュー生成に関わるbotです。

これをAI学習系botと混同して雑に止めると、SNS上の見え方が壊れる可能性があります。

たとえば、

OGP画像が出ない
タイトルが出ない
説明文が反映されない
SNS共有時のカードが崩れる

といった問題が起き得ます。

AI学習を止めたい場合でも、SNSプレビューbotまでまとめて止める必要があるとは限りません。

Common CrawlはAI企業botではないが無関係ではない

Common Crawl公式の FAQ は、CCBotがまずrobots.txtを確認し、許可された場合にHTTP GETでページを取得すると説明しています。

Common CrawlはOpenAIやGoogleのようなAI製品企業ではありません。
しかし、AI時代のデータ供給網を考える上では重要です。

なぜなら、Common Crawl由来のWebアーカイブは、検索・研究・機械学習・AIデータセットの上流に位置し得るからです。

そのため、CCBot は以下のように扱うと分かりやすいです。

観点	内容
直接のAI検索botか	いいえ
AI学習と関係し得るか	はい、上流データとして関係し得る
制御方法	robots.txt / Crawl-delay
実務判断	収録されたいか、されたくないかで判断

判断早見表

実務では、まず以下の表で考えるのが分かりやすいです。

したいこと	方針
AI学習には使わせたくない	GPTBot, ClaudeBot, Applebot-Extended等をDisallow
AI検索には出したい	OAI-SearchBot, PerplexityBot, Applebot等をAllow
SNSプレビューは壊したくない	facebookexternalhitは別扱い
ユーザーfetchを観測したい	access log / WAF / CDNで見る
広域アーカイブを避けたい	CCBotをDisallow
高負荷botを抑えたい	Rate limit / Crawl-delay / WAFで制御
bot偽装を疑う	IP / ASN / rDNS / TLS fingerprintを見る

最小robots.txt例

以下は、あくまで考え方を示すサンプルです。
そのままコピペするのではなく、自サイトの目的に合わせて調整してください。

# ChatGPT検索には出したい
User-agent: OAI-SearchBot
Allow: /

# OpenAIの学習には使わせたくない
User-agent: GPTBot
Disallow: /

# Apple検索系は許可
User-agent: Applebot
Allow: /

# Apple基盤モデル学習は拒否
User-agent: Applebot-Extended
Disallow: /

# Common Crawlへの収録を避けたい場合
User-agent: CCBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

この例の考え方は、以下です。

検索・引用系は許可
学習系は拒否
広域アーカイブは方針次第
sitemapは明示
ただしrobots.txtだけで完全制御できるとは考えない

ログで見るべき項目

AI bot対応では、robots.txtを書いて終わりではありません。
実際に誰が来ているかを見ます。

見る項目	理由
User-Agent	第一識別子
IP / ASN	公式botか、クラウド経由か、住宅用回線かを見る
rDNS	Googlebot / Applebot等の真正性確認
path	`robots.txt`, `llms.txt`, `sitemap.xml` へのアクセス確認
status code	200 / 403 / 404 / 429 / 5xxを見る
request rate	高負荷botやバーストを検知
referrer / query	`utm_source=chatgpt.com` 等を見る
WAF action	allow / block / challenge の結果を見る

特に、User-Agentだけを信じるのは危険です。

User-Agentは名乗るだけなので、偽装できます。
そのため、重要なbotについては、IPレンジやreverse DNSも合わせて見る必要があります。

Google公式も、Verify requests from Google crawlers and fetchers で、Googleからのリクエスト確認方法を説明しています。

robots.txtだけでは足りない

繰り返しますが、robots.txtは重要です。
しかし万能ではありません。

理由は以下です。

限界	内容
強制力がない	robots.txtは協調的な指示であり、アクセス制御そのものではない
ユーザー起点fetchは別扱いの場合がある	Google user-triggered fetchersなど
User-Agentは偽装できる	bot名だけでは真正性を確認できない
非自己識別botには効きにくい	botとして名乗らないアクセスがある
実UAではない制御トークンもある	Google-ExtendedやApplebot-Extendedのような指定

したがって、実務では以下を組み合わせます。

robots.txt
sitemap.xml
llms.txt / llms-full.txt
access log
WAF / CDN
IP / ASN / rDNS
Rate limit
X-Robots-Tag
構造化データ
OGP / SNSプレビュー

llms.txtとrobots.txtは別々に考えない

AIOを考えるなら、llms.txt と robots.txt は別々に扱うべきではありません。

llms.txt：AIに何を読ませたいか
llms-full.txt：AIにどの文脈を正典として渡すか
robots.txt：どのbotに何を読ませるか
sitemap.xml：どのURLを発見させるか
WAF/CDN：不審・過剰・非自己識別アクセスをどう扱うか

つまり、AIOは「AIに読ませる文章設計」だけではありません。

AIに渡す意味と、その意味を読むbotの制御を同時に設計する必要があります。

この考え方を、私は完全版では AIO Bot Governance と呼んでいます。

詳細版

この記事は要約版です。

詳細版では、以下まで整理しています。

OpenAI / Google / Apple / Amazon / Anthropic / Meta / Perplexity / xAI / ByteDance / Common Crawl の分類
bot別の役割
公式資料と観測資料の切り分け
Cloudflare等の観測レポート
robots.txt例
WAF / CDN / IP / rDNS / TLS fingerprint
ログ観測項目
AIOとbot governanceの接続
参考URL集

完全版はこちらです。

AIクローラーを一括りにするな：学習・検索・ユーザーfetch・AIエージェントを分けて制御するAIO Bot Governance

まとめ

AIクローラー対応は、もはや「botを許可する / 拒否する」だけでは足りません。

重要なのは、botを用途で分けることです。

学習系
検索・引用系
ユーザー起点fetch
SNS / OGP系
広域アーカイブ系
広告・検証系
GUI / Agent実行系
非自己識別・難読化系

少なくとも、GPTBot と OAI-SearchBot は同じではありません。
Applebot と Applebot-Extended も同じではありません。
facebookexternalhit をAI学習botと同じように扱うと、SNSプレビューが壊れる可能性があります。

AIOは、llms.txt を置くだけでは終わりません。
robots.txt を書くだけでも終わりません。

これから必要なのは、どのAI botに、何を、どの目的で、どこまで許すかを設計することです。