HubSpotの初期構築で後から変えにくいのは、プロパティの内部名、カスタムオブジェクトの内部名、関連付けラベルの内部名のように「作成後は編集できない」と公式ナレッジに明記された項目と、通貨・タイムゾーン・フィールドタイプのように「変更はできるが、既存のデータへの影響を見ておく必要がある」項目、ライフサイクルステージのように「前の値へ戻すときに条件がある」項目です。 画面から変更できるものの多くは、あとからでも直せます。直せないものだけを先に見極めて、そこに設計の時間を集中させるのが、手戻りを減らす最短の進め方です。
「とりあえず作って、あとで直せばよい」という進め方は、HubSpotの設定の大半には当てはまります。ただし、直せない項目を取り違えたまま本番運用に入ると、連携やレポートを巻き込んだ作り直しになります——どの設定が直せて、どの設定が直せないのか。
この記事でわかることは次のとおりです。
- 公式ナレッジで確認できた「変更できない/制約がある」設定の一覧 ── 確認できなかった項目は載せていません
- 設定ごとの判断表 ── 決める前に確認すること、決め切れないときの暫定方針
- StartLinkの設計工程での決め方 ── 現状整理から定着まで、どの段階で何を確定させるか
- 失敗しやすい箇所と回避策 ── 内部名・通貨・パイプライン・ラベルの具体例
「後から変えにくい」を公式ナレッジの記載で線引きする
最初に、この記事の前提を明確にしておきます。「後から変えにくい」という言葉は、人によって指すものが違います。作業が面倒なものも、データが壊れるものも、すべて「変えにくい」と呼ばれがちです。そこで、この記事ではHubSpotの公式ナレッジに記載がある項目だけを対象にします。
3つの種類に分けて考える
公式ナレッジの記載を読み分けると、制約は次の3種類に整理できます。
| 種類 |
意味 |
該当する設定 |
| 作成後は編集できない |
作ったあとに画面から変更する手段がない |
プロパティの内部名、カスタムオブジェクトの内部名、関連付けラベルの内部名 |
| 変更はできるが、既存データへの影響を見る |
設定は変えられるが、既存の値や取引の扱いを別に確認する |
通貨、プロパティのフィールドタイプ、タイムゾーン |
| 削除・巻き戻しに条件がある |
使用中のものは削除できず、削除すると復元できないものもある。ライフサイクルステージは前の値へ戻す手段に条件がある |
カスタムオブジェクト、パイプライン、関連付けラベル、ライフサイクルステージ |
この区別が大切なのは、対処が違うからです。1つ目は作る前に決め切るしかありません。2つ目は変更の手順と既存データの確認をセットで設計します。3つ目は、使い始める前に「将来、削除や巻き戻しをする可能性があるか」を見ておきます。
本記事で扱わないもの
公式ナレッジで制約を確認できなかった設定は、載せていません。たとえば、プロパティの削除(アーカイブ)に関する制約は、プロパティ編集の公式ページには記載がなく、「レコードやワークフローなどで使用されているプロパティーは編集できない場合がある」という趣旨の記述にとどまります。確認できない内容を断定すると、読者の判断を誤らせるためです。
「変えられない」と言い切れる設定は、思ったより少数です。少数だからこそ、構築の最初に確定させる項目として一覧にしておくと、判断が速くなります。
内部名は作成後に変えられない:プロパティ・オブジェクト・ラベル
公式ナレッジで最も明確に「編集できない」と書かれているのが内部名です。内部名は、APIや連携、ワークフローの内部処理で使われる識別子で、画面に表示される名前(ラベル)とは別のものです。
プロパティの内部名とオブジェクトタイプ
プロパティを編集する公式ページには、「プロパティーのオブジェクトタイプまたは内部名は編集できません」と記載されています。ラベルは後から直せますが、内部名は作成時に決まった値のままです。連携ツールやレポート、ワークフローがその内部名を参照している場合、あとから「名前がおかしい」と気づいても、内部名だけを直す方法はありません。
設計の実務では、プロパティを作る前に命名規則を決めます。たとえば、用途の接頭辞、英数字の小文字とアンダースコア、日付なら末尾に _date を付ける、といった規則です。命名の考え方はHubSpotプロパティ設計と命名規則、データ型の選び方にまとめています。

カスタムオブジェクトと関連付けラベルの内部名
カスタムオブジェクトの内部名も同様です。公式ナレッジには、作成時に編集アイコンから内部名を変更できるものの、「作成後は変更できません」と記載されています。一方で、オブジェクトの名前(単数形・複数形)と説明は作成後も編集できます。連携やAPIでは内部名を使うため、ラベルが変わっても連携は壊れませんが、内部名の付け間違いは残り続けます。
関連付けラベルも、内部名は作成時に設定し、作成後は変更できません。表示名は後から編集できます。同じ構造を持つ3つの設定ですから、「ラベルは直せる、内部名は直せない」と一括で覚えておくと整理しやすくなります。
フィールドタイプ・通貨・タイムゾーンは変えられるが、既存データへの影響を見ておく
次に、変更自体はできるものの、既存のデータへの影響を見ておくべき設定です。「変えられる」ことと「変えても困らない」ことは別です。
プロパティのフィールドタイプ変更
公式ナレッジでは、フィールドタイプの変更について次のように説明されています。
| 変更の内容 |
公式ナレッジの記載 |
| スコアまたは計算への変更、およびスコア・計算から別タイプへの変更 |
できません |
| 1行テキスト・複数行テキストからドロップダウン系(チェックボックス、ラジオ、ドロップダウン)への変更 |
できます。一意のテキスト値ごとにオプションが作られ、大文字小文字が違う値は別のオプションになります |
| 変更後の既存値 |
保存済みの値が「無効」になることがあります。変更前のエクスポートが推奨されています |
つまり、自由入力のテキストを後からドロップダウンに変える運用は可能ですが、「LinkedIn」と「linkedin」が別の選択肢として生成されます。選択肢を整理したいなら、変更後にオプションを統合する作業が発生します。最初から選択式で作るほうが、手戻りは小さくなります。変更の反映には、アカウント全体で最大30分ほどかかる場合がある点も、公式ナレッジに記載があります。
会社の通貨と複数通貨
会社の通貨は、公式ナレッジによると、すべてのアカウントで編集できます。ただし、公式には更新後に確認する値が示されています。無料ツールを利用しているアカウントでは、会社通貨を変更しても取引の「金額」プロパティーは自動換算されないため、既存の取引の値を新しい通貨の正しい金額に更新する必要があります。Starter、Professional、Enterpriseの複数通貨対応アカウントでは、会社通貨を取引で以前に使用された通貨に更新した場合、影響を受けるクローズ済み取引の「為替レート」の値を「1」に更新するよう案内されています。
通貨をアーカイブした場合は、新規取引で選べなくなりますが、既存取引では引き続き使われます。複数通貨を使う可能性が少しでもあるなら、運用開始前に会社通貨と通貨の一覧を確定させ、為替レートの管理方法まで決めておくのが安全です。詳しくはHubSpot多通貨対応とグローバル展開で解説しています。
タイムゾーン
アカウントのタイムゾーンは、「設定」の「アカウントの既定値」にある「一般」タブから変更できます。公式ナレッジには、変更時に確認ダイアログが出ることのほか、次の注意が記載されています。メールの送信予約やソーシャル投稿のスケジュール、アナリティクスの日時はアカウントのタイムゾーンに従う一方、記録されたセールスアクティビティー、レコードタイムライン、プロパティー履歴のタイムスタンプは、使っているコンピューターのタイムゾーンを参照します。

複数拠点で使う場合、画面ごとに時刻の基準が違うことを前提に、レポートの集計時刻や自動化の起動時刻を設計する必要があります。
オブジェクト・パイプライン・ライフサイクルは「削除と巻き戻し」に条件がある
3つ目は、作ったあとに削除する、または状態を巻き戻すときに条件が付く設定です。
カスタムオブジェクトの定義
カスタムオブジェクトは、対象プランがEnterpriseであること、作成できる数に契約上の上限があること、既存のHubSpot定義のオブジェクトと同名にできないことが公式ナレッジに記載されています。削除については、確認のチェックボックスで「削除後は復元できない」ことを確認する必要があり、他のツールで使われているオブジェクトは削除できません。ワークフローや計算プロパティ、残っている関連付け、関連付けラベルが削除をブロックします。
設計の判断は、「標準オブジェクトで足りないか」を先に見ることです。足りない場合のみカスタムオブジェクトを作ります。判断の観点はHubSpotカスタムオブジェクトの設計判断で整理しています。
パイプラインとステージ
パイプラインについては、レコードが含まれるパイプライン、または他のHubSpotツールや連携で使われているパイプラインは削除できません。ステージの削除も、ステージ内のレコードや使用中の条件付きプロパティなどの参照が妨げになります。公式ナレッジは、「使用箇所」の列から削除を妨げている参照を確認できると説明しています。
取引ステージには受注確度が設定され、ボードの加重金額は「ステージの合計金額×確度」で計算されます。また、売上のレポートや分析が正しく動くよう、「成約」と「失注」のステージを必ず含めるよう案内されています。ステージの区切り方は集計に直結するため、設計の初期に営業プロセスと突き合わせて決めます。考え方はHubSpotパイプライン設計ガイドにあります。

関連付けラベルとライフサイクルステージ
関連付けラベルは、削除すると元に戻せず、レコードや他のツールで使われている場合は先にそれらから外す必要があります。作成できる数は、オブジェクトペアごとに最大50個です。独自のラベルの作成には、ProfessionalまたはEnterpriseが必要です。
ライフサイクルステージは、前の段階へ戻すときの手段によって扱いが分かれます。公式ナレッジによると、画面から手動で前の値に設定することはでき、その場合は後ろのステージに対応する「〜になった日付」プロパティーがクリアされます。一方、インポート、フォーム送信、API、Salesforce連携、ワークフローなどで順序上より前の値を設定するには、先に手動またはワークフローで値を一時的に削除する必要があります。ステージの意味を曖昧にしたまま運用を始めると、あとから定義を揃え直す際にこの扱いが影響します。定義の考え方はHubSpotライフサイクルステージ設計と自動化の手順をご覧ください。

設定ごとの判断表:決める前に確認すること
ここまでの内容を、初期構築の場面で使える判断表にまとめます。「決める前に確認すること」を関係者に問いかけ、答えが出ないものは暫定方針で進めます。
| 設定 |
決める前に確認すること |
決め切れないときの暫定方針 |
| プロパティの内部名 |
連携ツール・レポート・ワークフローで参照するか。命名規則はあるか |
命名規則を先に文書化し、迷うものは作らない |
| フィールドタイプ |
値を集計・絞り込みに使うか。選択肢は固定できるか |
集計に使う項目は最初から選択式・日付・数値で作る |
| 会社の通貨・複数通貨 |
海外取引や外貨建ての見込みはあるか。為替レートを誰が管理するか |
外貨の可能性があれば、運用開始前に通貨を登録する |
| タイムゾーン |
拠点は複数か。自動化の起動時刻に依存する業務はあるか |
拠点の基準を1つ決め、画面差を運用手順に書く |
| カスタムオブジェクト |
標準オブジェクトで表現できないか。Enterpriseの契約はあるか |
標準オブジェクトで開始し、不足が確定してから作る |
| パイプラインとステージ |
営業プロセスは言語化されているか。成約・失注の定義は合意済みか |
ステージを少なめに始め、運用で増やす |
| 関連付けラベル |
1つの会社に複数の窓口があるか。ラベルは何種類必要か |
必要最小限のラベルから始め、内部名は慎重に付ける |
| ライフサイクルステージ |
各ステージの入口条件は定義できるか。前の値へ戻す運用はあるか |
定義を一枚にまとめ、自動化の前に関係者で合意する |
導入全体で起きやすい失敗の型はHubSpot導入の失敗パターンと回避策が網羅しており、本記事はそのうち「作ってから直せない設定」に絞った判断表です。プラン選定や移行の進め方はHubSpot料金と導入ガイド、製品全体の機能の見取り図はHubSpot完全ガイドに整理しています。
内部名と命名の決め方を手順にする
内部名のように作成後に変えられない設定は、作業の順序で手戻りを抑えられます。次の手順で進めます。
- 連携する外部ツールと、参照するレポート・ワークフローの一覧を作る
- プロパティの命名規則(接頭辞、英数字の使い方、型ごとの接尾辞)を一枚に書く
- 既存システムの項目名と、HubSpot側の内部名の対応表を作る
- 対応表の内部名を、関係者がレビューする。曖昧な項目は作成を保留する
- 検証用の環境、または少数のテスト項目で作成し、連携・レポートで参照できることを確認する
- 本番で作成し、作成した内部名を設計書へ書き戻す
6番を忘れると、設計書と実機が食い違います。作った内部名は設計書に戻しておくと、移行や連携の担当者が同じ名前で作業できます。
StartLinkの設計工程での決め方
StartLinkは、HubSpotの導入を「現状の整理・要件定義」「設計・構築」「データ移行」「テスト・検証」「定着・運用改善」の工程で進めます。後から変えにくい設定は、この工程のなかで確定させる時期が決まっています。企業様によって最適な形は異なりますので、以下は一般的な進め方として示します。
現状整理・要件定義で「決める項目」を洗い出す
要件定義の段階では、画面を作る前に、前述の判断表の質問を関係者に確認します。外貨取引の有無、連携予定のツール、営業プロセスの区切り、窓口の種類。ここで答えが揃わない項目は「保留項目」として一覧に残し、設計の段階で扱いを決めます。スモールスタートで始めて広げる考え方に立つと、保留したままで構築を進められる項目と、構築前に確定すべき項目が見分けられます。
設計・構築で内部名と定義を確定する
設計・構築の段階で、内部名の対応表、パイプラインのステージ定義、関連付けラベルの一覧、ライフサイクルステージの定義を設計書にまとめます。構築は、この設計書を正として進めます。設計書は準委任の伴走で関係者と読み合わせ、合意した状態で本番へ反映します。標準的な導入の進め方はHubSpot初期設定・オンボーディング完全マニュアルに手順があります。
データ移行とテストで「直せない箇所」から検証する
データ移行では、内部名やフィールドタイプが移行元の項目と対応しているかを先に検証します。テスト・検証の工程でも、直せない項目から順に確認します。定着・運用改善の工程では、運用して見えてきた不足を、直せる設定の範囲で調整します。
よくある質問
Q1. プロパティの内部名を間違えて作ってしまった場合はどうすればよいですか
公式ナレッジでは、内部名は編集できないと記載されています。ラベルは変更できるため、画面上の表示は直せます。内部名そのものを揃えたい場合は、正しい内部名で新しいプロパティを作り、値を移して参照先を切り替える作業になります。移行前に、そのプロパティを使っているワークフロー・レポート・連携を洗い出しておくことが前提です。
Q2. 会社の通貨は、導入後に変更できますか
公式ナレッジでは、すべてのアカウントで会社の通貨を編集できます。ただし、無料ツールを利用しているアカウントでは取引の「金額」が自動換算されないため既存の取引の値を更新する必要があり、複数通貨対応のアカウントで会社通貨を取引で以前に使用された通貨に更新した場合は、影響を受けるクローズ済み取引の為替レートを1に更新するよう案内されています。外貨取引の可能性があるなら、変更を前提にせず、運用開始前に確定させるほうが安全です。
Q3. カスタムオブジェクトは、最初に作っておいたほうがよいですか
標準オブジェクトで表現できるかを先に確認し、足りないと確定してから作るのが基本です。公式ナレッジでは、内部名が作成後に変更できず、削除には条件があり、Enterpriseが対象です。使い方が見えないまま作ると、削除や作り直しの負担が残ります。
Q4. パイプラインのステージは、あとから増やしたり減らしたりできますか
ステージ名の変更や追加は画面から行えます。ステージの削除は、ステージ内のレコードや条件付きプロパティなどの参照が残っていると行えません。減らす可能性がある場合は、先にレコードの移動や参照の解消が必要になるため、最初から細かく区切りすぎないほうが運用は楽になります。
Q5. ライフサイクルステージを間違えて進めてしまったとき、戻せますか
戻し方によって条件が違います。公式ナレッジによると、画面から手動で前の値に設定することはでき、その場合は後ろのステージの「〜になった日付」プロパティーがクリアされます。インポート・フォーム送信・API・Salesforce連携・ワークフローで前の値にしたい場合は、先に手動またはワークフローで値を一時的に削除する必要があります。履歴を集計に使っている場合は、戻す前に影響を確認してください。
まとめ:変えられない項目を先に確定させる
後から変えにくい設定は、整理すると数が限られます。要点は次のとおりです。
- 内部名は作成後に変更できません。 プロパティ・カスタムオブジェクト・関連付けラベルの3つで共通です
- 通貨・フィールドタイプ・タイムゾーンは、変更できても既存データへの影響を確認する必要があります。 公式に示された補正(取引金額・為替レートの更新、既存値の無効化への備え)を変更手順とセットで設計します
- オブジェクト・パイプライン・ラベルは、削除に条件があります。 使用中のものは削除できず、削除後に復元できないものもあります。ライフサイクルステージは、前の値へ戻す方法によって条件が変わります
- 決め切れない項目は、暫定方針で進めます。 判断表の「暫定方針」の列を使います
最初の一歩は、プロパティの命名規則を一枚に書き出し、関係者で読み合わせることです。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
出典・参考