Cloudflare Kitesurf実測：AI専用ブラウザで海外AI情報の自動収集は組めるのか

2026年8月6日、CloudflareがAIエージェント専用ブラウザ「Kitesurf」を発表した。「エージェント専用のブラウザ」と言われてもピンとこないが、要は「人間が見るためではなく、プログラムが読むためのブラウザ」をCloudflareのサーバー側で動かしてくれるサービスだ。

発表から5日、日本語の実測レポートがまだ見当たらないので、実際にAPIを叩いて確かめた。題材は「海外AI情報の自動収集」。Hacker News・Anthropic・DeepMind・TechCrunch・HuggingFaceなど7サイトに対して実測し、どこが通り、どこで弾かれ、何が集まったかをそのまま書く。

数値・仕様は執筆時点（2026年8月11日）の実測と各社公式ドキュメントに基づく。ベータ版なので、料金や制限は変わる可能性が高い。

要点（先に結論）

• KitesurfはCloudflare Workers上で動く使い捨てブラウザ。curl一発で「JSレンダリング¹済みのページ」をMarkdownやPNGで受け取れる。自前でブラウザを飼う必要がない
• 実測では7サイト中5サイト成功。TechCrunchのような大手メディアも通った。一方でOpenAIには403で弾かれ、「HTTP 200なのに中身が空」という罠パターンもあった
• APIは8種類。/markdown /screenshot /pdf /json /content /crawl は動くが、/links /scrape /snapshot はKitesurf非対応（実測）
• 1回の巡回（5サイト・計23.9秒）で見出し136本ぶんのMarkdown 96KBが集まった。費用はベータ期間中のため0円
• Chromiumと比べて速くはない（約1.8倍遅い）が、CPU・メモリ消費は3〜7分の1。「大量に安く」が身上
• ベータのレート制限は厳しく、連続で叩くと2件目から429。実運用は間隔を空ける前提で設計する
• ボット対策が固いサイト・ログインが要るサイト・E2Eテストには向かない

Kitesurfは何者か（仕組み）

Kitesurfは、Cloudflareのサーバーレス実行環境Workers（V8 isolate²）の上で動くブラウザエンジンだ。Chromiumを載せたのではなく、Rust製の部品——レンダリングエンジンのBlitz、FirefoxのCSSパーサStylo、JSエンジンのBoa——を組み合わせて、タブも拡張機能も持たない「読むためだけのブラウザ」として12週間で作られた。標準適合性はWeb Platform Tests³で21.5万件超をパスしており、「おもちゃ」ではない。

利用者から見た構図はシンプルで、従来との違いはこうなる。

これまで「JSで描画されるサイトを機械で読む」には、自分のマシンかサーバーでヘッドレスブラウザ⁴を動かすしかなかった。KitesurfはそこをAPI一発に置き換える。ブラウザのプロセス管理・メモリ・アップデートという運用がまるごと消える。

出典: Cloudflare Blog: Introducing Kitesurf・Kitesurf · Browser Run docs

なぜ「安い」のか（そして速くはない）

Cloudflare公式のベンチマークによると、スクリーンショット取得やHTML抽出のような典型タスクで、KitesurfはChromium比でCPU・メモリを3〜7分の1しか使わない。

一方で、実行の所要時間はChromiumより約1.7〜1.8倍遅い。KitesurfのJSエンジン（Boa）にはJIT⁵がないためだ。つまりこれは「速いブラウザ」ではなく、同じ計算資源で何倍も多くのページを並列に読めるブラウザだ。1件の速さより件数のコストが効く用途——つまり巡回・収集——に合わせた設計になっている。

出典: Cloudflare Blog: Introducing Kitesurf（ベンチマーク数値は公式ブログの14 URLコーパスによる計測）

実測1: 7サイト、どこが通ってどこで弾かれたか

使い方は、Cloudflareダッシュボードで APIトークン（Account → Browser Run → Edit 権限）を発行して、エンドポイントを叩くだけ。browser=kitesurf パラメータを外すと従来のChromium版で実行される。

curl -X POST \
  "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/markdown?browser=kitesurf" \
  -H "Authorization: Bearer <API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://news.ycombinator.com"}'

海外AI情報の収集先として使いたい7サイトに、Markdown抽出APIで疎通を確認した結果がこれだ。

予想が外れた点がふたつある。

TechCrunchが普通に通った。 大手メディアはボット対策で全滅すると踏んでいたが、33本の記事見出しがきれいなMarkdownで取れた。取れた見出しの中に「Cloudflare launches Kitesurf, a browser built for AI agents」が入っていたのはご愛嬌。

OpenAIには弾かれた。 Kitesurfは本物のブラウザのTLSフィンガープリント⁶を持たず、アクセス元もCloudflareのデータセンターIPになる。ボット対策が固いサイトからは正面からボットに見える——これは欠陥ではなく仕様で、公式も「ボットチャレンジのあるサイトはChromium版を使え」という整理をしている。

もうひとつ実務で重要なのがMarkTechPostの「成功したのに空」パターンだ。HTTPステータスもAPIレスポンスも成功なのに、resultが空文字で返る。エラーにならないので、「中身が空なら失敗扱い」のチェックを自分で書かないと、静かにデータが欠落する。

実測2: APIで何ができるのか（全8種を叩いた）

Browser Runには「Quick Actions」と呼ばれるREST APIが8種類ある。URLを投げるだけで結果が返る使い方で、Kitesurfで全部叩いた結果がこれだ。

非対応の3つは Action "links" is not supported by the kitesurf browser という明示的なエラーを返す。同じリクエストから browser=kitesurf を外すと、Chromium版では普通に動く（/links で確認済み）。つまり機能の穴はKitesurf側の実装状況であって、アカウントや権限の問題ではない。

驚いたのは /json だ。「トップ5件のタイトルとポイント数をJSONで返して」と自然言語で書くだけで、その形の構造化データが返ってくる。セレクタを書く必要がない。サイトのHTML構造が変わっても壊れにくいので、収集の実装コストはかなり下がる。

curl -X POST ".../browser-run/json?browser=kitesurf" \
  -H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json" \
  -d '{"url":"https://news.ycombinator.com",
       "prompt":"Return the top 5 story titles and their points as JSON"}'

/crawl は非同期で、投げるとジョブIDだけが返り、結果は GET /browser-run/crawl/<id> で取りに行く。返ってきたJSONに browserSecondsUsed（消費したブラウザ秒数）が入っているのが実務的にありがたい。課金メーターが見えるので、自動化を回す前にコストを見積もれる。

なお、Quick Actions以外にCDP経由（Puppeteer / Playwright / chrome-remote-interfaceをbrowser=kitesurf付きのWebSocketに繋ぐ）、MCP（AIエージェントから直接）、Stagehand（セレクタではなく意図で要素を探す）という使い方もある。既存のPuppeteerコードがあるなら、接続先を変えるだけで載せ替えられる。

出典: Browser Run docs（対応状況は2026年8月11日の実測。ベータのため変わりうる）

実測3: 1回の巡回で何が集まったか

成功した5サイトぶんの生Markdownは合計96KB。ここから正規表現で見出しを抜くと136本になった。取得にかかった時間は5サイト合計で23.9秒、費用はベータ無料なので0円。あとはこの見出し群をLLM⁷に渡して分類・翻訳すれば、毎朝のダイジェストが作れる。

実際に、TechCrunch分の33本をLLMで分類・和訳した内訳がこれだ（分類は筆者環境のLLMによる。カテゴリ設計次第で数字は変わる）。

「英語圏の一次情報を、自分の関心軸で毎朝1枚に整理する」という仕組みの素材としては十分すぎる。RSSを出していないサイトが混ざっていても、全部同じMarkdown抽出で拾えるのが効いている。

なお当然だが、収集した記事の本文をそのまま再配信するのは著作権侵害になる。この手のパイプラインで公開してよいのは、自分の言葉での要約・論評と出典リンクまで。社内利用の情報整理なら問題は小さいが、対外公開するなら引用の範囲に収める設計が先に要る。

実測4: 集めた見出しから、実際に何が作れるか

「Markdownが取れた」で終わっては意味がない。取得は1回でも、切り口を変えれば別のアウトプットになる。今回の136本から実際に作ったものを3つ出す。

その1: 朝のダイジェスト

関心軸（ここでは「エージェント」「実装に効く話」）で絞って並べ替えると、そのまま朝に読む1枚になる。以下は実際の収集結果から抜いたものだ（見出しは筆者訳、リンクは一次情報）。

自分が毎朝5サイトを開いて眺めていた作業が、そのまま置き換わる。

その2: 週次トレンド集計

「何が話題か」は、見出しを数えるだけでも輪郭が出る。収集した136本のうち、機械的に数えられる96本（TechCrunch・HuggingFace・DeepMind分）でキーワード出現を集計した結果がこれだ。

企業名で数えると Google/Gemini/DeepMind が13本、OpenAI 6本、Meta 3本。1日ぶんのスナップショットなので傾向を語るには足りないが、これを毎日積めば「先月と比べてエージェント系が増えた」といった話が数字で言えるようになる。単純な正規表現での集計なので、分類の精度もそれなり（「agent」を含むだけの見出しも拾う）。厳密にやるならLLMに分類させる工程を挟むことになる。

その3: 記事・提案のネタ帳

見出しと一次情報URLの組が貯まっていくので、そのまま「書くネタ」「客先で話すネタ」の在庫になる。実際この記事も、収集結果の中にあった「Cloudflare launches Kitesurf, a browser built for AI agents」から始まっている。

3つとも、取得したデータは同じ1回ぶんだ。収集を自動化する価値は、取得そのものより「同じ素材を何度も使い回せる形で溜まること」にある。

ハマりどころ: レート制限が想像より厳しい

ベータ版で最初に確実にぶつかるのがこれだ。7サイトを続けて叩いたら、1件目以外すべて429（Rate limit exceeded）が返ってきた。数秒空けても駄目で、最終的に45秒間隔にしたら安定した（執筆時点の実測。公式に間隔の数値は明記されていない）。

つまり現状のKitesurfは「100サイトを一気に並列巡回」には使えない。cronで1件ずつ間隔を空けて回すのが現実的な設計だ。毎朝の情報収集のような用途なら、巡回に数分かかっても何も困らないので、実用上の支障はなかった。

他の手段との比較

「機械でWebページを読む」手段は、コストの階段で整理すると分かりやすい。

Kitesurfの立ち位置は「curlでは読めないが、Chromiumを飼うほどではない」の隙間だ。そして大事なのは、RSSやAPIを公開しているサイトにブラウザを使うのはただの無駄だということ。ブラウザが要る相手だけに使う。

向くケース・向かないケース

向く:

• 企業サイト・公式ブログ・テックメディアの定点観測、更新検知
• JSレンダリング必須のページからのテキスト抽出（Markdown APIの出力はfrontmatter付きで、LLMにそのまま渡せる品質だった）
• 収集からLLM処理までをCloudflare内で完結させるサーバーレス構成

向かない:

• ボット対策が固いサイト、ログインが要るサイト（SNS・EC・求人系）。データセンターIP＋非本物TLSで正面から検知される
• E2Eテスト。ユーザーが実際に使うブラウザで壊れていないことの保証にならず、Kitesurf未実装の機能（動画・WebGL⁸）で偽の失敗も出る
• 1件の応答速度が要る用途。Chromiumより遅い

料金（執筆時点）

Kitesurf自体はベータ中無料（アカウントごとの利用上限あり）。正式価格は未発表だ。土台のBrowser Runの現行料金は、無料プランで1日10分まで、有料（Workers Paid $5/月）で月10時間込み・超過$0.09/時間。

ひとつ注意点がある。現行課金は「ブラウザが動いていた実時間」ベースだが、KitesurfはCPU・メモリは安い一方で実時間はChromiumより長い。同じ実時間メーターのまま課金されると1タスクあたりむしろ割高になり得る。Cloudflareの売り文句からすればCPUベースか割安な別枠になる可能性が高いが、これは推測で、公式発表はまだない。

いずれにせよ規模感としては、5サイトの毎日巡回で月3時間強。無料枠か$5プランに収まる。

出典: Browser Run Pricing・Changelog: Introducing Kitesurf

使い方の手順（トークン発行から実行まで）

コードを書かずに挙動だけ見たいなら、公式プレイグラウンド（kitesurf.cloudflare.app）にURLを入れれば済む。APIから使う場合は、先にAPIトークンの発行が要る。ここが唯一の準備作業で、5分で終わる。

手順1: APIトークンを発行する

Cloudflareダッシュボードの右上ユーザーメニュー → API Tokens → Create Token → 一番下の Custom token を選ぶ。設定するのは実質1行だけだ。

Permissions を「Account」→「Browser Run」→「Edit」にする。ここだけ間違えなければ動く。旧名の Browser Rendering で覚えている人は、名称が変わっている点に注意。

残りは任意だが、実務では次の2つを入れておくとよい。Account Resources を自分のアカウントに限定する（All accounts のままにしない）、TTL で有効期限を切る（試すだけなら1ヶ月など）。トークンは作成直後の画面でしか表示されないので、その場でコピーして環境変数などに保管する。

なお、wrangler login で作られるOAuthトークンではこのAPIは通らない（実測で401）。Browser Run 権限を持つトークンを別途発行する必要がある。

手順2: 叩く

export CF_TOKEN='<発行したトークン>'
export CF_ACCOUNT='<アカウントID>'   # ダッシュボードのURLに含まれる32桁

curl -X POST \
  "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT/browser-run/markdown?browser=kitesurf" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://news.ycombinator.com"}'

手順3: 実運用に入れる前に2つ足す

①リクエスト間隔を空ける（連投すると429）、②「200でも中身が空」を失敗扱いにする。この2つを入れずに自動化すると、静かに欠損したデータが溜まる。

まとめ

発表5日のプロダクトとしては、驚くほど「もう使える」。JSレンダリングが要るページを、インフラなしで、（今は）無料で、LLMに渡せるMarkdownにして返してくれる——この一点だけで、情報収集の自動化の敷居は一段下がった。

一方で、遅い・ボット対策に弾かれる・レート制限が厳しい・空レスポンスの罠がある、という制約も実測ではっきり見えた。万能の代替ではなく、「堂々と読みに行ける相手を、大量に安く読む」専用の道具だ。そこを外さなければ、ベータ無料の今は試し得だと思う。

うちでは今回組んだ巡回をこのまま運用に乗せて、海外AI動向の朝ダイジェストとして使っていく予定だ。

こういう「使えるかどうかの検証」を代わりにやります

この記事でやったことは、要するに新しいツールを本番投入する前の検証だ。公式が謳う性能ではなく実測値を取り、自社の対象サイトで通るか確かめ、落とし穴（レート制限・空レスポンス・非対応API）を先に踏み、向く用途と向かない用途に線を引く。

新しいものが週単位で出てくる今、これを全部自前でやるのは正直しんどい。「AIで作ったコードが動いてはいるが、本番に出して大丈夫か分からない」「この新サービス、うちの案件に使えるのか誰も判断できない」——そういう、技術のことで止まっている時間を引き取るのが当社の外部技術部です。単発の「リリース前コード検品」（5万円〜）から、月額で技術相談・調査・レビューを受ける形まであります。

Footnotes

1. JSレンダリング 近年のWebサイトの多くは、HTMLに中身が直接書かれておらず、ブラウザがJavaScriptを実行して初めて画面が組み立てられる。curlのような単純取得では「空っぽのページ」しか見えない。 ↩

2. V8 isolate Chromeと同じJavaScriptエンジンV8が持つ軽量な分離実行単位。1つのプロセスの中で多数のisolateがメモリを分けて同居できるため、VMやコンテナより桁違いに軽く起動できる。 ↩

3. Web Platform Tests ブラウザがWeb標準にどれだけ正しく従っているかを検証する業界共通のテスト集。主要ブラウザ各社が開発に使っている。 ↩

4. ヘッドレスブラウザ 画面表示なしで動かすブラウザ。スクレイピングやテスト自動化で使う。Chromiumをヘッドレスで常駐させるとメモリを数百MB単位で消費する。 ↩

5. JIT Just-In-Timeコンパイル。実行中にコードを機械語へ変換して高速化する仕組み。V8はJITを持つが、KitesurfのJSエンジンBoaは持たないため実行が遅い。 ↩

6. TLSフィンガープリント 暗号化通信(TLS)の開始手順に現れる、ブラウザ実装ごとの癖。ボット対策サービスはこれを見て「本物のChromeか、偽装したプログラムか」を見分ける。 ↩

7. LLM 大規模言語モデル。ここでは収集した英語見出しの分類・翻訳・要約に使う。 ↩

8. WebGL ブラウザ上で3D描画を行うAPI。地図やグラフ描画に使われることがあり、Kitesurfは未対応。 ↩