「Treasure Dataを導入したんですが、正直よく使えていなくて……」
この言葉を、私はこれまで何度聞いただろう。
展示会のブースで、LinkedIn のDMで、知人のマーケターから。Treasure DataのTOP LAPIDARIST AWARDを受賞したエンジニアとして活動していると、こういう相談が定期的に届く。
話を聞いてみると、驚くほどパターンが一致している。会社の規模は違う。業種も違う。担当者のバックグラウンドも違う。それでも「使えていない理由」は、ほぼ5つのパターンのどれかに当てはまる。
この記事は、そのパターンを正直に語るものだ。Treasure Dataというプラットフォームへの批判ではない。むしろ逆だ。Treasure Dataの価値は本物だからこそ、「使えていない」という状況は「ツールの問題」ではなく「使い方の問題」であることがほとんどだ。そしてその使い方の問題は、全て解決できる。
CDPは今、「幻滅の谷」にいる
まず業界全体の状況を確認しておきたい。
Gartnerは2024年に、CDPが「幻滅のトラフ（Trough of Disillusionment）」に入ったと発表した。これはGartnerのハイプサイクル上の段階であり、技術への期待が現実の成果に追いつかず、失望と撤退が相次ぐフェーズを指す。
具体的な数字が衝撃的だ。
Gartner 2023年マーテック調査によると、CDPを導入している企業の67%がCDPを採用しているにもかかわらず、「CDPの機能を高度に活用している」と答えたマーケターはわずか17%だった（AdExchanger報告）。Gartnerの別の調査では、CDPを導入した企業が活用できている機能は全体の47%に過ぎず、前年の55%からさらに低下している。
また2024年には、21%の企業が自社のデータ管理プラットフォーム/CDPを入れ替えたという調査結果もある（CMSWire）。そして、CDP実装プロジェクトのうちスケジュール通りに完了したのはわずか23%だとも報告されている。
一方でTreasure Dataは、CDPが「幻滅のトラフ」に入っているこの状況の中でも、Gartner Magic QuadrantのCDP部門でリーダーとして選出され続けている。ForresterのWave、IDC MarketScapeでも同様だ。
つまり「ツールは本物だ。問題は使い方にある」
この構図は、データが示している。
では、「使えていない会社」は何を間違えているのか。
失敗パターン①：「まずデータを全部入れる」から始めてしまう
最も多い、そして最もよくある失敗パターンがこれだ。
「とりあえず全部のデータをTreasure Dataに入れてから考えよう」
気持ちは分かる。Treasure Dataはデータレイクとしての思想を持つプラットフォームだ。「何でも入れておけば後から使える」は正しい。しかしその前に「何のために入れるのか」が定義されていないと、巨大なデータの海に溺れる。
現場で見た具体的な失敗
あるEC企業は、Treasure Data導入後の3ヶ月間、全システムのデータ連携に費やした。ECのトランザクションデータ、CRMの顧客マスタ、MAツールのメール配信ログ、実店舗のPOSデータ、アプリの行動ログ。全部を繋いだ。
しかし「何をしたいか」が決まっていなかったため、データは入ったが施策は何も動かなかった。半年後、経営層から「CDPを導入したのに何も変わっていない」という声が上がった。
なぜこうなるのか
Treasure DataのパートナーであるInfoverityで7年のCDP実装経験を持つBrandon Mooreは明確に言う。「最も成功したCDP実装は、派手なユースケースを追いかけない。しっかりした土台と、全員が支持できるロードマップから始める」（Treasure Data公式ブログ「Successful CDP Implementation」）。
使うべきアプローチは「ユースケースファースト」だ。まず「最初の3ヶ月で何を実現したいか」を1〜2つのユースケースに絞る。そのユースケースに必要なデータだけを最初に繋ぐ。成果が出たら次のユースケースに進む。
Treasure Data自身の調査（Advertiser Perceptionsとの共同調査）でも、正しく取り組んだ企業の大多数はCDP導入から平均8ヶ月でValue（価値）を実感できることが示されている。しかしその前提は「最初にユースケースを絞ること」だ。
解決策：「最初の90日」でやること
Day 1〜30：ユースケースの確定 - 「休眠顧客のウィンバック」か「新規顧客の2回目購買促進」か、1本に絞る - そのユースケースで必要なデータだけをリストアップ - KPIを決める（例：休眠顧客の復帰率を現状の2%から5%にする）Day 31〜60：必要なデータだけを繋ぐ - ECトランザクションとCRMの顧客マスタだけを最初に連携 - 名寄せ処理を実施し、1顧客1IDを確立するDay 61〜90：最初のSegmentを作って施策を打つ - SQLで「90〜180日購買なし、過去LTV3万円以上」のセグメントを抽出 - MAツールに連携してメールを配信 - 結果を計測し、改善を繰り返す失敗パターン②：SQLを書ける人間がゼロ（または1人しかいない）
これは組織の問題として最も深刻なパターンだ。
Treasure Dataはノーコード機能を充実させている。Audience Studio（セグメント作成UI）、Journey Builder（シナリオ設計UI）
これらを使えば、SQLを書かずにある程度のことはできる。
しかし「ある程度」の壁にぶつかった瞬間に、組織が止まる。
「ノーコードの壁」が来る瞬間
「先月のLTVが15%以上下落した顧客だけを、購買カテゴリ別にセグメントしたい」
このユースケースは、ノーコードUIでは対応できない。「購買間隔が90〜120日の顧客だけに、次の購買タイミングに合わせてメールを送りたい」これもUIでは難しい。
本当にビジネスインパクトのある「自社ならではの施策」は、必ずSQLが必要になる局面が来る。
Gartnerが指摘するCDP低活用の原因の一つが「talent recruitment challenges（人材採用の困難）」だ。CDPを使いこなすには「SQLを書けるビジネス人材」が必要だが、そのような人材は市場で慢性的に不足している。
「1人依存」という時限爆弾
SQLが書ける人間が1人しかいない場合、さらに危険な状況が生まれる。
その1人に全てのデータ抽出・セグメント作成・クエリ設計が集中する。その人が異動または退職した瞬間に、組織のCDP活用能力がゼロになる。これは実際に私が複数の現場で目撃した「時限爆弾」だ。
解決策：「SQLを書けるマーケター」を育てる
エンジニアとマーケターの間に存在する壁を壊すことが、CDP活用の最大の投資対効果を生む。
具体的には、既存のマーケター・企画担当者の中から「データに興味がある人」を1名選び、3〜6ヶ月でSQLの基礎を習得させる。必要なのはSELECT / WHERE / GROUP BY / LEFT JOIN / CASE WHENの5つだ。これだけで、Treasure Dataで日常的に行う分析の80%はカバーできる。
現場で使えるようになる最速ルートは「実際の業務データでクエリを書くこと」だ。教科書的なサンプルデータではなく、自社のトランザクションデータと格闘する経験が、最も速く「書ける人材」を育てる。
失敗パターン③：「データの品質」を無視してスタートする
「Garbage In, Garbage Out（ゴミを入れれば、ゴミが出てくる）」AIの世界でよく言われるこの原則は、CDPでも全く同じだ。
「汚いデータ」がCDPを壊す具体的な例
名寄せ未実施の状態でTreasure Dataに連携した場合
EC側のcustomer_id：C001（yamada@example.com）CRM側のcustomer_id：CRM_0059（yamada@example.com）アプリ側のuser_id：APP_99112（yamada@example.com）この3つが「同一人物」と認識されていないまま連携すると、LTVは3分の1に見える、メールが3通届く、「新規顧客」として扱われるという問題が起きる。
カラムの定義が統一されていない場合：
ECとCRMで「最終購買日」の定義が違う。ECは「注文確定日」、CRMは「出荷日」を持っている。これを同一条件で比較すると、平均で3〜10日のズレが生まれ、休眠顧客の判定基準がずれる。
Celebrusが整理した「CDP失敗の主要原因」
CDPベンダーのCelebrusが整理した「CDPプロジェクト失敗の10大原因」の中で、「データ品質の不足（Insufficient Data Quality）」は第2位に挙げられている。そして同記事が指摘する通り、「最初から質の悪いデータを基盤にして大きなデータウェアハウスを作ることは、すでに抱えている問題を悪化させるだけだ」。
あるEC企業の事例では、Treasure Dataで4百万件超の重複顧客プロファイルを発見し、それを名寄せすることで広告費を36%削減できたという報告がある（Treasure Data公式ブログ）。
つまり「汚いデータ」は、単にパーソナライゼーションの精度を下げるだけでなく、広告費の無駄にも直結する。
解決策：「連携前にSQLでデータを棚卸しする」
Treasure Dataに全データを入れる前に、SQLを使ってデータの品質を確認する。
-- データ品質チェッククエリ（連携前に必ず実施）
-- ① 重複IDの確認
SELECT
email,
COUNT(DISTINCT customer_id) AS id_count
FROM customers
WHERE email IS NOT NULL
GROUP BY email
HAVING COUNT(DISTINCT customer_id) > 1
ORDER BY id_count DESC
LIMIT 100;
-- → 大量に出る場合、名寄せ処理が必要
-- ② 重要カラムのNULL率確認
SELECT
COUNT(*) AS total,
ROUND(100.0 * SUM(CASE WHEN email IS NULL THEN 1 END)
/ COUNT(*), 1) AS email_null_pct,
ROUND(100.0 * SUM(CASE WHEN last_purchase_date IS NULL THEN 1 END)
/ COUNT(*), 1) AS last_purchase_null_pct,
ROUND(100.0 * SUM(CASE WHEN customer_segment IS NULL THEN 1 END)
/ COUNT(*), 1) AS segment_null_pct
FROM customers;
-- → 重要カラムのNull率が高い場合、データ収集の仕組みを見直す
-- ③ 日付の異常値確認
SELECT
MIN(last_purchase_date) AS earliest_date,
MAX(last_purchase_date) AS latest_date,
COUNT(*) AS total_records,
SUM(CASE WHEN last_purchase_date > CURRENT_DATE THEN 1 ELSE 0 END) AS future_dates
FROM orders
WHERE status = 'completed';
-- → 未来の日付がある場合、データ投入処理に問題があるこのチェックを連携前に実施するだけで、後から発覚する「なぜかセグメントの人数がおかしい」「メールが重複して届く」という問題の大半を防げる。
失敗パターン④：「部門横断の合意」を取らずにIT部門だけで進める
CDPは技術的なツールだ。しかし「誰が使うか」はマーケター・営業・カスタマーサクセスなどビジネス部門の人間だ。IT部門だけで実装を進め、「できました。使ってください」と渡しても、現場は使わない。
「誰も使わないCDP」の誕生
CDP失敗のパターンとして業界で広く共有されているのが「No cross-department buy-in（部門横断的な合意なし）」だ（Scott Zakrajsek氏の調査 / David Chan氏によるMedium記事）
日本の大企業で特によく起きる。IT部門がプロジェクトオーナーになり、マーケティング部門は「要件を出す側」として関与するが、実際の実装フェーズには関与しない。完成後に「使い方が分からない」「自分たちのやりたいことと違う」という声が上がる。
あるメーカーでは、Treasure Dataの実装に8ヶ月かかったにもかかわらず、マーケティング部門が実際に使い始めたのは完成から半年後だったというケースがある。IT部門が作ったセグメントの定義が「マーケターが思っていた定義」と微妙にずれていたからだ。
なぜ合意なしに進んでしまうのか
CDPは「IT部門が主導して技術的に実装するもの」というイメージが強い。一方でマーケターは「難しいシステムの話は分からない」と思って関与を避ける。この「すれ違い」が、誰も使わないCDPを生む。
しかし実際には、Treasure DataはSQLという「共通言語」を持っている。マーケターがSQLの基礎を理解していれば、「このセグメントはこういう条件で作りたい」という要件をSQLで正確に表現できる。ITとマーケが同じ言語で話せれば、すれ違いは起きにくい。
解決策：「フュージョンチーム」を作る
Gartnerが推奨する「フュージョンチーム（Fusion Team）」の考え方が有効だ。CDPプロジェクトの最初から、以下のメンバーで構成するチームを作る。
- プロジェクトオーナー（マーケティング or 経営企画）：ビジネス目標を定義する
- データエンジニア（IT or 外部パートナー）：技術実装を担う
- マーケター/ビジネス担当（CDP活用の現場）：ユースケースと要件を定義する
- 分析担当（SQLを書ける人）：ユースケースをクエリに翻訳する
このチームが「週次で集まり、ユースケースの定義とSQL設計を一緒にやる」文化が、CDP活用成功の最短ルートだ。
失敗パターン⑤：「複雑すぎる要件」を最初から詰め込む
「せっかくTreasure Dataを入れたのだから、最初から全部やりたい」この欲張りが、プロジェクトを殺す。
「完璧主義の罠」
CDP導入のプロジェクト計画書に、こんな内容が書かれているケースは珍しくない。
- フェーズ1：全データソース14本の連携（ECサイト×3、実店舗POS×2、CRM、MA×2、アプリ×3、コールセンター×3）
- フェーズ2：顧客360°ビューの構築と全部門への展開
- フェーズ3：リアルタイムパーソナライゼーションの実装
- フェーズ4：AI/MLによる次の購買予測
これを「最初の1年」でやろうとして、どのフェーズも中途半端になる。特にデータ連携の数が多い場合、各システムごとに仕様確認・API設計・テストが必要で、14本を繋ぐだけで1年近くかかるケースがある。
なぜ「一気にやりたい」という衝動が生まれるのか
CDPは「高額な投資」だ。だからこそ「元を取ろう」という心理が働き、最初から大きなスコープを設定してしまう。しかしこれが逆効果だ。
CDP.comが整理した「CDP成功の鍵」の一つが「スケジュール通りに進めること」だ。CDP実装プロジェクトの約77%がスケジュール超過するという現実の中で、最初から大きすぎるスコープを設定することは、失敗の確率を跳ね上げる。
Treasure Dataのデータ成熟度モデルが示す通り、CDP活用は「基盤構築→基本施策→高度化→AI活用」という段階的なプロセスだ。最初から最後の段階を目指しても、基盤が整っていなければ何も動かない。
解決策：「最初の成功体験」を3ヶ月で作る
Celebrusの推奨する「パイロットユースケースのシンプルさ」の基準がそのまま使える。
良いパイロットユースケースの条件：
- 全員が理解できるほどシンプル
- 実行可能（必要なデータが揃っている）
- 複数のステークホルダーに説明できる
- 測定可能なROIがある
具体的には「休眠顧客（90〜180日未購買）に特別オファーメールを送り、復帰率を改善する」
このレベルで十分だ。これを3ヶ月で実施して成果を出し、「CDPを使えばこういうことができる」という社内の実績を作ることが最優先だ。
まとめ：「使えていない」は、全て解決できる
5つの失敗パターンを整理すると、共通の本質が見えてくる。
CDP失敗の本質は「技術の問題」ではなく「使い方の問題」だ。
| 失敗パターン | 本質的な問題 | 解決策の核心 |
|---|---|---|
| ① 全部入れてから考える | ゴールなき行動 | ユースケースを先に1つ決める |
| ② SQLを書ける人がいない | 組織のスキルギャップ | ビジネス職にSQLを習得させる |
| ③ データ品質を無視する | 基盤の不備 | 連携前にSQLでデータを棚卸しする |
| ④ 部門横断の合意なし | 組織の分断 | フュージョンチームを作る |
| ⑤ 複雑すぎる要件 | 完璧主義 | 3ヶ月で最初の成功体験を作る |
Treasure Dataはデータレイクとしての思想を持ち、SQL前提の設計哲学を持ち、Presto/Hiveの二刀流エンジンを持つ。IDC MarketScape・Forrester Wave・GartnerのMagic QuadrantでリーダーであるTreasure Dataが「使えない」わけがない。
使えていないとすれば、それはツールではなく「使い方」の問題だ。
そしてその問題は、今日から取り組める。
付録：Treasure Data活用度チェックリスト
以下の質問で「No」が3つ以上あれば、今すぐ見直しが必要だ。
□ 最初に実現すべきユースケースが1〜2本明確に定義されているか□ そのユースケースに紐づくKPIが数値で設定されているか□ SQLを書けるメンバーが2名以上いるか□ 主要テーブルの名寄せ処理が完了しているか□ 重要カラムのNULL率を把握しているか□ マーケターとエンジニアが週次で同じ場で議論しているか□ 直近3ヶ月以内にCDPを使った施策を1本以上実施したか□ その施策の効果をSQLで検証したか8項目すべてに「Yes」と答えられる組織は、CDPを本当に使いこなしている。
参考文献・出典
© MarTech Farm. All rights reserved.