～大規模エンタープライズが直面する ExpressRoute 環境の複雑性～
1. 問題の概観とビジネスインパクト
1.1 重複アドレスの背後にある事業要因
大企業が Azure を採用する際、多くの場合オンプレミス環境との密結合が求められます。
たとえば SAP などの基幹システムやデータレイクをクラウド化しつつ、社内ネットワークから専用線で安全・高速に接続するために ExpressRoute を選択するケースが典型です。
しかし、部門ごとにバラバラに管理されてきた RFC1918 アドレス（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 など）がすでに多数存在し、これが Azure 仮想ネットワーク (VNet) のアドレス空間と衝突すると、障害あるいはネットワーク統合の頓挫が発生します。
ビジネス上のインパクトは甚大で、アドレス更改が遅れると合併後のシステム統合が進まず M&A シナリオ全体の ROI が下がる、あるいはクラウド移行計画が大幅に遅延する、といったリスクが顕在化します。
ひとたび本番環境で IP 衝突が起きれば、パケットの送信先が特定できず通信不能になるリソースが出るなど、システム障害へと直結することも少なくありません。
1.2 ExpressRoute の特徴がもたらす衝突リスク
加えて ExpressRoute は インターネットを経由せず Azure とオンプレミスを直接 L3 接続する点が特徴的です。
インターネット上の NAT などを通さないため、ネットワークエッジでのアドレス変換がデフォルトでは行われません。
すなわち、同じ 10.0.0.0/16 がオンプレ側にあり、Azure 側にも別部門で使われていると、どちらのアドレス空間が優先されるかルーターにとって曖昧になり、衝突を回避できません。このように プライベート通信を実現する手段が逆に プライベート空間の重複という課題を鮮明にするのです。
2. RFC1918 空間の再設計: 根本的かつ最優先のアプローチ
2.1 組織レベルでの IP アドレス管理 (IPAM) の重要性
オンプレミスとクラウドを安定的に統合するには、まず IP アドレス空間を全社で可視化し、重複を原則排除する設計方針が不可欠です。
現代の大企業ではサブネットや VLAN 単位であまりに多数のプライベートネットワークが独立管理されており、IT 統合の段階で衝突が続発します。
ここで IPAM（IP Address Management）ツールの活用や、アドレス割り当ての承認プロセスを一本化することが不可欠です。
Azure の VNet でも大・中規模のサブネットを切る際には事前にオンプレミスとの整合性を検証し、CIDR レンジが衝突していないかをツールで検知できる体制を整えます。
2.2 Azure Landing Zone 設計での CIDR 配分
Azure では一度 VNet を作成した後に追加アドレス空間を割り当てることは可能ですが、既存サブネットのサイズを縮小したり、アドレス範囲を大きく変える作業は容易ではありません。
Azure Landing Zone の設計で推奨されるように、最初から将来の拡張も視野に入れた集約 CIDRを幾つか用意してサブネットを階層的に分割し、オンプレミスの既存空間と競合しないよう調整するのがベストプラクティスです。
たとえばオンプレミスで 10.0.0.0/8 を広域に使っているならば、Azure にはあえて 172.16.0.0/12 系を割り当てるなどの対策を講じます。
もちろん、オンプレで 172.16.0.0/12 も使っている組織は少なくありませんが、その場合は 192.168.0.0/16 を割り当てるなど、複数のクラスレス空間を段階的にマッピングし直す設計が基本となります。
2.3 IPv6 導入による衝突回避
近年、Azure では VNet のデュアルスタックサポートや ExpressRoute IPv6 ピアリングが進化し、エンタープライズでも IPv6 の活用が現実的になってきました。
大規模アドレス競合を根本から解決するには、IPv6 への移行・並行運用が有力です。とはいえ、既存アプリケーションやドメインコントローラー、ファイアウォール機器が IPv6 に対応していないケースも多いので、一気に切り替えるのは困難ですが、将来像として「新しいシステムは IPv6 を優先し、IPv4 はレガシーに留める」方策を採用すれば重複リスクが大幅に緩和されます。
3. NAT を用いた重複回避策 (VPN Gateway, Firewall, NVA)
3.1 VPN Gateway の NAT 機能
根本的な再設計がすぐにできない場合、Azure VPN Gateway の NAT 機能が有効です。Site-to-Site VPN でオンプレミス側から Azure へ入るパケットを 静的 NAT によって任意のアドレスに変換し、Azure 内部から見てユニークにする手法です。
静的 NAT: 1 対 1 で IP アドレスをマッピングし、双方向の通信を可能にします。
たとえばオンプレ側 10.1.0.0/16 を 100.64.1.0/16 にマップし、Azure からは後者をルーティング先とみなせるようになる。
動的 NAT: 多対 1 の変換であり、セッションを起点とするステートフル NAT。正確なアドレスの 1 対 1 対応が不要な用途には有用だが、双方向通信を必要とするワークロードでは扱いが複雑。
VPN Gateway による NAT は、特に複数拠点が同じ IP を使っているような厳しい重複にも対処可能ですが、あくまで IPsec を介したトンネルという経路を使うため、ExpressRoute の帯域保証や低レイテンシが得にくいデメリットも無視できません。
一部ケースでは、ExpressRoute 上で IPsec トンネルを張るという高度な方法が紹介されています。これによりインターネットを経由せずに IPsec を通すため、帯域的に有利となりつつ NAT による重複解決が可能です。オンプレ側は Azure の VPN Gateway のプライベート IP を宛先とし、トンネル確立後に NAT でアドレス変換をする構成です。
ただしこの構成はドキュメントが限定的でサポート条件が複雑なため、十分な検証が不可欠です。
3.2 Azure Firewall / サードパーティ NVA での NAT
NAT を機能面で拡張したい場合、Azure Firewall やサードパーティ製 NVA（Cisco, Palo Alto, Fortinet など）を仮想アプライアンスとしてデプロイし、そこをトラフィックの中継点にする方法があります。
Azure Firewall: PaaS としてスケーラブルな統合ファイアウォール機能を提供し、アウトバウンド SNAT、インバウンド DNAT、そして 2025 年現在一部プレビュー段階のプライベート間 DNAT などを包含します。重複サブネット間の相互通信を二重 NAT で中継し、Azure 内外の重複を最小化できる可能性があります。
NVA: サードパーティ製のファイアウォールや UTM, ADC などを高可用性構成で Azure に配置し、ユーザー定義ルート(UDR)で強制的にすべてのオンプレ-クラウド通信を NVA 経由にするといった設計も可能です。
柔軟なルール管理や企業標準のセキュリティスタックと整合させやすい一方、VM ベースゆえに可用性設計（Active-Active、Scale Set など）やパフォーマンスチューニングが煩雑になります。
ExpressRoute でダイレクトに繋いだとしても、クラウド側で一度ファイアウォール / NVA を経由させてトランスレーションすれば、オンプレ IP とクラウド IP が重複する問題を回避可能です。
ただしルーティングは意図的に「すべてのパケットを Firewall/NVA へ送る (UDR や BGP 連携を使う)」よう設計する必要があります。
これを確立しないと、重複プレフィクスのまま直接 VNet リソースへ行こうとして通信不能になります。
4. Azure NAT Gateway の立ち位置
4.1 アウトバウンド専用の SNAT サービス
Azure NAT Gateway は、VNet 内のリソースがインターネットへ出る際の送信元アドレスを NAT Gateway 所有のパブリック IP に変換するサービスです。SNAT ポートプールの枯渇を防ぎ、かつ送信元を統一することで固定 IP が得られるという利点があります。
しかし、ExpressRoute でオンプレミスと直結するプライベート接続においては、NAT Gateway は機能しません。 NAT Gateway はそもそも アウトバウンド (外向き) のみ をターゲットにしたデザインだからです。オンプレ環境へのルートがプライベートで張られている場合、NAT Gateway を介した重複解消は不可能です。
4.2 インターネット経路への切り替えという妥協策
もし「オンプレ-クラウド連携をインターネット経由に変更してもよい」という方針なら、NAT Gateway で出て行くトラフィックを一意のパブリック IP に統一し、オンプレミス側でそのグローバル IP だけ受け入れるよう FW 設定を変えれば、アドレス重複の問題は発生しません。
しかし ExpressRoute で期待している低遅延・高帯域・安全性は享受できず、通信路の設計意図が台無しになるリスクがあります。よほどの小規模・一時的用途でない限り、あまり現実的ではないでしょう。
5. Private Link を応用した限定的接続
5.1 NAT/Proxy 方式による部分的統合
Azure Private Link は、サービス提供側（Azure PaaS や IaaS リソース）とクライアント側を直接ピアリングするのではなく、マイクロソフトのバックボーン上の NAT/Proxy を経由させる仕組みです。
重複サブネットであろうとも、Private Endpoint と Private Link Service 間で暗黙のアドレス変換が行われるため、個別サービスへのアクセスだけを許す形で衝突を回避できます。
たとえばアプリケーションサーバーや DB を Azure に置き、オンプレからそこに対して Private Link 経由でアクセスする場合、両者が同じ 10.0.0.0/16 を使っていてもエンドポイント/32 により衝突を回避できます。ただし、ネットワーク全体の透過的な疎通はできず、「特定サービスだけ接続できればよい」という要件に限定される点が留意事項です。
5.2 大規模マルチテナントの定番解
複数子会社・事業部・パートナーが各自のプライベート空間を持っているケースでは、Private Link が理想的にはたらくことがあります。
SaaS プロバイダーが Azure 上にサービスを置き、各顧客はプライベートエンドポイントだけ作成すれば済むので、背後の CIDR が競合していようが関係ありません。
大企業の内部サービスを擬似 SaaS 化する手法として Private Link を活用することも可能ですが、管理対象の Private Endpoint が非常に多くなる場合、DNS やセキュリティルールの設計が複雑化します。
6. ルーティング設計と制御手法
6.1 重複サブネットを広告しない/受け取らない
ExpressRoute や VPN で BGP 広告する際、重複するサブネットは意図的に非広告化（または相手からの受信を拒否）することで衝突を避ける方法があります。
問題は「その重複プレフィクスを実際にどう通信するのか」という点ですが、たとえば一部だけ NAT でマップしたり Private Link でプロキシを張ったりすることで、全体の重複ルーティングは切り捨て、限定的なパスだけ通すという設計ができます。
また、AS-PATH プリペンドやコミュニティを用いて、重複経路の優先度を意図的に下げるのも手法の一つです。
6.2 ブラックホールルート
Azure の User Defined Route (UDR) では、Next hop を “None” に設定してパケットをドロップする ブラックホールルートを定義できます。
重複サブネットあて通信が発生すると、意図的に廃棄しループを防ぐわけです。ただし、通信が必要なリソースに対しても一律に廃棄されると困るため、多くの場合は「メイン経路で重複を使わず、NAT/FW 経由でマッピングされた経路だけを許可」といった併用が必要です。
6.3 Route Server, BGP ポリシーでの高度制御
大規模ネットワークでは Azure Route Server を介して、サードパーティ NVA と Azure VNet 間の BGP ピアリングを柔軟に制御するシナリオも検討されます。
たとえば重複したサブネットは特定コミュニティをつけて Route Server に広告し、そこから先は Firewall / NVA だけが再配布を行うといった分業が可能です。
ただし Route Server は細かなフィルタリングや再書き換えを直接サポートしない面があり、NVA 側のポリシーが複雑化する傾向にあります。運用面を鑑みると、全体設計を統合的に考えねばなりません。
7. 運用観点とロングターム戦略
7.1 暫定対策としての NAT, 永続解決としての再設計
最適解は言うまでもなく、全社的なアドレス更改で重複を根絶することです。
しかし、巨大組織や短期間での統合要件がある場合、全面的リナンバリングは非現実的な場合も多々あります。
そうした場面で NAT や Private Link は “応急策” として効果を発揮する一方、ネットワークが複雑化し、運用保守にコストがかかるデメリットがあります。
最終的には、中長期的に段階的な IP 改訂や新セグメントへの業務移行を進めるロードマップを描きつつ、それまでを NAT・特定プロキシで凌ぐという構図が多いでしょう。
7.2 監視とトラブルシュートの高度化
複数の NAT やルーティングポリシーが入り混じると、トラブルシュートは著しく難度を増します。
通信経路を可視化し、どの経路がいつ NAT 化され、どのルータ/ファイアウォールを経由しているかを常に把握できる仕組みを構築することが不可欠です。
Azure Monitor や Network Watcher、オンプレ側の NetFlow / IPFIX、NVA のログなど、多岐にわたる観測点を体系的にまとめる必要があります。
また BGP テーブルの検証、Azure Firewall のログ、Private Endpoint 接続の DNS 解決など確認ポイントは膨大です。事前にテストプランを定義し、どのようなパスが想定外に閉塞・ループするのかテストシナリオを包括的に策定する運用リーダーシップも求められます。
7.3 IPv6 マイグレーションと拡張
IPv6 を併用する将来構想が現実味を帯びてきた今こそ、重大システムにおける実験的導入を始める好機とも言えます。
大規模企業ほど IPv4 重複の罠に絡み取られがちですが、IPv6 の広大なアドレス空間を活かせば、オンプレと Azure のバッティングを根本的に消せる可能性があります。
今後数年にわたる段階的デュアルスタック化を経て、クラウド側は IPv6 メイン、オンプレも新セグメントは IPv6 優先、という環境が定着すれば、重複問題は「レガシー IPv4 域のみ」の局所的課題へと縮小していくはずです。
結論
オンプレミスと Azure を ExpressRoute 接続する際の IP アドレス重複問題は、ハイブリッドネットワークを設計・運用する上級エンジニアにとって極めて根深いテーマです。
根源的には RFC1918 空間の再編が理想解であり、Azure の Landing Zone 設計で初期から衝突を排除する方針を打ち出すのが最善策といえます。
しかし多くの大企業・グローバル拠点では既に膨大なレガシー空間があり、即時の大規模再編は困難です。そのため各種 NAT（VPN Gateway NAT、Azure Firewall DNAT、NVA）、Private Link、特別なルートフィルタリング等を駆使して回避する “小手先” の対策が必要となります。
これらの対処法を的確に組み合わせれば、当面は衝突を最小限に抑えた稼働を継続可能です。しかしネットワーク構成は複雑化し、現場のトラブルシュート負荷も増します。
結局、長期視点では CIDR 設計を刷新し、重複をそもそも生まない体制を作る、または IPv6 へのシフト で根本対処する以外に運用負荷を根底から軽減する術はないという点は明白です。
クラウド移行計画の初期段階でこの問題を正面から捉え、エグゼクティブレベルの合意のもと全社的 IP アドレス再編ロードマップを策定することが、将来にわたるネットワーク運用の安定とコスト効率につながります。
参照リンク・参考資料
ExpressRoute & VPN を併用した NVA/NAT 構成
VPN Gateway NAT 機能ガイドライン (Microsoft Docs)
Azure Landing Zone - ネットワーク設計 (Cloud Adoption Framework)
Azure Firewall の DNAT/SNAT (Private 間プレビュー含む)
Azure Private Link - Overlapping IP 対策
Virtual Network Peering の重複 CIDR 不可要件
UDR (User Defined Routes) とブラックホールの使い方
上記ドキュメント類に示される Microsoft の公式ガイドラインや、ベンダー製ファイアウォールの BGP / NAT 機能リファレンスは、オンプレミスと Azure を融合するうえでの IP 設計・運用に強い影響を与えます。
日々アップデートされるため、常に最新情報を参照しながら自社のネットワークアーキテクチャを最適化してください。
最終的には、設計段階から IP 重複の可能性を払拭し、NAT やルートフィルタを“最小限の補助”として使うことが、エンタープライズ規模での負荷軽減と可用性確保の要諦と言えます。