%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
日本の顧客データは、姓・名を分け、フリガナと都道府県は専用プロパティで持ち、敬称は差し込み側で扱うと崩れにくくなります。入力経路ごとの設計を整理します。
HubSpotで日本の顧客データを扱うときは、「姓と名は別のプロパティで持つ」「フリガナは専用のカスタムプロパティを足す」「都道府県は入力経路ごとに選択肢の持ち方を決める」「敬称はレコードに持たせず差し込み側で付ける」の4点を先に決めます。 既定のコンタクトプロパティには「名」「姓」が用意されていますが、フリガナと日本の都道府県に対応する専用の項目は公式ナレッジの既定プロパティ一覧には載っていません。足りない部分は、カスタムプロパティと入力ルールで設計することになります。
データは入力した時点では整っているように見えて、あとからインポート、フォーム、手入力が混ざると崩れます——「東京」と「東京都」が別の値になる、フリガナの欄にひらがなと半角カナが混在する、といった形で表面化します。
この記事でわかること
- 日本の顧客データで追加する項目の決め方：既定プロパティで足りるものと、カスタムで足すものの切り分け
- 姓・名・フリガナの持ち方：表示順を差し込み側で決める考え方と、フリガナの入力ルール
- 都道府県の選択肢化：単行テキストからドロップダウンへ変える手順と、表記ゆれの扱い
- 敬称を持たせない判断：レコードに持たせる場合と持たせない場合の使い分け
- 入力経路別の設計：インポート・フォーム・ワークフローで、値の一致条件がどう違うか
日本のデータで足りない項目を洗い出す
最初に、既定のプロパティで足りる項目と、足りない項目を切り分けます。公式ナレッジのHubSpotの既定のコンタクトプロパティ（HubSpotナレッジベース）には、First name、Last name、State/Region、Postal code、City、Street address、Country/Region、Job title、Salutation などが載っています。一方で、フリガナや姓名の表示順、敬称の使い分けに対応する項目は載っていません。
この切り分けを先に行う理由は、あとから足した項目ほど入力経路が増えて整理が難しくなるためです。新しいカスタムプロパティを足す前に、既定のプロパティで代用できないかを確かめます。
| 項目 | 既定プロパティ | 設計の方向 |
|---|---|---|
| 名・姓 | あり（名、姓） | そのまま使う。氏名を1欄にまとめない |
| フリガナ | なし | 姓用・名用のカスタムプロパティを足す |
| 都道府県 | State/Region（英語版の表記）あり | 既定を使うか、選択肢用のカスタムを足すかを入力経路で決める |
| 郵便番号・市区町村・番地 | Postal code、City、Street address | 既定を使い、郵便番号には入力ルールを付ける |
| 敬称 | Salutation あり | 使うかどうかを、宛名の出し方から逆算して決める |
既定のプロパティで足りる項目は、足さずにそのまま使います。カスタムプロパティは、入力経路が増えるたびに管理の負担が増えるためです。
プロパティ設計の全体の考え方は、HubSpotプロパティ設計と命名規則、データ型の選び方で扱っています。この記事は、日本語のデータに特有の4項目に絞った内容です。
姓と名は分けて持ち、表示順は差し込み側で決める
日本語の氏名は、姓が先、名が後に並びます。HubSpotのコンタクトには「名」「姓」が別のプロパティとして用意されているため、氏名を1つの欄にまとめて入れるのではなく、姓と名を分けて入れます。分けておくと、あとから宛名や差し込みの並びを変えられます。
姓名を1欄に入れてしまうと、並び順を変えたいとき、あるいは姓だけで呼びかけたいときに、文字列を分解し直す作業が発生します。分けて持つことは、後から変更する余地を残すことと同じです。
差し込みで並びを決める
メールや書類に氏名を出すときの並びは、パーソナライズトークンの並べ方で決まります。公式ナレッジのパーソナライズトークンの使用（HubSpotナレッジベース）によれば、エディターで［パーソナライズ］を選び、［タイプ］でカテゴリーを選んだうえで、［トークン］でプロパティを選びます。トークンで選べる項目は、実際のエディターの［タイプ］［トークン］で確認します。
日本語のメールでは、姓のトークンを先に、名のトークンを後に並べます。宛名として「姓」のトークンだけを使い、あとに敬称を本文側で書く、という使い方もできます。この並べ方を決めるのはテンプレートの作り手であり、プロパティの側ではありません。
空欄のときの表示を決めておく
トークンには予備の値を入力できます。公式ナレッジでは、コンタクトにそのプロパティの値がない場合に予備の値が使われ、設定していないと空白のままになると案内されています。姓が空欄のコンタクトに「様」だけが残ると、受け手に不自然な印象を与えます。
そのため、宛名のトークンには、空欄のときの予備の値を必ず設定します。たとえば、予備の値を「お客」のような汎用の呼びかけにしておく、といった形です。予備の値はメールごとに入力するため、宛名のトークンを使うテンプレートには、あらかじめ予備の値を入れた状態で雛形を作っておくと抜けが出ません。
フリガナ用のカスタムプロパティを足す
フリガナは、既定のプロパティにありません。足すときは、姓のフリガナと名のフリガナを別々のカスタムプロパティとして作ります。氏名と同じく、分けて持つことで、並びを変えたい場面や、姓だけを読み上げたい場面に対応できます。
作成は、設定アイコンから［プロパティー］を開き、［オブジェクトを選択］でコンタクトを選び、［プロパティーを作成］から行います。公式ナレッジのプロパティーを作成して編集（HubSpotナレッジベース）では、［プロパティーラベル］を入力し、［フィールドタイプ］を選んで［プロパティーを作成］を押す流れが案内されています。
作成の手順は次のとおりです。
- 設定アイコンから［プロパティー］を開き、［オブジェクトを選択］でコンタクトを選びます
- ［プロパティーを作成］を押し、［プロパティーラベル］に「姓（フリガナ）」と入力します
- ［フィールドタイプ］で単行テキストを選び、［プロパティーを作成］を押します
- 作成したプロパティの名前をクリックし、［ルール］タブで入力ルールをオンにして保存します
- 名のフリガナも同じ手順で作り、テスト用のコンタクト1件で入力と表示を確かめます
フリガナのプロパティの設計例
| 設計項目 | 設計の例 | 理由 |
|---|---|---|
| ラベル | 姓（フリガナ）、名（フリガナ） | 画面で、姓・名の隣に並べたときに意味が通じる |
| フィールドタイプ | 単行テキスト | フリガナは1行の短い文字列のため |
| グループ | 既存のコンタクト情報とは別の、氏名まわり用のグループ | 一覧で探しやすくする |
| 入力ルール | 先頭と末尾のスペースを許可しない。必要なら正規表現で全角カタカナに限定する | 全角・半角、ひらがな・カタカナの混在を防ぐ |
作成時のラベルは変更できますが、プロパティの内部名は、公式ナレッジに「編集できません」と明記されています。連携やAPIで使う名前になるため、作成前に英字の内部名をチームで決めておきます。
入力ルールで表記をそろえる
フリガナの表記ゆれは、ルールで防げます。公式ナレッジのプロパティーの検証ルールを設定する（HubSpotナレッジベース）では、単行テキストに対し、「先頭と末尾のスペースを許可しない」「スペースを許可しない」「最小文字数」「最大文字数」などのルールが使えると案内されています。標準のルールは全製品・全プランが対象です。
ひらがなやカタカナの種類を限定するには、正規表現による「カスタムルールを使用した検証」を使います。この方法は、公式ナレッジでProfessionalまたはEnterpriseが必要とされています。たとえば、全角カタカナと長音記号だけを許可する正規表現を設定します。式の書き方は設定前に検証用の値で試してください。
ルールは、CRMの画面からの入力とインポートの両方に適用されます。ただし、すでに入っている値が遡って書式変更されることはありません。既存データの整理は、別途の作業として計画します。ワークフローからの更新にはルールが適用されない点も、公式ナレッジに記載があります。検証ルールの種類ごとの設定手順と、一意の値で重複を防ぐ方法は、HubSpotのプロパティの入力規則で整理しています。
都道府県は入力経路ごとに持ち方を決める
都道府県は、既定のState/Regionで足りる場合と、選択肢を持つカスタムプロパティを足したほうがよい場合があります。判断の軸は、データがどの経路から入るか、集計や絞り込みで正確な値が必要か、の2点です。
選択肢にする最大の利点は、表記が47個の選択肢に固定されることです。レポートやセグメントで「東京都」と「東京」が別々に数えられる問題が、入口で防げます。一方で、選択肢にすると、インポートやAPIから入る値も選択肢と一致する必要が出てきます。
| 判断の軸 | 単行テキストのまま | ドロップダウン選択にする |
|---|---|---|
| 表記ゆれ | 入力者次第で発生する | 選択肢に固定され発生しない |
| インポート | 値の制限がない | ラベルまたは内部値との一致が必要 |
| フォーム | 自由入力になる | 選択式にでき、入力の手間も減る |
| 向いている場面 | 住所を文字列として控えるだけのとき | 地域別の集計・セグメント・担当の振り分けをするとき |
すでに溜まった値は、変換せず新しいプロパティで試す
すでに単行テキストの値が溜まっている場合、フィールドタイプをドロップダウン選択へ変える方法と、新しいドロップダウンのプロパティを作る方法があります。公式ナレッジのプロパティーを作成して編集（HubSpotナレッジベース）には、単行テキストなどからドロップダウンへ変更できる旨の記載がありますが、型の変更は既存の値に影響し得るため、本番のプロパティでいきなり行うのは避けます。
安全な進め方は、新しいドロップダウンのプロパティを作り、少数のコンタクトで入力と絞り込みを試してから、既存データの移し方を決めることです。表記ゆれ（たとえば「東京」と「東京都」）が実際に何通りあるかは、設計前にエクスポートした一覧で数えておきます。型の変更を行う場合も、事前にバックアップを取り、小さな見本で動きを確かめます。
選択肢の統合は［マージ］で行う
選択肢の統合は、設定アイコンの［プロパティー］から対象のプロパティにポインターを合わせて［編集］を選び、［フィールドタイプ］タブで行います。公式ナレッジの列挙プロパティーのオプションの管理（HubSpotナレッジベース）では、［マージ］で複数のオプションを1つにまとめられ、統合元の値を持つレコードは統合先の値に更新されると案内されています。ただし、セグメント、ワークフロー、フィルターは自動では更新されないため、手動での更新が必要です。
内部値は保存後に変えられない
選択肢には「ラベル」と「内部値」があります。ラベルは画面に表示される名前、内部値はシステムが保存する値で、新規作成時は既定でラベルと同じになります。公式ナレッジでは、内部値は保存後に変更できないと案内されています。
都道府県の選択肢を作るときは、内部値を「東京都」のように日本語のラベルと同じにするか、連携先とそろえた英字や番号にするかを、保存前に決めます。のちに連携を足す可能性があるなら、連携先の持つコードに合わせておくと、あとで値の対応表を作らずに済みます。
敬称はレコードに持たせず、差し込み側で付ける
既定のコンタクトプロパティには、Salutation（宛名に使う称号）があります。日本の顧客データで敬称を持たせるかどうかは、宛名をどう出すかから逆算して決めます。多くの場合、「様」はテンプレート側の本文に書くほうが管理しやすくなります。
レコードに敬称を持たせると、コンタクトごとに「様」「殿」「先生」などを入力・維持する作業が発生します。大半のコンタクトが「様」であれば、レコード側の項目は空欄が大半になり、入力されている少数のデータだけが、更新されないまま古くなります。
| 判断 | レコードに持たせない | レコードに持たせる |
|---|---|---|
| 宛名の出し方 | 全員に同じ敬称を、テンプレートの本文で付ける | 相手によって敬称を変える必要がある |
| 運用の負担 | 入力・更新の作業が発生しない | 入力と、変更時の更新が必要 |
| 差し込みの形 | 姓のトークンに本文の敬称を続ける | 敬称のトークンを姓のトークンに続ける |
| 向いている場面 | 一斉配信が中心のとき | 医療・教育・士業など、呼称を使い分ける相手が多いとき |
持たせる場合はドロップダウンにする
敬称を持たせる場合は、自由入力ではなくドロップダウン選択にします。選択肢が限られているため、前節の都道府県と同じく、表記ゆれを入口で防げるためです。選択肢の数は少ないので、運用の負担も大きくありません。
敬称が空欄のコンタクトにも、予備の値で対応できます。トークンの予備の値を「様」にしておけば、空欄のコンタクトには「様」が出て、入力済みのコンタクトにだけ個別の敬称が出ます。この組み合わせなら、レコードに持たせても入力の負担は例外的な相手だけに限られます。見積書の宛名で会社名や敬称をどう出すかは、HubSpotの見積書テンプレートを日本向けに整える方法で扱っています。
入力経路ごとに値の一致条件を確認する
項目を設計しても、入力経路ごとに値の扱いが異なるため、崩れる場所は経路ごとに決まります。次の表は、公式ナレッジで確認できた条件を、経路別にまとめたものです。
| 入力経路 | 確認できた条件 | 設計上の対応 |
|---|---|---|
| インポート | 列挙プロパティの値は、オプションの「ラベル」または「内部値」と一致させる。外国語の文字を含むファイルはUTF-8でエンコードする | 都道府県の列を、選択肢のラベルにそろえてから取り込む |
| フォーム | 更新されたフォームエディターで作ったフォームでは、検証ルールが強制される | フリガナと郵便番号のルールは、フォームにも効く |
| ワークフロー | 検証ルールは適用されない。値のコピーは互換性のあるフィールドタイプ間のみ（選択系は同じタイプで内部値が完全一致） | ワークフローで書き込む値は、設計時に整えておく |
| 手入力・CRM画面 | 検証ルールが適用される。既存値は遡って変更されない | 既存データの整理は、別の作業として計画する |
インポートの前に値をそろえる
公式ナレッジのインポートファイルの設定（HubSpotナレッジベース）では、列挙プロパティの値は、オプションのラベルまたは内部値のいずれかと一致させる必要があると案内されています。都道府県をドロップダウンにした場合は、ファイル側の「東京」を「東京都」にそろえるなど、取り込む前の整理が必要です。インポートの流れはHubSpotインポートでコンタクト移行を成功させる手順と関連付け設計、エラーが出たときの読み方はHubSpotのインポートエラーの直し方で扱っています。
なお、この公式記事には、国・地域・都道府県の専用の書式規定は書かれていません。したがって、都道府県の表記は、プロパティ側で選択肢をどう決めるかによって決まります。
ワークフローの値コピーには、同じタイプという条件がある
見落とされやすいのが、ワークフローの値コピーの条件です。公式ナレッジのワークフローで値をコピーできる、互換性のあるプロパティータイプ（HubSpotナレッジベース）では、［レコードを編集］アクションでプロパティー値をコピーするとき、互換性のあるフィールドタイプのプロパティーだけが選べると案内されています。コピー元とコピー先のプロパティーは同じタイプである必要があり、ドロップダウン選択へコピーできるのは、同じタイプ（ドロップダウン選択）のプロパティーからです。チェックボックスからドロップダウン選択へのコピーは互換性がないと明記されています。さらに、コピー元の内部値がコピー先にもすべて存在し、大文字・小文字、スペース、アンダースコアまで完全に一致することが条件です。
この条件からは、単行テキストで持つ既定のState/Regionの値を、ワークフローでドロップダウンの都道府県へ自動で写す設計は、公式の互換条件の対象外と読み取れます。ただし、公式ナレッジに単行テキストからドロップダウンへの可否が明記されているわけではないため、採用前に自社のポータルで実際に試して確かめてください。この機能は、Marketing Hub、Sales Hub、Service Hub、Data Hubの各ProfessionalまたはEnterpriseが対象です。
都道府県を選択肢にするなら、入口（フォーム・インポート）の側でドロップダウンの値を直接入れる設計を第一候補にします。
支援の進め方：日本のデータ設計を段階的に整える
StartLinkは、HubSpotゴールドパートナーとして、日本の顧客データの設計を、工程に分けて支援します。項目を決めるだけでなく、すでに溜まったデータの整理と、入力経路の統制まで含めて設計することが、あとから崩れない形につながります。
| 工程 | 日本の顧客データに関する作業 | 成果物 |
|---|---|---|
| 現状の整理・要件定義 | 既存の名簿、名刺管理、他システムでの氏名・住所の持ち方を洗い出す。宛名の出し方を整理する | 項目一覧と、宛名ルールの叩き台 |
| 設計・構築 | フリガナ・都道府県などのカスタムプロパティ、入力ルール、グループの設計と作成 | プロパティ設計書、作成済みのプロパティ |
| データ移行 | 氏名の分割、都道府県の表記統一、インポートファイルの整形 | 移行前後の件数と値の照合表 |
| テスト・検証 | 各入力経路から実際に登録し、値が想定どおりに入るかを確認 | 経路別の確認結果 |
| 定着・運用改善 | 入力ルールの見直し、担当交代時の引き継ぎ、表記ゆれの定期点検 | 運用手順書、点検の観点 |
進め方としては、最初に氏名・フリガナ・都道府県の3項目に絞って整え、入力経路が回ることを確かめてから、住所の細目や敬称へ広げるスモールスタートを勧めています。準委任で伴走する形をとるため、運用しながら入力ルールを調整できます。
AIを使う場面もあります。たとえばBreezeや外部のAIを使って、既存データの表記ゆれを洗い出す作業を補助できます。ただし、AIが提案した変換結果は、そのままレコードへ書き込まず、対象を絞った見本で人が確かめてから反映します。名寄せ全般の考え方は、CRMのデータクレンジング実践ガイドと企業データ名寄せ実務ガイドで扱っています。企業様（チーム）によって最適な形は異なりますので、入力経路の数とデータ量に合わせて、設計の粒度を決めます。
よくある失敗と回避策
| 失敗 | 原因 | 回避策 |
|---|---|---|
| 氏名が1つの欄に入っていて、並びを変えられない | 移行元の氏名が1列だった | 取り込む前に、姓と名の列に分ける |
| 「東京」と「東京都」が別々に集計される | 都道府県を自由入力で受けている | ドロップダウンにし、重複した選択肢は［マージ］で統合する |
| フリガナにひらがなと半角カナが混在する | 入力ルールがない | 検証ルールで文字種を限定する。既存値は別途整理する |
| 宛名に「様」だけが表示される | 姓が空欄で、予備の値がない | トークンに予備の値を設定する |
| ドロップダウンにしたあとにインポートが失敗する | ファイルの値が選択肢のラベル・内部値と違う | 取り込む前に、ファイルの値を選択肢にそろえる |
| 選択肢の内部値を後から直したくなった | 内部値は保存後に変更できない | 保存前に、連携を見越して内部値を決める |
よくある質問
Q1. HubSpotにフリガナの既定プロパティはありますか。
公式ナレッジの既定のコンタクトプロパティ一覧には、フリガナに対応する項目は載っていません。姓用・名用のカスタムプロパティを、単行テキストで作成して使います。
Q2. 姓と名の表示順は、HubSpotの設定で変えられますか。
公式ナレッジで、表示順を切り替える設定は確認できませんでした。メールや書類に出す並びは、パーソナライズトークンの並べ方で決めます。姓のトークンを先に、名のトークンを後に置けば、日本語の順になります。
Q3. 都道府県は、既定のプロパティのままでも使えますか。
使えます。ただし、既定のState/Regionはテキスト系のため、表記ゆれは入力経路の側で防ぐ必要があります。集計や振り分けに使うなら、ドロップダウン選択のカスタムプロパティを足す設計も検討します。
Q4. 単行テキストの都道府県を、ドロップダウンに変えても大丈夫ですか。
公式ナレッジでは、単行テキストなどからドロップダウンへの変更自体は案内されていますが、型の変更は既存の値に影響し得ます。本番でいきなり変えず、新しいドロップダウンのプロパティを作って少数のコンタクトで試し、バックアップを取ってから進めます。
Q5. フリガナの入力ルールは、どのプランで使えますか。
「先頭と末尾のスペースを許可しない」などの標準の検証ルールは、全製品・全プランが対象です。正規表現による「カスタムルールを使用した検証」は、ProfessionalまたはEnterpriseが必要と案内されています。
まとめ：日本の顧客データは「入力の入口」で整える
- 姓と名は別のプロパティで持ち、表示の並びはパーソナライズトークンで決めます
- フリガナは、姓用・名用のカスタムプロパティとして足し、検証ルールで表記をそろえます
- 都道府県は、集計や振り分けに使うならドロップダウンにします。重複した選択肢は［マージ］で統合します
- 敬称は、持たせない運用を基本にし、持たせるならドロップダウンにします
- インポート・フォーム・ワークフローで値の一致条件が違うため、経路ごとに確認します
最初の一歩は、いまの名簿から50件ほどを抜き出し、氏名の持ち方と都道府県の表記が何通りあるかを数えることです。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
参考にした公式ドキュメント
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
