課題
あなたはB2B SaaSプロダクトを構築しています。顧客は企業名のリストをアップロードします。彼らは、売上規模、従業員数、技術スタック、資金調達ラウンド、主要な連絡先、最近のニュースといった、クリーンなレコードが返ってくることを期待しています。彼らはそれを数日後ではなく、数分以内に期待しています。And they expect it to be right.
データは存在します。それはCrunchbase、企業の会社概要ページ、LinkedInの企業ページ、Google Maps、Glassdoor、地域の商業登記、TechCrunchのアーカイブに存在しています。問題は、そこに信頼性高くアクセスすることです。
ソースごとに、壊れ方は異なります。Crunchbaseは、ボットを検知すると再レンダリングを行う重いクライアントサイドアプリケーションを提供しています。LinkedInはアグレッシブにrate limitを適用し、セレクターを修正するよりも早くDOMを変更します（ある人気コミュニティの投稿によると、バニラのPythonスクレイパーはアンチボットの壁に阻まれるまでに約50プロファイルしか取得できないとベンチマークされています）。企業のウェブサイトは、静的なHTMLから、コンテンツを表示するためだけにフルブラウザを必要とするシングルページアプリケーションまで多岐にわたります。地域のディレクトリは四半期ごとにレイアウトを変更し、国固有のブロックでアクセスを制限します。GroupBWTによる2026年の業界レポートによると、一部の業種では、アンチボットのアップデートやDOMの変動に対応するためだけに、クローラーの10〜15%が毎週の修正を必要としています。
そのため、エンリッチメントパイプラインは最初、5つのソースを対象としたクリーンな設計から始まります。半年後には、半分壊れたスクレイパー、リトライキュー、そして誰も開かなくなった#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経由でルーティングできます。この1つの機能だけで、エンリッチメントにおける最もコストのかかるバグクラス、すなわちデータベースにゴミデータを書き込んでしまうサイレントエラーを排除できます。
以下は、単一ソース呼び出しの構成です。
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秒から、キャッシュされたレジデンシャルルートで中央値1.5秒未満に低下します
- サイレントエラー率（データが空の200 response）は、
validateブロックがデータベースに到達する前にソフトフェイルをキャッチすることで、約8%から1%未満に低下します - スクレイパーのメンテナンスにかかるエンジニアリング時間は、1〜2人のフルタイムエンジニアから、ほとんど静かなままのSlackチャンネルへと減少します
- 保護されたディレクトリにおける初回パス成功率は、
unblocker: trueとクリーンなproxy idを組み合わせることで、90%台後半まで上昇します
もう1つ注目すべき数値があります。初回の正確性（正しいデータ、正しい企業）は、初回の成功率より約4ポイント遅れる傾向が見られました。ここでの教訓は、スクレイピングが難しいということではありません。実際に要求した企業に対してレコードを検証する必要が依然としてあるということです（このパターンについては、なぜウェブスクレイパーは壊れ続けるのかで解説しています）。
重要な数値は、proxyプールのサイズやrequest数ではありません。エンリッチメントのendpointが最初の試行で正しいデータを返す割合と、今後6ヶ月間のスクレイパーメンテナンスグラフの傾きです。
主なまとめ
エンリッチメントパイプラインは、スローモーションのように徐々に崩壊していきます。最初に作成したスクレイパーは、火曜日の時点では問題ないように見えます。3つ目のソースに達する頃には、夜の11時にセレクターをパッチ修正しています。10番目のソースに達する頃には、顧客ベースに合わせて拡大するメンテナンス負債を抱え込むことになります。20番目に達する頃には、チームの誰も次のソースを担当したくないため、新しいソースの追加を静かに停止しています。
ボトルネックは決してソースではありませんでした。それはルーティング、つまりすべてのURLに対して、常に正しいツール、正しいproxy、正しいバリデーションルールを選択することでした。このレイヤーを一度構築し、すでにそれを実行しているものに任せることで、チームはセレクターの破損をトリアージする代わりに、火曜日をプロダクトの開発に費やすことができます。