ボット検出回避にCloakBrowserが選ばれる理由と類似OSS比較

Web スクレイピング・ブラウザ自動化の現場では、Cloudflare Turnstile・reCAPTCHA v3・FingerprintJS のような高度なボット検出システムに阻まれ、既存の Playwright スクリプトが突如として動かなくなるケースが増えています。playwright-stealth や undetected-chromedriver といった既存のステルス系 OSS は、Chrome 本体のアップデートのたびに壊れがちで、運用負荷の高さから別の選択肢を探している方も多いはずです。

そうした文脈で 2026 年に注目を集めているのが、CloakHQ/CloakBrowser です。「設定パッチ」「JavaScript インジェクション」ではなく、Chromium の C++ ソースコードに 49 箇所以上のパッチを当てた専用バイナリを配布し、pip install ひとつで Playwright/Puppeteer のドロップイン代替として動作する点が、既存ツールとの決定的な違いになっています。

本記事では、公式 README・GitHub のリポジトリメタ情報を一次情報として、CloakBrowser の概要・仕組み・主要機能・Camoufox / playwright-stealth / undetected-chromedriver との違い・採用検討時の確認項目を整理します。動作検証は行わず、公開情報ベースで「自プロジェクトに採用すべきか」を判断するための材料を提供することを目的とします。

詳細は GitHub の公式リポジトリ（CloakHQ/CloakBrowser）も併せて参照してください。

CloakBrowserとは：C++ソース改変で「本物のブラウザ」になるStealth Chromium

CloakBrowser は、Chromium のソースコードに直接パッチを当てて再ビルドした、ステルス特化の Chromium バイナリです。GitHub のリポジトリ説明には次のように記載されています。

Stealth Chromium that passes every bot detection test. Drop-in Playwright replacement with source-level fingerprint patches. 30/30 tests passed. （出典: CloakHQ/CloakBrowser）

「設定変更」や「JavaScript で navigator.webdriver を上書きする」といった表層パッチではなく、canvas・WebGL・audio・fonts・GPU・WebRTC・network timing・automation signals・CDP input behavior といった検出ベクターをすべて C++ レベルで改変している点が、CloakBrowser のコア特性です。

何ができるツールか（1行サマリ）

Playwright / Puppeteer のコードを 1 行だけ書き換えるだけで、ボット検出回避能力を備えた Chromium バイナリに切り替えられる OSS ライブラリです。Python と JavaScript の両方に同名パッケージが用意されており、初回起動時にステルス Chromium バイナリ（約 200MB）が自動的にダウンロードされ、ローカルキャッシュされます。

リポジトリ概況（Stars / License / Language / 最新更新）

GitHub API から取得したリポジトリメタ情報は次のとおりです。

スター数 11,000 超・直近で push が継続している点から、現時点ではアクティブにメンテナンスされている OSS と判断できます。

なぜ「設定パッチ」ではなく「ソースコードパッチ」が選ばれるのか

CloakBrowser を理解するうえで最大のポイントは、既存ステルスツールとアーキテクチャが根本的に異なることです。同じ「Playwright + ステルス」というカテゴリでも、検出を回避できるレイヤが大きく違います。

JS injection / 設定パッチ系の限界

playwright-stealth や puppeteer-extra-plugin-stealth は、起動した Chromium に対して JavaScript を注入し、navigator.webdriver などの自動化フラグを上書きする方式です。undetected-chromedriver は Chrome の起動フラグや設定ファイルを書き換える設定レベルのパッチで、Selenium ベースの自動化に対応します。

これらの方式には共通する弱点があります。

• 注入する JavaScript やパッチそのものを、最新のアンチボットシステムが検出できるようになってきている
• Chrome のメジャーアップデートで内部 API が変わると、パッチがそのまま動かなくなる
• レンダラ起動後にしか介入できないため、ブラウザ起動直後の TLS フィンガープリントや CDP の初期挙動は素のままになる

README の Comparison テーブルでも、これらのツールは「Breaks often」「Stale」と評価されています。

49+ C++ パッチが触れる検出ベクター

CloakBrowser はこの構造を逆転させ、Chromium のソースコード（C++）に直接 49 箇所以上のパッチを当て、改変済みの状態でバイナリをビルドして配布します。最新の v0.3.26 ではパッチ数が 57 まで拡張され、WebAuthn・AAC audio・window position・WebGL/canvas 整合性などが追加カバレッジに含まれています。

Not a patched config. Not a JS injection. A real Chromium binary with fingerprints modified at the C++ source level. Antibot systems score it as a normal browser — because it is a normal browser. （出典: CloakHQ/CloakBrowser README）

パッチ対象の検出ベクターは次のとおり広範です。

「同じ挙動がローカル・Docker・VPSで再現される」設計

C++ ソースに組み込んだパッチがバイナリレベルで完結するため、ローカル・Docker・クラウド VPS のいずれの環境でも同一の挙動が得られる、と公式は説明しています。これは「ローカルでは通るが、本番 VPS では検出される」といった環境差分のトラブルシューティングを大幅に減らす設計上の利点になります。Docker イメージは cloakhq/cloakbrowser として配布されており、CI/CD パイプラインへの組み込みも CLI ベースで完結します。

検出回避テスト結果（公式README記載）

採用判断で最も具体的な材料となるのが、公式 README が掲載している検出回避テストの実測結果です。CloakBrowser リポジトリでは、Stock Playwright と CloakBrowser の比較を 30 以上の検出サイトで実施した結果が、表形式で公開されています（2026 年 4 月時点・Chromium 146）。

CloakBrowser が目指しているのは「CAPTCHA を解く」ことではなく、「そもそも CAPTCHA を出現させない」ことです。reCAPTCHA v3 のスコアを 0.1（bot 判定）から 0.9（人間水準）まで引き上げられている点は、後段の CAPTCHA solver 系サービスへの依存を減らせる、運用面での価値を持ちます。

Playwright・Puppeteerのドロップイン代替としての導入

CloakBrowser の最大の実務的メリットは、既存の Playwright/Puppeteer スクリプトを 1 行書き換えるだけで導入できる点です。学習コストが事実上ゼロに近く、PoC の立ち上げが速いことが採用ハードルを下げています。

pip / npm でのインストールとバイナリ自動ダウンロード

CloakBrowser の公式パッケージは PyPI と npm の両方で配布されています。詳細なバージョン履歴は PyPI のパッケージページ および npm のパッケージページ で確認できます。

# Python
pip install cloakbrowser

# JavaScript / Node.js（Playwright と併用）
npm install cloakbrowser playwright-core

# JavaScript / Node.js（Puppeteer と併用）
npm install cloakbrowser puppeteer-core

（出典: CloakHQ/CloakBrowser README）

初回 launch() 時に約 200MB のステルス Chromium バイナリが自動ダウンロードされ、~/.cloakbrowser 配下にキャッシュされます。SHA-256 チェックサムでの検証も自動的に行われるため、社内環境での導入時もバイナリ完全性の懸念は低く抑えられます。

Python での launch() 利用例（最小コード）

公式 README から、最小構成の Python サンプルは次のように示されています。

from cloakbrowser import launch

browser = launch()
page = browser.new_page()
page.goto("https://protected-site.com")  # no more blocks
browser.close()

（出典: CloakHQ/CloakBrowser README）

既存の Playwright コードからの移行は、import 行だけを差し替えれば、ほとんどのケースで他のコードは変更不要です。

- from playwright.sync_api import sync_playwright
- pw = sync_playwright().start()
- browser = pw.chromium.launch()
+ from cloakbrowser import launch
+ browser = launch()

page = browser.new_page()
page.goto("https://example.com")
# ... rest of your code works unchanged

（出典: CloakHQ/CloakBrowser README）

加えて、launch_context() / launch_persistent_context() / 非同期版 launch_async() といったヘルパーが提供されており、永続プロファイル・ストレージステート復元・タイムゾーン/ロケール設定までを 1 行で組み立てられます。

JavaScript（Playwright / Puppeteer）での利用例

JavaScript / TypeScript の利用例も同等です。Playwright 版が推奨され、Puppeteer 版は別エントリポイント（cloakbrowser/puppeteer）として用意されています。

import { launch } from 'cloakbrowser';

const browser = await launch();
const page = await browser.newPage();
await page.goto('https://protected-site.com');
await browser.close();

（出典: CloakHQ/CloakBrowser README）

ただし README には、reCAPTCHA Enterprise を採用しているサイトでは Puppeteer 経由だと intermittent 403 が発生する旨が明示されています。これは Puppeteer 自体の CDP 経由のリーク特性で、CloakBrowser 固有の問題ではないものの、検出耐性を最優先する場合は Playwright 版を選ぶのが安全側の選定軸です。

humanize=True による挙動の人間化

検出回避には「フィンガープリント」だけでなく「行動パターン」も影響します。CloakBrowser は humanize=True フラグ 1 つで、マウス移動・クリック・キーボード入力・スクロールを人間的な挙動に置き換える機能を備えています。

browser = launch(humanize=True)
page = browser.new_page()
page.goto("https://example.com")
page.locator("#email").fill("user@example.com")
page.locator("button[type=submit]").click()

（出典: CloakHQ/CloakBrowser README）

具体的には、マウスは Bézier 曲線で目標座標まで動き、キーボードは 1 文字ずつ可変ディレイで入力され、スクロールは加速→巡航→減速のマイクロステップで処理されます。挙動を「より慎重にしたい」場合は human_preset="careful" を指定でき、human_config で mistype_chance（自己訂正付きタイポ率）・typing_delay・idle_between_actions などを細かく上書きすることもできます。

Camoufox・playwright-stealth・undetected-chromedriverとの違い

CloakBrowser を採用するかを判断するうえで、知名度のある類似 OSS との位置関係を整理しておくことが重要です。README には主要な比較表が掲載されています。

（出典: CloakHQ/CloakBrowser README）

パッチ方式の比較

ステルス系 OSS は大きく 4 つのアプローチに分類できます。

• JS injection（playwright-stealth・puppeteer-extra-plugin-stealth）: 起動済みブラウザに JavaScript を注入し、navigator.webdriver 等を上書きする。実装は軽量だが、Chrome のアップデートで API が変わると壊れやすい。
• 設定パッチ（undetected-chromedriver）: 起動フラグや設定ファイルを書き換える方式。Selenium ベースの自動化に対応するが、CDP やレンダラ起動直後の挙動には踏み込めない。
• C++ Firefox パッチ（Camoufox）: Firefox のソースに C++ パッチを当てる方式。Chromium ベースのスクリプト資産は流用できない。
• C++ Chromium パッチ（CloakBrowser）: Chromium 本体に C++ レベルでパッチを当てる方式。Playwright / Puppeteer の既存スクリプトをそのまま流用できる。

Camoufox（Firefox系）との選定軸の違い

Camoufox は、CloakBrowser と並んで「C++ ソースレベルパッチ」のアプローチを採るプロジェクトです。違いはベースエンジンが Firefox であることで、reCAPTCHA v3 スコアは 0.7-0.9 と高水準ながら、Playwright API ネイティブ互換ではない点が CloakBrowser との大きな選定軸の違いになります。

選択の指針は、既存の自動化資産・対象サイトの傾向で決まります。

• Chromium ベースの Playwright/Puppeteer スクリプト資産があり、それを流用したい → CloakBrowser
• Firefox 系の挙動・指紋プロファイルが対象サイト側で扱いやすい、または Chrome の自動更新ライフサイクルから距離を置きたい → Camoufox

「Chrome更新で壊れる/壊れない」の運用差

playwright-stealth と undetected-chromedriver は、新しい Chrome バージョンへの追随が遅れがちで、README でも「Stale」と評価されています。CloakBrowser は配布するバイナリ自体が Chromium 146 にリベース済みであり、利用者は wrapper の更新を受け取るだけで最新の Chromium ベースに追随できます。CLOAKBROWSER_AUTO_UPDATE=true（デフォルト）でバックグラウンドの更新チェックが行われる設計のため、運用上のアップデート負荷も小さく抑えられます。

採用時の確認チェックリスト

社内決裁や法務確認に持ち込みやすいよう、CloakBrowser を自プロジェクトに組み込むかどうかを判断する際の確認項目を整理します。

• 既存スクリプトが Playwright（Python or JavaScript）または Puppeteer ベースで、launch() 行の差し替えで移行できる構成になっているか
• reCAPTCHA Enterprise を採用しているサイトを対象に含む場合、Puppeteer 版ではなく Playwright 版を選択できるか
• 永続プロファイル（launch_persistent_context()）の利用有無と、ストレージクォータの設定方針（FingerprintJS を通す既定値 vs --fingerprint-storage-quota=5000 で BrowserScan の notPrivate を通すか）を整理できているか
• Linux 環境で動かす場合、Kasada / Akamai 等のキャンバスフォントハッシュ検出に備え、fonts-noto-color-emoji などのフォントパッケージを追加導入できるか
• バイナリ自動更新の挙動（CLOAKBROWSER_AUTO_UPDATE / CLOAKBROWSER_SKIP_CHECKSUM）が、自社のセキュリティ・コンプライアンス要件と整合するか
• MIT ライセンスでの商用利用にあたり、対象サイトの利用規約・robots.txt・契約条件・データ取得目的が法的・倫理的に問題ない範囲に収まることを社内で確認できるか
• ブラウザプロファイルを大量に管理する必要がある場合、関連プロダクトの CloakBrowser-Manager（Multilogin・GoLogin・AdsPower の OSS 代替）を併用する選択肢を検討できるか
• BYO プロキシ（HTTP / SOCKS5）の調達と運用ポリシー（IP ローテーション・地域分布・ログ保存）が整っているか

なお、CloakBrowser はライセンスが MIT のため、商用利用・改変・再配布が可能です。一方で、対象サイトのスクレイピングは利用規約や各国の法令（不正アクセス禁止法・GDPR・CCPA など）に強く依存します。技術的に検出を回避できることと、行為自体の合法性・倫理性は別問題であるため、利用範囲は必ず自社法務と合意したうえで運用することが前提となります。

まとめ

CloakBrowser は、Chromium の C++ ソースに 49 箇所以上のパッチを当てた専用バイナリを配布し、Playwright / Puppeteer のドロップイン代替として動作する Stealth Chromium OSS です。playwright-stealth や undetected-chromedriver のような「設定パッチ」「JS インジェクション」方式と異なり、検出ベクター（canvas・WebGL・audio・fonts・GPU・WebRTC・TLS）をバイナリレベルで改変している点が、Chrome アップデート耐性とアクティブメンテナンスの両立を支えています。

Firefox ベースの Camoufox とは選定軸が異なり、「Chromium 系の Playwright/Puppeteer 資産を活かして高い検出回避を狙う」ユースケースでは、現時点で CloakBrowser が最有力候補のひとつです。スター数 11,000 超・直近の push が継続している点・Chromium 146 ベースでのリリースが続いている点から、ステルスツール市場における信頼度は高い水準にあります。

採用検討の次の一歩としては、まず公式 README の Install セクション で導入手順を確認し、必要に応じて PyPI / npm のリリース履歴で最新バージョン・依存関係を参照したうえで、自社の対象サイト・運用要件・法務要件に照らして適合性を判定する流れが現実的です。