GPTBot・ClaudeBot を許可すべきか、拒否すべきか

AI クローラーには、どんな種類がありますか？

大きく 3 種類です。モデルの学習データを集める学習用、AI 検索の索引を作る検索用、ユーザーが URL を貼った瞬間に取りに行くユーザー操作用。robots.txt では別々のトークンなので、個別に許可・拒否を決められます。

「AI に読ませたくない」と「AI に引用されたくない」は、まったく別の話です。この区別ができていないと、学習を拒否したつもりで、AI 検索の引用元からも消えるという結果になります。実際によく起きています。

実際にはクロールしない「意思表示だけ」のトークン

Google-Extended と Applebot-Extended は特殊で、この名前のクローラーは存在しません。 ページを取得しに来るのは Googlebot と Applebot であり、Extended の方は「すでに取得したコンテンツを AI の学習に使ってよいか」を伝えるためだけの制御用トークンです。

仕組みを分けている理由は明快です。検索インデックスと AI の学習は用途が別なのに、クロールが 1 本しかないと、片方を拒否するにはもう片方も諦めるしかなくなります。トークンを分けることで、検索には載せたいが学習には使わせないという意思表示が可能になります。したがって Google-Extended を拒否しても、Google 検索の順位には影響しません。

どのクローラーを見ておけばいいですか？

実務では下の 21 トークンで十分です。OpenAI・Anthropic・Google・Perplexity・Common Crawl の 5 系統を押さえれば大半をカバーできます。本ツールもこの一覧を robots.txt に照らして 1 件ずつ判定しています。

許可すべきですか、拒否すべきですか？

コンテンツ自体が商品なら学習用を拒否、集客が目的なら全許可、が基本線です。判断軸は「AI に読まれることで、自分のビジネスの何が減るか」の一点です。減るものが無いなら、拒否は流入を捨てるだけの選択になります。

迷ったときは、拒否によって守られるものを具体的に言えるかどうかで判断してください。「なんとなく AI に使われるのは嫌だ」で全拒否にすると、AI 検索からの流入という実利だけを確実に失います。

robots.txt はどう書きますか？

クローラーごとに User-agent のグループを作り、その中に Disallow または Allow を書きます。全面的に許可するなら、 そもそも何も書かないのが最も安全です。robots.txt に書かれていないクローラーは、既定で許可されます。

すべて許可する（多くのサイトはこれで十分）

User-agent: *
Allow: /

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

学習は拒否し、AI 検索には載せたい（メディア向け）

# ── 学習用クロールは拒否する ─────────────────
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: meta-externalagent
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: cohere-ai
Disallow: /

# 実際には来ない。学習に使わないでほしいという意思表示のトークン。
# Google 検索・Apple 検索の順位には影響しない
User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

# ── AI 検索のインデックスは許可する（引用元として載りたい） ──
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# ── ユーザーが自分で開いたときの取得は許可する ──────────
User-agent: ChatGPT-User
Allow: /

User-agent: Claude-Web
Allow: /

User-agent: Perplexity-User
Allow: /

# ── それ以外すべて ────────────────────────────
User-agent: *
Disallow: /admin/
Disallow: /cart/

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

なぜ User-agent: * の設定が GPTBot に効かないのですか？

RFC 9309 では、クローラーは自分に最も具体的に一致するグループを 1 つだけ選び、他のグループは完全に無視すると定められているためです。GPTBot のグループがあれば、GPTBot は User-agent: * の中身を一切読みません。

この仕様は極めて誤解が多く、しかも実害が大きい部分です。次の robots.txt を見てください。

User-agent: *
Disallow: /admin/
Disallow: /cart/

User-agent: GPTBot
Disallow: /private/

書いた人はおそらく「GPTBot には /admin/・/cart/ に加えて /private/ も禁止」のつもりです。しかし実際には、GPTBot は自分専用のグループを見つけた時点でそちらだけを採用し、User-agent: * の内容は読みません。結果、GPTBot は /admin/ も /cart/ も自由にクロールできます。

ルールは継承されません。特定のクローラー向けにグループを作るなら、共通のルールも書き写す必要があります。

User-agent: *
Disallow: /admin/
Disallow: /cart/

User-agent: GPTBot
Disallow: /admin/
Disallow: /cart/
Disallow: /private/

あわせて知っておくべき挙動

• User-agent 名は大文字小文字を区別しません。gptbot と GPTBot は同じものとして扱われます
• パスは大文字小文字を区別します。Disallow: /Admin/ は /admin/ を止めません
• 同じ User-agent のグループが複数あればマージされます。ただし読み手が混乱するので 1 か所にまとめるべきです
• 該当するルールが無ければ許可です。Allow: / は明示のためのものであり、無くても許可されます
• Allow と Disallow が競合したら、パスが長い（＝より具体的な）方が勝ちます。同じ長さなら Allow が優先されます

robots.txt を無視するクローラーはどうしますか？

robots.txt に強制力はありません。「玄関の貼り紙」であって鍵ではないので、無視するクローラーは止まりません。本当に止めたいなら、認証をかけるか、 サーバー側や CDN 側で User-Agent・IP による遮断を行う必要があります。

robots.txt は RFC 9309 で標準化されていますが、規定しているのは書式と解釈方法であって、遵守を強制する仕組みではありません。 主要な事業者は尊重を表明していますが、それは各社の方針であって技術的な保証ではありません。実際、robots.txt を無視しているという報告が繰り返し上がっているクローラーも存在します。

技術的に止める手段は、robots.txt の外にあります。

1. 認証をかける — 最も確実です。ログインが必要なコンテンツは、そもそも robots.txt の管轄外です
2. CDN・WAF で遮断する — 主要な CDN は AI クローラーのブロック機能を持っています。User-Agent だけの判定は詐称に弱いので、公開されている IP レンジや逆引き検証と組み合わせます
3. レート制限をかける — 全面遮断より穏当で、負荷対策としても機能します

よくある事故は何ですか？

最も多いのは、ステージング用の User-agent: * / Disallow: / が本番に紛れ込むことです。これは AI どころか Google 検索からも消えます。次に多いのが、学習を拒否したつもりで AI 検索用のトークンまで拒否してしまう取り違えです。

1. 全面拒否の置き土産 — ステージングの Disallow: / がそのまま本番へ。数か月気づかれないこともあります
2. 学習と検索の取り違え — OAI-SearchBot や PerplexityBot まで拒否し、引用元から消えて流入を失う
3. Google-Extended の誤解 — Google 検索に影響すると思い込んで許可し続ける／逆に Googlebot ごと拒否する
4. グループの継承ミス — 前節のとおり、特定クローラー用グループを作ったせいで共通ルールが外れる
5. robots.txt が HTML を返している — SPA の catch-all が 200 でアプリのシェルを返し、robots.txt として解釈不能になる。「書いたのに効かない」の典型です
6. そもそも本文が読めない — 許可していても、JavaScript なしで本文が読めないなら、クローラーが得るものはありません

robots.txt を書き換えたら、必ず実物を curl で確認してください。ブラウザで開くとキャッシュや CDN の影響が混ざります。

# 中身と content-type を同時に確認する。
# content-type が text/html なら、それは robots.txt として機能していない
curl -sIL https://example.com/robots.txt | grep -i "^content-type\|^HTTP"
curl -sL  https://example.com/robots.txt

サイト診断では、この 21 トークンそれぞれについて robots.txt を RFC 9309 に沿って解釈し、許可・拒否を 1 件ずつ判定します。文字列の部分一致で判定すると、グループの取り違えや Allow による例外指定を読み違えるためです。