ヘッドレスはもはや隠せない
7日前、csideは2026年におけるヘッドレスブラウザ検出に関する技術的な解説を公開した。一貫したテーマは、検出器が現在ピクセルレベルでヘッドレスセッションを捕捉しているということだ。名目上のブラウザやオペレーティングシステムが同じでも、WebGLの出力が異なる。AudioContextのタイミングが異なる。フォントの列挙が異なる。小さなシグナルだが、スコアリングには十分な一貫性がある。
この投稿は、別のアプローチから同じ結論に至ったWebDecoyのBrowser Fingerprinting 2026の解説の1週間後に行われた。今年の初めに公開されたBrowserlessのState of Web Scraping 2026でも、ヘッドレスブラウザはユーザー操作のブラウザよりも頻繁にフラグを立てられ、その差は広がり続けていると明言されている。
本番環境でPuppeteerやPlaywrightを実行している場合、これはコストカーブを変化させる。
実際に何が変わったのか
ヘッドレス検出に関するかつての話は、navigator.webdriver === true、空のプラグイン配列、User-Agent内のHeadlessChromeであった。2020年以降のすべてのステルスプラグインはこれらにパッチを当てている。そのため、検出器はスタックの下位層に移動した。
ソフトウェアレンダリングがその大きな要因だ。ユーザーのブラウザはGPUを使用する。コンテナで実行されるヘッドレス環境は、通常ソフトウェアラスタライザにフォールバックする。WebGLのレンダラー文字列は異なって読み取られる。同じ名目上の入力でもピクセル出力が異なる。同一の入力でもCanvasフィンガープリントが分岐する。これらのどれも真偽値チェックには引っかからないが、確率的スコアに寄与する。
2つ目はAudioContextだ。ページがオーディオコンテキストをインスタンス化し、サンプルレートやチャンネル数を要求すると、ヘッドレス環境は通常のデスクトップセッションとは微妙に異なる値で応答する。同じ操作のタイミングも予測可能な形でずれる。
3つ目はフォントの列挙だ。ユーザーのマシンには過去の履歴によってフォントがインストールされている。コンテナイメージには厳選された(そして少数の)セットがある。フィンガープリントスクリプトが50のフォントにわたって100の一般的な文字列の幅を測定する場合、欠落しているフォントのパターンが診断基準となる。
これらのどれも単体では弱いシグナルだ。しかしこれらをまとめ、検出器が依然としてチェックしている古いシグナルと組み合わせることで、自動化されたセッションとユーザーセッションを十分な精度で分離して対処できるスコアとなる。
なぜ検出器は今投資しているのか
数字がようやく研究開発予算を正当化したからだ。
F5の2026 Advanced Persistent Bot Reportによると、既存のボット対策を適用した後でも、スクレイパートラフィックは世界のWebトラフィックの10.2%を占めている。これは残余である。つまり、防御側が既存のツールでゼロにできない割合だ。この割合を少しずつでも減らすことには価値がある。
Cloudflareは7月13日にPrecursorをリリースしました。Precursorは、クライアント側の継続的な行動シグナル(ポインターの動き、キーボードのタイミング、フォーカス、可視性)を収集し、ページ更新をまたいで持続するbotスコアに反映させます。これについては2週間前に記事にしました。現在、セッションの挙動は1年前のフィンガープリントと同じようにスコアリングされています。
Precursorとheadless特有のシグナルの波は、独立した動きではありません。これらは同じ戦略です。1つのrequestを単独でスコアリングするのはもう終わりです。測定可能なすべての軸で、セッション全体をスコアリングするのです。
実際に支払っている2つの税金
社内でheadlessを実行することは、理論上は常に安価でした。フレームワークは無料、ブラウザも無料、そしてコンテナは安価です。しかし2026年、請求書には記載されない2つの項目が追加されました。
メンテナンス税は、人々が気づくものです。Puppeteer-extra-stealthは、パッチの間に数ヶ月の猶予をもたらしていました。2026年の強固な防御を持つサイトでは、それが数週間になります。headlessの更新、ブラウザの更新、防御の更新、ステルスプラグインの更新の間で、スタックを調整するために1人のエンジニアが月に1週間を費やす可能性があります。誰もそれをロードマップには載せません。それは単にロードマップを食いつぶすだけです。
検出税は、成功率のチャートに隠れているため、人々が気づかないものです。保護されたターゲットでのブロック率は徐々に上昇します。リトライが増加します。成功したフェッチあたりのコストもそれに伴って上昇します。「サイトが難しくなった」と結論づけて先に進むでしょう。その一部は事実です。一部は、あなたのスタックの見え方と通常のブラウザの見え方のギャップが広がっているためです。どちらも同じ傾向を示します。
どちらの税もプロジェクトを破綻させるものではありません。しかし両方が合わさることで、自社開発か購入かの計算が変わります。
データチームにとっての意味
すべてのスクレイピングにブラウザが必要なわけではありません。この部分は変わっていません。しかし、単純なHTTP requestで済むページで多くのheadless展開が始まったため、再度述べる価値があります。
ターゲットのデータがXHRやJSON endpoint経由で来る場合は、ブラウザをスキップしてください。HTTP requestはより安く、より速く、そもそもこれらのフィンガープリントシグナルを一切持ちません。7月のokhlopkovの記事は、正しい順序を示しています。まずAPIとXHR、次に埋め込みJSON、ページが本当に必要とする場合のみブラウザ、そして他のすべてを確認した後にのみLLM抽出を使用します。
ブラウザを必要とするサイトの場合、問題は防御レベルです。軽度の保護(rate limit、User-Agentフィルタ、リファラチェック)の場合、適切に設定されたheadlessスタックは機能し、税金は低いです。重度の保護(Cloudflare、PerimeterX、完全なセッションスコアリングを伴うDataDome)の場合、税金は現実のものであり、複利で増加します。ここで計算が逆転します。
誰も言及しない中間層も存在する。完全にブロックするのではなく、密かに劣化させるサイトである。価格が異なる、リストが少ない、画像がない、レビューがない、などだ。scraperは成功を報告する。しかしデータは静かに間違っている。fingerprintingのスコアがブロックの判定ではなくコンテンツ決定の入力となるにつれて、この障害モードは一般的になりつつある。
自分がその層にいるかどうかわからない場合、おそらくそこにいる。
今後の展開
headlessは、誰も注意深く見ていなかったため10年間機能したハックだった。過去2年間で状況は変わった。検出ベンダーはついに、残存するscraperのシェアを排除する価値があると判断し、自動化を最も分離しやすいレイヤーを選択した。
次の段階は、より賢いステルスpluginについてではない。アクセシビリティツール、古いGPUs、企業proxies、プライベートDNSなど、通常とは異なる設定を持つ正当なユーザーに対する誤検知率に見合う検出精度であると、どのサイトが判断するかになるだろう。彼らがheadless検出の精度を上げるたびに、実際のユーザーの数パーセントの何分の一かが犠牲になる。そのトレードオフこそが、Puppeteerの設定ではなく、軍拡競争が実際に展開される場所である。
すでにheadless税を払っているなら、少なくともそれを測定するべきだ。さもなければ、それは単にあなたが同意した覚えのない条件にすぎない。