KitesurfとObscura：AIブラウザを支配するのは誰か

いまAIブラウザと聞くと、多くの人はチャット画面を備えた通常のブラウザを思い浮かべるでしょう。AIがタブを要約し、質問に答え、フォームを入力するものです。しかし技術的には、もう一つのカテゴリーの方が興味深いと言えます。人間のためには作られていないブラウザエンジンです。画面を表示せず、APIで制御され、一つのタスクを処理する間だけ存在することさえあります。

以前の記事WebMCPとエージェント型Webでは、エージェントに構造化された機能を提供するWebサイトを扱いました。KitesurfとObscuraが取り組むのは、この問題の反対側です。Webの大部分にエージェント向けインターフェースがない限り、AIシステムには通常のページを読み、操作できるエンジンが必要です。

CloudflareがKitesurfを位置づけるのは、まさにこの領域です。新しいブラウザはCloudflare Workers上で動作し、Chrome DevTools Protocolを利用します。完全なChromiumプロセスよりもはるかに低いコストで、エージェントにWebページを提供することが狙いです。興味深いのはアーキテクチャだけではありません。Cloudflare自身が、最初のプロトタイプはRustで書かれた独立系オープンソースブラウザObscuraに着想を得たと述べています。

ただしObscuraには、もう一つの目標があります。任意で有効にできるステルスモードは、自動化ブラウザに典型的な特徴を隠そうとします。Kitesurfはそうしません。反対にBrowser Runは、送信requestをCloudflareの自動化として運営者が識別し、暗号学的に検証できるよう、意図的に印を付けます。

そこで厄介な疑問が生じます。Cloudflareは優れたオープンソースのアイデアを取り込み、Bot検知にとって都合の悪い部分を取り除き、自社で制御できる製品にしたのでしょうか。

短い答えはこうです。この批判は、現実の利益相反を一部正しく指摘しています。しかし、それがKitesurf誕生の理由だったという証拠は、現時点ではありません。 技術的にも戦略的にも、これはObscuraを無難に作り直しただけのものではありません。

検証の根拠と限界

本分析は、2026年8月6日付のCloudflareの記事、現在のBrowser Runドキュメント、そして2026年8月25日に行った公開Obscuraリポジトリのコードと文書の確認に基づきます。当時の最新版Obscura 0.2.1は、その2日前に公開されていました。特にアーキテクチャ、ネットワーク経路、ステルス実装、セキュリティ上の注意、リリースノート、別リポジトリのベンチマークを確認しました。

Kitesurfに対する独自の性能測定や、本番環境のBot challengeに対する試行は行っていません。したがって検知回避性能についての記述は、実装、文書化された制約、公開されたベンダーのベンチマークに基づきます。そこからCloudflareの戦略的意図を読み取る箇所は、同社が確認した事実ではなく、明示的に筆者の評価です。

AIブラウザに必要な技術的能力

従来のブラウザは巨大な汎用機械です。複雑なCSSを描画し、メディアを再生し、GPUでグラフィックを高速化し、拡張機能を管理し、プロファイルを同期し、多数のタブを何時間も安定して維持します。商品ページを読み、ボタンを探し、スクリーンショットを撮るだけのエージェントにとって、その多くは余分な負担です。

それでも、エージェントにはHTTPクライアント以上のものが必要です。現代のページは、最初にほとんど空のHTML骨格だけを返すことがよくあります。JavaScriptが実際の内容を構築し、追加のrequestを開始し、DOMを変更し、ユーザー操作に反応します。実用的なAIブラウザには、最低でも次が必要です。

• JavaScript runtime
• 十分な互換性を持つDOM
• ネットワーク、cookie、originのロジック
• マウス、キーボード、フォーム、ナビゲーションのevent
• エージェントと自動化ツール向けのインターフェース
• 用途に応じたlayout、スクリーンショット、PDF出力
• 外部コード、実行時間、メモリ、ネットワークアクセスに対する厳格な制限

KitesurfとObscuraは、Chromiumをエージェントに必要な部分へと縮小します。どちらもCDPを提供するため、PlaywrightやPuppeteerのような既存ツールをまったく新しいインターフェース向けに作り直す必要はありません。どちらも本物のJavaScriptを実行し、動的なDOMを構築します。また、起動パラメータを変えてChromiumを呼び出すだけではなく、独自のレンダリング経路を開発しています。

つまり、これらは自動化のためのブラウザエンジンです。言語モデル、タスク計画、権限、エージェントが操作を実行してよいかという判断は、その上の層に残ります。この分離は重要です。高速なブラウザでも、信頼できないエージェントが安全になるわけではありません。

Kitesurf：Workersで構成されたブラウザ

CloudflareはKitesurfを単一の実行ファイルとして構築していません。エンジンは、異なる信頼境界を持つ複数のWorkerコンポーネントに分散しています。

Engine、PageScript、PageRenderer

Engine Workerは公開された入口です。CDP接続とREST呼び出しを受け取り、セッション状態を保持します。そのため既存のCDPクライアントは、Chromeに近い方法でKitesurfと通信できます。

各ページと分離されたiframeについて、KitesurfはPageScript Workerを起動します。ここには新しいグローバルJavaScriptコンテキストとページのDOMが与えられます。HTMLとCSSはBlitzとStyloのコンポーネントで処理され、通常のJavaScriptとWebAssemblyはWorkerのV8 isolate内で動きます。

注目すべき例外はeval()です。Cloudflare Workersはセキュリティ上の理由から、動的なコード評価をネイティブでは許可しません。そのためKitesurfは、Rust製ECMAScriptエンジンBoaを使い、Worker環境内でこうした呼び出しを実行します。現実的な解決策ですが、難しい互換性の境界が生じます。コードの一部はV8で直接動き、動的に生成されたコードは、動作が異なる可能性のある第二のJavaScriptエンジンを通ります。

PageRenderer WorkerはスクリーンショットとPDFのピクセルを生成します。sceneの記述を受け取り、ラスタライズして結果を返します。Rendererは重要なページ状態を保持しません。停止やクラッシュが起きれば、engineはそれを破棄してレンダリング処理を再開できます。

ネットワークへ接続できるのは一つのコンポーネントだけ

セキュリティ面で特に興味深いのがSandboxOutbound Workerです。インターネットからresourceを取得できるのは、このコンポーネントだけです。CORSルールを適用し、ページごとにcookieを分離して管理し、responseをフィルターし、ブラウザらしいheaderを追加します。PageScriptとEngineに無制限のネットワークアクセスがそのまま与えられるわけではありません。

これは、自作のエージェント環境との重要な違いです。ブラウザエージェントが開くのは、人間がすでに信頼したページだけではありません。検索結果、外部文書、さらには改ざんされたpromptのリンクをたどることもあります。ページアクセスはすべてuntrusted inputです。したがってネットワーク境界は最適化ではなく、セキュリティモデルの一部です。

Kitesurfは可能な限りstatelessなコンポーネントを使います。状態を持たないものは、障害時に終了し、再起動できます。短時間で変動の大きいエージェントworkloadに、このモデルはWorkerプラットフォームとよく合います。

Cloudflareは、215,000件を超えるWeb Platform Testsに合格し、DOM、HTML、CSS、SVG、Selection、XHRを幅広くカバーしたと報告しています。数字は印象的ですが、それだけで成熟度を示すものではありません。WPTの各ファイルには多数のsubtestがあり、Cloudflareは完全な合格率、Kitesurfのコード、正確なテスト構成を公開していません。そのためObscuraの公開WPT runnerやChromiumの互換性と正確には比較できません。発表時のKitesurfは開発開始からわずか12週間で、現在もbetaです。

効率は高いが、速くはない

Cloudflare自身の測定からは、経済的な魅力が見えます。14 URLのコーパスを5回実行した結果、CloudflareによればKitesurfはスクリーンショット処理で、warm Chromium poolよりCPUを3.1分の1、メモリを4.7分の1に抑えました。HTML抽出ではCPUが3.8分の1、メモリが7分の1でした。

一方、レイテンシは悪化しました。スクリーンショットの中央値は1.8倍、HTML抽出は1.7倍の時間を要しました。Kitesurfが主に節約するのは、タスクごとのインフラです。単一ページを最速で処理する競争に自動的に勝つわけではありません。

これらは有用な数字ですが、独立したベンチマークではありません。コーパス、環境、比較対象はCloudflare自身が選んでいます。warm Chromium poolも、多数ある運用方式の一つにすぎません。測定結果はアーキテクチャの可能性を示しますが、任意の実運用workloadでKitesurfが安価、または信頼性に優れることまでは証明していません。

Obscura：独立したRustブラウザ

Obscuraは同じ基本思想を、ローカルまたはセルフホストで動かすオープンソースプロジェクトとして追求しています。コードはApache 2.0ライセンスです。最新版0.2.1は2026年8月23日に公開され、CLI、CDP、ブラウザロジック、JavaScript、DOM、ネットワーク、MCP、レンダリングを担う複数のRust crateで構成されています。

V8、独自DOM、CPUレンダリング

Obscuraはdeno_coreを通じてV8を組み込みます。ブラウザAPIは、大規模なJavaScript bootstrap層とRust operationで提供されます。DOMは独自実装です。layoutとレンダリングには、Taffy、独自のブラウザロジック、CPUベースのpaint経路などを使います。

ObscuraもCDPを利用し、MCP serverを備えます。エージェントはページを開き、DOM snapshotを取得し、クリックやフォーム入力、JavaScript実行、スクリーンショット、PDF作成を行えます。実用上の利点は制御権です。engineはローカル、container、自社インフラで動かせます。Cloudflareアカウントは技術的な前提ではありません。

その代償は自前運用です。アーキテクチャ文書によると、一つのプロセス内のページはV8 isolateを共有し、JavaScript処理はglobal lockで直列化されます。watchdogと厳格なdeadlineにより、一つのページがプロセスを永久に止めることを防ぎます。それでもセキュリティ文書は限界を正しく記しています。これらの保護はOSレベルの分離に代わるものではありません。敵対的なページを大規模に処理する場合は、ネットワークを制限したcontainerまたは仮想マシン内でObscuraを動かすべきです。

これは小さな注意点ではありません。RustはV8、ネイティブdependency、FFI境界のすべての脆弱性を防ぐものではありません。インターネット上の任意のJavaScriptを実行するプロセスは、依然として高リスクなサービスです。

ステルスモードはUser-Agentだけではない

Obscuraで最も興味深い違いは、任意のstealth buildです。通常のreqwest transportを、BoringSSLを使うwreqに置き換え、Chromeに似たTLS handshakeを再現します。ClientHello、ALPN、cipher suiteの順番も対象です。Botシステムは、見えるUser-Agentだけを調べるわけではないため重要です。HTTP header、TLS fingerprint、JavaScriptの特性が同じブラウザ像を語っているかを比較します。

JavaScript側でも、Obscuraはその一貫性を維持しようとします。コードはnavigator.userAgentData、platform値、画面、GPU、Canvas、audio、batteryなどのfingerprint surfaceを再現します。navigator.webdriverは見えないままです。Obscura内部のプロパティは列挙から隠され、ネイティブ関数はFunction.prototype.toString()で本物のブラウザ関数のように見えることを目指します。

event.isTrustedも区別して扱われます。ページコードがnew Event()で生成したeventはuntrustedのままです。CDP経由の入力は、ブラウザが生成したeventとして印を付けられます。すべてにtrueを返せば簡単に検知され、通常のWeb挙動としても誤りです。

ステルス経路はナビゲーション、subresource、fetch()、XHRをカバーします。これは重要です。メイン文書だけがChromeらしいTLS fingerprintを使い、後続のAPI requestが突然Rust libraryのように見えれば、Botシステムが探す矛盾そのものが生まれます。

さらにObscuraは、既知のtrackingおよびfingerprinting endpointをブロックします。ブラウザ特性はセッションごとに変えられます。ただし文書自身が、不整合な組み合わせを警告しています。IP地域、タイムゾーン、位置情報、JavaScript profile、TLS fingerprintは一致していなければなりません。ローテーションは透明マントではありません。一つのexit IPが異なる端末IDへ頻繁に切り替われば、むしろ目立つ可能性があります。

Obscuraは本当にBot検知をうまく回避できるのか

Kitesurfとの直接比較では、Obscuraが明らかにanti-detectionを重視していることがコードと文書から分かります。しかし、それだけで現代的なBot対策を確実に回避できるとは言えません。

プロジェクトは自らの主張を明確に限定しています。ステルスモードが通過を目指すのは、TLS fingerprintまたはUser-Agentに対する単純な検査です。文書によれば、次には対応しません。

• Cloudflareの対話型challenge
• DataDomeおよびAkamai Bot Managerのactive challenge
• CAPTCHA
• IPベースのrate limit

したがって、ObscuraがBot検知を回避できるという話は、狭い意味でのみ正しいと言えます。一般的なheadless clientらしく見えないよう工夫しますが、万能のchallenge bypassではありません。

現代のBotシステムはブラウザfingerprint以外も評価します。IP reputation、ASN、request頻度、ナビゲーション、マウスとキーボードのパターン、cookie履歴、アカウント行動、多数のセッション間の関係を見ます。千件のrequestがデータセンターから同じリズムで届けば、navigatorを完璧に再現してもほとんど役に立ちません。

公開されているObscuraのベンチマークにも注意が必要です。別リポジトリにはWPT、obstacle course、実サイト、信頼性、ステルス一貫性を対象にした再現可能なテストスクリプトがあります。マーケティング表だけよりは優れています。しかしstealth suiteはローカルで動作し、主に自ら定義したfingerprintの内部整合性を検査します。大規模な商用Botシステムがtrafficを人間として受け入れる証拠ではありません。

開発速度も考慮が必要です。リリースノートによれば、Obscura 0.2.0から0.2.1まで、2週間あまりで122 commitがありました。活発な開発を示す一方で、まだ大きく変化している領域があることも示します。若いブラウザエンジンでは、一度のデモ成功を本番利用可能性の証明にしてはいけません。

Cloudflareは見えないBotを望んでいない

Kitesurfの状況は根本的に異なります。Cloudflare Browser Runは、送信requestに変更できないheaderを付けます。さらにWeb Bot Auth signatureにより、対象serverはrequestがCloudflareのブラウザインフラから来たことを暗号学的に検証できます。

CloudflareのFAQは明確です。Browser RunのrequestはCloudflareによって常にBot trafficとして検知されます。許可するかブロックするかはWebサイト運営者が決めます。自分のzoneを自動テストする場合は、WAFルールでこのtrafficを明示的に許可できます。

KitesurfはBrowser Run内の選択肢として動きます。したがって、偽装がないことを単なる技術的遅れと見るのは誤りです。透明なBot IDは製品モデルの一部です。Cloudflareはブラウザ自動化基盤と同時に、Webサイト運営者がBotを検知、制御するセキュリティ製品も提供しています。その制御を意図的に回避する自社ブラウザは、このモデルを直接損ないます。

Cloudflareは、Kitesurfが現在、本物のTLS fingerprintを使ったbot-challenge handshakeを処理できないことも明言しています。そのようなサイトには、引き続きChromiumベースの標準Browser Runを推奨しています。しかし、このChromium trafficもCloudflareのheaderとsignatureにより自動化として識別可能です。

この判断には利点があります。運営者は自由に偽装できるUser-Agentではなく、検証可能なIDを得ます。正当なBotを個別に許可、測定、制限でき、悪用を事業者とインフラに結び付けられます。

一方で批判もできます。ユーザーに代わって公開ページを読む個人エージェントは、そのユーザーのブラウザより、商用crawlerに近いものとして技術的に扱われます。サイト運営者はCloudflareのエージェントを簡単に遮断できます。個人の調査を自動化しているだけでも、ユーザーは人間らしい通常セッションへ切り替えられません。

それでもCloudflareが独自に作った理由

Cloudflareは、Obscuraが最初の着想を与え、まずAIエージェントの助けを借りてWorkersへ移植したと書いています。ほとんど動かなかったproof of conceptからKitesurfが生まれました。これは明確な帰属表示であり、アイデアが自社研究所で生まれたかのような主張ではありません。

しかしCloudflareがステルス機能を理由にObscuraを捨てたという説は、Kitesurfの記事にもBrowser Runの文書にもありません。より明確に見える理由が複数あります。

Obscuraはセルフホストするプロセスとして作られています。Kitesurfは分散Workerアプリケーションです。Cloudflareはisolate、Service Bindings、Worker-RPC、自社のoutbound sandbox、既存のBrowser Run APIを使おうとしています。それにはRust binaryをどこかで起動するだけでは足りません。

Cloudflareには、ライフサイクル、resource消費、telemetry、障害時の挙動が自社基盤に適したengineも必要です。問題のあるRPCの後に破棄できるstateless rendererは、共有V8 isolateとglobal lockを持つプロセスとは異なる運用アーキテクチャです。

さらにKitesurfは製品部品です。CDPによりクライアント側は比較的portableですが、サービス自体はBrowser RunとCloudflare Workersに強く結び付いています。Cloudflareは将来Kitesurfをオープンソース化し、顧客自身のCloudflareアカウントにdeploymentできるようにすると約束しています。しかし現在、コードは未公開です。Obscuraならアーキテクチャ、セキュリティ境界、実装を今すぐ検証できます。Kitesurfについて現在評価できるのは、公表された設計、文書、観察可能な挙動だけです。

ここには正当な批判があります。Cloudflareはオープンなアイデアと既存プロジェクトから利益を得る一方、自社の発展版は当初非公開です。Apache 2.0はそれを許し、CloudflareもObscuraを明記しています。法的には問題ありません。それでも近日公開を約束する企業にとって、最終的に問われるのは公開されたコードであり、「soon」という言葉ではありません。

二つのブラウザ、二つの制御モデル

主な違いは速度だけでは語れません。

Kitesurfは単にObscuraより優れたものではなく、異なる運用課題を解きます。Cloudflareは、自社基盤上で大量の短命なブラウザタスクを安全かつ低コストに処理したいと考えています。Obscuraは、運営者が自ら管理でき、必要なら検知されにくくできる独立ブラウザエンジンを目指します。

未解決のセキュリティ問題はブラウザの上にある

両プロジェクトはWebページの分離に多くを投資しています。必要なことですが、AIブラウザ最大のリスクは解決しません。Webページがエージェント自体を操作できることです。

DOM内のprompt injection文は、V8 sandbox escapeを起こす必要がありません。モデルがそれを命令と解釈し、内部データを漏らし、誤ったリンクを開き、強力なtoolを使えば十分です。ネットワーク分離はブラウザインフラを保護しますが、ユーザーの意図を自動的には守りません。

本番利用できるエージェントブラウザには、追加の制御が必要です。

• 無関係なタスクごとに分けたブラウザcontext
• セッションごとの最小限のsecretと短命token
• login、購入、upload、データ変更前の明確な承認
• ページJavaScript外部でのdomainおよびegressルール
• モデル判断、ブラウザ操作、結果を結ぶlog
• 予期しないナビゲーションやdownloadを安全に停止する経路
• ページ内容がsystem instructionになることへの防御

CloudflareはPrompt InjectionとTool Safetyを優先課題に挙げますが、Kitesurfの記事は主にブラウザ分離を説明します。Obscuraはブラウザtoolを提供しますが、上位エージェントの認可は担いません。どちらを使う場合も、この隙間は利用者自身が埋める必要があります。

用途ごとに適したモデル

自社が許可したページのスクリーンショット、HTML抽出、文書生成にはKitesurfが興味深い選択肢です。Workerアーキテクチャは運用負担を減らし、自社環境では透明なBot IDも障害になりません。運営者はBrowser Runを明示的に許可し、追跡可能な送信元を得られます。

ローカル研究、内部自動化、厳格なデータ管理が必要な環境ではObscuraが魅力的です。ただしengineは適切に制限したruntimeへ置く必要があります。containerまたはVM、制限されたegress、分離したcredential、有効な--obey-robotsは、後付けの追加機能であってはなりません。

長時間の認証済みセッション、メディア、WebGL、複雑なBot対策のあるページには、本物のChromiumブラウザが現実的な選択肢であることが多いでしょう。CloudflareもKitesurfについて明言しています。小さなブラウザが自動的に互換性の高いブラウザになるわけではありません。

ステルス機能は、正当で許可されたテスト、またはプライバシー重視の自動化にのみ使うべきです。技術的にページへアクセスできることは、法的な問題や、そのルール、rate limit、resourceを尊重しているかという問題への答えにはなりません。

結論

Obscuraは、エージェント向けブラウザが必ずしもChromiumである必要はないことをCloudflareに明確に示しました。Kitesurfはその基本思想を取り込み、説得力ある分離、低いresource消費、Browser Runとの直接統合を備えたWorker-nativeアーキテクチャにしました。

Bot検知についてObscuraがより積極的なのは確かです。ステルスモードはKitesurfよりもTLS、HTTP、JavaScriptの各surfaceを明確に再現します。それでも「回避性能が高い」という表現は大きすぎます。確認できるのは、単純なfingerprint検査に対する偽装の改善です。プロジェクト自身が、現代的な対話型challengeの回避を否定しています。

Cloudflareの抑制は単なる技術的未熟さではありません。Browser RunはBotとして識別されるべき製品です。削除できないheaderとWeb Bot Authは、その透明性を製品機能にします。反対側でBot Managementを販売する企業には整合的です。しかし同時に、Kitesurfがユーザーのために動く独立ブラウザになることも妨げます。

したがって最も強い批判は、CloudflareがObscuraを単純にコピーしたというものではありません。両者のアーキテクチャと運用モデルは大きく異なり、Cloudflareも着想源を公に認めています。

より強い批判はこうです。Cloudflareは、ID、runtime、分散、アクセスがすべてCloudflareの制御モデルに適合するAIブラウザを作っています。運営者には合理的かもしれません。しかし、開かれたユーザー中心のエージェントWebにとって、それは一つの答えにすぎません。

Kitesurfが本当に公開されるのか、公開コードはどこまで完全か、Cloudflareのプラットフォーム外でも有意義に運用できるかは、まだ分かりません。それまでは、Obscuraがより開かれた実験であり、Kitesurfがより統合された製品です。

それでは、また次回。
Joe