コンポーザブルCDPとは？仕組みと導入メリットを解説

コンポーザブルCDPとは、単一の統合プラットフォームを導入するのではなく、Customer Intelligence Loop（顧客データの収集・統合・活用を継続的に回す仕組み）の各段階を担うモジュール型のベストオブブリードなツールを組み合わせることで、CDPの機能を実現するアプローチである。 多くのコンポーザブルCDPはウェアハウスネイティブであり、既存のクラウドデータウェアハウス（Snowflake、BigQuery、Databricksなど）を基盤とし、名寄せ、セグメンテーション、データアクティベーションのための専用ツールを追加する。

コンポーザブルCDPのアーキテクチャ。データソースはクラウドデータウェアハウスに集約され、そこで名寄せ、データモデリング、機械学習が実行される。続いてアクティベーションレイヤーがオーディエンスをセグメント化し、ペイドメディア、メッセージングプラットフォーム、AIエージェントへ振り分ける。リアルタイムキャッシュを介して、セッション中のパーソナライズをAPI経由で実現する経路も用意されている。

顧客データをすべて自社専用のCDPデータベースへ集約するのではなく、コンポーザブルなアプローチでは統合顧客プロファイルをウェアハウスに置いたまま、リバースETLを介したコネクタでオーディエンスと属性を下流のマーケティング・分析ツールへ同期する。CDPの全体像については、CDP（カスタマーデータプラットフォーム）とは何かを参照してほしい。

コンポーザブルソフトウェアという考え方

コンポーザブルソフトウェアとは、モノリシックなアプリケーションではなく、独立して交換可能なモジュールを組み合わせてシステム基盤を構築するアプローチである。中核となるアプリケーションは専門化されたマイクロサービスに分割され、それらがAPIを介して連携することで、スケールしやすく開発スピードも上がる。プラットフォーム型アーキテクチャ（交換可能なモジュールが共有の中核システムに依存する構成）とは異なり、コンポーザブルなシステムでは他のスタックに影響を与えずに各コンポーネントを差し替えられる。コンポーザブルCDPは、この同じモジュール型の思想を顧客データの技術スタックに適用したものである。

コンポーザブルCDPとは何か

「コンポーザブルCDP」という用語は2021年頃に登場した。すでに最新のクラウドウェアハウスに顧客データを集約できているデータチームが、従来型のオールインワンCDPが本当に必要なのかを問い直し始めたことがきっかけである。コンポーザブルという発想は、より広いコンポーザブルソフトウェアの原則を借用したものであり、モノリシックなシステムではなく交換可能なコンポーネントからソリューションを構築するという考え方である。

コンポーザブルCDPのアーキテクチャでは、データ取り込み、名寄せ、セグメンテーション、アクティベーションといった各機能を、それぞれ別のツールが担うことができる。例えば次のような構成である。

• データ取り込み：Webサイト、アプリ、CRMなどのソースから顧客イベントを収集し、ウェアハウスへ取り込むコネクタとパイプライン
• 変換とモデリング：生データを整形・結合し、統合顧客テーブルや計算済み属性を作り出すSQLベースのツール
• 名寄せ：匿名プロファイルと既知プロファイルを1つの顧客レコードへとつなぎ合わせる、決定的または確率的なマッチングロジック
• アクティベーション：ウェアハウスからマーケティングプラットフォーム、広告ネットワーク、CRMへオーディエンスと属性を同期させるリバースETLツール
• オーケストレーション：パイプラインの実行を統制し、データの新鮮さを監視し、依存関係を管理するスケジューラーとワークフローエンジン

ウェアハウスが唯一の信頼できる情報源となることで、データのサイロは解消され、顧客データを別のプラットフォームへ複製する必要もなくなる。実際にどのようなツールが使われているかは、後述する。

Customer Intelligence Loopとコンポーザブルな構成要素の対応関係

コンポーザブルであるかどうかを問わず、あらゆるCDPはCustomer Intelligence Loopの5つの段階を実行しなければならない。コンポーザブルなスタックでは、各段階を別々のベンダーやツールが担う。

このモジュール性は本物であり、エンジニアリング上の主導権を確保するうえで価値がある。ただし、アーキテクチャ上の代償にも注意が要る。エンゲージメントの結果（開封、クリック、コンバージョン）は、ESP → リバースETL → ウェアハウス → dbtによる再構築 → モデルの再学習という経路をすべて逆方向にたどってからでなければ、システムの学習に反映されない。

ウェアハウスネイティブな基盤

コンポーザブルCDPは、収集と統合の段階におけるストレージおよび計算基盤としてクラウドデータウェアハウスに依存する。顧客のイベントストリーム、トランザクション記録、サポートチケットなどのデータソースは、データ連携ツールを通じて取り込まれ、SQLやdbtのような変換フレームワークを用いて統合顧客プロファイルへとモデリングされる。

ウェアハウスにはすでに行動データ、トランザクションデータ、属性データが蓄積されているため、それらを別のCDP専用データベースへ複製する必要はない。アナリストやエンジニアは、使い慣れたSQLのワークフローで顧客データを照会・結合・拡張できる。

リバースETLによるアクティベーション

顧客プロファイルとセグメントがウェアハウス側で定義されると（統合と理解の段階）、リバースETLツールがエンゲージメントを担い、メールプラットフォーム（BrazeやIterableなど）、広告ネットワーク（Google AdsやFacebookなど）、CRM（SalesforceやHubSpotなど）、カスタマーサポートツール（ZendeskやIntercomなど）といった運用系システムへデータを送り出す。

リバースETLは、従来のETLの流れを逆転させたものだ。運用系ツールからウェアハウスへ抽出するのではなく、ウェアハウスから運用系ツールへ抽出する。これにより、マーケティングやカスタマーサクセスのチームは、コードを書いたりエンジニアリングの支援を待ったりせずに、ウェアハウスで定義したオーディエンスをアクティベーションできる。

モジュール型のアクティベーションと実験

各コンポーネントが疎結合であるため、必要に応じてツールを入れ替えられる。より高精度な名寄せベンダーが登場すれば、スタック全体を作り直さずにそのレイヤーだけを置き換えられる。新しいアクティベーションチャネルを試したい場合も、データモデルを再設計せずにコネクタを追加するだけでよい。この柔軟性こそがコンポーザブルスタックの強みだが、同時にAI活用における構造的な限界の源にもなっている。サイクル全体をベンダーの境界を越えずに完結させることが求められる場面では、この柔軟性が裏目に出る。

コンポーザブルCDPのメリットとデメリット

メリット

データの所有権とポータビリティ：顧客データは自社が管理するウェアハウスに残る。アクティベーションのベンダーを切り替えても、統合プロファイルはそのまま保たれる。

既存投資の活用：データパイプライン、dbtモデル、ウェアハウス基盤をすでに構築している場合、コンポーザブルCDPはそれらを置き換えるのではなく、拡張する形で機能する。

柔軟性とカスタマイズ性：SQLベースのモデリングにより、顧客属性の定義・算出・拡張をチームが完全にコントロールできる。ベンダーの機能リリースを待たずに、独自のビジネスロジックを組み込める。

導入初期のコスト効率：ウェアハウスベースのストレージと計算リソースは、エージェンティックCDPのプロファイル単価制やプラットフォーム型のライセンス費用と比べて、当初は経済的に見える場合が多い。

デメリット

価格が急速に膨らみやすい：コンポーザブルCDPは導入初期費用の低さを訴求することが多いが、データ量とアクティベーションの活用事例が増えるにつれて総保有コストは膨らんでいく。G2のレビューデータ（2025年）によれば、コネクタ数、同期頻度、処理行数が増えるにつれて予想外のコスト増を指摘する利用者は多く、エンタープライズ規模ではエージェンティックCDPの価格に近づく、あるいはそれを上回ることも少なくないという（エンタープライズ向けスイートも、CDP機能を使うためにエコシステム全体の料金を支払うスイート税という同種のコスト問題を抱えている）。

複雑性の高さ：コンポーザブルスタックの構築には、複数ツールの連携、依存関係の管理、コンポーネント間のデータ品質の確保が必要であり、高度なデータエンジニアリングの専門性が求められる。

価値実現までの時間が長い：あらかじめ機能が組み込まれたエージェンティックCDPと異なり、コンポーザブルアーキテクチャではデータモデリング、パイプラインのオーケストレーション、ツール連携への先行投資が必要になる。

AI機能の標準搭載が限定的：多くのコンポーザブルCDPは、理解と意思決定の段階を別のML基盤に依存している。追加のツールなしでは、組み込みのプロペンシティスコアリングやネクストベストアクションのレコメンデーションは得られない。しかもツールを追加するたびに、フィードバックサイクルが越えなければならないベンダーの境界がもう一つ増える。

保守負荷：スタックが拡大するほど、ベンダーをまたいだパイプラインの監視という運用負荷も増していく。意思決定とエンゲージメントの間の同期エラーのデバッグ、コネクタの更新、結果データが確実に収集の段階へ戻ってくるようにする作業などが、その内容である。

コンポーザブルとエージェンティックの3年間の総保有コスト比較

コンポーザブルCDPとエージェンティックCDPのコスト比較は、時間軸を通じた総保有コストをモデル化しなければ実態を見誤る。コンポーザブルスタックは導入初期費用が低い一方、アクティベーションの活用事例が増えるにつれて非線形にコストが拡大する。CDP市場は2028年までに282億ドル規模に達すると予測されており（MarketsandMarkets、2023年、CAGR 39.9％）、その成長の多くは、マルチベンダー構成のスタックを統合プラットフォームへ集約する企業によって支えられると見込まれている。

これらの数値は、公開されているベンダーの価格帯と2025年時点のG2レビューデータをもとに、アクティブプロファイル1,000万件、日次同期、下流ツール8件との連携、ESPの中間層契約を前提としてモデル化したものである。実際のコストはベンダー、データ量、同期頻度、活用事例の複雑さによって大きく異なる。コンポーザブルは単に「高い」わけではない。コンポーザブルのコストは乗算的に積み上がる（処理行数×コネクタ数×頻度×ツール数）のに対し、エージェンティックCDPの価格は多くの場合プロファイル単価制でアクティベーションを含む。この構造の違いが、両者のコスト差を生んでいる。

ベンダーの境界を越えるPIIの複製

コンポーザブルCDPは統合プロファイルをウェアハウスに保持するが、アクティベーションには依然として個人を特定できる情報（PII）を外部ツールへコピーする作業が伴う。メールアドレスや電話番号、顧客属性を別のESP、広告プラットフォーム、CRMへ送るリバースETLの同期は、そのたびに主要なデータ環境の外側にPIIのコピーをもう1つ作り出す。典型的なコンポーザブルスタックでは、顧客のPIIがウェアハウス、リバースETLツールの同期キャッシュ、各アクティベーション先という3つ以上のシステムに同時に存在しうる。

コピーが増えるたびに、コンプライアンス上の負荷も増していく。ベンダーごとに個別のGDPR第28条に基づくデータ処理契約が必要になり、削除リクエストの処理は遅くなり（3～5システムへの伝播には分単位ではなく日単位の時間がかかる）、侵害の対象範囲は広がって各システムで個別のSOC 2審査が必要になり、ベンダーが異なるリージョンにデータを保存している場合はデータの保存地域に関する複雑さも生じる。詳しいコンプライアンス分析については、CISOのためのCDPアーキテクチャガイドを参照してほしい。

日本市場で実際に導入されているコンポーザブルCDPの例

コンポーザブルCDPの市場には、リバースETL専業のツール、ウェアハウスネイティブなオーディエンス構築ツール、そしてコンポーザブルモードとマネージドCDPモードの両方を提供するハイブリッド型プラットフォームが含まれる。日本市場で実際に導入が進んでいる代表的な例として、Salesforce Data CloudとTreasure AI（旧Treasure Data）の2つが挙げられる。

Salesforce Data Cloud は、Salesforceのエコシステム内および外部のウェアハウスとの間でゼロコピーのデータ共有を行う。Salesforceの各プロダクトとウェアハウスをまたいで、データを複製せずに参照できる点が特徴である。

Treasure AI は、コンポーザブルCDPとコンプリートCDPの両方のモードを提供する。Composable Audience Studioは、Snowflake、BigQuery、Databricks上でゼロコピーの連携クエリを実行し、Complete CDPはリアルタイムプロファイル、ネイティブなメッセージング、AIによる意思決定を追加する。

海外にはリバースETL専業のベンダーなど、コンポーザブルCDPの構成要素を提供する企業がほかにも数多く存在し、その一部は国内リセラー経由で導入事例を持つ場合もある。ただし、CDPとしての機能を包括的に提供し、日本法人または直接的な日本語サポート体制を備えているという点では、上記の2社が実際に確認できる代表例である。詳細な機能とプランの比較は、コンポーザブルCDPベンダーの一覧を参照してほしい。

コンポーザブルCDPが適しているケース

コンポーザブルCDPが向いているのは、すでに顧客データがきちんとモデリングされた成熟したクラウドウェアハウスを持ち、マルチベンダーのパイプラインを保守できるデータエンジニアリングチームを抱えている組織である。具体的には、次のような場合にコンポーザブルは適している。

• アクティベーションの頻度がバッチ中心（日次や週次のオーディエンス同期、定期レポートなど）で十分な場合
• 既製のマッチングでは対応できない、独自のデータモデルや複雑な名寄せロジックが必要な場合
• プロファイル単価制の料金やベンダーロックインを避けたい場合
• AIやMLの活用がバッチ学習モデル（解約予測、LTVスコアリングなど）に限られ、1時間から1日程度の更新間隔で十分な場合

リアルタイムのフィードバックループ、組み込みのAI意思決定、パーソナライズのためのサブ秒単位のプロファイルアクセスが必要な組織には、エージェンティックCDPの方が適している場合がある。エージェンティックCDPは、データ収集、名寄せ、AI意思決定、ネイティブなメッセージングを単一のプラットフォームに統合し、ベンダーの境界を越えることなくAIエージェントがCustomer Intelligence Loopの全体を継続的に回せるようにする。一部のエージェンティックCDPはハイブリッドCDPとしての展開にも対応しており、既存のウェアハウスと連携しながら、リアルタイム活用のためのマネージドストレージを追加できる。詳しい比較は、パッケージ型CDPとコンポーザブルCDPの比較を参照してほしい。

AIとフィードバックループの課題

ベンチャーキャピタリストのTomasz Tunguzは、AIのバンドリングの時代という論考で、AIはSaaS時代のアンバンドリングの流れを逆転させていると論じている。AIシステムは、ワークフロー全体をエンドツーエンドで観測し、その場でインサイトに基づいて行動できるときに最も力を発揮するという主張である。コンポーザブルスタックでは、Customer Intelligence Loopがベンダーの境界を越えて分断されており、エンゲージメントの結果がシステムの学習に反映されるまでには、前述の経路をすべて経由する必要がある。この往復には秒単位ではなく時間単位の時間がかかる。

このフィードバックの遅延は、週次のオーディエンス同期や定期レポートといったバッチ活用事例であれば問題にならないが、リアルタイムのAI意思決定やエージェンティックマーケティングにとっては構造的な限界になる。この点を検討する組織は、ループをどれだけ速く閉じる必要があるか、そしてハイブリッドCDPやエージェンティックCDPがリアルタイム要件に合っているかどうかを評価すべきである。詳しい分析は、AI時代のCDP評価方法を参照してほしい。

FAQ

コンポーザブルCDPとデータウェアハウスの違いは何ですか？

データウェアハウスはデータを保存・照会するための基盤である。コンポーザブルCDPは、そのデータウェアハウスを基盤としつつ、名寄せ、セグメンテーション、アクティベーションのための専用ツールを組み合わせたアーキテクチャである。 ウェアハウスが提供するのは統合された顧客データという「何」であり、コンポーザブルCDPのツール群が提供するのは、そのデータを実際の顧客体験へと変換する「どのように」である。

中小企業でもコンポーザブルCDPを導入できますか？

コンポーザブルCDPは一般に、統合型CDPよりも高い技術力とインフラが求められるため、専任のデータチームを持つミッドマーケットやエンタープライズの組織に向いている。 ただし、エンジニアリング体制が強く、すでにウェアハウスへの投資を行っているスタートアップであれば、コンポーザブルなアプローチを採用できる場合もある。特にFivetran、dbt、Snowflakeといった最新のデータスタックをすでに使っており、別の専用プラットフォームを追加するコストと複雑さを避けたい場合はその候補になる。

コンポーザブルCDPはエージェンティックAIやリアルタイムマーケティングに対応できますか？

コンポーザブルCDPは、カート放棄や注文確認のようなトリガー型のリアルタイムメッセージには十分対応できるが、継続的に学習するAIエージェントには不向きである。 この違いは重要だ。事前に定義したルールに基づいてトリガーメッセージを送ること自体は、コンポーザブルスタックでも問題なくできる。構造的な限界となるのは継続学習の部分である。AIエージェントが行動し、結果を観測し、次の意思決定を秒単位で改善しようとする場面では、結果データがリバースETLを経てウェアハウスへ戻り、dbtの再構築とモデルの再学習を経てからでなければ学習に反映されない。クローズドループの学習が必要な活用事例では、メッセージングとAI意思決定を組み込んだエージェンティックCDPであれば、サイクル全体を単一のプラットフォームの中に収められる。

さらに詳しく：AI時代のCDP評価方法：購入検討者が確認すべき10の問い

リバースETLとパッケージ型CDPのアクティベーションはどう違いますか？

パッケージ型CDPは顧客プロファイルを自社のデータベースに保存し、事前に構築された連携を通じてマーケティングツールへアクティベーションする。リバースETLはこの構図を反転させ、顧客プロファイルはウェアハウスに置いたまま、リバースETLのコネクタがオンデマンドでセグメントと属性を下流のツールへ同期させる。 この方式では、ウェアハウスを唯一の信頼できる情報源として保ちながら、顧客データを別のシステムへ複製する必要をなくせる。最終的な結果（パーソナライズされたキャンペーン、ターゲティング広告、拡充されたCRMレコード）は似ているが、その裏にあるデータの流れは根本的に異なる。

コンポーザブルCDPとエージェンティックCDPの違いは何ですか？

コンポーザブルCDPはデータウェアハウスの上にベストオブブリードのツールを組み合わせるのに対し、エージェンティックCDPはデータ統合、AI意思決定、ネイティブなメッセージングを単一のプラットフォームに束ねる。 両者の根本的なアーキテクチャの違いは、Customer Intelligence Loopがどこで実行されるかにある。コンポーザブルスタックでは、ループはウェアハウス、リバースETL、外部のESP、別のML基盤という複数のベンダーにまたがり、結果データがシステムの学習に反映されるまでにそのすべてを経由しなければならない。エージェンティックCDPはループ全体を単一のプラットフォームの境界内に収め、AIエージェントがデータの収集、意思決定、実行、結果からの学習を、時間単位ではなく秒単位で行えるようにする。コンポーザブルCDPはエンジニアリング上の主導権とベンダーロックインの回避に優れ、エージェンティックCDPはフィードバックループの速さと運用の複雑さの低さに優れる。詳しい比較は、パッケージ型CDPとコンポーザブルCDPの比較を参照してほしい。

コンポーザブルCDPの導入にはどれくらいの費用がかかりますか？

コンポーザブルCDPの費用は、アクティブプロファイル1,000万件規模で3年間に110万～570万ドルほどが目安であり、同規模のエージェンティックCDPの30万～120万ドルと比べて大きい。 この差は、コストが積み上がる構造から生じる。コンポーザブルスタックでは、ウェアハウスの計算コスト（年間5万～30万ドル）、リバースETLの同期費用（年間3万～15万ドル）、外部のメッセージングプラットフォーム（年間5万～50万ドル）、専任のデータエンジニア2～5名分の人件費（年間20万～75万ドル）が、それぞれ個別に発生する。各変数は互いに掛け合わさる形で増えていく（処理行数×コネクタ数×同期頻度×ツール数）ため、アクティベーションの活用事例が増えるほどコストは非線形に拡大する。導入初期費用はエージェンティックCDPより低いが、総保有コストはエンタープライズ規模になると同水準か、それを上回ることが多い。詳しい内訳は、上記の3年間の総保有コスト比較を参照してほしい。

関連用語

• データウェアハウス — コンポーザブルCDPが基盤とするストレージ層
• データガバナンス — マルチベンダー構成でのデータ品質を管理するための方針
• カスタマーデータプラットフォーム — コンポーザブルCDPが属するより広いカテゴリー
• リアルタイムCDP — コンポーザブルスタックが再現しにくいストリーミング型アーキテクチャ
• データレイクハウス — 一部のコンポーザブルスタックが採用する別の基盤レイヤー