課題
開発チームが物件情報プロダクトをリリースします。3週間は正常に動作します。しかし、ZillowがDOMを変更し、RightmoveがTLSチェックを強化すると、わずか1回の週末で6つのソースのうち4つでスクレイパーが機能しなくなります。
不動産情報の集約には、価格監視やSERPトラッキングにはない特有の課題があります。1つのクリーンなAPIから構造化データを取得するわけではありません。それぞれ異なるアンチボットスタック、異なるレイアウト、異なる地域、異なる更新頻度を持つポータルから物件情報を繋ぎ合わせる必要があります。米国のZillow、MLSベースのデータを扱うRedfin、英国のRightmove、オーストラリアのrealestate.com.au、ドイツのImmobilienscout24。すべてのポータルが、それぞれ独立したエンジニアリングプロジェクトになります。
Scrapfly's 2026 researchによると、主要な不動産ポータルはTLSフィンガープリントを検査し、ブラウザレベルのハンドシェイクを模倣していないクライアントを拒否します。彼らのRightmove guideでは、JavaScript変数に埋め込まれ、数ヶ月ごとに構造が変化するJSONの処理方法について解説しています。Redfinは物件データを数十個のDOMノードに分散させているため、レイアウトが1箇所変更されるだけで、一度に半分のフィールドが失われる可能性があります。さらに、地域限定のポータルは訪問者の国に基づいて異なるコンテンツを提供するため、米国ベースのスクレイパーではrealestate.com.auから有用な情報を取得できません。
その結果、物件情報の鮮度は静かに低下します。物件の3分の1は48時間以内に古くなります。ユーザーには先週の価格が表示されます。セールスチームは反発を受け始め、ポータルのレイアウト変更は週末に行われる傾向があるため、月曜日にはサポートチケットが急増します。
アプローチ
物件情報を大規模に集約することは、スクレイピングの課題ではありません。それは、スクレイピングの課題を装った信頼性の問題です。Why your scraper keeps breakingでは一般的なケースをカバーしていますが、不動産分野ではそのすべての要素が増幅されます。
これを適切に処理するプラットフォームには、連携して機能する4つの要素が必要です。第1に、実際のブラウザと一致するTLSフィンガープリント（単にブラウザに似せたUser-Agent文字列だけでなく、ZillowやRightmoveがボットと人間を区別するために使用する実際の暗号順序やClientHello拡張）。第2に、各ターゲット市場における正確な地域の住宅用IP。ドイツの集約事業者が米国のデータセンターのトラフィックをImmobilienscout24に送信しても、有用なレスポンスは期待できないからです。第3に、per-host proxy routing。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フラグは、一致するTLSフィンガープリントとともに完全なブラウザのheaderセットを挿入します。maxTries: 5は、成功するまで最大5つのIPをローテーションするようproxyマネージャーに指示します。検証ルールは、物件データの代わりにソフトブロックページを返す200 responseなどのサイレントブロックをキャッチします。そのため、成功率はHTTPステータスが主張するものではなく、実際に機能したものを反映します。
すべてをJavaScript経由で提供するポータル（Redfinが顕著な例です）は、実際のブラウザレンダリングを必要とします。当社のBrowser製品は、最初のハンドシェイクでフラグが立てられるような軽量のエミュレータではなく、実際のChromiumインスタンスを使用してこれらを処理します。Bot detection went behavioral（ボット検知は行動分析へと移行した）のは2026年のことであり、実際のブラウザに満たないものはますます検知されやすくなっています。
成果
不動産集約事業者がカスタムのスクレイピングスタックからAPIファーストのアプローチに切り替えると、何が起こるでしょうか。実際の運用で見られるパターンは以下の通りです（業界のベンチマークに基づく例示的なシナリオ）：
- 物件情報の鮮度：活発な市場において「48時間以内の更新」から「2時間以内の更新」に向上
- エンジニアリング時間：スクレイパーのメンテナンスにかかる時間が70%削減。専任チームの代わりに1人のエンジニアのローテーションで対応可能に
- ポータルのカバー範囲：インフラを比例して増やすことなく、6サイトから20サイト以上に拡大
- サイレントブロック率：検証ルールがソフトブロックをキャッチすることで、保護されたポータルでの割合が3%未満に低下
当社のプラットフォームを使用しているチームに見られる1つのパターンとして、信頼性レイヤーが共有されると、新しい市場の追加はスプリント開発ではなく、単なる設定変更になります。興味深い問いは「なぜまた壊れたのか」から「次にどのポータルを追加すべきか」へとシフトします。
率直な制限事項として、ログインセッションを必要とする不動産ポータル（一部のMLSシステム、特定のエージェント専用ビューなど）では、リクエストインフラに加えてアカウント管理が必要になります。これは当社が解決しない別の問題であり、その方法を説明せずに解決できると主張する者を信用すべきではありません。
主なまとめ
不動産は、データの鮮度の低さが単なる不便にとどまらない、数少ない業界の1つです。それはプロダクトの欠陥を意味します。ファッションサイトでの1週間前の価格は軽い当惑で済みます。しかし、活発な不動産市場における1週間前の物件情報は、ユーザーが火曜日に売却済みの住宅について問い合わせてしまうことを意味します。
しかし、この分野で勝利を収めるチームは、最も多くのソースを持つチームではありません。新しいポータルが登場するたびに、同じproxyやアンチボットの配管を再構築するのをやめたチームです。そのレイヤーが共有されれば、データ品質、鮮度のSLA、ポータル間の重複排除、価格トレンド分析といった、真に興味深い仕事が始まります。それこそがプロダクトです。その下にあるすべてのものは、ただ正常に機能するべきです。