複数のオンライン環境またはテナントについて
Customer Engagement アプリ (Dynamics 365 Sales、Dynamics 365 Customer Service、Dynamics 365 Field Service、Dynamics 365 Marketing) には、データおよびユーザー アクセスを分離するためのオプションが用意されています。 大半の企業では、サブスクリプションに複数の Power Platform 環境を追加して使用することで、機能と管理の容易さを適切に組み合わせることができます。 ディレクトリとライセンスを分ける可能性がある異なるエンティティを持つ企業は、複数のテナントを使用することを考慮する場合があります。 テナント内のすべてのユーザーが複数の環境にアクセスできます。 複数のテナントは、他のテナント ユーザーをゲスト ユーザーとして招待して、アクセス権を付与する必要があります。
複数の環境の使用
環境の概念は、業務機能に応じてフロアが構成された高層商業ビルに似ています。 ビル内の各フロアはアプリケーション (営業/サービス/マーケティング、ベンダー管理、資産管理) であり、フロア内の各ユニットは、製造、トレーニング、テスト、開発などの特定の目的の環境として考えることができます。
部署を使用して容易に隔離できない、データ、プラグイン、ワークフロー、または管理リソースの分離が必要な場合は、複数の環境が必要です。
複数の環境の展開
一般的な顧客は 1 つのテナントのみを持っています。 テナントには 1 つ以上の環境を含めることができますが、環境は常に単一のテナントに関連付けられます。
この例では、営業、マーケティング、サービスの 3 つのチームに対して、2 つの環境を使用します。
営業およびマーケティングは環境を共有するため、リード情報に、両方とも簡単にアクセスできます。 サービスには独自の環境があるため、チケットや保証は、キャンペーンや他の営業関連イベントとは別に管理できます。
1 つまたは両方の環境に簡単にアクセスできます。 拡張アクセス権限を持つサービス ユーザーは、両方の環境でアカウント関連のサポート エスカレーション レコードを更新できますが、営業およびマーケティング ユーザーはそれぞれの環境に限定されます。
複数の環境を持つ単一テナントについて:
テナント内の各環境は、独自の SQL データベースを受け取ります。
データは環境間で共有されません。
環境間でストレージを共有する方法については、Microsoft Dataverseストレージ 容量 を参照してください。
単一テナントの環境は、取引先企業に最初にサインアップした地理的な場所で既定で設定されます。 さらに、環境の作成者は、別の地域で環境を作成することを選択できます。ユーザーが選択できるように、許可された地域が表示されます。 特定の状況では、ユーザーは、Power Platform でサポートされているすべての地域を表示または選択できる必要があります。
記憶域の消費は、顧客のテナントに添付されたすべての環境全体で合計され、追跡されます。
誰が環境を表示およびアクセスできるかを制御する場合は、環境に個別のセキュリティ グループを設定できます。
ライセンスを持つユーザーは、テナントに関連付けられたすべての環境に、潜在的にアクセスできます。 アクセスは環境のセキュリティ グループ メンバーシップによってコントロールされます。
複数の環境を使用する理由は?
以下のものは、複数の環境展開を使用する一般的な例です。 業務要件に合った展開タイプを決める際には、これらの例を参考にしてみてください。
マスター データ管理
このシナリオでは、「マスター」データセットは、中央のマスター データソースを介して変更管理を提供します。 このアプローチでは、各環境が最新バージョンの主要情報に対してアクセスできるように、中央マスター データをすべての環境と同期する必要があります。 情報に対して要求された変更は、マスター システム内で直接実行されます。 また、ユーザーは明示的にマスター システムにアクセスしたり、ローカル環境での変更を取得して、それらの変更をマスター環境に渡すこともできます。
一元的に変更を実行して、変更コントロールを一元化する必要があります。 たとえば、不正対策チェックを実行して、与信限度の変更など、変更によって利益を得られる可能性があるローカル チームではなく、中央チームによってのみ変更が行われるようにすることができます。 これにより、1 人のユーザーまたは緊密に連携して共同作業するユーザーのグループが不正行為に影響を与えることを回避する第 2 レベルの変更承認と検証が提供されます。 別の独立したチームに要求をプッシュすることにより、潜在的な不正から保護することができます。
セキュリティとプライバシー
欧州連合 (EU) などの地域や国の法律が異なると、展開内のさまざまな地域または国においてデータのセキュリティ保護やデータのプライバシーの確保に関する要件が異なる場合があります。 場合によっては、国や地域の境界外にあるデータをホストすることが法令/規制によって違法とされており、特定の事業部門でこの課題に対応することが特に重要になります。
たとえば、患者情報の共有については、医療分野の制限を考慮します。 一部の EU 規制では、EU 内のユーザーについて収集された健康情報は、EU の境界内のみで管理および共有されることを要求しています。一方、米国の従業員について収集された同種のデータは、米国の境界内に保管されます。 顧客情報を共有する際の銀行部門の制限についても考慮します。 たとえばスイスでは、国境外で顧客情報を共有することは違法です。
スケーラビリティ
単一の環境であれば、データ量が非常に多い場合や複雑なレベルの場合には、顧客のビジネスの成長をサポートするためにスケールアップや、スケールアウトすることができますが、それ以外にも考慮すべき点があります。 たとえば、ボリュームが極端に大きいか、サービス スケジューリングを多用している、またはその両方に該当する環境では、SQL Server をスケールアップするために管理がきわめて高コストまたは極端に難しい複雑で高価なインフラストラクチャが必要になる場合があります。
機能要件が自然に機能別に分割されているシナリオは数多くあります。 このような場合、これらの機能的分割に基づいてスケールアウト シナリオを作成して作業負荷を委託すると、商用のインフラストラクチャを使用して高容量を提供できます。
サブスクリプションに環境を追加する
テナントに環境を追加する方法については、環境を作成および管理する を参照してください。
マルチテナント型の展開
異なる地域モデルまたは国モデルでのグローバル業務では、テナントを使用して、手法、市場規模、または法規制による制約の順守での違いを説明できます。
この例には、Contoso Japan 向けの第 2 のテナントが含まれています。
ユーザー アカウント、ID、セキュリティ グループ、サブスクリプション、ライセンス、およびストレージは、テナント間で共有できません。 すべてのテナントは、特定の各テナントに関連付けられている複数の環境を持つことができます。 データは環境またはテナント間で共有されません。
複数のテナントについて:
マルチテナント型のシナリオでは、テナントに関連付けられたライセンス ユーザーは、同じテナントにマッピングされた、1 つ以上の環境に対してのみアクセスできます。 別のテナントにアクセスするには、ユーザーをゲスト ユーザーとして招待する必要があり、別のライセンスを割り当てる必要がある場合があります。
各テナントは、固有のサインイン資格情報を持つ Microsoft Power Platform の管理者が必要となり、各テナントの関係者は管理者コンソールで個別にそのテナントを管理することになります。
管理者がアクセス権限を持つ場合、テナント内の複数の環境はインターフェースから表示できます。
テナント加入契約の間にライセンスを再割り当てすることはできません。 加入契約した関連会社は、1 回の加入契約でライセンスの控除を使用し、それを容易にするためにライセンスを別の加入契約に追加できます。
異なるテナント (たとえば Contoso.com および Fabricam.com) でフェデレーションするために必要な最上位ドメインを持たない場合、1 つ以上のテナントで設置型 Active Directory Federation を確立することはできません。
なぜ複数のテナントを使用するのですか。
機能的なローカライズ
このシナリオは、通常、重複した組織で別個の機能を必要とする場合に発生します。 いくつかの一般的な例を次に示します。
それぞれ異なる市場または工程モデルを持つ異なる事業部門がある組織。
アプローチ、市場の規模、または法的制約や規制への準拠のバリエーションを考慮するために、異なる地域モデルまたは国モデルがあるグローバル ビジネス。
これらの種類の業務環境では、組織は大抵、特定の地域、国、または業務領域において以下の程度のローカライズが許容される、一連の共通機能を保有します。
情報の取得。 たとえば、米国の郵便番号の取得は、英国の郵便番号の取得と関連します。
フォーム、ワークフロー。
物流
物理的にはなれたユーザーをサポートする必要があるビジネス ソリューション、特にグローバルな展開では、単一の環境を使用することは、ユーザーが接続するインフラストラクチャに関連する影響 (WAN の待ち時間など) のために適していない場合があり、ユーザー エクスペリエンスに重大な影響を与える可能性があります。 より多くのローカル アクセスをユーザーに提供するため環境を配布すると、アクセスがより短いネットワーク接続上で発生するため、WAN 関連の問題を軽減または克服できます。
ボリューム ライセンスでのマルチテナント型の展開を追加する
マルチテナント型の展開では、マルチテナント型の変更が必要です。 マルチテナント型の変更は、ライセンスの購入に使用するボリューム使用許諾契約に対する実際の変更です。 変更を取得する方法については、Microsoft の営業担当者または再販業者にお問い合わせください。
マルチテナント型の制限
複数のテナントを展開および管理する管理者は、次を認識する必要があります。
ユーザー アカウント、ID、セキュリティ グループ、サブスクリプション、ライセンス、および記憶域はテナント間で共有することはできません。
単一のドメインは、1 つのテナントとのみフェデレーションができます。
各テナントには独自の名前空間があります。UPN または SMTP 名前空間は、テナント間で共有できません。
オンプレミスの Exchange 組織が存在する場合、この組織を複数のテナントに分割することはできません。
同期の下流で明示的に管理されている場合を除き、連結されたグローバル アドレス リストを使用することはできません。
交差するテナントの共同作業は、Lync フェデレーションおよび Exchange フェデレーション機能に限定されます。
テナント間の SharePoint アクセスはできない場合があります。 これはパートナー アクセスによって解決される場合もありますが、ユーザー エクスペリエンスは混乱し、ライセンス状況が適用されます。
オンプレミスの Active Directory では、テナントまたはパーティション間で重複するアカウントを使用できません。