--- schema_version: "1" id: a24af1952c4b039177bc9acba14f5c043023d525dfbcaf796c0282297b2522f6 title: Data 360 プロビジョニング collection: architect version: next locale: ja-jp portal_url: https://docs.salesforce.com/architect/next/ja-jp/decision-guides/guides/data-360-provisioning.md canonical_url: https://staging.architect.salesforce.com/docs/architect/ja-jp/decision-guides/guide/data-360-provisioning.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: 662be4c4db44d097929805c342e343195c18ec7127a590ff50a54d8e040551c0 products: - 決定ガイド - Architect Site Content Repo updated_at: 2025-10-01T00:00:00Z --- ## 概要 Salesforce Data 360は、Hyperforce上に構築されたデータ プラットフォームで、Salesforceと外部データを、すべての顧客またはアカウントの明確で完全、かつ信頼できる全方位的なビューに統合します。 合併や買収、地域の業務、職務の分離、または歴史的な理由により、多くの場合、企業は複数の Salesforce 組織を運営しています。アーキテクトは、1 つの自宅組織と複数組織のどちらを設定するかだけでなく、複数の独立した Data 360 インスタンスをプロビジョニングするか、Data Cloud One を使用して 1 つのインスタンスで組織を統合するか、Data 360 間のデータ共有 (Data 360 と Data 360 のデータ共有) を使用して独立した Data 360 インスタンス間でコラボレーションするかも決定する必要があります。これらの選択は、ガバナンス、コンプライアンス、コスト、レイテンシ、および組織の AI および組織間プラットフォーム機能の拡張能力に影響します。 Data 360 は、Data 360 ライセンスを受け取る本番組織で自動的にプロビジョニングされます。Data Cloud One は、1 つの自宅組織で Data 360 インスタンスをホストし、他の Salesforce 組織はコンパニオン組織として接続できるようにする Salesforce の複数組織の接続アーキテクチャです。Data 360 ライセンスを保持し、Data 360 ホーム組織となる組織の選択は、長期的な影響を伴う重要なアーキテクチャ上の決定です。 Salesforce Data 360のプロビジョニング方法は、アーキテクチャに関する基本的な決定事項です。これは、企業がどのように顧客データを統合し、ガバナンスを適用し、重要なプラットフォーム機能(特にAI、Agentforce、分析)を組織全体で有効にするかを決定するためです。組織のクラスターを 1 つの Data 360 に固定することで、統合されたデータモデル、一元化されたガバナンス、全社的な AI 準備が実現します。また、コンパニオン組織はデータがローカルにあるかのように共有メタデータと機能にアクセスできます。一方、規制、コンプライアンス、または自律性の要件によって一元化できない場合、Data 360 組織間のデータ共有により、これらのインスタンス間でゼロコピーで選択的なコラボレーションが可能になるため、複数の独立した Data 360 インスタンスが適しています。 建築家にとって、この決定は非常に重要です。データガバナンスを制御するユーザー、データが存在する場所、プラットフォーム機能の有効化方法、将来のインテグレーションと AI イニシアチブの拡張性を定義します。現在 Data 360 を使用していない組織でも、今後 Data 360 アクセスを追加する戦略を立てることで、アーキテクチャを将来に備えることが重要になる場合があります。Sales、Service、Marketing、Commerce、Industries、AgentforceにわたるSalesforceの機能は、Data 360上に構築されることが増えています。これらのプラットフォーム機能を使用する組織は、独自の Data 360 をプロビジョニングするか、共有の Data 360 にコンパニオン組織として接続する必要があります。 このガイドは、アーキテクトがシンプルさ、エンタープライズ全体の一貫性、コンプライアンス、拡張性のバランスを取るプロビジョニング戦略を設計するのに役立ちます。これにより、組織は自信を持ってData 360をCustomer 360、AI、クロス プラットフォームのイノベーションに活用できます。Data 360 をプロビジョニングする組織の選択方法、および Data Cloud One と Data 360 組織間のデータ共有の選択方法を決定し、Data 360 中心の未来にビジネスを進めるための強固な基盤を築くのに役立ちます。 --- ## プロビジョニングに関する考慮事項 Data Cloud One と Data 360 組織間のデータ共有のどちらを選択するか、またはどの組織をホーム組織として指定するかなど、すべてのプロビジョニングの選択は、次の横断的な考慮事項に照らして評価する必要があります。
考慮事項 重要な理由 シナリオの例
データレジデンシーとコンプライアンス データを保存および処理する場所を決定します。規制ルールでは、特定の地域または複数のインスタンスが必要になる場合があります。 あるグローバル銀行は、GDPR に準拠するためにフランクフルトに地理的に配置された Salesforce 組織に Data 360 テナントをプロビジョニングし、米国部門用にバージニア州の組織に Data 360 テナントをプロビジョニングしました。
ガバナンスとセキュリティ Data 360 を所有および管理するのは誰ですか?ポリシーはビジネスユニットごとに一元管理するか、委任するか? 強力な中央 IT を持つ多国籍企業が、Center of Excellence によって管理される専用の自宅組織を作成します。
Autonomy vs.一元化 リーダーによって、データの所有権が異なる場合があります。自律性では複数の Data 360 が、一元化では Data Cloud One が適しています。 独立した子会社を持つ持株会社では、各 BU が独自の Data 360 を実行できます。
レイテンシとパフォーマンス 特に、リージョン全体の Data 360 テナントに接続されているコンパニオン組織の場合、クエリ速度とエクスペリエンスに影響します。 ロンドンの営業チームが米国の Data 360 テナントからデータを照会すると、遅延が大きくなる場合があります。
インテグレーションの複雑さ Data 360 テナントが増えると、パイプライン、API、ミドルウェアが増えます。統合により、統合が簡素化されます。 ある小売業者は、Data Cloud One 設定に統合することで、10 個の ETL パイプラインを構築する必要がなくなります。
ゼロコピーデータソース領域 Zero Copy コネクタには、Data 360 を配置できるリージョンを制限するクロスリージョンアクセス要件がある場合があります。 ある会社に AWS eu-west-1 リージョンの Snowflake インスタンスがあります。Zero Copy を使用して自分の地域の Data 360 にデータを統合できますが、Zero Copy を使用して米国地域の Data 360 に統合することはできません。
プライベートコネクトのリージョン間の互換性 場合によっては、データソースが Data 360 テナントと同じリージョンにあるかどうかによってプライベートコネクトのサポートが異なる場合があります。 aws-east-1 リージョンに、ゼロコピーで接続する Snowflake インスタンスがあります。Data 360 ホーム組織が同じリージョンにある場合のみ、プライベートコネクトネットワーク接続を確立できます。
コストとライセンス 各 Data 360 テナントのコストが増加します。より少ないインスタンスに統合することで、支出が最適化されます。 あるヘルスケア事業者は、複数の独立した Data 360 インスタンスではなく Data Cloud One を採用してライセンスコストを削減します。
将来の拡張性 今日のプロビジョニングの選択肢は、成長の基盤となります。 ある SaaS 会社は、1 つの Data 360 インスタンスから開始し、Salesforce 組織の子会社を買収して Data Cloud One に拡張する予定です。
エンタープライズ全体のAI対応 AI機能とAgentforceでは、すべての組織に接続されたData 360テナントが必要です。プロビジョニングの決定は、AI モデルが企業全体でどのようにトレーニングおよび有効化されるかに影響します。 ある金融サービス会社は、データをData Cloud Oneに統合し、Einstein AIモデルがエンタープライズ全体の顧客データにアクセスできるようにします。
### 重要な考慮事項 --- ## セクション 1:Provisioning Data 360 – Choosing the Home Org (Data 360 のプロビジョニング – ホーム組織の選択) ### 1.1 Data 360 ホーム組織とは? Data 360 ライセンスを購入すると、そのライセンスに関連付けられた Salesforce 組織に Data 360 インスタンスがプロビジョニングされます。この組織は Data 360 ホーム組織と呼ばれます。 Data 360 ホーム組織を示す決定図 ホーム組織は、Data 360 インスタンスのアンカーです。ここで、 - Data 360 のストレージとコンピューティングは (プロビジョニング時に選択した地域で) 管理されます。 - 管理、ガバナンス、セキュリティポリシーが適用されます。 - データの取り込み、ハーモナイゼーション、ID解決、セグメンテーション、有効化が実行されます。 マルチ組織のシナリオでは、ホーム組織で他の Salesforce 「コンパニオン」組織の中央 Data 360 インスタンスを管理します。 ホーム組織が重要な理由: - Data 360 インスタンスの地理的位置を決定します。 - Data 360 インスタンスの所有者と管理者を決定します。Data 360 ホーム組織の管理者は、Data 360 に取り込まれたすべてのデータにアクセスできます。 - Data Cloud One 設定でコンパニオン組織の接続を制御します。 - これにより、エンタープライズデータ戦略の基盤が確立されます。後で変更するのは困難で、中断を伴います。 ### 1.2 決定:ホーム組織として既存の組織または新規組織 最初の大きな決定は、既存の本番組織で Data 360 をプロビジョニングするか、新しい専用組織を作成してホーム組織として機能させるかです。 既存の組織と新しい組織をホーム組織として示した決定図 #### オプション A:既存の組織での Data 360 のプロビジョニング **最適な用途:**1 つの Salesforce 組織を使用しているお客様、またはほとんどのビジネスが実行されている主要な一元化された組織をすでに使用している複数組織のお客様。 既存の組織での Data 360 プロビジョニングを示す図 - **長所**: - 最もシンプルなパス:Data 360 は、CRM データがすでに存在する場所でプロビジョニングされます。 - ローカルの営業、サービス、マーケティングデータにすぐにアクセスできます。 - 追加のインテグレーションは必要ありません。 - 管理するライセンスと環境が少ない。 - 早期導入、パイロット、本番での使用事例を加速します。 - **短所**: - 既存の組織のガバナンスまたは技術的負債を継承する可能性がある。 - 「メイン組織」が 1 つも存在しない場合、1 つを選択すると所有権に関する議論が生じる可能性があります。 - 組織の場所に関連するパフォーマンス。企業全体のレジデンシーのニーズと一致しない場合があります。 - 複数のビジネスユニットで異なる組織を使用している場合、ローカルプロビジョニングを Data Cloud One と組み合わせないと断片化が発生する可能性があります。 **例:** 1 つの Salesforce 組織を持つ SaaS 会社は、顧客のサブスクリプションデータとサポートデータを統合するために、その組織に Data 360 をプロビジョニングします。 #### オプション B:新しい専用組織での Data 360 のプロビジョニング **最適な用途:**複数の Salesforce 組織があり、1 つの主要組織で連携できないお客様、または強力な Center of Excellence (CoE) モデルを使用する企業。 新しい専用組織での Data 360 プロビジョニングを示す図 - **長所**: - 継承された組織の複雑さがなく、ガバナンスを一から構築できます。 - 複数の基幹業務の一元管理。 - コンプライアンスのニーズに基づいて地域を柔軟に選択できます。 - 1 つのビジネスユニットに縛られず、中立的な「共有サービス」組織として機能します。 - 将来の Data Cloud One アーキテクチャ (複数のコンパニオン組織がある自宅組織) に合わせて設定します。 - **短所**: - 顧客は、Data 360 をプロビジョニングする新しい Salesforce 組織のライセンスを取得する必要があります。 - Data Cloud One コンパニオン接続を介して組織を Data 360 に接続するには、追加のインテグレーションが必要です。 - 管理オーバーヘッド (ユーザー管理、セキュリティ、ID) を追加する場合があります。 - 既存の本番組織のプロビジョニングと比較して、タイム トゥ バリューが遅い。 **例:** ある多国籍金融サービス会社は、Data 360 をプロビジョニングするための専用の自宅組織を作成します。すべてのビジネスユニット組織 (リテール、ウェルス、コマーシャルバンキング) は、Data Cloud One を介してコンパニオン組織として接続します。 #### 決定条件
考慮事項 在宅組織としての既存の組織 (優先デフォルト) ホーム組織としての新規組織 (代替)
シンプルさ 既存のユーザーとデータ構造に基づいて構築されているため、設定を迅速化できます。Data 360 はデフォルトでホーム組織と統合されています。 新しい Salesforce 組織のライセンスと設定、およびそれを管理するための追加の管理オーバーヘッドが必要です。
Time-to-Value ローカル CRM データの迅速な使用。 傾斜が遅い。インテグレーションが必要。
ガバナンス 既存の組織の基本ガバナンスモデル (既存のユーザーと権限セット) を継承します。組織がすでに中央にある場合は、これで問題ありません。 ガバナンスのための白紙の状態。CoE 主導のモデルに最適です。
コンプライアンス 既存の組織の地域に関連付けられたレジデンシー。 既存の組織から独立した地域を柔軟に選択できます。
Performance ローカル CRM クエリで最高のパフォーマンス。 コンパニオン組織の接続性 (他の組織と同じリージョンかクロスリージョンか) によって異なります。
将来の拡張性 Data Cloud One と組み合わせると適切に機能します。間違った組織が選択されている場合、後で移行するのが困難です。 中立性を考慮して設計された Data Cloud One を使用して簡単に拡張できます。
Cost (コスト) 増分コストを削減。 環境の追加によるオーバーヘッドの増加。
### 1.3 推奨事項 原則として、既存のメジャー組織をホーム組織として使用し、初期作業を最小限に抑えて導入を加速します。長期的なガバナンスまたはコンプライアンス戦略で必要な場合にのみ、新しい専用のホーム組織を作成します。新しい専用の在宅組織を作成することは、Center of Excellence (COE) を使用する大規模企業にとって一般的な選択肢です。 **単一組織環境** 既存の本番組織で Data 360 をプロビジョニングします。これにより、シンプルさと即座の価値が最大限に高まります。不要なインテグレーションのオーバーヘッドを回避できます。 **複数組織環境** ホーム組織として機能させるには、主要な組織 (通常はビジネスの大部分を実行する組織、またはすでに一元化された CRM として機能する組織) のいずれかを選択します。これにより、複雑さが軽減され、設定作業を最小限に抑え、Data 360 の価値をすばやく実感できます。既存の主要組織を使用すると、新しい環境の管理にかかるコストと統合作業も回避できます。 **新しい専用の自宅組織を検討するケース** 組織に強力な Center of Excellence (CoE) があり、ビジネスユニット組織から独立したガバナンスが必要な場合。コンプライアンスや組織の制約のために適切な既存の組織が 1 つもない場合。このような場合、新しい自宅組織を作成すると、柔軟性と中立性が確保されますが、タイム トゥ バリューは遅くなります。 --- ## セクション 2:複数組織戦略と Data Cloud One ### 2.1 複数組織の課題 多くの場合、企業は複数の Salesforce 組織を運用していますが、これはエッジケースではなく、通常のケースです。2024 年 2 月の時点で、約 19,000 人の Salesforce ユーザーがすでに複数の Salesforce 組織を運用しています。 なぜこのようなことが起こるのでしょうか? - **買収と合併：**新しく買収した会社は、独自の Salesforce インスタンスを持ち込みます。 - **地域のオペレーション：**多くの場合、データレジデンシー法を満たすために、EU、北米、アジア太平洋などの組織を分離します。 - **機能の分離：**さまざまなビジネスユニット (Retail Banking、Wealth Management、Insurance など) が、自律性を確保するために独自の組織を維持しています。 - **規制またはセキュリティの分離：**特定の業界では、コンプライアンス上の理由で論理的に区別された組織が義務付けられています。 - **歴史的/技術的な理由:**時間の経過とともに、顧客は複数の組織を有機的に蓄積します。 それぞれの理由は個別に意味を持ちますが、それらが組み合わさってデータが断片化します。統合レイヤーを使用しない場合、各組織には顧客の部分的なビューのみが表示されます。 アーキテクチャの課題:コンプライアンス、ガバナンス、自律性の要件を尊重しながら、組織全体のデータを 1 つの情報源に統合する方法は? --- ### 2.2 Data Cloud One とは? Data Cloud One は、複数の Salesforce 組織で 1 つの Data 360 インスタンスを共有できる Salesforce の複数組織接続アーキテクチャです。これは、複数の Salesforce 組織を使用する企業に推奨されるパターンです。 Data Cloud One クラスターでは、1 つの Salesforce 組織が Data 360 インスタンスをホストするホーム組織として指定されます。他の Salesforce 組織はコンパニオン組織として接続し、ホーム組織の Data 360 の統合データとメタデータを使用します。 Data Cloud One アーキテクチャを示す図 #### Data Cloud One のしくみ
  1. データ取り込みと統合 (自宅組織)
  2. データスペースアーキテクチャ
  3. メタデータ共有
    コンパニオン組織は、DMO(データ モデル オブジェクト)、統合プロファイル スキーマ、計算済みインサイト、セグメントなどのメタデータ定義をホーム組織から受け取ります。これらは、コンパニオン組織内ではローカルアセットのようにネイティブに表示されますが、実際にはホーム組織にリンクされています。
  4. Jobs to Be Done in Home Orgg vs.コンパニオン組織
    5. 機能へのアクセスは、ホーム組織とコンパニオン組織で異なります。コンパニオン組織では、データの取り込みや統合ができず、取り込み、モデリング、統合はホーム組織に依存します。コンパニオン組織は Data 360 データにアクセスして Data 360 プラットフォーム機能を強化し、共有された信頼できるデータの上にローカルインサイト、セグメント、フローを作成できます。将来のビジョンでは、有効化機能にもアクセスできます。
    機能 ホーム組織 コンパニオン組織
    Connect 設定コネクタ、データストリームの作成、データの取り込みまたは統合 ✅ ❌
    調和と統合 データ変換と ID 解決の構築および実行 ✅ ❌
    データスペースと権限によるデータの保護のガバナンス ✅ ✅
    セグメントと予測 セグメント、インサイト、Einstein Studioモデルの構築 ✅ ✅
    Activate Everywhere Activations、データアクション ✅ ✅
    プラットフォーム機能プロンプトビルダー、フロー、レポート、強化など ✅ ✅
    Data 360対応機能 Prospecting Center、Sales CloudおよびService Cloudの機能、Agentforceなど ✅ ✅
  5. プラットフォーム機能パリティ
    ユーザーとビルダーの観点では、メタデータが共有されると、Salesforce Platform 機能の使用に関してホーム組織とコンパニオン組織でいくつかの機能の違いが生じます。サポートされる機能のリストは、「Data 360 Features on Companion Orgs (コンパニオン組織の Data 360 機能)」を参照してください。
  6. 消費モデル
    すべてのコンパニオン組織のアクティビティ(クエリ、セグメントの実行、Data 360トリガー フロー、AIの使用状況、Einstein Trust Layerのログ記録など)では、ホーム組織のData 360クレジットが使用されます。消費は一方向に流れます。クレジットは一元化され、請求され、自宅組織のクレジット割り当てに対して追跡されます。ただし、ドリル ダウンすると、各個人組織が Digital Wallet で使用したクレジット数を確認できます。
  7. 設計原則:横方向の構築
    Data Cloud One は、Sandbox によく似た Salesforce Platform の水平構造として設計されています。目標は、Salesforce がリリースするすべての新機能が、追加の設定なしで自宅組織とコンパニオン組織の両方で機能することです。これにより、Data Cloud One は単なるデータアーキテクチャの選択肢ではなく、今後の Salesforce Platform の基盤要素となります。
--- ### 2.3 決定:複数の独立した Data 360 と1 つの共有データ 360 (Data Cloud One) 複数の組織を持つ企業は、エコシステム内で Data 360 を配置する方法と場所を選択する必要があります。各組織で独立した Data 360 をプロビジョニングするか、Data Cloud One を使用して 1 つの自宅組織で組織を統合しますか? #### オプション A:複数の独立した Data 360 各 Salesforce 組織は、独自の Data 360 インスタンスをプロビジョニングします。 **長所**: - **自治**:各ビジネスユニットまたは地域が独自の Data 360 を制御します。 - 各組織内**のシンプルさ**:ガバナンス、セキュリティ、カスタマイズはローカライズされています。 - **法令順守**:厳格な規制の分離が必要な場合 (データが国境を越えてはならない場合など) に便利です。 **短所**: - **データ サイロ:**Customer 360 は組織全体で実現できません。 - **コストの増加**:各インスタンスには、ライセンス、管理、インテグレーションが必要です。顧客は、複数の異なる組織で完全な C360 ビューを実現するために、同じソースデータを複数回取り込むことになります。 - **重複作業:**各 Data 360 で ID 解決、セグメンテーション、強化を繰り返す必要があります。 #### オプション B:1 つの共有データ 360 (Data Cloud One クラスター) 1 つの Data 360 がホーム組織にプロビジョニングされ、他の Salesforce 組織がコンパニオン組織として接続されます。 **長所**: - **SSOT(Single Source of Truth):**すべての組織で同じ統合データモデルを共有します。 - **コスト効率：**管理する Data 360 ライセンスとインフラストラクチャは 1 つのみです。 - **統合ガバナンス:**ポリシー、セキュリティ、およびコンプライアンス管理が一元的に適用されます。 - **組織間強化：**コンパニオン組織は、ハーモナイズプロファイル、インサイト、セグメントにアクセスできます。 - **AIの準備状況:**企業全体のデータセットにより、AI モデルのトレーニングと有効化を改善できます。 - **将来への対応:**新しいコンパニオン組織の追加は簡単で、新しい Data 360 は必要ありません。 **短所**: - **追加の準備:**組織間接続の計画が必要です。 - **レイテンシに関する考慮事項:**異なる地域のコンパニオン組織では、クエリに時間がかかる場合があります。 - **複雑なガバナンス：**組織ごとにカスタマイズのニーズが大きく異なる場合、きめ細かなガバナンスが複雑になる可能性があります。 #### オプション C:複数の Data Cloud One クラスター 場合によっては、ガバナンス、コンプライアンス、その他のビジネス要件により、すべての組織をクラスター化することが現実的でない場合があります。そのため、企業が複数の Data 360 を運用し、それぞれがコンパニオン組織の異なるクラスターのホーム組織であるハイブリッドソリューションを実装する必要が生じる可能性があります。 #### 例: ある多国籍企業では、ヨーロッパ、米国、アジアなど、さまざまな地域に Salesforce 組織があります。地域のデータレジデンシー規制に準拠するために、地域ごとに 1 つの Data 360 をプロビジョニングします。 #### 決定条件
考慮事項 複数の独立した Data 360 1 つの共有データ 360 (Data Cloud One)
自律 各組織またはビジネスユニットの高い自律性。 一元化されたガバナンス、組織ごとの自律性の低下。
コンプライアンス 厳格な分離が必要な場合 (地域の法律など) に便利です。 レジデンシーで集中管理が許可されている場合に最適です。
Cost (コスト) ライセンスコストと管理コストの増加。 コスト効率が向上。多くの組織で 1 つのライセンスを使用できます。
ガバナンス 断片化。ポリシーは組織によって異なります。 組織全体で一元化された一貫したポリシー。
データサイロ 各組織には独自のビューがあり、Enterprise 360 はありません。 統合されたデータセット (重複なし)。
AI/Analytics 各組織のデータに制限されます。 精度が向上したエンタープライズ規模のモデル。
複雑さ 管理するインスタンスが増え、インテグレーションも増えました。 シンプルなアーキテクチャ、可動部品の削減。
Performance 組織内の使用事例に最適です。 コンパニオン組織へのアクセスで遅延が発生する場合があります。
--- ### 2.4 おすすめ **優先パターン:****Data Cloud One** デフォルトでは、複数組織企業の接続されたコンパニオン組織を含む 1 つの自宅組織になります。 これにより、企業全体のCustomer 360が作成され、ガバナンスがシンプルになり、コストが最適化されます。 **複数の Data 360 を使用する場合:** コンプライアンス、レジデンシー、または組織の自主性によって厳密に要求される場合のみ。たとえば、規制のためにヨーロッパの業務を米国の業務から完全に分離する必要がある場合などです。 **Data Cloud One でホーム組織を選択する方法:** まず、主要な組織 (通常はほとんどのビジネスが実行されている組織) のいずれかを検討します。Data 360 をプロビジョニングすることで、複雑さを最小限に抑え、早期の価値を最大化できます。 適切な既存の組織がない場合のみ、Center of Excellence チームが管理する専用の自宅組織を作成することを検討してください。 **一般原則:** マルチ組織環境では、Data 360 の数を最小限に抑えます。Data Cloud One をデフォルトパターンとして選択すると、重複が減り、AI の準備が有効になり、ガバナンスが簡素化されます。 --- ## セクション 3:複数の Data 360 および Data 360 組織間のデータ共有 ### 3.1 Data 360 組織間のデータ共有とは? Data Cloud One はほとんどの企業にとって推奨される方法ですが、複数の Data 360 インスタンスのプロビジョニングが必要なシナリオもあります。複数の Data 360 が存在すると、それらの統合は自動的に行われません。 Data 360 to Data 360 データ共有により、重複やカスタムパイプラインなしで Data 360 インスタンス間で特定のオブジェクトを共有できます。これは、Data 360 全体でのコラボレーションのために設計されたゼロコピーメタデータ共有メカニズムです。 #### 操作手順 - 各 Data 360 は、独自のホーム組織でプロビジョニングされます。 - 管理者は、共有する特定のオブジェクトのグループであるデータ共有を作成できます。 - 選択したデータへのアクセスは対象組織の Data 360 と共有され、オブジェクトはローカルで定義されたかのように表示されます。基盤となるデータはソース Data 360 に残り、アクセス権のみが共有されます。 - タグは共有されません。使用できるのは未加工オブジェクトのみです。対象組織は、必要に応じてガバナンス、運用、AI タグを再適用する必要があります。 #### Data Cloud One との主な違い - Data Cloud One では、複数のコンパニオン組織が 1 つの Data 360 インスタンスを共有します。プラットフォーム機能(Agentforce、Prospecting Center、Tableau Nextなど)はすべて同じ基礎データで実行され、一貫性が確保されます。 - Data 360 組織間のデータ共有を使用する場合、各組織に独自の Data 360 があります。組織 A と組織 B の Agentforce などの機能は、それぞれローカル インスタンスで独立して動作します。共有は自動的に行われません。特定のオブジェクトに対してのみコラボレーションするには、意図的なデータ共有を作成する必要があります。 --- ### 3.2 Data 360 組織間でのデータ共有の使用事例 **地域のコンプライアンス：** ある多国籍小売業者は、EU と米国の 1 つの Data 360 をプロビジョニングしています。Data 360-to-Data 360 データ共有では、未加工データをローカルに残したまま、米国本社と共有するためのインサイト (ロイヤルティ KPI など) を集計できます。 **ビジネス・ユニットのコラボレーション：** ある複合企業が小売と保険で別々の Data 360 を実行しているとします。Data 360 間のデータ共有により、ユーザーは移動やコピーを行うことなく、1 つの信頼できるデータソースにアクセスできます。Data 360 組織間のデータ共有により、保険組織は対象を絞ったクロスセルキャンペーンで小売の「High Value Customer」セグメントを受け取ります。 **M&A:** 親会社が独自の Data 360 を持つ子会社を買収します。2 つのインスタンスを管理する場合、短期のデータサイロを保持することで、データセキュリティと SSOT の整合性が維持されます。同時に、2 つの Data 360 インスタンス間でデータを共有することで、移行中に必要なコラボレーションが可能になります。 **統合エグゼクティブ・ダッシュボード：** 大陸にまたがる多国籍の広がりでは、地域ごとに個々の Data 360 がプロビジョニングされます。エグゼクティブは、四半期パフォーマンスの統合ビューを求めています。各地域の Data 360 は、集計された計算済みインサイトを「エグゼクティブ組織」と共有し、企業全体のレポートを可能にします。 #### Data 360 組織間でのデータ共有の長所と短所
要素 プラス面 マイナス面
データレジデンシー コラボレーションを可能にしながら、地域の分離をサポートします。 複数の Data 360 を管理する必要はありません。
データの複製 ゼロコピー、オブジェクトの重複なし。 各データ共有に含めるオブジェクトを慎重に選択する必要があります。
ガバナンス 共有は明示的かつ慎重に行われます (オブジェクトレベル)。 タグまたはポリシーフローはありません。対象組織はガバナンスを再適用する必要があります。
複雑さ 一元化なしで選択的なコラボレーションを可能にします。 複数の Data 360 とデータ共有の管理が必要です。
AI/Analytics 地域の AI/分析が可能。インサイトを組織間で共有できます。 データを意図的に共有しない限り、全社的な AI は使用されません。
プラットフォーム機能 各組織の Data 360 対応機能は独立して実行されます。 自動共有なし — 慎重に設計しないと重複のリスクがあります。
Cost (コスト) ETL パイプラインの必要性を減らすことができる。 ただし、複数の Data 360 のコストが発生します。データクエリとデータ共有のクレジットを消費します。
#### 決定条件
考慮事項 Data Cloud One (マルチ組織に推奨) Data 360 組織間でのデータ共有
一元化された情報源 ✅ はい — すべての組織で同じ DC を共有します。 ❌ いいえ — 各 Data 360 には独自のデータモデルがあります。
コンプライアンス レジデンシーで一元化が許可されている場合にのみ機能します。 居住法によって一元化が妨げられている場合に必要です。
ガバナンス 一元化された一貫性。 統合。オブジェクトレベルの共有を意図します。
複雑さ 可動部品が少なく、シンプル。 または複雑 — 設定データ共有と複数の Data 360 が必要です。
AI/Analytics エンタープライズ全体の AI モデル。 地域 AI。インサイトは選択的に共有できます。
プラットフォーム機能 Shared Data 360 では、すべての機能がホームとコンパニオンで一貫して動作します。 機能は Data 360 ごとに独立して実行されます。共有は明示的に行う必要があります。
### 3.3 ベストプラクティス **エンタープライズに複数の Data 360 がある場合:** - カスタムパイプラインを作成したりデータを複製したりするのではなく、Data 360 組織間でデータ共有を使用してコラボレーションします。 - データ共有を作成して対象組織に付与することで、特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。 - タグは共有されないことに注意してください。受け取り側組織はタグ (ガバナンス、分類、AI 強化など) を再適用する必要があります。 **Data 360 組織間のデータ共有を使用する場合:** - 一元化を妨げる規制要件を満たす。 - ビジネスユニットの自律性を維持しながら、選択的なコラボレーションを実現する。 - 複数の地域で統合エグゼクティブダッシュボードを提供する。 - 統合がすぐには実現できない M&A シナリオの橋渡しをします。 **慎重に設計** 共有は意図的でオブジェクト固有である必要があります。「過剰な共有」を避ける — データ共有をビジネスとコンプライアンスのニーズに合わせます。Data 360-to-Data 360 データ共有は、 Data Cloud One の代替戦略としてではなく、統合戦略として扱います。 --- ## サマリー
  1. すべての組織が Data 360 へのアクセスを計画する必要がある
  2. 組織ごとではなく、企業全体で考える
  3. データサイロの最小化
  4. 複数の Data 360 を実行する必要がある場合は慎重に設計してください
  5. ガバナンスと所有権を早期に計画する
  6. 短期的なショートカットの回避
Salesforce Platform は、顧客セグメンテーションから AI エージェントのグラウンディングまで、すべての機能がデータ 360 ファーストモデルに依存するように進化しているため、これらのプロビジョニングの選択は非常に重要です。今日の意思決定により、企業が顧客データをどの程度効果的に統合できるか、新しい Salesforce 機能をどの程度迅速に採用できるか、ビジネス全体で AI をどの程度自信を持って拡張できるかの基盤が構築されます。成功するためには、慎重にプロビジョニングし、重複を最小限に抑え、コンプライアンス要件に準拠し、慎重に管理し、長期的な視点で考える必要があります。最終的に、Data 360 のプロビジョニングは、データ、AI、CRM を 1 つの統合されたプラットフォームとして連携させるための最初のステップです。 # ## 著者について Kunal Goyal は Salesforce の製品管理ディレクターで、Data 360 内のマルチ組織アーキテクチャと拡張性の向上に取り組んでいます。2017年より、組織間コラボレーションとマルチテナントシステム設計を中心に複数のイニシアチブと製品を率いている。Kunal は、Data 360 のベストプラクティスアーキテクチャリードの 1 人で、Data Cloud One、設定、プロビジョニング、管理エクスペリエンスのプロダクト所有者です。 Erin Wagner Tidwell は、Data 360 のプリンシパルテクニカルライターおよびコンテンツデザイナーです。2013 年から Salesforce に勤務。明確で一貫性のある正確な技術ドキュメントとアプリケーション内コミュニケーションを通じて、Data 360 をよりわかりやすく、使いやすくすることに専念しています。 Yugandhar Bora は、Salesforce のソフトウェアエンジニアリングアーキテクトで、Data & Intelligence アプリケーションプラットフォーム内のデータアーキテクチャを専門としています。データガバナンスと統合データモデルに焦点を絞ったエンタープライズアーキテクチャレビューボード (EARB) イニシアチブを主導しながら、自動化プラットフォームプロビジョニングソリューションに貢献しています。 Samarpan Jain は、Commerce Cloud、プラットフォームインテグレーション、組織間アーキテクチャを専門とする Salesforce のプリンシパルアーキテクトです。Salesforce で最も勤続年数が長い従業員の 1 人で、政府機関の顧客向けのデータレジデンシーコンプライアンスや Data 360 利用状況属性システムなどの重要なイニシアチブを主導しています。