Cloudflare Kitesurfとは？AI向け新ブラウザの導入・使い方

この記事は、Kitesurfを「話題の名前」で終わらせず、次の順に実際に試せるところまで案内します。

• 何が新しく、従来のBrowser RunやChromiumと何が違うのか
• CPU・メモリを減らせた仕組みと、その代わりに失ったもの
• インストール不要のPlaygroundから、REST API、MCP、Puppeteerまでの導入手順
• 料金、利用上限、トークン管理、実運用で詰まりやすい点

Kitesurfとは何か：Browser Runの中で選べる新エンジン

まず製品名の関係を整理します。

つまり「Browser RunからKitesurfを使う」が正確です。Quick ActionsやCDP endpointへ browser=kitesurf を加えると、既定のChromiumではなくKitesurfが選ばれます。

Cloudflareが従来提供していたBrowser Run（旧Browser Rendering）は、コンテナでChromiumを起動するサービスです。Kitesurfは別物で、ブラウザそのものがWorkers上の複数コンポーネントとして動きます。Cloudflareの発表によると、着手から発表まで約12週間。AIエージェントも実装を加速し、人間がアーキテクチャとレビュー、Web Platform Tests（WPT）による合格条件を担当した点も、このプロジェクトを象徴しています。

AI開発の前提から知りたい方は、先にAIエージェント入門を読むと位置づけをつかみやすくなります。

なぜAI専用ブラウザが必要なのか

人間とAIでは、ブラウザに求めるものが違います。

人間は複数タブを開き、拡張機能を使い、動画を見て、ピクセル単位の見た目や滑らかなスクロールを気にします。一方、エージェントが欲しいのは「見出しは何か」「購入ボタンはどの要素か」「Consoleにエラーがあるか」「このページをMarkdownやJSONへ変換できるか」といった機械可読な状態です。

それでも、単純なHTTP取得だけでは足りません。現代のサイトはJavaScript実行後に本文やボタンが現れ、クリック、フォーム入力、Cookie、CORS、iframeまで含めて初めて「ページ」として成立します。Kitesurfは、Chromiumの人間向けオーバーヘッドを抱えず、このエージェントに必要な部分を実装する狙いです。

この数値はCloudflare自身のベンチマークであり、独立した第三者検証ではありません。しかも比較対象のChromiumはwarm pool、Kitesurfはcold software rendererです。結論は「常に高速」ではなく、CPUとメモリは大幅に少ないが、現在の実時間はChromiumより遅いです。大量の短い処理を並べるサービスには魅力的ですが、1件の待ち時間を最優先する用途ではChromiumが勝つ可能性があります。

どう動くのか：3つの中核と1つの出口

Kitesurfは大きく、Engine、PageScript、PageRenderer、SandboxOutboundに分かれます。

HTMLとCSSの解析にはRust製のBlitzとFirefox由来のStylo、描画には blitz-paint、Workersが直接許可していない eval の処理にはRust製JavaScriptエンジンBoaが使われています。Rust部分はWebAssemblyへコンパイルされ、ページのJavaScriptはV8 isolate内で動きます。

重要なのは、単に軽量ライブラリを寄せ集めたのではなく、**「すべてのページは信頼できない入力」「セッションは毎回まっさら」**を設計原則にしたことです。ページごとにCookie jarを分け、ネットワーク出口をSandboxOutboundへ集約し、失敗した描画コンポーネントは使い捨てます。これは、未知のサイトを次々に開くAIエージェントの脅威モデルに合っています。

ただし、分離されたブラウザでも、ページ内の文章によるプロンプトインジェクションや、エージェントが誤って購入・送信する問題までは自動で消えません。書き込み操作には人間の確認を残し、APIトークンや秘密値の扱いはAIエージェントの秘密情報保護と同じく最小権限で設計してください。

Web互換性はどこまであるか

公式Docsは、2026年8月7日更新時点で23万5,000超のWPT subtestに合格したとしています。発表Blogにある21万5,000超から、公開直後も対応が増えた形です。主要分野の掲載値は次の通りです。

数字は高く見えますが、WPTはWeb標準への適合度を測るもので、実在する全サイトが正しく動く保証ではありません。Cloudflareが動作例として挙げるのは、TodoMVCの各実装、Wikipedia、Hacker News、Cloudflare Blog、Cloudflare Dashboardの多くの部分です。

逆に、現時点でKitesurfを選ばない方がよい条件も明確です。

• 動画再生やWebGLが必要
• 本物のTLS fingerprintを使ったbot challengeのhandshakeが必要
• 認証状態を保った長時間セッションが必要
• スクリーンショットやPDFでピクセル単位の一致が必要
• 未実装のCDP commandへ依存する

この場合はBrowser Runの既定Chromiumを使います。Kitesurfは「Chromiumの完全互換・完全上位版」ではありません。

導入方法1：Playgroundならインストール不要

最初に試す場所は公式Kitesurf Playgroundです。

1. Playgroundを開く
2. 調べたい公開URLを入力する
3. Kitesurfでの表示を確認する
4. DevToolsでDOM、Console、Networkを確認する
5. Memory panelでisolateとframeのWebAssembly使用量を見る

ここで重要なのは、見た目だけで合否を決めないことです。AIが本文抽出に使うならDOMに必要な情報があるか、操作に使うなら対象ボタンが取得できるか、ConsoleやNetworkに失敗がないかを確認します。

Playgroundで崩れるサイトへ、いきなり自動化コードを書く必要はありません。そのサイトだけChromiumへ戻すルーティングを最初から用意した方が堅実です。

導入方法2：REST APIでスクリーンショットを撮る

単発のスクリーンショット、PDF、HTML・Markdown抽出にはBrowser RunのQuick Actionsが向きます。Workerをデプロイする必要はなく、HTTPS APIを1回呼ぶだけです。

事前準備

1. Cloudflareアカウントを作る
2. DashboardでAccount IDを確認する
3. Custom API Tokenを作り、Browser Rendering - Edit 権限だけを与える
4. トークンを環境変数へ保存する

PowerShellでは、現在のターミナルだけに値を入れて試せます。実値は記事、Git、チャット、スクリーンショットへ貼らないでください。

$env:CF_ACCOUNT_ID = "<ACCOUNT_ID>"
$env:CLOUDFLARE_API_TOKEN = "<API_TOKEN>"

$headers = @{
  Authorization = "Bearer $env:CLOUDFLARE_API_TOKEN"
  "Content-Type" = "application/json"
}
$body = @{ url = "https://example.com" } | ConvertTo-Json
$uri = "https://api.cloudflare.com/client/v4/accounts/$env:CF_ACCOUNT_ID/browser-run/screenshot?browser=kitesurf"

Invoke-WebRequest `
  -Method Post `
  -Uri $uri `
  -Headers $headers `
  -Body $body `
  -OutFile "screenshot.png"

# 試し終えたら現在のPowerShellセッションから消す
Remove-Item Env:CF_ACCOUNT_ID
Remove-Item Env:CLOUDFLARE_API_TOKEN

成功すれば、現在のフォルダに screenshot.png ができます。Kitesurfを選ぶ本質は、URL末尾の browser=kitesurf です。これを外すと既定のChromium経路になります。

Quick Actionsにはスクリーンショット以外にも、HTML、PDF、Markdown、snapshot、accessibility tree、selector指定のscrape、AIによるJSON抽出、link一覧、crawlがあります。ただしKitesurfとの組み合わせで対象サイトが正しく動くかは、個別に確認してください。

導入方法3：MCPでClaude CodeやCursorから使う

Kitesurfの面白さが出るのは、AIエージェントが直接ブラウザを操作するときです。Browser RunはCDP endpointを公開し、chrome-devtools-mcp がMCPのtool callをCDP commandへ変換します。

公式の一般MCPガイドはClaude Desktop、Claude Code、Cursor、OpenCodeを対象にしており、KitesurfのページはOpenCode用例を掲載しています。Claude CodeやCursorでも、mcpServers 形式のendpointをKitesurf用に差し替える考え方は同じです。

前提は次の3点です。

• Node.js 20.19以上
• MCP対応クライアント
• Browser Rendering - Edit だけを持つ専用APIトークン

{
  "mcpServers": {
    "kitesurf": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"
      ]
    }
  }
}

設定ファイルの場所はクライアントごとに異なります。一般ガイドでは、Claude Desktopは claude_desktop_config.json、Claude Codeは ~/.claude.json、Cursorは ~/.cursor/mcp.json が案内されています。Windowsでは ~ がユーザープロファイルを指します。

この公式形式はトークンを設定ファイルへ入れるため、そのファイルをGit管理せず、端末を共有せず、Kitesurf専用の最小権限トークンを使ってください。漏えいが疑われたら、設定から消すだけでなくCloudflare側で即時ローテーションします。MCP自体が初めてなら、MCP入門ガイドも併せて確認してください。

接続後は、たとえば次のように依頼できます。

https://example.com を開き、ページタイトルと主要見出しを取得してください。
Console errorと失敗したNetwork requestを一覧にし、読み取りだけで原因を説明してください。
現在のページをスクリーンショットにして、DOM上のCTA文言と一致するか確認してください。

最初は閲覧、抽出、検査だけに限定してください。フォーム送信、購入、公開、削除などは「実行直前に人間へ確認する」境界をプロンプトとクライアント権限の両方に置きます。

導入方法4：PuppeteerからCDP接続する

決まった手順を再現可能なコードにしたい場合は、MCPよりPuppeteerが向いています。ローカルにChromium本体を入れる必要はなく、CDP clientだけの puppeteer-core を使います。

New-Item -ItemType Directory kitesurf-demo
Set-Location kitesurf-demo
npm init -y
npm install puppeteer-core

$env:CF_ACCOUNT_ID = "<ACCOUNT_ID>"
$env:CF_API_TOKEN = "<API_TOKEN>"

import puppeteer from "puppeteer-core";

const accountId = process.env.CF_ACCOUNT_ID;
const apiToken = process.env.CF_API_TOKEN;

if (!accountId || !apiToken) {
  throw new Error("CF_ACCOUNT_ID と CF_API_TOKEN を設定してください");
}

const browserWSEndpoint =
  `wss://api.cloudflare.com/client/v4/accounts/${accountId}` +
  "/browser-run/devtools/browser?browser=kitesurf";

const browser = await puppeteer.connect({
  browserWSEndpoint,
  headers: { Authorization: `Bearer ${apiToken}` },
});

try {
  const page = await browser.newPage();
  await page.goto("https://example.com", { waitUntil: "domcontentloaded" });

  console.log({
    title: await page.title(),
    h1: await page.$eval("h1", (element) => element.textContent?.trim()),
  });

  await page.screenshot({ path: "example-kitesurf.png" });
} finally {
  await browser.close();
}

node .\script.mjs

# 試し終えたら現在のPowerShellセッションから消す
Remove-Item Env:CF_ACCOUNT_ID
Remove-Item Env:CF_API_TOKEN

公式Kitesurf Docsは、既存のPuppeteer、Playwright、chrome-remote-interface、MCP/CDP対応エージェントから接続できるとしています。ただしKitesurfが実装するCDPはまだsubsetです。接続方式が互換でも、すべてのCDP commandやページ機能がChromiumと同じとは限りません。

料金と利用上限

Kitesurfは、2026年8月13日時点でベータ中は無料です。ただし公式Docsは「per-account limitsの範囲内」としており、将来の課金体系は未確定です。

一方、Kitesurfが合わないときに戻す通常のChromium版Browser Runには、次の一般料金があります。

Workers Paidの技術上限は同時120 browser/accountですが、料金に含まれる同時数は月平均10です。「起動できる上限」と「追加料金なしの枠」は同じではありません。Quick Actionsの応答には X-Browser-Ms-Used headerが入り、Dashboardと併せて使用時間を追えます。

料金と上限は変更されやすいため、Kitesurfを本番採用する判断は、ベータ終了後の価格が出てから更新するのが安全です。

KitesurfとChromiumの使い分け

迷ったら、次の基準で選べます。

実運用では、全面的にどちらかへ寄せるより、Kitesurfを第一経路、互換性エラー時だけChromiumへfallbackする構成が現実的です。ただし自動fallbackは同じ操作を二重実行する危険があります。閲覧・抽出は再試行しても、送信・購入・公開など副作用のある操作は自動再試行しないでください。

よくある詰まりどころ

Playgroundでは動くのに自動化が失敗する

描画できることと、使いたいCDP commandが実装されていることは別です。ConsoleとNetworkに加え、selector、待機条件、redirect先を確認します。networkidle は通信が続くサイトで終わらないことがあるため、最初は domcontentloaded と必要要素の待機を組み合わせます。

401または403になる

Account ID、tokenの有効期限、Browser Rendering - Edit 権限を確認します。token値はエラー報告へ貼らず、疑わしい場合は再発行してください。接続先が browser-run か、Kitesurf指定の browser=kitesurf が付いているかも確認します。

見た目がChromiumと違う

現時点では仕様です。WPT coverageが高くてもpixel-perfectではなく、PageRendererの改善は継続中です。視覚回帰テストの基準画像をChromiumと共有せず、Kitesurf専用の許容差を設けるか、画像品質が要件ならChromiumを使います。

ログインやCAPTCHAで止まる

Kitesurfは実TLS fingerprintを使うbot challengeや長時間の認証状態に向きません。また自動化を隠してbot判定をすり抜けるための製品でもありません。対象サイトの利用規約、robots.txt、API提供有無を確認し、正式APIがあるならそちらを優先します。

まとめ：まず5分、Playgroundで触る価値がある

Cloudflare Kitesurfは、ブラウザを人間の画面ではなく、AIエージェントの実行基盤として再設計した試みです。Blitz、Stylo、Boa、WebAssembly、V8 isolate、Workers RPCを組み合わせ、DOM・JavaScript実行・描画・CDP接続をChromiumなしで成立させています。

現時点の評価は明快です。

• 魅力：CPU・メモリが小さく、短時間・大量・ステートレスなエージェント処理へ向く
• 互換性：23万5,000超のWPT subtestに合格したが、実サイトとCDPは要検証
• 弱点：Chromiumより実時間が遅く、動画、WebGL、bot challenge、長時間認証、pixel-perfect描画は不向き
• 始め方：Playground → Quick Actions → MCPまたはPuppeteerの順なら迷いにくい

最初の一歩はインストールではありません。Kitesurf Playgroundへ、普段AIに読ませたい公開ページを1つ入れてみてください。DOM、Console、Networkまで見て問題がなければ、この記事のPowerShell例で1枚スクリーンショットを取り、その後にMCPへつなぐ。それだけで、この新しいブラウザが自分のワークフローに効くかを判断できます。