MENU

Azure App Serviceのwebspace相違でMicrosoft.Webを別リソースグループへ移動できない時の完全対処ガイド｜App Service Plan/ Web App移行

Azure

Azure App Service で「Microsoft.Web リソースを別リソースグループに移動できない」というエラーに直面すると、テスト／本番の統合作業が一気に止まります。原因は “webspace（内部ホスティング グループ）” の相違です。本記事では、発生メカニズムから実践的な移行手順、ダウンタイム最小化、運用のベストプラクティスまでを具体的に解説します。

目次

Microsoft.Web リソースを別リソースグループへ移動できない問題

状況と影響

以下のような構成で、Azure ポータル／CLI の「移動」でエラーが発生します。

項目内容
現状リソース グループrg_MTA
対象App Service Plan と Web App（プロダクション／開発）
内部 webspaceasp‑mta‑prod‑centralus‑basic‑windows_group など、論理 RG と一致しない名称が混在
やりたいことすべてを rg-c1-mta-test-centralus へ一括移動
発生症状「同一 webspace ではないため移動できません」等のエラー
ビジネス影響テスト・本番統合の移行がブロックされ、環境整備スケジュールに遅延

結論（重要）

App Service Plan は作成時に割り当てられた webspace（内部ホスティング グループ）をまたいで移動できません。 ポータルや CLI の「リソース移動」で既存リソースを丸ごと別 RG に寄せることはできないため、“作り直し”による移行が現実解です。

なぜ webspace がボトルネックになるのか

  • 同一リージョン・同一 OS・SKU 等の条件で、App Service の内部ではサイトを「webspace」という単位に束ねて管理します。
  • webspace はプラン作成時に固定され、後から変更・移動は不可です。
  • RG 移動は「移動元と移動先が同一 webspace に属していること」を前提としており、webspace が異なると移動バリデーションで失敗します。

ありがちな誤解

  • 「同じサブスクリプションなら RG は自由に動かせる」は誤り。App Service（Microsoft.Web）は webspace 制約がかかります。
  • Web App だけ／プランだけを先に動かすのも不可。サイトとプランは同一 webspace でなければなりません。

移行の全体像（作り直しで解決）

既存リソースを残したまま webspace をまたぐことはできないため、新しい App Service Plan を移行先 RG に作成し、Web App を複製・再構成・切替の手順を踏みます。

移行ステップのサマリ

  1. 依存関係の棚卸し（アプリ設定、接続文字列、証明書、ドメイン、ネットワーク、診断、ID など）
  2. 移行先 RG（rg-c1-mta-test-centralus）に新しい App Service Plan を同リージョン・同 SKU で作成
  3. Web App を複製（Clone / Backup & Restore / 再デプロイ のいずれか）
  4. アプリ設定・ドメイン・証明書・ネットワーク・Managed Identity 等を再構成
  5. ダウンタイム最小化の仕組み（スロットスワップ、Front Door / Traffic Manager、DNS TTL）で本番切替
  6. 新環境の安定稼働を確認後、旧環境のクリーンアップ

Web App 複製方法の比較

方法概要利点注意点
Clone Appポータルの「Clone App」で同設定のアプリを直接コピーGUI で直感的、反復が早いFree/Shared では不可。構成の差分は要確認
Backup & Restore旧アプリをバックアップし、新プラン上の新アプリに復元サイト コンテンツと構成をまとめて複製できるStandard 以上が必要。ストレージ アカウント準備が前提
再デプロイCI/CD（GitHub Actions、Azure Pipelines 等）で新アプリに再デプロイパイプラインを再利用。再現性・監査性が高いスロット設定・証明書・ドメインは手動で移行が必要

準備：棚卸しチェックリスト

まずは「何を移すか」を正確に把握します。下表を使って抜け漏れをなくしましょう。

カテゴリ確認項目取得方法の例
基本情報リージョン、OS（Windows/Linux）、SKU、スケール設定、Always Onポータルの App Service Plan / Web App プロパティ
アプリ設定App Settings、スロット設定の有無az webapp config appsettings list
接続文字列名称、種別（SQLServer/MySQL/Custom）、slotSettingaz webapp config connection-string list
アイデンティティSystem / User Assigned、参照している外部リソース（Key Vault 等）az webapp identity show、外部側の RBAC/アクセスポリシー
ドメイン／証明書カスタム ドメイン、SSL 証明書（ソース：Key Vault / PFX）az webapp config hostname list、az webapp config ssl list
ネットワークVNet 統合、プライベート エンドポイント、アクセス制限（IP/サービスタグ）az webapp vnet-integration list、az webapp config access-restriction show
監視・ログApplication Insights、診断設定（Log Analytics / ストレージ）ポータルの「診断設定」／az monitor diagnostic-settings list
スロットスロット名、スロット固有設定、スワップルールaz webapp deployment slot list
CI/CDリポジトリ、ブランチ、ビルド／デプロイ方式ポータル「デプロイ センター」、各パイプライン定義

手順：新規 App Service Plan の作成

移行先 RG（rg-c1-mta-test-centralus）に、旧プランと同じリージョン・SKU のプランを作成します。

Azure CLI（例）

# Windows プラン（例：Standard S1）
az appservice plan create \
  -g rg-c1-mta-test-centralus \
  -n asp-mta-centralus-s1 \
  --sku S1 \
  --location centralus

# Linux プラン（例：P1v3）

az appservice plan create 
-g rg-c1-mta-test-centralus 
-n asp-mta-centralus-p1v3-linux 
--is-linux 
--sku P1v3 
--location centralus

Bicep（例）

param location string = 'centralus'

resource plan 'Microsoft.Web/serverfarms@2023-01-01' = {
name: 'asp-mta-centralus-p1v3-linux'
location: location
sku: {
name: 'P1v3'
capacity: 1
tier: 'PremiumV3'
}
kind: 'linux'
properties: {
perSiteScaling: false
reserved: true // Linux
}
tags: {
'env': 'test'
'owner': 'mta'
}
}

手順：Web App の移行

1) Clone App（ポータル）

対象アプリの「Clone App」から新プランを選択して複製します。Free/Shared では利用できません。複製後に App Settings・接続文字列・スロット固有設定を差分確認します。

2) Backup & Restore（CLI 例）

Standard 以上でバックアップ／復元が可能です。事前にストレージ アカウントとコンテナーを用意します。

# バックアップの作成
az webapp config backup create \
  -g rg_MTA -n app-mta-prod \
  --container-url <SAS 付きコンテナー URL> \
  --db-connection-string <必要なら指定>

# 復元（新アプリ側で）

az webapp config backup restore 
-g rg-c1-mta-test-centralus -n app-mta-prod-new 
--container-url <同上> 
--backup-name <バックアップ名> 
--overwrite

3) 再デプロイ（CI/CD）

新プラン上に空の Web App を作成し、既存のパイプラインで再デプロイします。

# 新アプリ作成（Windows の .NET 例）
az webapp create \
  -g rg-c1-mta-test-centralus \
  -p asp-mta-centralus-s1 \
  -n app-mta-prod-new \
  --runtime "DOTNET|8-lts"

# 新アプリ作成（Linux の Node 例）

az webapp create 
-g rg-c1-mta-test-centralus 
-p asp-mta-centralus-p1v3-linux 
-n app-mta-dev-new 
--runtime "NODE|18-lts"

構成のコピー（設定／接続文字列／スロット）

移行では「アプリ本体」と同じくらい「構成の再現性」が重要です。以下のスクリプト例をベースに、自組織の標準に合わせて自動化しましょう。

PowerShell（App Settings）

$srcRg = "rg_MTA"
$srcApp = "app-mta-prod"
$dstRg = "rg-c1-mta-test-centralus"
$dstApp = "app-mta-prod-new"

$appSettings = az webapp config appsettings list -g $srcRg -n $srcApp | ConvertFrom-Json
$kv = @()
$appSettings | ForEach-Object {
if (-not $*.slotSetting) { $kv += "$($*.name)=$($_.value)" }
}
az webapp config appsettings set -g $dstRg -n $dstApp --settings $kv

PowerShell（接続文字列）

$conns = az webapp config connection-string list -g $srcRg -n $srcApp | ConvertFrom-Json
foreach ($c in $conns) {
  if (-not $c.slotSetting) {
    az webapp config connection-string set `
      -g $dstRg -n $dstApp `
      -t $($c.type) `
      --settings "$($c.name)=$($c.connectionString)"
  }
}

カスタム ドメインと証明書

# Key Vault にある証明書をインポートする例
az webapp config ssl import \
  -g rg-c1-mta-test-centralus \
  -n app-mta-prod-new \
  --key-vault <KeyVault 名> \
  --key-vault-certificate-name <証明書名>

# ドメインのバインド

az webapp config hostname add 
-g rg-c1-mta-test-centralus 
-n app-mta-prod-new 
--hostname [www.example.com](http://www.example.com)

# HTTPS バインド（必要に応じて）

az webapp config ssl bind 
-g rg-c1-mta-test-centralus 
-n app-mta-prod-new 
--certificate-thumbprint <拇印> 
--ssl-type SNI

Managed Identity と外部リソース権限

# System Assigned ID を付与
$iden = az webapp identity assign -g $dstRg -n $dstApp | ConvertFrom-Json
$principalId = $iden.principalId

# 例：Key Vault のシークレット参照に必要な RBAC を付与

$kvId = az resource show -g rg-security -n kv-mta --resource-type "Microsoft.KeyVault/vaults" --query id -o tsv
az role assignment create 
--assignee-object-id $principalId 
--assignee-principal-type ServicePrincipal 
--role "Key Vault Secrets User" 
--scope $kvId

ネットワーク（VNet 統合／アクセス制限）

# VNet 統合
az webapp vnet-integration add \
  -g rg-c1-mta-test-centralus \
  -n app-mta-prod-new \
  --vnet mta-vnet \
  --subnet snet-webapp

# アクセス制限（IP Allow 例）

az webapp config access-restriction add 
-g rg-c1-mta-test-centralus 
-n app-mta-prod-new 
--rule-name allow-corp 
--action Allow 
--ip-address 203.0.113.0/24 
--priority 100

ダウンタイムを最小化する切替設計

スロットスワップ

  • 新環境の staging スロットにデプロイし、検証後に本番とスワップします。
# スロット作成とスワップ
az webapp deployment slot create -g rg-c1-mta-test-centralus -n app-mta-prod-new --slot staging
# 検証後
az webapp deployment slot swap -g rg-c1-mta-test-centralus -n app-mta-prod-new --slot staging --target-slot production

注意：「スロット固有設定」に分離されていない App Settings／接続文字列は、スワップ時に意図せず切り替わります。切替前に見直してください。

Front Door / Traffic Manager での段階的切替

  • 新旧サイトをバックエンドとして登録し、重み付きルーティングで 10%→50%→100% と段階的に切替。
  • ヘルス プローブを厳しめに設定して、異常検知で自動フェールバック。

DNS 切替のベストプラクティス

  • 切替 24〜48 時間前から DNS TTL を短縮（例：300 秒）。
  • ロールバック要員が同席し、旧環境を最低 24 時間は温存。

検証計画：移行の品質を数字で担保する

観点テスト内容合否基準
機能主要画面／API の E2E テスト、非機能フラグ（FEATURE FLAG）の確認合計 100 ケース中 100% 合格
パフォーマンスピーク相当の負荷試験（例：90 パーセンタイル応答時間）P90 < 500ms、エラー率 < 0.1%
監視／ログApplication Insights のトレース／メトリック、診断ログの転送ダッシュボードが移行後 15 分以内に全項目更新
セキュリティKey Vault 参照、RBAC、アクセス制限、証明書の期限・暗号強度RBAC 逸脱なし、スキャナで重大脆弱性 0
ネットワークVNet 統合／DNS 解決／アウトバウンド IP 制御（必要ならば）全ルート到達性 OK、エグレス経路が要件に一致

トラブルシューティング（よくある落とし穴）

  • ランタイムの不一致：旧アプリのスタック（.NET / Node / Python / Java）とバージョンが一致していない。新規作成時の --runtime を合わせる。
  • x86 / x64 の違い：Windows アプリはプラットフォーム設定（32/64 ビット）を合わせる。
  • Always On が無効：バックグラウンド ジョブや常駐プロセスが動かない。新環境でも有効化。
  • スロット固有設定の漏れ：本番切替で接続先が入れ替わる事故。固有設定を厳密に分離。
  • Managed Identity の権限不足：新しいプリンシパル ID に Key Vault / ストレージ / DB の権限を再付与。
  • アクセス制限の順序：優先度（priority）競合で誤ブロック。新環境のルール順を再現。
  • Application Insights の関連付け：Instrumentation Key / Connection String の差し替え忘れに注意。

コストと運用の注意

  • 一時的な二重コスト：新旧プランが並走する期間の費用を見込む（P 系列は特にインパクト大）。完了後に速やかに旧プランを停止・削除。
  • 容量設計：新プランはスロット分のリソースも加味。スワップ時のスパイクを見越して余裕を持たせる。
  • タグ／命名：RG・プラン・アプリに一貫した命名規則（例：rg-<sys>-<env>-<region>、asp-...、app-...）を適用。

ベストプラクティス（将来の可搬性を高める）

  • 設計時に webspace を意識：「リージョン」「OS」「SKU」を統一し、環境ごとに別プランでも webspace が割れない設計を採用。
  • IaC（Bicep / Terraform）で再現性：作り直し移行に強い。what-if で差分を安全に確認。
  • パイプラインに “移行プレイブック” を組み込む：設定の抽出→変換→適用→検証を自動化。
  • Azure Policy で逸脱防止：許可リージョン・SKU・タグの強制でドリフトを抑止。

Terraform（例）

resource "azurerm_service_plan" "mta" {
  name                = "asp-mta-centralus-p1v3-linux"
  resource_group_name = "rg-c1-mta-test-centralus"
  location            = "Central US"
  os_type             = "Linux"
  sku_name            = "P1v3"
  per_site_scaling    = false
}

resource "azurerm_linux_web_app" "app" {
name                = "app-mta-prod-new"
resource_group_name = azurerm_service_plan.mta.resource_group_name
location            = azurerm_service_plan.mta.location
service_plan_id     = azurerm_service_plan.mta.id

https_only = true

site_config {
application_stack {
node_version = "18-lts"
}
always_on = true
}

identity {
type = "SystemAssigned"
}

app_settings = {
"WEBSITE_RUN_FROM_PACKAGE" = "1"
}
}

移行後のクリーンアップ

新環境の安定稼働を最低 24 時間確認したら、旧環境を段階的に削除します。

# 旧アプリの削除
az webapp delete -g rg_MTA -n app-mta-prod
az webapp delete -g rg_MTA -n app-mta-dev

# 旧プランの削除（他サイトがないことを確認）

az appservice plan delete -g rg_MTA -n asp-mta-centralus-old --yes

FAQ

Q. webspace が同じなら移動できますか？

A. はい。同一 webspace・同一サブスクリプション内で前提条件を満たせば RG 移動は可能です。ただし、webspace が異なると移動不可です。

Q. 同じ名前の RG を作れば解決しますか？

A. いいえ。RG 名は論理名であり、webspace の紐付けとは無関係です。

Q. App Service Environment（ASE）なら話は別？

A. ASE は別の制約体系（専用スタンプ）ですが、「プラン／サイトの作成時に決まる配置が後から自由に動かせない」点は共通です。原則として作り直し移行が安全です。

Q. 途中まで作ってからやっぱり RG を変えたい場合は？

A. 早期に IaC へ設計を落とし込み、最初から正しい RG／プランで構築し直すのが最短です。急場しのぎの手作業移行はドリフトの温床になります。

実運用での意思決定フレーム

条件推奨アクション理由
Small／単純構成Clone または再デプロイ作業コストが最小。差分も追いやすい
Middle／複数スロット・証明書ありBackup & Restore + 設定スクリプト構成の再現性を担保しつつ自動化でヒューマンエラーを排除
Large／複数プラン・大量サイトIaC + CI/CD で全面再構築スケール・監査・再現性・将来の可搬性が最大化

エラーメッセージの例と読み解き

この操作はサポートされていません。移動元と移動先のリソースは同じホスティング グループ（webspace）に属している必要があります。

このメッセージは、論理 RG ではなく内部 webspace が一致していないことを示します。プラン作り直しによる移行に切り替えましょう。

まとめ

  • ポイント：App Service Plan の webspace は作成時に固定で、またいだ RG 移動はできません。
  • 解決：移行先 RG に新しいプランを作り、Clone / Backup & Restore / 再デプロイで Web App を複製し、構成を再適用します。
  • 切替：スロットスワップや Front Door / Traffic Manager、TTL 短縮でダウンタイムを最小化します。
  • 運用：IaC と命名規則・タグ、ポリシー適用で将来の可搬性と統制を強化します。

以上の手順で、rg_MTA にある Microsoft.Web リソース群を rg-c1-mta-test-centralus に安全に統合できます。移行は「作り直し」が本筋――だからこそ、自動化と再現性に投資するほど、今回だけでなく次回以降のメンテナンス性も大きく向上します。

Azure
移行 Azure App Service Web App App Service Plan webspace

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次