Azure公式ドキュメント更新で確認すべきApplication Gateway V1廃止とV2移行

Azureの公式ドキュメント更新「Add retirement-faq.md and v1-retirement.md changes from PR 315056」は、単なる文言修正ではありません。結論から言うと、Azure Application Gateway V1はすでに廃止日を迎えており、残っているV1リソースはサポート・SLA・通信継続性の面でリスクが高い状態として扱うべきです。特にdevelopers、cloud admins、solution architects、technical decision makersは、仕様確認より先に「自社環境にV1が残っていないか」「V2移行または削除の責任者が決まっているか」を確認する必要があります。Microsoft Learnでは、2026年4月28日以降はApplication Gateway V1リソースがサポートされず、SLAもなく、V1を通過するトラフィックが影響を受けると明記されています。(Microsoft Learn)

Azureの公式ドキュメント更新「Add retirement-faq.md and v1-retirement.md changes from PR 315056」で何が変わったか

今回の更新は、MicrosoftDocs/azure-docsリポジトリに入ったAzure Application Gateway関連ドキュメントの更新です。対象ファイルは articles/application-gateway/retirement-faq.md と articles/application-gateway/v1-retirement.md の2つで、コミット上は6行追加・28行削除の差分として記録されています。(GitHub)

重要なのは、更新内容が「これから廃止される」という予告表現から、すでに廃止されたサービスとしての運用上の扱いへ寄っている点です。たとえば、V1廃止FAQでは「Application Gateway V1は2026年4月28日に廃止される」という位置づけになり、2026年4月28日以降はサポートもSLAもなく、V1を通過するトラフィックは保証されないと説明されています。(Microsoft Learn)

確認ポイント	更新から読み取れる意味	取るべき対応
V1の廃止状態	「廃止予定」ではなく「廃止済み」として扱う段階	残存V1を即時棚卸しする
サポートとSLA	2026年4月28日以降はサポート・SLA対象外	障害時の業務影響をリスク登録する
通信影響	V1を通過するトラフィックが影響を受ける可能性	DNS、Public IP、バックエンド到達性を確認する
移行責任	Microsoftが利用者環境を代行移行するものではない	自社でV2移行計画を作る
削除リスク	移行されていないV1デプロイは削除対象になり得る	不要リソースは削除、必要リソースはV2へ移行する

対象サービスはAzure Application Gateway V1

この更新で確認すべき対象は、Azure全体ではなくAzure Application Gateway V1です。Application Gatewayは、Webアプリケーションの入口でL7ロードバランシング、SSL/TLS終端、WAFなどを担うことが多いため、残存していると影響範囲が大きくなりやすいサービスです。

特に注意すべき環境は次のようなものです。

以前から運用しているStandard V1またはWAF V1のApplication Gateway
古いWebアプリ、社内ポータル、API基盤の前段に置かれているApplication Gateway
DNSやPublic IPを直接Application Gatewayに向けている環境
WAFポリシー、TLS証明書、Key Vault、NSG、UDRなどを組み合わせている環境
担当者交代により、Application GatewayのSKUや移行状況が把握されていない環境

今回のドキュメント更新は、技術仕様の新機能発表というより、廃止後フェーズに入ったことを運用部門へ再通知するシグナルとして読むべきです。

2026年4月28日以降に残ったV1で起き得る影響

Microsoft LearnのFAQでは、2026年4月28日以降、Application Gateway V1リソースに対するパッチ、サポート、SLAカバレッジは提供されず、Microsoftがデータパスをブロックしてリソースを削除するとサービス中断に直面すると説明されています。(Microsoft Learn)

ここで重要なのは、「サポート対象外になるだけなら、しばらく動くかもしれない」と楽観視しないことです。Application Gatewayはアプリケーション入口に置かれるため、影響は単一サーバーの停止ではなく、利用者から見たサービス全体の停止として現れる可能性があります。

運用影響を判断する基準

観点	低リスクに見えるが確認が必要な例	高リスクな例
トラフィック	検証環境のみで利用	本番WebサイトやAPIの入口
DNS	一時的な検証用FQDN	主要ドメインのAレコードやCNAMEが向いている
WAF	WAF未使用	WAF V1で攻撃対策ルールを運用している
証明書	HTTPのみ	HTTPSリスナー、Key Vault、複数証明書を使用
変更体制	担当者と手順が明確	ベンダー、アプリ担当、ネットワーク担当が分断されている
復旧手段	V2移行済みで切り戻し設計あり	V1依存のまま代替経路がない

特に本番環境では、まず「通信しているか」ではなく、そのApplication Gatewayが止まった場合に誰が何分で判断できるかを確認してください。廃止後の残存リソースは、通常の運用障害よりも復旧の選択肢が少なくなります。

まずV1リソースを棚卸しする

最初の実務アクションは、全サブスクリプションを対象にApplication GatewayのSKUを確認することです。Azure Portalで個別に見るだけでは見落としやすいため、Azure Resource GraphやPowerShellで一覧化するのが現実的です。

Azure Resource Graphで確認する例

Resources
| where type =~ 'microsoft.network/applicationgateways'
| extend skuName = tostring(sku.name), skuTier = tostring(sku.tier)
| where skuTier in ('Standard', 'WAF')
   or skuName in ('Standard_Small', 'Standard_Medium', 'Standard_Large', 'WAF_Medium', 'WAF_Large')
| project subscriptionId,
          resourceGroup,
          name,
          location,
          skuName,
          skuTier,
          provisioningState = tostring(properties.provisioningState),
          operationalState = tostring(properties.operationalState)
| order by subscriptionId, resourceGroup, name

環境によってSKU表記の見え方が異なる場合があるため、最初はApplication Gatewayをすべて出力し、Standard_v2 や WAF_v2 以外が残っていないか確認すると安全です。

PowerShellで確認する例

Get-AzSubscription | ForEach-Object {
    $sub = $_
    Set-AzContext -SubscriptionId $sub.Id | Out-Null

    Get-AzApplicationGateway | Where-Object {
        $_.Sku.Tier -in @('Standard', 'WAF') -or
        $_.Sku.Name -in @(
            'Standard_Small',
            'Standard_Medium',
            'Standard_Large',
            'WAF_Medium',
            'WAF_Large'
        )
    } | Select-Object `
        @{Name='SubscriptionId';Expression={$sub.Id}},
        ResourceGroupName,
        Name,
        Location,
        @{Name='SkuName';Expression={$_.Sku.Name}},
        @{Name='SkuTier';Expression={$_.Sku.Tier}},
        @{Name='OperationalState';Expression={$_.OperationalState}}
}

棚卸し結果は、単なるリソース一覧ではなく、次の情報とセットで管理してください。

必須項目	確認理由
サブスクリプション、リソースグループ、リソース名	所有者と変更権限を特定するため
SKU名、Tier	V1かV2かを判定するため
紐づくPublic IP、DNS名	トラフィック移行方法を決めるため
リスナー、ルール、バックエンドプール	アプリケーション影響を確認するため
WAF設定	セキュリティ設定の移行漏れを防ぐため
証明書、Key Vault連携	HTTPS停止や証明書検証エラーを防ぐため
診断ログ、アラート	移行後の監視欠落を防ぐため
業務オーナー	移行可否とメンテナンス時間を判断するため

V2移行は「構成移行」と「トラフィック移行」を分けて考える

Microsoft Learnの移行ガイドでは、Application GatewayとWeb Application FirewallのV1からV2への移行を、Azure PowerShellスクリプトを使った構成の移行と、その後のトラフィックの移行の2段階として説明しています。V1ゲートウェイはV2へ自動アップグレードされないため、計画して実行する必要があります。(Microsoft Learn)

フェーズ	実施内容	失敗しやすいポイント
事前調査	V1のSKU、IP、DNS、WAF、証明書、バックエンドを確認	リソースだけ見て、DNSやアプリ担当を確認しない
構成移行	V2ゲートウェイを作成し、V1構成を複製	同じサブネットに作ろうとして失敗する
検証	V2のIPへ直接通信し、バックエンド正常性を確認	DNS切り替え前の疎通確認を省略する
トラフィック移行	DNS、Traffic Manager、Public IP保持スクリプトなどで切り替え	TTLやダウンタイムを見積もらない
事後対応	V1削除、監視・ログ・WAF・証明書設定の再確認	移行後にログやアラートが抜ける

構成移行だけで終わったと判断しないことが重要です。FAQでは、Azure PowerShellスクリプトは構成のみを移行し、実際のトラフィック移行は利用者が責任を持って制御すると説明されています。(Microsoft Learn)

拡張複製スクリプトを使う場合の確認点

移行ガイドでは、拡張複製スクリプトが推奨オプションとして紹介されています。フロントエンドSSL証明書やバックエンドの信頼されたルート証明書の手動入力を減らし、プライベートのみのV2ゲートウェイのデプロイもサポートするとされています。(Microsoft Learn)

ただし、スクリプトを実行すれば安全に完了するわけではありません。次の点を事前に確認してください。

同じサブネットにV1とV2は共存できない

V1ゲートウェイとV2ゲートウェイは同じサブネットに共存できません。移行予定の環境では、V2用の専用サブネットと十分なIPアドレス空間を用意する必要があります。FAQにも、各ゲートウェイ種別には仮想ネットワーク内で独自の専用サブネットが必要と説明されています。(Microsoft Learn)

NSGとUDRはV2要件に合わせて見直す

V2ゲートウェイ用サブネットにNSGやUDRを関連付ける場合、Application Gateway V2の要件に合っていないと移行や稼働に失敗することがあります。移行ガイドでも、V2ゲートウェイサブネットのNSGやUDRが要件に準拠しているか確認するよう記載されています。(Microsoft Learn)

TLS検証の緩和は一時的な措置として扱う

拡張複製スクリプトでは、複製中にバックエンドTLS検証が既定で緩和されると説明されています。これは移行時の互換性を確保するためには有効ですが、本番運用で恒久的に緩和したままにすると、証明書チェーン、有効期限、SNI検証の観点でセキュリティリスクになります。移行後は信頼されたルート証明書を追加し、必要な検証を再度有効化する流れを作ってください。(Microsoft Learn)

トラフィック移行で選ぶべき方法

V2ゲートウェイを作成して疎通確認が終わったら、実際のクライアントトラフィックを切り替えます。ここは環境依存が大きく、単純に「DNSを変える」だけでは済まないことがあります。

現在の構成	推奨される考え方	注意点
カスタムドメインのAレコードがV1のフロントエンドIPを指す	V2のフロントエンドIPまたはDNSラベルへ変更	DNS TTLにより反映に時間差が出る
CNAMEがV1のDNSラベルを指す	V2のDNSラベルへ変更、またはTraffic Managerで段階移行	段階移行には事前設計が必要
クライアントがIPアドレスへ直接接続	クライアント設定をV2のIPまたはDNS名へ変更	直接IP利用は変更範囲が広がりやすい
既存Public IPを維持したい	Public IP保持スクリプトを検討	ダウンタイムと不可逆性を理解する
社内向け・private-only構成	V2用サブネット、委任、ネットワーク分離設定を確認	事前設定不足でデプロイ失敗しやすい

移行ガイドでは、Public IP保持スクリプトによりV1のBasic Public IPを予約し、Standardへ変換してV2ゲートウェイにアタッチできる一方、通常1〜5分程度の短いダウンタイムが発生し、V1とV2は同じサブスクリプションにある必要があると説明されています。また、このPublic IPスワップは開始後にスクリプトでV1へ戻せない不可逆操作です。(Microsoft Learn)

WAF、証明書、ログは移行後に必ず再点検する

Application Gateway V1からV2への移行で見落としやすいのは、ロードバランサーとしての疎通だけを見て「移行完了」と判断してしまうことです。実際には、WAF、証明書、ログ、アラートが期待通りに動いているかまで確認しなければ、セキュリティと運用の品質が下がります。

WAF構成

WAF V1を使っている場合、WAF V2側のルールセット、除外設定、カスタムルール、検知モード・防止モードの設定を確認してください。移行ガイドでは、WAF V2が既定でCRS 3.0を使う構成になること、CRS 3.0は非推奨へのパス上にあるため移行後に最新のルールセットへアップグレードする必要があることが示されています。(Microsoft Learn)

バックエンド証明書

FAQでは、V1は認証証明書を使用し、Application Gatewayに構成された証明書とバックエンドサーバー証明書の完全一致を行う一方、V2は既定で証明書チェーンとバックエンドサーバー証明書のサブジェクト名をより包括的に検証すると説明されています。(Microsoft Learn)

つまり、V1で問題なく動いていたHTTPSバックエンドが、V2では証明書検証の違いでエラーになる可能性があります。移行前に、バックエンド証明書の発行元、CN/SAN、有効期限、SNI要件を確認してください。

ログと監視

FAQでは、V1でAzure Storageへログを送信していた構成は、スクリプトによってV2へ自動的に複製されないため、移行後のV2ゲートウェイにログ構成を別途追加する必要があると説明されています。(Microsoft Learn)

移行後は、少なくとも次の監視を確認してください。

確認対象	見るべき内容
バックエンド正常性	すべてのバックエンドプールがHealthyか
アクセスログ	実トラフィックがV2経由になっているか
WAFログ	ブロック・検知ルールが想定通りか
メトリック	接続数、スループット、エラー率、容量ユニット
アラート	既存の通知先・閾値がV2に適用されているか
コスト	V1とV2の料金モデル差分が想定内か

V2へ移行するメリットも同時に評価する

今回の対応は廃止回避が主目的ですが、V2移行は単なる延命作業ではありません。Microsoft Learnでは、Application Gateway v2はv1に比べてパフォーマンス強化、自動スケーリング、ゾーン冗長、静的VIPなどの利点があると説明されています。(Microsoft Learn)

技術判断では、次のように「移行で何を改善するか」まで決めておくと、関係者の合意が取りやすくなります。

改善テーマ	V2移行時に検討すること
可用性	ゾーン冗長を利用できるリージョンか確認する
性能	自動スケーリング有効化の要否を判断する
セキュリティ	WAFポリシー、Bot保護、Key Vault連携を見直す
運用	ログ、アラート、ダッシュボードを再設計する
コスト	V1の固定的な見積もりではなく、V2の消費ベースで試算する
将来性	新機能がV2中心に提供される前提で設計する

意思決定者が確認すべき優先順位

技術担当者だけでなく、technical decision makersは次の順番で判断してください。

優先度	対応	判断基準
最優先	本番V1の有無を確認	外部公開サービス、売上影響、顧客影響がある
高	V2移行または削除の方針決定	業務オーナーが不明、または移行期限を過ぎている
高	メンテナンスウィンドウ確保	Public IP保持やDNS切り替えが必要
中	セキュリティレビュー	WAF、TLS、Key Vault、証明書検証に差分がある
中	コスト試算	V2移行後の容量ユニット、Public IP、ログ保存コストを確認
低ではない	不要V1の削除	使っていないが残っているリソースも削除対象として扱う

判断を遅らせる一番の原因は、「まだ通信できているから大丈夫」という見方です。廃止後のリソースは、正常稼働しているように見えても、サポート・SLA・継続性の前提が変わっています。運用上は、既知の障害リスクとして扱うのが安全です。

この記事を読んだ後に実施すべきチェックリスト

チェック	完了条件
全サブスクリプションでApplication Gatewayを一覧化した	V1 SKUの有無が分かっている
V1が残っている場合、業務オーナーを特定した	移行・削除を判断できる責任者がいる
DNS、Public IP、バックエンド、WAF、証明書を棚卸しした	トラフィック切り替え方式を選べる
V2用サブネットとNSG/UDR要件を確認した	構成移行で詰まらない
V2作成後の疎通確認手順を用意した	DNS切り替え前にテストできる
トラフィック移行方法を決めた	DNS変更、Traffic Manager、Public IP保持などを選定済み
ダウンタイムと不可逆操作を関係者に説明した	メンテナンス承認が取れている
移行後のログ・監視・WAF・証明書検証を確認した	移行後の運用品質が落ちていない
不要なV1を削除した	廃止済みリソースが残っていない

まとめ

Azureの公式ドキュメント更新「Add retirement-faq.md and v1-retirement.md changes from PR 315056」は、Application Gateway V1廃止後の扱いを明確にする更新です。確認すべき点は、差分の文言そのものではなく、自社環境にV1が残っていないか、残っている場合にV2移行または削除をすぐ実行できるかです。

次に取るべき行動は明確です。まず全サブスクリプションでApplication Gateway V1を洗い出し、残存リソースごとに「削除」「V2移行」「業務オーナー確認待ち」に分類してください。そのうえで、V2用サブネット、証明書、WAF、ログ、DNS、Public IPの移行方式を決め、構成移行とトラフィック移行を別工程として管理することが、サービス中断を避けるための現実的な対応です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure公式ドキュメント更新で確認すべきApplication Gateway V1廃止とV2移行

Azureの公式ドキュメント更新「Add retirement-faq.md and v1-retirement.md changes from PR 315056」で何が変わったか

対象サービスはAzure Application Gateway V1