← すべての記事
ユースケース 読了時間 1 分

大規模な不動産リスティングの集約

不動産ポータルはそれぞれ異なるBot検知スタック、レイアウト、地域制限を採用しています。本稿では、6つのスクレイパーを個別に保守することなく、大規模に物件情報を集約する方法を解説します。

real-estateweb-scrapingproxy-rotationanti-botdata-aggregation

課題

チームが不動産リスティング製品をリリースしたとします。3週間は正常に動作します。しかし、ZillowがDOMを変更し、RightmoveがBot対策を強化すると、たった1回の週末で6つのソースのうち4つが停止します。

不動産データのアグリゲーションには、価格監視やSERPトラッキングにはない特有の問題があります。単一のクリーンなAPIから構造化データを取得するわけではありません。それぞれ異なるBot検知スタック、レイアウト、地域、更新頻度を持つポータルからリスティングをつなぎ合わせることになります。米国のZillow、MLSデータを扱うRedfin、英国のRightmove、オーストラリアのrealestate.com.au、ドイツのImmobilienscout24。すべてのポータルがそれぞれ独立したエンジニアリングプロジェクトです。

Scrapflyの2026年の調査によると、主要な不動産ポータルは接続レベルのシグネチャを検査し、ブラウザと同等のハンドシェイクに一致しないクライアントを拒絶します。同社のRightmoveガイドでは、JavaScript変数内に埋め込まれたJSONが数か月ごとに構造を変える様子が解説されています。Redfinはプロパティデータを数十のDOMノードに断片化しているため、わずかなレイアウト変更だけでフィールドの半分が一気に失われることがあります。また、地域ポータルは訪問者の国に基づいて異なるコンテンツを返すため、米国ベースのスクレイパーはrealestate.com.auで有用なデータを取得できません。

その結果、リスティングの鮮度は静かに低下します。物件の3分の1は48時間以内に陳腐化します。ユーザーには先週の価格が表示されます。営業チームは反発を受け始め、ポータルのレイアウト変更が週末に行われがちなため、月曜日にサポートチケットが急増します。

アプローチ

大規模なリスティングのアグリゲーションは、単なるスクレイピングの問題ではありません。実態は信頼性の問題です。スクレイパーが壊れ続ける理由では一般的なケースを扱っていますが、不動産分野ではそのすべての要素が増幅されます。

これを適切に処理するプラットフォームには、連携して機能する4つの要素が必要です。第1に、実際のブラウザと一致するリクエストシグネチャ（単にブラウザに似せたUser-Agent文字列ではなく、ZillowやRightmoveがBotと人間を区別するために使用する実際のワイヤレベルの詳細）。第2に、各ターゲット市場における地理的に正確な住宅用IP（ドイツのアグリゲーターがImmobilienscout24に米国データセンターのトラフィックを送信しても有用なレスポンスは得られません）。第3に、ホストごとのプロキシルーティング（Zillowで機能する戦略がrealestate.com.auでは失敗するため）。第4に、すべてをクライアントサイドで処理するポータルに対するフォールバックとしてのブラウザレンダリング。

FourAのProxy製品を使用してRightmoveに送信するリクエストのサンプルは、次のようになります。

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 フラグは、一致するワイヤレベルのシグネチャとともに完全なブラウザヘッダーセットを挿入します。maxTries: 5 は、いずれかが成功するまで最大5つのIPをローテーションするようプロキシマネージャーに指示します。検証ルールはサイレントブロック（物件データの代わりにソフト拒絶ページを返す200レスポンス）を検出します。そのため、成功率はHTTPステータスの主張ではなく、実際に成功した結果を反映します。

すべてをJavaScript経由で配信するポータル（代表例はRedfin）には、実ブラウザでのレンダリングが必要です。当社のBrowser製品は、最初の接続でフラグが立つ軽量エミュレータではなく、完全なブラウザインスタンスでこれらを処理します。Bot検知は行動ベースへと進化しており、実ブラウザ未満の環境はますます検知されやすくなっています。

結果

不動産アグリゲーターが独自のスクレイピングスタックからAPIファーストのアプローチに切り替えると何が起きるでしょうか。実際の運用で見られる傾向は以下のとおりです（業界ベンチマークに基づく想定シナリオ）。

  • 物件情報の鮮度: アクティブな市場において「48時間以内に更新」から「2時間以内に更新」へ改善
  • エンジニアリング工数: スクレイパーの保守時間が70%削減。専従チームではなく1名のエンジニアがローテーションで対応
  • ポータルカバレッジ: インフラを比例して増やすことなく、6サイトから20サイト以上へ拡大
  • サイレントブロック率: 検証ルールでソフトブロックを検知することで、保護されたポータルでの発生率が3%未満に低下

当社のプラットフォームを利用するチームに見られる傾向として、信頼性レイヤーを共通化すると、新しい市場の追加がスプリント単位の開発ではなく設定変更だけで済むようになります。関心事は「なぜまた壊れたのか」から「次にどのポータルを追加すべきか」へと移行します。

率直な制限事項として、ログインセッションが必要な不動産ポータル（一部のMLSシステムや特定のエージェント専用ビュー）では、リクエストインフラに加えてアカウント管理が必要です。これは当社が解決しない別の課題であり、方法を説明せずに対応可能と主張するベンダーは信頼すべきではありません。

要点

不動産は、データの陳腐化が単なる不便にとどまらない数少ない業界の一つです。それはプロダクトの欠陥となります。ファッションサイトで1週間前の価格が表示されていても多少気まずい程度ですが、過熱する不動産市場で1週間前の物件情報が表示されれば、火曜日に売却済みの物件についてユーザーが問い合わせてしまうことになります。

しかし、この分野で成功するチームは、最も多くのソースを持つチームではありません。新しいポータルごとに同じプロキシやリクエストの配管を再構築するのをやめたチームです。そのレイヤーが共有されれば、データの品質、鮮度のSLA、ポータル間の重複排除、価格トレンド分析といった本来の価値ある作業に集中できます。それこそがプロダクトです。その下層にあるものはすべて、ただ正常に機能すべきです。