HubSpot移行のデータマッピング表とは、移行元の項目をHubSpotのどのプロパティーへ、どの値の形に変えて入れるかを1行ずつ決めた「移行の仕様書」です。 項目名の対応を並べるだけの表では、取り込みの段階で選択肢が一致せず、日付が読み取れず、同じ意味の値が別々の選択肢に割れてしまいます。値の変換と「持っていかない」判断まで書いて、初めて取り込みの作業者が迷わない表になります。
移行の相談で多いのは、「項目の対応は決めたのに、取り込むとエラーが出る」「取り込めたが、選択肢が増えすぎて集計できない」というものです。原因の多くは、項目名の対応には気を配っても、値の対応を決めていないことにあります。
この記事では、HubSpotの公式ナレッジで確認できた取り込みの仕様を前提に、マッピング表の列の設計、型ごとの変換ルール、選択肢の統一、持っていかない項目の判断を、実務の順に整理します。
- 列は「対応」ではなく「変換と判断」まで持たせる ── 移行元の値・変換ルール・取り込み後の確認方法を同じ行に書きます
- 値の変換は型ごとにルールを決める ── ドロップダウン、複数チェックボックス、日付、数値で守る書式が違います
- 選択肢は旧値→新値の変換表で統一する ── 表記の揺れをHubSpot側へ持ち込まないためです
- 持っていかない項目は理由つきで残す ── 後から「なぜ消えたのか」に答えられるようにします
マッピング表を「移行の仕様書」として設計する
マッピング表は、移行の担当者が替わっても同じ結果が再現できる粒度で書くのが基本です。項目名の対応だけでは、取り込み作業のたびに判断が必要になり、担当者ごとに結果が変わります。
1行に持たせる列を決める
マッピング表の1行は、移行元の1項目に対応します。次の列を持たせておくと、設計・取り込み・検証の3つの工程が同じ表を使えます。
| 列 |
書く内容 |
使う工程 |
| 移行元の項目名・型 |
移行元システムでの名称と、テキスト・選択・日付などの型 |
設計 |
| 移行先オブジェクト |
コンタクト、会社、取引など |
設計 |
| 移行先プロパティー(表示名/内部名) |
既存のものか新規作成か。新規なら型も |
設計・構築 |
| 判定 |
移行する/変換して移行する/移行しない/統合する |
設計 |
| 変換ルール |
値の置換、書式の変更、結合・分割の方法 |
取り込み |
| 空欄の扱い |
空欄のまま取り込む/既定値を入れる/行を除外する |
取り込み |
| 確認方法 |
取り込み後に何を突き合わせるか |
検証 |
この中で特に抜けやすいのが「判定」「空欄の扱い」「確認方法」の3列です。対応関係だけを書いた表は、この3列が空のまま取り込みに進み、後から検証で手戻りが起きます。
行の粒度は「移行元の1項目=1行」で揃える
移行元の1項目を、移行先の複数プロパティーに分ける場合(たとえば、氏名を姓と名に分ける場合)も、行は移行元の項目単位で立て、変換ルール列に分割の方法を書きます。1行が複数の項目を同時に扱うと、判定や確認方法を書き分けられなくなるためです。
逆に、移行元の複数項目を移行先の1つにまとめる場合は、移行元の項目ごとに1行を立て、移行先プロパティーに同じ名前を書きます。この形にしておくと、「移行先のこのプロパティーには、移行元のどの項目が流れ込んでいるか」を、移行先の名前で並べ替えるだけで確認できます。
持っていく項目・持っていかない項目の判断表
マッピング表の「判定」列を埋める作業が、設計の中心です。移行元の項目をすべて移す前提で始めると、使われていない項目や、HubSpotの標準機能で代替できる項目まで移すことになり、プロパティーが増えて運用が重くなります。
4つの判定の基準
| 判定 |
当てはまる項目の特徴 |
例 |
| そのまま移行する |
営業・マーケティング・サポートの判断や集計で使い、型もそのまま対応できる |
会社名、電話番号、リード獲得日 |
| 変換して移行する |
使うが、型や選択肢が移行先と合わない |
自由記述の業種、独自の地域区分 |
| 移行しない |
利用実態がない、またはHubSpotの標準機能が同じ情報を持つ |
利用者がいない旧項目、システムが自動で付ける更新日時 |
| 別の形で持つ |
値は残したいが、プロパティーにすると使いにくい |
長文のメモ、過去の対応履歴 |
「移行しない」を決めるときの確認
移行しないと判定する前に、次の3点を確認します。
- その項目を、直近の一定期間に入力・参照した人がいるか(入力率だけでなく、画面・帳票・集計での参照を含めて確認します)
- 他の項目から導出できないか(導出できる値をそのまま移すと、元の値が変わったときに食い違います)
- 他の項目・自動処理・帳票がこの項目の値を条件にしていないか
3点目を確認せずに外すと、移行後に「営業会議の集計が合わない」という形で表面化します。入力率が低いことは、不要であることの根拠にはなりません。月に数件しか入力されない項目が、重要な判断の条件になっている場合があるためです。
「移行しない」は、理由と確認した人の名前を同じ行に残します。移行後に必要だったと分かったときに、元データのどこから戻せるかを答えられるようにするためです。
現状の業務と項目の利用実態を整理する工程については、HubSpot導入前の現状整理の進め方で扱っています。
型ごとの値の変換ルールを決める
マッピング表の「変換ルール」列は、HubSpotが取り込みで受け付ける値の形から逆算して書きます。HubSpotの公式ナレッジ(インポートファイルの設定)で確認できた書式を、移行の変換ルールとして整理すると次のようになります。
型別の変換ルール一覧
| 移行先の型 |
HubSpotが受け付ける形 |
変換ルールに書くこと |
| ドロップダウン選択 |
プロパティーのオプションの「ラベル」または「内部値」に一致する値 |
旧値→新値の変換表(次の章)を参照 |
| 複数のチェックボックス |
セミコロンで区切り、前後にスペースを入れない。オプションは取り込み前に作成済み |
区切り文字の置換。旧システムがカンマ区切りなら置き換える |
| 1つのチェックボックス |
「True」「はい」または「False」「いいえ」 |
旧システムの「1/0」「○/空欄」などをどちらに寄せるか |
| 日付 |
月は数字・3文字・フルネーム、区切りはスラッシュ・ハイフン・ピリオド。並びは日月年、月日年、年月日 |
旧システムの出力形式と、取り込み時に指定する日付形式を一致させる |
| 日時 |
時刻は hh:mm。タイムゾーンは +hh:mm または -hh:mm で指定。省略すると真夜中 |
時刻なしの日付をどう扱うか、タイムゾーンをどう揃えるか |
| 数値(パーセンテージ) |
「25%」または「.25」 |
旧システムが0〜100で持つか、0〜1で持つかを確認 |
| 数値(通貨) |
HubSpotで使える通貨。小数点を使う形式 |
桁区切りの除去、通貨記号の除去 |
| 電話番号 |
国コードに基づく自動書式にする場合は +[国コード][電話番号]。内線は ext を付ける |
ハイフンや先頭の0の扱い |
この表の右列「変換ルールに書くこと」が、マッピング表の「変換ルール」列に実際に書く内容です。たとえばパーセンテージは、旧システムが「75」と持っていれば「75%」に直すのか、「.75」に直すのかを決めておかないと、取り込み後に値が100倍ずれても気づけません。
検証ルールがある項目は先に確認する
移行先のプロパティーに検証ルールを設定している場合、そのルールに合わない値は取り込まれません。たとえば、数値の範囲や文字種を制限しているプロパティーに、旧システムの自由な入力値をそのまま流すと、該当する行の値だけが入らない形で表れます。
マッピング表を作る段階で、移行先プロパティーに検証ルールがあるかを一覧で確認し、ある場合は変換ルールに「ルールに合わない値は空にする」「旧システムの値を補正してから取り込む」のどちらかを書いておきます。
日付と時刻は、取り込み画面の設定も表に書く
日付の書式は、ファイルの中身だけでなく、取り込み時の画面でも指定します。公式ナレッジ(データのインポート手順)では、最終確認の設定として、日付は「日付形式」、日時は「タイムゾーン」、数値は「数値の形式」で指定すると案内されています。日と月の並びを取り違えると、存在しない月になる行がエラーになり、存在する日付になる行は、別の日付として入る場合があります。後者のほうが検出しにくいため、日付の列は変換前後の見本を表に1〜2行書いておきます。
選択肢の統一は、旧値→新値の変換表で行う
移行元の選択肢は、長く運用されるほど表記が揺れています。同じ意味の値が、全角と半角、略称と正式名称、部署ごとの独自の呼び方で複数に分かれていることが少なくありません。これをそのままHubSpotへ移すと、集計やセグメントの条件が割れます。
旧値→新値の変換表の作り方
選択肢の統一は、次の手順で進めます。
- 移行元から、対象項目に実際に入っている値を、件数つきで一覧にする(選択肢の定義ではなく、実データの値を取ります)
- 意味が同じ値をまとめ、新しい選択肢の候補を決める
- 新しい選択肢ごとに、表示名(ラベル)と内部値を決める
- 旧値→新値の変換表を作り、旧値の件数を併記する
- どれにも当てはまらない値と空欄の行き先(「その他」「未設定」など)を決める
- 業務の担当者に、新しい選択肢が現場の使い方に合っているかを確認してもらう

実データから値を取る理由は、選択肢の定義に残っていない過去の値が、実際には入っていることがあるためです。定義だけを見て変換表を作ると、変換表にない値が取り込み時のエラーとして現れます。
変換表の記入例
| 旧値 |
件数の目安 |
新値(ラベル) |
内部値 |
備考 |
| 製造 |
多い |
製造業 |
manufacturing |
旧値の表記違いも同じ行に集約 |
| ものづくり |
少ない |
製造業 |
manufacturing |
現場の呼び方 |
| IT/情報通信 |
多い |
情報通信業 |
it_communication |
全角・半角の違いを含めて統合 |
| (空欄) |
一定数 |
未設定 |
unset |
空のまま取り込むか、未設定を明示するかを決める |
| 上記以外 |
少ない |
その他 |
other |
件数が増えたら新しい選択肢を検討 |
この表は例であり、件数や選択肢は企業様(チーム)によって異なります。重要なのは、旧値を1つずつ、新値の1つに必ず対応させることです。1つの旧値が複数の新値に当てはまる場合は、移行元の別の項目を使って振り分けるか、現場に確認して1つに決めます。
ラベルと内部値の扱いに注意する
HubSpotは、ドロップダウン選択のオプションを、ラベルまたは内部値のどちらかで一致させて取り込みます。公式ナレッジ(インポートエラーのトラブルシューティング)には、エラーの種類として「列挙オプションが無効です」と「列挙オプションがあいまいです」が載っています。前者は、ファイルの値がどの選択肢にも一致しない場合、後者は、1つの値が複数のオプションに一致する、またはラベルが内部値と異なるオプションでラベルを入力している場合です。
ラベルと内部値が異なる選択肢がある場合は、変換表の出力を内部値に揃えておくと、あいまいエラーを避けられます。HubSpotの既定のプロパティー(ライフサイクルステージ、業界など)は、内部値または英語のラベルに合わせる必要があります。日本語のラベルをそのまま入れると、取り込めないことがあります。
内部名は、プロパティーを作成した後に編集できません(公式ナレッジプロパティーの作成と編集)。選択肢の内部値の付け方も含めて、設計の段階で決め切る必要があります。後から変えにくい設定の整理は、HubSpotで後から変えにくい設定の一覧にまとめています。
テキストからドロップダウンへの変更に頼らない
移行元の値が自由記述のとき、いったんテキストのプロパティーに取り込み、後でドロップダウンに変更する方法があります。公式ナレッジによると、テキストのプロパティーをドロップダウンに変更すると、保存されている一意の値ごとに選択肢が作られ、大文字と小文字の違いや表記の揺れも別の選択肢として扱われます。
この方法は、実データの値を手早く洗い出す手段としては使えますが、そのまま運用に入れると、統一していない選択肢が大量に並びます。取り込み前に変換表で統一しておくほうが、後の整理の手間が小さくなります。選択肢の設計の考え方は、プロパティー設計のベストプラクティスも参考にしてください。

空欄・上書き・クリアの扱いを表に書く
「空欄の扱い」は、見落とされやすい一方で、移行後の値のずれに直結する列です。HubSpotの取り込みでは、空白セルは無視され、既存レコードの値をクリアしません(公式ナレッジインポートファイルの設定)。
空欄が影響する場面
| 場面 |
起きること |
マッピング表に書くこと |
| 新規レコードの作成 |
空欄はそのまま空の値になる |
空のままでよいか、既定値を入れるかを決める |
| 既存レコードの更新 |
空欄は無視され、既存の値は残る |
旧システムで空にした値を、HubSpot側でも空にしたいかを確認 |
| 値を消したい場合 |
取り込みでは消せない |
一括編集か、ワークフローの「レコードを編集」アクションで別途消す手順を書く |
旧システムで意図的に空にした値を、HubSpot側にも反映したい場合は、取り込みだけでは消えません。その項目は、取り込みとは別に値をクリアする手順を、マッピング表の備考か別の作業表に書いておきます。
「上書きしない」を使う項目を決める
既存のレコードを更新する取り込みでは、「既存の値を管理」列の「上書きしない」を選べます。公式ナレッジ(データのインポート手順)によると、この設定は、新規レコードと、そのプロパティーが空だった既存レコードにだけ値を入れ、値が入っている項目や、過去に値があった項目は更新しません。
HubSpot側で現場が更新している項目(たとえば、担当者が直接直している電話番号)を、旧システムの古い値で上書きしたくない場合に使います。どの項目に使うかは、マッピング表に「上書きしない」の列を足して、行ごとに決めておきます。更新を繰り返す移行(差分の移行)では、この列の有無で結果が変わります。
取り込み画面の操作とマッピング表の対応
マッピング表が仕様書であれば、取り込み画面の操作は、その表を実行する作業です。表の行と画面の操作が1対1で対応するようにしておくと、作業者が画面上で判断する場面が減ります。
取り込み画面での手順
公式ナレッジ(データのインポート手順)の単一ファイルの手順を、マッピング表の列に対応させると、次のようになります。
- 「その他」から「データ管理」>「データ連携」を開き、「ファイルをインポート」の「データをインポート」から「詳細インポート(全てのオブジェクト)」を選ぶ
- 取り込むオブジェクトを選び、「単一ファイル」または「複数のファイル」を選ぶ
- オブジェクトごとに、「作成と更新」「新規の作成のみ」「既存の更新のみ」のどれにするかを選ぶ(マッピング表の外に、取り込み方式の一覧を持っておきます)
- ファイルをアップロードし、一意の識別子(レコードID、Eメール、会社ドメイン名、一意の値を必要とするカスタムプロパティーのいずれか)を先にマッピングする
- 残りの列について、「HubSpotプロパティー」でマッピングする。取り込まない列は「次の形式としてインポート」で「列をインポートしない」を選ぶ
- 「既存の値を管理」で「上書きしない」を行ごとに設定する
- 最終確認の画面で、日付形式・タイムゾーン・数値の形式を、マッピング表に書いた設定に揃える
「判定」列が「移行しない」の行は、ファイルから列を外すか、手順5で「列をインポートしない」を選びます。後者は、移行元から出力したファイルの形を変えたくない場合に使えます。

ファイルの形式はマッピング表の前提になる
取り込めるのは、1シートのCSV、XLS、XLSXで、1行目をヘッダー行にし、各ヘッダーはHubSpotのプロパティーに対応させます。日本語など英語以外の文字を含む場合はUTF-8で保存します。また、列見出しは移行先プロパティーと対応づける必要があるため、マッピング表の「移行先プロパティー」に載っていない列は、ファイルに残さない運用にします。
移行先のプロパティーが無いまま取り込むと、「プロパティー定義が見つかりません」というエラーになります。マッピング表の段階で、新規作成が必要なプロパティーの一覧を作り、取り込みの前に作っておきます。一意の識別子や関連付けの設計は、関連付けキー設計の記事で扱っています。
エラーはマッピング表に戻して直す
取り込みで出たエラーは、ファイルだけを直して再取り込みすると、次回の移行でまた同じエラーが出ます。原因がマッピング表の変換ルールにあるなら、表を直し、表から再度ファイルを作る運用にします。
エラーの種類と、直す場所
公式ナレッジ(インポートエラーのトラブルシューティング)に載っているエラーを、マッピング表のどこを直すかで整理すると次のようになります。
| エラー |
主な原因 |
直す場所 |
| 列挙オプションが無効です |
ファイルの値が既存の選択肢に一致しない |
旧値→新値の変換表に旧値を追加。必要なら選択肢を追加 |
| 列挙オプションがあいまいです |
1つの値が複数のオプションに一致、またはラベルと内部値が異なる |
変換表の出力を内部値に揃える |
| 日付を解析できませんでした |
日付の書式が、取り込み時に選んだ日付形式と一致しない |
変換ルールの日付形式と、取り込み時の指定を揃える |
| 数値を解析できませんでした |
数値のプロパティーに数字以外の文字が含まれる |
変換ルールに、記号・桁区切りの除去を追加 |
| プロパティー検証ルールエラー |
値が検証ルールに違反している |
変換ルールに、補正または空にする処理を追加 |
| プロパティー定義が見つかりません |
列見出しがHubSpotのプロパティーと一致しない |
移行先プロパティーの名前を確認。無ければ作成 |
| 担当者が見つかりませんでした |
担当者がHubSpotの有効なユーザーと一致しない |
担当者の対応表を追加(下記) |
マッピング画面では、エラー件数のリンクから値を直接編集することもできます。ただし、画面上の編集はそのファイルの取り込みにしか効かないため、再発させたくない修正は、必ずマッピング表の側に反映します。
担当者は専用の対応表を持つ
担当者の列は、移行元のユーザー名とHubSpotのユーザーを対応させる別の表が必要です。「担当者が見つかりませんでした」は、HubSpotの有効なユーザーに一致しないときのエラーで、無効化されたユーザーは再有効化する必要があります。また、名前が複数のユーザーに一致する場合は、Eメールアドレスで指定する必要があります。
担当者の対応表には、「一致するユーザー」「未招待の在職者」「退職者」「判別できない」の区分を持たせ、一致しないだけで退職者として扱わないようにします。検証の観点は、データ移行の検証手順にまとめています。
StartLinkのデータ移行支援でのマッピング表の使い方
StartLinkは、HubSpotゴールドパートナーとして、現状の整理・要件定義から、設計・構築、データ移行、テスト・検証、定着・運用改善までの工程で、HubSpotの導入と移行を支援しています。マッピング表は、この工程をまたいで1枚の表を育てていく形で使います。
工程ごとの表の使い方
| 工程 |
マッピング表で行うこと |
成果物 |
| 現状の整理・要件定義 |
移行元の項目を洗い出し、利用実態を確認して「判定」列の案を作る |
項目の一覧、利用者への確認結果 |
| 設計・構築 |
移行先プロパティーの型・内部名・選択肢を決め、旧値→新値の変換表を作る |
確定したマッピング表、新規プロパティーの一覧 |
| データ移行 |
少量のサンプルで取り込み、エラーを表に戻して直し、全体を取り込む |
取り込み用ファイルの作成手順、エラーの記録 |
| テスト・検証 |
「確認方法」列に沿って、件数・値・選択肢の分布を突き合わせる |
検証ログ、差分の理由の記録 |
| 定着・運用改善 |
現場で増えた値・追加された項目を表に反映し、運用ルールに戻す |
更新したマッピング表、入力ルール |
最初から全オブジェクトを一度に移すのではなく、取引先と担当者のように影響が大きく関係の単純なオブジェクトから始め、変換ルールの考え方を固めてから広げる進め方を勧めています。準委任契約で伴走する形では、表の「判定」を決める場面に、現場の担当者に同席していただく運用を取ります。業務の判断は、現場の方でないと決められないためです。
AIを使った旧値の洗い出し
選択肢の統一では、実データに入っている旧値の洗い出しと、意味の近い値のまとめ候補づくりに、AI(ClaudeなどのAI)を使います。AIは、表記の揺れの候補を挙げるところまでを担当し、新しい選択肢に統合するかどうかの判断は、必ず現場の担当者が行います。
また、自社開発の連携アプリ(Sync for freee / Sync for Notion)の開発元として、会計や業務ツールとHubSpotの間で継続的に同期する項目については、移行のときに作ったマッピング表をそのまま連携の項目対応の設計に引き継ぎます。これにより、移行後に連携を始めるときの二重の設計作業を避けられます。移行の全体像は、SalesforceからHubSpotへの移行ガイドや、CRM移行のデータ設計で整理しています。
自社の移行元と状況に当てはめたマッピング表の設計を検討したい場合は、HubSpot導入・移行の支援をご覧のうえ、お問い合わせください。
よくある質問
Q1. マッピング表は、どのツールで作るのがよいですか
複数人で同時に編集でき、変更履歴が残る表計算ツールが適しています。重要なのは、ツールよりも列の設計と、1つの表を設計・取り込み・検証の全工程で使い続けることです。工程ごとに別の表を作ると、変更が反映されずに食い違います。
Q2. 移行元の項目は、すべてHubSpotへ移すべきですか
すべて移す必要はありません。判定は「そのまま」「変換して」「移行しない」「別の形で持つ」の4つに分け、移行しない項目は理由と確認した人を残します。使われていない項目まで移すと、プロパティーが増えて運用が重くなります。
Q3. 選択肢の統合は、移行前と移行後のどちらで行うべきですか
移行前に、旧値→新値の変換表で統一するほうが、後の手間が小さくなります。移行後に統合する方法もありますが、一度取り込んだ後は、表記の揺れが別々の選択肢として残り、レコード側の値の確認も必要になります。
Q4. 取り込みで日付がずれていた場合は、どう直しますか
まず、取り込み時に指定した「日付形式」と、ファイルの日付の並び(日月年、月日年、年月日)が一致しているかを確認します。原因が変換ルールにあるなら、マッピング表の日付形式を直し、表からファイルを作り直して再取り込みします。
Q5. 既存の値を消したい場合は、取り込みで消せますか
取り込みでは消せません。HubSpotの取り込みは空白セルを無視し、既存の値をクリアしないためです。値を消したいときは、一括編集か、ワークフローの「レコードを編集」アクションを使います。
まとめ:マッピング表は「変換」「除外」「確認」まで書いて完成する
- 列は変換と判断まで持たせる:移行元の値、変換ルール、空欄の扱い、確認方法を同じ行に置きます
- 値の変換は型ごとに決める:ドロップダウン・複数チェックボックス・日付・数値で、HubSpotが受け付ける形が違います
- 選択肢は旧値→新値の変換表で統一する:実データの値を件数つきで洗い出し、出力は内部値に揃えます
- 持っていかない項目は理由を残す:入力率だけで外さず、他の項目や集計が参照していないかを確認します
- エラーは表に戻して直す:ファイルだけを直すと、次回の移行で同じエラーが再発します
最初の一歩は、移行元の項目一覧に「判定」列を足し、使われている項目と使われていない項目を、現場の方と一緒に仕分けることです。自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
参考にした公式情報