AzureでTrusted Launch（セキュリティタイプ：Trusted launch）のWindows Server VMを作成した後に、Azure Site Recovery（ASR）やAzure Backupの「Standardポリシー」に追加できず、運用設計をやり直す羽目になることがあります。本記事では“Standard（通常のセキュリティタイプ）へ戻す/作り直す”現実的な手段と、失敗しやすいポイント（特にBitLocker）を具体的に整理します。
まず確認：本当に「Trusted Launchだから」ASR/バックアップが弾かれている？
最初に押さえておきたいのは、Trusted Launch VMが原因に見えるエラーでも、実際はシナリオやポリシー種別、ディスク設定が原因のことがある点です。最近はASRもAzure BackupもTrusted Launch対応が進んでいるため、「Trusted Launch＝常にASR不可/バックアップ不可」と決め打ちすると遠回りになります。
2025年時点の公式情報では、Azure-to-AzureシナリオにおけるASRはTrusted Launch VM（Windows/Linux）をサポートしています。加えて、Azure BackupもEnhancedポリシーではTrusted Launch VMをサポートし、StandardポリシーでもCLI/PowerShell/REST経由なら保護できる旨が明記されています。
それでも「追加できない」場合、原因切り分けを先にやると、Standard化（変換/作り直し）の必要がなくなることがあります。以下の表で、よくある症状と当たりどころをまとめます。
| 症状 | よくある原因 | 先に試すこと（切り分け） |
|---|---|---|
| ASRに追加できない（ポータルでブロック/エラー） | Azure-to-Azure以外のシナリオ、リージョン要件、ディスク公開設定、作成時期や条件（Linux）など | 「保護シナリオがAzure-to-Azureか」「ソース/ターゲットリージョン」「ディスクのNetwork access」「VM構成（共有ディスク等）」を確認 |
| バックアップで「Standard policy not supported…」系の表示 | ポータルではTrusted Launch＋Standardポリシーが制限に当たりやすい | Enhancedポリシーを検討。StandardにこだわるならCLI/PowerShell/RESTでの保護が可能か確認 |
| バックアップはできるが、Trusted Launchを後から有効化できない | Standardポリシーで保護中のVMは、Trusted Launch有効化がブロックされる | 先にStandard→Enhancedへ移行してからTrusted Launchを有効化する |
この切り分けで「ASR/バックアップの仕様上、どうしてもStandardにしたい」と確定した場合に、次章以降の“戻し方/作り直し方”が効いてきます。
Trusted LaunchとStandardの違いと、なぜ「変換」がややこしいのか
Azure VMのセキュリティタイプには、ざっくり言うと次の2つがあります（ここでいうStandardは“通常のセキュリティタイプ”であり、ディスクのStandard SSD/HDDなどの意味ではありません）。
| 観点 | Trusted Launch | Standard |
|---|---|---|
| ブートの防御 | Secure BootやvTPMなどを組み合わせて、ブートキット/ルートキット対策を強化 | 従来のGen2/Gen1 VMのブートモデル |
| vTPM | 有効化可能（既定で有効のケースが多い） | なし |
| Secure Boot | 有効化可能（推奨） | なし（少なくともTrusted Launchの枠組みでは） |
| VMゲスト状態（VMGS） | UEFI署名DBなどのセキュリティ情報を保持するVMGSを利用し、OSディスクとライフサイクルが結び付く | VMGSの枠組みなし |
Trusted Launchは「あとからON/OFFできる単なるオプション」に見えますが、実体としてはブートや信頼の根（vTPM・Secure Boot）まで踏み込むため、OSディスク側に紐づく情報（VMGSなど）も絡んできます。これが“ディスクをそのまま使っただけではStandardにならない/なりにくい”と言われる背景です。
結論：ポータルのワンクリックで確実にStandard化するのは難しい
現場感としては、次のいずれかになります。
- 条件が合えば「ロールバック（プレビュー）」でsecurityTypeをStandardへ戻せる
- 条件が合わない/プレビューを避けたい場合は、Standardで作り直して移行が最も堅実
- 作り直しの手作業が重いなら、OSディスクをエクスポート→VHDからManaged Disk再作成してStandard側で使う
以降は、上から順に「なるべく停止時間を短く」「戻せる設計」を意識した手順を紹介します。
選択肢A：プレビュー機能でsecurityTypeをStandardへロールバックできる場合
公式ドキュメントには、既存Gen2 VMでTrusted Launchを有効化した後に、securityTypeをStandardへロールバックする手順が記載されています。ポイントは以下です。
- サブスクリプションでプレビュー機能UseStandardSecurityTypeの登録が必要
- Azure portalではロールバックがサポートされない（CLI/PowerShell/ARMなどが前提）
- VMは一度割り当て解除（deallocate）が必要
運用メモ：プレビュー機能は、サポート範囲や動作が変わる可能性があります。ミッションクリティカルな本番VMにいきなり適用せず、同条件の検証VMで「起動」「BitLocker」「ドメイン参加」「監視エージェント」「アプリ起動」を通してから本番に入るのが安全です。
Azure CLIの例（概要）
以下は概念を掴むための流れです（実際にはResource Group名やVM名を読み替えてください）。
az vm deallocate --resource-group RG_NAME --name VM_NAME
az vm update --resource-group RG_NAME --name VM_NAME --security-type Standard
az vm start --resource-group RG_NAME --name VM_NAMEロールバック後は、VMのセキュリティプロファイル（securityProfile）が期待どおりに更新されたかを確認し、ASR/バックアップの登録可否を再チェックします。
選択肢B（推奨・シンプル）：Standardで作り直してデータ移行
「多少の手作業があっても確実に進めたい」「プレビューは避けたい」「構成を棚卸しして負債を減らしたい」なら、この方法が最も安全です。特にWindows Server VMは、アプリ構成が整理できているほど移行は短時間で終わります。
作り直し移行が向くケース
- アプリが少ない/構成がシンプル（ファイル＋サービス程度）
- OSのカスタマイズが大きくない（ローカルユーザーやレジストリ改変が少ない）
- 「この機会にIaC化・標準化したい」（NSG/拡張機能/監視などを整える）
移行前の棚卸しチェックリスト
移行で事故が起きるのは「VMの中身」よりも「周辺リソースの取りこぼし」です。以下の表を、移行設計のチェックシートとして使ってください。
| カテゴリ | 確認項目 | メモ（落とし穴） |
|---|---|---|
| ネットワーク | VNet/サブネット、NIC、NSG、UDR、Public IP、LB/ASG | “同じIPで切り替えたい”場合はPublic IPやLBの付け替え計画が必要 |
| ID/認証 | Managed Identity（システム割り当て/ユーザー割り当て）、Key Vault参照 | VMを作り直すとシステム割り当てIDは変わる。権限付与の再設定が必要 |
| ディスク | OS/Dataディスク、暗号化（SSE/ADE）、スナップショット | 暗号化方式が混在すると復元や差し替えで詰まりやすい |
| 拡張機能 | VM Extension（監視、セキュリティ、カスタムスクリプトなど） | 自動展開していないと“何が入っていたか”を忘れがち |
| 運用 | バックアップ設定、ASR、Update管理、ログ（AMA/Log Analytics） | 「作り直したら監視が途切れた」を防ぐため、先に設計図を作る |
実作業の流れ（例）
- 既存VMの構成（サイズ、ディスク、NIC、拡張機能、IP設計）をドキュメント化
- 新規にSecurity type: StandardでWindows Server VMを作成（同一サブネット推奨）
- 必要に応じてデータディスクを新VMへ付け替え、アプリ/設定を移行
- 切り替えウィンドウで旧VM停止→最終差分同期→DNS/ロードバランサ/ルーティング切替
- 新VMで業務テスト、監視/バックアップ/ASRを有効化して完了
コツ：「切り替え当日にやる作業」を極小化すると成功率が上がります。例えば、事前に新VMで監視エージェントやWindows Update設定を揃え、切替当日はデータ同期と宛先切替だけに寄せるのが定番です。
選択肢C：OSディスクをエクスポート→再作成してStandard VMへ差し替える
「OSの中の構成が複雑で、作り直しの手作業が重い」場合に検討されるのがこの方法です。発想としては、Trusted Launch VMのOSディスクを“エクスポートしたVHD”として扱い直し、そこから新しいManaged Diskを作り直して、Standard側で使える状態に寄せます。
全体像（ざっくり）
- 旧VMを停止（割り当て解除）し、まずはスナップショットを取る
- OSディスクにSASを発行して、ストレージアカウントへVHDとしてコピー
- そのVHDから新しいManaged Diskを作成
- Standardの新VMを用意し、OSディスクを差し替え（またはディスクから新VM作成）
- 起動確認（特にBitLockerとネットワーク）
Managed Diskをストレージアカウントへコピーする基本コマンド例は、Microsoft Learnのサンプルでも紹介されています。
ディスクコピー（CLIの雛形）
# 例：OSディスクのSASを発行（有効期限は適宜）
sas=$(az disk grant-access --resource-group RG_NAME --name OS_DISK_NAME --duration-in-seconds 3600 --query "accessSAS" -o tsv)
# 例：ストレージアカウントのコンテナへサーバーサイドコピー
az storage blob copy start
--destination-blob DEST_VHD_NAME.vhd
--destination-container CONTAINER_NAME
--account-name STORAGE_ACCOUNT_NAME
--account-key STORAGE_ACCOUNT_KEY
--source-uri $sasコピー後、VHDのURIを指定してManaged Diskを作成します（OSディスクとして使う場合はosTypeやhyperVGenerationなどの指定が関わります）。
VHDからManaged Disk作成（CLIの雛形）
az disk create \
--resource-group RG_NAME \
--name NEW_OS_DISK_NAME \
--location REGION_NAME \
--sku Premium_LRS \
--size-gb DISK_SIZE_GB \
--source https://STORAGE_ACCOUNT_NAME.blob.core.windows.net/CONTAINER_NAME/DEST_VHD_NAME.vhdVM側への適用パターン
| パターン | 概要 | 向くケース |
|---|---|---|
| 新VMを作ってOSディスクをSwap | Standard VM（空のOSでも可）を用意し、OSディスクを新ディスクに入れ替える | NIC/Private IPなど“VMリソース側”を維持したい |
| ディスクから新VMを作成 | 新しく作ったManaged DiskからVMを生成する | 切替をシンプルにしたい（ただしNICやPublic IPは新規になりやすい） |
OSディスクのSwapは、PowerShellでの公式手順が公開されています。暗号化の混在やディスクサイズの一致など、前提条件があるため注意してください。
また、OSディスクから新VMを作る方法も公式に案内されていますが、同じコンピューター名や一部識別子が引き継がれるなどの注意点があります。複製台数が増えるとアプリによっては問題になるため、使い方を整理してから進めるのが安全です。
重要な注意点：BitLockerは「vTPM/Secure Bootが変わるだけ」で詰むことがある
Trusted LaunchからStandardへ寄せる過程では、VMのブート/TPMの見え方が変わります。BitLockerが有効なWindows Serverでは、TPM状態や起動整合性の変化に反応して回復キーの入力を要求することがあります。回復キーを持っていないと、最悪「起動できない＝移行失敗」になり得ます。
作業前にやっておくこと（最低限）
- BitLockerの有無を確認（OSドライブだけでなくデータドライブも）
- 回復キーの保管場所を確定（AD/Azure AD/手元の保管庫など）
- 可能なら作業直前にBitLockerを一時停止（Suspend）して、再起動の影響を減らす
- Azure portalでBoot diagnosticsを有効化し、コンソール画面を確認できるようにしておく
実務のポイント：回復キーの所在が曖昧なまま進めるのは避けてください。移行作業自体はやり直せても、BitLockerでロックされたOSディスクは“データそのものが守られている”状態なので、鍵がなければ復旧できません。
どれを選ぶべき？判断基準を一枚にまとめる
最後に、よくある現場の選択を“判断表”に落とします。悩む時間を減らし、関係者に説明しやすくするための表です。
| 優先したいこと | おすすめ | 理由 |
|---|---|---|
| とにかく安全に確実にStandardへ | 選択肢B：作り直し移行 | 手順が単純で、ロールバックも容易。構成の棚卸しにもなる |
| 停止時間を最小化したい（条件が合う） | 選択肢A：securityTypeロールバック（プレビュー） | VMを作り直さずに戻せる可能性。ただしプレビュー前提で検証が必須 |
| OS内の作り込みが重く、作り直しが現実的でない | 選択肢C：エクスポート→再作成 | OSを維持しつつStandard側へ寄せられる。ただし手順が多く事故りやすい |
Azure Backupで詰まりやすいポイント：StandardポリシーとEnhancedポリシー
「標準のバックアップポリシー（Standard）に追加できない」の背景には、Azure Backupのポリシー種別の違いがそのまま影響しているケースが多いです。Enhancedポリシーは新しい機能や新しいディスク/VM要件に追従している一方で、Standardポリシーは“新しいオファリング”の保護で制限が出ることがあります。
| 項目 | Standardポリシー | Enhancedポリシー |
|---|---|---|
| Trusted Launch VMの保護 | ポータル経由では制限に当たりやすい。CLI/PowerShell/REST（特定バージョン以降）で保護できる旨が記載 | サポートされる（推奨） |
| 新しいディスク/機能への追従 | Ultra SSDやPremium SSD v2などで制限が出る | 新しいオファリングを含めてサポートが拡張されやすい |
| ポリシー変更 | Standard→Enhancedへの移行はサポートされている（移行後は戻せない） | Enhanced→Standardへの変更は不可 |
もし目的が「バックアップを取りたいだけ」で、ASRやセキュリティタイプ変更が必須ではないなら、先にEnhancedポリシーを採用するだけで解決する可能性があります。Standardにこだわる理由（運用統一、コスト、既存設計）を言語化したうえで、どこまで“設計を守るか/現実に寄せるか”を決めるのが良いです。
Standard化が目的なら、バックアップ/DR設計も同時に見直す
Trusted Launch→Standardへ戻す背景には、多くの場合「ASRやバックアップ要件」があります。ここを満たせないと本末転倒なので、最後に要点だけ整理します。
- ASR：Trusted Launch VMはAzure-to-Azureシナリオでサポートされているため、まずは前提条件（シナリオ/リージョン/ディスク設定）を確認。
- Azure Backup：Trusted Launch VMはEnhancedポリシーでの保護が基本。Standardポリシーにこだわる場合でも、CLI/PowerShell/REST経由で保護できる可能性がある。
よくある質問
vTPMやSecure BootをOFFにすれば「Standard扱い」になりますか？
いいえ。vTPM/Secure BootはTrusted Launchの“機能”であって、セキュリティタイプそのもの（securityType）とは別です。要件が「Standardのセキュリティタイプであること」なら、ロールバック/作り直し/ディスク再作成のいずれかが必要になります。
結局、最短で終わるのはどれですか？
条件が合えばロールバックが最短ですが、検証が不十分だと一発で詰みます。初回は作り直し移行が結果的に最短（やり直しが容易）になることも多いです。
作業を失敗したときの戻し方は？
基本は「旧VMを消さずに残す」「OSディスク/データディスクのスナップショットを取る」「切替はDNSやLBで行い、物理的な削除は最後」の3点です。特に選択肢Cは、ディスクが“どの時点の実体か”を取り違える事故が多いので、命名規則（例：osdisk-20251227-pre）を先に決めてから進めるのがおすすめです。
コメント