AIクローラー

AIクローラーとは、生成AI各社がWebページを自動取得するボット（巡回プログラム）の総称です。目的で「学習・収集系」（モデル訓練用に大量収集）と「回答・検索系」（ユーザーの質問に答えるためその場で取得）に大別され、加えて人の操作を起点に取りに来る「user-triggered fetcher」があります。AIに読まれ・引用されるための対策（AIO）の対象は、まずこのAIクローラーです。

AIクローラーとは（正確な定義）

AIクローラーは、生成AIを運営する事業者が自動でWebページを取得するために走らせるボットです。ボット（bot）はロボットの略で、人間が操作しなくても定められた動作を繰り返すプログラムを指します。AIクローラーは、リンクをたどって（あるいは対象URLを直接指定して）HTMLをダウンロードし、その中身をAIの学習素材や回答の材料として使います。運営元・目的・robots.txt（＝クローラーへの取得許可を書くファイル）での制御方法が、ボットごとに公式ドキュメントで公開されています。

「AIクローラー」という単一の公式な定義があるわけではなく、実務では、生成AIの提供に関わって自動でWebを取得するボット群をまとめてこう呼びます。従来の検索エンジンのクローラー（Googlebot等）と、技術的な巡回の仕組みは共通です。違いは取得後の使い道にあり、検索インデックスではなくAIモデルの訓練やAIの回答生成のためにページが使われる点が本質です。近年は各社が自社ボットの名前・目的・制御方法を公式ページで明示するようになり、サイト運営者がボット単位で許可・拒否を判断できる環境が整ってきています。

なぜ重要か（AI検索での位置づけ）

AI検索で自社が引用・参照されるには、その前提として自社ページがAIクローラーに取得されている必要があります。読まれていないページは、AIの回答に登場しようがありません。したがって「どのAIクローラーを歓迎し、どれを拒否するか」「歓迎するボットにちゃんと読まれているか」を設計・観測することが、AIO（AI最適化）の土台になります。とりわけ、学習に使われるのは嫌だが検索結果には出したい、といった細やかな出し分けが実務では重要で、そのためにはボットの種別を正確に理解しておく必要があります。

AIクローラーの存在感は、AI検索の利用が広がるほど増しています。ユーザーがGoogleで検索する代わりにChatGPTやPerplexityに質問して答えを得る場面が増えると、その答えの材料としてWebを取得するAIクローラーの巡回が、自社の露出を左右する新しい入口になります。従来のSEOがGooglebotに読まれ検索結果で上位に出ることを狙ったように、AI検索対策（AIO）はAIクローラーに読まれAIの回答に引用されることを狙います。だからこそ、まず相手であるAIクローラーの正体と種別を正確に知ることが、対策の前提になるのです。

ここで押さえたいのは、AIクローラーへの態度が「コンテンツを守る」観点と「露出を得る」観点でしばしば衝突することです。学習に使われたくないという著作権・資産保護の動機からはボットを拒否したくなりますが、AI検索の結果に出て新しい流入を得たいという集客の動機からは歓迎したくなります。この相反する要求を、ボットの種別ごとに別々に扱えるからこそ、両立が可能になります。だからこそ「学習系」と「検索系」を混同せず、それぞれ独立に判断する姿勢が、AI検索対策の実務では欠かせません。

もう一点、AIクローラーを語るうえで欠かせないのが「観測なくして対策なし」という原則です。自社にどのAIボットが来ているかを知らないまま、robots.txtで闇雲に許可・拒否を書いても、それが効いているのか、そもそも狙ったボットが来ているのかが分かりません。サーバーログでAIボットの訪問を観測し、その実態に基づいて方針を決め、変更後に再び観測して効果を確かめる——この観測を軸にした循環こそが、AIクローラー対策を推測ではなく事実で回すための骨格です。用語としてのAIクローラーを理解することは、この循環の第一歩にあたります。

仕組み／3つの種別

AIクローラーは、目的と起動のされ方で次の3種類に整理できます。この分類が、robots.txtでの制御可否や、取得されたページの使い道を決めます。

• 学習・収集系: モデルの訓練や大規模な索引作成のために、サイトを自動で大量に巡回して集めます。代表はGPTBot（OpenAIの学習用）、ClaudeBot（Anthropicの収集用）、Bytespider（ByteDanceの収集用）。robots.txtでの拒否に対応する
• 回答・検索系: ユーザーの質問に答えるための検索索引を作る目的で巡回します。代表はOAI-SearchBot（ChatGPT検索用）、PerplexityBot（Perplexity検索用）。これも robots.txtで制御できます。拒否すると各AI検索の結果に載りにくくなる
• user-triggered fetcher（ユーザー起動型フェッチャー）: 人がAIに質問したその瞬間に、答えるためにページを取りに来ます。代表はChatGPT-User、Perplexity-User。自動巡回ではなく人の操作が起点である点が根本的に異なる

この3種別の区別は、自社の目的に応じた打ち手を選ぶための地図になります。「学習に使われたくない」が主目的なら学習・収集系（GPTBot等）への対応を最優先に考え、「AI検索での露出を増やしたい」が主目的なら回答・検索系（OAI-SearchBot、PerplexityBot等）を確実に許可して読ませることを考えます。そしてuser-triggered fetcherは、robots.txtだけでは完全に制御できない前提で、必要なら別の遮断手段を検討します。種別を曖昧にしたまま「AIボットを一括で許可／拒否」と大雑把に扱うと、露出したいのに止めてしまう、あるいは守りたいのに漏れる、という取り違えが起きます。まず相手を種別で分けてから方針を決める、という順序が実務の要点です。

具体例・代表的なAIクローラー一覧

主要なAIクローラーを、運営元・種別・User-Agent（自己申告名）の例とともに整理します。User-Agent文字列は版数（バージョン番号）を含み、各社の更新で変わりうるため、最新は各社の公式ドキュメントで確認してください。

各ボットの目的は、運営元の公式説明を読むと明確に整理されています。要点を並べると次のようになります。この違いを踏まえると、どのボットを歓迎し、どれを断るかの判断がしやすくなります。

• GPTBot（OpenAI）: 主に生成AI基盤モデルの訓練向けにコンテンツを収集します。robots.txtでの拒否に対応。学習利用を避けたいならここをDisallowする
• OAI-SearchBot（OpenAI）: ChatGPTの検索機能で結果に載せるための索引用。拒否すると検索の回答に出にくくなります。露出したいなら許可する
• ChatGPT-User（OpenAI）: ユーザーがChatGPT内で操作した瞬間に、答えるためページを取りに来るフェッチャー。人の操作が起点
• ClaudeBot（Anthropic）: Claude向けにWebコンテンツを収集するクローラー。robots.txtでの制御に対応
• PerplexityBot（Perplexity）: Perplexity検索の索引用。AI基盤モデルの訓練には使わないと明言されている
• Perplexity-User（Perplexity）: ユーザーの質問に答えるためその場でページを訪れるフェッチャー。訓練用の収集ではない

なお同じOpenAIでも、GPTBot（学習）とOAI-SearchBot（検索）は用途が独立しています。OpenAIの公式説明でも、GPTBotを拒否しつつOAI-SearchBotを許可すれば「学習には使わせないが検索結果には出す」という出し分けが可能とされています。この独立性を使い分けるのがAIO実務の勘所です。同様にPerplexityも、検索索引用のPerplexityBotと、ユーザーの質問に答えるためその場で取りに来るPerplexity-Userを分けて説明しており、いずれも「AIモデルの訓練には使わない」と明言しています。各社が自社ボットの目的を細かく公開しているのは、サイト運営者が納得して許可・拒否を選べるようにするためです。

Googleの扱いはやや特殊です。GoogleはGoogle-Extendedという制御用の識別名を用意していますが、これは独立したボットではなく、既存のGoogleのクローラーが取得した内容をGemini（ジェミニ）等の学習に使ってよいかだけを制御するためのトークン（＝robots.txtに書く識別名）です。つまり通常の検索クロール（Googlebot）はそのまま許可しつつ、学習利用の可否だけをGoogle-Extendedで切り分けられます。AIクローラーを考えるときは、こうした「HTTPリクエストとして現れるボット」と「robots.txtの制御専用トークン」の違いも意識しておくと、設定を誤りにくくなります。

一覧に載っていないボットに出会うことも珍しくありません。AIの事業者は次々に増えており、それぞれが独自のボットを走らせているためです。見慣れないボット名に出会ったら、まずそのUA文字列に含まれる+URL（説明ページへのリンク）をたどって運営元と目的を確認し、DarkVisitorsのような既知ボットの一覧サイトも参照します。目的が学習系か検索系か、自社の露出戦略に合うかを見極めてから、許可・拒否を判断します。名前を見た瞬間に反射的にブロックするのではなく、正体を確かめてから扱う姿勢が、機会損失も過剰な負荷も避ける近道です。

よくある誤解・注意点

• 「クロールされた」と「AIの回答に引用された」は別物。取得＝引用ではない
• 学習系を拒否しても検索系まで自動的に拒否されるわけではありません。ボットごとに設定が独立している
• user-triggered fetcher は robots.txt に従わないことがあるため、robots.txtだけで完全に止められるとは限らない
• UA名は各社の更新で変わります。ブロック・許可の設定は最新の公式ドキュメントを基に見直す

AIエージェントとの関係

近年は、単にページを取得するだけでなく、ユーザーの代わりにWeb上で複数の操作を連続して行う「AIエージェント」（＝目的を与えると自律的に手順を踏んで作業するAI）も登場しています。これらがWebにアクセスするときも、その実体はページを取得するボットであり、広い意味ではAIクローラーと地続きです。DarkVisitorsのような一覧サイトが、クローラーだけでなくAIアシスタントやAIエージェントまで含めてボットを分類しているのは、この境界が溶けつつあるためです。サイト運営者から見れば、「自動巡回する学習系」「質問に答える検索系」「人の操作を代行するフェッチャー」「自律的に作業するエージェント」が、いずれもUser-Agentを名乗ってアクセスしてくる、という一段広い視野が必要になってきています。

ただし本質は変わりません。相手が何であれ、まずUser-Agentで正体を見分け、公式情報で目的を確かめ、自社の露出戦略に照らして許可・拒否を決め、サーバーログで結果を観測する——この基本サイクルは、エージェント時代でも有効です。新種のボットが現れるたびに慌てるのではなく、種別と目的で整理して扱うという型を持っておくことが、変化の速いこの領域で振り回されないための備えになります。

実務での扱い方（企業・サイト運営者向け）

1. 方針を決める: 学習に使われてよいか／AI検索の結果に出したいかを、ボット種別ごとに整理する
2. robots.txtで出し分ける: 検索系（OAI-SearchBot、PerplexityBot）は許可、学習系（GPTBot等）は方針に応じて許可/拒否を書く
3. サーバーログで観測する: 許可したボットが実際に取得できているか、拒否したボットが本当に止まっているかを確認する
4. 本物か検証する: 重要な判断の前に、公式IPレンジJSONとログの接続元IPを照合し、詐称を排除する
5. 定期的に見直す: UA名・公式方針は変わるため、四半期ごとなど周期を決めて設定を点検する