ChromeやSafariは「人間が画面を見て操作する」前提で作られています。 Kitesurfは、その前提を捨てたブラウザです。使うのはAI。だから、人間しか要らない機能を全部そぎ落としました。
実際に叩いてみた実測レポートを見る →まず「ブラウザ」という言葉が指すものを分解すると、話が一気に分かりやすくなります。
普段使っているChromeを思い浮かべてください。画面にはタブがあり、URLを入れる欄があり、 ブックマークバーがあり、右上に拡張機能のアイコンが並んでいます。 そして、その下に実際のWebページが表示されている。
この「上の方の飾り」は全部、人間が操作するために付いているものです。 AIがWebページを読むだけなら、タブもブックマークも拡張機能も1ミリも要りません。 でも従来は、AIにWebページを読ませたいときも、この全部入りのブラウザを丸ごと起動していました。
→ Kitesurfは Chromium を軽量設定にしたものではなく、ブラウザの中身そのものを作り直したものです。
そぎ落とした分だけ、動かすのに必要なメモリとCPUが激減しました。ただし良いことばかりではありません。
そぎ落としたので、当然できなくなったこともあります。ここを知らずに使うとハマります。
「AIにWebを読ませる」ためのサービスは既にいくつもあります。その中でのKitesurfの立ち位置。
ひとつは「読むだけ」の流派。URLを渡すと中身のテキストが返ってくる。シンプルで速いが、 ボタンを押したりフォームに入力したりはできない。Firecrawlがこれです。
もうひとつは「操作する」流派。クラウド上に本物のChromeを1台立ててくれて、 こちらから遠隔でクリック・入力・ログインまでさせられる。BrowserbaseやBrowserless、 Steelがこれです。自由度は高いぶん、1台ごとに重くて高い。
Kitesurfは、この地図の中でひとつだけ違う場所に立っています。
→ 他社は全員「クラウドに本物のChromeを置く」方向。Kitesurfだけが「ブラウザの中身を作り直して軽くする」方向に振れています。
| サービス | 中身 | できること | 向いている量 |
|---|---|---|---|
| Kitesurf | 独自エンジン Workers上 |
読む・スクショ・自動処理 （ログイン維持は不可） |
超大量 |
| Firecrawl | 抽出API | URL → Markdown。ブラウザ操作はできない | 大量 |
| Cloudflare Browser Run |
本物のChromium | ほぼ何でも。Kitesurfと同じAPIで切替可能 | 中〜大量 |
| Browserless | 本物のChromium | 操作可。簡単なボット対策なら突破できる | 中量 |
| Steel / Kernel | 本物のChromium | 操作可。AIエージェント運用向けの管理機能 | 中量 |
| Browserbase | 本物のChromium | クリック・入力・OAuthログイン・状態の維持まで | 少〜中量 |
| 自前でPlaywright | 本物のChromium | 何でも。ただしサーバー運用は全部自分持ち | 運用次第 |
「どちらが優れているか」という問いは、実は成立しません。 Chromiumは「人間が1枚のページを見る」ために作られ、Kitesurfは「機械が何万枚も読む」ために作り直されたものだからです。 用途が違うので、比べるべき軸そのものが違います。
軸ごとに整理すると、こうなります。
| 比べる軸 | 優れているのは | 理由 |
|---|---|---|
| 機能の幅 | Chromium | ログイン維持・WebGL・正確な描画は Kitesurf では不可 |
| 1回あたりの速さ | Chromium | テキスト抽出で 8〜21% 速い（実測） |
| 攻撃対象領域の小ささ | Kitesurf | Rust + WebAssembly で新規実装、機能が少ない分だけ狙われる面も小さい |
| バースト時のスケール | Kitesurf | V8 isolate 方式のため、急激な負荷増に素直に追従する |
| リソース消費の読みやすさ | Kitesurf | Chromium はページ次第でメモリが乱高下する |
| 抽出される中身 | 同一 | 実測で完全一致（後述） |
スクレイピングとは、不特定多数の他人が書いたコードを、自社の環境で実行する行為です。 ブラウザはそのまま攻撃対象になります。
Chromiumは巨大なC++のコードベースで、メモリ安全性に関わる脆弱性が継続的に報告され続けています。 対してKitesurfはRust と WebAssembly で新しく書かれ、V8 isolate で隔離されている。 そもそも積んでいる機能が少ないので、狙える面も小さい。
「軽くした」ことの副作用として「堅くなった」という見方ができます。 大量のサイトを機械的に開く用途では、これは実務上の差になります。
※ これは設計から導かれる解釈であり、Cloudflareが安全性を主張しているのを確認したものではありません。
?browser=kitesurf
を足すだけで切り替わります。コードの書き換えは不要。
「軽い処理はKitesurf、複雑な処理はChromium」をパラメータ1つで使い分けられるのが、実務上いちばん効く差です。
判断基準はひとつだけ。「同じ処理が、大量に繰り返し発生するか」。 月に数回しか動かさないものにKitesurfを使う意味はありません。
作るのはエンジニア、恩恵を受けるのは営業・経営。案件や商品に直結する使い方です。
Browser Runには自然言語で「このページから会社名と電話番号を取って」と書くだけで構造化データが返る機能があります。 従来のスクレイピング案件は、サイトが改修されるたびに指定が壊れて保守地獄になるため見積もりが合いませんでした。 そこが自然言語指定になると開発も保守も工数が激減し、断っていた案件が粗利の出る案件に変わります。
納品後の保守案件は積み上がっていくのが制作会社の構造。全サイトの主要ページを毎日巡回して、 表示崩れ・エラー・改ざんを自動検知します。保守サービスの付加価値として請求できるのが強み。 （リンク切れの一括チェックはKitesurf非対応のため、そこだけChromium側で回します）
「URLを入れたら要約」「社内サイトをAIで検索」といった機能を作るとき、 最近のサイトは普通に取得してもHTMLが空なので、ブラウザで描画してからでないと中身が取れません。 Markdown出力がそのままAIへの入力になります。
自社の画像生成サービスで、生成物ごとにSNS用のOGP画像やサムネイルが要るはず。 HTMLテンプレートを組んでスクショ化する方式です。ピクセル単位の精度が不要な用途なので、 Kitesurfの割り切りと完全に噛み合います。
売上の話ではなく、手元の開発が楽になる使い方。 共通しているのは「今までブラウザが重すぎて諦めていた自動化」が予算内に入ってくる、という点です。
CIでブラウザテストを回すとき、並列度を上げられない原因はたいていメモリです。 Kitesurfは1本あたりのメモリが1/5〜1/7で、しかもページ次第でメモリが跳ね上がることがない。 並列度を上げたときの見積もりが立てやすくなります。
PRを作るとプレビュー環境が立つ構成なら、主要画面を自動でキャプチャして PRのコメントに貼り付けるところまで自動化できます。 レビュアーがブランチを切り替えてローカルで立ち上げなくても、見た目の変化が一目で分かる。
SPAの事故で一番怖いのが、サーバーは正常に200を返しているのに、JSが落ちて画面が真っ白というやつです。 従来の死活監視はHTTPステータスしか見ないので、これを検知できません。 実際にレンダリングして中身があるか確認すれば拾えます。
依存している外部サービスのドキュメントページを毎日Markdown化して、前日との差分を取る。 「知らないうちに仕様が変わって本番が壊れる」を、壊れる前に拾える。 決済・地図・SMSなど、外部依存の多い案件ほど効きます。
全ページ × 全画面幅のスクショを毎晩自動取得し、前日との差分でレイアウト崩れを検知。 量は確実に出ます。ただしピクセル単位の厳密な差分比較には向かないため、 「大崩れの検知」レベルで使えるかは実測が必要です。
客先で「E2Eテストが遅くて並列度を上げられない」「スクレイピング基盤のサーバー代が」という課題は普通にあります。 エンジニアが持ち込める提案の弾として使えます。
ここを一緒に示せると、提案の説得力が上がります。