ネットワークセキュリティウェブスクレイピングの検出方法：ログ、IP ルックアップ、死角
アクセスログからウェブスクレイピングを検出する方法。CCBot、AhrefsBot、Tor 出口、クラウドサーバーの実際のルックアップ、Googlebot を名乗るリクエストの追跡、そして IP では見えないものを解説します。
スクレイパーからの 1 件のリクエストは、ただの GET です。ステータスコード、パス、User-Agent があり、ログの他の行と何も変わりません。スクレイピングが姿を現すのは、数百行にまたがり、ネットワークをまたいだときだけです。クラウドサーバー上の Python スクリプト、Puppeteer や Playwright で動かすヘッドレスブラウザ、AI 学習用クローラー、AhrefsBot のような SEO クローラー、ローテーションするプロキシをギガバイト単位で販売するスクレイピング API などがあります。
2026-10-08 に、スクレイパー系の 7 件の IP を GeoIPHub API にかけました。検証済みクローラー 4 件（Googlebot、CCBot、ClaudeBot、AhrefsBot）はいずれもホスティングネットワークから来ており、allow でした。ごく普通の Linode クラウドサーバーのスコアは 10 でやはり allow、Tor 出口と Mullvad VPN サーバーはどちらもスコア 100 で block でした。IP からわかるのはネットワークです。スクレイピングかどうかの判断は、ログから下します。
以下では、アクセスログでスクレイピングボットを検出する方法を示し、Googlebot を名乗る 1 行のログを追跡し、IP データが見えなくなる場面を示したうえで、見つけたものを許可、レート制限、チャレンジ、ブロックのどれにするかを整理します。まず IP シグナルを 1 つずつ確認したい方は、ハブ記事のIP によるボット検出をシグナルごとに解説した記事をご覧ください。この記事では、それをスクレイピングに当てはめます。
ウェブスクレイピングの検出方法：頻度、パス、クライアント、ネットワーク
ウェブスクレイピングを検出するには、4 つのシグナル群を確認します。クライアントがどれだけの速さでリクエストするか（頻度）、何をどの順序でリクエストするか（パス）、自分自身について何と名乗っているか（クライアント）、どこから接続しているか（ネットワーク）です。OWASP はスクレイピングを独立した自動化脅威 OAT-011 として挙げ、「他の場所で使うためにアプリケーションのコンテンツやその他のデータを収集すること」と定義しています（OWASP Automated Threats）。この定義は意図に関するもので、意図は見えません。見えるのは、この 4 つの群です。
- 頻度。 IP ごと、およびネットワークごとの 1 分あたりのリクエスト数です。ここでのネットワークとは ASN、より細かく分けるなら IPv4 の /24 や IPv6 の /64 を指します。スクレイパーは 24 時間一定のペースで動くことが多く、人間はバーストで現れ、眠ります。
- パス。 一覧ページやページネーションの URL が順番に辿られる、サイトマップが先頭から末尾まで読まれる、商品ページや価格ページだけが対象になる、CSS、JavaScript、画像のリクエストがまったくない、といった特徴です。
- クライアント。 User-Agent の名乗り、
Accept-Languageヘッダーの欠落、リクエスト間で Cookie を保持しない、自動化のマーカーなどです。ブラウザ側では、Chrome が--headlessまたは--enable-automationで動いているときnavigator.webdriverが true になります（MDN）。ただし、本気のスクレイパーはこれを書き換えて隠します。エッジでは、TLS フィンガープリント（JA3 または JA4）から、Chrome を名乗る User-Agent の裏に HTTP ライブラリがいることがよくわかります。 - ネットワーク。 IP ルックアップが返す内容です。データセンター（ホスティング）の IP（API では
detection.is_hostingとしてフラグが立ちます）、検証済みクローラー、Tor、VPN、スキャナーなどです。
ウェブスクレイピング検出が難しいのは、どのシグナルにも無実のそっくりさんがいるからです。オリジンを取得しに来る CDN、稼働監視サービス、1 つの NAT アドレスの背後にあるオフィス、RSS リーダーは、どれも 1 つの軸では不審に見えます。スクレイピングの根拠になるのは、複数のシグナルが一致することです。
| シグナル | スクレイパーの見え方 | 無実のそっくりさん |
|---|---|---|
| IP またはネットワークごとの頻度 | 何時間も 1〜2 秒おきに一定のリクエスト | オフィスの NAT、CGNAT、CDN、監視サービス |
| ページの順序 | page=1, 2, 3 … と順番、またはサイトマップをファイルの順に | 検索結果をめくる人間。ただしページ数ははるかに少ない |
| アセット | HTML のみで CSS、JS、画像なし | フィードリーダー、リンクプレビュー、テキストブラウザ |
| セッションの深さ | 1 セッションで数千ページ | 社内の QA クロールや自社の SEO 監査ツール |
| User-Agent | そのクローラーが使わないネットワークからのクローラー名 | ここ数日で追加された範囲の本物のクローラー |
| ネットワーク | データセンター、Tor、VPN の出口 | 企業 VPN、AI ショッピングエージェント、クラウド上のツール |
ウェブサイトがスクレイピングされているか確認する方法：まずアクセスログを読む
ウェブサイトがスクレイピングされているかを確認するには、アクセスログをネットワーク単位でグループ化し、多数のページを、順番に、ブラウザなら読み込むアセットを一切読み込まずに取得しているクライアントを探します。外部からの兆候のほうが先に現れることが多く、商品の説明文や価格が別のサイトに現れたり、コンバージョンは横ばいのまま一覧ページの帯域幅やサーバーコストが増えたりします。外部から確かめるには、自分のページの特徴的な一文を引用符で囲んで検索し、価格を変更してから数時間以内にそれがアグリゲーターサイトに再び現れていないかを観察します。誰がやったのかは、ログが教えてくれます。
combined 形式のアクセスログでは次のように見えます。これらは説明用の値であり、実際のトラフィックではありません。 45.33.32.156 は Linode 上の Nmap の公開テストホストで、これらのリクエストを送ったわけではありません。実在の訪問者の IP を公開するわけにはいかないため、「クラウドサーバー」の代役として使っています。
# illustrative values, not real traffic
45.33.32.156 - - [08/Oct/2026:03:14:07 +0000] "GET /products?page=34 HTTP/1.1" 200 48211 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
45.33.32.156 - - [08/Oct/2026:03:14:08 +0000] "GET /products?page=35 HTTP/1.1" 200 47960 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
45.33.32.156 - - [08/Oct/2026:03:14:10 +0000] "GET /products?page=36 HTTP/1.1" 200 48377 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
45.33.32.156 - - [08/Oct/2026:03:14:11 +0000] "GET /products?page=37 HTTP/1.1" 200 48102 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
45.33.32.156 - - [08/Oct/2026:03:14:13 +0000] "GET /products?page=38 HTTP/1.1" 200 47815 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
45.33.32.156 - - [08/Oct/2026:03:14:14 +0000] "GET /products?page=39 HTTP/1.1" 200 48290 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
目立つ点が 3 つあります。ページが午前 3 時に 1 つずつ、1〜2 秒間隔で増えていきます。リファラーがなく、その間に .css や .js のリクエストが 1 件もありません。そしてクライアントは Googlebot を名乗っており、これは次のセクションで検証します。
こうしたクライアントを見つけるのにログ基盤は必要ありません。標準的な combined 形式のログなら、次のワンライナーで足ります。まず混雑した 1 時間分で試してください。
# Busiest client IPs
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
# Busiest IPv4 /24 networks (rotating scrapers often stay inside one block)
awk '{split($1,o,"."); print o[1]"."o[2]"."o[3]".0/24"}' access.log | sort | uniq -c | sort -rn | head -20
# Busiest User-Agents
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -20
# Clients with more than 100 page requests and zero asset requests
awk '{ if ($7 ~ /\.(css|js|png|jpe?g|webp|svg|woff2?)(\?|$)/) a[$1]++; else p[$1]++ }
END { for (ip in p) if (!(ip in a) && p[ip] > 100) print p[ip], ip }' access.log | sort -rn
出力は、次のリストに沿って確認します。
- アクセスされたページ。 混雑しているクライアントは、一覧、価格、検索結果、サイトマップに集中していますか。
- IP ごと、次にネットワークごとの頻度。 IP を付加情報で補完したあと、ASN ごとにリクエスト数を合計します。同じ ASN 内の 50 個のホスティングアドレスが同じページを辿っているなら、おそらく同一の攻撃者です。
- セッションの深さ。 カート、ログイン、検索ボックスの利用がないまま、1 セッションで数百ページ。
- 順序。 ページネーションやサイトマップの URL が順番に取得されている。
- アセット。 HTML のみで、CSS、JavaScript、フォント、画像がない。
- クローラーの名乗り。 Googlebot、Bingbot、GPTBot、ClaudeBot の User-Agent はすべて、IP で検証するリストに入れます。
- 自動化のマーカー。 ライブラリの User-Agent（
python-requests、curl、Go-http-client）とヘッドレスブラウザの手がかり。
スクレイパーの IP アドレス：実際の GeoIPHub ルックアップは何を返すか
スクレイパーの IP アドレスはいくつかのネットワークの種類に分かれ、ルックアップが教えてくれるのは、どの種類を見ているかであって、そのリクエストがスクレイパーだったかどうかではありません。当社の GeoIPHub ルックアップでは、検証済みクローラーのスコアは 0〜23（allow）、Tor と VPN の出口は 100（block）でした。2026-10-08 に、種類ごとに 1 回ずつ匿名でルックアップを 4 秒間隔で実行しました。
curl -s https://api.geoiphub.com/v1/lookup/18.97.14.81
| IP | ボットの種類 | ネットワーク（ASN） | 主なフラグ | fraud_score | recommended_action | detection_methods |
|---|---|---|---|---|---|---|
| 18.97.14.81 | クローラー（category: archiver） | Amazon AMAZON-AES (AS14618) | is_hosting: true, crawler.name: CCBot, verified: true | 0 | allow | datacenter_ip, rdns_hosting, verified_crawler |
| 216.73.216.10 | クローラー（category: ai） | Amazon AMAZON-02 (AS16509) | is_hosting: true, crawler.name: ClaudeBot, verified: true | 0 | allow | datacenter_ip, no_ptr_datacenter, verified_crawler |
| 5.39.1.230 | クローラー（category: seo） | OVH (AS16276) | crawler.name: AhrefsBot, verified: true, is_abusive: true | 23 | allow | abusive_listed, datacenter_blocklisted, no_ptr_datacenter, verified_crawler |
| 192.178.4.40 | クローラー（category: search_engine） | Google (AS15169) | crawler.name: Googlebot, verified: true | 0 | allow | datacenter_ip, no_ptr_datacenter, verified_crawler |
| 45.33.32.156 | ごく普通のクラウドサーバー | Akamai Connected Cloud, Linode (AS63949) | is_hosting: true, crawler.name: none | 10 | allow | datacenter_ip |
| 185.220.101.47 | Tor 出口 | Stiftung Erneuerbare Freiheit (AS60729) | is_tor: true, is_spammer: true | 100 | block | tor_exit, datacenter_blocklisted, rdns_tor, known_spammer |
| 185.213.155.73 | 商用 VPN | 31173 Services AB (AS39351) | is_vpn: true, vpn_provider: Mullvad, vpn_confidence: 95 | 100 | block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter |
これらは特定の 1 日の単発のルックアップであり、ベンチマークではありません。範囲が変われば値も変わります。既知の欠落が 1 つあります。Googlebot と AhrefsBot の行にある no_ptr_datacenter は、先方の問題ではなく、当社のデータの問題です。一部のクローラー範囲については、逆引き DNS が解決できるにもかかわらず、API に PTR レコードが保存されていません（192.178.4.40 は crawl-192-178-4-40.googlebot.com に解決されます）。ClaudeBot の IP については、このシグナルは正確です。逆引き DNS がありません。
次は CCBot のレスポンスです。省略してありますが、値は実際のもので、入れ子構造も元のままです。
{
"ip": "18.97.14.81",
"asn": {
"asn": 14618,
"org": "AMAZON-AES - Amazon.com, Inc.",
"asn_type": "hosting"
},
"detection": { "is_hosting": true, "is_vpn": false, "is_tor": false },
"threat": {
"is_crawler": true,
"crawler": {
"verified": true,
"name": "CCBot",
"operator": "CommonCrawl",
"category": "archiver",
"verification_method": "ip_range_list"
}
},
"scoring": {
"fraud_score": 0,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "rdns_hosting", "verified_crawler"]
}
}
Common Crawl 自身のクローラーは AWS 上で動いていますが、それでもスコアは 0 です。この IP は 18.97.14.80/29 にあり、これは Common Crawl が ccbot.json ファイルで公開している範囲です。当社のスコアリングにおける検証済みクローラーの補正（−28.5）が、データセンターのシグナルを打ち消します。GeoIPHub は、Google、Bing、OpenAI、Anthropic、Common Crawl、Ahrefs などを含む 19 の公式クローラー範囲フィードを、このように照合しています。そのデータが CCBot や GPTBot のような AI モデルに使われるクローラーにページを読ませたいかどうかは、ポリシーの問題です。ルックアップが決めるのは、それが誰なのかだけです。
意外だったのは AhrefsBot です。検証は通りました（5.39.1.230 は Ahrefs が公開しているクローラー範囲の 5.39.1.224/27 にあります）が、同時に is_abusive: true で、methods に abusive_listed が入り、スコアは 23、結果はやはり allow でした。どのリストが原因でフラグを立てたのかは追跡していません。いずれにしても教訓は変わりません。「検証済み」が示すのはクローラーが誰であるかであり、あなたがそれを望むかどうかではありません。競合他社の被リンクレポートのためにあなたのサイトをマッピングする SEO クローラーも、名乗りを上げているだけで、スクレイピングであることに変わりはありません。
スクレイピングログにおけるクローラーのなりすまし：1 行を追跡する
User-Agent に Googlebot とあるのに、クラウドサーバーから来たリクエストは、裏付けのない名乗りです。その IP が Google の範囲にないことは GeoIPHub が教えてくれますが、User-Agent との突き合わせはあなたのコードで行います。ルックアップはあなたのヘッダーを見ないからです。説明用ログの 4 行目、45.33.32.156、GET /products?page=37、User-Agent Googlebot/2.1 を例に取ります。
- IP をルックアップする。 実際のルックアップは、ASN 63949、Akamai Connected Cloud（Linode）、
detection.is_hosting: true、threat.crawler.name: "none"、verified: false、fraud_score10、allow、methods は["datacenter_ip"]を返しました。 - 名乗りを突き合わせる。 あなたのコードで、User-Agent のトークンを
threat.crawler.verifiedとthreat.crawler.nameと照合します。 - 判断する。 UA は Googlebot ですが、IP はどの Google の範囲にもありません。つまり「Googlebot として未検証」です。レート制限するか、チャレンジを課します。チャレンジ（CAPTCHA や JavaScript チェック）は、API の
step_upアクションに対応する手段です。偽物と決めつけないでください。Google の新しい範囲が当社のデータで検証されるまでに、最大でおよそ 2 日かかることがあります。範囲ファイルは毎日取得され、ルックアップのデータベースも毎日再構築されるためです。 - 対比を確認する。
192.178.4.40の本物の Googlebot は、verified: true、name: "Googlebot"、verification_method: "ip_range_list"、スコア 0 を返しました。
Google は、自分で同じ確認をする方法を 2 つ文書化しています。IP の逆引き DNS を行い、そのホスト名を正引きする方法と、common-crawlers.json などの公開されている範囲ファイルと照合する方法です（Google Search Central）。コードでの突き合わせは次のようになります。
// Map User-Agent tokens to the crawler names the API returns.
// They don't always match: OpenAI's "ChatGPT-User" comes back as "ChatGPTUser".
const CRAWLER_NAMES = {
"Googlebot": "Googlebot",
"GPTBot": "GPTBot",
"CCBot": "CCBot",
"ClaudeBot": "ClaudeBot",
"AhrefsBot": "AhrefsBot",
"ChatGPT-User": "ChatGPTUser",
};
async function classifyRequest(ip, userAgent) {
const res = await fetch(`https://api.geoiphub.com/v1/lookup/${ip}`, {
headers: { "x-api-key": process.env.GEOIPHUB_API_KEY },
});
const { threat, scoring } = await res.json();
const token = Object.keys(CRAWLER_NAMES).find((t) => userAgent.includes(t));
if (token) {
const ok = threat.crawler.verified && threat.crawler.name === CRAWLER_NAMES[token];
return ok ? "allow_crawler" : "unverified_crawler_claim"; // rate-limit or challenge
}
return scoring.recommended_action; // allow, review, step_up or block
}
これは、スコアが allow を示し、パターンがスクレイパーを示すケースです。IP だけで見れば、このリクエストはスコア 10 の allow です。クラウドサーバーであること自体は弱いシグナルだからです。スクレイピングという判断は、スコアには見えない 3 つの要素から導かれます。UA の不一致、一定の頻度、ページを 1 つずつ辿る動きです。Google の手順の全体は、逆引き DNS と Google の範囲ファイルによる Googlebot の検証を、GPTBot、ClaudeBot、署名付きエージェントについては、IP、逆引き DNS、Web Bot Auth による AI クローラーの検証をご覧ください。
IP データでは見えないもの：レジデンシャルプロキシと本物のブラウザ
IP データでは、レジデンシャルプロキシやモバイルプロキシを経由するスクレイパーは見えません。GeoIPHub はレジデンシャルプロキシを検出せず、is_residential_proxy フィールドは ASN に基づく大まかな推定なので、シグナルなしとして扱ってください。レジデンシャルプロキシネットワークは、リクエストごとに誰かの家庭の回線を経由させます。IP の層では、リクエストはその世帯に見えます。一般消費者向けの ISP、実在の都市、ホスティングのフラグなし、クリーンなスコアです。
ローテーションがさらに状況を悪化させます。プールはリクエストごとに新しい家庭の IP を割り当てられるため、IP ごとのカウンターは上がりません。モバイルプロキシは実際のスマートフォンとキャリアの IP を共有し、IPv6 のスクレイパーは新しいネットワークに触れることなく /64 全体を循環できます。
本物のブラウザが 2 つ目の死角です。オフィスや自宅の回線から Chrome を操作する Playwright スクリプトは、隣の席の人と同じ IP、同じ TLS ハンドシェイク、同じアセットを送ります。ヘッドレス環境には自分の存在を知らせてしまうものもありますが、調整されたものは知らせません。
それでもこうしたスクレイパーを露呈させるのは、リクエストをまたぐパターンです。
| スクレイパーの構成 | IP からわかること | それでも露呈する手がかり |
|---|---|---|
| ローテーションするレジデンシャルプロキシ | 一般消費者向け ISP、クリーンなスコア | 同じページ順序、同じタイミングのリズム、同じフィンガープリントを共有する多数の IP |
| モバイルプロキシ | 実際のスマートフォンと共有されるキャリア IP | スマートフォンのユーザーにはあり得ないセッションの深さとパスの順序 |
| /64 内での IPv6 ローテーション | リクエストごとに新しいアドレス | アドレス単位ではなく /64 単位でリクエストを数える |
| 自宅やオフィスの回線上のヘッドレスブラウザ | 通常のアクセスネットワーク | 自動化のマーカー、TLS フィンガープリント、Cookie の継続性がない |
| すべてのリンクを辿るスクレイパー | 使っているネットワークによる | 隠しリンクへのリクエスト：CSS で隠され、どの訪問者にも見えないリンクです。それをリクエストするものは、リンクを盲目的に辿っています |
隠しリンクを設置する場合は、そのパスを robots.txt で Disallow にしてください。そうすれば、robots.txt に従うクローラーがそこに触れることはありません。IP の隣にあるレイヤーについては、さらに 2 つの記事で掘り下げています。デバイスフィンガープリントと IP インテリジェンスを組み合わせるのが効果的な理由と、ルックアップで何が見えて何が見えないかを扱ったレジデンシャルプロキシ不正の検出です。
スクレイピング、クロール、API 悪用の違い
クロールは申告されていて検証可能であり、スクレイピングはあなたのコンテンツやデータを取得するもので、多くの場合は申告されていません。API 悪用は、利用規約や制限を超えてあなたのエンドポイントを呼び出すスクリプト化された呼び出しです。これらの境界線は技術ではなく、振る舞いと身元です。Googlebot と価格のスクレイパーが、同じクラウド上で同じ HTTP ライブラリを動かしていることもあります。
| トラフィックの種類 | 対象 | 身元の示し方 | 確認すること |
|---|---|---|---|
| クロール | 検索インデックス、アーカイブ、AI モデルのためのページ | 名前付きの User-Agent と公開された IP 範囲 | IP が運用者の範囲内にあるか。robots.txt の遵守 |
| スクレイピング | 特定のコンテンツやデータ：価格、一覧、記事 | ブラウザの UA、または借用したクローラー名であることが多い | 頻度、ページ順序、欠落したアセット、UA と検証済みクローラーの対比 |
| API 悪用 | あなたの JSON エンドポイント。多くはサイトの裏側にある | API キー、セッショントークン、またはなし | キーごと・ネットワークごとの呼び出し数、通常のアプリのフローを外れたエンドポイント |
AhrefsBot が示すとおり、検証済みのクローラーでもスクレイピングはあり得ますし、スクレイパーがクローラーに見えることもあります。次のセクションが、検証済みのものだけを許可するところから始まるのはそのためです。
検索クローラーをブロックせずにウェブスクレイピングを防ぐ方法
検索クローラーをブロックせずにウェブスクレイピングを防ぐには、まず検証済みクローラーを許可し、次にネットワーク単位でレート制限をかけ、ブラウザらしく振る舞わないクライアントにはチャレンジを課し、確認できたものだけをブロックします。GeoIPHub のスコア帯は、その IP 側の目安を示します。25 までが allow、50 までが review、75 までが step_up、75 超が block です。順序が重要です。最初に一律のデータセンターブロックを実行していたら、当社の表の Googlebot、CCBot、ClaudeBot、AhrefsBot の 4 件はすべてホスティングネットワークから来ていたため、巻き込まれていたでしょう。
- 検証済みクローラーを許可する。
threat.crawler.verifiedが true で、crawler.nameが User-Agent のトークンと一致する場合です。そのうえで、クローラーごとに自社のポリシーを適用します。AI クローラーについては、GPTBot、OAI-SearchBot、ChatGPT-User の比較記事で、AI 検索から外れずに学習用をブロックする方法を紹介しています。 - IP のルールを再利用する。 スコア帯、Tor の扱い、プレフィックス単位のレート制限は、スクレイパーでも他のボットと同様に機能します。詳細はハブ記事にあります。データセンターの IP は、ブロック対象ではなく重み付けする入力として扱ってください。ホスティングには AI エージェント、企業のプロキシ、自社のツールも含まれるためです（データセンター IP アドレスとはを参照）。
- スクレイパーが狙うページでは ASN 単位でレート制限する。 1 つのホスティングプロバイダーを巡回するプールは、IP 単位の制限の下にとどまりますが、一覧、検索、価格のページに ASN 単位のカウンターを設ければ合算できます。大手クラウドは無関係な多数の顧客が 1 つの ASN を共有しているので、上限は高めに設定してください。
- ページネーションに上限を設け、完全な一覧はログインの背後に置く。 匿名の訪問者には、決まった数の一覧ページだけを提供します。アカウントの壁があれば、スクレイパーごとにアカウントを数えて停止できます。
- ページが呼び出す JSON エンドポイントに、キー単位のクォータを設定する。 スクレイパーは HTML を飛ばして、その裏にある API を呼び出すことがよくあります。そのため、キーやセッショントークンを発行し、キーごとの呼び出し数に上限を設けます。
- ボット管理や WAF のレイヤーを追加する。 エッジでの TLS フィンガープリントや JavaScript チェックなど、ログにはないクライアントのシグナルを補います。
- レジデンシャルのトラフィックには行動ルールを使う。 IP からは何も得られないためです。
対応は、許可、レート制限、チャレンジ、ブロックという段階になります。サイトによっては、スクレイパーと疑われるクライアントへの応答を遅くするタールピットや、すでに分類済みのトラフィックへの価格を改変したダミーコンテンツの提供を加えています。どちらも、分類が間違っていた場合には代償を払うことになるため、どのみちブロックするトラフィックにだけ使ってください。
| シグナル | デフォルトの対応 |
|---|---|
| threat.crawler.verified かつ User-Agent が一致 | 許可し、クローラーごとのポリシーを適用 |
| クローラーの User-Agent で crawler.name が "none" | レート制限またはチャレンジ |
| 同じ ASN 内の 20 以上の IP から同じページ順序 | ASN をレート制限し、その後チャレンジ |
| HTML のみ、100 ページ以上、CSS や JS なし | IP が何を示していてもチャレンジ |
| 人間には見えないリンクへのアクセス | そのクライアントをブロック |
| 一般消費者向け ISP、クリーンなスコア、スクレイパーらしいパターン | 行動ルールとフィンガープリント |
IP だけで判断できる行（Tor、リレー、スキャナー、IPv6 プレフィックス）については、当社のIP によるボット検出ガイドの対応マップを使ってください。
では robots.txt はどうでしょうか。これはお願いであって、強制ではありません。robots exclusion の標準である RFC 9309 は、そのルールは「アクセス認可の一形態ではない」と述べています（RFC 9309）。robots.txt に従うクローラーのために残しつつ、それ以外はすべてサーバー側で強制してください。AI クローラーのブロックのガイドでは、その強制のレイヤーを nginx と Express のコードで示しています。
まず昨日のログから始めましょう。アセットを読み込まなかったクライアントのうち、最も混雑している 50 件を書き出し、それぞれを無料の IP ルックアップ（キーなしで 1 分あたり 30 回、無料キーがあれば 1 日 1,500 回）に貼り付けて、上のルックアップ表の種類に分類します。混雑していて一般消費者向けネットワーク上にある残りのものが、次に行動ルールを適用する対象です。
よくある質問
GPTBot や CCBot などの AI スクレイパーはどうやってブロックしますか？
まず robots.txt から始めます。GPTBot と CCBot はどちらも robots.txt に従うので、それぞれのトークンに Disallow ルールを書けば、名乗っているクローラーは止まります。ただし robots.txt はお願いであって、アクセス制御ではありません（RFC 9309 は、そのルールは「アクセス認可の一形態ではない」と述べています）。そのため、サーバー側でも強制してください。各クローラーを公開されている IP 範囲で検証し、その範囲の外からクローラーの名前を使うクライアントは未検証として扱います。OpenAI は役割の異なる複数のボットを運用しています。ChatGPT 検索に残したい場合にどれをブロックすべきかは、当社の記事 GPTBot vs OAI-SearchBot vs ChatGPT-User で解説しています。
1 分あたり何リクエストならスクレイピングといえますか？
普遍的な数値はありません。通常の日の人間のベースラインを、IPv4 なら /24、IPv6 なら /64 単位で自分で測定し、それをはるかに上回るネットワークに注目してください。頻度だけでは、オフィスの NAT、CGNAT、監視サービスにもフラグが立ちます。そのため、高い頻度は、ページが順番に取得され、アセットのリクエストがない場合にのみスクレイピングとみなしてください。
ウェブスクレイピングを完全に止めることはできますか？
できません。ブラウザが表示できるものは、本気のスクレイパーならレジデンシャルプロキシや本物のブラウザ経由を含めてコピーできます。目標は、スクレイピングを遅く、高コストで、目に見えるものにすることです。クローラーを検証し、ネットワーク単位でレート制限をかけ、ブラウザらしく振る舞わないクライアントにはチャレンジを課し、価値の高いデータはログインや API キーの背後に置きます。
データセンターの IP をブロックすればスクレイピングは止まりますか？
部分的には止まります。安価なクラウドサーバーで動くスクレイパーは止まりますが、先に許可しておかない限り、検証済みのクローラーもブロックされます。2026-10-08 に行った当社のルックアップでは、AWS 上の CCBot のスコアは 0（allow）、本物の Googlebot のスコアも 0（allow）で、どちらもホスティングネットワーク上にありました。ごく普通の Linode サーバーのスコアは 10 でやはり allow なので、スコアだけではブロックされません。レジデンシャルプロキシを借りるスクレイパーは、データセンターのブロックを完全にすり抜けます。
IP ルックアップで、その IP がスクレイパーだとわかりますか？
わかりません。ルックアップが教えてくれるのは、ネットワークの種類とリスク、つまり検証済みクローラー、データセンターのサーバー、Tor 出口、VPN のいずれかということです。その IP があなたのサイトをスクレイピングしているかどうかは、ログからわかります。リクエストの頻度、取得するページの順序、アセットを読み込むかどうか、そして User-Agent がルックアップで検証されたクローラーと一致するかどうかです。
スクレイパーがレジデンシャルプロキシを使っているかどうかはどうやってわかりますか？
IP からはわかりません。また、GeoIPHub はレジデンシャルプロキシを検出しません。同じセッションパターンを共有する多数の一般消費者向け IP を探してください。同じページ順序、リクエスト間の同じタイミング、同じ欠落アセット、似通った TLS やデバイスのフィンガープリントなどです。スクレイパーの正体を示すのは個々のアドレスではなく、アドレスをまたぐパターンです。
GeoIPHub API を支えるチーム
GeoIPHub IP インテリジェンス API とそのスキャナーを開発している GeoIPHub チームが執筆しています。下書きは AI の支援を受けて作成し、チームが編集しています。API の例は、「説明用」と明記したものを除き、本番 API に対する実際のルックアップです。
