Microsoft Power Platformから別テナントのバックエンドAPIへ閉域接続するための構成ガイド

Microsoft Power Platform（以下、Power Platform）から、別のMicrosoft Entra IDテナントで管理するバックエンドAPIへ、インターネットにAPIを公開せずに接続するには、通信経路と名前解決をどこに用意すればよいのでしょうか。

この記事では、次の要件を前提に構成を検討します。

  • Power Platform環境は日本リージョンに配置されている。
  • Power PlatformからバックエンドAPIを呼び出す。
  • APIは別のMicrosoft Entra IDテナントで管理されている。
  • APIをインターネットに公開せず、Azure Private Linkを使用して接続したい。
  • APIの名前解決にはプライベートDNSを利用する。

Power PlatformのAzure Virtual Network（以下、VNet）統合と、接続元テナントに配置するPrivate Endpointを組み合わせる構成が基本です。

日本リージョンでは、東日本（Japan East）と西日本（Japan West）の両方にVNetと委任サブネットを用意します。この記事は公式資料に基づく設計ガイドであり、実環境での構築・疎通試験の結果を示すものではありません。

目次

1. 全体アーキテクチャ

以下は、接続先がAzure App ServiceまたはAzure FunctionsでホストされているAPIである場合の構成例です。

テナントAの東日本・西日本の委任サブネットから各Private Endpointを通り、テナントBのAPIへHTTPSで接続する
図1：両リージョンにPrivate Endpointを置く論理構成例。API自体のリージョン冗長化は別途設計します。クリックすると拡大できます。

この構成には、役割の異なる4つの技術が使われます。

技術 担当する役割
VNet統合 Power PlatformからのAPI通信をAzure VNet内に出す
Private Endpoint 接続元VNet内にAPIのプライベート接続先を作る
クロステナントPrivate Link 別テナントで管理されているAPIとのプライベート接続を確立する
Private DNS APIのホスト名をPrivate EndpointのプライベートIPに解決する

特に重要なのは、VNet統合は通信の出口、Private Endpointは接続先への入口という役割の違いです。[1][3]

2. Power PlatformのVNet統合

Power Platformは通常、Microsoftが管理するサービス基盤で実行されるため、Azureの仮想マシンのように自分のVNetに直接配置することはできません。

そこで使用するのが、Power PlatformのAzure Virtual Networkサポート（サブネット委任）です。

この機能では、利用者が所有するAzure VNetのサブネットをPower Platformに委任し、サポートされるコンポーネントからのAPI通信をそのサブネット経由で実行させます。

日本リージョンで必要なリソース

項目 Japan East Japan West
Azure VNet 必要 必要
Power Platform委任サブネット 必要 必要
サブネット委任先 Microsoft.PowerPlatform/enterprisePolicies 同左
エンタープライズポリシー 両リージョンのサブネットを関連付ける 同左
Private Endpoint ネットワーク設計に応じて配置 ネットワーク設計に応じて配置
DNS解決経路 必要 必要

Microsoftは、日本のPower Platform環境に対してjapaneastとjapanwestを対応リージョンとして明記しています。[1][2]

両リージョンに委任サブネットを用意することは、Power Platform側のフェールオーバーを考慮するための要件です。バックエンドAPI自体の冗長化とは別の話になります。

VNet統合の構築手順

  1. AzureにJapan EastとJapan WestのVNetを作成する。
  2. Power Platform用サブネットをそれぞれ用意し、サブネット委任を設定する。
  3. Azure上にエンタープライズポリシー（Enterprise Policy）を作成し、両サブネットを登録する。
  4. Power Platform環境をマネージド環境に設定し、適用するライセンス条件を確認する。
  5. Enterprise PolicyをPower Platform環境に関連付け、VNetサポートを有効化する。
  6. API通信の経路とDNS解決を検証する。

両委任サブネットは利用可能なIPアドレス数をそろえます。VNetサポートの有効化・無効化では最大30分の不安定化や利用不可が生じる場合があるため、既存環境への適用時には作業時間も確保します。[2]

注意点として、VNet統合はすべてのPower Platformコンポーネントに無条件で適用されるわけではありません。

Microsoftのドキュメントでは、Microsoft Dataverse（以下、Dataverse）のプラグイン、カスタムコネクタ、HTTP with Microsoft Entra ID (preauthorized)などが対象として挙げられています。実際に使うコネクタが対応しているか、個別に確認する必要があります。

また、VNet統合の有効化により、従来はインターネット経由でアクセスできていた接続先が、ネットワーク制御によって通信できなくなることがあります。既存のフローやプラグインへの影響評価も必要です。[2]

3. クロステナントPrivate Linkの仕組み

異なるテナント間でPrivate Linkを利用するときは、接続を開始する側（Consumer）とAPIを提供する側（Provider）に分けて考えます。

接続元をテナントA、API提供側をテナントBとした場合、次の分担です。

項目 テナントA（Power Platform側） テナントB（API側）
Power Platform 保有 なし
VNet統合 構成する 不要
Private Endpoint 作成する 必要に応じて別途作成
バックエンドAPI 呼び出す 保有・運用
Private Link接続 接続要求する 接続を承認する
Private DNS 接続元用の名前解決を構成 必要に応じて構成
API認証・認可 トークンなどを取得 トークン検証・アクセス許可

Private Endpointを作成する場所

接続元であるテナントAにPrivate Endpointを作成します。

ただし、Power Platformに委任したサブネットに配置するのではなく、Private Endpoint用の別サブネットを利用する構成にします。

たとえば以下のようなアドレス設計です。

リソース アドレスの例
Japan East VNet 10.10.0.0/16
Japan East Power Platformサブネット 10.10.1.0/24
Japan East Private Endpointサブネット 10.10.2.0/27
Japan West VNet 10.20.0.0/16
Japan West Power Platformサブネット 10.20.1.0/24
Japan West Private Endpointサブネット 10.20.2.0/27

これらは設計例であり、既存ネットワークとのアドレス重複がないことを確認する必要があります。

クロステナント接続の確立手順

  1. API提供側が接続情報を共有する

    Azure App Serviceの場合、対象リソースの完全なAzure Resource IDと、サブリソース sites を提供します。

  2. Power Platform側がPrivate Endpointを作成する

    対象を別テナントのリソースIDで指定して、Private Endpoint接続を要求します。

  3. API提供側が接続を承認する

    API側の管理者がPrivate Endpoint接続を確認し、承認します。承認前は通信できません。

  4. Power Platform側がDNSとルーティングを設定する

    APIのFQDNをPrivate EndpointのIPに解決し、サブネットから到達できるようにします。

  5. API呼び出しを検証する

    DNS、TCP、TLS、API認証、アプリケーション応答を順に検証します。

Azure App ServiceとAzure Functionsでは、対応するプランのPrivate Endpoint機能を使います。追加でAzure Private Link Serviceを自作する必要はありません。App ServiceとFunctionsで利用可能なプランは同一ではないため、採用するプランの対応を確認します。[3][4]

一方、バックエンドAPIがAzure Virtual Machines（VM）、Azure Kubernetes Service（AKS）、独自のロードバランサー配下で動く場合には、Standard Load BalancerとAzure Private Link Serviceを組み合わせる方式を検討します。

ここは接続先サービスによって設計が変わります。[3][7]

4. DNSの設定

今回の設計では、DNSは重要な要素です。

Private Endpointを作成しても、APIの名前解決がパブリックIPを返してしまうと、Private Linkを利用した通信にはなりません。

したがって、Power PlatformのVNetからAPIのFQDNを引いたときに、正しいPrivate EndpointのIPが返るようにする必要があります。

App Serviceの例

APIが backend-api.azurewebsites.net という名前で提供されているとします。

APIの元のホスト名をCNAMEとPrivate DNSのAレコードでPrivate EndpointのIPへ解決し、そのIPへHTTPSで接続する
図2：Japan East側のDNS解決例。Japan West側はそのVNetに対応するゾーンと到達先IPを用意します。クリックすると拡大できます。

必要なDNSリソース

Azureの標準DNSを利用する場合、一般的には次を用意します。

リソース 設定
Private DNS Zone privatelink.azurewebsites.net
DNSレコード backend-api のAレコード
レコードの値 Private EndpointのプライベートIP
Virtual Network Link Power PlatformのVNetから解決できるよう関連付け
DNS Zone Group Private EndpointとDNS Zoneを連携

App Serviceの場合、API呼び出しには元のホスト名 backend-api.azurewebsites.net を使用します。HTTPSの証明書検証やHostヘッダーとの整合性を維持するためです。

Private EndpointのIPをAPIのURLに直接指定する構成は避けるべきです。

また、Private DNS Zoneのレコード登録はクロステナント構成で自動化されない場合があります。接続元テナントの管理者がDNS設定を確認する必要があります。

Japan EastとJapan WestのDNSはどうするか

ここは、Private Endpointの配置とセットで設計する必要があります。

代表的な方式は次の2つです。

方式 特徴
各リージョンにPrivate Endpointを置き、DNSゾーンをVNetごとに分離 リージョンごとに独立した接続を構成しやすい
Private Endpointを集約し、他リージョンからネットワーク接続する リソース数を削減できるが、リージョン間ルーティングとDNS設計が必要

各リージョンに異なるプライベートIPのPrivate Endpointを作る場合には、同一ホスト名に対してどちらのIPを返すかを考える必要があります。

同じPrivate DNS ZoneにAレコードを2つ登録するだけでは、リージョンごとの適切な振り分けを保証できません。ここでは、各リージョンのVNetに、同じゾーン名の別々のPrivate DNS Zoneを関連付ける設計例を採用します。各ゾーンには、そのリージョンから到達させるPrivate EndpointのIPを登録します。DNSゾーンはリージョンに配置するリソースではなく、どのVNetに関連付けるかで名前解決の範囲を分けます。

リージョン別のDNSビューやDNSフォワーダー、Private DNS Resolver、VNetピアリングなどを使って、意図した接続先に解決させる設計が必要になります。

また、Power PlatformのVNetサポートは、VNetに設定されたカスタムDNSを利用できます。企業内DNSと統合する場合には、Azure DNS Private Resolverや条件付き転送の利用が候補となります。[5][1]

5. ネットワーク以外に必要な設定

Private LinkとDNSが完成しても、それだけでAPIを呼び出せるわけではありません。通信経路、認証、Power Platform側の実行条件まで確認する必要があります。

ネットワークとアクセス制御

項目 設計・確認内容
NSG Power Platform委任サブネットからPrivate EndpointへのHTTPS通信を許可する
ルートテーブル APIまでの経路が正しく確保され、意図しない経路へ転送されないこと
VNetピアリング リージョン間またはHub-Spoke間で必要に応じて設定する
Private Endpoint接続 API提供側で承認済みになっていること
APIのパブリックアクセス 閉域接続の要件に合わせて無効化する
TLS DNS名とAPIのサーバー証明書が一致すること
認証・認可 Private Linkとは別にMicrosoft Entra IDやOAuthなどで制御する

Private Linkはネットワーク上のプライベート接続を提供するもので、APIの認証機能ではありません。App Serviceでは、Private Endpointの作成だけでパブリックアクセスが無効になるとは限らず、別途無効化します。また、App Serviceのアクセス制限ルールはPrivate Endpoint経由の要求では評価されません。[4]

クロステナント構成の場合、APIにアクセスするアプリケーションのID、トークンの発行元、API側のアクセス許可も設計対象です。

Power Platform特有の注意点

特にカスタムコネクタを利用する場合、Microsoft公式資料では次の制約が示されています。

  • VNet統合より前に作成したカスタムコネクタは再保存が必要。
  • APIエンドポイントへの要求はVNetを経由する。
  • OAuth認証・トークン取得要求は、そのVNetを経由しない。
  • 特定のトリガーやカスタムコードに制約がある。

したがって、APIへの通信経路と、認証トークンを取得する経路を分けて考える必要があります。[6]

6. 必要な管理権限と担当分担

実際の構築では、Power Platform管理者だけで完結しません。

作業 主な担当者・権限
VNetとサブネットの作成 テナントAのAzureネットワーク共同作成者など
サブネット委任 テナントAのAzureネットワーク管理者
Enterprise Policyの作成 テナントAのAzureリソース管理担当
Power Platformへの関連付け Power Platform管理者。Enterprise Policyに対する読み取り権限も必要
Private Endpointの作成 テナントAのAzureネットワーク管理者
Private Link接続の承認 テナントBの対象APIリソース管理者
Private DNSの設定 テナントAのDNS管理担当
API認証設定 テナントA・Bのアプリケーション管理担当

Power Platform VNetサポートの構築には、AzureとMicrosoft Entra IDの両方で適切な権限が必要です。

7. 構築と検証の進め方

まずは本番環境に一括適用するのではなく、テスト用Power Platform環境で疎通を確認することをおすすめします。

構築・検証チェックリスト

  • 日本リージョンに対応したEast / WestのVNetを準備
  • 委任サブネットとEnterprise Policyを作成
  • Power Platform環境でVNet統合を有効化
  • 接続元側にPrivate Endpointを作成
  • API提供側でクロステナント接続を承認
  • Private DNS Zoneと名前解決経路を構成
  • APIのFQDNがプライベートIPに解決されることを確認
  • TCP 443とTLSの接続を検証
  • Power Platformの実際のコネクタからAPIを実行
  • Japan East / West両方の通信・障害時動作を検証
  • パブリック経路からのアクセスが遮断されていることを確認

障害が発生した際には、次のように切り分けます。

症状 主に疑う箇所
APIがパブリックIPに解決される Private DNS Zone、VNet Link、DNSフォワーダー
DNSは正常だが接続タイムアウト NSG、ルーティング、Private Endpoint接続状態
HTTP 403 API認可、パブリックIPへの誤解決、Private Endpoint経路。App Serviceのアクセス制限ルールはPrivate Endpoint経由では評価されない
HTTP 401 Microsoft Entra ID、OAuth、トークン設定
特定のコネクタだけ失敗する Power PlatformのVNet対応範囲、コネクタ固有の制約
東日本で動くが西日本で失敗する 西日本側のDNS、Private Endpoint、通信経路

なお、Power Platformの委任サブネット内には一般的な検証用VMを直接配置しないため、別の検証用サブネットにVMを配置してDNSとネットワークの疎通を確認し、最後にPower Platformの実際の呼び出し元から確認する方法が現実的です。

8. 要件に対する推奨構成

現時点では、以下を基本設計の出発点にするのがよいと考えます。

設計項目 推奨
Power Platformの配置 日本リージョン
VNet統合 Japan EastとJapan Westの委任サブネット
Enterprise Policy 両リージョンを登録したポリシー
Private Endpoint 接続元テナントAに配置
クロステナント接続 テナントBのAPIリソースに対する接続要求と承認
DNS 接続元側にPrivate DNS Zone、または既存DNS基盤との連携
API通信 HTTPS / TLS
API認証 Microsoft Entra IDなど
冗長性 両リージョンでの名前解決とPrivate Link到達性を検証

設計前に確定しておくべきこと

ここまでの構成は、APIがAzure App Service / Functionsで提供される想定です。実際には、次の3点が構成を大きく左右します。

  1. APIのホスティング先：App Service / Functions / API Management / AKS / VMのどれか。Private EndpointとPrivate Link Serviceのどちらを使うかに関係します。
  2. Power Platformの呼び出し方式：カスタムコネクタ、Power AutomateのHTTPアクション、Dataverseプラグインのどれか。VNet対応範囲に関係します。
  3. DNSの既存構成：Azure DNSを使っているか、企業独自のDNSサーバーが存在するか。名前解決の設計に関係します。

特に次の検討段階では、東日本・西日本のVNetから別テナントのAPIへどう到達させ、どこでDNSを解決するかを、物理構成に近いネットワーク図に落とし込むことが重要です。

この3点が確定すれば、Azureリソースの配置、アドレス体系、DNS Zone、VNet Link、Private Endpoint接続、必要権限までを具体的な構築手順として整理できます。

参考資料

資料の確認日：2026年11月5日。英語版の本文を確認し、参考リンクには日本語版を掲載しています。ネットワーク構成とアドレスは設計例です。

  1. Power PlatformのVNetサポートの概要（Microsoft Learn）
  2. Power PlatformのVNetサポートの設定（Microsoft Learn）
  3. Private Endpointによるクロステナントのアプリ接続（Microsoft Learn）
  4. App ServiceでのPrivate Endpointの使用（Microsoft Learn）
  5. Azure Private EndpointのプライベートDNSゾーン（Microsoft Learn）
  6. カスタムコネクタの概要とVirtual Networkの制約（Microsoft Learn）
  7. マルチテナント構成でのAzure Private Linkの設計（Microsoft Learn）