HubSpotのデータモデルヘルスチェックは、オブジェクト・プロパティー・関連付け・パイプライン・ライフサイクルステージの5カテゴリを自動でスキャンし、16種類の問題を一覧にして推奨アクションまで示す点検機能です。 場所は「データ管理」>「データモデル」の「健康」タブで、公式ナレッジでは「すべての製品とプラン」で利用できると案内されています。
プロパティーが増え続け、似た名前の項目が並び、誰も使っていないパイプラインが残る——データモデルの劣化は気づきにくく、レポートの信頼性や入力の手間にじわじわ効いてきます。この記事では、ヘルスチェックの実行手順、検出内容、整理するかどうかの判断、移行前後の点検としての使い方を整理します。
- 実行手順と結果画面の読み方 ── 「健康」タブを開くだけで始まるスキャンの流れと、オブジェクト別の詳細画面
- 検出される16種類の問題 ── 5カテゴリ別に、何を見つけて何を勧めるのかを一覧で確認
- 整理するか残すかの判断表 ── アーカイブの前に確認すること。公式の事実と当社の見解を分けて記載
- 移行前・移行後の定期点検 ── 工程のどこでヘルスチェックを走らせるか
ヘルスチェックの位置づけと、まず押さえる前提
ヘルスチェックは、データモデルの「設計の健全性」を点検する機能です。個々のレコードの誤入力を探すのではなく、プロパティーの使われ方やパイプラインの作り、関連付けの有無といった「器」の側を診断します。
公式ナレッジ(日本語版)によると、対象は「すべての製品とプラン」です。必要な権限の記載はありません。また、日本語版は自動翻訳で、正確な最新情報は英語版を確認するよう注記されています。製品の発表面では、公式の Fall 2026 Spotlight の一覧で「Updated」として掲載されており、ベータ表記は付いていません(公式のSpotlightページで確認)。
データクレンジングとの違い
重複レコードの統合や表記ゆれの修正は「データ(中身)」のクレンジングです。ヘルスチェックが見るのは「データを入れる器」で、たとえば充填率の低いプロパティーや、似た内容で二重に作られたプロパティー、完了ステージのないパイプラインが対象です。レコードの名寄せや重複管理はCRMデータクレンジングの設計と運用で整理しており、両者は補い合う関係です。
画面で見る前に、役割を決めておく
ヘルスチェックの結果から実行できる操作には、プロパティーのアーカイブやカスタムオブジェクトの削除など、データモデルを変更するものが含まれます。見る人と、変更を実行する人を分けておくと、事故を防げます。当社では、結果の閲覧は運用担当、変更の実行は「設計を決めた人の承認後」とする分担を推奨しています。企業様によって最適な形は異なりますので、まずは自社の権限構成に合わせて決めてください。

ヘルスチェックの実行手順と結果画面の読み方
実行そのものは数クリックで済みます。時間がかかるのはスキャン完了の待ち時間と、結果の解釈です。公式ナレッジの手順に沿って整理します。
実行の流れ
- HubSpotで「その他」から「データ管理」>「データモデル」を開きます
- 「健康」タブを選びます
- ページを開くとヘルスチェックが自動的に始まります。再実行する場合は「ヘルスチェックを再実行」をクリックします
- スキャンには最大約20分かかります。ページを離れても問題なく、進行状況のインジケーターで実行中かどうかを確認できます
- 完了後、結果が概要ページに表示されます
スキャン完了時のプッシュ通知はありません。実行したら、別の作業をしつつ、あとで「健康」タブを開き直して結果を確認する運用になります。
概要ページと詳細ページ
概要ページには、検出された問題の総数、再実行ボタン、問題のあるオブジェクトの一覧(件数とカテゴリ別内訳)が表示されます。オブジェクトを選ぶと詳細ページに入り、「オブジェクト」「プロパティー」「関連付け」「パイプライン」「ライフサイクルステージ」のタブごとに問題を確認できます。
詳細ページには、検索バー、課題タイプのフィルター、行ごとの「アクション」メニュー、チェックボックスによる一括操作があります。最初は件数の多いオブジェクト(コンタクト・会社・取引など)から見るのが効率的です。
現在のバージョンでできないこと
公式ナレッジには、次の制限が明記されています。問題を却下(無視)する機能はなく、解決するか、そのまま残すかのどちらかになります。再実行すると新しい結果が以前の結果を置き換えるため、前回の結果は残りません。実行中に別のスキャンを始めることもできません。
これらは運用の設計に直結します。却下ができないため、「意図的に残す」と決めた項目は、一覧に出続けます。次の節で、その扱い方を整理します。
検出される16種類の問題を5カテゴリで読み解く
公式ナレッジが示す検出項目は、5カテゴリ・16種類です。それぞれに推奨アクションが付いていますが、推奨に従えば正しい、というものではありません。「なぜその問題として出たのか」を理解して判断します。
オブジェクトと関連付け(5種類)
| 検出される問題 |
公式の推奨アクション |
| カスタムオブジェクトのレコード数が少ない |
削除または非アクティブ化を検討 |
| 切り替え可能なオブジェクトのレコード数が少ない |
オブジェクトを無効化 |
| カスタムオブジェクトに関連付けがない |
関連付けを作成 |
| カスタム関連付けのレコード数が少ない |
内容を確認し、不要なら削除 |
| 切り替え可能な関連付けのレコード数が少ない |
内容を確認し、不要なら無効化 |
試験的に作ったカスタムオブジェクトの残骸や、使われなかった関連付けラベルが見つかる領域です。一方で、「今後使い始める予定のオブジェクト」もレコード数が少ないため検出されます。設計の意図を知っている人が判断する必要があります。カスタムオブジェクトの設計判断はカスタムオブジェクトの設計判断で整理しています。
プロパティー(6種類)
| 検出される問題 |
公式の推奨アクション |
| 充填率が低い |
アーカイブを検討。プロパティーの管理や履歴のエクスポートも選択肢 |
| 重要なプロパティーの充填率が低い |
レコードのレイアウトを見直す。履歴のエクスポート、管理、アーカイブも可能 |
| 充填率は低いが使用率は高い |
利用状況を確認し必要性を判断 |
| 未利用プロパティー |
アーカイブ、履歴のエクスポート、管理から選ぶ |
| 類似(重複)するプロパティー |
データを確認して同期の要否を判断し、不要な方をアーカイブ |
| 充填率が高いが使用されていない |
ビューへの追加を検討 |
件数が最も多くなりやすいのがこのカテゴリです。「充填率が低い」だけでアーカイブへ進まないことが重要です。充填率の低いプロパティーでも、特定の条件でだけ入力する項目や、年1回だけ使う項目は正当に存在します。
パイプラインとライフサイクルステージ(5種類)
| 検出される問題 |
公式の推奨アクション |
| 標準的でないパイプラインの使用法 |
用途を見直し、情報の置き場所が適切か検討 |
| パイプラインの段階が多すぎる |
パイプライン設定で段階数を減らす |
| 閉じたステージが見つからない |
完了(クローズ)ステージを追加 |
| パイプライン段階のレコード数が過去最低 |
パイプライン設定で段階を見直す |
| ライフサイクルステージごとのレコード数が少ない |
ライフサイクル設定を見直す |
「閉じたステージが見つからない」は、受注・失注に相当する終点がないパイプラインを指します。集計や予測が成立しなくなるため、優先度の高い指摘です。ステージ設計の考え方はパイプライン設計ガイドとライフサイクルステージ設計に整理しています。
なお、公式ナレッジのこのページには、「充填率が低い」と判定されるしきい値や、「少ない」とみなすレコード数の基準は記載されていません。基準値を前提にした説明は避け、画面に表示された事実をもとに判断してください。
整理するか残すかを決める判断表
ここからは当社の見解です。公式が示すのは「何が検出されるか」と「どの操作ができるか」で、「どの項目を消すべきか」は自社の業務によって決まります。
アーカイブの前に確認する3点
プロパティーのアーカイブは、設定画面の「プロパティー」からも実行でき、公式ナレッジでは次の仕様が示されています。アーカイブしたプロパティーは「アーカイブ済み」タブに保存され、90日後に完全に削除されます。90日以上前にアーカイブしたものは復元できません。復元には「プロパティー設定を編集」権限が必要で、完全削除はスーパー管理者のみが実行できます。
また、ワークフローやプロパティーカード、フォームなどで使われているプロパティーは、そのツールから外すまでアーカイブできません。アーカイブを妨げるツールは、右パネルのリンクから確認できます。
これらを踏まえ、当社では次の3点を確認してからアーカイブへ進む運用を勧めています。
- 使われ方の確認:プロパティーの「使用法」タブで、CRM内のどこで使われているかを確認する
- 値の退避:設定の「プロパティー」から、プロパティー定義のエクスポート(ZIP内の3つのCSV)または全プロパティーのエクスポート(充填率を含む)を取り、アーカイブ前の状態を保存する。レコードごとの値を残したい場合は、プロパティー履歴のエクスポートも選べる(手順は公式の別記事)
- 復元の期限の記録:アーカイブした日付を記録し、90日の期限内に問題が出ないか確認する
判断表
| 状況 |
当社の見解 |
理由 |
| 未利用で、作成者・用途とも不明 |
エクスポートを取ったうえでアーカイブ |
90日間は復元でき、定義の控えも残る |
| 充填率は低いが、条件付きで使う項目 |
残す。判断を記録する |
却下機能がなく、一覧に出続けるため理由を別に残す |
| 類似する2つのプロパティー |
値の入り方を比較し、正を決めてから統合を検討 |
同期や参照先の整理が先に必要 |
| 閉じたステージのないパイプライン |
早期に是正 |
受注・失注の集計や予測が成立しない |
| レコード数の少ないカスタムオブジェクト |
設計の意図を確認 |
今後使う予定のものも検出されるため |
判断記録を別に持つ
ヘルスチェックには問題を却下する機能がないため、「検出されたが残す」と決めた項目は、スプレッドシートなど別の場所に記録しておくと、次回の点検で同じ議論を繰り返さずに済みます。記録する列は、項目名・検出された問題・判断(解決・残す・保留)・理由・判断した人・日付の6列が実用的です。
移行前後の点検としての使い方
ヘルスチェックは「たまに実行する掃除道具」としてより、工程の節目で使う点検として位置づけると効果が出ます。StartLinkの支援は、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の工程で進めますが、ヘルスチェックは次の4か所に組み込めます。
工程ごとの使いどころ
| 工程 |
ヘルスチェックの使い方 |
見るポイント |
| 現状の整理・要件定義 |
既存ポータルで実行し、現状の記録にする |
未利用・重複プロパティーの規模感 |
| 設計・構築 |
新規作成物の命名や型の重複を確認 |
類似プロパティー、パイプライン段階数 |
| データ移行後(テスト・検証) |
移行直後に実行して設計意図とのずれを探す |
充填率の低い項目、二重作成、テスト用オブジェクト |
| 定着・運用改善 |
30日ごと、大きな変更の後に再実行 |
件数の推移、新規の指摘 |
移行後に出やすい指摘
移行直後の点検では、次の指摘が出やすくなります。移行元の項目をそのまま持ち込むと、似た名前のプロパティーが二重にできて「類似(重複)」が検出されます。マッピングの漏れや、移行元に値がなかった項目は「充填率が低い」として現れます。また、検証用に作ったカスタムオブジェクトや段階の多いパイプラインが残っていると、オブジェクト・パイプラインのカテゴリで指摘されます。
ここで注意したいのは、移行したばかりの新規プロパティーは、使い始めてから日が浅く充填率が低いのは自然だという点です。移行直後の点検は「異常探し」ではなく、「設計意図とのずれ探し」と捉え、判断記録に「運用開始後に再点検」と書いて保留にするのが現実的です。データ移行の進め方はCRMデータ移行の方法とCRM移行のデータ設計をご覧ください。
定期点検の運用
公式ナレッジでは、前回の実行から30日以上経つと再実行を促す表示が出ます。大きなデータモデル変更の後は定期的な実行が推奨されています。通知は届かないため、月初に1回「健康」タブを開く、と決めておくと運用に乗せやすくなります。毎月の確認では、新しい指摘が増えていないか、保留にした項目の判断期限が来ていないかを見ます。

整理後のデータモデルを保つための運用ルール
一度整理しても、新しいプロパティーを無秩序に作れば、数か月後に同じ指摘が戻ります。点検と並行して、作る側のルールを置きます。
新規プロパティーを作る前の確認
プロパティーを作る前に、既存のプロパティーで代用できないかを確認する手順を決めます。命名規則とデータ型の選び方はプロパティー設計と命名規則に整理しています。作成時に「作成の目的・使うレポートやワークフロー・担当者」の3点を説明欄に書く運用にすると、後から未利用プロパティーとして検出されたときに判断がしやすくなります。
点検結果を設計に戻す
検出された問題が繰り返し同じ領域に出るなら、それは個別の整理ではなく設計の見直しのサインです。たとえば、似たプロパティーが部署ごとに作られる状況は、入力ルールや権限の設計の問題です。個別にアーカイブするだけで終わらせず、原因の設計に手を入れるところまでが点検の役割です。
AIを組み込む場合の注意
HubSpotのBreezeやスマートプロパティーのようにAIがプロパティーを埋める機能を使う場合、整った器があるほど結果が安定します。重複したプロパティーが並ぶ状態でAIに入力させると、どの項目を参照しているかが曖昧になります。AIの活用に進む前の準備として、データモデルの点検を位置づける考え方は、スマートプロパティーの使い方の背景にもつながります。
ヘルスチェックは「消すための機能」ではなく、「判断の材料を一覧にする機能」です。 実行して、判断記録を残し、変更は復元できる形で実行する。この3つを分けて運用すると、データモデルの整理は安全に続けられます。
よくある質問
Q1. ヘルスチェックは無料で使えますか
公式ナレッジ(日本語版)では、「すべての製品とプラン」で利用できると案内されています。具体的な契約条件は、自社のサブスクリプションの内容と公式の最新情報で確認してください。日本語版は自動翻訳のため、英語版が正とされています。
Q2. 実行するとデータが変更されますか
公式ナレッジでは、データモデルを変更するアクションとして、結果画面から実行できるプロパティーのアーカイブやカスタムオブジェクトの削除などが整理されており、これらは実行前に確認のモーダルが表示されます。ヘルスチェックの実行ボタンを押すこと自体を、データの変更として説明する記載は確認できませんでした。
Q3. 検出された問題を無視(却下)できますか
現在のバージョンでは、問題を却下する機能はないと公式ナレッジに明記されています。残すと決めた項目は一覧に出続けるため、別の場所に判断記録を持つ運用をおすすめします。
Q4. アーカイブしたプロパティーは元に戻せますか
「アーカイブ済み」タブから復元できます。ただし、アーカイブしたプロパティーは90日後に完全に削除され、90日以上前のものは復元できません。復元には「プロパティー設定を編集」権限が必要です。
Q5. どのくらいの頻度で実行すればよいですか
公式ナレッジでは、前回の実行から30日以上経つと再実行を促す表示が出ます。大きなデータモデルの変更や、データ移行の直後にも実行する運用がおすすめです。通知は届かないため、月初に「健康」タブを開くといった、人の習慣に結び付けた運用にしておくと、確認の漏れを防げます。
一次情報・参考にした公式ドキュメント
まとめ:点検・記録・復元可能な変更の3点で整える
HubSpotのデータモデルヘルスチェックは、整理の優先順位を決めるための材料を、短時間で一覧にしてくれる機能です。
- 「データ管理」>「データモデル」>「健康」タブで実行します。 スキャンは最大約20分で、完了通知はありません
- 検出は5カテゴリ・16種類です。 推奨アクションは判断の材料であり、充填率だけで消さないことが重要です
- アーカイブの前に、使用法の確認とエクスポートを取ります。 アーカイブ後の復元は90日が期限です
- 却下機能がないため、判断記録を別に持ちます。 次回の点検で同じ議論を繰り返さずに済みます
- 移行の前後と30日ごとに実行します。 設計意図とのずれを早く見つけられます
最初の一歩としては、いま使っているポータルで一度ヘルスチェックを実行し、件数の多いオブジェクト1つについて判断記録を付けるところから始めるのがおすすめです。
自社のデータモデルの整理や、移行前後の点検の進め方を検討したい場合は、HubSpotゴールドパートナーであり、Sync for freee / Sync for Notion の開発元でもあるStartLinkのお問い合わせからご相談ください。現状の整理から設計・定着まで、工程に合わせてご支援します。HubSpot全体の支援内容はHubSpot導入・運用支援のサービスページにもまとめています。