Power Platformで環境を作成・管理する場合、今回もっとも重要なのは「環境を増やせるか」ではなく、誰が作成できるか、容量が足りているか、DataverseやDynamics 365アプリを後から変更できるかを事前に確認することです。
特に、Power Platform admin centerで新しい環境を作成する前に、ライセンス、1GB以上の空きデータベース容量、テナント側の作成ポリシー、セキュリティグループ、リージョン、Dataverseの有無を確認しておく必要があります。Dynamics 365アプリの有効化やDataverseデータストアの追加は、後から簡単に戻せない選択があるため、管理者と開発者が同じ前提で設計しておくことが重要です。(Microsoft Learn)
Power Platformの環境とは何か
Power Platformの環境は、アプリ、フロー、接続、ゲートウェイ、Dataverseデータ、チャットボットなどを保存・管理・共有するためのコンテナです。部署、用途、セキュリティ要件、対象ユーザーが異なるリソースを分離するために使います。(Microsoft Learn)
たとえば、次のような分け方が実務ではよく使われます。
| 環境の分け方 | 使いどころ | 注意点 |
|---|---|---|
| 開発・検証・本番で分ける | アプリの改修やテストを本番影響なく進めたい場合 | ソリューション移行、接続参照、環境変数の管理が必要 |
| 部門ごとに分ける | 営業、マーケティング、サポートなどでデータや権限を分けたい場合 | セキュリティグループとDataverseロールを合わせて設計する |
| 地域ごとに分ける | データ所在地や利用部門が国・地域で異なる場合 | 作成時のリージョン選択を誤ると後工程に影響しやすい |
| 個人開発・学習用に分ける | Power Apps Developer Planなどで試作したい場合 | 本番用途に使わず、共有範囲を限定する |
Power Appsではテナントごとに既定の環境が1つ作成され、テナント内のユーザーが共有します。ただし、既定の環境は本格的な業務アプリの本番運用に向いているとは限りません。業務データを扱うアプリは、セキュリティ、バックアップ、DLP、所有者、変更管理を考慮して、専用のProduction環境やSandbox環境を用意するのが安全です。(Microsoft Learn)
2026年5月更新で押さえるべきポイント
Microsoft Learnの該当ページは、ページメタデータ上では2026年5月6日更新として管理されています。日本時間で2026年5月7日前後に確認した更新内容として見る場合、実務上のポイントは次のとおりです。(GitHub)
| 確認ポイント | 管理者・開発者への影響 |
|---|---|
| Power Platform admin centerでの環境作成手順が整理されている | 旧UIや古い手順を前提にした社内マニュアルは見直しが必要 |
| 作成条件としてライセンス、容量、テナントポリシーが明確化されている | 「権限があるのに作れない」原因を切り分けやすくなる |
| Dataverseデータストアを追加する場合の不可逆な選択が強調されている | 本番環境を作る前に、DataverseとDynamics 365アプリの要否を決める必要がある |
| Security group項目の重要性が増している | 環境アクセスを誰に開くかを作成時点で検討する必要がある |
| 更新頻度を示すRefresh cadenceが説明されている | Canvas app authoringの新機能適用タイミングを環境ごとに調整できる |
| Dynamics 365アプリ有効化時のSales／Customer Service関連の説明が追加・修正されている | アプリが表示される理由を理解し、削除ではなくセキュリティロールで制御する必要がある |
GitHub上の更新履歴を見ると、2026年5月の変更では「関連コンテンツの追加」「Dynamics 365 Appsアクセス説明の明確化」「Sales and Customer Service applicationsに関するFAQ見出しの修正」などが行われています。大規模な仕様変更というより、管理者が誤解しやすい箇所を補強した更新と捉えるのが現実的です。(GitHub)
環境を作成できる人と条件
Power Platformで環境を作成するには、単に管理画面にアクセスできるだけでは不十分です。公式情報では、環境作成に必要な条件として主に次の3つが示されています。(Microsoft Learn)
| 条件 | 内容 | 確認する場所 |
|---|---|---|
| ライセンス | 環境作成が許可されるライセンスを持っているか | Microsoft 365 admin centerのアクティブユーザー |
| 容量 | Production／Sandbox環境では少なくとも1GBのデータベース容量が必要 | Power Platform admin centerのCapacity関連画面 |
| テナントポリシー | ユーザーによる環境作成が許可されているか | Power Platform admin centerのTenant settings |
注意したいのは、Microsoft 365ライセンスだけでは環境を作成・管理できない点です。Power Apps、Power Automate、Dynamics 365、Microsoft Copilot Studioなどのライセンス種別によって、Trial環境やProduction環境を作れるかが変わります。(Microsoft Learn)
また、環境の作成数は昔のように単純な「ライセンス数あたり何個」という考え方だけでは判断できません。公式FAQでは、Power AppsのProduction環境プロビジョニングはデータベース容量に基づき、Dataverseあり／なしにかかわらず環境は少なくとも1GBの容量を消費すると説明されています。(Microsoft Learn)
管理者が最初に確認すべき作成ポリシー
組織でPower Platformを運用する場合、まず確認すべきなのは「一般ユーザーが自由に環境を作成できる状態になっていないか」です。
Power Platform admin centerでは、Developer、Production、Trialの各環境タイプについて、作成できるユーザーを制御できます。制限すると、Global admin、Dynamics 365 admin、Power Platform adminなどの管理者ロールを持つユーザーに環境作成を限定できます。(Microsoft Learn)
ただし、制限を有効にしても、既に作成済みの環境は作成者が引き続き管理できる場合があります。つまり、制限を入れるだけでは既存環境の棚卸しにはなりません。運用改善を行う場合は、次の順番で進めるのが安全です。
| 手順 | やること | 目的 |
|---|---|---|
| 1 | 既存環境の一覧を取得する | 野良環境や用途不明環境を把握する |
| 2 | 環境タイプ、所有者、リージョン、Dataverse有無を確認する | 本番相当の環境を見落とさない |
| 3 | 環境作成ポリシーを制限する | 新規の無秩序な環境作成を防ぐ |
| 4 | 既存環境にセキュリティグループや管理者を設定する | アクセス制御と管理責任を明確にする |
| 5 | 社内申請フローを用意する | 必要な環境を止めずにガバナンスを維持する |
Dataverseあり・なしの判断基準
Power Platform admin centerでは、環境をDataverseデータベースありで作るか、なしで作るかを選べます。ここは後工程への影響が大きいため、アプリ作成者だけで判断せず、管理者、業務部門、セキュリティ担当者が事前に合意しておくべきです。
| 選択 | 向いているケース | 注意点 |
|---|---|---|
| Dataverseあり | モデル駆動型アプリ、Dynamics 365アプリ、業務データ管理、セキュリティロールを使う場合 | 作成時に容量を消費する。Dynamics 365アプリの有効化判断が重要 |
| Dataverseなし | 外部データソース中心のキャンバスアプリやPower Automateフローを使う場合 | 後からDataverseを追加できるが、最初から設計していないと移行時に手戻りが出やすい |
公式情報では、Dataverseデータストアを追加する設定は「Yes」を選ぶと元に戻せないと説明されています。一方、Dataverseなしで作成した環境には、後からデータストアを追加できます。(GitHub)
実務では、次のように判断すると失敗しにくくなります。
| 作りたいもの | 推奨判断 |
|---|---|
| SharePointリストやExcelなどを使った小規模な申請アプリ | まずはDataverseなしでもよい。ただし本番化するなら再設計を検討 |
| 顧客、案件、契約、問い合わせなどの業務データを長期管理するアプリ | Dataverseありを前提に設計 |
| Dynamics 365 SalesやCustomer Serviceと連携するアプリ | Dataverseあり、かつDynamics 365 apps有効化を作成時に検討 |
| 開発者が個人で試すプロトタイプ | Developer環境やSandbox環境を利用し、本番データを入れない |
| 複数部署で使う全社アプリ | Production環境を作り、セキュリティグループとロールを設計 |
Dynamics 365アプリの有効化は後から変更できない前提で考える
今回の公式情報で特に注意したいのが、Dynamics 365アプリの有効化です。
ProductionまたはSandbox環境をDataverseデータベースありで作成する場合、作成時に「Enable Dynamics 365 apps」を選択できます。ここでYesを選ばなかった場合、後からその環境でDynamics 365アプリを有効化したり、インストールしたりできないと説明されています。(Microsoft Learn)
これは、開発・展開計画に大きく影響します。
たとえば、最初はPower Appsのカスタムアプリだけを作る予定でも、将来的にDynamics 365 SalesやCustomer Serviceを導入する可能性がある場合、環境作成時点で判断が必要です。すでに「Enable Dynamics 365 apps」をNoで作った環境に後から追加できない場合、新しい環境を作り直し、ソリューション、データ、接続、権限を移行することになります。
また、Trialタイプの環境ではDynamics 365アプリを有効化できないとされているため、検証のためにTrial環境を作る場合も、本番移行時の前提を別途整理しておく必要があります。(Microsoft Learn)
SalesやCustomer Serviceが入る理由
FAQでは、「Enable Dynamics 365 Apps」をYesにするとSalesとCustomer Serviceアプリが既定でインストールされると説明されています。これらのアプリは削除するのではなく、セキュリティロールでアクセスや表示を制御する考え方が推奨されています。(Microsoft Learn)
現場で起きやすい失敗は、「使わないから消す」という判断です。後から関連機能や権限で問題が出る可能性があるため、まずは誰に見せるか、誰が使えるかをロールで制御してください。
セキュリティグループとロール設計が重要になる
環境へのアクセス制御では、Microsoft Entra IDのセキュリティグループを使って、どのユーザーが環境に入れるかを管理できます。複数環境を持つ組織では、営業用、マーケティング用、サポート用、開発用など、環境ごとにセキュリティグループを分けるのが基本です。(Microsoft Learn)
ここで混同しやすいのが、「環境に入れること」と「Dataverseデータにアクセスできること」は別だという点です。公式情報では、ライセンスを持つユーザーであっても、環境内のデータにアクセスするにはセキュリティロールの割り当てが必要だと説明されています。(Microsoft Learn)
| 項目 | 役割 | 不足すると起きること |
|---|---|---|
| ライセンス | Power AppsやDataverseなどを利用する権利 | アプリや環境を利用できない |
| セキュリティグループ | 環境に入れるユーザーを絞る | 共有済みアプリでも環境に入れない |
| 環境ロール | Environment AdminやEnvironment Makerなどの管理・作成権限 | アプリやフローを作成・管理できない |
| Dataverseセキュリティロール | テーブルやデータへのアクセス権 | アプリを開けてもデータアクセスでエラーになる |
注意点として、既定環境やDeveloper環境にはセキュリティグループを割り当てられないとされています。既に割り当てている場合は削除が推奨されています。(Microsoft Learn)
また、オンプレミスのWindows Active Directoryで作成したセキュリティグループではなく、Microsoft Entraのセキュリティグループを選ぶ必要があります。既存環境にセキュリティグループを関連付けると、グループに含まれない既存ユーザーが無効化される可能性があるため、切り替え前にメンバー一覧を確認してください。(Microsoft Learn)
リージョンと「Get new features early」の注意点
環境作成時にはリージョンを選択します。環境に作成されたアプリ、フロー、接続、ゲートウェイ、Dataverseデータベースなどは、その環境の場所に紐づきます。(Microsoft Learn)
今回の情報では、「Preview (United States)」リージョンが選択肢として表示されなくなり、「Get new features early」設定に置き換えられている点も確認されています。早期リリースサイクルの設定は、米国、Europe – Default、オーストラリア、カナダのリージョンで利用できると説明されています。(Microsoft Learn)
本番環境で早期機能を使うかどうかは慎重に判断しましょう。新機能を早く試せる利点はありますが、業務クリティカルなアプリでは、標準リリース環境で安定運用する方が適している場合があります。
おすすめは、次のように役割を分ける方法です。
| 環境 | Get new features early | 理由 |
|---|---|---|
| 個人検証・技術検証 | Yesを検討 | 新機能の検証に向いている |
| 開発環境 | 必要に応じてYes | 開発チームが影響を早めに把握できる |
| 検証環境 | 本番に合わせる | 本番移行前の再現性を確保する |
| 本番環境 | 原則慎重に判断 | 業務影響を抑える |
Refresh cadenceはCanvas app authoringの更新タイミングに影響する
Power Platform admin centerでは、環境作成後にRefresh cadenceを設定できます。これは、Microsoft Power Platformサービスの更新や機能をどの程度の頻度で受け取るかの希望を示す設定です。(Microsoft Learn)
公式情報では、Canvas app authoringについて次の2つの選択肢が示されています。
| 設定 | 内容 | 向いている環境 |
|---|---|---|
| Frequent | 月に複数回、新しい更新や機能にアクセスする | 検証、開発、新機能確認 |
| Moderate | 少なくとも月1回、更新や機能にアクセスする | 本番に近い検証、本番運用で安定性を重視する場合 |
既定ではFrequent cadenceです。Canvas appsの作成・編集は週1回の更新を受け取り、アプリを公開すると対応するランタイムバージョンが適用されると説明されています。Moderateを選んだ場合、作成・編集は月1回の更新になります。(Microsoft Learn)
ただし、この設定はPower Platform全体やDynamics 365 Sales、Customer Service、Marketingなどの更新タイミングを変えるものではありません。Canvasアプリの作成・編集体験に関する設定として理解しておくと誤解を避けられます。(Microsoft Learn)
URL、削除、変更時の移行トラブルに注意
環境URLを作成または使用する場合、削除済みまたは変更済みの環境と同じURLはすぐには使えません。公式情報では、環境の削除または変更後、同じURLを使うには少なくとも24時間待つ必要があるとされています。(Microsoft Learn)
これは移行計画で見落とされやすいポイントです。
たとえば、旧環境を削除して同じURLで新環境を作り直す計画を立てると、当日中に切り替えられず、展開作業が止まる可能性があります。URLを引き継ぎたい場合は、少なくとも次の準備をしてください。
| 確認項目 | 理由 |
|---|---|
| 旧URLを本当に再利用する必要があるか | ブックマークや外部連携の影響を判断する |
| 削除・変更から24時間以上の余裕があるか | URL再利用待ちで展開が止まるのを防ぐ |
| 接続、フロー、アプリ内リンクを洗い出したか | URL変更によるリンク切れを防ぐ |
| 代替URLで問題ないか | 切り替えスケジュールを柔軟にできる |
| 利用者への案内タイミングを決めたか | 誤アクセスや問い合わせを減らす |
管理者が確認すべき設定チェックリスト
今回の更新内容を踏まえると、Power Platform管理者は次の項目を優先的に確認すべきです。
| チェック項目 | 確認内容 |
|---|---|
| 環境一覧 | Default、Production、Sandbox、Trial、Developer、Dataverse for Teamsの数と用途 |
| 所有者 | 誰が作成し、誰が管理責任を持っているか |
| リージョン | データ所在地や社内ルールに合っているか |
| Dataverse有無 | 業務データ管理に必要な構成になっているか |
| Dynamics 365 apps | 将来の導入予定と作成時の有効化判断が合っているか |
| 容量 | Dataverse database、file、log、環境作成に必要な1GB以上の空き容量 |
| セキュリティグループ | 環境アクセスが部署・用途に合わせて制限されているか |
| セキュリティロール | Dataverseデータへのアクセス権が適切か |
| DLPポリシー | 業務データと個人利用のコネクタが混在しないか |
| Refresh cadence | 開発・検証・本番の更新頻度が運用方針に合っているか |
| 環境作成ポリシー | 一般ユーザーが不要なProduction／Trial／Developer環境を作れないよう制御されているか |
| URL再利用 | 削除・変更後の24時間制約を展開計画に入れているか |
特に重要なのは、既定環境の扱いです。既定環境はテナント内のユーザーに広く共有されるため、個人の試作や軽量なアプリには便利ですが、機密性の高い業務データや部門限定アプリを置くには慎重な設計が必要です。環境の目的が曖昧なままアプリを増やすと、後から権限整理、DLP対応、移行作業が重くなります。
開発者が確認すべき展開・移行上の注意点
開発者は、アプリやフローを作る前に「どの環境で作るか」を決める必要があります。環境設計を後回しにすると、完成後に移行や権限設定で手戻りが発生します。
開発開始前に確認すること
| 確認項目 | 具体的な質問 |
|---|---|
| 環境タイプ | これはDeveloper、Sandbox、Productionのどこで作るべきか |
| データソース | Dataverse、SharePoint、SQL、外部APIのどれを使うか |
| 権限 | 利用者は誰で、どのデータにアクセスできるべきか |
| 将来の展開 | 本番移行、別部門展開、多言語・多地域展開の予定はあるか |
| Dynamics 365連携 | Sales、Customer Service、Field Serviceなどを使う可能性はあるか |
| 更新頻度 | 新機能を早く使いたいのか、安定性を優先するのか |
本番展開前に確認すること
本番展開前には、少なくとも次の点をチェックしてください。
| 項目 | 確認ポイント |
|---|---|
| ソリューション管理 | アプリ、フロー、テーブル、環境変数、接続参照をソリューションに含めているか |
| 接続参照 | 開発者個人の接続に依存していないか |
| 環境変数 | URL、サイトID、リストID、APIエンドポイントなどを本番用に切り替えられるか |
| セキュリティロール | 利用者、管理者、サポート担当者のロールを分けているか |
| 容量 | 本番データ投入後もDataverse容量に余裕があるか |
| フロー所有者 | 退職者や異動者の個人アカウントに依存していないか |
| 監査・ログ | 重要データの変更履歴やトラブル調査に必要な設定があるか |
| 変更管理 | 誰がいつ本番反映するかを決めているか |
よくある失敗と回避策
Power Platformの環境管理では、技術的なミスよりも「最初に決めていなかったこと」が後から問題になりがちです。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| 既定環境に本番アプリを作ってしまう | 作りやすさを優先し、環境設計を後回しにした | 本番用途はProduction環境を作成し、既定環境は個人・軽量用途に限定する |
| Dynamics 365アプリを後から入れられない | 環境作成時にEnable Dynamics 365 appsをNoにした | 将来利用の可能性を事前に確認し、必要なら最初から有効化する |
| ユーザーがアプリを開けない | アプリ共有だけ行い、環境セキュリティグループやDataverseロールを設定していない | ライセンス、環境アクセス、セキュリティロールをセットで確認する |
| 容量不足で環境を作れない | Dataverse容量を確認していない | 作成前にCapacity add-onsやDataverse容量を確認する |
| 検証環境と本番環境の動作が違う | Refresh cadenceやリージョン、接続設定が異なる | 本番相当の検証環境を用意し、設定差分を管理する |
| 移行当日にURLを再利用できない | 削除・変更後の24時間制約を知らなかった | URL再利用が必要な場合は移行スケジュールに待機時間を入れる |
今回の更新を受けて次にやるべきこと
Power Platformの「Create and manage environments in the Power Platform admin center」に関する今回の更新は、環境作成の基本条件や設定項目を改めて確認する良いタイミングです。新機能の追加だけを見るのではなく、既存の環境管理ルールが現在の公式情報と合っているかを見直してください。
まず実施すべきことは、既存環境の棚卸しです。環境タイプ、所有者、リージョン、Dataverse有無、容量、セキュリティグループ、Dynamics 365 appsの設定を一覧化します。次に、環境作成を誰に許可するかを決め、Tenant settingsでProduction、Trial、Developer環境の作成制御を確認します。最後に、新規環境を作る前のチェックリストを社内標準にして、開発者が迷わず判断できる状態にしましょう。
Power Platformは簡単にアプリやフローを作れる一方で、環境設計を誤ると後からの修正が難しくなります。特にDataverse、Dynamics 365 apps、セキュリティグループ、リージョン、容量は、作成前に確認する価値が高い項目です。管理者と開発者が同じチェックリストを使い、環境作成を「その場の操作」ではなく「運用設計の一部」として扱うことが、安定したPower Platform活用につながります。
コメント