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

  • [アーティクル]

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

作成者: 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) には、次に関する情報が含まれています:

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

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

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

  1. Power Automate フローを作成します。

  2. テナント DLP ポリシーの取得 コネクタを使用して、問題の DLP を指定します。

  3. 結果は、ビジネス データと非ビジネス データの 2 つの配列になります。 例として、Twitter コネクタは次のコードを示します:

    [
  {
    "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
    "name": "Twitter",
    "type": "Microsoft.PowerApps/apis"
  }
……
]

  4. このリストから、csv アプリまたはフロー 接続 列の名前リストと一致するコネクタの名前にアクセスできます。

  5. csv を Excel 形式に変換して OneDrive に配置することで、Power Automate から影響を受けたすべてのアプリとフローを読み取ることができます。 接続とコネクタ名を比較するロジックに基づいて、どの接続が影響を受けるかを確認します。

  6. どの接続が影響を及ぼしているかが一致したら、アプリまたはフロー ID、および DLP の影響を受けるコネクタを含む新しいリストを生成します。

  7. 以前の情報を使用して、将来の影響について作成者に通知します。 アプリまたはフローを削除できる場合、または別の環境に移行する必要がある場合は、パワー カードを使用して作成者からフィードバックを収集できます。

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

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

環境戦略

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

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

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

コミュニケーション戦略

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

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

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

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

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

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

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

対象者

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

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

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

ケイデンス

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

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

リソース

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一括移行オプション

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

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

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

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

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

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

  • サポート: Dataverse、ダイナミクス アプリ
  • 部分的なサポート: キャンバス アプリ、コンポーネント ライブラリ、カスタム ページ、Power Automate、Microsoft Copilot Studio

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

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

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

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

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

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

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

  • 選択したコンポーネントをソリューションに手動で追加します。 この場合、すべての依存コンポーネントがターゲット環境ですでに使用可能であることがわかっていることを前提としています。

  • ソリューションの中から 依存関係を表示する ボタンを使用して、システムに依存関係を識別させます。 すべての依存関係を追加することも、ターゲット環境に存在しない依存関係だけを選択的に追加することもできます。

    取引先企業テーブルの依存コンポーネントの例を示す画像。

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

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

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

接続参照の調整

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

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

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

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

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

フローがソリューションにない場合、接続を使用します。 その後、そのフローがソリューションに追加されると、最初は接続が引き続き使用されます。 フローは、次の 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 を使用して実現できる可能性を解放する際に活用できます。

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