NSGで「誰と通信してよいか」を決めたら、次のテーマは「通信がどの経路（ルート）を通るか」です。これを扱うのがルーティング。Azureは何も設定しなくても通信が流れる仕組み（システムルート）を持っていますが、実務では「全通信を一度ファイアウォールに通して検査したい」といった要件のために、この経路を意図的に上書きします。それを可能にするのがUDR（ユーザー定義ルート）です。
NSGは分かってきたけど、「ルートテーブル」とか「0.0.0.0/0をFirewallに向ける」って何をしてるの？
この記事では、ルーティングについて次の3つを順番に整理します。読み終えたときに、これらを自分の言葉で説明できるようになることをゴールにしています。
- システムルート（既定経路）の動きを理解している
- ユーザー定義ルート（UDR / ルートテーブル）で経路を制御できる
- 0.0.0.0/0 を Azure Firewall / NVA に向ける設計を理解している
システムルート（既定経路）の動き
まず大前提として、Azureは何も設定しなくても、VNet内の通信が正しく流れるように「システムルート」を自動で用意しています。だからVMを2台作れば、ルーティングを一切触らなくても互いに通信できるのです。
システムルートとは、Azureが各サブネットに自動で適用する既定の経路表です。「VNet内はVNet内で」「それ以外はインターネットへ」といった基本の道順が、最初から用意されています。
主なシステムルートを、宛先ごとの「次の行き先（ネクストホップ）」で整理すると次のようになります。
宛先アドレス ネクストホップ（次の行き先）
──────────────────────────────────────────
自分のVNetの範囲 → Virtual network（VNet内で直接届ける）
ピアリング先のVNet → VNet Peering（ピア接続経由）
0.0.0.0/0（上記以外全部）→ Internet（インターネットへ出す）ポイントは、0.0.0.0/0（＝「他のどれにも当てはまらない宛先すべて」を表す記法）は、既定でインターネットに向かうという点です。つまり何もしなければ、VNet内リソースはインターネットへ直接出ていける状態になっています。この既定の道順を理解しておくことが、次のUDRを考える出発点になります。
【ここが説明できればOK①】
「Azureはシステムルートを自動適用しており、VNet内は直接・ピア先はピアリング経由・それ以外(0.0.0.0/0)は既定でインターネットへ流れる」——これを言えれば、1つ目のチェックはクリアです。
ユーザー定義ルート（UDR / ルートテーブル）で経路を制御する
システムルートは便利ですが、実務では「既定の道順では困る」場面が出てきます。たとえば「インターネットへ直接出さず、必ずファイアウォールを通してから出したい」。この既定の経路を上書きするのが、UDR（User-Defined Route／ユーザー定義ルート）です。
UDRとは、ルートテーブルに自分で書く経路ルールです。「この宛先の通信は、次にここへ送れ」とネクストホップを指定してサブネットに関連付けると、システムルートより優先して適用されます。
使い方の流れは、NSGとよく似ています。①ルートテーブルを作る → ②ルート（宛先＋ネクストホップ）を書く → ③サブネットに関連付ける。関連付けて初めて効く点もNSGと同じです。ネクストホップには次のような種類を指定できます。
- Virtual appliance：Azure FirewallやNVA（後述）のIPへ送る
- Virtual network gateway：VPN/ExpressRouteゲートウェイ経由（オンプレ方向）
- Internet / None：インターネットへ出す／通信を破棄する（あえて塞ぐ）
# ルートテーブルを作成
az network route-table create -g rg-network -n rt-app
# ルートを追加：0.0.0.0/0 を Firewall(10.0.5.4) に向ける
az network route-table route create \
-g rg-network --route-table-name rt-app \
-n to-firewall \
--address-prefix 0.0.0.0/0 \
--next-hop-type VirtualAppliance \
--next-hop-ip-address 10.0.5.4
# サブネットに関連付け（これで有効化）
az network vnet subnet update \
-g rg-network --vnet-name myVnet -n subnet-app \
--route-table rt-appUDRは「Azureが用意した道順を、自分の都合で書き換える上書きルール」。作って→サブネットに当てて有効、という流れはNSGと同じだよ！
【ここが説明できればOK②】
「UDRはルートテーブルに書く経路ルールで、システムルートより優先される。作ってサブネットに関連付けると経路を制御できる」——これを説明できれば、2つ目のチェックはクリアです。
0.0.0.0/0 を Azure Firewall / NVA に向ける設計
UDRの最も代表的な使い道が、この「強制トンネリング」とも呼ばれる設計です。目的は明確で、「VNetから外へ出ていく全通信を、必ずファイアウォールに通して検査・記録する」こと。セキュリティ要件の厳しい企業ではほぼ必須の構成です。
やることは1つ。0.0.0.0/0（＝すべての外向き通信）のネクストホップを、既定のInternetから Azure Firewall（またはNVA）に向け直すだけです。図で見ると、通信の流れがこう変わります。
【既定（システムルート）】直接インターネットへ
VM ──→ 0.0.0.0/0 ──→ Internet
【UDR適用後】必ずFirewallを経由
VM ──→ 0.0.0.0/0 ──→ Azure Firewall ──検査──→ Internet
（ログ・許可/拒否・検査）ここで出てくる用語を整理しておきます。
- Azure Firewall：Azureのマネージドなファイアウォールサービス。通信の検査・許可/拒否・ログ記録を担う。
- NVA（Network Virtual Appliance）：サードパーティ製のファイアウォール等を仮想マシンとして持ち込んだもの。既存のセキュリティ製品を使いたい場合に選ぶ。
この「0.0.0.0/0 → Firewall」の設計は、後続の記事で扱うハブ＆スポーク構成と組み合わさります。ファイアウォールを「ハブVNet」に1つ置き、各業務VNet（スポーク）からの全通信をそこへ集約して検査する——というのが、企業ネットワークの王道パターンです。UDRは、その「集約」を実現する要の部品というわけです。
【ここが説明できればOK③】
「UDRで 0.0.0.0/0 のネクストホップをAzure Firewall / NVA に向けると、VNetからの全送信を検査させられる（強制トンネリング）。ハブ＆スポークの検査集約の要になる」——これを説明できれば、3つ目のチェックはクリアです。
まとめ
- システムルート：Azureが自動適用する既定経路。VNet内は直接、それ以外(0.0.0.0/0)は既定でインターネットへ
- UDR（ルートテーブル）：既定経路を上書きする自分のルール。作ってサブネットに関連付けて有効化
- 0.0.0.0/0 → Firewall / NVA：全送信を検査に通す定番設計。ハブ＆スポークの検査集約の要
1つのVNetの中の制御（サブネット・NSG・ルーティング）が固まったら、次は視点を上げて「VNet同士・オンプレとどう繋ぐか」です。VNetピアリング、ハブ＆スポーク、VPN Gateway / ExpressRouteを次の記事で整理します。今回学んだUDRが、そこでどう効いてくるかも見えてきます。
