Webサイトを自動操作しようとPlaywrightやPuppeteerでChromiumを立ち上げると、多くのサイトで「あなたはロボットですか?」と問われ、Cloudflareのチャレンジ画面やreCAPTCHAに行く手を阻まれます。これは、アンチボット(anti-bot)システムが、自動化ブラウザに特有の「足跡」——navigator.webdriverフラグ、ヘッドレス特有のUA文字列、canvasやWebGLの指紋(フィンガープリント)——を検知しているためです。アンチボットは、Webサイトを自動化された不正アクセスやスクレイピングから守るための仕組みであり、それ自体は防御技術として正当なものです。

この検知をすり抜けることを狙って作られたのが、本記事で扱う CloakBrowser(クロークブラウザ) です。GitHubで27,000スター超を集めるこのオープンソースは、自らを「すべてのボット検知テストを通過するステルスChromium」と称します。最大の特徴は、その手法にあります。JavaScriptを注入したり起動フラグをいじったりするのではなく、ChromiumのソースコードそのものをC++レベルで改変し、指紋を作り変えたバイナリをコンパイルする——つまり「パッチを当てた設定」ではなく「最初から普通のブラウザに見える本物のブラウザ」を作る、というアプローチです。

⚠️ はじめに:本記事の立場(必読)

CloakBrowserはボット検知を回避するデュアルユース(両義的)ツールです。本記事は、その技術的な仕組みと、アンチボットとの「いたちごっこ」を中立に理解するための解説であり、特定サイトの保護を破る手順書ではありません。利用は必ず対象サイトの利用規約・robots.txt・各国の法令(日本の不正アクセス禁止法、米国CFAA等)を遵守し、自分が権限を持つ対象・許可された調査の範囲に限られます。第三者サイトへの無断・大規模アクセスや、認証・課金・レート制限の回避は規約違反や違法行為になり得ます。本記事は防御側(サイト運営者)が脅威を理解する一助となることも意図しています。

1. CloakBrowserとは — 「設定パッチ」ではなく「ソース改変」

CloakBrowserは、CloakHQが公開するオープンソースです。PythonおよびJavaScript(さらにコミュニティ製の.NETクライアント)から使え、ラッパー部分はMITライセンスで公開されています。公式の説明はこう謳います。

パッチを当てた設定ではない。JavaScriptの注入でもない。C++ソースレベルで指紋を変更した本物のChromiumバイナリだ。アンチボットシステムはこれを通常のブラウザと判定する——なぜなら、これは実際に通常のブラウザだからだ。

ここがCloakBrowserの核心です。従来のステルス手法——playwright-stealthundetected-chromedriverpuppeteer-extraなど——は、JavaScriptを実行時に注入したり、起動フラグを調整したりして指紋を「上書き」します。しかしこの方法には弱点があります。アンチボット側は、その「上書きの痕跡」自体を検知できてしまうのです。さらにChromiumがアップデートされるたびに、これらの小手先のパッチは壊れます。

CloakBrowserは発想を変えました。Chromiumのソースコードを改変し、指紋がもとから別物になったブラウザをビルドする。実行時の注入がないため「上書きの痕跡」が存在せず、検知サイトからは本物のブラウザにしか見えない、というわけです。

なぜ「ソース改変」は見抜かれにくいのか 従来:JS注入 / 設定パッチ 本物のChromium + 実行時にJSで指紋を上書き → 上書きの「痕跡」を検知される CloakBrowser:C++ソース改変 ソースコードを58カ所改変 → 指紋が別物のバイナリをビルド → 上書きの痕跡が存在しない
JS注入は「上書きの痕跡」を検知されるが、ソースレベル改変は痕跡そのものが残らない(出典: CloakHQ/CloakBrowser の説明をもとに作図)

形態:カスタムビルドのChromiumバイナリ + 薄いラッパー(Python / JS / .NET)
ライセンス:ラッパーはMIT。バイナリは「旧版は無料・最新版はPro(有料)」の遅延無料公開モデル
互換性:Playwright / Puppeteer のドロップイン代替(importを差し替えるだけ)
インストールpip install cloakbrowser または npm install cloakbrowser。初回起動時にバイナリ(約200MB)を自動ダウンロード

公式が強調するのは「3行のコード、30秒でブロック解除」という手軽さです。既存のPlaywrightコードのimport文を差し替えるだけで動く、という低い導入障壁が、27,000スターという人気を支えています。実際、移行は from playwright.sync_api import sync_playwrightfrom cloakbrowser import launch に置き換えるだけで、page.goto(...) 以降の既存コードはそのまま動く設計です。学習コストがほぼゼロである点は、技術的な巧妙さとは別の次元で、このツールの普及を後押ししています。裏を返せば、検知回避の敷居がここまで下がったことは、防御側にとって脅威の裾野が広がったことを意味します。

2. 58のC++ソースパッチ — 何を「作り変えて」いるのか

CloakBrowserがバイナリに組み込んでいるのは、公式によれば58カ所(最新Pro版では59カ所)のソースレベルC++パッチです。これらは、ブラウザフィンガープリンティングで使われる主要な「識別の手がかり」を、本物のChrome相当の値に作り変えます。

ブラウザフィンガープリンティングとは、ブラウザが返す無数の細かい属性を組み合わせて、個々のブラウザを一意に識別する技術です。CloakBrowserがパッチを当てる領域を整理すると、検知側がいかに多面的にボットを見分けようとしているかが見えてきます。

Canvas / WebGL / Audio:描画・音声処理の微妙な差異(ハードウェアごとの癖)を再現
フォント / GPU / 画面プロパティ:インストール済みフォント一覧、GPU情報、画面解像度などを実機相当に
WebRTC:ローカルIPの漏洩を防ぎ、プロキシの出口IPに合わせてICE候補を偽装
ネットワークタイミング:DNS/接続/SSLのタイミング差を消し、プロキシ経由の痕跡を除去
自動化シグナルnavigator.webdriverfalse に、window.chrome を本物同様に存在させる
CDP入力挙動:DevTools Protocol経由の操作が「自動化された入力」と見抜かれないよう挙動を模倣

公式のテスト結果(対30以上の検知サイト)では、navigator.webdrivertrue から false に、UA文字列が HeadlessChrome から Chrome/146.0.0.0 に、navigator.plugins.length が0から5に変わるなど、自動化の痕跡が軒並み消えることが示されています。さらにTLSフィンガープリント(ja3n/ja4/akamai)まで本物のChromeと一致させる、という徹底ぶりです。

ここで「なぜ58カ所も必要なのか」を考えると、アンチボット検知の本質が見えてきます。検知側は、たった一つの決定的な「ボットの証拠」を探しているのではなく、無数の小さな違和感を総合してスコア化しています。canvasの描画が他の属性と矛盾している、GPU情報がUA文字列と合わない、フォント構成が不自然——こうした「整合性の綻び」を一つでも残せば、総合スコアで弾かれます。だからCloakBrowserは、canvasだけ、UAだけ、といった部分的な偽装では足りず、ブラウザが外部に晒すあらゆる属性を互いに矛盾しないよう一貫して作り変える必要があるのです。58という数字は、現代のフィンガープリンティングがいかに多面的になっているかを物語っています。

特に巧妙なのが、Windows版で採用された「ネイティブGPUパススルー」です。GPU情報を偽の値で「詐称」すると、かえって他の属性との矛盾を生みやすい。そこでCloakBrowserは、実機の本物のハードウェア値をそのまま通すことで、本物のブラウザと同じ挙動を再現します。「偽装しすぎないことで、かえって本物らしくなる」という、検知回避の逆説がここにあります。

ポイント:なぜ「ソースレベル」が効くのか

JavaScript注入による偽装は、いわば「化粧」です。近づいて見れば(=検知スクリプトが詳しく調べれば)塗った跡が分かります。一方ソースレベルの改変は「整形手術」に近く、ブラウザの出力そのものが最初から別物になります。検知側が「偽装の痕跡」を探す手法では、痕跡そのものが存在しないため見抜けない——これがCloakBrowserの設計上の強みであり、同時にアンチボット業界にとっての難題です。

3. 指紋だけでなく「挙動」も — humanizeという発想

近年のアンチボットは、指紋(静的な属性)だけでなく、挙動(behavioral signals) も見ています。マウスがカクカクと直線的に動く、キー入力が機械的に等間隔、スクロールが不自然に一定——こうした「人間らしくない動き」を検知するのです。指紋を完璧に偽装しても、動きがロボット然としていれば見抜かれます。

CloakBrowserはこれに対し、humanize=True という単一のフラグで応えます。これを有効にすると、以下が「人間らしく」なります。

マウス:直線でなくベジェ曲線を描く、自然な軌道
キーボード:1文字ごとに微妙にばらつく入力タイミング
スクロール:一定でない、現実的なスクロールパターン

公式によれば、行動ベースのボット検知サイト(deviceandbrowserinfo.com)で、humanize=True により24個の挙動シグナルすべてを通過し「You are human!(あなたは人間です)」と判定された、とされています。

この「指紋+挙動」の二段構えは、現代のアンチボットが多層防御であることの裏返しでもあります。検知と回避が、レイヤーごとに鏡合わせに進化しているのです。一方が新しい検知手法を編み出せば、他方がそれをすり抜ける手を打つ——この終わりのない応酬が、ブラウザ自動化とアンチボットの世界の常態になっています。

flowchart LR subgraph 検知側 [アンチボット検知] D1["指紋検査
canvas/WebGL/UA"] D2["自動化シグナル
webdriver/CDP"] D3["挙動分析
マウス/キー/スクロール"] D4["サーバー側
TLS/IP/レート"] end subgraph 回避側 [CloakBrowserの対応] C1["C++ソース改変で
指紋を実機化"] C2["シグナル除去
webdriver=false"] C3["humanizeで
人間らしい挙動"] C4["プロキシ/geoip
※利用者が用意"] end D1 -.対抗.-> C1 D2 -.対抗.-> C2 D3 -.対抗.-> C3 D4 -.対抗.-> C4

重要なのは、CloakBrowserがCAPTCHAを解くわけではない点です。公式は「CAPTCHAを解くのではなく、そもそも出現させない」と明言しています。CAPTCHA解決サービスも、プロキシのローテーション機能も内蔵していません。プロキシは利用者が自分で用意する設計(BYO proxy)で、あくまで「検知されにくいブラウザ」に徹しています。

4. 既存ステルスツールとの比較

CloakBrowserの位置づけを理解するため、既存の主要なステルス自動化ツールと比較します。公式が示す比較表をもとに整理すると、設計思想の違いが鮮明になります。

観点 playwright-stealth undetected-chromedriver Camoufox CloakBrowser
パッチ方式 JS注入 設定パッチ C++(Firefox) C++(Chromium)
Chrome更新への耐性 壊れやすい 壊れやすい 高い 高い
メンテ状況 停滞気味 停滞気味 不安定 アクティブ
ブラウザエンジン Chromium Chrome Firefox Chromium
Playwright API ネイティブ 非対応(Selenium) 非対応 ネイティブ

この表から見える差別化点は2つです。第一に、JS注入・設定パッチ系(playwright-stealth等)は、Chromeのアップデートで壊れやすく、検知もされやすいこと。第二に、ソースレベルで改変する点ではCamoufoxが近い思想ですが、CamoufoxはFirefoxベースで、Playwright APIをネイティブには使えません。CloakBrowserはChromiumベースかつPlaywrightネイティブである点で、既存のPlaywright資産をそのまま活かせる利便性を持ちます。

なお、バイナリは「旧版(v146)は無料で永久公開、最新版はPro(有料サブスク)」という遅延無料モデルを採用しています。アンチボットの進化に追従するには最新バイナリが要るため、本番運用ではProが現実的、という収益設計です。この「無料版は数週間で陳腐化する」という構造は、検知回避が本質的に時限的なものであることを正直に示しています。今日通用する偽装が、明日も通用する保証はないのです。バイナリのダウンロードはEd25519署名で検証され、改ざんやダウングレードを防ぐ仕組みも備えています。OSSとしての透明性とサプライチェーンの安全性に配慮している点は、この種のツールとしては評価できる姿勢です。

5. AIエージェント時代の文脈 — なぜいま注目されるのか

当サイトがこのツールを取り上げる理由は、そのAIとの接点にあります。CloakBrowserの公式READMEは、対応する連携先として browser-use・Crawl4AI・Scrapling・Stagehand・LangChain・Selenium といった、AIエージェント/AIスクレイピングのフレームワークを明示しています。

近年、AIブラウザエージェント(Webを自律操作するAI)や、LLMの学習・RAG用にWebデータを収集するクローラーが急増しています。ところが、これらが本物の人間のアクセスと区別されてアンチボットにブロックされると、機能しません。CloakBrowserのようなステルスブラウザは、AIエージェントが「人間と同じようにWebを使う」ための土台として、需要が高まっているのです。

ここには、Web全体にまたがる緊張関係があります。サイト運営者は、サーバー負荷やコンテンツの無断利用、不正利用を防ぐためにアンチボットを導入します。一方、AIエージェントやスクレイパーは、それを「正当なアクセスまで阻む障壁」と感じる。CloakBrowserの人気は、この「AI時代のアクセスを巡る綱引き」が激化していることの、ひとつの象徴と言えます。

この綱引きは、単純な善悪では割り切れません。たとえば、ユーザー本人が「自分のために」AIエージェントに自分のアカウントの情報を取得させたい、という場面を考えてみましょう。これはユーザーから見れば正当な代理操作ですが、サイト側のアンチボットからは「ボットによる不正アクセス」と区別がつきません。逆に、コンテンツを大量に無断収集してLLMの学習に使う行為は、サイト運営者から見れば明確な権利侵害です。同じ「検知回避」という技術が、文脈によって正当にも不当にもなる——この曖昧さこそが、デュアルユースツールの難しさの核心です。

だからこそ、技術そのものをブラックボックス化して「危険だから見ない」のではなく、その仕組みを正しく理解し、攻守両面から議論できるようにすることに意味があります。CloakBrowserがオープンソースとして公開され、これだけの注目を集めている事実は、Webのアクセス制御という古くて新しい問題が、AIの台頭によって再び最前線に押し出されたことを示しているのです。

正当な用途の例

検知回避技術には、明確に正当な用途があります。
自社サイトのアンチボット防御のテスト:自分の防御が回避ツールにどこまで耐えるかを検証する
QA・E2Eテスト自動化:自社サービスの自動テストが過剰な検知でブロックされるのを避ける
アクセシビリティ検証:自動化ツールでの到達性を確認する
権限のあるセキュリティ調査:許可されたペネトレーションテストや脅威リサーチ
これらはいずれも「自分が権限を持つ対象」または「明示的に許可された範囲」での利用が前提です。

6. 防御側の視点と、利用上の倫理・法的リスク

CloakBrowserのようなツールの存在は、サイト運営者(防御側)にとっても重要な示唆を含みます。それは、指紋ベースの検知だけに依存する防御はもはや十分ではないという現実です。

C++ソースレベルで指紋を実機化されると、navigator.webdriver のような「分かりやすい印」は当てになりません。防御側が取るべき方向は、より多層的なアプローチへとシフトします。

サーバー側のシグナル重視:TLS指紋、IPレピュテーション、アクセスパターン、レート
挙動の連続性分析:単発の指紋でなく、セッション全体の行動の自然さ
リスクベース認証:怪しい場合のみ段階的にチャレンジを上げる
正当なボットの許可:検索エンジンや正規APIへの導線を整え、無理なスクレイピング需要を減らす

つまりCloakBrowserの技術解説は、攻撃側の手口を知ることで防御を設計し直す、という防御的セキュリティの観点からも価値があります。

一方で、利用にあたっては倫理的・法的な一線を強く意識する必要があります。検知回避そのものは技術ですが、それをどこに向けるかで合法にも違法にもなります

想定 評価
自社サイトの防御テスト・QA 一般に問題なし(自分が権限を持つ対象)
許可された調査・ペンテスト 合意・スコープ内なら可
公開データの節度ある収集 robots.txt・ToS・レート・著作権の遵守が前提。グレーも多い
認証・課金・レート制限の回避 規約違反。不正アクセス禁止法・CFAA等に抵触し得る
第三者サイトへの無断大規模アクセス 業務妨害・違法のリスク。明確に避けるべき
法的注意(日本の読者向け)

日本では、アクセス制御を回避して他人のIDで認証を突破するような行為は不正アクセス禁止法に抵触し得ます。また、過度なアクセスでサーバーに障害を与えれば電子計算機損壊等業務妨害罪の対象になり得ます。収集したデータの利用には著作権法・個人情報保護法も関わります。「技術的に可能」と「法的に許される」は別物です。CloakBrowserを使う場合は、対象サイトの利用規約と関連法令を必ず確認し、グレーな用途には踏み込まないでください。

まとめ

本記事では、ボット検知を回避するステルスChromium CloakBrowser を、技術・正当な用途・法的リスク・防御側視点の4面から解説しました。

技術的に見たCloakBrowserの新しさは、JavaScript注入や設定パッチではなく、Chromiumのソースコードを58カ所C++改変し、指紋がもとから別物のバイナリをビルドする点にあります。さらに humanize=True で挙動まで人間に近づけ、指紋・自動化シグナル・挙動という多層の検知を横断的にすり抜けます。Playwright互換で導入が容易なことも、27,000スターという人気の理由です。

しかし、この技術はデュアルユースです。自社防御のテスト・QA・許可された調査といった正当な用途がある一方、第三者サイトへの無断アクセスや認証・課金回避に使えば、規約違反や違法行為になります。技術の理解と、その使いどころの倫理・法令遵守は、つねにセットで考える必要があります。

そして防御側にとって、CloakBrowserの存在は「指紋検知だけでは守れない」という警鐘です。攻撃側の手口を知ることは、より堅牢な多層防御を設計する第一歩になります。検知と回避のいたちごっこは続きますが、その構造を正しく理解することが、攻守どちらの立場でも出発点になるのです。

よくある質問(FAQ)

Q1. CloakBrowserは何をするツールですか? ChromiumのソースコードをC++レベルで改変し、ブラウザの指紋(canvas/WebGL/WebRTC等)と挙動を本物のブラウザに近づけることで、ボット検知システムに検知されにくくする「ステルスChromium」です。Playwright/Puppeteerのドロップイン代替として使えます。

Q2. 既存のplaywright-stealthなどと何が違いますか? playwright-stealthやundetected-chromedriverはJavaScript注入や設定パッチで指紋を上書きするため、その痕跡自体を検知されやすく、Chromeの更新で壊れがちです。CloakBrowserはソースコードを改変してビルドするため痕跡が残らず、更新にも強い、という違いがあります。

Q3. CAPTCHAを自動で解いてくれますか? いいえ。公式は「CAPTCHAを解くのではなく、そもそも出現させない」と明言しています。CAPTCHA解決サービスやプロキシのローテーション機能は内蔵しておらず、プロキシは利用者が自分で用意する設計です。

Q4. 使うのは合法ですか? 用途次第です。自社サイトの防御テストや許可された調査は一般に問題ありませんが、第三者サイトへの無断アクセス、認証・課金・レート制限の回避などは利用規約違反であり、日本の不正アクセス禁止法や業務妨害罪、米国のCFAA等に抵触し得ます。対象サイトの規約と法令の遵守が大前提です。

Q5. なぜAIメディアであるこのサイトが取り上げるのですか? CloakBrowserはbrowser-use・Crawl4AI・Stagehand・LangChainなどAIエージェント/AIスクレイピングのフレームワークと連携でき、AIがWebを操作・収集する際の土台として注目されているためです。AI時代の「Webアクセスを巡る綱引き」を理解するうえで重要な事例です。

Q6. サイト運営者(防御側)は何をすべきですか? 指紋ベースの検知(navigator.webdriver等)だけに頼らないことが重要です。TLS指紋・IPレピュテーション・アクセスパターンといったサーバー側シグナル、セッション全体の挙動分析、リスクベース認証など、多層的な防御へシフトする必要があります。

参照ソース

CloakBrowser(CloakHQ 公式リポジトリ) — 本記事が解説した一次情報。C++パッチの範囲・テスト結果・比較表
Playwright 公式ドキュメント — CloakBrowserが互換性を持つ自動化フレームワーク
FingerprintJS — ブラウザフィンガープリンティング/ボット検知の代表的サービス