Azure App Service の Premium v3（P2v3）で動いている Linux Web アプリを Premium v4 に上げたいのに、ポータルの「スケールアップ」で v4 が選べない……。本記事では、その原因となる「デプロイメント ユニット（スケールユニット）」の仕組みと、West Europe / Linux 環境での具体的な移行手順、Linux で Clone app が使えない場合の現実的な対処方法まで、実運用を想定して詳しく解説します。
問題の全体像：West Europe の P2v3 → Premium v4 に上げられない
まず、今回の前提条件を整理します。
| 項目 | 現状 | 理想（やりたいこと） |
|---|---|---|
| リージョン | West Europe | 同じく West Europe |
| App Service Plan | Premium v3 P2v3 | Premium v4（例：P2v4） |
| OS | Linux（コード／コンテナ） | Linux のまま |
| 操作 | 「スケールアップ（App Service プランの変更）」 | Premium v4 SKU を選択したい |
| 症状 | Premium v4 の SKU（P0v4〜）が表示されない、または選択できない | ポータルからシームレスに v4 へアップグレードしたい |
結論から言うと、この状況では「同じ App Service Plan のまま Premium v3 → v4 へスケールアップすることはできません」。
理由は、現在の App Service Plan が属している「デプロイメント ユニット（スケールユニット / webspace）」が Premium v4 非対応だからです。Premium v4 はリージョン単位ではなく、「リージョン内の一部のデプロイメント ユニット」でのみ利用可能な SKU として提供されています。
なぜ Premium v4 が選べないのか：デプロイメント ユニット（webspace）の仕組み
Azure App Service は、同じリージョン内でも複数の「デプロイメント ユニット（webspace）」に分かれて運用されています。公式ドキュメントでは、次のようなポイントが説明されています。
- App Service Plan は、作成されたリージョン内のいずれかのデプロイメント ユニットに割り当てられる。
- 同じ リソース グループ + リージョン + OS 種別 の組み合わせで作成された App Service Plan は、同じデプロイメント ユニットに配置される。
- 各デプロイメント ユニットがサポートする SKU は異なり、Premium v4 に対応していないユニットも存在する。
つまり、次のような関係になります。
| 状況 | 意味するところ |
|---|---|
| スケールアップ画面に Premium v4 が出てこない／グレーアウトしている | その App Service Plan が属するデプロイメント ユニットが Premium v4 をサポートしていない |
| 同じ RG・リージョン・OS で新しいプランを作る | 同じデプロイメント ユニットに配置されるため、やはり Premium v4 にスケールアップできない |
| 新しい RG で Premium v4 の App Service Plan を作る | Premium v4 対応ユニットに乗る確率が高く、実際に v4 SKU を選択できる |
この仕組みのため、「スケールアップ画面に Premium v4 がそもそも出てこない」場合は、その App Service Plan は構造的に Premium v4 に上げられない と判断できます。
Linux アプリと「Clone app」機能の現状
Windows アプリの場合、Azure ポータルの [開発ツール] > [Clone app] を使うことで、設定やスロット、証明書などをまとめて複製し、別の App Service Plan への移行をかなり楽にできます。
一方で、Linux アプリに対する Clone app のサポートは限定的で、Windows のようにフルサポートされていません。Microsoft Q&A でも、Windows では Clone app で対応できる一方、Linux の場合は「新しい App Service Plan を作って手動で構成をコピーする」ことが案内されており、Clone app の Linux 対応については公開された ETA は提示されていません（2025 年 9 月時点）。
| 項目 | Windows アプリ | Linux アプリ |
|---|---|---|
| Clone app のサポート状況 | ポータルから利用可能。構成・スロット・証明書などをまとめて複製可能。 | 制限が多く、実運用では「手動移行（IaC / スクリプト等）」が前提。 |
| Premium v3 → v4 移行時の使い勝手 | Clone app を使うことで、新しい Premium v4 プランへのコピーが比較的容易。 | 同等のことを自前で再現する必要がある（設定コピー、スロット再作成など）。 |
したがって、Linux アプリの Premium v4 への移行は手動前提 と割り切り、移行時に人手でやるべきタスクを洗い出しておくことが重要です。
正しい解決策：Premium v4 対応ユニット上に新しい App Service Plan を作成する
ここまでの整理から、解決策は次の 1 パターンに収束します。
- Premium v4 に対応しているデプロイメント ユニット上に、別の App Service Plan（Premium v4）を作成し、そこへアプリを移行する。
より具体的には、次のような流れになります。
- （推奨）新しいリソース グループを作成する。
- West Europe × Linux × Premium v4 で 新しい App Service Plan を作成する。
- そのプラン上に 新しい Web App（Linux） を作成する。
- アプリ設定・接続文字列・ネットワーク・証明書・カスタム ドメインなどを移行する。
- コード／コンテナ イメージをデプロイし、新環境で動作を検証する。
- DNS 切り替えや外部接続設定の更新を行い、本番トラフィックを新環境に寄せる。
- 問題がなければ旧環境を縮退・削除する（一定期間はロールバック用に残しておく）。
以降では、この一連の手順をもう少し掘り下げて解説します。
手順詳細：West Europe / Linux アプリを Premium v4 へ移行する
事前確認：Premium v4 がリージョンと SKU として利用可能か
まず、West Europe で Premium v4（Linux）がサポートされているかを確認します。Premium v4 自体は多くのリージョンで利用可能ですが、プレビュー → GA のフェーズで利用可能リージョンが徐々に拡大しているため、最新の情報を確認するのが安全です。
Azure CLI を使うと、Linux 向け Premium v4 の利用可能リージョンを確認できます。
# Linux 向け Premium v4（例：P1v4）の利用可能リージョン一覧
az appservice list-locations --linux-workers-enabled --sku P1V4
ここで West Europe が含まれていれば、Premium v4 自体はそのリージョンで使える、ということになります。
ステップ 1：新しいリソース グループを作成する
既存の App Service Plan と同じ リソース グループ + リージョン + OS で新規プランを作ると、同じデプロイメント ユニットに配置されて Premium v4 が使えない、という状況が再現されてしまいます。
そのため、新しいリソース グループを用意することが推奨されます。
az group create \
--name rg-webapp-pv4-west-europe \
--location westeurope
ステップ 2：Premium v4 の App Service Plan（Linux）を作成する
次に、新しいリソース グループ内で Premium v4 の App Service Plan を作成します。
az appservice plan create \
--name asp-webapp-p2v4-linux \
--resource-group rg-webapp-pv4-west-europe \
--location westeurope \
--sku P2V4 \
--is-linux
このプランは Premium v4 対応のデプロイメント ユニット上に作成されるため、後から P2v4 以外の v4 SKU へのスケールアップ／スケールダウンも可能になります。
ステップ 3：新しい Web App（Linux）を作成する
新しい App Service Plan 上に、Linux Web App を作成します。ここではランタイム スタックは仮のものとし、後でコンテナやアプリをデプロイし直す想定です。
az webapp create \
--name my-webapp-on-pv4 \
--resource-group rg-webapp-pv4-west-europe \
--plan asp-webapp-p2v4-linux \
--runtime "PYTHON:3.12"
コンテナ利用の場合は、--deployment-container-image-name で既存イメージを指定して作成しても構いません。
ステップ 4：アプリ設定・構成項目を移行する
次に、旧環境の設定や構成を新環境へ移行します。Linux では Clone app でまとめて移行できないため、以下の観点で 1 つずつ移していきます。
| 項目 | 具体例 | 移行のポイント |
|---|---|---|
| アプリ設定 / 環境変数 | 接続文字列、API キー、フラグ、バージョン設定など | ポータルの JSON エクスポート、または ARM/Bicep/Terraform から再利用するとヒューマンエラーを減らせる。 |
| マネージド ID（システム / ユーザー割り当て） | Key Vault、Storage、SQL などへのアクセス | 新 Web App でもマネージド ID を有効化し、必要なロール割り当て・アクセス ポリシーを追加し直す。 |
| Key Vault 参照 | @Microsoft.KeyVault(SecretUri=...) 形式の設定 | 新しいマネージド ID に対して Key Vault 側で権限を再付与する。 |
| 証明書・カスタム ドメイン | 独自ドメイン、SNI バインド、App Service 証明書 | 新 Web App に再バインドが必要。場合によってはドメイン所有確認や Key Vault 連携の再承認が発生する。 |
| デプロイ スロット | staging / blue-green 環境 | スロットは自動では移行されないため、新環境側で同名スロットを作成し、構成を同期する。 |
| スケール設定 | 自動スケール ルール、インスタンス数 | Premium v4 プラン側で、旧環境と同等のスケール設定を再作成する。 |
| ネットワーク関連 | VNet 統合、アクセス制限、Private Endpoint、サービス エンドポイントなど | 新 Web App に対して再設定が必要。特に VNet 統合はサブネットの空き容量に注意。 |
IaC（ARM/Bicep/Terraform）やスクリプトで構成をコード化している場合は、テンプレートを Premium v4 向けに調整して再デプロイする方が安全で再現性も高くなります。
ステップ 5：コード／コンテナ イメージをデプロイして検証する
設定が移行できたら、新しい Web App に対してアプリをデプロイします。
- コードベースの場合：GitHub Actions / Azure DevOps / Zip Deploy / Oryx など、既存パイプラインを新 Web App に向ける。
- コンテナの場合：コンテナ レジストリ（ACR / Docker Hub など）に同じイメージを用意し、新 Web App 側からの Pull を確認する。
テスト環境を別 URL のまま用意しておけるのが、新規プラン移行の大きなメリットです。本番切り替え前に、次のような観点で十分に検証しましょう。
- アプリの基本動作（主要な画面・API）
- 外部サービス連携（DB、メッセージ キュー、外部 API 等）
- 認証・認可（Entra ID / OpenID Connect / OAuth2 等）
- ログ出力・監視（Application Insights, Log Analytics 等）
ステップ 6：DNS 切り替えと Outbound IP の考慮
新環境での動作に問題がなければ、本番トラフィックを新しい Premium v4 環境へ切り替えます。
DNS 切り替え
- 事前に DNS レコード（CNAME / A / TXT）の TTL を短くしておくと、切り替え時のダウンタイムを最小化しやすくなります。
- カスタム ドメインを新 Web App にバインドし、所有確認が必要な場合は TXT レコードを追加します。
- 検証済みのところで、本番用の CNAME / A レコードを新 Web App に向けて切り替えます。
Outbound IP の変更と Premium v4 の仕様
App Service から外部サービス（ファイアウォールで IP 制限された DB や API など）へ接続している場合、Outbound IP の変更が大きな注意点になります。
- 旧環境（Premium v3）と新環境（Premium v4）では、Outbound IP アドレスが異なります。
- Premium v4 は仕様上、従来のような「安定した Outbound IP」を提供しません。ポータルでも Outbound IP は「Dynamic」と表示され、ARM/CLI からも固定値は返ってこない挙動になっています。
- Premium v4 上のアプリで安定した送信元 IP が必要な場合は、Azure NAT Gateway を使って固定の Outbound IP を提供する構成が推奨されます。
外部サービス側で IP アドレスの許可リストや WAF 設定を行っている場合は、新環境の Outbound 経路（NAT Gateway を含む）を事前に許可しておくことが重要です。
ステップ 7：旧環境の縮退・削除
切り替え後、一定期間（数日〜数週間）は旧環境を残しておくと、問題発生時にロールバックしやすくなります。
- 切り戻し方針（DNS を戻す、旧 Web App を再度有効化する等）をあらかじめ決めておく。
- 問題がなければ、旧 Web App と旧 App Service Plan を順次削除し、ランニング コストを削減する。
この期間は Premium v3 と Premium v4 の両方に課金が発生するため、コストの二重化を許容する期間をあらかじめ決めておくと、予算管理上のトラブルを避けられます。
Azure ポータルで作業する場合のイメージ
Azure CLI ではなくポータルを使う場合の流れを、ざっくりと整理しておきます。
- [リソース グループ] で新しい RG を作成（例：
rg-webapp-pv4-west-europe）。 - [App Service プラン] > [作成] から、Linux / West Europe / Premium v4 を選んで新プランを作成。
- [App Service] > [作成] で、新しい Web App（Linux）を作成し、上記の Premium v4 プランを指定。
- 旧 Web App の [構成]・[TLS/SSL 設定]・[カスタム ドメイン]・[ネットワーク] を参照しながら、新 Web App 側に同様の設定を再現。
- パイプラインや手動デプロイでコード／コンテナを新 Web App に配備。
- ステージング URL で検証後、DNS を切り替え。
Linux アプリでは、[開発ツール] > [Clone app] に頼らず、上記のような「新 Web App への構成コピー」を手作業または IaC で行うのが基本になります。
移行時にチェックすべきポイントと落とし穴
チェックリスト（抜け漏れ防止用）
| チェック項目 | 確認内容 |
|---|---|
| リージョン / OS | 新旧ともに West Europe / Linux であることを確認。 |
| Premium v4 利用可否 | スケールアップ画面で Premium v4 が選べる、または CLI でリージョンが対応していることを確認。 |
| リソース グループ | Premium v4 プランは新しい RG に作成しているか。 |
| アプリ設定・接続文字列 | すべて新 Web App にコピーされているか。機密情報は Key Vault 参照などで管理できているか。 |
| マネージド ID | 新 Web App のマネージド ID に必要な RBAC / ポリシーが付与されているか。 |
| Key Vault 参照 | 参照エラーが出ていないか、シークレットのバージョン固定の有無を確認。 |
| 証明書・カスタム ドメイン | SNI バインドやドメイン検証が完了しているか。 |
| デプロイ スロット | 必要なスロットが新環境に作成済みで、構成が同期されているか。 |
| ネットワーク | VNet 統合、アクセス制限、Private Endpoint の設定が旧環境と同じ振る舞いになっているか。 |
| Outbound IP | 外部サービスの IP 許可リストが、新しい経路（Premium v4 / NAT Gateway）に対応しているか。 |
| 監視・アラート | Application Insights / Log Analytics / アラート ルールが新 Web App にも適用されているか。 |
よくある落とし穴
- コストの二重化 移行期間中は旧 P2v3 プランと新 Premium v4 プランの両方が課金対象になります。計画的に移行期間を決めずに進めると、想定以上のコストが発生することがあります。
- Outbound IP の変更による接続エラー ファイアウォールや WAF、外部 DB / API の IP 許可リストを更新し忘れると、本番切り替え後にだけ接続エラーが出る、といった事象が起こります。Premium v4 は安定した Outbound IP を提供しないため、NAT Gateway などを併用する設計を検討してください。
- 証明書の再バインド忘れ カスタム ドメインと TLS 設定を移し忘れると、HTTPS が無効になったり、証明書エラーが出たりします。特に App Service マネージド証明書や Key Vault にある証明書を使っている場合は、再承認が必要になるケースがあります。
- スロットの移行を失念 staging スロットを前提にした運用フロー（blue-green デプロイなど）がある場合、新環境でも同じスロット構成を再現しないと、リリース プロセスが一時的に停止してしまいます。
FAQ：Premium v3 → v4 移行でよくある疑問
Q. 既存の App Service Plan を別のプランに移せば、Premium v4 が使えるようになりますか？
A. App Service Plan 自体は他のプランへ移動できません。移動できるのは「アプリ（Web App）」だけです。また、アプリを別プランへ移す場合も、同じリソース グループ・リージョン・OS の組み合わせでしか移動できず、結果的に同じデプロイメント ユニットの中でしか動かせません。Premium v4 非対応のユニットからは抜け出せないため、新しい RG に Premium v4 プランを作成して、そこへ移行するのが現実的な解となります。
Q. 一度 Premium v4 対応ユニットでプランを作れば、あとからスケールダウンしても大丈夫ですか？
A. はい。Premium v4 対応ユニット上に作成された App Service Plan であれば、必要に応じて一時的に別の SKU にスケールダウンし、後から再び Premium v4 へ戻すことができます。Microsoft の Q&A やドキュメントでも、「Premium v4 対応ユニットに乗せること」が重要で、その後のスケールアップ／ダウンは柔軟に行えると説明されています。
Q. Premium v4 にすると、パフォーマンス面でどんなメリットがありますか？
A. Premium v4 は、最新の Dadsv6 / Eadsv6 シリーズ VM と NVMe ベースの一時ディスクを採用しており、Premium v3 に比べて CPU・メモリ・ストレージ性能が大きく向上しています。Microsoft の公式アナウンスでは、従来の Premium v3 と比べて 25〜50％ 程度の性能向上が期待できるとされています。 高負荷な Web アプリや API、コンテナベースのアプリでは、より少ないインスタンスで同等以上のスループットを得られる可能性があります。
Q. Linux 環境で Clone app がフル対応する予定はありますか？
A. 2025 年時点の公式な情報では、Windows アプリに比べて Linux アプリの Clone app 機能には制限があり、Microsoft Q&A でも Linux については「新規 Web App + App Service Plan を用意し、構成を手動でコピーする」ことが案内されています。 公開された明確な ETA は無いため、少なくとも現状の計画では「Linux は手動移行が前提」と捉えておくのが無難です。
まとめ：Premium v4 への移行は「ユニットを跨ぐ」ことが本質
Premium v3（P2v3）から Premium v4 へスケールアップできないのは、App Service Plan が属している デプロイメント ユニットが Premium v4 非対応 であることが根本原因です。この場合、同じプラン内でのスケールアップや、同じ RG・リージョン・OS で新プランを作るだけでは状況は変わりません。
本質的な解決策は、Premium v4 対応のデプロイメント ユニット上に新しい App Service Plan を作成し、アプリを移行することです。そのために：
- 新しいリソース グループで Premium v4 プラン（Linux）を作成する。
- 新プラン上に Web App を作成し、設定・証明書・ネットワーク・スロットを丁寧にコピーする。
- コード／コンテナをデプロイして検証し、DNS と Outbound IP（NAT Gateway を含む）を適切に切り替える。
Linux アプリでは Clone app に頼れない分、手動移行の作業量は増えますが、その分「構成の棚卸し」と「IaC への落とし込み」を行う良い機会にもなります。Premium v4 の高いパフォーマンスとスケーラビリティを活かしつつ、堅牢で再現性の高いアプリ基盤へとアップグレードしていきましょう。
コメント