HubSpot 標準の「コンタクト・会社・取引・チケット」では表現できないビジネスデータがある。契約書・プロジェクト・製品・資産・店舗・不動産——こうしたドメイン固有のデータを CRM に持ち込み、既存オブジェクトと関連付けることで、HubSpot を汎用 CRM から「自社のビジネスモデルに特化したシステム」へと進化させるのがカスタムオブジェクトの役割だ。本章ではカスタムオブジェクトの設計原則・プロパティ設計・アソシエーション（関連）設計・API による作成・業種別ユースケース・運用のベストプラクティスを解説する。
HubSpot の標準オブジェクトは「コンタクト・会社・取引・チケット」の4種類だ。これらはほとんどの BtoB ビジネスで使えるが、自社固有のビジネスエンティティ（契約書・プロジェクト・機器・資産など）は表現できない。カスタムオブジェクトはこの制約を取り除く。
| 判断基準 | カスタムオブジェクトを作る | 別の方法で対応する |
|---|---|---|
| データの独立性 | そのエンティティ独自のプロパティが10個以上あり、コンタクトや取引とは明らかに別物 | コンタクトや取引にカスタムプロパティを追加するだけで表現できる |
| 1対多の関係 | 1つの会社に対して複数の「契約書」がある・1つのコンタクトが複数の「プロジェクト」に紐づく | 常に1対1（1社に1契約）なら取引オブジェクトのカスタム化で対応できる場合が多い |
| WF・レポートでの活用 | そのオブジェクトを起点にワークフローを動かしたい・レポートで集計したい | 閲覧するだけなら Notes や添付ファイルで管理する方法もある |
| 外部システムとの同期 | ERP・基幹システムの「契約」「製品」「注文」を HubSpot に同期して活用したい | 外部システムが正であり、HubSpot は参照するだけなら連携だけで十分な場合もある |
カスタムオブジェクトは一度作ってデータが入り始めると、オブジェクト名の変更・プロパティの削除・アソシエーションの変更が難しくなる。本番で使い始める前に必ずサンドボックスで設計を検証し、「5年後もこの構造でいいか」を考えてから作成する。特にオブジェクト名（API 名）は一度設定すると変更できないため、命名規則を事前に決めておく。
カスタムオブジェクトの用途はビジネスモデルによって大きく異なる。以下に代表的な4業種の具体的な設計例を示す。
カスタムオブジェクトのプロパティは、標準オブジェクトと同じプロパティタイプをすべて使える。適切なタイプを選ぶことが、後のレポート・フィルター・自動化の精度に直結する。
HubSpot のアソシエーションにはラベル（役割）を付けられる。例えば Contract ↔ Contact のアソシエーションに「署名者 / 承認者 / 担当者」というラベルを設定することで、単なる「紐づいている」以上の文脈情報を記録できる。ラベルは後から追加できるが、設計時に「このアソシエーションでどんなロールを追跡したいか」を考えておくと後の活用が広がる。
カスタムオブジェクトの日常的な作成・更新は HubSpot の UI からも行えるが、外部システムとの連携・大量データのインポート・ワークフローからの自動作成には HubSpot API を使う。カスタムオブジェクトの API エンドポイントは標準オブジェクトと同じ構造で、スキーマ（オブジェクト定義）だけが異なる。
標準の4オブジェクトで表現できないビジネスエンティティを CRM に追加できる。判断基準は「独自のプロパティが10個以上・1対多の関係がある・WF やレポートで活用したい」の3点。すべてに当てはまらない場合はカスタムプロパティの追加で対応できることが多い。
SaaS は Contracts（複数契約管理）、製造業は Equipment（機器追跡）、不動産は Properties（物件管理）、教育は Enrollments（受講記録）が典型例。自社のビジネスで「スプレッドシートで管理していて CRM から切り離されているデータ」がカスタムオブジェクト化の有力候補。
カスタムオブジェクトの API 名・プロパティ内部名は一度設定すると変更不可。「p_contracts」「p_equipment」のように複数形スネークケースで統一する命名規則をチームで合意してから本番作成する。サンドボックスでの検証は必須。
単に「紐づける」だけでなく「Contract ↔ Contact」のアソシエーションに「署名者 / 承認者 / 担当者」というラベルを付けることで関係の文脈まで記録できる。多対多の関係はアソシエーションで表現し、中間テーブルを自前で作ろうとしない。