Headlessはもはや隠蔽できない
7日前、csideが2026年におけるheadlessブラウザ検出に関する技術的な解説を公開しました。要点は、検出エンジンがピクセルレベルでheadlessセッションを捕捉するようになったことです。名目上は同じブラウザ、同じOSであっても、WebGLの出力が異なります。AudioContextのタイミングが異なります。フォントの列挙結果が異なります。個々は小さなシグナルですが、スコア判定を下すには十分な一貫性があります。
その投稿は、別のアプローチから同じ結論に達したWebDecoyのBrowser Fingerprinting 2026レポートの1週間後に公開されました。Browserlessが今年前半に発表したState of Web Scraping 2026でも明言されています。headlessブラウザは人間が操作するブラウザよりもフラグが立ちやすく、その差は広がり続けています。
本番環境でPuppeteerやPlaywrightを運用している場合、この変化はコスト構造に直結します。
実際に何が変わったのか
従来のheadless検出といえば、navigator.webdriver === true、空のplugins配列、User-Agent内のHeadlessChromeなどが中心でした。2020年以降のパッチプラグインはこれらをすべてカバーしています。そのため、検出エンジンはスタックのより下層へと移行しました。
最大の変化はソフトウェアレンダリングです。一般的なユーザーのブラウザはGPUを使用します。一方、コンテナ内で実行されるheadless環境は通常、ソフトウェアラスタライザにフォールバックします。これによりWebGLレンダラー文字列が異なります。名目上同一の入力であってもピクセル出力が異なります。同一入力に対するCanvasフィンガープリントが乖離します。これらはブール値の判定に引っかかるのではなく、確率的スコアに加算されます。
2つ目はAudioContextです。ページがオーディオコンテキストをインスタンス化し、サンプルレートやチャンネル数を要求すると、headless環境は通常のデスクトップセッションとは微妙に異なる値を返します。同一処理におけるタイミングも予測可能な形でズレが生じます。
3つ目はフォントの列挙です。ユーザーのマシンには過去の利用履歴に基づくフォントがインストールされています。コンテナイメージに含まれるフォントは厳選された少数のセットに過ぎません。フィンガープリンティングスクリプトが50種類のフォントで100個の一般的な文字列の幅を計測すると、欠落しているフォントのパターンが決定的な証拠となります。
個々の要素は弱いシグナルに過ぎません。しかし、これらが組み合わさり、さらに検出エンジンが現在もチェックしている従来のシグナルと合算されることで、自動化セッションと通常セッションをアクション可能な高精度で識別するスコアが形成されます。
なぜ検出側は今投資を強化しているのか
数字がR&D予算の正当性を証明したからです。
F5の2026 Advanced Persistent Bot Reportによると、既存のBot対策を適用した後でも、スクレイパーのトラフィックは世界のWebトラフィックの10.2%を占めています。これが残余トラフィックです。防御側が既存のツールではゼロに抑えきれない割合です。このシェアを1ポイントでも削ることに、十分な価値が存在します。
Cloudflareは7月13日にPrecursorをリリースしました。Precursorは継続的なクライアント側の行動シグナル（ポインタの動き、キーボード入力のタイミング、フォーカス、可視性）を収集し、ページの再読み込みを跨いで維持されるボットスコアに反映します。当社が2週間前に書いたとおり、1年前にフィンガープリントがスコア化されていたように、現在はセッション行動がスコア化されています。
Precursorとheadless特有のシグナルの波は個別の動きではありません。同じ戦略です。単一のrequestを個別にスコア化するのをやめ、測定可能なあらゆる軸でセッション全体をスコア化することです。
実際に支払っている2つのコスト
自社でheadlessを運用することは、書類上は常に安価でした。フレームワークは無料で、ブラウザも無料、コンテナも安価です。しかし2026年、請求書には表示されない2つの項目が加わりました。
メンテナンスコストは誰もが気づくものです。puppeteer-extra-plugin-stealthは以前、パッチ適用までに数か月の猶予をもたらしていました。2026年の実効的な防御を備えたサイトでは、その猶予は数週間です。headlessの更新、ブラウザの更新、防御側の更新、プラグインの更新の間で、1人のエンジニアがスタックの整合性を維持するために毎月まる1週間を費やす可能性があります。誰もそれをロードマップには載せません。ただロードマップを圧迫するだけです。
検知コストは成功率チャートに隠れているため、気づかれにくいものです。保護対象のブロック率は徐々に上昇します。リトライが増加します。成功したfetchあたりのコストもそれに伴って上昇します。「サイトの難易度が上がった」と考えて済ませてしまいます。それは一部真実です。もう一部は、自社のスタックの挙動と通常のブラウザの挙動との間の格差が広がっていることです。どちらも同じ傾向をたどります。
どちらのコストも単体でプロジェクトを破綻させることはありません。しかし合わさることで、内製か購入かの採算計算を一変させます。
データチームにとっての意味
すべてのスクレイピングにブラウザが必要なわけではありません。この点は変わっていません。しかし多くのheadless運用が、単純なHTTPコールで済んだはずのページから始まっているため、改めて述べる価値があります。
ターゲットのデータがXHRまたはJSON endpoint経由で取得できる場合は、ブラウザを省略してください。HTTP requestはより安価で高速であり、そもそもこれらのフィンガープリントシグナルを一切持ちません。7月のokhlopkovの記事は、適切な優先順位を示しています。APIとXHRが最優先、次に埋め込みJSON、ページが本当に必要とする場合のみブラウザ、LLMによる抽出はその他すべてを検証した後の最終手段です。
ブラウザが必要なサイトについては、防御レベルが問題となります。軽度の保護（rate limit、User-Agentフィルタ、リファラチェック）であれば、適切に設定されたheadlessスタックが現在も機能し、コストは低く抑えられます。高度な保護（完全なセッションスコアリングを備えたCloudflare、PerimeterX、DataDome）では、コストは現実となり、複利的に膨らみます。そこが判断の分かれ目となります。
誰も話題にしない中間層も存在します。完全にブロックするのではなく、密かに劣化させるサイトです。異なる価格、間引かれたリスティング、欠落した画像、消えたレビュー。スクレイパーは成功を報告します。しかしデータは静かに狂っています。フィンガープリントのスコアがブロック判定ではなくコンテンツ出し分けの入力として使われるようになるにつれ、この障害モードはますます一般的になっています。
自分がその対象になっているか分からない場合、十中八九その対象になっています。
今後の展開
Headlessは、誰も厳密に監視していなかった10年間機能したハックに過ぎませんでした。ここ2年で状況は一変しました。検知ベンダーはついに残余のスクレイパー層を排除する価値があると判断し、自動化を最も特定しやすいレイヤーを標的に選びました。
次のラウンドは、より賢いパッチプラグインの争いにはなりません。アクセシビリティツール、旧型GPU、企業内プロキシ、プライベートDNSといった、標準的でない構成を持つ正規ユーザーに対する誤検知率を許容してまで、検知精度を追求する価値があると判断するサイトがどれだけあるかの勝負になります。彼らが得るHeadless検知精度の1ポイントごとに、正規ユーザーの何分の一かの割合が犠牲になります。軍拡競争が実際に繰り広げられるのはPuppeteerの設定内ではなく、まさにこのトレードオフの領域です。
すでにHeadlessの代償を払っているのなら、少なくともそれを測定してください。そうでなければ、意図せず引き受けた隠れコストを払い続けることになります。