Azure「Deploy Azure Virtual Desktop」2026年7月更新点｜影響範囲・設定・移行対応

Azure Virtual Desktopの展開手順を見直す際、「既存のホストプールも新方式へ移行しなければならないのか」「設定変更によってセッションホストや利用者にどのような影響が出るのか」が気になる管理者は多いでしょう。

2026年7月2日に更新されたMicrosoft Learnの「Deploy Azure Virtual Desktop – Azure Virtual Desktop」で、最初に押さえるべき点は次の3つです。

既存のStandard管理ホストプールに一律の移行期限は示されていません。一方、ホストプールの管理方式は作成後に変更できないため、Session Host Configurationを導入する場合は、新しいホストプールを作成して移行する必要があります。また、Session Host Configurationを利用する環境では、マネージドID、RBAC、Key Vaultの構成確認が重要です。

今回の更新は、単なるAzureポータルの操作手順変更ではありません。2026年6月に利用可能になったAutomated Host PoolsやDynamic Autoscalingを踏まえ、Azure Virtual Desktopのセッションホストを「誰が、どの仕組みで、どのライフサイクルまで管理するか」を明確に選ぶ内容になっています。(Microsoft Learn)

「Deploy Azure Virtual Desktop」2026年7月2日版の要点

現在のAzure Virtual Desktopでは、ホストプール作成時に次の2つの管理方式から選択します。

Session Host Configurationによる管理
Standard管理

Session Host Configurationは、Azure PowerShellなどではManagementType = 'Automated'として扱われます。本記事では、これを「SHC管理」と表記します。

比較項目	SHC管理（Automated）	Standard管理
対応するホストプール	Pooledのみ	Pooled、Personal
セッションホストの配置先	Azure	Azure、Azure Local
セッションホストの作成	ホストプールの台数を変更し、Azure Virtual Desktopが作成	Azureポータル、スクリプト、パイプラインなどで作成
構成の統一	Session Host Configurationで統一	管理者が独自に統一
イメージ更新	Session host updateを使用	独自の更新手順やパイプラインを使用
オートスケール	電源オン・オフに加え、VMの作成・削除に対応	主にVMの電源オン・オフ
既存の自動化ツール	従来のStandard向けツールはそのまま利用できない	既存のIaC、スクリプト、外部製品を利用しやすい
作成後の方式変更	変更不可	後からSHCを追加できない

SHC管理では、Azure Virtual Desktopの外部で作成したVMを登録トークンによって追加する方式は利用できません。セッションホストの作成、更新、スケールはAzure Virtual Desktop側の仕組みに統一する必要があります。(Microsoft Learn)

最大の変更点はホストプール作成時の「管理方式の固定化」

最も注意すべき点は、ホストプールの管理方式を後から変更できないことです。

たとえば、既存のStandard管理ホストプールに対して、後からSession Host Configurationだけを追加することはできません。反対に、SHC管理で作成したホストプールを、従来の登録トークンや独自スクリプト中心の運用へ切り替えることもできません。(Microsoft Learn)

これは、ホストプール作成時の選択が単なる設定項目ではなく、セッションホストのライフサイクル全体を決める設計判断であることを意味します。

SHC管理が向いている環境

次の条件に当てはまる場合は、SHC管理を検討しやすいでしょう。

Pooledホストプールを利用する
全セッションホストを同じイメージと設定で統一したい
セッションホストを使い捨て可能な構成として運用できる
イメージ更新時にVMを再作成する方式を採用できる
利用状況に応じてセッションホストを自動的に作成・削除したい
セッションホスト管理をAzure Virtual Desktopの標準機能へ集約したい

たとえば、Windows 11 Enterprise multi-sessionを使用し、業務アプリをゴールデンイメージへ組み込んでいる環境では、SHC管理によってホスト間の設定差異を抑えやすくなります。

Standard管理を継続すべき環境

次のケースでは、Standard管理の方が現実的です。

Personalホストプールを利用する
Azure Localへセッションホストを配置する
Azure DevOpsやGitHub Actionsなどの既存パイプラインを継続したい
Terraform、独自PowerShell、構成管理製品でVMを管理している
VMごとに異なる設定や例外構成が必要
Session host updateを利用できないクラウドで運用する
更新時にVMを再作成できないステートフルな構成がある

既存の運用が安定している場合、SHC管理が利用可能になったことだけを理由に移行する必要はありません。標準化による効果と、既存自動化の作り直しに必要な工数を比較して判断します。

マネージドIDとRBACの設定を確認する

SHC管理では、ホストプールへマネージドIDを割り当てることで、セッションホストの作成、削除、更新に必要なAzure Resource Manager操作を実行できます。

マネージドIDを付与するだけでは不十分です。操作対象のリソースグループ、サブスクリプション、Key Vaultに対して、必要な権限を割り当てる必要があります。

対象	主な役割・権限	確認ポイント
ホストプールのマネージドID	Desktop Virtualization Virtual Machine Contributor	セッションホストを配置するリソースグループまたはサブスクリプションに付与
Key Vault	Key Vault Secrets User、または対応するシークレット読み取り権限	ローカル管理者やドメイン参加用資格情報を読み取れること
デプロイ実行者	Desktop Virtualization Contributor	ホストプール、ワークスペース、アプリケーショングループの作成に必要
Azure上のセッションホスト	Virtual Machine Contributor	VM作成に必要
Azure Local上のセッションホスト	Azure Stack HCI VM Contributor	Azure LocalのVM操作に必要

Azureポータルでシステム割り当てマネージドIDを指定した場合、実行者にRBAC割り当て権限があれば、必要な権限を自動割り当てできます。ただし、自動割り当てに任せたままにせず、デプロイ後に実際のスコープを確認してください。(Microsoft Learn)

マネージドIDの導入予定日はすでに経過している

Microsoftが2025年9月に公開した更新情報では、SHCを利用するホストプールに対して、マネージドIDを段階的に必須化する予定が示されていました。

公表された日付	予定された影響
2025年9月19日	Azureポータルで新規SHCホストプールを作成する際にマネージドIDが必要
2025年10月15日	マネージドIDのない既存SHCホストプールでは、SHCを更新できなくなる
2025年11月15日	マネージドIDのない既存SHCホストプールでは、セッションホストを作成できなくなる

これらは当初「予定」として案内された日付ですが、2026年7月時点ではすべて経過しています。既存のSHCホストプールにマネージドIDがない場合は、ポータルやAPIでの実際の動作を確認し、優先度の高い是正項目として扱うべきです。(Microsoft Learn)

マネージドIDだけですべての権限を置き換えられるわけではない

Azure Virtual Desktopのホストプール向けマネージドIDは、専用ページではプレビューとして案内されています。また、次の機能ではAzure Virtual Desktopのサービスプリンシパルを引き続き使用するケースがあります。

Autoscale
Start VM on Connect
Microsoft Entra参加セッションホストとAzure Filesを組み合わせる一部のApp Attach構成

そのため、マネージドIDを付与した直後に、既存のサービスプリンシパルからRBACを一括削除してはいけません。機能ごとの依存関係を確認し、不要であることを検証してから権限を整理します。(Microsoft Learn)

Key Vaultのネットワーク設定と資格情報を見直す

SHC管理でローカル管理者やAD DSドメイン参加用の資格情報を使用する場合、Key Vaultの構成がデプロイ成否に直結します。

最低限、次の項目を確認してください。

ホストプールのマネージドIDがシークレットを読み取れる
Key Vault Secrets Userが適切なスコープで割り当てられている
Azure Resource Managerのテンプレートデプロイが許可されている
Key Vaultのネットワーク設定が想定どおりになっている
シークレットの有効期限切れや資格情報のロックがない
AD DS参加用アカウントが対象OUへコンピューターアカウントを作成・再利用できる

Session host updateでプライベートネットワーク接続のKey Vaultを使用する場合は、マネージドIDが必要です。マネージドIDを使わない構成では、Key Vaultをすべてのネットワークからアクセス可能にする必要があるため、セキュリティ面でもマネージドIDを優先した方がよいでしょう。(Microsoft Learn)

なお、SHCで実行するカスタムPowerShellスクリプトのURLは、パブリックインターネットから名前解決およびアクセスできる必要があります。社内限定URLやプライベートエンドポイントだけで公開しているスクリプトを指定すると、更新に失敗する可能性があります。(Microsoft Learn)

Session host updateは「上書き更新」ではなくVMの再作成

SHC管理におけるSession host updateは、既存VMへパッチを上書きする機能ではありません。

既存のセッションホストを割り当て解除または削除し、新しい構成のVMを作成してホストプールへ登録します。そのため、変更内容だけでなく、利用者の切断、同時利用可能なVM数、監視エージェントの再導入まで考慮する必要があります。(Microsoft Learn)

分類	対象となる設定
更新可能	VMイメージ、VMサイズ、ディスク種類、セキュリティ種類、AD DS参加資格情報、Intune登録、ローカル管理者資格情報、カスタムPowerShellスクリプト
更新後も維持	ネットワーク構成、配置場所、可用性に関する構成
更新では変更不可	OSディスクのサイズ
別途再導入が必要になるもの	Azure Virtual Desktop Insights用のAzure Monitor AgentやLog Analytics Agentなど

Session host updateでは、最初に1台だけを更新して一連の処理を検証し、成功後に指定したバッチサイズで残りのVMを更新します。バッチサイズは、同時に利用できなくなるセッションホスト数の上限です。(Microsoft Learn)

既定の管理ポリシーをそのまま使用しない

AzureポータルでSHCホストプールを作成すると、既定のSession Host Management Policyも作成されます。

設定	Azureポータルの既定値	日本企業での確認例
タイムゾーン	UTC	日本時間で実行するならAsia/Tokyoへ変更
同時に更新する最大VM数	1台	冗長性と更新時間を踏まえて調整
ログオフまでの待機時間	2分	社内通知ルールに合わせて延長を検討
ログオフメッセージ	You will be signed out	日本語で理由、時刻、再接続方法を案内
作成後のドレインモード	無効	追加構成や検証が必要なら有効化を検討

特に見落としやすいのがタイムゾーンです。既定値のUTCを日本時間と誤認してスケジュールすると、業務時間中に更新が始まる可能性があります。(Microsoft Learn)

更新前に確保すべき空き容量

10台のセッションホストに対してバッチサイズを3台に設定した場合、初期検証後は最大3台が同時に利用できなくなります。

通常時に10台のうち9台相当の負荷がかかっている環境では、残り7台でユーザーを収容できません。更新前に、次のいずれかを行います。

更新時間帯の同時接続数が少ないことを確認する
一時的にセッションホスト数を増やす
バッチサイズを小さくする
利用部門ごとに更新時間を分ける
新規接続先となる更新済みホストの動作を先に確認する

接続中の利用者には管理者が設定したメッセージが表示され、待機時間の経過後にサインアウトされます。業務影響を抑えるには、Azure上の更新予約だけでなく、利用者への事前通知も変更手順へ組み込む必要があります。(Microsoft Learn)

監視エージェントの消失に注意する

Session host update後のVMには、Azure Virtual Desktop Insightsで使用するAzure Monitor AgentやLog Analytics Agentが自動的に導入されない場合があります。

更新そのものが成功していても、監視データだけが途切れることがあるため、次の方法で再導入を自動化します。

Azure PolicyによるAzure Monitor Agentの展開
VMイメージへの必要コンポーネントの組み込み
更新後チェックで拡張機能とデータ収集ルールを検証
Azure Virtual Desktop Insightsで新しいセッションホストを再確認

「VMが正常に起動した」だけで更新完了と判断せず、ログ、メトリック、アラート、セキュリティ製品の接続状態まで確認してください。(Microsoft Learn)

Azure Government、21Vianet、Azure Localへの影響

Azure Virtual Desktopはグローバルに提供されていますが、SHC管理やSession host updateをすべてのクラウドで同じように利用できるわけではありません。

環境	2026年7月時点での主な注意点	管理者が行うこと
グローバルAzure	PooledホストプールでSHC管理を利用可能。Session host updateも利用可能	マネージドID、バッチ更新、イメージ管理を設計
West US 3	Automated Host Poolsは非対応	別リージョンまたはStandard管理を検討
Azure Government	Session host updateは非対応。Azure Local連携はプレビューで、ポータルからのプロビジョニングも非対応	公開Azureと同じ手順を前提にせず、対応APIや手動手順を確認
Azure operated by 21Vianet	Session host updateは非対応。Azure Local連携はプレビュー	中国向けドキュメントと実際のポータル機能を基準に設計
Azure Local	SHC管理は非対応。Standard管理を使用	Azure Local 23H2以降、Azure登録、接続性、論理ネットワーク、ライセンスを確認
Azure Extended Zones	セッションホストの配置に対応	対象Extended Zoneへのサブスクリプション登録と、送信規則を持つAzure Load Balancerを準備

Session host updateはグローバルAzureクラウドのみで利用でき、Azure US Governmentや21Vianetでは利用できません。また、Azure LocalのセッションホストにはSHC管理を使用できません。(Microsoft Learn)

Azure Localでは、Azure上のセッションホストとAzure Local上のセッションホストを同じホストプールに混在させることもできません。Azure Localは最低でも23H2が必要で、Azureへの安定した接続、Windowsイメージ、論理ネットワーク、VMのライセンス認証も必要です。(Microsoft Learn)

Azure Extended Zonesへ配置する場合は、対象ゾーンへの利用登録に加え、セッションホストを配置する仮想ネットワーク上で、送信規則を持つAzure Load Balancerが必要です。(Microsoft Learn)

Standard管理からSHC管理への移行期限

少なくとも2026年7月2日時点の公式ドキュメントでは、既存のStandard管理ホストプールをSHC管理へ移行する一律の期限は示されていません。

ただし、管理方式は作成後に変更できません。そのため、「設定を有効化して切り替える」のではなく、次のような新規ホストプールへの移行が必要です。(Microsoft Learn)

安全に移行する手順

既存環境を棚卸しする
ホストプール種別、VMイメージ、アプリケーション、GPO、Intune、FSLogix、ネットワーク、スケーリングプラン、監視エージェント、セキュリティ製品を一覧化します。
SHC管理への適合性を判定する
Pooledであること、セッションホストを再作成できること、Azure Localではないこと、対象クラウドでSession host updateを利用できることを確認します。
マネージドIDとKey Vaultを先に構成する
ホストプール作成後に権限不足で止まらないよう、RBACの割り当てスコープと資格情報の保管方法を決めます。
検証用の新規ホストプールを作成する
本番と同じイメージ、ネットワーク、ドメイン参加方式を使用し、少数のセッションホストから開始します。
パイロットユーザーで接続試験を行う
Windows Appからの接続、アプリ起動、印刷、リダイレクト、FSLogix、サインイン時間、プロファイルの引き継ぎを確認します。
新しいアプリケーショングループへ段階的に割り当てる
いきなり全ユーザーを切り替えず、部署やグループ単位で移行します。新旧両方のデスクトップがフィードに表示されないよう、割り当ても整理します。
旧ホストプールをドレインモードにする
新規接続を新環境へ誘導し、既存セッションが終了したことを確認してから旧環境を停止します。
一定期間後に旧環境を削除する
ロールバック期間中は旧ホストプールを保持し、業務アプリ、監視、バックアップ、問い合わせ状況に問題がないことを確認してから削除します。

デプロイ前後にネットワーク接続を検証する

公式ドキュメントでは、セッションホストを展開する前に、対象サブネットからAzure Virtual Desktopに必要なFQDNとエンドポイントへ接続できることを確認するよう案内されています。

さらに、最初のセッションホストがネットワークへ参加した時点で、Azure Virtual Desktop Agent URL Toolを実行します。接続確認を省略すると、EXPIRED_MACHINE_TOKENや必要エンドポイントの不足に関連する登録エラーが発生しやすくなります。(Microsoft Learn)

実務では、次の順番で進めると原因を切り分けやすくなります。

対象サブネットのDNS、プロキシ、ファイアウォールを確認する
必要なFQDNとエンドポイントへのTCP 443通信を許可する
最初のセッションホストを1台だけ作成する
Agent URL Toolで接続性を検証する
Azure Virtual Desktop Agentの登録状態を確認する
問題がないことを確認してから台数を増やす

Azure Virtual Desktopへの接続のために、セッションホストへインターネットからの受信ポートを開放する必要はありません。また、Azureポータルからセッションホストを作成する場合、PowerShell DSCが使用されるため、WinRMを無効化しないよう注意してください。(Microsoft Learn)

管理者が今すぐ確認すべきチェックリスト

優先度	確認項目	問題があった場合の対応
最優先	各ホストプールがSHC管理かStandard管理か	管理方式ごとに運用手順と担当を分ける
最優先	SHCホストプールにマネージドIDがあるか	マネージドIDを割り当て、RBACを設定
最優先	Key Vaultから資格情報を読み取れるか	Key Vault Secrets Userとネットワーク設定を確認
最優先	Azure Government、21Vianet、Azure Localで非対応機能を前提にしていないか	クラウドごとに設計と手順を分離
高	Session Host Management Policyのタイムゾーン	日本環境ではAsia/Tokyoなど適切な値へ変更
高	バッチ更新中の残存キャパシティ	バッチサイズ、更新時間、一時増設を調整
高	更新後に監視・セキュリティエージェントが入るか	Azure Policyやイメージで自動化
高	カスタムスクリプトへ外部から到達できるか	公開可能な安全な配布先へ配置
高	必要なFQDNとエンドポイントへ接続できるか	Agent URL Toolで検証
中	Standard向け既存パイプラインをSHCへ流用していないか	SHC対応の作成・更新方式へ変更
中	旧環境へ戻せる移行計画があるか	新旧ホストプールの並行期間を設ける

Azure PowerShellを利用している場合は、次のコマンドでホストプールのプロパティを確認できます。

Get-AzWvdHostPool `
  -Name "<HostPoolName>" `
  -ResourceGroupName "<ResourceGroupName>" |
  Format-List *

SHC管理で作成されたホストプールでは、ManagementTypeがAutomatedになります。あわせて、マネージドIDの種類、配置リージョン、ホストプール種別も確認してください。SHC対応のAzure PowerShellコマンドレットにはプレビュー版のAz.DesktopVirtualizationモジュールが必要になる場合があるため、運用端末と自動化環境のモジュールバージョンも管理対象に含めます。(Microsoft Learn)

まず管理方式、次にIDと更新手順を確認する

2026年7月2日版の「Deploy Azure Virtual Desktop」で重要なのは、デプロイ画面の操作ではなく、ホストプールのライフサイクル設計です。

既存のStandard管理ホストプールを急いで移行する必要はありません。しかし、新規ホストプールを作成する際は、将来の自動化まで考えたうえで管理方式を選ぶ必要があります。作成後に方式を変更できないためです。

管理者は、まず全ホストプールのManagementTypeを棚卸ししてください。そのうえで、SHC管理ではマネージドID、RBAC、Key Vault、Session Host Management Policyを確認します。Standard管理では、既存のイメージ更新やスケール処理が属人化していないかを見直します。

最後に、グローバルAzure、Azure Government、21Vianet、Azure Localで利用可能な機能を分けて管理し、検証用ホストプールで更新と接続試験を行ってから本番へ反映することが、安全な対応手順です。

この記事を書いた人

佐藤健司

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

Azure「Deploy Azure Virtual Desktop」2026年7月更新点｜影響範囲・設定・移行対応

「Deploy Azure Virtual Desktop」2026年7月2日版の要点