2026年4月30日のMicrosoftDocs系のAzure公式ドキュメント更新「Update migration notes for IP retention and downtime」は、Azure Application Gateway V1からV2へ移行するチームにとって見逃せない更新です。結論から言うと、Public IPを保持して移行する場合は、V1とV2が同一サブスクリプションであること、IP切り替え時に約1〜5分のダウンタイムが発生すること、そして切り替え操作は慎重に計画すべきことが重要な確認ポイントです。
特に、既存のApplication Gateway V1をまだ利用している環境では、「いま動いているから問題ない」と判断するのは危険です。Microsoftの公式ドキュメントでは、Application Gateway V1は2026年4月28日に廃止され、以後はサポートやSLAの対象外になると説明されています。移行対象の棚卸し、Public IP保持の可否、メンテナンス時間、Dedicated Backend Connectionの影響を早めに確認しましょう。(Microsoft Learn)
今回の公式ドキュメント更新で何が変わったか
今回の更新は、GitHub上のMicrosoftDocs/azure-docsリポジトリにおけるコミット「Update migration notes for IP retention and downtime (#315056)」として確認できます。コミット日は2026年4月30日で、Application Gateway関連の3ファイルが更新されています。(GitHub)
更新対象は、主に次の3領域です。
| 更新対象 | 主な変更内容 | 実務で見るべきポイント |
|---|---|---|
migrate-v1-v2.md | Public IP retention scriptに関する移行条件を追記 | V1とV2が同一サブスクリプションであるか、1〜5分の停止を許容できるか |
application-gateway-faq.yml | Application Gateway V1がサポート外である旨に更新 | V1利用環境を「移行待ち」ではなく「対応必須」として扱う |
configuration-http-settings.md | Dedicated Backend Connectionの注意点を整理 | NTLM/Kerberos、レガシークライアント、SNAT、HTTP/2非対応を確認する |
表題は「IP retention and downtime」ですが、差分全体を見ると、単なる説明文の修正ではありません。Application Gateway V1廃止後の移行判断、Public IP保持、バックエンド接続方式、運用リスクをまとめて再確認するための更新と捉えるべきです。
Public IP retentionで必ず確認すべき点
Application Gateway V1からV2へ移行する際、既存のPublic IPを維持できれば、DNS変更や外部接続元の許可リスト更新を最小化できます。しかし、今回の更新では、その前提条件と停止時間を明確に確認する必要があります。
Microsoft Learnの移行ドキュメントでは、Public IP retention scriptについて、V1のBasic Public IPを予約し、Standardへ変換してV2 Gatewayにアタッチすることで、受信トラフィックをV2へ向けると説明しています。このIPスワップ操作では、通常約1〜5分の短いダウンタイムが発生するとされています。(Microsoft Learn)
さらに重要なのが、IP retentionを成立させるには、V1 GatewayとV2 Gatewayが同じサブスクリプションに存在している必要があるという点です。今回の更新で、この条件が移行ノートに明記されました。(Microsoft Learn)
確認すべき条件
| 確認項目 | 判断基準 | 対応 |
|---|---|---|
| V1とV2のサブスクリプション | 同一サブスクリプションであること | 異なる場合はIP保持前提の移行計画を見直す |
| メンテナンス時間 | 約1〜5分の停止を業務上許容できること | 利用者通知、監視抑止、作業時間帯を決める |
| Public IP名・DNS名 | 数字で始まる名前に制限がないか | 該当する場合は事前にDNSラベルなどを調整する |
| 並行作業 | IP移行中に関連リソースを操作しないこと | Change Freezeを設定し、作業者を限定する |
| ロールバック | スクリプトで元に戻せないことを理解する | DNS切替や別経路での復旧案を用意する |
Public IPを保持する移行は便利ですが、「IPが変わらないから無停止」とは考えないでください。公式ドキュメント上でも、IPスワップに約1〜5分のダウンタイムが発生する前提で計画するよう示されています。(Microsoft Learn)
Application Gateway V1は「サポート外」として扱う
今回の更新では、Application Gateway FAQでもV1 SKUの扱いが更新されています。公式FAQでは、Application Gateway V1 SKUは2026年4月28日に廃止され、現在はサポートされていないと説明されています。残存するV1 Gatewayについては、V2への移行が強く推奨されています。(Microsoft Learn)
日本語版の公式ページでも、Application Gateway V1は2026年4月28日に廃止され、以後はサポート対象外、SLAなし、V1を支えるハードウェアの使用停止に伴ってトラフィックへ影響が出る可能性があると説明されています。(Microsoft Learn)
つまり、運用判断としては次のように切り替えるべきです。
| 以前の見方 | 今後の見方 |
|---|---|
| V1は古いがまだ使える | V1はサポート外であり、早急に移行対象 |
| 障害が起きたらサポートへ相談する | サポートやSLAを前提にできない |
| 移行は余裕がある時に進める | 残存リソースの棚卸しと移行計画を優先する |
| Public IP保持なら影響は小さい | 1〜5分の停止と不可逆操作を前提にする |
特に、経営層やサービスオーナーに説明する場合は、「機能改善のための移行」ではなく、サポート外リスクを解消するための移行として説明したほうが合意を取りやすくなります。
Dedicated Backend Connectionの影響も確認する
今回の更新では、Application GatewayのHTTP設定にあるDedicated Backend Connectionの注意点も整理されています。これは、NTLMやKerberosのようにフロントエンド接続とバックエンド接続の1対1対応が重要な認証方式を扱う場合に関係します。
公式ドキュメントでは、Dedicated Backend Connectionは、クライアントごとにフロントエンド接続とバックエンド接続を1対1でマッピングし、個別の永続的な接続を確保する機能として説明されています。NTLM/Kerberosのパススルー認証を使う場合、この1対1対応がセッション整合性の維持に必要です。(Microsoft Learn)
ただし、有効化すればよいだけではありません。次の点を必ず確認してください。
| 確認項目 | 影響 | 対応策 |
|---|---|---|
| NTLM/Kerberos利用 | Dedicated Backend Connectionが必要になる場合がある | 認証方式とSPN設定を事前確認する |
| レガシークライアント | 古いUser-AgentやMSIE6相当の挙動で接続が不安定になる可能性 | 対象クライアントを洗い出し、段階的に検証する |
| バックエンド接続数 | 接続数が増え、Application Gatewayとバックエンドの負荷が増える | インスタンス数、自動スケール、バックエンド容量を確認する |
| SNATポート | リモートバックエンド利用時にSNATポート枯渇リスクが増える | 接続数、ピーク時間帯、NAT設計を見直す |
| HTTP/2 | Dedicated Backend ConnectionはHTTP/2非対応 | HTTP/2前提の設計がないか確認する |
とくに見落としやすいのは、容量計画です。Dedicated Backend Connectionを有効にすると、バックエンド接続数が増えるため、Application Gateway側のインスタンス数や自動スケールだけでなく、バックエンドサーバー側の同時接続数、CPU、メモリ、コネクションプールも確認が必要です。公式ドキュメントでも、接続増加に応じてインスタンス数増加または自動スケールを検討するよう説明されています。(Microsoft Learn)
移行準備で最初にやるべき棚卸し
Application Gateway V1からV2への移行では、まず対象リソースの棚卸しが必要です。大規模環境では、Azure Portalを目視で確認するだけでは漏れが出やすいため、Azure Resource GraphやAzure CLIで候補を抽出するのが現実的です。
以下は、Application GatewayのうちV2 SKUではないリソースを抽出する例です。環境によってSKU名や運用ルールが異なるため、抽出結果は必ずAzure Portalまたはリソース定義で再確認してください。
az graph query -q "
Resources
| where type =~ 'microsoft.network/applicationgateways'
| extend skuName = tostring(sku.name), skuTier = tostring(sku.tier)
| where skuTier !in ('Standard_v2', 'WAF_v2')
| project subscriptionId, resourceGroup, name, location, skuName, skuTier
"棚卸し後は、単に「V1が何台あるか」を数えるのではなく、次の観点で優先度を付けます。
| 優先度 | 条件 | 理由 |
|---|---|---|
| 最優先 | インターネット公開、本番、WAF利用、重要業務 | 停止時の事業影響が大きい |
| 高 | Public IP保持が必要、外部許可リストが多い | 移行調整に時間がかかる |
| 中 | 社内向け、DNS変更で対応可能 | 計画移行しやすい |
| 低 | 検証環境、未使用の可能性あり | 削除または統合を検討できる |
棚卸しの段階で、サブスクリプション、リソースグループ、VNet、サブネット、Public IP、WAFポリシー、証明書、バックエンドプール、ヘルスプローブ、診断ログの出力先まで一覧化しておくと、移行直前の手戻りを減らせます。
V1からV2への移行で見落としやすい設計差分
Application Gateway V1からV2への移行は、単にSKUを変更する作業ではありません。構成移行、トラフィック移行、検証、監視の再設定を分けて考える必要があります。
MicrosoftのFAQでは、Azure PowerShellスクリプトは構成を移行するものであり、V1 Gatewayから新しいV2 Gatewayへの実際のトラフィック移行は利用者が責任を持って制御すると説明されています。Public IP retention scriptを使えばV1からV2へPublic IPを保持できますが、その操作には1〜5分のダウンタイムがあります。(Microsoft Learn)
また、V1 GatewayとV2 Gatewayを同じサブネットに共存させることはできません。V2 Gateway用に専用サブネットを作成し、十分なIPアドレス空間を確保する必要があります。(Microsoft Learn)
実務で確認する項目
| 項目 | 確認内容 |
|---|---|
| サブネット | V2専用サブネットを用意しているか |
| Public IP | 同一サブスクリプションでIP保持できるか |
| DNS | IP保持しない場合、TTLを短くできるか |
| 証明書 | Key Vault参照、証明書チェーン、SNI設定を確認したか |
| WAF | WAFポリシー、除外ルール、検知・防御モードを確認したか |
| バックエンドTLS | V2で証明書検証の挙動差分が問題にならないか |
| ログ | 診断ログ、Azure Monitor、Storage出力先を再設定したか |
| 監視 | ヘルスプローブ、メトリック、アラートをV2向けに更新したか |
特にバックエンド証明書の検証は注意が必要です。公式FAQでは、V1は認証証明書を使い、V2は既定で証明書チェーンとバックエンドサーバー証明書のサブジェクト名をより包括的に検証すると説明されています。移行時に検証を一時的に無効化できる場合もありますが、本番環境では完全な検証を再度有効化することが推奨されています。(Microsoft Learn)
失敗しやすいポイントと対策
Application Gateway V1からV2への移行で失敗しやすいのは、技術的な作業そのものよりも、前提条件の確認漏れです。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 同一サブスクリプション条件を見落とす | Public IP保持ができない | 早い段階でV1/V2のサブスクリプションを確認する |
| 1〜5分の停止を軽視する | 利用者から障害扱いされる | メンテナンス通知、監視抑止、関係者連絡を準備する |
| IPスワップをロールバック可能と誤解する | 切り戻し手順が破綻する | スクリプトで戻せない前提で復旧案を設計する |
| 移行中に別作業を行う | 予期しない構成不整合が起きる | 作業時間中は関連リソースの変更を禁止する |
| Dedicated Backend Connectionの容量影響を見ない | 接続数増加やSNAT枯渇が起きる | 負荷試験、インスタンス数、自動スケールを確認する |
| ログ設定の再確認を忘れる | 移行後に障害解析できない | V2側の診断設定を移行後すぐ確認する |
日本語版FAQでは、Azure Storageにログを送信するように構成したV1 Gatewayについて、スクリプトではV2用にその構成はレプリケートされず、移行後のV2 Gatewayにログ構成を個別に追加する必要があると説明されています。監視や監査要件がある環境では、移行チェックリストに必ず入れてください。(Microsoft Learn)
推奨する移行の進め方
移行は、構成作成と切り替え作業を一度に行うのではなく、段階を分けて進めるのが安全です。
| フェーズ | 作業内容 | 完了条件 |
|---|---|---|
| 棚卸し | V1 Gateway、Public IP、WAF、証明書、バックエンドを一覧化 | 移行対象と優先度が確定している |
| 設計 | V2用サブネット、容量、Public IP保持方針、停止時間を決める | 変更計画と関係者合意がある |
| 構築 | V2 Gatewayを作成し、構成を移行する | バックエンドヘルスが正常である |
| 検証 | ルーティング、TLS、WAF、認証、ログ、アラートを確認 | 本番相当のテストが完了している |
| 切り替え | Public IP retentionまたはDNS切替でトラフィックを移行 | 監視上の異常がなく、利用者影響が許容範囲 |
| 移行後 | V1側の残存、ログ、コスト、アラートを整理 | 不要リソースと古い運用手順が削除されている |
公式FAQでは、移行に必要な時間はデプロイの複雑さによって異なり、最大で2か月かかるよう計画すると説明されています。複数のアプリケーション、複数リージョン、外部許可リスト、WAFチューニングがある環境では、短期間での一括移行を前提にしないほうが安全です。(Microsoft Learn)
技術担当者と意思決定者で確認すべき観点を分ける
今回の更新は、開発者、クラウド管理者、ソリューションアーキテクト、技術意思決定者のそれぞれに影響します。ただし、見るべきポイントは異なります。
| 役割 | 確認すべきこと |
|---|---|
| 開発者 | 認証方式、バックエンドTLS、アプリ側ログ、4xx発生時の切り分け |
| クラウド管理者 | SKU、サブネット、Public IP、診断設定、メンテナンス作業 |
| ソリューションアーキテクト | V2設計、可用性、スケーリング、SNAT、WAF、切り戻し案 |
| 技術意思決定者 | サポート外リスク、停止許容時間、移行予算、事業影響 |
この分担を明確にすると、移行会議が「誰が何を確認するのか分からない」状態になりにくくなります。特にPublic IP retentionは、ネットワーク担当だけでなく、アプリ担当、セキュリティ担当、外部接続先の管理者にも影響する可能性があります。
まず取るべき次の行動
今回の「Update migration notes for IP retention and downtime」で最も重要なのは、Public IP保持の条件とダウンタイムを移行計画に明示することです。Application Gateway V1はすでにサポート外として扱うべき段階にあり、残存環境がある場合は早急にV2移行の実行計画へ落とし込む必要があります。
まずは次の3つから始めてください。
- Azure Resource GraphやAzure CLIでApplication Gateway V1候補を棚卸しする。
- Public IPを保持する必要がある環境について、V1とV2が同一サブスクリプションにあるか確認する。
- IPスワップ時の1〜5分の停止、不可逆操作、Dedicated Backend Connectionの影響を含めた移行チェックリストを作る。
「公式ドキュメントが更新された」だけで終わらせず、自社環境の移行条件に照らして確認することが重要です。とくに本番公開系のApplication Gatewayでは、Public IP保持、WAF、証明書、監視、認証方式のどれか一つでも見落とすと、移行当日の手戻りにつながります。今回の更新をきっかけに、残存するApplication Gateway V1の移行計画を具体化しましょう。
コメント