2026年8月25日、Chrome 152がWindows、Mac、Linux、ChromeOS、Androidの安定版チャンネルに登場し、navigator.cpuPerformanceというプロパティをもたらしました。 これは0から4までの数値で、サイトが同期的に読み取ります。許可なしで、計算のサイクルも必要ありません。これは、ビデオ通話やストリーミングのためのヒントとして設計されています：弱いデバイスには240pを背景をぼかさずに、強力なデバイスには1080pをエフェクト付きで提供します。リリースから2週間後、スクレイピング業界は別の話題を議論しています：アンチボットシステムには、ブラウザが動作しているハードウェアに関する安価で安定したシグナルが登場しました。
ブラウザが何を提供するのか
このプロパティは、ギガヘルツやプロセッサのモデルを返すのではなく、「パフォーマンスのティア」を返します。WICGの説明書によると、ティアは4つと0の組み合わせです：
- 0 — デバイスの分類ができなかった;
- 1 — 重いタスクにはほぼ不適;
- 2 — 弱いが動作する;
- 3 — 一般的なシナリオには快適;
- 4 — パフォーマンスが高く、マルチタスクに余裕がある。
仕様はベンダー、モデル名、コア数を開示することを明示的に禁止しており、HTTPSを要求し、プライバシーの目標を設定しています：各ティアはインターネット上の目立つデバイスの割合をカバーする必要があります — 数百の異なるCPUモデルの範囲で、値がオーディエンスを数に絞らないようにするためです。
Chromiumでの実装は、仕様よりも簡単でした。Zyteの分析によると、分類は主に論理コアの数と埋め込まれた昇降テーブルに基づいています：周波数はまったく考慮されていませんが、仕様では許可されています。AMD Ryzen、Intel Gracemontコア、Appleシリコン、Intel Core Ultraは昇格を受け、Intel AtomとCore 2時代のプロセッサは降格されます。粗い関連付けは次のようになります：シングルコアで非常に弱いマシンは最初のティアに、2〜4コアは2番目に、4〜10コアまたは現代の省エネチップは3番目に、8コア以上のCore Ultra、Apple Mシリーズ、10コア以上のすべては4番目に分類されます。
なぜこれは検出シグナルであり、単なるエントロピーのバイトではないのか
その値自体は弱いです：5つの選択肢は約2.3ビットのエントロピーで、インターフェース言語が提供するものよりも少ないです。危険は他の3つのプロパティにあります。
それは無料です。 実際のJS実行速度をタイミングで取得するには、検出スクリプトがプロセッサを数十ミリ秒占有する必要があり、これはプロファイラーで明らかです。ここでは、プロパティの同期読み取りが行われ、コストはゼロ、痕跡もゼロです。
それは安定しています。 値はチェック時のマシンの負荷に依存しません：これはハードウェアのクラスであり、現在の利用状況ではありません。セッション間、再起動、IP変更の間に同じままであり、つまり長寿命のプロファイル識別子の一部として適しています。
それは矛盾がないか確認されます。 これが最も重要です。現代のアンチボットエンジンは、単一のフィールドで禁止することはまれです — 彼らはセット内の内部矛盾を探します。4番目のティアを主張するデバイスは、信頼できるnavigator.hardwareConcurrency、合理的なnavigator.deviceMemory、現代のGPUレンダラーの文字列、JSの実行速度と一致する必要があります。ティア4を提供しながら、ベンチマークをデュアルコアの仮想マシンとして実行するプロファイルは、単純なクロスチェックで捕まります。
別々に、ほぼ完成した境界線が「データセンター対生ユーザー」となります：典型的なクラウドインスタンスは2つのvCPUで誠実に最初のティアを報告し、消費者向けのノートパソコンや電話は3〜4ティアに存在します。安価なVPSでヘッドレスモードで回っているスクレイパーが通常のWindows上のChromeを装っている場合、これは不都合な組み合わせです。
これは常に存在していたhardwareConcurrencyとは何が違うのか
合理的な質問：サイトは以前からnavigator.hardwareConcurrencyを介してコア数を読み取っており、メモリ容量はnavigator.deviceMemoryを介して読み取っていました。何が変わったのですか？
関連性が変わりました。hardwareConcurrencyは生の数値であり、長い間どこでも置き換えられています：32の代わりに8を設定すれば、問題は解決します。cpuPerformanceは、ブラウザ自体によって埋め込まれたテーブルに基づいて計算された派生量です。セットに2つのフィールドが存在する場合、そのうちの1つが他から計算されると、いかなる一方向の修正もそれらの間の関連性を破ります。4つのコアを設定したが、ティアは4のまま — 実装の論理によれば、その組み合わせはAppleシリコン、Core Ultra、または10コアを必要とします；したがって、コア数が間違っているか、GPUの文字列が間違っているか、検出器は不一致の事実に気づくだけで、どこが嘘であるかを明らかにする必要はありません。
まさにそのため、古いチェックリスト「プロファイルのどのフィールドを置き換えるか」は、1つの項目ではなく、全体のブロックで時代遅れになります：今や正しい質問は「何を置き換えるか」ではなく、「私たちが得られる矛盾のないハードウェア構成は何か」です。
これが最も影響を受けるのは誰か
Chromium専用 — これは軽減要因ではありません。このAPIに対してWebKitは「反対」の立場を取り、Mozillaは公の立場を表明していないため、SafariやFirefoxではこのプロパティはおそらく存在しません。しかし、プロダクションの自動化の大部分 — Playwright、Puppeteer、nodriver、Patchright、エージェントブラウザ — はまさにChromiumに基づいています。つまり、シグナルは最も期待されていないニッチに届きます。
最も痛手となるのはモバイルプロファイルのエミュレーションです。アンチデテクトプロファイルがAndroidスマートフォンを装い、cpuPerformanceが「4」と応答する場合、ブラウザが物理的にRyzenのデスクトップで実行されているため、これは小さな不正確さではなく、相互排他的なシグナルのペアです。同様に、同じホストマシン上で異なる「デバイス」を持つ数十のプロファイルが存在し、同じティアを提供するファームシナリオでも同様です。
これがパーシングスタックに何を変えるのか
ヘッドレスブラウザを一度に大量に実行する人々にとってのいくつかの実用的な結果です。
- コンテナはホストを継承します。 Docker内のブラウザはホストマシンのコアを見ており、cgroupの制限ではありません — つまり、1つの太いサーバー上の10のコンテナは、10の同じ最大ティアを提供します。ユーザーエージェントで一生懸命描いたプロファイルの多様性は、ハードウェアレベルでは存在しません。
- 安価なVPSがより目立つようになりました。 2つのvCPUは最初のティアであり、デスクトップChromeの最初のティアは生の人々にはあまり見られませんでした。以前は弱いサーバーは単に遅かったですが、今ではそれにラベルが付けられています。
- サイトにとってシグナルは無料です。 タイミングベンチマークのような重いチェックは、ユーザーの時間を要するため、選択的にサイトに組み込まれています。プロパティの読み取りはコストがかからないため、以前はIPの評判やヘッダーに制限されていたサイトでも基本セットに追加されるでしょう。
- それはCompute Pressureの隣に置かれます。 Chromeのリリースノートでは、新しいAPIをCompute Pressure APIと組み合わせることを直接提案しています — つまり、「ハードウェアクラスと観察された負荷」の組み合わせは、最初から標準的なシナリオとして考えられており、アンチボットは何も発明する必要がありません。
一度「良い」プロファイルを収集して何年も再利用するだけで十分だという仮定を再考する必要があります。ブラウザは最終ユーザー向けに発表なしにこれらのプロパティを追加します：Chrome 152のリリースと最初の公の分析の間には数週間があり、その間プロファイルは何も知らずに新しいフィールドを提供していました。フィールドのセットを確認するのは、年に一度ではなく、リリースサイクルごとに行うのが理にかなっています。
実際に何をすべきか
- 現在の値を取得してください。 プロファイルのコンソールで：
navigator.cpuPerformance、navigator.hardwareConcurrency、navigator.deviceMemory、およびWebGLレンダラーの文字列。フィールドを1つずつではなく、4つまとめて記録してください — あなたはまさにその組み合わせでチェックされます。 - ティアをプロファイルの伝説と照らし合わせてください。 モバイル伝説は最初から3ティア、予算ノートパソコンは2〜3ティア、フラッグシップデスクトップは4ティアです。ティア4を古いAndroidのふりをしている場合や、ティア1をMシリーズのMacBookのふりをしている場合は、同様に疑わしいです。
- プロパティを直接修正しないでください。
Object.definePropertyを介した置き換えは、ゲッターの再定義の痕跡や実際の実行速度との不一致によって捕まります。変更する場合は、ブラウザのビルドレベルまたは組み込みメカニズムを介して行ってください。 - 合法的なオーバーライドを覚えておいてください。 Chromeはユーザーに設定で手を提供します（パフォーマンス → スピード → CPUパフォーマンスティアのオーバーライド）、管理者には企業ポリシーを提供します。これは両方の側面で知っておくと便利です：値は「本物」であるだけでなく、手動で設定されたものでもあり、プロファイルのプールで一様なオーバーライドは自体がラベルになります。
- プロファイルを異なるハードウェアに分散させてください。 すべてのプロファイルが同じサーバーに存在する場合、ティアは同じになります — それらがどのデバイスを装っているかに関係なく。これは、異なる構成の複数のマシンのパークが問題を誠実に解決する場合であり、パッチでは解決できません。
同じファミリーの隣接シグナルについては、デバイスメモリの量に基づくフィンガープリンティングの分析を、これらのプロパティを標準で使用するステルスブラウザについては、nodriver、Camoufox、Patchrightのベンチマークを参照してください。
ここでのプロキシは何か
率直に言って、プロキシはブラウザのフィンガープリンティングを修正しません。cpuPerformanceはクライアント側で計算され、どのIPもそれを変更することはありません。しかし、アンチボットはレイヤーの合計に基づいて決定を下し、通常、レイヤーの接続点で失敗が発生します。
典型的な安価なセットアップが崩れるチェーンは次のようになります：知られたホスティングネットワークからのIP、プロセッサの最初のティア、JSのヘッドレスの兆候 — それぞれが独立したシグナルであり、単独では許容されますが、組み合わせると明確な判決に至ります。この合計からネットワークレイヤーを取り除く方が、ブラウザフィールドと戦うよりも安価で信頼性があります：レジデンシャルIPからのリクエストは、通常の家庭プロバイダーのトラフィックのように見え、「データセンター」の仮説は検出器から自動的に排除されます。モバイル伝説についても同様の論理が適用されます — モバイルプロキシはモバイルプロファイルをサポートする必要があり、そうでなければ矛盾はプロセッサからネットワークに移動するだけです。
要約
Chrome 152は、新しいフィンガープリンティングを追加したというよりも、クロスチェックのテーブルに新しい行を追加しました。2ビット強のエントロピーは自体では誰も明らかにしません — 明らかにするのは不一致です：主張されたデバイスは、プロセッサのクラス、メモリ容量、グラフィックカード、実行速度、リクエストが来たネットワークと一致する必要があります。今週のプロファイル監査は、コンソールの1行と「このハードウェアは本当に私たちが主張するものと一致するのか？」という質問から始めるべきです。