Azureの公式ドキュメント更新「Update v1-retirement.md」を見て最初に押さえるべき結論は、今回のコミット自体は大きな仕様変更ではなく、ms.date の表記を修正するメタデータ更新だという点です。ただし、対象ページは Azure Application Gateway V1 の廃止に関する重要文書です。2026年5月時点では Application Gateway V1 はすでに退役日を過ぎており、V1を利用している環境ではサポート、SLA、通信継続性の観点から早急な確認が必要です。(GitHub)
この記事では、2026年5月1日前後に確認された公式ドキュメント更新の読み解き方、Azure運用担当者が確認すべき影響範囲、Application Gateway V1からV2への移行準備で失敗しやすいポイントを、実務目線で整理します。
Azureの公式ドキュメント更新「Update v1-retirement.md」で何が変わったか
今回の GitHub コミット「Update v1-retirement.md」は、articles/application-gateway/v1-retirement.md を対象にした更新です。差分を見ると、本文の廃止日や移行方針が書き換えられたのではなく、フロントマター内の ms.date が 0430/2026 から 04/30/2026 に修正されています。(GitHub)
| 確認項目 | 内容 | 実務上の見方 |
|---|---|---|
| 対象ファイル | articles/application-gateway/v1-retirement.md | Azure全体ではなく、Application Gateway V1 の廃止通知ページ |
| コミット差分 | ms.date の表記修正のみ | 新機能追加や移行期限延長とは読まない |
| 公開ページの位置づけ | Application Gateway V1 から V2 への移行案内 | V1利用環境の棚卸し・移行計画の確認が主目的 |
| 重要度 | 差分は小さいが、対象テーマは高重要度 | 変更内容よりも「廃止済みサービスを使っていないか」が重要 |
つまり、今回の更新を「Azureの新しい仕様変更」と捉えるより、Application Gateway V1廃止に関する公式ページが更新状態になったため、自社環境のV1残存を再確認するタイミングと捉えるのが実務的です。
今回の更新で本当に確認すべきポイント
Microsoft Learn の該当ページでは、Application Gateway V1 は 2026年4月28日に廃止され、同日以降は V1 リソースがサポートされず、SLA も提供されないと説明されています。さらに、V1を支えるハードウェアの使用停止が進むと、V1リソースを通過するトラフィックに影響が出る可能性があります。(Microsoft Learn)
ここで重要なのは、「ドキュメント更新日」ではなく「サービスの状態」です。2026年5月時点で見ると、Application Gateway V1 は将来廃止予定のサービスではなく、すでに退役日を過ぎたサービスとして扱う必要があります。
確認すべき点は、次の3つです。
| 確認すべき点 | 判断基準 | 対応 |
|---|---|---|
| V1リソースが残っているか | SKU が Standard_Small、Standard_Medium、Standard_Large、WAF_Medium、WAF_Large などのV1系か | 影響範囲を特定し、移行チケットを作成 |
| 本番トラフィックを処理しているか | DNS、パブリックIP、社内システム、API、WAF経由通信を確認 | 優先度を最高にして切り替え計画を作る |
| 移行済みと判断できる証跡があるか | V2ゲートウェイ、DNS切り替え、監視、ログ、WAFポリシーを確認 | 旧V1削除または残存理由を記録 |
V1が見つからない場合でも、「確認した」という記録を残すことが大切です。大規模環境では、古いサブスクリプション、検証環境、買収・統合されたシステム、海外拠点のリソースにV1が残っていることがあります。
影響を受ける可能性がある環境
今回の対象は Azure Application Gateway V1 です。Application Gateway は、WebアプリケーションのL7ロードバランシング、SSL/TLS終端、WAF、URLベースルーティングなどで使われることが多く、影響範囲がアプリケーション全体に広がりやすいサービスです。
特に注意すべき環境は次の通りです。
| 環境 | リスク | 確認ポイント |
|---|---|---|
| 本番Webサイト | 外部ユーザーからのアクセス断 | DNS、フロントエンドIP、バックエンド正常性 |
| 社内業務システム | ログイン画面やAPIが利用不能になる可能性 | 社内DNS、VPN経由アクセス、認証方式 |
| WAF利用環境 | セキュリティルールや検知挙動が変わる可能性 | WAFポリシー、除外ルール、ルールセット |
| 証明書を多用する環境 | TLS検証の違いでバックエンド接続に失敗する可能性 | ルート証明書、SNI、証明書チェーン |
| グローバル展開サービス | リージョン、時差、TTLにより切り替えが複雑化 | メンテナンス時間帯、各国DNS反映、監視体制 |
Application Gateway V2 では、可用性ゾーン、自動スケール、Key Vault統合、WAF機能強化、CPU以外も含む監視など、V1より多くの機能が提供されます。一方で、V1からV2へ自動アップグレードされるわけではないため、移行作業はユーザー側で計画する必要があります。(Microsoft Learn)
まず実施すべき棚卸し
Azureポータルだけで確認すると、サブスクリプションをまたいだ見落としが起きやすくなります。複数サブスクリプションを管理している場合は、Azure Resource Graph や PowerShell を使って一覧化するのが安全です。
Azure CLI で確認する場合は、次のようなクエリが使えます。
az graph query -q "
Resources
| where type =~ 'microsoft.network/applicationgateways'
| project
name,
resourceGroup,
subscriptionId,
location,
skuName = tostring(sku.name),
skuTier = tostring(sku.tier)
| order by subscriptionId, resourceGroup, name
"PowerShell でサブスクリプションごとに確認する場合は、次の観点で出力します。
Get-AzApplicationGateway |
Select-Object Name, ResourceGroupName, Location,
@{Name='SkuName';Expression={$_.Sku.Name}},
@{Name='SkuTier';Expression={$_.Sku.Tier}}棚卸しで見るべき項目は、SKU名だけではありません。移行可否や切り替え方法に関わる情報も同時に集めます。
| 項目 | なぜ必要か | 具体的な確認内容 |
|---|---|---|
| SKU / Tier | V1かV2かを判定するため | Standard_v2、WAF_v2 以外がないか |
| フロントエンド構成 | 切り替え方法に影響するため | パブリックIP、プライベートIP、DNS名 |
| リスナー | アプリ単位の影響を把握するため | HTTP/HTTPS、ホスト名、ポート |
| 証明書 | TLS移行の失敗を防ぐため | PFX、Key Vault、期限、信頼チェーン |
| バックエンドプール | 移行後の疎通確認に必要 | VM、VMSS、App Service、AKS、IP/FQDN |
| WAF設定 | セキュリティ挙動が変わる可能性があるため | ルールセット、除外、カスタムルール |
| 診断ログ | 移行後の調査に必要 | Log Analytics、Storage、Event Hub |
| DNS / TTL | 切り替え時間に影響するため | Aレコード、CNAME、TTL、Traffic Manager利用 |
棚卸しのゴールは、「V1があるかないか」を見るだけではありません。移行の難易度、停止許容時間、切り戻し方法、責任者まで明確にすることです。
移行準備で押さえるべき実務ポイント
構成移行とトラフィック移行は別作業として扱う
Microsoftの移行ガイドでは、Azure PowerShellスクリプトを使ってV1からV2へ構成を移行できます。ただし、移行は大きく「構成移行」と「クライアントトラフィック移行」の2段階です。スクリプトで新しいV2ゲートウェイを作成しても、本番トラフィックの切り替えまで自動的に完了するわけではありません。(GitHub)
失敗しやすいのは、「スクリプトを実行したから移行完了」と判断してしまうケースです。実際には、次の作業が残ります。
| 作業 | 内容 |
|---|---|
| V2構成の確認 | リスナー、ルール、バックエンド、WAF、証明書を確認 |
| 疎通テスト | V2のIPまたはDNSへ直接アクセスして確認 |
| 監視設定 | メトリック、ログ、アラートを再設定 |
| DNSまたはIP切り替え | 本番トラフィックをV2へ向ける |
| 旧V1の停止・削除判断 | 安定稼働を確認して不要コストとリスクを解消 |
特に、夜間や休日のメンテナンス枠で作業する場合は、「構成作成」「検証」「トラフィック切り替え」「切り戻し判断」の時間を分けて計画してください。
V2用の専用サブネットを用意する
Application Gateway V1とV2は同じサブネットに共存できません。V2へ移行する場合は、V2用の新しい専用サブネットを用意し、十分なIPアドレス空間を割り当てる必要があります。(Microsoft Learn)
この点は、ネットワーク設計で詰まりやすいポイントです。既存VNetのアドレス空間が小さい場合、単純に「V2用サブネットを追加する」だけでは済まないことがあります。
確認すべき項目は次の通りです。
| 確認項目 | 注意点 |
|---|---|
| VNetの空きアドレス | V2用サブネットを切れるだけのCIDRがあるか |
| NSG | Application Gatewayの要件を満たしているか |
| UDR | 管理トラフィックやバックエンド通信を妨げないか |
| Private-only構成 | 必要な機能登録やサブネット委任を確認 |
| IaC管理 | Terraform、Bicep、ARMテンプレートとの差分を反映 |
V2移行を急ぐ場面でも、ネットワーク設計を飛ばすと後から切り戻しや再作成が必要になります。特にグローバル環境では、リージョンごとのVNet設計やIPアドレス管理ルールも確認してください。
バックエンド証明書とTLS検証の違いに注意する
Application Gateway V1とV2では、バックエンド証明書の扱いが異なります。FAQでは、V1はApplication Gatewayに構成された証明書とバックエンドサーバー証明書の完全一致を使う一方、V2は既定で証明書チェーンとバックエンド証明書のサブジェクト名をより包括的に検証すると説明されています。(Microsoft Learn)
移行時に起きやすいトラブルは、V1では動いていたHTTPSバックエンドが、V2では証明書検証エラーになるケースです。移行ガイドでは、V2のバックエンドTLS検証を一時的に緩和できる機能にも触れていますが、これは移行を円滑にするための一時措置であり、本番では適切な信頼ルート証明書を設定し、検証を戻すことが推奨されます。(GitHub)
実務では、次の順序で確認すると安全です。
| 手順 | 確認内容 |
|---|---|
| 証明書一覧を作る | リスナー証明書、バックエンド証明書、Key Vault連携を整理 |
| バックエンドFQDNを確認 | 証明書のCN/SANと一致しているか |
| ルート証明書を確認 | V2に必要な信頼ルート証明書を準備 |
| テスト通信を行う | V2経由でHTTPSバックエンドに疎通できるか |
| 一時緩和を戻す | 移行完了後にTLS検証を安全な状態へ戻す |
「とりあえず検証を緩めたまま本番運用する」は避けるべきです。移行直後のトラブル回避と、移行後のセキュリティ維持は分けて考えてください。
WAF利用環境ではルールセットとログを必ず確認する
Application Gateway WAF V1を使っている環境では、V2移行後のWAF設定も確認が必要です。移行ガイドでは、WAF V2のルールセットやWAFポリシーに関する注意点が示されています。特に、移行後に最新のルールセットへ更新するか、既存アプリケーションで誤検知が起きないかを確認することが重要です。(GitHub)
WAF移行で見落としやすいのは、ブロックされた通信そのものではなく、これまで許可していた業務通信が新しいルールで検知されることです。ログイン、ファイルアップロード、検索フォーム、APIリクエストなどは事前にテストしてください。
| 確認対象 | 具体例 |
|---|---|
| 除外ルール | 特定ヘッダー、Cookie、リクエストボディの除外 |
| カスタムルール | IP制限、国別制限、特定パスの制御 |
| ルールセット | CRS / DRS のバージョン差異 |
| 検知モード | Detection か Prevention か |
| ログ出力 | Log Analytics、SIEM連携、アラート通知 |
セキュリティチームとアプリ担当が別組織の場合、移行直前にWAFの判断をすると調整が遅れます。早めにテストログを共有し、誤検知をつぶしておくことが重要です。
パブリックIP維持とDNS切り替えの方式を選ぶ
V1からV2への切り替えでは、DNSを変更する方法と、パブリックIP保持スクリプトを使う方法があります。Microsoftの移行ガイドでは、パブリックIP保持スクリプトを使う場合、通常1〜5分程度のダウンタイムが発生すること、IPスワップは不可逆であること、作業中は関連リソースへの別操作を避ける必要があることが示されています。(GitHub)
どちらを選ぶべきかは、システムの接続方式で変わります。
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| DNS切り替え | CNAMEやAレコードで管理しているWebサイト | TTLにより反映時間がばらつく |
| Traffic Manager等で段階移行 | グローバルサービス、段階的な移行が必要な環境 | 事前設計と検証が必要 |
| パブリックIP保持 | クライアントが固定IPへ直接接続している環境 | 短時間停止、不可逆操作、同一サブスクリプション条件に注意 |
| クライアント設定変更 | 社内システムや限定利用API | 利用者側の変更漏れに注意 |
固定IPを外部取引先に許可リスト登録している場合、DNSだけでは解決できないことがあります。逆に、DNS管理が整っている環境では、TTLを事前に短くして段階的に切り替える方が安全な場合もあります。
開発者・クラウド管理者・アーキテクト別の確認観点
今回の Azure 公式ドキュメント更新は、読む人の役割によって取るべき行動が変わります。
| 役割 | 重点的に見るポイント | 次のアクション |
|---|---|---|
| developers | アプリのHTTPS通信、リダイレクト、WAF誤検知 | V2経由のE2Eテストを用意 |
| cloud admins | SKU、サブネット、IP、DNS、監視、コスト | V1棚卸しと移行作業計画を作成 |
| solution architects | 可用性、切り替え方式、グローバル影響 | 移行方式と切り戻し設計をレビュー |
| technical decision makers | サポート切れリスク、停止リスク、予算 | 移行優先度と責任者を決定 |
技術的な移行だけに注目すると、意思決定が遅れます。Application Gatewayは入口のコンポーネントなので、アプリ、ネットワーク、セキュリティ、運用、ビジネス部門を巻き込んで進める必要があります。
よくある誤解と注意点
今回の更新で廃止期限が延長されたわけではない
コミット差分は ms.date の表記修正であり、Application Gateway V1の廃止日が延長されたことを示すものではありません。公式ページでは、V1は2026年4月28日に廃止される、または廃止済みであるという説明が維持されています。(GitHub)
Microsoftが自動で移行してくれるわけではない
FAQでは、Microsoftがユーザーのデータを移行することはできず、セルフサービスの移行が必要だと説明されています。構成移行スクリプトはありますが、最終的な移行計画、テスト、トラフィック切り替えは利用者側の責任です。(Microsoft Learn)
ログ設定は移行後に再確認が必要
FAQでは、V1でAzure Storageへログを送信していた構成は、スクリプトでV2へ複製されないと説明されています。移行後にログが出ていないと、障害発生時に原因調査が難しくなります。(Microsoft Learn)
移行期間は短く見積もらない
FAQでは、移行に必要な時間はデプロイの複雑さによって異なり、最大で数か月を見込むよう案内されています。単一ゲートウェイなら短時間で終わる場合もありますが、WAF、証明書、複数バックエンド、固定IP、グローバルDNSが絡むと調整に時間がかかります。(Microsoft Learn)
優先度の付け方
V1リソースが複数見つかった場合は、数ではなく影響度で優先順位を決めます。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | 本番、外部公開、WAF利用、固定IP利用、重要API | 直ちに移行計画とメンテナンス枠を確保 |
| 中 | 社内向け、検証環境だが業務影響あり | 利用者確認後、短期でV2へ移行または廃止 |
| 低 | 未使用、停止済み、移行済みの残骸 | 削除可否を確認し、不要なら削除 |
| 確認のみ | すべてV2で運用中 | 棚卸し結果を記録し、監視対象を更新 |
本番環境だけでなく、検証環境も軽視しないでください。検証環境が止まると、リリース前テストや障害調査ができなくなり、結果的に本番運用へ影響します。
最後にやるべきこと
今回の Azure 公式ドキュメント更新「Update v1-retirement.md」は、差分だけを見ると小さなメタデータ修正です。しかし、対象は Application Gateway V1 の廃止という、運用影響の大きいテーマです。
まずは全サブスクリプションで Application Gateway のSKUを棚卸しし、V1が残っているかを確認してください。V1が見つかった場合は、V2用サブネット、証明書、WAF、DNSまたはIP切り替え、監視ログ、切り戻し条件を整理し、移行計画を具体化します。V1が見つからなかった場合も、確認結果を記録しておくことで、監査や障害対応時に説明しやすくなります。
ドキュメント更新を読む目的は、変更差分を眺めることではありません。自社環境に影響するサービス終了、仕様差異、移行作業を見落とさず、次の行動につなげることです。
コメント