ZillowスクレイパーのGitHub:2026年に使えるもの、壊れるもの

最終更新日 July 22, 2026
ZillowスクレイパーのGitHub:2026年に使えるもの、壊れるもの

「zillow scraper github」で検索すると、409件のリポジトリが見つかります。しかし、そのうち264件は1年以上更新されておらず、検索結果の件数だけでは現在の実用性を判断できません。

本記事では、主要なリポジトリの更新状況を調べ、実際のZillowページでの動作確認に加えて、GitHubのIssueやRedditで報告されている障害事例も確認しました。共通するのは、公開当初は動作していても、ZillowのDOM変更、ボット対策の強化、内部APIエンドポイントの廃止によって利用できなくなるケースが多いことです。コミュニティでも、*「スクレイピングプロジェクトは、ページやAPIの変更に対応するため、絶えずメンテナンスが必要だ」*と指摘されています。この記事では、2026年時点で動作するもの、動作が不安定なもの、その理由を整理し、GitHubのリポジトリを保守する方法と、Thunderbitのようなマネージドツールを検討しやすい場面を比較します。

ZillowスクレイパーのGitHubプロジェクトとは何か、誰に必要なのか?

「Zillowスクレイパー」とは、Zillowのサイトから物件情報を自動取得するスクリプトやツール全般を指します。対象は価格、住所、ベッド数、バスルーム数、専有面積、Zestimate、掲載ステータス、掲載日数、場合によっては価格履歴や税情報のような詳細ページのデータまで含まれます。GitHubのリポジトリが検討される主な理由は、無料で入手でき、オープンソースで、用途に合わせてカスタマイズできるためです。リポジトリをフォークして取得項目を調整し、出力を既存のパイプラインへ組み込む運用が考えられます。

主な利用者は次のように分けられます。

  • 不動産投資家:郵便番号ごとに案件を追い、値下げ、Zestimateとの乖離、掲載日数を見て機会を絞り込みたい
  • エージェント:営業先リストを作るために、掲載URL、担当エージェント情報、掲載ステータスの変化が必要
  • 市場調査担当者やアナリスト:住所、平方フィート単価、売却価格と掲載価格の差、在庫数などの構造化された比較データが欲しい
  • オペレーションチーム:定期的に市場ごとの価格や在庫を監視したい

いずれの用途でも必要になるのは、一回限りのコピー&ペーストではなく、構造化され、繰り返し利用できるデータです。スクレイピングにはその利点がある一方、リポジトリが動かなくなった場合の保守負担もあらかじめ見込む必要があります。

2026年版 Zillowスクレイパー GitHub リポジトリ監査:実際にまだ動くものはどれか

GitHub上でスター数とフォーク数が多いZillowスクレイパーのリポジトリを抽出し、最終コミット日、公開Issue、実際のZillowページでの動作を確認しました。判定基準は次のとおりです。2026年4月時点で、Zillowの検索結果ページまたは詳細ページから正確な物件データを返せるものを「動作中」としました。動作してもデータが不完全な場合、数ページ後にブロックされる場合、対応ページが限られる場合は「部分的に動作中」です。完全に失敗するもの、またはメンテナーが終了を明言しているものは「破損」としています。

確認した範囲では、12〜18か月前には利用可能だったリポジトリでも、現在は動作しないものが複数ありました。

厳選比較表:主要なZillowスクレイパー GitHub リポジトリ

zillow_scraper_repo_audit_v1_0c4f771ad2.png

リポジトリ言語スター数最終更新アプローチ2026年の状態主な制約
johnbalvin/pyzillPython962025-08-28Zillowの検索/詳細抽出 + プロキシ対応部分的に動作中READMEには「ローテーションする住宅用プロキシを使う」と記載。IssueにはCloudflareのブロック、proxyrack経由の403、プロキシ使用時でもCAPTCHAが含まれる。
johnbalvin/gozillowGo102025-02-23物件URL/IDと検索メソッド向けのGoライブラリ部分的に動作中pyzillと同じメンテナーだが、採用例が少なく、Issueも少ない。信頼度は低め。
cermak-petr/actor-zillow-api-scraperJavaScript592022-05-04内部Zillow APIの再帰呼び出しを使うホスト型アクター部分的に動作中(リスクあり)うまい設計で、地図の境界を再帰的に分割して件数制限を回避している。ただしGitHubリポジトリは2022年以降更新されていない。Issueのタイトルには「これはまだ動いていますか?」というものがある。
ChrisMuir/ZillowPython1702019-06-09Selenium破損READMEには明記されています。「2019年時点で、このコードはほとんどのユーザーにとってもう動きません。」ZillowはWebDriverを検知し、延々とCAPTCHAを表示します。
scrapehero/zillow_real_estatePython1522018-02-26requests + lxml破損「空のデータセットを返す」「.csvファイルに出力がない」「このリポジトリはまだ更新されていますか?」といったIssueがあります。
faithfulalabi/Zillow_ScraperPython/notebook302021-07-02ハードコードされたSelenium破損教育用プロジェクトで、テキサス州アーリントンの賃貸物件に固定されています。汎用スクレイパーではありません。
eswan18/zillow_scraperPython102021-04-10スクレイパー + 処理パイプライン破損リポジトリはアーカイブ済みです。
Thunderbitノーコード(Chrome拡張)N/A継続的に更新AIがページ構造を読み取り、事前構築済みのZillowテンプレートを利用動作中GitHubリポジトリの保守は不要。Zillowのレイアウト変更にもAIが自動対応。無料プランあり。

比較すると、現在も利用できるコードは一部に残っていますが、検索上位には学習用プロジェクト、更新が停止したリポジトリ、住宅用プロキシを前提とする実装も含まれます。スター数だけでなく、最終更新日、Issue、必要なプロキシ環境、実際の出力結果を確認することが重要です。

「動作中」「破損」「部分的に動作中」の意味

このラベルは、スター数よりはるかに重要なので、正確にしておきたいと思います。

  • 動作中:テスト日において、Zillowの検索ページや詳細ページから正確な物件データを返せる。メンテナーがプロジェクト終了を明言していない
  • 部分的に動作中:動くものの、データが不完全だったり、数ページ後にブロックされたり、特定のページだけでしか動かなかったりする。通常はプロキシ基盤と継続的な調整が必要
  • 破損:データを返せない、エラーを出す、またはメンテナーやコミュニティから明確に機能停止とみなされている

170スターあるのに「破損」しているリポジトリは、10スターしかなくてもちゃんとデータを返すリポジトリより価値が低いのです。人気は過去の記録であって、品質の証明ではありません。

ZillowスクレイパーのGitHubプロジェクトが壊れる理由(5つの典型的な失敗パターン)

なぜZillowスクレイパーが壊れるのかを理解することは、どんなREADMEよりも時間を節約してくれます。理由が分かれば、より壊れにくいものを作ることもできますし、保守コストに見合わないと判断することもできます。

1. DOMの再構成(ZillowのReactフロントエンド)

ZillowのフロントエンドはReactで構築されており、頻繁に変わります。クラス名、コンポーネント構造、データ属性が予告なく変わるのです。今日 div.list-card-price を狙うスクレイパーは、明日にはそのクラス名が消えているかもしれません。あるStack Overflowの回答が指摘しているように、Zillowでは「クラス名がページごとに異なる」のです。

結果として、スクリプトは動いているのに空欄のままになり、1週間も空データを集め続けてから初めて気づく、ということが起きます。

2. 内部APIとGraphQLエンドポイントの変更

一部のリポジトリはHTMLを解析せず、Zillowの内部GraphQLやREST APIに直接アクセスします。たとえば actor-zillow-api-scraper は、Zillowの内部APIを使い、結果件数の制限を回避するために地図の境界を再帰的に分割します。この方式も、Zillowがエンドポイントやレスポンス仕様を変更すると動作しなくなる可能性があります。その場合、スクレイパーは404を返すか、明示的なエラーがないまま空のJSONを返すことがあります。

コード自体を変更していなくても、接続先の仕様変更によって出力が停止するため、レスポンス内容まで監視する必要があります。

3. ボット対策とCAPTCHAの強化

Zillowはボット検知を段階的に強化してきました。2026年4月の検証では、requests.get() を使って zillow.comzillow.com/homes/Chicago,-IL_rb/ の両方にアクセスしたところ、CloudFrontから403レスポンスが返りました。Chrome風のUser-AgentとAccept-Languageヘッダーを付けた場合も同様でした。コミュニティでは、逆解析したAPIフローが約100リクエスト後に403を返すようになったという報告もあります。

少量のテストでは動作しても、リクエスト数やアクセス条件が変わると失敗する可能性があります。複数の郵便番号で継続的に物件を追跡する場合は、テスト時の成功だけで本番運用の安定性を判断しないことが重要です。

4. 有料データのログイン壁

Zestimateの詳細、税情報、一部の価格履歴などは、認証が必要なページに表示される場合があります。オープンソースのスクレイパーがログインフローに対応していないと、これらの項目が空欄になる可能性があります。価格履歴や固定資産評価額を必要とする用途では、対象項目が認証なしで取得できるか、事前に確認する必要があります。

5. 依存関係の劣化と未保守リポジトリ

scrapeheroリポジトリのIssueには、No module named 'unicodecsv' のようなインストール問題があります。eswan18のリポジトリには、手動のドライバ設定やGIS依存関係の面倒さが記されています。Pythonライブラリの更新が互換性を壊すのです。6か月以上更新されていないリポジトリは、Zillowのボット対策に触れる前に、クリーンインストールの時点で失敗しがちです。

2026年のZillowボット対策:確認すべき技術要素

プロキシの利用やヘッダーのローテーションだけでは、現在のZillowで安定した取得を保証できません。IPアドレス以外の検知要素も含めて確認する必要があります。

IPブロックを超えて:TLSフィンガープリンティングとJavaScriptチャレンジ

Zillowのボット検知は、IPアドレスだけで判断されるとは限りません。コミュニティの報告では、ZillowはCloudflareの背後にあり、単純なレート制限に加えてフィンガープリンティングとボット検知が行われているとされています。TLSフィンガープリンティングでは、暗号化通信を開始する際のクライアント固有の特徴から、一般的なブラウザ以外のアクセスを識別できる場合があります。プロキシを変更しても、TLSの特徴が通常のChromeブラウザと大きく異なれば、検知対象になる可能性があります。

JavaScriptチャレンジも別の判定要素です。JavaScriptを十分に実行しないヘッドレスブラウザや、navigator.webdriver = true のような自動化の痕跡を露出する環境は、検知される可能性があります。

検索ページと物件詳細ページ:防御レベルは違う

Zillowのすべてのページが同じ強度で守られているわけではありません。Apifyの不動産スキーマでは、詳細ページを飛ばす「Fast Mode」と、より豊富なデータを含む遅い「Full Mode」を明確に区別しています。ThunderbitのZillowガイドでも、最初の一覧取得と、詳細ページを取得する「サブページのスクレイピング」を分けています。

実務上のポイントは、検索結果ページでは問題なく動いても、個別物件ページでは失敗することがあるということです。Zillowは、価値が高く、より頻繁にスクレイピングされるデータほど強く防御するからです。

HTTPのみで取得する方法とブラウザ自動化の違い

Selenium、Playwright、Puppeteerを使わず、HTTPリクエストだけで取得したい開発者もいます。ブラウザ自動化は処理が遅く、必要なリソースが多く、規模を拡大する際のデプロイも複雑になりやすいためです。

一方、2026年のZillowでは、HTTPのみの方式で安定運用するには、ヘッダーやクライアントフィンガープリントを継続的に管理する必要があると考えられます。コミュニティの報告を見る限り、ブラウザレンダリングを使う構成も比較対象に含め、対象ページ、取得量、運用コストに応じて選ぶのが現実的です。

Zillow向けの具体的なボット対策と運用上の注意点

zillow_scraper_antibot_v1_316931a4bc.png

自作する場合は、次の運用要素を確認します。

  • 人間の閲覧に近いランダムなリクエスト間隔を使う。固定遅延ではなく、セッション単位で可変間隔を設定する
  • 現実的なヘッダー設定を使う。Accept-LanguageSec-CH-UA 系のヘッダー、適切なrefererの連鎖を含める。ただし、ヘッダーだけで安定した取得を保証できるわけではない
  • セッションのローテーションを行う。同じプロキシとクッキーの組み合わせを長時間使い続けない
  • ブラウザレンダリングへの切り替えを判断する。HTTPのみの方式で一定量のアクセス後に403が続く場合は、取得方式を見直す

特定のヘッダー設定だけで、2026年のZillowから安定して取得できるとは限りません。対象サイトの利用規約を確認し、アクセス頻度と取得範囲を抑えて検証する必要があります。

Thunderbitのクラウドスクレイピングは、プロキシやブラウザレンダリングを自分で構築せずにZillowデータの取得を試したい場合の選択肢です。ローテーション基盤、レンダリング、ボット対策に関する設定をサービス側で扱うため、利用者の運用作業を減らせる可能性があります。ただし、対象ページや取得量によって結果は異なるため、まず少量のデータで取得精度と安定性を確認してください。

AIでZillowスクレイピングを試す

Zillowスクレイパーを長期運用しやすくするための実践策

GitHubのリポジトリや自作スクリプトを選ぶ場合は、短期間の動作確認だけでなく、仕様変更を検知し、修正できる運用を用意する必要があります。ここでは、保守性を高めるための実践策を整理します。

自動生成されるクラス名への依存を減らす

リポジトリがZillowの自動生成CSSクラス名に強く依存している場合は、保守性を確認する必要があります。クラス名は変更される可能性があるため、次の方法も検討します。

  • aria-labeldata-* 属性、近くの見出しテキストを手がかりに要素を特定する
  • 可能な限りテキスト内容ベースのセレクターを使う
  • Zillowがページソース内に構造化データを返すなら、HTMLパースよりJSON優先で抽出する

自動ヘルスチェックを入れる

Zillowスクレイピングは、一回きりのスクリプトではなく、本番監視として扱ってください。cronジョブかGitHub Actionsを設定し、次を毎日実行します。

  1. 既知の物件1件に対してスクレイパーを実行する
  2. 出力スキーマを検証する(期待する項目がすべて存在し、空でないか)
  3. 出力が壊れているか空ならアラートを出す

これで、数週間後ではなく24時間以内に壊れたことを検出できます。

依存関係のバージョン固定と仮想環境の利用

PythonでもNodeでも、依存関係は必ず特定バージョンに固定してください。仮想環境やDockerコンテナを使いましょう。今回の監査に出てきた古いリポジトリを見ると、インストールの劣化がどれだけ早く進むかが分かります。壊れる最初の要因は、Zillowのボット対策ではなく、依存関係であることも多いのです。

スクレイピング量は控えめにする

約100リクエストの閾値は固定の上限ではありません。ただし、少量のテストでは動作しても、リクエスト数が増えると挙動が変わる可能性を示す事例ではあります。リクエストはセッションごとに分散し、適切な間隔を設定してください。一度に大量取得する前に、小規模な検証で成功率とエラーの発生状況を確認することが重要です。

自作が見合わないタイミングを見極める

スクレイパーの保守に、データ分析より多くの時間を使っているなら、経済性は逆転しています。それは失敗ではありません。マネージドな解決策を検討すべきサインです。

ZillowスクレイパーのGitHub(DIY) vs ノーコードツール:運用条件で比較

Zillowデータの取得方法は、コードと処理基盤を自社で管理したい場合と、表計算ソフトなどへ必要なデータを短時間で出力したい場合で選択肢が異なります。開発者にはGitHubのリポジトリが適することがありますが、不動産担当者やオペレーションチームにはノーコードツールが扱いやすい場合があります。以下では、セットアップ、保守、カスタマイズ、コストの違いを比較します。

横並び比較表

zillow_scraper_decision_v1_f44b8159c9.png

比較項目GitHubスクレイパー(Python)ノーコードツール(例:Thunderbit)
セットアップ時間30〜120分(環境、依存関係、プロキシ)約2分(拡張機能を入れてスクレイプを押すだけ)
保守継続的に必要。Zillowの変更で壊れる不要。AIがページ構造に自動適応
ボット対策対応手動(プロキシ、ヘッダー、遅延)組み込み済み(クラウドスクレイピング、ローテーション基盤)
データ項目自由自在。コードした分だけAI提案またはテンプレートベース
エクスポートコードでCSV/JSONExcel、Google Sheets、Airtable、Notionへ無料出力
コスト無料(コード)+ プロキシ費用(住宅用で$3.50〜$8/GB)無料プランあり。以降はクレジット制
カスタマイズ上限実質無制限(コードを自分で持つ)高い(項目AIプロンプト、サブページスクレイピング)だが上限あり

プロキシ費用の現実

GitHubのリポジトリ自体は無料でも、住宅用プロキシが必要な構成では別途費用が発生します。公開されている価格例は次のとおりです。

提供元価格(2026年4月時点)
Webshare1GBで$3.50、まとめ買いで単価低下
Decodo従量課金で約$3.50/GB
Bright Data名目上は$8/GB、現在のプロモで$4/GB
Oxylabs$8/GBから

このため、Zillowの取得方法を比較する際は、コードの価格だけでなく、プロキシ、実行環境、保守にかかる費用も含めて判断する必要があります。

GitHubリポジトリを選ぶべきケース

  • コードを書くことや保守することが苦にならない
  • かなり細かいカスタマイズが必要(独自のデータ変換、独自パイプライン連携など)
  • 壊れたときに直す時間と技術力がある
  • プロキシ基盤の管理を引き受けられる

Thunderbitが候補になるケース

  • コードを保守せず、まずZillowデータを表形式で取得できるか試したい
  • 開発者ではない不動産エージェント、投資家、オペレーション担当者が利用する
  • Google Sheets、Airtable、Notionへ直接エクスポートしたいが、出力用のコードは書きたくない
  • 詳細ページから追加項目を取得するサブページスクレイピングを試したい
  • 定期スクレイピングの条件を自然言語で指定したい

対象ページや取得項目によって結果は異なるため、まず少量の物件で抽出精度、必要な項目、出力形式を確認するのが現実的です。

Zillowスクレイピング用にThunderbitをインストール

ステップごとに解説:ThunderbitでZillowをスクレイピングする方法(GitHub不要)

ノーコードの流れは、GitHubのセットアップとはまったく違います。

STEP 1: ThunderbitのChrome拡張をインストールする

Chrome Web Store に行き、Thunderbitをインストールして、サインアップします。無料プランがあります。

STEP 2: Zillowに移動してThunderbitを開く

任意のZillow検索結果ページ、たとえば特定の郵便番号の売り出し物件ページを開きます。ブラウザのツールバーにあるThunderbit拡張機能アイコンをクリックします。

STEP 3: Zillowのインスタントスクレイパーテンプレートを使う(またはAIに項目を提案させる)

Thunderbitには事前構築済みのZillowテンプレートがあります。対象ページでテンプレートを選び、提案された項目を確認してから実行します。テンプレートは、住所、価格、ベッド数、バスルーム数、平方フィート数、担当エージェント名、担当エージェントの電話番号、掲載URLなど、標準的な項目を対象としています。

別の方法として、「AIで項目を提案」をクリックすると、AIがページを読み取り、列の候補を提示します。ページによっては、Zestimateを含む20項目以上が検出される場合があります。実行前に、必要な項目が含まれているか、サンプル結果で確認してください。

STEP 4: スクレイプをクリックして結果を確認する

「スクレイプ」をクリックすると、Thunderbitがページネーションやデータの構造化を処理し、結果を表形式で表示します。実行後は、行数、空欄、重複、物件URLを確認してください。対象ページやアクセス状況によっては403エラーや欠損が発生する可能性があるため、少量の結果で問題がないことを確認してから取得範囲を広げます。

STEP 5: サブページデータで情報を拡張する(任意)

「サブページをスクレイプ」をクリックすると、各物件の詳細ページから、価格履歴、税情報、土地面積、学校評価などの追加項目を取得できる場合があります。GitHub構成では、詳細ページ向けのセレクターとボット対策を別工程として実装する必要があります。Thunderbitでは同じ画面から設定できますが、ページによって表示項目や取得可否が異なるため、必要な列が埋まるか確認してください。

STEP 6: データをエクスポートする

Excel、Google Sheets、Airtable、Notionへのエクスポートに対応しています。必要に応じてCSVやJSONとしてダウンロードすることもできます。利用できる出力先や無料枠の条件は、現在のプランで確認してください。

GitHubの構成では、環境構築、出力処理、403エラーなどへの対応を自分で実装する必要があります。Thunderbitを使う場合も、出力前に欠損や重複がないかを確認することが重要です。

CSVからインサイトへ:Zillowデータをどう使うか

CSVを取得しただけでは、業務上の判断には直結しません。取得したデータを整理し、用途に応じて分析、共有、監視へつなげる必要があります。

以下では、スクレイピング後のデータを実務で利用するまでの流れを整理します。

STEP 1: スクレイプ — 掲載データを集める

検索結果からの主要項目:価格、ベッド数、バスルーム数、平方フィート数、住所、Zestimate、掲載ステータス、掲載日数、掲載URL。

STEP 2: 拡張 — サブページスクレイピングで詳細ページデータを取る

物件詳細ページでは、価格履歴、税情報、土地面積、HOA費用、学校評価、エージェント連絡先などを追加項目として検討できます。Thunderbitのサブページスクレイピングを使う場合は、詳細ページから必要な列を取得できるか、サンプルで確認します。GitHub構成では、詳細ページ向けのセレクターとボット対策ロジックを備えた別工程が必要です。

STEP 3: エクスポート — 好きなプラットフォームへ送る

  • Google Sheets:簡単な分析と共有
  • Airtable:ミニCRMや案件トラッカー
  • Notion:チーム用ダッシュボード
  • CSV/JSON:独自パイプライン向け

STEP 4: 監視 — 定期スクレイプをスケジュールする

定期取得では、当日のデータを保存するだけでなく、値下げ、ステータス変更(active → pending → sold)、新規掲載を継続的に確認できることが重要です。これらは、コミュニティでも自作運用の課題として報告されています。

Thunderbitのスケジュールスクレイパーでは、「毎週火曜と金曜の午前8時」のように自然な言葉で実行間隔を指定できます。GitHub構成では、cronジョブ、認証状態の維持、失敗時の通知と復旧を自分で管理する必要があります。いずれの場合も、取得失敗を検知するアラートを用意しておくと運用しやすくなります。

STEP 5: 実行 — 案件を絞り、営業ワークフローにつなげる

ここでデータが意思決定に変わります。

  • 投資家向け:30日で5%以上値下げ、掲載日数90日超、Zestimateより安い物件を絞り込む
  • エージェント向け:買い手条件に合う新規掲載、営業候補として失効/取り下げ物件を抽出する
  • 調査担当向け:平方フィート単価の推移、売却価格と掲載価格の比率、在庫回転率を算出する

実例:3つの郵便番号で200件の物件を追う投資家

利用ケースごとに、どんなデータ項目になるかを整理するとこうなります。

データ項目投資エージェントの見込み客市場調査
価格✅ 基本
Zestimate✅ 基本(乖離分析)
価格履歴✅ 基本(トレンド検出)
掲載日数✅ 基本(動機の指標)
税評価額✅(評価額の照合)
掲載ステータス✅ 基本
掲載日
エージェント名/電話番号✅ 基本
平方フィート単価✅ 基本
売却価格と掲載価格✅ 基本

投資家は3つの郵便番号にまたがる週次スクレイプを設定し、Google Sheetsに出力して、値下げと掲載日数の外れ値に条件付き書式を適用します。エージェントはAirtableに出力して、営業パイプラインを作ります。調査担当者はスプレッドシートに取り込み、トレンド分析を行います。同じスクレイピングでも、ワークフローは3通りです。

Zillowをスクレイピングする際の法的・倫理的な考慮点

Zillowデータを取得する前に、対象となる規約と利用方法を確認する必要があります。

Zillowの利用規約には、スクリーンスクレイピング、クローラー、スパイダー、CAPTCHA類の保護回避を含む自動問い合わせに関する禁止事項が記載されています。robots.txt でも、/api//homes/、クエリ状態付きURLを含む範囲に対するクロール方針が示されています。規約とrobots.txtは更新される可能性があるため、実行前に最新版を確認してください。

米国のWebスクレイピング法は、「スクレイピングはすべて違法」または「公開データなら常に合法」と一律に判断できるものではありません。CFAAに関するhiQ v. LinkedInの系列判例は、公開データへのアクセスを考える際の重要な事例です。Haynes Booneの2026年4月の新しい要約では、第9巡回区が、LinkedInによる公開プロフィールのスクレイピング阻止をめぐる主張を再び退けたと説明されています。ただし、この判例だけで契約、プライバシー、技術的保護の回避に関する論点が解消されるわけではなく、Zillowの利用規約が無関係になるわけでもありません。

実務上は、次の点を確認してください。

  • 公開ページへのアクセスであっても、CFAA以外の契約、プライバシー、知的財産などの論点が残る
  • Zillowの利用規約には自動アクセスに関する禁止事項がある
  • CAPTCHAなどの技術的障壁を回避すると、追加の法的リスクが生じる可能性がある
  • 商用利用や大量取得を予定する場合は、対象地域の専門家に相談する
  • レート制限に配慮し、サーバーへ過度な負荷をかけず、取得した個人データを迷惑営業などに利用しない

本節は一般的な情報であり、個別案件に対する法的助言ではありません。

Zillowワークフローに適したツールを選ぶ

2026年時点で確認できるZillowスクレイパーのGitHubリポジトリには、更新が停止しているものや、プロキシと継続的な調整を前提とするものが含まれます。比較的新しいリポジトリの一部、特にpyzillは候補になりますが、実際のページで出力を確認し、プロキシやボット対策の保守工数を見積もる必要があります。

選択時は、オープンソースかクローズドソースかだけでなく、必要なカスタマイズ範囲と、運用・保守をどこまで自社で担うかを確認します。

  • コード、取得ロジック、出力処理を細かく制御したい場合は、GitHubリポジトリが候補になります。プロキシ管理、セレクター更新、ヘルス監視に必要な時間も見込んでください。
  • 開発環境を構築せず、まず検索結果を表形式で取得したい場合は、ThunderbitのZillowテンプレートを試す方法があります。ページ構造の読み取りをAIが支援するため、固定セレクターの保守を減らせる可能性がありますが、対象ページと必要な項目で取得結果を確認する必要があります。

どちらの方法でも、導入前に少量のデータで動作、欠損、出力形式、継続運用のコストを確認することが重要です。GitHubリポジトリを使う場合は、READMEだけでなく、最終コミット日、未解決Issue、実際の出力も確認してください。

ノーコードの流れを確認する場合は、Thunderbitの無料プランを試してみてください。まず少数の物件で抽出精度と出力先を確認し、要件に合う場合に対象範囲を広げると判断しやすくなります。操作手順はThunderbitのYouTubeチャンネルでも確認できます。

ZillowスクレイピングでThunderbitを試す Get Started Free

FAQ

2026年にGitHubで動くZillowスクレイパーはありますか?

いくつかのリポジトリは部分的に動作しています。特に johnbalvin/pyzill は今もデータを返しますが、ローテーションする住宅用プロキシと継続的な調整が必要です。スター数の多い大半のリポジトリ(170スターのChrisMuir/Zillow、152スターのscrapehero/zillow_real_estateを含む)は、Zillowのボット対策変更とDOM更新のせいで壊れています。現在の状態は上の監査表を確認してください。

ZillowはGitHub製スクレイパーを検知してブロックできますか?

Zillowへの自動アクセスがブロックされる可能性はあります。報告されている要素には、IPアドレス、TLSフィンガープリンティング、JavaScriptチャレンジ、CAPTCHA、アクセス頻度などがあります。2026年4月の検証では、Chrome風のヘッダーを付けた通常のHTTPリクエストでもCloudFrontから403が返りました。また、コミュニティには約100リクエスト後にブロックされた事例がありますが、これは固定の閾値ではありません。結果はアクセス方法、ページ、リクエスト数、ネットワーク環境によって異なります。

Zillowからはどんなデータをスクレイプできますか?

一般的な項目は、価格、住所、ベッド数、バスルーム数、平方フィート数、Zestimate、掲載ステータス、掲載日数、掲載URL、エージェント連絡先です。詳細ページのスクレイピングを使えば、価格履歴、税情報、土地面積、HOA費用、学校評価も取得できます。正確な項目は、スクレイパーの機能と、検索結果を対象にしているのか個別物件ページを対象にしているのかで変わります。

Zillowのスクレイピングは合法ですか?

一律には判断できません。公開データへのアクセスについては、hiQ v. LinkedInの系列判例がCFAA上の重要な参考になりますが、Zillowの利用規約には自動アクセスに関する禁止事項があります。CAPTCHAやレート制限などの技術的保護を回避すると、追加の法的論点が生じる可能性があります。個人利用か商用利用か、取得量、対象データ、利用目的、地域によって検討事項が異なるため、用途だけでリスクを断定することはできません。商用利用や大量取得を予定する場合は、対象地域の専門家に相談してください。いずれの場合も、最新の規約を確認し、サーバー負荷、個人情報、著作権に配慮する必要があります。

ThunderbitはZillowのページ変更にどう対応しますか?

Thunderbitは、実行時にAIでページ構造を読み取り、抽出する列の候補を提示します。固定CSSセレクターやXPathだけに依存する構成と比べ、Zillowのフロントエンド変更後に必要となる手作業を減らせる可能性があります。また、Zillow向けには事前構築済みのZillowインスタントスクレイパーテンプレートも用意されています。クラウドスクレイピングでは、プロキシやブラウザレンダリングに関する設定をサービス側で扱うため、利用者が自前で基盤を構築する作業を減らせます。

ただし、レイアウト変更後も常に同じ結果が得られることを保証するものではありません。対象ページ、アクセス状況、表示項目によっては欠損やエラーが発生する可能性があるため、まず少量の物件で抽出結果を確認し、必要な列と出力形式が維持されているかを定期的に点検してください。

さらに詳しく

Ke
Ke
Thunderbit の CTO | シニアデータサイエンティスト & ML エキスパート 機械学習とデータサイエンスで約10年の経験を持つ Ke Shen は、コロンビア大学の卒業生であり、Walmart Labs の元シニアデータサイエンティストです。Python、R、Java、統計学における深い専門性は同業者からも高く評価されており、理論段階の複雑な AI アルゴリズムを本番運用レベルのアーキテクチャへと落とし込むための、実践に裏打ちされた知見を共有しています。
目次
Thunderbit · AI web data agent

Extract data from any page in 1 click

Trusted by 250,000+ users
free plan available
AIでデータを抽出
Google Sheets、Airtable、Notionへ簡単にデータを移行できます
Chrome Store Rating
PRODUCT HUNT#1 Product of the Week