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

今すぐ「zillow scraper github」で検索すると、が見つかります。期待が高まりますよね——でも、そのうちが1年以上更新されていないと分かると、見方は変わります。

私はこれらのリポジトリをかなり長い時間かけて調査し、実際のZillowページで動作確認を行い、さらにGitHubのIssueやRedditのスレッドも読み込んで、開発者たちが「今回は何が壊れたのか」をどう嘆いているかまで追いました。パターンは一貫しています。最初に動いたときはスターが一気に増えるのに、ZillowがDOMを変更したり、ボット対策を強化したり、内部APIエンドポイントを廃止したりすると、静かに息を引き取るのです。Redditのある不満を抱えた開発者は、こう言い切っていました。「スクレイピングプロジェクトは、ページやAPIの変更に対応するため、絶えずメンテナンスが必要だ」。この記事は、初めてZillowスクレイパーのGitHubリポジトリをクローンする前に欲しかった監査レポートです。2026年時点で本当に動くもの、壊れるもの、その理由、そしてGitHubの迷路に入らずのようなツールを使ったほうがよい場面を、率直に整理します。

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

「Zillowスクレイパー」とは、Zillowのサイトから物件情報を自動取得するスクリプトやツール全般を指します。対象は価格、住所、ベッド数、バスルーム数、専有面積、Zestimate、掲載ステータス、掲載日数、場合によっては価格履歴や税情報のような詳細ページのデータまで含まれます。人々がGitHubを探すのは、無料で、オープンソースで、しかも自分でカスタマイズできるものが欲しいからです。リポジトリをフォークして項目を調整し、出力を自分のパイプラインに流し込む。理屈の上では、かなり理想的です。

主な利用者はかなりはっきり分かれています。

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

共通点はただ一つ、みんなが欲しいのは一回限りのコピペではなく、構造化され、繰り返し使えるデータだということです。だからこそスクレイピングは魅力的です。そして、リポジトリが動かなくなったときのメンテナンス負担を、容赦なく重く感じさせるのです。

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

GitHubで、スター数とフォーク数が多いZillowスクレイパーのリポジトリを探し、最終コミット日を確認し、公開Issueを読み、実際のZillowページで試しました。判断基準はシンプルです。2026年4月時点で、Zillowの検索結果ページまたは詳細ページから正確な物件データを返せるなら「動作中」。動くものの、データが不完全だったり、数ページ後にブロックされたりするなら「部分的に動作中」。完全に失敗するか、メンテナーが死んだと明言しているなら「破損」です。

厳しい現実として、12〜18か月前には有望に見えたリポジトリの多くが、ひっそり壊れています。

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

見えてきたパターンは明快です。GitHubのエコシステムには今も生きたコードはありますが、目につくリポジトリの多くはチュートリアル、歴史的アーティファクト、またはプロキシ依存のワークフローに薄く被せただけのものです。

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

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

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

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

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

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

1. DOMの再構成（ZillowのReactフロントエンド）

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

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

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

より賢いリポジトリはHTMLを使わず、Zillowの内部GraphQLやREST APIに直接アクセスします。たとえば は、Zillowの内部APIを使い、結果件数の制限を回避するために地図の境界を再帰的に分割します。巧妙な設計ですが、Zillowは定期的にこれらのエンドポイントを再構成します。そうなると、スクレイパーは404か、エラーメッセージのない空のJSONを返すようになります。

これはより気づきにくい壊れ方です。コードは問題ありません。ターゲットが移動しただけです。

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

Zillowはボット検知を段階的に強化してきました。2026年4月の私のテストでは、requests.get() を使って zillow.com と zillow.com/homes/Chicago,-IL_rb/ の両方にアクセスしたところ、が返りました。Chrome風のUser-AgentとAccept-Languageヘッダーを付けてもです。コミュニティの報告も一致しています。あるユーザーは、逆解析したAPIフローが約後に403を返すようになったと述べていました。

低ボリュームでは問題なく動くスクレイパーでも、規模を拡大した途端に失敗することがあります。3つの郵便番号で200件の物件を追跡しようとしているときには、かなり厄介な驚きです。

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

Zestimateの詳細、税情報、一部の価格履歴などは認証の背後に置かれています。オープンソースのスクレイパーはログインフローを扱えないことが多く、これらの項目は空欄のまま返ってきます。価格履歴や固定資産評価額に依存する用途なら、この壁にはすぐにぶつかります。

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

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

2026年のZillowボット対策：本当に何と戦っているのか

「プロキシを使ってヘッダーをローテーションすればいい」は、2022年なら十分な助言でした。2026年では違います。

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

ZillowはIPだけをブロックしているわけではありません。コミュニティの報告によると、ZillowはCloudflareの背後にあり、単純なレート制限を超えたを行っています。TLSフィンガープリンティングは、クライアントの「デジタルな握手」、つまり暗号化の交渉方法によって、ブラウザ以外のクライアントを識別します。新しいプロキシを使っても、TLSの署名が本物のChromeブラウザと一致しなければ、スクレイパーはフラグを立てられる可能性があります。

JavaScriptチャレンジもさらに一枚上です。JSを完全に実行しないヘッドレスブラウザや、navigator.webdriver = true のような自動化の痕跡を露出するものは検知されます。

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

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

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

HTTP専業派：なぜブラウザ自動化を避ける開発者がいるのか

Selenium、Playwright、Puppeteerを使わないHTTP専用のアプローチを明確に望む開発者は少なくありません。理由は実務的です。ブラウザ自動化は遅く、リソースを食い、スケール時のデプロイも難しいからです。

率直に言うと、2026年のZillowに対しては、高度なヘッダー管理とフィンガープリント管理がなければ、純粋なHTTPアプローチはますます難しくなっています。コミュニティの証拠を見る限り、Zillowのようなターゲットでは、ブラウザレンダリングが例外ではなく標準になりつつあります。

Zillow向けの具体的なボット回避ベストプラクティス

自作で進めるなら、実際に役立つものとそうでないものは次の通りです。

• 人間の閲覧に近いランダムなリクエスト間隔を使うこと。固定遅延ではなく、セッション風の振る舞いを伴う可変間隔にする
• 現実的なヘッダー設定を使うこと。Accept-Language、Sec-CH-UA 系のヘッダー、適切なrefererの連鎖を含める。ただし、現実的なヘッダーは必要条件であって十分条件ではない
• セッションのローテーションを行うこと。同じプロキシ/クッキーの組み合わせを何百回も使い回さない
• ブラウザレンダリングに切り替えるべきタイミングを見極めること。HTTP専用で50リクエスト後に403が返るなら、勝ち目の薄い戦いをしています

2026年のZillowを、魔法のヘッダーひとつで突破できると示唆する記事は信じないでください。

なら、このあたりをすべて自動で処理します。米国/欧州/アジアにまたがるローテーション基盤、レンダリング、ボット対策まで管理されるので、ユーザーはプロキシ設定の迷路に入らずに済みます。重要なのは、運用負担がどこに乗るかです。

ZillowスクレイパーのGitHub環境を将来に備えて強くするベストプラクティス

GitHub/自作ルートを選ぶ読者向けに、数か月持つスクレイパーと、数日で壊れるスクレイパーを分ける実践策を紹介します。

壊れやすいクラス名への依存をやめる

リポジトリがZillowの自動生成CSSクラス名に依存しているなら、赤信号だと思ってください。そうした名前は頻繁に、時には毎週のように変わります。代わりに次のようにします。

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

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

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

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

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

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

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

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

そのが絶対ではありませんが、テストでは問題なかったスクレイパーでも、量によって挙動が変わるという現実的な注意喚起です。リクエストはセッションごとに分散し、ランダムな遅延を入れましょう。一度の実行で1万件を刈り取ろうとしないことです。

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

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

ZillowスクレイパーのGitHub（DIY） vs ノーコードツール：率直な比較

「zillow scraper github」を探す人は、きれいに2つに分かれます。コードの所有権が欲しい開発者と、表計算ソフトにデータが入れば十分な不動産担当者です。どちらも正当です。実際のトレードオフを見てみましょう。

横並び比較表

プロキシ費用の現実

「無料リポジトリ」という主張は、プロキシ費用を加味すると一気に説得力が下がります。住宅用プロキシの現在の公開価格は以下の通りです。

リポジトリ自体は無料でも、プロキシを使うZillowワークフローは、たいてい無料ではありません。

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

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

Thunderbitを選ぶべきケース

• 今日はとにかく確実にデータが欲しい。セットアップや保守は不要
• 自分は開発者ではなく、不動産エージェント、投資家、またはオペレーション担当だ
• が、出力コードは書きたくない
• 追加設定なしでサブページスクレイピング（詳細ページデータによる情報拡張）を使いたい
• 予定スクレイピングを、平易な言葉で指定したい

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

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

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

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

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

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

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

Thunderbitにはがあります。設定は不要で、ワンクリックするだけです。テンプレートは、住所、価格、ベッド数、バスルーム数、平方フィート数、担当エージェント名、担当エージェントの電話番号、掲載URLなど、標準的な項目をカバーしています。

別の方法として、「AIで項目を提案」をクリックすると、AIがページを読み取り、列を提案します。私の経験では、Zestimateを含むを検出することが多いです。

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

「スクレイプ」をクリックします。Thunderbitがページネーション、ボット対策、データ構造化を自動で処理します。結果は構造化された表で取得でき、403エラーも空欄もプロキシ設定もありません。

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

「サブページをスクレイプ」をクリックすると、Thunderbitが各物件の詳細ページにアクセスし、価格履歴、税情報、土地面積、学校評価などの追加項目を取得します。GitHub構成なら、これは独立したセレクター処理とボット対策を伴う、かなり複雑な2回目のスクレイピングになります。ここではワンクリックです。

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

Excel、Google Sheets、Airtable、Notionに無料でエクスポートできます。必要ならCSVやJSONとしてダウンロードも可能です。書き出しコードを書く必要はありません。

これは、たいてい環境構築から始まり、403のトラブルシューティングで終わるGitHubの導入体験とは、実質的に別物です。

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

多くのガイドは「はい、CSVです」で終わります。それは、釣り竿を渡しておきながら、魚の調理法を説明せずに立ち去るようなものです。

スクレイピングは第1段階にすぎません。その先があります。

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件の物件を追う投資家

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

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

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

簡潔ですが、必須の話です。

は、スクリーンスクレイピング、クローラー、スパイダー、CAPTCHA類の保護回避を含む自動問い合わせを明確に禁止しています。 も、/api/、/homes/、クエリ状態付きURLを含む広い範囲を拒否しています。

一方で、米国のWebスクレイピング法は「スクレイピングはすべて違法」と単純化できるものではありません。CFAAに関するhiQ v. LinkedInの系列判例は、公開データのスクレイピングにとって重要です。Haynes Booneのによると、第9巡回区は、LinkedInが公開メンバーのプロフィールのスクレイピングを阻止しようとした試みを再び退けました。しかし、それで契約、プライバシー、回避禁止に関する別の論点が消えるわけではなく、Zillowの利用規約が無関係になるわけでもありません。

要するに、次のようになります。

• 公開ページのスクレイピングは、多くのサイト運営者が主張するよりCFAA上の主張が強い可能性がある
• ただしZillowは契約上、明確に禁止している
• 技術的障壁を回避すると、法的リスクはさらに上がる
• 商用利用や大量利用なら、法的助言を受けるべき
• 法環境に関係なく、責任あるスクレイピングを心がけること。レート制限を守り、サーバーに負荷をかけず、個人データをスパムに使わない

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

2026年のZillowスクレイパー GitHub 界隈は、見た目よりずっと薄いです。目につくリポジトリの大半は古く、壊れやすく、あるいは壊れています。新しめのリポジトリの一部、特にはまだ動きますが、継続的なプロキシとボット対策のメンテナンスが必要です。

本当の選択肢は、オープンソースかクローズドソースかではありません。制御したいのか、運用負担を持ちたいのかです。

• 完全な制御が欲しく、スクレイパーの保守自体を楽しめるなら、GitHubリポジトリは強力です。ただし、プロキシ管理、セレクター更新、ヘルス監視の時間を見込んでください。
• 今日はとにかく確実なデータが欲しく、保守はゼロにしたいなら、を使えば、数分で検索結果からスプレッドシートまで到達できます。AIが毎回ページ構造を新しく読み取るので、壊れやすい固定セレクターに依存しません。

どちらの道にも正当性があります。

最悪なのは、GitHubスクレイパーのセットアップに何時間も費やしたあと、実は先月から壊れていて、誰もREADMEを更新していなかったと気づくことです。

ノーコードの流れを実際に見たいなら、。Zillowの物件を約2クリックでスクレイプして、チームがすでに使っているプラットフォームへ出力できます。先に手順を見たいですか？ には解説動画があります。

FAQ

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

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

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

はい。ZillowはIPブロック、TLSフィンガープリンティング、JavaScriptチャレンジ、CAPTCHA、レート制限を使っています。テストでは、Chrome風ヘッダーを付けた通常のHTTPリクエストでもCloudFrontから403が返りました。適切な検知回避策、つまり住宅用プロキシ、現実的なヘッダー、ブラウザレンダリングのないGitHubスクレイパーは、しばしば100リクエスト以内でブロックされます。

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

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

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

これは一概には言えません。公開データのスクレイピングは、hiQ v. LinkedInの系列判例以降、法的にはより主張しやすくなっていますが、Zillowの利用規約は自動アクセスを明確に禁止しています。CAPTCHAやレート制限を回避すると、追加の法的リスクが生じます。個人的な調査なら、一般にリスクは低めです。商用または大量利用なら、弁護士に相談してください。いずれにしても、責任ある方法で行ってください。

Thunderbitはどうやって壊れずにZillowをスクレイプするのですか？

ThunderbitはAIを使って、実行のたびにページ構造を新しく読み取ります。Zillowのフロントエンドが更新されたときに壊れる固定CSSセレクターやXPathに依存していません。また、ワンクリック抽出向けに事前構築済みのもあります。クラウドスクレイピングがローテーション基盤でボット対策を自動処理するため、ユーザーが自分でプロキシ設定やブラウザレンダリングを管理する必要はありません。Zillowがレイアウトを変えても、AIが適応します。リポジトリの更新は不要です。

さらに詳しく