【Dataverseガバナンス】 Power Platform環境の管理

こんにちは。DXソリューション営業本部の吾妻です。



Power Platformには、 環境 と呼ばれる、アプリやフロー、テーブルなどを格納して、まとめて管理する機能が用意されています。

この機能を利用して、 組織・部署別 や 目的別 といった単位でデータやロジックを分離することによって、システムごとのセキュリティを確保したり、 ガバナンス管理 を効率化してより多くのユーザーに市民開発を広げたりすることが可能になります。

この記事では、 Power Platform環境 とはどのようなものか、どのように管理すればよいのか、簡単にご紹介したいと思います。

Power Platform環境とは？

環境は、Microsoft Entra テナントの配下に1つ以上作成される、アプリやフローなどのコンポーネントを格納するための入れ物のようなものです。さらに、環境の中には、ソリューションと呼ばれる入れ物を含めることができるので、次の図のように テナント＞環境＞ソリューション＞コンポーネント の順で入れ子構造をとります。




環境には、Dataverseデータベースを1つだけ配置することが（しないことも）できます。環境を作成する際には、地理的な場所（米国、日本などの「地域」）を指定するのですが、このDataverseデータベースに格納されているデータや、アプリやフローなどのコンポーネントは、指定された地域のデータセンターで保持されます。Dataverseデータベースを作成できるかどうかは、購入済みのライセンスや、利用可能なデータベース容量、ユーザーに割り当てられているセキュリティロールといった条件によって異なります。

また、それぞれの環境には、セキュリティグループを紐づけることが可能で、そのセキュリティグループのメンバーだけが環境を利用できるようになります。オープンアクセス（セキュリティグループによらず、組織内の全員が利用できる）とすることもできます。


ちなみに、Microsoftの公式資料を読むと、

環境でアプリを作成する場合、そのアプリは、接続、ゲートウェイ、フローおよび Dataverse データベースを含む、同じ環境に展開されたデータソースにのみ接続できます。 たとえば、テストおよび開発という名前の 2 つの環境を作成し、それぞれの環境に Dataverse データベースを作成した場合のシナリオを考えます。 テスト環境にアプリを作成した場合、テスト データベースにのみ接続でき、'開発' データベースには接続できません。

というように、アプリからは、同一の環境の中にあるデータしか扱うことができないという記載になっていますが、最近は、キャンバスアプリやクラウドフローから、別の環境にあるDataverseテーブルの内容を参照したり、更新したりできるように機能が更新されています。

このため、例えば、 マスタデータだけを格納させるための環境 を用意して、 業務アプリだけを格納させるための環境 からアクセスする、といった要件も実現することができます。

ただし、モデル駆動型アプリについては、現在も、同一環境の中にあるデータしか扱うことができないので、モデル駆動型アプリから別の環境にあるDataverseテーブルの内容を参照したり、更新したりする場合には、キャンバスアプリを埋め込んだり、Power Automateの自動フローを用いてバックグラウンドでレコードを操作したりといった間接的な方法で実装する必要があります。

環境の種類

Power Platform環境には、以下の6種類があります。

表の2列目にある「ロール（セキュリティロール）」について補足します。

表中で○になっている3種類の環境では、すべて管理者の思い通りにカスタマイズすることができます。このため、環境自体にセキュリティグループによる制限を掛けたうえで、アプリやデータの閲覧者、更新者といった役割ごとの権限を割り振ることができます。

既定環境では、Power AppsやPower Automate、Microsoft 365などのライセンスが割り当てられているユーザーに自動的に 環境の作成者 ロールが割り当てられてしまうため、アプリを作成したり共有したりできてしまいます。このため、管理者の立場からすると、Power Platform導入時にガバナンス管理の1つとして 環境戦略 を計画しておかないと、野良アプリ・野良フローが溢れて統制が効かなくなるリスクがあります。

残り2つの環境のうち、開発者環境は、アプリなどの開発のために個人的に使用するための環境で、Dataverse for Teams環境は、Teamsチームごとにキャンバスアプリを作るための環境です。どちらも、通常のDataverse環境とは利用目的が異なるので、セキュリティグループとセキュリティロールの組み合わせでアクセスを制限するのではなく、前者は所有者自身しか環境に入れず、後者はTeamsでの権限に基づいて管理されるようになっています。

環境の使い分けの例

先ほど表に挙げた 5 種類の使い分け方として、よくある例を見てみましょう。

※Dataverseが利用できる環境であれば、敢えてDataverse for Teamsを利用する必要はなく、 特に環境を使い分けないといけないような規模なのであれば 、絶対に（無印の）Dataverseを利用したほうがよいので、これ以降はDataverse for Teams環境は除きます。



先ほどの入れ子関係を表した図から、1システムだけを抜粋した図を以下に示します。




このような構成とする場合の、環境の種類を使い分けるルールについて簡単にまとめます。


①システムを利用するユーザーや役割に応じて環境を使い分ける

・ 既定環境 はどのユーザーにも利用させない
　→ 野良アプリ ／ フロー が作成され、管理しきれなくなる状況となるのを防ぐため
　→ただし、システム的に利用制限を掛けることはできないため、野良アプリ／フローを見つけ次第削除するような 管理用のクラウドフロー を、ガバナンス管理の一環として設置することが多い

・開発者環境（または、試用版環境）は、技術検証を行ったり、開発者自身で使用するアプリを実行したりするために利用させる
　→技術検証を行う場合には、問題を解決するために環境を丸ごとリセットする必要が生じることがあるため、そのような機能を有する種類の環境を利用することが望ましい


② 全社的に利用するシステム が構築される場合は、開発環境・検証環境・運用環境の3環境を払い出す（紛らわしいですが、下線を引いたこの3環境の名前は、先ほどの環境の種類とは別で、環境の利用目的をもとにした命名です）

・システムの開発者は、開発環境でアプリやフローなどのコンポーネントやテーブルを作成する
　→システムのバージョンアップが頻繁にはない場合は、バージョンアップのための開発作業のたびに試用版環境を利用して開発環境を用意する
　→システムを頻繁にバージョンアップする場合は、サンドボックス環境を利用して開発環境を用意する（ただしその分データベース容量を消費してしまう）

・サンドボックス環境を利用して検証環境を、実稼働環境を利用して運用環境を用意する
　→検証環境も、開発環境と同様に、システム更新の頻度やライセンスコスト、維持できる保守体制といった条件に応じて、常設するか都度用意するか検討する必要がある


③ALMの基本的な考え方に従う

・システムのコンポーネントはソリューションにまとめて、ソリューションパッケージの形で環境から環境へ展開していき、原則開発環境から運用環境までで内容が変更されないようにする
　→開発環境では、アンマネージドソリューションとして内容を変更できる状態とし、検証環境・運用環境では、マネージドソリューションとして環境にインポートして、パッケージ（を展開したソリューション）の中にあるコンポーネントを編集できない状態とする

・3環境（開発環境・検証環境・運用環境）で、環境ごとに相違が生じる箇所（パラメーターの管理や、外部連携など）については、Power Platformの機能としてALMの考え方に従った機能を用いて実装する
　→ソリューションの展開を自動化する場合には「パイプライン」を、環境ごとにパラメーターを変更する場合には「環境変数」を、ソースコードを（テキストデータの形で）バージョン管理する必要がある場合には、Azure DevOpsやGitHubとの間でのGit連携を利用する

環境が配置される地域の例

Power Platform環境を作成する際に地域を選択しますが、現時点で利用可能な地域として、いくつかデータセンターの場所が用意されています。

組織のセキュリティ要件として、データの保管場所を国内や特定の地域に限定する場合には「日本」リージョンを選択します。また、Power Platformの最新の機能が追加され次第すぐに体験したいという場合には、一般に米国環境かつ英語設定だと公開タイミングが早めなので、「米国」リージョンを選択することがあります。


利用可能な地域（データセンター）は随時変更されるため、Microsoftが提供している「 製品提供状況レポート 」を必要なタイミングでご覧ください。

この記事の執筆時点では、以下の都市が挙げられていました。
日本国内も、東日本（東京）と西日本（大阪）の2都市がありますが、環境を作成する際にはどちらかだけを選ぶことはできず、可用性を確保するために東京と大阪の双方を用いて多重化されます。

Abu Dhabi, UAE
Beijing, China
Berlin, Germany
Busan, Korea
California, United States
Cardiff, United Kingdom
Chennai, India
Dubai, UAE
Frankfurt, Germany
Geneva, Switzerland
Hong Kong, Asia Pacific
Iowa, United States
Ireland, Europe
Johannesburg, South Africa
London, United Kingdom
Marseille, France
Netherlands, Europe
New South Wales, Australia
Osaka, Japan
Oslo, Norway
Paris, France
Pune, India
Quebec City, Canada
Sao Paulo State, Brazil
Seoul, Korea
Shanghai, China
Singapore, Asia Pacific
Texas, United States
Tokyo, Japan
Toronto, Canada
Victoria, Australia
Virginia, United States
Zurich, Switzerland

まとめ

今回は、Power Platform環境とはどのようなものか、どのように利用すればよいのかについて簡単にご紹介しました。

QES では Power Platform の開発支援、QAサポート、開発者教育、ガバナンス整備など、組織で Power Platform を活用するためのサポートを包括的にご提供しています。Power Platform 活用についてご興味がある／利用中だが課題を感じていらっしゃるお客様はまずはお気軽にお問い合わせください。

Power Platform（ローコード開発） ｜ QES
ローコード開発ツール「Microsoft Power Platform」で現場からアプリ開発・DXを推進！QESはマイクロソフト認定パートナー、「パートナー・オブ・ザ・イヤー」受賞パートナーとしてお客様の Power Platform 活用を包括的に支援しています。