【BtoB向け】HubSpotカスタムオブジェクト設計の実践ガイド

カスタムオブジェクトとは何か：標準オブジェクトとの違いを正しく理解する

このセクションでは、HubSpotのカスタムオブジェクトの位置づけを、標準オブジェクトとの対比で整理します。

HubSpotのCRMには、コンタクト（個人）、会社、取引、チケットという4つの標準オブジェクトが用意されています。これらはBtoBの基本的な営業・マーケティング業務をカバーする最小単位として設計されており、多くの企業はこの4つで十分に運用できます。一方で、自社のビジネスに固有の「物」「契約単位」「関係性」を扱いたい場合、標準オブジェクトのプロパティを増やすだけでは表現しきれない場面が出てきます。このときに、独自のオブジェクト型を定義できるのがカスタムオブジェクトです。

カスタムオブジェクトは、独自のレコード一覧を持ち、独自のプロパティを定義でき、コンタクト・会社・取引・チケットや他のカスタムオブジェクトと関連付けることができます。ワークフローのトリガーやアクション、リスト、レポート、APIからの操作対象としても扱えます。つまり、標準オブジェクトと同等のCRM資産として扱える「自社専用のオブジェクト型」を作れる仕組みです。

カスタムオブジェクトと「カスタムプロパティ」の違い

混同されがちですが、カスタムプロパティはあくまで既存オブジェクトに項目を追加する機能で、カスタムオブジェクトはオブジェクトそのものを新設する機能です。たとえば「契約更新日」を会社レコードに持たせるならカスタムプロパティで足りますが、「1社が複数の契約を持ち、契約ごとに開始日・解約日・プランが異なる」状態を扱うには、契約というオブジェクトを別に持つ必要があります。

利用できるプランと前提

カスタムオブジェクトは、Marketing Hub・Sales Hub・Service Hub・Operations HubいずれかのEnterprise以上のプランで利用できます。Professionalプラン以下では作成できないため、設計を検討する前にまず自社の契約プランを確認する必要があります。Enterpriseプランへのアップグレードコストを正当化できるだけの業務上のメリットがあるかを問うことが、設計プロセスの最初のチェックポイントになります。

カスタムオブジェクトを「作るべきか」の判断軸

このセクションでは、カスタムオブジェクトを新設する前に必ず確認すべき判断軸を整理します。

HubSpotコンサルタントとして実務で関わると、「とりあえずカスタムオブジェクトを作っておこう」という発想で設計を進めると、ほぼ確実に後悔することになります。オブジェクトは一度作って運用に乗せると、廃止・統合のコストが大きく、レポートやワークフローの依存関係も増えていくためです。作る前に、以下の判断軸を順に確認することをおすすめします。

判断軸1：標準オブジェクト＋カスタムプロパティで表現できないか

多くのケースは、標準オブジェクトにプロパティを追加することで対応できます。会社レコードに「契約プラン」「契約開始日」「解約予定日」を追加すれば足りる場合、カスタムオブジェクトは不要です。ただし、1社あたり契約を複数持ち、それぞれが独立したライフサイクルを持つ場合は、プロパティでは表現できません。「1対多」の関係になった瞬間に、カスタムオブジェクトの検討が始まります。

判断軸2：そのデータをトリガー／レポートの軸として使うか

単に保存しておきたいだけのデータなら、メモやファイルでも構いません。重要なのは、そのデータをワークフローのトリガー、リストの絞り込み、レポートのディメンションとして使うかどうかです。「契約終了60日前にCSがフォローを開始する」「プラン別の解約率をレポートする」といった運用要件があるなら、構造化されたオブジェクトとして持つ価値があります。

判断軸3：誰がそのレコードを作成・更新するのか

営業が手入力するのか、外部システムからAPI連携で同期するのか、フォームから自動生成するのかによって、設計の難易度が大きく変わります。手入力に依存する設計は、入力漏れと表記揺れでデータが汚れていきます。基幹システムからの同期が前提なら、APIで参照する一意キー（外部IDなど）を最初から設計に組み込む必要があります。

判断軸4：取引オブジェクトとの違いを説明できるか

BtoBで頻繁に起きる混乱が、「カスタムオブジェクトの契約」と「標準オブジェクトの取引」の役割整理です。一般論として、取引は「1回の商談プロセス」を扱うのに適しており、契約は「成立後の継続的な関係」を扱うのに適していますが、企業によってこの境界は異なります。両方を持つ場合、それぞれのライフサイクルとレポート用途を明確に切り分けないと、二重管理になります。

BtoBで採用されやすいカスタムオブジェクトの典型パターン

このセクションでは、BtoB企業で導入を検討されることが多いカスタムオブジェクトの典型的なパターンを紹介します。

以下は、BtoB企業の業態別によく検討されるカスタムオブジェクトの例です。実際にこれらが必要かは個社の業務によるため、一般化された参考例として捉えてください。

SaaS／サブスクリプションビジネス

サブスクリプションオブジェクトを作り、契約プラン・MRR・契約開始日・更新日・解約日を保持する設計が考えられます。1社が複数プロダクトを契約するケースや、プラン変更履歴を残したいケースで有効です。HubSpotには標準で「サブスクリプション」という概念がCommerce Hub内に存在しますが、これと混同しないよう、自社ビジネスでカスタムオブジェクトとして持つべきかは慎重に判断する必要があります。

不動産・物件・資産管理系

物件、車両、機材といった「物」を扱う業態では、これらを独立したオブジェクトとして持つ設計が一般的です。1つの物件に対して複数の問い合わせ（コンタクト）が紐づき、複数の取引が発生するため、標準オブジェクトでは表現が難しい構造になります。

医療・士業・教育機関

医師個人と所属施設、講師と所属法人など、「個人」と「組織」の関係が複雑な業態では、所属関係をカスタムオブジェクトとして持つ設計が検討されます。ただし、HubSpotにはコンタクトと会社の関連付けを補助する機能もあるため、まずは標準機能で表現できないかを確認することが先決です。

代理店・パートナーチャネル

代理店経由の販売を扱う場合、代理店オブジェクトを作り、エンドユーザー会社・代理店・取引の3者の関係を整理する設計が考えられます。代理店ごとの売上・成約率・サポート工数を可視化したい場合に有効です。

イベント・プロジェクト管理

展示会・セミナーごとの参加者管理、または受注後のプロジェクト進捗管理を、独立したオブジェクトとして持つパターンです。展示会についてはHubSpotのキャンペーン機能やマーケティングイベント機能で代替できる場合もあるため、まず標準機能の確認が必要です。

カスタムオブジェクトの設計ステップ

このセクションでは、実際にカスタムオブジェクトを設計する際の具体的なステップを示します。

ステップ1：業務要件の言語化

「何を、どの単位で、誰が管理し、誰が見るのか」を文章で書き出します。ここを曖昧にしたまま設計に入ると、プロパティが過剰になったり、関連付けが破綻したりします。最低限、以下を整理します。

• このオブジェクトが扱う対象（例：契約、物件、プロジェクト）
• 1レコードが表す単位（例：1契約＝1レコード）
• 必須プロパティと任意プロパティ
• 関連付ける標準オブジェクト・他のカスタムオブジェクト
• レコードの作成・更新・削除のルール

ステップ2：プロパティの定義

プロパティは、後から追加することはできても、削除や型変更は運用への影響が大きいため、最初の設計で慎重に決める必要があります。BtoB業務でよく定義されるプロパティの種類を整理します。

• 識別子：レコードを一意に特定する外部キー（基幹システムのID等）
• 状態：ライフサイクルステージや進行ステータス
• 金額：MRR、契約金額など
• 日付：開始日、終了日、更新日
• 関係者：担当者、責任者
• カテゴリ：プラン、種別など選択肢型

すべてのプロパティに「内部名」を付けるルールを最初に決めておくと、後でAPI連携やレポート作成が楽になります。日本語のラベルだけでは、開発・連携時に混乱が発生しやすくなります。

ステップ3：関連付けの設計

HubSpotでは、オブジェクト間の関連付けに「関連付けラベル」を設定でき、1対多／多対多の関係性をラベルで意味付けできます。たとえば1つの契約レコードに対して、コンタクトを「契約者」と「請求先担当者」というラベルで紐づける設計が可能です。関連付けラベルを使わずに「とにかく関連付けるだけ」にすると、後でレポートを切るときに役割が判別できなくなるため、設計時にラベル体系を決めておくことを推奨します。

ステップ4：レコード作成・連携の設計

レコードがどのように作られ、更新されるのかを決めます。手入力、フォーム連携、ワークフローでの自動作成、外部システムからのAPI同期といった選択肢があります。データの正本（マスタ）がHubSpotなのか、基幹システムなのかを明確にしないと、「どちらが正しいデータか分からない」状態に陥ります。

ステップ5：運用テスト・展開

本番展開の前に、サンプルレコードを使って想定ワークフロー・レポートが意図どおり動くかを必ず検証します。ここを省略すると、運用開始後に「ワークフローが意図しないタイミングで動く」「レポートに数字が出ない」といった問題が頻発します。

ワークフロー・レポートとの連携で気をつけるべきこと

このセクションでは、カスタムオブジェクトを作成した後、ワークフローとレポートで活用する際の注意点を整理します。

ワークフローでの利用

カスタムオブジェクトはワークフローのトリガーとアクションの両方で使えます。「契約終了日の30日前に担当者にタスクを作る」「契約ステータスが特定の値になったらコンタクトのプロパティを更新する」といった運用が可能です。ただし、ワークフローはオブジェクト単位で動くため、たとえばコンタクトベースのワークフローからカスタムオブジェクトのプロパティを直接参照することには制約があります。設計時にどのオブジェクトを起点にするかを決めておく必要があります。

レポート作成時の制約

カスタムオブジェクトはカスタムレポートビルダーのデータソースとして利用できます。一方で、ダッシュボードの一部ウィジェットやプリセットレポートでは、標準オブジェクトのみを対象としているものもあるため、カスタムオブジェクトを軸にしたレポートを作る場合はカスタムレポートビルダーで作成する前提になります。レポートに必要なディメンションがプロパティ化されているか、関連付けが正しく取れているかを、設計段階で確認しておくと手戻りが減ります。

HubSpotレポートの設計指針

カスタムオブジェクトを軸にしたレポート設計の基本的な考え方は、標準オブジェクトのレポート設計と共通する部分が多いため、HubSpotレポート設計のガイドもあわせて参照すると、ディメンションと指標の整理がしやすくなります。

カスタムオブジェクトでよくある失敗パターン

このセクションでは、設計段階・運用段階で発生しやすい失敗パターンを紹介します。

失敗1：取引と役割が重複する

「契約」というカスタムオブジェクトを作ったが、取引オブジェクトと役割が被り、同じ情報を二重に入力する運用になっているケースです。取引を「成約までの商談プロセス」、契約を「成約後の継続関係」と切り分けるなど、ライフサイクルの境界を明示する必要があります。

失敗2：プロパティが肥大化する

「念のため」でプロパティを増やし続けた結果、入力者が何を埋めればいいか分からなくなり、結果的に大半のプロパティが空欄になっている状態です。プロパティは必須・任意・自動入力を最初に明確に分け、増やすたびに「これがないと業務が止まるか」を問うルールを設けることが有効です。

失敗3：関連付けラベルがなく、役割が判別できない

「契約者」と「請求先担当」を区別せずに関連付けてしまい、レポートで「契約あたりの担当者数」が意味をなさなくなるケースです。関連付けラベルを使い、役割を区別することで防げます。

失敗4：データの正本が決まっていない

基幹システムとHubSpotの両方で同じカスタムオブジェクトを更新できる状態になり、どちらが最新か分からなくなる失敗です。設計段階で、各プロパティについて「どこが正本か」を明示し、片方を読み取り専用にする運用ルールが有効です。

失敗5：ワークフローが想定どおり動かない

カスタムオブジェクトとコンタクトの間でデータが期待通りに連動しない、関連レコードのプロパティが取れないといった問題です。ワークフローはオブジェクト単位で動く制約があるため、設計時にトリガーとなるオブジェクトを明確にし、必要であれば関連レコードを更新するワークフローを別建てで作る判断が必要です。

失敗6：データクレンジングを前提にしていない

運用初期は綺麗だったデータも、入力者の増加・連携先の追加・プロパティ追加で徐々に汚れていきます。HubSpotのデータクレンジングの考え方をカスタムオブジェクトにも適用し、定期的な点検フローを最初から組み込んでおくことが重要です。

外注・社内体制の判断：自社で設計するか、外部に任せるか

このセクションでは、カスタムオブジェクト設計を社内で進めるか、外部の支援を受けるかの判断軸を整理します。

カスタムオブジェクト設計は、HubSpotの操作スキルだけでは完結せず、CRMのデータモデル設計、業務プロセス整理、API連携の知見が交差する領域です。社内にCRM／MA設計の経験者がいれば内製でも進められますが、以下のような場合は外部の支援を検討する価値があります。

• HubSpot Enterpriseを契約したばかりで、社内に運用経験者がいない
• カスタムオブジェクトを基幹システムとAPI連携する必要がある
• 取引・契約・サブスクリプションなど、複数オブジェクトの関係整理が必要
• 過去に標準オブジェクトの運用で失敗した経験があり、再発を避けたい

外注の選択肢としては、HubSpot公認のソリューションパートナー、フリーランスのHubSpotコンサルタント、CRM設計の専門会社などがあります。それぞれの特徴と選び方は、HubSpot導入支援サービスの選び方やHubSpot運用代行で頼めることでも整理しています。

社内に1人だけマーケ担当者がいて、CRM設計まで一人で抱えるのが厳しい場合は、HubSpotの一人マーケ運用の論点も参考になります。

まとめ：カスタムオブジェクトは「データモデル」の意思決定

このセクションでは、本記事の要点をまとめます。

HubSpotのカスタムオブジェクトは、自社固有のデータ構造をCRMに組み込める強力な機能です。一方で、安易に作るとデータモデルが複雑化し、ワークフロー・レポートの保守コストが膨らみます。本記事で示した判断軸を再掲します。

• 標準オブジェクト＋カスタムプロパティで表現できないかを最初に問う
• そのデータをワークフローやレポートの軸として使うかを確認する
• レコードの作成・更新の主体と正本を明確にする
• 取引などの標準オブジェクトとの役割の境界を言語化する
• 関連付けラベルでオブジェクト間の役割を意味付ける
• 運用後の汚染を前提にデータクレンジングの仕組みを最初から組み込む

カスタムオブジェクトは機能ではなく、データモデルの意思決定です。設計を後から変更するコストは大きいため、業務要件を言語化し、必要性を慎重に判断したうえで、長く使える構造を作ることをおすすめします。HubSpotのデータモデル設計や運用にお悩みの方は、お気軽にご相談ください。

よくある質問（FAQ）

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

Marketing Hub・Sales Hub・Service Hub・Operations HubのいずれかのEnterprise以上で利用できます。Professionalプラン以下では作成できないため、設計検討の前にプラン要件の確認が必要です。

カスタムオブジェクトとカスタムプロパティの違いは何ですか？

カスタムプロパティは既存オブジェクトに項目を追加する機能で、カスタムオブジェクトはオブジェクトそのものを新設する機能です。1社あたり複数件の独立したライフサイクルを持つデータを扱う場合は、プロパティではなくオブジェクトとして設計する必要があります。

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

HubSpotのプランごとに作成可能数に上限が定められていますが、上限値はプラン仕様の変更により更新される可能性があるため、最新の上限はHubSpotの公式ドキュメントで確認することをおすすめします。実務上は、数を増やすほど運用が複雑化するため、上限よりも自社の運用キャパシティが先に制約になることが多いです。

カスタムオブジェクトのレコードはAPIで作成・更新できますか？

はい、HubSpot APIを通じてレコードの作成・更新・削除・取得が可能です。基幹システムとの連携を前提とする場合は、設計段階で外部キー（一意識別子）を持たせる、関連付けの紐づけ方を決めるなど、API連携を意識した設計が必要になります。

カスタムオブジェクトを作った後で削除することはできますか？

削除は技術的には可能ですが、関連レコード・ワークフロー・レポート・リストなどへの影響が広範囲に及びます。実運用では、削除よりも「使わなくする」「アーカイブする」運用に切り替える方が現実的なケースが多いため、最初から削除前提で気軽に作るのは推奨できません。