TLS handshakeはbot検出の最低ライン
98.6%。
これは、JA4の機能のみを使用したCatBoostモデルが達成した分類精度です。headerも、IPも、挙動も関係ありません。TLS handshakeの形状のみです。arXivの論文が2026年2月に公開されましたが、この結果は例外的なものではありません。Cloudflare、AWS、VirusTotal、Akamaiはすべて、本番環境でJA4（またはその前身であるJA3）を実行しています。2026年に通常のHTTPクライアントでスクレイピングを行っている場合、requestがアプリケーション層に到達する前に判定は下されています。
これは、bot検出のチュートリアルが省略している部分です。アンチbot回避に関するほとんどの投稿は、依然としてUser-Agentのローテーション、cookie、CAPTCHAを中心に展開しています。これらは簡単なレイヤーです。しかし、TLSレイヤーはheaderでごまかすことができないレイヤーです。
JA4が実際に見ているもの
JA4は、TLS ClientHelloのfingerprintです。プロトコル（TCPまたはQUIC）、TLSバージョン、SNIの有無、ソートされた暗号スイート、拡張機能、署名アルゴリズム、ALPNをエンコードします。出力は、t13d1516h2_8daaf6152771_e5627906d626のようなコンパクトな文字列になります。同じブラウザであると主張する2つのクライアントは、同じJA4ハッシュを生成します。Chromeであると主張するPythonのrequestsスクリプトは、スクレイパー以外には世界中のどこにも存在しないJA4を生成します。
JA4ファミリー（JA3の開発元と同じFoxIOによって開発）は、JA3の最大の弱点であった拡張機能の順列（Chromiumが単純なfingerprintingを無効化するために2023年に導入したもの）に対処しました。JA4は拡張機能をソートしてカウントするため、ランダム化は効果がありません。簡単な逃げ道はありません。
Akamaiは、クロスレイヤー分析によって92〜98%のbot分類精度を明らかにしました。このクロスレイヤーの部分が重要です。TLS単体でも支配的なシグナルですが、それをHTTP/2フレームの順序、headerの順序、requestのタイミングと組み合わせることで、誤検知率はほとんどのスクレイパーが許容できるレベルを大幅に下回ります。
ポスト量子TLSによる急展開
これは誰も予想していなかった展開です。2026年1月31日、Akamaiはすべての接続でポスト量子鍵交換をデフォルトにしました。2026年初頭までに、実際のブラウザから開始される接続の57.4%にX25519MLKEM768鍵共有が含まれています。ChromeのPQ対応シェアは約93%に達しています。Firefox 132は85%です。Safariも順次展開しています。
PQ鍵共有は巨大です。従来のX25519の36バイトに対して、1,124バイトあります。ClientHelloは300〜500バイトから1,400バイト以上に肥大化しました。この増加は、JA4、パケットキャプチャ、およびWAFでのパッシブ監視に現れます。
スクレイピングクライアントにPQ鍵共有が含まれていない場合、現在のChromeやFirefoxではあり得ない主張をしていることになります。2026年第1四半期の2つのCVEは、まさにこの不一致を指摘しています。CVE-2026-26995（パディング拡張）はrequestあたり25〜50%の検出確率をもたらし、CVE-2026-27017（ECHとGREASEの不一致）は約50%に達します。セッション全体で組み合わせると、検出される確率はほぼ確実になります。
これは、12ヶ月のスパンだった問題が3ヶ月の問題に縮小していることを意味します。ほとんどのオープンソースのスクレイピングスタックは、まだPQ対応のTLSをリリースしていません。対応しているものであっても、実際のChromiumから数週間遅れています。
proxyがこれを解決できない理由
より大きなproxyプールが現代のbot検出を解決するという、都合の良い話が広まっています。しかし、解決にはなりません。Security Boulevardが報じた2026年1月の買い占め（スキャルピング）事案では、390万のユニークIPにわたって1,600万のrequestが使用されました。IPごとのブロックは役に立ちませんでした。効果のあった防御策は、主にTLSと挙動のfingerprintingでした。
レジデンシャルproxyの経済性も、今四半期に崩壊しました。Help Net Securityの2026年4月の報道によると、1月にIPIDEAネットワークが停止したことで、業界のレジデンシャル容量が一夜にして約40%減少しました。Bright DataとOxylabsの特許紛争（最高裁判所は2026年2月23日にBright Dataの申し立てを却下し、公判は5月18日に設定）は、その容量減少の打撃に比べれば些細な出来事です。fingerprinting対策としてレジデンシャルIPを追い求めているバイヤーは、WAFが気にも留めない解決策に対して、より多くの費用を支払っていることになります。
proxyは依然として重要ですが、それは多くの人が考えている理由からではありません。地理的な分散とISPタイプは、ルーティングの決定やrate limitのプロファイルを形成します。しかし、handshakeを突破する役には立ちません。
データチームにとっての意味
2026年にスクレイピングインフラを構築または購入する場合、3つの変化が生じます。
第一に、TLSスタックが必須要件になりました。実際のブラウザのTLS handshake（PQ鍵共有、拡張機能の順序、ALPN、署名アルゴリズム）を偽装しないクライアントは、高い確度でbotとして分類されるfingerprintを生成します。Pythonのrequestsをより優れたheaderでラップしても、何も解決しません。トランスポート層こそが、正体を暴く手がかりなのです。
第二に、headlessブラウザの検出は改善されるどころか、さらに厳しくなりました。Browserlessの「State of Web Scraping 2026」は、headlessと通常のChromiumの間のギャップが広がっていると報告しています。アンチbotベンダーはfingerprintの違いをカタログ化し、顧客サイト間で脅威インテリジェンスをほぼリアルタイムで共有しています。12月に動作していたheadlessインスタンスが、5月にはbotとして分類される可能性があります。挙動シグナルはTLSの上に積み重なり、その両方が常に変化するターゲットです。
第三に、自社構築か外部購入かの判断基準（build-vs-buy）が変化しました。変化し続けるターゲット（Chromiumは数週間ごとにPQアップデートをリリースし、マイナーバージョン間で拡張機能の順序が変わり、暗号スイートの優先順位がシフトする）に一致するTLS fingerprintを維持することは、今や専任の仕事です。2024年にエンジニアのリソースの20%をスクレイパーのメンテナンスに費やしていたチームは、2026年には半人分以上の工数を費やしています。私たちは以前、スクレイパーが壊れ続ける理由について執筆しました。2026年において、その答えは「DOM」よりも「TLS」であることの方が多くなっています。
最も安価なスクレイパーは、分類（検出）されないスクレイパーである
興味深い予測は、アンチbotベンダーがハードルを上げ続けるかどうかではありません。彼らは確実にそうするでしょう。興味深い予測は、98%の精度が最低限の検出基準である市場において、どのスクレイピングツールが生き残るかということです。
ほとんどは生き残れません。しかし、生き残るツールは、TLS handshakeをトランスポートの詳細としてではなく、requestの一部として扱うでしょう。そしてバイヤーは、12ヶ月前の評価チェックリストにはなかった質問をベンダーに投げかけ始めるでしょう。「どのようなTLS fingerprintを提供しているのか、そしてどのくらいの頻度でアップデートしているのか？」
requestがその主張を通す機会を得る前に、handshakeによって勝負は決しているのです。