オンプレのサーバー群をAzureに移行するとき、まずSite-to-Site VPNで接続してみるケースは多いと思います。ただ、いざ本番環境の移行を進めると「インターネット経由の遅延が読めない」「帯域が不安定で基幹業務に影響が出る」「社内コンプライアンス上、インターネット経由の接続が認められない」という壁にぶつかります。
これを解決するのがAzure ExpressRouteです。通信キャリアやネットワーク事業者の閉域網を経由し、オンプレミスとAzureをインターネットを経由せずに直結できます。
この記事では、ExpressRouteの仕組みからVPN接続との違い・ピアリング設定・料金体系・冗長構成まで、オンプレのWAN設計経験者にもわかりやすく解説します。
なぜExpressRouteなのか？VPN接続との根本的な違い
オンプレ経験者にとって身近な例で言うと、Azure ExpressRouteは「専用線」や「閉域VPN（IP-VPN）」に相当します。インターネットVPN（IPsec）と専用線の違いはWANの世界では当たり前の概念ですが、Azureでも同じ選択肢が用意されているのがExpressRouteです。
| 接続方式 | 経路 | 帯域の安定性 | セキュリティ | コスト |
|---|---|---|---|---|
| Site-to-Site VPN | インターネット | 不安定（ベストエフォート） | 暗号化あり（IPsec） | 低い |
| Azure ExpressRoute | 閉域網（プロバイダー提供） | 保証帯域・安定 | 物理回線分離 | 高い（帯域依存） |
VPNはインターネットを使うため帯域が保証されず、ピーク時に遅延が増加しやすい。ExpressRouteは物理的に分離された専用回路を通るため、帯域・遅延ともに安定します。
もう一点、オンプレ経験者に補足しておきたいのが「物理的な分離」の意味です。VPNはあくまでインターネット上の暗号化トンネルであり、通信経路自体は他のインターネットトラフィックと共有されます。ExpressRouteはプロバイダーの閉域網を通るため、経路レベルで他のトラフィックと分離されており、企業の情報セキュリティポリシーや金融・医療系の規制要件をクリアしやすいのが実際の現場での強みです。
ExpressRouteの基本構成を理解する
1. 接続プロバイダーの選択
ExpressRouteの接続には、Microsoftが認定した接続プロバイダー（ExpressRoute Partner）を経由する必要があります。国内では以下のようなプロバイダーが対応しています（2026年1月時点）。
・KDDI: 企業向けWANとの統合接続
・NTTコミュニケーションズ: 閉域網OCNからの接続
・IIJ: IIJ GIO コネクトサービス
・Equinix: 東京・大阪のデータセンターを拠点とした接続
・AT TOKYO: データセンターコロケーション+ExpressRoute
プロバイダーごとに帯域メニューや料金が異なります。自社データセンターとプロバイダーの接続拠点（POP）の距離や、既存のWAN契約との統合可否も選定基準に加えましょう。
2. ExpressRoute回路（Circuit）の概念
Azure側の設定単位はExpressRoute回路（Circuit）です。1つの回路は「接続プロバイダー + ピアリングの場所 + 帯域幅」の組み合わせで定義されます。1つの回路に対して最大10個のVNetを接続できます（同一リージョン内の場合）。
3. ピアリングの種類
ExpressRoute回路には2種類のピアリングが存在します。
・Azure Private Peering: Azure Virtual Network（VNet）内のリソース（VM・ストレージ等）にプライベートIPアドレスで接続する。最もよく使われるピアリング種別
・Microsoft Peering: Azure PaaSのパブリックエンドポイント（Blob Storage・SQL Database等）やMicrosoft 365に、閉域網経由で接続する
オンプレのサーバーからAzure VMやVNet内リソースに接続したい場合はPrivate Peering、Office 365のExchangeやSharePointへの接続を閉域化したい場合はMicrosoft Peeringを選びます。多くの企業環境ではPrivate Peeringがメインになります。
4. ExpressRoute Virtual Network Gatewayとの接続
VNetとExpressRoute回路を繋ぐためにはExpressRoute Virtual Network Gatewayが必要です。VPN Gatewayとは別製品です（GatewaySubnetを共有してVPN GatewayとExpressRoute Gatewayを共存させることは可能です）。
GatewayのSKUはErGw1AZ / ErGw2AZ / ErGw3AZ（いずれも可用性ゾーン対応）があり、SKUによって最大スループットと接続できる回路数の上限が異なります。本番環境では可用性ゾーン対応SKU（末尾がAZ）を選ぶのが無難です。
基本的な設定手順（Azure CLIとAzure Portal）
ExpressRouteの設定は大きく4ステップです。プロバイダーとの調整工数が最も時間を要するため、本番接続は数週間～数か月の準備期間を見込んでおきましょう。
1. ExpressRoute回路の作成
Azure PortalまたはAzure CLIで回路を作成します。この時点では設定上の「枠」だけ作る状態で、プロバイダーとの物理接続はまだ確立されていません。
# Azure CLIでExpressRoute回路を作成する例（Azure CLI使用） az network express-route create \ --resource-group rg-network-prod \ --name er-circuit-tokyo01 \ --location japaneast \ --provider "NTT Communications - Flexible InterConnect" \ --peering-location "Tokyo" \ --bandwidth 200 \ --sku-tier Standard \ --sku-family MeteredData # 作成後にService Keyを確認する（プロバイダーへの提供に使用） az network express-route show \ --resource-group rg-network-prod \ --name er-circuit-tokyo01 \ --query serviceKey -o tsv
2. 接続プロバイダーへの設定依頼
回路作成後に発行されるService Keyをプロバイダーに提供し、プロバイダー側の回線設定を依頼します。この工程はプロバイダーとの調整が必要で、通常2週間～6週間かかります。
プロバイダー側の設定が完了すると、回路のProvisioningStateが`NotProvisioned`から`Provisioned`に変わります。PortalまたはCLIで定期的に確認しましょう。
3. ExpressRoute Virtual Network Gatewayの作成
接続先VNetにGatewayサブネット（/27以上のCIDR）を作成し、ExpressRoute Virtual Network Gatewayをデプロイします。デプロイには15分～45分程度かかります。
# Gateway Subnetの作成（Azure CLI使用） az network vnet subnet create \ --resource-group rg-network-prod \ --vnet-name vnet-prod-eastjapan \ --name GatewaySubnet \ --address-prefix 10.0.255.0/27 # パブリックIPの作成（可用性ゾーン対応・Standard SKU必須） az network public-ip create \ --resource-group rg-network-prod \ --name pip-er-gateway \ --sku Standard \ --zone 1 2 3 # ExpressRoute Gateway作成（15～45分程度） az network vnet-gateway create \ --resource-group rg-network-prod \ --name er-gateway-prod \ --vnet vnet-prod-eastjapan \ --public-ip-addresses pip-er-gateway \ --gateway-type ExpressRoute \ --sku ErGw1AZ \ --location japaneast
4. 回路とVNetの接続（Connection）
最後に、ExpressRoute回路とVNet Gatewayを「接続リソース（Connection）」で繋ぎます。
# ExpressRoute回路のリソースIDを取得（Azure CLI使用） CIRCUIT_ID=$(az network express-route show \ --resource-group rg-network-prod \ --name er-circuit-tokyo01 \ --query id -o tsv) # 接続リソースの作成 az network vpn-connection create \ --resource-group rg-network-prod \ --name er-connection-prod-vnet \ --vnet-gateway1 er-gateway-prod \ --express-route-circuit2 $CIRCUIT_ID \ --routing-weight 0
接続が確立したら、オンプレのルーターからAzure VM（プライベートIP）へのpingやSSH接続で疎通を確認します。
料金の仕組み（2026年3月時点）
ExpressRouteの料金は大きく「回路料金」と「データ転送料金」の2軸で構成されます。
| 料金コンポーネント | 内容 | 料金目安 |
|---|---|---|
| 回路料金（ポート料金） | 帯域幅・SKU（Standard / Premium）に応じた月額固定 | 50Mbps 約$55/月 ～ 10Gbps 約$5,000/月（Standard・Metered） |
| Metered（従量）データ転送 | アウトバウンド転送量に応じた従量課金 | ゾーン1（日本）: $0.025/GB（2026年3月時点） |
| Unlimited（定額）データ転送 | アウトバウンド転送量を月額固定で無制限に | 50Mbps 約$290/月（Standard・Unlimited） |
| VNet Gateway料金 | ExpressRoute Gateway SKUに応じた月額固定 | ErGw1AZ: 約$174/月（japaneast） |
MeteredとUnlimitedの選び方は月間アウトバウンドデータ量が判断基準です。バックアップや大量ログの転送が多い環境では、早い段階でUnlimitedプランの方がコスト効率が良くなります。目安として、Metered料金のブレークイーブン点は帯域によって異なりますが、200Mbpsの場合は月間数十TBを超えてくるとUnlimitedが有利になります。
注意点として、Azure側の料金に加えてプロバイダー側の回線料金（月額固定）も別途かかります。総コストの試算にはプロバイダー見積もりも含めて計算しましょう。
冗長構成と応用Tips
2回路冗長構成（本番環境では必須）
Microsoftは本番環境向けに2つのExpressRoute回路による冗長構成を強く推奨しています。1回路のみだと、プロバイダー側や回線障害時に自動フェイルオーバーができません。
理想的な構成は以下のとおりです。
・回路1: プロバイダーA経由 / ピアリングの場所: 東京
・回路2: プロバイダーB経由、または同一プロバイダーの別拠点 / ピアリングの場所: 大阪
2回路の優先度制御はBGP属性（AS Path、Local Preference、Weight）で設定します。オンプレルーターでの設定が必要なため、ネットワーク担当者との連携が不可欠です。
ExpressRoute Global Reach
複数のオンプレ拠点（例: 東京本社と大阪データセンター）がそれぞれAzureとExpressRoute接続している場合、Global Reachを使えばAzureバックボーンを経由して拠点間を閉域接続できます。既存の拠点間WAN回線を廃止してコスト削減できる可能性があります。対応しているピアリングの場所であることが条件です。
FastPath
通常のExpressRoute接続はVNet Gatewayを経由してデータが流れますが、FastPathを有効にするとゲートウェイをバイパスしてオンプレ↔Azure VM間の帯域・レイテンシを改善できます。ErGw3AZまたはUltraPerformance SKU以上が必要です。大量データを扱うミッションクリティカルな環境では検討の価値があります。
よくあるトラブルと対処法
ProvisioningStateがNotProvisionedのまま変わらない
回路作成後にプロバイダーへ設定依頼を出してもProvisioningStateが変わらない場合、まずService Keyをプロバイダーに正しく伝えられているか確認します。プロバイダー担当者への依頼漏れや、依頼受付後の工事完了待ちであることが大半です。Azure Portal上では問題なく見えても、物理回線の開通はプロバイダー作業が完了するまで進みません。
VNet内リソースへの疎通ができない
接続リソースのステータスは「接続済み」になっているのに、オンプレからAzure VMに到達できない場合は以下を順番に確認します。
・オンプレルーターとAzureのBGPセッションが確立しているか（`show bgp summary`等で確認）
・VNetのアドレス空間がBGPでオンプレルーターに広報されているか
・NSG（ネットワークセキュリティグループ）でオンプレ側のIPからのインバウンドが許可されているか
・GatewaySubnetにカスタムのUDR（ユーザー定義ルート）が設定されていないか（GatewaySubnetへのUDR設定は原則禁止）
帯域が想定より出ない
ExpressRoute回路の帯域は保証されていますが、以下の要素がボトルネックになることがあります。
・VNet GatewayのSKUが帯域上限に達している（ErGw1AZの場合、最大スループットは約1Gbps）
・オンプレルーター・スイッチのポート速度が回線帯域に追いついていない
・FastPathが無効になっており、Gateway経由で帯域が制限されている
まとめ
Azure ExpressRouteは、オンプレ経験者にとって馴染みのある「閉域専用線」の概念をクラウドで実現するサービスです。
| 項目 | 内容 |
|---|---|
| 接続方式 | 認定プロバイダーの閉域網経由でAzureバックボーンへ直結 |
| ピアリング種別 | Private Peering（VNet）・Microsoft Peering（PaaS/Microsoft 365） |
| 設定の主な流れ | 回路作成 → プロバイダーへService Key提供 → Gateway作成 → 接続リソース作成 |
| 料金体系 | 回路料金（固定）+ データ転送料金（MeteredまたはUnlimited）+ Gateway料金 |
| 冗長構成 | 本番環境では2回路冗長を必須とする |
コストが高いため、すべての環境をExpressRouteにする必要はありません。基幹業務のデータベース接続や機密情報を扱うシステムに限定し、開発環境はSite-to-Site VPNで済ませるという使い分けが現場ではよく見られます。
ExpressRouteの接続先となるVNetの基礎設計については、Azure Virtual Network（VNet）入門｜サブネット設計からNSG・ピアリングまでで詳しく解説しています。ExpressRoute設定の前提としてVNet設計を固めておくことをお勧めします。
また、AWSのオンプレ接続方式との比較はAWS Direct Connect vs Site-to-Site VPNの記事もあわせて参照ください。
PR
クラウドFinOps 第2版（J.R. Storment／Mike Fuller／オライリー・ジャパン）
ExpressRouteは月額コストが大きく、帯域選択やMetered/Unlimitedプラン選定がコストに直結します。クラウド支出の最適化手法を体系的に学べる一冊で、回線コストの整理にも役立ちます。
