不動産仲介の物件情報処理を自動化｜提案速度3倍の想定モデル事例

レインズ・SUUMOのデータ統合と物件提案AIで、提案準備45分→15分をめざす構成を想定モデル事例として解説。数値は試算で、特定企業の実績ではありません。

結論：本記事では「不動産仲介の物件情報処理を自動化」について、Claude Codeを活用した実践的な実装手順・プロンプト例・注意点を体系的に解説します。

対象読者：不動産仲介業務の自動化に興味がある中堅エンジニア・営業マネージャー・IT担当者。

読了後にできること：物件情報の収集・統合・提案書作成までのパイプラインを、Claude Codeで段階的に構築するための具体的なアクションプランを立てられます。

本記事の位置づけ：本記事は公開情報と一般的な不動産仲介の業務フローをもとに構成した想定モデル事例です。登場する会社（A社）・体制・数値はいずれも試算であり、特定企業の実績ではありません。実際の効果は物件数・人員体制・既存システム・データ提供元の規約によって大きく変わります。導入を検討する際は、自社データで前提を置き直したうえで試算し直してください。

物件情報の収集と提案資料作成に追われる毎日。レインズで物件を探し、SUUMOで競合物件を確認し、Excelに転記して提案書を作る——この一連の作業に1物件あたり平均45分かかっている中堅仲介会社を想定し、Claude Codeによる自動化で物件提案速度を3倍まで引き上げる道筋を組み立てる。本記事では、年間取扱件数800件規模の不動産仲介会社を想定モデルとして置き、業務改革の全体像を試算値・実装コード・プロンプト例とともに示す。数値はいずれも試算であり、特定企業の実績ではない。

想定モデルの前提：1日の半分が「物件情報の処理」に消える

業務時間の55%を占めると置いた内訳

本記事の想定モデルでは、東京・神奈川を中心に売買仲介を手がける従業員25名規模の仲介会社を「A社」と置く。営業担当者1人あたり週20件以上の物件提案を行っているが、業務時間のおよそ半分が物件情報の収集・整理・資料化に費やされ、顧客対応や内見同行に充てる時間が圧迫されている——という前提だ。A社は特定の実在企業ではなく、以降に出てくる数値もこの前提から置いた試算値である。

工程ごとに時間を置いてみる。レインズから物件をピックアップして条件をExcelに転記する作業に1物件15分、SUUMO・アットホーム・HOME’Sでの競合価格チェックに10分、PDF提案書の作成に20分。この前提だと1日10件の提案を出すだけで7時間半が消える計算になる。「提案を増やすほど雑務が増える」という構造で月間の提案件数が頭打ちになる、というのがこの想定モデルの出発点だ。

提案遅延による機会損失を試算すると年間1.5億円規模

さらに効いてくるのが、この作業負荷による機会損失だ。新着物件がレインズに掲載されてから顧客への提案までに平均2.3日かかると置く。人気エリアの物件は数日で買付が入ることも多く、「良い物件なのに提案が間に合わない」という機会逸失が月12件発生すると仮定する。年間にして約144件、平均成約単価3,500万円・仲介手数料率3%で計算すると年間約1.5億円分の手数料収入機会という試算になる。前提の置き方で大きく振れる数字なので、自社の成約単価・提案リードタイムで置き直してほしい。

Claude Codeへの最初の問いかけ：業務フロー分析

想定モデルでは、営業マネージャーがこの課題を次のようにClaude Codeへ投げかけるところから始める。

以下の業務フローを分析し、自動化による時間短縮の可能性が大きい箇所を優先度順にリストアップしてください。

業務フロー:
1. レインズで新着物件を条件検索（所要: 10分/回、1日3回）
2. 条件に合う物件をExcelに転記（所要: 15分/物件）
3. SUUMO/アットホームで同一物件の掲載状況を確認（所要: 10分/物件）
4. 競合価格・成約事例を調査（所要: 5分/物件）
5. 顧客条件とのマッチング判断（所要: 5分/物件）
6. 提案書PDFの作成（所要: 20分/物件）

制約条件:
- レインズのデータは外部APIに送信不可
- 社内ネットワーク内で完結する必要がある
- エンジニアは社内IT担当1名のみ

Claude Codeで構築した「物件情報処理パイプライン」の全体像

3つの中核モジュール構成

この想定モデルでは、Claude Codeを使って物件情報の収集から提案書作成までを一気通貫で処理するパイプラインを組む。中核となるのは以下の3つのモジュールだ。

レインズ・SUUMOデータ統合モジュール：物件IDをキーに各サイトのデータを自動マッチング
物件提案AIモジュール：顧客の希望条件と物件特性をスコアリングして優先順位付け
提案書生成モジュール：マッチング結果をテンプレートに流し込んでPDF化

開発体制とコストの試算：内製なら120万円規模

開発期間は約6週間と置く。エンジニアではない営業マネージャーがClaude Codeに指示を出しながら、社内のIT担当1名と連携して実装する体制だ。外部委託せず内製で完結させた場合、初期投資は約120万円という試算になる。内訳はClaude Code利用料（月額約8万円×3か月＝24万円）、IT担当者の工数（約6週間×50%稼働）、テスト用データ整備の外注費（約30万円）。利用プラン・人件費単価によって変わるため、金額はあくまで置き方の例として読んでほしい。

毎朝12分で完了する自動処理フロー

パイプラインの処理フローは以下の通りだ。毎朝8時にスケジューラが起動し、レインズの新着物件を取得→データ正規化→SUUMO等との照合→顧客条件とのマッチング→スコア上位物件の提案書自動生成、という一連の処理を回す。取扱件数がこの規模なら十数分程度で回りきる設計にできる。営業担当者が出社する9時には、その日の提案候補がSlackに通知されている状態を目指す。

Claude Codeでパイプラインの骨格を設計する際に使用したプロンプト例を示す。

Pythonで不動産物件情報処理パイプラインのクラス設計を行ってください。

要件:
- DataIngester: レインズCSVとSUUMOスクレイピング結果を取り込む
- DataNormalizer: 住所・価格・面積の表記を統一する
- PropertyMatcher: 異なるソース間で同一物件を照合する
- ScoringEngine: 顧客条件に対するスコアリングを行う
- ProposalGenerator: 提案書PDFを生成する

各クラスはパイプラインとして直列に接続可能で、
中間結果はJSON形式でローカルストレージに保存すること。
エラー発生時は該当物件をスキップし、処理を継続すること。

レインズとSUUMOのデータ統合：表記揺れを吸収する仕組み

住所・価格・面積の表記揺れパターン

不動産業界の永遠の課題が、データソース間の表記揺れだ。レインズでは「東京都港区六本木1-2-3」と記載される物件が、SUUMOでは「港区六本木1丁目2-3」となっていることが日常茶飯事。価格表記も「3,980万円」「3980万円」「39,800,000円」とバラバラだ。

正規化ロジックで狙う精度と、その限界

この構成では、Claude Codeに住所の正規化ロジック、価格・面積・駅徒歩分数の単位統一処理、そして物件名の類似度判定（編集距離とトークン一致率の組み合わせ）を書かせる。後述するプロンプトでは表記揺れの吸収精度98%以上を目標値として指定しており、ここに到達できれば同一物件の重複検出ミスは月数件レベルまで下げられる、という置き方をしている。実際の到達精度はデータの汚れ方に強く依存するので、自社データでの実測が前提になる。

さらに、レインズ専用情報（成約事例・取引履歴）とSUUMOの公開情報（写真・周辺施設・口コミ）を1物件のプロファイルに統合することで、営業担当者が1画面で全情報を俯瞰できる構成にする。

住所正規化の効果を試算してみる。手動で表記揺れを目視確認していると照合作業に1物件あたり平均3分かかるが、自動化すればスクリプトの実行時間は1秒未満に収まる。月間800件の物件を処理する前提なら、この工程だけで月40時間ぶんの削減、という計算になる。

Claude Codeで住所正規化ロジックを生成する際のプロンプト例を示す。

不動産物件の住所正規化関数をPythonで実装してください。

処理要件:
1. 都道府県の補完（「港区」→「東京都港区」、都道府県マスタ参照）
2. 丁目表記の統一（「1丁目」「1-」「一丁目」→すべて数字ハイフン形式）
3. 番地表記の統一（「2番3号」「2-3」→ハイフン区切り）
4. 全角数字→半角数字変換
5. マンション名の正規化（スペース除去、カタカナ統一）

テストケース:
- "港区六本木1丁目2-3" → "東京都港区六本木1-2-3"
- "東京都港区六本木１−２−３" → "東京都港区六本木1-2-3"
- "世田谷区三軒茶屋二丁目11番1号" → "東京都世田谷区三軒茶屋2-11-1"

精度目標: 98%以上の正規化成功率
エッジケース: 京都の通り名住所は別途処理フラグを立てること

同一住所・複数物件の誤統合を防ぐ複合条件

⚠️ 要注意：住所正規化で最も失敗しやすいのは「同一住所に複数物件が存在するケース」だ。大規模マンションでは同一住所に棟違いの物件が存在するため、住所だけでマッチングすると誤統合が発生する。この想定モデルでは住所一致＋面積差10%以内＋価格差20%以内の複合条件を設定し、条件外のものは手動確認キューに回す運用にしている。

物件提案AIによるマッチング精度の向上

5軸スコアリングの重み設計

顧客の希望条件を入力すると、AIが約2,000件の在庫物件から最適な10件を抽出するロジックを構築した。単純な条件一致だけでなく、以下の要素を重み付けしてスコアリングしている。

評価軸	重み	具体例
立地適合度	30%	勤務地までの所要時間、希望沿線との一致
価格適合度	25%	予算範囲、ローン審査通過見込み
間取り・広さ	20%	家族構成との適合、収納量
築年数・設備	15%	耐震基準、リフォーム履歴
周辺環境	10%	学区、買い物利便性、治安

試算では、初回提案物件の内見実施率を42%から71%程度まで引き上げることを目標に置いている。条件一致だけの機械的な絞り込みから、顧客属性に合わせた重み付けに変えることで、初回提案の納得感を上げるという狙いだ。到達水準は顧客層と在庫の質で変わる。

成約データによる重みの自動調整

スコアリングエンジンの精度を上げるうえで効きそうなのが、過去の成約データによる重みの自動調整だ。想定モデルでは過去3年分の成約データ（約2,400件）をもとに、顧客属性ごとにどの評価軸が成約に寄与するかを分析する。たとえば子育て世帯では「周辺環境」の重みを10%→22%に、単身の投資目的では「価格適合度」を25%→35%に振り直す、といった調整が考えられる。振り幅は自社データで検証したうえで決める前提だ。

Claude Codeでスコアリングロジックを実装する際のプロンプト例を示す。

不動産物件のスコアリングエンジンをPythonで実装してください。

入力:
- customer_profile: 顧客の希望条件（辞書型）
  - budget_min, budget_max: 予算範囲（万円）
  - station: 最寄り駅の希望（リスト）
  - commute_to: 勤務地住所
  - commute_max_min: 通勤時間上限（分）
  - family_size: 家族人数
  - must_have: 必須条件リスト
- property: 物件情報（辞書型）

出力:
- total_score: 0-100のスコア
- breakdown: 各評価軸のスコア内訳
- recommendation_reason: 提案理由（自然言語、3文以内）

要件:
- must_have条件を1つでも満たさない場合はスコア0を返す
- 重み付けは顧客属性（投資/実需、家族構成）で動的に変更
- スコア計算の根拠を追跡可能にすること（説明可能AI）

スコアしきい値による提案件数の最適化

運用ルールの例としては、スコア80以上の物件を自動提案、60-79を「参考物件」として提示、59以下は非表示、という置き方が扱いやすい。このしきい値なら顧客に提示する物件数は平均5-8件に絞られ、「選択肢が多すぎて迷う」という課題を避けやすくなる。

提案速度3倍を試算で分解する

提案準備時間67%削減の試算内訳

ここまでの前提を数字に落とすと、1物件あたりの提案準備時間は45分から15分になる。営業担当者1人あたりの月間提案件数は平均80件から240件という計算だ。これが本記事で言う「提案速度3倍」の中身であり、実測値ではなく前提から導いた試算値である。

1物件あたりの提案準備時間：45分 → 15分（67%削減）
月間提案件数（1人あたり）：80件 → 240件（3倍）
初回提案からの成約率：8.2% → 12.6%（1.5倍）
営業担当の残業時間：月平均48時間 → 22時間（54%削減）
年間売上：前年比137%相当（成約件数増加と平均成約単価向上を合算した試算）

この設計で狙いたいのは、提案件数が3倍になっても「雑な提案」が増えない状態だ。事前スコアリングで筋の悪い物件を自動的に除外できれば、提案1件あたりの質を落とさずに件数を伸ばせる。逆に言えば、スコアリングの質が伴わないまま件数だけ増やすと成約率が落ちる。

ROI試算：投資回収期間1.2か月という置き方

ROI（投資対効果）を試算する。初期投資120万円＋月間ランニングコスト約15万円（Claude Code利用料＋サーバー費用）に対し、削減できる人件費を月約180万円（営業担当10名×月26時間削減×時給換算）と置くと、投資回収期間は約1.2か月という計算になる。成約件数の増加による手数料収入増をさらに年間約4,800万円と見込む置き方もできるが、これは成約率の伸びをそのまま採用した強気の前提だ。稟議に出すときは人件費削減分だけで回収できるかを先に確認したい。

効果測定ダッシュボードの構築

効果測定のためにClaude Codeで作成したダッシュボード用のデータ集計スクリプトの生成プロンプトを示す。

不動産仲介の営業KPIダッシュボード用データ集計スクリプトをPythonで作成してください。

集計項目:
1. 日別・週別・月別の提案件数（担当者別）
2. 提案→内見→成約のファネル転換率
3. 1物件あたりの処理時間（工程別内訳）
4. AIスコアと実際の成約有無の相関
5. 新着物件掲載から初回提案までのリードタイム

データソース: PostgreSQL（テーブル定義は別途提供）
出力形式: JSON（Grafanaで可視化する前提）
集計期間: 直近12か月のローリング集計

導入時に想定される3つの壁と対処の考え方

壁1：ベテラン営業の「勘と経験」との衝突

「AIのスコアリングなんて信用できない」というベテラン社員の反発は、この種の導入でまず起きる。想定モデルでは、これに対して3か月間のA/Bテストを組み、AI提案組と従来手法組の成約率を比較して、データで判断できる状態を作る。

設計としては、営業担当10名を5名ずつに分け、成約率とファネル転換率を並べて比較する。前掲の試算どおりに成約率が12.6%と8.8%で分かれるなら、3か月間の累計で成約件数に数十件の差が出る計算になり、社内合意の材料になる。ここで重要なのは、AIを「ベテランの勘を否定するもの」ではなく「ベテランの勘をデータで裏付けるもの」として位置づけることだ。ベテラン社員の暗黙知（例：「この学区は2年後に統廃合がある」）をスコアリングの補正条件として組み込めば、両者の知見を重ねられる。

壁2：レインズの利用規約とデータ取り扱い

レインズは加盟業者専用システムであり、データの取り扱いや外部送信には規約上の制約がある。想定モデルでは、Claude Codeを社内ネットワーク内で動作させ、物件の実データを外部APIに送らないアーキテクチャを前提に置いている。ただし、この構成が規約に適合するかどうかは各社の契約内容と運用実態で判断が変わる。実装前に必ず自社の法務部門と加盟窓口へ確認してほしい。本記事はその判断を代替するものではない。

アーキテクチャの要点は以下の通りだ。Claude Codeはローカル環境で動作し、物件データの処理ロジック（正規化・スコアリング）はすべてローカルのPythonスクリプトとして生成・実行される。Claude Codeに渡すのは「コード生成の指示」とスキーマ・ダミーデータに限り、実データはローカルのPostgreSQLに格納して外部に出さない。切り分けのポイントは「ロジックを外部に相談してよいか」と「実データを外部に出してよいか」を分けて考えることで、後者は原則としてローカルに閉じる設計にする。

壁3：パイプラインの保守運用

各サイトの仕様変更でスクリプトが動かなくなるリスクは、この種のパイプラインで最も現実的な運用課題だ。想定モデルでは週1回の動作確認ジョブを自動化し、異常検知時にSlack通知する体制を前提に置く。検知の仕組みさえあれば、掲載サイト側のHTML構造が変わっても数日以内に追随できる。

具体的な監視体制としては、毎日6時に実行されるヘルスチェックジョブが各モジュールの正常動作を確認する。取得件数が前日比50%以下に落ちた場合、マッチング精度が95%を下回った場合、処理時間が通常の3倍を超えた場合にアラートを出す。掲載サイトの構造変更で「取得件数0件」のアラートが出たら、変更後のHTMLをClaude Codeに渡してセレクタ定義を書き直させる——という復旧手順を用意しておけば、半日程度の作業で戻せる想定だ。次のようなプロンプトがそのまま使える。

SUUMOの物件一覧ページのHTML構造が変更されました。
以下が新しいHTML構造のサンプルです。

[新しいHTMLサンプルを貼り付け]

既存のスクレイピングスクリプト（property_scraper.py）を
新しい構造に対応するよう修正してください。

修正要件:
- 物件名、価格、住所、面積、間取り、築年数を正しく取得できること
- 既存のデータ形式（PropertyDataクラス）との互換性を維持すること
- テストケースも合わせて更新すること

最終確認日：2026年5月19日