HubSpotの初期設定は、画面の案内に従えば半日で終わります。問題は、その半日で決めた項目のいくつかが、稼働後には実質的に変更できなくなる点です。設定メニューの見た目は同じでも、後から変えられるものと、変えると既存データの整合が崩れるものが混在しています。

私たちがHubSpot導入を支援する際、キックオフ直後に行うのが「不可逆な設定の洗い出し」です。順序を決めずに設定を進めると、後工程で見つかった要件に合わせて最初の設定をやり直すことになり、その時点で既にデータが入っていると手戻りが数週間規模になります。本記事では、どの設定が後から変えにくく、変更しようとしたときに具体的に何が起きるのかを整理します。

なお、各設定の操作手順そのものはHubSpot初期設定解説で扱っています。本記事は手順ではなく、不可逆性と判断順序に軸を置いています。

なぜ「変えられる設定」と「変えてよい設定」は違うのか？

HubSpotの設定は、技術的に変更可能かどうかと、変更して業務が壊れないかどうかが一致しません。管理画面上は変更ボタンが出ていても、変更した瞬間に既存レコードの値・レポートの集計・外部連携の参照先のいずれかが崩れる項目があります。

不可逆な項目を先に洗い出すという進め方自体は、CRM固有の話ではありません。IPA（情報処理推進機構）のユーザのための要件定義ガイドでも、後工程で変更が困難になる事項を上流で確定させる重要性が示されています。

私たちは、設定を3段階に分けて扱っています。第1段階は仕様上変更できないもの、第2段階は変更できるが既存データへの手当てが別途必要なもの、第3段階は自由に変更してよいものです。初期設計のレビューでは、第1段階と第2段階だけを議題にし、第3段階は現場に委ねます。この切り分けをしないと、合意形成に使う時間が設定項目の数だけ膨らみます。

プロパティーの内部名は、なぜ最初に決め切る必要があるのか？

プロパティーの内部名は、HubSpotで最も典型的な不可逆設定です。詳細タブから基本情報は更新できますが、プロパティーのオブジェクトタイプと内部名は編集できません。表示ラベルは後から変えられますが、内部名は変わりません。入力規則やドキュメントの記述を含む編集画面の構成は、プロパティーエディターで確認できます。

内部名が変えられないことの実務的な意味は2つあります。1つは、API連携・インポートのマッピング・カスタムコードがすべて内部名を参照するため、内部名の命名が悪いと連携側のコードの可読性が恒久的に下がること。もう1つは、作り直す場合に新しいプロパティーを作成して値を移す作業が発生し、その間に履歴が分断されることです。内部名の仕様はHubSpot開発者ドキュメントのプロパティーAPIでも確認できます。

フィールドタイプの選択は、どこまでやり直せるのか？

フィールドタイプは内部名と異なり、編集タブから変更できます。ただし、どのタイプからどのタイプへでも自由に変えられるわけではなく、変更時に値の解釈が変わります。複数行または1行のテキストをドロップダウンに変更する場合は、確認用のチェックボックスにチェックを入れてから確定します。

設計段階で押さえておくべき技術的な上限もあります。注目すべきは、上限そのものより「フォームで使えないタイプがある」という制約です。リード獲得フォームで取得したい項目を、フォームで使えないタイプで作ってしまうと、作り直しになります。

プロパティーの一般的な考え方はHubSpotプロパティーとはでも解説しています。

内部名の命名規則は、どう決めればよいのか？

内部名が変えられない以上、命名規則は初回で完成させる必要があります。私たちが使っている型は、接頭辞で出所を示し、続けて対象と内容を英小文字とアンダースコアでつなぐ形です。接頭辞で出所を示すのは、標準プロパティーとカスタムプロパティー、さらに連携アプリが自動生成したプロパティーを、一覧上で判別するためです。

インポート時の列と項目の対応づけも内部名を軸に行うため、命名の質はデータ投入の作業効率に直結します。手順はインポートファイルの作成、API経由の場合はインポートAPIに記載があります。

避けるべきなのは、組織名・システム名・年号を内部名に含めることです。部門再編やシステム更改のたびに意味がずれ、しかも変更できません。業務上の概念を表す語だけで構成してください。プロパティーの保有数には契約に応じた上限があり、使用状況はCRMデータ使用状況の確認に記載された画面で把握できます。

通貨を後から変えると、具体的に何が起きるのか？

通貨設定は「変更できるが手当てが必要」の代表例です。会社通貨は、すべてのアカウントで編集できます。ボタンは押せます。問題はその後です。

会社通貨を更新した場合には、後処理が必要になります。無料ツールのアカウントでは取引の金額プロパティーが自動で換算されないため、既存の取引の値を新しい通貨の正しい金額に更新します。Starter・Professional・Enterpriseで複数通貨を使っている場合、過去に取引で使われていた通貨へ会社通貨を変更したときは、影響を受けるクローズ済み取引の為替レートの値を1に更新します。

つまり、通貨の変更は設定作業ではなく、既存の取引データに対する一括更新作業を伴います。取引件数が数万件ある状態で会社通貨を変えるという判断は、実質的にデータ移行プロジェクトです。初期設定の段階で、海外拠点を含めるのか、将来含める可能性があるのかを確認しておくことをお勧めします。

クローズ済み取引の為替レートは、なぜ後から直せないのか？

クローズ済みの取引では、為替レートの値が設定した為替レート・過去の為替レート・通貨コードの変更・会社通貨の更新に基づいて自動更新されることはなく、クローズ時点で有効だった為替レートに基づいて設定されます。これは会計上は妥当な挙動ですが、設定変更の観点では「過去の取引の金額は後からの設定変更では直らない」ことを意味します。

レポートで為替換算後の金額を扱う場合、この仕様を前提に、移行時のデータに正しいクローズ日と為替レートを持たせておく必要があります。移行後に気づいても、設定からは修正できません。

オブジェクト構成は、どこまでやり直せるのか？

カスタムオブジェクトは作成も削除も可能ですが、作成時に決める項目に不可逆なものが含まれます。主要表示プロパティーの内部名は連携やAPIで使用され、オブジェクトの作成後は編集できません。また、カスタムオブジェクトの名前はHubSpotが定義する既存のオブジェクトと同じにはできず、エラーが出る場合は単数形・複数形の名称を変えます。

より重要な判断は、そもそもカスタムオブジェクトを作るべきかどうかです。標準オブジェクトで表現できるものをカスタムオブジェクトにすると、標準機能（既定のレポート、既定のプロパティー、各種連携の対応範囲）の恩恵を受けられなくなります。この判断基準はHubSpotカスタムオブジェクトの設計判断と作らない基準で整理しています。

保有できるカスタムオブジェクトやカスタムプロパティーの数には契約内容に応じた上限があり、具体的な数はProducts & Services Catalogで確認します。契約を見直す場合は、有料サブスクリプションのダウングレードの影響に記載された、上限を超過した状態になったときの扱いも併せて確認してください。

パイプラインとステージは、なぜ後から削れないのか？

パイプラインとステージの構成は、運用開始後に最も変更要望が出る領域であり、同時に最も削除が難しい領域です。レコードが含まれている場合、または他のHubSpotツールや連携で使用されている場合、パイプラインは削除できません。削除の前に、レコードを削除するか別のパイプラインへ移動し、他のツールからの参照を取り除く必要があります。

ステージの削除も同様です。「使用先」列の数値から、削除をブロックしている参照（ステージ内のレコード、使用中の条件付きプロパティーなど）を確認して取り除きます。稼働から1年が経過したパイプラインでは、この参照の除去だけで相当の作業量になります。

ステージ設計で、初期に決め切るべきことは何か？

名称は後から変更できます。パイプライン名の変更、ステージ名の編集、ステージの並べ替えは、いずれも手順が用意されています。一方で、パイプラインとステージには内部名があり、連携とAPIで使用されます。ステージの内部名を後から変更できるという記載は確認できませんでした。外部システムとステージを連携させる設計では、内部名を前提に組む必要があります。

私たちがステージ設計で初期に固定するのは、ステージの「数」と「意味の粒度」です。数を増やすのは後からでも比較的容易ですが、減らすには該当ステージのレコードをすべて移動させる必要があります。初期は少なめに設計し、運用の中で必要が確認できてから増やす順序をお勧めしています。あわせて、ステージの意味を「営業の行動」ではなく「顧客の状態」で定義しておくと、組織変更や営業プロセスの見直しがあってもステージの再設計が不要になります。

ポータルの言語・タイムゾーン・会計年度は、どこまで波及するのか？

アカウント全体の既定値は、画面上は小さな設定に見えますが、波及範囲が広く、変更すると過去データの見え方が変わります。アカウントアクセス権限を持つユーザーは、既定の地域・言語設定からタイムゾーン・言語・通貨・日付と数値の形式をカスタマイズできます。

アカウントのタイムゾーン設定は、スケジュール送信されるメールの送信時刻、ソーシャルメディアの予約投稿、アナリティクスの日時情報などを現地化します。一方で、HubSpotの一部の要素はHubSpotで設定したタイムゾーンではなくコンピューターのタイムゾーンを使用します。対象は、記録された営業活動のタイムスタンプ、レコードのタイムライン、プロパティー履歴です。海外拠点を含む組織では、この差を理解していないとレポートと画面表示の食い違いを不具合として報告されることになります。

タイムゾーンが未設定だと、何が起きるのか？

タイムゾーンの未設定は、自動化の挙動に直接影響します。HubSpotアカウントにタイムゾーンが設定されていない場合、ワークフローのタイミング設定は既定でEST（東部標準時）になります。営業時間内にのみアクションを実行する設定を入れたのに深夜に動く、という事象の原因がここにあります。

この設定は後から変更できますが、変更前に実行された処理の時刻は遡って直りません。初期設定の段階で、アカウントのタイムゾーンを明示的に設定してください。

言語設定で、翻訳されないものは何か？

既定言語の設定はHubSpotインターフェイスの既定言語を変えるもので、カスタムプロパティーは翻訳されません。多言語で利用する組織では、カスタムプロパティーのラベルをどの言語で作るかを初期に決める必要があります。

電話サポートは英語のみで提供され、コールバック・メール・チャットのサポートは英語・フランス語・ドイツ語・日本語・ポルトガル語・スペイン語で利用できます。サポート体制を前提にした運用設計を行う場合、ユーザーの言語設定がサポート言語に影響する点も確認しておいてください。

会計年度の設定は、いつ行うべきか？

会計年度は、レポートの集計区分に影響します。既定ではアカウントの会計年度は1月から12月に設定されており、アカウントのデフォルト設定から変更できます。4月開始の日本企業では、既定のままだと四半期の区切りがずれます。

この設定は後から変更できますが、保存済みのレポートやダッシュボードを既に多数作成した後に変更すると、全レポートの集計区分が変わります。レポートを作り込む前の段階で設定してください。レポートの設計そのものはHubSpotのレポートとダッシュボードで解説しています。

メール送信ドメインは、なぜ後から変えにくいのか？

メール送信ドメインは、技術的には変更できますが、変更が社外に見える点で性質が異なります。顧客から見れば、差出人のドメインが変わるという事実が残ります。加えて、他の用途（ウェブサイトのホスティングなど）で現在使用されているメール送信ドメインは認証できません。コーポレートサイトで使っているドメインをそのまま送信ドメインにする構成は取れません。

info.domain.com のようなサブドメインを送信ドメインとして接続でき、接続するサブドメインは送信元メールアドレスのドメインと一致している必要があります。送信元アドレスを後から変える場合、このサブドメインの設計も連動して変わります。

設定作業そのものにも時間がかかります。接続の過程ではMX・DKIM・SPF・DMARCの4種類のDNSレコードを設定し、DKIMは2つのCNAMEレコード、SPFとDMARCはそれぞれTXTレコードを必要とします。DNSレコードの反映には通常10分から70分、場合によっては48時間かかることがあります。既存のSPFレコードがある場合は、新規に作成するのではなく既存のレコードにHubSpotを追加し、SPFのバージョンと -all フラグが1回だけになるよう確認します。この作業は社内のDNS管理部門との調整を伴うため、プロジェクトの初期にリードタイムを確保してください。

レコードのマージと削除は、どこまで戻せるのか？

設定ではありませんが、初期のデータ投入時に実行されやすく、かつ取り返しがつかない操作として、マージを挙げておきます。マージは取り消しできず、累計250回以上マージされたレコードはそれ以上マージできません。マージ後は新しいレコードIDが発行され、旧IDは「Merged record IDs」に退避し、作成日は最も古いものが保持されます。

外部システムがHubSpotのレコードIDを保持している構成では、マージによって参照が切れます。重複の解消を急ぐ前に、レコードの重複排除で検知の仕組みを確認し、マージの実行順序と対象を設計してから着手してください。

削除については復旧の余地があります。削除から90日以内はごみ箱から復元でき、ワークフロー・インポート・手動編集による更新は直近14日以内の時点に巻き戻せます。一方、完全削除やプライバシー要求による削除はごみ箱に保存されません。データ保持の運用方針はデータ保持ポリシー設定の管理とあわせて設計してください。

初期設定で決め切るべき項目は、どう順序づけるのか？

不可逆性の高い項目から順に決めるのが原則ですが、実務では依存関係があるため、単純な降順では進みません。たとえばプロパティーの内部名は、オブジェクト構成が決まらないと命名できません。以下は、私たちが初期設計のレビューで使っている順序です。上から順に確定させると、手戻りがほぼ発生しません。

権限設計は不可逆ではありませんが、7番に置いているのは、オブジェクトとパイプラインが決まらないと権限の対象が定まらないためです。権限の考え方はユーザー権限ガイド、権限セットの作成手順は権限セットの作成と割り当て、アセット単位の制限はアセットへのアクセス制限、実務上の注意点はHubSpot権限とはを参照してください。設定変更の記録を残すにはアカウントのアクティビティー履歴の表示とエクスポートが使えます。

よくある質問（FAQ）

プロパティーの内部名を間違えました。どう対処すればよいですか？

内部名の編集はできないため、新しいプロパティーを正しい内部名で作成し、値を移したうえで旧プロパティーを使用停止にする流れになります。値の移行にはワークフローまたはインポートを使います。旧プロパティーを参照しているワークフロー、レポート、連携をすべて洗い出してから着手してください。

表示ラベルだけ変えれば、内部名が古いままでも問題ありませんか？

画面上の運用に限れば問題ありません。ただし、API連携やカスタムコードを読む担当者は内部名を見ます。内部名と表示ラベルが乖離していると、連携の保守コストが恒常的に上がります。乖離が生じた場合は、設計書に対応表を残してください。

会社通貨を変更する場合、どの順序で作業すべきですか？

先に既存取引の件数と、クローズ済みと進行中の内訳を確定させてください。会社通貨の更新後は、無料ツールのアカウントでは取引の金額を手動で更新する必要があり、複数通貨を使うアカウントでは影響を受けるクローズ済み取引の為替レートを1に更新する必要があります。対象件数が分からない状態で設定を変更すると、作業量の見積もりができません。

パイプラインのステージを減らしたいのですが、どう進めればよいですか？

該当ステージのレコードを別のステージへ移動し、条件付きプロパティーなどの参照を取り除いてから削除します。手順としては、「使用先」の列から削除をブロックしている参照を確認して取り除きます。レコードの移動はステージ履歴に残るため、移動の理由を記録に残しておくと、後のレポート分析で混乱を避けられます。

サンドボックスで試してから本番に反映すれば、不可逆な設定も安全ですか？

設定の妥当性は確認できますが、不可逆性そのものは解消されません。サンドボックスで作ったプロパティーの内部名をそのまま本番に持ち込めば、本番でも内部名は変更できません。サンドボックスは「決め切るための検証の場」であって、「やり直せる本番」ではないという位置づけで使ってください。サンドボックスの提供条件と制約はサンドボックスの作成と本番環境への反映で確認できます。

メール送信ドメインは、複数のHubSpotアカウントで共有できますか？

メール送信ドメインは、複数のHubSpotアカウントに同時に接続できます。グループ会社で複数ポータルを運用する場合の選択肢になります。ただし、送信元アドレスのドメインと接続するサブドメインの一致が求められる点は変わらないため、ポータルごとの送信元設計は個別に整理してください。

タイムゾーンを変更すると、過去のレポートの数字は変わりますか？

アカウントのタイムゾーン設定は、アナリティクスの日時情報を現地化します。一方で、記録された営業活動のタイムスタンプ、レコードのタイムライン、プロパティー履歴にはコンピューターのタイムゾーンが使われます。変更の影響範囲は一様ではないため、変更前に主要レポートの数値を控え、変更後に差分を確認する手順をお勧めします。

初期設定をやり直すために、ポータルを作り直すのは現実的ですか？

稼働前であれば選択肢になりますが、稼働後は現実的ではありません。レコードの移行だけでなく、連携の再接続、送信ドメインの再認証、ユーザーの再設定が発生します。稼働後に大きな設計変更が必要になった場合は、ポータルの作り直しではなく、既存ポータル内での段階的な再設計を検討してください。

不可逆な設定の洗い出しから支援が必要な場合

株式会社100は、HubSpotの認定エリートパートナーとして、大手企業の導入初期における設定の順序設計と、稼働後の設計見直しを支援しています。初期設定のレビューのみ、命名規則の設計のみといった部分的なご相談もお受けしています。お問い合わせよりご連絡ください。