不動産データ収集とは、価格、ステータス、サイズ、位置、担当エージェント、そしてそれぞれが変更された日付といった、物件に関する構造化情報をポータルサイトやデータベースから取得することを指す。技術的な難しさは、このデータを保持するポータルがそれを自社の中核資産として扱い、それに応じて防御している点にある。
そのため、プロキシの選択が重要な意味を持つ。本ガイドでは、何を収集すべきか、主要ポータルからブロックされずに収集する方法、そして実際に機能するリクエスト頻度と更新サイクルについて解説する。
必要な構成
公開されている物件一覧ページには、ローテーティングレジデンシャルプロキシを使う。主要ポータルは、他の何かを確認する前にデータセンターのアドレス範囲を分類する商用の不正アクセス対策システムを稼働させているため、データセンタープロキシはレートに関係なく最初のリクエストで失敗する。
ログインが必要なもの（大半のMLSアクセスを含む）にはISPプロキシを使う。セッションを維持する必要があり、アドレスが変わるとセッションが無効になるためだ。
それ以外はすべてリクエスト頻度の規律の問題であり、プロキシの選択よりもこちらの方が重要になる。
何を収集すべきか
| 項目 | 重要な理由 | 更新頻度 |
|---|---|---|
| 物件IDとURL | 他のすべてが結合するキー | 1回のみ |
| 価格と価格履歴 | ほぼすべての分析における主要な信号 | 毎日 |
| ステータス（掲載中、保留中、成約済み、取り下げ） | 市場の動きの速さを示す指標の源 | 毎日 |
| 掲載日と更新日 | 市場滞留日数、中核となる健全性指標 | 毎日 |
| 住所、座標、郵便番号 | 地理的な集計 | 1回のみ |
| ベッドルーム数、バスルーム数、床面積、敷地面積 | 価格を比較可能な形に正規化する | 1回のみ |
| 物件種別と建築年 | セグメンテーション | 1回のみ |
| エージェントと仲介業者 | 市場シェア分析、および個人データであるため慎重に扱う | 1回のみ |
| 説明文と特徴 | テキスト分析、設備の抽出 | 週次 |
| 写真数とURL | 掲載品質の信号 | 週次 |
変化する項目と変化しない項目を区別することが、収集量を管理可能な範囲に保つ鍵となる。価格とステータスは毎日確認する必要がある。床面積は変化しないため、毎日再収集しても帯域を無駄に消費するだけだ。
MLSデータベースの監視
MLSデータは最も豊富な情報源であると同時に、最も制限が厳しい。これは公開ウェブサイトではない。アクセスは契約に基づいてライセンスを持つ参加者にのみ許可され、正規のルートはスクレイパーではなくデータフィードである。
- RESO Web APIは現代的な標準であり、JSONを返す構造化APIで、増分同期に対応しているため、前回のポーリング以降に変更されたレコードだけを要求できる。MLSアクセスの権限があるなら、これが正しい連携方法だ。
- RETSはより古いフィード標準で、一部の地域では今も使われているが、上記に取って代わられつつある。
- **フルではなく増分でポーリングする。**前回のタイムスタンプ以降の変更を要求すること。大規模なMLSの全件再取得は膨大かつ不要だ。
- **ライセンスを尊重する。**MLS契約は表示、保持、再配布を規定している。これに違反するとアクセス自体が危険にさらされ、それはどのデータセットよりも大きな損失となる。
ここではプロキシの重要性は公開ポータルほど高くない。あなたは認証済みの参加者だからだ。プロキシが役立つのは安定性の面であり、ISPプロキシは連携先に固定された1つのアドレスを提供する。これは、アクセスが登録済みのアドレスに紐づいている場合に重要となる。
主要ポータルからのデータ収集
公開ポータルこそ、プロキシが本領を発揮する場だ。それぞれ挙動が異なる。
Zillow
強力な不正アクセス対策と積極的なレート制限がある。検索結果ページは、各物件を訪問せずとも大半の概要項目を含んでいるため、効率的な入り口となる。
- **プロキシ：**ローテーティングレジデンシャル、米国向けジオターゲティング。
- **レート：**慎重に。アドレスごとに3〜5秒おきに1リクエスト。
- **注意点：**地図ベースの検索は、HTMLではなく内部エンドポイントを通じてデータを返すため、より効率的である一方、より厳しく監視されている。
Redfin
Zillowよりやや許容度が高く、構造も整っている。データはHTMLの解析を必要とせず、埋め込まれたJSONで取得できることが多い。
- **プロキシ：**ローテーティングレジデンシャル、米国向け。
- **レート：**アドレスごとに2〜3秒おきに1リクエスト。
- **注意点：**カバレッジは市場によって異なるため、物件が見つからないことは、それが存在しない証拠にはならない。
Realtor.com
MLSからの直接シンジケーションのため、データは最新であり、保護は中程度だ。
- **プロキシ：**ローテーティングレジデンシャル、米国向け。
- **レート：**アドレスごとに2〜4秒おきに1リクエスト。
RightmoveとZoopla
英国の二大ポータル。両者ともに防御しているが、Rightmoveの方が厳格だ。
- **プロキシ：**ローテーティングレジデンシャル、英国向けジオターゲティング。英国以外のアドレスからは異なる結果、または結果が表示されないことがある。
- **レート：**アドレスごとに3〜5秒おきに1リクエスト。
- **注意点：**両サイトは同じ物件を異なるエージェント経由で掲載しているため、物件IDではなく住所で重複を排除すること。
リクエストレート、ローテーション、並行性
収集が生き残るかどうかを決める最大の要因はレートだ。ブロックされる人の多くは、プロキシとして検知されたわけではなく、急ぎすぎていると検知されたのだ。
- **アドレスごとのレート：**ポータルでは2〜5秒おきに1リクエスト。必要以上に遅く感じるかもしれないが、それが並行処理の存在理由だ。
- **速度ではなく並行性：**より速く収集するには、間隔を短縮するのではなくアドレスを追加する。10個のアドレスで3秒おきに1リクエストなら、合計で毎秒約3リクエストとなり、10,000件の掲載を約1時間で処理できる。
- **ローテーション：**独立した物件ページを閲覧する場合はリクエストごとに切り替える。カーソルを持つ検索をページ送りする場合はスティッキーセッションを使い、ページ送りが完了するまでの間だけ保持する。
- **ジッターを加える。**正確に3.0秒間隔でのリクエストは特徴的なパターンとなる。2〜5秒の間で変化させること。
- **対象市場のタイムゾーンでオフピーク時に収集する。**基準となる通信量が少ないほど、自分のリクエストが全体に占める割合は小さくなり、レート制限も通常緩くなる。
ブロックが始まったとき
- **レスポンスを読む。**429はレート制限であり、遅くする必要があることを意味する。チャレンジページは、レートではなくフィンガープリントが問題であることを意味する。
- **まずレートを半分にする。**最も安価で、通常は正しい対処法だ。
- **ヘッダーとフィンガープリントを確認する。**それ以外何もないリクエストにむき出しの
User-Agentが付いているのは、明らかなボットの特徴だ。 - **ブロック中に再試行しない。**指数バックオフを使うこと。ソフトなレート制限を叩き続けると、そのアドレスへのハードな永久禁止に変わる。
- **対象を再検討する。**あるポータルの再試行コストがデータの見返りを上回るなら、Web Scraping APIがレンダリングとチャレンジ対応を代わりに処理してくれる。単価は高くなるが、メンテナンスの手間は大幅に少ない。
更新頻度
- **毎日：**新規掲載、ステータスの変更、価格の変更。分析上の価値のほぼすべてがここにある。
- **週次：**説明文、写真、エージェント詳細。掲載開始後はまれにしか変化しない。
- **1回のみ：**住所、座標、サイズ、物件種別。構造的な事実。
このようにスケジュールを分割することで、すべてを毎日再収集する場合と比べて、通常は帯域を半分以上削減できる上、信号の損失はない。
まとめ
不動産データ収集は、技術的な問題というよりも規律の問題がほとんどだ。ポータルはデータセンターのアドレスを一目で分類するため、レジデンシャルプロキシを使い、アドレスごとのリクエスト頻度は遅く保ち、代わりに並行性を追加し、更新スケジュールは各項目が実際にどれくらいの頻度で変化するかによって分割すること。
スクレイピング全般の仕組みについてはweb scraping proxiesを、商用アプリケーションについてはprice intelligenceを、法的な根拠についてはproxy and scraping legalityを参照してほしい。Shifterのresidential proxiesは、これらのポータルが求めるジオターゲティングに対応しており、料金はpricing pageに記載されている。