「Dynamics 365を使っているが、マーケティング機能が足りずHubSpotを併用したい」
「Dynamics 365からHubSpotへの移行を検討しているが、データの移行方法がわからない」
——Microsoft Dynamics 365とHubSpotは、それぞれ異なる強みを持つCRMプラットフォームです。両方を活用する企業や、Dynamics 365からHubSpotへの移行を検討する企業にとって、データ連携の設計は最も重要な課題のひとつです。
本記事では、HubSpotとDynamics 365の連携パターン、データ同期の設計方法、移行時の注意点を解説します。
この記事でわかること:
本記事はStartLinkの「HubSpot完全ガイド」関連記事です。
HubSpotとDynamics 365を組み合わせて利用するパターンは、大きく3つに分類できます。自社の状況と目的に応じて、最適なパターンを選択することが重要です。
マーケティング活動はHubSpotで管理し、営業活動はDynamics 365で管理するパターンです。マーケティング部門がHubSpotのMarketing Hubを活用してリード獲得・ナーチャリングを行い、MQLに達したリードをDynamics 365に同期して営業チームが対応します。
このパターンは、既にDynamics 365を営業チームが深く利用しており、営業プロセスの変更が困難な場合に適しています。
Dynamics 365からHubSpotへ全面移行するパターンです。営業・マーケティング・カスタマーサービスのすべてをHubSpotに統合します。HubSpotの統合プラットフォームのメリットを最大限に活かせますが、移行にかかる工数と社内の変更管理が課題となります。
まずマーケティング領域をHubSpotに移行し、営業チームは一定期間Dynamics 365を併用しながら、段階的にHubSpotへ移行するパターンです。リスクを分散できるため、多くの企業で採用されています。
| 連携パターン | メリット | デメリット | 適するケース |
|---|---|---|---|
| 並行運用（共存型） | 既存の営業プロセスを維持できる | データの二重管理が発生する | 営業がDynamics 365を深く利用中 |
| 完全移行型 | データの一元管理が実現する | 移行工数が大きい | 小〜中規模のデータ量 |
| 段階移行型 | リスクを分散できる | 移行期間中の運用が複雑になる | 中〜大規模のデータ量 |
HubSpotとDynamics 365ではデータモデルが異なるため、フィールドマッピング（項目の対応付け）が連携設計の核になります。
| Dynamics 365 | HubSpot | 注意点 |
|---|---|---|
| Account（取引先企業） | Company（会社） | 企業の階層構造はHubSpotでは「親会社」プロパティで再現 |
| Contact（連絡先） | Contact（コンタクト） | ほぼ1対1で対応可能 |
| Opportunity（営業案件） | Deal（取引） | ステージ名の対応付けが必要 |
| Lead（リード） | Contact + Lifecycle Stage | HubSpotにはLeadオブジェクトがないため、ライフサイクルステージで管理 |
| Activity（活動） | Engagement（エンゲージメント） | メール・電話・ミーティングのマッピング |
| Case（サポート案件） | Ticket（チケット） | ステータスのマッピングが必要 |
特に注意が必要なのは、Dynamics 365の「Lead」オブジェクトです。Dynamics 365ではリードと連絡先が別オブジェクトとして管理されますが、HubSpotではすべて「コンタクト」として管理し、ライフサイクルステージで状態を区別します。この設計の違いを正しく理解しないと、データ移行後に混乱が生じます。
データ同期の設計では、以下の3つの要素を明確にする必要があります。
同期の方向: 一方向同期（Dynamics 365 → HubSpot、またはHubSpot → Dynamics 365）か、双方向同期かを決定します。並行運用の場合は双方向同期が必要ですが、競合処理（同じレコードが両方で更新された場合の優先ルール）を事前に設計しておく必要があります。
同期の頻度: リアルタイム同期、定期バッチ同期（15分〜24時間）、手動同期のいずれかを選択します。営業活動のデータはリアルタイム同期が望ましく、マスターデータの更新は日次バッチで十分なケースが多いです。
同期の範囲: すべてのレコードを同期するか、特定の条件に合致するレコードのみを同期するかを決定します。不要なデータの同期はコストとパフォーマンスの両面で影響があるため、対象を絞り込むことが推奨されます。
HubSpotのApp Marketplaceには、Microsoft Dynamics 365との連携アプリが提供されています。基本的なコンタクト・会社・取引の同期はこのネイティブ連携で対応できます。
より複雑な連携要件がある場合は、iPaaS（Integration Platform as a Service）の活用が効果的です。
| ツール | 特徴 | 適するケース |
|---|---|---|
| Microsoft Power Automate | Microsoft製品との親和性が高い | 既にMicrosoft 365を利用中の企業 |
| Zapier | ノーコードで設定が容易 | シンプルな連携要件 |
| Make（旧Integromat） | 複雑なデータ変換に対応 | フィールドマッピングが複雑 |
| Workato | エンタープライズ向けの高信頼性 | 大量データ・ミッションクリティカル |
HubSpotとDynamics 365はともに豊富なAPIを提供しています。既存の連携ツールでは対応できない要件がある場合は、カスタムAPI連携を開発することも選択肢になります。ただし、開発・保守のコストが発生するため、ネイティブ連携やiPaaSで対応できないかを先に検討すべきです。
移行対象のデータ量、カスタマイズの範囲、連携している外部システムを洗い出します。Dynamics 365のカスタムエンティティやワークフローの棚卸しを行い、HubSpotで再現が必要な機能を特定します。
移行前にDynamics 365内のデータをクレンジングします。重複レコードの統合、不要なレコードのアーカイブ、フィールド値の標準化を実施します。移行後にクレンジングするよりも、移行前に実施する方が効率的です。
前述のフィールドマッピング表に基づいて、HubSpot側のカスタムプロパティを作成します。Dynamics 365のカスタムフィールドに対応するプロパティをHubSpotに用意し、データ型（テキスト、数値、日付、ドロップダウンなど）を揃えます。
本番移行の前に、小規模なテストデータで移行を実施します。データの整合性、関連付け（アソシエーション）の正確性、ワークフローの動作を検証します。
テスト移行で問題がないことを確認した後、本番移行を実施します。移行期間中のデータ入力ルール（どちらのシステムに入力するか）を明確にし、チーム全体に周知します。
Volkswagen Group Japanでは、複数のシステムに分散していた顧客データをHubSpotに統合することで、マーケティングと営業の連携を強化しています。CRMの統合プロジェクトでは、段階的な移行アプローチが成功の鍵となっています。
データの競合（同じレコードが両方で同時に更新される）は起こりえます。対策として、「最終更新日時が新しい方を優先する」「特定のフィールドはDynamics 365をマスターとする」といったルールを事前に設定しておくことが重要です。iPaaSツールの多くは、競合解決のルールを設定する機能を備えています。
Dynamics 365のワークフローやPower Automateのフローを、HubSpotのワークフローに直接変換する機能はありません。ただし、HubSpotのワークフロー機能で同等のロジックを再構築することは可能です。複雑なビジネスルールは、移行の機会に業務プロセスを見直し、シンプル化することをおすすめします。
HubSpotのレポート機能で多くのレポートを再現できます。ただし、Dynamics 365のPower BIとの統合によるAdvanced Analyticsは、HubSpotの標準レポートでは対応しきれない場合があります。その場合は、HubSpotのデータをGoogle Looker StudioやTableauに接続して高度な分析を行うアプローチが有効です。
データ量とカスタマイズの複雑さによりますが、一般的な目安は以下の通りです。小規模（コンタクト数千件、カスタマイズ少）で2〜4週間、中規模（コンタクト数万件、一定のカスタマイズ）で1〜3ヶ月、大規模（コンタクト10万件以上、複雑なカスタマイズ）で3〜6ヶ月程度を想定してください。
カテゴリ: HubSpot連携・エコシステム | HubSpot