「Azure Web App を VNet 統合したのにオンプレから見えない」「固定プライベート IP を付けたい」――この相談は非常に多い誤解から始まります。結論はシンプルで、VNet 統合は発信（Outbound）専用、着信（Inbound）にはプライベート エンドポイント（Private Endpoint）を使います。本稿では、その理由と設計の勘所、実践手順、運用の落とし穴までを一気通貫で解説します。
目次
なぜ「VNet 統合」だけではオンプレから Web App に届かないのか
Azure Web App（App Service）の VNet 統合 は、アプリから仮想ネットワーク（VNet）内のリソースへ向けた発信トラフィックを VNet に注入するための機能です。オンプレ／別ネットワークからの着信を受ける仕組みではありません。したがって、VNet 統合だけを構成しても Web App にプライベート IP は付与されず、オンプレから直接の到達性は確保できません。
オンプレミスと Azure は VPN（Site-to-Site など）で既に接続され、同じ VNet 内の仮想マシン（VM）には到達できる――それでも Web App には届かないのは、そもそもの入口（Inbound）が用意されていないからです。
よくある誤解を整理
- 誤解：「VNet 統合＝プライベート IP 付与」
→ 現実：VNet 統合は Outbound のみ。Web App に NIC やプライベート IP は付きません。 - 誤解：「VPN ができていれば Web App も見える」
→ 現実：Web App はマルチテナント PaaS。着信の私設回線口が必要（＝Private Endpoint）。 - 誤解：「パブリック IP の専有化（Dedicated Inbound）で解決」
→ 現実：これは パブリック経路の話。オンプレ直結の プライベート経路とは別問題です。
解決の原則：「Inbound はプライベート エンドポイント」
Web App に対し VNet 内の Private Endpoint（PE） を作成することで、アプリに対する着信口を VNet 側へ延伸できます。PE は VNet のサブネット内に NIC（仮想ネットワーク インターフェイス） を生成し、そこに プライベート IP を割り当てます。以降、オンプレからのトラフィックは VPN → VNet → PE → Web App という経路で流れます。
設計のポイント（要点）
| 項目 | 決めること／注意点 |
|---|---|
| サブネット | Private Endpoint 用に小さくても良い専用サブネットを用意（後述のネットワークポリシー仕様のため共用は避けるのが無難）。 |
| IP アドレス | PE のプライベート IP は自動（動的）割り当ても可能。運用上わかりやすくするため 静的 IP を指定しておくと便利。 |
| DNS | privatelink.azurewebsites.net の Private DNS ゾーン利用が基本。オンプレ DNS と連携し、オンプレ端末から Web App 名を引くと プライベート IP を返すようにする。 |
| アクセス制御 | 公開ネットワーク（インターネット）経由を遮断し、Private Endpoint 経由のみ許可へ。App Service のアクセス制限／Public network access 設定で制御。 |
| 監視・課金 | Private Link の時間課金＋転送量課金が発生。Private DNS ゾーンの課金も考慮。 |
機能比較（一覧表）
| 機能 | 用途 | IP 付与 | 着信可否 | 代表シナリオ | 主な注意点 |
|---|---|---|---|---|---|
| VNet 統合 | Outbound を VNet に流す | Web App に NIC/Private IP は付かない | 不可 | アプリから DB/Redis 等へ私設経路でアクセス | Inbound には一切使えない |
| Private Endpoint | Inbound を VNet 側に引き込む | PE の NIC に Private IP（静的も可） | 可 | オンプレ→VPN→VNet→Web App（私設） | DNS 設計必須。ネットワークポリシー仕様に注意 |
| App Service Environment v3（ILB） | 専用環境で私設のみ公開 | ILB 経由のプライベート VIP | 可 | 大規模・厳密な境界制御、専有運用 | コスト・環境構築の重さ。用途により過剰 |
| App Gateway + Private Link | WAF/リバプロ経由で私設公開 | AppGW のプライベート IP（バックエンドは PL） | 可 | WAF 必須、L7 制御や共通入口を設けたい | 運用構築が増える。まずは PE 直結が簡素 |
前提条件（サンプル想定）
- オンプレミスと Azure は Site-to-Site VPN で接続済み。
- 対象は Windows 版 Azure Web App（Linux でも手順はほぼ同じ）。
- VNet 統合は既に構成済み（Outbound 用）。
- Resource Group、VNet、サブネット、権限（Contributor 以上）がある。
手順（Azure Portal）
- Private Endpoint 用サブネットを準備
- VNet に「
subnet-pe-webapp」のような小規模サブネットを追加。 - Private Endpoint はサブネットの ネットワークポリシー（NSG/UDR）無効化要件があるため、専用サブネットを推奨。
- VNet に「
- Private DNS ゾーン（
privatelink.azurewebsites.net）を作成
- ゾーン作成後、VNet とのリンクを作成（登録は無効、解決のみで可）。
- Azure DNS Private Resolver または DNS フォワーダー（Azure VM）で、オンプレからこのゾーンへの名前解決を Azure 側へフォワードする設計を決める。
- Web App に Private Endpoint を作成
- Web App → [ネットワーク] → [プライベート エンドポイント] → [＋ 追加]。
- 対象リソース：該当 Web App、リージョン一致を確認。
- VNet と先ほどのサブネットを選択。
- IP アドレスは静的（手動）にし、管理しやすい空きアドレスを指定（動的でも可）。
- Private DNS ゾーン統合をオンにして、
<app-name>.privatelink.azurewebsites.netの A レコードを自動作成。
- Public 経路を閉じる（推奨）
- Web App → [ネットワーク] → [アクセス制限] で Private Endpoint 経由のみ許可にする、または「Public network access: Disabled」相当の設定にする。
- オンプレ DNS を構成
- オンプレ DNS から
privatelink.azurewebsites.netへのクエリを Azure 側へフォワード。 - クライアントが使うホスト名の設計を選択（後述）。
- オンプレ DNS から
- 疎通確認
nslookup <app-name>.privatelink.azurewebsites.net nslookup <app-name>.azurewebsites.net （※オーバーライド設計にした場合） curl -I https://<利用するホスト名>/health注意：ICMP（ping）は通りません。HTTP/HTTPS（443）で確認します。
手順（Azure CLI サンプル）
# 変数
RG=rg-app
LOC=japaneast
VNET=vnet-hub
SUBNET=subnet-pe-webapp
APPNAME=mywebapp-01
# Private DNS ゾーン作成と VNet リンク
az network private-dns zone create -g $RG -n privatelink.azurewebsites.net
az network private-dns link vnet create -g $RG -n link-$VNET
-z privatelink.azurewebsites.net -v $VNET --registration-enabled false
# Web App リソース ID 取得
APPID=$(az webapp show -g $RG -n $APPNAME --query id -o tsv)
# Private Endpoint 作成（静的 IP 例: 10.10.20.10）
az network private-endpoint create -g $RG -n pe-$APPNAME
--vnet-name $VNET --subnet $SUBNET
--private-connection-resource-id $APPID --group-id sites
--connection-name peconn-$APPNAME
--manual-request false
--private-ip-address 10.10.20.10
# Private DNS A レコード作成（自動連携が無い場合の手動例）
az network private-dns record-set a add-record -g $RG
-z privatelink.azurewebsites.net -n $APPNAME -a 10.10.20.10 DNS 設計：3つの選択肢
Private Endpoint を作成すると、<app-name>.privatelink.azurewebsites.net がプライベート IP に解決できるようになります。オンプレ利用者（クライアント）がどのホスト名でアクセスするかを、次のいずれかで決めます。
設計 A：privatelink のホスト名をそのまま使う
- ブラウザやアプリのエンドポイントを
<app-name>.privatelink.azurewebsites.netに変更。 - メリット：シンプル。
privatelinkゾーンだけの連携で済む。 - デメリット：既存の URL を変える必要がある。証明書名（TLS）やリダイレクト設計に配慮。
設計 B：社内ドメインのカスタム ドメインを使う（推奨）
app.contoso.localやapp.intra.contoso.com等の 社内 DNS 管理ドメインを Web App にカスタム ドメインとして追加。- その FQDN を CNAME で
<app-name>.privatelink.azurewebsites.netに向ける（社内 DNS ゾーンで解決）。 - メリット：外部公開と分離でき、URL を社内標準に合わせられる。証明書運用も一元化。
- デメリット：カスタム ドメインのバインドと証明書（App Service Managed Certificate など）の用意が必要。
設計 C：azurewebsites.net の内部上書き
- 社内 DNS に
azurewebsites.net私設ゾーンを作り、<app-name>の A レコードを PE の IP に向ける、または CNAME をprivatelink側へ。 - メリット：既存の URL（
<app-name>.azurewebsites.net）を変えずに済む。 - デメリット：ゾーン全体を社内で抱えるため、将来的な他アプリへの影響に配慮（名前衝突や運用負担）。
セキュリティ強化（必須レベルの設定）
- Public network access を無効化：Private Endpoint 経由のみを許可。
- アクセス制限（Access Restrictions）：想定外の経路や Service Tag を誤って許可しない。
- SCM/Kudu へのアクセス：同様に Private Endpoint 経由または限定した経路のみに。
- FTP/FTPS：不要なら停止。必要時は FTPS のみ + 制限。
- TLS 証明書：カスタム ドメイン利用時は必ずバインドし、自動更新を設計（Managed Certificate も活用）。
運用・監視・コストの実務ポイント
- 監視：App Service の診断ログ、Private Link 接続状態、応答時間（Application Insights）を可視化。
- 課金：Private Endpoint（時間課金 + 転送量）、Private DNS ゾーン、VPN ゲートウェイのコストを月次試算。
- バックアップ：App Service のバックアップ機能、IaC（Bicep/ARM/Terraform）で構成の再現性を確保。
- 変更管理：Private DNS のレコード変更は影響が大きい。TTL とキャッシュに注意。
トラブルシューティング チェックリスト
| 症状 | 確認ポイント | 対処 |
|---|---|---|
| 名前解決でパブリック IP が返る | オンプレ DNS のフォワーダー設定／Private DNS ゾーン連携 | privatelink.azurewebsites.net を Azure 側へ正しく転送。必要なら社内 CNAME/A を上書き |
| HTTPS は通るが URL がリダイレクトで外へ出る | アプリ側の URL 生成ロジック／リバースプロキシ設定 | Host ヘッダに依存した絶対 URL 生成を修正。 カスタム ドメイン利用時はその FQDN を基準に |
| 一部端末のみ到達しない | キャッシュ DNS／分断 DNS（Split-Horizon） | 端末の DNS キャッシュクリア。複数 DNS 経路の整合性を確認 |
| ping は失敗する | ICMP は閉じている | HTTP/HTTPS で疎通確認（curl -I やヘルスエンドポイント） |
| Private Endpoint 作成に失敗 | サブネットのポリシー／アドレス枯渇 | 専用サブネットで十分な空き IP。ネットワークポリシー要件を満たす |
アーキテクチャ選定ガイド
要件によっては、PE 以外の選択肢が適します。以下を目安にしてください。
- 最小構成・早く安全に閉じたい：Private Endpoint + Private DNS（本稿の方法）
- WAF/共通入口・ルーティング統制が必要：Application Gateway（プライベート フロント）+ Backend への Private Link
- 厳密隔離・大規模：App Service Environment v3（ILB モード）
オンプレ端末 ── VPN ── VNet（PE サブネット）
│
├─ [Private Endpoint IP] ── App Service（Web App）
└─ [Private DNS] 解決
実運用で効く Tips
- IP の「見える化」：運用台帳に PE の静的 IP、サブネット、作成者、用途、紐付く Web App 名を必ず記録。
- テストの標準化：
nslookup→curl -I→ アプリの/health→ 実業務パスの順でチェック。 - 多環境の切り替え：DEV/TEST/PROD で FQDN を分ける。DNS 側での CNAME 差し替えで段階反映できるように。
- ロギング：「接続はできるが 403/401」はアプリ認証の問題。
ネットワークは DNS/疎通、アプリは認証・権限と切り分け。
よくある質問（FAQ）
Q. Web App に完全な固定プライベート IP を「直付け」できますか？
A. できません。Web App 自身に NIC を付けることはできず、Private Endpoint の NIC に対してプライベート IP を割り当てます。これが実質的な「固定プライベート IP」として機能します。
Q. Private Endpoint の IP を静的にしたいのですが？
A. 作成時にサブネット内の未使用アドレスを指定して静的割り当てが可能です。後から変更する場合は影響が大きいのでメンテナンス時間を確保してください。
Q. NSG や UDR で Private Endpoint のトラフィックを制御できますか？
A. Private Endpoint の設計上、サブネットのネットワークポリシー適用には制約があります。PE 用サブネットは基本的に専用にし、他リソースと共用しない設計を推奨します。
Q. 複数の Web App を 1 つの IP でまとめられますか？
A. Private Endpoint は 1:1 を基本と考えましょう。WAF/リバースプロキシでまとめたい場合は Application Gateway を検討してください。
Q. 可用性の観点は？
A. Web App 自体はマネージド冗長です。ネットワーク側は VPN ゲートウェイ冗長、PE サブネットのアドレス余裕、DNS 冗長、監視アラートまでを一式で設計します。
完全手順（要点の再掲）
- 「VNet 統合は Outbound 専用」と理解する。
- Web App に対し Private Endpoint を作成し、静的 IP を割り当てる。
- Private DNS ゾーン（
privatelink.azurewebsites.net）を作成・VNet リンク。 - オンプレ DNS から当該ゾーンへフォワード。必要に応じて カスタム ドメイン（社内 FQDN）で CNAME を張る。
- Web App の アクセス制限で Private Endpoint 経由のみ許可（Public 経路停止）。
- nslookup / curl で疎通確認し、監視とバックアップを整備。
ケーススタディ：最短でオンプレ到達を実現する
要件：オンプレ PC から https://intra-app.contoso.local で Web App にアクセス。外部公開は不可。
解：
- PE 用サブネット（/28 程度）を作成。
- Web App に Private Endpoint を作成し、IP を
10.20.30.10（静的）に固定。 - Private DNS ゾーン
privatelink.azurewebsites.netを作り VNet にリンク。 - 社内 DNS に
intra-app.contoso.localを CNAME で<app-name>.privatelink.azurewebsites.netに設定。 - Web App に
intra-app.contoso.localをカスタム ドメインとして追加し、証明書を適用。 - Public network access を無効化。
- オンプレから
nslookupとcurl -Iで確認。
「固定プライベート IP を割り当てるには？」に対する最短回答
- できること：Web App に対する Private Endpoint の NIC に 静的 IP を割り当てる（実質的な固定プライベート IP）。
- できないこと：Web App 本体に NIC を付けて直接 IP を持たせる。
- 要点：Inbound は Private Endpoint、Outbound は VNet 統合。DNS は
privatelink.azurewebsites.netを基点に設計。
ベストプラクティスまとめ
- VNet 統合＝発信専用／Private Endpoint＝着信専用と覚える。
- PE は専用サブネット＋静的 IPで管理性を上げる。
- DNS 設計（privatelink ゾーン、カスタムドメイン、フォワーダー）を最優先で詰める。
- Public 経路を必ず遮断し、最小権限でアクセスを限定。
- 監視・課金・バックアップを 1 セットで運用設計。
付録：PowerShell サンプル（参考）
# Az モジュール前提
$rg = "rg-app"
$vnet = "vnet-hub"
$subnet = "subnet-pe-webapp"
$app = "mywebapp-01"
$peName = "pe-$app"
$peIP = "10.10.20.10"
# WebApp のリソース ID
$appRes = az webapp show -g $rg -n $app | ConvertFrom-Json
$appId = $appRes.id
# Private Endpoint 作成（静的 IP）
az network private-endpoint create -g $rg -n $peName ` --vnet-name $vnet --subnet $subnet`
--private-connection-resource-id $appId --group-id sites `
--connection-name "peconn-$app" --private-ip-address $peIP
# DNS ゾーン・レコード（必要時）
az network private-dns zone create -g $rg -n privatelink.azurewebsites.net
az network private-dns link vnet create -g $rg -n "link-$vnet" ` -z privatelink.azurewebsites.net -v $vnet --registration-enabled false
az network private-dns record-set a add-record -g $rg`
-z privatelink.azurewebsites.net -n $app -a $peIP 最後に
オンプレ接続の Web App は「Private Endpoint と DNS 設計」で 8 割決まります。複雑な自前のロードバランシングや NAT を組む前に、まずは PE を素直に導入し、Public を閉じ、DNS を正しく整える――この王道でシンプルに、速く、安全に到達性を確保しましょう。
コメント