📑

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

に公開
テーマ「GitHub Copilot 活用選手権」
SEO
Security
LLMs
robots
AIO
tech

この記事の位置づけ

本稿は、AI時代のWebサイト運用における AIO Bot Governance を扱う。

ここでいうAIO Bot Governanceとは、単に robots.txt を書くことではない。
また、単に llms.txt や llms-full.txt を設置して、AIに読ませる文脈を整えることでもない。

本稿の主張は明確である。

本稿は「AI bot一覧」ではない。
一覧表だけなら、既に多くのSEO記事やbot directoryが存在する。

本稿の目的は、AI botを実務上の制御対象として分類し、AIO、robots.txt、llms.txt、sitemap、構造化データ、アクセスログ、WAF/CDN、IP/rDNS/TLS fingerprint までを一体で扱う、実務的な設計論としてまとめることにある。

この記事のタグ

Zennのtopicsには5個しか入れられないため、本文上では以下のタグ群を扱う。

`#AIO` `#AIOptimization` `#robots.txt` `#llms.txt` `#AIcrawler` `#GPTBot` `#OAI-SearchBot` `#Googlebot` `#Applebot` `#ClaudeBot` `#PerplexityBot` `#CCBot` `#MetaExternalAgent` `#Bytespider` `#BotManagement` `#WAF` `#CDN` `#SEO` `#GEO` `#LLMO` `#Security` `#Observability`

読み方

この記事は長い。
ただし、辞書のように読めるよう、以下の構成にしている。

  • まず全体像を掴む
  • 次に9分類を見る
  • 主要ベンダーごとの違いを見る
  • 実務でどう設計するかを見る
  • 最後に参考URL集で裏取りする

「急いでいる読者」は、次の3章だけ読めばよい。

  • 先に結論：AIO Bot Governanceの5原則
  • AI botの9実務分類
  • 実務設計：許可・拒否・観測・防御の4層モデル

エビデンスの扱い

本稿では、情報源を3段階に分ける。

区分 例 記事内での扱い
公式一次情報 OpenAI crawler docs、Google crawlers docs、Applebot docs、Common Crawl FAQ 仕様根拠として扱う
準一次・観測情報 Cloudflare Blog、Cloudflare Perplexity report、Cloudflare AI Crawl Control 実運用上の観測・リスク補強として扱う
二次整理・bot directory CrawlerCheck、DataDome bot directory、Search Engine Journal、51Degrees 公式で埋まらない分類・観測補助として扱う

なぜこの記事を書くのか

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

典型的には、Googlebotを許可する。
不要なパスは robots.txt で制御する。
サイトマップを出す。
検索結果に載る。
検索流入が返ってくる。

この関係は比較的単純だった。

しかし、AI時代には状況が変わった。

同じ「bot」に見えても、目的が違う。

  • 将来の基盤モデルを学習するbot
  • AI検索結果に引用するためのbot
  • ユーザーがURLを投げた時だけ取得するfetcher
  • 広告ランディングページを検証するbot
  • SNSでリンクカードを生成するbot
  • 広域アーカイブを作るbot
  • ブラウザを操作し、DOMやボタンを実際に扱うagent
  • そもそも自分をbotとして名乗らないトラフィック

これらをすべて同じ User-agent: * で扱うと、設計は破綻する。

たとえば、AI学習には使わせたくないが、AI検索で引用されたい場合がある。
この場合、学習系botは拒否し、検索・引用系botは許可する必要がある。

逆に、AI検索で引用されるメリットが薄く、サーバー負荷やコンテンツ再利用リスクが高い場合は、検索系botも制限対象になる。

さらに、ユーザー起点fetch系は通常の自動クロールとは違い、サービス側では「ユーザーの代理アクセス」と位置づけられることがある。Googleは User-triggered fetchers について、ユーザー要求で起動するため、一般に robots.txt を無視すると説明している。

つまり、AI bot対応は、もはやSEOの小技ではない。

それは、AI時代のアクセス統治である。

先に結論：AIO Bot Governanceの5原則

本稿では、AIO Bot Governanceを次の5原則で定義する。

原則 内容 実務での意味
1. 用途で分ける 会社名ではなく、botの目的で分類する OpenAIだから許可/拒否、ではなくGPTBotとOAI-SearchBotを分ける
2. 学習と検索を分ける TrainingとSearch/Citationを同一視しない AI学習は拒否し、AI検索露出は維持する設計が可能
3. fetchを別枠で扱う ユーザー起点fetchは通常クロールではない robots.txtだけで完全制御できると考えない
4. 宣言を疑う UA文字列は偽装できる IP、rDNS、ASN、TLS fingerprint、行動パターンで補強する
5. 意味供給とアクセス統治を接続する llms.txt等の意味設計とrobots/WAFを分離しない 何を読ませるかと、誰に読ませるかを同時に設計する

1. AI botの9実務分類

まず、AI botを実務で扱いやすいように9分類へ圧縮する。

これは学術的分類ではなく、Web運用・AIO・セキュリティ・ログ分析のための分類である。

分類 主目的 代表例 基本方針
学習系 基盤モデルやAI製品改善用のデータ収集 GPTBot, ClaudeBot, Amazonbot, Meta-ExternalAgent, Applebot-Extended, Bytespider 許可/拒否を明示。検索露出とは分ける
検索・引用系 AI検索・回答生成・引用元リンク OAI-SearchBot, Claude-SearchBot, PerplexityBot, Amzn-SearchBot, Meta-WebIndexer, Applebot AIO露出を狙うなら許可候補
ユーザー起点fetch系 ユーザーがURLや質問を投げた時の取得 ChatGPT-User, Claude-User, Perplexity-User, Amzn-User, Google user-triggered fetchers robots.txtだけでは不十分。ログ観測が重要
広域アーカイブ系 Web全体のアーカイブ・研究データ構築 CCBot AI企業botではないが、上流データ供給層として扱う
SNS/OGP系 SNS共有時のリンクカード生成 facebookexternalhit 雑に止めると共有プレビューが壊れる
広告・検証系 広告LP安全性・関連性・ブランドセーフティ OAI-AdsBot, AmazonAdBot, Meta-ExternalAds, Google AdsBot 広告運用有無で別管理
マルチモーダル収集系 画像・音声・動画・メディア取得 imageSpider, FacebookBotの一部, GoogleOther-Image/Video 画像・音声AIOと接続
GUI/Agent実行系 ブラウザ操作・DOM解釈・フォーム入力 ChatGPT Operator/Atlas, Google-Agent, ByteBot, xAI-Web-Crawler robots/UAではなく挙動観測・WAFが中心
非自己識別・難読化系 botとして名乗らない、または偽装するアクセス Grok系の観測報告, Perplexity stealth疑義系 公式仕様ではなくログ・TLS・ASN・行動で検知

この分類で重要なのは、会社名ではなく目的で分けることである。

「OpenAIを許可する」「Googleを拒否する」「Metaを止める」という発想は粗い。
正しくは、同じ会社の中でも学習系・検索系・fetch系・広告系を分ける。

2. OpenAI：GPTBotとOAI-SearchBotを混同してはいけない

OpenAI公式の Overview of OpenAI Crawlers は、OpenAIが自動またはユーザー要求で動くWeb crawlers / user agentsを使うと説明している。さらに、OAI-SearchBot と GPTBot のrobots.txtタグにより、Webサイト管理者がAIとの関係を制御できると説明している。

特に重要なのは、公式ページの説明では、OAI-SearchBotとGPTBotの設定は独立している点である。OpenAIは、たとえばOAI-SearchBotを許可して検索結果に表示される一方で、GPTBotを拒否して生成AI基盤モデルの学習用途を拒否できる、と説明している。

2.1 OpenAI系botの実務分類

bot 分類 主用途 設計判断
GPTBot 学習系 OpenAIの生成AI基盤モデルの学習・改善 学習利用を避けたいなら拒否候補
OAI-SearchBot 検索・引用系 ChatGPT Search等でWebサイトを検索結果に出す AIO露出を狙うなら許可候補
ChatGPT-User ユーザー起点fetch系 ユーザーやGPT Actions等による取得 通常クロールと分けて観測
OAI-AdsBot 広告・検証系 ChatGPT広告LPの安全性・関連性確認 広告運用時は別枠管理

OpenAI公式は、OAI-SearchBotについて、ChatGPTの検索機能でWebサイトを表示するために使われるbotだと説明している。
一方、OAI-AdsBotは広告として提出されたページの安全性確認や関連性判断に使われ、生成AI基盤モデルの学習には使われないと説明されている。

この構造から分かることは単純である。

2.2 robots.txt例

AI学習には使わせたくないが、ChatGPT検索の引用・露出は維持したい場合は、概念的には以下のような設計になる。

# Allow ChatGPT search visibility
User-agent: OAI-SearchBot
Allow: /

# Disallow OpenAI model-training crawler
User-agent: GPTBot
Disallow: /

ただし、実運用ではOpenAIの公開IPレンジ、アクセスログ、応答コード、botの挙動を合わせて見る必要がある。
UA文字列だけではなりすましに弱い。

2.3 OpenAI系の実務判断表

判断したいこと 見るべきbot 使う制御 注意点
ChatGPT検索に出したい OAI-SearchBot robots.txtで許可 学習許可とは別
OpenAI学習には使わせたくない GPTBot robots.txtで拒否 過去取得分の削除とは別
ユーザーがURLを投げた時の挙動を見たい ChatGPT-User ログ観測/WAF 通常クロールと同一視しない
ChatGPT広告文脈を管理したい OAI-AdsBot LP制御/広告設定 SEOではなく広告検証文脈

3. Google：分類型Bot Governanceの標準例

Googleは、AI時代のbot分類を考える上で最も重要な参照例の一つである。

Google公式の Overview of Google crawlers and fetchers は、Googleのcrawler / fetcherを大きく以下のように分けている。

  • Common crawlers
  • Special-case crawlers
  • User-triggered fetchers

Google公式は、common crawlers について、GooglebotなどがGoogle製品のためにWebサイトを発見・スキャンするもので、automatic crawlsではrobots.txtを常に尊重すると説明している。

一方で、user-triggered fetchers は、ユーザー要求により起動するfetcherであり、一般にrobots.txtを無視すると説明されている。

3.1 Googleの分類が示すこと

Google分類 性質 AIO Bot Governance上の意味
Common crawlers 自動クロール、robots.txt準拠 通常の検索・発見向け
Special-case crawlers 特定プロダクト・合意・広告等 グローバルrobotsだけで判断しない
User-triggered fetchers ユーザー要求で起動 robots.txt制御だけでは不十分
User-triggered agents ユーザーに代わるAI/agent型アクセス DOM操作・行動観測が必要

Googleの設計は非常に示唆的である。

なぜなら、Google自身が「自動クローラー」と「ユーザー起点fetcher」を分けているからである。
これは、AI時代のbot governanceにおける基本原理と一致する。

3.2 Google-Extendedは実UAではなく制御トークン

Googleで特に注意すべきなのが Google-Extended である。

Google-Extendedは、通常のアクセスログに出てくる独立したクローラーUAではなく、robots.txtでAI利用を制御するためのプロダクトトークンとして扱うべきである。
つまり、Google-Extendedをログで探しても通常は見つからない。

これは、AI bot governanceにおける重要な教訓である。

3.3 Googleリクエスト検証

Googleは Verify requests from Google crawlers and fetchers で、Google crawler/fetcherのリクエスト検証方法を説明している。

実務では、次のような確認が必要になる。

確認項目 意味
User-Agent まずbot名を推定する
reverse DNS Google管理ホスト名か確認する
forward DNS 逆引き名が元IPへ戻るか確認する
IP range JSON 公開レンジと照合する
403/429/5xxログ 誤ブロックや過負荷を検出する

Googleは、bot分類だけでなく、検証プロトコルの標準例としても重要である。

4. Apple：ApplebotとApplebot-Extendedを分ける

Appleも、検索露出とAI学習制御を分ける分かりやすい例である。

Apple公式の Applebotについて は、Applebotでクロールされたデータが、Spotlight、Siri、SafariなどAppleエコシステムの検索技術を支えると説明している。さらに同ページでは、ApplebotによってクロールされたデータがApple Intelligence等の生成AI機能を実現する基盤モデルのトレーニングにも使われる場合があると説明している。

ただし、Appleは Applebot-Extended をrobots.txtで禁止することで、コンテンツが生成基盤モデルのトレーニングに使われることを拒否できるとも説明している。

Apple公式の Applebot、拡張機能、プライバシー も、Applebotが公開Web情報をクロールし、Webパブリッシャーがrobots.txtでApplebotのクロールやApple基盤モデル学習利用を制御できると説明している。

4.1 Apple系botの分類

bot 分類 主用途 設計判断
Applebot 検索・引用系 + 一部学習利用可能性 Spotlight, Siri, Safariなど Apple検索露出を維持するなら許可候補
Applebot-Extended 学習制御トークン Apple基盤モデル学習利用の拒否 AI学習を拒否したい場合にDisallow
iTMS 特殊fetch系 Apple Podcasts等 通常SEO/AIOとは別枠

4.2 robots.txt例

Appleの検索露出を維持しつつ、生成AI学習利用を拒否したい場合の考え方は以下である。

# Keep Apple search discovery available
User-agent: Applebot
Allow: /

# Opt out from Apple generative foundation model training
User-agent: Applebot-Extended
Disallow: /

これは、AIO Bot Governanceの理想形に近い。

検索露出は許可する。
学習利用は制御する。

この分離ができるかどうかが、AI時代のrobots.txt設計の重要点になる。

5. Amazon：Amazonbot / Amzn-SearchBot / Amzn-Userを分ける

Amazon公式の About AmazonBot は、Amazonbotおよび関連botについて説明している。特にAmazonはhost単位でrobots.txtを確認し、複数hostがある場合はそれぞれのhostのrobotsルールを尊重すると説明している。

Amazon系botは、AIO Bot Governanceの観点ではかなり重要である。
なぜなら、AmazonはEC、Alexa、Rufus、広告、Bedrock、Kendraなど、複数のプロダクト文脈を持つからである。

5.1 Amazon系botの実務分類

bot 分類 主用途 設計判断
Amazonbot 学習系/サービス改善系 Amazonサービス改善・一部AI関連利用 学習利用を避けたい場合は制御候補
Amzn-SearchBot 検索・引用系 Alexa/Rufus等の検索体験 露出目的なら許可候補
Amzn-User ユーザー起点fetch系 ユーザー要求による取得 ログ観測対象
AmazonAdBot 広告・検証系 広告LP等の検証 広告運用次第
Amazon Kendra / Q Business / Bedrock関連 RAG/企業内検索/AI基盤系 B2B・エンタープライズ文脈 公開Webとは別に要件定義

Amazon系は、単純な「Amazonbotを止める/許可する」ではなく、Amazon内のどのAI体験に関与したいかで判断すべきである。

6. Anthropic：ClaudeBot / Claude-SearchBot / Claude-Userの三分離

Anthropic系botについては、公式ドキュメントに加えて、SEO業界の報道でも三分離が確認されている。たとえば Search Engine Journal は、AnthropicがClaudeBot、Claude-User、Claude-SearchBotを分け、training、search indexing、user requestsの用途別に説明したと報じている。

また、Cloudflare AI Crawl Control bot reference でも、ClaudeBot、Claude-SearchBot、Claude-Userが分類対象として扱われている。

6.1 Anthropic系botの分類

bot 分類 主用途 設計判断
ClaudeBot 学習系 Claudeモデルの学習・改善 学習利用を避けたい場合は拒否候補
Claude-SearchBot 検索・引用系 Claude検索・回答精度向上 Claude検索露出を狙うなら許可候補
Claude-User ユーザー起点fetch系 ユーザー指定URL等の取得 仕様確認とログ観測が必要
Claude-Web / Claude Code / MCP経由 GUI/AgentまたはTool実行系 ユーザー環境・外部ツール連携 IP固定前提は危険

Anthropic系の重要点は、OpenAIと同様に、学習・検索・ユーザーfetchが分離していることである。
これは、AIベンダー全体で分類構造が収束し始めている証拠でもある。

7. Meta：AI botとSNSプレビューbotを混同すると壊れる

Metaは、bot governance上かなり難しい。
理由は、AI botとSNS共有系botが混在しているからである。

Meta公式の Meta Web Crawlers は、MetaのWeb crawlerを説明している。日本語ページでも、FacebookExternalHit の主目的は、Facebook、Instagram、MessengerなどMetaファミリーアプリで共有されたWebコンテンツをクロールすることだと説明されている。

一方、Stanford CRFMの Meta Transparency Report では、Meta-ExternalAgentがAIモデルtrainingや製品改善のためのcontent indexingに使われ、Meta-ExternalFetcherはユーザー要求のfetchとしてrobots.txtをバイパスする場合があると整理されている。

7.1 Meta系botの分類

bot 分類 主用途 設計判断
Meta-ExternalAgent 学習系 AIモデルtraining / 製品改善用indexing 学習利用を避ける場合は拒否候補
Meta-WebIndexer 検索・引用系 Meta AI検索・回答品質向上 露出目的なら検討
Meta-ExternalFetcher ユーザー起点fetch系 ユーザー要求による取得 robotsだけでは不十分な場合あり
facebookexternalhit SNS/OGP系 Facebook/Instagram/Messenger等のリンクプレビュー生成 雑に止めるとOGPプレビューが壊れる
Meta-ExternalAds 広告・検証系 広告・ビジネス関連 広告運用次第

Metaで最も危険なのは、Meta-ExternalAgentを止めたいからといって、facebookexternalhitまで雑に止めることである。

facebookexternalhitを止めると、SNSで共有された時のタイトル・画像・説明文プレビューが壊れる可能性がある。
これは、AI学習拒否とはまったく別の問題である。

8. Perplexity：公式仕様と観測上の疑義を分けて扱う

Perplexity公式の Perplexity Crawlers は、PerplexityBotとPerplexity-Userを分けて説明している。PerplexityBotは検索インデックスや引用元のためのbotであり、Perplexity-Userはユーザーの質問に応じてページを訪問するfetcherとして説明されている。公式説明では、これらはAI foundation modelのtrainingには使われないとされている。

また、Perplexityのヘルプセンターは、Perplexityがrobots.txtに従う方法 を説明している。

ただし、Perplexityについては観測上の疑義が強い。

Cloudflareは、Perplexity is using stealth, undeclared crawlers to evade website no-crawl directives において、顧客がrobots.txtとWAFでPerplexityBotおよびPerplexity-Userをブロックしたにもかかわらず、Perplexityが依然としてコンテンツへアクセスできていたという苦情を受けたと説明している。Cloudflareはテストドメインを作り、ステルス・未申告crawlerの利用を指摘した。

この件は、The Verge や GIGAZINE でも報じられている。一方で、Perplexity側はCloudflareの主張に反論しており、ここは公式確定情報ではなく、Cloudflareの観測・告発とPerplexity側反論が存在する領域として扱うべきである。

8.1 Perplexityから得られる教訓

論点 意味
公式bot仕様は重要 PerplexityBot / Perplexity-Userは公式に分かれている
公式仕様だけでは不十分 実アクセスが公式botだけとは限らない
WAF・ログ検証が必要 robots.txtだけで制御できたとは言えない
観測情報は観測情報として扱う 断定ではなく、検証対象として提示する

Perplexityは、次の記事における重要な反例である。

透明なbot governanceがある場合は、robots.txtと公式IPでかなり制御できる。
しかし、公式bot以外の経路が疑われる場合、アクセス統治はWAF・ログ・挙動分析の領域に進む。

9. xAI / Grok：非自己識別・動的探索型の扱い

xAI / Grok系については、公式の包括的なcrawler仕様が十分に公開・整理されているとは言いにくい。
そのため本稿では、xAI / Grokを 観測ベースのリスク例 として扱う。

xAI公式には Web Search や Regional Endpoints など、API・検索ツールに関する開発者向け情報がある。しかし、Webサイト管理者がrobots.txtやUAで包括的に制御できるcrawler仕様としては、OpenAI・Google・Apple・Common Crawlほど整備された一次情報は確認しにくい。

一方、Cloudflareは responsible AI bot principles の文脈で、AI botは透明性、説明責任、サイト運営者の選好尊重が必要だと主張している。

9.1 xAI/Grokを記事でどう扱うか

扱い 内容
確定情報 xAIがWeb Search等のツールを提供している
観測・疑義 Grok系が自分をbotとして明確に名乗らない可能性、UA偽装・住宅用プロキシ等の指摘
記事での役割 非自己識別・難読化系botの例
注意 公式仕様として断定しない

xAI/Grokから得られる教訓は、次の一点である。

10. ByteDance / Bytespider：高負荷・多UA・マルチモーダル収集の注意例

ByteDance系についても、公式一次情報だけで十分に固めるのは難しい。
しかし、観測系・bot directory・インフラ記事では、BytespiderはAI crawler文脈で頻繁に扱われている。

DataDomeのBytespider解説 や CrawlerCheckのBytespiderページ は、BytespiderをByteDance系のbotとして扱っている。
また HAProxyの記事 は、自社のAI crawler trafficの大部分がByteDance系Bytespider由来だったという観測を公開している。

10.1 ByteDance系botの分類

bot 分類 主用途として観測・整理されているもの 設計判断
Bytespider 学習系/検索系/高負荷crawler Doubao/Lark等のAI・検索・推薦系へのデータ供給とされる 負荷と目的を見て制限候補
TikTokSpider / TikTokBot SNS/推薦/収集系 TikTokエコシステム向け 公式性・負荷を確認
Doubaobot 学習/参照系 Doubao向けとされる 公式確認が弱い場合は観測扱い
imageSpider マルチモーダル収集系 画像・メディア収集 画像AIOと接続
ByteBot GUI/Agent実行系 ブラウザ自動化型とされる WAF・挙動観測対象

ByteDance系は、AIO Bot Governanceにおいて「多UA」「高負荷」「モバイルUA風」「マルチモーダル収集」という観点を持ち込む。

ここでも重要なのは、断定ではなく分類である。

11. Common Crawl：AI企業botではないが、上流データ供給層である

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

Common Crawl公式の FAQ は、CCBotがまずrobots.txtを確認し、許可された場合にHTTP GETでページを取得する自動crawlerであると説明している。User-Agentは CCBot/2.0 (https://commoncrawl.org/faq/) である。

Common Crawl公式の CCBot ページも、CCBotがWebデータ収集のためのcrawlerであることを示している。さらにFAQでは、CCBotが Crawl-delay に従うことも説明されている。

11.1 Common Crawlの位置づけ

観点 内容
直接のAI製品botか 違う
収集目的 広域Webアーカイブ・研究データ
データ形式 WARC等
AIとの関係 学習データ・検索データ・研究データの上流になり得る
制御 robots.txt、Crawl-delay、Common Crawlのopt-out等

AIO Bot Governanceでは、CCBotを「AI企業ではないから無関係」とは扱えない。

なぜなら、AI企業や研究者がCommon Crawl由来データを利用し得るからである。
つまり、CCBotはAI検索・生成AIの直接botではなく、AIデータ供給網の上流層として扱うべきである。

12. Mistral / DeepSeek / Cohere等：補助分類として扱う

Mistral、DeepSeek、Cohere等のbotもある。
これらは本稿の主軸ではないが、AIO Bot Governanceの分類を補強する材料として扱える。

これらの扱いは、次のように整理する。

系統 扱い
公式robots情報があるもの 公式情報を一次根拠にする
bot directoryのみで確認できるもの 二次資料として扱う
挙動観測が中心のもの 未確定・観測ベースとして扱う

本稿では主要ベンダーを中心に扱うため、Mistral / DeepSeek / Cohereは、参考URLと補助分類として掲載する。

13. 実務設計：許可・拒否・観測・防御の4層モデル

ここまでの分類を、実務設計へ落とす。

AIO Bot Governanceは、次の4層で設計する。

13.1 許可するもの

許可候補 理由
OAI-SearchBot ChatGPT検索/引用露出を狙う場合
Googlebot / GoogleOther系 Google検索・Google製品露出を狙う場合
Applebot Spotlight / Siri / Safari系露出を狙う場合
Claude-SearchBot Claude検索文脈に出したい場合
PerplexityBot Perplexityの引用付き回答に出したい場合
facebookexternalhit SNS共有プレビューを維持したい場合
CCBot 広域アーカイブ・研究データに入ることを許容する場合

13.2 拒否するもの

拒否候補 理由
GPTBot OpenAI基盤モデル学習への利用を避けたい場合
Applebot-Extended Apple基盤モデル学習への利用を避けたい場合
ClaudeBot Anthropic学習利用を避けたい場合
Meta-ExternalAgent Meta AI学習/製品改善への利用を避けたい場合
Bytespider 高負荷・不明瞭な用途・ByteDance系学習/検索利用を避けたい場合
CCBot 広域アーカイブへの収録を避けたい場合

13.3 観測するもの

観測対象 理由
ChatGPT-User ユーザー起点fetchとして通常クロールと違う
Perplexity-User ユーザー起点fetchと公式には説明される
Meta-ExternalFetcher ユーザー要求によるfetchとして扱われる場合がある
Google user-triggered fetchers Google公式がrobots.txt無視を説明している
xAI/Grok系 非自己識別やUA偽装が疑われる場合がある
ByteBot等 GUI/Agent型で通常crawlerと異なる

13.4 防御するもの

防御対象 防御方法
UA偽装bot IP/rDNS/ASN照合
非自己識別bot TLS fingerprint、行動パターン、WAF
高頻度crawler Rate limit、429、Crawl-delay、CDN rule
headless browser型agent JS挙動、DOM操作、フォーム操作、セッション挙動の監視
未申告crawler疑義 Cloudflare Bot Management等の利用

14. robots.txtだけでは足りない

robots.txt は重要である。
しかし、万能ではない。

Google公式の robots.txt仕様解釈 は、Googleがrobots.txtをどう解釈するかを説明している。これは検索エンジン運用では基本である。

しかし、AI bot governanceでは次の限界がある。

限界 内容
強制力がない robots.txtはアクセス制御ではなく、協調的な指示
ユーザー起点fetchは別扱いの場合がある Googleはuser-triggered fetchersが一般にrobots.txtを無視すると説明
UA偽装に弱い User-Agentは任意に名乗れる
非自己識別botには効かない botとして名乗らないアクセスは対象にできない
内部利用制御と外部fetchは別 Google-Extendedのようにログ上のUAではない制御もある

したがって、robots.txtは第一層にすぎない。

15. アクセスログで見るべき項目

AIO Bot Governanceでは、アクセスログが重要になる。

見るべき項目は、単なるUser-Agentだけではない。

項目 見る理由
timestamp バースト・周期・crawl patternを見る
IP 公式レンジやASNとの照合
User-Agent bot識別の第一シグナル
path llms.txt / llms-full.txt / robots.txt / sitemap.xml / assetsへのアクセス有無
status code 200/304/403/404/429/5xxの分布
referrer 人間流入かbot fetchか推測
query parameter utm_source=chatgpt.com 等のAI流入確認
ASN クラウド/住宅用/企業ネットワーク判定
reverse DNS 公式bot真正性の検証
request rate 負荷・異常クロール検出
accept-language 人間/機械っぽさの補助
TLS fingerprint UA偽装検出の補助
JS execution headless/agent型の検出補助

15.1 ログ分類の例

16. WAF/CDNで見るべき項目

WAF/CDNでは、以下を設計する。

設計項目 内容
Allowlist 公式IP/rDNSが確認できるbotを通す
Blocklist 明確に拒否したいbotを止める
Rate limit 高負荷botの頻度を抑える
Challenge 疑わしいagentにJS challenge等を出す
Path-based rule /llms.txt は通すが /admin は止める
Header validation UA以外のヘッダ整合性を見る
TLS fingerprint headless/偽装botの補助検出
Bot score Cloudflare等の機械学習判定を使う
Log export BigQuery/S3等へ送って分析する

Cloudflareは AI bot検出方法 や AI crawler制御 に関する資料を公開している。
また、Cloudflareの AI Crawl Control bot reference は、実務上のbot分類参照として使える。

17. ポートフォリオをケーススタディとして見る

ここからは、具体例として小型の公開ポートフォリオを扱う。

対象は、AI向けに以下を持つ静的SPAである。

17.1 ケーススタディの構造

17.2 AIO Bot Governance上の意味

この構成では、以下のように役割が分かれる。

ファイル 役割
llms.txt AI向けの入口、短縮正典、読む順序の提示
llms-full.txt 完全なGround Truth、エンティティ定義、履歴、制約
robots.txt どのbotに何を許可/拒否するかの第一層
sitemap.xml AI/検索botへの発見導線
WebP/MP3 HTML外に流通するasset-level AIO
AI2AI.md AI間の引き継ぎ・制約継承

AIO Bot Governanceの観点では、ここにさらにアクセスログ設計が必要になる。

つまり、次の段階はこうである。

  1. AI向け正典を用意する
  2. botごとの許可/拒否を設計する
  3. 実際にどのbotが来たか観測する
  4. bot挙動に応じてrobots/WAF/sitemap/llmsを調整する
  5. AI検索・引用・学習・fetchの結果を検証する

18. 実装テンプレート：AIO Bot Governanceのrobots.txt設計

以下は、概念テンプレートである。
そのまま使うのではなく、各サイトの目的に合わせて調整する。

18.1 AI検索露出は維持し、AI学習は制限する例

# ------------------------------
# AI search / citation crawlers
# ------------------------------
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Applebot
Allow: /

# ------------------------------
# AI training crawlers
# ------------------------------
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# ------------------------------
# Broad archive crawler
# ------------------------------
User-agent: CCBot
Disallow: /

# ------------------------------
# Sitemaps
# ------------------------------
Sitemap: https://example.com/sitemap.xml

18.2 AIOファイルを明示的に許可する例

User-agent: *
Allow: /llms.txt
Allow: /llms-full.txt
Allow: /sitemap.xml
Allow: /robots.txt

18.3 高負荷bot向けにCrawl-delayを入れる例

User-agent: CCBot
Crawl-delay: 2
Allow: /

注意点として、Crawl-delay はすべてのbotが従う標準仕様ではない。
Common CrawlはFAQでCrawl-delayを尊重すると説明しているが、Googleはrobots.txt仕様解釈の中でGoogle側の対応範囲を別途説明している。
つまり、Crawl-delay は万能ではない。

19. 意思決定フロー

実務では、次のフローで判断する。

20. リスク別の対策表

リスク 典型例 対策
AI学習に使われる GPTBot, ClaudeBot, Applebot-Extended, Meta-ExternalAgent robots.txtで明示拒否
AI検索から消える OAI-SearchBotやPerplexityBotを誤ブロック 検索系と学習系を分ける
SNSプレビューが壊れる facebookexternalhitを雑に止める SNS/OGP系は別分類
サーバー負荷が増える Bytespider, CCBot, ClaudeBot等 Rate limit / Crawl-delay / WAF
UA偽装される bot名だけ真似るアクセス IP/rDNS/ASN検証
robots.txtを無視される user-triggered fetcher / stealth疑義 WAF/CDN/ログ観測
AIに誤読される llms.txtなし、断片だけ読まれる llms.txt / llms-full.txt / schema
assetだけ流通する 画像・音声だけ拾われる XMP/ID3/ファイル名AIO
過剰ブロックする 検索botやSNSbotまで止める 用途別分類

21. AIO Bot Governanceチェックリスト

21.1 方針チェック

  • AI検索に出たいか
  • AI学習を許容するか
  • SNS共有プレビューを維持するか
  • Common Crawlへの収録を許容するか
  • 広告botを許可する必要があるか
  • ユーザー起点fetchをどう観測するか
  • GUI/Agent型アクセスをどう扱うか
  • 非自己識別botを想定しているか

21.2 ファイルチェック

  • robots.txt
  • sitemap.xml
  • llms.txt
  • llms-full.txt
  • JSON-LD
  • Open Graph
  • X-Robots-Tag
  • WebP XMP
  • MP3 ID3
  • canonical URL
  • asset filename
  • access log export

21.3 ログチェック

  • UA別アクセス数
  • IP/ASN別アクセス数
  • robots.txt fetch有無
  • llms.txt fetch有無
  • llms-full.txt fetch有無
  • sitemap fetch有無
  • 404/403/429/5xx
  • 1分あたりリクエスト数
  • 同一IPの連続アクセス
  • 異常なUAローテーション
  • 公式IPレンジ外アクセス
  • rDNS不一致
  • TLS fingerprint不一致

22. 参考：bot別方針早見表

bot/系統 分類 許可候補 拒否候補 観測必須
GPTBot 学習系 △ ◎ ○
OAI-SearchBot 検索・引用系 ◎ △ ○
ChatGPT-User ユーザーfetch △ △ ◎
OAI-AdsBot 広告・検証 △ △ ○
Googlebot 検索系 ◎ △ ○
Google-Extended AI利用制御トークン △ ◎ ○
Google user-triggered fetchers ユーザーfetch △ △ ◎
Applebot 検索系 ◎ △ ○
Applebot-Extended 学習制御 △ ◎ ○
ClaudeBot 学習系 △ ◎ ○
Claude-SearchBot 検索系 ◎ △ ○
Claude-User ユーザーfetch △ △ ◎
Amazonbot 学習/サービス改善 △ △ ○
Amzn-SearchBot 検索系 ◎ △ ○
PerplexityBot 検索・引用系 ◎ △ ◎
Perplexity-User ユーザーfetch △ △ ◎
Meta-ExternalAgent 学習系 △ ◎ ◎
Meta-WebIndexer 検索系 △ △ ○
Meta-ExternalFetcher ユーザーfetch △ △ ◎
facebookexternalhit SNS/OGP ◎ △ ○
CCBot 広域アーカイブ △ △ ○
Bytespider 学習/高負荷crawler △ ◎ ◎
Grok/xAI系 非自己識別/agent疑義 △ △ ◎
ByteBot GUI/Agent △ △ ◎

凡例：
◎ = 強く考慮
○ = 通常考慮
△ = サイト方針次第

23. 参考URL集

ここでは、記事中で使った一次情報・準一次情報・補助情報を整理する。

23.1 OpenAI

23.2 Google

23.3 Apple

23.4 Amazon

23.5 Anthropic / Claude

23.6 Meta

23.7 Perplexity

23.8 xAI / Grok

23.9 ByteDance / Bytespider

23.10 Common Crawl

23.11 Mistral / DeepSeek / Cohere / その他

23.12 防御・検証・ログ分析

23.13 ケーススタディ関連

24. 結論：AIOは意味供給からアクセス統治へ進む

AIOは、AIに読ませる文章を書くことから始まる。

llms.txt を置く。
llms-full.txt を作る。
構造化データを整える。
画像や音声にもメタデータを入れる。
AIが誤読しにくい導線を用意する。

しかし、それだけでは足りない。

なぜなら、AI botは一種類ではないからである。

同じAI企業でも、学習bot、検索bot、ユーザーfetcher、広告bot、agentが分かれている。
Google-Extendedのように、ログ上のUAではなく、内部利用制御トークンとして機能するものもある。
Common Crawlのように、AI企業botではないが、AIデータ供給網の上流に位置するものもある。
PerplexityやGrok系のように、公式仕様だけでは語り切れない観測・疑義領域もある。

したがって、AI時代のWeb公開では、次の問いが必要になる。

どのAI botに、何を、どの目的で、どこまで許すのか。

これがAIO Bot Governanceである。

AIOは、意味供給からアクセス統治へ進む。
llms.txt と robots.txt は別々のファイルではない。
それらは、AIに対して「何を意味として渡すか」と「誰にその意味を読ませるか」を定義する、同一アーキテクチャの別レイヤーである。

最後に、本稿の主張を一文で圧縮する。

追記：TechFeed掲載とはてなブックマーク人気エントリー入りについて

この記事を公開後、ありがたいことに、TechFeed様に取り上げていただきました。

また、はてなブックマークでも一時的に人気エントリーに掲載され、多くの方に読んでいただく機会を得ました。

本稿は、単なるAI bot一覧ではなく、AI botを「学習系」「検索・引用系」「ユーザー起点fetch系」「GUI/Agent実行系」などに分け、Web公開・AIO・アクセス統治をどう設計するかを整理した記事です。

そのため、この記事自体がTechFeedやはてなブックマークを通じて広がったことは、個人的な喜びであると同時に、AI時代のWeb公開において「どこで読まれ、どこで拾われ、どのように再流通するか」を観測する一つの小さな実例にもなりました。

取り上げてくださったTechFeed様、ブックマーク・共有・閲覧してくださった皆さま、ありがとうございます。

引き続き、AIO、AI bot governance、llms.txt、robots.txt、AI時代のWeb設計について、実装と観測を往復しながら整理していきます。

自己紹介

  • 私のリポジトリ

https://github.com/yutapr0117-design/portfolio

  • 私のポートフォリオ

https://yutapr0117-design.github.io/portfolio/

  • 最近作成したDiscord

https://discord.gg/bfr9NRgDNm

Discussion