私が引き継ぐ Azure Virtual Desktop 環境には、いつも同じ 2 つの問題があります。セッション ホストがどのイメージ バージョンから作られたのか誰も答えられないこと、そして前回のパッチ適用が 30 台の仮想マシンに 1 台ずつサインインして行われていたことです。このガイドは、その代わりに私が使っているプロセスです。イメージに何を含めるか、Azure Compute Gallery でどうビルドしてバージョン管理するか、セッション ホスト更新または従来のドレインして置き換えるパターンでどう展開するか、ビルドが失敗したときにどうロールバックするか、各ステップが実際にどれくらいかかるか、そして Spot VM とエフェメラル OS ディスクがコストの全体像のどこに位置するかを扱います。ここに書いた内容はすべて、本文中のリンクと「ソース」節に挙げた Microsoft Learn のページで確認しています。

イメージ戦略：ギャラリー イメージかカスタム ゴールデン イメージか

出発点は 2 つあります。1 つ目は Windows 11 Enterprise マルチセッションの Azure Marketplace イメージで、Microsoft がセキュリティ パッチのリリース後に毎月更新しており、FSLogix がプレインストールされています。Microsoft 365 Apps 入りのバリアントは毎月第 3 週の中頃に提供されます。基幹業務アプリが Intune 経由できれいにインストールできるなら、Marketplace イメージだけで運用し、イメージ パイプラインを丸ごと省略できます。

2 つ目はカスタム イメージです。Microsoft のゴールデン イメージ ガイドは、Marketplace の VM をカスタマイズし、Sysprep で一般化してキャプチャしたものと説明しています。ガイドはレプリケーションとバージョン管理ができるため、本番環境ではスタンドアロンのマネージド イメージより Azure Compute Gallery を推奨し、よくある失敗も率直に挙げています。イメージに Azure Virtual Desktop エージェントをインストールしない、既にホスト プールに参加している VM をキャプチャしない、Sysprep 前に VM をドメインから外す、同じ VM を 2 回キャプチャしない、既存のカスタム イメージから新しいベース VM を作らない。毎回 Marketplace イメージから新しく始めてください。

イメージに入れるもの、Intune や FSLogix に任せるもの

私のルールは単純です。イメージには、インストールに時間がかかるもの、または最初のユーザーがサインインする前に存在していなければならないものを入れます。それ以外は、再構築なしに変更できる層へ移します。

層ここに置くもの理由
イメージ（Compute Gallery バージョン）OS ビルド、累積更新、Microsoft 365 Apps、WebRTC リダイレクターを含む Teams、FSLogix エージェント、大きい、または扱いにくい基幹業務インストーラー、Visual C++ ランタイム、Virtual Desktop Optimization Tool の変更インストールに時間がかかる、初回サインインで必要、テスト済みの再構築が有利
Intune またはグループ ポリシー設定カタログ ポリシー、Defender 構成、証明書、小さなシステム コンテキスト アプリ、Windows Update の品質更新設定セッション ホスト更新は手動で追加したファイル、レジストリ キー、証明書を保持しないため、構成は管理ツールかイメージから来る必要がある
FSLogix プロファイル コンテナーユーザー プロファイル、Office キャッシュ、OneDriveプロファイルがホスト間でローミングするため、ホストを削除しても何も失われない
カスタム構成スクリプトプロビジョニング時に実行しなければならない最後の微調整セッション ホスト構成から新しいホストごとに実行される

Intune についてイメージに関わる点が 2 つあります。Intune マルチセッション ドキュメントは、既に登録済みのデバイスを複製したイメージを Intune がサポートしないと述べているので、ビルド VM を絶対に登録しないでください。マルチセッション向けアプリはシステム コンテキストで「必須」として割り当てる必要があり、これはイメージに何を入れるかを決める良い判断基準になります。ユーザー単位でしかインストールできないものは Intune ではなくイメージに入れます。

Image Builder とカスタム イメージ テンプレート、それとも手動 Sysprep か

手動ビルドは数台のホストなら機能しますが、同じ月に 2 人の管理者が別々のイメージをビルドした瞬間に破綻します。Azure Virtual Desktop ポータルのカスタム イメージ テンプレートが Microsoft の答えです。Azure VM Image Builder をラップし、Marketplace、ギャラリー、マネージド イメージ、既存テンプレートのいずれかをソースとして、組み込みスクリプト（FSLogix のインストールと構成、Teams 最適化、言語パック、タイム ゾーン リダイレクト、RDP Shortpath、画面キャプチャ保護、Storage Sense の無効化、Windows 更新の適用）と公開 URL に置いた独自スクリプトを実行し、Sysprep を代わりに実行して、結果を Compute Gallery またはマネージド イメージに配布します。ビルドはユーザー割り当てマネージド ID で IT_<ResourceGroupName>_<TemplateName>_<GUID> という名前のステージング リソース グループ内で動き、失敗時に見るのは packerlogs コンテナーの customization.log です。

コードで扱いたいなら、基盤となる Image Builder テンプレートが Bicep または JSON で同じカスタマイザーを提供します。計画に関わる既定値が 2 つあります。buildTimeoutInMinutes は既定 240 分、最大 960 分で、Microsoft は Windows では 60 分未満にしないよう推奨しています。再起動やインストーラーが保留中だと WindowsUpdate カスタマイザーが 0x80240016 で失敗することがあるので、その前に WindowsRestart ステップを置いてください。Microsoft の AVD Image Builder チュートリアルは、Windows のビルド VM は Standard_D2_v2 以上にするべきとも記しています。

バージョン命名規則とレプリケーション リージョン

Azure Compute Gallery には 3 つの階層があります。ギャラリー、イメージ定義（発行元、オファー、SKU、OS 状態、Hyper-V 世代、セキュリティの種類）、イメージ バージョンです。イメージ バージョン名は MajorVersion.MinorVersion.Patch 形式でなければならず、latest はメジャー、マイナー、パッチの順に最も大きいものに解決されます。私は Windows ビルドとパッチ月をエンコードする規則を使っており、例えば現在のイメージ定義における 2026 年 11 月の累積更新は 2026.11.0、同月のホットフィックス再構築は 2026.11.1 です。発行元、オファー、SKU の値は出発点にした Marketplace イメージと揃えておくと、ポータルで OS バージョンが一目で分かります。これはドキュメント化されたベスト プラクティスです。

レプリケーションについて Compute Gallery の概要は具体的な指針を示しています。本番イメージには最低 3 レプリカを保持する、同時に作成する VM 20 台ごとに 1 レプリカ追加する、リージョンが対応していれば ZRS にバージョンを保存する、本番とテストでギャラリーを分ける、災害復旧のために別リージョンに 2 つのギャラリーを持つ。AVD ドキュメントはさらに、セッション ホスト更新は対象イメージに最低 2 レプリカを求めること、ホスト プールと別サブスクリプションにあるギャラリー イメージはサポートされないことを付け加えています。追加リージョンへのレプリケーションは「場合によっては数時間かかる」とされ、これは後述の所要時間に関わります。

初日から有効にしておく価値のある安全設定が 3 つあります。検証に合格するまでバージョンに excludeFromLatest を設定し、そこから何も自動デプロイされないようにする。safetyProfile.allowDeletionOfReplicatedLocations を false にして、稼働中のホストが依存するリージョンを誰も削除できないようにする。ギャラリーにリソース ロックをかける。Trusted Launch を使う場合、API バージョン 2025-03-03 以降で作成したイメージ定義は既定で Hyper-V 第 2 世代と TrustedLaunchSupported になり、プレビューの Trusted Launch 検証はバージョンが有効と判定されるまで最低 1 時間を追加する点に注意してください。

AVD イメージ更新とホスト プール パッチ戦略

戦略の問いは、ホスト プール作成時に下す 1 つの決定に集約されます。標準管理かセッション ホスト構成か、です。Microsoft のホスト プール管理アプローチのページは、このアプローチは後から変更できず、セッション ホスト構成はプール ホスト プール専用だと明言しています。これらの自動化ホスト プールの登場は 2026 年 6 月の Azure Virtual Desktop 更新まとめで紹介しました。この節は運用の詳細です。

自動化ホスト プール向けのセッション ホスト更新

セッション ホスト構成を持つホスト プールには 2 つのサブリソースがあります。セッション ホスト構成はホストがどうあるべきかを定義します。イメージ、VM サイズ、OS ディスクの種類、セキュリティの種類、ドメイン参加、ネットワーク、可用性ゾーン、Key Vault からの管理者資格情報、タグ、任意のカスタム構成スクリプトです。セッション ホスト管理ポリシーはホストをどのように作成し更新するかを定義します。タイム ゾーン、バッチ サイズ（ポータルの既定値は 1）、サインアウト遅延（既定 2 分、0〜60 分で設定可能）、サインアウト メッセージ、元の VM を削除するかどうかです。

構成を変更して更新をスケジュールすると、セッション ホスト更新は次の手順で動きます（Microsoft の記述に私の言い換えを加えたものです）。

  1. 名前順に最初のバッチを選び、接続中のユーザーに通知メッセージを送り、残ったユーザーをサインアウトさせる前に設定された遅延時間だけ待つ。
  2. 該当ホストをドレイン モードにし、ホスト プールから削除する。Active Directory のコンピューター オブジェクトは削除されない。
  3. 更新後の構成から同数の新しい VM を SessionHostName-DateTime という名前で作成する。OS のホスト名は元のまま維持されるため、ドメイン参加ホストは既存のコンピューター オブジェクトとグループ ポリシーの適用範囲を引き継ぐ。
  4. 新ホストをプールに参加させ、ドレイン モードを解除する。
  5. 元の VM を削除する。

バッチが始まる前に、initial と呼ばれる 1 台のホストだけが先に更新され、エンドツーエンドのプロセスが機能することを確かめます。initial が失敗すると更新は停止します。Microsoft 自身の例は 10 ホストでバッチ サイズ 3 のプールで、initial 1 台、続いて 3 台ずつ 3 バッチ、全体を通して最低 7 台が利用可能です。更新は最大 2 週間先までスケジュールでき、構成ガイドはセッション ホストあたり約 20 分、各バッチは並行して処理されると述べています。

PowerShell ではプレビューの Az.DesktopVirtualization モジュール（5.3.0 以降）を使います。構成を特定のギャラリー バージョンに向け、ポリシーを調整し、スケジュールします。

powershell
Update-AzWvdSessionHostConfiguration -HostPoolName 'hp-fin-prod' -ResourceGroupName 'rg-avd-prod' `
  -ImageInfoType 'Custom' `
  -CustomInfoResourceID '/subscriptions/<sub>/resourceGroups/rg-avd-images/providers/Microsoft.Compute/galleries/acg_avd/images/win11-ms-m365/versions/2026.11.0'

Update-AzWvdSessionHostManagement -HostPoolName 'hp-fin-prod' -ResourceGroupName 'rg-avd-prod' `
  -ScheduledDateTimeZone 'Mountain Standard Time' -UpdateMaxVmsRemoved 5 `
  -UpdateLogOffDelayMinute 15 -UpdateLogOffMessage 'Maintenance: save your work and sign out.' `
  -UpdateDeleteOriginalVM $true

Invoke-AzWvdInitiateSessionHostUpdate -HostPoolName 'hp-fin-prod' -ResourceGroupName 'rg-avd-prod' `
  -ScheduledDateTime (Get-Date '2026-11-07 22:00')

Get-AzWvdSessionHostManagementsUpdateStatus -HostPoolName 'hp-fin-prod' -ResourceGroupName 'rg-avd-prod' |
  Format-List PercentComplete, ProgressSessionHostsCompleted, ProgressSessionHostsRollbackFailed

セッション ホスト更新が置き換えるのは、これまでこの作業をしていたスクリプトの山です。ドレイン モードを設定する Runbook、新しい VM をビルドするパイプライン、古い VM を削除するクリーンアップ ジョブ、どのホストがどのイメージか追跡するスプレッドシート。置き換えないのは構成管理です。Microsoft のガイダンスでは、ホストに手動で加えたものは更新後に消えるため、イメージ、Intune またはグループ ポリシー、あるいはカスタム構成スクリプトに置かなければなりません。ドキュメントにある運用ルールが 2 つあります。更新中はプールの自動スケーリングを無効にすること（そうしないと実行時エラーで失敗することがある）、そして既存のセッション ホストから新しいイメージをビルドする場合はキャプチャ前に C:\packages\plugin を削除すること（そうしないと DSC 拡張機能が新しい VM をプールに参加させられない）。

標準ホスト プールの従来型ローリング更新

標準ホスト プールにはこれらは一切なく、Microsoft の比較表もそう述べています。「自動化パイプラインやカスタム スクリプトなど、既存のツールとプロセスを使用」するのです。パターンはセッション ホスト更新が自動化しているものと同じで、それを自分で行います。

  1. 新しいイメージ バージョンから新しいセッション ホストを同じプールにデプロイし、そのプール用に生成した登録トークンを使う。新旧を区別できる名前を付ける。
  2. 旧ホストをドレイン モードにして、新規接続は新ホストに向かい既存セッションはそのまま残るようにする。自動スケーリングが割り当てられている場合は、自動スケーリングがドレイン モードを上書きするため、先に旧ホストへスケーリング プランの除外タグを付ける。
  3. ユーザーに通知し、セッションが空になるのを待つか、メンテナンス枠でサインアウトさせる。
  4. 旧ホストをプールから削除し、VM、ディスク、NIC を削除する。
powershell
Update-AzWvdSessionHost -ResourceGroupName 'rg-avd-prod' -HostPoolName 'hp-eng-std' `
  -Name 'avd-eng-07.corp.contoso.com' -AllowNewSession:$false

ドレイン モードには Desktop Virtualization Session Host Operator ロールが必要で、切り替え後およそ 60 秒間はポータルに古い状態が表示されることがあります。Nerdio Manager などのサードパーティ ツールは標準プール向けにこの同じ手順を自動化します。既に持っているなら使ってください。新しいプールを作るなら、セッション ホスト構成で作成してプラットフォームに任せましょう。

イメージ内再構築かインプレース パッチか

セッション ホスト更新のページは、更新済みイメージからホストを置き換えることが「継続的に繰り返されるスケジュールで各セッション ホストに個別に更新を配布・インストールするのではなく、コアとなるソース イメージ内で更新を管理するという推奨に沿う」と述べています。Microsoft のセキュリティに関する推奨事項は、ベース イメージを毎月パッチするよう付け加えています。それが戦略です。毎月の累積更新は新しいイメージ バージョンとして出荷され、ホストはそこから置き換えられます。

インプレース パッチにも役割は残ります。次のビルドを待てない緊急のセキュリティ修正です。Windows 11 Enterprise マルチセッションでドキュメント化された選択肢は、思われているより狭いものです。

方法Windows Enterprise マルチセッションに対するドキュメント上の位置づけ用途
Intune 設定カタログ、Windows Update for Business カテゴリ品質更新をサポート：アクティブ時間、延期、期限と猶予期間、一時停止。更新リングは非サポート。再構築の間に Entra 参加またはハイブリッド参加ホストを最新に保つ
Microsoft Configuration Managerドキュメント化済み：OS SKU 175 のクエリが Windows クライアント更新を使う自動展開ルールに供給する既に Configuration Manager を運用しているハイブリッド参加環境
WSUSマルチセッション FAQ が WSUS 経由の品質更新と機能更新を確認隔離ネットワーク
Azure Update Managerサポート対象イメージとカスタム イメージの一覧は Windows Server のみ。Windows クライアントやマルチセッション SKU は記載なしWindows Server ベースのセッション ホスト
自動 VM ゲスト パッチカスタム イメージは非サポート。サポート一覧は Windows Serverマルチセッションには該当しない
機能更新（例：24H2 から 25H2）プール ホスト プールではインプレース アップグレード非サポート常に新しいイメージ

機能更新の行が、プール ホスト プールに関する議論に決着をつけます。Windows バージョンの変更はイメージの変更であり、それ以外はありません。Intune はマルチセッションを独自の OS エディションとして扱うため、品質更新ポリシーを作るときは設定カタログで OS edition == Enterprise multi-session でフィルターしてください。さもないと、なぜ何も適用されないのかと午後を丸ごと費やすことになります。

推奨サイクル

サイクルアクション仕組み
第 2 火曜日と同じ週最新の Marketplace リリースまたは自前のベースから、その月の累積更新、アプリ更新、FSLogix を含むイメージ バージョン YYYY.MM.0 をビルドカスタム イメージ テンプレートまたは Image Builder パイプライン。excludeFromLatest を設定してギャラリーへ配布
3 営業日以内同じ構成のテスト ホスト プールで検証し、excludeFromLatest を解除検証プールでのセッション ホスト更新
次の週末のメンテナンス枠本番ホスト プールをバッチで新バージョンへ切り替えセッション ホスト更新、または標準プールのドレインと置き換え
臨時次のビルドまで数日以上ある場合、稼働中ホストに重大なセキュリティ修正を適用設定カタログの品質更新期限、Configuration Manager、または WSUS
年 2 回新しい Marketplace イメージを基に次の Windows 機能更新へ移行新しいイメージ定義またはバージョン、全ホスト置き換え
四半期ごと直近 2 つの既知の良好なリリースより古いイメージ バージョンを削除し、レプリカ数とリージョンを見直すギャラリーの定期整理

AVD イメージのバージョン管理とロールバック戦略

ロールバックは、前のイメージ バージョンが残っていれば安く、誰かがスナップショット ストレージを数 GB 節約するために削除していれば高くつきます。直近 2 つの既知の良好なバージョンを残し、イメージ定義のリリース ノートに現在のバージョンを記し、本番が依存するものには BlockDeletionBeforeEndOfLife かリソース ロックを設定してください。

前のイメージ バージョンに固定する

本番ホスト プールを決して latest に向けないでください。セッション ホスト構成は正確なバージョンのリソース ID を参照し、動的自動スケーリングはその構成が示すものから新ホストを作成するので、固定することで決定論的なホストと簡単に取り消せる変更が得られます。セッション ホスト構成を持つホスト プールのロールバックは、前進と同じ操作です。前のバージョンのリソース ID で Update-AzWvdSessionHostConfiguration を実行し、再度セッション ホスト更新をスケジュールします。Microsoft 自身のロールバックへの意識は、ステータス オブジェクトの ProgressSessionHostsRollbackFailed に現れていますから、このカウンターを監視してください。

セッション ホスト更新は失敗をどう扱うか

ドキュメントは明確な失敗モデルを示しています。initial ホストが失敗すると、どのバッチも実行される前に更新が停止します。バッチが失敗した場合は、ポータルまたは Invoke-AzWvdControlSessionHostUpdate -Action Retry で一時停止、再開、キャンセル、再試行ができ、再試行は大きなバッチ サイズで散発的に起きる AgentRegistrationFailureGeneric エラーをたいてい解消します。一時停止したまま 2 週間以内に再開されない更新は自動的にキャンセルされます。復旧できないホストはドレイン モードのまま残されます。重要な注意点は、途中でキャンセルすると 2 つの OS ビルド、場合によっては 2 つのドメインにまたがる混在プールが残ることで、Microsoft はできるだけ早く別の更新をスケジュールして一貫性を取り戻すよう求めています。実務上は、キャンセルした更新の直後に前のバージョンへのロールバック更新を行うということで、プールを中途半端に放置してはいけません。また、失敗した更新はキャンセルされるまでホスト プールの削除をブロックし、いったんスケジュールされた更新は編集できず、キャンセルして再作成するしかないことにも注意してください。

標準ホスト プールをロールバックする

セッション ホスト更新がない場合、ロールバックはローリング パターンの逆です。前のギャラリー バージョンから新しい登録トークンでホストをデプロイし、問題のあるイメージのホストをドレインし、セッションが空になったら削除します。FSLogix がプロファイルを保持し、コンピューター アカウントは名前を維持した場合にのみ再利用されるため、2 世代のホストが 1 日共存できる命名規則にしてください。標準プールでギャラリーではなくマネージド イメージから VM を再構築しているなら、今がギャラリーへ移行する時です。マネージド イメージには戻るためのバージョン履歴がありません。

AVD イメージの更新にはどれくらいかかるか？

正直な答えは 3 つに分かれ、そのうち Microsoft の数値が付いているのは 1 つだけです。以下の範囲は私が実務で見ているもので、ドキュメント化されたアンカーは明示し、それ以外は Microsoft の数値ではなく典型的な範囲です。

段階典型的な範囲左右する要因ドキュメント上のアンカー
イメージ ビルド（Image Builder またはカスタム イメージ テンプレート）1〜3 時間インストーラーの数と大きさ、Windows Update ステップ、再起動、Teams と Office のインストール既定の buildTimeoutInMinutes は 240、最大 960。Windows ビルドは 60 未満にしない
新バージョンの Trusted Launch 検証（プレビュー）1 時間以上バージョン作成後のプラットフォーム検証最低 1 時間
Compute Gallery レプリケーションソース リージョンは数分。追加リージョンとレプリカ数により 1 時間から数時間占有イメージ サイズ、ターゲット リージョン数、レプリカ数「場合によっては数時間かかる」。各リージョンへの初回コピーにエグレス料金
テスト プールでの検証1〜2 営業日プラットフォームではなくアプリ所有者なし
セッション ホスト更新（ホストあたり）約 20 分割り当て解除、作成、ドメイン参加、エージェント登録セッション ホストあたり約 20 分
セッション ホスト更新（プール全体）initial と各バッチ、バッチあたり約 20 分ホスト数をバッチ サイズで割った数に、サインアウト遅延（0〜60 分）を加算プールあたり同時に 1 更新。最大 2 週間先までスケジュール可能

算出例（Microsoft の引用ではなく、ドキュメントの 20 分という数値からの導出です）。40 ホスト、バッチ サイズ 5、サインアウト遅延 15 分のプールでは、initial 1 台のあと 8 バッチが走ります。約 20 分の 9 ラウンドに遅延を加えて約 3 時間半、全期間で最低 35 ホストが利用可能です。バッチ サイズを半分にすれば作業枠は倍に、倍にすれば半分になりますが、同時に 10 ホストがサービス外になり、エージェント登録エラーの確率も上がります。バッチ サイズは焦りではなく同時接続の余裕から選んでください。

エンドツーエンドでは、「AVD イメージの更新にどれくらいかかるか」への現実的な答えはこうです。当日にビルドとレプリケーション、1〜2 日の検証、そして中規模プールで 2〜4 時間のメンテナンス枠。誰かが 30 分と言うなら、それは 1 台のホストの話です。

Spot インスタンスで AVD ホスト プールを自動化する：ドキュメントは何と言っているか

毎月この質問が検索されるので、ドキュメント化された立場を示します。Azure Spot VM は未使用容量を割引価格で、SLA なしで販売します。Azure が容量を取り戻したいとき、VM は 30 秒前の通知（Scheduled Events 経由でベスト エフォート配信）で削除されます。削除ポリシーは「割り当て解除」（既定。ディスクは課金され続け、クォータも消費）か「削除」です。B シリーズとプロモ サイズは対象外、Spot には別個のクォータ プールがあり、作成後に Spot へ、または Spot から変換することはできません。

Azure Virtual Desktop 側には、サポートするともしないとも書かれたドキュメントがありません。ホスト プール ウィザードに Spot オプションはなく、セッション ホスト構成スキーマには vmSizeId、diskInfo、securityInfo、diffDiskSettings はあっても優先度、削除ポリシー、課金プロファイルのプロパティはなく、AVD の新機能履歴にも Spot の項目はありません。Microsoft Q&A では、2024 年 4 月の質問に Microsoft 社員が、Spot は AVD には「少々リスクがある」「VDI は Azure Spot VM に適したワークロードではない」と答え、製品チームもコスト管理には自動スケーリングを勧めていると述べました。ボランティア モデレーターは唯一の回避策を説明しています。Spot VM を自分で作成し、ディレクトリに参加させ、登録トークンで標準ホスト プールに登録する、というものです。

そこから導かれる結論はこうです。

  • 標準ホスト プール上の開発、テスト、トレーニングのラボ：作業中にセッションが消えることを受け入れられるなら実用的。FSLogix でプロファイルを守り、取り残されたディスクに課金されないよう削除ポリシーを「削除」にし、ポータルの価格履歴ビューで過去の削除率が低いサイズを選ぶ。
  • 非永続的なプール型本番環境：私なら設計しません。30 秒の通知はほとんどの組織が設定するサインアウト遅延より短く、ユーザーは未保存の作業を失います。
  • セッション ホスト構成を持つ自動化ホスト プール：現時点では不可能。スキーマにそれを表現する場所がありません。

コスト目的で「ホスト プールを自動化する」サポートされた方法は自動スケーリングです。標準プール向けの電源管理スケーリングはホストのオン・オフを行い、セッション ホスト構成プール向けの動的自動スケーリングは最小と最大のプール サイズの間でホストの作成と削除も行います。作成と削除の動きだけが欲しいなら Minimum percentage of active hosts (%) を 100 に設定します。動的自動スケーリングは現在のセッション ホスト構成にあるイメージから新ホストをビルドするので、バージョンを固定する理由がもう 1 つ増えます。

コストのレバー：エフェメラル OS ディスク、予約、ドレイン時の割り当て解除、イメージ ストレージ

エフェメラル OS ディスク。 AVD の新機能ページは、エフェメラル OS ディスクのサポートを 2025 年 10 月にパブリック プレビュー、2026 年 6 月に利用可能と記載し、セッション ホスト構成スキーマは option: Local と placement: CacheDisk または TempDisk を持つ diffDiskSettings を公開しています。AVD の前提条件ページと FAQ はまだ追いついておらず、エフェメラル OS ディスクを非サポートとしているので、コミットする前に自分のリージョンで確認してください。エフェメラル OS ディスクのドキュメントが制約を定めています。イメージは VM サイズのキャッシュ、一時ディスク、または NVMe ディスクに収まる必要があり、Trusted Launch はそのうち 1 GiB を予約し、停止と割り当て解除、スナップショット、VM キャプチャ、Azure Backup はできず、再イメージ化でデータは消えます。この最後の点こそ、FSLogix を使うプール ホストで、かつ割り当て解除ではなく削除と再作成を行う動的自動スケーリングと組み合わせる場合にしか意味がない理由です。見返りは再イメージ化の高速化と OS ディスクの低遅延で、ベース ディスク料金は SSD ベース ディスクを選んだ場合にのみ発生します。

予約インスタンスと節約プラン。 AVD コスト ガイドは、自動スケーリング、Azure 節約プラン、予約 VM インスタンスをコンピューティングの 3 つのレバーとして挙げています。予約 VM インスタンスは 1 年または 3 年で、コンピューティングのみ（Windows ソフトウェア メーターは含まない）を対象とし、容量保証ではなく課金割引であり、2026 年 7 月 1 日以降は一部の VM シリーズで販売・更新されなくなるため、更新前に自分のシリーズを確認してください。コンピューティング節約プランは時間あたりのドル コミットメントでサイズやリージョンをまたいで適用され、動的自動スケーリングでサイズが変わるプールに向いています。常時稼働のベースライン（アクティブ ホストの最小割合）を予約か節約プランで賄い、弾力的な部分は従量課金のままにしておきます。

ドレイン時の割り当て解除。 自動スケーリングのランプダウンはホストをドレイン モードにし、強制サインアウトを有効にしていれば待機時間後にユーザーをサインアウトさせ、その後割り当てを解除します。切断されたセッションは統合計算上アクティブ扱いなので、Set time limit for disconnected sessions ポリシーと組み合わせないとプールはゼロに到達しません。セッション ホスト更新も電源状態を尊重します。すべてのホストが割り当て解除されたプールも更新できるので、夜間に停止しているプールでイメージを切り替える最も安い方法になります。

イメージ ストレージ。 Compute Gallery 自体は無料で、各バージョンの占有サイズに対するスナップショット ストレージにレプリカ数とリージョン数を掛けたもの、加えて各リージョンへの初回コピーのエグレス料金を支払います。Microsoft の例では、127 GB の OS ディスクで実際の占有が 10 GB のイメージを 3 リージョンに各 2 レプリカで複製すると、10 GB のスナップショット 6 個として課金されます。現在のバージョンは広く複製し、古いバージョンは 1 リージョンだけに残し、直近 2 つの既知の良好なバージョンより古いものは削除し、クリーンアップ スクリプトが本番に触れないようテスト ギャラリーは分けておきます。

セッション ホストが Azure VM ではなく Azure Local や Arc 対応サーバーで動いている場合、イメージ ビルドのパイプラインは同じですが展開ツールが異なります。これはハイブリッド Arc 対応サーバー プレビューの記事で扱いました。このプロセスに影響する機能の変更履歴は、Azure Virtual Desktop の新機能シリーズで追ってください。

何をすべきか

  1. 今、ホスト プールごとに管理アプローチを決める。新しいプール ホスト プールにはセッション ホスト構成を使い、カスタム パイプラインに残す必要があるものだけ標準のままにする。後から切り替えることはできない。
  2. 本番用の Compute Gallery と別のテスト用ギャラリーを作り、それぞれに Marketplace の発行元、オファー、SKU を反映し、Hyper-V 第 2 世代と TrustedLaunchSupported を持つイメージ定義を用意する。
  3. パッチ チューズデーから 2 日以内に YYYY.MM.0 を生成するカスタム イメージ テンプレートまたは Image Builder パイプラインを立ち上げ、検証まで excludeFromLatest を設定して配布する。
  4. 本番リージョンに最低 3 レプリカ、同時作成ホスト 20 台ごとに 1 レプリカを設定し、可能なら ZRS を使い、allowDeletionOfReplicatedLocations を false にする。
  5. ホストで手動構成しているものを、マルチセッション エディションでフィルターした Intune 設定カタログ ポリシーかカスタム構成スクリプトに移す。
  6. セッション ホスト構成プールでは管理ポリシーを一度決める。同時接続の余裕から導いたバッチ サイズ、平易なメッセージ付きの 10〜15 分のサインアウト遅延、UpdateDeleteOriginalVM を $true に。
  7. 標準プールでは、自動スケーリングの除外タグを含む 4 段階のドレインと置き換え手順をスクリプト化し、ソース管理に置く。
  8. 臨時修正向けの Intune 品質更新ポリシーを作り、機能更新は常に新しいイメージだと受け入れる。
  9. 各プールのロールバック コマンドを文書化し、四半期に 1 回検証プールでテストする。
  10. Spot の要望は Q&A の立場に照らして審査し、業務側が譲らない場合はラボ プールを標準管理にして手動登録ホストに振り向ける。
  11. 常時稼働のベースラインに予約または節約プランを見積もり、2026 年 7 月以降も自分の VM シリーズが予約可能か確認する。
  12. セッション ホスト構成を通じてイメージ バージョンをホストの VM タグに書き込み、「このホストはどのイメージか」という問いにポータルで答えられるようにする。

よくある質問

AVD イメージを更新してホスト プールに展開するにはどれくらい時間がかかりますか？ 3 つの段階で見積もります。Image Builder またはカスタム イメージ テンプレートのビルドは既定 240 分のタイムアウトの下で動き、通常 1〜3 時間で完了します。Compute Gallery のレプリケーションは複数リージョンにコピーすると数時間かかることがあります。その後のセッション ホスト更新はホストあたり約 20 分で、ホストはバッチ単位で置き換わるため、40 ホストでバッチ サイズ 5 なら約 3 時間です。当日にビルドし、次のメンテナンス枠で展開する計画を立ててください。

AVD セッション ホストはインプレースでパッチすべきですか、それとも毎月イメージを再構築すべきですか？ Microsoft のセッション ホスト更新ドキュメントは、コアとなるソース イメージ内で更新を管理するのが推奨される方法だと述べ、セキュリティ ガイダンスはベース イメージを毎月パッチするよう求めています。インプレース パッチはビルドの間に出る緊急のセキュリティ修正に役割が残ります。その用途には Intune 設定カタログの品質更新ポリシー、Configuration Manager、または WSUS を使ってください。Windows Update for Business の更新リングと Azure Update Manager は Windows Enterprise マルチセッション向けにドキュメント化されていないためです。

AVD イメージを前のバージョンにロールバックするにはどうすればよいですか？ 少なくとも前の Compute Gallery バージョンを残し、本番環境を決して latest に向けないでください。セッション ホスト構成を持つホスト プールでは、前のバージョンのリソース ID を指定して Update-AzWvdSessionHostConfiguration を実行し、再度セッション ホスト更新をスケジュールします。標準ホスト プールでは、前のバージョンから新ホストをビルドし、登録トークンで追加し、問題のあるホストをドレインしてセッションが空になったら削除します。

Azure Spot VM を AVD セッション ホストとして使えますか？ AVD のポータル、セッション ホスト構成スキーマ、デプロイ テンプレートのいずれにもドキュメント化された Spot オプションはありません。Spot VM には SLA がなく、30 秒前の通知で削除されます。Microsoft Q&A で Microsoft 社員が、VDI は Spot に適したワークロードではないと述べ、代わりに自動スケーリングを推奨しました。使い捨てのラボでどうしても Spot を使いたい場合は、VM を自分で作成し、登録トークンで標準ホスト プールに登録してください。

セッション ホスト更新と標準ホスト プールの更新の違いは何ですか？ セッション ホスト更新は、セッション ホスト構成を使って作成したホスト プールのネイティブ機能です。構成を変更して更新をスケジュールすると、サービスがセッション ホスト管理ポリシーに従ってバッチ単位でホストをドレイン、置き換え、削除します。標準ホスト プールにはこの機能がなく、新しいイメージから新ホストをビルドし、登録トークンで参加させ、旧ホストをドレインして自前のスクリプトやパイプラインで削除します。管理方式はホスト プール作成時に固定されます。

人手が足りないときは、Big Hat Group が米国とカナダの組織向けに Azure Virtual Desktop アーキテクチャと Windows 365 のコンサルティングを提供しています。イメージ パイプラインのレビューからホスト プールの全面的な再設計まで対応します。ディスカバリー コールを予約して、お使いの環境についてお話しください。

ソース