Salesforce Data 360（旧 Data Cloud）とは？Sales Cloud・Marketing Cloudとの違い

Salesforce Data 360（旧称：Data Cloud）は、顧客データを統合して全社で活用するための基盤として注目を集めています。

しかし、既存のSales CloudやMarketing Cloudとの違いが分かりにくく、「自社に本当に必要なのか」と迷う企業も少なくありません。

本記事では、Salesforce Data 360（旧称：Data Cloud）の製品定義や既存製品との役割分担を整理し、導入が必要となる具体的なシーンを明らかにします。さらに、技術アーキテクチャやデータ統合の仕組み、既存のDWHやCRMとの棲み分け、導入手順、実際の事例、そしてライセンス体系とコストまでを網羅的に解説します。

Data Cloudの導入を検討している方、既存のSalesforce製品との連携を最適化したい方にとって、判断材料となる情報を提供します。

Salesforce Data 360（旧称：Data Cloud）とCRM・Marketing Cloudの違い

この章では、Salesforce Data 360（旧称：Data Cloud）の製品定義を整理し、Sales CloudやMarketing Cloudとの役割分担を明確にします。また、Salesforce Data 360（旧称：Data Cloud）が必要になる具体的な3つのシーンを示し、導入の妥当性を判断する基準を提示します。

Salesforce Data 360（旧称：Data Cloud）の製品定義と位置づけ

Salesforce Data 360（旧称：Data Cloud）は、Salesforceエコシステム全体に顧客データを供給する中核的な存在です。Sales CloudやMarketing Cloudが蓄積する顧客情報に加え、外部のWebサイト行動ログ、モバイルアプリのイベントデータ、IoTセンサーからのリアルタイム情報など、多様なソースからデータを取り込み、統合された顧客像を作り上げます。これにより、営業部門・マーケティング部門・カスタマーサポート部門が同じ顧客情報を参照しながら、一貫性のある顧客体験を提供できるようになります。

Salesforce Data 360（旧称：Data Cloud）は、Salesforceエコシステム全体にリアルタイムのデータ知能を提供する中核を担います。従来は各部門が個別にデータを管理していたため、顧客理解が断片的になりがちでしたが、Salesforce Data 360（旧称：Data Cloud）によって部門横断的なデータ活用が可能になります。

なお、データ統合基盤（CDP）にはSalesforce製品以外にも選択肢があります。例えばGENIEE CDPのように、日本の商習慣に合わせ、よりシンプルな構成でデータ統合を実現できる国内ツールも存在します。

Sales Cloud・Marketing CloudとSalesforce Data 360（旧称：Data Cloud）の役割分担

Salesforce製品群における役割分担を整理すると、Sales Cloudは営業活動の管理、Marketing Cloudは施策の実行、Salesforce Data 360（旧称：Data Cloud）はデータの供給という三位一体の構造になります。

Sales Cloudは商談管理や顧客接点の履歴を記録し、営業担当者が日々の活動を効率的に進めるためのツールです。Marketing Cloudはメール配信やSNS投稿、広告配信といった施策を実行するためのプラットフォームです。一方、Salesforce Data 360（旧称：Data Cloud）は外部行動ログを統合し、CRMやマーケティングツールへ即時にデータを供給する役割を果たします。

例えば、WebサイトでカタログをダウンロードしたユーザーがSales Cloud上の既存顧客だった場合、Salesforce Data 360（旧称：Data Cloud）はその行動データを即座にSales Cloudへ反映させます。営業担当者は最新の関心事を把握した状態で商談に臨めるため、提案の精度が高まります。同様に、Marketing Cloudでは、Salesforce Data 360（旧称：Data Cloud）が提供するリアルタイムセグメントを活用して、タイミングを逃さずにパーソナライズされたメッセージを配信できます。

Salesforce Data 360（旧称：Data Cloud）が必要になる3つのシーン

Salesforce Data 360（旧称：Data Cloud）の導入が必要となる具体的なシーンは、外部ログとの紐付け、リアルタイムセグメント、複数チャネルのID統合の3つです。

1. 外部ログとの紐付け

Webサイトやモバイルアプリでの行動履歴を、Sales CloudやMarketing Cloudに蓄積された顧客情報と紐付けたい場合、Salesforce Data 360（旧称：Data Cloud）が不可欠です。例えば、匿名ユーザーがサイトを閲覧し、その後フォームから問い合わせを行った際に、閲覧履歴と実名の顧客情報を統合することで、関心の高いコンテンツを把握した状態でフォローアップできます。

2. リアルタイムセグメント

顧客の行動に応じて即座にセグメントを更新し、施策を実行したい場合にもSalesforce Data 360（旧称：Data Cloud）が必要です。例えば、ECサイトでカートに商品を入れたまま離脱したユーザーに対して、数分以内にリマインドメールを送るといった施策は、リアルタイムなデータ処理がなければ実現できません。

3. 複数チャネルのID統合

店舗、EC、コールセンター、SNSなど、複数のチャネルで顧客接点がある場合、各チャネルで使用されるIDを統合して単一の顧客プロファイルを構築する必要があります。Salesforce Data 360（旧称：Data Cloud）は、メールアドレス、会員ID、Cookie IDなどを紐付け、顧客の全体像を把握できるようにします。

Salesforce Data 360（旧称：Data Cloud）の技術アーキテクチャとデータ統合の仕組み

この章では、Salesforce Data 360（旧称：Data Cloud）がどのようにデータを取り込み、統合し、施策へ反映させるのかを、4層のアーキテクチャとID統合の技術を中心に解説します。また、リアルタイム処理と外部連携の仕組みについても触れます。

Salesforce Data 360（旧称：Data Cloud）の4層アーキテクチャ

Salesforce Data 360（旧称：Data Cloud）は、取り込み・統合・セグメント・アクションの4層構造により、データの価値を即座に施策へ反映させます。

第1層の「取り込み」では、Salesforce製品、外部データベース、API、ファイルアップロードなど、多様なソースからデータを収集します。

第2層の「統合」では、収集したデータをクレンジングし、重複を排除しながら単一の顧客プロファイルに統合します。

第3層の「セグメント」では、統合されたデータをもとに条件を設定し、ターゲットとなる顧客グループを作成します。

第4層の「アクション」では、作成したセグメントをMarketing CloudやSales Cloudへ供給し、メール配信や営業活動に活用します。

ノーコードでセグメントを作成できるため、マーケターが情シスを介さず迅速に施策を実行可能です。従来はデータ抽出を依頼してから施策実行までに数週間かかることもありましたが、Salesforce Data 360（旧称：Data Cloud）を活用すれば数時間で完結します。

アイデンティティ・レゾリューションの実装

複数の識別子を統合するマッチングルール設計が、顧客理解の精度を左右する重要な鍵となります。アイデンティティ・レゾリューションは、散在する顧客IDを単一のプロファイルに統合する技術です。

確定的な一致と確率的な一致の2つの手法があります。確定的な一致は、メールアドレスや会員IDなど、完全に同一の値を持つデータを紐付ける方法です。一方、確率的な一致は、氏名や住所、電話番号などの部分的な一致をもとに、統計的に同一人物である可能性を判定します。

メールアドレスやCookie IDを紐付けることで、匿名ユーザーから実名顧客への変化を捉えられます。例えば、あるユーザーがWebサイトを複数回訪問した後、フォームから問い合わせを行った場合、それまでの閲覧履歴を実名の顧客情報に統合できます。これにより、関心の高いコンテンツや閲覧頻度を把握した状態で、最適な提案を行えるようになります。

リアルタイム処理と外部データ連携

Salesforce Data 360（旧称：Data Cloud）は、ストリーミングデータの取り込みと、MuleSoft等を用いた外部システムとの連携により、リアルタイムな施策実行を可能にします。

Webサイトの行動をリアルタイムで取り込むことで、離脱直後のフォローアップなどが可能になります。例えば、カートに商品を入れたまま離脱したユーザーに対して、数分以内にリマインドメールを送ることで、購買率を高められます。また、店舗での購買データをリアルタイムで取り込み、オンラインでの行動履歴と統合することで、オンライン・オフラインを横断したパーソナライズが実現します。

外部システムとの連携には、MuleSoftやAPI接続が活用されます。基幹システムや既存のDWHからデータを取り込む際には、MuleSoftを介してデータフローを構築することで、柔軟かつ安全な連携が可能になります。

Salesforce Data 360（旧称：Data Cloud）導入から施策実行までの4つのステップ

この章では、データ接続からモデル設計、運用開始までの具体的なステップを解説します。導入期間を短縮するためのコツについても触れます。

ステップ1：データソースの特定と接続

導入は「小さく始めて大きく育てる」のが鉄則であり、まずは主要なデータソース1〜2つの統合から着手します。

優先順位の付け方としては、施策への影響が大きいデータソースから着手することが推奨されます。例えば、Webサイトの行動ログやSales Cloudの商談データなど、顧客理解に直結するデータを優先します。

接続方法の選択基準としては、データ量と更新頻度が重要です。リアルタイム性が求められる場合はAPI接続を、大量のデータを定期的に取り込む場合はバッチ処理を選択します。Salesforce製品同士であれば、標準コネクタにより数クリックでデータの同期設定が完了します。

ステップ2：データモデルの設計とID統合ルールの定義

データ基盤の根幹となる設計手順として、共通キーの設定や名寄せルールの作成が必要です。

共通キーとしては、メールアドレスや会員IDなど、複数のデータソースで共通して使用される識別子を選定します。名寄せルールでは、確定的な一致と確率的な一致を組み合わせ、どの程度の類似度で同一人物と判定するかを定義します。

不完全なデータが統合されないよう、事前にデータクレンジングのルールを定義することが不可欠です。例えば、メールアドレスの大文字・小文字を統一する、電話番号のハイフンを除去するなど、標準化のルールを明確にします。

ステップ3：セグメント作成とテスト

ノーコード画面での条件設定と、意図した通りのデータが抽出できているかの検証方法を解説します。

セグメント作成では、Salesforce Data 360（旧称：Data Cloud）の画面上で条件を設定します。例えば、「過去30日以内にWebサイトを訪問し、特定のページを閲覧したが、まだ問い合わせをしていないユーザー」といった条件を設定できます。

作成したセグメントの件数が想定と乖離していないか、サンプルデータを確認するプロセスを挟みます。件数が極端に多い場合や少ない場合は、条件設定にミスがある可能性があるため、再度見直しを行います。

ステップ4：Marketing Cloud・Sales Cloudへのデータ連携とステップ5：本番運用

アクティベーションの設定と、運用開始後のEinstein活用による予測分析への拡張について説明します。

アクティベーションでは、作成したセグメントをMarketing CloudやSales Cloudへ供給する設定を行います。Marketing Cloudでは、セグメントをもとにメール配信やジャーニーの起点として活用できます。Sales Cloudでは、営業担当者がリストを参照して優先的にアプローチする顧客を把握できます。

本番開始後はLTV予測などのAI機能を段階的に取り入れ、施策の高度化を図ります。Einsteinを活用することで、どの顧客が将来的に高い価値をもたらすかを予測し、リソースを効率的に配分できるようになります。

Salesforce Data 360（旧称：Data Cloud）のライセンス体系とコスト構造

この章では、エディション別の機能差や従量課金の仕組み、導入にかかる初期・運用費用の目安を詳述します。また、他社製品とのコスト比較を通じ、ROIを最大化するための判断材料を提供します。

Salesforce Data 360（旧称：Data Cloud）のライセンス体系とエディション別機能

Salesforce Data 360（旧称：Data Cloud）のコストはデータ量に応じた従量課金が主となるため、不要なデータの除外がコスト抑制に直結します。

ライセンス体系としては、StandardからUnlimitedまでの複数のエディションが用意されています。上位エディションではEinsteinによる予測分析など、高度なAI機能が標準で利用可能になります。

ライセンス契約時に注意すべきポイントとしては、データ量の見積もりとエディション選択があります。データ量が増加するとコストも増加するため、初期段階では必要最低限のデータソースから始め、段階的に拡張することが推奨されます。

初期費用とランニングコストの目安

導入支援パートナーへの依頼費用や、月々の運用費用の相場感を提示します。

初期費用としては、要件定義、データモデル設計、接続設定、テストなどの工程が含まれます。パートナーに依頼する場合、要件定義から初期設定までで数百万円規模の支援費用が発生するのが一般的です。

ランニングコストとしては、ライセンス費用とデータ転送量に応じた従量課金が発生します。データ量が多い場合や、頻繁にデータを同期する場合は、コストが増加するため、運用設計の段階で最適化を図ることが重要です。

他社CDP・DWHとのコスト比較と導入判断基準

Treasure DataやBigQuery等との費用構造の違いを比較し、自社の要件に最適な製品を選ぶためのチェックリストを提示します。

Treasure Data CDPは、豊富なコネクタを持ち、多様なデータソースとの連携に強みを持ちます。コスト構造は主にデータレコード数や契約プランに基づく定額・従量ハイブリッド型が中心です。

BigQueryは、データ保存量とクエリ実行量に応じた課金となり、大量データの分析に強みを持ちます。ストリーミング取り込み機能も備えていますが、ミリ秒単位の超低レイテンシが求められる高頻度リアルタイム分析よりも、大規模バッチ分析やBI用途に最適化されています。

Salesforce製品を既に活用している企業にとって、Salesforce Data 360（旧称：Data Cloud）は学習コストを抑えられるメリットがあります。また、Salesforceのユーザーインターフェースに慣れている場合、操作性の面でも優位性があります。

選定の判断基準としては、既存のSalesforce製品の利用状況、リアルタイム処理の必要性、外部システムとの連携範囲、運用体制の有無、コスト上限などを総合的に評価することが求められます。

CDPツール比較15選！おすすめランキング・機能・選び方を徹底解説

もし、Salesforceのライセンスコストや専任エンジニアの確保がボトルネックとなる場合は、GENIEE CDPのような代替案も検討に値します。コストパフォーマンスに優れ、ノーコードでの連携機能が充実しているため、スモールスタートでAX（AIトランスフォーメーション）を進めたい企業に適しています。

まとめ

Salesforce Data 360（旧称：Data Cloud）は、顧客データを統合して全社で活用するための中核的な基盤です。Sales CloudやMarketing Cloudとの役割分担を理解し、外部ログとの紐付け、リアルタイムセグメント、複数チャネルのID統合といった具体的なシーンで必要性を判断することが重要です。

技術アーキテクチャとしては、取り込み・統合・セグメント・アクションの4層構造により、データの価値を即座に施策へ反映させます。アイデンティティ・レゾリューションによる顧客IDの統合と、リアルタイム処理による迅速な施策実行が特徴です。

導入手順としては、データソースの特定と接続、データモデルの設計とID統合ルールの定義、セグメント作成とテスト、Marketing CloudやSales Cloudへのデータ連携、本番運用の5つのステップを踏むことで、段階的に施策を高度化できます。

ライセンス体系とコスト構造を理解し、データ量の見積もりと運用設計を適切に行うことで、ROIを最大化できます。Salesforceエコシステムを最大限活用するにはSalesforce Data 360（旧称：Data Cloud）が最適ですが、運用体制やコストに見合わない場合は、GENIEE CDPなど、より導入ハードルの低い国産ツールの検討も推奨されます。自社の要件に最適な製品を選び、段階的に拡張していくことが成功の鍵となります。