Azure VPN Gateway や VM で Basic SKU のパブリック IP を使っていると、Microsoft からの通知メールと公式ドキュメントで日付が違って見え、「結局いつまでに移行すればいいの？」と判断に迷いがちです。本記事では、VPN Gateway とそれ以外で扱いが分かれるポイント、期限の読み解き方、Standard SKU への移行を失敗しない実務手順をまとめます。
結論：期限は「VPN Gateway」と「それ以外」で分けて考える
混乱の原因は、同じ「Basic SKU のパブリック IP」でも、ぶら下がっているサービスによって“扱い”と“タイムライン”が異なることです。とくに Azure VPN Gateway は、移行ツールの提供状況や互換性の事情により、Basic IP の移行期限が別枠で更新されてきました。
| Basic Public IP の使い道 | 公式情報（要点） | 実務上の結論 |
|---|---|---|
| VPN Gateway で使用（Virtual network gateway の Public IP） | VPN Gateway 向け Basic IP の deprecation タイムラインは 2026年3月末まで延長と記載 2026年4月に Basic SKU Public IP が非推奨という記載 ただし「タイムラインは変更され得る」と明記 | 2025年9月末を“絶対期限”にせず、2026年3月末までに移行完了できる計画にする（ただし余裕を強く推奨）。 |
| VPN Gateway 以外（VM/NIC、NVA、各種フロントエンド IP など） | Basic Public IP は 2025年9月30日に retired retired 後も運用上は動作し得るが、サポート外・SLA 外として利用リスクを受け入れる前提 | “動くかもしれない”に賭けず、できるだけ早く Standard 化（社内の締切は 9/30 を目安にすると事故が減る）。 |
そもそも何が変わる？Basic と Standard の違い（移行後に止まる原因）
Basic から Standard に上げると、単に SKU が変わるだけではなく、通信の前提（セキュリティ既定値）が変わります。移行後の「想定外の疎通不可」の多くは、ここを見落とすことで起きます。
| 観点 | Standard SKU Public IP | Basic SKU Public IP |
|---|---|---|
| 割り当て方式 | Static（固定） | IPv4 は Dynamic / Static、IPv6 は Dynamic など |
| セキュリティ | Secure by default（既定で閉じる）。受信を通すには NSG などで許可が必要 | Open by default（既定で開く）。NSG は推奨だが必須ではない |
| 機能・互換性 | 可用性ゾーン、Standard Load Balancer、NAT Gateway などの組み合わせが前提になる | 機能・互換性が限定される（Standard LB / NAT Gateway などと組み合わせできない） |
なぜ日付が混在するのか：メールとドキュメントで期限がズレて見える理由
日付の混在は、次の3つが同時に語られることで起きます。
- Basic SKU Public IP（IP リソース）の retired（サポート終了）
- VPN Gateway に紐づく Basic IP の移行（ツール提供状況により期限が更新）
- VPN Gateway のレガシー SKU（Standard / High Performance 等）の移行期限
たとえば VPN Gateway FAQ には「Standard / High Performance の既存ゲートウェイは 2026年2月28日までサポート（当初 2025年9月30日から延長）」という記述があります。これは“Basic Public IP の期限”ではなく“レガシーなゲートウェイ SKU のサポート期限”です。
一方で VPN Gateway の変更予定（Upcoming projected changes）には、Basic IP の deprecation タイムラインが 2026年3月末へ更新され、2026年4月に Basic IP が非推奨になる旨が書かれています。つまり、「メール（一般ルール）」と「VPN Gateway（例外・別ルール）」が混ざることで、日付が食い違って見えるのが実態です。
質問1：2025年9月末までに必ず移行が必要？後ろ倒しできる？
VPN Gateway で Basic Public IP を使っている場合
結論として、VPN Gateway に紐づく Basic Public IP は 2025年9月末を絶対期限として扱う必要はありません。VPN Gateway の projected changes では、Basic IP の deprecation タイムラインが 2026年3月末まで延長され、2026年4月に Basic SKU Public IP が非推奨になる想定が示されています（ただし変更され得ます）。
ただし、ここで重要なのは「期限が延びた＝放置でOK」ではないことです。VPN Gateway の Basic IP 移行は、リージョンへの段階的ロールアウトや構成（Active-Active/Active-Passive、P2S あり/なし等）によって適用可否・手順が変わります。期限間際だと、GatewaySubnet の空き不足など“事前設計が必要な問題”に気付いた時点で詰みやすいので、棚卸しと準備は早めに進めましょう。
VPN Gateway 以外で Basic Public IP を使っている場合
こちらは考え方が逆になります。Basic Public IP は 2025年9月30日に retired とされ、retired 後はサポートされない状態になります。ただし公式ガイダンスでは、retired 後も一定期間は動作し得る一方で、“unsupported / SLA 対象外”のリスクを受け入れる前提であることが明記されています。
したがって、メールが「9月30日までに移行」と言っていても、実務的には“その日以降はいつ止まっても文句が言えない状態”だと捉えるのが安全です。外部公開や顧客向け接続など止められない用途ほど、9月末を社内の締切として前倒しで Standard 化するのが無難です。
質問2：期限延長の対象は「VPN Gateway に紐づく Basic IP だけ」？
はい。延長（別タイムライン）が示されているのは VPN Gateway に関連する Basic Public IP の移行です。VPN Gateway には “IP アドレスを変えずに Basic → Standard を移行する” ための仕組み（ポータルの Migrate タブ等）が提供されており、その展開計画に合わせて期限が更新されています。
一方で、VM やロードバランサー、NVA などで使っている Basic Public IP は、VPN Gateway の延長とは別扱いです。retired 後に動作し得るとされても、サポート外である以上、運用リスク（監査・障害対応・SLA）を抱えたまま残る点を踏まえて、早期移行を基本方針にします。
質問3：VPN Gateway 以外で使っている Basic IP はいつまで動作する？
Microsoft Learn のガイダンスでは、Basic Public IP は 2025年9月30日に retired とされる一方で、retired 後も一定期間は「運用上は動作し得る」とされています。ただしその場合、利用者がリスクを受け入れ、サポート外・SLA 外で使い続ける形になります。
つまり「いつまで動くか」を一点で断言するよりも、“9/30 以降は動作しても無保証”という前提で、移行コストと停止リスクを比較して ASAP で Standard 化する、が現実的な答えです。
移行前に必ずやる：Basic Public IP の棚卸し（影響範囲の切り分け）
移行計画を立てるときは、まず「どの Basic IP が VPN Gateway 用で、どれがそれ以外か」をリソース単位で切り分けます。ここを曖昧にしたまま作業すると、期限も手順もズレて事故が起きます。
ポータルでの確認ポイント
- 「Public IP addresses」の一覧で SKU 列を確認（Basic / Standard）
- 対象 IP の Associated to（関連付け先） を確認（NIC、Load Balancer、Virtual network gateway など）
- VPN Gateway の場合は Virtual network gateway リソース側から IP リソースへ辿って確認
CLI での棚卸し例
サブスクリプション内の Basic Public IP を一覧化するなら、Azure CLI のクエリが便利です。
az network public-ip list --query "[?sku.name=='Basic'].{name:name,rg:resourceGroup,ip:ipAddress,allocation:publicIPAllocationMethod}" -o table個別の Public IP の SKU を確認するなら次のようにします。
az network public-ip show --resource-group <RG> --name <PublicIPName> --query "sku.name" -o tsvVPN Gateway 用 Basic Public IP を Standard に移行する手順（IP を変えたくない人向け）
VPN Gateway で Basic Public IP を使っている場合、「IP アドレスを維持したまま SKU を上げたい」ケースがほとんどです。公式手順では、移行プロセス中に Basic の Public IP リソースが Standard に移行され、ゲートウェイに割り当てられている IP アドレスは変わらないと説明されています。さらに VpnGw1-5 の場合、ゲートウェイ SKU が AZ SKU に移行される可能性も示されています。
作業の全体像（Prepare → Migrate → Validate/Commit）
| フェーズ | やること | 運用上の注意点 |
|---|---|---|
| Prepare | 事前要件をチェックし、Standard 側の準備を作成 | GatewaySubnet の空き IP など、構成によってはこの段階で止まる |
| Migrate | Basic → Standard の移行を実行（必要に応じてゲートウェイ SKU も AZ SKU へ） | ポータル手順では約 5 分のダウンタイム、Projected changes では最大 10 分程度が目安として示されている |
| Validate / Commit | 疎通を確認し、問題なければ Commit。問題があれば Abort でロールバック | 検証を急がず、監視・ログも含めて確認する |
よく詰まる前提条件：GatewaySubnet の空き IP
VPN Gateway の移行では、GatewaySubnet に少なくとも 3 つの利用可能 IPが必要とされています。/28 以下など小さすぎる場合はエラーになる可能性があり、その場合は GatewaySubnet にプレフィックスを追加するなどの対処が必要です。
「Migrate タブが出ない」場合
移行機能はリージョンに段階的に展開されており、ポータルに Migrate タブが表示されない場合は、その時点で利用できない可能性があります（その場合は PowerShell の手順を選ぶ、もしくは計画を見直す）。
P2S の legacy DNS（cloudapp.NET）を使っている場合の注意
Point-to-Site を使っている VPN Gateway の一部構成では、旧来の cloudapp.NET ベースの DNS 設定が残っていると、現行ツールでは移行できないケースがあるとされています。この場合は専用の移行アプローチが開発中で、ガイド付き移行体験のリリースは2026年1月末までにタイムライン告知予定と説明されています。該当する場合、公式の注意事項（P2S 構成を削除しない等）に従って計画を立てます。
VPN Gateway 以外の Basic Public IP を Standard 化する手順
VPN Gateway 以外は「IP を変えずにアップグレードしたいか」「IP が変わってもよいか」で手順が分かれます。外部公開の宛先が固定（取引先の許可リストや DNS 固定）なら“同一 IP のままアップグレード”、それ以外は“新しい Standard IP へ付け替え”が運用しやすいことが多いです。
同一 IP のままアップグレード（Basic → Standard）したい場合
公式手順では、Basic Public IP を Standard にアップグレードするには、対象の IP が Static であること、そしていったん関連付けが外れていることが前提になります。Dynamic の Basic IP は Standard にアップグレードできないため、事前に Static へ変更します。アップグレード自体は元の IP を維持します。
CLI なら次のような形になります（実行前に関連付け解除が必要です）。
az network public-ip update --resource-group <RG> --name <PublicIPName> --sku Standardまた、Standard は既定で閉じるため、切替後に通信が止まらないよう、NIC またはサブネットに適切な NSG ルールを適用します。
“アップグレードしたのにゾーン冗長にならない”問題
Basic からアップグレードした Standard Public IP は、可用性ゾーンが「保証されない」扱いになることがあります。可用性ゾーン前提の設計（ゾーン冗長のフロントエンド等）に載せたい場合は、新規に Standard Public IP を作り直す方が安全です。
IP が変わってよい場合（新規 Standard を作って付け替える）
関連付け解除の影響が大きい場合や、切替を段階的に行いたい場合は、Standard Public IP を新規作成して付け替える方が現実的です。DNS を使っているなら TTL を短くして切替し、許可リストがあるなら新 IP の反映を先に依頼する、という段取りが基本です。
ロードバランサー利用者は要注意：SKU の“組み合わせ制約”がある
外部公開が Load Balancer 経由の場合、Public IP の SKU だけを上げても完了しません。Microsoft Learn の Load Balancer SKU 比較では、Public Standard Load Balancer は Standard Public IP が必須、Public Basic Load Balancer は Basic Public IP が必須と明記されています。さらに Basic Load Balancer 自体が 2025年9月30日に retired とされているため、Basic LB を使っている場合はLoad Balancer の Standard 化もセットで検討する必要があります。
例外として知っておきたいケース（全部が同じ締切ではない）
- Cloud Services Extended Support（CSES）は、この Basic Public IP の retired による影響を受けない（CSES では Basic IP を使い続けられる旨の記載がある）。ただし ARM ネイティブの構成では Standard 推奨。
- Application Gateway v1に紐づく Basic IP は、AppGW v1 自体が retired されるまで影響を受けない旨の説明がある（ただし v2 への移行が推奨）。
移行後に事故らないためのチェックリスト
| 観点 | チェック内容 | 見落としがちなポイント |
|---|---|---|
| 疎通 | 外部→サービス、VPN 接続、監視の死活を確認 | Standard は NSG 未設定だと“閉じたまま”になりやすい |
| 名前解決 | DNS の A レコード、TTL、キャッシュ状況を確認 | 切替直後はクライアント側キャッシュで旧 IP に向くことがある |
| 許可リスト | 取引先 FW / SaaS 側の許可 IP を更新 | IP を維持したつもりでも、実際の宛先が変わっていないか確認 |
| IaC / 自動化 | ARM/Bicep/Terraform、スクリプトの SKU/参照先を更新 | VPN Gateway（Basic SKU Gateway）では Basic Public IP リソース参照が属性に置き換わる案内がある |
| 監査・運用 | 手順書、障害対応、SLA 前提の見直し | retired のまま残すと、監査上の指摘やリスク承認が必要になりやすい |
まとめ：判断に迷ったら「サポート期限」と「VPN Gateway の移行期限」を分けて読む
- VPN Gateway の Basic Public IPは別タイムラインで延長が示されており、2026年3月末までに Standard へ移行完了できる計画にする（余裕を推奨）。
- VPN Gateway 以外の Basic Public IPは 2025年9月30日に retired。retired 後も動作し得るがサポート外なので、止められない用途ほど前倒しで Standard 化する。
- ドキュメントに出てくる 2026年2月28日は「レガシーな VPN Gateway SKU（Standard/High Performance）」のサポート期限であり、Basic Public IP の期限と混同しない。
コメント