Azure VPN GatewayでBasicパブリックIP（動的）をStandardへ移行しようとすると、公式ドキュメントとAzureポータルの画面表示が一致せず「Prepare new Standard IP resources」「Third IP configuration」に戸惑いがちです。本記事では、画面差分が起きる理由、具体的に何をすべきか、IP維持やP2S影響、期限の考え方まで実務目線で整理します。
症状：ドキュメントとポータルが違う「Prepare new Standard IP resources」
Microsoft Learnの移行ガイドに沿って作業しているのに、ポータル上では次のようなメッセージが出て手が止まるケースがあります。
- 「準備中はゲートウェイに対して変更を行うことはできません。」
- 「Third IP configuration（3つ目のIP構成）」
- さらに、ドロップダウンで「Standardの未割り当てパブリックIP」を選ぶよう求められる
結論から言うと、これは「手順が間違っている」よりも、移行ウィザードが環境条件（ゲートウェイSKU、Active-Active/Active-Passive、機能のロールアウト状況）で分岐していることが原因である場合がほとんどです。移行の成否と安全性は、どの“種類”を移行しているのかを正しく切り分けると一気に見通しが良くなります。
まず整理：移行対象は「Public IPのSKU」なのか「VPN GatewayのSKU」なのか
今回の話題は「VPN Gatewayを作り直す」ではなく、VPN Gatewayに紐づくパブリックIP（Public IP Addressリソース）のSKUをBasic→Standardへ移行することが本筋です。ここを混同すると、IPが変わる/変わらない、追加IPが必要、などの判断がブレます。
| よく混同される項目 | 例 | 今回の論点 |
|---|---|---|
| Public IPのSKU | Basic / Standard | 移行対象。Basicはリタイア方針のためStandardへ |
| 割り当て方式 | Dynamic / Static | Standardは静的が前提。移行機能を使う場合は「IP文字列」を維持したままSKUだけ変える |
| VPN GatewayのSKU | Basic / VpnGw1〜5 / (Legacy) Standard・HighPerf など | 移行手順・提供状況が変わる。SKUによってポータルの分岐が起きやすい |
| 冗長構成 | Active-Passive / Active-Active | 画面差分の大きな要因。「Third IP configuration」が出やすい |
より新しい/詳しい一次情報はどこ？
結論として、次の3つを“最新の一次情報”として押さえると迷いが減ります（いずれもMicrosoft Learn上の公式情報です）。
- 「How to migrate a Basic SKU public IP address to Standard SKU for VPN Gateway – Preview」（移行手順）
- 「About migrating a Basic SKU public IP address to Standard SKU – Azure VPN Gateway」（仕様・FAQ）
- 「What’s new in Azure VPN Gateway?」（提供時期・ロールアウト・期限の更新）
特に「What’s new」は更新が入りやすく、“期限が延びる/短くなる”“Active-Active対応の時期が動く”といった情報が反映されます。なお、これらのタイムラインは変更され得る旨が明記されています。
IPは維持できる？結論と注意点
Microsoftが提供する移行機能（ポータルのMigrateタブ等）を使う限り、VPN Gatewayに割り当てられているIPアドレス（文字列）は変わらない、と公式に案内されています。逆に、手動で削除→再作成を選ぶとIPは変わります。
- 移行機能を使う：IPは変わらない
- ゲートウェイを削除して作り直す：IPは変わる（＝パートナー/クライアント側の設定変更が必須）
この「どの方法を選ぶか」が、パートナー接続やP2Sへの影響を決める最大要因です。
「Prepare new Standard IP resources」ステップで具体的にやること
このステップは名前のとおり、StandardパブリックIPへの移行に必要な“新しいStandard側のリソース”を裏側で準備するフェーズです。準備中はポータル上に「変更できない」旨が表示されます。ここで慌ててブラウザ更新や別設定を触るより、準備が完了するまで待つのが基本です。
事前に確認したい前提条件（ここで詰まりやすい）
- GatewaySubnetに十分な空きIPがあること（少なくとも3つの未使用アドレスが必要と案内されています）
- リージョンによっては移行機能が未提供で、ポータルにMigrateタブが出ない場合がある
GatewaySubnetが/28以下などで空きが不足すると、検証（Validation）で止まったり、Prepareが失敗することがあります。必要に応じてGatewaySubnetへ追加プレフィックスを付与する、といったネットワーク側の準備が先に必要です。
ポータルで「Standardの未割り当てパブリックIP」を求められた場合の手順
画面によっては、Prepareの前後で「未割り当てのStandardパブリックIP」を選択するUIが出ます。これは移行処理のために一時的に利用する“プレースホルダー（仮のStandard Public IPリソース）”として要求されます。
- Azureポータルで「パブリックIPアドレス」を開く
- 新規作成で、SKUをStandard、IPバージョンをIPv4、割り当てを静的として作成する
- 作成したStandard Public IPがどのリソースにも関連付いていない（未割り当て）状態であることを確認する
- VPN Gatewayの移行ウィザードのドロップダウンで、その未割り当てIPを選択する
- Prepareの完了を待つ（準備中はゲートウェイの変更がブロックされる）
重要なのは、ここで選ぶStandard Public IPは「移行中に使う仮の器」であり、パートナーが参照している“現在のVPN GatewayのグローバルIP”を置き換えるためのものではないという点です。
「Third IP configuration」とは何か？なぜ3つ目が出てくるのか
「Third IP configuration」は、特にActive-Active構成で表示されやすい文言です。Active-Activeではゲートウェイのインスタンスが複数になり、IP構成も複数になります。移行処理ではStandard側の構成へ安全に切り替えるために、裏側で追加のIP構成を確保する動きが入り、その結果として「3つ目」と表示されることがあります。
ここで誤解しやすいポイントは次の2つです。
- 「Third IP configuration」と表示されても、いきなり本番の接続先IPが差し替わるという意味ではない
- 求められる「未割り当てStandard IP」は、移行プロセス上の一時リソース（プレースホルダー）として使われる場合がある
つまり、表示上は“新しいIPを足す”動きに見えても、移行完了後にパートナーへ提示しているIPがそのまま維持される設計になっています。
なぜ追加のIPが必要に見えるのに「IPは変わらない」と言えるのか
ここが一番の混乱ポイントです。整理すると、移行の対象は「IPアドレスの文字列」ではなく、そのIPを保持している“Public IPリソースのSKU（Basic→Standard）”です。
移行機能では、次のような“安全策”が組み込まれていると考えると理解しやすくなります。
- いきなり本番IPの器を壊さず、Standard側の器を先に準備する（＝Prepare）
- 移行中は変更をロックして状態を固定する（＝「準備中は変更できない」）
- 検証（Validate）フェーズでトンネル疎通を確認してから確定（Commit）する
- 問題があれば中止（Abort）でロールバックできる
実際、公式手順では「Prepare → Migrate → Validate/Commit」という3段階のワークフローが説明され、移行中のダウンタイム（最大10分程度）や、失敗時のAbort（ロールバック）も明記されています。
期限の整理：2025年9月30日を過ぎたら即停止？
Basic Public IPの“リタイア日”としてよく引用されるのが2025年9月30日です。公式ガイダンスでは、この日付以降、Basic SKU Public IPはリタイア扱いとなり、Standardへの移行が推奨されています。一方でFAQには、2025年9月30日以降も一定期間は動作し続ける（ただしサポート外・SLA対象外）という説明もあります。
そしてVPN Gatewayは、一般のPublic IPとは事情が少し違います。VPN Gateway向けの移行ツール提供状況やタイムラインは「What’s new in Azure VPN Gateway?」に集約されており、VPN GatewayとしてのBasic IP期限が延長されている旨が記載されています（“End of Mar 2026”など）。
なお、過去のQ&A回答や古い記事では「2026年1月末まで」と記載されていることがありますが、公式の更新で前後する可能性があります。“最終判断は最新のWhat’s new”という運用にしておくと、情報の揺れに強くなります。
| 論点 | 押さえるべきポイント | 実務上のアクション |
|---|---|---|
| 2025年9月30日 | Basic Public IPはリタイア扱い。以降も動作するケースはあるが、サポート/SLA面のリスクが増える | まずは棚卸し（Basic IPがどこで使われているか）→順次Standard化 |
| VPN Gatewayの期限 | VPN Gatewayは個別にタイムラインが更新され得る。公式「What’s new」で延長やロールアウト状況を確認 | 移行可能になったリージョンから計画的に実施。Active-Activeは提供時期がずれる可能性を見込む |
| 移行に伴う停止 | 顧客主導の移行では最大10分程度のダウンタイムが想定される | メンテナンス枠を確保し、パートナー/社内へ事前周知 |
パートナー接続（Site-to-Site）でIPを失う可能性は？
パートナー企業とのS2S接続では「相手側が許可している接続元IP」を変更できない/変更に時間がかかることが多く、IP維持は最優先事項です。ここは公式見解としても、Microsoft提供の移行プロセスに従う限りIPは維持されると案内されています。
ただし実務では、次の“事故”がIP変更につながりやすいので要注意です。
- 移行ではなく、誤ってVPN GatewayやPublic IPリソースを削除してしまう
- ドキュメントとは別の手順（手動での作り直し）に切り替えてしまう
- IaC/スクリプトが「Public IPリソースID」を参照しており、移行後に参照先が変わって監視/自動化が誤作動する
特に最後の「参照のズレ」は盲点です。What’s newには、Basic IPリソース参照を使っているテンプレートや監視は、今後はゲートウェイのIPアドレスプロパティ参照に更新する必要がある旨も示されています。
Point-to-Site（P2S）構成への影響はある？
P2Sはクライアント（Azure VPN ClientやネイティブVPN）側が「接続先（サーバーアドレス）」としてVPN GatewayのPublic IP（またはFQDN）を参照します。そのため、もしIPが変わればクライアント設定の更新が必要になります。
しかし、Microsoft提供の移行機能を使う前提ではIP自体は変わらないため、P2Sの“宛先変更”は基本的に不要です。影響が出るとすれば次の2点です。
- 移行中のダウンタイムで、一時的に切断される（再接続が必要）
- 万一、手動再作成などでIPが変わった場合は、全クライアントの接続先更新が必要
つまり、P2S観点でも「移行機能を使う」「削除→再作成をしない」が鉄則です。
よくある質問（FAQ）
この移行に関する、より新しい／詳しい手順書はあるのか？
あります。Microsoft Learnの「How to migrate…（移行手順）」「About migrating…（仕様/FAQ）」に加え、提供時期や期限は「What’s new in Azure VPN Gateway?」が最も更新頻度が高い一次情報です。
「Prepare new Standard IP resources」ステップで、具体的に何をすれば良いのか？
基本は、Prerequisitesを満たしたうえでPrepareを実行し、完了を待ちます。画面で未割り当てStandard Public IPの指定を求められる場合は、事前に作成した未割り当てStandard Public IPを“プレースホルダー”として選択します。
移行後も、現在のVPN GatewayのパブリックIPアドレスはそのまま維持されるのか？
Microsoft提供の移行機能を使う限り、維持されると公式に案内されています。手動でゲートウェイを削除して作り直す方法はIPが変わるため、パートナー接続がある環境では避けるのが安全です。
2025年9月30日までに移行しないと、VPN Gateway に影響が出るのか？
一般論としては、Basic Public IPは2025年9月30日でリタイア扱いです。ただし、公式FAQでは“直後に一斉停止”という形ではなく、移行猶予（ただしサポート外）に触れています。VPN Gatewayはさらに個別タイムラインが示され、公式「What’s new」で期限延長が明記されています。
パートナー企業との接続に使っているIPを失う可能性はあるのか？
移行機能を正しく使う限り「IPを失う（変わる）」可能性は低いです。主なリスクは、削除→再作成をしてしまう、誤って関連リソースを消してしまう、など運用上の事故です。作業前にIPを控え、検証→確定（Commit）の手順を踏むことで安全性が上がります。
ポイント対サイト（P2S）構成への影響はあるのか？
移行機能でIPが維持される前提では、P2Sクライアントの接続先変更は基本不要です。影響は「移行中の一時切断」と考えるのが現実的です。もし手動再作成でIPが変わった場合のみ、すべてのクライアント設定更新が必要になります。
ウィザードで「Standard の未割り当てパブリックIP」を選ぶよう求められるが、なぜ追加のIPが必要なのか？
そのStandard Public IPは、移行処理を進めるための“仮の器（プレースホルダー）”として使われる場合があります。見た目はIP追加に見えますが、Microsoft推奨の移行では、最終的にパートナーが参照しているIPが置き換わる設計ではありません。
実務的な進め方：現場で安全にやるためのチェックリスト
“画面の違い”に翻弄されず、事故なく終わらせるための実務チェックをまとめます。
着手前（計画フェーズ）
- VPN GatewayのSKU、構成（Active-Active/Active-Passive）、Public IPのSKU/割り当て方式を記録
- 現在のVPN Gateway Public IP（パートナーに提示しているIP）を控える
- 接続しているS2S（Local Network Gateway/Connection）と、P2S方式（証明書/Entra ID/OpenVPN/IKEv2など）を棚卸し
- GatewaySubnetのプレフィックス長と空きIP数を確認（不足するなら先に対処）
- メンテナンスウィンドウを確保（最大10分＋検証時間）
- 可能なら検証用VNet/検証用VPN Gatewayで同様の手順を先に試して挙動を確認
実行フェーズ（ポータル移行の流れ）
- VPN Gateway → 設定（Configuration）→（あれば）Migrateタブを開く
- Prerequisites/Validationでエラーがないことを確認（問題があれば先に解消）
- Prepareを実行（画面で未割り当てStandard IPを求められたら事前作成したものを指定）
- Prepare完了後にMigrateを実行（この間は変更不可、短時間の切断が発生し得る）
- Validateで疎通確認（トンネルのIngress/Egress、接続状態、ログ）
- 問題なければCommitで確定。問題があればAbortでロールバック
Validate/Abort/Commitの考え方を知っておくと、心理的にも安全に進められます。
実施後（必ずやる確認）
- VPN GatewayのPublic IPが移行前と同一であること（最重要）
- パートナーとのS2Sトンネルが復旧し、双方向疎通できること
- P2Sクライアントが再接続できること
- 監視/自動化がPublic IPリソースID参照に依存していないか（依存しているなら更新計画）
よくあるつまずきと対処
| 現象 | ありがちな原因 | 対処 |
|---|---|---|
| Migrateタブが出ない | 機能がリージョンへ未ロールアウト、または対象外SKU/構成 | 「What’s new」で提供状況を確認。ロールアウト待ち/別経路を検討 |
| Prepareで止まる/検証が失敗 | GatewaySubnetの空きIP不足（/28以下等） | 追加プレフィックス付与などで空きを確保してから再実行 |
| 未割り当てStandard IPが一覧に出ない | Standard IPを作っていない、または何かに関連付いている | 同一リージョンで未割り当てのStandard Public IPを新規作成 |
| Third IP configurationと表示され不安 | Active-Active等の分岐で追加構成を確保している | プレースホルダーIPを指定して進める。移行後IPが維持される前提を理解 |
「画面がドキュメントと違う」だけで引き返すのではなく、上表の観点で要因を切り分けると、作業が前に進みます。
まとめ
- 「Prepare new Standard IP resources」はStandard移行のためのバックエンド準備フェーズで、準備中はゲートウェイ変更がロックされる
- ウィザードで求められる「未割り当てStandard Public IP」は、移行処理用のプレースホルダーとして使われることがあり、本番IPを置き換える意図ではない
- Microsoft提供の移行機能を使えば、VPN GatewayのIPは維持され、パートナー接続やP2Sの宛先変更は基本不要
- 削除→再作成を選ぶとIPは変わるため、IP固定が必要な環境ほど移行機能を優先
- 期限や提供状況は更新され得るため、「What’s new」を定期的に確認し、メンテナンス計画に落とし込む
コメント