0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

新人プログラマ応援 - みんなで新人を育てよう！
@yuta_yokoi_ai

AIクローラーを一括りにするな：robots.txt設計で学習・検索・ユーザーfetchを分ける

0
Posted at

この記事は、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に、何を、どの目的で、どこまで許すかを設計することです。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?