課題
チームがリスティング製品をリリースしたとします。3週間は正常に動作します。その後、ZillowがDOMを変更し、Rightmoveがボットチェックを強化し、単一の週末で6つのソースのうち4つでスクレイパーが機能しなくなります。
不動産の集約には、価格監視やSERPトラッキングにはない特有の問題があります。1つのクリーンなAPIから構造化データを取得するわけではありません。それぞれ異なるアンチボットスタック、レイアウト、地域、更新頻度を使用するポータルからリスティングをつなぎ合わせています。米国のZillow、MLSベースのデータを提供するRedfin、英国のRightmove、オーストラリアのrealestate.com.au、ドイツのImmobilienscout24などです。すべてのポータルが独自のエンジニアリングプロジェクトとなります。
Scrapflyの2026年の調査によると、主要な不動産ポータルは接続レベルのシグネチャを検査し、ブラウザレベルのハンドシェイクと一致しないクライアントを拒否します。彼らのRightmoveガイドでは、数ヶ月ごとに構造が変わるJavaScript変数に埋め込まれたJSONについて解説しています。Redfinは物件データを数十のDOMノードに分散させているため、1つのレイアウト変更でフィールドの半分が一度に失われる可能性があります。また、地域ポータルは訪問者の国に基づいて異なるコンテンツを提供するため、米国ベースのスクレイパーはrealestate.com.auで有用な情報を何も取得できません。
結果として、リスティングの鮮度は静かに低下します。物件の3分の1が48時間以内に古くなります。ユーザーは先週の価格を見ることになります。営業チームは反発を受け始め、ポータルのレイアウトは週末に変更される傾向があるため、月曜日にはサポートチケットが急増します。
アプローチ
大規模なリスティングの集約はスクレイピングの問題ではありません。それはスクレイピングを装った信頼性の問題です。一般的なケースについてはスクレイパーが壊れ続ける理由でカバーしています。不動産はそのすべての要素を増幅させます。
これをうまく処理するプラットフォームには、4つの要素が連携して機能することが求められます。第一に、実際のブラウザと一致するrequestシグネチャです(ブラウザ風のUser-Agent文字列だけでなく、ZillowやRightmoveがボットと人間を区別するために使用する実際のワイヤーレベルの詳細)。第二に、ターゲット市場ごとの地理的に正確な住宅用IPです。ドイツのアグリゲーターがImmobilienscout24に米国のデータセンタートラフィックを送信しても、有用なresponseは期待できません。第三に、ホストごとのproxyルーティングです。Zillowで機能する戦略はrealestate.com.auでは失敗するためです。第四に、すべてをクライアントサイドに押し付けるポータルに対するフォールバックとしてのブラウザレンダリングです。
FourAのProxy製品を通じてRightmoveに対するサンプルrequestは次のようになります。
curl -X POST https://api.foura.ai/api/proxy/ \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"maxTries": 5,
"timeout_ms": 45000,
"request": {
"method": "GET",
"url": "https://www.rightmove.co.uk/properties/123456",
"unblocker": true,
"followRedirects": 5,
"validate": {
"status": {"accept": [200]},
"data": {"fail": ["blocked", "access denied"]}
}
}
}'
unblockerフラグは、一致するワイヤーレベルのシグネチャとともに完全なブラウザheaderセットを注入します。maxTries: 5は、成功するまで最大5つのIPをローテーションするようにproxyマネージャーに指示します。検証ルールはサイレントブロックを捕捉します。つまり、リスティングデータではなくソフトブロックページを返す200のresponseです。そのため、成功率はHTTPステータスの主張ではなく、実際に機能したものを反映します。
すべてをJavaScript経由で提供するポータル(Redfinが典型例です)には、実際のブラウザレンダリングが必要です。当社のBrowser製品は、最初の接続でフラグを立てられる軽量エミュレータではなく、完全なブラウザインスタンスでこれらを処理します。2026年にボット検出は振る舞いベースに移行し、実際のブラウザ以外のものはますます目立つようになっています。
結果
不動産アグリゲーターがカスタムスクレイピングスタックからAPIファーストのアプローチに切り替えるとどうなるでしょうか。実際の運用で見られるパターンは以下の通りです(業界ベンチマークに基づくシナリオ例)。
- リスティングの鮮度が、アクティブな市場において「48時間以内の更新」から「2時間以内の更新」に向上します。
- スクレイパーの保守にかかるエンジニアリング時間が70%削減されます。専任チームではなく1人のエンジニアのローテーションで対応できます。
- インフラストラクチャを比例して増やすことなく、ポータルのカバー範囲が6サイトから20サイト以上に拡大します。
- 検証ルールがソフトブロックを捕捉するようになると、保護されたポータルでのサイレントブロック率が3%未満に低下します。
当社のプラットフォームを使用しているチームの1つのパターンとして、信頼性レイヤーが共有されると、新しい市場の追加はスプリントではなく設定変更になります。関心事は「なぜまた壊れたのか」から「次はどのポータルを追加すべきか」へと移行します。
誠実な制限事項として、ログインセッションを必要とする不動産ポータル(一部のMLSシステムや特定のエージェント専用ビュー)には、requestインフラストラクチャの上にアカウント管理が必要です。それは当社が解決しない別の問題であり、その方法を説明せずに解決すると主張する人を信用すべきではありません。
重要なポイント
不動産は、古いデータが単なる迷惑ではない数少ない業界の1つです。それは製品の失敗です。ファッションサイトでの1週間前の価格は少し恥ずかしい程度です。活況な市場での1週間前のリスティングは、火曜日に売れた家についてユーザーが問い合わせたことを意味します。
しかし、ここで勝つチームは、最も多くのソースを持つチームではありません。彼らは、新しいポータルのたびに同じproxyとアンチボットの配管を再構築するのをやめたチームです。そのレイヤーが共有されると、データ品質、鮮度SLA、ポータル間の重複排除、価格動向分析といった興味深い作業が始まります。それが製品です。その下のすべてのものは、単に機能するべきです。