HubSpotカスタムオブジェクトの設計判断｜標準で足りない時に何をどう作るか

「HubSpotの標準オブジェクト（コンタクト・会社・取引・チケット）だけでは管理しきれないデータがある」「カスタムオブジェクトを作るべきか、標準オブジェクトで工夫して乗り切るべきか判断がつかない」「カスタムオブジェクトを作ったが、複雑になりすぎて運用が回らない」——HubSpotの活用が進むほど、こうしたデータ設計の壁にぶつかる企業は多いです。

カスタムオブジェクトとは、HubSpotの標準オブジェクト（コンタクト・会社・取引・チケット）では表現できないビジネスデータを、独自のオブジェクトとして定義・管理する機能です。ただし、「作れる」ことと「作るべき」ことは別問題です。本記事では、カスタムオブジェクトの「設計判断」にフォーカスし、標準で足りないときに何をどう作るかの判断フレームワークを解説します。

この記事でわかること

• HubSpotカスタムオブジェクトの基本概念と利用条件
• 標準オブジェクトで対応すべきケースの判断基準
• カスタムオブジェクトを作るべきケースの判断基準
• 設計時に考慮すべき5つのチェックポイント
• 業種別のカスタムオブジェクト設計パターン
• よくある設計ミスと回避策

HubSpotカスタムオブジェクトとは？

HubSpotカスタムオブジェクトとは、HubSpotの標準4オブジェクト（コンタクト・会社・取引・チケット）では表現できないビジネスエンティティを、独自に定義して管理するための機能です。Enterprise版で利用可能で、標準オブジェクトと同様にプロパティの設定、関連付け、ワークフロー、レポート作成が可能です。

Salesforceを使ったことがある方であれば、Salesforceのカスタムオブジェクトとほぼ同等の概念とお考えいただければと思います。HubSpotの場合、Enterpriseプランでの提供となるため、プラン選定の際に重要な判断ポイントになります。

なぜカスタムオブジェクトの「設計判断」が重要なのか

作りすぎのリスク

カスタムオブジェクトは強力な機能ですが、安易に作りすぎると以下のリスクが生じます。

第一に、データモデルの複雑化です。オブジェクト間の関連付けが増えるほど、レポート作成やワークフロー設計が複雑になり、運用担当者の負担が増大します。

第二に、運用コストの増加です。カスタムオブジェクトごとにプロパティ設計、ビュー設計、権限設計、レポート設計が必要になります。作ったものの入力されない「幽霊オブジェクト」が増えると、データ品質が低下します。

第三に、プラン変更リスクです。カスタムオブジェクトはEnterprise限定機能のため、コスト削減でProfessionalにダウングレードすると、カスタムオブジェクトのデータにアクセスできなくなります。

作らなすぎのリスク

一方で、標準オブジェクトに無理やりデータを詰め込むのも問題です。例えば、不動産会社が「物件情報」をコンタクトのカスタムプロパティで管理しようとすると、1人のコンタクトに対して複数の物件を紐づけることができず、データモデルが破綻します。

つまり、「作るべきか・作らないべきか」の判断基準を持つことが、CRM設計の品質を大きく左右するのです。

設計判断フレームワーク：3つの質問

カスタムオブジェクトの作成を検討する際に、以下の3つの質問で判断します。

質問1：「1対多」の関係が必要か？

標準オブジェクトのプロパティは、1つのレコードに対して1つの値しか持てません。例えば、1つの取引に対して「複数の請求レコード」を紐づけたい場合や、1つの会社に対して「複数の物件」を紐づけたい場合は、カスタムオブジェクトが必要です。

判断基準：

• 1対1の関係 → カスタムプロパティで対応可能
• 1対多の関係 → カスタムオブジェクトが必要

質問2：独自のパイプライン（ステージ管理）が必要か？

取引パイプラインとは別の、独自のステータス管理が必要なデータがある場合は、カスタムオブジェクトが適しています。例えば、請求管理で「請求予定→請求書発行→入金済み→未入金」というステータス管理をしたい場合、取引パイプラインとは別のパイプラインが必要です。

判断基準：

• 既存の取引/チケットのパイプラインで管理可能 → 標準オブジェクトで対応
• 独自のステータス遷移が必要 → カスタムオブジェクトが適切

質問3：レポートで独立した集計軸が必要か？

「物件ごとの収益」「プロジェクトごとの工数」「商品ごとの出荷状況」など、標準オブジェクトとは異なる集計軸でレポートを作成する必要がある場合、カスタムオブジェクトが有効です。

判断基準：

• 既存オブジェクトのプロパティとしてフィルタ/グルーピングすれば十分 → 標準で対応
• 独立したエンティティとして集計したい → カスタムオブジェクトが適切

判断フローチャート

以上の3つの質問を組み合わせた判断フローは以下のとおりです。

標準オブジェクトで対応すべきケース

カスタムオブジェクトを作る前に、以下の方法で標準オブジェクトの活用を最大化できないか検討してください。

方法1：カスタムプロパティの活用

取引オブジェクトにカスタムプロパティ（契約形態、月額金額、契約期間など）を追加するだけで対応できるケースは多いです。プロパティのグループ機能を使って整理すれば、項目が増えても管理しやすくなります。

方法2：複数パイプラインの活用

HubSpotでは1つの取引オブジェクトで複数のパイプラインを持てます。例えば、「新規営業パイプライン」「既存顧客アップセルパイプライン」「パートナー商流パイプライン」を別パイプラインとして管理すれば、カスタムオブジェクトなしでも多様な商流を管理できます。

方法3：チケットオブジェクトの流用

「プロジェクト管理」「検収プロセス」「資料請求の処理」など、社内業務のステータス管理にはチケットオブジェクトが流用できるケースがあります。チケットは独自のパイプラインを持てるため、カスタムオブジェクトの代替として検討する価値があります。

方法4：関連付けラベルの活用

同一オブジェクト間（例：会社↔会社）で「親会社-子会社」「パートナー-クライアント」といった関係性を表現したい場合、関連付けラベル機能で対応できます。これはProfessionalプランでも利用可能です。

カスタムオブジェクトを作るべきケース：業種別パターン

パターン1：不動産業界の物件管理

不動産会社では、コンタクト（顧客）と物件は多対多の関係です。1人の顧客が複数の物件に興味を持ち、1つの物件に複数の顧客が関心を示します。物件情報を取引のプロパティで管理しようとすると、物件ごとの成約率や空室率の分析ができません。

設計：「物件」カスタムオブジェクトを作成し、コンタクト・会社・取引と関連付ける

パターン2：SaaS企業の請求管理

SaaS企業では、1つの契約（取引）に対して月次の請求が複数回発生します。例えば、36ヶ月契約であれば36件の請求レコードが紐づきます。これを取引のプロパティで管理することは不可能です。

設計：「請求」カスタムオブジェクトを作成し、取引と1対多で関連付ける。「請求予定→請求書発行→入金済み→未入金」のパイプラインを設定

取引が「契約」ステージに移行したら、ワークフロー（またはカスタムコード）で12ヶ月分の請求レコードを自動作成するといった運用も可能です。

パターン3：コンサルティング業のプロジェクト管理

受注後のプロジェクトの進捗管理が必要な場合、取引は「受注」で完了しますが、プロジェクトは「キックオフ→設計→実装→検収→完了」と続きます。

設計：「プロジェクト」カスタムオブジェクトを作成し、取引・会社・コンタクトと関連付ける。独自のパイプラインでプロジェクトステータスを管理

パターン4：営業報告の蓄積

日次・週次の営業報告を構造化データとしてCRMに蓄積したい場合、カスタムオブジェクトが有効です。

設計：「営業報告」カスタムオブジェクトを作成。プロパティとして「報告日」「訪問先」「議題」「訪問者」「提案書リンク」「ネクストアクション」を設定し、コンタクト・会社・取引と関連付ける

設計時の5つのチェックポイント

カスタムオブジェクトを作ると決めた場合、以下の5つを設計段階で確認してください。

チェック1：プロパティ設計は最小限から

よくあるSFAのあるあるで、使っていない項目が大量にあるケースがあります。カスタムオブジェクトでも同じリスクがあるため、初期のプロパティは本当に必要な5〜10個に絞り、運用しながら追加するスモールスタートを推奨します。

チェック2：関連付けの方向と多重度を明確にする

どのオブジェクトとどの方向で関連付けるか、1対1なのか1対多なのか多対多なのかを、設計段階で明確にしてください。関連付けの設計を間違えると、レポートで意図したデータが取れなくなります。

チェック3：入力者と閲覧者を分ける権限設計

カスタムオブジェクトに対して「誰が作成・編集できて、誰が閲覧だけできるか」の権限設計を事前に行います。HubSpot Enterpriseでは、カスタムオブジェクトレベルでの権限設定が可能です。

チェック4：レポート要件から逆算する

「このカスタムオブジェクトを使って、どんなレポートを作りたいか」をまず定義し、レポートに必要なプロパティと関連付けを逆算する設計アプローチが効果的です。「とりあえず作って、あとで考える」は避けてください。

チェック5：サンドボックスでテストする

Enterpriseプランにはサンドボックス環境があります。本番環境にいきなり作るのではなく、まずサンドボックスでカスタムオブジェクトを作成し、プロパティ設計・関連付け・レポート作成をテストしてから本番に反映するのが安全です。「新しいプロパティやデータについてはまだレポートも紐づいていないし実際の現場も使っていないので本番環境にテストするぐらいはいいが、既存で使っているデータに影響するものはサンドボックスを使っていただいたほうが安心」という判断基準が参考になります。

注意点・よくある設計ミス

ミス1：標準オブジェクトで対応できるのにカスタムオブジェクトを作る

最も多い設計ミスです。「なんとなくカスタムのほうがちゃんとしてそう」という理由で作ると、不要な複雑性を持ち込むことになります。まず標準オブジェクトの限界を実際に確認し、それでも足りない場合にのみカスタムオブジェクトを検討してください。

ミス2：関連付けを設計せずにカスタムオブジェクトを作る

カスタムオブジェクトを作ったが、既存のオブジェクトとの関連付けを設計しなかったため、孤立したデータサイロになってしまうケースです。カスタムオブジェクトの価値は、他のオブジェクトと関連付けてリレーションデータベースとして機能させることにあります。

ミス3：プロパティを作りすぎる

初期段階で50個のプロパティを作り、結果として入力率が低く、ほとんど使われないプロパティだらけになるケースです。「フィルレートが1%しかないプロパティは、おそらく使っていない」——HubSpotのデータ品質画面でフィルレートを定期的にチェックし、使われていないプロパティは整理する運用を設計してください。

正直な限界

HubSpotのカスタムオブジェクトはEnterprise限定機能であり、Enterpriseプランへのアップグレードが前提になります。また、カスタムオブジェクトの数にはプランごとの上限があります（Enterprise: 10個まで）。Salesforceのカスタムオブジェクトと比較すると、まだ制約が多い部分もありますが、HubSpotは毎年のアップデートで機能拡張を続けており、今後の改善にも期待できるかなと思います。

まとめ

カスタムオブジェクトの設計判断は、以下のステップで進めるのが効果的です。

1. 標準オブジェクトの限界確認：まずカスタムプロパティ・複数パイプライン・チケット流用で対応できないか検討
2. 3つの質問で判断：「1対多が必要か」「独自パイプラインが必要か」「独立した集計軸が必要か」
3. レポート要件から逆算：どんなレポートを作りたいかを先に定義し、必要なプロパティと関連付けを逆算
4. 最小限のプロパティで開始：5〜10個のプロパティからスモールスタート
5. サンドボックスでテスト：本番反映前にサンドボックスで設計を検証

企業様によって最適なデータモデルは異なります。自社の業務プロセスに合わせて、標準オブジェクトで対応すべきか、カスタムオブジェクトを作るべきかを慎重に判断いただければなと思います。「作れるから作る」ではなく、「作るべきだから作る」という設計判断が、長期的なCRM運用の成否を分けます。

カスタムオブジェクトの具体的な設定方法は「HubSpotカスタムオブジェクト実践ガイド｜設計パターン・関連付け・レポート活用を事例で解説」で詳しく解説しています。CRM全体のデータ設計については「CRM運用ルール設計ガイド」もあわせてご覧ください。また、プランの選び方については「HubSpot全プラン徹底比較！料金・機能・シートの選び方まで完全解説」も参考になるかと思います。

よくある質問（FAQ）

Q. カスタムオブジェクトはProfessionalプランでも使えますか？

いいえ。カスタムオブジェクトはHubSpot Enterprise版の限定機能です。Professionalプランでは利用できません。Enterpriseへのアップグレードを検討する最大のトリガーのひとつが、カスタムオブジェクトの必要性です。ただし、標準オブジェクト＋カスタムプロパティ＋複数パイプラインで対応できるケースも多いので、まずProfessionalプランでの限界を確認してからアップグレードを判断するのがおすすめです。

Q. カスタムオブジェクトはいくつまで作れますか？

Enterprise版では最大10個のカスタムオブジェクトを作成できます。ただし、10個すべてを使い切る必要があるケースは稀です。一般的には2〜3個（例：請求・物件・プロジェクト）で十分なケースがほとんどです。

Q. Salesforceのカスタムオブジェクトとの違いは何ですか？

Salesforceのカスタムオブジェクトは数の制限が緩く（Enterprise: 200個）、式フィールドやバリデーションルールなどの細かい制御が可能です。HubSpotのカスタムオブジェクトは数の上限（10個）や機能面での制約がまだありますが、UIの使いやすさとワークフロー・レポートとの連携のシームレスさはHubSpotの強みです。大規模なカスタマイズが必要な場合はSalesforceが有利ですが、中規模以下であればHubSpotで十分対応可能なケースが増えています。

Q. カスタムオブジェクトを作った後に不要になったら削除できますか？

はい、カスタムオブジェクトは削除可能です。ただし、削除するとそのオブジェクトに蓄積されたデータもすべて失われます。削除前にデータのエクスポートを行い、関連するワークフローやレポートへの影響を確認してから実行してください。

Q. カスタムオブジェクトの設計を外部に依頼すべきですか？

データモデルの設計は、CRM運用の長期的な成否を左右する重要な意思決定です。自社でCRM設計の知見がある場合は内製で問題ありませんが、初めてカスタムオブジェクトを導入する場合は、HubSpotパートナーのコンサルタントに設計レビューを依頼することを推奨します。設計の段階でミスがあると、あとから修正するコストが大きくなるためです。