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

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

カスタムオブジェクトとは、コンタクト・会社・取引・チケットといった標準オブジェクトでは表せない自社固有の単位（契約、物件、プロジェクトなど）を、独自のプロパティと関連付けを持つオブジェクトとして新設できるHubSpotの機能です。既存オブジェクトに項目を足すカスタムプロパティとは、扱える関係の形が違います。

HubSpotのCRMには、コンタクト（個人）、会社、取引、チケットを中心に、リード・製品・見積もりなどの標準オブジェクトが用意されています。BtoBの営業・マーケティング業務の多くは、コンタクト・会社・取引・チケットの4つで運用できます。一方で、自社のビジネスに固有の「物」「契約単位」「関係性」を扱いたい場合、標準オブジェクトのプロパティを増やすだけでは表現しきれない場面が出てきます。そうした場面で、独自のオブジェクト型を定義する手段がカスタムオブジェクトです。

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

HubSpotの標準オブジェクト一覧と役割

HubSpotのオブジェクトとは、CRMに保存するデータの種類のことです。コンタクトや取引といった種類ごとにレコードの一覧とプロパティがあり、オブジェクト同士を関連付けて使います。HubSpotナレッジベース（2026年8月4日更新）に載っている標準オブジェクトのうち、BtoBの営業・マーケティングで使うことの多いものは次のとおりです。

このほか、サービス、物件（英語版ではListings）、アポイントメント、コース、プロジェクトも標準オブジェクトとして用意されていますが、スーパー管理者が有効にしてから使います。電話・メモ・タスクといった活動の記録もオブジェクトの一種です。利用条件はプランの改定で変わるため、設計を始める前にHubSpotナレッジベースのオブジェクト一覧と自社の契約プランを照らし合わせてください。

カスタムオブジェクトの作成を検討する前に、標準オブジェクトで代わりが利かないかを確かめます。たとえば受注後の契約を管理したい場合でも、定期請求を自動化したいだけならサブスクリプションで、商談前の見極めを取引と分けたいだけならリードで足りることがあります。一覧のどれにも当てはまらず、1社に複数件ぶら下がる単位が残ったときが、カスタムオブジェクトを作る候補です。

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

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

利用できるプランと前提

カスタムオブジェクトは、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue HubのいずれかのEnterpriseプランで利用できます（HubSpotナレッジベースの記載による）。Professionalプラン以下では作成できないため、設計を検討する前にまず自社の契約プランを確認してください。Professionalプランを使っている場合は、Enterpriseへのアップグレード費用に見合う業務上の効果があるかを、設計に入る前に経営側と確認します。

カスタムオブジェクトは、標準オブジェクトで表現しきれない業務構造を持たせるための機能です。まだコンタクト・会社・取引の使い分けが固まっていないなら、先に標準オブジェクトでの設計を決めてから、足りない部分だけをカスタムオブジェクトにします。

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

作るべきなのは、1社に複数件ぶら下がり、それぞれが独立して状態を変えるデータを、ワークフローやレポートの軸として使う場合です。標準オブジェクトにプロパティを足して表せるなら、作りません。

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

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

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

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

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

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

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

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

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

1対多にならない情報であれば、オブジェクトを増やすより既存オブジェクトのプロパティで持つほうが運用は軽くなります。プロパティで持つと決めたら、標準オブジェクト側のプロパティとして型と選択肢を先に決めてから作成します。

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

BtoBで検討されやすいのは、サブスクリプション、物件・資産、個人と組織の所属関係、代理店、イベント・プロジェクトの5つです。いずれも、先に標準機能で代替できないかを確認してから作ります。

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

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

サブスクリプションオブジェクトを作り、契約プラン・MRR・契約開始日・更新日・解約日を保持する設計が考えられます。1社が複数プロダクトを契約するケースや、プラン変更履歴を残したいケースで有効です。HubSpotには定期支払いや定期請求を扱う標準の「サブスクリプション」機能もあるため、請求の自動化が目的ならそちらで足りないかを先に確認し、MRRや更新管理を独自の項目で持ちたい場合にカスタムオブジェクトを検討します。

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

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

医療・士業・教育機関

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

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

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

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

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

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

設計は、業務要件の書き出し→プロパティ定義→関連付け→レコード作成・連携→運用テストの5ステップで進めます。後から変えにくいプロパティの型と関連付けラベルを、運用開始前に決めておくのが目的です。

ステップ1：業務要件の書き出し

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

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

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

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

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

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

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

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

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

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

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

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

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

カスタムオブジェクトはワークフローのトリガー・アクションにも、カスタムレポートビルダーのデータソースにも使えます。気をつけるのは、ワークフローをどのオブジェクト起点で組むかと、レポートに使う項目をプロパティとして持っているかの2点です。

ワークフローでの利用

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

レポート作成時の制約

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

HubSpotレポートの設計指針

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

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

よくある失敗は、取引との役割重複、プロパティの肥大化、関連付けラベルの未設定、データの正本の未決定、ワークフローの起点の誤り、データ劣化の放置の6つです。どれも設計段階で決めておけば防げます。

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

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

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

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

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

「契約者」と「請求先担当」を区別せずに関連付けてしまい、レポートで「契約あたりの担当者数」が意味をなさなくなるケースです。更新月にCSが契約レコードを開いても、誰に更新の連絡をすればよいか分からない状態になります。関連付けラベルを使い、役割を区別することで防げます。

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

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

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

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

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

運用初期は綺麗だったデータも、入力者の増加・連携先の追加・プロパティ追加で徐々に汚れていきます。HubSpotのデータクレンジングの考え方をカスタムオブジェクトにも適用し、定期的な点検フローを最初から組み込んでおきます。たとえば四半期ごとに、必須プロパティの空欄率と、どのオブジェクトにも関連付いていないレコードの件数を確認します。

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

社内にCRMのデータモデル設計とAPI連携の経験者がいれば、内製で進められます。いなければ、少なくとも初期設計は外部の支援を受けるほうが、作り直しの費用を抑えられます。

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

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

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

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

カスタムオブジェクトは一度作ると後戻りが難しいため、作る前の判断で結果がほぼ決まります。業務構造を前提に設計方針をご相談いただけます。

カスタムオブジェクトでも表せない業務がある場合は、カスタマイズ開発やスクラッチ開発を検討する段階です。開発会社に相談する前に、SaaSの設定で足りるかシステム開発が必要かを判断の条件に沿って確かめます。

まとめ

カスタムオブジェクトを作るかどうかは、機能を使うかどうかではなく、自社のデータをどの単位で持つかの決定です。

HubSpotのカスタムオブジェクトは、自社固有のデータ構造をCRMに組み込める強力な機能です。一方で、安易に作るとデータモデルが複雑化し、ワークフロー・レポートの保守コストが膨らみます。作る前に確認するのは次の6点です。

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

次にやることは、作りたいオブジェクトについて「1レコードが何を表すか」「1社に何件ぶら下がるか」「どのワークフローとレポートで使うか」を1枚に書き出し、標準オブジェクト＋プロパティで表せないかを確かめることです。表せないと分かってから、設計ステップに進んでください。書き出した1枚をもとに、作るかどうかの判断からご相談いただけます。

よくある質問（FAQ）

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

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

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

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

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

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

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

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

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

削除はできますが、削除したカスタムオブジェクトは復元できません。また、ほかのツールで使われているカスタムオブジェクトは削除できないため、先にワークフローやレポートなどからの参照を外す必要があります（HubSpotナレッジベースの記載による）。実運用では、削除よりも「使わなくする」「アーカイブする」運用に切り替える方が現実的なケースが多いため、最初から削除前提で気軽に作るのは推奨できません。