Power PlatformからAzureや社内ネットワーク上のリソースへ安全に接続したい場合、ポイントになるのがPower Platformの仮想ネットワークサポートです。結論から言うと、今回確認すべき中心は「Power Platform環境をAzure Virtual Networkに直接入れる」のではなく、委任したAzureサブネットを使って、Dataverseプラグインや対応コネクタのアウトバウンド通信をプライベートネットワーク経由にするという点です。Microsoft Learnのセットアップ手順は2026年5月末に更新され、手順上の前提や確認項目が整理されています。特に、Azure管理者、Power Platform管理者、Dataverseプラグイン開発者は、サブネット設計、リージョン、DNS、NAT Gateway、ファイアウォール、TLS証明書を有効化前に確認しておく必要があります。(Microsoft Learn)
Power Platformの仮想ネットワークサポートとは
Power Platformの仮想ネットワークサポートは、Power PlatformやDataverseのコンポーネントから、Azure Virtual Network内のリソース、またはExpressRouteなどで接続されたオンプレミス側リソースへ、インターネット公開を前提にせず接続するための仕組みです。Microsoftの説明では、Azure subnet delegationを使って、Power Platform実行時のアウトバウンド通信を管理します。(Microsoft Learn)
よくある誤解は、「Power AppsやPower Automate全体がVNet内に配置される」と考えてしまうことです。実際には、Power Platform環境に関連付けたEnterprise Policyと委任済みサブネットを使い、対応するDataverseプラグインやコネクタの通信が、そのネットワークポリシーの影響を受けるようになります。
たとえば、次のような構成で効果があります。
| 利用シーン | 期待できる効果 |
|---|---|
| DataverseプラグインからAzure SQLへ接続する | Azure SQLをパブリック公開せず、Private Endpoint経由で接続しやすくなる |
| Power Automateの対応コネクタからAzure Key Vaultを参照する | Key Vault側のネットワーク制限と組み合わせて秘密情報を守りやすい |
| カスタムコネクタから社内APIを呼び出す | ExpressRouteやVNet Peeringを組み合わせ、社内ネットワーク上のAPIへ接続できる |
| IP許可リスト運用を減らしたい | Azure IP範囲やサービスタグの広範な許可に頼らない設計に近づけられる |
セキュリティ上の価値は大きい一方で、設定を誤ると既存のプラグインやフローが外部エンドポイントへ接続できなくなる可能性があります。単なる「セキュリティ強化オプション」ではなく、ネットワーク設計の変更として扱うべき機能です。
2026年5月末更新で押さえるべき変更点
今回の「Set up virtual network support for Power Platform」関連で実務上もっとも分かりやすい変更は、GitHub上の更新履歴にあるとおり、構成ガイドから enterprisePoliciesPreview フィーチャー登録手順が削除された点です。あわせて、ドキュメントの日付やコントリビューター情報も更新されています。(GitHub)
これにより、管理者がまず確認すべき作業は、主に次の流れになります。
| 確認項目 | 以前の理解で注意すべき点 | 現在の実務上の見方 |
|---|---|---|
| プレビュー機能登録 | enterprisePoliciesPreview の登録が必要だと思い込む | セットアップ手順からは削除されているため、最新手順に合わせる |
| リソースプロバイダー | Azure側の登録を軽視する | Microsoft.Network と Microsoft.PowerPlatform の登録を確認する |
| 権限 | Power Platform管理者だけで進められると考える | Azure側のネットワーク権限とPower Platform管理者権限の両方が必要 |
| Enterprise Policy | Power Platform管理センターだけで完結すると考える | Azureリソースとして作成し、Power Platform環境に関連付ける |
なお、Microsoft Learnのページ上では最終更新が2026年5月29日として表示されています。日本時間での確認や配信タイミングにより、2026年5月30日更新情報として扱われるケースがありますが、実務ではページ本文とGitHub更新履歴の内容を基準に確認するのが安全です。(Microsoft Learn)
影響を受ける範囲
Power Platformの仮想ネットワークサポートは、すべてのPower Platform機能に一律で効くわけではありません。公式ドキュメントでは、Dataverseプラグインと対応コネクタが主な対象として説明されています。対応サービスには、SQL Server、Azure SQL Data Warehouse、Azure Queues、Custom connectors、Azure Key Vault、Azure File Storage、Azure Blob Storage、HTTP with Microsoft Entra ID、Snowflake、Databricks、AI Searchなどが含まれます。(Microsoft Learn)
一方で、環境種別にも制約があります。Production、Default、Sandbox、Developerはサポート対象ですが、TrialとMicrosoft Dataverse for Teamsは対象外です。導入計画を立てる際は、検証環境がサポート対象かどうかを最初に確認してください。(Microsoft Learn)
管理者に影響するポイント
Azure管理者とPower Platform管理者には、次の作業が発生します。
| 役割 | 主な確認ポイント |
|---|---|
| Azure管理者 | VNet、サブネット、サブネット委任、NSG、Firewall、NAT Gateway、Private DNS Zone、Private Endpointの設計 |
| Power Platform管理者 | Managed Environments化、対象環境の選定、Enterprise Policyの関連付け、環境履歴での成功確認 |
| セキュリティ担当 | パブリックアクセス遮断範囲、ログ監視、通信先許可、証明書要件、データ流出対策 |
| 開発者 | プラグイン、コネクタ、フロー内のURL、接続先、認証方式、例外処理の見直し |
特に見落としやすいのは、Power Platform管理者だけでは完結しない点です。Azure側でサブネットやEnterprise Policyを作成する作業があるため、組織内で権限が分かれている場合は、AzureチームとPower Platformチームの作業分担を先に決める必要があります。
開発者に影響するポイント
開発者が最初に確認すべきなのは、DataverseプラグインやカスタムコネクタがどのURLへ接続しているかです。仮想ネットワークサポートを有効化すると、対象サービスの実行時リクエストは委任済みサブネット上で動作し、ネットワークポリシーの影響を受けます。そのため、これまでパブリックURLへ接続していた処理が、ファイアウォールやDNS設定によって失敗する可能性があります。(Microsoft Learn)
たとえば、プラグインが https://api.example.com のような外部APIを呼び出している場合、次の判断が必要です。
| 現状の接続先 | 見直し方 |
|---|---|
| Azure PaaSのパブリックエンドポイント | Private Endpointを作成し、Private DNS Zoneで名前解決する |
| 社内API | ExpressRouteやVPN経由でVNetから到達できるか確認する |
| SaaSの公開API | NAT GatewayやFirewall経由で許可するか、設計上許容するか判断する |
| 自己署名証明書のHTTPSサーバー | 公的に信頼された証明書へ変更する |
「有効化したらセキュアになる」ではなく、有効化前に通信先を棚卸しし、Private Endpoint化するもの、NAT経由で許可するもの、廃止するものを分類することが重要です。
事前準備で確認すべき設定
Power Platformの仮想ネットワークサポートを有効にするには、環境がManaged Environmentsである必要があります。また、Azureサブスクリプション、Azure側のネットワーク管理権限、Power Platform管理者ロール、PowerShell実行環境が必要です。公式手順では、PowerShellまたは手動手順のどちらでも、VNetとサブネットの準備、Enterprise Policyの作成、Power Platform環境への設定という流れで進めます。(Microsoft Learn)
サブネットは「後で広げればよい」と考えない
サブネット設計は最初に慎重に決めるべきです。公式の目安では、本番環境は通常25〜30個のIPアドレス、非本番環境は6〜10個のIPアドレスを見込むとされています。また、サブネットでは予約IPも考慮する必要があります。(Microsoft Learn)
たとえば、4つの本番環境を同じEnterprise Policyに関連付け、各環境で30 IPを見込む場合は、単純計算で120 IPに予約分を加える必要があります。小さすぎるサブネットを選ぶと、後から環境追加や負荷増加に対応しにくくなります。
注意したいのは、委任後のサブネット範囲変更です。公式FAQでは、Microsoft.PowerPlatform/enterprisePolicies に委任されたサブネットのIPアドレス範囲は、機能利用中には変更できないと説明されています。変更すると構成が壊れ、環境が停止する可能性があるため、変更するには機能を外してから再構成する必要があります。(Microsoft Learn)
リージョンはPower Platform環境に合わせる
VNetやサブネットは、Power Platform環境に関連付くAzureリージョンに作成する必要があります。日本の場合、対応するAzureリージョンは japaneast と japanwest です。Power Platformの地域によっては2つのAzureリージョンが必要になり、これは本番環境だけでなく非本番環境にも適用されます。(Microsoft Learn)
ここで失敗しやすいのは、「普段使っているAzureリージョン」にVNetを作ってしまうことです。たとえば日本のPower Platform環境なのに、既存の都合でEast USのVNetへ直接関連付けようとしても、要件と合わない可能性があります。別リージョンのリソースへ接続したい場合は、Power Platform環境側のリージョンにVNetを用意し、VNet Peeringなどで接続先ネットワークへ橋渡しする設計を検討します。(Microsoft Learn)
セットアップの基本手順
PowerShellで進める場合、公式手順では Microsoft.PowerPlatform.EnterprisePolicies モジュールを利用します。まずモジュールをインストールし、VNetとサブネットをPower Platform向けに準備します。(Microsoft Learn)
Install-Module Microsoft.PowerPlatform.EnterprisePolicies
Import-Module Microsoft.PowerPlatform.EnterprisePolicies既存VNetを使う場合の例は次のとおりです。
New-VnetForSubnetDelegation `
-SubscriptionId "00000000-0000-0000-0000-000000000000" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet"新しくVNetを作る場合は、アドレス範囲、サブネット範囲、リージョンを明示します。
New-VnetForSubnetDelegation `
-SubscriptionId "00000000-0000-0000-0000-000000000000" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-ResourceGroupName "myResourceGroup" `
-CreateVirtualNetwork `
-AddressPrefix "10.0.0.0/16" `
-SubnetPrefix "10.0.1.0/24" `
-Region "westus"その後、委任済みサブネットを使ってEnterprise Policyを作成し、Power Platform環境へ関連付けます。
Enable-SubnetInjection `
-EnvironmentId "00000000-0000-0000-0000-000000000000" `
-PolicyArmId "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.PowerPlatform/enterprisePolicies/myPolicy"手動で進める場合は、Azureサブスクリプションで Microsoft.Network と Microsoft.PowerPlatform のリソースプロバイダーを登録し、サブネットを Microsoft.PowerPlatform/enterprisePolicies に委任します。その後、ARMテンプレートでEnterprise Policyを作成し、Power Platform管理センターの「Security」からAzure Virtual Network policiesを環境に割り当てます。(Microsoft Learn)
PowerShellと手動設定の使い分け
| 方法 | 向いているケース | 注意点 |
|---|---|---|
| PowerShell | 複数環境へ展開する、手順を自動化したい、設定を再現可能にしたい | 実行アカウントのAzure権限とPower Platform権限を確認する |
| 手動設定 | 初回検証、Azure管理者と画面を見ながら確認したい | ARMテンプレートのパラメーター入力ミスに注意する |
| IaC化 | 本番展開、監査、変更管理を重視する | Enterprise Policy、サブネット、DNS、Firewallをまとめて管理する設計が必要 |
本番導入では、初回だけ手動で理解し、その後はPowerShellやIaCで再現できる形にしておくと安全です。特に複数リージョン、複数環境、複数サブネットを扱う場合、画面操作だけでは差分管理が難しくなります。
移行前にやるべき通信棚卸し
既存環境を移行する場合は、いきなり本番環境へEnterprise Policyを関連付けないでください。先に、プラグイン、クラウドフロー、カスタムコネクタ、接続参照、環境変数を洗い出します。
| 棚卸し対象 | 確認内容 | 判断基準 |
|---|---|---|
| Dataverseプラグイン | 外部HTTP呼び出し、SQL接続、Key Vault参照 | Private Endpoint化できるか、ポートと名前解決が通るか |
| Power Automate | 対応コネクタ、接続先URL、認証方式 | VNet対応コネクタか、公開API利用が残るか |
| カスタムコネクタ | ベースURL、認証、証明書 | Private DNSで名前解決できるか |
| Azure PaaS | SQL、Storage、Key Vault、Queueなど | Private EndpointとPrivate DNS Zoneが正しく構成されているか |
| オンプレミスAPI | ExpressRoute、DNS、Firewall | VNetから到達可能か、TLS証明書が信頼されるか |
移行の判断基準は明確です。接続先をパブリック公開しなくても名前解決と通信が成立するかを確認します。これが確認できない状態で有効化すると、「ネットワーク的には安全になったが業務処理が止まる」という典型的な失敗につながります。
展開時に失敗しやすいポイント
パブリックエンドポイントへの通信が突然失敗する
仮想ネットワークサポートを有効化すると、対応サービスのリクエストは委任済みサブネットで実行され、NSGやFirewallなどのネットワークポリシーの影響を受けます。公式ドキュメントでも、公開リソースへの呼び出しが壊れ始める可能性があると説明されています。(Microsoft Learn)
対策は、通信先ごとに次のどちらかを選ぶことです。
| 通信先 | 推奨対応 |
|---|---|
| Azure内の重要リソース | Private Endpoint化し、Private DNS Zoneをリンクする |
| 社内システム | ExpressRouteやVPN経由でVNetから到達できるようにする |
| 外部SaaS API | NAT GatewayやFirewallで明示的にアウトバウンド許可する |
| 不要な外部通信 | プラグインやフローから削除する |
インターネット向け通信自体は既定で可能とされていますが、組織として制御・保護するためにAzure NAT Gatewayの利用が推奨されています。(Microsoft Learn)
DNSがパブリックIPを返してしまう
Private Endpointを作成しても、DNSがパブリックIPを返していると、想定どおりプライベート接続になりません。トラブルシューティング手順では、Test-DnsResolution を使って、Power Platform環境のコンテキストから名前解決を確認できます。(Microsoft Learn)
Azure SQLであれば privatelink.database.windows.net、Key Vaultであれば privatelink.vaultcore.azure.net のように、サービスに応じたPrivate DNS Zoneが必要です。Private DNS Zoneを作っただけで満足せず、対象VNetへリンクされているか、Aレコードが正しいかまで確認してください。
TCP接続は成功するがアプリが動かない
Test-NetworkConnectivity でTCP接続が成功しても、アプリケーションが正常に動くとは限りません。ファイアウォールがHTTPSの中身をブロックしている、認証に失敗している、TLS証明書が信頼されていない、といったケースがあります。公式のトラブルシューティングでは、TLSハンドシェイク確認用に Test-TLSHandshake も案内されています。(Microsoft Learn)
特にオンプレミスAPIで自己署名証明書や社内CA証明書を使っている場合は注意が必要です。Power Platform側では、公的に信頼された証明書チェーンが求められ、独自のルートCAを追加することはできないと説明されています。(Microsoft Learn)
Enterprise Policyを簡単に外せると思ってしまう
Power Platform管理センターからポリシーを割り当てることはできますが、環境からEnterprise Policyを削除する場合はPowerShellの Disable-SubnetInjection を使う必要があります。公式セットアップ手順でも、この点は重要事項として明記されています。(Microsoft Learn)
Disable-SubnetInjection -EnvironmentId "00000000-0000-0000-0000-000000000000"本番環境で切り戻しが必要になった場合に備えて、無効化手順、影響範囲、実行権限を事前に運用手順書へ入れておきましょう。
導入判断の基準
Power Platformの仮想ネットワークサポートは、すべての環境に無条件で導入すべきものではありません。次の条件に当てはまる場合は、優先して検討する価値があります。
| 導入を検討すべきケース | 理由 |
|---|---|
| Azure SQL、Storage、Key Vaultなどをパブリック公開したくない | Private Endpoint中心の構成にしやすい |
| Dataverseプラグインから社内APIを呼び出している | ExpressRouteやVNet経由で閉域接続しやすい |
| 金融、医療、製造などネットワーク制御が厳しい | アウトバウンド経路と通信先を管理しやすい |
| IP許可リスト運用が複雑化している | Azureの広いIP範囲許可に頼らない構成へ移行しやすい |
| 複数環境を標準化して展開したい | Enterprise Policyとサブネット設計を共通化できる |
一方で、外部SaaS APIを多く呼び出す環境や、対応していないコネクタを多用している環境では、事前検証の工数が大きくなります。まずはSandboxやDeveloper環境で、代表的な通信パターンを検証してから本番へ展開するのが現実的です。
管理者・開発者向けチェックリスト
本番展開前には、最低限次の項目を確認してください。
| 分類 | チェック項目 |
|---|---|
| 環境 | 対象環境がManaged Environmentsである |
| 環境種別 | Production、Default、Sandbox、Developerのいずれかである |
| リージョン | Power Platform環境に対応するAzureリージョンにVNetを作成している |
| 高可用性 | 2リージョンが必要な地域では、両方のVNetとサブネットを準備している |
| サブネット | 本番25〜30 IP、非本番6〜10 IPを目安に余裕を持っている |
| 委任 | サブネットを Microsoft.PowerPlatform/enterprisePolicies に委任している |
| DNS | Private EndpointのFQDNがプライベートIPへ解決される |
| NAT | インターネット向け通信を許可する場合、NAT GatewayやFirewallで制御している |
| 証明書 | 接続先HTTPSサーバーが公的に信頼された証明書を使っている |
| アプリ | プラグイン、フロー、コネクタの接続先URLを棚卸ししている |
| 権限 | Azure側のネットワーク権限とPower Platform管理者権限を用意している |
| 切り戻し | Disable-SubnetInjection を含む手順を準備している |
| 検証 | Power Platform管理センターの環境履歴でStatusがSucceededになることを確認している |
まず何から始めるべきか
Power Platformの仮想ネットワークサポートを検討するなら、最初にやるべきことは設定作業ではなく、通信経路の見える化です。対象環境のプラグイン、コネクタ、フローがどのリソースへ接続しているかを一覧化し、Private Endpoint化する接続、NAT経由で許可する接続、廃止する接続に分類してください。
そのうえで、Azure管理者はリージョンとサブネットサイズを決め、Power Platform管理者はManaged Environments化とEnterprise Policyの関連付け手順を確認します。開発者は、URL、DNS、TLS、認証の変更が必要な処理を修正します。
Power Platformの仮想ネットワークサポートは、うまく設計すればDataverseやPower Automateから社内・Azureリソースへ安全に接続する強力な選択肢になります。ただし、ネットワーク、DNS、証明書、アプリ実装がそろって初めて安定します。まずは非本番環境で代表的な通信を検証し、失敗パターンを潰してから本番展開へ進めましょう。
コメント