Azure Confidential Live Migrationとは？Intel TDX機密VMへの影響と確認ポイント

Microsoft AzureのConfidential Live Migrationは、Intel TDXを利用するAzure Confidential VMを、プラットフォーム保守時に別ホストへ移動しやすくするための新機能です。ポイントは、単なるライブマイグレーションではなく、機密VMの保護を維持しながら、保守時の中断を小さくすることにあります。Microsoftは、Intel TDX Confidential VMを対象に、限定的な中断で別ホストへ移動し、特権ソフトウェアからの保護を維持する機能として案内しています。(マイクロソフト Azure)

ただし、現時点のステータスはIn developmentです。Azure Updates上のIn developmentは、選定された顧客向けに非本番用途・テスト用途で提供される段階と説明されています。(マイクロソフト Azure) そのため、管理者が今すぐ行うべきことは「本番環境へ適用する前提で設計を変える」ことではなく、対象となるIntel TDX機密VMの棚卸し、可用性設計の確認、今後のプレビュー・GAに備えた検証計画の作成です。

Microsoft AzureのConfidential Live Migrationで何が変わるのか

従来のAzure VMでは、ホスト保守や基盤更新に伴う移動をクラウド側が吸収しやすい一方、Confidential VMでは「実行中のデータを守る」ための制約があります。特にIntel TDX Confidential VMは、ハイパーバイザーやホスト管理コード、管理者からVMのメモリや状態を保護することを目的とした仕組みです。Microsoft Learnでも、Intel TDXはメモリ管理・暗号化、CPU状態の機密性と整合性保護に関わる技術として説明されています。(Microsoft Learn)

今回のConfidential Live Migrationは、その制約を前提にしながら、プラットフォーム保守時の運用柔軟性と可用性を高めるための機能です。通常のVMのライブマイグレーションに近い運用メリットを、機密VMの保護モデルに近づける動きと捉えると分かりやすいでしょう。

観点	これまでの課題	Confidential Live Migrationで期待される変化
基盤保守	機密VMでは保護要件により移動や更新時の制約が大きい	保守時に別ホストへ移動しやすくなる
可用性	再起動や停止を前提にした設計が必要になりやすい	限定的な中断で済む場面が増える可能性
セキュリティ	移動中のVM状態やメモリ保護が重要	attestationやポリシー enforcementを含む保護を維持する方向
運用計画	メンテナンス通知、冗長化、手動切り替えの設計が重要	将来的に保守対応の自動化・簡素化余地が出る

重要なのは、「保守時の停止が完全になくなる」と読むべきではない点です。公式説明でも、表現はlimited interruptionです。アプリケーション側では、短時間の停止、ネットワーク遅延、接続再確立、処理の一時停止が起きても問題が拡大しない設計を続ける必要があります。

対象はIntel TDX Confidential VM。通常VMやすべての機密VMではない

今回の更新で中心になるのは、Intel TDX confidential VMs in Azureです。通常のAzure VM、Trusted Launch VM、AMD SEV-SNPベースのConfidential VM、AKS上のノードなどに自動的に広く適用されるものとして扱うのは早計です。

Azure Confidential VMそのものは、高いセキュリティ要件を持つテナント向けのIaaSであり、使用中データ、プロセッサ状態、VMメモリの暗号化、ホストの構成確認、vTPMなどを提供します。(Microsoft Learn) その中でもIntel TDXは、ハイパーバイザーやホスト管理コード、管理者がVMメモリや状態へアクセスしにくくするための技術です。(Microsoft Learn)

対象確認では、少なくとも次の条件を見ます。

確認項目	見るべきポイント
VMのセキュリティ種別	ConfidentialVMとして作成されているか
CPU/VMシリーズ	Intel TDX対応のConfidential VMサイズか
リージョン	対象リージョンで該当VMサイズが使えるか
OSイメージ	Confidential VM対応イメージ、または要件を満たすカスタムイメージか
ディスク暗号化	VMGuestStateOnly、DiskWithVMGuestState、CMK/PMKの選択を把握しているか
可用性構成	Availability Zone、VM Scale Sets、負荷分散、バックアップ設計を維持しているか

Microsoft Learnでは、Confidential VMはすべてのリージョンで利用できるわけではないと案内されています。(Microsoft Learn) そのため、今後この機能がプレビューや一般提供に進んでも、リージョン・SKU・OSイメージごとの対応確認は必須です。

まず確認すべき対象VMの棚卸し

最初に行うべき作業は、環境内にあるConfidential VMの棚卸しです。特に、機密データ処理、AI推論、個人情報処理、金融・医療・公共系のワークロードなどで、Intel TDX対応VMを使っている場合は優先度が高くなります。

Azure CLIで候補を出す場合は、次のようにsecurityProfile.securityTypeを確認します。

az vm list \
  --query "[?securityProfile.securityType=='ConfidentialVM'].{name:name,resourceGroup:resourceGroup,location:location,size:hardwareProfile.vmSize,securityType:securityProfile.securityType}" \
  -o table

大規模環境ではAzure Resource Graphで横断的に確認する方が現実的です。

resources
| where type =~ 'microsoft.compute/virtualmachines'
| where tostring(properties.securityProfile.securityType) =~ 'ConfidentialVM'
| project name, resourceGroup, location, vmSize=tostring(properties.hardwareProfile.vmSize), subscriptionId

VM Scale Setsを使っている場合は、VM単体だけでなくスケールセット側のプロファイルも確認します。

az vmss list \
  --query "[?virtualMachineProfile.securityProfile.securityType=='ConfidentialVM'].{name:name,resourceGroup:resourceGroup,location:location,sku:sku.name}" \
  -o table

棚卸し結果には、次のタグを付けておくと後続の検証が楽になります。

workload-class=confidential
confidential-tech=intel-tdx
maintenance-risk=high
owner=team-name
migration-test=required

タグ設計は地味ですが、プレビュー参加、メンテナンス通知の確認、検証対象の抽出、変更管理の承認で効きます。運用で失敗しやすいのは、機能そのものではなく「どのVMが対象なのか分からない」状態です。

現時点では「利用可能」と決めつけない

今回の発表で特に注意したいのは、公式更新のステータスがIn developmentであることです。Azure Updatesでは、In developmentは限定された顧客向けの非本番・テスト用途という位置づけです。(マイクロソフト Azure)

また、Microsoft LearnのDCesv6-seriesの機能サポート表では、Live MigrationとMemory Preserving UpdatesはNot Supportedと記載されています。(Microsoft Learn) これは、少なくとも既存ドキュメント上では「すぐに本番で使える標準機能」とは扱えないことを示しています。

実務上は、次の判断が安全です。

状況	管理者の判断
本番のSLA設計	まだConfidential Live Migrationを前提にしない
非本番の検証	Microsoftから対象案内があれば検証候補にする
既存の保守手順	当面は従来どおり、再起動や停止を想定したRunbookを維持
可用性設計	Availability Zone、負荷分散、再試行、バックアップを削らない
ドキュメント更新	Azure Updates、Microsoft Learn、リージョン別可用性を継続確認

特に「ライブマイグレーションが来るなら冗長化を緩めてもよい」という判断は避けるべきです。Confidential Live Migrationは、基盤保守時の中断を減らす機能であり、アプリケーション障害、OS障害、リージョン障害、誤操作、データ破損を解決するものではありません。

管理者が確認すべき設定ポイント

VMサイズとリージョン

Intel TDX対応のConfidential VMを使っているかを確認します。DCesv6-seriesはIntel第5世代Xeon ScalableプロセッサとIntel TDXに対応し、処理中のコードとデータの機密性・整合性を保護するVMとして説明されています。(Microsoft Learn)

ただし、リージョンごとに使えるVMサイズは変わります。新機能が段階的に展開される場合、同じSKUでもリージョン差が出ることがあります。東日本・西日本リージョンで利用している場合も、グローバル発表だけを見て判断せず、実際のサブスクリプション、リージョン、クォータで確認しましょう。

確認する項目は次の通りです。

項目	確認理由
VMサイズ	Intel TDX対象かどうかを判断するため
リージョン	機能展開がリージョン単位になる可能性があるため
vCPUクォータ	検証用VMを追加作成できないケースがあるため
ゾーン構成	ゾーン冗長設計と移行動作の関係を確認するため
既存のメンテナンス通知	既存Runbookとの整合を取るため

OSイメージとカスタムイメージ

Confidential VMでは、すべてのOSイメージが使えるわけではありません。Microsoft Learnでは、Confidential VMで動作するOSイメージは、セキュリティと互換性の要件を満たす必要があると説明されています。(Microsoft Learn)

特に注意が必要なのは、独自に作成したカスタムイメージです。ベースOS、カーネル、ブート構成、暗号化、エージェントの状態に差があると、Confidential VMとしては動いていても、将来のConfidential Live Migration検証で想定外の問題が出る可能性があります。

カスタムイメージを使っている場合は、次の情報を残しておきます。

- ベースイメージ
- OSバージョン
- カーネルバージョン
- Azure VM Agentの状態
- セキュアブート設定
- vTPM設定
- ディスク暗号化方式
- 追加しているセキュリティエージェント
- 起動時に実行される初期化スクリプト

ディスク暗号化とキー管理

Confidential VMでは、作成時にディスク暗号化やキー管理の選択が重要です。Azure CLIの作成例でも、--security-type ConfidentialVM、--enable-vtpm true、--os-disk-security-encryption-typeなどの指定が使われています。(Microsoft Learn)

さらに、Customer Managed Keyを使う場合はAzure Key VaultまたはManaged HSMを選ぶ構成になり、Key VaultではPremium SKUなどの条件が出てきます。(Microsoft Learn)

ここで失敗しやすいのは、「あとから変えればよい」と考えることです。Microsoft Learnでは、Confidential VM作成後にフルディスク暗号化を無効化・再有効化することはできず、新しいConfidential VMを作成する必要があると説明されています。(Microsoft Learn) また、Platform-managed keyとCustomer-managed keyの選択も作成時のみ可能です。(Microsoft Learn)

そのため、Confidential Live Migrationの検証前に、少なくとも以下を整理しておきます。

確認項目	判断基準
PMKかCMKか	規制要件、監査要件、鍵管理責任で判断
Key VaultかManaged HSMか	HSM要件、運用負荷、コストで判断
鍵のローテーション	アプリ停止やVM再作成が必要にならないか確認
権限設定	Confidential VM関連のサービスプリンシパルに必要権限があるか
復旧手順	鍵削除、無効化、権限変更時の影響を確認

Attestationの確認

Intel TDXベースのConfidential VMでは、起動時にプラットフォームが準拠し最新状態であることを確認するattestationが透過的に行われると説明されています。さらに、起動後にVM内からIntel TDX上で動作していることを検証するin-guest platform attestationも案内されています。(Microsoft Learn)

Confidential Live Migrationでは、移動前後で信頼できるホストへ移動していること、移動後も期待する保護状態が維持されていることが重要になります。アプリケーション開発者やセキュリティ担当は、単にVMが起動しているかではなく、attestation結果を監査証跡として残せるかを検証項目に入れるべきです。

実務では次の観点を確認します。

- VM起動時のattestationが成功しているか
- 移行前後で期待するセキュリティ状態が変わらないか
- 監査ログに必要なイベントを残せるか
- 監視アラートが誤検知・見逃しを起こさないか
- セキュリティ基準に満たない状態でワークロードを実行しない仕組みがあるか

開発者が確認すべきアプリケーション側の影響

Confidential Live Migrationはインフラ側の機能ですが、アプリケーション側が無関係になるわけではありません。公式の表現は「limited interruption」であり、ゼロ中断を保証するものではありません。(マイクロソフト Azure)

特に次のようなアプリケーションは、移行時の短い揺らぎに弱い可能性があります。

アプリケーション特性	起きやすい問題	対策
長時間TCP接続	一時的な遅延、再接続	接続タイムアウトと再試行を明示
インメモリ処理	処理停止に見える瞬間がある	ジョブのチェックポイントを持つ
分散ロック	リーダー選出の誤判定	lease時間とヘルスチェック間隔を調整
DB接続プール	接続切断や枯渇	コネクション再生成を自動化
バッチ処理	二重実行、途中終了	idempotencyと再開位置を設計
APIサーバー	瞬間的なレイテンシ増	クライアント側リトライとキューイング

「VMが止まらないならアプリはそのままでよい」と考えると、検証で見落とします。ライブマイグレーションの成否だけでなく、アプリケーションのSLO、処理遅延、リトライ回数、エラー率、外部連携先のタイムアウトまで見る必要があります。

移行・展開時に注意すべき落とし穴

非Confidential VMをあとからConfidential VMに変換できるとは限らない

既存の通常VMを、後からConfidential VMへ変換して今回の機能対象にする、という考え方は危険です。Microsoft Learnでは、セキュリティ上の理由から、非Confidential VMをConfidential VMへ変換することはできず、最初からConfidential VMとして作成する必要があると説明されています。(Microsoft Learn)

既存システムをConfidential VMへ移す場合は、実質的には新規VM作成、データ移行、DNSや負荷分散の切り替え、監視設定の再適用が必要になります。

機能提供後もHA設計は省略しない

Confidential Live Migrationは、Azure基盤側の保守に対する可用性向上策です。アプリケーションのバグ、OSパッチ適用、ゲストOS内の再起動、リージョン障害、ネットワーク障害、ストレージ障害まで吸収するものではありません。

本番環境では、次の基本設計を維持します。

- 複数インスタンス構成
- Availability Zoneまたはゾーン冗長構成
- ロードバランサーまたはアプリケーションゲートウェイ
- バックアップとリストア演習
- パッチ適用時のローリング更新
- 障害時の切り戻し手順

ライブマイグレーションが入ると、保守時の中断は減る可能性があります。しかし、可用性設計を単純化しすぎると、別の障害で復旧できなくなります。

セキュリティ担当は「移行中の保護」だけで満足しない

Confidential Live Migrationは、VM移動中の保護を高める重要な機能ですが、セキュリティ対策の全体を置き換えるものではありません。

たとえば、次のリスクは引き続き別の対策が必要です。

リスク	必要な対策
ゲストOS内の侵害	パッチ管理、EDR、最小権限
アプリケーション脆弱性	SAST/DAST、依存関係管理
秘密情報の漏えい	Key Vault、Managed Identity、ローテーション
誤設定	Azure Policy、IaCレビュー、変更管理
権限過多	RBAC、PIM、監査ログ
データ破損	バックアップ、復元テスト、世代管理

機密VMは、クラウド基盤や管理者からの保護を強める技術です。アプリケーション内部で秘密情報をログに出す、過剰な権限を付与する、鍵をVM内に平文で置く、といった設計ミスまでは自動で防げません。

検証計画の作り方

Confidential Live Migrationが利用可能になったときに慌てないため、今の段階で検証シナリオを作っておきます。検証は「移行できたか」だけで終わらせず、性能、監視、セキュリティ、運用手順まで含めるのが実務的です。

フェーズ	やること	成果物
棚卸し	対象VM、リージョン、SKU、OS、暗号化方式を一覧化	対象VMリスト
非本番検証	テストVMで移行時の挙動を確認	検証ログ、メトリクス
アプリ検証	レイテンシ、エラー率、再接続、ジョブ再開を確認	SLO影響レポート
セキュリティ検証	attestation、鍵アクセス、監査ログを確認	セキュリティ確認表
運用反映	Runbook、障害対応、通知文面を更新	運用手順書
本番判断	提供ステータス、リージョン、SLA、制約を確認	本番適用判断メモ

検証時のメトリクスは、最低でも次を見ます。

- VMの再起動有無
- アプリケーションのエラー率
- レスポンスタイムの最大値・p95・p99
- DB接続の切断回数
- キュー滞留時間
- ログイン済みセッションへの影響
- attestation結果
- Azure Monitorのアラート発報状況

本番に近い検証を行う場合は、単体VMではなく、実際の負荷分散、監視、バックアップ、鍵管理、デプロイパイプラインを含めた構成で確認します。

影響を受けやすい組織とワークロード

今回の発表を優先的に追うべきなのは、次のような組織です。

組織・ワークロード	優先度が高い理由
金融・保険	顧客情報、取引情報、リスクモデルを扱うため
医療・ヘルスケア	個人情報や医療データの保護要件が高いため
公共・自治体	機密性と監査性が重視されるため
AI/ML基盤	学習データ、推論データ、モデル重みを保護したいため
データクリーンルーム	複数組織間でデータを出し合うため
SaaS事業者	顧客データの分離と説明責任が重要なため

一方で、一般的なWebサーバーや社内ツールで、Confidential VMを使っていない環境では、直接の影響は限定的です。ただし、将来的に「機密データ処理をAzureへ移す」計画があるなら、設計段階でIntel TDX Confidential VMとConfidential Live Migrationの進展を見ておく価値があります。

今すぐやるべきこと

現時点での実務アクションは、次の5つに絞れます。

1つ目は、Azure環境内のConfidential VMを棚卸しすることです。VMサイズ、リージョン、OS、暗号化方式、オーナーを一覧化します。

2つ目は、Intel TDXベースのVMを分けて管理することです。すべてのConfidential VMが今回の対象とは限らないため、confidential-tech=intel-tdxのようなタグを付けておくと後から追跡しやすくなります。

3つ目は、既存の可用性設計を維持することです。In development段階では、Confidential Live Migrationを本番SLAの前提にしない方が安全です。

4つ目は、アプリケーションの短時間中断耐性を確認することです。ライブマイグレーションが成功しても、アプリが短い遅延や接続断に弱ければ利用者影響は残ります。

5つ目は、Azure UpdatesとMicrosoft Learnの更新を継続的に確認することです。特に、ステータスがIn previewやLaunchedに変わったタイミング、対象リージョン、対象SKU、制約事項、料金への影響を確認します。

まとめ

Microsoft AzureのConfidential Live Migrationは、Intel TDX Confidential VMの運用柔軟性と可用性を高める重要な発表です。プラットフォーム保守時に、機密VMの保護を維持しながら別ホストへ移動しやすくなる点が大きな変更点です。

ただし、現時点ではIn developmentです。本番環境では、すぐに既存の可用性設計やメンテナンス手順を削るのではなく、対象VMの棚卸し、リージョン・SKU・暗号化方式の確認、アプリケーションの短時間中断耐性の検証から始めるのが現実的です。

次に取るべき行動は明確です。まずAzure環境でConfidential VMを一覧化し、Intel TDXベースのワークロードを特定してください。そのうえで、非本番環境での検証計画、attestation確認、監視・Runbook更新の準備を進めておくと、プレビューや一般提供が進んだときに安全に評価できます。