Webページから情報を取るとき、多くの場合はHTMLを丸ごと取得してから処理します。しかしAIに渡す前提なら、その時点で大量のノイズを含んだトークンを消費していることになります。
この検証では、Cloudflare Browser Renderingの各エンドポイントを軽い順に叩いて、何が取得できるかを比較しました。
この検証の概要
| 項目 | 内容 |
|---|---|
| 検証時期 | 2026年6月3日〜（検証中） |
| 対象 | Cloudflare Browser Rendering（Browser Run）REST API |
| やりたかったこと | ニュース一覧 → 記事URL収集 → 本文取得というパイプラインを、どのエンドポイントの組み合わせで最小コストに組めるか見極める |
| 方法 | 同一ページに対し、5つのエンドポイントを軽い順に実行して比較 |
| 結果 | 各エンドポイントとも取得成功 |
外部サイトのデータ取得は、対象サイトの利用規約およびrobots.txtを尊重して行う必要があります。
結論：用途別に最小コストの取得手段を選べる
5つのエンドポイントが、それぞれ異なる粒度で結果を返します。
| エンドポイント | 用途 | 取得物 |
|---|---|---|
/links | ページ内のリンク一覧（最軽量） | 全リンクURLの配列 |
/markdown | 本文をMarkdownで取得（LLMに優しい） | ノイズ除去済みMarkdown |
/content | レンダリング後のフルHTML | 実際のDOM全体 |
/json | AIで構造化データ抽出 | 整形済みJSON |
/scrape | CSSセレクタで特定要素だけ抽出 | 指定セレクタの要素 |
すべて POST .../browser-rendering/{endpoint} という同一形式で、Bodyに対象URLを渡すだけです。学習コストは低く、用途に応じて切り替えられます。
/markdown がトークン削減に効く
実務で最も効く発見です。
/markdown はHTMLのノイズを除いたMarkdownを返します。DOM全取得よりトークン消費が圧倒的に少なくなります。
実際に一覧ページで試したところ、記事タイトル・日付・URL・カテゴリがほぼ構造を保ったまま取得できました。
HTMLには、スクリプトタグ、スタイル、属性、ナビゲーション、フッターなど、内容とは関係のない要素が大量に含まれます。それをそのままAIに渡すと、読ませたい部分より周辺のほうが多くなります。
なお /content は実際のDOMが全て取得できましたが、コンテキストが過大になるため、この検証ログでは結果の掲載を割愛しています。それだけの分量になるということです。
2つのパイプライン構成
目的に応じて、2つの現実的な構成があります。
① 2段構成
/links でリンク収集
↓
/markdown で本文取得
/links は最軽量で、ページ内の全リンクURLが配列で返ります。24時間以内の記事に絞り込む前段として最適です。
一覧ページ全体を取得せず、URLだけ取ってから対象を絞り、必要な記事だけ本文を取る——この順番でコストが下がります。
② 一発で構造化
/json は背後でWorkers AIが動き、構造化済みJSONを返します。プロンプトで抽出項目を指定できます。
これが決まれば、後段のワークフローツール側でLLM処理を省略できる可能性があります。取得と構造化が1回のリクエストで完結します。
「取得してからAIで整形する」を「取得時点で整形させる」に変えられるという発想です。
SPAでの落とし穴
実装上の注意点です。
JavaScript重め・SPAのページでは、デフォルトのページ読み込み判定だと中身が空・不完全になることがあります。
対処は gotoOptions.waitUntil を networkidle0 / networkidle2 に設定することです。
「取得できたけど中身が空」という症状が出たら、まずここを疑います。エラーにならず成功扱いで空が返るため、気づきにくい部分です。
それぞれの使いどころ
| やりたいこと | エンドポイント |
|---|---|
| 一覧からURLだけ集めたい | /links |
| 記事本文をAIに読ませたい | /markdown |
| 特定の要素だけ確実に取りたい | /scrape（CSSセレクタ指定） |
| 取得と構造化を1回で済ませたい | /json（プロンプトで項目指定） |
| DOM全体が必要 | /content |
目的が決まっていれば、フルHTMLを取る必要はほとんどありません。
懸念点
- SPAでは
waitUntilの調整が必要で、設定を誤ると中身が空・不完全になる - 対象ページのDOM構造変更によりCSSセレクタが壊れる可能性（
/scrape使用時） - Cloudflare（Workers / Workers AI）への依存
2つ目は構造的な問題です。セレクタ指定は正確ですが、相手のページ構造に依存します。壊れる前提で、代替手段を用意しておく必要があります。
その点、/markdown や /json は構造変更に比較的強くなります。「どこを取るか」ではなく「何が欲しいか」で指定するためです。
よくある質問
どのエンドポイントを使うべきですか？
目的によります。URLだけなら /links、AIに読ませる本文なら /markdown、取得と構造化を1回で済ませたいなら /json です。フルHTMLが必要なケースは限られます。
なぜMarkdownで取るのですか？
HTMLのノイズを除いたテキストが返るため、トークン消費が圧倒的に少なくなります。一覧ページでも、タイトル・日付・URL・カテゴリの構造を保ったまま取得できました。
取得結果が空になります
JavaScript重めのページで、読み込み完了前に取得している可能性があります。gotoOptions.waitUntil を networkidle0 / networkidle2 に設定してください。
AIによる構造化は使えますか？
/json でプロンプトを指定して抽出できます。これが機能すれば、後段のワークフローでLLM処理を省略できる可能性があります。
まとめ
- 用途別に5つのエンドポイントがあり、目的に応じて最小コストの取得手段を選べる
/markdownはDOM全取得よりトークン消費が圧倒的に少ない。構造も保たれる- パイプラインは「
/linksでURL収集 →/markdownで本文取得」の2段構成が効率的 /jsonなら取得と構造化を1リクエストで完結でき、後段のLLM処理を省略できる可能性がある- SPAでは
waitUntilの調整が必要。設定を誤ると空の結果が成功扱いで返る - CSSセレクタ指定は正確だが相手のDOM構造変更に弱い
AIに渡すデータは、渡す前の整形でコストが決まります。取得の段階で必要な形にできれば、後段の処理そのものが不要になります。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の情報収集・業務自動化を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。