- Cloudflare が Browser Rendering の新しい /crawl エンドポイントをオープンベータとして提供開始。たった 1 回の API 呼び出しでウェブサイト全体をクロール可能
- 開始 URL を送信すると、ページを自動的に探索し、ヘッドレスブラウザでレンダリングして、結果を HTML、Markdown、JSON 形式で返す
- Workers AI ベースの構造化 JSON 出力、クロール深度、ページ数制限、ワイルドカードパターンなどの スコープ制御機能に加え、増分クロール、静的モードなど多様な機能を提供
- robots.txt のルールを順守し、異常なトラフィックを防ぐ crawl-delay にも対応
- モデル学習、RAG パイプライン構築、サイト全体のコンテンツ調査およびモニタリングに活用可能
/crawl エンドポイント概要
- Cloudflare の Browser Rendering サービスに新たに追加された /crawl エンドポイントは、単一の API 呼び出しでウェブサイト全体を探索し、コンテンツを収集する機能を提供
- ユーザーが開始 URL を送信すると、システムが自動的にリンクをたどりながらページをレンダリングし、結果を返す
- 返却形式は HTML、Markdown、構造化 JSON から選択可能
- この機能は オープンベータ(open beta) として提供され、Workers Free および Paid プランの両方で利用可能
- クロール処理は 非同期(asynchronous) 方式で実行される
- URL を送信すると job ID を受け取り、その後、処理完了時点で結果を取得できる
- ページは順次処理され、完了した結果を段階的に確認可能
主な機能
- 複数の出力形式をサポート
- HTML、Markdown、JSON など、さまざまな形式で結果を返す
- JSON 形式は Workers AI を通じて構造化データとして提供
- クロール範囲の制御(crawl scope controls)
- クロール深度(depth)、ページ数制限、URL パターンの包含/除外設定が可能
- 自動ページ探索(automatic page discovery)
- サイトマップ(sitemap)、ページリンク、またはその両方をもとに URL を自動探索
- 増分クロール(incremental crawling)
modifiedSince と maxAge パラメータを使って変更されていないページをスキップし、時間とコストを削減
- 静的モード(static mode)
render: false 設定時はブラウザを起動せず、静的 HTML のみを取得し、静的サイトを高速にクロール可能
- 適切に振る舞うボット(well-behaved bot)
- robots.txt の指示を順守し、crawl-delay 設定も認識
活用例と参考ドキュメント
利用可能プラン
- Workers Free および Paid プランの両方で利用可能
5件のコメント
軽く試してみたけど、ボット対策は突破できないみたいですね。自分はまだしばらく
apifyやzyteを愛用することになりそうです……（笑）これってCloudflareのボット遮断機能も突破するんですか？
矛も売って盾も売るってことなんですか？？
なんだか変ですね（笑）
みんなのマーブルの始まりですね（笑）
何かのカードを防御する、何かの能力を無効化する、何かの特殊能力の……
wwwww なんだか面白いですね
Hacker News のコメント
私の経験では、Cloudflare で保護されたページではこれは動作しない
残念ながら、自分で問題を作っておいて、あとから解決策を売っているようなものだ
Cloudflare が、プロキシを使うウェブサイトの事前スクレイプ済みバージョンをホストしていないのは意外だ
たとえば https://www.example.com/cdn-cgi/cached-contents.json のような形で提供できそうだし、すでにキャッシュにコンテンツがあるのだから、わざわざスクレイピングサービスや API を通す必要はないと思う
もちろんそうしない理由はあるのだろうが、デフォルトのオプションとして提供していないのは驚きだ
アクセス制御をかけることもできるだろうが、それは結局、誰も望んでいない複雑な CDN APIを新たに作るようなもので、法的な問題も生じる
「便利な JSON」から「AI スクレイパーにサイト全体を渡す」までは紙一重だ
リクエストがあったときだけ変換すれば、オリジンへのリクエストを減らしつつ、キャッシュ効率も維持できる
私が CDN で働いていたときは、キャッシュヒット率を上げるために「second hit caching」を使っていた — 2回目のリクエストが来たときだけキャッシュに保存する方式だ
Markdown for Agents を有効にすると、AI システムが
text/markdownを要求した際に、HTML をリアルタイムで Markdown に変換してくれるCloudflare がスクレイピング対策を売りながら同時にスクレイピングサービスも売っているのは、まるで暴力団のようだ
インターネット全体にまたがる影響力があるからこそ可能なことだ
DNS はデータ収集と「善良なイメージ」作りのためだ
パブリッシャーが Cloudflare の背後にいて、AI 企業がデータを欲しがるなら Cloudflare 経由で有料アクセスさせる構図だ
一般ユーザーではなく、AI 企業が主な顧客層だ
/crawlエンドポイントはrobots.txtを尊重するつまり、クロール禁止の URL はレスポンスで
"status": "disallowed"と表示される構造化されたcrawl endpointを公開するのは、
robots.txtやsitemapの自然な進化のように感じるより多くのサイトがこうした機械可読な入口を提供すれば、インデックス作成ははるかに効率的になるだろう
今はクローラーが同じ構造を何度も再探索していて、無駄が多い
私は API を人間中心で設計し、その上で LLM プロバイダーが最適化する形のほうが好みだ
HTML と DOM は本質的に機械が読むための構造だ
新しいものを発明する必要はなく、既存技術を正しく活用すればよい
人間には正常なページを見せ、ボットには別のページを見せるといった悪用が考えられる
ウェブアーカイブ用途に使えただろうに、WARC フォーマットのサポートがないのは残念だ
記者や研究者には有用だったはずだ
オリジンサーバーは依然として Cloudflare のBrowser Rendering リクエストを検知してブロックできる
CF-Workerヘッダーで識別でき、WAF ルールやミドルウェアでフィルタリング可能だただし、これらのリクエストは Cloudflare ASN 13335 から来て低い bot scoreを持つため、単純なスコアベースの防御は通用しない
結局、アプリケーションレベルのレート制限と行動分析のほうが効果的だ
構造的な衝突はあるが、検索エンジンがウェブマスターツールを提供するのと似た状況だ
robots.txtに従うのだから、それが最も簡単な方法だこのクローラーが bot ブロックロジックの前で動くのか後で動くのか気になった
自分のサイトのうまくクロールされたバージョンを提供できたらいいのにと思っていた
サイト管理者にそうした機能を提供すれば、クローラーは単に転送料だけ払ってアクセスできるはずだ
自分のサイトを対象にクロールジョブを走らせ、
static.サブドメインで提供するような実装もできそうだサイトが静的なら単に HTML としてレンダリングしてホスティングすればよいし、動的ならスナップショットにどんな意味があるのか疑問だ
キャッシュを追加するほうがよいアプローチかもしれない
Cloudflare は最近、面白い機能を全部持っていっている感じがする
AWS は何をしているのだろう
今回の機能は本当に印象的だ
Cloudflare が未来の方向へ先回りして動いている