IP インテリジェンスIPでAIクローラーとエージェントを検証する方法：逆引きDNS、CIDRレンジ、Web Bot Auth
IPでAIクローラーを検証する方法を解説します。前方確認付き逆引きDNS、公開CIDRレンジ、Web Bot Auth（RFC 9421）を使って、GPTBot、Googlebot、AIエージェントを見分けます。
ログにGPTBot、ClaudeBot、PerplexityBotが現れたとき、許可するか、レート制限するか、ブロックするかを判断しなければなりません。しかしその前に、もっと基本的な問いに答える必要があります。それは本当にそのbotなのか？ User-Agentヘッダーは主張であって、証明ではないからです。誰でもcurl -A "GPTBot/1.3" https://your-site.comを実行でき、ログには律儀に「GPTBot」と記録されます。
これは理論上の話ではありません。HUMAN SecurityのSatoriチームは、有名なAIクローラーを名乗るトラフィック全体の5.7%がなりすましであり、日によっては7.7%（1日約200万リクエスト）に達し、ChatGPT-Userエージェントは約6件に1件が偽装されていたことを確認しました。このガイドでは、IP層と暗号層でクローラーを検証する3つの確かな方法（前方確認付き逆引きDNS、運営者が公開するCIDR許可リスト、Web Bot Auth）に加え、他のほぼすべてのガイドがつまずく失敗パターンを扱います。
User-Agentが「GPTBot」でも何も証明されない理由
User-Agentは自己申告のメタデータです。認証はなく、署名もなく、オリジンサーバーが確認できるものは何もありません。クローラーを検証するとは、リクエストを、運営者が実際に管理しているインフラまたは鍵に結びつけることです。それを実現する方式は、ちょうど3つです。
- 前方確認付き逆引きDNS（FCrDNS）: IPが運営者のドメインへ、そしてドメインからIPへと解決されることを証明します。
- 公開CIDR許可リスト: IPを、運営者が公開するレンジと照合します。
- Web Bot Auth（RFC 9421）: リクエスト自体に付けられた暗号署名を検証します。
以下はすべて、これらを正しく行うことと、それぞれが何を証明でき、何を証明できないかについての説明です。
2026年の状況：botがWebの過半数を占める
自動化されたトラフィックがインターネットの大半を占めるようになった時点で、クローラーの検証はSEOのニッチな話題ではなくなりました。Impervaの2026年版Bad Bot Reportによると、自動化されたトラフィックは2025年に観測したWebトラフィックの53%を占め、悪質botだけで40%を占めました。ほとんどのリクエストが自動化されており、AIクローラーの量も増え続ける中で、「このbotは本物か？」という問いは、robots.txtだけでなく、ログイン、サインアップ、チェックアウトのエンドポイントでも問われます。チェックアウトでは不正の問題でもあります。実在のエージェントによる販売をブロックせずにAIショッピングエージェントの不正を防ぐ方法をご覧ください。クローラーのレンジからスキャナーのフラグまで、どのIPシグナルがどのbotの問いに答えるかについては、IPによるbot検出のハブをご覧ください。
方法1：前方確認付き逆引きDNSを正しく行う
FCrDNSは、GoogleがGooglebotの検証方法として文書化している標準的な方法です。手順は4つです。
# 1. Reverse-DNS the source IP → hostname
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com
# 2. Confirm the suffix matches the operator
# Googlebot: googlebot.com, google.com, or googleusercontent.com
# Bingbot: *.search.msn.com
# 3. Forward-DNS that hostname → IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1
# 4. Confirm it matches the original IP. Match = verified.
順引きの段階が不可欠な理由: 攻撃者は自分のIPの逆引き（PTR）レコードを管理できるため、1.2.3.4をcrawl-fake.googlebot.comに向けることができます。しかし、そのホスト名が1.2.3.4に解決されるように、googlebot.comの権威DNSによる順引きを偽造することはできません。PTRレコードが「googlebot.com」を含むかどうかを文字列で照合するだけのチェック（驚くほど多くのチュートリアルがこれを勧めています）は、それ自体がなりすまし可能です。順引きによる確認こそが要点です。Googleについては、3種類のクローラーとそれぞれ別のレンジファイルがあるため、IPでGooglebotを検証し、偽のGooglebotを見抜くのガイドをご覧ください。
精度の上限として押さえておくべき点があります。PTRレコードは任意であり、特に新しいAIベンダーでは存在しないことが多くあります。PTRがない場合、FCrDNSは「検証不能」を返し、これは合格でも不合格でもありません。 そこで方法2の出番です。
方法2：botごとの公開CIDR許可リスト
多くのAIベンダーはPTRレコードを用意せず、代わりにクローラーのIPレンジをJSONで公開しています。これは運用上、最も実用的なチェックです。各運営者の一次情報のフィードを取得してください。
- OpenAI: botごとのファイル：
openai.com/gptbot.json、openai.com/searchbot.json、openai.com/chatgpt-user.json（OpenAIのクローラーのドキュメント）。 - Google:
developers.google.com/static/crawling/ipranges/配下に5つのCIDRファイル。 - Anthropic: 自社のbot用に1つのファイル
claude.com/crawling/bots.jsonを公開しており、クローラーのヘルプページからリンクされています。プラットフォームのドキュメントにあるアドレスの一覧はAPI用であり、クローラー用ではありません。 - Perplexity:
perplexitybot.jsonとperplexity-user.json。 - Apple iCloud プライベートリレー:
mask-api.icloud.com/egress-ip-ranges.csvにある出口のCSV（Appleのドキュメント）。注意：これらはプライバシーリレーを使う人間であり、botではありません。許可リストに入れてください。ブロックしてはいけません。
当社は、10の運営者から19のクローラーレンジファイルを読み込んでいます。検証済みクローラーのIPリストには、それぞれのファイルと日付、そして許可リストの作り方を掲載しています。
正しい実装と壊れた実装を分ける3つのルールがあります。
- 各botを運営者のファイルに対応させ、運営者がbotごとにファイルを公開している場合は、そのbot自身のファイルに限定します。
GPTBotは「OpenAIのどこかのレンジ」ではなくgptbot.jsonにあり、OpenAIの別のファイルと照合すると、学習用クローラーとユーザー起点のフェッチャーが混同されます。Anthropicは3つのbotに共通の1つのファイルを公開しており、DuckDuckGoの2つのファイルは同一なので、その場合は運営者単位が最も正確な照合です。GPTBot、OAI-SearchBot、ChatGPT-Userの比較では、OpenAIの各botの役割、ブロックした場合のコスト、各ファイルからの実際のルックアップを紹介しています。 - ホスティングのASNではなく、公開されている正確なプレフィックスと照合します。 botがたまたま動いているからといって「AWS全体」や「Google Cloud全体」を許可リストに入れると、同じクラウド上にいるすべての攻撃者を通してしまいます。
- 定期的に更新します。 これらのレンジは変わります。定数ではなく、フィードとして扱ってください。
ベンダーごとの非対称性：そもそもどの方法が存在するか
多くのガイドは、ベンダーをひとまとめにしてしまいます。実際には、どの検証方法が存在するかも、各社が提供するクローラーのトークンも異なり、それぞれにポリシー上の意味合いの違いがあります。
| 運営者 | FCrDNS | 公開CIDR | Web Bot Auth | 主なトークン（ポリシーが異なる） |
|---|---|---|---|---|
| ✅（標準） | ✅ | ⚠️ 実験的 | Googlebotとユーザー起点のフェッチャー | |
| OpenAI | ✕（ほぼPTRなし） | ✅ botごと | 新規 | GPTBot（学習）・ChatGPT-User（ユーザーによるフェッチ）・OAI-SearchBot |
| Anthropic | ✕ | ✅ | 新規 | ClaudeBot・Claude-User・Claude-SearchBot |
| Perplexity | ✕ | ✅（係争中） | なし | PerplexityBot・Perplexity-User |
単純なパイプラインを壊す微妙な点があります。ユーザー指示のフェッチャーは実在の訪問者のように振る舞い、公開されているbotのレンジの外から正当に発信されることがあります。 ユーザーがアシスタントに特定のURLを開くよう頼んだとき、そのフェッチは、通常のブラウザのUser-Agentを持つ一般的なクラウドインフラから届くことがあります。そのため、「GPTBotのレンジにない」ことを理由にブロックすると、実在のユーザーのエージェント操作をブロックしてしまう可能性があります。レート制限とブロックのポリシーは、ベンダー単位ではなく、トークン単位で変える必要があります。
SEO・分析系クローラーの検証：AhrefsBotなど
同じ2つのIP層の方法で、ログの中で最も確認したくなるSEOや分析系のクローラー、つまりAhrefsBotと、SemrushBotやDataForSeoBotのような同類を検証できます。これらはAIクローラーではありませんが、検証の方法は同じです。
- AhrefsBotは前方確認付き逆引きDNSで検証できます（アドレスがAhrefs自身のドメイン配下のホスト名に解決されます）。また、Ahrefsは許可リスト用にクローラーのIPレンジを公開しています。方法1と同じFCrDNSのチェックを実行するか、方法2の公開リストと照合してください。
- 落とし穴はAIクローラーと同じです。ASNで許可リストに入れてはいけません。 検証していない適当なホスティングのレンジから届く「AhrefsBot」は、まさになりすましのパターンです。誰でも
User-Agent: AhrefsBot/7.0を送れるからです。文字列ではなく、IPを確認してください。
ファイアウォールのルールを作るために「AhrefsBotのIPアドレス」を探しているなら、長持ちするのは、前方確認付き逆引きDNSのチェックと、運営者が公開するレンジを定期的に更新する方法です。クローラーが容量を増やした途端に陳腐化する、ハードコードしたIPリストではありません。
方法3：Web Bot Authと暗号による検証
なりすましの構造的な解決策は、ネットワーク上の位置を信用するのをやめ、代わりに署名を検証することです。Web Bot Authでは、エージェントがRFC 9421 HTTPメッセージ署名（Proposed Standard、2024年2月）を使い、Ed25519鍵で各リクエストに署名します。リクエストには次のものが含まれます。
Signature: 署名の値Signature-Input: 対象となるコンポーネント、created／expires、keyid、tag="web-bot-auth"Signature-Agent: 任意。署名するエージェントを示します
鍵は、/.well-known/http-message-signatures-directoryにあるJWKSとして検出されます（RFC 8615のwell-known URIの仕組みに基づきます）。検証は、ディレクトリを取得し、keyidのサムプリントを照合し、署名とcreated／expiresの期間を検証します。IPによる方法に対する利点は決定的です。ID はルートではなくリクエストに載っているため、共有されたアドレス、ローテーションするアドレス、CGNATのアドレスでも有効です。
現実的な評価：実験段階であり、標準ではない
ここでは、アーキテクチャに対して正直になってください。Web Bot Authは、IETFのインターネットドラフト（draft-meunier-web-bot-auth-architecture、2026年3月2日、著者はCloudflareとGoogle）で規定されており、「IETFによる承認はなく、正式な位置づけはない」という定型文が付き、2026年9月3日に失効します。Google自身の対応も明示的に実験的です。「まだすべてのリクエストに署名しているわけではない」とされ、運営者にはIP、逆引きDNS、User-Agentによる検証を使い続けるよう案内されています。インフラ層ではさらに進んでおり、CloudflareはVerified Bots ProgramにMessage Signaturesを組み込み（2025年7月）、AWS WAFも対応を追加しました（2025年11月）。結論：署名がある場合は優先しますが、まだそれに依存してはいけません。
段階的な判断パイプライン（そのまま使えます）
3つの方法を優先順位に組み合わせ、その後でエンリッチと分類を行います。botを検証したら、そのガイドにある3段階のポリシーで、検証済みの各AIクローラーをどう扱うかを決めてください。
1. Parse the claimed bot token from the User-Agent; treat it as a HINT only.
2. If a Web Bot Auth signature is present → verify against the JWKS.
PASS → verified-good (strongest; IP-independent). Done.
3. Else match source IP against the vendor's published CIDR file,
pinned to that specific token.
IN RANGE → verified-good.
4. Else run FCrDNS where a PTR record exists.
FORWARD-CONFIRMED → verified-good.
5. Enrich the IP (this is where an IP-intelligence API slots in):
ASN / owner, hosting/datacenter flag, VPN/proxy/Tor flags,
and an IP risk score.
6. Classify:
verified-good → allow
declared-but-unverified → rate-limit or challenge (NOT hard block)
undeclared automation → challenge / block by behavior + provenance
ステップ5がGeoIPHubの出番です。自己申告したbotのIPが公開レンジになく、PTRもない場合、ASNの所有者、データセンター／ホスティングのフラグ、VPN、プロキシ、Torのフラグ、そしてリスクスコアによって、判断不能なケースを推測ではなく、ログイン、サインアップ、チェックアウトの場面でスコアリングできます。申告済みだが未検証のバケットをレート制限する場合、IPv6の送信元はアドレスではなくプレフィックスで集計してください。理由は、/64プレフィックスによるIPv6のレート制限とブロックのガイドで説明しています。
同じGoogleのASNで、検証済みのGooglebotとそうでないもの
同じGoogleのネットワーク内にある2つのアドレスが、正反対のクローラー判定を受けます。チェックはASNではなく公開プレフィックスを使うからです。2026年10月5日に2つのGoogleのIPをルックアップしました（結果はレンジの変化に伴って変わります）。1つはGoogleが公開しているGooglebotのレンジファイルにある最初のIPv4プレフィックスの先頭アドレス192.178.4.0、もう1つはGoogle Public DNSの8.8.8.8です。
[
{
"ip": "192.178.4.0",
"asn": { "asn": 15169, "org": "GOOGLE - Google LLC", "asn_type": "hosting", "user_type": "search_engine_spider" },
"detection": { "is_hosting": true, "is_vpn": false, "is_proxy": false },
"threat": {
"is_crawler": true,
"crawler": {
"verified": true,
"name": "Googlebot",
"operator": "Google",
"category": "search_engine",
"verification_method": "ip_range_list"
}
},
"scoring": {
"fraud_score": 0,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "no_ptr_datacenter", "verified_crawler"]
}
},
{
"ip": "8.8.8.8",
"asn": { "asn": 15169, "org": "GOOGLE - Google LLC", "asn_type": "hosting", "user_type": "hosting" },
"detection": { "is_hosting": true, "is_vpn": false, "is_proxy": false },
"threat": {
"is_crawler": false,
"crawler": { "verified": false, "name": "none", "verification_method": "none" }
},
"scoring": {
"fraud_score": 15,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "no_ptr_datacenter"]
}
}
]
どちらもAS15169に属し、どちらもホスティングなので、ASNの許可リストでは同じ扱いになります。Googlebotのファイルの内側にあるのは1つ目だけで、threat.crawler.verification_method: "ip_range_list"は、判定が方法2から得られたことを示しています。verified_crawlerのシグナルによりfraud_scoreは0まで下がり、8.8.8.8は通常のデータセンターのスコア15のままです。no_ptr_datacenterのメソッドは両方で発動していますが、これは当社のレコードにこれらのPTRがないためです。一方、実際にdig -x 192.178.4.0を実行するとcrawl-192-178-4-0.googlebot.comが返ります。これは、レンジのチェックこそ自動化すべきものであることを示す、小さな実例です。PTRの引き当てが成功するかどうかに依存しないからです。
失敗パターンと誤検知
ランキング上位の記事が間違えやすい点です。
- レンジ外 ≠ 偽物。 Perplexityの事例（Cloudflare、2025年8月）では、一般的なChromeのUA、公開レンジの外にあるIP、ローテーションするASNを使うクローラーが、1日300万〜600万リクエストを行っていました。レンジ内は真陽性、レンジ外は判断不能であり、偽物の証明ではありません。
- CGNATの地理的な偏り。 2025年後半のCloudflareの調査（The Register経由）では、CGNATのIPは、botのシグナルが低いにもかかわらず、約3倍の頻度でレート制限を受けていました。数百のユーザーが1つのIPv4を共有しており、アフリカとアジアに集中しています。単純なIPブロックは公平性の問題です。
- iCloud プライベートリレー。 実在の人間を運ぶ、共有されローテーションする出口IPです。AppleのCSVで許可リストに入れてください。
- 住宅用プロキシ。 ASNの許可リストを完全に無効化します（Impervaの2025年のレポートでは、bot攻撃の21%がこれを使用）。だからこそ、実在の顧客をブロックせずに匿名化トラフィックを検出することは、リストの照会ではなく挙動の問題です。
原則：ハードブロックは挙動と出どころの組み合わせに対してのみ行い、リストに載っていないという事実だけで行ってはいけません。
検証済みbotはGIVT、なりすましはSIVT
Media Rating Councilの分類では、申告済みのクローラーと既知のデータセンターIPは一般的な無効トラフィック（General Invalid Traffic）でリストによるフィルタリングが可能ですが、「正当なユーザーになりすます」botは、分析と審査が必要な高度な無効トラフィック（Sophisticated Invalid Traffic）です。IPでクローラーを検証することは、リクエストを後者のバケットから前者へ移すことにほかなりません。カテゴリの全リスト、Google独自の9つのカテゴリ、そのうちIPルックアップで見えるものについては、GIVTとSIVT：Googleの無効トラフィックのカテゴリをご覧ください。
GeoIPHubでAIクローラーとエージェントを検証する
GeoIPHubは、従来のジオIPサービスがハウツーのコンテンツで触れていないステップ5のエンリッチを提供します。ASNと接続タイプ、ホスティング／データセンターの検出、VPN／プロキシ／Torのフラグ、19の公式レンジフィードに基づく検証済みクローラーのフラグ（GPTBot、ClaudeBot、PerplexityBot、AhrefsBotを含む）、そしてIP不正リスクスコアです。住宅用プロキシは検出しません。それには挙動のシグナルが必要です。これにより、自己申告したbotが本当にベンダーのインフラから発信されているかを確認し、判断不能なケースを乱暴にブロックするのではなくスコアリングできます。上記の検証方法と、アカウント乗っ取りとクレデンシャルスタッフィングの検出およびIPジオロケーションの本当の精度の関連ガイドを組み合わせてください。
よくある質問
リクエストが本当にGPTBotからのもので、なりすましではないことをどう確認すればよいですか？
User-Agentヘッダーは簡単に偽装できるため、信用してはいけません。送信元IPを、OpenAIが公開しているbotごとのレンジファイル（openai.com/gptbot.json）と照合し、一般的なOpenAIのレンジではなく、GPTBotに限定してチェックします。有効なWeb Bot Auth署名がある場合は、IPに依存しないため、まずOpenAIの鍵ディレクトリで検証します。公開レンジに含まれないIPは、偽物と証明されたわけではなく、判断不能として扱ってください。ユーザーの指示で動くエージェントのトラフィックは、他のインフラから発信されることがあるためです。GPTBot、OAI-SearchBot、ChatGPT-Userの比較では、OpenAIの各レンジファイルからの実際のルックアップを紹介しています。
前方確認付き逆引きDNS（FCrDNS）とは何ですか？
FCrDNSは4段階のチェックです。送信元IPを逆引きDNSでホスト名に変換し、そのホスト名が運営者のドメインで終わることを確認し、そのホスト名を順引きDNSで解決し、元のIPに戻ってくることを確認します。順引きの段階がなりすましを防ぎます。攻撃者は自分のIPに偽のPTRレコードを設定できますが、運営者の権威DNSによる順引きは偽造できません。PTRの文字列を調べるだけのチェックは、なりすましが可能です。
なぜUser-Agent文字列だけでAIクローラーをブロックできないのですか？
User-Agentは誰でも送れる主張だからです。HUMAN Securityは、有名なAIクローラーとラベル付けされたトラフィック全体の5.7%が偽物であり、ChatGPT-Userエージェントでは6件に1件近くに達することを確認しました。ヘッダーだけでブロックすると、なりすましのbotを通してしまううえ、単に名乗るのをやめた運営者には何の効果もありません。
Web Bot Authとは何ですか？ 完成した標準ですか？
Web Bot Authは新しい手法で、botがRFC 9421のHTTPメッセージ署名を使い、Ed25519鍵で各HTTPリクエストに暗号署名を付け、オリジンが/.well-known/http-message-signatures-directoryで公開された鍵で検証します。RFC 9421自体はProposed Standard（2024年2月）ですが、Web Bot Authは2026年半ば時点でもIETFのインターネットドラフトにとどまり、正式な位置づけはありません。実験的なものとして扱い、署名がある場合は検証しつつ、IPと逆引きDNSによる検証を基本として維持してください。
AIベンダーはクローラーのIPレンジをどこで公開していますか？
OpenAIはopenai.com/gptbot.json、searchbot.json、chatgpt-user.jsonでbotごとのJSONを公開しています。Googleはdevelopers.google.com/static/crawling/ipranges/配下でCIDRのJSONを公開しています。Anthropicは自社のbot用に、claude.com/crawling/bots.jsonで1つのファイルを公開しています。Perplexityはperplexitybot.jsonとperplexity-user.jsonを公開しています。各チェックを該当するbotのファイルに限定し、ホスティングのASNではなく公開されている正確なプレフィックスと照合し、ファイルを定期的に更新してください。OpenAIの3つのファイルと現在のプレフィックス数については、GPTBot、OAI-SearchBot、ChatGPT-UserのIPレンジをご覧ください。
IPがベンダーの公開レンジに含まれない場合、リクエストは偽物ということですか？
いいえ。レンジ内のIP、FCrDNSの合格、有効な署名は信頼度の高い真陽性ですが、レンジ外のIPは判断不能です。他のインフラから届く正当なユーザー指示のエージェントトラフィック、CGNATで共有されているアドレス、iCloud プライベートリレーの出口、PTRレコードを公開していないベンダー、あるいはこちら側のレンジファイルが古いことが考えられます。ハードブロックは、リストに載っていないという事実だけでなく、挙動と出どころのシグナルに対してのみ行ってください。
クローラーのIPレンジをブロックすると、共有アドレスを使う一般ユーザーに影響しませんか？
影響します。だからこそ、IPが載っていないことをハードブロックのきっかけにしてはいけません。2025年後半のCloudflareの調査では、CGNATのアドレスは、botの指標が低いにもかかわらず、CGNATでないアドレスの約3倍の頻度でレート制限を受けていました。数百から数千のユーザーが1つのIPv4アドレスを共有しており、CGNATはアフリカとアジアの一部に集中しているため、地理的な偏りが生じます。iCloud プライベートリレーの出口IPにも実在の人間が含まれるため、Appleが公開しているCSVを使って許可リストに入れるべきです。
GeoIPHub API を支えるチーム
GeoIPHub IP インテリジェンス API とそのスキャナーを開発している GeoIPHub チームが執筆しています。下書きは AI の支援を受けて作成し、チームが編集しています。API の例は、「説明用」と明記したものを除き、本番 API に対する実際のルックアップです。
ネットワークセキュリティ
不正防止