Power Platform の委任サブネット（仮想ネットワーク サポート）で作る閉域接続の構成例
Power Platform（以下、PP）の業務アプリやフローから、社内の API・DB、Azure の VM や PaaS に安全に接続したい。こうした場面で使えるのが、Power Platform の「仮想ネットワーク サポート」と Azure の「サブネット委任」です。対応コネクタや Dataverse プラグインの送信通信を、自社の Azure VNet 内のサブネットから開始できるため、接続先をインターネットに公開せずに連携できます。
まず、この組み合わせで何ができるのかと、基本の通信の仕組みを紹介します。その後、基本構成の接続範囲を広げる応用として、VNet ピアリング、VNet 間 VPN、オンプレミス向け S2S VPN、ExpressRoute、ハブのゲートウェイ共有を順に見ていきます。最後に利用者のアクセス経路を整理し、ディシジョンツリーで採用候補を選びます。
仮想ネットワーク サポートとサブネット委任でできること
Power Platform の仮想ネットワーク サポートは、対応コネクタやプラグインからの通信を、自社の VNet 内のサブネットから送り出せるようにする機能です。そのために、次の2段階で設定します。
- Azure 側で「このサブネットを PP の処理に使ってよい」と設定する。 これが「サブネット委任」です。サブネットの委任先として
Microsoft.PowerPlatform/enterprisePoliciesを指定します。この名前は、Azure 上で Power Platform 用の委任先を識別するためのものです。 - 「どの PP 環境が、どのサブネットを使うか」を指定する。 サブネットの情報を「エンタープライズ ポリシー」という Azure のリソースに登録し、そのポリシーを対象の PP 環境に関連付けます。日本リージョンの例では、東日本と西日本のサブネットを登録します。
この設定がそろうと、対象の PP 環境の対応コネクタやプラグインは、登録したサブネットのプライベート IP を送信元として、社内 API や DB へ通信できるようになります。
この役割分担は、Power Platform の VNet サポート概要と Azure のサブネット委任で確認できます。その結果、次のことができます。
- 非公開の API・DB を業務に組み込む：対応コネクタやプラグインから、VM のプライベート IP や PaaS のプライベートエンドポイントへ接続する。
- 自社のネットワーク ポリシーで送信を管理する：委任サブネット側の NSG、ルート、DNS、必要に応じた Firewall で、接続先と経路を制御する。
- Azure のネットワーク接続を使って範囲を広げる：基本は VNet 内の接続で、別の VNet やオンプレミスは後述するピアリング・VPN・ER でつなぐ。
業務での利用例
| ケース | Power Platform 側 | 接続先 | この機能が効く理由 |
|---|---|---|---|
| 現地拠点の基幹データを業務アプリで参照・更新 | Power Apps（SQL Server コネクタ） | VM 上の SQL Server や ERP の DB | DB をインターネットに公開せずにアプリ化できる |
| 社内 API を使った承認・通知フロー | Power Automate（カスタム コネクタ、HTTP with Microsoft Entra ID） | パブリック アクセス無効の App Service | API を閉じたまま承認や集計を自動化できる |
| データを特定リージョンに置いたまま業務処理 | Power Apps / Power Automate | Azure SQL Database（プライベートエンドポイント） | データの保存場所を変えずに扱える |
| 社内情報を答える問い合わせエージェント | Copilot Studio（対応コネクタ、Azure AI Search） | 社内 API や検索インデックス | 社内データを外部公開せずにエージェントへ組み込める |
| Dataverse のデータ変更を社内システムへ連携 | Dataverse プラグイン | VM や App Service 上の連携 API | 在庫や受注などの同期を閉域のまま実行できる |
基本の仕組み：PP の処理を委任サブネットから送信する
まずは、接続先が委任サブネットと同じ VNet にある場合を考えます。この段階では、別ネットワークに接続するためのピアリングや VPN Gateway は登場しません。委任サブネットは PP の対応処理の送信元、VM やプライベートエンドポイントはその通信の接続先です。VM やプライベートエンドポイントは、PP の委任サブネットとは別のサブネットに配置します。
Azure のサブネット委任だけで PP との関連付けや別ネットワークへの接続が完成するわけではありません。エンタープライズ ポリシー、対応サービスの設定、DNS・経路・認証がそろって初めて連携できます。また、対象は対応コネクタ・プラグインの送信処理であり、PP の画面や利用者端末そのものを VNet 内へ移す機能ではありません。
仕組み
- 利用者が VNet 内のサブネットを
Microsoft.PowerPlatform/enterprisePoliciesに委任し、エンタープライズ ポリシーを介して Power Platform 環境に関連付けます。 - 環境が使われ始めると、プラグインやコネクタの処理を実行するコンテナーが委任サブネットに挿入され、そのサブネットの IP アドレスを取得します。
- そのため、Power Platform からの通信は VNet 内のリソースと同じように扱われ、NSG やファイアウォール、ルートテーブルといった利用者側のネットワーク ポリシーがそのまま適用されます。
- 1 つの環境に関連付けるエンタープライズ ポリシーは 1 つです。日本リージョンの例では、そのポリシーに東日本と西日本の委任サブネットを登録します。ほかの顧客の環境がそのサブネットを使うことはありません。
利用前に確認する条件と制約
- 対象の環境がマネージド環境であること。
- Power Platform テナントに Azure サブスクリプションが関連付けられていること。
- 環境の種類が運用、既定、サンドボックス、開発者のいずれかであること（試用版と Dataverse for Teams は対象外）。
- Power Platform 環境のリージョンに対応する 2 つの Azure リージョンの両方に VNet を用意し、サブネットを委任すること。フェールオーバーに備えるためで、たとえば日本リージョンなら japaneast と japanwest の組み合わせになります。
サブスクリプションとリソース グループの要件
結論として、Learn には「VNet とエンタープライズ ポリシーを同じサブスクリプションやリソース グループに置かなければならない」という明示的な制限は書かれていません。ただし、公式手順の例はすべて同じサブスクリプション・同じリソース グループで作成しています。
| 対象 | 同一である必要は？ | 補足 |
|---|---|---|
| Azure サブスクリプションと Power Platform テナント | 同じテナントであることが必要 | VNet サポートを有効にするには、Power Platform テナントに Azure サブスクリプションを関連付ける必要があります。 |
| エンタープライズ ポリシーと委任 VNet（A・B） | 明示的な制限の記載なし | ポリシーは作成先のサブスクリプションとリソース グループを指定し、VNet はサブスクリプションとリソース グループを含む完全なリソース ID で個別に指定します。 |
| VnetA と VnetB | 明示的な制限の記載なし | 条件として明記されているのは「対応する別々の Azure リージョンに置くこと」です。 |
| 接続先の VNet（ピアリング先） | 不要 | 委任とは関係なく、Azure の VNet ピアリングの仕様に従います。ピアリングは別サブスクリプションや別テナントの VNet とも構成できます。 |
実務上は、エンタープライズ ポリシーと委任 VNet（A・B）を同じサブスクリプションにまとめておくのが無難です。公式手順のとおりに進められ、権限やリソース プロバイダーの管理も簡単になります。
分ける場合は、次の点を確認してください。
- 各サブスクリプションで、リソース プロバイダー
Microsoft.NetworkとMicrosoft.PowerPlatformを登録する。 - 作業者に、各 VNet に対するネットワーク共同作成者相当の権限と、ポリシーを作成するリソース グループへの権限を付与する。
- 公式の例から外れる構成になるため、本番適用前に検証環境で、ポリシーの作成と環境への関連付けまで通しで確認する。
対応しているサービス
対応しているのは Dataverse プラグインと、一部のコネクタです。コネクタは SQL Server、Azure SQL Data Warehouse、Azure Queues、カスタム コネクタ、Azure Key Vault、Azure File Storage、Azure Blob Storage、HTTP with Microsoft Entra ID（事前承認済み）、Snowflake、Databricks、Azure AI Search が対象です。
一方で、次のものは対象外です。
- Power BI と Power Platform データフロー（これらは VNet データ ゲートウェイを使います）
- コネクタを使う Dataverse ローコード プラグイン
- オンプレミス データ ゲートウェイ経由の SQL Server 接続
- Azure 対応プラグイン（Azure-aware plugins）
知っておきたい注意点
- サブネットのサイズ：目安は運用環境で 25〜30 IP、サンドボックスや開発者環境で 6〜10 IP です。これにサブネットの予約 5 IP を加えて見積もります。
- 後から変更できない設定：委任後は、使用中にサブネットの IP 範囲や VNet の DNS サーバー設定を変更できません。変更するには、いったんサブネット挿入を無効化する必要があります。
- インターネット向け通信：委任後もインターネット向けの通信は既定で可能です。NAT Gateway は送信元のパブリック IP を固定するために使い、通信の許可・拒否は NSG や Azure Firewall で制御します。Firewall を経由させる場合は、UDR でその経路を設定します。Power Platform の送信接続のベスト プラクティス、NAT Gateway のトラフィック ルーティングを参照してください。
- TLS 証明書：接続先は、よく知られたルート CA までのチェーンを含む証明書を提示する必要があります。独自のルート CA は追加できません。
- 既存の接続先 URL：有効化すると、プラグインやコネクタの通信はネットワーク ポリシーに従います。公開エンドポイントを前提にした URL や接続は、事前にプライベート接続向けに見直します。
応用：別の VNet・オンプレミスへ接続範囲を広げる
基本構成で PP の送信元を VNet に統合すると、その先には Azure のネットワーク接続方式を利用できます。公式ホワイトペーパーの Technical architectureは、ピアリング、ExpressRoute、VPN Gateway で接続範囲を別の VNet やオンプレミスへ広げられると説明しています。
| 応用 | 接続先・目的 | 基本構成に追加するもの |
|---|---|---|
| 応用1：VNet ピアリング | 別の Azure VNet の VM・PaaS | A–C、B–C のピアリング |
| 応用2：VNet 間 VPN | Azure VNet 同士を IPsec トンネルでつなぐ | 各 VNet の VPN Gateway と接続 |
| 応用3：S2S VPN | インターネット経由でオンプレミスへつなぐ | VPN Gateway と拠点の VPN 装置 |
| 応用4：ExpressRoute | プライベート接続でオンプレミスへつなぐ | ER 回線と ExpressRoute Gateway。必要に応じて IPsec |
| 応用5：ハブ共有 | 既存ゲートウェイを複数 VNet で利用する | ピアリングとゲートウェイ トランジット |
いずれの応用でも、PP 環境に対応するリージョンの委任サブネットは維持します。接続方式を追加しても対応コネクタの範囲は増えず、認証・TLS の条件も変わりません。以下は2026年10月9日に公式資料を照合した構成案であり、実環境での疎通試験結果ではありません。
応用1：VNet ピアリングで別の VNet へつなぐ
日本リージョンの PP 環境から、東南アジアの別 VNet にある接続先を使う例で、ピアリングの応用を具体化します。リージョン、VNet 名、アドレスはすべて説明用に設定したものです。
想定する条件は次のとおりです。
- Power Platform 環境は日本リージョンにある。
- 接続したい VM と PaaS アプリは、東南アジア リージョンの VnetC にある。
- 委任サブネットは、日本リージョンに対応する東日本（VnetA）と西日本（VnetB）に作る。
- エンタープライズ ポリシーと VnetA・VnetB は同じサブスクリプションにまとめる。VnetC は東南アジア拠点が管理する別のサブスクリプションにあってもよい（ピアリングは別サブスクリプション間でも構成できるため）。
委任サブネットを置く VNet は環境のリージョンに対応する Azure リージョンに置く必要があるため、VnetC に直接委任することはできません。そこで、VnetA と VnetB の両方から VnetC へ VNet ピアリングでつなぎます。これは Learn の FAQ でも、別リージョンのリソースに接続する方法として案内されている構成です。
構成図
実線が通常時、破線が障害時の経路です。点線は DNS ゾーンのリンク先（VnetA・B・C）を示します。
通信の流れ
Power Platform は、通常は東日本の VnetA の委任サブネットから送信し、障害時は西日本の VnetB に切り替わります。どちらからもグローバル ピアリング経由で VnetC の VM と PaaS アプリに閉域で到達します。名前解決は Azure DNS とプライベート DNS ゾーンで行い、PaaS アプリはプライベートエンドポイント経由でのみ公開します。
リソース一覧
アドレスはすべて例です。3 つの VNet のアドレス空間が重複しないことだけは必須条件です。
| VNet / リソース | リージョン | サブネット（例） | 用途 |
|---|---|---|---|
| VnetA 10.10.0.0/16 | 東日本 | snet-pp 10.10.0.0/24 | Power Platform 委任（プライマリ） |
| snet-test 10.10.1.0/24 | 名前解決・疎通確認用の検証 VM | ||
| VnetB 10.20.0.0/16 | 西日本 | snet-pp 10.20.0.0/24 | Power Platform 委任（フェールオーバー） |
| snet-test 10.20.1.0/24 | 名前解決・疎通確認用の検証 VM | ||
| VnetC 10.30.0.0/16 | 東南アジア | snet-vm 10.30.1.0/24 | 業務 VM |
| snet-pe 10.30.2.0/24 | PaaS アプリと DB のプライベートエンドポイント | ||
| エンタープライズ ポリシー | 日本 | ― | 委任サブネット A・B を Power Platform 環境に関連付け |
| プライベート DNS ゾーン | グローバル | ― | VM 用（例：corp.internal）と privatelink.* を A・B・C にリンク |
委任サブネットの /24 は、複数環境の追加を見込んだ例です。前述の目安（運用環境 25〜30 IP＋予約 5 IP）から、環境数に合わせて決めてください。
設定のポイント
Power Platform
- 対象環境をマネージド環境にする。
- VnetA・VnetB の snet-pp を委任し、両方を 1 つのエンタープライズ ポリシーに登録して環境へ関連付ける。
- 使うコネクタやプラグインが対応サービスに含まれるかを事前に確認する。
ネットワーク
- グローバル ピアリングを A–C と B–C の 2 本作る。A–B 間は不要。
- A・B に UDR を設定する場合は、10.30.0.0/16 宛てが意図した経路（直接ピアリング、またはハブの Firewall）を通るようにする。
- ピアリングは非推移的なので、A–C のピアリングだけで、C の先の別 VNet やオンプレミスまで到達できるとは考えない。VPN Gateway の共有には、後述するゲートウェイ トランジットなどの追加設定が必要。
- インターネット向けの送信元 IP を固定したい場合は、委任サブネットに NAT Gateway を関連付ける。送信先の許可・拒否は NSG で制御し、Azure Firewall を使う場合は UDR で Firewall を経由する経路を設定する。
DNS
- Power Platform は、委任サブネットがある VNet（A・B）の DNS 設定で名前解決する。
- A・B・C は既定の Azure DNS を使い、プライベート DNS ゾーンを 3 つの VNet すべてにリンクする。
- VM 用ゾーン（例：corp.internal）は C を自動登録付きでリンクし、A・B は解決用としてリンクする。
- PaaS 用の privatelink.* ゾーン（例：App Service なら privatelink.azurewebsites.net、SQL Database なら privatelink.database.windows.net）も A・B にリンクする。
- 委任後は使用中に VNet の DNS サーバー設定を変更できない。DNS Private Resolver などのカスタム DNS を使う可能性があるなら、委任前に決めておく。
セキュリティ
- C の NSG で、送信元 10.10.0.0/24 と 10.20.0.0/24（委任サブネット）から必要なポートだけを許可する。
- B 側の許可漏れはフェールオーバー時まで表面化しないため、A と B のルールは同じテンプレートで管理する。
- C の VM で動くサービスの TLS 証明書は、よく知られたルート CA までのチェーンを含むものにする。
PaaS アプリ
- アプリ（例：App Service）と DB は snet-pe にプライベートエンドポイントを作り、パブリック ネットワーク アクセスを無効にする。
- コネクタからは公開 FQDN（例：app.azurewebsites.net）で呼び出す。プライベート DNS ゾーンにより内部 IP に解決され、証明書の名前とも一致する。
- プライベートエンドポイントのサブネットでネットワーク ポリシーを有効にすると、エンドポイントにも NSG を適用できる。
動作確認チェックリスト
- [ ] A・B・C のアドレス空間が重複していない
- [ ] A–C、B–C のピアリング状態がどちらも「接続済み」
- [ ] A・B の検証 VM から、VM の FQDN と PaaS の FQDN が 10.30.x.x に解決される
- [ ] A・B の検証 VM から、C の VM と PaaS へ必要なポートで接続できる
- [ ] PaaS のパブリック アクセスを無効にしても、A・B から接続できる
- [ ] Power Platform 管理センターで環境にエンタープライズ ポリシーが関連付いている
- [ ] Power Automate などのコネクタから C の VM と PaaS に接続できる
- [ ] B 側の NSG・DNS リンク・ピアリングが A と同じ設定になっている
切り分けには、Learn で公開されている診断用 PowerShell モジュール（Microsoft.PowerPlatform.EnterprisePolicies）も使えます。
応用2：A・B と C を VNet 間 VPN で直接つなぐ
記事の構成例をピアリングなしで実現する場合は、VnetA・VnetB・VnetC にそれぞれ VPN Gateway を置き、A–C と B–C の VNet-to-VNet 接続を作ります。Power Platform 環境に関連付ける委任サブネットは、引き続き東日本の A と西日本の B です。VPN を使っても、このリージョン要件は変わりません。
| 送信元 | 通信経路 | 接続先 |
|---|---|---|
| VnetA の snet-pp | A の VPN Gateway → VNet 間 VPN → C の VPN Gateway | C の VM またはプライベートエンドポイント |
| VnetB の snet-pp | B の VPN Gateway → VNet 間 VPN → C の VPN Gateway | 同じ接続先。B 側も独立して到達できるようにする |
VNet 間 VPN は、IPsec/IKE で暗号化され、通信はインターネットではなく Microsoft Azure のバックボーンを通ります。異なる Azure リージョンの VNet 間でも利用できます。VPN Gateway FAQ の VNet-to-VNet 接続で確認できます。
設定では次を確認します。
- 各 VNet に、委任サブネットとは別の
GatewaySubnetを作る。たとえば A は10.10.255.0/27、B は10.20.255.0/27、C は10.30.255.0/27。他のサブネットと重複させない。 - VPN Gateway は ルートベースを使用し、A–C と B–C の双方で接続を設定する。各接続ペアの共有キーを一致させ、接続状態が
Connectedになることを確認する。 - C 宛てだけでなく、C から A・B の委任サブネットへの戻り経路も確認する。既存の UDR や Firewall の設定で、片方向だけが別経路へ向かわないようにする。
GatewaySubnetに NSG を付けない。0.0.0.0/0の UDR を置いたり、同サブネットの BGP ルート伝播を無効にしたりしない。通信の許可・拒否は委任サブネット、接続先サブネット、Firewall などで設計する。- 別サブスクリプションの VNet 間接続は、公式の PowerShell 手順を使う。VNet-to-VNet のポータル手順は同じサブスクリプションを前提としている。
手順は VNet-to-VNet 接続の構成、サブネットの要件は VPN Gateway の設定を参照してください。
DNS は VPN 接続とは別に設定します。 A・B で既定の Azure DNS を使う場合は、C のプライベートエンドポイントに対応する同じプライベート DNS ゾーンを A・B にもリンクし、必要な A レコードを管理します。VPN トンネルが接続済みでも、FQDN が公開 IP に解決されれば意図したプライベート接続にはなりません。カスタム DNS を使う場合は、DNS フォワーダーや Azure DNS Private Resolver への到達経路と転送設定を確認します。プライベートエンドポイントの DNS 統合を参照してください。
オンプレミスへつなぐ：インターネットと ER の2つの経路
オンプレミスへ接続する場合は、インターネット経由の S2S VPN と ExpressRoute（ER）の Azure プライベート ピアリングを分けて考えます。どちらも、委任サブネットから社内 API・DB のプライベート IP へ到達する構成です。Power Platform の VNet サポート概要でも、ExpressRoute によるオンプレミス リソースとの接続が案内されています。
| パターン | オンプレミスまでの経路 | Azure 側のゲートウェイ | 暗号化 |
|---|---|---|---|
| インターネット経由 | 公衆インターネット上の S2S VPN | VPN Gateway | IPsec/IKE で暗号化 |
| ExpressRoute 経由 | プロバイダーのプライベート接続と Azure プライベート ピアリング | ExpressRoute Gateway | ER 自体は既定で暗号化しない。TLS や追加の IPsec を検討 |
インターネット経由は応用3、ER 経由は応用4で説明します。その後、応用5でゲートウェイをハブに集約する構成を紹介します。
応用3：オンプレミスへインターネット経由の Site-to-Site VPN でつなぐ
接続先が Azure の VNet ではなく社内拠点なら、A・B の VPN Gateway と拠点の VPN 装置を Site-to-Site（S2S）VPNで接続する構成を検討できます。Power Platform の対応コネクタやプラグインは、委任サブネットから VPN 経由で社内 API や DB のプライベート IP に接続します。A・B のどちらからも、接続先・社内 DNS に到達できるようにします。
拠点側の VPN 装置、ローカル ネットワーク ゲートウェイに登録する接続先のアドレス範囲、IPsec/IKE の設定、拠点から A・B への戻り経路が必要です。社内 FQDN の名前解決には、VNet のカスタム DNS または条件付き転送を設計します。接続先の認証方式と TLS 証明書が Power Platform 側の要件に合うことも確認してください。VPN Gateway の概要、対応 VPN 装置と接続条件を参照してください。
ここでいう S2S VPN は、通常、インターネット上に作る暗号化トンネルです。社内 API や DB をインターネットに公開せずに接続できますが、ExpressRoute のような専用のプライベート接続と同じ意味の「閉域」ではありません。 公衆インターネットを経由しないこと自体が要件なら、この違いを踏まえて ExpressRoute のプライベート ピアリングなどを検討します。
応用4：オンプレミスへ ExpressRoute のプライベート接続でつなぐ
公衆インターネットを経由させない場合は、委任サブネット → ExpressRoute Gateway → ER 回線の Azure プライベート ピアリング → オンプレミスのルーター → 社内 API・DBという経路を構成します。VPN Gateway を使う応用3とは異なり、ER の VNet 接続には ExpressRoute Gateway を使用します。ExpressRoute 仮想ネットワーク ゲートウェイを参照してください。
図では A・B にそれぞれ ExpressRoute Gateway と専用の GatewaySubnet を作り、同じ ER 回線に接続しています。回線の SKU・接続先リージョン・接続数などの条件を確認し、A・B の両方を接続できる回線を選びます。ハブの ExpressRoute Gateway をピアリングとゲートウェイ トランジットで共有する構成も可能ですが、共有ハブ・回線・拠点ルーターが共通依存になる点を評価してください。
設定では、オンプレミスのアドレス範囲を BGP で Azure 側へ広告し、A・B の委任サブネットへの戻り経路も確保します。UDR・NSG・拠点のファイアウォールが往復の通信を妨げないこと、A・B から社内 DNS へ到達して接続先 FQDN をプライベート IP に解決できることを確認します。Power Platform のリージョン切り替えだけでは ER 回線や拠点の障害は解消しないため、必要な可用性に合わせて回線・接続拠点・ルーターの冗長化を設計します。
ER のプライベート接続と暗号化は別の要件です。 ER の通信は既定では暗号化されないため、API・DB の TLS を使用し、ネットワーク層の暗号化も必要なら ER 上に IPsec VPN を重ねる構成を検討します。ExpressRoute の暗号化を参照してください。
VPN Gateway を ER 経由で使う場合
S2S VPN はインターネット経由だけでなく、ExpressRoute のプライベート ピアリング上に構成することもできます。 この場合は ER 接続に加えて VPN Gateway と拠点の VPN 装置を用意し、VPN のトンネル終端にプライベート IP を使用します。ER を下位の通信経路、IPsec をその上の暗号化トンネルとして使う構成です。標準 IP ベースの VPN Gateway など、公式手順の前提条件を確認してください。
ER の直接経路と IPsec 経路が併存するため、暗号化を必須とする通信が直接経路へ流れないよう、Azure・オンプレミス両側でプレフィックスと経路優先順位を設計します。インターネット経由の S2S VPN を別の予備経路として用意する場合も、切り替え時の往復経路を確認します。ER プライベート ピアリング上の S2S VPNに構成条件とルーティングの説明があります。
ここで扱うのは、委任サブネットからオンプレミスへ向かう通信の Azure プライベート ピアリングです。利用者が Power Platform サービスへアクセスするための Microsoft ピアリングとは、通信の向きと接続先が異なります。
応用5：既存ハブの VPN Gateway を共有する
A・B それぞれに VPN Gateway を作らず、ハブ VNet にあるゲートウェイを共有する方法もあります。この場合は ピアリングとゲートウェイ トランジットの組み合わせであり、ピアリングを完全に置き換える構成ではありません。
ハブ側の AllowGatewayTransit と、A・B 側の UseRemoteGateways を設定し、ゲートウェイが接続するネットワークへのルートが委任サブネットまで伝播することを確認します。Basic SKU はゲートウェイ トランジットに対応しません。A・B の両経路を同じハブに依存させる場合は、Power Platform のリージョン切り替えとは別に、ハブ・ゲートウェイの障害への対策を設計してください。VPN ゲートウェイ トランジットの構成を参照してください。
C の VPN Gateway の先にあるオンプレミスなどへ、さらに VPN を中継する構成では、接続があるだけで到達可能とは判断しません。複数ゲートウェイを通る BGP トランジットを使う場合は、中間の VNet 間接続すべてで BGP を有効にし、接続先プレフィックスの広告と戻り経路を確認します。VPN Gateway FAQ の BGP とルーティングを参照してください。
この共有の考え方は ExpressRoute Gateway にも適用できます。ER を選んだ場合は、ハブの ER Gateway を A・B が利用する配置を検討し、回線への接続、ルート伝播、機能・容量と共通障害点を確認します。VPN over ER では ER と VPN の両方の経路・配置を評価してください。
各方式の比較と動作確認
| 方法 | 向いている接続 | 設計で確認する点 |
|---|---|---|
| VNet ピアリング | Azure の VNet 同士を直接つなぐ | ゲートウェイ不要。非推移性、両リージョンの経路、DNS を確認 |
| VNet-to-VNet VPN | Azure の VNet 同士を IPsec/IKE トンネルでつなぐ | 各 VNet の GatewaySubnet、VPN Gateway、接続設定が必要。SKU・共有帯域・費用を確認 |
| S2S VPN | オンプレミスの社内ネットワークへつなぐ | 拠点の VPN 装置、社内 DNS、往復の経路が必要。インターネット経由の暗号化通信 |
| ExpressRoute（Azure プライベート ピアリング） | 公衆インターネットを経由せずオンプレミスへつなぐ | ER 回線・ExpressRoute Gateway・BGP・DNS・回線冗長化が必要。暗号化は別に設計 |
| S2S VPN over ExpressRoute | ER 経由の通信に IPsec 暗号化を追加する | ER と VPN の両方が必要。暗号化されない直接経路への迂回を防ぐ |
| ピアリング＋ゲートウェイ トランジット | 既存ハブの VPN Gateway を A・B から共有する | ハブ側・スポーク側の設定、ルート伝播、ハブへの依存を確認 |
Azure の VNet 同士を接続するだけなら、まず既存のピアリング構成と比較します。VPN Gateway を選ぶ場合は、暗号化トンネルの必要性、既存ネットワークとの接続、ゲートウェイの運用負荷と費用を含めて判断します。
VPN 構成で追加する動作確認
- [ ] A・B の委任サブネットと GatewaySubnet、C・オンプレミスのアドレス範囲が重複していない
- [ ] A・B の両経路で VPN 接続が
Connectedになっている - [ ] 必要な接続先プレフィックスと A・B への戻り経路が設定されている
- [ ] A・B の検証 VM から、接続先 FQDN がプライベート IP に解決され、必要なポートへ接続できる
- [ ] 実際の Power Platform コネクタ・プラグインで、認証を含めて接続できる（検証 VM の成功だけでは完了としない）
- [ ] B 側の経路でも動作を確認し、単一のハブや C 側ゲートウェイが障害時の共通依存になっていないかを評価した
- [ ] VPN Gateway の帯域・接続数・遅延が業務処理に足りることを確認した
ExpressRoute 構成で追加する動作確認
- [ ] A・B の両方から、ER 経由でオンプレミスの接続先と社内 DNS に到達できる
- [ ] オンプレミス宛ての BGP 経路と、A・B の委任サブネット宛ての戻り経路がある
- [ ] Power Platform の実際のコネクタ・プラグインから、名前解決・認証・TLS を含めて接続できる
- [ ] ER 回線・拠点ルーターなどの障害時にも、必要な通信経路が確保される
- [ ] VPN over ER を使う場合は、暗号化を必須とする通信が IPsec 経路を通り、直接 ER 経路へ迂回しない
利用者アクセスの設計への影響
委任サブネットが制御するのは、対応コネクタ・プラグインから接続先へ向かう送信通信です。利用者のブラウザーや Power Apps クライアントから Power Platform へ向かう経路は、各構成とは独立して設計します。 以下は、利用者向けの ExpressRoute Microsoft ピアリングを別途構成していない場合の整理です。VNet サポート概要と、Power Platform 向け ExpressRoute のクライアント通信の設定を参照してください。
| 接続先への方式 | Power Platform から接続先への経路 | 利用者から Power Platform への接続 |
|---|---|---|
| VNet ピアリング（応用1） | 委任サブネット → ピアリング → C | 通常はインターネット経由の HTTPS。利用者が A・B・C に入る必要はない |
| VNet-to-VNet VPN（応用2） | 委任サブネット → A/B の VPN Gateway → C | 通常はインターネット経由の HTTPS。VNet 間 VPN への参加は不要 |
| インターネット経由の S2S VPN（応用3） | 委任サブネット → VPN Gateway → 拠点の VPN 装置 | 通常はインターネット経由の HTTPS。拠点との S2S VPN は利用者向け VPN ではない |
| ハブの VPN Gateway 共有（応用5） | 委任サブネット → ピアリング → ハブの VPN Gateway → 拠点 | 通常はインターネット経由の HTTPS。利用者をハブ経由にする必要はない |
| ExpressRoute のプライベート接続（応用4） | 委任サブネット → ER Gateway → Azure プライベート ピアリング → 拠点 | 通常はインターネット経由の HTTPS。Azure プライベート ピアリングだけでは利用者の通信は ER に切り替わらない |
| S2S VPN over ExpressRoute | 委任サブネット → ER 上の IPsec トンネル → 拠点 | 通常はインターネット経由の HTTPS。ER 上の IPsec は接続先への通信を暗号化する |
| ハブの ER Gateway 共有 | 委任サブネット → ピアリング → ハブの ER Gateway → 拠点 | 通常はインターネット経由の HTTPS。利用者向け ER の設定は別に必要 |
どの方式でも、利用者は Power Platform に Microsoft Entra ID で認証してアプリを利用し、対応コネクタ・プラグインの処理が委任サブネットから接続先を呼び出します。委任サブネットによって利用者端末から社内 API・DB へ直接アクセスできるようになるわけではありません。 ブラウザー内のコードが API を直接呼ぶ設計なら、端末側の DNS・ネットワーク経路・認証が別途必要です。在宅利用者の社内 VPN は、端末制御や社内プロキシの要件で必要になる場合がありますが、本記事のバックエンド接続方式から自動的に必須になるものではありません。
利用者の通信にも ExpressRoute を使いたい場合
社内ネットワークから Power Platform への利用者通信を ER 経由にする場合は、Microsoft ピアリングと、対象サービスへの BGP 経路・ルートフィルター・必要な NAT を別途設計します。応用4の Azure プライベート ピアリングとは別の設定です。自宅やモバイル回線の利用者は、社内ネットワークへ戻す経路を設けなければ、その ER 回線を使用しません。Power Platform と ExpressRoute のピアリングを参照してください。
Microsoft ピアリングでも、Power Platform 環境そのものに専用のプライベート IP が付くわけではなく、共有サービスの公開 IP へ Microsoft ネットワークの入口まで専用接続で到達します。管理ポータルや認証など、ER だけでは網羅できない関連サービスがあるため、利用者の全通信を ER のみにできるとは判断しません。 往路と復路でインターネット・ER が混在する非対称ルーティングにも注意します。ExpressRoute 採用時の考慮事項を参照してください。
利用者側のアクセスを絞りたい場合は、閉域化ではなく次の制御を組み合わせるのが一般的です。
- Entra ID の条件付きアクセス：社内ネットワークや準拠デバイスからのアクセスに限定する。
- Dataverse の IP ファイアウォール：環境へのアクセス元を特定の IP 範囲に限定する。
- テナント分離：他テナントとのコネクタ接続を制限し、データの持ち出しを防ぐ。
テナント分離はコネクタによるテナント間通信の制御であり、利用者端末の経路を制御するものではありません。経路とアクセス権・アクセス元制限を分けて確認してください。
まとめ
Power Platform の委任サブネットを使うと、接続先をインターネットに公開せずに、対応コネクタやプラグインからプライベート IP のリソースへ接続できます。環境のリージョンに対応する 2 つの Azure リージョンに委任サブネットを用意し、VNet ピアリング、VPN Gateway、ExpressRoute で接続範囲を拡張します。オンプレミスへは、インターネット上の暗号化トンネルである S2S VPN と、ER 経由のプライベート接続を選べます。ER 自体の暗号化は既定で無効なので、必要なら TLS や VPN over ER を組み合わせます。設計では、A・B 両方の往復経路と DNS をそろえること、対応サービスと認証・証明書の要件を確認することが重要です。
採用方式を決めるディシジョンツリー
次のツリーは、本記事の構成例から最初に比較・検証する候補を選ぶためのものです。特定の方式を一律に推奨する公式ルールではありません。まず対応コネクタ・プラグイン、環境、リージョンなどの前提条件を満たすことを確認してください。
図の判断を文章でたどると、次の順序です。
- 接続先が Azure VNet か、オンプレミスかを決める。 同じ委任 VNet 内なら、追加の VNet 間接続は不要です。
- 別の Azure VNet なら、まず VNet ピアリングを比較する。 VNet 間に IPsec トンネルが必要などの理由があれば、VNet-to-VNet VPN（応用2）を候補にします。IPsec が不要でも、組織のポリシーでピアリングを使えない場合は VPN の実現性を評価します。アドレス重複は、どちらでも自動的には解決しません。
- オンプレミスなら、公衆インターネット経由を許容できるかを確認する。 許容でき、帯域・遅延・可用性を満たせるなら S2S VPN（応用3）を候補にします。公衆インターネットを避ける、既存 ER を活用する、または回線品質・帯域の要件から ER を選ぶ場合は応用4へ進みます。
- ER 経由で、TLS に加えてネットワーク層の IPsec 暗号化も必要かを確認する。 不要なら ER の Azure プライベート ピアリング、必要なら VPN over ER を候補にします。後者では暗号化されない直接経路への迂回を防ぎます。
- ゲートウェイを既存ハブで共有できるかを判断する。 A・B の到達性、機能・容量、ルート伝播、共通障害点への対策を満たせるなら、ピアリングとゲートウェイ トランジットで VPN Gateway（応用5）または ER Gateway を共有します。満たせなければ A・B 個別のゲートウェイや適切な冗長ハブを用意します。共有は接続方式の上に重ねる配置の判断です。
- 利用者から Power Platform への経路を別に決める。 通常はインターネット経由の HTTPS と Entra ID 認証です。利用者通信にも ER を使う要件がある場合は Microsoft ピアリングを別途評価し、対象外の関連サービスや在宅利用者の経路も設計します。
最後に、A・B 両側の DNS・往復経路・認証・実際のコネクタによる疎通と、帯域・遅延・費用・障害時の動作を確認して採用を決めます。VPN と ER を併用する場合は、予備経路へ切り替わったときの通信要件も検証します。
参考リンク
Power Platform
- Microsoft Azure Virtual Network サポートの概要
- Power Platform の Virtual Network サポートを設定する
- Virtual Network サポートのホワイトペーパー
- 仮想ネットワークに関する問題のトラブルシューティング
- New-SubnetInjectionEnterprisePolicy（PowerShell リファレンス）
- マネージド環境の概要
- VNet データ ゲートウェイの概要
- Dataverse の IP ファイアウォール
- テナント間の受信と送信の制限（テナント分離）
Azure
- サブネットの委任とは
- 仮想ネットワーク ピアリング
- 異なるサブスクリプションの仮想ネットワーク ピアリングを作成する
- プライベート エンドポイントとは
- Azure プライベート エンドポイントの DNS 構成
- Azure Private DNS とは
- Azure NAT Gateway とは
- Azure のハブスポーク ネットワーク トポロジ
- VPN Gateway の概要
- ExpressRoute 仮想ネットワーク ゲートウェイ
- ExpressRoute の暗号化
- ER プライベート ピアリング上の S2S VPN
- VNet-to-VNet 接続の構成
- VPN Gateway の設定と GatewaySubnet
- VPN Gateway FAQ（VNet 間接続・BGP・制約）
- VPN ゲートウェイ トランジットの構成
- プライベートエンドポイントの DNS 統合
- 条件付きアクセスとは