実演 — URLを1つ渡すと、何が返ってくるのか

その前に

用語の整理

ここを飛ばすと以降が全部ぼやけます。3つだけ押さえてください。

① ブラウザが「自分のPC以外」で動いている

これが最大の引っかかりどころです。今回の話に出てくるブラウザは、 自分のPCでは動きません。

普段のブラウザ画面がある

自分のPC
  ↓ Chromeを起動
ページが画面に映る
  ↓
人が見る

目的は人が読むこと。だから画面が要る。

今回の話画面がない

自分のコード
  ↓「このURL開いて」と依頼
Cloudflareのサーバーの中で
ブラウザが起動してページを開く
  ↓ 結果をデータにして返す
画像・テキストが手元に届く

目的はプログラムが処理すること。だから画面は要らない。自分のPCには何も表示されません。

→ 画面のないブラウザが、他人のサーバーの中で動いている。 これが掴めれば、あとは全部つながります。

② Chromiumとは

Google Chromeの中身そのものです。ブラウザの心臓部だけを取り出したもので、オープンソースとして公開されています。Chrome・Edge・Braveなど、多くのブラウザがこれを土台に作られています。

ざっくり 「Chromiumで実行」＝「Chromeでそのページを開いた」 と考えて差し支えありません。

そしてKitesurfは、このChromiumの代わりに使える、Cloudflareが新しく作った軽量エンジンです。置き換えられる部品、という位置づけになります。

③ エンドポイントとは

機械が仕事を頼むための住所です。

普段のURL（https://uhd-inc.jp）は、人がブラウザで開いて中身を見るためのもの。エンドポイントは人が開くのではなく、プログラムが「これやっといて」と依頼を送りつける先です。送ると、結果がデータで返ってきます。

実際のエンドポイントを分解すると7つの部分

POST https://api.cloudflare.com/client/v4
     /accounts/{id}/browser-run/screenshot?browser=kitesurf

部分	意味
POST	「送る」という動作。ページを見るときは GET（取ってくる）、仕事を頼むときは POST
api.cloudflare.com	Cloudflareの機械用の窓口。人間用の管理画面は dash.cloudflare.com
/client/v4/	APIのバージョン（第4版）
/accounts/{id}/	どのアカウントからの依頼か
/browser-run/	Browser Run という機能グループを使う
/screenshot	その中の「スクショを撮る」を選ぶ。ここを差し替えると返る形が変わる
?browser=kitesurf	オプション。「ChromiumではなくKitesurfを使って」という指定

つなげると「スクショ窓口に、uhd-inc.jp を撮ってという注文書を送る。ブラウザはKitesurfで」という1件の依頼になっています。注文書にあたるのが、一緒に送る {"url": "https://uhd-inc.jp"} の部分です。

STEP 01

入れるもの

これだけです。URLを1つ書いて送るだけ。ブラウザを立ち上げる必要も、サーバーを用意する必要もありません。

リクエストこれを送る

POST /browser-run/screenshot?browser=kitesurf

{ "url": "https://uhd-inc.jp" }

screenshot の部分を差し替えると、返ってくる形が変わります。下の4つは、すべてこの1行を変えただけの結果です。

STEP 02

この指示は、どこに書くのか

Kitesurfに管理画面はありません。入力欄がどこかにあるわけではないので、「ここに指示を打ち込む」という場所を探しても見つかりません。ここが分かりにくいところです。

実体はただのHTTPリクエストです。自然言語の指示は、送信するデータの中の prompt という項目に、文字列として書くだけ。つまり、いつも書いているプログラムの中に、日本語を1行埋め込む形になります。

よくある誤解 Cloudflare Workersは必要ありません。 Workersから呼ぶこともできますが、必須ではない。 サーバー側からHTTPリクエストが送れる場所なら、どこからでも同じコードで動きます。 以下の3つは、いずれも実際に動かして同じ結果が返ってくることを確認したものです。

A. ターミナルからcurl

curl -X POST \
 "https://api.cloudflare.com/client/v4/\
accounts/$ID/browser-run/json\
?browser=kitesurf" \
 -H "Authorization: Bearer $TOKEN" \
 -d '{
   "url": "https://uhd-inc.jp",
   "prompt": "会社名とサービス一覧を抽出して"
 }'

動作確認はこれが最速です。今回の検証もこの方法で回しました。

B. Node.jsからfetch

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: "https://uhd-inc.jp",
      prompt: "会社名とサービス一覧を抽出して",
    }),
  }
);

ただのスクリプトです。Cloudflareのインフラは何も使っていません。

C. Next.jsのAPI Route実案件ならこれ

// app/api/extract/route.ts
export async function POST(req) {
  const { url, prompt } = await req.json();

  const res = await fetch(ENDPOINT, {
    method: "POST",
    headers: { Authorization: `Bearer ${TOKEN}` },
    body: JSON.stringify({ url, prompt }),
  });

  const data = await res.json();
  return Response.json(data.result);
}

御社のスタック（Next.js）ならこの形。画面から入力させて、指示を組み立てて投げるところまで作れば、社内ツールとして完成します。

どこで動くのか、まとめ Kitesurf本体はCloudflare側で動きます。こちらが用意するのは、リクエストを1回送るコードだけです。ブラウザのインストールも、サーバーの増強も要りません。APIトークンさえあれば、今日から呼べます。

なお、コードを一切書かずに試したい場合は、Cloudflareが公開プレイグラウンドを用意しています。まず手触りを確かめたいときはそちらが早いです。

STEP 03

返ってくるもの（実物）

すべて2026年8月17日に uhd-inc.jp へ実行した、加工なしの結果です。

① 画像screenshot / 3.06秒

uhd-inc.jpのスクリーンショット。ヘッダーメニューが表示され、その下は白い

ページを画像にして返します。人が見て確認するための出力。サイトの表示崩れチェックや、SNS用のサムネイル生成に使います。

② テキストmarkdown / 2.64秒

# アイデアを、価値に変える

## つくりたいを、つくれるに

アプリも、ECも、AIも。
あらゆるプロダクト開発を、
企画から運用まで

[SES](https://uhd-inc.jp/ses)
[自社サービス](/our-services)
[会社概要](/about)

ページの中身を、AIが読める形のテキストにして返します。全部で 4,703文字。広告や装飾が落ちて本文だけが残るのがポイントです。

実際の全文を開く（4,703文字）→

③ PDFpdf / 7.68秒

%PDF-1.4
...
2,011,196 バイト

ページをそのままPDFにして返します。帳票やレポートの出力機能を自社サービスに載せるときに使えます。請求書・見積書の自動生成などが典型です。

実際のPDFを開く（2.0MB）→

④ 構造化データjson / 5.91秒

{
  "会社名": "株式会社UHD",
  "所在地": "五反田",
  "事業内容の要約":
    "システム開発、ITコンサルティング",
  "提供しているサービス名の一覧": [
    "Webシステム・アプリ開発",
    "CRMカスタマイズ開発",
    "ECサイト構築",
    "AI開発",
    "補助金活用システム開発",
    "BIツール",
    "SES事業",
    "自社サービス"
  ],
  "使用技術": ["Next.js","React","Shopify"]
}

これが目玉です。詳しくは次のセクションで。

生の応答を開く →

STEP 04

④が、いちばん効く

さっきの構造化データを取り出すために書いた指示は、これだけです。プログラムではありません。日本語の文章です。

指示日本語で書くだけ

この会社のWebサイトから、会社名・所在地・
事業内容の要約・提供しているサービス名の一覧・
使用技術を抽出してください。

↓ 5.91秒

結果そのまま使えるデータ

会社名   : 株式会社UHD
所在地   : 五反田
使用技術 : Next.js / React / Shopify
サービス : Webシステム・アプリ開発
           CRMカスタマイズ開発
           ECサイト構築
           AI開発
           補助金活用システム開発
           BIツール / SES事業 / 自社サービス

なぜこれが重要か従来、こういう情報の自動収集は「HTMLのこの位置の、この要素を取る」とプログラムで指定していました。だから相手のサイトが少しでも改修されると壊れます。取得先が100サイトあれば、100個の壊れやすい仕掛けを保守し続けることになる。受託の仕事として見積もりが合わなかったのは、これが理由です。

それが日本語で指示するだけになると、サイトの構造が変わっても指示は変えなくて済みます。 作る手間も、直す手間も激減するということです。

つまり、こういう仕事が取れるようになる

USE CASE

営業リストの自動生成

業界サイトや企業一覧から、会社名・所在地・事業内容・使用技術を自動で吸い上げる。上でやったことを、100社・1000社に対して回すだけです。

USE CASE

競合の価格モニタリング

「このページの商品名と価格と在庫状況を取って」と書いておけば、毎日自動で集まります。相手がサイトを作り替えても、指示はそのままで動き続けます。

USE CASE

社内AIへの読み込み

②のテキスト出力が、そのままAIへの入力になります。「URLを入れたら要約」「社内サイトをAIで検索」といった機能の、土台の部分です。

STEP 05

で、何から始めるのか

先に、誤解を解いておく Kitesurfは「新しいサービス」ではありません。既存APIのオプションです。 エンドポイントは今までと同じで、URLの末尾に ?browser=kitesurf を付けるかどうかで、裏で動くブラウザが変わるだけ。

Cloudflareが12週間かけてブラウザをゼロから作り直した成果が、使う側から見ると17文字のパラメータになっている、という話です。

同じエンドポイント、ブラウザだけが変わる比較

POST /browser-run/screenshot
     → Chromiumで実行（重いが何でもできる）

POST /browser-run/screenshot?browser=kitesurf
     → Kitesurfで実行（軽いが機能は限定）

手順

前提はCloudflareアカウントだけ。無料プランで始められます。

① APIトークンを発行2分

ダッシュボードの My Profile → API Tokens → Create Custom Token。必要な権限は1つだけです。

Account → Browser Rendering → Edit

あわせてAccount IDも控えておきます。

② 動作確認1分

curl -X POST \
 ".../browser-run/markdown?browser=kitesurf" \
 -H "Authorization: Bearer $TOKEN" \
 -d '{"url":"https://example.com"}'

テキストが返ってくれば導入完了です。ここまで実質3分。 サーバーの用意もインストールも要りません。

③ 自分のコードに入れる30分程度

STEP 02 のコードをそのまま貼るだけです。あとは prompt の日本語を書き換えれば、用途が変わります。

prompt: "会社名と電話番号を抽出して"
prompt: "商品名と価格と在庫状況を抽出して"
prompt: "求人の職種と勤務地と年収を抽出して"

取りたいものを日本語で書き換えるだけで、別の案件に流用できます。

本番に載せる前に決めること

必須

再試行処理を入れる

ベータ期間中のレート制限がかなり厳しく、連続実行するとすぐ429が返ります。待って再試行する処理がないと、実運用では止まります。

必須

トークンはサーバー側だけに置く

APIトークンをブラウザ側のコードに出すと、誰でも自社アカウントでリクエストを打てるようになります。必ずサーバー経由で呼びます。

要確認

正式版の料金

現在はベータで無料ですが、正式化後の価格は未確認です。「無料だから」を前提にした事業計画は危険なので、商品化を検討するなら料金体系の発表を待つか、Cloudflareに確認すべきです。

まず触ってみるならコードを一切書かずに試したい場合、Cloudflareが公開プレイグラウンドを用意しています。手触りを確かめるだけならそちらが最短です。

付録

Kitesurfに切り替えて大丈夫なのか

ここから先は、実際に導入を検討する段階で必要になる検証データです。

対応していない機能がある

Kitesurfは軽くするために機能を削っているので、Chromiumなら動くのに動かないものがあります。公式ドキュメントに一覧がないため、全部叩いて確かめました。

機能	内容	Kitesurf	備考
screenshot	画像で返す	✅	—
markdown	テキストで返す	✅	—
pdf	PDFで返す	✅	公式に記載なし。叩いたら動いた
json	構造化データで返す	✅	今回の目玉機能
links	リンク一覧を返す	❌	リンク切れ検査はChromium側で
snapshot	ページ状態を返す	❌	—
scrape	CSS指定で要素を取る	❌	④のjsonで代替できる

速度差は、用途によって大きく違う

「1.8倍遅い」と一括りにされがちですが、実測すると用途で全く違いました。主用途であるテキスト抽出では、体感できるほどの差ではありません。

用途	対象	Chromium	Kitesurf	差
テキスト抽出	この資料	1.20s	1.30s	+8%
テキスト抽出	uhd-inc.jp	1.63s	1.97s	+21%
スクリーンショット	uhd-inc.jp	2.55s	3.06s	+20%
スクリーンショット	この資料（文字量が多い）	1.90s	3.39s	+79%

公式が言う「1.7〜1.8倍遅い」に当てはまったのは、 文字量の多いページのスクリーンショットという、Kitesurfが最も苦手な条件だけでした。テキスト抽出なら +8〜21% です。

そして、抽出される中身は完全に同一

3サイトすべてで、テキスト抽出の結果を照合しました。 SHA256ハッシュまで一致——つまり1バイトも違いません。

対象	Chromium	Kitesurf	判定
uhd-inc.jp	4,703 文字	4,703 文字	完全一致
この資料	6,696 文字	6,696 文字	完全一致
example.com	200 文字	200 文字	完全一致

つまりテキストを取る用途では、Kitesurfに切り替えて劣化する要素がゼロです。 1〜2割遅くなるだけで、得られるデータは同一。

注意：この「中身が同じ」は、Kitesurfの利点ではなく前提条件です。「乗り換えても失うものがない」ことを示しているだけで、乗り換える理由は次のセクションにあります。

では、乗り換える理由は何か

ここが一番誤解されやすいところです。「メモリが1/7」はCloudflare側のサーバー内部の話で、 そのままこちらの請求が7分の1になるわけではありません （Kitesurf専用の料金は未公表）。実際の利点は別の場所にあります。

STRENGTH 01

攻撃対象領域が小さい

スクレイピングとは他人が書いたコードを自社環境で実行する行為であり、ブラウザはそのまま攻撃対象になります。Chromiumは巨大なC++コードベースで脆弱性報告が続いていますが、 KitesurfはRustとWebAssemblyで新規実装され、機能が少ない分だけ狙える面も小さい。「軽くした」副作用として「堅くなった」と言えます。

STRENGTH 02

バーストに素直に追従する

V8 isolate方式で動くため、コンテナ方式より起動が軽い。「普段は0、必要な瞬間に1000ページ」という使い方でスケールしやすく、平常時にコストを抱えずに済みます。Cloudflareが「バースト型のワークロードに最適化」と説明しているのはこの部分です。

STRENGTH 03

消費リソースが読める

Chromiumのメモリ使用量は開くページ次第で乱高下します。広告の多いサイトを1枚開くだけで跳ね上がる。Kitesurfは機能が限られている分、上限が読めます。キャパシティ設計では、平均値より最悪ケースが見えることの方が価値が高い場面が多い。

STRENGTH 04

試すリスクがゼロに近い

切り替えは ?browser=kitesurf を足すか外すかだけ。コード変更なし、切り戻し即時。通常なら新技術の採用には検証コストと後戻りリスクが伴いますが、それがありません。処理の種類ごとに使い分けることもできます。

※ STRENGTH 01 は設計から導かれる解釈であり、Cloudflareが安全性を主張しているのを確認したものではありません。

画像で撮ると、見た目は変わる

同じ段落を撮り比べたものです。Chromium側は「タブ」「URLを入れる欄」が太字ですが、 Kitesurf側は太字が消えています。文字幅も広く、折り返し位置がずれます。

Chromium強調あり

Kitesurf強調なし

太字が消え、折り返し位置もずれている

判断レイアウトの大崩れを見つける用途なら十分使えます。ただしデザインの確認用キャプチャはChromiumで撮るべきです。切り替えはURLに ?browser=kitesurf を付けるかどうかだけなので、用途で使い分けられます。

おまけ：自社サイトで見つけたこと

①のスクリーンショットで、uhd-inc.jp のヘッダーの下が真っ白になっているのに気づいたでしょうか。これはKitesurfのせいではありません。Chromiumで撮っても同じです。スクロールしてから表示されるアニメーションの、初期状態が写っているだけです。

一方、②のテキスト出力では中身が4,703文字きちんと取れています。つまりコンテンツは存在していて、見えていないだけ。

ここから学べること自動監視を作るとき、画面を撮って判定すると、この状態を「壊れている」と誤検知します。逆に、本当にJavaScriptが落ちて真っ白になった事故は、 サーバーの応答だけを見る監視では絶対に気づけません。どちらで判定するかで結果が変わる、という実例です。

結論

どちらが優れているか、ではない

検証を通して分かったのは、「どちらが優れているか」という問いが成立しないということでした。

Chromiumは「人間が1枚のページを見る」ために作られ、 Kitesurfは「機械が何万枚も読む」ために作り直されたものです。用途が違うので、比べるべき軸そのものが違います。

比べる軸	優れているのは	根拠
機能の幅	Chromium	Kitesurfは3機能が非対応、ログイン維持もWebGLも不可
1回あたりの速さ	Chromium	テキスト抽出で8〜21%速い（実測）
描画の正確さ	Chromium	Kitesurfは太字が消え、折り返しがずれる（実測）
攻撃対象領域の小ささ	Kitesurf	Rust + WebAssemblyで新規実装、機能が少ない
バースト時のスケール	Kitesurf	V8 isolate方式で起動が軽い
リソース消費の読みやすさ	Kitesurf	Chromiumはページ次第でメモリが乱高下する
抽出される中身	同一	3サイトでSHA256まで一致（実測）

実務的な結論 「軽い処理を大量に、かつ不特定多数のサイトに対して回す」なら Kitesurf。 「正確さ・機能の幅が要る処理」なら Chromium。

切り替えはパラメータ1つなので、どちらか一方を選ぶ必要はありません。処理の種類ごとに使い分けるのが正解です。

未確認：料金

Browser Runの課金単位はブラウザの稼働時間（Paidプランで月10時間まで無料、以降 $0.09/時間）で、同時実行数はブラウザの「数」で数えられます（10本まで無料、以降 $2.00/本）。

Kitesurf専用の料金・制限は公表されていません。 「メモリ1/7」がこちらの請求にどう反映されるかは、正式版の価格発表を待つ必要があります。 「安くなる」を前提にした事業計画は、現時点では立てられません。