世界を動かす技術を、日本語で。

Cloudflareクローラーエンドポイント

概要

CloudflareBrowser Rendering で新たに /crawlエンドポイント が公開ベータとして登場。 1回のAPIコールで ウェブサイト全体をクロール 可能。 HTML・Markdown・JSON など多様な出力形式に対応。 非同期ジョブ管理 で効率的なクロール運用。 Workers Free/Paidプラン の両方で利用可能。

Cloudflare Browser Rendering /crawlエンドポイント概要

  • /crawlエンドポイント で、指定URLから サイト全体の自動クロール を実現
  • ヘッドレスブラウザ によるページレンダリングと自動リンク発見
  • HTML・Markdown・構造化JSON (Workers AI対応)での出力形式選択
  • API非同期設計 :ジョブIDで進捗・結果を個別取得
  • RAGパイプライン構築モデル学習用データ収集サイト監視 に最適

主要機能

  • 複数出力形式 :HTML、Markdown、JSONでのデータ取得
  • クロール範囲制御 :クロール深度・ページ数・ワイルドカードパターン指定
  • 自動ページ発見 :サイトマップ・ページ内リンクからURL抽出
  • インクリメンタルクロール :modifiedSince・maxAgeで変更のないページをスキップ
  • スタティックモード :render:false設定で静的HTMLのみ取得、静的サイトの高速クロール
  • ロボット遵守 :robots.txtの指示やcrawl-delayを厳守

利用手順

  • クロール開始API例
    • curl -X POST 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' -H 'Authorization: Bearer <apiToken>' -H 'Content-Type: application/json' -d '{ "url": "https://blog.cloudflare.com/" }'
  • 結果確認API例
    • curl -X GET 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl/{job_id}' -H 'Authorization: Bearer <apiToken>'

利用条件・推奨事項

  • Workers Free/Paidプラン の両方で利用可能
  • 公式ドキュメント 参照による詳細なAPI利用手順確認
  • 自サイトクロール時 はrobots.txt・sitemapsのベストプラクティス遵守

活用ユースケース

  • AIモデル用コーパス収集
  • RAG(Retrieval-Augmented Generation)パイプライン構築
  • サイト全体のコンテンツ監視・調査

Hackerたちの意見

Cloudflareが、Cloudflareのプロキシを使っているウェブサイトの事前にスクレイプされたバージョンをホスティングし始めていないのが驚きだな。例えば、https://www.example.com/cdn-cgi/cached-contents.jsonみたいな感じで。彼らはすでにウェブサイトのコンテンツをキャッシュに持ってるんだから、スクレイピングサービスやAPIの中間業者を省いて、公開しちゃえばいいのに。もちろん、そうしない理由はあるだろうけど、まだ提供してないのは意外だね(当然「デフォルトでオン」オプションとしてね)。

簡単なサイトにはそれでいけるかもしれないけど、もっと複雑なサイト(例えばSPA)をレンダリングするには、やっぱりブラウザを使った専用のスクレイピングサービスが必要だよね。

Cloudflareが、Cloudflareのプロキシを使っているウェブサイトの事前にスクレイプされたバージョンをホスティングし始めていないのが驚きだな。 もしかしたら、彼らはキャッシュしているコンテンツが公開されていると明確に特定できる場合に、裏でこっそりやってるかもしれないね。

それよりちょっと複雑だよ。これは彼らの製品であるブラウザレンダリングで、実際のブラウザを動かしてページを読み込み、JavaScriptを実行するんだ。単純なcurlでのスクレイピングよりも、もう少し手間がかかる。

https://blog.cloudflare.com/markdown-for-agents/

まあ、JSON形式への変換プロセスはCPUを使うし、結果を保存する必要があるから、実質的にキャッシュの負荷が倍になるんだよね。オンデマンドでやると、キャッシュされたバージョンを使えるから、オリジンに行く手間が省けるけど、キャッシュサイズを倍にする必要はない。もし同じサイトが何度もスクレイピングされたら、結果をキャッシュすることもできるけど、リクエストされないものをキャッシュする必要がなくなるから、無駄が減る。キャッシュの負荷管理はCDNのコストとパフォーマンスにとって大きな要素で、ストレージを最大限に活用したいし、できるだけ多くのページをキャッシュから提供したいんだ。CDNで働いていた経験から言うと、キャッシュのヒット率を最大化するために色々なことを試してたよ。実際、キャッシュヒット率を上げるための最も簡単で効果的なテクニックは、君が提案していることの逆をやることなんだ。コンテンツを事前にキャッシュする代わりに、「セカンドヒットキャッシング」をするんだ。つまり、コンテンツが2回リクエストされたときだけキャッシュに保存するってこと。多くのコンテンツは一度だけリクエストされて、二度と使われないから、キャッシュに保存するのは無駄なんだよね。2回目にリクエストされるまで待ってキャッシュすることで、単発で使われるページがキャッシュに入るのを避けられるし、全体のパフォーマンスにもあまり影響しない。なぜなら、キャッシュするのに最も役立つコンテンツはたくさんリクエストされるから、余計にオリジンにリクエストを1回追加するだけで済むんだ。

Cloudflareって、なんかマフィアみたいになってきた? スクレイピング対策を売ってるのに、今度はスクレイピングも売ってるんだもん。無料DNSのおかげで、ネット全体に影響力があるからできるんだろうね。

長い間、CloudflareはDDoS-as-a-serviceのサイトを誇らしげに守ってきたけど(もちろん、彼らは「ホスティング」してるとは言わないけどね)。

いや、10秒で確認できるよ: > /crawlエンドポイントは、robots.txtファイルの指示を尊重していて、crawl-delayも含まれてる。/crawlがクロールしないように指示されているすべてのURLは、レスポンスに「status": "disallowed」としてリストされるんだ。そんなクローラーにはスクレイピング対策なんて必要ないよ。

彼らの無料DNSは、全体のほんの一部に過ぎない。ウェブの30%以上が彼らのキャッシングサービスやルーティングサービス、DDoS保護サービスに依存しているっていうのが、主な魅力なんだ。彼らのDNSは、実際にはデータ収集と「善意」のフロントとして機能してるだけだよ。

Cloudflareは出版社とAI企業の仲介を試みてるみたい。もし出版社がCloudflareを支持して、Cloudflareのボット検出が出版社のリクエストでスクレイパーを止めるなら、出版社はデータをスクレイピングさせることができる(このエンドポイントを通じて)けど、そのためにはお金が必要になる。市場の希少性が生まれるんだよね。ターゲットオーディエンスは、あなたや私じゃないと思う。AI企業が支払うような人気ブログを持ってる人以外は。

いいえ: https://developers.cloudflare.com/browser-rendering/rest-api...

Hacker Newsで議論の続きを見る