Power BI の実装計画: データ ゲートウェイ

この記事は、Microsoft Fabric のオンプレミス データ ゲートウェイと仮想ネットワーク (VNet) データ ゲートウェイを、計画し実装する際に役立ちます。 主な対象者は次のとおりです。

• Fabric 管理者: 組織の Fabric 監視を担当する管理者。 Fabric 管理者は、Power Platform 管理者、データベース管理者、情報セキュリティ チーム、ネットワーク チーム、その他の関連チームとの共同作業を必要とする場合があります。
• ゲートウェイ管理者: ゲートウェイとそのデータ ソース接続の実装、管理、監視を担当する個人。
• ゲートウェイ共同作成者: ゲートウェイのデータ ソース接続の追加と管理を担当する、集約的ではないチームおよび個人。
• センター オブ エクセレンス (COE)、IT、BI チーム: データへのアクセス、接続、更新を行う必要があるユーザーをサポートするチーム。
• コンテンツの所有者と作成者: ゲートウェイを使用してデータ ソースに接続し、Fabric データ項目を更新するチームと個人。

Power BI セマンティック モデル、データフロー、その他の Fabric データ項目のソース データにアクセスするには、データ ゲートウェイが必要となることがあります。 データ ゲートウェイ は、プライベート ネットワークまたはオンプレミスのデータ ソースと、Fabric を含むクラウド サービスの間で、データを安全に転送します。

主要な決定事項を計画する

多くの場合、Power BI と Fabric の実装を成功させるためには、ゲートウェイが不可欠です。 一部の組織では非集約的なチームを使用してゲートウェイを管理しますが、通常は、COE または中央のデータおよび BI チームがゲートウェイを計画し、一元的に管理します。 将来の中断とガバナンス リスクの可能性を軽減するには、ゲートウェイを使用する方法と時期を慎重に計画することが重要です。

通常、ゲートウェイの実装は 2 つの異なる段階で計画されます。

• テナントのセットアップ: Fabric の実装、またはそれへの移行を準備する場合は、いずれかのデータ ソースでゲートウェイが必要とされるかどうかを評価します。 ゲートウェイを計画する作業は、セキュリティ、ワークスペース、監査と 監視のテナント レベルの計画策定とも関係しています。
• BI ソリューションの計画: 新しい BI ソリューションを計画する際には、新しいソリューションの技術的な要件を収集 しながら、そのソリューションにゲートウェイが必要かどうかを評価する必要があります。 また、既存のソリューションに新しいデータ ソースを追加する場合にも、ゲートウェイが必要となることがあります。

ゲートウェイ実装の計画は、ゲートウェイが必要かどうかをはじめとした、重要な諸事項の決定により開始されます。

ゲートウェイが必要かどうかを特定します

一般に、次の場合は、データ ソース用にゲートウェイが必要です。

• データ ソースがオンプレミスにある。
• データ ソースがプライベート ネットワーク内にある。
• コネクタ ソフトウェアのホストが必要。
• 特定のコネクタまたは機能のために、セキュリティの分離が必要。

このようなシチュエーションでは、次の目的でゲートウェイが必要です。

• Fabric ポータルでのデータ更新。 このシナリオは、ゲートウェイを必要とするデータ ソースの Power BI サービスで、コンテンツの作成者がデータ更新を設定する場合に適用されます。
• Fabric ポータル内でのコンテンツ作成。 このシナリオは、ゲートウェイを必要とする Power BI サービス内で、コンテンツ作成者がデータ項目 (セマンティック モデルやデータフローなど) を作成または変更する場合に適用されます。
• DirectQuery 接続のサポート。 このシナリオは、コンテンツ作成者が DirectQuery (または Dual) ストレージ モード テーブルを含むセマンティック モデルを発行し、それらのテーブルのデータ ソースでゲートウェイが必要な場合に適用されます。 この使用シナリオには、データ ソースで定義されたデータアクセス許可を、ユーザーごとに適用する機能も含まれます。 たとえば、SQL Server データベースでは行レベル セキュリティ (RLS) を適用でき、Power BI ではシングル サインオン (SSO) 接続を管理できます。 詳細については、「コンシューマーの ID に基づいてデータ セキュリティを適用する」を参照してください。
• SQL Server Analysis Services へのライブ接続。 このシナリオは、SQL Server Analysis Services (SSAS) データベースへのライブ接続を使用するレポートを、コンテンツ作成者が公開する場合に適用されます。

次のセクションでは、ゲートウェイが必要な場合について説明します。

オンプレミス データ ソース

Fabric ポータルからオンプレミスのデータ ソースに接続するには、ゲートウェイが必要です。 ゲートウェイはブリッジとして機能し、ゲートウェイ マシン上のクエリ式の評価と、オンプレミス データのクラウドへの安全な転送を行ないます。

このシナリオは、以下に対し接続する場合に関係があります。

• オンプレミスのマシン上に存在するデータ ソース。
• ローカル ディレクトリに保存されているファイル。
• 単一クエリ内で結び付けられている、クラウドとオンプレミスのデータ ソース。
• クラウドベースの仮想マシン (VM)、いわゆる、サービスとしてのインフラストラクチャつまり IaaS。

プライベート ネットワーク データ ソース

Azure Virtual Network (Azure VNet) などのプライベート ネットワーク内に置かれたデータ ソースに接続するには、ゲートウェイが必要です。 仮想ネットワーク (VNet) とは、ネットワークの論理的に隔離されたセグメントであり、トラフィックをパブリック インターネットから分離します。 VNet により、強化されたネットワーク セキュリティが提供されます。

このシナリオと関係があるのは、データ ソースが次の状態のときです。

• 組織ネットワーク (またはファイアウォールの内側) など、プライベート ネットワーク内のデータ センターに存在する。
• VNet 内のクラウドベースの VM (サービスとしてのインフラストラクチャつまり IaaS) である。
• VNet 内にあるクラウドベースのデータベース サービス (サービスとしてのプラットフォームつまり PaaS) である。

ホスト コネクタ ソフトウェア

場合によると、データ ソースへの接続に必要なサポート アイテムをホストするために、ゲートウェイが必要になることがあります。 このソフトウェアには、ゲートウェイ マシン上にインストールするカスタム データ コネクタ、ドライバー、またはライブラリなどが含まれます。 クラウドのデータ ソースに接続している場合でも、Power BI サービスはこのソフトウェアにアクセスできないため、このサービスを使用するデータ ソースの更新を、ゲートウェイに依存せずに実行することはできません。

このシナリオは、次のようなコネクタを使用してデータ ソースに接続する場合に関係します。

• ドライバー。 公式コネクタでは、前提条件としてドライバーのインストールが必要な場合があります。 たとえば、Oracle データベースに接続する場合は、Oracle Data Access Client ソフトウェアが必要になります。
• カスタム コネクタ。 一部のデータ ソースでは、カスタム コネクタまたはサード パーティ製のコネクタが必要になります。 たとえば、レガシ システムまたは専用システムに接続する際に、カスタム コネクタが必要となることがあります。
• クライアント ライブラリ。 一部のデータ ソースでは、クライアント ツールからの接続を可能にするために、サポート ライブラリを必要とします。 たとえば、Analysis Services データベースに接続する場合には、クライアント ライブラリのインストールが必須です。
• ODBC または OLE DB コネクタ。 公式コネクタには、ODBC ドライバーまたは OLE DB プロバイダーが必要な場合があります。 たとえば、SAP HANA に接続する場合は、ODBC ドライバーが必要となります。

セキュリティ分離

Web コネクタや Web.BrowserContents 関数など、特定の Power Query コネクタまたは関数を使用するには、ゲートウェイが必要です。 これらのコネクタと関数では、セキュリティの分離などのさまざまな理由で、ゲートウェイを必要とします。

このシナリオは、次のようなコネクタとドライバーを使用して、データ ソースに接続する場合に関係します。

• Web コネクタを使用するクエリ。
• Web.Page または Web.BrowserContents 関数を使用するクエリ。
• Access データベース エンジン (ACE) ドライバーを使用する接続。

必要なゲートウェイの種類を決定する

ゲートウェイが必要であることを確認したら、次にインストールするゲートウェイの種類を決定する必要があります。 ゲートウェイには 3 つの種類があります。

• オンプレミス データ ゲートウェイ (標準モード)
• 個人用ゲートウェイとも呼ばれる、オンプレミス データ ゲートウェイ (個人用モード)
• 仮想ネットワーク (VNet) ゲートウェイ サービス

選択するゲートウェイの種類は、実際の要件とデータ ソースによって異なります。 次のセクションでは、3 種類のゲートウェイについて個々に説明します。

オンプレミス データ ゲートウェイ (標準モード)

オンプレミス データ ゲートウェイ (標準モード) では、複数のユーザーが 1 つの共有ゲートウェイを介してデータ ソースに接続することが可能です。 通常、標準モード ゲートウェイは、常時稼働の VM 上に一元的にインストール、管理されます。 標準モード ゲートウェイを使用すると、Fabric、Power BI、その他の Power Platform サービスなど、複数のサービスからデータに接続できます。

次の図に、標準モード ゲートウェイの概要を示します。

この図は、次の概念を示しています。

Item	説明
	オンプレミス データ ゲートウェイ (標準モード) は、オンプレミスのデータ ソースからクラウド サービスにデータを安全に転送します。
	特定の (前のセクションで説明した) シナリオのクラウド データ ソースには、標準モードのデータ ゲートウェイが必要です。
	標準モードのデータ ゲートウェイは、常時稼働の VM にインストールされます。 管理者は、VM とデータ ゲートウェイを一元的に管理します。 ゲートウェイ管理者は、必要に応じて、データ ソース接続に必要なソフトウェアをインストールします。
	複数のユーザーが、データ ゲートウェイのデータ ソースに接続できます。
	ユーザーは、セマンティック モデル、データフロー、パイプライン、改ページ対応レポートなど、Fabric ワークスペースに発行されたアイテムに対して、データ ゲートウェイを使用できます。
	ユーザーは、Power Platform データフローなど、他の Power Platform クラウド サービスに対して、データ ゲートウェイを使用できます。

次の特定の状況では、標準モードのゲートウェイが必要になります。

• さまざまな Microsoft クラウド サービス (Power Apps や Fabric など) や Fabric データ アイテム (データフローなど) で、オンプレミスのデータ ソース (またはゲートウェイを必要とするクラウド データ ソース) に対するクエリの実行が必要。
• 改ページ対応レポートで、オンプレミスのデータ ソース (またはゲートウェイを必要とするクラウド データ ソース) に対するクエリの実行が必要。
• セマンティック モデルで、オンプレミスのデータ ソース (またはゲートウェイを必要とするクラウド データ ソース) への接続が必要な、DirectQuery ストレージ モードを使用。
• SSAS ライブ接続。
• データ ソースは、カスタム データ コネクタ、ドライバー、またはライブラリに依存します。
• ゲートウェイを再配置または移行する必要性が予想される場合。

Personal Gateway

一般に個人用ゲートウェイとも呼ばれる、オンプレミス ゲートウェイ (個人用モード) を使用すると、ユーザーは同じマシン上にあるオンプレミスのデータ ソースに接続できます。 通常、ユーザーは自分のマシンから、個人用ゲートウェイをインストールして管理します。 個人用ゲートウェイでは、ユーザーは他の Power Platform サービスからのデータに接続できません。 また、ゲートウェイあるいは接続を、他のユーザーと共有することもできません。

個人用ゲートウェイは、1 人の人物による、限定的かつ個人向けの使用を目的としています。 通常はコンテンツ作成者が、個人 BI を遂行するために、これらのゲートウェイをインストールして使用します。 これらのゲートウェイは共有できないため、個人 BI に制限されます。 さらに、パーソナル ゲートウェイでは、パーソナル ゲートウェイ ソフトウェアをダウンロードしてインストールするために、ユーザーがマシンの権限とポリシーによる承認を保持している必要があります。

次の図に、個人用ゲートウェイの概要を示します。

この図は、次の概念を示しています。

Item	説明
	個人用ゲートウェイは通常、ユーザーのマシンにインストールされます。
	個人用ゲートウェイは、ユーザー マシン上のローカル データ ソースからクラウド サービスに、データを安全に転送します。
	通常、個人用ゲートウェイは、インストールしたユーザーによって管理されます。
	1 人のユーザーが限られた個人的な目的に、個人用ゲートウェイを使用します。 個人用モードのゲートウェイを共有することはできません。
	個人用ゲートウェイは、セマンティック モデルや Power BI データフローなど、Power BI ワークスペースに発行されたアイテムに対してのみ使用できます。

繰り返しになりますが、個人用ゲートウェイは、1 人の人物による制限付きの個人的な使用を目的としています。 ただし、個人用ゲートウェイの使用が必須な、特定のシナリオが 2 つ存在します。

• セルフサービス コンテンツ作成者は、自分のマシンまたはその他のオンプレミス データ ソース上のローカル データ ソースに接続されている、発行済みのコンテンツを更新する必要があります。
• セマンティック モデルでは、Power Query で Python または R コード を使用します。

VNet ゲートウェイ

VNet ゲートウェイは、プライベート エンドポイントを使用するデータ ソースなど、プライベート ネットワークで保護されたデータ ソースに複数のユーザーが接続することを可能にします。 VNet ゲートウェイを使用すると、複数のサービスを使用してデータに接続でき、また、ゲートウェイまたは接続を複数のユーザーと共有できます。

VNet ゲートウェイは、Microsoft 管理サービスです。 プライベート ネットワークを使用している組織のユーザーには、VNet ゲートウェイが必要です。

次の図に、VNet ゲートウェイの概要を示します。

この図は、次の概念を示しています。

Item	説明
	仮想ネットワーク (VNet) ゲートウェイは、Azure VNet 内のデータ ソースと同様に、非公開ネットワーク上のデータ ソースに接続するために使用します。
	VNet データ ゲートウェイは、Microsoft 管理サービスです。 VNet データ ゲートウェイは、Azure portal と Power Platform 管理ポータルから一元的に管理します。
	複数のユーザーが VNet データ ゲートウェイを使用できます。
	ユーザーは、セマンティック モデルなどの Fabric ワークスペースに発行されたアイテムに対して VNet データ ゲートウェイを使用できます。
	VNet データ ゲートウェイは、Power Platform データフローなど、他の Power Platform サービスに対しても使用することができます。

ゲートウェイの数を決定する

ゲートウェイが必要であることを確認し、必要なゲートウェイの種類を判断したら、次に必要なゲートウェイの数を決定する必要があります。

ニーズによっては、複数のゲートウェイが必要になる場合があります。 インストールして使用するゲートウェイの数を決定する際には、次の要因を考慮してください。

可用性とパフォーマンス

ゲートウェイには、更新またはクエリの遅延が原因で起こる中断を回避するために、高い可用性があることが重要です。 ゲートウェイの可用性を保証する 1 つの方法は、高可用性のゲートウェイ クラスターに複数のゲートウェイをインストールすることです。 ゲートウェイ クラスターは、異なる VM にインストールされており、論理的に 1 つの機能ユニット (クラスター) として関連付けられているゲートウェイのコレクションです。 しばしば、各ゲートウェイ マシンはノードと呼ばれます。

ゲートウェイ クラスターを使用することの利点を次に示します。

• 単一障害点の回避: プライマリ ゲートウェイ マシンが使用できなくなった場合、フェールオーバー により単一障害点を回避します。 このマシンが使用できなくなった場合には、クエリがクラスター内の別のノードに送信されます。 複数のマシンのクラスターを使用することで、リスクを軽減します。 また、アップタイムも増加するので、高可用性とディザスター リカバリーの要件を満たすために役立ちます。
• パフォーマンスの改善:負荷分散により、同時使用量が多いときのパフォーマンスを向上します。 負荷分散は、クラスター内の他のノードにクエリを送信することで、ワークロードを分散します。 これは、プライマリ ゲートウェイがビジー状態のときや、単一の操作 (長いデータ更新など) が多くのリソースを消費している場合に役立ちます。
• ダウンタイムの回避: ゲートウェイ ソフトウェア更新プログラムをインストールするときは、一度ごとに、クラスターの 1 つのノードでインストールを実行します。 そうすることで、クラスター全体をオフラインにすることを回避できます。

ゲートウェイ クラスターの設定の詳細情報とガイダンスについては、「ビジネスクリティカルなゲートウェイ ソリューションの計画、スケーリング、保守」を参照してください。

環境

通常、コンテンツの作成者は、開発、テスト、運用などのビジネスクリティカルなソリューションを開発および管理するために、分離された環境を使用しています。 使用する環境の数とその使用方法によっては、環境ごとに個別のゲートウェイ クラスターが必要になる場合があります。

ゲートウェイ クラスターを異なる環境に分離することは、次を可能にします。

• 開発とテストのアクティビティによって発生する中断を隔離し、それを最小限に抑えます。
• 運用ワークロードの可用性とパフォーマンスを向上しす。
• ゲートウェイ ソフトウェア更新プログラムをインストールおよびテストするための、安全な環境を提供します。

リージョン

データ更新の良好なパフォーマンスを確保するには、データ ソース、ゲートウェイ、およびユーザーが存在している場所を考慮に入れることが重要です。 待機時間を短縮するには、可能な限りデータ ソースの近くに、ゲートウェイをインストールする必要があります。 このため、異なるリージョンやテナントをサポートするために、複数のゲートウェイ クラスターのインストールが必要になる場合があります。

チェックリスト - ゲートウェイの実装を計画する際の、主な決定事項とアクションは次のとおりです。

• データ ソースのインベントリの作成: データ ソースのインベントリにより、ゲートウェイが必要なデータ ソースを検証およびドキュメント化できるようになります。
• ゲートウェイが必要な状況の判断: コンテンツ作成者とコンシューマーがどのような作業を行なうのかを検討します。 ゲートウェイが必要とされる状況を、よく理解しておきます。 ユーザー コミュニティのために、ドキュメントとトレーニングを作成します。
• 必要なゲートウェイの種類の決定: 想定される事項を検証し、考えられる制限事項を評価して、選択したゲートウェイの種類が要件を満たしていることに確信が持てるようにします。
• 個人用ゲートウェイを避ける: 代わりに、標準モードでゲートウェイを使用することを検討します。 リダイレクトして標準モード ゲートウェイを使用するようにできる、個人用ゲートウェイのデータ ソースがあるかどうかを判断します (これにより、使用するのが 1 人の個人に限定されないようにします)。
• ゲートウェイ クラスターが必要かどうかの決定: ビジネス クリティカルなソリューションには、ゲートウェイ クラスターを使用します。 ゲートウェイ クラスターでは、高可用性と負荷分散が提供されます。 これらはまた、単一障害点を回避し、同時使用度が高い期間中のパフォーマンスの向上にも役立ちます。
• 必要なゲートウェイ数の決定: 中断を回避するために、異なる環境用に個別のゲートウェイ クラスターを検討します。 使用状況やリージョンなど、他の要因も考慮に入れます。

ゲートウェイのインストール

この時点で、必要なゲートウェイの種類と数が把握されています。 次に、ゲートウェイのインストールを計画する必要があります。 通常、ゲートウェイは、専用の目的を持つ VM (多くの場合、ゲートウェイ マシンと呼ばれます) にインストールされます。 ユーザー アクティビティとデータ更新操作を継続的にサポートするには、ゲートウェイ クラスター内の各マシンが常にオンになっている必要があります。

ゲートウェイの所有者とインストーラを特定する

ゲートウェイをインストールする前に、ゲートウェイをインストールして所有するユーザーを特定します。

ゲートウェイの所有者

通常、ゲートウェイの所有者とは、ゲートウェイをインストール、所有、管理する技術担当者のことです。 ゲートウェイの所有者は、さまざまなアクティビティを担当します。

• 計画: 前出の説明の通りに主要な事項を決定し、初期のシステム リソースなど、ゲートウェイ マシンの技術仕様を定義します。 また、ゲートウェイの所有者は、サポート プランを確実に配置する必要もあります。
• インストール: ゲートウェイ ソフトウェアをインストールするための適切なマシンを選択して、初回インストールとセットアップを実行します。
• 管理: 最適化のためのゲートウェイの設定または優先事項 (データ のスプールではなくストリーミングの構成など)、または監視の目的 (パフォーマンス ログの構成など) を変更します。 また、ゲートウェイの所有者は、スケールアップ (ゲートウェイ マシンへのリソースの追加)、またはスケールアウト (クラスターへのゲートウェイの追加インストール) を行なう時期についても決定します。
• テスト: 初回セットアップ時にゲートウェイの使用状況を検証し、十分なリソースをゲートウェイ マシンが使用可能であることを確認します。 ゲートウェイの所有者は、毎月の更新をインストールする前に、それらをテストする必要もあります。
• 更新: ゲートウェイ ソフトウェアとサポート アイテム (コネクタ ソフトウェアなど) を適時、更新してインストールします。
• 監視:問題や異常なアクティビティを監視できるゲートウェイ ログ ファイルのコレクションなどにより、ゲートウェイのアップタイムと正常性を監視します。
• 移行: 広範なチームによるアクセスが可能で安全な場所に、回復キー を保存します。 ゲートウェイの所有者は、これらのキーを使用したゲートウェイの移行、復元、または再配置を、必要に応じて行うユーザーでもあります。

ゲートウェイの所有権には重要な責任があるため、組織内でゲートウェイをインストールできるユーザーは、明確に定義される必要があります。

ゲートウェイ インストーラ

管理オーバーヘッドを減らしガバナンス上のリスクを軽減するには、組織内のアクティブなゲートウェイの数を制限することが重要です。 これを達成するためには、ゲートウェイをインストールできるユーザーの数を制限することが推奨されます。

標準モード ゲートウェイでは、Fabric ポータルまたは Power Platform 管理センターから、ゲートウェイ インストーラを管理します。 また、ゲートウェイのインストーラ設定を使用して、VNet データ ゲートウェイを作成できるユーザーを管理します。

• ファブリック接続とゲートウェイ ページ: Fabric ポータルの [接続とゲートウェイ] ページ内からゲートウェイ インストーラを管理できます。
• Power Platform 管理センター: また、Power Platform 管理センターから、ゲートウェイ インストーラを管理することもできます。 設定に対するここでの変更の内容は、Fabric から使用するゲートウェイに影響を与えます。

また、オンプレミスのゲートウェイ管理用の PowerShell コマンドレットを使用して、ゲートウェイ インストーラをプログラムで管理することもできます。 個人用ゲートウェイと標準モード ゲートウェイの場合は、これらのコマンドレットを使用して、ゲートウェイ テナントのポリシーを設定できます。 PowerShell を使用してゲートウェイ テナント ポリシーを設定することは、テナントに個人用ゲートウェイをインストールできるユーザーを管理するための唯一の方法です。

ゲートウェイのインストールを準備する

ゲートウェイをインストールして所有するユーザーを特定したら、ゲートウェイのインストールを準備する必要があります。 次のことを行う必要があります。

• ゲートウェイをインストールする場所を特定します。
• ゲートウェイ マシンに必要なリソースを決定します。
• ゲートウェイのインストール時における、ゲートウェイの名前の付与方法に同意します。

次のセクションでは、ゲートウェイのインストールを計画するために重要な、これらの考慮事項について説明します。

ゲートウェイをインストールする場所を特定する

通常、ゲートウェイは、常時オン状態の VM (ゲートウェイ マシンとも呼ばれます) にインストールします。 マシン上には、それぞれの種類 (個人用モードまたは標準モード) のゲートウェイを 1 つだけインストールできます。

ゲートウェイをインストールする場所を決定するための、主な要因を次に示します。

• 場所: 通常、待機時間を最小限に抑えるために、ゲートウェイ マシンはデータ ソースの近くに配置されます。 通常、標準ゲートウェイは、既定のデータ リージョンにインストールされます。 ただし、Premium 容量の場所がテナントの既定のデータ リージョンと異なる場合は、データ所在地の要件を満たすためのオプションとして、Azure Relay の使用についても調査してください。
• サポート アイテム: ゲートウェイ マシンにインストールする必要があるコネクタ、ドライバー、ライブラリを決定します。
• ドメイン: ゲートウェイ マシンとターゲット ドメインに、どのような関係性があるかを決定します。 VM は、ターゲット ドメインとの信頼関係を持つ、ドメイン参加済みのマシンである必要があります。 これをドメイン コントローラーにすることはできません。

ゲートウェイ マシンのリソースを決定する

ゲートウェイ マシンには、予想されるクエリ ワークロードを処理するための、十分なリソースが必要です。

ゲートウェイ マシンのリソースを決定するための主な要因を次に示します。

• 使用法: ゲートウェイを使用するアイテムの数と種類、およびクエリが (多くのユーザーから) どのように同時実行されるのかを決定します。 使用率が高い場合は、より多くのリソースを持つゲートウェイ マシンが必要です。
• 接続の種類: Power BI セマンティック モデルはデータをインポートするのか、DirectQuery を使用するのか、ライブ接続を使用するのかを決定します。 インポート セマンティック モデルの場合は、ゲートウェイ リソースのニーズ (RAM など) を見積もるために、データ更新の数を確認することが重要です。 DirectQuery またはライブ接続の場合は、リソースのニーズ (CPU など) を見積もるために、レポート コンシューマーの数を評価する必要があります。

名前付け規則に同意する

ゲートウェイとそのデータ ソース接続に、どのように名前を指定するのかは重要です。 名前は、接続する対象をコンテンツ作成者が単刀直入に把握できるようにします。 ゲートウェイとデータ ソース接続に明瞭な名前を付けるためには、論理的な名前付け規則を使用する必要があります。

名前付け規則を定義する際には、次の点を考慮します。

• 監査、ログ記録、トラブルシューティングの目的でゲートウェイを識別するには、名前に Gateway または DataGW を変形して含めます。
• 特定の Fabric アイテム、操作、リージョン、またはビジネス領域をサポートする場合は、そのゲートウェイの具体的な目的を含めます。
• ゲートウェイが特定の環境をサポートしている場合は、名前に Dev、 Test、または Prod を変化させたものを使用します。
• ゲートウェイには、それが属するクラスターの名前に沿った名前を付けます。 たとえば、クラスター内の各ゲートウェイ マシンに、Node1、Node2 と続くような、一意の名前をそれぞれ付けます。

いくつかの論理ゲートウェイの名前の例を次に示します。

• DataGW-Prod-Node1
• Gateway-DevTest-Node1
• Gateway-FinanceTeam-Prod-Node1

ゲートウェイのインストールと設定

主要な事項を決定し準備を行った後、ゲートウェイの所有者はゲートウェイをインストールし、初回のセットアップを実行します。

ゲートウェイのインストールと設定を行なう際には、次の要因を考慮してください。

• インストール場所: ゲートウェイを既定のインストール パス以外の場所にインストールしたい場合は、インストール場所を変更できます。
• 回復キー: 既存のゲートウェイを移行、復元、または引き継ぐ場合は、ゲートウェイの回復キーを使用する必要があります。 回復キーは、他のゲートウェイ管理者がアクセスできる安全で保護された場所に、適切に保管してください。
• データ センター リージョン: リージョンを登録済みサービスのテナントとは異なる場所にしたい場合は、データ センター リージョンを変更できます。
• Azure Relay: 既定のリレーの代わりに独自のリレーを使用したい場合は、独自のリレーの詳細を指定できます。
• プロキシ設定: ご使用の作業環境において、ゲートウェイが Fabric ポータルに接続するためにプロキシ サーバーを経由す必要がある場合は、プロキシを設定する必要があります。
• ゲートウェイ サービス アカウント: 明示的なドメイン アカウントを使用する場合は、ゲートウェイ サービス アカウントを既定の PBIEgwService から変更できます。
• 通信設定: 送信接続がファイアウォールによりブロックされる場合、セキュリティチームとネットワーク チームは、ゲートウェイから関連付けられた Azure リージョンへの送信接続を許可するように、ファイアウォールを設定できます。
• テナントの登録: どの時点で、データ流出を防ぐために、オンプレミスのデータ ゲートウェイ アプリケーションを登録することが許可されたテナントを制限するか。
• 統合テナントの設定: ゲートウェイがシングル サインオン (SSO) で (たとえば、Microsoft Entra ID ベースの認証を使用して)、意図した方法通りに動作していることを、どの時点で確認するか。

チェックリスト - ゲートウェイを準備およびインストール際の、主な決定事項とアクションは次のとおりです。

• ゲートウェイの所有者とインストーラの特定: ゲートウェイの所有者が各自の責任を認識していることを確認します。 ゲートウェイのインストールを適切なユーザーに制限します。
• トレーニングの実施: ゲートウェイを効果的にインストール、管理、サポートするために、必要に応じて、ゲートウェイの所有者とインストーラーをトレーニングします。 必要な場合には、バックアップのためのクロストレーニングを実施します。
• 名前付け規則の作成: 目的、環境、クラスター ノード、サポートされているユース ケース、または実行する操作に対応して、ゲートウェイの名前付け規則を作成します。
• リソースのニーズを考慮する: 初期リソース (メモリや CPU など) を決定するために、ワークロードと使用状態がどうなるのかを確認します。
• 統合テナントの設定: 統合テナントの設定を レビューおよび指定し、ゲートウェイがシングル サインオン (SSO) で、意図した方法通りに動作するようにします。
• ゲートウェイ マシンのプロビジョニング: ゲートウェイ操作をサポートするのに十分なリソースを備えた、常時オン状態の VM を設定します。
• ゲートウェイのインストール: ゲートウェイ マシンでゲートウェイの初回セットアップを実行します。
• サポート アイテムのインストール: 対象のシナリオをサポートするために、カスタム データ コネクタまたは依存するソフトウェアをインストールします。

ゲートウェイを管理する

ゲートウェイをインストールした後は、データ ソース接続を追加します。 これらの接続を追加するときには、ゲートウェイとその接続へのアクセスをどのように管理するのかも、計画する必要があります。

データ ソース接続:を追加する

ゲートウェイを使用する前に、初期データ ソース接続を追加する必要があります。 接続の追加は、Power BI サービスまたは Power Platform 管理センターから手動で、または Power BI REST API を 使用してプログラムで行ないます。

接続を追加する際には、次の点を考慮してください。

• 保存された資格情報: データ ソースへの接続に、どの資格情報を使用するかを検討します。 接続を追加する場合、そのデータ ソースの資格情報を指定する必要があります (匿名認証がサポートされている場合を除く)。 この決定は重要です。データ ゲートウェイの Microsoft Entra シングル サインオン (SSO) を使用していない限り、データ ソースに対するすべてのクエリは、これらの資格情報を使用して実行されるためです。
• 名前付け規則: ゲートウェイと同様、接続においても、論理的かつ一貫性のある名前付け規則を使用する必要があります。 接続の名前は、データ ソースの名前に対応させます。 たとえば、 FinanceDB-Prod は、データ ソースを示す論理的な名前です。
• シングル サインオン: DirectQuery で (Active Directory SSO または Microsoft Entra SSO を使用して) シングル サインオン (SSO) を使用する場合は、Fabric の管理者設定で、ゲートウェイ の Microsoft Entra シングル サインオン (SSO) オプションを有効にする必要があります。 レポート ユーザー ID に基づいて、データ ソース システムでデータ セキュリティを適用する場合は、SSO を使用する必要があります。
• プライバシー レベル: データ ソース接続のインポート用に、プライバシー レベルを設定する必要があります。 データ ソースを適切に分離するためには、必要に応じて、適切なプライバシー レベルを選択する必要があります。 Power BI Desktop で設定されたプライバシー レベルは、ゲートウェイでは歓迎されないと理解しておくことが重要です。

ゲートウェイ アクセスをプロビジョニングする

初期データ ソース接続を追加した後は、ゲートウェイとその接続の両方へのアクセスを管理する方法を決定します。

コンテンツ作成者は、データ ソースに正常に接続するためにゲートウェイ接続にアクセスする必要があります。 ゲートウェイ接続へのユーザー アクセスは接続ごとに行われるので、各ゲートウェイ接続へのアクセスを必要とするユーザーと、そのアクセスを管理する方法を検討します。 ゲートウェイと接続の両方に対し、セキュリティ ロールを使用してアクセスを管理する必要があります。

ゲートウェイのロール

ゲートウェイ ロールにより、ゲートウェイとそのデータ ソース接続を管理できるユーザーを制御できます。 これらのロールはワークスペース ロールと同様に機能し、ロールに応じて異なるアクセスを許可します。 ロールを使用すると、ゲートウェイ アクセスをより効果的に管理できます。

オンプレミスの標準ゲートウェイの管理用としては、3 つのゲートウェイ ロールが存在します。

• 管理者: このロールのメンバーは、ゲートウェイを管理および更新できます。 通常、ゲートウェイの所有者はゲートウェイ管理者ですが、1 つのゲートウェイに複数の管理者が存在する場合もあります。 ゲートウェイ管理者は、Fabric の管理者であるか、COE または中央 BI チームのメンバーである必要があります。 管理者の役割は、ゲートウェイ所有者と同じです。
• 共有を使用する接続作成者: このロールのメンバーは、ゲートウェイ接続の作成、ゲートウェイの状態のテスト、他のユーザーとのゲートウェイの共有を行うことができます。 このロールでは、ゲートウェイからユーザーを削除することはできません。 ビジネス ユニットの非集約型チームなどで、分析ソリューションのサブセットを担当する場合には、このロールにユーザーを追加することを検討してください。 このロールを担うユーザーの役割には次が含まれます。
  • 新しい接続の設定とテスト。
  • 資格情報の設定など、自身が所有する接続の管理。
  • 必要とする他のユーザーとのゲートウェイの共有。
  • ゲートウェイへのアクセス権を持つユーザーを定期的にレビューし、ゲートウェイをまだ必要としているかどうかを検証し、不要である場合は削除します。
• 接続作成者: このロールのメンバーは、ゲートウェイ上で接続を作成し、その状態をテストできます。 接続作成者は、ゲートウェイを使用するための正しい接続を適切に設定できる、コンテンツ所有者である必要があります。 接続作成者ロールの役割は、ゲートウェイへのアクセスを共有できない点を除いて、共有を使用する接続作成者ロールと同じです。

データ ソース接続ロール

データ ソース接続ロールでは、接続を使用、管理、共有できるユーザーを制御できます。 接続ロールを担うユーザーは、ゲートウェイ ロールに属す必要はありません。

データ ソース接続には 3 つのロールがあります。

• 所有者: このロールのメンバーは接続を管理し、不要な場合にはそれを削除することができます。 所有者は、他の接続の所有者を追加することを含め、接続ロールを管理できます。 また通常、所有者は接続の作成者でもあります。 誰かがデータ ソースのスチュワードまたは管理者であるか、データ ソースとその内容に関して顕著な知識を持っている場合は、その人物を接続所有者にすることを検討してください。 所有者の役割には次が含まれます。
  • 資格情報の更新など、必要に応じた接続の管理。
  • 不要になった場合の接続の削除。
  • Power Platform 管理センターからの接続ロールの管理。
• 共有を使用するユーザー: このロールのメンバーは、他のユーザーを追加することで、データ ソースを使用および共有できます。 誰かがユーザー コミュニティで重要な役割を果たしている場合は、その人物をこのロールに追加することを検討してください。 チャンピオンは、この役割に適した候補だと言えます。 このロールを担うユーザーの役割には次が含まれます。
  • それを必要とする他のユーザーとの接続の共有。
  • 接続にアクセスできるユーザーの定期的なレビュー、まだ接続を必要としているかどうかの確認、および不要な場合の削除。
• ユーザー: このロールのメンバーは、Power BI レポートと Power BI データフロー内でデータ ソースを使用できます。 ユーザーの役割は、ワークロードとクライアント ツールからのデータに対してクエリを実行することのみです。

ゲートウェイと接続をドキュメント化する

ゲートウェイ クラスターを設定したら、そのドキュメント化を行なう必要があります。 コンテンツ作成者には見つけやすく、ゲートウェイ管理者には管理しやすくするために、ゲートウェイのドキュメントを作成します。 ゲートウェイドキュメントは、関連する実践コミュニティの一元化されたポータルのような、アクセス可能な場所に保存することを考慮します。

ドキュメント化では以下の情報を考慮に入れます。

• ゲートウェイ名と GUID
• ゲートウェイ マシン名 (およびそれぞれの識別子)
• ゲートウェイ所有者
• ソフトウェアの最終更新日 (ゲートウェイ のバージョン)
• ゲートウェイ クラスターの目的 (環境、リージョン、ビジネス領域など)
• ゲートウェイで維持する必要があるデータ ソース接続
• ゲートウェイが、ユーザー ID と保存された資格情報のどちらを使用するか
• アクセス管理ポリシー (ゲートウェイ ロールと接続ロールをどのように使用するか)

ゲートウェイを更新

ゲートウェイの機能性と良好なパフォーマンスを維持するには、いくつかのタスクを実行する必要があります。

• Windows 更新プログラムをインストールし、他のサーバー メンテナンスを実行します。
• ゲートウェイ ソフトウェアを更新します。 ゲートウェイ ソフトウェアは毎月更新され、オンプレミス ゲートウェイについて Microsoft は、最後の 6 つのリリースのみをサポートします。
• 必要に応じて、カスタム データ コネクタ、ドライバー、ライブラリを更新します。

このセクションの残りの部分では、ゲートウェイ ソフトウェアを更新する方法について説明します。

開発用またはテスト用ゲートウェイに更新内容をインストールする

予期しない中断を回避し、最新の機能強化の恩恵を受けるためにも、ゲートウェイを最新の状態に保つことは重要です。 とはいえ、更新によって、ゲートウェイのパフォーマンスと機能に予期しない結果が生じる可能性があります。 ビジネスクリティカルなソリューションに影響を与えないようにするには、まず (運用環境をサポートするゲートウェイに適用する前に)、ゲートウェイのソフトウェア更新プログラムを開発ゲートウェイまたはテスト ゲートウェイにインストールしてみる必要があります。

更新プログラムを確認する

ゲートウェイのテストは、最初に、開発とテストの環境をサポートするゲートウェイに更新プログラムを適用することで行ないます。

ゲートウェイの更新を確認する際には、次の点を考慮に入れてください。

• 反復可能なテスト条件の定義: すべての関連するゲートウェイ操作とデータ ソースを確実にテストできるように、反復可能なテスト条件のリストを定義します。 たとえば、重要と見なされ検証が必要なレポートとセマンティック モデルを、特定することが考えられます。 また、反復可能なテスト条件として適格な、コンプライアンス要件を満たす必要がある場合もあります。
• テスト レポート セットの使用: ゲートウェイが更新されるたびの機能テストに、一連のレポートが使用されるよう維持します。 これらのレポートは、反復可能なテスト条件をすばやく検証するのに役立ちます。 多くの場合、これらのテスト レポートは合計とカウントのみを示します。 目標とするのは、次についてのアクセス、レンダリング、更新を確実にテストすることです。
  • 共通で使用される各データ ソース。
  • 最もクリティカルなセマンティック モデルなど、データ項目の各キーの種類。
  • インポートや DirectQuery など、さまざまなストレージ モード。
• ビジネスクリティカルなレポートの特定: 新しい更新内容をテストできる、ビジネスクリティカルなレポートにアクセス (またはそのコピーを取得) します。 これらのレポートは、データを更新できることと、DirectQuery レポートが期待どおりに動作していることを、確認するのに役立ちます。
• テスト プロセスの自動化: Power BI REST API を使用して、インポート データ項目のデータ更新をテストし、DAX クエリを評価します。 更新の失敗やクエリ エラーをキャッチしてログに記録できることを確認します。

運用環境に更新内容をインストールする

ゲートウェイの更新を検証した後は、運用環境をサポートするすべてのゲートウェイに、その更新プログラムを適用します。 更新中のゲートウェイは利用不可となるため、ゲートウェイ を更新するタイミングと方法には、一貫性を持つ必要があります。

ゲートウェイの更新については、次の点を考慮してください。

• 一元化されたポータルで、ゲートウェイの現在のバージョンをドキュメントします。
• 履歴上、ゲートウェイ使用率が低い期間中に、更新プログラムを適用します。
• 更新内容をテストおよび適用する時期には、一貫性のあるスケジュールを使用します。 毎月の更新が頻繁すぎる場合は、少なくとも四半期ごとにゲートウェイが更新されることを保証してください。
• ゲートウェイ クラスター マシンは、一度に 1 つ更新します。 各マシンをローテーションさせることで、ダウンタイムを回避できます。

資格情報の更新

保存された資格情報を必要とするデータ ソース接続の場合は、資格情報を定期的にローテーションすることが必要になる場合があります。 たとえば、組織のポリシーで、頻繁なパスワードのリセットを要求している場合があります。 この方法は、主要なチーム メンバーが組織を離れる場合にも有益です。 効率を向上させるため、資格情報の更新に Power BI REST API を使用できます。

チェックリスト - データ ゲートウェイを管理する場合の主な決定事項とアクションには、次が含まれます。

• データ ソース接続の作成: 組織で共通したデータ ソースの、データ ソース接続を設定します。 その接続は、明確で一貫性のある名前付け規則に従っていることを確認します。
• ゲートウェイとデータ ソースをドキュメント化する: ゲートウェイと接続に関する簡潔なドキュメントを作成します。 このドキュメントには、ゲートウェイの所有者と管理者向けの一元化されたポータルから、簡単にアクセスできるようにします。
• 接続要求の処理: 接続要求を収集および管理するプロセスを作成します。 接続要求に承認プロセスが必要かどうかを判断します。 Power BI REST API を使用してプロセスを自動化することを検討します。
• ゲートウェイ ロールのプロビジョニング: 最小特権の原則を使用して、ゲートウェイ ロールに個人を割り当てます。 接続作成者または共有を使用する接続作成者が接続管理に貢献できるようにするため、これらのユーザーにデータ ソース スチュワードを追加することを検討してください。
• 接続ロールのプロビジョニング: コンテンツ作成者 (および該当する場合はコンシューマー) を接続ロールに割り当てて、ゲートウェイを使用できるようにします。 これらのユーザーに共有を制限し、責任を持って接続を共有し、アクセスを定期的にレビューおよび管理します。
• 簡潔なユーザー ドキュメントの作成: コンテンツ作成者がゲートウェイとその接続を検索して使用するための、主だった重要な項目をドキュメント化します。 このドキュメントは、たとえば一元化されたポータルや SharePoint のサポート サイトなど、ユーザー コミュニティが簡単にアクセスできる一元的な場所に配置します。
• 回復キーの慎重なドキュメント化と保存: 回復キーは、複数のチーム メンバーがアクセスできる、安全で保護された場所に保存します。 ゲートウェイを回復する必要がある場合に、それらを簡単に見つけられるようにします。
• 更新をインストールするプロセスの作成: ゲートウェイ ソフトウェア更新プログラムをインストールする頻度と、従うべきプロセスを決定します。 更新のリリース後、1 か月から 3 か月以内にゲートウェイを更新することを目指します。
• 最初にゲートウェイの更新を開発およびテスト向けにインストールする: 運用前に開発およびテスト向けゲートウェイが更新され、初期テストに使用されていることを確認します。
• 運用ゲートウェイに適用する前にゲートウェイの更新をテストする: 繰り返しが可能なテスト条件と項目を使用して、毎月のゲートウェイ更新をテストするプロセスを設定します。
• 運用時はゲートウェイの更新を迅速かつ定期的にインストールする: 運用ゲートウェイは、確実に最新の状態に保たれているようにします。
• 接続資格情報の更新: 必要に応じて、保存されている資格情報を接続で使用するように更新します。

ゲートウェイの監視、監査、最適化

ゲートウェイは、Fabric データ統合にとって極めて重要な部分です。 中断を回避しリスクを軽減するには、定期的にテナント内のゲートウェイを監査し、監視を行なう必要があります。

ゲートウェイの監視は、次のことに役立ちます。

• ガバナンス リスクの軽減。
• 問題の回避。
• パフォーマンスの問題やデータ更新での失敗など、インシデントの調査。

次の表に、データ ゲートウェイ クラスターを管理するときに発生する可能性がある一般的な問題の概要と、問題を監視および調査する方法を示します。

可能性のある問題	問題の種類	問題を監視および調査する方法
多すぎるゲートウェイ数	ガバナンス	• Power Platform 管理センター • ゲートウェイ PowerShell コマンドレット • Power BI REST API
ゲートウェイの過剰共有	ガバナンス	• Power Platform 管理センター • ゲートウェイ PowerShell コマンドレット • Power BI REST API • Power BI アクティビティ ログ
ゲートウェイがオフライン	パフォーマンスと可用性	• Power Platform 管理センター • ゲートウェイ マシンの監視 • ゲートウェイ ログ
ゲートウェイのエラー	パフォーマンスと可用性	• ゲートウェイ ログ
クエリの失敗	パフォーマンスと可用性	• ゲートウェイ ログ • ゲートウェイ ログ (追加ログ)
低速な更新またはクエリ	パフォーマンスと可用性	• ゲートウェイ マシンの監視 • Windows イベント ログ • Windows パフォーマンス カウンター • ゲートウェイ ログ • ゲートウェイ ログ (追加ログ) • サーバー監視ツール

ゲートウェイの監視

テナントにインストールされているゲートウェイの数と、だれがインストールしたかを、定期的にレビューする必要があります。 Fabric ポータルの [接続とゲートウェイ] ページ、および Power Platform 管理センターから、ゲートウェイがどの程度行き渡っているかを監視できます。 どちらのビューも、アクセスできるすべてのゲートウェイについて、簡潔かつ機能的な概要を提供します。 管理者は、この情報を定期的にレビューする必要があります。

ゲートウェイの普及度合いを監視する場合は、次のメトリックに注目してください。

• 上昇しているゲートウェイまたはインストーラーの数: 予期していない新規のゲートウェイまたはインストーラーは、調査する必要があります。
• ゲートウェイ間の接続の冗長性: ゲートウェイの余分なメンテナンス作業を回避するために、接続を統合することを試します。
• 予期しないインストーラーまたはゲートウェイ: 新しいインストーラーまたはゲートウェイがインストールされる前に、それらの承認プロセスが完了していることを確認します。
• 予期しないゲートウェイ マシン、接続、または構成: ユーザー マシンにインストールされているゲートウェイやローカル ファイルへの接続など、異常なゲートウェイ プロパティは特定しておく必要があります。 また、プライバシー レベルの無視など、リスクを生み出す設定内容も特定します。

ゲートウェイ ログの収集と分析

各ゲートウェイ マシンは、問題の特定と解決に使用できる詳細な ログ を生成します。 これらのログは、詳細な技術ファイルのコレクションであり、ゲートウェイ マシンに格納されます。 また、オンプレミス ゲートウェイ アプリからの追加ログを一時的に有効にして、クエリとそのタイミングについての、より詳細な情報を収集することもできます。

ネットワークの遅延が引き起こされないようにするために、ゲートウェイ ログは、ローカル ゲートウェイ マシンに書き込めるようにすることをお勧めします。 ただし、ログが書き込まれるパスを、ゲートウェイ構成ファイルを使用して変更することもできます。 また、ログを保持する期間の長さも変更できます。 構成ファイルを編集する際は、必ず事前にコピーを作成してください。

データを分析できるように、各ゲートウェイ マシンからログ ファイルを収集して統合する、データ統合ソリューションを作成します。 理想的には、すべてのゲートウェイを簡単に表示し異常を特定できるように、このプロセスを自動化し分析レポートに出力させる必要があります。

ゲートウェイ マシンの正常性を監視する

ゲートウェイの正常性は、そのサーバーの正常性に依存します。 中断を回避するには、ゲートウェイ マシンを監視して、マシンのパフォーマンスが良好でない、あるいはオフラインになったことを検出する必要があります。

ゲートウェイを最適化しトラブルシューティングする

ゲートウェイで問題が発生した場合は、その問題を調査および特定する必要が生じます。 通常、トラブルシューティングでは、前出のセクションで説明したゲートウェイ ログを調査し、さまざまな最適化をテストして問題が解決されるかどうかを確認します。

一般的なゲートウェイの最適化を次に示します。

• スプーリングからストリーミングへの変更: ゲートウェイの既定では、クエリを評価する際、ゲートウェイ マシンにデータをスプールします。 その結果、クラウドに転送される前にデータが一時的に保存されます。 スプーリングは、代替方法の (データが直接転送される) ストリーミングより低速になることがあります。 この設定は、ゲートウェイ構成ファイルで変更できます。
• ウイルス対策スキャン: ゲートウェイマシン上のウイルス対策スキャンから、特定のフォルダー を除外すると、ファイル レベルのウイルス対策ソフトウェアを使用する場合のパフォーマンスが向上することがあります。
• スケールアップまたはスケールアウトの計画: どの場合に、ゲートウェイ マシンにリソースを追加してゲートウェイ クラスターをスケールアップするのか、または別のゲートウェイを別のマシンに追加してクラスターをスケールアウトするのかを検討します。

チェックリスト – ゲートウェイを監視する際の主な決定事項とアクションには、次が含まれます。

• ゲートウェイ マシンの監視: 企業の監視ソリューションによって監視されているマシンに、ゲートウェイがインストールされていることを確認します。 それ以外の場合は、これらのマシンのパフォーマンスが良好でないときに、それを検出できる必要があります。
• ゲートウェイの普及度を測定する: 時間の経過に伴いテナントにインストールされているゲートウェイの数が、どのように発展しているかを監視します。
• ゲートウェイ ログの収集と分析: さまざまなゲートウェイ マシンからのログ ファイルを、自動的に収集して結合するソリューションを作成します。 これらのファイルを分析して、有意義な情報を抽出します。 次の 2 種類の分析監視ソリューションを設定することを検討してください。1 つはアラートとアクション用、もう 1 つは問題発生時の調査的根本原因分析用です。
• 役割と責任の検証: 監視、最適化、トラブルシューティングのために、ロールと責任が定義されていることを確認します。

関連するコンテンツ

Power BI の実装の決定に役立つ考慮事項、アクション、意思決定基準、推奨事項について詳しくは、「Power BI 実装計画」をご覧ください。