IP による bot 検知：IP でわかること、わからないこと

このギャップが重要なのは、今やリクエストの大半が bot によるものだからです。Imperva の 2026 Bad Bot Report によると、2025年に同社が観測した Web トラフィックの53%が自動化トラフィックで、悪質な bot だけで40%を占めていました。つまり、ログインフォームで役に立つ問いは「これは bot か？」であることはまれです。「どの種類の bot で、通すべきか？」なのです。

種類を挙げておく価値があります。検証済みのクローラー、検証されていない自己申告の bot、なりすまし、AI エージェントとユーザー起点のフェッチャー、コンテンツや価格のスクレイパー、クレデンシャルスタッファー、そしてスキャナーです。以下では、bot の分類ごとに1つずつ、計5つの IP に対して1回のルックアップが何を返したかを示し、それぞれの用途を詳しく扱うガイドを紹介します。IP、逆引き DNS、公開レンジによるクローラーの検証、サインアップとチェックアウトの保護、そして実在ユーザーを締め出さないレート制限です。

IP アドレスで bot を検知する方法：6つのシグナル

IP アドレスで bot を検知するには、送信元 IP をルックアップし、6つのシグナルを読み取ります。ネットワークタイプ、逆引き DNS、公開されているクローラーのレンジ、匿名性のフラグ、スキャナーのフラグ、そしてそのプレフィックスから届くリクエストの数です。IP が User-Agent よりも優れた出発点である理由はシンプルです。ヘッダーはクライアントが自由に選べるテキストですが、HTTP リクエストには TCP ハンドシェイクの完了が必要なため、送信元 IP は簡単には偽造できません。現実の回避策は、他人の IP を借りるかプロキシ経由で使うことであり、それについては以下のセクションで取り上げます。

2026年10月7日に、bot の分類ごとに1回ずつ、GeoIPHub API の匿名ルックアップを実行しました。

スコアの列を上から読んでいくと、主な教訓が見えてきます。2026年10月7日の GeoIPHub のルックアップでブロックされたのは、Tor 出口ノード（fraud_score 100）だけでした。Googlebot は0、Censys のスキャナーは0、iCloud Private Relay の出口は9、DigitalOcean のサーバーは15で、すべて allow でした。スコアが答えるのは「この IP はどれだけ危険か？」であり、「これは bot か？」ではありません。スコア15のデータセンターサーバーもスコア0のスキャナーも自動化されたトラフィックですが、どちらもそれ自体は危険ではありません。ここで最も信頼できるシグナルはリストとの一致です。ネットワークタイプのフラグは推定であり、だからこそスコアをわずかしか動かしません。これは5件の単発ルックアップであってベンチマークではなく、レンジが変わると値も変わります。

各シグナルが何を示し、詳細がどこにあるかは次のとおりです。

• ネットワークタイプ（asn.asn_type、asn.user_type、detection.is_hosting）。ASN、つまりその IP をアナウンスしているネットワークから、誰のネットワークなのかがわかります。データセンター（ホスティング）の IP、つまり API の detection.is_hosting は最初のフィルターです。bot の大半はデータセンターで動いており、人間の大半はそうではないからです。ただし単独では弱い判定材料であり、だからこそ DigitalOcean のスコアは15でした。データセンター IP アドレスとは何かの解説記事では、ホスティングがどのように検知されるのか、そしてどのような場合に正当なのかを取り上げています。
• 逆引き DNS（network.ptr_record、fcrdns_valid）。正引きで確認されたホスト名から、運営者がわかることがあります。Tor 出口ノードの PTR は tor-exit.artikel10.org で終わっており、rdns_tor が発火しました。当社側の制約を1つ挙げておきます。API は Googlebot や DigitalOcean の IP について PTR を保存していませんが、dig -x を実行するとどちらもライブな名前が返されます。そのため、これらには no_ptr_datacenter が発火します。ホスト名が重要な場合は、DNS チェックを自分で実行してください。
• 公開されているクローラーのレンジ（threat.crawler）。IP を運営者自身のレンジファイルと照合することは、bot が名乗っているとおりの存在であることを示す最も明快な証明です。GeoIPHub は、Google、Microsoft（Bing）、Apple、DuckDuckGo、OpenAI、Anthropic、Perplexity、Mistral、Common Crawl、Ahrefs の19の公式レンジフィードを読み込み、毎日再取得しています。
• Tor、VPN、プロキシ、リレーのフラグ（detection.is_tor、is_vpn、is_proxy、is_relay）。これらは、本当のクライアントが他人のネットワークの背後に隠れていることを示します。IP で Tor トラフィックを検知する方法と VPN とプロキシの検知の仕組みを参照してください。
• スキャナーのフラグ（threat.is_scanner）。インターネット全体をスキャンするスキャナーは、到達できるあらゆるアドレスを探索します。
• プレフィックスごとのレート。 これは当社ではなくあなたの側のシグナルです。後述のレート制限のセクションで説明するとおり、IPv6 では /64 ごとにリクエストを数えます。

スキャナーの結果は意外だったので、実際のレスポンスを抜粋して示します。

スキャナーのフラグは立っていますが、スコアには何も加算されておらず、Censys のネットワークはホスティングとして分類されていません。recommended_action だけで判断していると、スキャナーのトラフィックは素通りします。アナリティクスから除外したい場合やファイアウォールでブロックしたい場合は、threat.is_scanner を直接読み取ってください。

bot の IP アドレスチェック：このクローラーは名乗っているとおりの存在か？

bot の IP アドレスチェックでは、名乗っているクローラーを、その IP を運営者が公開しているレンジファイル、または正引きで確認された逆引き DNS 名と照合して確認します。User-Agent を信用して判断することは決してありません。どのクライアントでもそのヘッダーに Googlebot と書いて送れます。IP レンジを管理しているのは運営者だけです。

当社の API が見るのは IP だけで、リクエストヘッダーは一切見ないため、比較はあなたのコードで行います。名乗っている bot の運営者を、threat.crawler.verified および threat.crawler.operator と照合してください。threat.crawler.name をキーにしてはいけません。これはファイルのラベルであり、1つのファイルが複数の bot をカバーすることもあるからです。当社のルックアップでは、66.249.66.1 は verified: true、name: "Googlebot"、verification_method: "ip_range_list" を返しました。DigitalOcean のサーバーは name: "none" を返したため、そこからの Googlebot という申告は未検証です。これは「その bot として検証されていない」という意味であり、偽物であることの証明ではありません。

ClaudeBot と PerplexityBot は、Anthropic と Perplexity が公開しているレンジファイルでカバーされています。2026年10月8日には、216.73.216.10 が verified: true、name: "ClaudeBot"、operator: "Anthropic" を返しました。レンジファイルを公開していない bot については、逆引き DNS など運営者自身が定める方法が引き続き必要です。Web Bot Auth でリクエストに署名している bot は、IP ではなく署名で確認できます。

詳細は4つの記事にまとめています。クローラー検証ガイドでは、逆引き DNS、CIDR ファイル、Web Bot Auth の署名を取り上げています。Googlebot を検証し、偽の Googlebot を見抜く方法では、Google の3つのクローラーグループとそのレンジファイルを解説しています。GPTBot、OAI-SearchBot、ChatGPT-User の比較では、どの OpenAI の bot をブロックすべきか、それぞれをどう確認するかを解説しています。検証済みクローラー IP リストには、19のファイルすべてとその日付、そして許可リストのコードを掲載しています。

IP ベースの bot 検知でわからないこと

IP ベースの bot 検知では、家庭の IP がレジデンシャルプロキシとして貸し出されているかどうかはわかりません。また、GeoIPHub はレジデンシャルプロキシを検知しません。レジデンシャルプロキシネットワークは、bot のリクエストを誰かの家庭の回線経由で中継します。IP レイヤーでは、そのリクエストはその家庭自身のトラフィックと同じに見えます。コンシューマー向け ISP、実在する都市、ホスティングのフラグなし、です。

当社の is_residential_proxy フィールドは ASN に基づく大まかな推定であり、検知ではないため、シグナルがないものとして扱ってください。ローテーションによって状況はさらに悪化します。プールはリクエストごとに異なる家庭の IP を割り当てられるため、IP ごとのカウンターは決して増えません。

ボットネットにも同じ盲点があります。感染した家庭用デバイスは普通のレジデンシャル IP から bot トラフィックを送り、ボットネットのフィードがカバーするのはコマンド＆コントロールサーバーのような既知のインフラであって、感染したすべてのデバイスではありません。bot が IP による検知を回避する一般的な方法は4つあります。アドレスのローテーション、レジデンシャルプロキシの借用、IPv6 の /64 内での巡回、そして実際のスマートフォンとキャリアの IP を共有するモバイルプロキシの経由です。

• レジデンシャルプロキシ。 検知されません。アカウントごとの頻度、デバイスやセッションの不一致といった行動で捕捉してください。
• User-Agent やその他のヘッダー。 API はこれらを一切見ません。申告内容の比較は自社のコードで行ってください。
• 誰が入力しているか。 同じオフィスの IP 上にいるヘッドレスブラウザと人間は、このレイヤーではまったく同じに見えます。
• 直近2日以内に公開されたレンジ。 クローラーのレンジファイルは毎日再取得し、ルックアップのデータベースも毎日再構築しているため、新しく公開されたばかりのレンジは最大で約2日間、未検証のままになる可能性があります。
• 当社の19フィードに含まれないクローラー。 何を名乗っていても、検証済みの ID は付きません。
• スキャナーのリスク。 is_scanner は立ちますが、当社のルックアップでは fraud_score は上がりませんでした。

これらのギャップを埋めるレイヤーは IP の隣にあります。行動と頻度、デバイスフィンガープリント、JA3 や JA4 などの TLS フィンガープリント、チャレンジ、そして自ら名乗る bot に対する Web Bot Auth です。レジデンシャル側については、ルックアップで何がわかり何がわからないかを レジデンシャルプロキシ詐欺の検知で、なぜこれほど多いのかをトラフィックにレジデンシャルプロキシがこれほど多く現れる理由で解説しています。

サインアップ、ログイン、チェックアウトで bot トラフィックを検知する方法

サインアップ、ログイン、チェックアウトで bot トラフィックを検知するには、操作が行われた時点で IP ルックアップを実行し、アプリがすでに把握している情報、つまりアカウントごと、プレフィックスごと、デバイスごとの試行回数と組み合わせます。IP は候補を絞り込みます。最終判断を下すのは自社のカウンターです。

エンドポイントごとに、シグナルの重み付けは異なります。

• ログイン。 クレデンシャルスタッフィングは、多数の IP に試行を分散させます。その多くは、IP レイヤーではフラグを立てられないレジデンシャルの IP です。それでも、Tor とホスティングのフラグで手抜きの部分は捕捉できます。アカウント乗っ取りとクレデンシャルスタッフィングのガイドでは、多層的なプレイブックを解説しています。
• チェックアウト。 チェックアウト時のデータセンター IP は正規の AI ショッピングエージェントである可能性があるため、ホスティングはブロックではなく重み付けされた入力として扱います。DigitalOcean のサーバーのスコアは15、allow でした。チェックアウトでの AI ショッピングエージェント詐欺を防ぐ方法を参照してください。
• 広告クリック。 ホスティングと Tor のフラグは、コンバージョンデータから除外すべきクリックを示します。IP アドレスでクリック詐欺を検知するガイドで、スコアリングの方法を紹介しています。
• サインアップ。 同じスコア帯が適用されるほか、1つのプレフィックスからの多数のアカウントもチェックします。

スコア帯をデフォルトの対応として使ってください。25までは allow、50までは review、75までは step_up、75を超えたら block です。is_scanner のようにスコアに反映されないフラグについては、独自のルールを追加してください。

実在ユーザーをブロックせずに bot の IP をレート制限する方法

bot の IP は、1人の行為者に対応する単位でレート制限します。IPv6 では /64、IPv4 では単一のアドレスです。ただし、CGNAT や iCloud Private Relay のような共有の出口については調整が必要です。間違った単位で数えると、bot を見逃すか、大勢の人を罰することになります。AI クローラーに特化した、許可するか、検証するか、レート制限するかの判断については、AI クローラーをブロックすべきかで詳しく検討しています。

IPv6 では、1人の加入者に /64 全体が割り当てられ、その中を無料で巡回できるため、アドレスごとのカウンターは決して作動しません。IPv6 を /64 プレフィックス単位でレート制限・ブロックするガイドでは、キー関数と、/56 や /48 へ範囲を広げるべきタイミングを紹介しています。

IPv4 では逆の問題が起こります。多くの人が1つのアドレスを共有しているのです。キャリアグレード NAT は、地域一帯を1つの IP の背後に置きます。API はこれを threat.is_cgnat としてフラグを立て、スコアリングでは CGNAT アドレスのリスクに上限を設けています。iCloud Private Relay も Apple ユーザーに対して同じことをします。当社がルックアップしたリレーの IP はスコア9、allow で、メソッドは relay_ip でした。

リレーのジオロケーションにも注意が必要です。当社のルックアップでは、104.28.46.99 はアンゴラのルアンダに位置付けられました。これはリレーの出口であって、ユーザーの所在地の証明ではないため、これに基づいて地域ブロックをしないでください。本物の顧客をブロックせずに匿名化トラフィックを検知するガイドでは、Apple が公開している出口リストと、リレーの扱い方を解説しています。

IP による bot 検知はどこから始めるか

IP による bot 検知を実践するには、各シグナルをデフォルトの対応に対応付けます（1つの疑わしいアドレスを調べる場合は、代わりにIP 調査の完全なプレイブックに従ってください）。検証済みのクローラーは許可し、未検証のクローラーの申告はレート制限し、Tor はブロックまたは追加認証を求め、IP がレジデンシャルに見える場合は行動シグナルを使います。以下の各行は1つのシグナルであり、それが証明すること、デフォルトの対応、そして詳しく解説している記事を示しています。

自社のトラフィックがどこに位置するかを最も早く確認する方法は、昨日のログから最も多くアクセスしてきた20個の IP を取り出し、それぞれを無料の IP ルックアップツールに貼り付けることです。あるいは、キーなしで curl -s https://api.geoiphub.com/v1/lookup/<ip> を実行する（1分あたり30回のルックアップ）か、無料キーを使えば1日1,500回までルックアップできます。最初の表の bot の分類で並べ替えれば、このマップのどのセクションから読むべきかがわかります。

よくある質問

IP アドレスだけで bot を検知できますか？

部分的には可能です。IP ルックアップからわかるのは、リクエストがどのような種類のネットワークから来たかです。公開されているクローラーのレンジ、データセンターのサーバー、Tor 出口ノード、VPN、プライバシーリレー、既知のスキャナーなどです。リクエストを送ったのが人間かスクリプトかはわからず、レジデンシャルプロキシネットワークを通じて貸し出された家庭の IP も見抜けません。IP は、リクエストレート、アカウント履歴、デバイスのシグナルと並ぶ判断材料の1つとして使ってください。

bot の IP アドレスが本物のクローラーかどうかは、どう確認すればよいですか？

IP を運営者が公開しているレンジファイルと照合するか、逆引き DNS ルックアップを実行して正引きで確認します。User-Agent は何の証明にもなりません。どのクライアントでも任意の文字列を送れるからです。2026年10月7日のルックアップでは、66.249.66.1 は threat.crawler.verified が true、名前が Googlebot と返されましたが、DigitalOcean のサーバーにはクローラーの ID がまったく返されませんでした。逆引き DNS、レンジファイル、Web Bot Auth については、クローラー検証ガイドで手順を追って解説しています。

IP による bot 検知の精度はどのくらいですか？

シグナルによって異なります。公開リストとの一致は強力な証拠です。GeoIPHub は10の運営者による19の公式クローラーレンジフィードを毎日再取得して照合し、6時間ごとに更新される Tor Project の出口ノードリストも照合しています。ホスティング、VPN、プロキシのフラグは推定です。ホスティングの検知には、厳選された853のホスティング ASN と、10のクラウド事業者の公式レンジを使っています。レジデンシャルプロキシは検知しません。精度の割合は公表しておらず、この記事の5件のルックアップはあくまで例であり、ベンチマークではありません。

不正スコアが高ければ、その IP は bot ということですか？

いいえ。スコアが測るのはリスクであり、自動化ではありません。5件のルックアップでは、Censys のスキャナーのスコアは0、DigitalOcean のサーバーは15で、どちらも allow でしたが、どちらも明らかに自動化されたトラフィックです。Tor 出口ノードのスコアは100で block でした。トラフィックの正体はフラグで、どれだけ危険かはスコアで読み取ってください。

GeoIPHub はレジデンシャルプロキシを検知しますか？

いいえ。is_residential_proxy フィールドは ASN に基づく大まかな推定であり、検知ではありません。プロキシネットワークを通じて貸し出された家庭の IP は、IP レイヤーでは普通の家庭の回線と同じに見えるため、捕捉するには行動とセッションのシグナルが必要です。