「Webページを機械に読ませる」コストが1桁下がった話 — Cloudflare Kitesurf を実務目線で検証した
池本 雅昭「Webページを機械に読ませる」コストが1桁下がった話 — Cloudflare Kitesurf を実務目線で検証した
こんな依頼を受けたことはないでしょうか。
- 「取引先候補になりそうな企業500社のサイトから、事業内容と使っている技術を一覧にまとめてほしい」
- 「納品した30サイトが今朝も正常に表示されているか、毎日自動でチェックしたい」
- 「社内の問い合わせAIに、自社サイトやマニュアルの情報を読み込ませたい」
- 「管理画面に『この内容をPDFで出力』ボタンを付けたい」
どれも「技術的にはできる」話です。ただ、実際に見積もりを出すと 思ったより高くなる 。そして運用が始まると 想定以上に壊れる 。この2つが理由で、提案しても流れてしまう。そんな経験はないでしょうか。
その前提が、ここ数ヶ月で変わりつつあります。2026年8月6日にCloudflareが公開した Kitesurf は、その変化を象徴する製品です。
この記事では、Kitesurf が 誰の、どんな仕事を変えるのか を整理した上で、弊社で実際に全機能を検証した結果を公開します。
なぜ今まで割に合わなかったのか
上に挙げた依頼には、実は共通点があります。どれも 「Webページを、人間ではなく機械に読ませる」 という処理です。
そしてこれには、2つの壁がありました。
壁1: ブラウザが重すぎる
意外に思われるかもしれませんが、Webページの中身を機械に取らせるには ブラウザを起動する必要があります 。
昔ながらのサイトなら、HTMLをそのまま取得すれば中身が読めました。しかし現在の主流であるSPA（JavaScriptで画面を組み立てるサイト）は、 ただ取得しただけでは中身が空っぽ です。JavaScriptを実行して、実際に画面を組み立てて、はじめて中身が現れます。
つまり、ブラウザを丸ごと1つ起動しないと読めない。ページ1枚ごとに、です。
Chrome を1つ起動するのに必要なメモリを考えてみてください。それを1万ページ分やる。サーバー代が跳ね上がり、「500社分のデータ収集」の見積もりが膨らむ原因はここにありました。
壁2: すぐ壊れる
もうひとつが保守の問題です。
従来、ページから情報を抜き出すには 「HTMLのこの位置にある、この要素を取る」 とプログラムで指定していました。
この方式は、 相手のサイトが少しでも改修されると動かなくなります 。デザインリニューアルはもちろん、ちょっとしたクラス名の変更でも壊れる。収集先が100サイトあれば、 100個の壊れやすい仕掛けを永久に保守し続ける ことになります。
作るのは簡単なのに、保守で赤字になる。これがスクレイピング案件が敬遠されてきた本当の理由です。
Kitesurf は前者を、そして同じCloudflareのサービス群が後者を、それぞれ解きにきています。
誰が、何のために使うのか
先に整理しておくと、 Kitesurf に管理画面はありません 。営業担当や経営層が直接触れるものではなく、 エンジニアがプログラムから呼び出す部品 です。
ただし、その恩恵を受けるのはエンジニアだけではありません。用途は大きく4つに分かれます。
① 大量のWebページから情報を集めたい
誰が欲しがるか : 営業部門、マーケティング部門、経営企画
競合の価格モニタリング、営業リストの自動生成、業界情報の定点観測。「毎日、決まったサイト群を見て、決まった項目を記録する」という仕事は、多くの会社に手作業のまま残っています。
② サイトを自動で見張りたい
誰が欲しがるか : 制作会社・開発会社の運用担当
納品後の保守案件は積み上がっていきます。全サイトの主要ページを毎日巡回して、表示崩れやエラーを自動検知する。これは 保守サービスの付加価値として提供できる 部分です。
③ AIに情報を読み込ませたい
誰が欲しがるか : 社内DX担当、自社サービスの開発チーム
「URLを入れたら要約が出る」「社内サイトをAIで検索できる」といった機能を作るとき、 AIに渡す前段でWebページをテキスト化する処理が必ず必要 になります。ここは自前で用意すると意外に手間がかかる部分です。
④ 画面を画像やPDFにしたい
誰が欲しがるか : 自社サービスを持つ開発チーム
SNS共有用のOGP画像を投稿ごとに自動生成する、管理画面から帳票をPDF出力する。地味ですが、実装しようとするとサーバー側にブラウザ環境を用意する必要があり、面倒な部類の機能です。
Kitesurf は何を変えたのか
Kitesurf は一言でいうと、 「人間向けの機能を全部捨てたブラウザ」 です。
普段使っているChromeを思い浮かべてください。タブがあり、URLを入れる欄があり、ブックマークバーがあり、拡張機能のアイコンが並んでいます。そしてその下に、実際のWebページが表示されている。
この「上の方の飾り」は全部、 人間が操作するために付いているもの です。AIがページを読むだけなら1ミリも必要ありません。にもかかわらず、これまでは機械に読ませるときも、この全部入りのブラウザを丸ごと起動していました。
Kitesurf は、そこを削りました。タブもテーマも拡張機能も、ピクセル単位の正確な描画も捨てています。さらに、 目に見えない描画エンジン部分もゼロから書き直しました 。Rust と WebAssembly を使い、開発期間は12週間。Chromiumの設定を絞ったものではなく、まったく別のソフトウェアです。
図1：ブラウザから「人間しか使わない部分」を取り除いたのがKitesurf
結果、公式発表では CPU・メモリの消費がChromiumの3〜7分の1 。壁1にあたる部分が構造的に軽くなりました。
ただし公式が公表しているのは大まかな数字だけで、 機能ごとの対応表も、実際の処理時間も、この数字が利用者側にどう還元されるのかも公開されていません 。実務に投入できるか判断がつかなかったため、弊社で全機能を検証しました。
検証結果
- 実施日: 2026年8月17日
- 対象: Cloudflare Browser Run の REST API
- 計測: 各3回実行の中央値（対応表のみ1回）
使える機能・使えない機能
| 機能 | 内容 | Kitesurf |
|---|---|---|
| screenshot | 画面のキャプチャ | ✅ 対応 |
| markdown | ページをテキスト化 | ✅ 対応 |
| ページをPDF化 | ✅ 対応（公式に記載なし） | |
| json | 自然言語での構造化抽出 | ✅ 対応 |
| links | ページ内リンクの一覧 | ❌ 非対応 |
| snapshot | ページ状態の取得 | ❌ 非対応 |
| scrape | CSS指定での要素抽出 | ❌ 非対応 |
非対応のものは Action "links" is not supported by the kitesurf browser と明示的に弾かれます。
実務目線で重要なのは2点です。 公式に記載のないPDF生成が動いた こと（用途④が守備範囲に入る）。そして links が使えない こと。リンク切れの一括チェックを組む場合、そこだけChromium側に回す必要があります（用途②の設計に影響します）。
対応している4つが実際に何を返すのかを並べると、こうなります。
図2：送るのはURL1つ。エンドポイントを差し替えるだけで返ってくる形が変わる（数値は実測）
処理速度 ─ 「1.8倍遅い」は用途次第
公式は「1.7〜1.8倍遅い」としています。実測したところ、 用途によって全く違いました 。
| 用途 | 対象 | Chromium | Kitesurf | 差 |
|---|---|---|---|---|
| テキスト抽出 | 文字量の多いページ | 1.20秒 | 1.30秒 | +8% |
| テキスト抽出 | 一般的な企業サイト | 1.63秒 | 1.97秒 | +21% |
| スクリーンショット | 一般的な企業サイト | 2.55秒 | 3.06秒 | +20% |
| スクリーンショット | 文字量の多いページ | 1.90秒 | 3.39秒 | +79% |
公式の数字に当てはまったのは、 文字量の多いページのスクリーンショット という、Kitesurfが最も苦手な条件だけでした。主用途であるテキスト抽出では +8〜21% で、体感できるほどの差ではありません。
抽出される中身は、1バイトも変わらない
「軽い＝手を抜いているのでは」という疑問は当然出ます。3サイトすべてで照合しました。
| 対象 | Chromium | Kitesurf | 判定 |
|---|---|---|---|
| 一般的な企業サイト | 4,703 文字 | 4,703 文字 | SHA256まで一致 |
| 文字量の多いページ | 6,696 文字 | 6,696 文字 | SHA256まで一致 |
| example.com | 200 文字 | 200 文字 | SHA256まで一致 |
ハッシュ値まで完全一致 、つまり1バイトも違いません。自然言語での構造化抽出も、返ってきた要約文まで同一でした。
レスポンス容量自体はKitesurfの方が小さくなりますが、差分はすべてHTTPヘッダなどの付帯情報です。 テキストを取る使い方であれば、Kitesurfにして劣化する要素はゼロ ということになります。
ただし注意したいのは、 これはKitesurfの「利点」ではなく「前提条件」 だという点です。乗り換えても失うものがないことを示しているだけで、乗り換える理由は別にあります。
ただし、見た目は変わる
一方、スクリーンショットには明確な差が出ました。
太字が反映されません。 強調指定した箇所が、すべて同じ太さで描画されます。文字幅も広く、折り返し位置がずれます。
同じ段落を撮り比べたものが以下です。
図3：Chromium。強調指定した箇所が太字で描画されている
図4：Kitesurf。同じHTMLだが太字が消え、文字幅が広いため折り返し位置もずれている
2枚のピクセル差分を取ると、文字量の多いページで 4.3% が食い違いました。赤い部分が食い違っている箇所です。
図5：背景の帯や区切り線は真っ白＝完全一致。ずれているのは文字だけ
背景や区切り線は完全に一致しており、 崩れるのはタイポグラフィだけでレイアウトの再現性は高い という結果でした。
用途②（表示崩れの検知）には十分使えますが、 デザインの最終確認用キャプチャはChromiumで撮るべき です。切り替えはパラメータ1つなので、用途で使い分けるのが現実的です。
では、Kitesurfを選ぶ理由は何なのか
ここが一番誤解されやすいところです。
「メモリが3〜7分の1」という数字は、 Cloudflare側のサーバー内部の話 です。そのまま自社の請求が7分の1になるわけではありません。実際、Browser Runの課金単位は ブラウザの稼働時間 （Paidプランで月10時間まで無料、以降 $0.09/時間）で、同時実行数は ブラウザの「数」 で数えられます。 Kitesurf専用の料金や制限は公表されていません。
では利点は何か。検証を通じて見えたのは、次の4つでした。
① 攻撃対象領域が小さい
見落とされがちですが、 スクレイピングとは「不特定多数の他人が書いたコードを、自社の環境で実行する行為」 です。ブラウザはそのまま攻撃対象になります。
Chromiumは巨大なC++のコードベースで、メモリ安全性に関わる脆弱性が継続的に報告され続けています。対してKitesurfは Rust と WebAssembly で新しく書かれ、V8 isolate で隔離 されている。そもそも積んでいる機能が少ないので、狙える面も小さい。
「軽くした」ことの副作用として「堅くなった」 という見方ができます。大量のサイトを機械的に開く用途では、これは実務上の差になります。
※ これは設計から導かれる解釈であり、Cloudflareが安全性を主張しているのを確認したものではありません。
② バースト（急激な負荷変動）に強い
KitesurfはWorkers上の V8 isolate で動きます。isolateはコンテナと比べて起動が桁違いに軽い方式です。Cloudflareが「バースト型のワークロードに最適化」と説明しているのはここです。
「普段は0、必要になった瞬間に1000ページ」という使い方がスケールしやすく、 平常時にコストを抱えずに済みます 。
③ 消費リソースが予測できる
Chromiumのメモリ使用量は 開くページ次第で乱高下します 。広告の多いサイトを1枚開いただけで跳ね上がる。Kitesurfは機能が限られている分、上限が読めます。
キャパシティ設計をする側からすると、平均値より 最悪ケースが見えること の方が価値が高い場面は多いはずです。
④ 試すリスクがほぼゼロ
切り替えは ?browser=kitesurf を 足すか外すかだけ 。コード変更は不要で、切り戻しも即座にできます。
通常、新しい技術の採用には検証コストと後戻りのリスクが伴いますが、それがありません。 処理の種類ごとに使い分ける ことも容易です。
壁2を壊すのは、実はこちらだった
ここまでKitesurfの話をしてきましたが、 実務インパクトが最も大きいと感じたのは別の機能 でした。Browser Run の json エンドポイントです。
冒頭で挙げた壁2 —— 「相手のサイトが改修されると壊れる」問題。これを解くのがこの機能です。
抽出したい内容を、 日本語の文章で指示するだけ で構いません。
{ "url": "https://example.co.jp", "prompt": "この会社の会社名・所在地・事業内容の要約・提供しているサービス名の一覧・使用技術を抽出してください" }
実際に弊社サイトへ実行したところ、5.91秒で以下が返ってきました。CSSセレクタもコードも一切書いていません。
{ "会社名": "株式会社UHD", "所在地": "五反田", "事業内容の要約": "システム開発、ITコンサルティング", "使用技術": ["Next.js", "React", "Shopify"] }
図6：指示は日本語の文章1つ。従来のようにHTMLの位置をコードで指定する必要がない
サイトの構造が変わっても、指示文は変えなくて済みます。
裏ではAIが動いています。Kitesurf自体は単なるブラウザでAIではありませんが、json エンドポイントだけは、取り出したテキストをLLMに読ませて構造化しています。処理時間がテキスト抽出の1.3〜2.6秒に対して5.9〜6.2秒と長いのは、この推論時間が乗っているためと考えられます。
壁1（重い）をKitesurfが、壁2（壊れる）をこの機能が下げた。 冒頭の「500社分のデータ収集」が現実的な見積もりに収まりはじめているのは、この2つが同時に起きたからです。
始め方
必要なのはCloudflareアカウントだけ。無料プランで始められます。
1. APIトークンを発行
ダッシュボードの My Profile → API Tokens → Create Custom Token から発行します。必要な権限は Account → Browser Rendering → Edit の1つだけです。
2. 動作確認
curl -X POST \ "https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/browser-run/markdown?browser=kitesurf" \ -H "Authorization: Bearer {TOKEN}" \ -H "Content-Type: application/json" \ -d '{"url":"https://example.com"}'
テキストが返ってくれば準備完了です。ここまで実質3分。サーバーの用意もインストールも要りません。
3. アプリケーションに組み込む
サーバーサイドから fetch を1回呼ぶだけです。 Cloudflare Workers は必須ではありません。 Next.js の API Route でも既存のバックエンドでも、HTTPリクエストが送れる環境なら同じコードで動きます。
// app/api/extract/route.ts export async function POST(req: Request) { const { url, prompt } = await req.json(); const res = await fetch( `https://api.cloudflare.com/client/v4/accounts/${ACCOUNT}/browser-run/json?browser=kitesurf`, { method: "POST", headers: { Authorization: `Bearer ${TOKEN}`, "Content-Type": "application/json", }, body: JSON.stringify({ url, prompt }), } ); const data = await res.json(); return Response.json(data.result); }
APIトークンは必ずサーバー側にのみ保持してください。
導入前に押さえておきたいこと
ベータのレート制限が厳しい。 連続してリクエストを送るとすぐに429が返ります。実運用に載せるなら再試行処理は必須です。
ログイン状態を保てない。 リクエストごとに使い捨てられる設計のため、会員サイト内の自動操作には使えません。この用途はChromiumか、他社の常駐型ブラウザサービスの領域です。
ボット対策のあるサイトは通りません。
正式版の料金が未確定。 Browser Runの課金単位は ブラウザの稼働時間 （Paidプランで月10時間まで無料、以降 $0.09/時間）で、同時実行数は ブラウザの「数」 で数えられます。そして Kitesurf専用の料金や制限は公表されていません 。
つまり「メモリ3〜7分の1」が自社の請求にどう反映されるかは、現時点では読めません。加えて json エンドポイントはAI推論を伴うため、別建ての課金になる可能性もあります。 「安くなる」を前提にした事業計画は、正式版の価格発表を待つべきです。
まとめ
「Webページを機械に読ませる」という処理は、実は多くの業務の裏側に埋まっています。営業リストの作成、サイト監視、社内AIへの読み込み、帳票出力。これまでは、その一つひとつが 重くて壊れやすい がゆえに見送られてきました。
検証を通じて分かったのは、 「ChromiumとKitesurf、どちらが優れているか」という問いが成立しない ということでした。 Chromiumは「人間が1枚のページを見る」ために作られ、Kitesurfは「機械が何万枚も読む」ために作り直された ものです。用途が違うので、比べるべき軸そのものが違います。
| 比べる軸 | 優れているのは |
|---|---|
| 機能の幅 | Chromium |
| 1回あたりの速さ | Chromium |
| 描画の正確さ | Chromium |
| 攻撃対象領域の小ささ | Kitesurf |
| バースト時のスケール | Kitesurf |
| リソース消費の読みやすさ | Kitesurf |
| 抽出される中身 | 同一 |
実務的には、 「軽い処理を大量に、かつ不特定多数のサイトに対して回す」ならKitesurf、「正確さや機能の幅が要る処理」ならChromium 。切り替えがパラメータ1つである以上、どちらか一方を選ぶ必要はなく、処理の種類ごとに使い分けるのが正解です。
そして、冒頭に挙げた 壊れやすさ の側は、自然言語での構造化抽出が解きつつあります。
弊社では、こうした新しい技術を実際に検証したうえで、案件に適用できるかを判断しています。「やりたいけれど、割に合わないと言われて諦めた」という案件がありましたら、いま一度ご相談ください。前提が変わっているかもしれません。
本記事の検証は2026年8月17日時点のものです。Kitesurfはベータ提供中のため、仕様・対応機能は変更される可能性があります。
