既定の環境からのアプリとフローを移行する

[アーティクル]
09/07/2023

このホワイトペーパーでは、組織と管理者が既定の環境からアプリとフローの移行を計画する方法について説明します。

著者: Ravi Chada (Microsoft)、Rui Santos (Microsoft)

注意

ブラウザーで印刷を選択して PDF として保存 を選択することで、このホワイトペーパーを保存または印刷できます。

既定の環境

テナントごとに 1 つの既定の環境が作成され、そのテナント内のすべてのユーザーがアクセスできます。既定の環境は、Microsoft Entra テナントの既定の地域に最も近い地域に作成され、次のように名前が付けられます: [Microsoft Entra テナント名] (既定)。新しいユーザーが Power Apps または Power Automate にサインアップするたびに、ユーザーは既定の環境の作成者ロールに自動的に追加されます。既定の環境の環境管理ロールに自動的に追加されるユーザーはいません。

既定の環境を削除したり、既定の環境を手動でバックアップしたりすることはできません。システムバックアップは継続的に実行されます。既定の環境は、1 TB のストレージ容量に制限されています。既定の環境には以下の機能があります:

3 GB Dataverse データベース容量
3 GB Dataverse ファイル容量
1 GB Dataverse ログ容量

新しい環境を作成する前に実行される容量チェックでは、新しい環境を作成するのに十分な容量があるかどうかを計算するときに、既定の環境の含まれているストレージ容量が除外されます。より多くのデータを格納するために、運用環境を作成できます。

既定の環境では、組織の従業員は Microsoft 365 ライセンスによりアプリとクラウドフローを作成できます。既定の環境は、これらの従業員がアプリとフローの構築を開始する最初のプレイグラウンドスタジオになります。既定の環境から環境作成者の役割を削除することはできないため、作成者は個人の生産性向上アプリとフローを構築し、他の人が利益を得られるようにチーム内で共有し始めます。ほとんどの組織では、既定の環境名を パーソナルプロダクティビティ に変更する場合が一般的です。

管理者は、多くのアプリとフローが既定の環境で作成されていることを事後的に発見します。次のようなシナリオでは、アプリまたはフローが既定の環境にあることは適切ではない可能性があります。

アプリは、本番環境と同様の動作で多くのユーザーと共有されます。
アプリは機密データを含む Excel ブックを使用します。
SharePoint のリストをベースとするアプリは、挿入や更新といったデータインタラクションを多く受けています。
アプリまたはフローが、新しいデータ損失防止 (DLP) ポリシーで許可されていないコネクタを使用しています。
カスタムコネクタは、専用環境で保護されるのではなく、既定の環境で有効化および使用されます。

上記のシナリオは検討する価値があり、これらのアプリとフローを既定の環境から独自の開発者環境、または別の共有環境に移行し始める必要があることを示しています。その他に関係する要因としては、既定の環境に関連する制限があります。

監視するセンターオブエクセレンス (CoE) チーム Power Platform 制限に達すると対応する必要があり、既定の環境で実行されているアプリに悪影響を及ぼします。この制限は、管理者や CoE チームも定期的に行う必要がある可能性があります。大きく分けて 3 つの段階があります:

Power Platform オブジェクトの識別
Power Platform オブジェクトの移動
Power Platform オブジェクトをクリーンアップします

アプリとフローをエクスポートして新しい環境に移動するには、さまざまな方法があります。ソリューションは単一のファイルで、作成者が構築したほとんどすべてのものを Power Platform に含めることができ、それらを一緒に移動できます。キャンバスアプリとクラウドフローを直接エクスポートできます。

Power Platform オブジェクトはソリューションを認識できるように進化してきました。アプリとフローは既定でソリューションを認識できるようになりましたが、これには手動でアクティブ化する必要があります。作成者は、make.powerapps.com と make.powerautomate.com からアプリやフローを作成することができます。これらはソリューションを意識しないものとして分類され、個別にエクスポートすることも、ソリューションに追加することもできます。ソリューションを追加することで、作成者は環境変数と接続参照を利用して、環境全体にエンドポイントを構成および展開できます。

目標は、すべての Power Platform コンポーネントを 1 つのソリューションに追加し、複数のコンポーネントを 1 つのユニットとして環境間で簡単に移動できるようにすることです。

Power Platform オブジェクトの識別

最初のステップは、移動またはクリーンアップする必要があるアプリ、フロー、アセットを特定することです。 CoE スターターキットは、すべてのアプリとフローのインベントリを提供し、Power BI レポートは使用状況の確認に役立ちます。このステップは、アプリの使用状況を評価し、ラベル付けに役立ちます。演習を進める際には、別の環境に移行する必要があるアプリとフローを必ずタグ付けしてください。タグは、使用されるコネクタ、ユーザーの場所、ユーザーの部門などに基づいて作成できます。この記事では、データ損失防止 (DLP) の実践に基づいて、クリーニングまたは再配置する必要があるアイテムを認識する方法についても概説します。

Power Platform オブジェクトの移動

コンポーネントが別の環境に移動するようにタグ付けされている場合、アプリを移動するために使用できるオプションがあります。移動はインタラクティブなプロセスであり、ある程度のレベルの作成者の対話が必要です。アプリまたはフローを移動する複雑さのレベルは、アプリまたはフローの構築に使用されるコンポーネントが混在するにつれて増加します。

たとえば、6 つの画面があるアプリには、複数の画面に 10 個のボタンがあります。たとえば、これら 10 個のボタンがそれぞれ個別のフローを呼び出すと仮定します。データを修正したり、別のシステムとデータを統合したりするために、毎日トリガーされるフローもいくつかあります。また、自動化の一部として使用される AI Builder 画像処理モデルがあると仮定しましょう。このようなアプリを移動するには、すべてのコンポーネントをソリューションに追加し、接続参照を正しく調整して、完了を確認する前にテストする必要があります。

別のケースでは、Office 365 接続を使用するキャンバスアプリがあるとします。この場合、作成者はキャンバスアプリのみをソリューションに追加するだけで済みます。

Power Platform オブジェクトをクリーンアップします

コンポーネントがクリーンアップ用にタグ付けされている場合、主なオプションは 2 つあります。 1 つ目のオプションは直接削除することで、2 つ目のオプションはバックアップを作成した後に削除することです。後者のバックアップの場合、オブジェクトの移動と同時にステップが重複する可能性があります。

一例として、CoE チーム管理者は、ほとんどの作成者が学習目的でテストアプリとフローを作成していることに気づきました。その後、作成者はアプリとフローを放棄しますが、これは使用状況の指標を調べることで確認できます。もう 1 つの方法は、アプリを隔離することです。アプリについて誰も連絡を取らない場合、アプリを削除することもできます。

コミュニケーション戦略を維持することが重要な役割を果たします。管理者は次のようなコミュニケーションを計画する必要があります:

作成者が新しい環境でアプリを起動するときに許可する必要がある接続を確立します。
ターゲット環境からのアプリの新しい URL です。
適切な環境へのナビゲートします。

オブジェクトを再配置するこれらのソリューションのいくつかは、既製品であり、ユーザーに Microsoft 365 を超えるデータソースにわたってアプリケーションを作成し、実行する能力を提供するスタンドアロン Power Apps と Power Automate のライセンスが必要な場合があります。

戦略

アプリとフローを特定して既定の環境から移行するプロセス全体は、戦略に基づいている場合に成功する可能性が高くなります。考慮すべき戦略は複数あります。

DLP 戦略

データ損失防止 (DLP) ポリシーの機能によって、ユーザーが誤って組織データを漏洩しないための防御柵の役割を果たし、テナント内の情報セキュリティが保護されます。 DLP ポリシーは、環境ごとに有効にするコネクタ、および一緒に使用できるコネクタのルールを適用します。コネクタは、ビジネスデータのみ、ビジネスデータは許可されていません、またはブロック済のいずれかに分類されます。ビジネスデータのみのグループのコネクタは、同じアプリ内もしくはフロー内のそのグループの他のコネクタとのみ使用できます。少なくとも 1 つのポリシーを作成することをお勧めします。

DLP によるオブジェクトの識別

DLP ポリシーベースの識別は、アプリとフローのターゲット環境を定義する際に役立ちます。 DLP によってブロックされているコネクタ、またはビジネスコネクタと非ビジネスコネクタの混合を使用しているアプリやフローがあり、DLP のアクティブ化時に動作が停止する可能性があります。

CoE スターターキットの一部である DLP による潜在的なクリティカルオブジェクトのダウンタイムを防ぐために、DLP エディター (影響分析) ツール を見つけることができます。 DLP エディターの目的は、管理者が既存のポリシーの影響、またはポリシー変更の潜在的な影響を確認できるようにすることです。管理者は、影響を受けるアプリやフロー、新規または更新されたポリシーが適用された場合に無効になるリソースを確認できます。このアプリを使用すると、既存のポリシーの見直し、既存のポリシーの変更、およびメーカーに連絡してアプリやフローに最適なアクションを通知することでリスクを軽減できます。

既存の DLP ポリシーを更新して影響を確認します。 CoE スターターキットを使用したテナントの正常性の確立の記事に従って、DLP エディタの詳細情報を確認してください。

DLP 機能を有効にする前に、影響を受けるアプリとフローを特定し、作成者に警告できます。 DLP エディターは、影響を受けるすべてのアプリとフローのリストを電子メールアドレスに送信でき、オブジェクトの種類ごとに .csv ファイルが生成されます。

DLP エディターバージョン 2.0 を使用して、 影響分析 エリア、影響を受けるアプリとフローを CSV にエクスポートする を選択してください。

DLP エディタバージョン 2.0 を使用してください。

生成された各 csv ファイル (flow.csv および apps.csv) には、次に関する情報が含まれています:

アプリとフローの名前です。
アプリとフローの所有者です。
アプリとフローのオーナーメールです。
アプリとフローが使用するすべての接続です。
オブジェクトを識別するためのアプリとフローの ID です。
アプリとフローが配置されている環境 ID です。

接続には、アプリやフローが使用するすべての接続のリストが表示されます。問題の DLP の影響を受けるコネクタを正確に特定する必要がある場合は、現時点で自動化が必要です。私たちはツールでこの状況を変えることを検討しています。

接続を識別するための実装例:

Power Automate フローを作成します。
テナント DLP ポリシーの取得 コネクタを使用して、問題の DLP を指定します。
結果は、ビジネスデータと非ビジネスデータの 2 つの配列になります。例として、Twitter コネクタは次のコードを示します:
```
[
  {
    "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
    "name": "Twitter",
    "type": "Microsoft.PowerApps/apis"
  }
……
]
```
このリストから、csv アプリまたはフロー接続列の名前リストと一致するコネクタの名前にアクセスできます。
csv を Excel 形式に変換して OneDrive に配置することで、Power Automate から影響を受けたすべてのアプリとフローを読み取ることができます。接続とコネクタ名を比較するロジックに基づいて、どの接続が影響を受けるかを確認します。
どの接続が影響を及ぼしているかが一致したら、アプリまたはフロー ID、および DLP の影響を受けるコネクタを含む新しいリストを生成します。
以前の情報を使用して、将来の影響について作成者に通知します。アプリまたはフローを削除できる場合、または別の環境に移行する必要がある場合は、パワーカードを使用して作成者からフィードバックを収集できます。

分析に基づいて、影響を受けるフローが使用されていないと判断した場合は、フローを隔離し、別の環境に移動する方法を記載した電子メールを作成者に送信できます。これにより、DIY (DIY) 文化が奨励され、シャドー IT が排除されます。状況によっては、一部のオブジェクトを DLP から除外したい場合があります。たとえば、作成された新しいリソースにのみ特定の DLP を適用し、現在のリソースを除外することができます。 DLP リソースの免除の詳細については、 DLP リソースの免除を参照してください。

事実上、環境戦略は DLP を通じて定義され、既定の環境で開発されたアプリとフローの宛先を提供します。

環境戦略

環境およびその他のデータセキュリティ層の構成方法について戦略的に検討することで、組織全体で開発の生産性が高まり、一方でリソースのセキュリティ保護や効率的な管理も可能になります。環境のプロビジョニングとアクセスを管理し、その中のリソースを制御するための戦略は、次の点で重要です。

データとアクセスのセキュリティを保護する。
準拠した方法で既定の環境を管理します。
環境を必要な数だけ正しく管理し、容量が余ったり不足したりしないようにする。
健全なアプリケーションライフサイクル管理 (ALM) を促進し、実装します。
リソースを論理的に分類して整理する。
専用環境にアプリを配置し、運用環境にあるアプリを特定する操作 (およびヘルプデスク) をサポートする。
データが許容可能な地域に保存および送信されていることを確認する (パフォーマンスとコンプライアンスの理由による)。
開発中のアプリケーションの隔離を確保する。
サービスを利用するビジネスエンドユーザーまたはビジネスユニットに対する内部請求サービスの有効化。

自立して既存の ALM プロセスを導入できる確立された部門が必要です。このような場合、環境は分離を提供し、部門に基づいてリソースを編成します。それに基づいた戦略は、部門ごとに個別の環境を構築することで実現できます。これらの環境は、既定の環境のアプリとフローの宛先になります。

コミュニケーション戦略

移行プロセス中は効果的なコミュニケーションが非常に重要です。通信は移行プロセスのすべてのフェーズで行われます。明確なコミュニケーションは、関係者間の理解と協力を促進します。これにより、情報の流れがスムーズになり、関係者全員が移行計画、進捗状況、潜在的な課題について十分な情報を得ることができます。

移行とクリーンアップの取り組みの一環として、作成者、関係者、リーダーにとってプロセスがスムーズであることを確認してください。最適なコミュニケーション方法と、どの時点でコミュニケーションする必要があるかに関する戦略を策定します。これにより、目標に一貫性がもたらされ、関係者全員のコミュニケーションが容易になります。考慮すべきオプションには次のようなものがあります:

CoE スターターキットを資産トラッカーとして使用します。
カスタムクラウドフローを追加して、さまざまな段階で通知を送信します。
作成者とのコミュニケーションのために送信されるテンプレートメールを作成します。

留意すべき点は以下の通りです:

アプリの URL 変更。アプリのユーザーは、既定の環境でアプリのブックマークを更新する必要があります。
URL ベースの HTTP トリガーフローがある場合は、それが引き続き Webhook として機能するように、依存フローで更新する必要があります。
作成者とアプリユーザーの両方に対して、移行が完了したら接続を確立するための詳細な手順を提供します。ユーザーは、新しい環境から初めてアプリを起動するときに、接続の作成について心配する必要はありません。

コミュニケーションの設定を適切に開始するには、単一ユーザーの電子メールや配布リストに任せるよりも、拡張性が高く、ユーザーにとってよりリアルタイムなセルフサービスモデルが必要です。 SharePoint サイトを確立する予定がある場合は、内部 Microsoft Power Platform ハブの作成に使用できるテンプレートが用意されています。ハブは戦略とガイダンスについて学ぶための共通の場所となり、作成者は何を構築するか、どこに進むべきかについて正しい決定を下せるようになります。

CoE スターターには、非アクティブ通知コンポーネントのセットアップや開発者コンプライアンスコンポーネントのセットアップなどの既存のソリューションコンポーネントがいくつかあります。ぜひ活用していただきたいキットです。これらのコンポーネントには電子メールテンプレートが付属しており、目的や既定の環境から移行する必要に応じて複製できます。さらに、コミュニケーションサイトでいくつかの成功事例を記録しておくことも効果的です。

対象者

移行プロセスでは、通常、さまざまな対象者がコミュニケーションに関与します。最も典型的な主要な関係者とその役割は次のとおりです:

アプリ所有者: アプリ所有者は、特定のアプリケーションの開発、メンテナンス、および管理を担当する個人またはチームです。彼らはアプリケーションの機能、ワークフロー、構成について深い知識を持っています。アプリ所有者とのコミュニケーションは、アプリ固有の要件を理解し、フィードバックを収集し、懸念事項に対処し、アプリを新しい環境にスムーズに移行するために重要です。
アプリユーザー: アプリユーザーとは、タスクやワークフローを実行するためにアプリケーションを定期的に利用する個人です。彼らはさまざまなレベルの技術的専門知識やアプリケーションに精通している場合があります。アプリユーザーとのコミュニケーションは、移行について通知し、発生する可能性のある変更や中断に関する最新情報を提供し、シームレスな移行を確実にするためのトレーニングやサポートを提供し、日常業務への影響を最小限に抑えることができるため、重要です。
部門長またはマネージャー: 部門長またはマネージャーは、それぞれの部門の業務と戦略目標を監督するため、移行プロセスで重要な役割を果たします。移行のタイムライン、潜在的な影響、メリットについて知らせる必要があります。部門長とのコミュニケーションにより、部門長は必要なガイダンスを提供し、移行を部門の目標に合わせて調整し、チーム内でのスムーズな調整を行うことができます。
ITまたは技術チーム: ITまたは技術チームは、移行のインフラストラクチャ、システム、および全体的な技術面を担当します。彼らは、移行プロセスの計画、実行、サポートに関与しています。技術要件、依存関係、セキュリティに関する考慮事項、移行を成功させるために実装する必要があるインフラストラクチャや構成の変更について話し合うには、IT チームとのコミュニケーションが不可欠です。
セキュリティおよびコンプライアンスチーム: セキュリティおよびコンプライアンスチームは、移行中のデータセキュリティ、プライバシー、規制コンプライアンスを確保する上で重要な役割を果たします。彼らはガイダンスを提供し、機密情報を保護するための適切な措置が講じられていることを確認します。セキュリティおよびコンプライアンスチームとのコミュニケーションには、セキュリティ要件、暗号化プロトコル、アクセス制御、および移行プロセス全体にわたるコンプライアンス関連の考慮事項について話し合うことが含まれます。
経営幹部: Cレベルの幹部や上級管理職を含む経営幹部は、移行プロセスについて常に情報を得る必要があります。詳細な技術情報は必要ない可能性もありますが、プロジェクトの目的、進捗状況、組織への潜在的な影響を認識しておく必要があります。経営陣とのコミュニケーションは、経営陣のサポート、戦略的目標との整合性、移行のためのリソース割り当てを確実にするのに役立ちます。

対象者ごとに、特定のニーズ、懸念事項、技術的理解のレベルを考慮して、コミュニケーション戦略とメッセージを調整することが重要です。すべての関係者との明確かつタイムリーなコミュニケーションにより、コラボレーションが促進され、スムーズな調整が確保され、移行プロセス中の潜在的な課題が軽減されます。

ケイデンス

移行プロセス中の関係者とのコミュニケーションの頻度や頻度は、プロジェクトの特定のニーズやダイナミクスによって異なります。定期的かつ一貫したコミュニケーションを確立して、関係者に情報を提供し、懸念事項に対処し、移行全体を通じて連携を維持することが重要です。さまざまな関係者とのコミュニケーションのペースを決定するための考慮事項をいくつか示します:

アプリ所有者: 移行プロセス全体を通じてアプリ所有者と頻繁にコミュニケーションをとることが重要です。これには、移行の進行状況に関する定期的な更新、懸念事項への対処、必要に応じてアプリ所有者を意思決定に参加させることが含まれます。通信の頻度はアプリの複雑さと重要度によって異なりますが、定期的にチェックインし、問い合わせにタイムリーに応答することをお勧めします。
アプリユーザー: 定期的なコミュニケーションチャネルを通じてアプリユーザーと交流し、移行に関する情報を継続的に提供します。これには、お知らせ、電子メール、ニュースレター、さらには専用のトレーニングセッションやワークショップが含まれる必要があります。アプリユーザーとのコミュニケーションの頻度はさまざまですが、主要なマイルストーンで更新情報を提供し、ユーザーに影響を与える可能性のある変更や中断について通知し、プロセス全体を通じてサポートとガイダンスを提供することが重要です。
部門長およびマネージャー: 部門長およびマネージャーとのコミュニケーションは、各部門における移行の重要性に基づいて、定期的に、または必要に応じて行うことができます。全体的な進捗状況、タイムライン、チームへの影響に関する最新情報を定期的に提供します。
ITまたは技術チーム: 移行に関与するITチームおよび技術チームと定期的にコミュニケーションを取ります。これには、継続的なコラボレーション、技術的な質問や問題に関する最新情報の共有、必要な構成や変更の調整が含まれます。通常、計画と分析の段階では通信頻度が高くなります。実装段階では、定期的にタッチポイントやミーティングを開催して、スムーズな調整を確保します。

リソース

移行を成功させるには、リソースを効果的に管理することが重要です。移行中のリソース管理に関して考慮すべき重要な側面は次のとおりです:

リソースの特定: 移行前の準備、データ移行、テスト、展開、構成、移行後のサポートなどのタスクを担当する個人またはチームを含む、移行プロジェクトに必要なリソースを特定します。各役割に必要な具体的なスキル、専門知識、利用可能性を判断します。
リソースの割り当て: リソースのスキル、可用性、およびワークロード容量に基づいて、リソースをロールとタスクに割り当てます。ワークロードのバランスをとり、プロジェクトの期限を守るためにリソースの適切な割り当てを実現します。複数のプロジェクトにわたる共有リソースなど、リソースの割り当てに影響を与える可能性のある依存関係や制約を考慮します。
スキル開発とトレーニング: チーム内のスキルと知識のギャップを評価し、リソースが割り当てられたタスクに適切に対応できるように、必要なトレーニングやスキルアップの機会を提供します。これには、トレーニングセッション、ワークショップ、または関連リソースやドキュメントへのアクセスの提供が含まれる場合があります。
コミュニケーションとコラボレーション: 移行に関与するリソース間の効果的なコミュニケーションとコラボレーションを促進します。定期的なステータス更新、調整会議、知識の共有を奨励して、すべてのチームメンバーが連携し、情報を共有し、共通の目標に向かって協力できるようにします。
緊急時対応計画: 潜在的なリソースの制約やリスクを予測し、緊急時対応計画を策定します。予期せぬ欠勤やリソースの制限など、不測の事態を軽減するために、重要な役割のバックアップリソースを特定するか、クロストレーニングを実行します。
利害関係者の関与: アプリの所有者、部門長、経営陣などの利害関係者に、リソースの割り当てと、タイムラインや成果物への潜在的な影響について情報を提供します。リソースの最新情報、進捗レポート、リソース計画の調整を定期的に伝えて、期待を管理し、透明性を維持します。

オブジェクトの個別の移行

アプリとソリューションの区別は重要です。アプリのエクスポートとインポートは、そのオブジェクトにのみ影響します。ソリューションは、複数のアプリ、フロー、その他のオブジェクトを含めることができるコンテナーです。

キャンバスアプリのエクスポートとインポート (従来の方法)

詳細な手順については、キャンバスアプリパッケージのエクスポートとキャンバスアプリパッケージのインポートに記載されています。

アプリをエクスポートするこの方法は従来の方法です。これもサポートされていますが、ソリューションを使用することをお勧めします。ソリューションを使用すると、1 つのリソースだけでなく、複数のコンポーネントを移行できます。

エクスポートとインポートのフロー (従来の方法)

以下の手順では、フローをエクスポートする方法を説明します。

「…」メニューを選択し、エクスポート を選択してから、 パッケージ (.zip) を選択します。
パッケージの名前と説明を入力します。その後、既定の設定を構成し、インポート段階でアクセスできるコメントを追加できます。
右下隅の エクスポート ボタンを選択し、パッケージをダウンロードします。ダウンロードが自動的に開始されない場合は、ダウンロード ボタンを選択できます。

以下の手順では、フローをインポートする方法を説明します。

インポート ボタンを選択します。
パッケージファイルをアップロードし、画面にパッケージの詳細が表示されるまで待機します。
フロー設定を構成する場合、新しいフローを作成するか、パッケージのフロー定義を使って既存のフローを更新するかを選択できます。
フローの設定に必要な接続を選択します。必要な設定がすべて完了すると、インポート ボタンが利用可能になります。

フローをインポートした後、フローをアクティブ化する必要があります。フローに接続参照がある場合、フローをアクティブ化するユーザーはそれらの接続にアクセスできる必要があります。そうでない場合、接続所有者はアクティベーションユーザーにアクセスを許可できます。

クラウドフローをエクスポートするこの方法は従来の方法です。サポートされている間は、1 つのリソースだけではなく複数のコンポーネントを移行できるソリューションを使用することをお勧めします。

モデル駆動型アプリのエクスポートとインポート

モデル駆動型アプリは常にソリューションの一部です。ソリューションファイル (.zip) に含まれるパッケージ化されたアプリは、ソース環境から正常にエクスポートされ、ターゲット環境にインポートされた後、セキュリティロールに基づいてユーザーと共有できます。

段階的なプロセスの詳細については、ソリューションのエクスポートとソリューションのインポートで説明します。

Microsoft Copilot Studio ボットのエクスポートとインポート

ソリューションを使ってボットをエクスポート、インポートすることができます。手順の詳細なリストについては、ソリューションを使用したボットのエクスポートとインポートで説明します。

Power Pages サイトのエクスポートとインポート

移行ページでは、ソースの Microsoft Dataverse 環境から既存の構成をエクスポートし、ターゲットの Dataverse 環境にインポートします。ターゲット環境で実行する必要がある前提条件の手順がいくつかあります。準備作業が完了したら、構成移行ツールを使用してポータル構成データをエクスポートできます。

SharePoint フォームアプリ – 既定の環境の特殊なケース

SharePoint フォームアプリは1つの環境にのみ関連付けることができ、特に設定されていない場合は、デフォルトの環境になります。すべてのアプリを移行するには、移行先を既定の環境ではなく別の環境に設定する必要があります。既存のカスタムフォームは、新しく指定された環境に自動的に移行されません。運用環境のみを SharePoint カスタムフォームに対して指定できます。キャンバスアプリの移動などの手動プロセスが続きます。

Microsoft Power Platform オブジェクトのバックアップ

ほとんどの Microsoft Power Platform オブジェクトは zip ファイルとしてエクスポートされます。そうでない場合は、少なくとも 1 つのファイル形式があります。これらのファイルは、zip ファイルまたは付属の拡張子として元の形式で、任意のファイル保存場所または選択したリポジトリに追加できます。いくつかのオプションとして、Azure DevOps、GitHub、 SharePoint、One Drive、またはすべてのファイル形式をサポートするその他のソリューションがあります。

一括移行オプション

アプリまたはフローが以前と同じように機能する場合、移行は成功します。ただし、転送できない特定の要素があります:

フローの過去の実行に関するフロー実行データ - フロー実行に関するデータは28日間のみ保存されます。データが必要な場合は、CoE スターターキットを使用するか、データレイクへのエクスポートを設定している場合はこれを使用して、データをエクスポートして保存できます。 CoE スターターキットの最新バージョンには、データエクスポートと使用した場合のフロー実行データが含まれています。
キャンバスアプリのバージョン - 作成者が開発プロセスを反復するにつれて、複数のバージョンが作成される場合があります。以前のバージョンは移行できません。最新バージョンのみを移行できます。
アプリまたはフローによって、またはコネクタを使用してアクセスされたデータ - エクスポートの一部としてアプリのメタデータのみが含まれます。

アプリまたはフロー内で作成されたコラボレーションコメントも含まれません。

この記事では、いくつかの可能性について概説します。決定する前に、それぞれの可能性の影響と利点を慎重に検討することが重要です。

すべて移行 - データベースのバックアップと復元のオプション

ほとんどの環境タイプと同様に、既定の環境もバックアップされます。これらのシステムバックアップは自動的に実行されます。既定の環境にはオンデマンドオプションがないため、サポートリクエストが必要です。バックアップは、Dataverse 内のすべてのデータを保持したまま、新しい環境に復元できます。このオプションは、閲覧者にその存在を示し、いつ考慮すべきかを閲覧者に教育することのみを目的としています。部分的な移行しか得られないため、これを第一の選択肢として追求すべきではありません。

サポート対象:: Dataverse、Dynamicsアプリ
完全にはサポートされていません: キャンバスアプリ、コンポーネントライブラリ、カスタムページ、 Power Automate、 Microsoft Copilot Studio

完全にサポートされていない場合は、移行中にデータが失われる可能性があり、より多くの手順が必要であることを示しています。

メタデータを移行してからデータを移行する

推奨されるアプローチは、ソリューションを使用してメタデータを移動し、データフロー、Azure Data Factory、またはその他の好みのツールを使用してデータを転送することです。多様なコネクターがあるため、すべてのケースで最初から最後まで完全自動化が達成できるわけではないが、ほぼ自動化することは可能です。

大まかな手順は以下の通りです:

アプリをソリューションに追加します。
フローをソリューションに追加します。
既存のボットを追加します。
アプリとフローの接続参照を調整します。
ソリューションの依存関係をチェックし、オブジェクトを追加します。
ソリューションをエクスポートします。
ソリューションをインポートします。
データを転送します。

ソリューションの依存関係を確認しています

ターゲット環境でのソリューションのインポートが確実に成功するのは、すべての関連コンポーネントがソリューションに追加されているか、ターゲット環境で使用できる場合に限られます。欠落しているコンポーネントがある場合、ソリューションのインポートは失敗する可能性があります。必要なコンポーネントがすべて揃っていることを確認するには、組み合わせて使用するのに最適なオプションがあります。

選択したコンポーネントをソリューションに手動で追加します。この場合、すべての依存コンポーネントがターゲット環境ですでに使用可能であることがわかっていることを前提としています。
ソリューションの中から依存関係を表示するボタンを使用して、システムに依存関係を識別させます。すべての依存関係を追加することも、ターゲット環境に存在しない依存関係だけを選択的に追加することもできます。

ソリューションにコンポーネントを追加する (手動)

ソリューションを作成する場合、作成者は既存のコンポーネントの追加メニューオプションを使用して、既存のアプリ、フロー、またはボットを追加する必要があります。

既存のコンポーネントをソリューションに追加することを示した画像。

接続参照の調整

キャンバスアプリとフローは、接続の処理が異なります。フローはすべてのコネクタに対して接続参照を使用しますが、キャンバスアプリはSQL Server認証などの暗黙的に共有される (非 OAuth) 接続に対してのみ接続参照を使用します。

アプリを更新して、接続ではなく接続参照を使用する

ソリューションに追加されたときにソリューションを認識していないキャンバスアプリは、自動的にアップグレードされないため、接続参照を使用しません。接続参照は、データソースがアプリに追加されたときにのみキャンバスアプリに関連付けられます。アプリをアップグレードするには、次のことを行う必要があります:

ソリューションに対応しないアプリをソリューションに追加します。
アプリから接続を解除します。
ソリューションに新しい接続参照を作成します。
関連する接続参照を含む接続を追加します。

接続ではなく接続参照を使用するようにフローを更新する

フローがソリューションにない場合、接続を使用します。その後、そのフローがソリューションに追加されると、最初は接続が引き続き使用されます。フローは、次の 2 つの方法のいずれかで、接続ではなく接続参照を使用するように更新できます:

フローがアンマネージソリューションでエクスポートされてインポートされた場合、接続は削除され、接続参照に置き換えられます。
ソリューションフローを開くと、フローの詳細ページのフローチェッカーに 接続参照を使用する 旨の警告が表示されます。警告メッセージには、接続参照を追加するために接続を削除する のようなアクションが含まれます。そのアクションを選択すると、フロー内のトリガーとアクションから接続が削除され、接続参照が選択および作成できるようになります。

ソリューションへのオブジェクトの追加 (自動化)

PowerShell コマンドを使用して、アプリをソリューションに一括で移動できます。既存のキャンバスアプリとクラウドフローをソリューションに追加することも、コマンドライン経由で行うことができます。このオプションを試すには、最新の PowerShell モジュールをインストールしてください。 2 つの主なコマンドは、Set-PowerAppAsSolutionAware と Set-FlowAsSolutionAware です。

モジュールがインストールされたら、独自の環境 ID、アプリ ID、フロー ID、ソリューション ID を挿入します。

キャンバスアプリ:

Set-PowerAppAsSolutionAware -EnvironmentName {Environment ID} -AppName {App ID} -SolutionId {Solution ID}

フロー:

Set-FlowAsSolutionAware -EnvironmentName {Environment ID} -FlowName {Flow ID} - SolutionId {Solution ID}

接続参照は、接続参照テーブルへのデータエントリです。接続参照をアプリまたはフローの一部として使用するには、コアアプリまたはフロー定義を変更する必要があります。 connectionReferences ノードを接続参照に置き換える必要があります。

ソリューションのエクスポートおよびインポート

ソリューションの準備ができていると仮定すると、自動化の次の段階は複数の方法で実行できます:

ソリューションをターゲット環境に手動でエクスポートしインポートします。
複数のソリューションを 1 つのパスで移動するには、パッケージを使用します。
Power Platform ビルドツールタスクを使用して、ソリューションのパック、ソリューションの解凍、ソリューションのエクスポート、ソリューションのインポートなどの複数の操作を実行します。 DevOps はアプリケーションライフサイクル管理 (ALM) を自動化する機能を提供し、これらのタスクはすべて Microsoft Power Platform のALMをサポートするように構築されています。

Power Platform コマンドラインインターフェイス (CLI) には、ソリューションをエクスポートおよびインポートするためのオプションも用意されています。ソリューション関連のすべてのコマンドは、ソリューションの構築、エクスポート、インポートに使用できます。 CLI を使用してデータを送受信することもできます。

作成者に親しみやすいオプションは、Power Platform のALM を民主化することを目的としたパイプラインを使用することです。 ALM の自動化と継続的インテグレーション/継続的デプロイメント (CI/CD) 機能を単一の機能サービスに組み込むことは、すべての作成者、管理者、開発者にとってより親しみやすくなります。

接続の作成 (手動)

インポート操作を設定する前に、ターゲット環境で、アプリまたはフローに必要な不足している接続を作成します。接続の作成方法については、Power Automate での接続を管理するを参照してください。

データの移行

データ移行には、手動から完全自動まで、複数のオプションが利用可能です。

Excel ワークブックを使用してデータを手動でエクスポートおよびインポートします。
Power Automate クラウドフローを開発して、ソーステーブルからデータを抽出し、宛先に直接書き込むことができます。ただし、これには作成者が Dynamics 365 Connector または Dataverse (レガシー) コネクタを使用する必要があります。現在、Dataverse コネクタは環境間の接続をサポートしていません。この機能は将来的なリリースを計画しており、リリース後はデータを一方から他方に移動するために使用される可能性があります。
構成移行ツール (CMT) はポータル移行に使用されるツールですが、通常のデータ移行にも使用できます。 CMT は PowerShell でも使用できる。 PAC CLI ツールを使用すると、CMT を呼び出すことができます。
データフローを使用すると、環境間のマッピングを作成したり、データを移動したりできます。 Dataverse の代わりに HTTP Web コネクタを使用することもできます。
Azure Data Factory を Dataverse コネクタと組み合わせて使用すると、ソースからデータを取得して宛先に挿入できます。

デフォルト環境のサイズが制限されていることを考慮すると、既定の環境からデータを移動するには上記のオプションのいずれかで十分です。

クリーンアップに関する考慮事項

長期間使用または更新されていないアプリやフローについては、クリーンアップを行うことをお勧めします。クリーンアップに関する限り、管理者にはさまざまなパスを考慮する必要があります。

データをインポートする順序を決定します。依存性の最も低いテーブルが最初に配置され、最も依存性の高いテーブルが最後に配置されます。
すべてのフィールドをマッピングする必要はありません。 バージョン、修正日、作成日 などのフィールドや、その他のシステムフィールドはマッピングする必要はありません。
元の 作成日 の日付を保持する場合は、ソースの 作成日 の日付フィールドを宛先テーブルの OverRiddenCreatedOn フィールドにマッピングします。
監査データは移行できません。
意図しない限り、データ挿入に基づいてトリガーされるワークフローやフローを有効にしないでください。これにより、データ移行にかかる時間が長くなります。

タグ付けのオプション

現在、CoE スターターキットにはタグ付けオプションがありません。ただし、スターターキットに追加できるカスタマイズである可能性があります。

Tags というテーブルを作成し、アプリ、フロー、その他のインベントリテーブルとの多対多 (N:N) 関係を設定します。次に、タグを作成し、これらのレコードを適切な在庫品目に関連付けることができます。ユーザーエクスペリエンスを向上させるために、アプリ、フロー、その他のインベントリテーブルの メイン フォームにグリッドを埋め込むことができます。このオプションは参照の一貫性があるため推奨されます。

各在庫テーブルにテキストフィールドを作成し、それを使用して、後で使用できるテキスト (タグ) をキャプチャします。

より固定的なリストが必要な場合は、グローバルオプションセットを作成し、それをすべての在庫テーブルとそのフォームにも追加します。

隔離オプション

特定のアプリケーションの必要性が不確かな場合は、しばらくの間そのアプリケーションを隔離し、隔離状態にしておくことができます。アプリは所有者のみが使用できます。適切な時間が経過し、所有者からの応答が受信されない場合は、環境から削除できます。

フローは隔離状態をサポートしていませんが、フローを停止し、所有者によって再度アクティブ化されるかどうかを確認することで、同様のアプローチを使用できます。

どちらの場合も、飼い主と適切なコミュニケーションをとることが重要です。

オプションの削除のみ

実際に生産性の損失がなく、オブジェクトの再利用が可能な場合は、このオプションが最適です。ほとんどのテストフローとアプリはこのカテゴリに分類されます。

この場合、オブジェクトのリストが特定されたら、PowerShell バッチを開発し、それに csv リストを渡して、それらのアセットをすべて削除することができます。

アプリとフローの ID をループすると、次のコマンドを使用してそれらを既定の環境から削除できます。

Remove-AdminFlow -EnvironmentName Default-[Guid] -FlowName [Guid]
Remove-AdminPowerApp -AppName [Guid] -EnvironmentName [Guid]

オブジェクトのバックアップと削除オプション

例として、Power Automate flow は特定の季節ニーズに対応するために作成されましたが、長い間使用されていませんでした。この場合、コンポーネントを削除する前にコンポーネントのバックアップを作成することをお勧めします。

コンポーネントのバックアップを作成するには、個別の移行または一括移行のオプションを使用して、エクスポートされたソリューションを生成できます。このファイルは、任意のファイルリポジトリか、OneDrive の場所に追加することができます。

バックアップが保護されたら、消去クリーンアッププロセスを完了するオプション。

多くの場合、これらは、個人的な生産性の学習や実験の一環としてメーカーが作成したテストフローやアプリです。

結論

Power Platform は市民開発者にもプロの開発者にも使えるツールです。既定の環境での使用は、主に Microsoft 365 製品を使用した個人的な生産性に重点を置く必要があります。他のすべてのアプリとフロー開発は、指定された共有環境、個人環境、または開発者環境で実行する必要があります。 DLP に基づいた独立した環境戦略を開発することを強くお勧めします。これは、メーカーが適切な環境でアプリとフローを開発するのに役立ちます。また、コミュニケーション戦略を確立し、戦略、ソリューションの実装、アプリとフローを開発するためのベストプラクティスについて学習するセルフサービスモデルをユーザーに提供することにも、大きな利点があります。さらに、コミュニケーションサイトでいくつかの成功事例を記録しておくことも効果的です。社内で発表される成功例は、作成者がアイデアと結びつき、Power Platform を使用して実現できる可能性を解放する際に活用できます。

特定のオブジェクトを移行または移動する場合は、強力なガバナンス戦略が不可欠です。オブジェクトの移行には、個別移行や一括移行など、さまざまな戦略が使用できます。最適なオプションは組織のポリシーによって異なります。ソリューションは、アプリケーションのコンポーネントを整理し、移行をより簡単にするために最も推奨される方法です。

次の方法で共有