マルチテナントアプリケーションのサービスプリンシパルプロファイルを構成する

この記事では、Power BI Embedded の embed for your customers ソリューション向けにサービスプリンシパルプロファイルを選択した後、サービスプリンシパルプロファイルを構成して操作する方法について説明します。プロファイルは、顧客スコープのコンテンツ管理と多数のワークスペースに対応します。顧客の分離は、適切なアプリケーションルーティング、ワークスペースのアクセス許可、適切なスコープの埋め込みトークンに依存します。プロファイルによって、独立した Microsoft Entra ID 識別情報や暗号学的な顧客境界が作成されることはありません。

注

新しいマルチテナントソリューションの場合は、ホスティングと信頼の要件に適合する場合は、マネージド ID とフェデレーション資格情報を使用して、専用のカスタマーサービスプリンシパルから始めます。プロファイルは、その利点と制限に適合する要件を持つ新規および既存のアプリケーションに対して、有効でオプションのソリューションであり続けます。プロファイルが要件を満たしている場合は、引き続きプロファイルを使用できます。

プロファイルは Microsoft Entra ID ではなく、Fabric REST API と共に使用できません。ソリューションで、顧客 ID 情報、ダウンストリームサービス、独立した Microsoft Entra サインインログ、ワークロード ID の条件付きアクセス、またはプロファイルモデルによって制限される機能が必要な場合は、サービスプリンシパルプロファイルをサービスプリンシパルに置き換えることを検討してください。

注

Power BI の "テナント" という単語は、Microsoft Entra テナントのことを指す場合があります。ただし、この記事では、"マルチテナント" という用語を使って、ソフトウェアアプリケーションの 1 つのインスタンスがデータの物理的および論理的な分離を必要とする複数の顧客または組織 (テナント) にサービスを提供するソリューションについて説明します。たとえば、Power BI アプリビルダーは、この記事で説明するように、顧客 (またはテナント) ごとに個別のワークスペースを割り当てることができます。これらの顧客は必ずしも Microsoft Entra テナントではありません。そのため、ここで使用する マルチテナントアプリケーション という用語を Microsoft Entra マルチテナントアプリケーションと混同しないでください。

"サービスプリンシパルプロファイル" とは、サービスプリンシパルによって作成されるプロファイルです。この記事で説明するように、ISV アプリでは、サービスプリンシパルプロファイルを使用して Power BI API を呼び出します。

ISV アプリケーションのサービスプリンシパルによって、顧客ごと、またはテナントごとに異なる Power BI プロファイルが作成されます。顧客が ISV アプリにアクセスすると、アプリは対応するプロファイルを使用して、ブラウザーでレポートを表示するために使用される埋め込みトークンを生成します。

サービスプリンシパルプロファイルを使用すると、ISV アプリから、単一の Power BI テナントで複数顧客をホストできます。 Power BI の各プロファイルは 1 顧客を表します。つまり、プロファイルごとに、特定の 1 顧客のデータの Power BI コンテンツが作成および管理されます。

サービスプリンシパルプロファイルとマルチテナントの図。

注

この代替方法の概要については、「サービスプリンシパルプロファイル: オプションのマルチテナントソリューション」を参照してください。プロファイルモデルを選択した後、次の構成手順が適用されます。

Power BI コンテンツの設定は、次の手順で行います。

プロファイルを作成する
プロファイルのアクセス許可を設定する
顧客ごとにワークスペースを作成する
ワークスペースにレポートとセマンティックモデルをインポートする
顧客のデータに接続するためのセマンティックモデル接続の詳細を設定する
サービスプリンシパルからアクセス許可を削除する (省略可能ですが、スケーラビリティに役立つ)
アプリケーションにレポートを埋め込む

上記のすべての手順は、Power BI REST API を使用して完全に自動化できます。

前提条件

サービスプリンシパルプロファイルを作成する前に、次のことを行う必要があります。

親サービスプリンシパルと必要なテナント設定を構成します。サービスプリンシパルのセットアップまたはマネージド ID の親オプションを参照してください。
Power BI テナント管理者アカウントから、"サービスプリンシパルの作成時に使用したのと同じセキュリティグループを使用して" テナントにプロファイルを作成できるようにします。

プロファイルを作成する

プロファイルは、Profiles REST API を使用して作成、更新、削除できます。

たとえば、プロファイルを作成するには、次のようにします。

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

また、サービスプリンシパルで、GET Profiles REST API を呼び出して、そのプロファイルのリストを取得することもできます。次に例を示します。

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

プロファイルのアクセス許可

Power BI アイテムにユーザーのアクセス許可を付与する API で、Power BI アイテムにプロファイルのアクセス許可を付与することもできます。たとえば、Add Group User API を使用して、ワークスペースにプロファイルのアクセス許可を付与できます。

プロファイルを使用する場合は、次の点を理解することが重要です。

プロファイルは、プロファイルを作成したサービスプリンシパルに属しており、そのサービスプリンシパルのみがそれを使用できます。
プロファイルの所有者は、作成後に変更することはできません。
プロファイルはスタンドアロンの ID ではありません。 Power BI REST API を呼び出すには、サービスプリンシパルの Microsoft Entra トークンが必要です。

ISV アプリから、サービスプリンシパルの Microsoft Entra トークンを Authorization ヘッダーに、プロファイル ID を X-PowerBI-Profile-Id ヘッダーに指定して、Power BI REST API を呼び出します。次に例を示します。

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

ワークスペースの作成

Power BI ワークスペースは、レポートやセマンティックモデルなど、Power BI の項目をホストするために使用されます。

プロファイルごとに、次のことを行う必要があります。

少なくとも 1 つのPower BI ワークスペースを作成する

POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

ワークスペースにアクセス許可を付与する。サービスプリンシパルプロファイルには、ワークスペースへの ''管理者'' アクセス権が必要です。

ワークスペースをキャパシティに割り当てる

POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

詳細については、Power BI ワークスペースに関するページをご覧ください。

レポートとセマンティックモデルをインポートする

Power BI Desktop を使用して、顧客のデータまたはサンプルデータに接続されるレポートを準備します。次に、Import API を使用して、作成したワークスペースにコンテンツをインポートできます。

POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

データセットパラメーターを使用して、異なる顧客のデータソースに接続できるセマンティックモデルを作成します。次に、Update パラメーター API を使用して、セマンティックモデルから接続する顧客のデータを定義します。

セマンティックモデルの接続を設定する

ISV は通常、次の 2 つの方法のいずれかを使用して顧客のデータを格納します。

顧客ごとに個別のデータベース
1 つのマルチテナントデータベース

どちらの場合も、最終的に Power BI で単一テナントセマンティックモデル (顧客ごとに 1 つのセマンティックモデル) が必要です。

顧客ごとに個別のデータベース

ISV アプリケーションに顧客ごとに個別のデータベースがある場合は、Power BI で単一テナントセマンティックモデルを作成します。各セマンティックモデルに、対応するデータベースを指す接続の詳細を指定します。次のいずれかの方法を使用して、接続の詳細が異なる同一のレポートを複数作成しないようにします。

セマンティックモデルパラメーター: 接続の詳細 (SQL サーバー名、SQL データベース名など) にパラメーターを指定してセマンティックモデルを作成します。次に、レポートを顧客のワークスペースにインポートし、顧客のデータベースの詳細に合わせてパラメーターを変更します。
Update Datasource API: サンプルコンテンツを含むデータソースを指す .pbix を作成します。次に、.pbix を顧客のワークスペースにインポートし、Update Datasource API を使用して接続の詳細を変更します。

1 つのマルチテナントデータベース

ISV アプリケーションですべての顧客に対して 1 つのデータベースを使用する場合は、次のように Power BI で顧客を異なるセマンティックモデルに分離します。

関連する顧客のデータのみを取得するパラメーターを使用してレポートを作成します。次に、レポートを顧客のワークスペースにインポートし、パラメーターを変更して関連する顧客のデータのみを取得します。

レポートの埋め込み

設定が完了したら、埋め込みトークンを使用して、顧客レポートや他のアイテムをアプリケーションに埋め込むことができます。

顧客がアプリケーションにアクセスするときに、対応するプロファイルを使用して GenerateToken API を呼び出します。生成される埋め込みトークンを使用して、レポートまたは他のアイテムを顧客のブラウザーに埋め込みます。

埋め込みトークンを生成するには、次のようにします。

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

設計の側面

プロファイルベースのマルチテナントソリューションを設定する前に、次の問題を認識しておく必要があります。

スケーラビリティ
自動化と運用の複雑さ
Multi-Geo のニーズ
コスト効率
行レベルのセキュリティ

スケーラビリティ

顧客ごとにデータを個別のセマンティックモデルに分離することで、大規模なセマンティックモデルの必要性を最小限に抑えます。容量がオーバーロードになったら、未使用のセマンティックモデルを削除して、アクティブなセマンティックモデルのためにメモリを解放できます。この最適化は、単一の大規模なセマンティックモデルでは不可能です。複数のセマンティックモデルを使用することで、必要に応じて、複数の Power BI 容量にテナントを分離することもできます。

プロファイルがない場合、サービスプリンシパルは 1,000 個のワークスペースに制限されます。この制限を克服するために、サービスプリンシパルは複数のプロファイルを作成し、プロファイルごとに最大 1,000 個のワークスペースにアクセス/作成することができます。複数のプロファイルを使用すると、ISV アプリでは、個別の論理コンテナーを使用して各顧客のコンテンツを分離できます。

サービスプリンシパルプロファイルからワークスペースにアクセスできるようになった後、スケーラビリティの問題を回避するために、その親サービスプリンシパルのワークスペースへのアクセスを削除できます。

これらの利点があっても、アプリケーションの潜在的なスケールを考慮する必要があります。たとえば、プロファイルからアクセスできるワークスペースアイテムの数は制限されています。現在、プロファイルには通常のユーザーと同じ制限があります。 ISV アプリケーションでエンドユーザーが埋め込みレポートの個人用コピーを保存できる場合、顧客のプロファイルは、すべてのユーザーの作成されたすべてのレポートにアクセスできます。このモデルは、最終的に制限を超える可能性があります。

自動化と運用の複雑さ

Power BI のプロファイルベースの分離を使用すると、場合によっては、数百から数千のアイテムを管理する必要があります。したがって、アプリケーションのライフサイクル管理で頻繁に発生するプロセスを定義し、これらの操作を大規模に実行するための適切なツールセットを確実に用意することが重要です。これらの操作には、次のものが含まれます。

新しいテナントの追加
一部またはすべてのテナントのレポートの更新
一部またはすべてのテナントのセマンティックモデルスキーマの更新
特定のテナントに対して計画外のカスタマイズを有効にする
セマンティックモデルの更新頻度の設定

たとえば、新しいテナントのプロファイルとワークスペースの作成は一般的なタスクであり、 Power BI REST API を使用して完全に自動化できます。

Multi-Geo のニーズ

Power BI Embedded の Multi-Geo のサポートにより、Power BI Embedded を使用して分析をアプリに組み込むアプリケーションをビルドする ISV や組織が、データを世界中の異なるリージョンにデプロイできるようになりました。異なるリージョンで異なる顧客をサポートするには、顧客のワークスペースを目的のリージョンの容量に割り当てます。このタスクは、追加コストを伴わないシンプルな操作です。しかしながら、複数のリージョンのデータを必要とする顧客がいる場合は、そのテナントプロファイルで、異なるリージョンの容量に割り当てられている複数のワークスペースにすべてのアイテムを複製する必要があります。この重複により、コストと管理の両方の複雑さが増す可能性があります。

コンプライアンス上の理由から、異なるリージョンに複数の Power BI テナントを作成することもできます。詳細については、Multi-Geo に関する記事をご覧ください。

コスト効率

Power BI Embedded を使用するアプリケーション開発者は、Power BI Embedded の容量を購入する必要があります。プロファイルベースの分離モデルは、次の理由により、容量に適しています。

容量に個別に割り当てることができる最小のオブジェクトは、ワークスペースです (たとえば、レポートを割り当てることはできません)。顧客をプロファイル別に分離することによって、顧客ごとに 1 つずつ、異なるワークスペースを取得できます。こうすることで、パフォーマンスのニーズに応じて各顧客を柔軟に管理でき、スケールアップまたはスケールダウンによって容量使用率を最適化できます。たとえば、量が多く、変動しやすい大規模な重要顧客は別個の容量で管理して一貫したサービスレベルを保証する一方、小規模な顧客は別の容量にグループ化してコストを最適化できます。
ワークスペースを分離するということは、セマンティックモデルをテナント間で分離することにより、データモデルを、単一の大規模なセマンティックモデルではなく、小さなチャンクにできるということでもあります。これらの小さなモデルにより、メモリ使用量をより効率的に管理する能力が向上します。使用されていない小規模なセマンティックモデルは、良好なパフォーマンスを維持するために、非アクティブな状態が一定期間続くと削除できます。

複数のセマンティックモデルがある場合、更新プロセスで追加の容量が必要になることがあるので、容量を購入する際には、並列更新の数に対する制限を考慮してください。

行レベルセキュリティ

この記事では、プロファイルを使用して、顧客ごとに個別のセマンティックモデルを作成する方法について説明します。または、ISV アプリケーションで、すべての顧客のデータを 1 つの大規模なセマンティックモデルに格納し、行レベルのセキュリティ (RLS) を使用して各顧客のデータを保護することもできます。このアプローチは、次の理由により、顧客が比較的少数で、小規模から中規模のセマンティックモデルを持つ ISV にとって都合が良い可能性があります。

1 つのレポートと 1 つのセマンティックモデルを維持するだけで済みます
新規顧客のオンボードプロセスを簡略化できる

ただし、RLS を使用する前に、制限事項を理解しておく必要があります。すべての顧客のすべてのデータが、1 つの大きな Power BI セマンティックモデルに含まれます。このセマンティックモデルは、独自のスケーリングやその他の制限がある単一の容量で実行されます。

サービスプリンシパルプロファイルを使用して顧客のデータを分離する場合でも、単一の顧客のセマンティックモデル内で引き続き RLS を使用して、データの異なる部分へのアクセス権を異なるグループに付与することができます。たとえば、RLS を使用すると、ある部門のメンバーが同じ組織内の別部門のデータにアクセスできないようにすることができます。

考慮事項と制限事項

プロファイルモデルを選択または拡張する前に、ID 管理、API、およびスケールの制限を評価します。

ID と API の制限事項

プロファイルを採用するか、既存のプロファイルベースのソリューションを拡張する前に、次の制限事項を確認してください。

制限	お客様のソリューションにとっての意味
Microsoft Entra ID ではない	プロファイルは、Power BIにのみ存在します。 Microsoft Entra ツールを使用して個別に統制またはレビューしたり、ダウンストリームサービスで ID としてアクセス許可を付与したりすることはできません。たとえば、プロファイルをセマンティックモデルからレイクハウスまたはウェアハウスへの Direct Lake 接続の資格情報にすることはできません。
Fabric REST API のサポートなし	プロファイルは、Power BI REST API、Power BI .NET SDK、およびサポートされている XMLA/TOM インターフェイスを介して動作します。 Fabric REST API ではそれらはサポートされておらず、サポートも計画されていません。
独立したサインイン ID がない	プロファイルスコープの操作では、顧客ごとの独立したMicrosoft Entraサインインレコードは生成されません。 Power BI のアクティビティログでは、引き続きプロファイルを識別できます。
プロファイルごとの条件付きアクセスなし	プロファイルは、ワークロード ID の条件付きアクセスがターゲットにできるプリンシパルではありません。対象となる専用サービスプリンシパルのポリシーには、個別のライセンスと構成の要件があります。
作成元プリンシパルにバインドされている	親サービスプリンシパル間でプロファイルを転送することはできません。親を変更するには、プロファイルの再作成、ワークスペースアクセスの復元、顧客マッピングの更新が必要です。
API のみの管理	プロファイルには、プロファイルを検査および管理するための専用の管理 UI はありません。これらは Microsoft Entra 管理センターでは表示されません。

これらの制限によってソリューションが制限される場合は、「サービスプリンシパルプロファイルをサービスプリンシパルに置き換える」を参照してください。移行を選択するお客様には、このガイドでは、ホスティングと信頼の要件に合う場合は、マネージド ID とフェデレーション資格情報をお勧めします。直接サービスプリンシパル認証は、引き続き代替手段です。

サポートされているインターフェイスとスケールの制限

サービスプリンシパルプロファイルは、Analysis Services クライアントライブラリバージョン 16.0.139.27 以降を使用する場合は、Power BI REST API、Power BI .NET SDK、XMLA エンドポイントおよび表形式オブジェクトモデル (TOM) を介した場合のみサポートされます。サービスプリンシパルプロファイルは、XMLA エンドポイントまたは古いクライアントライブラリを使用した表形式オブジェクトモデル (TOM) を介して Power BI でサポートされていません。
サービスプリンシパルプロファイルは、ライブ接続モードの Azure Analysis Services (AAS) ではサポートされていません。
1 つのサービスプリンシパルが保有できるプロファイルの最大数は 100,000 です。

Power BI の容量の制限事項

各容量では、購入した SKU に従って、割り当てられているメモリと仮想コアのみを使用できます。各 SKU の推奨セマンティックモデルサイズについては、「Premium 大規模セマンティックモデル」を参照してください。
10 GB を超えるセマンティックモデルを使用するには、Premium 容量を使用し、大規模なセマンティックモデルの設定を有効にします。
容量に対して同時に実行できる更新の数については、リソースの管理と最適化に関する記事をご覧ください。

サービスプリンシパルを管理する

サービスプリンシパルを変更する

Power BI では、プロファイルは、それを作成したサービスプリンシパルに属しています。つまり、プロファイルを他のプリンシパルと共有することはできません。この制限により、何らかの理由でサービスプリンシパルを変更する場合は、すべてのプロファイルを再作成し、関連するワークスペースへのアクセス権を新しいプロファイルに提供する必要があります。多くの場合、ISV アプリケーションで、必要に応じて適切なプロファイルを選択するために、プロファイル ID と顧客 ID の間のマッピングを保存する必要があります。サービスプリンシパルを変更してプロファイルを再作成すると、ID も変更され、ISV アプリケーションデータベースのマッピングの更新が必要になる場合があります。

サービスプリンシパルを削除する

警告

サービスプリンシパルを削除するときは注意してください。関連するすべてのプロファイルのデータを誤って失わないようにするためです。

Active Directory でサービスプリンシパルを削除すると、Power BI 内のすべてのプロファイルが削除されます。ただし、Power BI はコンテンツをすぐに削除しないため、テナント管理者はワークスペースに引き続きアクセスできます。実稼働システムで使用されているサービスプリンシパルを削除する場合、特に Power BI でこのサービスプリンシパルを使用してプロファイルを作成した場合は注意してください。プロファイルを作成したサービスプリンシパルを削除する場合は、すべてのプロファイルを再作成し、関連するワークスペースへの新しいプロファイルアクセスを提供し、ISV アプリケーションデータベースのプロファイル ID を更新する必要があります。

データの分離

サービスプリンシパルプロファイルを使用する場合、アプリケーションは、認証された各顧客を適切なプロファイルと許可されたリソースにマップする必要があります。ワークスペースのアクセス許可と適切にスコープが設定された埋め込みトークンは、アクセスを制御します。プロファイルは Microsoft Entra の独立した ID エンティティではなく、親サービスプリンシパルは作成したプロファイルを通じて動作できます。

ソリューションでMicrosoft Entraガバナンス、独立したサインイン監視、対象となるワークロード ID の条件付きアクセスポリシー、ダウンストリームサービス ID、または Fabric REST API アクセスが必要な場合は、専用のサービスプリンシパルを検討してください。また、プロファイルから親への結合または API のみの管理によって運用上の困難が生じる場合にも、代替手段となります。プロファイルが要件を満たしている場合は、引き続き使用できます。

専用のサービスプリンシパルを使用すると、顧客のアクセス許可と認証を個別に管理できます。保存されている証明書を使用する場合は、顧客ごとに個別に更新できます。ただし、認証情報の漏えいやランタイム侵害の影響は、ランタイムが使用できる顧客の認証情報またはフェデレーション信頼関係によって異なります。どちらのアーキテクチャでも、顧客間の分離は自動的には保証されません。

専用 ID を管理すると、ディレクトリオブジェクトの制限とライフサイクル作業が発生します。これらのトレードオフを評価し、移行を選択した場合はサービスプリンシパルプロファイルをサービスプリンシパルに置き換えるに従ってください。埋め込みトークンを生成するときに、エンドユーザーに表示するデータの構成をバックエンドで保持します。 ID情報、ワークスペース、またはコンテンツを選択する前に、顧客メンバーシップを検証します。

1 つのレポート、複数のセマンティックモデル

一般に、テナントごとに 1 つのレポートと 1 つのセマンティックモデルがあります。数百のレポートがある場合は、セマンティックモデルも数百になります。場合によっては、レポート形式は 1 つで、セマンティックモデルが異なる (たとえば、パラメーターや接続の詳細が異なる) ことがあります。新しいバージョンのレポートを作成するたびに、すべてのテナントのすべてのレポートを更新する必要があります。このプロセスは自動化できますが、レポートのコピーが 1 つしかない場合は管理が簡単です。埋め込むレポートを含むワークスペースを作成します。セッションランタイム中、レポートをテナント固有のセマンティックモデルにバインドします。詳細については、動的バインドに関する記事をご覧ください。

コンテンツのカスタマイズと作成

コンテンツを作成するときは、だれに編集するアクセス許可を与えるかを慎重に検討してください。各テナントで複数のユーザーに編集を許可すると、セマンティックモデルの制限を超えやすくなります。ユーザーに編集機能を提供することを決定した場合は、そのコンテンツ生成を注意深く監視し、必要に応じてスケールアップします。同じ理由から、この機能は、各ユーザーがレポートを少し変更して自分用に保存できる、コンテンツのカスタマイズには使用しないことをお勧めします。 ISV アプリケーションでコンテンツのカスタマイズが許可されている場合は、ユーザー固有のコンテンツに対してワークスペースの保持ポリシーを導入することを検討してください。リテンションポリシーを使用すると、ユーザーが新しい場所に移動したり、退社したり、プラットフォームの使用を停止したりしたときに、コンテンツを簡単に削除できます。

システムマネージド ID

サービスプリンシパルの代わりに、ユーザー割り当てまたはシステム割り当てのマネージド ID を使用してプロファイルを作成できます。マネージド ID により、シークレットと証明書の必要性が軽減されます。

注

プロファイルを作成して使用するマネージド ID では、これらのプロファイルをMicrosoft Entra ID に変換したり、Fabric REST API での使用を有効にしたりすることはありません。この条件は、マネージド ID とフェデレーション資格情報を使用して顧客専用のサービスプリンシパルとして認証する場合とは異なります。「サービスプリンシパルプロファイルをサービスプリンシパルに置き換える」を参照してください。

システムマネージド ID を使用する場合は、次の理由から、注意が必要です。

システム割り当てマネージド ID が誤ってオフになった場合、プロファイルにアクセスできなくなります。この状況は、サービスプリンシパルを削除した場合と似ています。
システム割り当てマネージド ID は、Azure (Web アプリ) のリソースに接続されています。リソースを削除すると、ID も削除されます。
複数のリソース (異なるリージョン内の異なる Web アプリ) を使用すると、複数の ID を個別に管理する必要があります (各 ID には独自のプロファイルがあります)。

上記の考慮事項により、ユーザー割り当てマネージド ID を使用することをお勧めします。

例

Power BI と App-Owns-Data 埋め込みでサービスプリンシパルプロファイルを使ってマルチテナント環境を管理する方法の例については、Power BI Dev Camp (サードパーティサイト) からアプリ所有データマルチテナントリポジトリをダウンロードしてください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-10-30