サーバーログにGPTBotからのリクエストが表示されています。本当に信頼できるのでしょうか？

率直な答えは「いいえ」です。その文字列だけでは信頼できません。ユーザーエージェントヘッダーはクライアントが自分自身について行う主張であり、どんなクライアントでも何でも主張できます。 curl -A "GPTBot" を入力するのにかかる時間は約4秒です。robots.txtポリシー、アナリティクス、またはペイウォールロジックがユーザーエージェント文字列に基づいて分岐する場合、それは未検証の入力に基づいて分岐することになります。

良いニュースは、主要なAIクローラーのほとんどが確認方法を公開していることです。あまり良くないニュースは、意味のある少数派が何も公開しておらず、1つのカテゴリ全体が設計上検証不可能であることです。この記事では、各検証方法の仕組み、どのクローラーがどの方法をサポートしているか、そして正直な答えが依然として「判断できない」場合について説明します。

ユーザーエージェント文字列は主張であり、アイデンティティではない

区別すべき3つのことがあります：

  • 識別 — クローラーが自分は誰かを伝える（ユーザーエージェント文字列）。
  • 検証 — あなたが独立して、運営者が管理する何かと照合してその主張を確認する。
  • 認可 — その検証済みアイデンティティに何を許可するかを決める。

robots.txtはレイヤー3で動作しますが、レイヤー2へのアクセスはありません。これは助言プロトコルです：RFC 9309は構文とコンプライアンスの期待を標準化するものであり、それを強制するメカニズムではありません。Disallowを無視するクローラーは技術的制御を破っているのではなく、リクエストを拒否しているのです。そして、行儀の良いクローラーを装うクローラーは、元々与えられた特権をすべて引き継ぎます。

これは2020年よりも2026年の方が重要です。なぜなら、特権が今や現実のものとなっているからです。サイトはAIクローラーがモデル回答に表現されることを許可したり、従量制で計測したり、ボットチャレンジから免除したりしています。これらすべてが、誰かにコスチュームを着せる理由となります。

3つの検証方法（最も強力なものから順に）

フォワード確認付き逆引きDNS

クラシックな方法であり、これをサポートする運営者にとっては依然として最も堅牢です。リクエストのIPを取得し、ホスト名（PTRレコード）に解決し、ホスト名が運営者が管理するドメインで終わっていることを確認し、そのホスト名を再びIPに解決して元のものと一致することを確認します。

フォワード確認ステップはオプションではありません。PTRレコードはIPブロックのリバースゾーンを管理する者が設定するものなので、フォワードで再度解決せずに信頼するのは、攻撃者制御のレコードを信頼することになります。

逆引きDNSサフィックスを文書化している運営者には、Google（.googlebot.com / .google.com）、Microsoft（.search.msn.com）、Amazon（.crawl.amazonbot.amazon）、Apple（.applebot.apple.com）、Common Crawl（.crawl.commoncrawl.org）が含まれます。

公開IP範囲

運営者がクローラーが使用するCIDRブロックのJSONファイルを公開し、メンバーシップを確認します。OpenAIはこれをopenai.com/gptbot.jsonで公開しており、実際には最も一般的な方法です — レジストリの41クローラーのうち20がIP範囲検証を文書化しており、単一で最も広くサポートされているチェックとなっています。

2つの運用上の注意点があります。リストは変更されるため、ハードコーディングではなくスケジュールで取得してキャッシュすること、そして範囲は運営者自身のインフラストラクチャ衛生状態と同じ程度にしか信頼できない — 共有クラウド範囲は専用範囲よりも証明力が低いということです。

Web Bot Auth署名

将来の方向性であり、ネットワークトポロジーではなく暗号的にアイデンティティを証明する唯一の方法です。ボットはHTTP Message Signaturesを使用して秘密鍵でHTTPリクエストに署名し、検出可能なJWKSディレクトリに公開鍵を公開し、サーバーが署名を検証します。これはIETFで進行中であり、Cloudflare、Akamai、AWSは検証側でサポートを提供しています。

ここで正直な運営者側の現状をお伝えします。これはほとんどの記事が省略する部分です：レジストリの41クローラーの一次ドキュメントを確認したところ、今日検証可能な署名エージェントドメインとJWKS URLを公開しているものは1つも確認できませんでした。 インフラストラクチャは存在しますが、運営者側のロールアウトはサイトオーナーが対応できる形で文書化されていません。Web Bot Authは今四半期にゲートするものではなく、目指すべきものとして扱ってください。

41のクローラーが実際にサポートしているもの

レジストリ全体の検証方法のカウント（1つのクローラーが複数の方法をサポート可能）：

方法 文書化しているクローラー数
公開IP範囲 20
逆引きDNS 11
IP署名 4
ネットワークレベルで方法なし 16

1つのクローラーが複数の方法を文書化できるため、最初の3行は重複します：41のうち25が少なくとも1つのネットワークレベルチェックをサポートし、残りの16はサポートしていません。 これら16については、ユーザーエージェント文字列が運営者が公開する唯一の識別子であり、照合するものは何もありません。許可することも、ブロックすることもできますが、検証することはできません。（16のうちの1つであるGoogle-Extendedにはユーザーエージェント文字列すらありません — 以下参照。）

目的別に同じ41を分類すると：13がユーザー起動型フェッチャー（人間が尋ねた直後にエージェントがページを取得）、10が検索インデックスクローラー、9がトレーニングクローラー、4がエージェント型ブラウザ、3がデータプロバイダー、2が純粋なオプトアウトトークン — Google-ExtendedとApplebot-Extendedはクローラーではなく、すでに取得されたページの使用方法を制御するrobots.txtトークンです。

この区別は、1つのDisallowを書く前に内面化する価値があります。トレーニングクローラーをブロックしても参照トラフィックにコストはかかりません。ユーザー起動型フェッチャーをブロックすると、人間がアシスタントにページについて尋ね、アシスタントがそれを読めなくなることを意味します。

一切検証できないカテゴリ

エージェント型ブラウザは真に異なる問題です。これらはユーザーに代わってAIエージェントが操作する本物のブラウザエンジンです。ネットワークの観点からブラウザそのものであるため、安定したボットトークンを持ちません：本物のChromeユーザーエージェント、本物のTLSフィンガープリント、本物のJavaScript実行。

レジストリは4つを追跡しており、そのリストの変更自体が示唆的です：ChatGPT Atlas（OpenAI）とComet（Perplexity）が現在のもので、OpenAIのOperatorとGoogleのProject Marinerはすでに非推奨として記録されています — 18ヶ月以内に置き換えられました。ここで構築するものは何であれ、置き換えられることを前提に構築してください。

一致させるユーザーエージェント文字列も、公開IP範囲も、逆引きDNSサフィックスもありません。残るのは行動シグナルだけであり、ヘッドレスだが本物のブラウザにおける行動シグナルは弱いものです。

これが現在のツールセットの正直な限界であり、Web Bot Authが重要な理由です：これはエージェント型ブラウザが推論を要求するのではなく、検証可能なアイデンティティを自主的に提供できる唯一の提案だからです。

チェックの実装

フォワード確認付き逆引きDNS、依存関係なしのNodeでの実装：

import { promises as dns } from "node:dns";

// Suffixes an operator has published for its crawler. Never infer these —
// use the domain the operator documents, or you will validate an impostor.
const SUFFIXES = {
  googlebot: [".googlebot.com", ".google.com"],
  bingbot:   [".search.msn.com"],
  applebot:  [".applebot.apple.com"],
  amazonbot: [".crawl.amazonbot.amazon"],
  ccbot:     [".crawl.commoncrawl.org"],
};

export async function verifyByReverseDns(ip, operator) {
  const suffixes = SUFFIXES[operator];
  if (!suffixes) return { verified: false, reason: "no published suffix" };

  let hostnames;
  try {
    hostnames = await dns.reverse(ip);            // PTR lookup
  } catch {
    return { verified: false, reason: "no PTR record" };
  }

  const host = hostnames.find((h) => suffixes.some((s) => h.endsWith(s)));
  if (!host) return { verified: false, reason: "PTR outside published domain" };

  // Forward-confirm: the PTR record alone is controlled by whoever owns the
  // reverse zone, so resolve the hostname back and require the IP to match.
  const forward = await dns.resolve(host).catch(() => []);
  return forward.includes(ip)
    ? { verified: true, host }
    : { verified: false, reason: "forward lookup did not match" };
}

Enter fullscreen mode Exit fullscreen mode

本番環境で正しく行うべき2つのこと。アウトオブバンドで行ってください — リクエストパス内でのDNSラウンドトリップはレイテンシとサービス拒否の責任となるため、非同期で検証し、IPごとに判定をキャッシュしてください。そしてポリシー上はフェイルクローズし、リクエスト上ではフェイルしないこと：未検証のリクエストは必ずしも敵対的ではなく、単に証明されていないだけなので、403を返すのではなく特権をダウングレードしてください。

「不明」が自信ある推測よりも良い答えである理由

公開されているAIクローラーリストのほとんどは、すべてのボットにrobots.txtコンプライアンスについて明確なはい/いいえを与えています。このデータをコンパイルしたところ、その明確さが最も擁護しがたい部分であることが判明しました。

かなりの数のクローラーについて、運営者はその正確な名前でエージェントに関する明示的な声明を単に公開したことがありません。利用可能な選択肢は、兄弟ボットから推論するか、別のリストが主張することをコピーするか、「不明」と記録して運営者が実際に言っていることを引用することです。3つ目の選択肢だけが、確認する人と接触しても生き残ります。

したがって、この記事の背後にあるレジストリは、はい、いいえ、不明の3値状態を保持しており、各個別の主張に一次ソースURLとlast_verified日付が添付され、もっともらしい推測ではなくソースを取得できなかった場合には明示的なnullが付いています。あまりきれいではありません。しかし、運営者が静かにドキュメントを変更したときに真実であり続ける唯一のバージョンです。

クローラーごとのデータ — ユーザーエージェントトークン、robots.txtトークン、検証方法、公開IP範囲URL、オプトアウトメカニズム、およびすべてのフィールドの背後にあるソースURL — をご希望の場合は、agentswelcome.dev/crawlersにあり、読むよりも差分を取ることを好む場合は/api/crawlersにJSONエンドポイントがあります。

FAQ

robots.txtでAIクローラーをブロックすると本当に止まるのでしょうか？
技術的には止まりません。robots.txtは助言的です：RFC 9309は構文と期待を定義するものであり、強制メカニズムではありません。OpenAI、Anthropic、Perplexityはそれぞれ、クローラーがこれを尊重すると述べるドキュメントを公開しており、主要な運営者がそうしているという証拠があります。強制が必要な場合は、エッジでのWAFルールまたは検証済みボットポリシーであり、テキストファイルではありません。

Google-Extendedはブロックすべきクローラーですか？
Google-Extendedはクローラーではなく、ユーザーエージェント文字列もありません。これは、Googleがすでに取得したコンテンツをGeminiのトレーニングに使用できるかどうかを制御するrobots.txtトークンです。これを拒否してもクロールトラフィックは減少しませんし、Searchインデックスにも影響しません。Applebot-ExtendedもAppleについて同じように機能します。

トレーニングクローラーはブロックし、検索クローラーは許可すべきですか？
これが一般的なポリシーであり、理由は成り立ちます：トレーニングクローラーは参照パスなしでコンテンツを消費しますが、検索インデックスまたはユーザー起動型フェッチャーは、人間が今読んでいる回答であなたを表示することができます。会社ごとではなくボットタイプごとに決定してください — いくつかの運営者は異なるトークンの下で両方の種類を実行しています。

このデータはどのくらいの頻度で変更されますか？
重要であるほど頻繁に変更されます。運営者は発表なしにトークンを追加し、エージェントの名前を変更し、IP範囲を更新します。主張ごとのソースURLと検証日付のないクローラーリストは、誰かの午後のスナップショットであり、このリストも含まれます — これが上記の数字がチェックされた日付（2026-07-30）を持つ理由です。

AGENTS WELCOME crawler registryのデータ — 41のクローラー、各フィールドが独自の一次ソースと検証日付を持ちます。2026-07-30にチェック済み。