配置パイプラインのプロセス
配置プロセスを使用すると、配置パイプライン内のあるステージのコンテンツを別のステージに (通常は開発からテスト、テストから運用に) クローンすることができます。
デプロイ中に、Microsoft Fabric は現在のステージのコンテンツをターゲットのステージにコピーします。 コピーされたアイテム間の接続は、コピー プロセス中は保持されます。 Fabric ではまた、構成されているデプロイ ルールをターゲット ステージ内の更新されたコンテンツにも適用します。 デプロイするアイテムの数によっては、コンテンツのデプロイに時間がかかる場合があります。 この間、ポータルで他のページに移動できますが、ターゲット ステージのコンテンツを使用することはできません。
デプロイ パイプライン REST API を使用して、プログラムでコンテンツをデプロイすることもできます。 このプロセスの詳細については、「API と DevOps を使用してデプロイ パイプラインを自動化する」を参照してください。
空のステージにコンテンツをデプロイする
空のステージにコンテンツをデプロイすると、デプロイ先のステージの容量で新しいワークスペースが作成されます。 元のワークスペースのレポート、ダッシュボード、セマンティック モデル内のすべてのメタデータが、デプロイ先のステージの新しいワークスペースにコピーされます。
あるステージから別のステージにコンテンツをデプロイするには、いくつかの方法があります。 すべてのコンテンツを配置することも、配置するアイテムを選択することもできます。
コンテンツは、配置パイプラインの後の方のステージから前の方のステージに、逆方向に配置することもできます。
デプロイが完了したら、新しくコピーしたコンテンツを使用できるようにセマンティック モデルを更新します。 データがステージ間でコピーされないため、セマンティック モデルの更新が必要です。 配置プロセス中にどのアイテムのプロパティがコピーされ、どのアイテムのプロパティがコピーされないかを理解するには、「配置中にコピーされるアイテムのプロパティ」のセクションを参照してください。
ワークスペースの作成
初めてコンテンツをデプロイするとき、デプロイ パイプラインによってアクセス許可があるかどうかが確認されます。
アクセス許可がある場合は、ワークスペースのコンテンツがデプロイ先のステージにコピーされ、そのステージの新しいワークスペースが容量に作成されます。
アクセス許可がない場合は、ワークスペースが作成されますが、コンテンツはコピーされません。 容量管理者にワークスペースを容量に追加するように依頼するか、容量に対する割り当てアクセス許可を要求できます。 その後、ワークスペースが容量に割り当てられたら、このワークスペースにコンテンツを配置できます。
Premium Per User (PPU) を使用している場合は、ワークスペースがその PPU に自動的に関連付けられます。 このような場合、アクセス許可は必要ありません。 ただし、PPU を使用してワークスペースを作成する場合、それにアクセスできるのは他の PPU ユーザーのみです。 また、このようなワークスペースで作成されたコンテンツを使用できるのは、PPU ユーザーのみです。
デプロイするユーザーは、複製されたセマンティック モデルの所有者になり、新しいワークスペースの唯一の管理者になります。
既存のワークスペースへのコンテンツの配置
動作中の運用パイプラインのコンテンツを、既存のワークスペースがあるステージに配置する手順は、次のとおりです。
既存のコンテンツに追加する形式で新しいコンテンツを配置します。
既存のコンテンツを一部置き換える形式で更新されたコンテンツを配置する。
デプロイ プロセス
現在のステージからターゲット ステージにコンテンツがコピーされると、Fabric によってターゲット ステージの既存コンテンツが特定され、上書きされます。 どのコンテンツアイテムを上書きする必要があるかを特定するために、配置パイプラインは親アイテムとそのクローンの間の接続を使用します。 この接続は、新しいコンテンツの作成時に保持されます。 上書き操作では、アイテムの "コンテンツ" のみが上書きされます。 アイテムの ID、URL、およびアクセス許可は変更されません。
ターゲット ステージでは、コピーされないアイテムのプロパティは、配置前の状態のままです。 新しいコンテンツと新しいアイテムが、現在のステージからターゲット ステージにコピーされます。
自動バインド
Fabric でアイテムが接続されている場合、あるアイテムが別のものに依存します。 たとえば、レポートは、接続されているセマンティック モデルに常に依存します。 セマンティック モデルは、別のセマンティック モデルに依存でき、それに依存するいくつかのレポートに接続することもできます。 2 つのアイテム間に接続がある場合、デプロイ パイプラインは常にこの接続を維持しようとします。
配置時に、配置パイプラインによって依存関係がチェックされます。 この配置は、配置されるアイテムが依存するデータを提供するアイテムの場所に応じて、成功または失敗します。
リンクされたアイテムがターゲット ステージに存在する - デプロイ パイプラインによって、デプロイされるアイテムが、デプロイされたステージで依存するアイテムに自動的に接続 (自動バインド) されます。 たとえば、改ページ対応レポートを開発からテストにデプロイし、そのレポートが以前にテスト ステージにデプロイされたセマンティック モデルに接続されている場合、そのレポートはそのセマンティック モデルに自動的に接続されます。
リンクされたアイテムがターゲット ステージに存在しない - アイテムが別のアイテムに依存していて、データを提供するアイテムがデプロイされておらず、ターゲット ステージに存在しない場合、デプロイ パイプラインによるデプロイは失敗します。 たとえば、レポートを開発からテストにデプロイし、テスト ステージにそのセマンティック モデルが含まれていない場合、デプロイは失敗します。 依存アイテムがデプロイされていないためにデプロイが失敗しないようにするには、 [関連アイテムの選択] ボタンを使用します。 [関連アイテムの選択] を使用すると、デプロイしようとしているアイテムに依存関係を提供する関連アイテムが、すべて自動的に選択されます。
自動バインドは、展開パイプラインによってサポートされ、Fabric 内に存在するアイテムでのみ機能します。 アイテムの依存関係を表示するには、アイテムの [その他のオプション] メニューから [系列の表示] を選択します。
![アイテムの [その他のオプション] メニューの [View lineage]\(系列の表示\) オプションのスクリーンショット。](media/understand-the-deployment-process/view-lineage.png)
パイプライン間での自動バインド
デプロイ パイプラインは、同じパイプラインのステージにある場合、パイプライン間で接続されているアイテムに自動的にバインドされます。 このようなアイテムを配置すると、配置パイプラインでは、配置されたアイテムと、他のパイプラインで接続されているアイテムとの間に新しい接続の確立が試行されます。 たとえば、パイプライン B のテスト ステージでセマンティック モデルに接続されているパイプライン A のテスト ステージにレポートがある場合、デプロイ パイプラインはこの接続を認識します。
パイプライン間の自動バインドのしくみを示す図の例を次に示します。
パイプライン A の開発ステージにはセマンティック モデルがあります。
パイプライン B の開発ステージにはレポートもあります。
パイプライン B のレポートは、パイプライン A のセマンティック モデルに接続されます。レポートはこのセマンティック モデルに依存します。
パイプライン B で、開発ステージからテスト ステージにレポートを配置します。
パイプライン A のテスト ステージに依存するセマンティック モデルのコピーがあるかどうかに応じて、デプロイが成功または失敗します。
パイプライン Aのテスト ステージでレポートが依存するセマンティック モデルのコピーがある場合:
デプロイは成功し、展開パイプラインはパイプライン B のテスト ステージのレポートを、パイプライン A のテスト ステージのセマンティック モデルに接続 (自動バインド) します。
パイプライン Aのテスト ステージでレポートが依存するセマンティック モデルのコピーがない場合:
展開パイプラインは、パイプライン B のテスト ステージのレポートを、パイプライン A のテスト ステージでレポートが依存するセマンティック モデルに接続 (自動バインド) できないため、デプロイは失敗します。
自動バインドの使用を避ける
場合によっては、自動バインドを使用しない方がいい場合があります。 たとえば、組織のセマンティック モデルを開発するためのパイプラインと、レポートを作成するためのパイプラインが別である場合などです。 この場合、すべてのレポートを、所属するパイプラインの実稼働ステージのセマンティック モデルに常に接続する必要があります。 これを実現するには、自動バインド機能を使用しないようにします。
自動バインドを使用しないようにするには、次の 3 つの方法を使用できます。
対応するステージにアイテムを接続しない。 アイテムが同じステージで接続されていないと、配置パイプラインは元の接続を保持します。 たとえば、パイプライン B の開発ステージにレポートがあり、それがパイプライン A の運用ステージのセマンティック モデルに接続されている場合などです。パイプライン B のテスト ステージにレポートをデプロイしても、パイプライン A の運用ステージのセマンティック モデルに接続されたままです。
パラメーター ルールを定義する。 このオプションは、レポートでは使用できません。 これは、セマンティック モデルとデータフローでのみ使用できます。
レポート、ダッシュボード、タイルを、パイプラインに接続されていないプロキシ セマンティック モデルまたはデータフローに接続します。
自動バインドとパラメーター
パラメータを使用して、セマンティック モデルまたはデータフローと、それらが依存するアイテムとの間の接続を制御できます。 パラメータで接続が制御される場合、セマンティック モデルまたはデータフローの ID、またはワークスペース ID に適用されるパラメータが接続に含まれている場合でも、デプロイ後の自動バインドは行われません。 このような場合は、パラメーターの値を変更するか、パラメーター ルールを使うことによって、配置後にアイテムをバインドし直す必要があります。
Note
パラメーター ルールを使ってアイテムをバインドし直す場合は、パラメーターが Text型である必要があります。
データの更新中
セマンティック モデルやデータフローなど、ターゲット アイテム内のデータは可能な限り保持されます。 データを保持するアイテムに変更がない場合、データはデプロイ前と同じまま保持されます。
多くの場合、テーブルの追加や削除などの小さな変更では、Fabric によって元のデータが保持されます。 スキーマの破壊的変更、またはデータ ソース接続の変更の場合は、完全更新が必要です。
既存のワークスペースを持つステージへの配置の要件
ターゲットとソース両方の展開ワークスペースの共同作成者であるすべてのライセンス ユーザーは、容量に存在するコンテンツを既存のワークスペースのあるステージにデプロイできます。 詳細については、「アクセス許可」のセクションを参照してください。
デプロイ パイプライン内のフォルダー (プレビュー)
フォルダー を使用すると、ユーザーは使い慣れた方法でワークスペースアイテムを効率的に整理および管理できます。 フォルダーを含むコンテンツを別のステージにデプロイすると、適用されたアイテムのフォルダー階層が自動的に適用されます。
フォルダー表現
デプロイはアイテムのみであるため、ワークスペースのコンテンツは、アイテムのフラット な一覧としてデプロイ パイプラインに表示されます。 アイテムの完全なパスは、リスト上の名前の上にマウス ポインターを置くと表示されます。 デプロイ パイプラインでは、フォルダーはアイテムの名前の一部と見なされます (アイテム名には完全なパスが含まれます)。 アイテムがデプロイされると、パスが変更された後 (たとえば、フォルダー A からフォルダー B に移動された場合)、デプロイ パイプラインは、デプロイ時にペアのアイテムにこの変更を適用します。ペアのアイテムもフォルダー B に移動されます。デプロイ先のステージにフォルダー B が存在しない場合は、最初にそのワークスペースに作成されます。 フォルダーは、ワークスペース ページでのみ表示および管理できます。
別のフォルダーに移動されたアイテムを識別する
フォルダーはアイテムの名前の一部と見なされるため、ワークスペース内の別のフォルダーに移動されたアイテムは、[デプロイ パイプライン] ページで [比較モードで異なる] として識別されます。 さらに、スキーマの変更がない限り、スキーマの変更を示す変更レビュー ウィンドウを開くラベルの横にあるオプションは無効になります。 その上にマウス ポインターを置くと、変更が設定の変更 (名前の変更など) であることを示すメモが表示されます。 これは、ソース ステージ上のペアのアイテムと比較して、変更がまだデプロイされていないためです。
個々のフォルダーをデプロイ パイプラインに手動でデプロイすることはできません。 それらのデプロイは、少なくとも 1 つのアイテムがデプロイされると自動的にトリガーされます。
ペアになっているアイテムのフォルダー階層は、デプロイ時にのみ更新されます。 割り当て中、ペアリング プロセスの後、ペアになっているアイテムの階層はまだ更新されません。
フォルダーは、そのアイテムのいずれかがデプロイされている場合にのみデプロイされるため、空のフォルダーをデプロイすることはできません。
フォルダー内の複数のアイテムから 1 つのアイテムをデプロイすると、アイテム自体がデプロイされていない場合でも、ターゲット ステージにデプロイされないアイテムの構造も更新されます。
配置中にコピーされるアイテムのプロパティ
サポートされているアイテムのリストについては、「デプロイメント パイプラインでサポートされているアイテム」を参照してください。
配置時に、以下のアイテムのプロパティがコピーされ、ターゲット ステージでアイテムのプロパティが上書きされます。
データ ソース (配置ルールがサポートされます)
パラメーター (配置ルールがサポートされます)
レポート ビジュアル
レポート ページ
ダッシュボードのタイル
モデルのメタデータ
アイテムのリレーションシップ
秘密度ラベルは、次の条件のいずれかが満たされた場合に "のみ" コピーされます。 これらの条件が満たされていない場合、デプロイ中に秘密度ラベルはコピーされません。
新しいアイテムが配置されるか、既存のアイテムが空のステージに配置されます。
Note
テナントでデフォルトのラベル付けが有効で、デフォルトのラベルが有効な状態で、デプロイされているアイテムがセマンティック モデルまたはデータフローであると、ラベルに保護がある場合にのみラベルはソースアイテムからコピーされます。 ラベルが保護されていない場合は、新しく作成されたターゲット セマンティック モデルまたはデータフローにデフォルトのラベルが適用されます。
ソースアイテムには保護付きのラベルがあるが、ターゲットアイテムにはない。 この場合、ポップアップ ウィンドウがターゲットの機密ラベルをオーバーライドするための同意を求めます。
コピーされないアイテムのプロパティ
以下のアイテムのプロパティは、配置中にコピーされません。
データ - データはコピーされません。 メタデータのみコピーされます
URL
ID
アクセス許可 - ワークスペースまたは特定のアイテムに対するもの
ワークスペースの設定 - 各ステージには独自のワークスペースがあります
アプリのコンテンツと設定: アプリを更新する場合、Power BI アプリのコンテンツの更新に関する説明を参照してください。
次のセマンティック モデルのプロパティも、デプロイ時にコピーされません。
ロール割り当て
スケジュールの更新
データ ソース資格情報
クエリ キャッシュの設定 (容量から継承可能)
保証の設定
サポートされているセマンティック モデルの機能
デプロイ パイプラインでは、多くのセマンティック モデル機能がサポートされています。 このセクションでは、デプロイ パイプラインのエクスペリエンスを拡張できる 2 つのセマンティック モデル機能を取り上げます。
増分更新
デプロイ パイプラインでは、大規模なセマンティック モデルの高速で信頼性の高い更新をより少ない消費で行う機能である、増分更新がサポートされています。
デプロイ パイプラインを使用すると、データとパーティションの両方を保持しながら、増分更新によりセマンティック モデルを更新できます。 セマンティック モデルをデプロイすると、ポリシーが一緒にコピーされます。
データフローで増分更新がどのように動作するかを理解するには、「データフロー ルールを使用した後、データフローに接続されている 2 つのデータ ソースが表示されるのはなぜですか?」を参照してください
Note
増分更新の設定は Gen 1 ではコピーされません。
パイプラインで増分更新をアクティブにする
増分更新を有効にするには、Power BI Desktop で増分更新を構成し、セマンティック モデルをパブリッシュします。 発行した後、増分更新ポリシーはパイプライン全体で類似しており、Power BI Desktop でのみ作成できます。
増分更新を使用してパイプラインを構成した後は、次のフローに従うことをお勧めします。
Power BI Desktop で .pbix ファイルに変更を加えます。 待機時間が長くならないようにするために、データのサンプルを使用して変更を行うことができます。
.pbix ファイルを最初の (通常は "開発") ステージにアップロードします。
コンテンツを次のステージにデプロイします。 デプロイ後は、行った変更は使用しているセマンティック モデル全体に適用されます。
各ステージで行った変更を確認し、検証した後で、最終ステージに到達するまで次のステージにデプロイします。
使用例
次に、増分更新を展開パイプラインと統合できる方法の例をいくつか示します。
新しいパイプラインを作成し、増分更新が有効になっているセマンティック モデルを使用してワークスペースに接続します。
開発ワークスペースに既に存在するセマンティック モデルで増分更新を有効にします。
増分更新を使用するセマンティック モデルがある運用ワークスペースからパイプラインを作成します。 たとえば、ワークスペースを新しいパイプラインの "運用" ステージに割り当て、逆方向のデプロイを使用して "テスト" ステージにデプロイし、"開発" ステージにデプロイします。
既存のパイプラインの一部であるワークスペースに増分更新を使用するセマンティック モデルを発行します。
増分更新の制限事項
増分更新の場合、デプロイ パイプラインでは、拡張セマンティック モデル メタデータを使用するセマンティック モデルのみがサポートされます。 Power BI Desktop で作成または変更されたすべてのセマンティック モデルは、拡張セマンティック モデル メタデータを自動的に実装します。
増分更新が有効になっているアクティブなパイプラインにセマンティック モデルを再パブリッシュするとき、次の変更を行うと、データ損失の可能性があるためデプロイ エラーが発生します。
増分更新を使用しないセマンティック モデルを再パブリッシュして、増分更新が有効になっているセマンティック モデルを置き換える。
増分更新が有効になっているテーブルの名前を変更する。
増分更新が有効になっているテーブルの非計算列の名前を変更する。
列の追加、列の削除、計算列の名前の変更など、その他の変更は許可されています。 ただし、変更によって表示内容が影響を受ける場合は、更新した後に変更が表示されます。
複合モデル
複合モデル使用すると、複数のデータ接続を含むレポートを設定できます。
複合モデル機能を使用して、Fabric セマンティック モデルを Azure Analysis サービス などの外部セマンティック モデルに接続できます。 詳細については、「Fabric セマンティック モデルおよび Azure Analysis サービス 用の DirectQuery の使用」を参照してください。
デプロイ パイプラインでは、複合モデルを使用して、パイプラインの外部にある別のFabric セマンティック モデルにセマンティック モデルを接続できます。
自動集計
自動集計 は、ユーザーが定義した集計を基に構築され、レポート クエリのパフォーマンスが最高になるように、機械学習を使用して DirectQuery のセマンティック モデルを継続的に最適化します。
自動集計はデプロイ後に各セマンティック モデルによって保持されます。 デプロイ パイプラインによってセマンティック モデルの自動集計が変更されることはありません。 つまり、自動集計を含むセマンティック モデルをデプロイする場合、ターゲット ステージの自動集計はそのまま残り、ソース ステージからデプロイされた自動集計によって上書きされることはありません。
自動集計を有効にするには、自動集計の構成に関する記事の手順のようにします。
ハイブリッド テーブル
ハイブリッド テーブルは、インポートと直接クエリの両方のパーティションを持つことができる増分更新を備えたテーブルです。 クリーンなデプロイでは、更新ポリシーとハイブリッド テーブルのパーティションの両方がコピーされます。 ハイブリッド テーブル パーティションが既に存在するパイプライン ステージにデプロイすると、更新ポリシーのみがコピーされます。 パーティションを更新するには、テーブルを更新します。
Power BI アプリのコンテンツを更新する
Power BI アプリは、コンテンツを無料のFabric コンシューマーに配布するための推奨される方法です。 Power BI アプリのコンテンツを、デプロイ パイプラインを使用して更新できます。これにより、アプリのライフサイクルの制御と柔軟性が向上します。
配置パイプラインのステージごとにアプリを作成し、各更新部分をエンド ユーザーの観点からテストできるようにします。 特定のパイプライン ステージでアプリを発行または表示するには、ワークスペース カードの発行または表示ボタンを使用します。
運用ステージでは、右下隅にあるメイン アクション ボタンをクリックすると、Fabric のアプリの更新ページが開き、アプリ ユーザーがコンテンツを更新できるようになります。
重要
デプロイ プロセスには、アプリのコンテンツや設定の更新は含まれません。 コンテンツまたは設定に変更を適用するには、必要なパイプライン ステージでアプリを手動で更新する必要があります。
アクセス許可
パイプラインと、それに割り当てられているワークスペースに対するアクセス許可が必要です。 パイプラインのアクセス許可とワークスペースのアクセス許可は、個別に付与および管理されます。
パイプラインにはアクセス許可 (''管理者'') が 1 つだけあり、これはパイプラインの共有、編集、削除に必要です。
ワークスペースには、ロールとも呼ばれるさまざまなアクセス許可があります。 ワークスペース ロールにより、パイプライン内のワークスペースへのアクセス レベルが決まります。
展開パイプラインは、パイプライン管理者として Microsoft 365 グループをサポートしていません。
パイプライン内のステージ間でデプロイするには、パイプライン管理者であり、関連するステージに割り当てられているワークスペースの共同作成者、メンバーまたは管理者である必要があります。 たとえば、ワークスペース ロールが割り当てられていないパイプライン管理者は、パイプラインを表示したり、他のユーザーと共有したりできます。 しかし、このユーザーは、パイプラインまたはサービスでワークスペースのコンテンツを表示することはできず、デプロイを実行できません。
アクセス許可の表
このセクションでは、デプロイ パイプラインのアクセス許可について説明します。 このセクションに記載されているアクセス許可は、他のFabric 機能では異なる適用になる場合があります。
デプロイ パイプラインの最も低いアクセス許可は ''パイプライン管理者'' であり、すべてのデプロイ パイプライン操作に必要です。
| ユーザー | パイプラインのアクセス許可 | 説明 |
|---|---|---|
| パイプライン管理者 |
|
パイプライン アクセス権では、ワークスペースのコンテンツに対する表示やアクションの実行のためのアクセス許可は付与されません。 |
| ワークスペース ビューアー (およびパイプライン管理者) |
|
ビルド権限のない視聴者ロールが割り当てられたワークスペース メンバーは、セマンティック モデルにアクセスしたり、ワークスペースのコンテンツを編集したりすることはできません。 |
| ワークスペース共同作成者 (およびパイプライン管理者) |
|
|
| ワークスペース メンバー (およびパイプライン管理者) |
|
"セマンティック モデルのセキュリティ" セクションにある "再パブリッシュのブロックとパッケージ更新の無効化" 設定が有効になっている場合、セマンティック モデルの所有者のみがセマンティック モデルを更新できます。 |
| ワークスペース管理者 (およびパイプライン管理者) |
|
付与されたアクセス許可
Power BI アイテムをデプロイするとき、デプロイされたアイテムの所有権が変わることがあります。 次の表を確認し、各アイテムをデプロイできるユーザーと、そのデプロイがアイテムの所有権に与える影響について理解してください。
| Fabric アイテム | 既存のアイテムをデプロイするために必要なアクセス許可 | 初回デプロイ後のアイテムの所有権 | アイテムを使用したステージへのデプロイ後のアイテムの所有権 |
|---|---|---|---|
| セマンティック モデル | ワークスペース メンバー | デプロイを行ったユーザーが所有者になります | 変更なし |
| データフロー | データフロー所有者 | デプロイを行ったユーザーが所有者になります | 変更なし |
| データマート | データマート所有者 | デプロイを行ったユーザーが所有者になります | 変更なし |
| ページ分割されたレポート | ワークスペース メンバー | デプロイを行ったユーザーが所有者になります | デプロイを行ったユーザーが所有者になります |
一般的なアクションに必要なアクセス許可
以下の表には、一般的なデプロイ パイプライン アクションに必要なアクセス許可が一覧表示されています。 特に指定がない限り、アクションごとに一覧表示されているすべてのアクセス許可が必要です。
| アクション | 必要なアクセス許可 |
|---|---|
| 組織内のパイプラインの一覧を表示する | ライセンス不要 (無料ユーザー) |
| パイプラインを作成する | 次のいずれかのライセンスを持つユーザー:
|
| パイプラインを削除する | パイプライン管理者 |
| パイプライン ユーザーを追加または削除する | パイプライン管理者 |
| ワークスペースをステージに割り当てる |
|
| ワークスペースのステージへの割り当てを解除する | 次のいずれか:
|
| 空のステージにデプロイする |
|
| アイテムを次のステージにデプロイする |
|
| ルールを表示または設定する |
|
| パイプライン設定を管理する | パイプライン管理者 |
| パイプライン ステージを表示する |
|
| ステージ内のアイテムの一覧を表示する | パイプライン管理者 |
| 2 つのステージを比較する |
|
| デプロイ履歴を表示する | パイプライン管理者 |
考慮事項と制限事項
このセクションでは、配置パイプラインでのほとんどの制限を列挙します。
- ワークスペースは、Fabric 容量に存在する必要があります。
- 1 回のデプロイでデプロイできるアイテムの最大数は、300 個です。
- 配置後の .pbix ファイルのダウンロードはサポートされていません。
- Microsoft 365 グループは、パイプライン管理者としてサポートされていません。
- Power BI アイテムを初めてデプロイするときに、ターゲット ステージ内の別のアイテムの種類が類似しており (たとえば、両方のファイルがレポートの場合)、同じ名前の場合、デプロイは失敗します。
- ワークスペースの制限事項の一覧については、「ワークスペースの割り当ての制限事項」を参照してください。
- サポートされているアイテムの一覧については、「サポートされているアイテム」を参照してください。 一覧にないアイテムはサポートされていません。
- いずれかのアイテムが循環依存関係または自己依存関係を持つ場合 (たとえば、アイテム A がアイテム B を参照し、アイテム B がアイテム A を参照)、デプロイは失敗します。
- 別の容量のリージョンのワークスペースにデプロイできるのは、Power BI アイテムのみです。 別の容量のリージョンにあるワークスペースに 他のFabric アイテムをデプロイすることはできません。
セマンティック モデル の制限
リアルタイム データ接続を使用するデータセットを配置することはできません。
バリエーションまたは自動の日付/時刻テーブルが使用される、DirectQuery または複合の接続モードのセマンティック モデルはサポートされていません。 詳細については、バリエーションまたはカレンダー テーブルを使用する、DirectQuery または複合の接続モードのデータセットがある場合の対処法に関する記事を参照してください。
配置中に、ターゲット セマンティック モデルでライブ接続が使用される場合は、ソース セマンティック モデルでもこの接続モードを使用する必要があります。
デプロイ後に (デプロイされているステージから) セマンティック モデルをダウンロードすることはサポートされていません。
配置ルールの制限事項の一覧については、「配置ルールの制限事項」を参照してください。
ネイティブ クエリと DirectQuery を一緒に使用するセマンティック モデルではデプロイはサポートされておらず 、DirectQuery データ ソースでは自動バインドが実行されます。
Direct Lake セマンティック モデルが配置されると、ターゲット ステージの項目に自動的にバインドされることはありません。 たとえば、レイクハウスが DirectLake セマンティック モデルのソースであり、両方とも次のステージに配置されている場合、ターゲット ステージの DirectLake セマンティック モデルはソース ステージのレイクハウスにバインドされます。 datasourece ルールを使用して、ターゲット ステージの項目にバインドします。 他の種類のセマンティック モデルは、ターゲット ステージのペアの項目に自動的にバインドされます。
データフローの制限
増分更新の設定は Gen 1 ではコピーされません。
データフローを空のステージにデプロイすると、デプロイ パイプラインによって新しいワークスペースが作成され、データフローのストレージがFabric の BLOB ストレージに設定されます。 ソース ワークスペースが Azure Data Lake Storage Gen2 (ADLS Gen2) を使用するように構成されている場合でも、BLOB ストレージが使用されます。
サービス プリンシパルは、データフローではサポートされていません。
Common Data Model (CDM) のデプロイはサポートされていません。
データフローに影響を与える配置パイプライン ルールの制限事項については、「配置ルールの制限事項」を参照してください。
デプロイ中にデータフローが更新されている場合、デプロイは失敗します。
データフローの更新中にステージを比較した場合、その結果は予測できません。
データマートの制限事項
秘密度ラベルを持つデータマートを配置することはできません。
データマートをデプロイするには、データマートの所有者である必要があります。