まだ1年前、スキームは明確でした：TLSハンドシェイクを偽造できるクライアントを取得し、新しいChromeに合わせたプロファイルを選び、一致するJA4を取得すれば、アンチボットは通過させました。しかし、2026年には、このレシピが失敗を始めました。その理由は「防御を回避する」こととは全く関係がありません。ブラウザは一斉にポスト量子鍵交換に移行しましたが、大多数のスクレイピングスタックはそうではありませんでした。そして、ポスト量子のキーシェアが欠如していること自体が自動化の印となっています。
基準に基づいて分析しましょう：ハンドシェイクで何が変わったのか、どのスタックがすでに移行したのか、どれがそうでないのか、そしてなぜ一致するハッシュJA4が十分な条件でなくなったのか。
何が起こったのか：ポスト量子交換がエキゾチックではなくなった
ハイブリッドポスト量子鍵交換は、古典的な楕円曲線X25519と格子ベースのメカニズムML-KEM（NIST FIPS 203標準）の組み合わせです。セッションは、2つのコンポーネントのうち少なくとも1つが堅牢であれば保護されます。意味は「今すぐキャッチして、後で復号化する」というシナリオからの保護です。トラフィックは、将来の量子コンピュータに備えてアーカイブされます。
クライアントへの導入のタイムライン：
- Chrome 124（2024年4月）— ハイブリッドポスト量子交換がデフォルトで有効；curl-impersonateのパッチには「Chrome 124および130に導入されたX25519Kyber768/X25519MLKEM曲線」と記録されています。
- Firefox 132（2024年11月）— サポートが有効になりました。
- iOSおよびmacOSのSafari — ポスト量子交換は2025年10月に導入されました。
- OpenSSL 3.5.0（2025年4月）— ハイブリッドグループX25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024がTLSのデフォルトグループリストに追加されました。
- Go 1.24（2025年2月）— X25519MLKEM768がcrypto/tlsにデフォルトで含まれます。Config.CurvePreferencesが明示的に指定されていない場合。
インフラストラクチャの観点から見ると、状況はさらに明確です。Cloudflare Radarは2026年4月に、ポスト量子暗号化を使用した約67%の人間のHTTPSトラフィックを示しました — 2025年1月の32%に対して。Akamaiは2026年1月31日にすべてのクライアント接続のデフォルトとしてポスト量子鍵交換を導入し、3月にネットワーク全体での展開を完了しました。業界の測定によると、約57.4%のすべてのブラウザトランザクションはすでにポスト量子対応であり、Chromeの中ではPQに対応できる割合は約93%です。
非対称性に注意してください：オリジンサーバー側のサポートは、はるかに遅く成長しています（Cloudflareでは約9%）。つまり、今日のポスト量子性は主にクライアントの特徴です。まさにアンチボットにとって興味深いものです。
基準1：キーシェアのサイズとClientHelloの構造
ポスト量子キーシェアは「もう一つのフラグではありません」。物理的に大きいです：古典的なX25519の36バイトに対して約1124バイトです。その影響はパケットレベルで明らかに見えます。
ポスト量子キーシェアを持つClientHelloは1400バイトを超え、1つのTCPセグメントに収まらなくなります。2つ以上のパケットに分割されます。そして、検出にとって最も興味深いのは、異なる実装でのフラグメンテーションパターンが異なるということです。スタックが大きなClientHelloをどのように切り分け、セグメントをどの順序で送信し、どのタイミングで行うかは、JA4のハッシュからは導き出せない観察可能な挙動であり、ほとんどのスクレイピングツールの作成者は意識的に再現していません。
実践的な結論：アンチボットには、従来のフィンガープリンティングよりも下層で機能する層が追加されました。暗号と拡張のリストを完璧に集めることができても、スタックがソケットにバイトを配置する方法で自分を示すことになります。
基準2：宣言されたブラウザバージョンとの整合性
2026年の主な罠は、あなたが自分をどのように表現しているかと、実際にあなたのTLSスタックが何をしているかの間の非同期です。
アンチボットプラットフォームは、標準のClientHelloのデータベースを保持しています。User-AgentとJA4でChrome 131を宣言しながら、ポスト量子キーシェアなしで到着するリクエストは、既知の有効なChrome 131のいずれとも一致しません。これは「疑わしい」ではなく、論理的に不可能な組み合わせです。本物のChromeは、そのバージョンでデフォルト設定のままで古典的なキーシェアを送信することは物理的に不可能です。
これが機械学習によってどれほど良く分離されるかも計算されています。JA4の特徴を持つCatBoost分類器は、研究でAUC 0.998と精度0.9863を示しています；ポスト量子トラフィックは古典的なものと約98%の精度で異なります。これは「誤検知のあるヒューリスティック」ではなく、ほぼ決定的な特徴です。
基準3：特定のスタックの準備状況
ここが本当の分かれ道です。グループに分けてみましょう。
デフォルトでPQキーシェアを送信する
- Chrome 124+、Firefox 132+、Safari（2025年10月以降のiOS/macOS） — あなたが比較される基準です。
- Go 1.24+ — crypto/tlsは、CurvePreferencesをオーバーライドしない限り、自動的にX25519MLKEM768を含みます。重要なニュアンス：ポスト量子性はありますが、素のGoクライアントのJA4は依然としてブラウザのものではありません。「PQ互換だがChromeに似ていない」フィンガープリンティングを得ることになります。
- Node.js 24 — 独自のOpenSSL 3.5を搭載しているため、デフォルトのグループリストにはハイブリッドがすでに含まれています。さらに、node:cryptoにはcrypto.encapsulate()/decapsulate()を介してML-KEMが追加され、sign()/verify()にはML-DSAが追加されました。
リンクされているものに依存する
- Python：requests、aiohttp、httpx — sslモジュールを使用し、それはシステムのOpenSSLを使用します。Ubuntu 24.04では、システムにOpenSSL 3.0.xが存在し、ポスト量子グループはまったくありません。PQを取得するには、OpenSSL 3.5をソースからビルドし、LD_LIBRARY_PATHを介して提供し、おそらくPython自体を再ビルドする必要があります。実際には、典型的なPythonスクレイパーは2026年に古典的なキーシェアを送信し、Akamaiでは異常に見えます。
できるが、正しいプロファイルを選択した場合のみ
- curl_cffi / curl-impersonate — ポスト量子曲線のサポートはフォークにあり、明示的に宣言されています。しかし、ターゲットのリストはchrome99からchrome146（フォークではchrome150まで）に及び、古いプロファイルはその時代のハンドシェイクを再現します。つまり、PQなしです。2年前のガイドからの
impersonate="chrome116"のコピペは、検出への直接的な道です。 - uTLS — 同じ原則：HelloChromeのプロファイル131未満はPQキーシェアを含みません。さらに、2026年のライブラリでは2つのフィンガープリンティングの脆弱性が修正されました：CVE-2026-26995（バージョン1.6.0–1.8.1）およびCVE-2026-27017（1.6.0–1.8.0、GREASE ECHの暗号選択の非同期 — Chromeは決定的に選択し、uTLSのparrotはAESとChaCha20の間でコインを投げていました。これは本物のChromeでは不可能です）。少なくとも1.8.2に更新する必要があります。
共通の結論：ツールは主に追いついています。問題は彼らにあるのではなく、設定がブラウザよりも早く古くなるということです。2024年に理想的だったプロファイルは、今日ではマーカーとして機能します。
5分で自分のスタックを確認する方法
- 自分の実際のクライアントから
https://tls.peet.ws/api/allまたはja4db.comにリクエストを送信します — これらは生のJA3/JA4とClientHelloの解析をJSONで返します。 - 解析結果からsupported_groupsとkey_shareのリストを見つけます。X25519MLKEM768（または古いプロファイルのX25519Kyber768）を探します。そこにx25519/secp256r1だけがある場合は、ポスト量子交換はありません。
- これを自分が表現しているブラウザのバージョンと照らし合わせます。Chrome 131+を宣言していてPQグループが見えない場合、その組み合わせは無効です。プロファイルを修正してください。
- ClientHelloのサイズを確認します。新しいChromeを宣言しているのに1400バイト未満の場合 — それも同じ特徴で、別の側面からのものです。
- 各出口ノードからチェックを実行し、作業マシンだけでなく：企業のゲートウェイやプロバイダーでのSSL検査がハンドシェイクをあなたのために書き換える可能性があります。
プロキシの役割
2つの独立した層を混同しないことが重要です。ポスト量子キーシェアはハンドシェイクに関するものであり、アドレスの評判はネットワークに関するものです。アンチボットはそれらを別々に考え、合算します。
ここから2つの実践的な結論が導かれます。第一に：理想的なレジデンシャルIPは、TLSレベルでPQグループなしでChrome 131を装うリクエストを救うことはありません — サーバーがアドレスを確認する前にあなたは負けます。第二に、逆に：適切に構成されたポスト量子ハンドシェイクは、あなたのセッションの100が悪評のあるデータセンターのサブネットから来ている場合には役に立ちません。両方の層を修正する必要があり、それぞれ異なるツールで修正されます。
タスクに関する実践的な配分：AkamaiやCloudflareの背後で、ハンドシェイクとネットワークの両方を考慮する場合、レジデンシャルプロキシを取得し、同時にターゲットのimpersonateを新しいChromeに引き上げるのが理にかなっています。モバイルアプリやIP評判の重みがTLSの要件よりも高いプラットフォームでは、モバイルプロキシがより多くの利益を得ることが多いです。そして、アンチボットが存在しない独自のAPI、パートナーのエクスポート、内部モニタリングの場合、レジデンシャルに過剰支払いする意味はありません — データセンターのプロキシで十分です。
フィンガープリンティングにゼロから取り組む場合は、基本から始めてください：JA4がどのように機能し、何を含むか。HTTPクライアントではなく完全なブラウザに関する場合、ステルスビルドとその弱点の比較は別途まとめられています — nodriver、Camoufox、Patchrightの2026年の測定。
結論
ポスト量子鍵交換はアンチボットメカニズムとして設計されたわけではありません。それは副次的にそうなりました：ブラウザは迅速かつ大規模に移行し、インフラストラクチャ（Akamaiは2026年1月31日から）をデフォルトにしましたが、スクレイピングスタックは3つのグループに分かれました — すでに移行したもの、システムのOpenSSLに依存するもの、そして新しいプロファイルでのみ機能するものです。
確認は1つの質問に集約されます：あなたのクライアントはX25519MLKEM768を送信し、あなたが表現しているブラウザのバージョンと一致していますか？もしそうでなければ、一致するJA4はあなたを救いません。なぜなら、比較されるのはハッシュではなく、ハンドシェイク全体の形状です：キーシェアのサイズ、TCPセグメントの数、そしてそれらの送信順序です。良いニュースは、ほとんどの場合、これを修正するのはプロファイルとライブラリのバージョンを更新することであり、スクレイパーを再記述することではないということです。