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 | 何でも。ただしサーバー運用は全部自分持ち | 運用次第 |
万能ではありません。できることの幅では、Browserbaseなどの本物のChromium勢に負けます。 ログインが必要な作業も、3Dのサイトも、ボット対策のあるサイトも扱えない。
Kitesurfが明確に勝つのは「単純な処理を、とにかく大量に回す」という一点です。 メモリが1/4.7〜1/7ということは、同じサーバー資源で4〜7倍の本数を同時に走らせられるということ。 1回が1.8倍遅くても、7本同時に走れば全体の処理量は勝ちます。
?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なので、同じCI枠で同時実行数を数倍にできる。 1本は1.8倍遅くても、5本同時に走れば全体は速くなります。
PRを作るとプレビュー環境が立つ構成なら、主要画面を自動でキャプチャして PRのコメントに貼り付けるところまで自動化できます。 レビュアーがブランチを切り替えてローカルで立ち上げなくても、見た目の変化が一目で分かる。
SPAの事故で一番怖いのが、サーバーは正常に200を返しているのに、JSが落ちて画面が真っ白というやつです。 従来の死活監視はHTTPステータスしか見ないので、これを検知できません。 実際にレンダリングして中身があるか確認すれば拾えます。
依存している外部サービスのドキュメントページを毎日Markdown化して、前日との差分を取る。 「知らないうちに仕様が変わって本番が壊れる」を、壊れる前に拾える。 決済・地図・SMSなど、外部依存の多い案件ほど効きます。
全ページ × 全画面幅のスクショを毎晩自動取得し、前日との差分でレイアウト崩れを検知。 量は確実に出ます。ただしピクセル単位の厳密な差分比較には向かないため、 「大崩れの検知」レベルで使えるかは実測が必要です。
客先で「E2Eテストが遅くて並列度を上げられない」「スクレイピング基盤のサーバー代が」という課題は普通にあります。 エンジニアが持ち込める提案の弾として使えます。
ここを一緒に示せると、提案の説得力が上がります。