2026年9月7日、CipherCueの研究者たちは、ヨーロッパのウェブを自動化しているすべての人が読むべき測定結果を発表しました。44,143のヨーロッパ企業の中で、CDNを検出できた企業は89.6%がCloudflareを利用しているという結果でした。「市場のリーダーが大きくリードしている」というわけではなく、ほぼ市場全体がそうです。スクレイピング、マルチアカウント、そしてあらゆる自動化にとって、これは簡単なことを意味します：EU内の10のサイトのうち9つにアクセスするためには、同じアルゴリズムが同じ基準で、同じ瞬間に働いています。
具体的に何を計算したのか
サンプルは、ドイツ、イギリス、オランダ、ポーランド、フランス、イタリア、スペイン、アイルランドの企業で、ウェブサイトに少なくとも1つのCDNコンポーネントが確認された企業です。検出はHTTPレスポンスとサーバーフィンガープリンティングに基づいて行われました：Cloudflareの場合はcf-rayヘッダーとserver: cloudflare、Fastlyの場合はキャッシュマーカー付きのx-served-by、CloudFrontの場合はx-amz-cf-idです。観測日付は2026年9月7日です。
プロバイダー別の内訳は以下の通りです：
- Cloudflare — 39,547社（89.6%）
- Amazon CloudFront — 3,112
- Fastly — 1,299
- Akamai — 396
国別の分布は顕著ですが、どこも高い上限があります：
- オランダ — 95.6%（7,587社中7,939社）
- イギリス — 93.2%（15,846社中17,007社）
- ポーランド — 92.6%（2,682社中2,896社）
- フランス — 86.2%（3,456社中4,008社）
- イタリア — 85.4%（3,126社中3,661社）
- ドイツ — 81.4%（4,650社中5,715社）
- スペインとアイルランド — それぞれ78.8%
著者たちは自ら制限を明記しており、これは正直なことです：1つの企業が複数のプロバイダーに該当する可能性があり（重複カウント）、サンプルは中小企業に偏っているため、Cloudflareの無料プランが最も強力です。つまり、89.6%は検出されたCDNを持つ企業の中での割合であり、すべてのヨーロッパ法人の中での割合ではありません。
独立した規模の確認があります：2026年9月のW3Techsのデータによると、Cloudflareを使用しているのはリバースプロキシが知られているサイトの84.7%であり、これは彼らのインデックス内のすべてのサイトの25.2%に相当します。異なる手法、異なるサンプルですが、結論は一つです：ウェブの4分の1と圧倒的多数の認識可能なCDNインストールの前には、1つの仲介者が立っています。
なぜ自動化にとってこれは「単なる市場シェア」ではないのか
フィルターが多いと、1つのフィンガープリンティングの誤りが1つのサイトへのアクセスを失うことになります。フィルターが実質的に1つだけの場合、誤りは全セグメントへのアクセスを失うことになり、これは作業の経済性を変えます。
Cloudflareはリクエストに対して1から99までのボットスコアを提示します：スコアが低いほど、サイトの前に自動化がいる可能性が高いということです。このスコアを計算するモデルは、同社の説明によれば毎秒4600万以上のHTTPリクエストを処理し、あなたの具体的なリクエストだけでなく、ネットワーク全体のグローバルな統計も考慮します：IPの評判、ASN、アドレスの種類（データセンター/居住者/モバイル）、ヘッダーの一貫性、TLSフィンガープリンティング、行動的特徴です。検出は層状であり、ヒューリスティックと機械学習が組み合わさっており、機械学習が決定の大部分を占めています。
実際の結果：あなたのプールとフィンガープリンティングはサイトではなくネットワークによって評価されます。1つのリソースでバレた場合、次の別のリクエストの際には評判シグナルがすでに考慮されています。このネットワークに9つのヨーロッパのサイトが存在する世界では、「別のターゲットに切り替えてやり過ごす」ことは戦略として成り立たなくなります。
居住者IPはもはや免罪符ではない
「居住者アドレスを取得すれば人間として通過できる」という古い論理は、フィルタープロバイダーがこの手法をすでにキャッチしているという事実にぶつかります。Cloudflareは居住者プロキシを通過するボットに対抗するための別のモデルを公に説明しました：最初はネットワークの特徴（余分なホップ、レイテンシ）を試みましたが、衛星インターネットでの誤検知のために断念し、行動分析に移行しました — IPアドレスの活動の特徴的な急増です。彼らの発表には、彼らが見ている現象の規模が示されています：居住者プロキシを通じて攻撃に関与する1700万のユニークIPが毎時、45,000のASN、237の国と地域（数字は2024年3月に関するもので、より新しいデータは提供されていません）。顧客の1人に対する分散攻撃の分類精度は95%とされ、クラウドネットワークからのボット検出の増加は20%です。
そこからの重要な詳細：モデルは意図的にIPのブロックに基づいて構築されていません — 同じネットワークの生きたユーザーを排除しないためです。これは、居住者アドレスからの正当なトラフィックにとっては良いニュースですが、「自宅」が自動的に緑の信号を出すと期待している人々にとっては悪いニュースです。機能するのはアドレスのタイプではなく、「アドレスのタイプ + 行動 + フィンガープリンティング」の組み合わせです。壁の違いについての詳細な分析は、Cloudflare、DataDome、Akamai、Kasadaのアンチボットシステムの比較で行いました — 現在は、ヨーロッパの最初の行における重みが不均衡に増えたことを考慮して再度確認する必要があります。
裏側：1つが落ちるとすべてが落ちる
モノカルチャーには、ブロックではなく可用性に関するもう一つの側面があります。過去1年半で、3つの顕著なエピソードがありました：
- 2025年11月18日 — グローバルな障害が発生し、推定で約5分の1のウェブページと10,000の最も人気のあるサイトとサービスの3分の1に影響を及ぼしました。原因は、同社の分析によれば、ClickHouseクラスターの権限変更がMLモデルのために使用される特徴ファイル内の行の重複を引き起こしたことです。皮肉なことに、人間かどうかを決定するメカニズムがインターネットのかなりの部分をダウンさせました。
- 2025年12月5日 — UTC 8:47に約25分間の障害が発生し、ネットワークを通じて流れるHTTPトラフィックの約28%を占めるクライアントのサブセットに影響を与えました。
- 2026年2月20日 — UTC 17:48に、BYOIP（自社IP範囲）を使用している一部のクライアントで、アドレスのオンボーディングパイプラインの変更によりBGP経由でルートが撤回されました。
研究者たちの表現は正確です：1つのプロバイダーが市場の大部分を占めると、そのエラーはもはやそのプロバイダーの問題ではなく、すべての人の問題になります。データ収集のパイプラインにとって、これは「ターゲットサイトがダウンした」と「全地域がダウンした」が区別がつかなくなることを意味します — そして、特定のドメインに設定されたアラートは誤報になります。
これに対して実際に何をすべきか
以下は、フィルターのモノカルチャーを前提とした場合に、作業プロセスで実際に変わることです。
- 1つのサイトだけでなく、複数のサイトでテストしてください。 あなたのフィンガープリンティングが3つのリソースで通過する場合、あなたはおそらく同じフィルターを3回確認したことになります。テストセットには、CloudFront、Fastly、AkamaiのリソースとCDNなしのリソースを含めてください。さもなければ、サンプルは何も証明しません。
- プロジェクトごとにプールを分けてください。 評判がネットワークによって評価されるため、「各ドメインごとに別々のプール」は何も隔離しません。隔離はプロジェクトとプロファイルのレベルで意味があります：1つのプロジェクトには独自のアドレスプール、独自のフィンガープリンティングセット、独自のペースがあります。
- アドレスのタイプと出所を確認してください。 ASNとアドレスのカテゴリは、スコアリングへの直接的な入り口です。敏感な目的には、居住者プロキシやモバイルアドレスが意味を持ちます；大量の技術的なタスク（可用性の確認、自社API、厳しいアンチボットのないプラットフォームでの作業）は、データセンター・プロキシを使用して安価で正直に解決する方が良いです。
- サブネットを焼かないでください。 行動モデルはアドレスの活動の急増をキャッチします。広いプールでの均一なペースは、狭いプールからの短い攻撃的なバーストよりもスコアリングに耐えます。
- フィンガープリンティングを全体的に整えてください。 TLSフィンガープリンティング、ヘッダーの順序と構成、HTTPのバージョン、JSの行動は一緒に評価されます。フィンガープリンティングが生のHTTPクライアントの居住者IPは、誠実なブラウザスタックを持つデータセンターアドレスよりも悪い結果をもたらします。
- 「私たちはブロックされた」と「彼らは障害がある」を分けてください。 簡単なルール：エラーが大量に増加した場合、まずは複数の無関係なターゲットが同時にダウンしていないか、プロバイダーのステータスページが何を示しているかを確認してください。グローバルな障害の際にリトライを行うことは、無駄にプールを焼く方法です。
- フィルターがダウンした日に備えてプランBを用意してください。 待機でき、見逃したものを補充できるタスクのキューは、開発にはコストがかかりますが、データ損失なしで25分のダウンタイムに耐えます。
結論
89.6%という数字は、Cloudflareが悪いということでも、ヨーロッパのウェブが閉鎖されたということでもありません。それはターゲットの多様性がもはや障害の多様性を意味しないことを示しています。1つのスコアリング、1つのモデル、1つの評判データベース — そして、その結果、1つの共通の障害モード：あなたがボットと見なされるときも、プロバイダーが自らルートを落とすときも。
実務における結論は退屈ですが、実行可能です：サイトに「最適化する」のをやめ、「行動」を最適化し始めること — アドレスの質、均一なペース、一貫したフィンガープリンティング、障害の正直な診断です。これが89.6%の向こう側でもこちら側でも同様にうまく機能する唯一の方法です。