はじめに
本稿は、オンプレと Azure を ExpressRoute で直結し、アプリは Hub‑Spoke で分離、PaaS は Private Link 経由で閉域接続する前提で、金融向けに求められがちな 統制・監査・分離を満たすための「全体像」を整理します。
なお、アウトバウンド設計（NAT/既定経路）には排他的な選択があります。
※排他的なのは「同一サブネット」であり、例外直出しを許容する場合は サブネットを分けて ルートテーブルと NAT の前提を切り分けます。
・強制トンネリング（既定経路 0.0.0.0/0 を Hub の集約装置へ）を採る場合、同一サブネットの NAT Gateway は意図どおり機能しません（既定経路によりバイパスされるため）。
・NAT Gateway を Spoke に置いてアウトバウンドを分散/最適化するなら、0.0.0.0/0 を Hub へ向ける設計自体を再整理し、Split/Semi‑Split トンネルとして設計します。
本稿では、金融案件で扱いやすい 「Hub 集約（強制トンネリング）＋Azure Firewall（または NVA）」を基本方針として記述し、必要に応じて代替案も補足します。
最小構成例（基本：Hub 集約アウトバウンド）
On‑Prem
│ (ER/VPN)
▼
[Hub VNet]
├─ ER Gateway / VPN Gateway
├─ Azure Firewall（または NVA）
├─ （任意）NAT Gateway ※Firewall/NVA の SNAT 逼迫対策として Hub 側で利用する場合
├─ DNS Private Resolver（Inbound/Outbound）
├─ Bastion / Jump
└─ Shared services Subnets
│
├─────Peering─────┐
▼ ▼
[Spoke-App] [Spoke-Data]
├─ App Subnet ├─ DB Subnet
├─ （任意）Ingress Subnet（Application Gateway v2 など）
└─ NSG（最小権限） └─ Private Endpoints（Storage/SQL/KeyVault 等）
補足：Spoke に NAT Gateway を置く構成は「Split/Semi‑Split トンネル」として別設計になります（強制トンネリングと同居させない）。
本稿は原則として強制トンネリング（0.0.0.0/0 を Hub 集約）を基本とします。
ただし例外として、特定のサブネットのみ Internet 直出し（NAT Gateway 等）を許容する場合は、当該サブネットには 0.0.0.0/0→Hub を設定しないなど、ルートテーブルと NAT の前提を分けて設計します。
1. Hub-Spoke ネットワーク構成
まずネットワークの骨格は Hub‑Spoke です。共有機能（ゲートウェイ、セキュリティ境界、名前解決、踏み台など）は Hub に集約し、業務ごとのアプリは Spoke に分離します。
既定経路（0.0.0.0/0）と例外の扱い
金融向けの統制・監査では、原則として **Spoke のワークロード サブネット（App/DB など）**の既定経路を、ユーザー定義ルート（UDR）で Hub の集約装置（Azure Firewall / NVA）へ誘導し、外向きと東西の通信を集約点で統制します（強制トンネリング）。
一方で、「全 Spoke サブネット例外なしに 0.0.0.0/0 を NVA に向ける」と書き切るのは危険です。サービス専用サブネットは例外設計が必要で、特に次は要注意です。
Application Gateway v2 専用サブネット
一律に 0.0.0.0/0 → Virtual Appliance を適用すると、非対称ルーティングやヘルス判定失敗など通信不成立を招きやすい典型構成になります。
→ 原則として AppGW v2 専用サブネットは既定経路の強制トンネル適用を例外扱いにします。どうしても 0.0.0.0/0→NVA を適用する場合は、Microsoft が示す Application Gateway v2 のルーティング要件（Network Isolation を含む前提条件）を満たし、疎通・健全性を含む検証結果で成立を証明できることを条件に、別途設計・検証します。
（参考）GatewaySubnet / AzureBastionSubnet などの サービス要件が強いサブネット
→ これらも “全サブネット一律” ではなく、サービス仕様に沿った扱いが前提です。
NSG と閉域化の基本
パケットの最初と最後の番人は NSG です。サブネットおよび NIC 単位に最小許可で絞り、フローログを必ず採取して可観測性に繋げます。
PaaS への接続は Private Endpoint/Private Link を基本にし、ストレージやデータベース、Key Vault など機微データを扱うサービスはすべて仮想ネットワーク内のプライベート IP で到達させます。
これに合わせて Private DNS Zone を用意し、該当 FQDN をプライベート名解決に切り替え、すべての VNet と紐付けます。アプリの公開は L7 を理解する Application Gateway（WAF）に正面で受けさせ、パス／ホストベースのルーティングと OWASP ルールで守りつつ、背面はアプリの種類に応じて Standard Load Balancer（L4）やサービス固有のエンドポイントへ接続します。
Firewall と NAT の整理（矛盾しない書き方）
東西・外向きの統制や URL/FQDN 単位の制御、集中 SNAT・ログが必要なら Azure Firewall（または NVA）を Hub に据えます。
大量のアウトバウンドを捌く必要がある場合は、次のどちらかで設計を整理します。
（基本）強制トンネリングを維持しつつ、Hub 側で SNAT 能力を増やす
→ Azure Firewall/NVA の設計（必要なら Hub 側に NAT Gateway を関連付ける等）で吸収します。
（代替）Spoke に NAT Gateway を置く “Split/Semi‑Split” 設計に切り替える
→ この場合、同一サブネットで 0.0.0.0/0 を Hub へ向けない（NAT と矛盾するため）。監査要件や経路統制要件と合わせて、設計方針として明文化します。
2. ExpressRoute と VPN の冗長化設計
オンプレとの接続は ExpressRoute を第一優先にし、物理的に経路が異なる 2 本で二重化します。可能なら事業者やビル導入経路、Peering ロケーションも分け、Azure 側の仮想ネットワークゲートウェイはゾーン冗長 SKU とし、FastPath を有効化してデータプレーンを短縮します。
BGP の優先制御（誤解しやすい点の整理）
BGP の経路制御は「ER を高優先、S2S VPN を低優先」となるよう設計しますが、“どちら向きの制御か” を混同しないことが重要です。
Azure → オンプレ方向
同一条件（例：同一プレフィックス長）で経路が提示された場合、Azure 側の選好として ExpressRoute が VPN より優先される前提で設計します（長いプレフィックス一致など一般の経路選択原則は別途）。
→ したがって「Azure 側で ER 優先にするために AS‑Path prepend が必要」という前提は、誤解を招きます。
オンプレ → Azure 方向
オンプレ側の BGP ポリシーで、ER 側の Local‑Preference を高くし、必要に応じて VPN 側で AS‑Path を伸ばすなどして「ER 優先」を担保し、非対称ルーティングを避けるのが定石です。
Azure 側に複数接続（複数 ER 経路など）がある場合
→ Azure 側の経路選好は、Connection Weight 等（同種経路間の選好）も含めて整理します。
フォールバックは回線障害時に自動で ER→VPN へ切り替わること、復旧時は無停止で ER へ復帰することを前提に、BGP の収束時間がアプリの SLO に収まるかを受入試験で確認します。ネットワーク層で経路が切り替わってもアプリの宛先 FQDN は固定のままとし、DNS 切替で混乱を生まないのが安定運用のコツです。
3. 名前解決と DNS 設計
名前解決は分割 DNS（Split‑Horizon）が前提です。内部向けの名前は Private DNS Zone、外部公開は Public DNS に明確に分けます。
ハイブリッドの経路では Azure DNS Private Resolver を Hub に配置し、オンプレからの問い合わせは Inbound Endpoint で受け、Azure からオンプレ名空間への解決は Outbound Endpoint とフォワードルールで実現します。オンプレ DNS には条件付きフォワーダを設定して Azure 側へ転送させ、Private Endpoint のゾーンはすべての Spoke と正しくリンクされていることを疎通試験で証明します。
経路多重化（ER×2 と VPN）と同様に、名前解決経路にも冗長性を持たせ、障害時に名前解決が詰まらないよう TTL 設計も含めて検討します。
4. アイデンティティと権限管理
アイデンティティと権限管理は Microsoft Entra ID（旧 Azure AD）を中核とします。管理プレーンの権限は RBAC をグループベースで付与し、サブスクリプション→リソースグループ→リソースの階層に応じて最小権限に落とします。
特権は PIM で「Eligible（適格）」状態に保ち、昇格は JIT で承認・理由・チケット番号の入力を必須にします。運用アカウントはすべて多要素認証と条件付きアクセス（場所、デバイス準拠、リスクベース）を適用し、いわゆる break‑glass アカウントは厳重な保管手順と演習を伴う例外として管理します。
ワークロード側の資格情報は原則廃止し、Managed Identity で Key Vault、Storage、SQL 等に権限委譲します。これによりシークレットの埋め込みと有効期限リスクを排除し、監査ログも中央に集約できます。
5. コンピュート設計の選定基準
コンピュートは非機能と運用力から選びます。HTTP ベース中心でインフラ運用を極小化したい場合は App Service や Functions、コンテナだが Kubernetes のフル運用までは要らない場合は Container Apps が向きます。
ネットワークポリシーやサイドカー、きめ細かなリリース制御を要するマイクロサービス群は AKS が適任ですが、クラスタ運用（ノードプール、アドオン、アップグレード戦略）の責務が増える点を受け止める必要があります。
OS やミドルウェアを完全に握りたい、ドライバや特殊ポート、極端なレイテンシ要件がある、あるいはレガシー資産を抱える場合は VM/VMSS を選びます。いずれも Blue‑Green や Canary といった無停止リリースの方針と、可観測性（メトリクス、ログ、トレース）の整備を同時に設計し、運用で回る最小構成から始めるのが実践的です。
6. ストレージの冗長化と暗号化設計
ストレージは RTO/RPO と可用性の要件から冗長化を選択します。単一リージョン内の三重化で十分なら LRS、AZ 障害にも書き込み継続を求めるなら ZRS、リージョン障害まで視野に入れるなら GRS/RA‑GRS もしくは GZRS/RA‑GZRS を検討します。
RA 系を選ぶと DR サイトで読み取りを継続できる反面、書き込みの扱いと整合性はアプリ側設計が必要です。暗号化は既定のサーバー側暗号化に加えて顧客管理鍵（CMK）を適用し、Disk は Disk Encryption Set、Storage はアカウント単位の CMK を Key Vault または Managed HSM で保護します。
伝送は TLS 1.2 以上が前提で、Private Link によって経路を閉じます。データ寿命はライフサイクル管理で Hot/Cool/Archive を自動遷移させ、WORM（イミュータブル）とバージョニングでランサム対策を仕込み、定期的な復元演習で“戻せること”を証明します。
7. ルーティング・NAT・帯域設計
ルーティングと NAT、帯域は数で裏付けます。ピークのリクエスト率と平均ペイロード（ヘッダ込み）から理論帯域を算出し、余裕係数として 1.5～2 倍を見込んだ上で ER 回線の本数と FastPath の有無で割り付けます。
アウトバウンドは SNAT ポートの枯渇を起こしやすいので、宛先ごとの同時接続数を見積もり、必要に応じて SNAT 能力を増強します。ここは 設計方針に応じて手段が変わるため、矛盾が出ないように書き分けます。
強制トンネリング（既定経路を Hub 集約）を採る場合
Spoke の該当サブネットに NAT Gateway を付けても 意図したアウトバウンドには使えません（既定経路で Hub 側に流れるため）。
SNAT の要件は **Azure Firewall/NVA 側（必要に応じて Hub 側での NAT 併用等）**で満たす方針に整理します。
Spoke NAT（Split/Semi‑Split）を採る場合
そのサブネットでは 0.0.0.0/0 を Hub へ向けない（NAT と矛盾するため）。
統制・監査の要件とトレードオフを明記し、どのサブネット/どの通信を Hub 経由にするかをプレフィックス単位で設計します。
設計審査で説明できるよう、少なくとも次をセットで揃えます。
ワークロード サブネットの既定経路が意図どおり集約装置へ収束していること（ただし AppGW v2 専用サブネット等は例外設計）
PaaS は Private Endpoint 宛の経路で Public を一切通らないこと
フォールバックで VPN に落ちた時の遅延と帯域でも SLO を満たせること
SNAT/帯域の試算と負荷試験結果（ピーク時の同時接続・宛先分布・ポート消費の見立て）
8. ExpressRoute 二重化と経路多様性
ExpressRoute の二重化と経路多様性は、提案書で物理層からはっきり言語化します。キャリア、ラストワンマイル、ビル内導通、Peering ロケーション、ルータと光収容、MSEE の冗長までを図示し、A 回線と B 回線がどこまで分離されているかを可視化します。
Azure 側はゾーン冗長ゲートウェイと FastPath の適用を前提にします。経路制御は、Azure → オンプレは ER 優先が基本であることを押さえた上で、オンプレ → Azureの優先度（Local‑Pref / AS‑Path など）はオンプレ側の設計根拠として記載します。四半期ごとの切替演習で期待切替時間（目標の収束時間）を測定・記録し、SLO と照合して運用に落とします。
9. 証明書と鍵管理の設計
証明書と鍵は Key Vault（必要に応じて Managed HSM）で一元管理します。証明書は Key Vault の証明書オブジェクトで有効期限と自動更新ポリシーを管理し、アプリや Application Gateway、Front Door、App Service からは「バージョンなしの URI」で参照します。
更新は新バージョンの発行であり、Event Grid をトリガにアプリ側の再読込やデプロイを自動化します。満了の 60～45 日前に自動発行と通知、30 日前に手動エスカレーション、という二重線で取りこぼしを防ぎます。
暗号鍵は Key Vault または Managed HSM で生成・保護し、Disk Encryption Set、Storage CMK、SQL TDE、署名鍵などの依存先をインベントリ化した上で、定期ローテーション時の重複有効期間（ロールオーバー）と再暗号化手順を文書化します。
アプリ設定に平文シークレットを置かないこと、ワークロードの認証は Managed Identity へ移行すること、Key Vault の管理・アクセス・ポリシーの監査ログを SIEM に送り保全することが最重要です。
10. 設計の確認観点と品質保証
設計の確認観点をまとめると、以下です。
既定経路設計（0.0.0.0/0）が方針どおりで、NAT と矛盾していないか
強制トンネルなら Spoke NAT を前提にしない
Spoke NAT を使うなら 0.0.0.0/0 を Hub に向けない
サービス専用サブネット（特に AppGW v2）を “全サブネット一律” で扱って破綻していないか
PaaS は Private Link で完全閉域になっているか
NSG とログが最小許可・最大可視で運用可能か
ER の優先と VPN のフォールバックが、向き（Azure→オンプレ / オンプレ→Azure）を切り分けた BGP 設計と試験結果で裏付けられているか
Private DNS のリンク漏れや二重定義がないか
さらに、権限は PIM＋MFA＋条件付きアクセスで最小化され Managed Identity に置き換えが進んでいるか、コンピュートの選定が非機能と運用力に対して過不足ないか、ストレージの冗長化と暗号化・WORM と復元演習まで揃っているか、帯域と SNAT は数値で耐えられるか、そして証明書・鍵の自動ローテーションが実際に最後まで流れるか――ここまでを “設計審査の通過条件” として書き切るのが、品質重視の金融案件で失敗しないための要点です。
11. 参照リンク集
■ 全体アーキテクチャ／Hub-Spoke／ハイブリッド
■ Private Link／Private Endpoint／PaaS の閉域化
■ DNS／Private DNS／DNS Private Resolver
■ ファイアウォール／WAF／NAT／NSG まわり
（NSG 単体のリファレンスはこちら）
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
■ アイデンティティ／RBAC／PIM／Managed Identity
■ Key Vault／Managed HSM／証明書・鍵管理
■ コンピュート選定（App Service／Functions／Container Apps／AKS／VMSS）
■ ストレージ冗長化／暗号化／WORM／ライフサイクル
■ 監視／ログ／メトリクス／診断設定