HubSpotで物件情報を管理する方法｜カスタムオブジェクト設計の実務

「HubSpotを入れたいけれど、物件情報はどこに持てばいいのか分からない」

「取引の項目に物件名を書いているが、同じ物件が何十件も別々に登録されている」

——不動産業でCRMを検討すると、必ずこの壁に当たります。

先に結論をお伝えします。HubSpotには「物件」という標準の入れ物はありません。取引のプロパティーとして持つ／カスタムオブジェクトとして持つ／基幹システムを正として参照するの3パターンから、設計して選ぶことになります。いきなりカスタムオブジェクトを作るのが正解とは限りません。

この記事では、次の4点を実装レベルで整理します。

HubSpotで物件マスターの持ち方を決めかねている方、すでに取引の項目で物件を管理していて限界を感じている方におすすめの内容です。

• 3つの設計パターンの選び分け ── 物件数と「1物件あたりの商談件数」で判断できます
• カスタムオブジェクトの設計手順 ── オブジェクト定義・プロパティー・関連付け・一意識別子の4ステップです
• プロパティー型の選び方と失敗例 ── 価格を文字列にした瞬間に、集計もフィルターも効かなくなります
• できないことと回避策 ── 運用に乗るところまで見ます

読み終える頃には、自社がどのパターンを選ぶべきか、選んだ場合に何をどう設計すればよいかが具体的に見えるはずです。ぜひ最後までご確認ください。

HubSpotに「物件」という標準機能はない。だから設計が要る

HubSpotは不動産専用のシステムではありません。標準で用意されているのは、コンタクト（人）・会社（法人）・取引（商談）・チケット（問い合わせ）といった汎用のオブジェクトです。物件・区画・部屋といった不動産固有の実体は存在しません。

裏を返すと、ここを自社で設計できるかどうかが、そのままCRMの成否になります。「自社に最適な形で設計する」ことが、不動産業ほど露骨に効く業種はありません。

標準オブジェクトだけでも、最初はうまくいく

物件数が数十件までなら、取引に「物件名」「所在地」「価格」を持たせるだけで成立します。問題が出るのは、同じ物件に複数の商談がぶら下がり始めてからです。

「物件」を取引に詰め込むと何が起きるか

症状は3つ出ます。第一に、同じ物件の情報が商談の数だけ複製されます。価格改定のたびに10件の取引を手で直すことになります。第二に、表記ゆれで集計が壊れます。「〇〇マンション」「○○マンション 301」が別物として数えられます。第三に、物件単位のレポートが作れません。「反響が多いのに成約していない物件」を出そうとしても、正しい数字になりません。

要するに、Excelでやっていた「物件マスターと商談シートの二重管理」を、そのままHubSpotに持ち込んだ状態です。乗せ替えたのに手間が減りません。

物件情報を持つ3つの設計パターンと選び分け

では、どう持つのか。実務では次の3パターンに整理できます。

パターンA：取引のプロパティーとして持つ

物件情報を取引の項目として直接持つ方式です。追加のオブジェクトを作らないため、どのプランでも実現できます。物件が数十件で、商談がほぼ1件ずつなら、これで十分です。

パターンB：カスタムオブジェクトとして持つ

「物件」という独立したオブジェクトを作り、取引・コンタクト・会社と関連付ける方式です。物件は1レコードだけ存在し、そこに複数の商談がぶら下がります。価格改定は1箇所を直せば済み、物件単位のレポートも作れます。

ただし、カスタムオブジェクトはEnterpriseプラン以上の機能です。公式ヘルプでは、Marketing Hub Enterprise／Sales Hub Enterprise／Service Hub Enterprise／Data Hub Enterprise／Content Hub Enterprise／Smart CRM Enterprise／Revenue Hub Enterprise の7つが対象と明記されています（出典: HubSpotナレッジベース 2026年8月1日確認）。ここが最初の分岐点です。

パターンC：基幹システムを正として参照する

物件マスターは基幹システムや流通サービス側に置いたまま、HubSpotには物件番号・物件名・ステータスだけを同期する方式です。二重入力を避けられる代わりに、HubSpot側では細かい分析ができません。

選び分けの基準

判断軸は、物件数・1物件にぶら下がる商談件数・更新の担い手の3つです。

「物件数が数十件なら、無理にカスタムオブジェクトを作らない」というのは、はっきり申し上げたい判断です。オブジェクトを1つ増やすと、レコード画面・ビュー・レポート・権限のすべてが保守対象に加わります。この考え方はカスタムオブジェクトを使うべきかの判断基準でも整理しています。

パターンB（カスタムオブジェクト）を選ぶ場合の設計手順

カスタムオブジェクトで進めると決めた場合、次の4ステップで設計します。順番を飛ばすと、後から直せない箇所が出ます。

手順1：オブジェクト定義を決める

最初に決めるのは、オブジェクトの名称と主表示プロパティーです。主表示プロパティーはレコードの名前として使われる項目で、一覧画面や検索でこの値が表示されます。

物件であれば、「物件名」ではなく「物件コード＋物件名」のような重複しにくい値を主表示にするのが実務的です。公式ヘルプでは、主表示プロパティーについて「一意の値を必須にするチェックボックスを選択できる。これを有効にすると、複数のレコードで同じ値を入力できなくなる」と説明されています（出典: HubSpotナレッジベース 2026年8月1日確認）。

手順2：プロパティーを設計する

次に、物件に持たせる項目を決めます。重要なのは項目名よりも型（フィールドタイプ）です。型は後から自由に変えられません。

「とりあえず全部入れておく」は避けてください。使われない項目が多いSFAは、現場の入力精度をむしろ下げます。考え方はプロパティー設計のベストプラクティスにまとめています。

手順3：関連付けを設計する

カスタムオブジェクトは、作っただけでは他のオブジェクトとつながりません。設定画面で関連付けを定義する必要があります。公式ヘルプでも「コンタクト・会社・取引・チケットなどのオブジェクトとの関連付けを設定できる」と記載されています（同上、2026年8月1日確認）。

不動産で最低限つないでおきたいのは3方向です。物件 ↔ 取引（どの商談がどの物件か）、物件 ↔ 会社（売主・管理会社・元付業者）、物件 ↔ コンタクト（オーナー・内見した見込み客）。ここを決めずに進めると、後からデータを入れ直すことになります。

手順4：一意識別子を決める

最も忘れられがちなのが一意識別子です。これを決めていないと、重複を止める手段がありません。

既定の一意識別子は、HubSpotが自動採番するレコードIDです。加えて独自の一意プロパティーも作れ、公式ヘルプには「各オブジェクトについて、一意の値を必須とするカスタムプロパティーを最大10個まで作成できる」と明記されています（出典: HubSpotナレッジベース 2026年8月1日確認）。

物件であれば、自社の物件コードや流通側の管理番号を一意プロパティーにします。これがあると、インポート時に「同じコードなら更新、なければ新規作成」という挙動になり、月次で取り込んでも重複が増えません。決めずに始めると、半年後には同じ物件が3レコード並びます。

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

HubSpotのデモ環境で組んだ場合の最小構成です。実際の項目は物件種別で変わりますので、出発点としてご覧ください。

型の選び方でよくある3つの失敗

ここが、この記事で最もお伝えしたい部分です。カスタムオブジェクトは「作れます」で終わる話ではなく、型を間違えると運用が止まります。

失敗1：価格を1行テキストにする。 「5,980万円」と入れると、集計も範囲検索もできません。価格帯での絞り込みも、平均価格のレポートも作れなくなります。価格・面積・戸数は必ず数値型にし、単位は1つに統一します。

失敗2：ステータスを自由記述にする。 「募集中」「募集中！」「空室あり」が混在した時点で、フィルターもワークフローの分岐も効きません。状態を表す項目は必ずドロップダウンにします。

失敗3：築年数を数値で持つ。 築年数は毎年変わるため、全レコードを毎年更新することになります。持つべきは築年月（日付）で、築年数は計算プロパティーで導出します。更新作業そのものが不要になります。

型は後から自由には変えられない

公式ヘルプには「既存のプロパティーのフィールドタイプを変更すると、プロパティーに保存されている現在の値が無効になることがあります」、また［スコア］や［計算］との相互変更はできない旨が記載されています（出典: HubSpotナレッジベース 2026年8月1日確認）。数千件を入れた後で「価格を数値に変えたい」となれば、値の一括変換と再インポートが必要です。最初の設計に数十分かける価値は十分にあります。

区画・部屋を子オブジェクトに分けるべきかの判断基準

もう1つ必ず論点になるのが、物件の下の階層です。一棟のマンションに部屋が30室ある、といったケースですね。

この図は不動産CRMのデータ設計でも使っている全体像で、物件の下に区画・部屋を置き、取引をその区画・部屋に紐づける構成です。

分けるべきケースと、分けないほうがよいケース

判断は「取引が何に対して発生するか」で決まります。契約の単位が部屋・区画なら分ける、棟や土地の丸ごとなら分けない、というのが原則です。

分けると解像度は上がりますが、レコード数は一気に増えます（100棟×30室で3,000レコード）。まずは物件オブジェクトだけで運用し、部屋単位の分析が必要になった時点で追加する形で問題ありません。

物件データをどう入れるか

設計ができたら、次はデータの入り口です。ここを詰めないまま公開すると、「箱はあるが中身が入っていない」状態になります。

初期移行はインポートで行う

既存のExcelや基幹システムからCSVで書き出し、インポート機能で取り込みます。このとき、手順4で決めた一意プロパティー（物件コード）を必ず列に含めてください。含めておけば、2回目以降の取り込みが「更新」として扱われます。

移行前のチェックは3点です。物件コードの重複、価格・面積の列に混ざった単位や記号、ステータス表記と選択肢の不一致。3点目は1文字違うだけでエラーになります。

日々の更新は「どれを使わないか」を決める

更新経路は主に次の4つです。入口が多すぎると、どこが最新か分からなくなります。

基幹システムとの同期は「正の向き」を先に決める

すでに物件管理システムをお使いの場合、まず決めるべきはどちらを正とするかです。両方向で更新できるようにすると、ほぼ確実に上書き事故が起きます。

実務的には「物件マスターは基幹システムが正、HubSpotは読み取り専用」から始めるのが安全です。HubSpot側で編集させたい項目（担当者コメント、反響メモなど）は、基幹側にない独自プロパティーとして持たせます。同期処理をHubSpot側で組む場合はカスタムコードワークフローが選択肢になります。

カスタムオブジェクトで「できないこと」と回避策

正直にお伝えすると、カスタムオブジェクトは標準オブジェクトと完全に同等ではありません。導入前に知っておきたい制約を挙げます。

フォーム連携は一段かませるのが確実です

公式ヘルプには「主表示プロパティーに一意の値が入力されたフォームが送信されると、カスタムオブジェクトのレコードが自動的に作成される」という記載があります（出典: HubSpotナレッジベース 2026年8月1日確認）。ただし、フォームの各項目を物件オブジェクトの任意のプロパティーへ自由にマッピングする方法は公式に明示されていません。実務ではコンタクト側で受け、ワークフローで転記する構成が確実です。

運用に乗せるための最後の一手

設計とデータ投入が終わっても、それだけでは現場は使ってくれません。最後に画面まわりを整えます。ここを省くと「作ったけど誰も見ていないオブジェクト」になります。

レコード画面を整える

物件レコードを開いたとき、必要な情報が一画面で見える状態にします。左サイドバーに基本情報、中央に販売ステータスと関連する取引、右に会社・コンタクト、という配置が扱いやすいです。作ったプロパティーは必ずどこかに表示させると決めておくのがおすすめです。

ビューで日常の切り口を用意する

一覧画面のビューは、カスタムオブジェクトでも標準オブジェクトと同じように作れます。「募集中の物件」「申込ありで契約待ち」「3ヶ月以上動いていない物件」といった切り口をあらかじめ保存しておきます。

レポートで「物件を軸にした数字」を出す

カスタムオブジェクトにした最大のメリットが、ここで効いてきます。物件を軸に反響数・内見数・成約率を並べたレポートが作れ、「反響は多いのに成約に至らない物件」が特定できれば、価格の見直しや掲載写真の差し替えといった打ち手につながります。

前提として、追客の進捗が取引側のパイプラインで正しく管理できている必要があります。組み方は不動産の追客パイプライン設計で扱っています。

よくある質問

物件をカスタムオブジェクトで持つ設計について、ご相談の場でよくいただく質問をまとめます。

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

Enterpriseプランが必要です（対象プランは本文2章のとおりです）。Professional以下では、取引のプロパティーで持つパターンAから始めることになります。

Q2. 作れるカスタムオブジェクトの数やプロパティー数に上限はありますか？

上限はありますが、具体的な数値は契約内容によって異なります。公式ヘルプは「契約内容によっては、使用できるカスタムオブジェクトとプロパティーの数に上限があります」として、HubSpot製品・サービスカタログを参照するよう案内しています（2026年8月1日確認）。

Q3. あとから「やっぱりカスタムオブジェクトにしたい」と変更できますか？

できます。取引のプロパティーの物件情報を書き出し、物件オブジェクトにインポートして取引と関連付ける手順です。ただし表記ゆれの名寄せが必要で、手間は物件数に比例します。将来オブジェクト化する見込みがあるなら、パターンAの段階から物件コードのプロパティーだけは作って入力しておくと、移行が格段に楽になります。

Q4. 一意識別子は必ず設定すべきですか？

物件のように「同じものを二度登録してはいけない」データでは、強くおすすめします。既定の識別子はHubSpotの自動採番レコードIDで、自社の物件コードとは無関係の値です。インポートのたびに新規レコードが増えるのを防ぐには、自社側のコードを一意プロパティーにする必要があります。

Q5. 物件が数十件でも、最初からカスタムオブジェクトにしたほうがきれいではないですか？

きれいではありますが、おすすめはしません。オブジェクトを1つ増やすと、プロパティー・関連付け・レコード画面・ビュー・レポート・権限の保守がすべて増えます。物件数が数十件で商談がほぼ1件なら、パターンAで得られる結果はほぼ同じです。同じ物件に複数の商談が同時にぶら下がるようになったらが、切り替えを検討する合図になります。

まとめ

HubSpotで物件情報を管理するときの要点を整理します。

• HubSpotに「物件」の標準機能はありません。 取引のプロパティー／カスタムオブジェクト／基幹システム参照の3パターンから設計して選びます
• 選び分けの軸は物件数と、1物件あたりの商談件数です。 数十件で商談が1件ずつなら、作らない判断が正解になることも多くあります
• 設計はオブジェクト定義→プロパティー→関連付け→一意識別子の順です。 特に一意識別子がないと、重複を止める手段がありません
• プロパティーは型が命です。 価格を文字列にすると集計できず、ステータスを自由記述にするとフィルターが効きません。しかも型は後から自由に変えられません
• 画面・ビュー・レポートまで作って、初めて運用に乗ります。 プロパティーが画面に出ていないオブジェクトは、誰にも使われません

最初の一歩は、いまお使いのExcel台帳を開いて、列の型を仕分けしてみることです。数値で持つべき列、選択式にすべき列、日付から計算できる列を分けるだけで、設計図はほぼ出来上がります。

不動産業でのHubSpot活用の全体像は不動産業界のHubSpot活用法でも解説しています。自社の物件データにどう当てはめるかを検討したい場合は、StartLinkの無料相談でご相談ください。現状の台帳と業務フローをうかがったうえで、設計の方向性をご提案します。