ハクソク

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

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

76日前原文(developers.cloudflare.com)

概要

Cloudflare の Browser 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...

└

もし彼らが売却したり、CEOが変わったら、そうなるかもね。今のところ、誰かをいじめようとしている強い兆候は見せてないし、責任者が交代したら状況が大きく変わる可能性はあると思う。

└

みんなの無数のボットが、住宅プロキシから情報を引っ張って、何も気にせずに動いてるのが、完全に空間を占有してると思う。これに対して、遅いけど賢いボットがいるって感じかな。違法なストリートレースで街を荒らす酔っ払いのティーンエイジャーの群れと、タクシー運転手の違いみたいなもんだ。

└

それは今までなかったの？彼らは競合からのDDoS攻撃から多くのDDoS代行サイトを守ってるよ。その代わりに、インターネット上のDDoSの量を増やしてるけどね。150ドルでサービスを提供して、数ヶ月後には突然150,000ドルを24時間以内に要求してくる。そうしないとビジネスを潰すって脅してくるんだ。DNSレジストラとして使うと、ドメインを人質に取られるよ。

└

ずっとそうだよ。彼らは自分たちの優位な立場を利用して、国が物事を運営する方法が気に入らないときに政治的圧力をかけることもあるしね。だから、私たちは今後何年も苦しむことになるメガコーポモンスターを作り出してしまったんだ。

Cloudflareがどんどんクールなツールを手に入れてるな。AWSは、誰か起きてる？

これ、実際にすごいよね。Cloudflareは、まさにパックが行く場所にスケートしてる感じ。

このクローラーは、彼らのボットブロッカーのロジックの前で動くのか、それとも後ろで動くのか？

└

前面に: https://developers.cloudflare.com/browser-rendering/rest-api...

ここでのコストは本当に理解しづらいね。1秒あたりのページ数はどれくらいが妥当なの？礼儀正しく考えると、基本的に1秒あたり1ページ＝3600ページ/時ってことになるのかな？すごく遅い気がする。

注目すべき点: オリジンの所有者は、必要に応じてCFブラウザレンダリングのリクエストを検出してブロックすることができる。ワーカーからのリクエストには、ワーカーのサブドメインを識別するCF-Workerヘッダーが含まれていて、通常のCDNプロキシと区別できるんだ。これをWAFルールやオリジンミドルウェアでマッチさせることができる。もっと厄介な問題は、レンダリングされたリクエストがCloudflare ASN 13335から発信されていて、ボットスコアが低いこと。だから、コンテンツ保護のためにCFボットスコアに依存していると、彼らのクローリング製品を通じたリクエストはそのチェックをバイパスしちゃう。実際の防御策は、ネットワークレベルのスコアよりもアプリケーション層でのレート制限と行動分析が重要だよね。構造的な対立は現実だけど、検索エンジンがウェブマスターツールを提供しながらインデックスを運営しているのと似ている。インセンティブはずれてるけど、各製品には独自の有用性がある。より難しい質問は、この組み合わせが彼らのプラットフォーム上で効果的なボット保護を構築するのを意味深く難しくするかどうかだね。

└

彼らはrobots.txtに従うって言ってるけど、それが一番簡単な方法じゃない？

「メールで済むはずだった」じゃなくて、「プロンプトで済むはずだった」って感じだね。これをローカルで実行できる方法はいくつかあるよ。 自分専用のクローラーを作って、サイト内のすべてのページをクロールする（元のドメインへの内部リンクのみ、スクロールして人間のように見せかけ、出力をWebPのスクリーンショット、HTML、Markdown、構造化JSONとして保存する）。ヘッドレスのGoogle Chromeを使って、Linuxマシンのターミナルでローカルに実行できるように設計し、同時に複数のページを処理するためにマルチコアを活用する。ただし、同じIPからサーバーに過剰にアクセスしないようにスロットルする必要があるかもしれない。 使えるオープンソースソフトウェアとしては、python、playwright、beautifulsoup4、pillow、aiofiles、trafilaturaなどが考えられるね。

└

これは安くて効果的になると思う。プロンプトをこれにラップする方が、自分で全部クロールするよりずっと簡単だよ。ただし、クロールの要件を無視したいなら、結局は手作業になるけどね。

└

実は、そんなクローラーを前に書いたことがあるけど、最近のプロジェクトではFirecrawlを選んだよ。スケールでの頭痛の種が多すぎるんだ。重いページからのOOM、クラウドIPをブロックするサイト用のプロキシ、ネストされたiframeの処理とかね。

└

それはまさに「フクロウを描く」ミームみたいだね。細かいところが大事なんだ。マジで、細かいことがめっちゃ多いな…

うわー、ちゃんとクロールされた自分のサイトを提供できると思ってたのに。サイト管理者向けにそれを提供してくれたら面白いのにね。そうすれば、クロールしたい人は、純粋な転送コストだけで手に入れられるものを得られるし。自分でクロールジョブを提出して、各ページにアクセスできるstatic.サブドメインを提供することで作れるかも。そうすれば、純粋なHTMLで瞬時に読み込めるし。

└

その使い方がよくわからないな。あなたのサイトは静的なの？だったら、HTMLファイルにレンダリングして静的ファイルをホスティングすればいいじゃん。もし静的じゃないなら、ページが後で変わったときにスナップショットがどう役立つの？それに、サイトにキャッシングを追加すればいいんじゃないの？

構造化されたクローリングエンドポイントを公開するアイデアは、robots.txtやサイトマップの自然な進化のように感じるね。もっと多くのサイトがクローラー用の明示的な機械可読エントリーポイントを提供すれば、インデックス作成がかなり無駄がなくなると思う。今はクローラーが同じ構造を何度も再発見するのに多くの労力を使ってるしね。それに、サイトが人間と自動エージェントに対して異なるビューを提供するようになるのか、興味深い疑問も浮かぶよ。

└

サイトが人間と自動エージェントに対して異なるビューを提供するようになるのか、興味深い疑問も浮かぶよ。この疑問は、これがサプライチェーンのインジェクション攻撃を悪化させるかもしれないという面白い問題を提起するね。人間には無害なページを見せて、ボットには別のページを見せるって感じで。

└

RESTを使っていたら、インデックス作成はもっと無駄がなくなってたと思う。最近は、APIは人間のために機能させるべきだって強く思うようになってきたし、LLMプロバイダーにはそれに最適化してほしいな。例えば、CLIツールにMCPは必要ないし、良いマニュアルページか--helpのドキュメントがあれば十分なんだ。

└

ルートに?llm=trueを付けるだけで、マークダウン/テキストに切り替えるクエリパラメータを使ってるよ。簡単なパターンで、オプトイン式だね。

└

もうやってるよ…多くの知られたクローラーは、クローラー最適化されたページのバージョンを受け取るんだ。

└

明らかな問題を除けば、クローラーと人間に異なるものを提示するってことだね。