CDP（カスタマーデータプラットフォーム、顧客データ基盤）導入の必要性は、4つの軸で判断できます。繋ぐデータ源の数、セグメントを渡す配信先、ID 統合と連携を維持する人、費用が何に比例して増えるかです。データ源がカートだけで、配信先が LINE とメール程度なら、CDP の機能の大半は使いません。データ源が4つ以上あり、専任の運用担当を置ける場合に、CDP を検討する意味が出てきます。
この記事で明らかにすること
- CDP の必要性を判断する4つの軸と、条件別の当てはまる型
- カート標準機能・軽量統合基盤・CDP の3つの型の違い
- 5つの比較軸で見た3つの型の比較表（各社公式ページの事実のみ）
- 導入前に確認すること（データの持ち出し、ID 連携率、見積もりの前提）
この記事では特定の製品を推奨しません。各社の公式ページで確認できた事実（2026年10月7日時点。一部は10月27日に再確認）だけを表に入れ、金額が公開されていないものは「公開なし」と書きます。
CDP（顧客データ基盤）が必要かを決める4つの判断軸
ベンダーから CDP の提案を受けている。マーケ担当からは「LINE と購買データを繋ぎたい」と言われている。年額の妥当性を判断したいが、自社の規模で本当に必要なのかが分からない。そうした状況では、製品の機能一覧より先に、自社の条件を4つの問いで確かめます。
- 繋ぐデータ源はいくつあるか: カートだけか、実店舗の POS、別ブランドのカート、広告、サポート履歴まであるか。データ源が1つなら、統合という問題自体が起きません
- セグメントをどこに渡したいか: カートのメール機能で足りるか、LINE に購買条件で配信したいか、広告やアプリ通知など多数の配信先に送りたいか
- 連携と ID 統合を維持する人がいるか: SQL を書ける人が1名いるか、ベンダーとの導入プロジェクトと日々の運用に専任担当を置けるか
- 費用が何に比例して増えるか: CDP には MTU（月間に追跡するユーザー数）で課金する製品があります。今の顧客数ではなく、2年後の顧客数で見積もったときに払えるか
この4つの答えを、次の表に当てはめます。
| 自社の条件 | 当てはまる型 | 理由 |
|---|---|---|
| データ源はカートだけ。配信はカートのメール機能で足りる | カート標準機能 | 統合の必要がない。追加の費用も人も要らない |
| データ源はカートだけだが、LINE に購買条件で配信したい | 軽量統合基盤 | 必要なのは ID 連携のテーブルと LINE への出口だけ。CDP の機能の大半を使わない |
| データ源が2〜3つ（カート + POS など）で、配信先は LINE とメール。SQL を書ける人がいる | 軽量統合基盤 | ID 統合のルールを自社で決められる規模。運用が1人に依存する点だけ対策する |
| データ源が4つ以上、配信先も多数、専任の運用担当を置ける | CDP | コネクタと ID 統合を自前で維持する手間が、ライセンス費を上回りやすい |
2行目の条件（カート + LINE）で MTU 課金の CDP を入れると、使わない機能の分も顧客数に応じて払う形になります。逆に4行目の条件で軽量基盤を内製すると、コネクタの保守に人が取られます。データ源の数の境目（2〜3つと4つ以上）は編集部が置いた目安で、配信先の数や運用体制と合わせて判断します。
以下では、表に出てくる3つの型の中身と、比較の根拠を順に示します。
3つの型: カート標準機能・軽量統合基盤・CDP
顧客データの統合は「CDP を入れるか、入れないか」の二択ではありません。規模と目的に応じて3つの型があります。
| 型 | 中身 | 例 |
|---|---|---|
| カート標準機能 | EC カートが持つ顧客一覧とセグメント機能。データ源はカート内に限られる | Shopify の顧客セグメント |
| 軽量統合基盤 | 自社のデータベースに注文・顧客・LINE の ID 連携テーブルを置き、SQL でセグメントを作って配信先の API に渡す。内製または小規模な連携ツール | 自社 DB + LINE Messaging API |
| CDP | 複数のデータ源を取り込み、ID を統合し、セグメントを多数の配信先に送る専用製品 | Segment、Treasure Data |
「ツール型（配信ツールのタグ管理）」はここに含めていません。タグ管理は顧客データの統合ではなく配信の設定なので、比較の対象が違います。既存CRMを活かすか、移行するかの判断は、LINE CRM移行チェックリストで扱っています。
5つの比較軸で見た3つの型
判断軸を、製品を比べるための5つの軸に置き換えて表にしました。機能の多さではなく、自社の条件に当てはめて確かめられる軸を選んでいます。
- 接続できるデータ源: 判断軸1に対応。カート以外に何を繋げるか
- ID 統合の方法: EC の顧客 ID と LINE のユーザー ID を、誰が同一人物として結ぶか
- セグメントの出口: 判断軸2に対応。作ったセグメントを配信先に渡せるか。渡せないセグメントは分析用にしかならない
- 課金単位: 判断軸4に対応。固定か、MTU か、問い合わせ制か。金額が公開されていなくても課金単位は比べられる
- 導入にかかる人と期間: 判断軸3に対応。設定する人、運用する人、動き出すまでの期間
| 軸 | カート標準機能 | 軽量統合基盤 | CDP |
|---|---|---|---|
| 接続できるデータ源 | カート内の顧客・注文データ | 自社 DB に取り込めるものすべて（取り込みは自前） | 多数のコネクタ（データ連携が製品機能） |
| ID 統合の方法 | カートの顧客 ID 単位 | ID 連携テーブルを自前で設計（メール・電話・LINE UID） | ID 統合が製品機能 |
| セグメントの出口 | Shopify の場合、Shopify Messaging でのマーケティングメッセージ送信。外部ツールへの連携はヘルプページに記載なし | 配信先 API に直接渡す（LINE のオーディエンスなど） | 多数の配信先（アクティベーション先）に送る |
| 課金単位 | カートの契約に含まれる（セグメント機能自体の追加料金はヘルプページに記載なし） | DB・サーバー費 + 開発・運用の人件費 | Segment: MTU 単位、CDP プランは問い合わせ制。Treasure Data: 公式トップに金額の記載なし |
| 導入にかかる人と期間 | 担当者が管理画面で設定。即日 | SQL を書ける人1名 + 配信先 API の実装。数週間 | ベンダーとの導入プロジェクト。コネクタ設定と運用担当が必要 |
出典: Treasure Data（2026-10-07 取得）、Shopify ヘルプ 顧客セグメント、Twilio Segment 料金（いずれも 2026-10-27 取得）。導入期間の「即日」「数週間」は編集部の目安です。「記載なし」はそのページに書かれていないという意味で、できないという意味ではありません。
比較表の補足 — ID統合のルール、LINEへの渡し方、課金単位、導入の人手
データ源と ID 統合
データ源がカートだけなら、統合の問題は起きません。実店舗の POS や別ブランドのカートがあると、同じ人が別の顧客 ID で存在するため、ID 統合が必要になります。軽量統合基盤ではメール・電話番号の一致で結ぶテーブルを自前で設計し、CDP では ID 統合が製品機能として用意されています。どちらも「何を一致の条件にするか」は自社で決める必要があり、製品が自動で決めてくれるわけではありません。
セグメントの出口
LINE に渡すことが目的なら、出口の仕様が判断材料になります。LINE の Messaging API では、ユーザー ID の一覧をオーディエンスとして登録し（JSON で最大10,000件、ファイルで最大1,500,000件、保存期間180日）、そのオーディエンスにナローキャスト（条件を指定した配信）で送ります。軽量統合基盤はこの API に直接ユーザー ID を渡す構成で、CDP は配信先コネクタの一つとして LINE を扱います。カート標準機能は、Shopify のヘルプページの範囲では Shopify Messaging でのメッセージ送信が記載されており、LINE への受け渡しには別の手段が必要です。
出典: オーディエンスを使用する（LINE Developers）（2026-10-07 取得）
課金単位
CDP の金額は公式ページで公開されていないことが多く、この記事でも金額は書きません。比べられるのは課金単位です。Segment は Monthly tracked users（MTU）に基づく課金で、CDP プランは営業への問い合わせと請求書払いのカスタム価格と記載されています。Treasure Data は公式トップページに金額の記載がなく、料金体系ページと無料相談への導線があります。MTU 課金は顧客数が増えるほど上がる構造なので、見積もりは2年後の顧客数で取ります。
軽量統合基盤はライセンス費がない代わりに、DB とサーバーの費用、構築する人の時間、運用する人の時間がかかります。金額は小さくても、SQL を書ける人がいなくなると止まる点が制約です。
導入にかかる人と期間
カート標準機能は担当者が管理画面で設定でき、即日使えます。軽量統合基盤は、注文データの取り込み・ID 連携テーブル・配信先 API の3つを作る必要があり、SQL と API を扱える人が1名いれば、数週間で動く規模です（編集部の目安）。CDP はベンダーとの導入プロジェクトになり、コネクタの設定とデータの定義、運用担当の配置が必要です。
導入前に確認すること
- データの持ち出し: どの型でも、顧客データをエクスポートできるかを先に確認します。乗り換えるときに困るのはここです
- ID 連携率: LINE に渡す場合、EC の顧客のうち LINE の ID と結べている割合が配信対象の上限になります。連携率が低いと、どの型を選んでも配信対象は小さいままです
- 運用する人: 軽量基盤は SQL を書ける人、CDP は運用担当者が要ります。いない場合は、人を確保するか、カート標準機能の範囲に留めるかを先に決めます
- 見積もりの前提: MTU 課金は顧客数の増加で上がります。2年後の想定顧客数で見積もりを取り直します
まとめ
- CDP の必要性は、データ源の数・配信先・運用する人・費用の伸び方の4つの軸で判断する
- 顧客データの統合は「カート標準機能 / 軽量統合基盤 / CDP」の3つの型で考え、CDP か否かの二択にしない
- データ源がカートだけで LINE に配信したいなら、必要なのは ID 連携と出口であり、軽量統合基盤の範囲で足りる
- CDP の金額は多くが非公開。課金単位（MTU など）を確かめ、2年後の顧客数で見積もる
統合した購買データを施策に落とす手順は、購買データから始めるLTV改善ガイドとRFM分析のやり方で扱っています。