課題
B2B SaaSプロダクトを構築しているとしよう。顧客は企業名のリストをアップロードする。彼らは整理されたデータを期待している。収益帯、従業員数、技術スタック、資金調達ラウンド、主要な連絡先、最近のニュースなどだ。数日ではなく数分での返答を求めている。そして正確であることを期待している。
データは存在する。Crunchbase、企業の概要ページ、LinkedInの企業ページ、Google Maps、Glassdoor、地域の企業登記簿、TechCrunchのアーカイブなどにある。問題は、確実にそれを取得することだ。
ソースごとに壊れ方は異なる。Crunchbaseは、botを疑うと再レンダリングする重いクライアントサイドアプリを提供する。LinkedInは厳密なrate limitを設け、セレクタを修正するよりも早くDOMを変更する(ある有名なコミュニティの投稿では、ボット対策の壁に阻まれるまでにプレーンなPythonスクレイパーで約50プロファイルというベンチマークを出している)。企業のウェブサイトは、静的HTMLから、コンテンツを表示するだけでフルブラウザを必要とするシングルページアプリまで様々だ。地域のディレクトリは四半期ごとにレイアウトを変更し、国別ブロックでアクセスを制限する。GroupBWTの2026業界レポートによると、特定の分野では10〜15%のクローラーが、ボット対策の更新やDOMの変動に追従するためだけに毎週の修正を必要としている。
そのため、エンリッチメントパイプラインは最初はクリーンな5つのソースの設計として始まる。6ヶ月後には、半壊したスクレイパー、リトライキュー、そして誰も開かなくなった#scraper-alertsというSlackチャンネルの絡み合いになっている(以前、独自のスクレイパーを維持する隠れたコストについて書いた)。サポートキューにはデータ品質に関する苦情が積み上がる。チームは、社名を「5つのスクレイパーと祈り」にすべきだったと冗談を言い始める。
アプローチ
少しの間、スクレイパーのことは忘れよう。エンリッチメントの難しい部分は抽出ではない。ルーティングだ。どのソースにどのツール、どのproxy、どのリトライポリシーが必要か、そして何をもって「良い」responseとするかを決定することだ。
FourAのようなプラットフォームは、アクセスしようとしている3つのクラスのソースに直接マッピングされる3つのプロダクトを提供する。
静的HTMLディレクトリと登記簿 ほとんどの地域の企業登記簿と多くの古いB2Bディレクトリはサーバーサイドレンダリングである。それらは、クリーンなIPからの高速でオーバーヘッドの少ないHTTP requestを求めている。これにはSingleを使用する。1つのURLを入力し、1つのresponseを出力する。unblocker: trueを追加すれば、標準的なHTTPクライアントを完全に停止させるハンドシェイクレベルのブロックを通過できる。Singleは自動的にProxy Finderを経由してルーティングし、responseのトップレベルにproxy idを返す(r.proxy)。これにより、セッションの継続性が必要な場合に、後続の呼び出しでそれをproxy:"<id>"として渡し、同じ出口を維持できる。
JavaScriptを多用するSPA Crunchbase、LinkedInスタイルのアプリ、さらには中規模企業のサイトでさえ、単なるHTTP responseからは必要なデータを返さない。それらはクライアントでレンダリングされる。これにはBrowserを使用する。フルブラウザがページを実行し、JSを実行し、レンダリングされたHTML、cookie、スクリーンショットを返す。Singleと同様に、内部でProxy Finderを経由してルーティングされる。別途選択するステップは不要だ。
バリデーションを伴う混合ソース FourAのAPIへのすべてのrequestは、validateブロックを受け入れる。特定のステータスコード、headerの一致、またはbody内の部分文字列の一致を要求できる。responseがソフトフェイル(CAPTCHAを含む200ページ、空のデータシェル、または「申し訳ありません」というインタースティシャル)の場合、バリデーターはそれを拒否する。その後、パイプラインは同じURLを代わりにBrowser経由でルーティングできる。この単一の機能により、エンリッチメントにおける最もコストのかかるバグ、つまりデータベースにゴミを書き込むサイレントフェイルを排除できる。
単一ソースの呼び出しの形は次のとおりだ。
curl -X POST https://api.foura.ai/api/single \
-H "Authorization: Bearer pk_live_..." \
-d '{
"url": "https://registry.example.com/company/123",
"unblocker": true,
"followRedirects": 5,
"validate": {
"status": { "accept": [200] },
"data": { "fail": ["captcha", "blocked", "access denied"] }
}
}'
そして、JavaScriptを多用する企業サイト向けのBrowserの同等のものは次のとおりだ。
curl -X POST https://api.foura.ai/api/browser \
-H "Authorization: Bearer pk_live_..." \
-d '{
"url": "https://www.example-saas.com/about",
"unblocker": true
}'
ルーティングロジックは独自のパイプラインにある。信頼性は我々のものにある。どのソースにどのツールを適用するかはあなたが決定する。我々はそのツールが確実に通過することを保証する。
結果
パブリックベータ期間中、少数のチームが自社製スクレイパーからFourAルーティングのパイプラインに切り替えるのを見てきた。パターンは一貫している(ベータコホート全体で見たことに基づく説明用の数値)。
- エンリッチメントのレイテンシは、企業あたり3〜6秒から、cached-residentialルートでは中央値1.5秒未満に低下する
- サイレントフェイル率(空のデータを持つ200 response)は、
validateブロックがデータベースに到達する前にソフトフェイルを捕捉すると、約8%から1%未満に低下する - スクレイパーのメンテナンスにかかるエンジニアリング時間は、フルタイムエンジニア1〜2人から、ほとんど静かなSlackチャンネルへと減少する
unblocker: trueをクリーンなproxy idと組み合わせると、保護されたディレクトリでの初回成功率は90%台後半に上昇する
もう一つ注目すべき数値がある。初回パスの正確性(正しいデータ、正しい企業)は、初回パスの成功に比べて約4ポイント遅れをとっていることがわかっている。教訓はスクレイピングが難しいということではない。実際に要求した企業とレコードを照合してバリデーションする必要があるということだ(このパターンについてはウェブスクレイパーが壊れ続ける理由で書いた)。
重要な数値は、proxyプールサイズやrequest数ではない。エンリッチメントendpointが最初の試行で正しいデータを返す割合であり、今後6ヶ月間のスクレイパーメンテナンスグラフの傾きである。
重要なポイント
エンリッチメントパイプラインはスローモーションで失敗する。最初に書いたスクレイパーは火曜日には問題なく見える。3番目のソースになると、午後11時にセレクタにパッチを当てている。10番目になると、顧客基盤に比例するメンテナンス負債を抱えることになる。20番目になると、チームの誰も次のソースを担当したくないため、新しいソースのオンボーディングを静かに停止している。
ボトルネックは決してソースではなかった。ルーティングだった。つまり、すべてのURLに対して、毎回適切なツール、適切なproxy、適切なバリデーションルールを選択することだ。そのレイヤーを一度構築し、すでにそれを行っているものに引き渡せば、チームはセレクタの破損のトリアージの代わりに、火曜日をプロダクトに費やすことができる。