HubSpotの標準プロパティを使うべき理由。コンタクト・会社・取引の重要項目を解説

旧記事の公開日：2026.07.24／情報確認日：2026.10.05

HubSpotを使い始めると、自社の管理方法に合わせてプロパティーを追加したくなる場面が多くあります。

たとえば、標準の「金額」があるのに「案件金額」を作る。標準の「クローズ日」があるのに「受注予定日」を作る。標準の「取引担当者」があるのに「営業担当者」を作る。入力する人にとっては分かりやすそうですし、データを保存するだけであれば、これでも大きな問題はないように見えます。

しかしHubSpotでは、どのようなデータを持っているかだけでなく、そのデータがどのプロパティーに入っているかが重要です。

HubSpotの標準プロパティーの中には、重複管理、自動計算、デフォルトの売上予測、AI取引スコアなどで参照される項目があります。同じ名前のカスタムプロパティーを作っても、その役割まで自動的に引き継がれるわけではありません。一方、レポートやワークフローではカスタムプロパティーも利用できます。

この記事では、コンタクト・会社・取引の3つのオブジェクトを対象に、特に重要な標準プロパティーと、それらがHubSpot内で果たしている役割を解説します。

HubSpotは、オブジェクトごとに数多くの標準プロパティーを用意しています。

これらの中には、同じような名前のカスタムプロパティーを作っても、機能を置き換えられないものがあります。

たとえば「案件金額」というカスタムプロパティーに100万円と入力しても、標準の「金額」を参照するレポートへは自動的に反映されません。デフォルトの売上予測も「金額」と「クローズ日」を使います。ただし、カスタム予測タイプでは、通貨として設定したカスタム金額項目と日付項目を指定できます。「カスタム項目は使えない」のではなく、機能ごとの参照先を確認することが大切です（公式：カスタム予測タイプ）。

HubSpotも、カスタムプロパティーを作成する前に、既存の標準プロパティーで要件を満たせないか確認することを推奨しています（公式：プロパティーの作成と編集）。

コンタクトは、人の情報やマーケティング・営業活動の履歴を管理するオブジェクトです。ここでは、特に重要な3つの標準プロパティーを取り上げます。

Eメール

Eメールは、コンタクトへの連絡先であると同時に、HubSpotがコンタクトを識別するための重要なプロパティーです。

HubSpotでは、Eメールを使ってコンタクトの重複を管理します。また、コンタクトのEメールドメインと会社の「会社ドメイン名」を照合し、コンタクトと会社を自動的に関連付ける機能でも使われます。

フォーム送信時のレコードの照合や、メール活動を記録する際にもEメールが使われます。ただし、フォームの既存レコード更新にはCookieやフォーム設定が関わり、メール活動の保存にはログ設定なども関わります。Eメールを入力しただけで、すべてのやり取りが自動保存されるわけではありません。

そのため、主要なメールアドレスを「連絡先メール」「業務用メール」といった別のカスタムプロパティーだけに保存すると、HubSpot上にデータは存在していても、メール送信や重複管理などの標準機能にうまくつながりません。

特別な理由がなければ、コンタクトの主要なメールアドレスは標準の「Eメール」に入れるのが基本です（公式：コンタクトの作成）。

コンタクト担当者

コンタクト担当者は、そのコンタクトに対して責任を持つHubSpotユーザーを表します。

担当者別のコンタクト一覧やレポートだけでなく、ワークフローによる割り当て、タスクの作成、通知、レコードのアクセス権限などにも利用されます。さらに、担当者が割り当てられた日時や担当チームなど、関連する標準プロパティーもHubSpotによって自動的に更新されます。

そのため、実質的に同じ意味で「営業担当者」などのカスタムプロパティーを作り、コンタクト担当者を空欄にしてしまうと、HubSpotが想定している担当者ベースの機能を利用しにくくなります。

コンタクトレコードの主担当者は標準の「コンタクト担当者」に設定し、標準プロパティーでは表現できない明確な役割がある場合に、追加のプロパティーを検討するのがよいでしょう。

ライフサイクルステージとリードステータス

ライフサイクルステージは、コンタクトや会社がマーケティング・営業プロセスのどの段階まで進んだかを表します。

HubSpotには、登録読者、リード、MQL、SQL、商談、顧客といった段階が用意されています。ライフサイクルステージを使うことで、ステージごとのコンタクト数、次のステージへ進むまでの期間、マーケティングから営業への引き渡しなどを分析できます。

一方、リードステータスは、営業がそのリードに対して現在どのような対応をしているかを管理するためのプロパティーです。

• ライフサイクルステージ：購買プロセス上の大きな段階
• リードステータス：営業による日々の対応状況

この2つは似ていますが、役割が異なります。「電話済み」「連絡待ち」といった細かい活動状況をライフサイクルステージに詰め込むと、ファネル分析が複雑になります。

ライフサイクルステージには、各ステージへの移行日時や滞在期間を扱う計算プロパティーがあります。ただし、最新滞在時間と累積滞在時間の利用にはProfessionalまたはEnterpriseが必要です。また、これらの滞在時間は、そのステージにいる間に現在の経過時間を表示し続けるものではありません（公式：ライフサイクルステージ）。

会社オブジェクトでは、法人・組織単位の情報を管理します。会社名だけでなく、ドメイン、担当者、ライフサイクルステージ、業種などを標準プロパティーへ入れることで、コンタクトや取引を会社単位で把握しやすくなります。

会社名と会社ドメイン名

会社名は、会社レコードを人が見て識別するために必要です。一方、HubSpotの機能上、より重要になることが多いのが「会社ドメイン名」です。

HubSpotには、コンタクトのEメールドメインと会社ドメイン名を照合し、コンタクトと会社を自動的に関連付ける機能があります。たとえば、user@example.comというコンタクトを、会社ドメイン名がexample.comの会社へ関連付ける仕組みです（公式：コンタクトと会社の自動関連付け）。

この自動関連付けは設定を有効にした場合の動作で、無料メールのドメインなどには例外があります。会社ドメイン名は重複管理にも使われますが、APIで作成される会社には、ドメインによる自動重複排除が適用されません。外部連携では作成経路も確認してください（公式：レコードの重複排除）。

「企業URL」「コーポレートサイト」などのカスタムプロパティーだけにURLを保存するのではなく、会社を識別する主要なドメインは標準の「会社ドメイン名」に入れておくことをお勧めします。

会社担当者

会社担当者は、その会社・アカウントに対して責任を持つHubSpotユーザーを表します。

コンタクト担当者は一人ひとりのコンタクトに対する担当者ですが、会社担当者は法人・組織単位の担当者です。同じ会社に複数のコンタクトが存在する場合でも、会社担当者を設定しておくことで、アカウント単位の責任者を明確にできます。

会社担当者は、会社別のレポート、ワークフロー、担当者の自動割り当て、チームやアクセス権限などで使われます。

会社のライフサイクルステージ

ライフサイクルステージは、コンタクトだけでなく会社にも存在します。

BtoBでは、個人単位ではなく会社単位で「見込み客」「商談中」「顧客」といった状態を把握したいことがあります。会社のライフサイクルステージを使えば、会社単位のファネルや、マーケティング・営業の対象企業数を確認できます。

HubSpotには、プライマリー会社のライフサイクルステージを、関連するコンタクトへ反映する設定があります。この標準設定は会社からコンタクトへの同期で、コンタクトの変更を会社へ戻す双方向同期ではありません。また、ステージを後戻りさせる更新は行いません（公式：ライフサイクルステージの自動設定と同期）。

独自の「顧客区分」や「会社ランク」が必要な場合は併用しても構いませんが、購買プロセス上の段階を表す情報は、まずライフサイクルステージで管理できないか検討してみてください。

業種・従業員数などのエンリッチメント対象項目

HubSpotのデータエンリッチメントでは、会社ドメイン名をもとに、取得可能な会社情報を追加できます。利用には対象の有料契約と権限が必要で、HubSpot側に補完できるデータがない場合は値が入りません。対象項目には次のようなものがあります。

• 業種
• 業界グループ
• 従業員数
• 従業員規模
• 年間売上高
• 所在地
• 設立年
• Webサイトで利用されている技術

これらの値を標準プロパティーに持つことで、セグメント、リードスコアリング、ワークフロー、ターゲティング、パーソナライズなどに利用できます（公式：エンリッチメント対象プロパティー）。

ただし、エンリッチメントで付与された値が、常に最新かつ正確であるとは限りません。

HubSpotのエンリッチメントは、HubSpotの商用データセットを利用します。実務では、推定値と確認済みの値を区別し、重要な項目は企業の公表資料や本人から取得した情報と照合する運用をお勧めします。

業種を大まかなセグメントに利用する、従業員数を営業優先度の参考にするといった使い方はできますが、契約条件や担当者の割り振りなど、重要な判断に使う場合は別途確認した方が安全です。

標準プロパティーを使うことと、値を無条件に信頼することは別です。値の出所と更新方法も確認しましょう。エンリッチメントの保存先は、型が対応するカスタムプロパティーへ変更できる場合もあります。自動・手動・継続的なエンリッチメントでは上書きの動作が異なり、ワークフローの設定などが優先される場合もあるため、マッピングと更新ルールを併せて確認します（公式：エンリッチメント設定）。

取引は、営業案件と売上機会を管理するオブジェクトです。取引の標準プロパティーは、売上予測やAI取引スコアなどと結び付いています。予測ツールはSales HubまたはService HubのProfessional／Enterprise、AI取引スコアはSales HubまたはSmart CRMのProfessional／Enterpriseが対象です。操作によって必要なシートや権限も異なります（公式：予測ツールの設定、公式：取引スコア）。

取引担当者

取引担当者は、その取引・営業案件に責任を持つHubSpotユーザーです。

HubSpotの標準担当者プロパティーには、基本的に一人の主担当者を設定します。取引担当者を設定することで、担当者別のパイプライン、売上予測、受注金額、営業成績などを集計できます。

また、HubSpotのAI取引スコアでは、取引に担当者がいない期間や、担当者が変更されたことも考慮されます（公式：AIによる取引スコア）。

取引スコアは、担当者や金額だけでなく、活動履歴、買い手の反応、取引の進行など複数の情報を使います。標準項目を入力すれば必ず高得点になるという意味ではなく、営業判断の参考情報として扱います。主な要因と履歴の確認にはSalesシートが必要です。

ここで大切なのは、マーケティング、セールス、カスタマーサクセスのすべての担当者を、一つの取引レコードに追加することではありません。

HubSpotは、コンタクト、取引、チケット、サービスなど、業務やフェーズに応じてオブジェクトを分け、それぞれに担当者プロパティーを用意しています。取引担当者には、その営業案件の主担当者を設定するのが基本です。サポートやサービス提供の担当者は、その業務を管理するオブジェクト側で持たせます。

同じ営業案件に複数の関係者が関わり、追加の担当者情報が本当に必要な場合は、カスタムのHubSpotユーザープロパティーなどで補足できます。ただし、標準の取引担当者を空欄にして、独自の「案件担当者」だけで管理するのは避けた方がよいでしょう。

金額

標準の「金額」は、取引の価値を表す中心的なプロパティーです。

金額に値を入れることで、次のような機能や値につながります。

• 加重金額
• 売上予測
• 担当者別の見込売上
• 受注金額レポート
• 関連会社の売上集計や直近の受注取引金額
• AI取引スコア

「加重金額（Weighted amount）」は、標準の「金額」×「取引確度」です。一方、「予測金額（Forecast amount）」は「金額」×「予測確度」で、別の項目です。予測ツールの金額表示には設定があり、両者を混同しないようにします（公式：予測ツールの金額設定）。AI取引スコアでも、金額やその変更が判断材料として使われます。

一方で、「案件金額」「見込金額」といったカスタムプロパティーに値を入れても、標準の金額と同じようにすべての機能から参照されるわけではありません。

取引に複数の金額がある場合は、どの値をHubSpot上の代表的な取引金額として扱うかを決めます。

たとえば、初期費用、月額費用、年間契約金額、原価、粗利がある場合、売上予測や案件規模の判断に使う値を標準の「金額」へ入れます。それ以外の金額は、カスタムプロパティーや商品項目で管理します。

商品項目を使う場合は、取引金額の計算設定も確認してください。標準のARR・MRR・TCVは商品項目をもとに計算され、「金額」の値から算出されるものではありません。ARR・MRRにはSales Hub Professional／Enterpriseが必要です（公式：取引の標準プロパティー）。

クローズ日

クローズ日は、取引が受注または失注すると見込んでいる日、あるいは実際に受注・失注した日を表します。

• オープンな取引：受注または失注する見込みの日
• クローズ済みの取引：実際に受注または失注した日

クローズ日は、月次・四半期の売上予測、クローズまでの日数、期間別の売上レポートなどで使われます。

また、AI取引スコアでは、クローズ日までの期間や、クローズ日が何度変更されたかも考慮されます。クローズ日が空欄だったり、実態と関係のない日付が入っていたりすると、AIや予測機能へ渡される情報の質も下がります。

HubSpotでは、オープンな取引を作成した際のデフォルトクローズ日や、取引を受注・失注ステージへ移動した際のクローズ日更新も設定できます（公式：クローズ日の自動化）。

「受注予定日」というカスタムプロパティーを作っている場合、その日付が取引のクローズ見込み日を意味するのであれば、標準のクローズ日へ入れることを検討してください。

一方、納入予定日、サービス開始日、請求予定日などは、取引がクローズする日とは意味が異なります。これらはカスタムプロパティーとして分けて管理します。

取引ステージ

取引ステージは、その取引が営業プロセスのどこまで進んでいるかを表します。

通常、取引を次のステージへ進めると、そのステージの設定に合わせて「取引確度」が更新されます。ただし、個別の取引確度を手動変更すると、オープンなステージ間の移動では自動更新されなくなります。ステージへの移行日時や滞在期間を扱う計算プロパティーにはProfessional／Enterpriseが必要です（公式：取引の標準プロパティー）。

AI取引スコアでも、現在の取引ステージや、そのステージに滞在している時間が考慮されます。

標準の取引ステージとは別に、実質的に同じ意味の「案件ステータス」を作ると、取引の進行状況が二つのプロパティーに分散してしまいます。営業プロセス上の進捗は、まず取引ステージで表現できないかを検討しましょう。

ここまで標準プロパティーを使うメリットを説明しましたが、すべての情報を標準プロパティーだけで管理する必要はありません。

重要なのは、次の順序で考えることです。

1. 管理したい情報と同じ意味の標準プロパティーがないか確認する
2. その標準プロパティーが、どのHubSpot機能で使われるか確認する
3. 標準プロパティーで表現できない情報だけをカスタムプロパティーで補う

複数の値がある場合は「代表値」を決める

実際の業務では、金額や日付が一つとは限りません。その場合、すべてを無理に一つの標準プロパティーへまとめるのではなく、HubSpot上で代表値として扱うものを決めます。

名称や選択肢が分かりにくい場合は、編集できる範囲で表示名や選択肢を調整できます。ただし、変更可能な範囲は項目ごとに異なり、内部名は変更できません。フィールドタイプの変更によって既存値が無効になることもあるため、事前にデータをエクスポートし、フォーム・レポート・ワークフロー・連携への影響を確認します（公式：プロパティーの作成と編集）。

それでも標準プロパティーでは表現できない場合や、そもそも保存したい情報の意味が異なる場合は、カスタムプロパティーを作成します。

カスタムプロパティーを作りすぎない

カスタムプロパティーを簡単に追加できることはHubSpotの長所ですが、増やしすぎると次のような問題が起こります。

• どのプロパティーに入力すればよいか分からない
• 同じ意味のデータが複数のプロパティーへ分散する
• 担当者ごとに入力先が変わる
• レポートやワークフローごとに参照先が異なる
• 使われていないプロパティーを判断できない
• 後から整理・統合するための作業が増える

特に、標準プロパティーとほぼ同じ意味のカスタムプロパティーを作る場合は注意が必要です。

新しいプロパティーを作る前に、「この情報を標準プロパティーへ入れることで使えるようになる機能はないか」を一度確認してみてください。

すでに重複した項目がある場合

運用中のカスタム項目を見つけても、すぐに削除するのは避けます。実務上は、次の順で整理することをお勧めします。

1. 項目の意味と、フォーム・レポート・ワークフロー・外部連携の参照先を調べる。
2. 標準項目と値が食い違う場合の優先ルールを決め、データをバックアップする。
3. 少数のレコードで値の移行と参照先の変更を試し、期待する集計や自動処理になるか確認する。
4. 本移行後に旧項目への入力を止め、参照が残っていないことを確認して整理する。

これからHubSpotへ移行する場合

スプレッドシートや他のCRMからHubSpotへ移行する場合も、移行元の項目を一対一ですべて再現する必要はありません。

まず、Eメール、会社ドメイン名、ライフサイクルステージ、担当者、金額、クローズ日、取引ステージなど、HubSpotの主要な標準プロパティーへ割り当てられる情報を整理します。

金額や日付が複数ある場合は、HubSpotの予測やレポートで使う代表値を決めます。そのうえで、意味の異なる情報だけをカスタムプロパティーとして残します。

この整理をしておくことで、移行直後からHubSpotの標準レポートや予測、自動化を利用しやすくなります。

HubSpotの標準プロパティーを必ずそのまま使わなければならないわけではありません。

ただし、一部の標準プロパティーには、重複管理や自動計算、デフォルトの予測、AI取引スコアで参照される役割があります。カスタム項目で補う場合も、どの機能がどの項目を使うかを確認することが大切です。

まず標準プロパティーを使ってみる。自社の運用に合わなければ、変更可能な範囲で名称や選択肢を調整する。それでも足りない情報をカスタムプロパティーで補う。

この順序で考えることで、データを必要以上に複雑にせず、HubSpotが持っている機能をより広く活用できるようになります。