Power Platform ソリューション運用のベストプラクティス

Published: / Last update: / Contributors:
feedback 共有

はじめに

こんにちは、Power Platform サポートチームの 早川 です。
本記事では、Power Platform のソリューションを運用するうえで押さえておきたいベストプラクティスについてご案内いたします。

ソリューションは、アプリやフロー、テーブルなどのコンポーネントをまとめて管理・移行するための仕組みです。
適切に設計・運用することで、変更管理や環境間の展開がスムーズになります。

Note

本記事は執筆時点の情報に基づいています。製品の仕様は予告なく変更される場合がありますので、最新の情報は公式ドキュメントをご確認ください。

ソリューションとは

Power Platform のソリューションとは、Power Apps のアプリや Power Automate のフロー、Dataverse のテーブルなどのコンポーネントをひとまとめにして管理するための「入れ物」です。

Power Apps や Power Automate で作成したコンポーネントは、既定では「既定のソリューション（Default Solution）」に含まれます。
しかし、本番運用を見据える場合はカスタムソリューションを作成し、関連するコンポーネントをまとめて管理することが推奨されます。

ソリューションを利用するメリットは主に以下のとおりです。

  • 開発環境から本番環境へコンポーネントをまとめて移行できる
  • 変更履歴やバージョンの管理がしやすくなる
  • コンポーネント間の依存関係を把握しやすくなる
  • 不要になった機能をまとめて削除（アンインストール）できる

重要

小規模な開発であっても、カスタムソリューションを使うことで変更管理やバックアップが容易になります。既定のソリューションのみでの運用は推奨されません。

マネージドソリューションとアンマネージドソリューション

ソリューションには「マネージドソリューション」と「アンマネージドソリューション」の 2 種類があります。
それぞれの特徴は以下のとおりです。

項目 アンマネージドソリューション マネージドソリューション
主な用途 開発環境での編集・作業用 テスト環境・本番環境への展開用
コンポーネントの編集 可能 不可（意図しない変更を防止）
アンインストール コンポーネントは環境に残る コンポーネントごと削除される

基本的な運用として、以下のフローが推奨されます。

  1. 開発環境でアンマネージドソリューションとしてコンポーネントを編集する
  2. マネージドソリューションとしてエクスポートする
  3. テスト環境や本番環境にマネージドソリューションとしてインポートする

警告

アンマネージドソリューションを本番環境に直接インポートすると、コンポーネントの削除やバージョン管理が困難になります。本番環境にはマネージドソリューションとして展開してください。

発行元（パブリッシャー）の設定

ソリューションの発行元（パブリッシャー）は、テーブルや列の論理名に付与されるプレフィックスを決定する重要な設定です。
以下のポイントに注意して設定してください。

組織で発行元を統一する

発行元は組織ごとにひとつ作成し、すべてのソリューションで同じ発行元を使用することが推奨されます。
発行元が異なるとコンポーネントの依存関係が複雑になり、管理が難しくなります。

プレフィックスを適切に設定する

プレフィックスは組織を識別できる短い文字列（例: contoso）に設定します。
プレフィックスを contoso に設定した場合、新しく作成したテーブルの論理名は contoso_テーブル名 のように自動的に付与されます。

重要

一度設定したプレフィックスはあとから変更できません。最初に慎重に決定してください。

既定の発行元を使用しない

既定の発行元（プレフィックス: new）は使用しないでください。
他の組織が作成したコンポーネントと名前が競合する恐れがあります。

ソリューションの設計

ソリューションを適切に設計することで、変更の影響範囲を限定でき、展開やテストが容易になります。

機能単位でソリューションを分割する

ひとつのソリューションにすべてのコンポーネントを詰め込むのではなく、機能や業務の単位で分割します。
たとえば「営業管理アプリ」と「経費申請フロー」がある場合、それぞれ別のソリューションとして管理します。

コンポーネントが多すぎるソリューションは、エクスポートやインポートに時間がかかり、エラー発生時の原因特定も難しくなります。

共通コンポーネントはベースソリューションにまとめる

複数のソリューションで共有するコンポーネント（テーブル、セキュリティロールなど）は、専用のベースソリューションにまとめます。
各機能ソリューションはベースソリューションに依存する形にすることで、整理された構成になります。

循環参照を避ける

ソリューション間の依存関係は一方向に保ち、循環参照が発生しないように設計します。
循環参照が発生すると、インポートの順序管理が複雑になり、展開に失敗する場合があります。

環境間のソリューション移行

ソリューションを環境間で移行する際は、以下のベストプラクティスに従ってください。

最低 3 つの環境を用意する

  • 開発環境: コンポーネントの編集・開発を行う環境
  • テスト環境: 動作確認・検証を行う環境
  • 本番環境: 実際のユーザーが利用する環境

テスト環境がないと、本番環境で初めて問題が発覚するリスクが高くなります。

接続参照と環境変数を活用する

接続参照は、フローやアプリが外部サービスに接続するための設定を環境ごとに分けるために使用します。
環境変数は、環境ごとに異なる値（URL、API キーなど）を管理するために使用します。

これらを活用することで、ソリューション自体を変更することなく環境に応じた設定が可能になります。
「開発環境の接続情報が本番環境に持ち込まれる」という事故を防ぐことができます。

バージョン管理と ALM

ソリューションのライフサイクルを適切に管理するために、バージョン管理と ALM（Application Lifecycle Management）の仕組みを取り入れることを推奨します。

バージョン番号の運用

ソリューションのバージョン番号は「メジャー.マイナー.ビルド.リビジョン」の 4 桁構成です。
以下のようなルールで運用すると管理がしやすくなります。

  • 初回リリース: 1.0.0.0
  • 軽微な修正: リビジョンを上げる（例: 1.0.0.1）
  • 機能追加: マイナーバージョンを上げる（例: 1.1.0.0）
  • 大規模な変更: メジャーバージョンを上げる（例: 2.0.0.0）

パイプラインによる展開の自動化

Power Platform のパイプライン機能を使うと、開発環境からテスト環境・本番環境への展開を効率的に行えます。

  1. Power Platform 管理センターでパイプラインを有効化します
  2. 開発環境とターゲット環境（テスト・本番）を登録します
  3. ソリューションの [パイプラインで展開] を選択して展開を実行します

ソース管理との連携

Azure DevOps や GitHub と連携することで、ソリューションの変更履歴をリポジトリで管理できます。
変更の追跡やコードレビューを行う本格的な ALM を実現したい場合に有効です。

まとめ

本記事では、Power Platform のソリューション運用におけるベストプラクティスをご紹介しました。
主なポイントは以下のとおりです。

  • ソリューションは小規模な開発でもカスタムソリューションを作成して管理する
  • 開発環境ではアンマネージド、本番環境にはマネージドソリューションとして展開する
  • 発行元は組織で統一し、既定の発行元（プレフィックス: new）は使用しない
  • 機能や業務単位でソリューションを分割し、循環参照を避ける
  • 開発・テスト・本番の 3 環境を用意し、接続参照と環境変数で設定を分離する
  • バージョン番号を適切に管理し、パイプラインやソース管理を活用する

参考情報

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。