VNet Integration を「閉域化」と呼んだ瞬間に、設計は崩れます

私は App Service の閉域設計を見るとき、最初に画面ではなく通信の向きを確認します。

App Service から外へ出る通信なのか。外部または社内ネットワークから App Service へ入る通信なのか。保守用の Kudu / SCM へ誰が入るのか。DNS は private IP を返しているのか。公開アクセスは本当に閉じているのか。委託先や監査人に、どの経路が開いていて、どの経路が閉じているか説明できるのか。

ここを確認せずに「VNet Integration を入れたので閉域化できています」と言われると、私はかなり危ない設計だと見ます。

1. 結論

VNet Integration は、App Service から VNet 側へ出ていくための送信経路です。App Service への受信を private にする機能ではありません。

これは設計上の根本です。

公式技術文書でも、App Service の VNet Integration は、アプリが VNet 内または VNet 経由のリソースへアクセスするための機能であり、VNet からアプリへの private inbound access を付与するものではないと説明されています。さらに、VNet Integration は App Service から VNet への outbound call 用であり、受信の private access には Private Endpoint を参照するよう明記されています。確認日：2026年5月4日。

だから、私は現場でこう言い切ります。

VNet Integration を入れても、App Service の入口は閉じません。入口を閉じるには、Private Endpoint、Private DNS、Public network access、Access Restrictions、保守導線を別で設計する必要があります。

2. 現場で実際に起きる勘違い

現場では、次の会話が本当に起きます。

「VNet Integration を入れました」「これで閉域化できています」「でもインターネットから App Service にアクセスできます」「それはなぜですか」「Private Endpoint も必要なんですか」「Private DNS は作った方がいいんですか」「SCM は別ですか」「外部委託先の保守アクセスはどうしますか」「監査資料には閉域化済みと書いてしまいました」

この時点で、技術設計だけでなく、クラウド法務上も危険です。

なぜなら、契約書、提案書、監査資料、セキュリティチェックシートに「閉域化済み」と書いているのに、実際には App Service の public endpoint が残っている可能性があるからです。

これは単なる設定ミスではありません。説明不一致です。

山崎行政書士事務所のクラウド法務では、この不一致を非常に重く見ます。技術構成、契約表現、監査資料、運用手順が一致していなければ、事故時に説明できません。

3. 私が最初に分けるのは「送信」と「受信」

App Service のネットワーク設計では、まずこの2つを分けます。

送信側App Service から、DB、Key Vault、Storage、API、別の PaaS、オンプレミス、社内ネットワークへ出ていく通信。

受信側利用者、社内端末、VPN、ExpressRoute、WAF、Front Door、Application Gateway、保守端末、委託先から App Service へ入ってくる通信。

VNet Integration は、前者です。Private Endpoint は、後者です。

App Service の Private Endpoint は、VNet 内の private IP を使って private network 側のクライアントから App Service へ接続するための仕組みです。公式技術文書でも、Private Endpoint は App Service への incoming traffic のみに使われ、outgoing traffic には使われないと説明されています。確認日：2026年5月4日。

つまり、こうです。

VNet Integration だけでは受信は閉じない。Private Endpoint だけでは送信は VNet 経由にならない。両方を混ぜて「閉域」と呼ぶと事故ります。

4. 私が見る具体的なチェック項目

私は App Service の PaaS 閉域化レビューで、最低限これを見ます。

VNet Integration 対象アプリ数。統合サブネット数。統合サブネットの CIDR。統合サブネットの委任状態。Route all の有効化有無。NAT Gateway の有無。Private Endpoint 数。Private Endpoint 用サブネット。Private DNS Zone。Private DNS Zone Link。A レコード。SCM / Kudu 用レコード。Public network access の状態。Access Restrictions の残存ルール。外部公開 IP からのアクセス可否。保守端末・委託先のアクセス経路。監査ログとアクセスログ。構成図上の通信方向。

特に見る数字は、次です。

VNet Integration 対象アプリ数。統合サブネット数。Private Endpoint 数。Private DNS Zone Link 数。公開アクセス許可の残存数。SCM / Kudu の公開残存数。委託先保守導線の数。Access Restriction の allow ルール数。Public network access enabled の App Service 数。

この数字が出せない会社は、「閉域化しています」と言うべきではありません。

5. VNet Integration の落とし穴

VNet Integration は便利です。App Service から VNet 内の DB、Storage、Key Vault、Private Endpoint 付き PaaS、オンプレミス側へ到達させるには必要になります。

しかし、落とし穴があります。

落とし穴1：受信閉域だと思い込む

一番多い誤解です。VNet Integration を入れても、App Service の public endpoint は閉じません。

落とし穴2：NSG の inbound で入口を制御できると思う

VNet Integration の統合サブネットに NSG を置いても、それは App Service への受信制御にはなりません。公式技術文書でも、VNet Integration では App Service への inbound access を提供できないため、統合サブネットの NSG inbound rules は適用されないと説明されています。確認日：2026年5月4日。

落とし穴3：Route all を見ていない

VNet Integration を有効にしても、全 outbound traffic が必ず VNet に入るとは限りません。公式技術文書では、all traffic routing が有効でない場合、private traffic と統合サブネット上の service endpoint 向け通信のみが VNet に送られ、インターネット向け outbound traffic は直接ルーティングされると説明されています。確認日：2026年5月4日。

落とし穴4：送信元 IP を固定したつもりになる

外部 API や取引先 FW で送信元 IP 制限をする場合、VNet Integration だけでは設計が足りないことがあります。公式技術文書では、App Service の outbound traffic の IP を制御するには、VNet Integration と NAT Gateway を使って静的 Public IP 経由にする構成が説明されています。確認日：2026年5月4日。

6. Private Endpoint の落とし穴

Private Endpoint を作れば終わり、でもありません。

App Service の Private Endpoint は inbound 側の private access を作るためのものです。しかし、公式技術文書では、Private Endpoint と public access は共存できるため、分離を確実にするには public network access を無効化する必要があると説明されています。確認日：2026年5月4日。

私はここを必ず確認します。

Private Endpoint は作成済みか。承認済みか。Private DNS Zone はあるか。VNet Link はあるか。A レコードは private IP を指しているか。App Service の既定ホスト名が private IP に解決されるか。Public network access は無効化されているか。Access Restrictions は意図通りか。SCM / Kudu 側の private name resolution はあるか。保守端末から private 経路でアクセスできるか。外部インターネットから 403 または到達不可になるか。

Private Endpoint は作った。でも DNS が public のまま。Public network access が有効。SCM が公開されたまま。委託先が public 経由で保守している。

これでは、閉域とは言えません。

7. DNS を軽く見ると必ず詰まる

Private Endpoint の設計で、私は DNS を最重要に見ます。

Private Endpoint を作っただけでは、利用者や保守端末が自動で private IP に向くとは限りません。公式技術文書では、App Service の Private Endpoint を使う場合、privatelink.azurewebsites.net の Private DNS Zone を作成し、アプリの A レコードを Private Endpoint の IP に向ける必要があると説明されています。確認日：2026年5月4日。

さらに、Kudu / SCM endpoint には別レコードが必要です。公式技術文書でも、Kudu console や Kudu REST API を使う場合は、Private DNS Zone またはカスタム DNS に、SCM 用の2つ目のレコードを作成する必要があると説明されています。確認日：2026年5月4日。

現場ではこうなります。

App Service 本体は private で見える。でもデプロイが失敗する。Kudu に入れない。Azure DevOps の self-hosted agent から到達できない。委託先の保守端末だけ名前解決が public に向く。一部拠点だけ 403 になる。オンプレ DNS から privatelink の解決ができない。

これは DNS 設計ミスです。

閉域化は Private Endpoint 作成ではありません。名前解決を private に寄せることです。

8. Access Restrictions は閉域化の補助であり、万能ではない

App Service には Access Restrictions があります。公式技術文書では、優先順位付きの allow / deny list により、IP アドレスや VNet サブネットからの network access を制御でき、1つ以上のルールがある場合は末尾に implicit deny all があると説明されています。確認日：2026年5月4日。

これは重要です。しかし、私は Access Restrictions だけで「閉域化」とは言いません。

Access Restrictions は public endpoint への入口制御として使えます。しかし、Private Endpoint 経由の通信には別の考慮が必要です。公式技術文書でも、Private Endpoint 経由の traffic には App Service の access restriction rules は評価されないと説明されています。確認日：2026年5月4日。

つまり、設計上はこう分けます。

public endpoint を残す場合は Access Restrictions で制御する。本当に private のみに寄せるなら Private Endpoint と public network access 無効化を検討する。Private Endpoint 経由のアクセス制御は、VNet、DNS、NSG、UDR、FW、認証、アプリ側認可と組み合わせて見る。

Access Restrictions は有効です。しかし、閉域設計の代替ではありません。

9. サブネット設計も雑にできない

VNet Integration と Private Endpoint は、同じ「VNet」という言葉が出るので混同されがちです。しかし、サブネット設計は別です。

公式技術文書では、Private Endpoint 用サブネットと VNet Integration 用サブネットは同じサブネットにできないと説明されています。確認日：2026年5月4日。

さらに、VNet Integration は専用サブネットに依存し、App Service Plan のインスタンスごとに統合サブネットの IP を使います。スケール操作やプラットフォームアップグレード時には、一時的に必要 IP が増えることも説明されています。確認日：2026年5月4日。

私は、閉域設計レビューで必ず聞きます。

統合サブネットの CIDR は足りていますか。複数 App Service Plan を詰め込んでいませんか。スケールアウト時の IP 消費を見ていますか。Private Endpoint 用サブネットと分けていますか。委任設定は正しいですか。将来の増設余地はありますか。

閉域設計は「つながったら終わり」ではありません。スケールしたとき、保守したとき、障害復旧したときに壊れないことが必要です。

10. 保守導線を忘れると、運用で public が復活する

私は、閉域化の設計で一番怖いのは、運用時に public 経路が復活することだと見ています。

本番リリース直前。障害対応中。委託先が急いでいる。Kudu に入れない。デプロイできない。ログが取れない。一時的に public access を開ける。Access Restriction に委託先 IP を追加する。そのまま戻し忘れる。

これは本当に起きます。

だから、私は最初から保守導線を設計します。

デプロイはどこから行うのか。Azure DevOps / GitHub Actions は public 経由か、self-hosted agent か。委託先は VPN / ExpressRoute 経由か。Kudu / SCM は private で解決できるか。障害時の緊急保守端末はどこにあるか。Break glass 的に public を開ける場合、誰が承認し、何分で閉じるか。変更ログは残るか。例外承認台帳に記録するか。

閉域化で一番危ないのは、平時ではなく障害時です。障害時のために public を開ける設計なら、それは閉域設計ではなく、例外付き公開設計です。その事実を契約・監査資料に書く必要があります。

11. クラウド法務として一番問題になる表現

私は、資料の文言もかなり厳しく見ます。

危ない表現はこれです。

「VNet Integration により閉域化」「App Service は VNet 内に配置」「PaaS は private 化済み」「インターネットからアクセス不可」「完全閉域」「外部公開なし」「監査対応済み」

この表現が、実態と合っていないことがあります。

App Service はマルチテナントの PaaS であり、VNet Integration によって App Service 自体が VNet 内に配置されるわけではありません。App Service から VNet へ出ていく通信が可能になる、という整理が正確です。

私は資料では、こう書きます。

「VNet Integration により、App Service から VNet 内または VNet 経由のバックエンドリソースへの送信経路を構成」「App Service への受信経路は、Private Endpoint、Private DNS、Public network access、Access Restrictions により別途制御」「保守導線として SCM / Kudu の private 解決とアクセス制御を設計」「例外的な public access は、承認制・期限付き・証跡保全の対象」

このように書かないと、契約書・監査資料・セキュリティチェックシートで誤解を生みます。

12. 事故時に聞かれる質問

この設計を間違えると、事故後に必ずこう聞かれます。

「閉域化済みと聞いていたのに、なぜ外部からアクセスできたのですか」「VNet Integration と Private Endpoint の違いを説明してください」「Public network access はいつまで有効でしたか」「Access Restrictions の allow ルールは誰が追加しましたか」「委託先の保守アクセスはどの経路でしたか」「SCM / Kudu は公開されていましたか」「Private DNS の設定はいつ変更されましたか」「外部からのアクセスログは残っていますか」「監査資料に閉域と書いた根拠は何ですか」

ここに答えられないと、技術事故が説明事故になります。

山崎行政書士事務所のクラウド法務では、技術設計をそのまま終わらせず、説明できる設計にします。

13. 私ならこう設計する

App Service の PaaS 閉域を本気で設計するなら、私は最低限この構成を考えます。

App Service からバックエンド PaaS へは VNet Integration。バックエンド PaaS は Private Endpoint。バックエンド用 Private DNS Zone を VNet に link。App Service 自体への受信は Private Endpoint。App Service 用 privatelink.azurewebsites.net を構成。SCM / Kudu 用レコードも確認。Public network access は原則無効化。例外的に public を残す場合は Access Restrictions で期限付き制御。保守端末は VPN / ExpressRoute / Bastion / Jumpbox / self-hosted agent 経由。委託先アクセスは Entra ID、条件付きアクセス、PIM、作業チケットと紐づける。Sentinel / Log Analytics にアクセスログと変更ログを保存。Azure Policy で public access 残存や Private Endpoint 未設定を検知。例外承認台帳を作る。

ここまでやって、初めて「PaaS閉域設計」と呼べます。

14. 山崎行政書士事務所としての見解

私は、App Service の閉域設計を、単なるネットワーク設計とは見ません。

これは、契約・監査・委託先管理・個人情報保護・インシデント対応に直結します。

閉域化済みと書いたのに public が残っていた。委託先が public 経由で保守していた。Private Endpoint はあったが DNS が public に向いていた。SCM が公開されていた。Access Restrictions の例外ルールが残っていた。ログが残っていなかった。

この場合、技術ミスだけではなく、説明責任の問題になります。

山崎行政書士事務所としては、次の成果物を整備すべきだと考えます。

App Service 閉域構成図。送信・受信経路分離表。VNet Integration 対象一覧。Private Endpoint 一覧。Private DNS Zone Link 一覧。Public network access 残存一覧。Access Restrictions 例外一覧。SCM / Kudu 保守導線表。委託先アクセス責任分界表。ログ・監査証跡設計書。例外承認台帳。監査向けワンペーパー。

これにより、情シス、法務、監査、委託先、経営層が同じ絵を見られます。

15. 最終評価

私は、VNet Integration の誤解をかなり危険視しています。

理由は、技術者の中でも、送信と受信を混ぜて説明してしまうことがあるからです。そして、その誤解がそのまま契約書、監査資料、提案書、セキュリティチェックシートに流れます。

正しい整理はこれです。

VNet Integration は送信。Private Endpoint は受信。Private DNS は名前解決。Public network access は公開面の制御。Access Restrictions は public endpoint への補助的な入口制御。保守導線は別設計。ログと例外承認が監査証跡。

山崎行政書士事務所のクラウド法務として、私はこのテーマを次の一文で整理します。

PaaS閉域化とは、VNet Integration を入れることではない。送信経路、受信経路、DNS、公開アクセス、保守導線、委託先権限、監査証跡を分けて設計し、後から説明できる状態にすることだ。

これを間違えない会社は、Azure PaaS を安全に使えます。これを混同する会社は、「閉域化済み」と言いながら、外部から App Service に到達できる設計を作ります。