【完全ガイド】Composable CDP vs パッケージCDP 徹底比較：Snowflake+dbt+Hightouch型と統合パッケージ型の判断軸

「パッケージ CDP（Treasure Data / Adobe RT-CDP）が高すぎて予算が組めない」「Composable CDP に切り替えたいが、自社で運用できるか不安」「Snowflake + dbt + Hightouch の構成で本当にパッケージ CDP の代替になるのか」 — このような声を、Aurant では中堅 BtoC 企業のデータ部門・マーケ部門・CDO 配下からよくいただきます。

2023〜2025年で CDP 業界に大きな潮流の変化が起きました。「Composable CDP」と呼ばれる、自社の DWH（Snowflake / BigQuery / Databricks）を中核に据えて Reverse ETL（Hightouch / Census）と組み合わせる構成が、従来の「パッケージ CDP」（Treasure Data / Twilio Segment / Adobe RT-CDP）の代替として急速に広がっています。

本記事では、Composable CDP とは何か、パッケージ CDP との本質的な違い、料金・機能・運用体制の比較、判断フレームワーク、移行パターン、運用体制 / セキュリティ / 3年 TCO の差別化視点まで、論理ステップで整理していきます。

1. Composable CDP とは — DWH + dbt + Reverse ETL の3層構成

Composable CDP の構成はシンプルで、「DWH（データ蓄積）+ dbt（変換 / モデリング）+ Reverse ETL（業務システム書き戻し）」の3層です。代表的な組み合わせは、Snowflake + dbt + Hightouch、もしくは BigQuery + dbt + Censusです。Identity 解決は DWH 内で SQL で書き、配信は Braze / Marketo / Salesforce Marketing Cloud と連携します。

1-1. Composable CDP の本質

Composable CDP の本質は、「CDP の各機能を、それぞれ最適なツールに分散させる」ことです。データ蓄積は DWH、変換は dbt、配信は専用ツール、というように分業させ、自社で組み合わせます。パッケージ CDP のように「1ベンダーで全機能カバー」のメリットは失いますが、各機能を最強のツールで構成できるメリットを得ます。

1-2. なぜ Composable CDP が広がっているか

Composable CDP が急速に広がっている背景には、「パッケージ CDP の高コスト」「DWH（Snowflake / BigQuery）の普及」「Reverse ETL ツール（Hightouch / Census）の成熟」「dbt の業界標準化」の4つの変化があります。これら4つが揃って初めて、Composable CDP が現実的な選択肢になりました。

2. パッケージ CDP との本質的な違い — データの所在と統制

両者の最大の違いは、「データが自社管理の DWH にあるか、ベンダー管理の CDP にあるか」です。

2-1. データの所在

パッケージ CDP では、データがベンダー側に蓄積されます。Composable CDP では、データは自社の Snowflake / BigQuery にあり、ベンダーは「ツール」として外側に配置されます。

2-2. ベンダーロックイン

この違いは「データ移植性」と「ベンダーロックイン」に直結します。パッケージ CDP は移行が困難（データの抽出・再投入が大規模工事になる）。Composable CDP は DWH 中心なので、Reverse ETL ツールを乗り換えても DWH 内のデータは無傷です。長期的にはこの柔軟性が大きな価値を生みます。

3. 料金比較 — 中規模では Composable が有利

料金面では、中規模（年商 50〜500億）では Composable が圧倒的に安くなります。

3-1. Composable CDP の料金内訳

中堅企業の標準構成例: Snowflake / BigQuery 月額数十万円〜、dbt Cloud 月額数十万円、Hightouch / Census 月額数十万円〜100万円。年額合計で 1,000〜3,000万円に収まります。

3-2. 大規模で拮抗する理由

超大規模（年商 1,000億超）では拮抗してきます。データ量が増えると Snowflake / BigQuery の従量課金が膨らみ、Composable のコストメリットが薄れます。一方、パッケージ CDP も MTU / レコード数で価格が伸びます。「企業規模で素直に決まる」のが料金面の結論で、中規模 BtoC のスタートアップ〜中堅は Composable、エンタープライズ大手で SaaS 連携が多いならパッケージ、という棲み分けです。

4. 機能比較 — Identity 解決と即時配信で差が出る

機能面の差は2点あります。

4-1. Identity 解決

パッケージ CDP はIdentity Graph や Profile Stitching を「機能」として持っているのに対し、Composable はSQL で自前構築する必要があります。複雑な名寄せ（決定的 + 確率的マッチング）を組むなら、パッケージ側に分があります。

4-2. 即時配信

パッケージ CDP の Reverse ETL は秒〜分オーダーが標準ですが、Composable は通常15分〜1時間のバッチです。リアルタイム性を強く求めるなら、パッケージ側か、専用ツール（Braze、KARTE）併用です。

4-3. Composable の優位 — SQL の柔軟性

逆に Composable の優位は、SQL で何でも書ける柔軟性です。複雑な集計、独自の LTV 計算、機械学習モデルの推論結果との統合などは、SQL で自由に組めます。パッケージ CDP では「製品の機能の枠内」で実装するため、複雑な要件には限界があります。

5. 運用体制の違い — 必要なスキルセットが変わる

Composable CDP は、「データエンジニア + dbt が書けるアナリティクスエンジニア」が社内に必要です。

5-1. Composable CDP の人材要件

SQL で Identity 解決やセグメント抽出を書くため、これを保守できる人がいないと運用できません。逆に、これらの人材がいれば、ベンダーロックインなしで自由に拡張できます。

5-2. パッケージ CDP の運用体制

パッケージ CDP は、「マーケティングオペレーターと、ベンダーサポート」で運用が回ります。GUI 中心で、SQL を書かなくてもセグメント抽出ができる（ただし複雑な要件はベンダー連絡が必要）。社内エンジニアが少ない企業はパッケージが向きます。

5-3. 組織能力が選定要因

「自社のエンジニア層 / アナリスト層の厚み」が選定の決定要因の1つです。技術的判断より「組織能力」の判断が選定の本質になります。

6. セキュリティ・ガバナンス — Composable はゼロから設計

セキュリティ面では、パッケージ CDP は標準で個人情報保護機能（マスキング、アクセス制御、監査ログ）が組み込まれているのが利点です。

6-1. Composable のセキュリティ設計

Composable では DWH 側で同等機能（BigQuery のポリシータグ、Snowflake のマスキングポリシー）を設定する必要があり、設計工数がかかります。データガバナンス全体（データカタログ、データリネージ）も、Composable は別途ツールを組み合わせる必要があります。

6-2. 規制業界の選定

金融・医療・公共のような規制業界では、パッケージ CDP の「セキュリティ機能の組み込み」が選定上の優位になります。一方、Composable でも DWH 標準機能 + Atlan / DataHub / Dataplex を組み合わせれば同等のガバナンスを構築可能です。設計能力さえあれば Composable の方が柔軟性が高くなります。

7. 判断フレームワーク — 5つの問いで決まる

Composable vs パッケージの判断は、5つの問いで機械的に決められます。

5問のうち3問以上が「Composable 寄り」なら Composable、3問以上が「パッケージ寄り」ならパッケージ。中間的な企業（2-3問が分かれる）は、まずパッケージで導入して、3〜5年運用後に Composable への移行を検討する、という段階的な道もあります。

8. Composable CDP の標準スタック

9. 移行パターン — パッケージ → Composable のリプレース

2024〜2025年で増えているのが、「既存のパッケージ CDP（特に Treasure Data や Adobe RT-CDP）から、Composable CDP への移行」パターンです。

9-1. 移行の動機

移行動機は「予算圧縮、社内エンジニア人材の充実、データ移植性確保」などが多くあります。年額 5,000万円のパッケージ CDP を、年額 2,000万円の Composable CDP に置き換える試算が、経営判断として通りやすいケースが増えています。

9-2. 段階的移行の標準

移行は段階的に行うのが定石です。最初の半年で並行運用（既存 CDP と Composable の双方にデータを送る）、次の半年でセグメント / Audience の Composable 側への移管、その後 1年でパッケージ CDP の段階的縮退、という流れです。

9-3. 移行スケジュール

「一気に切り替え」は配信効果の継続性が崩れるので避けます。Aurant の支援案件では、この移行に 1.5〜2年を見積もるのが標準です。

10. 運用体制の現実 — データチーム + マーケ部門

ここから3つの差別化セクションに入ります。

10-1. データチーム編成

Composable CDP の運用には、データエンジニア 2〜3名 + アナリティクスエンジニア 1〜2名 + データアナリスト 1〜2名の合計 5〜7名規模が必要です。これより少ないと、運用 / 品質 / 改善のいずれかが手薄になります。

10-2. マーケ部門との連携

セグメント定義 / 配信戦略はマーケ部門が主導し、データチームが SQL 実装を担当する分業が標準です。マーケ部門の中堅メンバーが SQL を書ける状態を目指すと、より柔軟な運用が可能になります。

10-3. dbt モデルのガバナンス

dbt モデルが乱立すると保守不能になるため、「dbt モデルの命名規約・ディレクトリ構造・レビュープロセス」を最初に整備します。GitHub での Pull Request レビュー、dbt のテスト機能の必須化、CI/CD でのデプロイなどが標準です。

11. セキュリティ・データガバナンス — DWH 標準機能の活用

11-1. BigQuery のポリシータグ

BigQuery のカラム単位ポリシータグで、個人情報カラムを「PII」「Confidential」と分類します。これを Data Catalog で管理し、アクセス権限と連動させます。

11-2. Snowflake のマスキングポリシー

Snowflake ではマスキングポリシーで、ロールに応じてカラム値を動的にマスクします。セグメント抽出時に PII カラムを自動マスクする運用が可能です。

11-3. データガバナンスツールの併用

大規模運用では、Atlan / DataHub / Dataplexなどのデータガバナンスツールを併用します。データカタログ、リネージ、品質スコアの統合管理を実現します。

12. 3年 TCO 内訳

13. 失敗パターン

13-1. 「DWH を持っていない状態で Composable を選ぶ」

DWH 構築から始めると、Composable CDP 全体の本格運用まで 2〜3年かかります。打開策は、まず DWH 単独で実用化してから Composable CDP に進むことです。

13-2. 「dbt が書けるエンジニアがいない状態で Composable を選ぶ」

Reverse ETL ツール（Hightouch / Census）まで導入したが、SQL のメンテができず、運用が回らないケース。打開策は、SQL / dbt スキルのある人材採用 / 育成、もしくはパッケージ CDP への切り戻しです。

13-3. 「dbt モデル乱立で保守不能」

dbt モデルが数百以上に膨らみ、誰も全体像を把握できなくなるケース。打開策は前述の dbt モデルガバナンス（命名規約・レビュープロセス・テスト必須化）です。

14. まとめ — 自社状況別の判断軸

判断のコツは、「5問の判断フレームワークで機械的に絞る」「組織能力で判断（DWH + dbt 人材の有無）」「移行は1.5〜2年スパンで段階的に」「dbt モデルガバナンスを最初に整備」の4点です。

Composable vs パッケージ CDP の判断は、技術より「組織能力」の問題が大きく成否を分けます。Aurant Technologies では Composable CDP の設計から内製化伴走、パッケージ CDP からの移行までトータルでご支援しています。お気軽にご相談ください。