Power PlatformからAzure SQL、Azure Storage、Azure Key Vault、社内APIなどへ安全に接続したい場合、Azure Networkingで注目すべき更新が「Virtual Network support overview – Power Platform」です。結論から言うと、この機能はPower Platformのアウトバウンド通信をAzure Virtual Networkの委任サブネット経由にし、接続先リソースをパブリックインターネットへ公開せずに連携できるようにする仕組みです。従来のようにPower Platform側の公開IP範囲やサービス タグを許可する設計だけに頼らず、管理者が所有するVNet、DNS、NSG、Firewall、NAT Gatewayで通信を制御しやすくなる点が大きなポイントです。(Microsoft Learn)
ただし、有効化すれば自動的に安全になるわけではありません。対象環境、対応コネクタ、リージョン、サブネットのIP数、DNS、既存プラグインやフローの接続先を事前に確認しないと、公開エンドポイントへの通信が急に失敗する可能性があります。この記事では、2026年5月末に更新された公式情報をもとに、変更点、影響範囲、管理者・開発者が確認すべき設定、移行時の注意点を実務目線で整理します。(Microsoft Learn)
Azure Networkingで何が変わるのか
Power PlatformのVirtual Network supportは、Power Apps、Power Automate、Dynamics 365、Dataverseプラグインなどが社内ネットワーク内のリソースへ接続する際の「出口」を変える機能です。ポイントは、Power Platformの実行時通信が、企業側で用意したAzure Virtual Networkの委任サブネットを使って送信されることです。これにより、Azure SQL、Azure Storage、Azure Key Vault、社内Web APIなどを公開エンドポイントとして開けずに、Private EndpointやExpressRoute、VNet Peeringなどを組み合わせたプライベート接続設計に寄せられます。(Microsoft Learn)
| 観点 | 従来の考え方 | Virtual Network support有効後の考え方 | 実務上の確認ポイント |
|---|---|---|---|
| 接続経路 | 公開ネットワーク経由の接続が中心 | 委任サブネット経由でプライベートネットワーク内のリソースへ接続 | 接続先がPrivate Endpointや社内ネットワークで到達可能か確認する |
| アクセス制御 | Azure IP範囲やサービス タグの許可に依存しやすい | NSG、Firewall、ルート、DNS、NAT Gatewayで制御しやすい | 通信許可ルールをPower Platform単位ではなくサブネット単位で整理する |
| 影響範囲 | 公開URLに接続できれば動く構成が多い | ネットワークポリシーにより公開URLへの通信が失敗する可能性がある | プラグイン、コネクタ、カスタムコネクタ、フローのURLを棚卸しする |
| 運用責任 | Power Platform管理者中心 | Power Platform管理者とAzureネットワーク管理者の共同管理 | 環境、VNet、サブネット、DNS、証明書を横断して設計する |
重要なのは、「Power PlatformをVNetの中に完全移動する」というより、Power Platformの実行時アウトバウンド通信を、指定したAzure Virtual Networkの委任サブネットから出す設計だと理解することです。Dataverseプラグインはコンテナー上で実行され、環境に委任サブネットを割り当てると、そのコンテナーのNICにサブネット内のIPアドレスが割り当てられます。(GitHub)
2026年5月末更新で確認したい主な変更点
今回の公式情報で特に確認すべきなのは、単なる機能説明ではなく、サポート範囲と展開条件が運用に直結する形で整理されている点です。GitHub上の履歴では、2026年5月28日に日付更新とコントリビューター追加が行われ、直前には米国政府クラウドのサポート注記も修正されています。現在の注記では、US government cloud environmentsのサポートはGCC HighまたはDoD環境が対象で、GCC環境は対象外とされています。(GitHub)
国内企業や日本リージョン利用者にとっては、米国政府クラウドの注記よりも、次の3点が実務上の影響として大きくなります。
| 確認すべき点 | 影響 |
|---|---|
| 対応サービスがDataverseプラグインと一部コネクタに限られる | すべてのPower Platform機能がVNet対応になるわけではない |
| 環境タイプとリージョンに条件がある | TrialやDataverse for Teams環境では使えない |
| サブネット、DNS、IP範囲は後から気軽に変更できない | 本番適用前のネットワーク設計ミスが障害につながる |
つまり、この更新は「今すぐ全環境を移行すべき」という告知ではありません。むしろ、Power PlatformとAzure Networkingをまたぐシステムで、どの通信をプライベート化し、どの通信をNAT GatewayやFirewall経由で制御するかを見直すタイミングと考えるべきです。
対象になるPower Platformサービスと環境
Virtual Network supportの対象は、主にDataverseプラグインと対応コネクタです。公式情報では、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などのコネクタがVirtual Network supportの対象として示されています。(Microsoft Learn)
| 区分 | 対象例 | 確認ポイント |
|---|---|---|
| Dataverse | Dataverseプラグイン | 外部API、DB、Key Vaultなどへ接続するコードを確認する |
| Power Apps / Power Automate | 対応コネクタ経由の接続 | 使用中のコネクタがVNet対応か確認する |
| Dynamics 365 apps | Dataverseやコネクタを使う拡張 | ISV提供プラグインのアウトバウンド通信先を確認する |
| カスタム連携 | Custom connectors、社内Web API | Private Endpoint、DNS、証明書、認証方式を事前に検証する |
環境タイプでは、Production、Default、Sandbox、Developerはサポート対象ですが、TrialとMicrosoft Dataverse for Teamsは対象外です。また、Virtual Network supportを有効化するには、対象環境がManaged Environmentsである必要があります。(Microsoft Learn)
注意したいのは、Dataverse low-code plug-insがコネクタを使うケースです。公式情報では、そのコネクタ種別がサブネット委任に対応するまでサポートされない制限が示されています。プラグイン名だけで判断せず、「その処理がどのコネクタを使って外部へ出ているか」まで確認してください。(Microsoft Learn)
Virtual Network data gatewayとの違い
混同しやすいのが、Virtual Network data gatewayとAzure Virtual Network support for Power Platformの違いです。Virtual Network data gatewayは、Power BIやPower Platform dataflowsのようなETL・データフロー用途に使われる管理型ゲートウェイです。一方、Power PlatformのVirtual Network supportは、Power Platform環境のワークロードがAzure subnet delegationを使って短時間・多数のAPIリクエストを処理するための仕組みです。(Microsoft Learn)
実務上は、次のように判断すると迷いにくくなります。
| やりたいこと | 選ぶべき仕組み |
|---|---|
| Power BIやPower Platform dataflowsからVNet内データへ接続したい | Virtual Network data gateway |
| DataverseプラグインやPower Platformコネクタからプライベートリソースへ接続したい | Virtual Network support for Power Platform |
| Power AppsやPower Automateの外部API通信を企業ネットワーク制御下に置きたい | Virtual Network support for Power Platform |
| オンプレミスデータソースを従来型ゲートウェイで扱いたい | 要件に応じてオンプレミスデータゲートウェイも検討 |
公式FAQでは、Power BIとPower Platform dataflowsを除くPower Platformからのアウトバウンド接続シナリオでは、Virtual Network support for Power Platformがサポートされる選択肢として位置付けられています。(Microsoft Learn)
リージョン設計で確認すべきこと
Virtual Network supportを使う前に、Power Platform環境のリージョンを確認し、そのリージョンに対応するAzureリージョンへVNetとサブネットを配置する必要があります。日本のPower Platformリージョンでは、対応するAzureリージョンとしてjapaneastとjapanwestが示されています。(Microsoft Learn)
Power Platform環境は地理的なリージョンにひも付き、環境内で作成したアプリ、Dataverse、接続、ゲートウェイ、カスタムコネクタなどもその環境の地域に展開されます。管理者はPower Platform admin centerのEnvironments画面でRegion列を確認できます。(Microsoft Learn)
| 利用パターン | 設計の考え方 |
|---|---|
| 日本リージョンのPower Platform環境 | japaneastとjapanwestの対応を前提にVNet構成を確認する |
| 高可用性を重視する本番環境 | Power Platformリージョンに関連する両方のAzureリージョンでVNet委任を設計する |
| 接続先リソースが別リージョンにある | 環境リージョン側にVNetを作り、必要に応じてVNet Peeringで接続する |
| オンプレミスリソースへ接続する | ExpressRouteなどでオンプレミスをVNet側へ到達可能にする |
トラブルシューティングの公式情報でも、Power Platform環境は自動フェールオーバーする可能性があるため、関連する両方のAzureリージョンでVNetを構成する必要があると説明されています。片方のリージョンだけ正常に動作し、もう片方で失敗する場合は、失敗側リージョンのVNet、DNS、Firewall設定を重点的に確認します。(Microsoft Learn)
サブネットサイズの見積もりは早めに決める
サブネット設計は、Virtual Network supportで最も失敗しやすいポイントです。公式情報では、本番環境では通常25〜30個のIPアドレス、SandboxやDeveloperなどの非本番環境では6〜10個のIPアドレスを割り当てる目安が示されています。環境が使われ始めると最小4つのコンテナーが作成され、呼び出し量に応じて動的にスケールし、多くのケースで10〜30コンテナーの範囲になるとされています。(Microsoft Learn)
| 構成例 | 計算例 | 推奨される考え方 |
|---|---|---|
| 本番環境1個 | 30 IP + Azure予約5 IP | 最低限ではなく拡張余地を持つ |
| 本番環境4個を同一ポリシーに関連付け | 4環境 × 30 IP + 5予約 = 125 IP | /25相当の容量を目安にする |
| 非本番環境20個 | 20環境 × 10 IP + 5予約 = 205 IP | /24相当など、追加環境を見込む |
| 将来さらに環境が増える | 現在数だけで見積もらない | 本番用と非本番用のポリシーを分ける |
Azureの各サブネットでは予約IPも考慮する必要があります。特に、同じ委任サブネットを複数のPower Platform環境で使う場合は、環境数とピーク時の同時実行量を見込んでCIDRを決めてください。サブネットを小さく作りすぎると、後からアプリ利用が増えたときにIP不足が原因で接続不安定になる可能性があります。(Microsoft Learn)
管理者が確認すべき前提条件
有効化前には、Power Platform管理者とAzureネットワーク管理者の両方で準備が必要です。公式のセットアップ手順では、Azureサブスクリプション、VNetとサブネット、Enterprise Policy、Power Platform環境の構成が必要であり、権限としてAzure側ではNetwork Contributor相当、Power Platform側ではPower Platform administratorが求められます。(Microsoft Learn)
| 担当者 | 確認すること |
|---|---|
| Power Platform管理者 | 対象環境がManaged Environmentsか、環境タイプがサポート対象か、Enterprise Policyを環境へ関連付けられるか |
| Azureネットワーク管理者 | VNet、専用サブネット、サブネット委任、NSG、Firewall、NAT Gateway、Private DNS Zoneを設計する |
| 開発者 | プラグイン、フロー、カスタムコネクタの接続先URL、接続文字列、証明書、認証方式を確認する |
| セキュリティ担当 | パブリック通信の扱い、ログ取得、送信元制御、データ流出対策、例外申請フローを決める |
セットアップはPowerShellまたは手動で実施できます。大きな流れは、VNetとサブネットの準備、Enterprise Policyの作成、Power Platform環境へのポリシー関連付けです。PowerShellではMicrosoft.PowerPlatform.EnterprisePoliciesモジュールを使い、サブネット委任、Enterprise Policy作成、Enable-SubnetInjectionによる環境への関連付けを行います。(Microsoft Learn)
有効化前に必ず棚卸しする接続
Virtual Network supportを有効にすると、Dataverseプラグインや対応コネクタのリクエストは委任サブネットで実行され、ネットワーク管理者が設定したポリシーの影響を受けます。公式情報では、公開リソースへの呼び出しが壊れ始める可能性があるため、有効化前にプラグインやコネクタのコード、URL、接続を確認するよう注意されています。(Microsoft Learn)
特に次のような接続は、事前確認が必要です。
| 棚卸し対象 | 確認内容 | 対応例 |
|---|---|---|
| Azure SQL / SQL Server | パブリックエンドポイントへ接続していないか | Private EndpointとPrivate DNS Zoneを用意する |
| Azure Key Vault | Firewallで公開アクセスを拒否しているか | Key VaultのPrivate Endpointを作成し、FQDNがプライベートIPへ解決されるか確認する |
| Azure Storage / Blob / File | 接続先FQDNとDNS解決結果 | privatelink系DNSゾーンをVNetへリンクする |
| 社内Web API | オンプレミスまたはAzure内で到達可能か | ExpressRoute、VPN、VNet Peering、Firewallルールを確認する |
| 外部SaaS API | インターネット向け通信が必要か | NAT GatewayとFirewallで送信元・宛先を制御する |
| ISVプラグイン | どのURLへアウトバウンド通信するか | ベンダーに通信先一覧を確認し、Firewall許可を検討する |
公開APIへ接続しているプラグインをそのまま本番環境で有効化すると、VNet内のネットワークポリシーによりブロックされる場合があります。必要であれば、接続先サービスをVNet内へ移す、AzureサービスならPrivate Endpointを構成する、外部インターネット接続が必要な場合はNAT GatewayやFirewallで明示的に許可する、といった対策を先に行います。(Microsoft Learn)
DNSとPrivate Endpointの確認が重要
Virtual Network supportでは、委任サブネットが存在するVNetに設定されたカスタムDNSがPower Platformからの名前解決に使われます。そのため、接続先FQDNがパブリックIPではなくプライベートIPへ解決されるかが重要です。(GitHub)
たとえばAzure SQL DatabaseにPrivate Endpointを作成していても、DNSがprivatelink.database.windows.netを正しく解決できなければ、Power Platform側の通信がパブリックIPへ向かう可能性があります。公式のトラブルシューティングでは、AzureリソースにPrivate Endpointがある場合、リソース種別に対応するPrivate DNS Zoneの存在、VNetへのリンク、DNS解決結果を確認するよう説明されています。(Microsoft Learn)
| 症状 | よくある原因 | 確認方法 |
|---|---|---|
| ホスト名が解決できない | DNSレコード不足、DNSサーバー設定ミス | Test-DnsResolutionでFQDNを確認 |
| パブリックIPへ接続される | Private DNS Zoneが未作成、VNet未リンク | DNS解決結果がプライベートIPか確認 |
| TCP接続は成功するがアプリが失敗 | 認証、証明書、Firewallの上位レイヤーで失敗 | Test-TLSHandshakeやアプリログを確認 |
| 一部リージョンだけ失敗 | 片方のリージョンのVNet/DNS設定漏れ | Get-EnvironmentRegionと-Region指定で両方を検証 |
DNS設定の変更には特に注意が必要です。公式FAQでは、Microsoft.PowerPlatform/enterprisePoliciesへ委任されたVNetのDNSアドレスやサブネットIP範囲は、機能を使用中の環境では変更できないと説明されています。変更するには、いったん環境から委任機能を外し、変更後に再度有効化する流れになります。(GitHub)
NAT GatewayとFirewallでインターネット向け通信を制御する
Virtual Network supportを有効にしても、プラグインやコネクタからインターネット向け通信が完全に禁止されるわけではありません。公式FAQでは、サブネット委任された環境でもインターネット向けアクセスは既定で利用可能であり、組織が送信アクセスを制御・保護するために、委任サブネットへAzure NAT Gatewayを関連付けることが推奨されています。(GitHub)
ここでの実務ポイントは、「プライベート接続にしたい通信」と「インターネットへ出る必要がある通信」を分けることです。
| 通信の種類 | 推奨設計 |
|---|---|
| Azure SQL、Key Vault、Storageなど社内管理リソース | Private EndpointとPrivate DNSでプライベート接続 |
| 社内API、オンプレミスDB | ExpressRoute、VPN、VNet Peering、Firewall経由で到達可能にする |
| 外部SaaS API | NAT Gatewayで送信元を安定化し、Firewallや送信先許可リストで制御 |
| 一時的な検証用API | 本番前に閉塞または明示的な例外管理へ移す |
「VNet対応にしたから安全」と考えて、外部SaaS APIへの通信を把握しないままにすると、データ持ち出し経路が残る可能性があります。逆に、Firewallを厳しくしすぎると、認証基盤や外部APIへの必要な通信まで止めてしまいます。送信先FQDN、ポート、認証方式、ログ取得の責任範囲を事前に文書化しておくことが重要です。
既存VNetを使う場合の注意点
既存のAzure Virtual NetworkをPower Platform用に使うことは可能です。ただし、既存サブネットを何でも流用できるわけではありません。公式FAQでは、既存VNetを使う場合でも、Power Platform専用に委任する新しい単一サブネットが必要で、その委任サブネットは他の用途に使えないと説明されています。また、同じ委任サブネットを複数のEnterprise Policyで再利用することもできません。(GitHub)
一方で、同じEnterprise Policyを複数のPower Platform環境で使うことは可能です。ただし、early release cycle environmentsは他の環境と同じEnterprise Policyでは使えない制限があります。複数環境を同一ポリシーへ関連付ける場合は、サブネットのIP数を必ず多めに見積もってください。(GitHub)
| やってよいこと | 避けるべきこと |
|---|---|
| 既存VNet内にPower Platform専用サブネットを新規作成する | 既存ワークロードと同じサブネットを委任する |
| 本番用と非本番用でEnterprise Policyを分ける | 本番・開発・検証を無計画に同じサブネットへ詰め込む |
| 将来の環境増加を見込んでCIDRを決める | 最小IP数だけでサブネットを作る |
| Hub-spoke構成やPeeringを使って既存ネットワークへ接続する | Power Platform環境と無関係なリージョンにだけVNetを作る |
移行・展開の進め方
本番環境へいきなり適用するのは避けるべきです。特に、既存のPower Apps、Power Automate、Dataverseプラグイン、カスタムコネクタが公開エンドポイント前提で作られている場合、Virtual Network supportの有効化はネットワーク境界の変更になります。小規模なSandboxまたはDeveloper環境で通信確認を行い、DNS、Firewall、証明書、認証の問題を潰してから本番へ展開します。
| ステップ | 作業内容 | 成功条件 |
|---|---|---|
| 現状調査 | アプリ、フロー、プラグイン、コネクタ、接続先URLを一覧化 | 外部通信先と所有者が分かる |
| 対象判定 | 対応環境、対応コネクタ、リージョンを確認 | 対象外機能が切り分け済み |
| ネットワーク設計 | VNet、専用サブネット、CIDR、DNS、NAT、Firewallを設計 | 本番ピーク時のIP数を満たす |
| プライベート接続化 | Private Endpoint、Private DNS Zone、Peering、ExpressRouteを構成 | FQDNがプライベートIPへ解決される |
| 検証環境で有効化 | Enterprise Policyを作成し、Sandboxへ関連付け | コネクタとプラグインが正常に動く |
| 診断 | PowerShell診断コマンドでDNS、TCP、TLSを確認 | 失敗箇所が再現可能な形で特定できる |
| 本番展開 | メンテナンス計画、ロールバック手順、監視を用意 | 有効化後の通信・業務影響を監視できる |
公式セットアップ手順では、VNetとサブネットの準備、Enterprise Policyの作成、Power Platform環境へのポリシー関連付けという流れが示されています。手動設定の場合は、Azure側でMicrosoft.NetworkとMicrosoft.PowerPlatformのリソースプロバイダー登録、サブネットのMicrosoft.PowerPlatform/enterprisePoliciesへの委任、Power Platform admin centerでのポリシー割り当てを行います。(Microsoft Learn)
トラブルシューティングで使うPowerShellコマンド
接続トラブルが発生した場合は、推測でFirewallやDNSを変更する前に、公式の診断PowerShellモジュールを使って原因を切り分けます。Microsoft.PowerPlatform.EnterprisePoliciesモジュールには、環境リージョンの確認、DNS解決、ネットワーク疎通、TLSハンドシェイク確認のための関数が用意されています。(Microsoft Learn)
| コマンド | 用途 | 使う場面 |
|---|---|---|
Get-EnvironmentRegion | Power Platform環境のリージョン確認 | 片方のリージョンだけ失敗する場合 |
Test-DnsResolution | 指定ホスト名のDNS解決確認 | FQDNがプライベートIPへ解決されるか確認する場合 |
Test-NetworkConnectivity | 宛先とポートへのTCP接続確認 | Firewall、NSG、ルートの問題を切り分ける場合 |
Test-TLSHandshake | TLSハンドシェイク確認 | 証明書、暗号スイート、TLSエラーを調べる場合 |
注意点として、Test-NetworkConnectivityでTCP接続が成功しても、アプリケーションが正常に動くとは限りません。認証、認可、証明書、アプリケーション設定の問題は別途確認が必要です。また、TLS証明書については公的に信頼された証明書が必要で、独自ルートCAを追加する形はサポートされないとされています。(Microsoft Learn)
開発者が修正すべきポイント
開発者は、ネットワーク管理者がVNetを用意するのを待つだけでは不十分です。Power Platform側のコードや接続定義が公開URL前提のままだと、ネットワークは正しくてもアプリが失敗します。
| 確認箇所 | 修正の方向性 |
|---|---|
| Dataverseプラグイン内のURL | パブリックFQDNではなく、Private Endpointで解決できるFQDNを使う |
| 接続文字列 | サーバー名、ポート、暗号化、証明書検証を確認する |
| カスタムコネクタ | ベースURL、認証方式、TLS証明書、Firewall許可を確認する |
| Power Automateフロー | 使用コネクタがVNet対応か、例外的な外部API呼び出しがないか確認する |
| ISVプラグイン | ベンダー提供の通信先リスト、固定IP要件、証明書要件を確認する |
特に避けたいのは、開発環境では公開URLへ接続し、本番だけPrivate Endpointに変える構成を属人的に運用することです。環境変数、接続参照、ソリューションの移行手順に接続先の違いを明記し、ALMプロセスの中で検証できるようにしておくと、後からの障害調査が楽になります。
有効化してよいケース、まだ待つべきケース
Virtual Network supportは、セキュリティ要件が高い組織ほど価値があります。ただし、ネットワーク設計とアプリ改修の準備が整っていない場合、先に有効化すると業務影響が出る可能性があります。
| 判断 | 条件 |
|---|---|
| 早めに検討すべき | Azure SQL、Key Vault、Storage、社内APIを公開せずにPower Platformから使いたい |
| 早めに検討すべき | Power Platformのアウトバウンド通信をFirewallやNAT Gatewayで統制したい |
| 早めに検討すべき | Dataverseプラグインやカスタムコネクタで機密データを扱っている |
| 慎重に進めるべき | 接続先URLや利用コネクタの棚卸しができていない |
| 慎重に進めるべき | サブネットCIDRやDNS設計を後から大きく変える可能性がある |
| 対象外または別方式を検討 | Trial、Dataverse for Teams、Power BI、Power Platform dataflows中心の用途 |
最初の一歩としては、全環境への展開ではなく、影響範囲が明確なSandbox環境で「1つのPrivate Endpoint対応リソースへ接続する」検証から始めるのが現実的です。Azure Key VaultやAzure SQLのように、Private EndpointとPrivate DNSの挙動を確認しやすいリソースを選ぶと、ネットワーク、DNS、証明書、Power Platform側の設定を一通り検証できます。
管理者向けチェックリスト
最後に、Virtual Network support overview – Power Platformを読んだ後に確認すべき項目を整理します。
| チェック項目 | 確認済みにする条件 |
|---|---|
| 対象環境 | Production、Default、Sandbox、Developerのいずれかで、Managed Environmentsになっている |
| 対象サービス | DataverseプラグインまたはVNet対応コネクタである |
| リージョン | Power Platform環境のリージョンと対応Azureリージョンを確認した |
| サブネット | 本番・非本番の環境数とピーク負荷を見込んでCIDRを決めた |
| 委任 | Power Platform専用サブネットをMicrosoft.PowerPlatform/enterprisePoliciesへ委任した |
| DNS | Private EndpointのFQDNがプライベートIPへ解決される |
| インターネット通信 | 必要な外部通信をNAT Gateway、Firewall、許可リストで制御する |
| コード修正 | プラグイン、フロー、カスタムコネクタのURLと接続を確認した |
| 証明書 | 接続先が公的に信頼されたTLS証明書を提示する |
| 診断 | Test-DnsResolution、Test-NetworkConnectivity、Test-TLSHandshakeで検証できる |
| ロールバック | 本番適用前に無効化手順、変更時間帯、影響連絡先を決めた |
Power PlatformのVirtual Network supportは、Azure Networkingの知識がないと扱いにくい機能ですが、正しく設計すれば、公開インターネットに依存した接続を減らし、Power Platformと社内システムの連携をより統制しやすくできます。まずは、対象環境、対応サービス、リージョン、サブネットサイズ、DNS、既存接続先の6点を棚卸しし、Sandboxで小さく検証してから本番へ展開してください。
コメント