ブラウザ自動化のブロック対策：4層防御スタック完全ガイド

ブラウザ自動化のスクリプトがある日突然ブロックされる。昨日まで動いていたのに、今日はCAPTCHAが出る。プロキシを変えてみる。User-Agentをランダムにしてみる。それでも数時間後にはまたブロック。この繰り返しに心当たりのある開発者は多いはずです。

原因はシンプルです。現代のアンチボットシステムは、単一のシグナルではなく、複数の層を同時に評価しています。1つの層だけ対策しても、他の層で検出されれば意味がありません。このガイドでは、Cloudflare、Akamai、PerimeterX、DataDomeといった主要なアンチボットシステムが評価する4つの層を体系的に解説し、それぞれの具体的な対策を示します。

なぜ自動化はブロックされるのか

アンチボットシステムは、リクエスト単位ではなく、セッション全体を4つの層で同時にスコアリングしています。

レイヤー1：ブラウザのアイデンティティ — フィンガープリントの一貫性
レイヤー2：ネットワーク — IPの評判、TLSフィンガープリント、地理的整合性
レイヤー3：行動パターン — マウスの動き、クリックのタイミング、スクロール
レイヤー4：セッション管理 — Cookie、ログイン状態、レート制限

各層には独自のスコアがあり、複数の層で低スコアが重なると、ブロックまたはCAPTCHAが発動します。User-Agentを変えただけでは、レイヤー1の20以上あるシグナルのうち1つしか対策できていません。ステルスプラグインを入れても、レイヤー2のTLSフィンガープリントで即座にバレます。

これが「先週まで動いていたスクリプトが急に動かなくなる」理由です。アンチボットシステムは常にモデルを更新しており、1つの層だけの対策は時間の問題で破られます。

レイヤー1：ブラウザのアイデンティティ（フィンガープリント）

ブラウザのフィンガープリントは、アンチボットシステムが最初に評価する層です。page.goto() が解決する前に、すでに20以上のシグナルが収集されています。

フィンガープリントの表面

アンチボットシステムが読み取る主なシグナルは以下の通りです。

カテゴリ	シグナル	自動化ブラウザの問題
Navigator	`navigator.webdriver`、`navigator.plugins`、`navigator.languages`	`webdriver=true` が露出、プラグイン数がゼロ
レンダリング	Canvas、WebGL、AudioContext	ヘッドレスモードでは出力がない、またはGPUと不整合
画面	`screen.width`、`screen.height`、`devicePixelRatio`	典型的なヘッドレス解像度（800x600等）
フォント	インストール済みフォントのリスト	OSと不一致のフォントセット
タイミング	レンダリングのタイミングパターン	人間には不可能な速度での連続アクセス

重要なのは、個々のシグナルではなく、シグナル間の一貫性です。navigator.platform が "MacIntel" なのに、フォントリストにmacOS固有のフォントがない。User-Agentは Chrome 120 なのに、Canvas の出力が Chrome 115 と一致する。こうした矛盾が検出の根拠になります。

なぜステルスプラグインは機能しないのか

puppeteer-extra-plugin-stealth のようなステルスプラグインは、navigator.webdriver を false に書き換えたり、navigator.plugins に偽の値を注入したりします。しかし、この方法には根本的な限界があります。

JavaScriptレベルのパッチは検出可能 — プロパティの書き換えは Object.getOwnPropertyDescriptor() で検出できます
一貫性の欠如 — パッチされた値と、Canvas やWebGL の実際の出力が矛盾します
アップデートへの追従が不可能 — アンチボットシステムは数週間ごとにチェック項目を更新します

必要なのは、ブラウザバイナリレベルで一貫したアイデンティティを持つアンチディテクトブラウザです。フィンガープリントの全表面がネイティブに整合していれば、JavaScriptのパッチは不要です。詳しくはブラウザフィンガープリントの仕組み：アンチボットシステムが使う20以上のシグナルを参照してください。

レイヤー2：ネットワーク

フィンガープリントが完璧でも、ネットワーク層で検出されることがあります。アンチボットシステムは、ブラウザがJavaScriptを実行する前に、接続レベルで複数のシグナルを評価しています。

IPの評判

すべてのIPアドレスが同じではありません。アンチボットシステムは、IPの種類と評判を以下のように分類しています。

IPの種類	ブロック率の目安	理由
データセンター（AWS、GCP等）	~90%	ボットトラフィックの大半がデータセンターから発信
レジデンシャル（住宅用）	<5%	実際のユーザーと同じISPからのアクセス
モバイル	<3%	CG-NATにより多数のユーザーが同一IPを共有

データセンターのIPからブラウザ自動化を実行すると、他のすべてが完璧でも高確率でブロックされます。レジデンシャルプロキシまたはモバイルプロキシの使用が実質的に必須です。

TLSフィンガープリント（JA3/JA4）

TLS Client Helloメッセージには、クライアントがサポートするcipher suite、拡張機能、楕円曲線のリストが含まれています。この組み合わせをハッシュ化したものがJA3（またはJA4）フィンガープリントです。

重要なポイント：Playwrightやpuppeteerが使う標準的なChromiumのTLSフィンガープリントは、アンチボットシステムのデータベースに登録されています。User-Agentで「Chrome」と名乗っていても、TLSフィンガープリントが通常のChromeと異なれば、矛盾として検出されます。詳しくは Playwrightスクリプトがなぜブロックされるのかを参照してください。

地理的整合性

ブラウザの Intl.DateTimeFormat().resolvedOptions().timeZone が東京を示しているのに、IPアドレスがフランクフルトのデータセンターから来ていれば、矛盾として検出されます。タイムゾーン、言語設定、IPの地理情報は一致している必要があります。

WebRTCリーク

WebRTCは、プロキシを経由せずに実際のIPアドレスをリークする可能性があります。STUNサーバーへのリクエストはプロキシ設定を迂回するため、プロキシの背後にいても実際のIPが露出します。アンチディテクトブラウザは、WebRTCをブロックするか、プロキシIPと整合したWebRTC応答を返す必要があります。

レイヤー3：行動パターン

フィンガープリントとネットワークが完璧でも、行動パターンが機械的であれば検出されます。アンチボットシステムは、ユーザーの操作パターンを統計的に分析しています。

ディレイ、マウス、スクロール、ペーシング

人間は一定間隔で操作しません。await page.click() を連続で呼ぶと、ミリ秒単位の等間隔アクセスになり、即座にボットと判定されます。ディレイ、マウスの動き、スクロールの3つを組み合わせて対策します。

ランダムなディレイの実装：

import random
import asyncio

async def human_delay(min_ms=800, max_ms=2500):
    delay = random.uniform(min_ms, max_ms) / 1000

ページ間のナビゲーションには1.5〜4秒、同一ページ内のクリックには0.3〜1.2秒、入力フィールドへのタイピング前には0.5〜1.5秒のランダムなディレイを入れることで、人間に近いペーシングを実現できます。一般的に、アクション間のディレイは2〜5秒の範囲が安全です。

自然なマウスの動き：

人間のマウスカーソルは直線的に動きません。わずかな曲線を描き、目標地点の近くで減速します。対象要素の正確な中心をクリックすることも不自然です。

async def move_and_click(page, selector):
    element = await page.query_selector(selector)
    box = await element.bounding_box()
    # Move to element with some randomness in the endpoint
    x = box["x"] + box["width"] * random.uniform(0.3, 0.7)

steps パラメータでマウスの移動をアニメーション化し、クリック位置を要素内でランダムにずらすことで、より自然な操作パターンを生成します。

スクロールとペーシング：

ページを開いた瞬間にページ最下部の要素をクリックするのは不自然です。人間はスクロールしてからクリックします。ビューポート外の要素にアクセスする前に、段階的なスクロールを挟むことが重要です。操作の種類に応じた推奨ディレイは以下の通りです。

操作	推奨ディレイ
ページ遷移	2〜5秒
同一ページ内のクリック	0.3〜1.2秒
フォーム入力前	0.5〜1.5秒
スクロール後の操作	1〜3秒

レイヤー4：セッション管理

大規模な自動化では、単一セッションの品質だけでなく、セッション全体の管理が重要になります。

Cookieとログイン状態

アンチボットシステムは、Cookieの有無とその変遷を追跡しています。初回アクセス時にCookieがすでに存在する、または逆に、何百回アクセスしてもCookieが蓄積されない。どちらも不自然です。

セッションごとにCookieを適切に保持し、ログイン状態を管理することが必要です。Cookieが自然に蓄積される動線を再現することで、アンチボットシステムのスコアを下げることができます。

セッションの分離

複数のアカウントやタスクを並行で実行する場合、セッション間のクロスコンタミネーション（相互汚染）を防ぐ必要があります。1つのブラウザプロファイルで複数のアカウントにログインすると、Cookie、localStorage、キャッシュが混在し、アンチボットシステムに検出される原因になります。

from playwright.async_api import async_playwright

async def isolated_session(profile_name, target_url):
    async with async_playwright() as p:
        # Connect to Clawbrowser with an isolated profile

各プロファイルは独立したCookie、ストレージ、フィンガープリントを持ちます。プロファイル間でデータが共有されることはありません。

レート制限の回避

単一のアカウントやIPから短時間に大量のリクエストを送信すると、行動パターンが完璧でもレート制限に引っかかります。サイトごとにリクエスト頻度の閾値は異なりますが、人間の利用パターンから大きく逸脱すれば必ず検出されます。各プロファイルのリクエスト頻度を抑え、全体のスループットはプロファイル数で確保するのが基本戦略です。

マルチアカウント分散

リクエストを複数のプロファイルに分散させることで、個々のプロファイルの負荷を下げつつ、全体の処理量を維持できます。プロファイルごとに異なるプロキシを割り当て、フィンガープリントも分離することで、サイト側からは独立した別々のユーザーとして認識されます。

自動化ブロックの診断方法については、なぜ自動化がCAPTCHAをトリガーするのか：7つのシグナル診断ガイドも参考になります。

4層を組み合わせる

4つの層すべてを同時に対策する必要がありますが、すべてをコードで解決する必要はありません。

Clawbrowserは、ブラウザバイナリレベルでフィンガープリントの一貫性を確保し、プロキシルーティングとTLSフィンガープリントの管理を内蔵しています。レイヤー1（フィンガープリント）とレイヤー2（ネットワーク）はブラウザに任せることで、コードの複雑さを大幅に削減できます。行動パターン（レイヤー3）とセッション管理（レイヤー4）は、アプリケーションのロジックに依存するため、コードで実装します。

以下は、ClawbrowserとPlaywrightを組み合わせた完全な例です。

from playwright.async_api import async_playwright
import random, asyncio

async def scrape_with_clawbrowser():
    async with async_playwright() as p:

Clawbrowserへの接続は標準的なCDPエンドポイント経由で行うため、既存のPlaywright/puppeteerスクリプトをほぼ変更なしで利用できます。CDPについて詳しくは AIエージェント向けCDPブラウザ：開発者ガイドを参照してください。

clawbrowser.ai からインストールプロンプトをコピーして、AIエージェントに貼り付けるだけです。セットアップは2分以内に完了します。

機能しないアプローチ

多くの開発者が試みるが、長期的には機能しないアプローチがあります。

アプローチ	なぜ機能しないのか	持続期間
ランダムUser-Agent	20以上あるフィンガープリントの1つを変えるだけ。他のシグナルと矛盾する	数時間〜数日
ステルスプラグイン	JavaScriptレベルのパッチは検出可能。一貫性の欠如	数日〜数週間
ヘッドレスモード	Canvas、WebGL、画面サイズ等のシグナルが本物のブラウザと大きく異なる	即座にブロック
プロキシのみ	レイヤー2だけの対策。フィンガープリントと行動パターンは未対策	数時間〜数日
リクエスト間隔を遅くする	レート制限は回避できるが、フィンガープリントとネットワーク層は未対策	効果限定的

よくある質問

Cloudflareはどうやって自動化を検出していますか？

Cloudflareは、TLSフィンガープリント、ブラウザのフィンガープリント（Canvas、WebGL等）、行動分析（マウスの動き、クリックパターン）、IPの評判を組み合わせてスコアリングしています。1つのシグナルだけではブロックされませんが、複数のシグナルが閾値を超えるとCAPTCHAまたはブロックが発動します。

レジデンシャルプロキシだけで十分ですか？

いいえ。レジデンシャルプロキシはレイヤー2（ネットワーク）の対策としては効果的ですが、レイヤー1（フィンガープリント）、レイヤー3（行動パターン）、レイヤー4（セッション管理）は別途対策が必要です。プロキシだけに依存すると、短期間でブロックされます。

ヘッドレスモードでスクレイピングはできますか？

技術的には可能ですが、アンチボット対策が施されたサイトでは即座にブロックされます。ヘッドレスモードは、Canvas の出力がない、navigator.plugins が空、画面サイズが不自然など、多数のシグナルで検出されます。ヘッドフルモードのアンチディテクトブラウザが推奨されます。

スクレイピングの速度を上げるにはどうすればいいですか？

速度を上げるには、並列化が鍵です。単一セッションのリクエスト頻度を上げるのではなく、複数の分離されたプロファイルで並列に実行します。各プロファイルは人間のペースでアクセスしつつ、プロファイル数を増やすことで全体のスループットを向上させます。

AIエージェントにもこの4層モデルは適用されますか？

はい。AIエージェントがブラウザを操作する場合も、同じアンチボットシステムに直面します。むしろ、AIエージェントは人間よりも機械的なパターンで操作する傾向があるため、行動パターン層（レイヤー3）の対策が特に重要です。

まとめ：下の層から固める

ブラウザ自動化でブロックされないためには、4つの層を下から順番に固めることが重要です。

レイヤー1（ブラウザのアイデンティティ） — アンチディテクトブラウザで一貫したフィンガープリントを確保
レイヤー2（ネットワーク） — レジデンシャルプロキシとTLSフィンガープリントの管理
レイヤー3（行動パターン） — ランダムなディレイ、自然なマウスの動き、段階的なスクロール
レイヤー4（セッション管理） — プロファイルの分離、Cookie管理、レート制限の分散