データ移行を終えた直後の報告は、たいてい「件数が一致したので問題ありません」です。ところがその2週間後、営業現場から「取引に会社が紐づいていない」「担当が前任者のままになっている」「同じ会社が2つある」という指摘が次々に上がります。件数が合っていたのは事実で、それでも移行は成功していませんでした。
件数の一致は、移行が終わったことを示す指標であって、移行が正しかったことを示す指標ではありません。レコードの本数は合っていても、関連付けが欠け、担当が空で、選択肢が「その他」に寄せられていれば、業務は回りません。検証の設計とは、件数以外の何を、どの粒度で、どこまで確認するかを先に決めることです。
株式会社100はHubSpotの認定エリートパートナーとして、100社以上の導入支援実績があります。この記事では、私たちがHubSpotへの移行後に実施している検証手順を、4層の検証設計・件数と関連付けと重複と担当者の突合方法・サンプリングの件数設計・差分が出たときの切り分け順序・検収の合格条件の決め方という順で説明します。
目次
移行で壊れるものには、エラーとして表に出るものと、出ないものがあります。型の不一致や必須項目の欠落はインポート時にエラーになりますが、関連付けの欠落・担当者の空欄・日付の解釈違い・選択肢の丸め込みは、エラーにならずに通過します。
エラーにならずに通過したものは、業務が始まってから発見されます。発見が遅れるほど、その間に現場が入力した新しいデータと混ざり、どこまでが移行の問題でどこからが運用の問題かが切り分けられなくなります。移行直後の短い期間に、エラーにならない種類の不具合を意図的に探しにいくのが検証工程の目的です。
HubSpot側の自動検出にも限界があります。データ品質ツールを使用するには、レコードがデータ品質ツールによって更新された後に手動で別の形式の値へ更新された場合、コマンドセンターは再びフラグを付けないこと、またユーザーによる手動更新・API・連携・インポート・データ移行によって追加された値は通常は再びフラグが立たないことが記載されています。移行で入った値は、ツール任せでは検出されないという前提で検証を設計する必要があります。
検証を1つの作業として扱うと、担当者の勘に依存します。私たちは4層に分け、層ごとに対象・判定方法・担当を変えています。層を分ける目的は網羅性ではなく、どの層で何が見つかるかを事前に決めて、見つからなかったときに「次の層へ進んでよい」と判断できるようにすることです。
下の表で注目していただきたいのは、担当の列です。上の2層はシステム側で完結しますが、下の2層は業務部門の参加なしには成立しません。業務部門の時間を確保できないプロジェクトでは、検証が上2層で止まり、運用開始後に残りが表面化します。
| 層 | 検証対象 | 判定方法 | 担当 |
|---|---|---|---|
| 1. 全件突合 | オブジェクトごとの件数、エラー行、除外行 | 移行元の集計とHubSpotのエクスポートを数値で比較 | 移行実施者 |
| 2. 構造突合 | 関連付け、担当者、パイプライン、ライフサイクル | 属性が空のレコード数をレポートで数える | 移行実施者 |
| 3. 標本精査 | 項目ごとの値、変換ルールの適用結果 | 抽出した標本を移行元と1件ずつ目視で比較 | 移行実施者＋業務部門 |
| 4. 業務確認 | 日常業務が回るか | 現場が実際の業務シナリオで操作する | 業務部門 |
件数の突合は、HubSpot側の数字を1か所から取るのではなく、2系統から取って一致を確認します。インポート実行の記録と、オブジェクトのエクスポート結果です。この2つがずれる場合、インポート後に何かが動いています。
インポート実行の記録は、過去のインポートを表示して分析から確認します。ここで見るのは成功件数だけでなく、作成と更新の内訳です。新規作成のつもりで流したファイルで更新が発生している場合、一意キーの設定が想定と違っています。エクスポート側はレコードをエクスポートするで取得します。
件数が合わない原因は、たいてい移行元の数え方にあります。HubSpot側が減っているように見えて、実は移行元に重複行や小計行が含まれていた、というケースが最も多くなります。
疑う順序は4つです。移行元ファイルの重複行、インポート時に一意キーで統合された行、エラーで取り込まれなかった行、そして意図的に除外した行。エラー行についてはレコードのインポートエラーの確認とトラブルシューティングにエラー種別の一覧があり、1行に10個を超えるエラーがある場合の扱いや、固有IDの値に改行や100文字を超える文字が含まれる場合にエラーになり得ることが記載されています。エラー行はダウンロードして原因別に分類し、再投入するものと手入力に回すものを分けます。
関連付けの検証は、全件を目で見ることができないため、「関連付けが0件のレコードが何件あるか」を数える形で行います。本来すべての取引に会社が紐づくはずなら、会社が紐づいていない取引の件数は0になります。
実務では0にならないことが普通で、0にならない理由を説明できる状態を目標にします。私たちは、関連付けのないレコードを抽出したうえで、移行元で親を持っていなかったものと、移行の過程で欠落したものに分類します。分類の結果、移行元に起因するものは「移行前からそうだった」という記録を残して合格にします。
ラベル付きの関連付けを使っている場合は、ラベルごとに同じ数え方をします。関連付けラベルの作成と使用とレコードの関連付けに適用する制限を設定するのとおり、上限の設定によっては、意図した件数が張られずに切り捨てられていることがあります。関連付けの合計数の上限とラベル側の上限が食い違う場合は、合計側の上限が優先されます。移行前に上限を緩めておき、検証後に本来の上限へ戻す手順を計画に入れておくと、このつまずきを避けられます。関連付けの操作全般はレコードを関連付けるに記載があります。
重複の検証で最初に確認すべきは、検出した重複を「移行で生まれたもの」と「移行元にもともとあったもの」に分けられるかどうかです。この区別をせずに統合を始めると、業務上は別レコードとして扱うべきものまで一つにまとめてしまいます。
HubSpotの重複検出は重複レコードの確認と管理で行います。重複管理ツールで個々の重複を管理し、最大10,000組の重複ペアを表示するには、ProfessionalまたはEnterpriseへの加入が必要です。重複をさらに表示するにはData Hubのサブスクリプションが必要で、Professionalでは最大30,000組です。却下した重複ペアは却下から最大14日後までロールバックでき、マージルールごとに最大20件のプロパティーオーバーライドを設定できます。これらは2026年10月23日時点の記載で、変更される可能性があります。重複の判定ロジックそのものはHubSpotのレコードの重複削除に整理されています。
統合の実行は、検証工程のなかで最も慎重に扱うべき操作です。レコードをマージには、全てのレコードのアクティビティーが同期されるまで最大30分かかること、コンタクトレコードが合計で250件以上のマージに含まれている場合はマージできないこと、マージされたレコードの詳細を最大90日前までエクスポートで確認できることが記載されています。マージは取り消せない操作であるため、私たちは検証段階では統合を実行せず、統合候補の一覧を作るところまでに留めます。統合は業務部門の確認を経てから、本番運用の開始前にまとめて実施します。マージ後のレコードIDの扱いはマージ時のレコードIDで解説しています。
担当者は、件数の突合では絶対に見つからない欠落が起きる項目です。担当者が空のままでも、レコードは正常に作成されます。運用開始後に「自分の担当案件が一覧に出てこない」という形で発覚します。
突合は3段階で行います。担当者が空のレコード件数、移行元の担当者名とHubSpotのユーザーの対応表に載っていない値の件数、そして担当者別の件数分布です。3つ目の分布を見ると、本来均等に近いはずの担当件数が特定の1人に偏っている場合に、対応表の誤りが見つかります。レコードの担当を割り当てに設定方法の記載があります。
退職者が担当していたレコードの扱いは、移行前に決めておく必要があります。退職者をHubSpotのユーザーとして作成しない方針なら、移行元の担当者名をカスタムプロパティーに退避したうえで、現担当へ付け替えます。この付け替えを記録せずに実施すると、過去の担当履歴が消えます。担当とチームの関係はチームの作成と管理、閲覧範囲との関係はレコードへのアクセス権の割り当てとHubSpotユーザー権限ガイドに記載があります。担当が正しくても権限設計が合っていないと一覧に出ないため、この2つは同時に確認します。
件数と関連付けと担当者を確認し終えても、まだ残る領域があります。ステージ、日付、金額の3つです。この3つはいずれも値が入っていることが確認できても、値が正しいとは限らないという共通点を持ちます。目視で1件ずつ見るには件数が多すぎるため、分布で異常を探します。
分布で見る、という方針が要点です。1件ずつ正しさを判定するのではなく、全体の形が移行元と同じかどうかを見ます。形が違えば、その区間だけを抽出して個別に調べます。
パイプラインステージは、ステージ別の件数分布を移行元と並べて比較します。移行元で「商談中」が多数を占めていたのに、HubSpot側で先頭ステージに寄っている場合、マッピングの対応が漏れて既定値に落ちています。既定値に落ちたレコードは、エラーにならないまま静かに積み上がります。
ステージの設計と既定値の挙動はオブジェクトパイプラインのセットアップと管理に記載があります。既定の取引パイプラインは7つのステージを持ち、各ステージに確度（アポイント設定済み20%、購入見込みあり40%、プレゼン予定済み60%、意思決定者の賛同80%、契約書送付済み90%）が設定されています。確度を自社の値に置き換えている場合、移行後の売上予測が設計どおりの数字になるかも、この段階で確認します。ライフサイクルステージについてはコンタクトと会社のライフサイクルステージを使用するのとおり、オブジェクト間で同期する設定があるため、移行直後に意図しない段階へ進んでいないかを確認します。
日付の検証で最初に見るのは、年月ごとの件数分布です。移行元と並べて、山の位置が一致しているかを確認します。月と日が入れ替わって取り込まれている場合、13日以降のデータが存在しない月が出現するため、日別の分布を見れば一目で分かります。この確認は、全件を目視するより圧倒的に早く、見落としません。
次に見るのは境界です。最古の日付と最新の日付を移行元と比較し、想定外に古い日付や未来の日付がないかを確認します。旧システムで未設定を表していた特殊な値が、そのまま日付として取り込まれていることがあります。時刻を含む項目では、タイムゾーンの扱いによって日付が1日ずれることがあるため、日付のみの項目と日時の項目を分けて確認します。インポート時の書式の扱いはインポートファイルの形式設定に記載があり、タイムスタンプを含めない場合は時刻が既定で真夜中に設定されることが明記されています。
金額は、合計値で突合します。レコード単位で1件ずつ見るのではなく、パイプライン別・年度別の合計を移行元と比較すると、桁の誤りや通貨の取り違えがすぐに出ます。複数通貨を扱う場合は、口座の通貨を追加・編集するの設定と、移行ファイルに通貨コードが含まれていたかを併せて確認します。為替レートの設定時期によって換算後の金額が変わるため、合計が合わない場合はレートの適用時点を先に疑います。
標本精査の件数を「全体の1割」のように比率で決めると、件数が多いときに終わらず、少ないときに不十分になります。比率ではなく、確認したい事象の種類の数で決めるほうが実務に合います。
統計的な標本調査の考え方は総務省統計局のなるほど統計学園などで解説されていますが、移行検証で必要なのは母集団の推定ではなく、変換ルールが設計どおり動いたかの確認です。目的が違うため、無作為抽出だけでは足りません。
次の件数は、私たちが検証対象の種類から算出している設計値です。無作為抽出の分と、意図的に選ぶ分を分けて積算します。合計件数は変換ルールの数に比例して増えるため、マッピング表の行数から先に算出できます。
| 標本の種類 | 選び方 | 件数の算出 | 見るもの |
|---|---|---|---|
| 無作為抽出 | オブジェクトごとに乱数で抽出 | オブジェクトあたり30件 | 全項目を移行元と1件ずつ照合 |
| 変換ルール別 | 変換を伴う項目ごとに抽出 | ルール1本につき3件 | 変換後の値が設計どおりか |
| 選択肢別 | 統合・廃止した選択肢ごとに抽出 | 旧値1種類につき1件 | 寄せ先が正しいか |
| 境界値 | 最古・最新・最大・最小・空欄 | 項目種別ごとに2件 | 日付と数値の解釈 |
| 業務上の重要レコード | 業務部門が指名 | 部門あたり10件 | 現場が納得できるか |
最後の行の「業務部門が指名」は、省略されがちですが最も効果があります。主要顧客や進行中の大型案件など、現場が中身を暗記しているレコードを見てもらうと、統計では出てこない違和感が出てきます。指名してもらう際は、「正しいか確認してください」ではなく「どこが違うか教えてください」と依頼すると、指摘が具体的になります。
差分が見つかったとき、最初に「HubSpotの仕様か」を疑うと時間を失います。移行の差分は、ほとんどが手前の工程で生まれています。切り分けは、データが通ってきた順序を逆にたどるのが最短です。
私たちが使っている順序は4段階です。抽出、変換、投入、投入後の自動処理。この順にチェックすると、同じ症状でも原因の層が特定できます。
| 段階 | 確認すること | この段階が原因なら出る症状 |
|---|---|---|
| 1. 抽出 | 移行元からの抽出条件と件数 | 特定の条件のレコードがまるごと無い |
| 2. 変換 | 変換後ファイルの該当行の値 | 値はあるが内容が違う。特定の項目だけ崩れる |
| 3. 投入 | インポート結果とエラーファイル | 行単位で欠落。エラー行に偏りがある |
| 4. 投入後 | ワークフロー・連携・自動採番 | 投入直後は正しく、時間が経つと変わる |
4段階目を見落とすと、原因が永遠に見つかりません。移行と同時にワークフローを有効にしていると、インポートをきっかけに自動化が動き、値を上書きします。ワークフローの登録設定の管理とワークフローの変更を表示で、移行期間中に動いた自動化を確認します。私たちは移行の実行中はワークフローを停止し、検証が終わってから段階的に有効化します。値が誰にいつ変更されたかはアカウントアクティビティー履歴の表示とエクスポートからも追えますが、全ログとセキュリティーアクティビティーのビューは過去30日以内が対象と記載されているため、調査は早いほど有利です。
やり直しが必要になった場合の退避策も、検証の前に確認しておきます。削除されたレコードを復元するには、HubSpotが定義するオブジェクトのレコードは削除後90日以内であれば復元できること、レコード復元ツールが一度に表示および復元できるレコードは最大10,000件までであること、完全な削除やGDPR関連の削除はごみ箱に保持されず、個人情報保護法に従って消去されるまでに最大30日かかる場合があることが記載されています。プロパティー値の変更についてはCRMの変更を復元する、バックアップの取得はCRMデータをバックアップするに手順があります。
合格条件を「全データが正しく移行されていること」と書くと、検収が終わりません。実データには移行元の時点で既に不整合があり、それをすべて直すことは移行の責務ではないためです。合格条件は、不一致の許容範囲を数えられる形で定義します。
IPA（情報処理推進機構）の情報システム・モデル取引・契約書では、工程ごとの成果物と確認の責任分担を整理しています。外部に委託する移行であれば、合格条件は契約の一部として事前に合意しておく性質のものです。社内プロジェクトでも、合格条件を先に文書化しておかないと、検収が「気が済むまで見る」作業になります。
私たちが合格条件に使っている書き方は、項目ごとに「一致率」ではなく「不一致件数の上限と、上限を超えた場合の扱い」を書く形です。たとえば、担当者が空のレコードは0件、会社に紐づかない取引は移行元で親を持たなかった件数と一致、選択肢の値はすべて設計した選択肢のいずれかに入っている、というように、数えられる形に落とします。数えられない条件は合格条件になりません。
加えて、合格判定を誰が行うかを層ごとに決めます。1層と2層は移行実施者、3層は移行実施者と業務部門の連名、4層は業務部門の責任者。4層の判定者を決めていないと、検証が終わったのに誰も「終わった」と言わない状態になります。受け入れテストの設計はHubSpot導入の受け入れテストで扱っています。非機能面の確認観点はIPAの非機能要求グレードに移行性の項目があり、検証計画の抜け漏れチェックに使えます。
検証の前提となるマッピング設計はデータマッピング表の作り方、移行当日の進め方は移行の切り替え計画、全体の設計思想は基本設計書にまとめています。運用開始後のデータ品質維持についてはCRMデータのクレンジングと週次のデータ品質ダイジェストが役立ちます。検証用のレポートはカスタムレポートを作成で作れます。インポートの再実行は過去のインポートを再度実行する、書式の問題の管理はコンタクトプロパティーのフォーマットに関する問題の管理を参照してください。
移行後の検証について、プロジェクトの終盤で実際に受ける質問を挙げます。本文の流れには乗らないものの、現場で判断を迫られる論点に絞っています。
移行の実行時間より、業務部門の確認日程で決まります。1層と2層は移行実施者だけで進むため数日で終わりますが、3層と4層は現場の稼働を確保できるかどうかが律速になります。私たちは、移行実行から本番開始までの間に、業務部門が触れる営業日を最低3日確保することを条件にしています。確保できない場合は、移行日を後ろにずらすほうが結果的に早く終わります。
直せる時期で分けてください。移行後に直せないもの、たとえば一意キーの不整合や関連付けの欠落は、本番開始前に直します。表記ゆれや空欄のように運用しながら直せるものは、本番開始後の課題として一覧に残します。この分類を先に決めておくと、「全部直すまで開始しない」という硬直を避けられます。
移行元の誤りは移行の責務ではありませんが、見つけた時点で記録し、業務部門に報告してください。報告を省くと、運用開始後に「移行で壊れた」と判断されます。私たちは、移行元起因の不整合を一覧にして、移行の完了報告に添付しています。この一覧が、移行後のデータクレンジング計画の出発点にもなります。
無作為抽出で0件なら、頻度の高い不具合はないと判断できます。ただし無作為抽出は、めったに出現しないパターンを拾えません。本文の表で挙げた変換ルール別・選択肢別・境界値の標本は、無作為抽出とは別に必ず実施してください。不具合は、出現頻度の低いパターンに集中します。
マージが取り消せない操作だからです。マージには制約があります。コンタクトレコードが合計で250件以上のマージに含まれている場合はマージできず、アクティビティーの同期には最大30分かかります。移行直後は、検証がまだ終わっておらず「どちらが正しいレコードか」の判断材料が揃っていません。統合候補の一覧を作るところまでに留め、業務部門の確認後に実行してください。
可能ですが、復元の制約を理解したうえで判断してください。削除後90日以内であれば復元できると記載されていますが、復元ツールが一度に表示および復元できるレコードは最大10,000件までです。数十万件を削除してやり直す計画であれば、復元を前提にせず、削除前のエクスポートを取得しておくほうが確実です。
層ごとに、確認日・確認者・対象件数・不一致件数・判定の5項目を1行で残してください。スクリーンショットの束は後から参照されません。特に不一致件数は、0ではない場合に「なぜその件数を許容したか」を1文添えておくと、運用開始後の問い合わせに即答できます。
代替はできません。データ品質ツールは書式の問題と重複の検出に有効ですが、移行の文脈で必要な「移行元と一致しているか」という観点は扱いません。加えて、インポートやデータ移行によって追加された値には、通常は再びフラグが立ちません。移行検証は移行元との突合で行い、データ品質ツールは運用開始後の継続監視に使う、という役割分担が現実的です。
株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして100社以上の導入支援実績があり、データ移行の設計から検証・検収までを支援しています。検証計画や合格条件の設計について具体的にご相談がある場合は、お問い合わせからご連絡ください。