CDP（カスタマーデータプラットフォーム）という言葉が業界に定着したのは2013年頃のことだ。それ以来、数百ものCDPベンダーが世界市場に参入し、買収され、統合され、そして静かに消えていった。
2026年現在、Treasure Dataは日本市場でのシェアトップを維持し続け、IDC MarketScapeのB2C CDP部門で2度連続のリーダー選出を受けた。Forrester WaveのB2C CDP部門でもリーダーに選ばれ、GartnerのMagic Quadrantでも高い評価を得ている（Treasure Data, 2024〜2025年）
「使いやすいUIがある」「サポートが手厚い」「営業が強い」
そういった表面的な理由では、13年間の生存競争を説明できない。この記事では、TOP LAPIDARIST AWARDを受賞した現場エンジニアとして、Treasure Dataが選ばれ続ける構造的な理由を語る。
CDPの「墓場」が教えてくれること
まず、業界の現実を直視するところから始めたい。
CDP Instituteの業界統計によれば、2024年6月時点でのCDPベンダー数は世界で194社だった（Statista, 2024年）。しかしこれは「現在生き残っている」数だ。CDP市場が本格的に立ち上がった2013〜2016年頃に参入したベンダーの多くは、現在独立したプロダクトとしては存在していない。
Segment（Twilio傘下）、Emarsys（SAP傘下）、Exponea（Bloomreach傘下）、BlueVenn（Upland Software傘下）、Boxever（ServiceMax傘下）
これらはいずれも、かつて独立した有力CDPベンダーとして名を馳せたプロダクトだ。今は大手の傘下に入り、独自の製品ロードマップを失っているものがほとんどだ。
Gartnerはかつて「CDP市場は2023年までに70%が統合・淘汰される」と予測していた（CMSWire, 2020年）。その予測はおおよそ正確だったと言えるだろう。
生き残ったベンダーと消えていったベンダーの差はどこにあったのか。 その問いへの答えが、これからの「CDPを選ぶ目線」と「データ基盤の本質」を明確にしてくれる。
なぜCDPはこれほど多く「死ぬ」のか
CDP市場における生存競争がこれほど過酷である理由を、技術と市場の両面から整理してみる。
「データの入口」は作れても「出口」が弱い
多くの新興CDPベンダーが犯した最大の失敗は、「データを集める部分」に注力して「データを使う部分」を軽視したことだ。
「弊社のCDPに繋げば、全チャネルのデータが統合されます」
このピッチは魅力的に聞こえる。しかし、データを統合することは手段であって目的ではない。その統合されたデータを使って「何を分析し」「どのセグメントに対して」「どのような施策を実行するか」を定義する能力が、企業側に求められる。
そしてその「使う部分」の核心が、SQLだ。SQLを書いてデータを引き出せるメンバーが社内にいない企業は、CDPを導入しても「データが入るだけのブラックボックス」を持つことになる。
実際、Gartnerの2023年マーテック調査によれば、CDPを導入している企業の67%が「CDP機能の47%しか活用できていない」と回答しており、2022年の55%から大幅に低下している。 さらにマーテック全体では、2023年のツール活用率はわずか33%まで落ちており、2020年の58%から一貫して低下し続けている（Gartner, 2023年マーテック調査）。
「買ったが使えていない」という現実が、CDPベンダーへの不満につながり、解約・ベンダー変更の引き金を引く。 良いCDPとは、導入後に「使える」環境を作れるCDPだ。
「ノーコード向けに設計しすぎる」というトラップ
CDPベンダーのもう一つの失敗パターンが、「SQLを書かなくてもいい」ことを過度に売り文句にしたことだ。
「コードを書かずに、誰でも複雑なセグメントが作れます」
確かに初期導入のハードルは下がる。しかし、実際のエンタープライズのデータ活用ニーズはそれほど単純ではない。
「先月のLTVが前月比15%以上下落した顧客で、購買カテゴリが特定のものに集中していて、最終購買から90日以上経過しているが、この四半期中に一度でもカスタマーサポートに問い合わせた履歴がある人を除いたセグメント」
このような条件定義は、GUIの積み木では限界に達する。ビジネスの本質的なニーズに応えるには、必ずSQLの柔軟性が必要になる瞬間が来る。
ノーコード設計に偏ったCDPは、「日常的な運用の8割」には使えるが、「本当に重要な施策の2割」に対応できない。企業はやがてその「2割の壁」に気づき、より本格的なプラットフォームへの乗り換えを検討し始める。
Treasure Dataが「SQL前提」を手放さなかった理由
Treasure DataはノーコードUI（オーディエンススタジオ）を充実させてきた。AIによる自動セグメント提案機能も搭載された。2025年には「Marketing Super Agent」というAIオーケストレーション機能まで発表している。
しかし、その全ての機能の根底に流れる設計哲学は一度も変わっていない。「SQLで全てのデータにアクセスできる」ことだ。
PrestoとHiveという二刀流の設計思想
Treasure Dataが技術的に他のCDPと一線を画す最大の特徴は、PrestoとHiveという2種類のクエリエンジンを使い分けられることにある。
Presto（現Trino）はメモリベースの分散処理エンジンだ。Facebookで開発されたこのエンジンは、アドホックな分析やBI連携に強みを持つ。数千万件のデータを数十秒〜数分でスキャンし、結果を返す。「昨日のキャンペーン結果をすぐ確認したい」という即時性のニーズに応える。
Hiveはディスクベースの分散処理エンジンだ。障害耐性が高く、数時間かかる大規模なバッチ処理に向いている。「全顧客の過去3年分のLTVを一括再計算したい」「全購買履歴を使ってコホート分析したい」という大規模処理のニーズに応える。
そしてどちらのエンジンも、SQL構文で操作できる。
-- Prestoエンジンで実行する例（アドホック分析向け）
-- 直近30日間のセグメント別LTV（高速）
SELECT
segment,
COUNT(DISTINCT customer_id) AS customer_count,
SUM(amount) AS total_ltv,
AVG(amount) AS avg_ltv
FROM td_purchase_log
WHERE TD_TIME_RANGE(time, TD_TIME_ADD(TD_SCHEDULED_TIME(), '-30d'), TD_SCHEDULED_TIME())
GROUP BY segment
ORDER BY total_ltv DESCこの「エンジンが変わっても、人間が書くSQLは変わらない」という体験は、Treasure Dataを使い続けるエンジニアに「言語の投資が無駄にならない」という安心感を与える。
「データレイク」としての設計哲学
多くのCDPは「使いやすいデータの出口」を作ることに注力した。しかしTreasure Dataは、「あらゆるデータを入れ、あらゆる形で出せる」データレイクとしての哲学を持ち続けてきた。
この設計の違いは、3〜5年のスパンで決定的な差を生む。
企業のビジネスモデルは変わる。使いたいマーケティングツールは変わる。分析したいKPIも変わる。しかし「蓄積されたデータそのもの」の価値は変わらない。それどころか、蓄積量に比例して価値は増す。
「何でも入れておけば、後から何でも取り出せる」この思想は、時代が変わるほど輝く。
特定の分析手法に最適化されたCDPは、その手法が「旧式化」した瞬間に価値を失う。しかしデータレイクとして設計されたTreasure Dataは、「新しい分析手法が登場した」ときにも、既存のデータ資産をそのまま活用できる。
マーテック投資が「死蔵」になる本当の理由
ここで、業界全体を揺るがしている事実に向き合う必要がある。
Gartnerの2023年マーテック調査が明かした衝撃的な数字がある。マーテック活用率は2020年の58%から、2022年に42%、そして2023年にはわずか33%まで下落した。 しかも、この期間中にマーテックへの支出は$153億ドル（2020年）から$236億ドル（2023年）へと35%も増加している（Statista）。
「使えていないのに、買い続けている」これが現実だ。
Gartnerが特定したマーテック活用率低下の3大原因
- ツール間の重複・複雑性（30%が指摘）：似たような機能を持つツールが複数入っており、何をどこで使えばいいかが分からない
- 活用を促進する人材の不足（28%が指摘）：ツールを使いこなせるスキルを持つ人間が社内にいない
- マーテックエコシステム全体の複雑さ（27%が指摘）：ツール同士の連携が複雑で、全体像を把握できる人間がいない
つまり、マーテック投資が死蔵される主因は「ツールの問題」ではなく「人材の問題」だ。
そして、「活用できる人材の問題」を解決する最もコスパの高い手段が、SQLだ。SQLを読み書きできるメンバーが社内に一定数いれば、CDPを含むマーテックスタック全体の「使える率」は劇的に変わる。
特にCDPに関しては、Gartnerの別の調査が示す通り「CDPを導入している企業の67%が機能の半分以下しか使えていない」のが現状だ。SQLを書けるメンバーがいることは、この47%という活用率を抜本的に引き上げるための最重要条件だ。
AI時代の「前処理基盤」としての価値—
2025〜2026年現在、生成AIをマーケティングに活用しようとする企業が急増している。
McKinseyの2024年AI調査によれば、AIを少なくとも一つのビジネス機能に活用している企業の比率は72%に達している（2023年の55%から大幅増）。しかし同時に、80%以上の企業が生成AIから「EBIT（利払い・税引き前利益）への具体的な影響」を実感できていないというのが現実だ。
BCGの1,000社を対象にしたC-level調査では、さらに明確な数字が出ている。AIから実際に価値を生み出せている企業はわずか26%で、74%の企業がAI活用で意味ある成果を出せずに苦戦している（BCG「The Widening AI Value Gap」, 2025年）。
なぜこれほどのギャップが生まれるのか。
答えは「データの品質」だ。
2025年、データ品質問題が「AIの最大の障壁」に急浮上
2024年に19%だった「データ品質の問題がAIプロジェクトの主要障壁だ」という回答は、2025年には44%へと倍増以上に急拡大した（Bigeye「The Data Quality Crisis Killing AI Projects」, 2025年）。
わずか1年でこれほど問題が顕在化した理由は明確だ。AIの活用スケールが「パイロット」から「本番稼働」に移行するにつれ、データの品質問題が致命的なボトルネックとして露出してきたのだ。
「Garbage In, Garbage Out（ゴミを入れたら、ゴミが出てくる）」
この原則はAI時代においてより一層真実だ。
Gartnerも同じ警鐘を鳴らしている。「AIへの準備が整ったデータ（AI-ready data）は、今後2〜3年の投資優先領域のトップ5に入る」と75%以上の企業が回答している（Gartner「A Journey Guide to Delivering AI Success Through ‘AI-Ready’ Data」, 2024年）。
さらに、Gartnerはかつてこう警告していた。「2025年末までに、PoC（概念実証）後に30%の生成AIプロジェクトが放棄されるだろう。その主因は、データ品質とコストの問題だ」（Gartner, 2024年7月）。この予測は、前述の「44%がデータ品質を最大の障壁と認識」という2025年のデータと見事に符合する。
SQLによる「前処理」が、AIの「精度」を決める
この文脈でTreasure Dataが担う役割を、明確に定義しよう。
Treasure DataはAIの「頭脳」ではない。AIに与える「食材」を準備する「キッチン」だ。
具体的に言うと、AIに渡すデータを作る前処理の工程はこうなる
-- AIに渡す「クリーンな顧客データセット」を作るSQL例
WITH
-- STEP1: 名寄せ（重複IDの統合）
deduped_customers AS (
SELECT
MIN(customer_id) AS canonical_id, -- 最も古いIDを正規IDとして使用
email,
MAX(registered_at) AS latest_registration
FROM customers
WHERE email IS NOT NULL -- メールなしレコードを除外
GROUP BY email
),
-- STEP2: 購買履歴の正規化（キャンセル・返品を除外）
valid_orders AS (
SELECT
o.customer_id,
SUM(o.amount) AS total_amount,
COUNT(o.order_id) AS order_count,
MAX(o.order_date) AS last_order_date
FROM orders o
WHERE
o.status = 'completed' -- 完了注文のみ
AND o.amount > 0 -- マイナス金額（返品）を除外
AND o.customer_id NOT IN ( -- 3年前の移行時のダミーIDを除外
SELECT customer_id FROM dummy_customer_master
)
GROUP BY o.customer_id
)
-- STEP3: AIに渡す最終データセットの生成
SELECT
dc.canonical_id,
dc.email,
COALESCE(vo.total_amount, 0) AS ltv,
COALESCE(vo.order_count, 0) AS purchase_count,
vo.last_order_date,
DATE_DIFF('day', vo.last_order_date, CURRENT_DATE) AS days_since_last_purchase
FROM deduped_customers dc
LEFT JOIN valid_orders vo
ON dc.canonical_id = vo.customer_idこのSQLが実行されなければ、AIには「重複した顧客ID」「キャンセル注文を含む偽りのLTV」「3年前のシステム移行で生まれたゴースト顧客」が混入したデータが渡される。どれほど賢いAIも、このデータからは正しい答えを出せない。
SQLによる前処理は、AIの「知能」を決めるのではない。AIが「実力を発揮できる環境」を整える仕事だ。
Treasure Dataがこの前処理基盤として機能できるのは、まさにSQL前提の設計があるからだ。「データを入れるだけ」のブラックボックスではなく、「SQLで自在に操作できる」データ基盤だからこそ、AIに渡す前の「最後の磨き」ができる。
「選ばれ続ける理由」を再定義する
ここまで見てきた事実を整理すると、Treasure Dataが選ばれ続ける理由は3層に分けて説明できる。
第1層：技術的な強固さ（PrestoとHiveの二刀流）
インタラクティブな分析から大規模バッチ処理まで、同じSQL構文で対応できる。エンジンが進化しても、人間が書くSQLは変わらない。これが「技術的負債を生まない」という安心感に繋がる。
第2層：データレイクとしての設計哲学（「後から何でも取り出せる」）
今日どんな分析ツールやAIが登場しても、Treasure Dataに蓄積されたデータ資産は活用できる。ビジネスモデルが変わっても、分析手法が変わっても、「データという原材料」は腐らない。この設計哲学が、3〜5年スパンでの「乗り換えコスト」を極小化する。
第3層：AI時代の前処理基盤としての存在意義（「最高の燃料を供給する」）
74%の企業がAIから価値を引き出せていない現実において、SQLで正しく前処理されたクリーンなデータはそれ自体が競争優位になる。Treasure Dataは「AIを使う企業」が最初に整備すべき「データの品質基盤」だ。
「道具はいつか変わる。しかしデータは残る。」
2013年のTreasure Dataを見た人は、こんな予言をするかもしれなかった。「いつかSalesforceやAdobeみたいな大手が同じものを作るから、消えるだろう」と。
実際にSalesforceはCDP機能を持ち、AdobeはReal-Time CDPをリリースし、OracleもSAPも同様の製品を持つ大手が市場に参入した。
しかしTreasure Dataは消えなかった。IDC MarketScapeでは2度連続のリーダー選出を受け、ForresterとGartnerでも高い評価を維持し続けている。
その理由は一言で言えば、「SQLへの投資を続けてきたこと」だ。
マーテックの世界では、「テクノロジーのトレンド」は3〜5年で変わる。しかし「データそのものの価値」は蓄積される一方だ。そのデータに触れるための言語、SQLの価値は、データが増えるほど大きくなる。
Gartnerの数字に戻ろう。マーテック活用率は33%。CDPの機能活用率は47%。これらの数字が「ツールへの失望」を表しているわけではない。「ツールを使いこなすための基礎、SQLを学んでいない」ことへの問題提起だ。
道具は変わる。しかしデータは残る。そして、データに触れるための言語、SQLは、データが生きている限り廃れない。
Treasure Dataが選ばれ続けているのは、この「データは残る」という哲学を、最も忠実に体現してきたプロダクトだからだと、私は考えている。
現場エンジニアとして言えること
TOP LAPIDARIST AWARDを受賞するまでに、私はTreasure Dataのクエリを何千本と書いてきた。RFM分析、LTV計算、コホート分析、休眠顧客の掘り起こし、データクレンジング、バッチ処理の自動化。
その経験を通じて、確信していることがある。
Treasure Dataのプラットフォームとしての本当の価値は、「SQLを書く手間を省く機能」ではなく、「SQLを書いた人間の能力を最大限に引き出す環境」にある。
AIがセグメントを自動生成してくれる時代になっても、そのAIに渡すデータを正しく整備できるエンジニアの価値は下がらない。むしろ上がる。AIが「動くが間違ったクエリ」を生成するとき、その間違いを見抜けるエンジニアの価値は上がる。
Treasure Dataは、そういうエンジニアが最も力を発揮できる舞台だ。そしてそれが、この基盤が13年間生き残り続けた、最も根本的な理由だと思っている。
参考文献・出典
© MarTech Farm. All rights reserved.
