--- schema_version: "1" id: 298e4fa197730b9ea396ea0f5df684367b668089c6c1695d0546afcb951f3cb8 title: Data 360 プロビジョニング collection: architect version: current locale: ja-jp portal_url: https://docs.salesforce.com/architect/current/ja-jp/decision-guides/guides/data-360-provisioning.md canonical_url: https://architect.salesforce.com/docs/architect/ja-jp/decision-guides/guide/data-360-provisioning.html source_site: architect.salesforce.com content_type: documentation content_hash: 5ec6c02ac69b4441c6f0f734d002515811420869386b767d8b94b363d509d907 products: - 決定ガイド - Architect Site Content Repo updated_at: 2025-10-01T00:00:00Z --- # Data 360 プロビジョニング Salesforce Data 360は、[Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/)上に構築されたデータ プラットフォームで、Salesforceと外部データを、すべての顧客またはアカウントの明確で完全、かつ信頼できる全方位的なビューに統合します。 合併や買収、地域の業務、職務の分離、または歴史的な理由により、多くの場合、企業は複数の Salesforce 組織を運営しています。アーキテクトは Data 360 に関するいくつかの決定を行う必要がありますが、これらはすべてガバナンス、コンプライアンス、コスト、レイテンシ、および AI と組織間プラットフォームの機能を拡張する組織の能力に影響します。 ## ガイドの概要 このガイドでは、Data 360 を使用してプロビジョニングに関する意思決定を行うためのフレームワークについて説明します。 - 単一ホーム組織と複数組織構成の選択 - 複数の独立した Data 360 インスタンスのプロビジョニング - Data Cloud One を使用して 1 つのインスタンスで組織を統合する - Data 360 組織間のデータ共有を使用する独立した Data 360 インスタンス間のコラボレーション 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 アクセスを追加する戦略を立てることで、アーキテクチャを将来にわたって保証することが重要です。営業担当、サービス担当、マーケティング、コマース担当、業種、および Agentforce 全体で Salesforce の機能が Data 360 上に構築されることが増えています。これらのプラットフォーム機能を使用する組織は、独自の Data 360 をプロビジョニングするか、共有の Data 360 をコンパニオン組織として接続する必要があります。 このガイドは、アーキテクトがシンプルさ、エンタープライズ全体の一貫性、コンプライアンス、拡張性のバランスを取るプロビジョニング戦略を設計するのに役立ちます。これにより、組織は自信を持って Data 360 を Customer 360、AI、クロスプラットフォームのイノベーションに活用できます。このガイドを使用して、Data 360 が必要な組織と、Data Cloud One を使用するか、Data 360 組織間でデータ共有を使用するかを判断します。この戦略により、Data 360 中心の未来に向けた強固な基盤が確立されます。 ## 範囲内の商品
Salesforce Platform のロゴ Salesforce Data 360 は、任意のソース (CRM、Web、モバイル、外部データレイク) のデータを 1 つのアクション可能な顧客プロファイルにハーモナイズして統合する、Salesforce のリアルタイムのハイパースケールデータプラットフォームです。Customer 360プラットフォームの重要なコンポーネントとして、セールス、サービス、マーケティング全体のAI、分析、パーソナライズされたエクスペリエンスを強化します。
## ポイント - **すべての組織は、Data 360インスタンスへのアクセスを計画する必要があります。**各組織は、Data 360 ホーム組織をホストするか、Data Cloud One を介して接続されたコンパニオン組織である必要があります。 - **組織ごとではなく、企業全体を考慮します。**単独で、事業ごとの意思決定は避けてください。理想的には、エンタープライズアーキテクチャまたはデータガバナンス協議会が、プロビジョニング戦略について共同で決定するべきです。広範な統合データセットに依存する将来の AI およびアナリティクスのニーズを常に予測してください。 - **ガバナンスとオーナーシップ / 所有権を早期に計画します。**Data 360 を一元管理するか (Center of Excellence モデル)、事業部門に委任するかを決定します。システム管理者、セキュリティチーム、コンプライアンスリードの役割を定義します。オーナーシップが不明瞭であると問題が発生する可能性があるため、あいまいさを避けてください。 - **プロビジョニングはライセンスに関連付けられています。**Data 360 ライセンスを購入した組織によって、Data 360 がプロビジョニングされる場所が決まり、その組織の場所によって地域が決まります。 - **データソースのサポートに関する考慮事項を理解します。**さまざまなパブリッククラウドおよびゼロコピーデータソースでサポートされるリージョンに注意してください。また、これらのデータソースへの接続にセキュリティ体制のプライベートコネクトが必要かどうか、および地域内接続と地域間接続のどちらがサポートされるかも判断します。 - **単一組織または複数組織のいずれを使用しているかに基づいてプロビジョニングします。**単一組織の顧客は、既存の本番組織で Data 360 をプロビジョニングして、最短で価値を実現できます。複数組織のユーザーの場合、作成する Data 360 インスタンスの数をできるだけ少なくして複雑さを最小限に抑えます。理想的なのは、Data Cloud One 設定を使用することです。 - **複数の Data 360 インスタンスは、必要な場合にのみ**使用**してください。**複数のインスタンスは、コンプライアンス、レジデンシー、または組織の自律性によって必要とされる場合にのみ使用してください。このような場合は、Data 360 組織間[のデータ共有](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5)を使用して安全なコラボレーションを実現します。 - **Data 360 組織間のデータ共有は、カスタム ETL パイプラインではなくコラボレーション用に設定します。**データ共有を介して特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。タグは共有されず、消費はソース組織に請求されます。 - **短期的なショートカットは避けてください。**長期計画なしで概念実証（POC）のために複数の Data 360 組織をスピンアップしないでください。パイロットと早期展開を企業全体のプロビジョニング戦略に合わせます。 ## 決定ポイント すべてのプロビジョニングの選択肢（Data Cloud One、Data 360 組織間のデータ共有、またはホーム組織の指定）を、次の横断的な考慮事項に照らして評価します。
考慮事項 重要な理由 シナリオの例
データレジデンシーとコンプライアンス データを保存および処理する場所を決定します。規制ルールでは、特定の地域または複数のインスタンスが必要になる場合があります。 あるグローバル銀行は、GDPR に準拠するためにフランクフルトに地理的に存在する Salesforce 組織で Data 360 テナントをプロビジョニングしています。US ディビジョンのバージニアの組織に別のテナントをプロビジョニングします。
ガバナンスとセキュリティ ポリシー管理や委任戦略を含め、Data 360 の管理者と所有権を特定します。 強力な中央 IT を持つ多国籍企業が、Center of Excellence によって管理される専用の Home 組織を作成します。
自律性と集中管理 異なるリーダーがデータの個別の所有権を持ちたい場合があります。自律性を重視する場合は、複数の Data 360 組織が優先されます。一元化により、Data Cloud One が優先されます。 独立した子会社を持つ持株会社では、各ビジネスユニットが独自の 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 360 インスタンスではなく Data Cloud One を採用してライセンスコストを削減します。
将来の拡張性 今日のプロビジョニングの選択肢は、成長の基盤となります。 ある SaaS 会社は、1 つの Data 360 インスタンスから開始し、Salesforce 組織の子会社を買収して Data Cloud One に拡張する予定です。
企業全体の AI 準備状況 AI機能と Agentforce では、すべての org に接続された Data 360 テナントが必要です。プロビジョニングの決定は、AI モデルが企業全体でどのようにトレーニングおよび有効化されるかに影響します。 ある金融サービス会社は、データをData Cloud Oneに統合し、Einstein AIモデルがエンタープライズ全体の本顧客データにアクセスできるようにします。
## 使用事例 Data 360 プロビジョニングの決定が必要なメジャーユースケースは 3 つあります。 - Home 組織の選択 - 複数組織戦略の適用 - Data 360 組織間でのデータの共有 ### ホーム組織の選択 Data 360 ライセンスを購入すると、そのライセンスに関連付けられた Salesforce 組織に Data 360 インスタンスがプロビジョニングされます。この組織は Data 360 ホーム組織と呼ばれます。ホーム組織は Data 360 インスタンスのアンカーです。これには次の内容が含まれます。 - Data 360 ストレージおよびコンピューティングの管理 (プロビジョニング時に選択したリージョン)。 - 管理、ガバナンス、セキュリティポリシーの適用 - データの取り込み、ハーモナイゼーション、ID解決、セグメンテーション、有効化のパフォーマンス マルチ組織のシナリオでは、ホーム組織で他の Salesforce 「コンパニオン」組織の中央 Data 360 インスタンスを管理します。 **ホーム組織:** - Data 360 インスタンスの地理的位置を決定します。 - Data 360 インスタンスの所有者と管理者を決定します。Data 360 ホーム組織の管理者は、Data 360 に取り込まれたすべてのデータにアクセスできます。 - Data Cloud One 設定でコンパニオン組織の接続を制御します。 - 企業データ戦略の基盤を設定します。後で変更するのは難しく、混乱を伴います。 Data 360 ホーム組織についての詳細は、「[Data 360 Integration Patterns and Practices](/docs/architect/ja-jp/fundamentals/guide/data360_integration_patterns_and_practices)」を参照してください。 #### 決定: Home Org として既存の Org か新規の Org のどちらを使用するか? 最初の大きな決定は、既存の本番組織で 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 のプロビジョニング** **最適な用途:** 1つの主要な組織で連携できない複数のSalesforce組織を使用しているお客様、または強力なCenter of Excellence(CoE)モデルを使用している企業。 新しい専用組織での Data 360 プロビジョニングを示す図 - **長所:** - 継承された組織の複雑さがなく、ガバナンスがクリーンな状態から始められます。 - 複数の事業分野にまたがる一元管理。 - コンプライアンスのニーズに基づいて地域を柔軟に選択できます。 - 1 つのビジネスユニットに縛られず、中立的な「共有サービス」組織として機能します。 - 将来の Data Cloud One アーキテクチャ (複数のコンパニオン組織があるホーム組織) に合わせて設定します。 - **短所:** - 顧客は、Data 360 をプロビジョニングする新しい Salesforce 組織のライセンスを取得する必要があります。 - Data Cloud One コンパニオン接続を介して組織を Data 360 に接続するには、追加のインテグレーションが必要です。 - 管理オーバーヘッド (ユーザー管理、セキュリティ、ID) を追加する場合があります。 - 既存の本番組織（Production Org）のプロビジョニングと比較して、タイム トゥ バリューが遅い。 **例:** ある多国籍金融サービス会社は、Data 360 をプロビジョニングするための専用のホーム組織を作成します。 すべてのビジネスユニット組織 (リテール、ウェルス、コマースバンキング) は、Data Cloud One を介してコンパニオン組織として接続します。 **決定基準**
考慮事項 Home Org としての既存の OrG（優先 Default） Home Org としての新規 OrG（代替）
シンプルさ 既存の本ユーザとデータ構造に基づいて構築され、より迅速に設定できます。
Data 360 はデフォルトでホーム組織と統合されています。		 新しい Salesforce 組織のライセンスと設定、およびそれを管理するための追加の管理オーバーヘッドが必要
タイム トゥ バリュー ローカル CRM データの迅速な使用 立ち上がりが遅く、統合が必要です。
ガバナンス 既存の Org の基本ガバナンスモデル（既存の本ユーザと権限セット）を継承します（Org がすでに中心になっている場合は、許容されます）。 ガバナンスを一新し、完全な白紙状態から始められます。COE 主導のモデルに最適です。
コンプライアンス 既存の組織の地域に関連付けられたレジデンシー 既存の組織から独立した地域を柔軟に選択
Performance ローカル CRM クエリで最高のパフォーマンス コンパニオン Org の接続性（同じリージョンか、他の Org とのクロスリージョンか）に依存します。
将来の拡張性 Data Cloud One と組み合わせると適切に機能します。誤った Org を選択した場合、後からの移行が困難になります。 Data Cloud One を使用して簡単に拡張できます。中立性を考慮した設計。
Cost (コスト) インクリメンタルなコストが低くなります。 環境の追加によるオーバーヘッドの増加
#### おすすめ 原則として、既存のメジャー Org をホーム Org として使用することで、初期作業を最小限に抑え、導入の加速を図ります。長期的なガバナンスまたはコンプライアンス戦略上必要な場合にのみ、新しい専用のホーム Org を作成します。新しい専用のホーム組織を作成することは、Center of Excellence (COE) を使用する大規模企業にとって一般的な選択肢です。 **単一組織環境** 既存の本番組織で Data 360 をプロビジョニングします。これにより、シンプルさと即時の価値が最大化されます。不要なインテグレーションのオーバーヘッドを回避できます。 **複数 Org 環境** ホーム組織として機能させるには、主要な組織 (通常はビジネスの大半を実行する組織、または一元化された CRM として機能する組織) を 1 つ選択します。これにより、複雑さが軽減され、設定作業を最小限に抑え、Data 360 の価値をすばやく実感できます。既存のメジャー Org を使用すると、新しい環境の管理にかかるコストとインテグレーション作業も回避できます。 **新しい専用のホーム Org を検討する場合** ホーム組織を作成すると、柔軟性と中立性が確保されますが、タイム トゥ バリューは遅くなります。 - 組織に強力な Center of Excellence (CoE) があり、ビジネスユニット組織から独立したガバナンスが必要な場合。 - コンプライアンスや組織の制約のために適切な既存の組織が 1 つもない場合。 ### マルチ組織戦略の適用 #### マルチ組織の課題 多くの場合、企業は複数の Salesforce 組織を運用していますが、これは特別なケースではなく、通常です。2024 年 2 月の時点で、約 19,000 人の Salesforce ユーザーがすでに複数の Salesforce 組織を運用しています。 なぜこのようなことが起こるのでしょうか？ - **買収および合併:** 新しく買収された企業は、独自のSalesforceインスタンスを持ち込みます。 - **地域業務:**EU、北米、アジア太平洋など、多くの場合、データレジデンシー法を満たすために別々の組織を使用します。 - **機能の分離:** Retail Banking、Wealth Management、Insuranceなど、さまざまなビジネスユニットが、自律性のために独自の組織を維持します。 - **規制または**セキュリティの分離: 特定の業界では、コンプライアンス上の理由で論理的に異なる組織に義務付けられています。 - **歴史的または技術的な理由:** 時間の経過とともに、顧客は複数の組織を有機的に蓄積します。 それぞれの理由は個別に意味を持ちますが、それらが組み合わさってデータが断片化します。統合レイヤーを使用しない場合、各組織には顧客の部分的なビューのみが表示されます。 アーキテクチャの課題: コンプライアンス、ガバナンス、自律性の要件を尊重しながら、組織全体のデータを 1 つの情報源に統合する方法は? --- #### Data Cloud One Data Cloud One は、複数の Salesforce 組織で 1 つの Data 360 インスタンスを共有できる Salesforce の複数組織接続アーキテクチャです。これは、複数の Salesforce 組織を使用する企業に推奨されるパターンです。 Data Cloud One クラスターでは、Data 360 インスタンスをホストするホーム組織として 1 つの Salesforce 組織が指定されます。他の Salesforce 組織はコンパニオン組織として接続し、ホーム組織の Data 360 の統合データとメタデータを使用します。 Data Cloud One アーキテクチャを示す図 **Data Cloud One のしくみ** - **データ取り込みと統合 (ホーム組織)** - すべてのデータ取り込み設定 (Salesforce CRM、外部ソース、ストリーミング、バッチ) は、ホーム組織からのみ実行されます。 - ホーム組織に関連付けられたData 360テナントは、ID解決、ハーモナイゼーション、モデリング、信頼できるお客様のプロファイルへの統合を実行します。 - Data 360 の管理、ガバナンスポリシー、タギング、マスキングは、ホーム組織から一元的に適用されます。 - **データスペースアーキテクチャ** - ホーム組織からデータはデータスペースに整理され、データスペースはデータ、メタデータ、プロセスの論理コンテナとして機能します。 - 企業は、ブランド、地域、または事業部門のデータスペースを作成できます。 - データスペース共有: ホーム組織から、特定のデータスペースがコンパニオン組織と選択的に共有されます。これにより、関連するデータ (および関連付けられたメタデータ) のみが適切な組織に転送されます。 - **メタデータ共有** コンパニオン組織は、ホーム組織から、データモデルオブジェクト (DMO)、統合プロファイルスキーマ、計算済みインサイト、セグメント[など](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5)のメタデータ定義を受け取ります。これらは、ローカルアセットのようにコンパニオン組織内にネイティブに表示されますが、ホーム組織にリンクされています。 - **ホーム組織とコンパニオン組織の機能** 機能へのアクセスは、ホーム組織とコンパニオン組織で異なります。コンパニオン組織はデータの取り込みや統合ができず、取り込み、モデリング、統合はホーム組織に依存します。コンパニオン組織は Data 360 データにアクセスして Data 360 プラットフォーム機能を強化し、共有された信頼できるデータの上にローカルインサイト、セグメント、フローを作成できます。将来のビジョンでは、有効化機能にもアクセスできます。
機能 ホーム組織 コンパニオン組織
Connect コネクタの設定、データストリームの作成、データの取り込み、統合 ✅ ❌
ハーモナイズと統合：データ変換と ID 解決の構築および実行 ✅ ❌
データスペースと権限によるデータの保護 ✅ ✅
セグメント化と予測 セグメント、インサイトの構築、Einstein Studioモデルの作成 ✅ ✅
Everywhere の有効化、データアクション ✅ ✅
プラットフォーム機能: プロンプトビルダー、フロー、レポート、強化、[さらに詳しく](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) ✅ ✅
Data 360 搭載の機能: Prospecting Center、Sales Cloud および Service Cloud の機能、Agentforce など ✅ ✅
- **プラットフォーム機能パリティ** ユーザーとビルダーの観点では、メタデータが共有されると、Salesforce Platform 機能の使用に関して自宅組織とコンパニオン組織でいくつかの機能の違いが生じます。サポートされている機能のリストは、「[Data 360 Features](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) on Companion org (コンパニオン組織の Data 360 機能)」を参照してください。 - Salesforce Platformの機能(フロー、レポート、プロンプトビルダー、ダッシュボード、その他のプラットフォーム固有のツールなど)は、メタデータが使用可能になると、自宅組織とコンパニオン組織の両方で機能します。 - Agentforce、見込み調査センター、Sales Cloud Einstein 機能、Service Cloud AI 機能などの Data 360 を活用した機能も、ホーム組織とコンパニオン組織の両方でシームレスに動作します。一部の機能は完全な互換性を達成するまでに時間がかかる可能性がありますが、全体的な目標は、Data 360 に依存するすべてのクロスクラウド機能について自宅組織とコンパニオン組織で同等の機能を実現することです。 - **消費モデル** コンパニオン組織のすべてのアクティビティ(クエリ、セグメントの実行、Data 360トリガー フロー、AIの使用状況、Einstein Trust Layerのログ記録など)では、ホーム組織のData 360クレジットが使用されます。消費は一方向です。クレジットは一元化され、請求され、ホーム組織のクレジット割り当てに対して追跡されます。ただし、ドリル ダウンすると、各個人組織が Digital Wallet で使用したクレジット数を確認できます。 - **設計原則: 横方向の構築** Data 360 の水平構造は、主に Data Cloud One を介して実装される基本的な設計原則であり、1 つの Data Cloud インスタンスを複数の別々の Salesforce CRM 組織にまたがることができます。目標は、新しくリリースされたすべての機能が、追加の設定なしでホーム組織とコンパニオン組織の両方で動作することです。この機能により、Data Cloud One は単なるデータアーキテクチャの選択肢ではなく、今後の Salesforce Platform の基盤要素となります。 --- #### 決定: 複数のデータ組織 vs. 共有 Data 360 (Data Cloud One) 複数の組織を持つ企業は、エコシステム内で Data 360 を配置する方法と場所を選択する必要があります。各組織で独立した Data 360 組織をプロビジョニングするのか、Data Cloud One を使用して 1 つのホーム組織で組織を統合するのか? **オプション A: 複数の独立した Data 360 組織** 各 Salesforce 組織は、独自の Data 360 インスタンスをプロビジョニングします。 **長所:** - **自律性:** 各ビジネスユニットまたは地域が独自の Data 360 を制御します。 - **各組織内**のシンプル化: ガバナンス、セキュリティ、カスタマイズがローカライズされています。 - **法令順守:** 厳格な規制の分離が必要な場合 (データが国境を越えてはならない場合など) に役立ちます。 **短所:** - **データ サイロ:**組織間でプロファイルを統合することはできません。 - **高いコスト:** インスタンスごとにライセンス、管理、インテグレーションが必要です。顧客は複数の異なる組織で同じソースデータを複数回取り込むことになります。 - **重複作業:** IDの解決、セグメンテーション、強化を各Data 360インスタンスで繰り返す必要があります。 **オプション B: 1 つの共有 Data 360 (Data Cloud One クラスタ)** 1 つの Data 360 がホーム組織にプロビジョニングされ、他の Salesforce 組織がコンパニオン組織として接続されます。 **長所:** - **Single Source of Truth (SSOT):** すべての組織で統合データモデルが共有されます。 - **コスト効率:** 1 つの Data 360 ライセンスとインフラストラクチャのみを管理します。 - **統合ガバナンス:** ポリシー、セキュリティ、およびコンプライアンスの管理を一元的に適用します。 - **組織間強化:** コンパニオン組織間でハーモナイズされたプロファイル、インサイト、セグメントにアクセスできます。 - **AIの準備**状況:エンタープライズ全体のデータセットにより、AIモデルのトレーニングと有効化を改善できます。 - **将来性:**新しいコンパニオン組織の追加は、新しいData 360組織を必要としないため簡単です。 **短所:** - **追加の準備:**1 つの Data 360 では、組織間接続を計画する必要があります。 - **レイテンシの考慮事項:** さまざまな地域のコンパニオン組織ではクエリが遅くなる場合があります。 - **複雑なガバナンス:** 組織ごとにカスタマイズのニーズが異なる場合、詳細なガバナンスが複雑になる可能性があります。 **オプション C: 複数の Data Cloud One クラスタ** ガバナンス、コンプライアンス、その他のビジネス要件により、すべての組織をクラスター化することが現実的でない**場合が**あります。そのため、企業が複数の Data 360 組織を運用し、それぞれが別のコンパニオン組織のクラスターのホーム組織であるハイブリッドソリューションを実装することが必要になる場合があります。 **例:** ある多国籍企業では、ヨーロッパ、米国、アジアなど、さまざまな地域に Salesforce 組織があります。地域のデータレジデンシー規制に準拠するため、各地域ごとに 1 つの Data 360 をプロビジョニングします。 **決定基準**
考慮事項 複数の独立した Data 360 組織 1 つの共有 Data 360 (Data Cloud One)
自治 組織またはビジネスユニットごとの高度な自律性 一元化されたガバナンス、組織ごとの自律性の低下
コンプライアンス 厳密な分離が必要な場合 (地域の法律など) に便利です。 レジデンシーで一元化が許可されている場合に最適
Cost (コスト) ライセンスコストと管理コストの増加 コスト効率が向上: 多くの組織で 1 つのライセンスを使用
ガバナンス 断片化。ポリシーは組織ごとに異なる 組織全体で一元化された一貫したポリシー
データサイロ 各組織が独自のビューを持つ（エンタープライズ 360 なし） 統合されたデータセット (重複なし)
AI/分析 各組織のデータに制限 精度が向上したエンタープライズ規模のモデル
複雑さ 管理するインスタンスの増加、インテグレーションの増加 シンプルなアーキテクチャ、可動部品の削減
Performance 組織内ユースケースに最適 コンパニオン組織のアクセスによる潜在的な遅延の増加
--- #### おすすめ **推奨パターン: Data Cloud One** 複数の組織にまたがるガバナンスを簡素化し、コストを最適化するには、接続されたコンパニオン組織と共に 1 つのホーム組織を使用します。 複数のData 360組織を**使用する場合:** コンプライアンス、レジデンシー、または組織の自律性によって厳密に必要とされる場合のみ、複数のData 360組織を使用します(規制のためにヨーロッパの業務を米国の業務から完全に分離する必要がある場合など)。 Data Cloud One でのホーム組織の**選択方法:** まず、主要な組織の 1 つ (通常はほとんどのビジネスが実行されている組織) を検討します。Data 360 をプロビジョニングすることで、複雑さを最小限に抑え、早期の価値を最大化できます。 適切な既存の組織がない場合にのみ、COE チームが管理する専用のホーム組織を作成することを検討してください。 **一般原則:** マルチ組織環境では、Data 360 組織の数を最小限に抑えます。Data Cloud One をデフォルトパターンとして選択すると、重複が減り、AI の準備が有効になり、ガバナンスが簡素化されます。 ### Data 360 組織間でのデータの共有 #### データ共有の必要性 Data Cloud One はほとんどの企業にとって推奨される方法ですが、次のような複数の Data 360 インスタンスをプロビジョニングする必要があるシナリオもあります。 - **地域のコンプライアンス。**ある多国籍リテーラーは、EU と米国にそれぞれ 1 つの Data 360 をプロビジョニングしています。Data 360-to-Data 360 データ共有により、ローカルデータからインサイトを作成し、そのインサイトを米国本社と共有できます。 - **ビジネスユニットのコラボレーション。**ある複合企業では、リテールと保険で別々の Data 360 組織を運営しています。Data 360 組織間のデータ共有により、ユーザーは移動やコピーを行うことなく、1 つの信頼できるデータソースにアクセスできます。Data 360 組織間のデータ共有により、保険組織はターゲットを絞ったクロスセルキャンペーン用にリテールの「価値の高い顧客」セグメントを受け取ります。 - **合併と買収。**親会社が、独自の Data 360 を持つ子会社を買収します。2 つのインスタンスを管理するにあたり、短期データサイロを維持することで、データセキュリティと SSOT の整合性が保たれます。同時に、2 つの Data 360 インスタンス間でデータを共有することで、移行中に必要なコラボレーションが可能になります。 - **フェデレーテッド・エグゼクティブダッシュボード。**複数の大陸にまたがる多国籍企業では、各リージョンごとに個々の Data 360 組織がプロビジョニングされます。エグゼクティブは、四半期ごとのパフォーマンスのフェデレーテッド・ビューを求めています。各リージョンの 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 などの機能は、それぞれローカルインスタンスで独立して動作します。共有は自動的に行われません。特定のオブジェクトについてのみコラボレーションするには、意図的なデータ共有を作成する必要があります。 #### Data 360 組織間でのデータ共有の長所と短所
要素 プラス面 マイナス面
データレジデンシー コラボレーションを可能にしながら、地域の分離をサポートします。 複数の Data 360 組織を管理する必要がなくなるわけではありません。
データの複製 ゼロコピー、オブジェクトの重複なし。 各データ共有に含めるオブジェクトを慎重に選択する必要があります。
ガバナンス 共有は明示的かつ意図的に行われます (オブジェクトレベル)。 タグまたはポリシーフローはありません。対象組織はガバナンスを再適用する必要があります。
複雑さ 一元化なしで選択的なコラボレーションを可能にします。 複数の Data 360 組織とデータ共有の管理が必要です。
**AI/Analytics** リージョンごとの AI 分析が可能。インサイトを組織間で共有できます。 データを意図的に共有しない限り、企業全体の AI は利用できません。
**プラットフォーム機能** 各組織の Data 360 搭載機能は独立して実行されます。 自動共有なし。慎重に設計しないと重複のリスクがあります。
Cost (コスト) ETL パイプラインの必要性を減らすことができる。 複数の Data 360 組織のコストは依然として発生します。データクエリとデータ共有の単位数を消費します。
#### 決定条件
考慮事項 Data Cloud One (マルチ組織に推奨) Data 360 組織間でのデータ共有
一元化された情報源 はい — すべての組織でデータモデルが共有されます。 いいえ — 各 Data 360 には独自のデータモデルがあります。
コンプライアンス レジデンシーで一元化が許可されている場合にのみ機能します。 居住法によって一元化が妨げられている場合に必要です。
ガバナンス 一元化され、一貫性があります。 フェデレーテッド — 意図的なオブジェクトレベルの共有。
複雑さ 可動部品が少なく、シンプル。 より複雑 — 設定データ共有と複数のデータ組織が必要です。
AI/分析 企業全体の AI モデル。 地域 AI。インサイトを選択的に共有する。
プラットフォーム機能 Shared Data 360 では、ホーム組織とコンパニオン組織全体で、すべての機能が一貫して動作します。 機能は Data 360 ごとに独立して実行されます。共有は明示的に行う必要があります。
#### おすすめ **エンタープライズに複数の Data 360 組織がある場合** - カスタムパイプラインを作成したりデータを複製したりするのではなく、Data 360 組織間でデータ共有を使用してコラボレーションします。 - データ共有を作成して対象組織に付与することで、特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。 - タグは共有されません。受信組織は、ガバナンス、分類、AI 強化のためにタグを再適用する必要があります。 **Data 360 組織間でのデータ共有の使用** - 一元化を妨げる規制要件を満たす。 - ビジネスユニットの自律性を維持しながら、選択的なコラボレーションを実現する。 - 複数のリージョンにわたって、フェデレーテッドなエグゼクティブダッシュボードを提供する。 - 統合がすぐには実現できない M&A シナリオの橋渡しをします。 **慎重に設計してください** Data 360-to-Data 360 データ共有は、Data Cloud One の置き換えではなく、統合戦略として扱います。 - オブジェクト固有の共有を使用します。 - 共有しすぎないようにします。 - データ共有をビジネスおよびコンプライアンスのニーズに合わせます。 #### 記憶 Data 360 プロビジョニングのデータ戦略を計画することは、組織ごとではなく、企業全体で取り組む必要がある重要な長期的なアーキテクチャ上の決定事項です。この初期の戦略的選択によって、顧客データの統合方法、ガバナンスの適用方法、およびプラットフォームの不可欠な機能 (特に AI と分析) の組織全体の拡張性が決まります。ガバナンスとオーナーシップのモデルを事前に計画し、断片化や複雑さの増大につながる短期的なショートカットを回避します。 ## リソース [Customer 360とは?](https://www.salesforce.com/products/what-is-customer-360/) [Data 360 インテグレーションのパターンとプラクティス](/docs/architect/ja-jp/fundamentals/guide/data360_integration_patterns_and_practices) [Data 360 アーキテクチャ](/docs/architect/ja-jp/fundamentals/guide/data-360-architecture) [Data 360 セキュリティアーキテクチャ](/docs/architect/ja-jp/fundamentals/guide/data360_security_architecture) **著者について** 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 のソフトウェアエンジニアリングアーキテクトで、データおよびインテリジェンスアプリケーションプラットフォーム内のデータアーキテクチャを専門としています。データガバナンスと統合データモデルに焦点を絞ったエンタープライズアーキテクチャレビューボード (EARB) イニシアチブを主導しながら、自動化プラットフォームプロビジョニングソリューションに貢献しています。 Samarpan Jain は、Commerce Cloud、プラットフォームインテグレーション、組織間アーキテクチャを専門とする Salesforce のプリンシパルアーキテクトです。Salesforce で最も勤続年数が長い従業員の 1 人で、政府機関の顧客向けのデータレジデンシーコンプライアンスや Data 360 利用状況属性システムなどの重要なイニシアチブを主導しています。