不動産CRMのデータ設計｜物件・顧客・取引をどう持つか

「CRM導入は決まったけれど、物件情報をどこに持てばいいのか分からない」「どの顧客にどの物件を提案したかを追えるイメージが湧かない」——不動産会社でCRM導入を任された方から、こうしたご相談をいただくことが少なくありません。

不動産CRMの設計とは、突き詰めると「物件・顧客・取引という3つの情報を、どのオブジェクトに、どの粒度で持ち、どう関連付けるか」を決める作業です。ツールの機能比較よりも先にこのデータ構造を決めることが、結構ミソになってきます。ここが曖昧なまま導入すると、入力はされているのに集計ができないという、一番もったいない状態になりがちです。

この記事では、HubSpotを例に不動産CRMのデータモデルの組み立て方を解説します。「カスタムオブジェクトを使いましょう」で終わらせず、使わない方がいいケースまで正直にお伝えします。

不動産会社でCRMの導入担当になった方、いま使っている顧客管理をHubSpotに寄せたい方に向けた内容です。次の4点がわかります。

• 物件をどこに持つかで後工程が決まる ── プロパティー・取引・カスタムオブジェクトのどれに持たせるかで、レポートで見えるものが変わります
• 標準オブジェクトで足りる会社と足りない会社の境目 ── 扱う物件数と提案の重なり方で判断できます
• 賃貸・売買・投資用でデータモデルは変わる ── 契約の継続性とオーナーの位置づけが違うためです
• 後から直すコストは想像より高い ── プロパティーの型変更や関連付けの張り替えには制約があります

読み終える頃には、自社の物件・顧客・取引をどのオブジェクトに、どの粒度で持てばよいかの判断軸が固まるはずです。ぜひ最後までご確認ください。

不動産CRMで最初に決めるべきは「物件をどこに持つか」

不動産のCRM導入で最初にぶつかるのが、物件情報の置き場所です。顧客管理だけなら一般的なCRMの設計論がそのまま使えますが、不動産では「顧客」と同じくらい「物件」が主役になります。ここが他業種との決定的な違いです。

物件は「顧客の属性」ではなく独立したレコード

多くの会社が最初にやってしまうのが、物件情報を顧客（コンタクト）のプロパティーとして持たせる方法です。入力が早く導入初日から動きますが、同じ物件を複数の顧客に紹介した瞬間に破綻します。「物件Aは今何人に紹介中で、そのうち何人が内見済みか」を出そうとしても、文字列の部分一致で数えるしかなくなるためです。

物件は本来、顧客とは独立して存在し、時間とともに状態が変わる（募集中→申込あり→契約済み→退去）オブジェクトです。顧客の属性ではなく、それ自体がレコードであるという前提に立つと、設計の選択肢がはっきりします。

「1顧客に何件の物件が紐づくか」が判断の起点

物件の持ち方を決める最短の質問は、「1人の顧客に対して、いくつの物件が関わりますか」です。

絶対的な基準ではありませんが、「提案が重なるかどうか」を最初に確認しておくと以降の議論が具体的になります。まずは紙でもスプレッドシートでもよいので、物件・顧客・取引の関係図を1枚書いてみることをおすすめします。業界全体の進め方は不動産業界のHubSpot活用法でも整理しています。

標準オブジェクトだけで組む場合の限界

HubSpotの標準オブジェクトは、コンタクト（個人）・会社（法人）・取引（商談）・チケット（問い合わせ対応）が中心です。これらは相互に関連付けができるリレーショナルな構造で、多くの業種はこの4つで足ります。不動産でどこまで表現できるのかを正直に整理します。

標準オブジェクトで表現できること

反響から契約までの営業プロセスは、標準オブジェクトだけでもかなりの部分が組めます。ポータルサイトからの反響をコンタクトで受け、追客状況を取引のステージで管理し、入居後の問い合わせをチケットで扱う形です。つまり「顧客をどう追いかけるか」だけであれば十分に戦えます。問題は「物件をどう見るか」を求めた瞬間に出てきます。

物件をプロパティーや取引に持たせたときに起きること

物件名をテキストプロパティーとして持つと、3つのことが同時に起きます。1つ目は表記揺れで、「グランドメゾン〇〇 101号室」「グランドメゾン〇〇101」のように入力者ごとに書き方が変わり、システム側では同一物件だと判定できません。

2つ目は物件側からの逆引きができないことです。「この物件に今どれだけ引き合いがあるか」を見たくても、開く画面そのものがありません。3つ目は状態管理ができないことです。募集中か契約済みかは物件の属性ですが、顧客側に持たせている限り顧客レコードの数だけ複製され、更新漏れによる不整合が起きます。

次によくあるのが、取引レコードを物件単位で作る方法です。集計しやすく金額も自然に乗るため、1顧客1物件の業態なら十分に機能します。ただし同じ物件を複数の顧客に提案する業態では、面積・築年・賃料といった情報が取引の数だけ重複し、賃料改定のたびに関係する取引をすべて手で直すことになります。

カスタムオブジェクトは標準オブジェクトと同じように扱える

カスタムオブジェクトというと特殊なものに聞こえますが、作ってしまえば標準オブジェクトとほぼ同じ感覚で使えます。一覧ビューでフィルターをかけ、プロパティーで絞り込み、レポートの集計対象にもできます。

それでも標準オブジェクトだけで足りるケース

ここは正直にお伝えしたい部分です。カスタムオブジェクトは万能ではなく、使わない方がいい場面が確かにあります。

第一に、扱う物件が少ない場合です。常時抱えている物件が数十件程度で、1顧客1物件で提案が重ならないなら取引のプロパティーで十分です。オブジェクトを増やすと入力と関連付けの手間も増え、かえって現場の負担になります。

第二に、専用の物件管理システムが既に稼働している場合です。物件マスターがそちらにあるなら、CRM側は参照キー（物件番号）だけを持ち、詳細は基幹側で見る割り切りが有効です。二重管理は必ずどちらかが腐ります。

第三に、プランの制約です。HubSpotのカスタムオブジェクトは、Marketing Hub / Sales Hub / Service Hub / Data Hub / Content Hub の各Enterprise、および Smart CRM Enterprise・Revenue Hub Enterprise で利用できる機能とされています（出典: HubSpotナレッジベース「カスタムオブジェクトを作成する」 2026年8月1日確認）。判断軸はカスタムオブジェクトを使うべきかでも整理しています。

物件・区画をカスタムオブジェクトで持つデータモデル

ここからは、物件をカスタムオブジェクトとして独立させる場合の具体的な設計に入ります。まず全体像を図で示します。

これはHubSpotのデモ環境で再現した設計例です。特定の企業の実装ではなく、不動産業でよく出てくる要素を一般化したものとしてご覧ください。

物件オブジェクトに持たせるプロパティー

物件オブジェクトのプロパティーは、「検索・絞り込みに使うもの」と「レポートで集計するもの」に絞るのが基本です。物件情報は際限なく増やせてしまうため、最初から全項目を持とうとすると入力されずに終わります。

最低限持たせたいのは、物件名・物件番号（一意キー）・所在地（都道府県／市区町村を別プロパティーに分ける）・種別・築年月・総戸数・ステータス（募集中／申込あり／契約済み／募集停止）あたりです。所在地を1つの文字列にせず分割しておくと、エリア別のレポートが作れます。

逆に、設備の細目や図面の寸法は、持たせても検索にも集計にも使われないことが多いものです。項目は少ないほうが現場は入力に集中できます。絞り込み方はプロパティー設計のベストプラクティスで詳しく扱っています。

区画（部屋）や契約を別オブジェクトに分けるかどうか

分譲マンションや賃貸マンションでは、「棟」と「部屋」の2階層が必要になります。部屋単位で募集・契約・退去が発生し、部屋ごとに賃料や間取りが違うのであれば、物件（棟）と区画（部屋）を分けるほうが自然です。棟の情報を1回だけ持ち、部屋ごとの情報（号室・間取り・賃料・現況）を区画側に持たせます。戸建や土地が中心で1物件＝1販売単位なら区画オブジェクトは不要です。

賃貸管理をやっている場合は、契約（賃貸借契約）を独立させるかも論点になります。契約は開始日・終了日・更新日・賃料といった固有の属性を持ち、同じ部屋に対して時系列で複数存在するためです。更新・退去業務を回したいなら持つ価値がありますが、仲介だけなら不要です。詳しくは物件をカスタムオブジェクトで管理するで解説しています。

関連付けとラベルの設計

データモデルの本体は、実はプロパティーではなく関連付けです。誰とどの物件が、どういう関係でつながっているのかを表現する部分になります。

HubSpotでは、異なるオブジェクト間だけでなく同じオブジェクト同士も関連付けができ、「ラベル」で関係性の種類を区別できます。関連付けラベルの利用にはProfessionalまたはEnterpriseのサブスクリプションが必要とされています（出典: HubSpotナレッジベース「レコードを関連付ける」 2026年8月1日確認）。また製品・サービスカタログでは、オブジェクトのペアごとに最大50個のラベルを設定できるとされています（出典: HubSpot Product & Services Catalog 2026年8月1日確認）。

不動産で使い分けたいラベルの例は、コンタクトと物件の間なら「問い合わせ」「内見済み」「申込」「入居中」、会社と物件の間なら「オーナー」「管理会社」「元付」「客付」です。ラベルを設計しておくと、「内見済みだが申込に至っていない人」を物件側から一覧できるようになります。

賃貸／売買／投資用でデータモデルはどう変わるか

「不動産CRM」とひとくくりにされがちですが、賃貸仲介・管理と売買仲介と投資用販売では、必要なデータモデルがかなり違います。同じ設計を使い回そうとすると、どこかで無理が出ます。

3類型の比較

賃貸は「継続関係」をどう持つかが焦点

賃貸で難しいのは、契約が終わりではなく始まりだという点です。入居後も更新・修繕依頼・退去といったイベントが続きます。入居中の問い合わせをチケットで受け、更新は契約オブジェクトの期限から自動でタスク化する設計が現実的です。

また、入居希望者とオーナーという性質のまったく違う2種類の顧客を、同じコンタクト／会社オブジェクトに混在させることになります。ライフサイクルステージやラベルで明確に区別しておかないと、入居希望者向けの案内がオーナーに飛ぶといった事故が起きます。

売買と投資用で気をつけたいこと

売買では1件あたりの金額が大きく、検討期間も長くなります。在庫として大量に抱える業態は多くないため、カスタムオブジェクトを作らず取引のプロパティーで持つ判断も十分にあり得ます。無理に増やさず、スモールスタートで様子を見るのがおすすめです。

投資用でやっかいなのは、同じ人物が買主にも売主にもなり得ることです。コンタクトを「買主」「売主」と固定的に分類すると、この転換を表現できません。役割は関連付けラベルや取引側の属性で表し、コンタクト自体は「1人1レコード」に保つのが基本です。

取引（Deal）を「1顧客1本」にするか「1提案1本」にするかの判断

データモデルの中で、実務上いちばん揉めるのがここです。取引レコードを顧客ごとに1本立てるのか、提案した物件ごとに立てるのか。どちらにも一長一短があります。

1顧客1本（追客ベース）の考え方

1人の顧客に対して取引を1本だけ作り、そこで追客全体を管理する方法です。レコード数が増えず、反響件数と取引件数が一致するため歩留まりレポートが素直に作れます。追客が中心で提案物件が入れ替わっていく賃貸仲介では扱いやすい形になります。

欠点は、「どの物件で成約したか」がぼやけることです。提案物件を関連付けで持つことはできますが、金額やクローズ日は1本しか持てないため、物件ごとの成約率は取引レポートだけでは出せません。

1提案1本（物件ベース）の考え方

提案した物件ごとに取引を立てる方法です。物件単位の金額・確度・クローズ日が正確に持てるため、フォーキャストの精度が上がります。売買や投資用のように1件あたりが重く、並行提案が発生する業態に向いています。

欠点は、レコードが増えることと失注の扱いが複雑になることです。5物件提案して1件成約すれば残り4件は失注になります。これを「顧客としての失注」と混同すると失注率が実態より高く見えるため、失注理由に「他物件で成約」という区分が必須になります。

判断の基準

折衷案：申込以降だけを取引にする

実務でよく落ち着くのが両者の中間です。反響から内見までの追客はコンタクト側のステージで管理し、申込が入った時点で初めて取引を作る設計にします。取引が「ほぼ確度のある案件」だけになり、パイプラインの数字が読みやすくなります。

不動産に合わせたステージの切り方は不動産の追客パイプライン設計で具体的に扱っています。

オーナー・管理会社を会社オブジェクトでどう表現するか

物件と顧客の設計ができたら、次はその周りにいる関係者です。不動産では、オーナー・管理会社・元付業者・金融機関・施工会社など、登場人物が多くなります。

個人オーナーをコンタクトに持つか会社に持つか

会社オブジェクトは法人を想定した項目構成のため、個人名を会社レコードとして登録するのは違和感があります。推奨は、個人オーナーはコンタクトとして持ち、オーナーであることは物件との関連付けラベルで表現する方法です。

法人オーナーの場合は会社レコードを作り、その担当者をコンタクトとして紐づけます。こうすると、個人でも法人でも「物件から所有者をたどる」という動線が統一されます。

役割はプロパティーではなくラベルで持つ

会社オブジェクトに「区分」というプロパティーを作り、「オーナー」「管理会社」「仲介会社」から選ばせる設計もよく見かけます。ただ、同じ会社がある物件ではオーナー、別の物件では管理会社というケースが普通に発生します。

役割は会社そのものの属性ではなく、会社と物件の関係の属性です。ですから関連付けラベルで持つほうが正確に表現できます。プロパティーで持つと1社1役割に固定され、後から表現しきれなくなります。なお金融機関や司法書士まで会社オブジェクトに入れるかは業務の必要性次第で、そうでなければ取引のプロパティーで足ります。

データ設計を間違えたときに起きること

設計をやり直すことになった現場では、だいたい同じ症状が出ています。3つに整理します。

重複レコードが増える

物件を文字列で持っていると、表記揺れのぶんだけ実質的な重複が発生します。コンタクト側でも、同じ人が反響のたびに新規レコードとして登録されるケースがあります。

重複が増えると、メールが二重に届く、担当が別々に付くといった、顧客に見える形の事故につながります。CRM上の数字も実態より大きく見えるため、経営判断の材料としても使えなくなります。

集計ができない

いちばん多いのがこれです。入力自体はされているのに、見たい数字が出せません。「エリア別の反響数」を出したいのに所在地を1つのテキストで持っていた、「物件種別ごとの成約率」を見たいのに種別が自由入力だった、という具合です。テキストプロパティーは集計軸に使いづらいため、レポートで軸にしたい項目は必ず選択肢（ドロップダウン）で持つというのが鉄則になります。

現場が入力しなくなる

入力項目が多すぎる、同じ情報を2か所に入れさせられる、入れても何も返ってこない。この3つが揃うと現場は入力をやめます。入力が止まったCRMは、データが中途半端に入っているぶんExcel時代より状況が悪くなります。入力してもらう項目は、それが誰のどのレポートに効くのかを説明できるものだけに絞るのが結局は近道です。

後から直すコストは想像より高い

「とりあえず作って後で直せばいい」と考えたくなりますが、直すコストは決して小さくありません。主な制約を整理します。

やり直しが不可能なわけではありません。ただ、レコードが数千件を超えたあたりから「直すより我慢する」という判断になりがちです。だからこそ、最初に決めるべきものだけは時間をかけて決める価値があります。

設計を進める順序

最後に、どの順番で決めていくかを整理します。順序を間違えると手戻りが発生するため、ここは型に沿って進めることをおすすめします。

全体の流れ

レポート要件から逆算する

大事なのは、ステップ0を最初に置くことです。「毎月の営業会議で何を見るのか」を先に決めておくと、必要なプロパティーと不要なプロパティーの線引きが一気に明確になります。逆に項目から考え始めると必ず増えます。「あったほうがいいかもしれない」で作られた項目は、ほぼ使われません。

一度に全部やらず、入力の入口も同時に決める

不動産のデータモデルは、突き詰めるといくらでも複雑にできます。物件・区画・契約・オーナー・管理受託・修繕履歴と広げていくと、初期構築だけで数か月かかります。現実的には、まず反響〜成約までの1本の線を通してから、管理業務や周辺の関係者を足していく進め方が続きます。

同じくらい重要なのが「そのレコードは誰がどこで作るのか」です。物件はポータルサイトからの取り込みなのか手入力なのか、反響はフォーム経由なのかメール転送なのか。ここが決まっていないと、きれいな設計図があっても中身が入りません。反響を担当者に振り分ける部分まで含めて考えると初動の速さが変わります。振り分けの自動化はリードの傾斜配布を自動化するで解説しています。

よくある質問

不動産CRMのデータ設計について、ご相談の場でよくいただく質問をまとめました。

Q1. 物件をカスタムオブジェクトにしないと、不動産でCRMは使えませんか。

そんなことはありません。扱う物件数が少なく、1顧客あたりの提案が重ならない業態であれば、取引のプロパティーに物件情報を持たせる形で十分に運用できます。オブジェクトを増やすと入力と関連付けの手間も増えるため、必要性が明確になってから足すほうが定着します。判断の起点は「同じ物件を複数の顧客に同時提案するか」「物件側から引き合いを見たいか」の2点です。

Q2. 既に物件管理システムを使っています。CRMにも物件を入れるべきですか。

二重管理になるため、原則としておすすめしません。物件マスターは既存システムに置いたまま、CRM側は物件番号などの参照キーだけを持つ設計が現実的です。ただし反響数を物件別に見たい場合は、必要最小限の項目（物件番号・物件名・エリア・種別・ステータス）だけを連携する判断もあります。どちらを正とするかを先に決めることが重要です。

Q3. 個人オーナーは会社オブジェクトとコンタクトのどちらに入れるべきですか。

コンタクトとして持ち、物件との関連付けにラベルを付けて「オーナー」であることを表現する方法をおすすめします。会社オブジェクトは法人を前提とした項目構成のためです。同じ会社が物件によってオーナーだったり管理会社だったりするため、役割はプロパティーではなく関連付けラベルで持つのが結構ポイントになってきます。

Q4. カスタムオブジェクトはどのプランで使えますか。

HubSpotのナレッジベースでは、Marketing Hub / Sales Hub / Service Hub / Data Hub / Content Hub の各Enterprise、および Smart CRM Enterprise・Revenue Hub Enterprise で利用できると案内されています（出典 2026年8月1日確認）。同ページには契約内容による上限がある旨も記載されていますが、具体的な数値は明示されておらず、製品・サービスカタログの確認が必要とされています。契約前にHubSpotまたはパートナーへ確認することをおすすめします。

Q5. 設計をやり直したくなったら、どのくらい大変ですか。

内容によります。プロパティーを1つ足すだけなら数分ですが、テキスト項目を選択肢型に変える、物件をオブジェクトに移す、取引の粒度を変えるといった変更は、既存レコード全件の再処理が必要になります。特にプロパティーのフィールドタイプ変更には制約があり、スコア・計算タイプへの変更やそこからの変更はできません。集計軸に使う項目の型だけは最初に決めておくことをおすすめします。

まとめ

不動産CRMの設計は、機能比較ではなくデータ構造から始めるのが結構ミソになってきます。要点を整理します。

• 最初に決めるのは「物件をどこに持つか」。プロパティーか、取引か、カスタムオブジェクトか。この選択で後から見えるレポートが変わります
• 標準オブジェクトだけで足りる会社もあります。扱う物件が少ない、提案が重ならない、基幹システムが既にある場合は、無理にオブジェクトを増やさないほうが定着します
• 賃貸・売買・投資用でデータモデルは変わります。契約の継続性とオーナーの位置づけが違うため、他社の設計をそのまま持ってきても合いません
• 取引の粒度は「1顧客1本」か「1提案1本」か。並行提案の有無と1件あたりの重さで決まります。申込以降だけを取引にする折衷案も現実的です
• 後から直すコストは高い。プロパティーの型変更には制約があり、関連付けの張り替えは全レコードの再処理になります

最初の一歩としておすすめしたいのは、「毎月の会議で見たい数字を5つ書き出す」ことです。空室率なのか、エリア別の反響数なのか、物件種別ごとの成約率なのか。その5つが出せるデータ構造になっているかを逆算すると、必要なオブジェクトとプロパティーが自然に決まります。ツールの検討はその後で構いません。

そのうえで、まずは物件・コンタクト・取引の3つで1本の線を通し、動き始めてから区画・契約・オーナー管理を足していく。この段階的な進め方が、結局いちばん現場に残ります。

自社の物件や顧客の持ち方をどう設計するか具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の運用をうかがったうえで、設計の方向性をご提案します。