Azure VPN Gateway（Generation 1）でBasic Public IPを使う場合の廃止対応とStandard移行手順（期限・自動対応・再構築）

Azure VPN Gateway（Virtual Network Gateway）をGeneration 1で運用し、さらにBasic SKUのPublic IPを使っていると、ポータルに「Basic→Standard」の移行UIが出ず、廃止対応が不安になりがちです。この記事では、最新のタイムラインの考え方、UIが出ない理由、停止を最小化する移行パターン（自動対応／手動再構築）を実務目線で整理します。

まず押さえるべき結論

「Generation 1 + Basic SKU Public IP」をどう扱うかは、実は“Generation”だけで決まりません。ポイントは、VPN Gatewayの「ゲートウェイSKU（Basic / VpnGw1〜5 など）」と「構成（Active-Activeかどうか）」です。ここを取り違えると、移行UIが出ない理由や、取るべき対策がずれてしまいます。

ゲートウェイSKUが「Basic（Basic VPN Gateway）」の場合は、ポータルの移行UI（Migrateタブ）が出ないことが多く、Microsoft側でBasic Public IPの扱いを更新し、自動的にBasic Public IP参照を外す仕組みが案内されています（時期は公式タイムライン参照）。
ゲートウェイSKUが「VpnGw1〜5」（Active-Passive構成）などの場合は、Basic Public IPをStandardへ移行する移行ツール（プレビュー）が提供され、条件を満たすとポータルにMigrateタブが出ます。
どうしても今すぐStandardへ寄せたい場合は、ゲートウェイの作り直し（削除→再作成）が王道です。ただしダウンタイムとPublic IPの変更が発生しやすい点に注意が必要です。

「Basic→StandardのマイグレーションUI」が出ない主な理由

ポータルでMigrateタブが表示されないとき、現場では「Gen1だから移行UIがない」と結論づけがちです。しかし公式ドキュメント上は、Migrateタブはリージョン展開状況や対象SKU/構成に左右される、と説明されています。

よくある原因	起きる現象	確認ポイント	代表的な対処
ゲートウェイSKUが「Basic」	Migrateタブが出ない／移行手順が見つからない	ゲートウェイのSKU表示（Basic / VpnGw…）	公式タイムラインに従い自動対応を待つ、または再作成で上位SKUへ
リージョンで機能が未展開	同じSKUでも環境によってMigrateタブが出たり出なかったりする	別リージョンの同条件ゲートウェイで比較／公式の「利用できない場合」の注記	展開を待つ、または計画メンテで再作成
構成が非対応（例：Active-Active）	移行メニューが出ない、または移行が進まない	Active-Active設定の有無	対応構成へ寄せるか、再作成で構成変更

最初にやること：自分の環境を「どのパターンか」判定する

最短で迷子にならない方法は、以下の3点を同時に押さえることです。

ゲートウェイSKU（Basic / VpnGw1 / VpnGw2…）
ゲートウェイ世代（Generation 1 / Generation 2）
Public IPのSKU（Basic / Standard）

ポータルでの確認（手早く）

Azureポータル → Virtual network gateways → 対象ゲートウェイ → Overview / Configuration を確認
SKUがBasicか、VpnGw系か（ここが分岐の起点）
Public IPがBasicかStandardか
ConfigurationにMigrateタブがあるか

CLIでの確認（運用・棚卸し向け）

運用チームでの棚卸しや、複数サブスクリプション横断での調査では、CLI/スクリプトで「事実」を取りにいくのが安全です。たとえばゲートウェイのJSONを取得して、SKUやGeneration（vpnGatewayGeneration）を確認します。

az network vnet-gateway show -g <リソースグループ> -n <ゲートウェイ名> -o json

出力されたJSON内で、以下のキーを探します（名称はAPI/ツールバージョンで表示形式が変わることがあります）。

sku（例：Basic / VpnGw1 / VpnGw2…）
vpnGatewayGeneration（例：Generation1 / Generation2）
activeActive（true/false）
ipConfigurations → publicIPAddress（Public IPリソースへの参照）

廃止期限は「2026年1月末」なのか？最新の考え方

結論から言うと、「2026年1月末」という案内を見たことがあるという理解自体は不自然ではありません。実際、Microsoftのコミュニティ回答などでは、VPN Gatewayに紐づくBasic Public IPのタイムラインが2026年1月31日に延長された、という説明が見られます。

ただし、VPN Gateway領域はタイムラインが更新されやすく、現在の公式タイムライン（VPN Gatewayの「What’s new」）では、Basic IPのVPN Gateway向けタイムラインが「2026年3月末」へ移動した旨が明記されています。さらに、Basic SKU Gateway向けの「Basic Public IP参照を自動で外す機能」は2026年2月中旬という記載になっています。

つまり実務では、「メールや過去情報で見た期限（例：2026年1月末）に固定しない」ことが重要です。必ず、運用の起点となるドキュメントをVPN Gateway側のタイムラインに寄せ、そこから逆算してメンテ計画・稟議・ベンダー調整を行うのが安全です（タイムラインは変更され得る、と公式にも注記があります）。

Basic Public IPの“扱い”が変わると何が困るのか

Basic Public IPの廃止対応は、単に「IPが使えなくなる」だけではありません。MicrosoftはBasic Public IPリソースの廃止に伴い、Basic VPN Gatewayの構成（Construct）を更新し、Basic Public IP参照がゲートウェイの属性として見えるようになる、と案内しています。

このとき、通信自体は継続しても、次のような“周辺資産”が影響を受けやすくなります。

ARM/Bicep/Terraformで「Basic Public IPリソースID」を固定参照している
監視でPublic IPリソースを監視対象にしている（存在/属性変化でアラート設計が崩れる）
資産台帳で「Public IPリソース＝境界IP」というモデルに依存している

公式にも、スクリプト・テンプレート・監視がBasic Public IPリソースを参照しているなら、Virtual Network Gateway側のIPアドレス情報を参照するよう更新することが推奨されています。

状況別：最適解が一発でわかる対応パターン表

あなたの状況	推奨アクション	ダウンタイム	グローバルIP変更	備考
VpnGw1〜5（Active-Passive）でBasic Public IP	ポータル/PowerShellの移行ツールでStandardへ移行	最大10分程度が想定	原則変わらない	移行はプレビュー。GatewaySubnetの空きIPなど前提あり
Basic VPN Gateway（多くがGen1）でBasic Public IP	公式タイムラインの自動対応を待ちつつ、周辺資産の参照を見直す	原則なし（中断しない前提）	変わらない前提	自動機能の時期は公式の更新を要確認
今すぐStandardに寄せたい／SKUも上げたい	削除→再作成（できればGen2 + AZ SKU）	発生（計画停止必須）	変わる	切り戻し含めた手順書が重要

パターンA：移行ツールでBasic→Standardへ移行できる場合（VpnGw1〜5）

対象に当てはまる場合、「Public IPのSKU移行」と「ゲートウェイSKUのAZ SKU化」が一連で行われる設計です。移行中もIPアドレスは変わらない前提で進み、停止も短時間で済むのが魅力です。

前提条件として要チェックなポイント

Active-Passive構成であること（Active-Activeは対象外）
リージョン展開：Migrateタブが見えない場合、リージョン未展開の可能性
GatewaySubnetに空きIPが少なくとも3つ必要。/28以下だとエラーになることがあるため、必要に応じてプレフィックス追加を検討
ダウンタイムは最大10分程度が想定（実行ステップで短時間停止）

ざっくり手順（ポータルの流れ）

対象のVirtual network gatewayを開き、Configuration付近にMigrateがあるか確認
事前チェック（準備）を実行（環境により数十分かかることがある）
移行（実行）を開始（このタイミングが短時間停止になりやすい）
検証・コミットを実施し、旧Basic Public IPリソースが整理される

パターンB：Basic VPN Gateway（Gen1が多い）でUIが出ない場合

Basic VPN Gatewayは、これまでコスト重視の小規模用途で使われてきた一方、SKU自体の制約も多く、公式にもBasic SKUは直接アップグレードできない旨が明記されています。つまり、SKUを変えるなら削除して作り直すのが原則です。

ただし今回の論点は「SKUを上げたい」だけでなく、「Basic Public IPの廃止にどう追随するか」です。ここについて、公式タイムラインではBasic SKU Gateway向けに、Basic Public IP参照を自動的に取り除く機能が案内されており、さらに実際のIPアドレスは変わらず、接続は中断しない前提で進める旨が記載されています。

このパターンで“今すぐ”やっておくと効くこと

Public IPリソースID直参照をやめる（IaC/監視/運用スクリプト）
「ゲートウェイの接続先として必要なのは“IPアドレス文字列”」という観点で、参照元を整理する
オンプレFWの許可設定、相手装置のピア設定、社内台帳に「どこでIPを見ているか」を棚卸しする

パターンC：自動対応を待たずにStandardへ寄せたい場合（手動の再構築）

「廃止対応に加えて、将来を見据えてGen2へ寄せたい」「Basic SKUの機能制約がつらい」といった理由で、早期に作り直す判断は現実的です。ただし、ここは計画停止と手順の品質がすべてです。

公式にも、アップグレードできないSKU（Basicなど）の場合は、削除して新規作成となり、ダウンタイムとPublic IP変更、そしてオンプレ機器やP2Sクライアントの再設定が必要になると書かれています。

手動再構築の標準手順（実務テンプレ）

現状の設定を退避
接続（S2S/VNet-to-VNet/P2S）、共有キー、BGP有無、カスタムIPsec/IKEポリシー、ルート（UDR/伝播）、証明書やアドレスプールを整理します。
メンテ時間の確保と関係者調整
オンプレNW担当（FW/ルータ/回線）と「切断→再接続」の作業窓を合意します。
既存ゲートウェイの削除（必要に応じて接続から先に）
削除中はVPNが停止します。
新しいVPN Gatewayを作成
可能ならGeneration 2 + Standard Public IP、かつ将来の運用を考えるとAZ SKU系（例：VpnGw2AZなど）を検討します（要件とコストで決定）。
接続の再作成
オンプレ側に新しいピアIP（新ゲートウェイのPublic IP）を設定し直し、共有キー等を合わせます。
疎通確認と監視復旧
トンネルUPだけでなく、業務通信（TCP/UDP/ICMP）、経路（BGP/静的）、名前解決、必要ならフェイルオーバーも確認します。

ダウンタイムをさらに抑えたいときの考え方

同一VNetにVPN Gatewayを同時に2つ置けない制約があるため、「完全無停止の入れ替え」は簡単ではありません。その代わり、

別VNetに新ゲートウェイを並行構築し、Hub-Spokeや一時的なルーティングで切替手順を作る
オンプレ側でピアを追加できる装置なら、段階的に切替できる設計に寄せる

といった“設計でダウンタイムを縮める”方向性が現実解になります（この方法は環境依存が強いので、ネットワーク設計者と一緒に詰めるのが安全です）。

Basic→Standard移行で見落としがちな「Public IP単体アップグレード」の罠

Public IP単体のアップグレード（Basic→Standard）は、一般には「IPは維持される」「ただし関連付け解除が必要」といった手順で説明されています。しかし、公式ドキュメントではPublic IPをアップグレードするには、そのIPがどのリソースにも関連付いていないことが条件と明記されています。VPN Gatewayはまさに“関連付いている”ため、ここが罠になります。

このためVPN Gatewayについては、Public IP単体のアップグレード手順ではなく、VPN Gateway用の移行ガイダンス（移行ツール、または自動対応/再構築）に乗る必要があります。一般のガイダンス側でも、VPN Gatewayは「VPN Gateway migration guidance」に従うよう整理されています。

棚卸しを一気に終わらせる：Resource Graphで「Basic Public IPを使うVPN Gateway」を洗い出す

複数のサブスクリプションや多数のゲートウェイがある場合、手作業だと抜け漏れが出ます。Azure Resource Graphで“ゲートウェイ→紐づくPublic IP→SKU/実IP”を引いて台帳化すると、移行計画が一気に現実になります。

Resources
| where type =~ 'microsoft.network/virtualnetworkgateways'
| extend pipId = tostring(properties.ipConfigurations[0].properties.publicIPAddress.id)
| project gwName=name, location, gwSku=tostring(sku.name), gwGen=tostring(properties.vpnGatewayGeneration), pipId
| join kind=leftouter (
    Resources
    | where type =~ 'microsoft.network/publicipaddresses'
    | project pipId=id, pipSku=tostring(sku.name), publicIp=tostring(properties.ipAddress)
) on pipId
| project gwName, location, gwSku, gwGen, pipSku, publicIp

将来的にBasic VPN Gatewayでは“Public IPがリソースではなく属性として扱われる”方向性が示されているため、台帳・監視のモデルも「Public IPリソースありき」から段階的に外していくと安全です。

運用チェックリスト

チェック項目	なぜ重要か	確認のコツ
ゲートウェイSKU（Basic / VpnGw…）	移行ツール対象か、待機か、再構築かが決まる	ポータルOverview、またはCLIでJSON確認
Active-Activeかどうか	移行ツールの対象外になるケースがある	Configurationの設定値
GatewaySubnetの空きIP	移行ツールで前提条件になる	サブネットサイズと使用状況を確認（少なくとも空き3）
オンプレ装置側のピア定義	IPが変わる手順（再構築）では確実に作業が発生	FW/ルータ設定、許可リスト、NAT有無
IaC/監視でPublic IPリソースIDを参照していないか	“IPは同じでも参照の仕方”が変わると壊れる	テンプレート内のpublicIPAddresses参照を検索

よくある質問

移行でグローバルIPは変わりますか？

移行ツールを使う場合、ゲートウェイのIPは変わらない前提で説明されています。一方、削除→再作成の手動移行では、IPが変わることが明記されています。

移行時にVPNは止まりますか？

移行ツールでは、停止は短時間（最大10分程度）とされています。Basic SKU Gateway向けの自動対応については「接続は中断しない」前提で案内されています。

結局、Generation 1はStandard Public IPへどうアップグレードするの？

Generation 1という“世代”そのものよりも、ゲートウェイSKUで分岐します。

VpnGw1〜5など対象SKUなら、移行ツールでBasic→Standardへ移行できる可能性があります（条件とリージョン展開次第）。
Basic VPN Gatewayなら、公式タイムライン上は自動対応が案内されており、周辺資産の参照を先に整えるのが現実的です。
どうしても早期にStandardへ寄せるなら、削除→再作成で設計ごと更新する（停止とIP変更に注意）。

まとめ

「移行UIが出ない＝Gen1だから」と決め打ちせず、ゲートウェイSKUと構成で整理するのが最短ルート。
期限は更新されやすい。過去に見た「2026年1月末」情報はあり得るが、現在の公式タイムラインでは2026年3月末や2026年2月中旬といった記載があるため、運用は公式ドキュメントに追随する。
待てるなら、周辺資産（IaC/監視/台帳）の参照を先に修正しておくのが最も費用対効果が高い。
早期移行したいなら、削除→再作成を前提に、オンプレ側も含めた切替手順と検証計画を作る。

この記事を書いた人

佐藤健司

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

Azure VPN Gateway（Generation 1）でBasic Public IPを使う場合の廃止対応とStandard移行手順（期限・自動対応・再構築）

まず押さえるべき結論

「Basic→StandardのマイグレーションUI」が出ない主な理由