robots.txtでAIクローラーを制御する方法 GPTBot等の学習・検索を分けて考える

自社サイトの情報をAIに学習されるのは避けたいが、ChatGPTの検索結果には表示させて集客につなげたい——そう考えたことはないだろうか。実は、この2つは両立できる。鍵になるのが、robots.txtによるAIクローラーの用途別の制御である。

この記事では、AIクローラーの種類と役割の違い、robots.txtでの具体的な設定方法、そして「学習用ボットをブロックすると検索結果からも消える」というよくある誤解について、一次情報をもとに解説する。

AIクローラーには3つの種類がある

一口に「AIのクローラー」と言っても、その目的は大きく3つに分かれている。この違いを理解しないまま設定すると、意図しない形でチャンスを失うことになりかねない。

学習用クローラーが集めたデータは、AIモデルの長期的な知識として組み込まれる。一方、検索用クローラーは、ユーザーが質問するたびにその場で情報を取りに行き、回答の根拠として提示する役割を担う。この2つは技術的に別のシステムで動いており、片方をブロックしてももう片方には影響しない。

「GPTBotをブロックすると引用が消える」は誤解

AIクローラーの制御に関して、最も多い誤解が「学習用のGPTBotをブロックすると、ChatGPTの回答で自社が紹介されなくなる」というものである。しかし、OpenAIの公開情報によれば、GPTBot(学習用)とOAI-SearchBot(検索用)は独立して動作しており、robots.txtでの設定もそれぞれ別に扱われる。

GPTBotをブロックした場合に失われるのは、将来のAIモデルの基礎知識に自社の情報が組み込まれる機会であって、現在のChatGPTユーザーが検索した際に自社サイトが情報源として提示されるかどうかは、検索用のOAI-SearchBotへのアクセス許可に左右される。つまり、学習は拒否しつつ検索での露出は残す、という設定が技術的に可能である。

目的別のrobots.txt設定パターン

中小企業にとって現実的な選択肢は、次の4つのパターンに整理できる。

多くの中小企業にとって現実的なのは、ハイブリッド型である。robots.txtに、学習用クローラーへのDisallow(拒否)と、検索用クローラーへのAllow(許可)を、それぞれ個別に記述する。

User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /

Google・Appleは専用のトークンで学習可否を制御する

OpenAIやAnthropicが独立したクローラー名で学習と検索を分けているのに対し、Googleの学習データ制御は少し異なる仕組みになっている。Googleは、既存のGooglebot自体を別のクローラーに分けるのではなく、robots.txt内の専用のトークンによって、収集済みのデータを将来のAIモデルの学習に使ってよいかどうかを切り分けている。Appleも同様の仕組みを採用しており、これをブロックしても通常の検索や音声アシスタントでのクロールには影響しない。

# Googleの将来モデルの学習を拒否(通常のGoogle検索には影響なし)
User-agent: Google-Extended
Disallow: /

# Appleの生成AIモデルの学習を拒否(通常のクロールには影響なし)
User-agent: Applebot-Extended
Disallow: /

これらのトークンをブロックしても、通常の検索結果への表示や、既存のクロールの仕組みには影響しない。「学習データとしての二次利用だけを止める」というピンポイントな制御ができる点が特徴である。

robots.txtだけでは守りきれないという限界

robots.txtは、あくまでクローラーに対する「お願い」に過ぎず、法的な強制力を持たない。ルールを守るかどうかは、クローラーを運営する側のプログラム次第である。正規のAI企業は基本的にルールを守るが、この仕組みを悪用しようとする動きも報告されている。

セキュリティ企業の調査によれば、正規のAIクローラーになりすまして、robots.txtを一切確認せずに、サーバーの設定ファイルや認証情報が入ったファイルへ直接アクセスを試みる、不正なアクセスが観測されている。こうした偽装アクセスは、ユーザーエージェント名(アクセス元の名乗り)を書き換えれば簡単に成立してしまうため、名前だけで許可・拒否を判断する設定には限界がある。robots.txtの設定に加えて、サーバーのアクセスログを定期的に確認する習慣も持っておきたい。

また、行儀の良いAIクローラーであっても、頻繁にアクセスを繰り返すことでサーバーの負荷を高めてしまうケースが指摘されている。中小企業のサーバーが、AI企業のクローラーによる大量アクセスで一時的に重くなるという事例も報告されており、アクセス頻度が明らかに異常な場合は、CDN(コンテンツ配信サービス)やWAF(不正アクセス対策)の仕組みを使って、ネットワークの入り口側で制御することも選択肢に入る。

今後の動き:なりすましを防ぐ新しい仕組み

こうしたなりすましの問題を解決するため、業界団体を中心に、クローラーの身元を暗号技術で証明する新しい仕組みの標準化が進められている。将来的には、名乗りだけでなく、暗号的な裏付けをもとにアクセス元を判断する方式へと移行していくことが見込まれている。中小企業が今すぐこの仕組みに対応する必要はないが、AIクローラーの制御が「名乗りベース」から「証明ベース」へと変わりつつあるという流れは、頭の片隅に置いておきたい。

設定後に確認しておきたいこと

robots.txtのAI対応についてよくある質問

学習用クローラーをブロックするとSEOに悪影響はありますか

通常の検索エンジン(Googlebot等)とAIの学習用クローラーは別物であり、学習用クローラーの制御が通常のGoogle検索の順位に影響することはない。

ChatGPTのユーザーが直接URLを開いた場合もrobots.txtで制御できますか

利用者が個別にURLを指定して要約を求めるような、その場限りのアクセスについては、通常の自動巡回を前提としたrobots.txtのルールが適用されない場合があるとされている。この点は完全な制御を保証するものではないと理解しておきたい。

中小企業はどのパターンを選ぶべきですか

明確な機密情報や有料限定コンテンツを持たない一般的な事業者であれば、学習は拒否しつつ検索での表示は残すハイブリッド型が、独自性の保護と認知度向上のバランスが取りやすい。

まとめ:一律の判断ではなく用途で分けて考える

AIクローラーへの対応は、「AIを全部拒否する」か「全部許可する」かの二択ではない。学習用・検索用・ユーザー起点型という用途の違いを理解したうえで、自社のコンテンツの性質に応じて個別に判断することが、知的財産の保護とAI検索での露出という、一見相反する2つの目的を両立させる鍵になる。robots.txtはあくまで紳士協定であり万能の盾ではないことも踏まえ、設定後のログ確認まで含めて運用したい。

今日できる点検

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。