ECカートとCRMの連携設計とは、注文データを丸ごと移す作業ではなく、どの情報をカート側に残し、どの情報をCRMに持つかの境界を決める作業です。 カートは正確な取引記録を持つ場所、CRMは顧客との関係の状態を持つ場所、という役割分担が出発点になります。 この線引きを先に決めておくと、レコード数を増やさずに「次に何を送るか」が判断できる状態になります。
「連携はできたが、コンタクトが数万件に増えただけで何も変わらない」——EC事業でCRMを導入した会社から、よく聞く話です。
原因のほとんどは、連携の設定ミスではありません。何のためにデータを移すのかを決めないまま、移せるものを全部移したことにあります。注文明細を1件ずつCRMに持たせても、送るメールの内容が変わらなければ意味がありません。逆に、注文金額の累計と最終購入日さえあれば、施策は動き出します。
この記事では、HubSpotを例に、ECカートとCRMの連携をどう設計するかを整理します。自社ECを運営していてCRM導入を検討している方、すでに連携したが活用しきれていない方に向けた内容です。次の4点がわかります。
- どこまでCRMに持つかの境界線 ── カート側に残すべき情報との線引きです
- 受け皿になるオブジェクトの選び方 ── コンタクト・会社・カート・注文の役割分担です
- 同期の方向とキー設計 ── 二重登録を防ぐための突合キーの決め方です
- 連携後に何を自動化するか ── 放棄カート・再購入・休眠復帰の考え方です
読み終える頃には、自社のEC連携で何を持ち何を持たないかの方針が立つ状態になります。ぜひ最後までご確認ください。
連携がうまくいかないのはデータ量の問題ではない
まず、なぜ「全部移す」がうまくいかないのかを整理します。
新規獲得より既存顧客の深耕が効く局面
総務省統計局の家計消費状況調査によれば、2026年5月のネットショッピング支出額は1世帯当たり26,606円で、前年同月の26,047円から名目2.1%の増加でした。一方、ネットショッピングを利用した世帯の割合は55.3%で、前年同月の56.2%から0.9ポイント低下しています。利用した世帯だけで見た1世帯当たりの支出額は48,102円で、前年同月比3.8%の増加です(家計消費状況調査 ネットショッピングの状況について(二人以上の世帯)2026年5月分結果、令和8年7月7日公表)。
同じ調査の広報資料では、2025年のネットショッピング支出金額(1か月平均26,928円)の内訳として、食料が21.6%、旅行関係費が20.9%、衣類・履物が9.8%と示されています(家計消費状況調査通信 2026年7月発行)。
利用する世帯の割合は伸びていないのに、利用している世帯の支出は増えている——この数字が示すのは、新しくEC利用を始める層を待つより、すでに買っている顧客の購入頻度と単価を伸ばすほうが確度が高い局面だということです。
そしてそれを実行するために必要なのは、注文明細の全件ではありません。誰が、何を、いつ買って、次にいつ買いそうかという状態の情報です。
全件を移すと起きること
注文データを丸ごとCRMに流し込むと、次の3つが起きます。
- レコードが増えて動作が重くなる:1顧客あたり数十件の注文が並び、画面を開いても状況が読み取れません
- どちらが正しいか分からなくなる:返品やキャンセルがカート側で処理されたとき、CRM側の数字が古いまま残ります
- 施策に使えない:「先月3回買った人」を出したいだけなのに、明細から集計し直す作業が発生します
CRMに必要なのは明細ではなく、明細から導かれた状態です。
どこまでCRMに持つかの境界線
ここからが設計の本体です。どちらに何を置くかを決めます。

これは特定の企業の実装ではなく、EC事業でよく出てくる構造を一般化した設計例です。
判断の基準は「正確性か、判断か」
境界を決める基準はシンプルです。会計や在庫の正確性が問われるものはカート側、次のアクションを判断するための情報はCRM側です。
| 情報 |
置き場所 |
理由 |
| 注文明細・数量・税額 |
カート・受注システム |
会計と一致している必要があります |
| 在庫・出荷ステータス |
カート・受注システム |
リアルタイム性が最優先です |
| 返品・キャンセル処理 |
カート・受注システム |
処理の起点がそちらにあります |
| 累計購入金額・購入回数 |
CRM |
セグメントの条件に使います |
| 最終購入日・初回購入日 |
CRM |
休眠判定と復帰施策の起点です |
| よく買うカテゴリ |
CRM |
送る内容を変えるために使います |
| 問い合わせ・レビュー履歴 |
CRM |
人との接点の記録です |
明細を持つべき例外
例外もあります。BtoBの卸チャネルを持っている場合は、明細をCRM側にも持つ価値があります。掛率の交渉や与信の判断が、商談の中で行われるためです。この場合は、消費者向けの注文とは別の扱いにします。卸チャネルの設計は卸売業のHubSpot活用ガイドで扱っています。
配送を自社で持っている、あるいは物流会社と密に連携している場合は、拠点側の情報の持ち方も設計対象になります。この考え方は物流業のCRMデータ設計にまとめています。
受け皿になるオブジェクトを決める
境界が決まったら、CRM側のどのオブジェクトで受けるかを決めます。

コンタクトが中心になる
消費者向けECでは、コンタクトが管理の中心になります。会社オブジェクトを使うのは、卸チャネルや法人向け販売がある場合です。個人顧客に対して会社レコードを作る必要はありません。
カートオブジェクトを使う
HubSpotには、eコマースの購入情報を格納するカートオブジェクトがあります。カートオブジェクトはすべての製品とプランで利用でき、Shopifyや、NetSuite、WooCommerceなどの他のeコマースアプリで放棄されたカートの情報も含まれます。カートレコードにはコンタクト・会社・注文などの他のオブジェクトを関連付けられ、カートベースのカスタムレポートやセグメントの作成もできます(カートオブジェクトを表示する)。
つまり、放棄カートを受ける器は最初から用意されているということです。ここを自作のカスタムオブジェクトで作る必要はありません。
コンタクト側に持たせる集計項目
明細をCRMに持たない代わりに、コンタクト側に集計値を持たせます。最初に作るべきは次の3つです。
- 累計購入金額:セグメントの基準になります
- 最終購入日:休眠判定の起点です
- 購入回数:初回購入者とリピーターを分ける唯一の条件です
この3つがあれば、「3回以上買っていて、最終購入から90日経過している人」という抽出ができます。ここから施策が始まります。
集計をCRM側で計算する場合、HubSpotの計算プロパティーが使えます。各製品の Professional 以上で利用でき、ロールアップ集計では最小値・最大値・件数・合計・平均・最早の日付・最新の日付の7種類が使えます(計算プロパティーを作成する)。カート側で集計してから連携で渡す方法もあり、どちらでも構いません。
同期の方向とキー設計
技術的に最も事故が起きやすいのがここです。

原則は一方向
カートからCRMへの一方向を基本にしてください。 双方向にすると、同じ項目が両側で更新されたときにどちらが正しいか判定できなくなります。CRM側から書き戻したいケース(顧客ランクなど)がある場合も、項目単位で方向を固定します。「この項目はカートが正、この項目はCRMが正」と決めておけば衝突は起きません。
突合キーをメールアドレスにしない
EC連携で最も多い事故が、メールアドレスをキーにしたことによる二重登録です。次の状況で必ず崩れます。
- 顧客がメールアドレスを変更した
- 家族が同じアドレスで別会員として登録した
- ゲスト購入で毎回違うアドレスを使った
カート側の顧客IDをCRM側のプロパティーとして持ち、それをキーにするのが安全です。メールアドレスは連絡先であって、識別子ではありません。
同期する項目を最初に絞る
連携ツールの設定画面には、同期できる項目が数十個並びます。ここで全部にチェックを入れないでください。最初は10項目以内に絞り、運用が回ってから足します。項目を足すのは簡単ですが、一度入れた項目を消すのは、それを使ったリストやワークフローを止める作業を伴います。
返品・キャンセルの反映
集計値を持つ以上、返品時の扱いを決める必要があります。選択肢は2つです。
- 返品分を差し引いて再計算する:数字は正確になりますが、連携の作り込みが増えます
- 返品は集計に反映せず、返品回数を別項目で持つ:実装が軽く、返品の多い顧客の把握もできます
売上の管理はカート側で行うのが原則なので、CRM側は後者で十分なことが多いというのが実務での感覚です。
連携後に何を自動化するか
連携そのものは目的ではありません。つないだ後に何をするかを決めておきます。
最初に着手する3つ
- 放棄カートのフォロー:カートオブジェクトに放棄カートの情報が入るため、これを起点にできます。ただし送りすぎると解除されます。24時間後に1通が現実的な起点です
- 初回購入後のフォロー:2回目の購入までの離脱が最も大きいため、ここに手を入れる価値が最も高くなります
- 休眠の検知:最終購入日から一定期間が経過した顧客を抽出します。カテゴリによって適切な日数が違うため、まず自社の購入間隔の中央値を確認します
定期購入がある場合
定期購入・サブスクリプション型の商品がある場合は、解約防止の設計が別途必要になります。更新のタイミング管理や解約予兆の扱いはHubSpotでサブスクリプション売上を管理する方法で扱っています。
効果を測れる形にしておく
自動化を始める前に、何をもって効果があったと判断するかを決めておいてください。ここを決めずに走らせると、送り続けているのに止め時が分からなくなります。
判断に使う数字は、次の3つで足ります。
| 施策 |
見る数字 |
判断の目安 |
| 放棄カートのフォロー |
送信後7日以内の購入率 |
送らなかった群と比べて上がっているか |
| 初回購入後のフォロー |
2回目購入までの日数の中央値 |
短くなっているか |
| 休眠の復帰 |
復帰率と配信停止率 |
復帰率より配信停止率の増加が大きくないか |
特に3つ目は必ず両方を見てください。 休眠顧客への配信は、復帰する人より離脱する人のほうが多くなることがあります。片方だけを見ていると、効果があったように見えて母集団を削っています。
やりすぎないこと
自動化は増やすほど効くわけではありません。メールの通数が増えると、配信停止も増えます。まず3つに絞り、開封率と配信停止率を見ながら足していくのが安全です。EC・D2C全体でのHubSpot活用はEC・D2C事業者のHubSpot活用法にまとめています。
よくある質問
ECカートとCRMの連携について、ご相談の場でよくいただく質問をまとめました。
Q1. HubSpotのCommerce機能を使えば、カートは不要になりますか。
なりません。HubSpotの決済・商取引機能は、請求や支払いリンクを扱うもので、在庫管理や配送設定を含む本格的なEC構築を置き換えるものではありません。既存のカートを残し、CRMは顧客側の情報を持つという構成が現実的です。両者の比較はHubSpot Commerce Hub と Shopify の比較で扱っています。
Q2. 注文明細をCRMに持たないと、何が見えなくなりますか。
「誰が何を買ったか」の商品単位の分析がCRM側だけでは完結しなくなります。ただし、これはカート側の分析機能で見るほうが正確で速いのが実情です。CRM側では、購入カテゴリの傾向をコンタクトのプロパティーとして持つ(例:直近購入カテゴリ)ことで、メールの出し分けには十分対応できます。全明細を持つのは、それが必要だと分かってからで遅くありません。
Q3. ゲスト購入のデータはどう扱うべきですか。
コンタクトとしては作成しますが、マーケティングの配信対象とは別に扱ってください。ゲスト購入者は会員登録をしていない=継続的な連絡に同意していない可能性が高いためです。同意の状態はプロパティーで明確に持ち、配信対象のリストは同意ベースで作ります。ここを曖昧にすると、配信停止と苦情が増えます。
Q4. 複数のECモールにも出店しています。モールの注文も同じCRMに入れるべきですか。
顧客情報が取得できる範囲でのみ入れてください。モールによっては購入者のメールアドレスが提供されないため、その場合はCRMに入れても連絡できません。チャネルを識別するプロパティーを必ず持たせたうえで、自社ECの顧客とモール経由の顧客を分けて集計できる状態にしておきます。混ぜると、施策の効果が測れなくなります。
Q5. 連携はどこから着手すればよいですか。
コンタクトの基本情報と、累計購入金額・最終購入日・購入回数の3項目だけから始めてください。この状態で1か月運用し、実際に使ったセグメントを確認します。使わなかった項目を後から足しても遅くありません。最初から完全な連携を目指すと、設計に時間がかかったうえに大半の項目が使われないまま残ります。
関連記事
まとめ
ECカートとCRMの連携設計は、つなぐ作業ではなく、境界を決める作業です。要点を整理します。
- 正確性が問われるものはカート、判断に使うものはCRM。これが唯一の判断基準です
- 明細ではなく状態を持つ。累計購入金額・最終購入日・購入回数の3つから始めます
- 放棄カートの器は標準で用意されている。カートオブジェクトはすべてのプランで使えます
- 同期は一方向、キーは顧客ID。メールアドレスをキーにすると必ず二重登録が起きます
- 同期項目は最初10個以内に絞る。足すのは簡単、消すのは大変です
- 自動化は3つまで。通数を増やすほど配信停止が増えます
最初の一歩としておすすめしたいのは、「自社の顧客の購入間隔の中央値を出す」ことです。この1つの数字が分かるだけで、休眠と判定すべき日数も、フォローを送るタイミングも決まります。逆にこれが分からないまま連携しても、送る時期を決められません。
そのうえで、コンタクトに3つの集計項目を持たせ、1つのセグメントを作って試す。ここから始めるのが現実的です。
自社のECとCRMの連携設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在のカート構成と施策の狙いをうかがったうえで、境界の引き方をご提案します。