- Published on
訪問者統計ではトラフィックの0.5パーセントしか見えない — ボット対策は自己申告ではなく出自で行う
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに — ダッシュボードに見えない99パーセント
- JavaScriptの分析ツールはボットを数えられない
- クロールあたりの流入比率 — 判断をひとつの数字に圧縮する
- 公開された比率と自分のサイトの比率が違う理由
- 自己申告を信じる規則と出自を見る規則
- 住宅用IPのボットネットの前では出自の規則も無力になる
- 防御機構そのもののコストを測れ
- 作業証明は何を解決し、何を解決しないのか
- 参考資料
はじめに — ダッシュボードに見えない99パーセント
2026年8月7日、PatronViewというサイトの運営者が1年間のスクレイパー防御記録を公開しました。米国の慈善寄付者データベースで、IRSの990書類と公開寄付者名簿をもとに作った個人プロフィールページが150万件あります。
記事が公開された週、サーバーは外部からリクエストを250万件受け取り、完全なページを128万件配信しました。ところが訪問者統計にはページビューが5,977件しか記録されていませんでした。
見えるページロード1件につき、見えないものが約214件あったということです。
ここで学ぶべきはボットが多いという事実ではありません。ボットが多いことは誰でも知っています。学ぶべきは、あなたがいま見ている指標がこの状況を構造的に見せられないという点です。
JavaScriptの分析ツールはボットを数えられない
原因は単純です。Plausible、Fathom、Google Analyticsを含め、クライアントサイドの分析ツールはJavaScriptを実行する訪問者だけを数えます。ほとんどのボットはJavaScriptを実行しません。
だからダッシュボードは一日の訪問者500人ほどのこぢんまりしたサイトを見せ、サーバーは毎週数百万件に応答します。二つの数字はどちらも本当です。互いに違うものを数えているだけです。
実務的な結論はひとつです。ボットトラフィックを判断するときは、分析ツールではなくサーバーログやエッジログを見るべきです。 そしてこの二つの差を定期的に確認してください。差が開き始めた時点が、何かが始まった時点です。
原文の最初のボット検知の事例が、まさにそういう形でした。2025年11月、数日にわたって4,000人の「訪問者」が現れました。それぞれちょうど1ページだけを見て、直帰率99パーセント、リファラーなし。そして実際の訪問者の10パーセントしか見ない特定の種類のページだけをなぞっていました。
これらの信号はどれ一つとして決定的ではありませんが、揃って現れれば明確です。そしてこれらの信号は分析ツールでも見られるものでした。JavaScriptを実行するボットだったからです。
クロールあたりの流入比率 — 判断をひとつの数字に圧縮する
原文でもっとも実用的な部分は、著者が落ち着いた指標です。クローラーがページを何件読むごとに訪問者を一人送ってくれるのか。
著者が測定した値はこうです。
| クローラー | クロール数あたり流入訪問者1人 |
|---|---|
| Googlebot | 46対1 |
| Bingbot | 406対1 |
| Claude-SearchBot | 35,000対1 |
| Amzn-SearchBot | 流入なし |
Claude側の根拠は具体的です。ある一週間にClaude-SearchBotが420,680ページを要求し、同じ週に、実際の人がページを要求するときに使われる別のユーザーエージェントであるClaude-Userを通じて入ってきた訪問者は12人でした。帯域で見るとボットに4.63GB、そのボットが送ってくれた人たちに175KBです。
Amazon側は一日およそ117,000件でその時点の首位クローラーでしたが、訪問者は一人も送りませんでした。
この指標の良いところは、方針の判断を道徳ではなく算数にすることです。「AIクローラーは悪い」ではなく「このクローラーは私の帯域を使って何も返さない」です。Bingbotは406対1でGoogleより九倍悪いけれど流入が実際に増えているので許可を続ける、と著者は書いています。同じ基準を当てはめて結論が分かれることが、良い基準である証拠です。
遮断後の観察も記録しておく価値があります。Claude-SearchBotをファイアウォールで止めると、一日6万件だったリクエストが一日25件程度の試行にまで落ちました。著者の表現で「行儀のよいAI企業は本当に403を受け入れます」。
公開された比率と自分のサイトの比率が違う理由
著者は「CloudflareはAnthropicのクローラーをクロール約3,000件あたり訪問者1人程度と述べた」と引用しつつ、自分のサイトでは35,000対1を測定したと書いています。
この二つの数字が違う理由を知っておくことが重要です。
Cloudflareがこの指標を最初に公開した記事は2025年7月1日付で、計算方法を明示しています。当該プラットフォームに関連するユーザーエージェントから来たリクエストのうち、応答のコンテンツタイプがHTMLだったものの総和を、そのプラットフォームから来た流入トラフィックで割った値です。当時、2025年6月19日から26日までの区間でAnthropicは70,900対1と報告されました。
同じ記事に、Cloudflare自身が付けた但し書きがあります。Claudeのネイティブアプリが送る流入トラフィックにはリファラーヘッダーがなく、他のネイティブアプリも同様である可能性が高いということです。だから自分たちの計算が「その比率を過大評価している可能性があり、どの程度かは不明である」と書いています。
ここから三つのことが導かれます。
第一に、この比率は時点によって大きく動きます。70,900、3,000、35,000はすべて別の時点、別の母集団の値です。どれか一つを「AIクローラーの比率」として引用すれば間違いになります。
第二に、集計値より自分のサイトの値のほうが重要です。あなたのサイトのコンテンツの性格、地理的な読者層、インデックス状況によって値は大きく変わります。
第三に、リファラーヘッダーのない流入は過小に数えられます。つまり実際の比率は測定値より有利な側にあるかもしれません。遮断の判断を下す前に、この限界を知っておく必要があります。
自己申告を信じる規則と出自を見る規則
原文の付録には実際のファイアウォール規則の式がすべて公開されています。規則一つひとつより重要なのは、どういう性質の情報に依存しているかです。
自己申告の値に依存する規則があります。ユーザーエージェント文字列が代表的です。
(lower(http.user_agent) contains "semrushbot") or
(lower(http.user_agent) contains "ahrefsbot") or
(lower(http.user_agent) contains "mj12bot")
こういう規則は正直なクローラーにしか効きません。著者もSEOクローラーについて、正直に自分を名乗ってくれる、ありがたいことだ、と書いています。嘘をつく側にはまったく効果がありません。
出自の情報に依存する規則は違います。IPがどの国から来たのか、どのASNに属するのかは、リクエストを送る側が勝手に決められません。
((ip.src.asnum in {212238 139341 9009}) or
(ip.src.continent in {"AF" "AN" "AS" "OC" "SA" "T1" "EU"}))
and not cf.client.bot
and not (ip.src.country in {"GU" "AS" "MP"})
著者がもっとも長く持ちこたえた規則二つは、どちらもこの性質です。北米以外の大陸にチャレンジを掛け、大規模クラウドのASN 46件にチャレンジを掛けます。実際の読者が97パーセント北米であり、人はAWS us-east-1のIPからウェブを見ないからです。遮断ではなくチャレンジなのは、クラウドデスクトップやVPNを使う人が中にいる可能性があるからです。
三つ目の種類が暗号学的な検証です。CloudflareはGooglebot、Bingbot、Applebotの身元を検証し、規則からは cf.client.bot で参照します。著者が指摘する順序が要領です。この迂回規則を遮断規則の後ろに置けば、自分が止めると決めた検証済みボットは止まったまま、Googleにはチャレンジが絶対に飛びません。
規則を設計するときは、いつもこの問いを先に立ててください。この規則が参照する値を、相手が勝手に変えられるか。 変えられるなら、その規則の寿命は相手が気にし始める日までです。
住宅用IPのボットネットの前では出自の規則も無力になる
ところが出自ベースの規則にも限界があり、原文はその限界に正確にぶつかります。
2026年7月、新しい波が米国から来ました。オハイオのある家庭、Spectrumの回線から来ます。大陸の規則も通り抜け、データセンターの規則も通り抜けます。どちらもこのトラフィックをそのまま通してしまいます。7月31日は一日のユニークIPが124,000件まで上がり、平常時の基準線は約18,000件でした。
住宅用プロキシネットワークの定義上そうなります。何千もの実在する家庭のインターネット回線をリクエスト単位で借りて使うので、すべてのリクエストが本物の人間の回線から出てきます。著者の結論が正確です。ネットワーク層でこれらを止めるのは設計上不可能です。
この波に対して著者が見つけた対応は、少し違う軸でした。同じボットネットがChrome 118から120のふりをしていたのです。2023年のブラウザバージョンがスクレイピングのツールキットの中にそのまま固まっていたわけです。
そこで古いブラウザにチャレンジを掛けます。Chrome 100から130まで、そして古いFirefox。先に実際のトラフィックを確認したところ、実際の検索流入訪問者のうちそこまで古いブラウザを使う割合は0.54パーセントで、そのほとんどがFirefox 115 ESRだったので、それだけ例外扱いにしました。
この規則も結局は自己申告の値、つまりユーザーエージェントに依存します。相手が文字列をひとつ直せば無力になります。著者もそれを分かったうえで、自分の好きな間抜けな規則だと呼んでいます。要点はこれです。自己申告に依存する規則を使うなら、まずその規則が実際のユーザーの何パーセントを叩くのかを測ってから使ってください。
防御機構そのもののコストを測れ
この記事でもっとも予想外で、もっとも広く当てはまる教訓がここにあります。
Cloudflareの「JavaScript Detections」機能が、一年じゅうすべてのページに検証スクリプトを注入していました。著者はサイトの速度を改善しようとしていて、これを見つけました。
そのスクリプトは中位スペックの携帯電話で2,875ミリ秒を使っていました。サイト自体のJavaScript全体が278ミリ秒でした。モバイルのLighthouseスコアが58点だった最大の理由であり、しかも使用中の料金プランではその判定結果をファイアウォール規則から読むことすらできませんでした。誰も読めない計測のために性能を40点払っていたわけです。
8月5日にこの機能を切ると、一時間以内にLighthouseスコアは99になりました。
そして五時間後、Azureのスクレイパーが一時間で23,000ページを持っていきました。80を超えるIPを動員し、それぞれおとなしくレート制限の下に留まりながらです。つまりその機能は実際に仕事をしていました。
この話の教訓は「切るな」でも「入れろ」でもありません。防御機構のコストを測ったことがあるかです。ボット対策の機能はたいてい「オン」のトグルとして提供され、一度入れたら誰も見返しません。その間、その機能はあなたの性能予算とユーザー体験から料金を取り続けます。
測定可能な形で運用する要領も原文にあります。遮断の代わりにチャレンジを使えば、通過率が残ります。著者の48時間の区間では、チャレンジ106,437件のうち252件が通過し、通過率は0.24パーセントでした。著者の判断基準は明確です。通過率0.2パーセントならボットなので規則を維持し、通過率30パーセントなら人に税金を課しているということなので規則を直します。
作業証明は何を解決し、何を解決しないのか
この記事のHacker Newsの議論でもっとも密度が高かった論争が、Anubisのような作業証明方式についてのものでした。両方の主張をそのまま移す価値があります。
批判側はこうです。Anubisのチャレンジは、チャレンジ文字列の後ろにノンスを付けてSHA-256ハッシュを求める形ですが、ノンスが後ろに来るため前半部分の圧縮ラウンドをキャッシュできます。ビットコイン採掘で使う中間状態の再利用手法がそのまま通用します。ノンスを前に置いていれば避けられた問題だという指摘です。だからネイティブコードのソルバーはブラウザのJavaScriptより数千倍速く、ブラウザで10分かかる難易度をミリ秒単位で解きます。
擁護側の反論は経験的です。迂回が可能なことと実際に迂回することは違います。専用のスクレイパーならはるかに効率よく迂回できますが、ほとんど誰もそうしません。大半のボットはあなたを狙い撃ちしているのではなく、低コストで大量に集めたいだけだからです。
Anubisのメンテナーも議論に参加して、次のリリース以降にWASMソルバー機能を準備中であり、古いスマートTVのブラウザまで検証するのに時間がかかっていると明かしました。
まとめると作業証明は、人とボットを区別する装置ではなく、大量収集の単価を上げる装置です。そう理解すれば評価基準も明確になります。あなたを標的にした相手にはあまり効かず、無差別な収集にはよく効きます。そしてJavaScriptの実行を強制するので、テキストブラウザの利用者や遅い回線の利用者には実質的なコストになります。
著者本人の結論も技術ではなく経済です。スクレイピングが悪化し続ける理由は安くなり続けるからであり、本当の解法はクロールあたり課金のような市場だということです。その市場ができるまで、著者の規則は一文です。訪問者を一人も送ってくれないクローラーは止める。
参考資料
- 99% of My Website Traffic Is Bots — PatronView, Nick Gray, 2026-08-07（数値と規則の式はすべてこの記事から移したものです）
- The crawl before the fall of referrals — Cloudflare Blog, 2025-07-01（クロールあたり流入比率の定義とCloudflare自身の但し書き）
- Hacker Newsの議論スレッド（作業証明の論争の出典）
- Anubis
この記事の数値は個別サイト一か所の実測値であり、サイトの性格と読者層によって大きく変わります。私が直接再現した値ではありません。