Data 360（旧Data Cloud）とは？Agentforceに必要な理由と導入の判断軸

Data Cloudという名前で調べたのに、Data 360という別の名前が出てくる。この状態で手が止まった経験はないでしょうか。Data 360とは、社内外に分かれたデータを取り込み、標準のモデルへ整え、同一の相手を突き合わせて必要な場所へ出力するデータ基盤です。名前が変わっただけで、担う役割は変わっていません。Agentforceの一部の機能は、この基盤がなければ動かないと公式に説明されています。

なお、Salesforce公式のTrailheadには「As of October 14, 2025, Data Cloud has been rebranded to Data 360.」と記載されています。本記事でも Data 360 の表記で統一します。古い資料でData Cloudと書かれているものは、同じものを指していると読み替えてください。

本記事では、業務用の照明器具を製造・販売する中堅メーカー（従業員480名・営業35名・情報システム部5名）を例に、Data 360が必要になる条件と、対象を選ぶ判断軸を解説します。この企業は説明のための架空の設定であり、実在の企業ではありません。記載内容は2026年8月時点のものです。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援と、Agentic CRM設計支援を提供している。

Data 360が必要になる3つの状況

Data 360の検討が始まるきっかけは、データ基盤への関心ではありません。多くの場合、AIを使おうとして初めて、社内のデータが1か所にまとまっていないという事実に直面します。例に挙げた照明器具メーカーも、Sales Cloudを6年、Service Cloudを3年使いながら、顧客のデータは4つのシステムに分かれたままでした。分かれていること自体は珍しくありません。困るのは、横断して見たい場面が生まれたときです。ここでは、Data 360が必要になる3つの状況を確認していきます。

状況①同じ顧客が複数の場所に登録されている

1つ目は、同じ取引先が別々のシステムに、別々の情報として存在している状況です。

このメーカーでは、Sales Cloudに商談の記録が、Service Cloudに問い合わせと保守の履歴が、基幹システムに受注と出荷の実績が、そして直販サイトに購入の履歴が入っていました。4つとも同じ顧客を扱っていますが、登録の仕方が揃っていません。同じ取引先が3通りの表記で登録されている例もありました。

表記が揃わない理由は、入力する部門も、入力する時期も違うからです。営業が商談の段階で登録した名称と、経理が請求のために登録した名称と、サポートが問い合わせを受けて登録した名称が、それぞれ別の正解として残ります。

分かれていること自体は、運用の失敗ではありません。 別々の目的で作られたシステムが、それぞれの目的を果たしてきた結果です。問題になるのは、横断して見たい場面が生まれたときです。照明器具メーカーで最初にその場面が生まれたのは、営業が商談の前に取引先の状況を確認しようとしたときでした。4つのシステムを順に開いて回るという運用が、そこで初めて問題として認識されています。

状況②AIに聞いても片側の情報しか返らない

2つ目は、AIを使い始めた段階で、返ってくる答えが部分的だと気づく状況です。

このメーカーが最初に試したのは、商談の前に取引先の状況を要約させることでした。返ってきたのは、Sales Cloudに入っている商談の経緯だけです。同じ取引先から保守の不具合について問い合わせが来ていたことは、要約に含まれていませんでした。参照先がSales Cloudに限られていたためです。

この状態でAIの精度を上げようとしても、限界があります。読める範囲の外にある情報は、どれだけ指示を工夫しても返りません。精度の問題に見えて、実際には参照範囲の問題です。

Trailheadでは「Agents built on Data 360 data know your customers inside and out, from their purchases in Sales Cloud to their engagements in Marketing Cloud.」と説明されています（2026年8月時点）。※参考記事はこちら

複数のクラウドにまたがる顧客の状況を踏まえた応答は、データが統合されていることが前提になります。

状況③名寄せの作業が定期的に発生する

3つ目は、重複した登録を手作業で突き合わせる作業が、業務として定着している状況です。

このメーカーでは、四半期ごとに情報システム部が名寄せの作業を行っていました。延べ40時間ほどかかっています。作業の内容は、表記の揺れている取引先を目視で確認し、同じ相手だと判断したものを紐づけていくというものです。

この作業には終わりがありません。次の四半期にはまた新しい重複が生まれるためです。入力の運用を厳しくすれば減りますが、ゼロにはなりません。取引先の社名変更や合併が起きれば、そのたびに突き合わせが必要になります。

手作業で続けている限り、この時間は固定費として毎期発生します。仕組みで突き合わせる方向に切り替えるかどうかが、検討の出発点になります。切り替えの判断には、40時間という数字が材料になります。この数字を記録していない企業では、そもそも比較の対象がありません。手作業の量を数えるところから始めると、判断の根拠が手に入ります。

Data 360が必要になるのは、データが分かれていること自体が問題になったときではなく、横断して見たい場面が業務のなかに生まれたときです。

Data 360が担う4つの処理

前章で挙げた3つの状況は、どれもデータが分かれたままであることに行き着きます。それをどう解消するのかは、公式に説明されている処理の流れを追うと分かりやすくなります。Trailheadでは、接続・調和・統合・出力という4つの段階で整理されています。この順番には意味があり、前の段階が終わらないと次に進めません。どの段階でつまずいているのかを把握できると、検討の論点も絞れます。名前の意味を覚えるより、どの段階で何が起きるのかを押さえたほうが、見積もりを読むときにも役立つはずです。ここでは、4つの処理を順に解説していきます。

処理①あらゆるデータを取り込む

最初の処理は、データを集めてくる段階です。

Trailheadでは「Connect any type of data from all your data sources, whether batch, streaming, or real-time data.」と記載されています（2026年8月時点）。※参考記事はこちら

まとめて送る形式、流し込む形式、即時に反映する形式のいずれにも対応するという説明です。取り込みの方式が選べることは、既存のシステムを作り変えずに接続できる可能性を意味します。

加えて、データを複製せずに参照する方式も用意されています。同じ資料が対象として挙げているのは、SnowflakeやDatabricks、BigQueryです。すでに社外の基盤にデータを置いている企業では、移し替えの作業を省ける場合があります。

照明器具メーカーの4つのシステムのうち、基幹システムは社内のサーバーで動いていました。取り込みの方式を選べることが、この環境で検討を進められた理由の1つです。

処理②標準のデータモデルへ整える

2つ目の処理は、集めたデータの形を揃える段階です。

Trailheadでは「Harmonize your data to a standard data model.」と記載されています。システムごとにバラバラな項目名や持ち方を、共通の形へ寄せる作業です。あるシステムで「会社名」と呼ばれている項目と、別のシステムで「取引先名」と呼ばれている項目を、同じものとして扱えるようにします。

この段階が実質的な作業の中心になります。取り込みは設定で済みますが、どの項目とどの項目が対応するのかは、業務を知っている人が決める必要があるためです。技術的な作業に見えて、実際には業務の理解が要る工程です。

照明器具メーカーでも、ここで情報システム部と営業部門の会話が必要になりました。基幹システムの「得意先コード」がSales Cloudのどの項目に相当するのかは、どちらか一方だけでは決められません。この会話には時間がかかりますが、後から効いてきます。対応を決めた記録が残っていれば、次にシステムを追加するときに同じ議論を繰り返さずに済みます。整形の設計は、1度作れば資産として残る種類の作業です。

処理③同一の相手を突き合わせる

3つ目の処理は、別々に登録されている相手を同じものだと判定する段階です。

Trailheadでは「Unify data with identity resolution rulesets.」と記載されています。ルールの集合にもとづいて、同一性を判定するという説明です。どの項目が一致していれば同じ相手と見なすのかを、あらかじめ定義しておく形になります。

状況③で挙げた手作業の名寄せを、このルールが引き受けます。ただし、ルールを決めるのは人です。法人番号が一致すれば同じと見なすのか、社名と住所の組み合わせで判定するのかは、扱うデータの状態によって変わります。

この段階で決めるルールが、後の精度をそのまま決めます。 緩く設定すれば別の相手を同一と判定し、厳しく設定すれば同じ相手が分かれたまま残るでしょう。どちらの誤りを許容するかは、業務によって変わります。営業が参照する情報であれば、無関係な相手の履歴が混じるほうが影響は大きくなります。一方、集計の用途では、分かれたまま残るほうが数字を狂わせます。用途を決めてからルールを組む順番が要ります。

処理④必要な場所へ出力する

最後の処理は、整ったデータを使う場所へ渡す段階です。

Trailheadでは「Output data to multiple sources to act on data based on your business needs.」と記載されています。統合した結果を保持しておくだけで終わらず、業務で使う先へ渡すところまでが対象という説明です。

出力の先には、Salesforceの各アプリケーションも、AIの機能も含まれます。状況②で挙げた「片側の情報しか返らない」という問題は、この段階まで到達して初めて解消します。統合が終わっていても、使う先へ渡っていなければ、業務での見え方は変わりません。

4つの処理のうち、検討で見落とされやすいのがこの最後の段階です。使い道を決めていない統合については、後の章で改めて扱います。進捗を見るときは、出力の設定まで終わっているかを到達点にすると実態と合います。

Data 360は、取り込み・整形・突き合わせ・出力という4つの処理を順に行う基盤であり、どの段階も飛ばせません。

Data 360とAgentforceの3つの接点

前章で4つの処理を追ってきましたが、なぜその基盤が必要なのかは別の話です。Data 360の検討がAgentforceの文脈で出てくるのには、はっきりした理由があります。公式の資料では、Agentforceの一部の機能がData 360を前提にしていると明記されているためです。切り離して考えられる関係ではありません。どこがどう依存しているのかを把握しておくと、着手の順番も決めやすくなります。接点を把握しておくと、Agentforceの検討とData 360の検討を並行して進めるべきか、順番に進めるべきかの判断もできます。ここでは、3つの接点を解説していきます。

接点①統合されたプロファイルを参照する

1つ目の接点は、AIが参照するデータの供給元としての役割です。

処理③で突き合わせた結果は、1つの相手についてまとまった情報として保持されます。Agentforceがこの情報を参照すると、Sales Cloudの商談だけでなく、他の接点での状況も含めて応答できます。状況②で片側しか返らなかった問題に、直接対応する関係です。

照明器具メーカーの場合、商談前の要約に保守の不具合が含まれるかどうかがここで決まります。含まれていれば、営業は先にその話題に触れられます。含まれていなければ、取引先から指摘されて初めて知ることになります。

参照できる範囲が広がることは、応答の精度が上がることと同じ意味を持ちます。AIの性能を上げる作業より、参照できる範囲を広げる作業のほうが、返ってくる答えの差は大きく出ます。指示の書き方を工夫しても、読めない情報は返りません。精度が上がらないと感じたときに、まず参照範囲を疑う習慣を持っておくと、遠回りを避けられます。Salesforceに含まれるAI機能の全体像は、ほか記事「Salesforce AIとは？Einstein・Agentforceの関係と使い分け」で整理しています。

接点②非構造データをData Libraryに取り込む

2つ目の接点は、文書のような形の定まらないデータを扱う仕組みです。

Trailheadでは「Agentforce Data Library (uses Data 360 storage): Only ingests unstructured data, doesn’t unify data.」と記載されています（2026年8月時点）。Data LibraryはData 360の保管領域を使うものの、取り込むのは非構造データに限られ、統合の処理は行わないという説明です。

この区別は重要です。Data Libraryに文書を入れれば統合まで済むと誤解すると、突き合わせが行われていない状態でAIを動かすことになります。マニュアルや手順書を読ませたい場合と、顧客の情報を統合したい場合とでは、使う仕組みが違います。

また、同じ資料には「After connecting sources and transforming data in Data 360, you’re ready to set up Retrieval Augmented Generation (RAG).」という記載もあります。RAGの設計は、データを整えた後の工程という位置づけです。仕組みの詳細は、ほか記事「Agentforce RAGの仕組みは？精度が上がらない5つの原因と改善Tipsも」で解説しています。

接点③Einstein Trust Layerの前提になる

3つ目の接点は、保護の仕組みとの関係です。

Trailheadでは「Agentforce features such as the Agentforce Data Library and Einstein Trust Layer don’t work without Data 360.」と記載されています（2026年8月時点）。Data LibraryとEinstein Trust Layerは、Data 360がなければ動かないという明確な記述です。

この記述は、稟議の書き方に影響します。「Agentforceを導入する」という起案の中に、Data 360が前提として含まれるためです。切り離して段階的に進める計画を立てると、途中で成立しなくなります。

一任する範囲と人が承認する場面をどう設計するかは、ほか記事「Einstein Trust Layerとは？AIに一任する範囲と人が承認する場面の設計」で扱っています。本記事では、Data 360側から見た依存の関係に絞ります。

Agentforceの一部の機能はData 360がなければ動かないと公式に明記されており、両者は選択の関係ではありません。前提の関係にあります。

Data 360で扱えるデータの3つの種類

処理①で触れたとおり、Data 360は複数の形式のデータを受け入れます。ただし、種類によって扱われ方が変わります。統合の対象になるものと、保管されるだけのものがあるためです。この違いを把握しないまま計画を立てると、期待した結果が得られません。種類ごとに、統合の対象になるかどうかと、どの処理まで進むかが変わります。計画を立てる前に、この違いを押さえておいてください。ここでは、扱えるデータを3つの種類に分けて解説していきます。

右の2列を見ると、非構造データだけ扱いが違うことが分かります。文書を読ませたい要望と、顧客の情報を横断して見たい要望は、別の準備が要るということです。

種類①CRMに入っている構造化データ

1つ目は、Salesforceの各アプリケーションに入っている表形式のデータです。

商談、取引先、問い合わせ、契約といったレコードが該当します。項目が定義されており、値の形も揃っているため、処理②の整形と処理③の突き合わせが行いやすい種類です。統合の起点として最初に扱う対象になります。

照明器具メーカーの場合、Sales CloudとService Cloudのデータがここに入ります。同じSalesforceの中にあっても、取引先の登録が別々になっていれば統合の対象です。同じ製品群の中だから揃っているとは限りません。

最初に統合する対象としては、この種類から選ぶほうが進みます。項目の対応を決める作業が、他の種類より軽く済むためです。同じSalesforceの製品どうしであれば、項目の考え方も近くなります。まったく別の設計思想で作られたシステムを相手にするより、対応表を作る作業は短く済みます。1件目の統合で運用の型を作るという意味でも、この種類から入るほうが無理がありません。

種類②外部の基盤に置かれたデータ

2つ目は、Salesforceの外にあるデータです。

基幹システム、データウェアハウス、自社で運用しているデータベースなどが該当します。Trailheadでは、SnowflakeやDatabricks、BigQueryについて、データを複製せずに参照する方式が示されています。すでにこれらを使っている企業なら、移し替えの作業を省ける可能性は高いでしょう。

照明器具メーカーの基幹システムは社内のサーバーで動いており、複製せずに参照する方式の対象には入りませんでした。この場合は、取り込みの方式を選んで接続することになります。月およそ300件の問い合わせに紐づく出荷の実績を参照したい場面では、この接続が必要になります。

外部システムとの接続には、都度呼び出す方式もあります。事前に集約する方式との使い分けは、ほか記事「【2026年8月時点】Agentforce MCPとは？複数システムをまたぐ境界設計と接続」で整理しています。

種類③文書や記録などの非構造データ

3つ目は、形の定まっていないデータです。

マニュアル、手順書、議事録、問い合わせの本文などが該当します。項目に分かれていないため、処理③の突き合わせの対象にはなりません。接点②で触れたとおり、Agentforce Data Libraryはこの種類を取り込みますが、統合の処理は行わないと公式に説明されています。

この違いを踏まえると、計画の立て方が変わります。文書を読ませたいだけであればData Libraryで足りますが、顧客の情報を横断して見たい場合は構造化データの統合が必要です。両方を求めているなら、両方の準備が要ります。

扱えるかどうかと、統合されるかどうかは別の話です。 この区別を最初に押さえておくと、期待と結果のずれを避けられます。照明器具メーカーの場合、製品のマニュアルを読ませたいという要望と、取引先の情報を横断して見たいという要望が同時に出ていました。前者はData Libraryで足り、後者は構造化データの統合が要ります。2つを分けて計画したことで、着手の順番も決められました。

Data 360で扱えるデータには、統合の対象になる構造化データと、保管はされても統合されない非構造データがあります。

Data 360を使う前に確認する3つの前提

扱えるデータの種類を整理しましたが、着手できるかどうかは自社の状態によります。照明器具メーカーが検討に3か月かけたのも、機能の比較に手間取ったからではありません。この前提の確認に時間がかかったためです。確認すべきなのは、どこまでを対象にするか、突き合わせの手がかりがあるか、整える作業を誰が担うかの3点です。3つとも、製品の資料を読んでいるだけでは答えが出ません。自社のシステムと体制を実際に見に行く作業になります。ここでは、着手する前に確認しておく3つの前提を解説していきます。

前提①統合の対象になるシステムの範囲

最初に確認するのは、どのシステムを対象に含めるかです。

照明器具メーカーには4つのシステムがありましたが、すべてを最初から対象にする必要はありません。むしろ、対象を広げるほど項目の対応を決める作業が増え、着手までの期間が読めなくなります。範囲を決める作業は、削る作業に近い性質を持ちます。

判断の材料になるのは、どの業務で分断が起きているかです。商談の前に全体像を見たいのであれば、必要なのはSales CloudとService Cloudの2つでした。出荷の実績まで見たい場面は、その次の段階に回せます。

範囲を決めずに「顧客データを統合する」という目標だけを掲げると、対象がいつまでも確定しません。先に決めるのは統合する範囲です。統合するかどうかの結論は、範囲が定まってから出ます。範囲を決める会話は、業務の側から始めると短く済むはずです。どの作業で画面の切り替えが起きているかを挙げれば、必要なシステムは自然に2つか3つに絞られます。

前提②突き合わせに使う項目の有無

2つ目は、同一の相手だと判定するための手がかりがあるかどうかです。

処理③で触れたとおり、突き合わせはルールにもとづいて行われます。ルールを組むには、比較できる項目が必要です。法人番号のような一意の値が入っていれば判定は確実になりますが、多くの場合そこまで整っていません。

照明器具メーカーでは、Sales CloudとService Cloudの両方に取引先の名称と住所が入っていました。一方で、法人番号を管理していたのは基幹システムだけです。この状態でも、名称と住所を組み合わせた条件で判定するルールは組めます。ただし、表記の揺れがそのまま判定の精度に影響します。

項目が足りない場合、先にその項目を埋める作業が必要になります。この作業は統合の前に来るため、着手の時期を左右します。埋める対象を全レコードにする必要はありません。対象にする範囲の主要な取引先から順に整えれば、判定の精度は上がっていきます。全件を揃えてから着手すると、時期が読めなくなります。

前提③データを整える担当者

3つ目は、処理②の整形と処理③のルール設計を担う人がいるかどうかです。

情報システム部5名のうち、Salesforceの設定を日常的に触っているのは2名でした。残る3名は社内インフラとヘルプデスクを担当しています。この2名が通常の運用に加えて対応できる範囲を見積もらないまま計画を立てると、途中で止まります。

見積もる対象は、初期の設定にかかる時間だけではありません。突き合わせの結果を確認し、誤って統合された組み合わせを直す作業が、稼働後に継続して発生します。この作業を誰が担うのかを先に決めておく必要があります。

社内に置けない場合、設計レビュー・アドバイザリーだけを外部に頼み、実装と運用は社内で持つという分け方もできます。すべてを外部に任せる形と社内で持つ形の中間に、いくつかの組み合わせがあります。

Data 360に着手できるかどうかは、対象にするシステムの範囲・突き合わせに使える項目・整える担当者という3つの前提で決まります。

Data 360の導入でつまずく3つの落とし穴

前提の確認を終えても、進め方を誤ると統合が終わらないまま費用だけが積み上がります。データ基盤の整備は成果が見えにくく、途中で評価が下がりやすい領域でもあります。照明器具メーカーが3か月の検討で方針を2度変えたのも、この難しさによるものでした。3つは連鎖します。対象を広げれば調整に時間を取られ、ルールを後回しにすれば統合が終わらず、使い道がなければ成果を示せません。ここでは、繰り返し起きる3つの落とし穴を解説していきます。

落とし穴①全システムを一度に統合しようとする

1つ目は、対象になりうるシステムをすべて含めて計画を立ててしまうことです。

一見すると効率的に見えます。どうせやるなら一度で済ませたいという発想です。ところが、対象が増えるほど項目の対応を決める会話の相手も増えます。4つのシステムを同時に扱えば、営業・サポート・経理・EC担当の4部門との調整が並行して走ります。

照明器具メーカーも、当初は4つすべてを対象にする計画でした。方針を変えたのは、項目の対応を決める打ち合わせの日程調整だけで数週間かかると分かった時点です。最終的に、最初に統合したのは2つのシステムでした。

一度で終わらせる計画より、2つから始めて広げる計画のほうが、結果として早く到達します。2つで型ができれば、3つ目以降は短く済みます。項目の対応をどう決めるか、ルールをどう調整するかという手順が一度できているためです。最初の1件に時間をかけることは、全体の期間を縮める判断でもあります。一度に終わらせようとする計画は、途中で止まったときに何も残りません。

落とし穴②突き合わせのルールを後回しにする

2つ目は、取り込みと整形を先に進め、判定のルールを後から考えようとすることです。

取り込みと整形は設定の作業として進められるため、着手した感覚が得られます。一方、突き合わせのルールは業務の判断を伴うため、決めるのに時間がかかるでしょう。順番を後ろに回したくなる理由がここにあります。

ところが、ルールが決まらないままデータを集めても、統合された結果は得られません。集まっただけの状態で止まり、何のために取り込んだのかが分からなくなります。処理の順番は飛ばせないと先に述べたのは、この意味でもあります。

ルールを決める会話は、統合を始める前に一度持つほうが早く済みます。どの項目で判定するかが決まっていれば、整形の段階でその項目を優先して揃えられます。この会話に必要なのは、技術の知識より業務の知識です。どの情報が一致していれば同じ取引先だと判断できるかは、日常的にその判断をしている人が知っています。情報システム部だけで決めようとすると、実態から離れたルールになります。

落とし穴③統合しただけで使い道を決めていない

3つ目は、統合が完了した時点を目標にしてしまうことです。

処理④で触れたとおり、公式の説明でも出力までが対象に含まれます。統合された情報が業務のどこで使われるのかを決めていなければ、見え方は何も変わりません。稟議で示した効果も説明できなくなります。

照明器具メーカーが最初に決めた使い道は、商談前の要約に保守の履歴を含めることでした。営業35名が日常的に行っている確認の作業に直接つながるため、効果を確かめやすいという判断です。使い道が具体的であるほど、統合の範囲も自然に絞られます。逆に「データを活用する」という抽象的な目標のままでは、範囲も完成の基準も決まりません。

どの業務から任せるかを決める考え方は、ほか記事「Agentforceのユースケースの選び方は？どの業務から始めるかを決める5つの判断軸」で解説しています。

Data 360でつまずく順番は決まっています。対象を広げすぎ、判定のルールを後回しにし、統合した後の使い道を決めていないという3つです。

Data 360の対象を選ぶ4つの判断軸

落とし穴①で触れたとおり、範囲を絞れるかどうかが進み方を決めます。絞る基準は、システムの重要度から決めません。業務の側から持ってきます。照明器具メーカーが最終的に2つへ絞り込めたのも、この転換によるものでした。判断軸は4つあり、すべてを満たす対象ほど最初に扱う候補として向きます。軸はどれか1つを満たせばよいというものではありません。4つすべてを候補に当てて、欠けている軸があればその対象は後回しにします。ここでは、その4つを順に解説していきます。

判断軸①その業務でデータが分断しているか

最初に見るのは、対象にする業務のなかで実際に分断が起きているかどうかです。

分断していないデータを統合しても、業務は変わりません。すでに1つの画面で完結している作業を対象に選ぶと、手間だけが増えます。分断が起きている場所を先に特定する作業が要ります。特定の方法としては、担当者の作業を1件分だけ追ってみることです。どこで別の画面を開いたかを記録すれば、分断の位置が見えます。1件で十分な理由は、分断が構造的なものだからです。特定の案件だけで起きている現象であれば、それは分断とは呼びません。

照明器具メーカーで分断していたのは、商談前の確認でした。営業はSales Cloudを開いた後、保守の状況を知るためにService Cloudを別途開いています。2つの画面を行き来している作業は、分断が業務の形として現れている状態です。

逆に、受注から出荷までの流れは基幹システムの中で完結していました。候補として残すかどうかは、その作業のなかで画面の切り替えが起きているかで判別できます。受注から出荷までの流れは1画面で完了するため、最初の対象からは外れます。

判断軸②突き合わせの鍵になる項目があるか

2つ目は、同一性を判定できる材料がその範囲にあるかどうかです。

前提②と重なりますが、ここでは業務単位で確認します。全社的に法人番号が整っていなくても、対象にする2つのシステムの間で比較できる項目があれば着手は可能です。逆に、全体としては整っているのに、その2つの間だけ共通の項目がない場合もあります。

照明器具メーカーのSales CloudとService Cloudには、取引先の名称と住所が共通して入っていました。加えて、Service Cloud側には契約の番号が保持されており、これがSales Cloudの商談にも記録されている場合がありました。判定の材料としては十分です。

材料が足りない業務を選ぶと、項目を埋める作業が本体になります。それ自体は必要な作業ですが、最初の1つに選ぶ対象としては向きません。確認の順番としては、業務を先に決めてから、その範囲にある項目だけを見に行くほうが早く進みます。全社のデータ品質を調べてから業務を探す進め方では、着手の判断まで届きません。

判断軸③統合した後に使う相手がいるか

3つ目は、統合された情報を実際に使う人がいるかどうかです。

落とし穴③の裏返しにあたります。使う相手が具体的に決まっていれば、必要な情報の粒度も決まります。誰が使うかを決めないまま統合すると、どこまで細かく揃えるべきかの判断ができません。

照明器具メーカーの場合、使う相手は営業35名でした。商談の前に取引先の状況を確認する場面で使います。この用途が決まっていたため、保守の履歴をどこまで含めるかも判断できました。過去の全件を含める必要はなく、直近の未解決分があれば足りるという結論です。

使う相手が決まっていない統合は、完成の基準も決まりません。相手が決まると、必要な粒度と更新の間隔も決まります。どこまで細かく揃えれば足りるのかという議論が、実際の用途から逆算して片付きます。逆に相手が決まっていなければ、揃えるほど良いという方向に流れ、作業が終わらなくなります。相手を決める作業は、統合の設計を始める前に片付けておきます。

判断軸④更新の頻度に耐えられるか

4つ目は、データの更新の速さに仕組みが追いつくかどうかです。

処理①で触れたとおり、取り込みの方式は複数から選べます。まとめて送る方式で足りる業務もあれば、即時の反映が要る業務もあるでしょう。必要な速さを見誤ると、統合はできているのに現場で使えないという状態が生まれます。

商談前の確認であれば、前日までの情報が反映されていれば実用に足ります。一方、問い合わせ対応の最中に参照する用途で必要になるのは、直前の状態です。月およそ300件の問い合わせをその場で扱う設計にするなら、求められる速さは変わります。

必要な速さは業務が決めます。最初から最も速い方式を選ぶ必要はありません。速さを上げる判断は、運用を始めた後でも下せます。まとめて処理する方式で始めて、業務側から要望が出た時点で切り替えるほうが、初期の費用も抑えられます。

Data 360の対象は、分断の有無・突き合わせの材料・使う相手・必要な更新の速さという4つの軸を業務に当てて決めます。

Data 360を使い始める4ステップ

判断軸で対象を絞ったら、進め方も決めておきます。データ基盤の整備は工程が長く、途中で目的を見失いやすいためです。照明器具メーカーが最初の8週間で踏んだのは、次の4つのステップでした。処理の4段階と対応していますが、こちらは意思決定の順番として並べています。順番を入れ替えると、どこかで手戻りが発生するでしょう。とくにステップ③を後ろへ回すと、落とし穴②で挙げた状態に入ります。ここでは、その4ステップを順に解説していきます。

ステップ①統合する2つのシステムを選ぶ

最初にするのは、対象を2つに絞ることです。

このメーカーが選んだのは、Sales CloudとService Cloudでした。判断軸①で分断が確認でき、判断軸②の材料も揃っており、判断軸③の使う相手も決まっていたためです。基幹システムと直販サイトは、次の段階へ回しました。

2つに絞る理由は、突き合わせの結果を評価しやすくするためです。3つ以上を同時に統合すると、誤って統合された組み合わせが見つかったときに、どの組み合わせで起きたのかを追う手間が増えます。2つであれば、原因の切り分けが単純になります。

小さく始める（スモールスタート）進め方には、調整の相手が減るという利点もあります。2部門で決められる範囲に収まれば、意思決定の速さが変わります。絞る作業は、他の候補を捨てることを意味しません。順番を決めているだけです。残した候補は、最初の2つで作った型をそのまま持ち込めます。3つ目を追加するときに、ゼロから設計をやり直す必要はありません。

ステップ②取り込みと整形の設定をする

2つ目は、選んだ2つからデータを取り込み、形を揃える工程です。

処理①と処理②に対応します。取り込みの方式は業務が求める速さから決め、整形の対応表は業務を知っている人と一緒に作ります。技術的な設定より、項目の対応を決める会話に時間がかかる工程です。

照明器具メーカーでは、この工程に4週間ほどかかりました。うち大半は、Sales CloudとService Cloudで別々に運用されていた取引先の項目を、どちらに寄せるかを決める議論に費やされています。どちらが正しいかという議論になりやすい場面ですが、統合後にどう使うかから逆算すると結論が出ます。

この工程は、業務設計から入る作業に近い性質を持ちます。設定画面を開く前に、何を正とするかを決める必要があるためです。決めた対応は、表の形で残しておきます。次にシステムを追加するときの出発点になり、担当者が代わったときの引き継ぎにもなります。この表は、外部に支援を依頼する場合の説明資料にもなります。

ステップ③突き合わせのルールを決める

3つ目は、同一の相手だと判定する条件を定義する工程です。

処理③に対応します。どの項目が一致していれば同じ相手と見なすのかを決め、実際のデータに当てて結果を確認します。1度で決まることはほとんどありません。結果を見て条件を調整する往復が発生します。

照明器具メーカーでは、名称と住所の完全一致から始め、結果を見て住所の表記揺れを吸収する条件を加えました。緩めすぎると別の相手が統合され、厳しすぎると同じ相手が分かれたまま残ります。どちらの誤りが業務に与える影響が大きいかを先に決めておくと、調整の方向が定まります。

このメーカーの場合、別の相手が統合される誤りのほうが、顧客対応への影響が大きいと判断しました。商談の前に無関係な取引先の履歴が表示されれば、営業の判断を誤らせるためです。この判断を先に決めておいたことで、条件の調整も一方向で済みました。迷ったときは厳しい側に寄せるという方針が立っていれば、往復の回数が減ります。

ステップ④出力先と使い道を決める

最後は、統合した結果をどこで使うかを設定する工程です。

処理④に対応します。照明器具メーカーの場合、出力先は商談前の要約に使われる参照範囲でした。統合された取引先の情報に、Service Cloud側の未解決の問い合わせが含まれる状態を作っています。

この工程まで到達して初めて、営業35名の画面に変化が現れます。逆にいえば、ここまで来ていない段階では、どれだけ統合が進んでいても画面の見え方は変わりません。進捗を報告する際も、この段階に達しているかどうかを基準にすると実態と合います。照明器具メーカーでは、8週間のうち最後の1週間をこの設定と確認に充てました。出力先を決める設定は短時間で終わりますが、要約に含める情報の範囲を営業側と合意する会話に時間がかかっています。ここで決めた範囲が、次にシステムを追加するときの基準にもなります。

以上が、Data 360を使い始める4ステップでした。

着手の進め方は、2つのシステムを選ぶ・取り込みと整形を設定する・判定のルールを決める・使い道まで設定するという4ステップに整理できます。

Data 360が効いてくる3つの業務

進め方を示しましたが、どの業務に当てるかで結果は変わります。効果が出やすいのは、複数の情報源を横断して確認している業務です。分断が業務の形として現れている場所ほど、統合した効果がはっきり出ます。照明器具メーカーで実際に変化があったのも、日常的に繰り返されていた3つの場面でした。3つに共通するのは、担当者が複数の画面を行き来しているという構造です。行き来の回数が、そのまま効果の大きさに変わります。ここでは、その3つを解説していきます。

業務①商談前に顧客の全体像を確認する

1つ目は、営業が商談の前に取引先の状況を確認する場面です。

このメーカーの営業35名は、商談の前にSales Cloudで過去の経緯を確認していました。保守の状況まで見るには、Service Cloudを別途開く必要があります。実際には、時間がないときにこの確認が省かれていました。

省かれると何が起きるかというと、商談の場で取引先から不具合の話を持ち出されて初めて知るという状況が生まれます。その場で答えられなければ、確認して折り返すことになります。統合された情報が最初から表示されていれば、この往復が減ります。

日常的に繰り返される確認であるほど、統合の効果は積み上がるはずです。確認の回数の多さが、そのまま効果の大きさに変わります。営業35名が週に何度この確認を行っているかを数えれば、効果の規模も見積もれます。1人が週に数回であれば、組織全体では相当な回数になります。回数を先に数えておくと、稟議で示す効果の根拠にもなります。

業務②保守契約の更新を判断する

2つ目は、保守契約の更新にあたって条件を判断する場面です。

このメーカーはおよそ2,400件の保守契約を持っていました。更新の判断には、契約の内容だけでなく、その期間に発生した問い合わせの状況も関わります。不具合が続いている取引先と、まったく問い合わせのない取引先とでは、提案の内容が変わるためです。

判断に必要な情報が2か所に分かれていると、担当者は都度突き合わせることになります。2,400件を1件ずつ突き合わせる運用は現実的ではないため、実際には契約の内容だけを見て機械的に更新する形になっていました。

統合されていれば、問い合わせの多い契約を先に抽出できます。件数の多い業務ほど、統合による選別の効果は大きいでしょう。2,400件すべてに同じ手間をかける運用から、優先順位を付けて対応する運用へ移せます。選別ができること自体が、統合の成果として説明しやすい材料になります。更新の提案を出す順番が変わるという形で、業務の変化が目に見えます。抽出した結果を定期的に受け取る仕組みとしては、メトリクスの変化を届ける仕組みもあわせて検討できます。

業務③問い合わせの背景を把握する

3つ目は、月およそ300件の問い合わせに対応する場面です。

サポート担当者はService Cloudで過去の問い合わせを確認できますが、その取引先とどのような商談が進んでいるかは見えません。導入したばかりの製品についての問い合わせなのか、長く使っている製品についてなのかで、対応の丁寧さを変えたい場面があります。

統合された情報があれば、この背景が分かります。加えて、AIに応答を任せる設計を検討する場合、参照できる範囲が広いほど適切な回答に近づくはずです。接点①で触れた関係が、ここでも効いてきます。

業務単位でAIに何を任せるかの考え方は、ほか記事「Agentforce活用事例7選｜成果が出た営業組織に共通する3つの特徴」でも整理しています。対象は違いますが、選び方の考え方は共通しています。扱う情報の種類が変わっても、どの業務から始めるかという問いは同じです。

Data 360の効果は、複数の情報源を横断して確認している業務ほど大きく出ます。商談前の確認・契約更新の判断・問い合わせ対応の3つが典型です。

Data 360の費用を見積もる3つの確認項目

ここまで、対象の絞り方と進め方を解説してきました。稟議を書く段階で次に必要になるのが費用の見積もりです。ただし、Data 360の費用は機能ごとの定額として決まりません。扱うデータの量と処理の回数に依存します。金額を出す前に、確認しておく項目が3つあります。金額を先に聞こうとすると、返ってくるのは前提つきの概算になります。前提のほうを先に固めておけば、見積もりの精度も上がります。確認の順番は、量・回数・契約範囲の3つです。ここでは、その3つを順に解説していきます。

項目①取り込むデータの量

1つ目の確認項目は、どれだけのデータを取り込むかです。

対象にするシステムと期間で、量は大きく変わります。過去の全件を取り込むのか、直近の一定期間に限るのかで規模は変わるでしょう。照明器具メーカーが最初に2つのシステムへ絞ったことは、費用の面でも効いています。

量を見積もるには、対象のシステムでレコードがどれだけあるかを数えます。保守契約およそ2,400件と、月およそ300件の問い合わせが数年分であれば、おおよその規模は出せるはずです。数える作業は、統合の設計を始める前に済ませておくほうが早く進みます。

期間を絞るという選択もあります。判断軸③で決めた使い道に必要な範囲だけを取り込めば、量は抑えられます。たとえば商談前の確認が用途であれば、10年前の問い合わせ履歴まで取り込む必要はありません。用途から逆算すると、必要な期間は自然に決まります。取り込む量を抑えることは、費用だけでなく処理の速さにも効いてきます。

項目②処理が発生する回数

2つ目の確認項目は、どのくらいの頻度で処理が走るかです。

判断軸④で触れたとおり、更新の速さは業務が決めます。即時の反映を求めるほど、処理の回数は増えるでしょう。前日までの反映で足りる業務であれば、まとめて処理する方式で済みます。

この差は、金額に直接効いてきます。全業務で即時の反映を前提に見積もると、必要のない部分まで含めた金額になります。業務ごとに求める速さを分けて整理するほうが、見積もりの精度は上がります。

照明器具メーカーの商談前の確認は、前日までの反映で足りる用途でした。問い合わせ対応での参照を後の段階に回したのは、求められる速さが違うためでもあります。段階を分けて見積もれば、承認する側も最初の段階だけを判断すれば済みます。全業務分の金額を最初に出すと、規模の大きさだけで判断が止まってしまうでしょう。求める速さを業務ごとに整理する作業は、見積もりの前に済ませておきます。整理の単位は、参照する場面ごとで構いません。

項目③既存の契約に含まれる範囲

3つ目の確認項目は、いま契約している内容にどこまで含まれるかです。

Salesforceの製品構成は、契約の時期によって内容が変わります。何年か前に契約したままの企業では、当時の契約書と現在の製品名が一致しない場合もあるでしょう。何が含まれ、何が追加になるのかを販売元へ確認する工程が要ります。

確認する順番としては、使いたい業務を先に決めてから尋ねるほうが早く済みます。「Data 360は使えますか」という聞き方では、返ってくる回答も一般論になります。どの業務でどのシステムを統合したいかを伝えれば、必要な範囲と費用の目安がその場で示されます。

Agentforce側の課金の考え方は、ほか記事「【2026年最新】Agentforce料金・ライセンス完全ガイド」で整理しています。見積もりの金額を左右するのは製品の選択より、どこまでを対象にするかという設計の側です。

Data 360の費用は定額で決まりません。取り込む量・処理の回数・既存契約に含まれる範囲という3つの掛け算で決まります。

Data 360の効果を測る3つの指標

費用を見積もったら、その支出に見合う結果が出ているかを測る仕組みも決めます。データ基盤の整備は成果が見えにくいため、測る対象を先に決めておかないと評価の場で説明できません。見るべき指標は、統合の進み方・手作業の減り方・参照範囲の広がり方の3つです。どれか1つだけを追うと、どの段階で止まっているのかが判別できません。3つを並べて初めて、原因の切り分けができます。照明器具メーカーも、統合の件数だけを追っていた時期は、止まっている原因を特定できませんでした。ここでは、順に解説していきます。

指標①統合されたプロファイルの件数

最初に見るのは、突き合わせによってまとまった相手の件数です。

処理③の結果として、別々に登録されていた相手が1つにまとまります。この件数は、統合がどれだけ進んだかを直接表します。設定が終わった時点で数えず、実際に統合された件数で見るところが要点です。

照明器具メーカーでは、この件数と併せて、統合されずに残った件数も記録していました。残った件数が多ければ、突き合わせのルールが厳しすぎる可能性があります。両方を並べると、ルールの調整が必要かどうかを判断できます。

件数だけを追うと、誤って統合された組み合わせが混じっていても気づきません。抽出して目視で確認する工程を、定期的に挟む設計にしておきます。確認する件数は多くなくて構いません。毎月いくつか抜き取るだけでも、ルールが業務の実態から外れていないかは分かります。確認の担当も、あらかじめ決めておきます。誰も見ない検証は、いずれ実施されなくなります。確認の頻度も、月に一度と決めておけば忘れません。

指標②名寄せの手作業にかかる時間

次に見るのは、状況③で挙げた手作業がどれだけ減ったかです。

このメーカーは、四半期あたり延べ40時間という数字を先に記録していました。着手の前に現状を数えておいたことが、後の比較で効いています。数え方も揃えておく必要があります。確認だけの時間を測るのか、修正まで含めるのかで数字が変わるためです。

時間が減っていない場合でも、原因の見立ては分かれます。ルールが緩く、確認の手間が増えているだけの状態か、そもそも対象にした範囲が手作業の発生源ではなかったのかで、打つ手が変わります。

比較できる形にしておくことが、この指標の価値です。導入前の数字がなければ、減ったかどうかも示せません。記録は、着手を決める前の段階で始めておきます。統合の作業が始まってからでは、以前の状態を正確に思い出せません。四半期に1度の作業であれば、記録の負担も小さく済みます。作業の日と所要時間を書き留めるだけで十分です。誰が担当したかも残しておくと、後で内訳を確認できます。

指標③AIが参照できた情報の範囲

3つ目は、統合の目的に直結する指標です。

状況②で挙げた「片側の情報しか返らない」という問題が解消したかどうかを見ます。具体的には、AIの応答に統合したはずの情報が含まれているかを、実際の質問で確かめます。照明器具メーカーでは、保守の未解決分が要約に含まれるかを毎週いくつか抜き取って確認していました。

この確認は、処理④まで到達しているかの検証にもなります。統合が完了していても、出力の設定が漏れていれば応答は変わりません。件数の指標が伸びているのに応答が変わらない場合、原因は出力側にあります。

効果測定の設計をより深く扱う考え方は、ほか記事「【2026年8月時点】Agentforce Observabilityとは？定着と精度を測る指標設計」で解説しています。

Data 360の効果は、統合された件数・手作業にかかる時間・AIが参照できた範囲という3つを並べて見ると、どこで止まっているかが分かります。

Data 360が向いている企業の3つの特徴

ここまで進め方と測り方を解説してきましたが、どの企業でも同じ効果が出るわけではありません。前提の整い方によっては、着手の順番を変えたほうがよい場合もあります。判断の材料になるのは、接点が分かれているか、同じ相手を別々に管理しているか、AIの活用が計画に入っているかの3点です。3つとも、見積もりを取る前に自社の側だけで確認できる項目です。接点の数を数え、重複の有無を調べ、AIの計画を確かめれば見当がつきます。ここでは、効果が出やすい企業の特徴を整理していきます。

特徴①顧客との接点が複数に分かれている

1つ目の特徴は、顧客と関わる経路が複数あることです。

販売だけを行っている企業と、販売に加えて保守やサポートを提供している企業とでは、蓄積される情報の広がりが違います。後者は、同じ相手について複数の文脈の情報を持っています。統合したときに見えてくるものが多いのは、後者です。

照明器具メーカーは、ディーラー経由と直販の2ルートで販売し、さらに保守サービスも提供していました。同じ取引先について、商談・受注・問い合わせ・保守という4つの文脈の情報を持っています。この構造が、統合の効果を大きくしています。

接点が1つしかない企業では、統合して現れる差も限られます。まず接点の数を数えるところから見当がつきます。数えるのは、顧客と情報のやり取りが発生する経路です。販売・保守・問い合わせ・イベントといった単位で挙げていくと、実態に近い数になります。経路が3つ以上あれば、統合の候補として検討する価値があります。2つであれば、まずその間だけを対象にして様子を見る選択もできます。

特徴②同じ相手を別々に管理している

2つ目の特徴は、実際に重複が発生していることです。

接点が複数あっても、最初から共通の識別子で管理されていれば、統合の必要は小さくなります。逆に、部門ごとに独立して登録している運用が続いていれば、重複は確実に存在します。

確かめる方法としては、主要な取引先を2つのシステムで検索してみることです。表記が一致していなければ、その企業には重複があります。照明器具メーカーで同じ取引先が3通りの表記で登録されていたのも、この方法で見つかりました。

重複の存在は、手作業が発生している証拠でもあります。四半期ごとの名寄せが業務として定着しているなら、その時点で条件を満たしています。定着している作業ほど、誰も疑問を持たなくなります。当たり前になっている手作業を洗い出す作業が、そのまま統合の候補を見つける作業になります。四半期に一度の作業は、日常の視界に入りにくいという性質もあります。前回いつ行ったかを覚えていない作業ほど、洗い出しの対象として見落とされます。

特徴③AIの活用が計画に入っている

3つ目の特徴は、AIを使う計画がすでにあることです。

接点③で触れたとおり、Agentforceの一部の機能はData 360を前提にしています。AIの活用を計画しているのであれば、データの統合は避けて通れません。逆に、当面AIを使う予定がない場合、統合の効果は業務の効率化に限られます。

照明器具メーカーがData 360の検討を始めたきっかけも、AIの試行でした。商談前の要約を試して参照範囲の限界に気づき、そこから基盤の話になっています。この順番は珍しくありません。

統合を先に済ませておくと、AIの検討に入ったときの立ち上がりが速くなります。データ基盤の整備を単独の投資として見るか、AI活用の前提として見るかで、判断の重みは変わります。後者として位置づけられれば、投資の理由も説明しやすくなります。

Data 360が効くのは、顧客との接点が複数あり、同じ相手が別々に管理されており、AIの活用が計画に入っている企業です。

Data 360を急がなくてよい3つのケース

向いている特徴を挙げましたが、当てはまらない場合に無理に進める必要はありません。データ基盤の整備は費用も期間もかかるため、前提が整っていない状態で着手すると、成果が出ないまま評価だけが下がります。一度「効果が見えなかった」という評価が付くと、条件が整った後で再び提案するときの障害になります。急がない判断は、諦める判断とは違います。着手の時期をずらし、その間に前提を整えるという選び方です。ここでは、着手を急がなくてよい3つのケースを解説していきます。

ケース①扱うデータが1つの場所に収まっている

1つ目は、そもそも分断が起きていないケースです。

判断軸①の裏返しにあたります。顧客の情報がSales Cloudの中で完結しており、他のシステムを開く必要がない運用であれば、統合して現れる差はほとんどありません。この状態で基盤を入れると、費用だけが増えます。

確かめる方法としては、担当者が1つの作業のなかで何回画面を切り替えているかを見ることです。切り替えが発生していなければ、分断はありません。切り替えが発生していても、それが別の用途であれば統合の対象にはなりません。

将来的に接点が増える見込みがあるなら、その時期に合わせて検討すれば足ります。保守サービスを新しく始める、直販のルートを増やすといった計画があれば、その時点で分断が生まれるでしょう。計画が具体化した段階で改めて検討すると、無駄な先行投資を避けられます。いま分断していないことは、将来も分断しないことを意味しません。計画の有無を確認しておくと、検討の時期を先に見通せます。

ケース②突き合わせる項目が定まっていない

2つ目は、同一性を判定する材料が揃っていないケースです。

前提②で触れたとおり、判定にはルールが要ります。ルールを組める項目が対象の範囲に存在しない場合、まずその項目を埋める作業が先になります。取引先の名称も住所も、システムごとに任意の形式で入力されている状態では、判定の精度は上がりません。

この作業は、Data 360を入れるかどうかに関係なく必要なものです。入力の形式を決め、既存のレコードを揃える取り組みは、別の場面でも効いてきます。順番を入れ替えると、項目の不揃いという別の原因が、基盤の評価として跳ね返ります。

揃える範囲は、最初に扱う2つのシステムの間だけで構いません。全社の統一を目指すと、着手までの期間が読めなくなります。2つの間で揃えた経験は、次の組み合わせにも使えます。どの項目を基準にし、誰が最終的に決めるのかという手順が一度できていれば、3つ目からは短く済むはずです。揃える作業を1組ずつ積み上げるほうが、全社の統一を目指すより早く進みます。

ケース③統合した後の使い道が決まっていない

3つ目は、統合の先に何をするかが決まっていないケースです。

落とし穴③と重なりますが、着手前の判断としても使えます。使い道が決まっていない状態で統合を始めると、完成の基準が定まりません。どこまで揃えれば十分なのかを誰も判断できず、作業が終わらなくなります。

先に決めるべきなのは、統合された情報を誰がどの場面で見るかです。この1文が書けない段階であれば、統合を始めるより使い道を決める会話を先に持つほうが早く進みます。定着まで伴走する体制をどう組むかも、この段階で検討できる論点です。

データ統合を前提としたCRMの設計論は、ほか記事「Agentic CRMとは？AIが動かすCRMの全体像と設計の考え方」で扱っています。待つ判断も、進める判断と同じくらい具体的な理由にもとづいて選びます。

分断が起きていない・判定の材料が揃っていない・使い道が決まっていないという3つのケースでは、着手を急がず前提を整えるほうが結果的に早く進みます。

【一問一答】Data 360に関するよくある質問

ここまで、Data 360が担う処理から対象の選び方、進め方、測り方までを解説してきました。実際に検討を始めると、名称の変更や費用、期間など、判断の手前で確認しておきたい点が出てきます。稟議を書く場面で問われやすい内容です。以下の回答は、Salesforce公式のTrailheadの記載と、本記事で置いた架空の設定にもとづいています。条件は変わる可能性があるため、契約の前に最新の記載を確認してください。最後に、Data 360についてよく寄せられる質問に答えていきます。

質問①Data 360はData Cloudと何が違うのか

名称が変わっただけで、担う役割は同じです。Salesforce公式のTrailheadには「As of October 14, 2025, Data Cloud has been rebranded to Data 360.」と記載されています。移行期には資料や画面にData Cloudの表記が残る場合があるとも説明されているため、古い資料は同じものを指していると読み替えてください。

質問②Data 360がないとAgentforceは使えないのか

Agentforceのすべてが使えなくなるわけではありませんが、一部の機能はData 360を前提にしています。Trailheadには「the Agentforce Data Library and Einstein Trust Layer don’t work without Data 360」と記載されています（2026年8月時点）。Data 360を切り離した段階計画は立てないほうが安全です。

質問③Data 360は既存のデータ基盤を置き換えるのか

必ずしも置き換えるものではありません。Trailheadでは、Snowflake・Databricks・BigQueryについて、データを複製せずに参照する方式が示されています。すでに社外の基盤を運用している企業では、移し替えずに接続できる場合があります。既存の基盤をどう扱うかは、取り込みの方式を選ぶ段階で決める論点になります。

質問④Data 360の費用はどう決まるのか

扱うデータの量と処理の回数に依存します。機能ごとの定額として決まる形ではないため、対象にするシステムと期間、必要な更新の速さを先に整理してから見積もりを取る順番になります。使いたい業務を伝えたうえで販売元へ確認すると、返ってくる回答の精度が上がります。

質問⑤Data 360の導入にはどのくらい期間がかかるのか

対象の広さで大きく変わるため、一律の目安はありません。本記事で例に挙げた架空のメーカーでは、検討に3か月、2つのシステムを統合するまでに8週間という設定を置いています。期間を短くしたい場合、対象を絞ることが最も効きます。範囲を広げるほど、項目の対応を決める会話の相手が増えるためです。

Data 360はAgentforceがCRMの外まで見るための基盤

Data 360とは、社内外に分かれたデータを取り込み、標準のモデルへ整え、同一の相手を突き合わせて必要な場所へ出力するデータ基盤です。本記事では、必要になる状況から、4つの処理、Agentforceとの接点、扱えるデータの種類、着手前の前提、つまずく落とし穴、対象を選ぶ4つの判断軸、進め方の4ステップ、費用と指標までを、一連の流れとして解説してきました。

本記事で例として挙げた照明器具メーカーの場合も、変わったのは対象の絞り方でした。従業員480名・営業35名・情報システム部5名で、Sales Cloudを6年、Service Cloudを3年使いながら、顧客のデータは4つのシステムに分かれています。4つすべてを統合する計画では日程調整だけで数週間を要し、業務の側から判断軸を当て直したことで、最初に扱う2つへ絞り込めました。統合までにかかったのは8週間です。

データを集めることから始めても、業務は変わりません。自社のどの業務で画面の切り替えが起きているかを数えるところから始めてみてはいかがでしょうか。

なお、どのデータをどの業務のために統合するかを業務設計から一緒に整理し、定着まで伴走してほしい場合は、Agentforce導入・定着支援サービスにお気軽にご相談ください。1ユースケース×3ヶ月のスモールスタートから対応しています。