2026年にサイトはどうやってヘッドレスブラウザを検知するか：CDPリーク、一貫性チェック、そして効くもの

あなたは生の HTTP から本物のブラウザへと移行しました。TLS フィンガープリントは紛れもなく Chrome のもの。IP は住宅用。それでもサイトには見抜かれてしまう。2026 年において、ヘッドレスブラウザ検出は navigator.webdriver をはるか昔に追い越しました — 現世代のチェックは自動化プロトコルそのものを検出し、ほとんどの「ステルス」プラグインは昨日のシグナルにパッチを当てる一方で、今日のシグナルを声高に晒し続けています。

本記事では、サイトが今実際に何をチェックしているのか、おおよそチェックする順番に沿ってマッピングし、各レイヤーで本当に効果のある対策を解説します。JA3/JA4 TLS フィンガープリンティング（ネットワーク層）と IP レピュテーション & ASN（アドレス層）に続き、検出の三部作を完結させるもの — これがブラウザ層です。

Tier 1：定番（解決済み、しかし依然チェックされる）

• navigator.webdriver — 仕様上、自動化下では true であることが必須です。Playwright/Puppeteer のステルス構成はこれを隠し、Chrome の --disable-blink-features=AutomationControlled はネイティブに対処します。無料で素朴なボットを捕まえられるため、サイトは依然としてこれをチェックします。
• ヘッドレス UA 文字列 — User-Agent 内の HeadlessChrome/。本物の Chrome バイナリパスを使う新しいヘッドレスモード（headless=new）で修正されます。
• ブラウザ周辺要素の欠如 — navigator.plugins がゼロ、chrome.runtime が存在しない、outerWidth が 0×0。旧ヘッドレスモードはこれらすべてに失敗しましたが、新ヘッドレスはほぼ通過します。

ターゲットが Tier 1 しかチェックしないなら、headless=new を使った最新の Playwright で通り抜けられます。本気のターゲットは何年も前にこの段階を卒業しています。

Tier 2：CDP 検出 — 2026 年の主力

Playwright と Puppeteer は Chrome DevTools Protocol 経由で Chrome を制御し、CDP はページ JavaScript から観測可能なランタイム上の副作用を残します。

// The classic CDP leak: serialization callbacks
const err = new Error();
Object.defineProperty(err, "stack", {
  get() {
    // This getter fires DURING console serialization -
    // which only happens when DevTools/CDP is attached
    window.__cdp_detected = true;
  },
});
console.debug(err);

このバリエーション — console シリアライズ中のゲッター副作用、Runtime.evaluate のタイミング異常、パッチ済みネイティブ関数に対する toString() の挙動 — は、あらゆる商用アンチボットバンドルに組み込まれています。決定的なポイントは、これがヘッドレスモードではなくプロトコルを検出しているという点です。ヘッド付きで、ステルスパッチが当たり、完璧に人間らしく見える Chrome でも、CDP 経由で制御されていれば検出に失敗します。

効果のある対策：

• パッチ済みランタイム — CDP の副作用をページから観測できない領域へ移す再構築ドライバ（例：patchright、rebrowser-patches）。上流リリースに遅れるため、バージョンを固定し、アップデートのたびに再テストしてください。
• 非 CDP 自動化 — OS レベルの入力やアクセシビリティ API でブラウザを制御するツールは、ページ内にプロトコルの痕跡を残しませんが、速度と API の面で代償を伴います。
• 専用設計のステルスブラウザ — Camoufox（強化版 Firefox）のようなエンジンは Chromium-CDP のチェックを完全に回避します。Firefox の自動化サーフェスは異なり、狙われにくいのです。

Tier 3：環境の一貫性

痕跡を超えて、現代のシステムはあなたのブラウザのストーリーが内部的に整合しているかをチェックします。

チェック項目	ボットの兆候
Canvas / WebGL レンダリングハッシュ	SwiftShader/llvmpipe のソフトウェアレンダリング = サーバー GPU、あるいは「別々の 1 万人のユーザー」で共有されているハッシュ
フォント & コーデック	Windows の User-Agent の下に Linux サーバーのフォントセット
タイムゾーン × ロケール × IP ジオ	Intl は UTC、IP はテキサス、Accept-Language は de-DE と言う
画面メトリクス	タスクバーがゼロの 1920×1080、devicePixelRatio がきっかり 1、ウィンドウが一度もリサイズされていない
ハードウェア並列度 / メモリ	スマホを名乗るページに 96 コアが報告される
行動上のマイクロシグナル	マウスのエントロピーがない、瞬時のフォーム入力、同一の 100px 刻みのスクロール

ここが DIY ステルスの死に場所です。適用するすべてのパッチは、他のあらゆるシグナルと一致しなければなりません。Linux コンテナ上で偽装された Windows UA は、フォント、GPU 文字列、TCP フィンガープリントと同時に矛盾します。一貫性は完璧さに勝ります — 正直なヘッド付き Linux Chrome は、下手に偽装された「Windows」Chrome より高いスコアを得ます。

そして下層も依然として適用される

アドレス層が焼け焦げていれば、これらはすべて無意味です。データセンター ASN 上の完璧なブラウザは、依然として「データセンター内の完璧なブラウザ」に過ぎず — ヘッドレス検出の閾値はIP レピュテーションに適応的です。同じブラウザでも、フラグ付き IP からだとより多くの JavaScript チャレンジを受けます。住宅用の出口は、ブラウザ層が生き残らねばならない精査を実質的に下げます。

browser = p.chromium.launch(
    headless=False,                      # headed survives more checks
    args=["--disable-blink-features=AutomationControlled"],
    proxy={
        "server": "us.jibaoproxy.com:913",
        "username": "USERNAME", "password": "PASSWORD",
    },
)

実践チェックリスト

1. 新ヘッドレスまたはヘッド付きモードを使う。レガシーなヘッドレスは決して使わない。
2. 本気のターゲットでは CDP 検出を前提とする — パッチ済みランタイム、非 CDP ドライバ、または強化された非 Chromium エンジン。
3. ステルスプラグインを盲目的に重ねない。パッチされていない toString() はそれ自体がシグナルです。少数の、一貫したパッチが勝ちます。
4. ストーリー全体を整合させる：タイムゾーン = IP ジオ = ロケール、GPU は名乗る OS に妥当であること。
5. 入力にエントロピーを加える — 曲線的なマウス軌道、可変の遅延、ときどきのスクロールバック。
6. 本番ターゲットの前に、中立的な観測器に対してテストする。

まとめ

• Tier 1（webdriver フラグ、ヘッドレス UA）は最低限の前提 — 新ヘッドレスモードはこれを通過します。
• Tier 2 こそが 2026 年の検出の本拠地です。CDP プロトコルの痕跡は、ヘッド付きでステルスパッチを当てた Chrome すら捕まえます。パッチ済みランタイムまたは非 CDP ドライバを使いましょう。
• Tier 3 は一貫性です。偽装したすべての値が、OS、GPU、フォント、タイムゾーン、IP ジオと一致しなければなりません。
• 検出閾値は IP レピュテーションに適応します — クリーンな住宅用出口はブラウザに余裕を買い与えます。
• 依存関係を更新するたびに経験的に検証しましょう。ステルスは速く腐ります。