Azure Virtual Desktopで既存のホストプールにセッションホストを追加する場合、2026年7月2日更新の公式情報で特に確認すべき点は、ホストプールの管理方式によって追加手順が変わること、Session host configurationを使うホストプールではAzure portal中心の操作になること、そして旧ARMテンプレート方式やマネージドID要件など、すでに期限を迎えた変更があることです。特に、標準管理のホストプールとSession host configuration付きホストプールを同じ感覚で扱うと、PowerShellや既存の自動化パイプラインがそのまま使えず、追加作業や監視設計でつまずきやすくなります。
この記事では、Azure の「Add session hosts to a host pool – Azure Virtual Desktop」の更新ポイントを、影響範囲、設定変更、移行期限、管理者が確認すべきポイントに分けて整理します。Azure Virtual Desktopを運用している管理者、ホストプールの拡張を予定しているインフラ担当者、Azure LocalやAzure Extended Zonesを含む構成を検討している担当者は、作業前のチェックリストとして活用してください。
Azure Virtual Desktopの「Add session hosts to a host pool」とは
「Add session hosts to a host pool」は、Azure Virtual Desktopで既存のホストプールにセッションホストを追加するための手順をまとめたMicrosoft Learnの公式ドキュメントです。2026年7月2日に更新され、ホストプールの管理方式、Azure Local、Azure Extended Zones、登録キー、Session host configurationを使う場合の制約などが整理されています。Microsoft Learnでは、ドキュメントの最終更新日が2026年7月2日と示されています。(Microsoft Learn)
セッションホストとは、ユーザーが実際にサインインしてデスクトップやアプリを利用する仮想マシンです。ホストプール、ワークスペース、アプリケーショングループを作成しただけでは、ユーザーは接続先を持ちません。利用者を受け入れるには、ホストプールにセッションホストを追加する必要があります。公式ドキュメントでも、ホストプール、ワークスペース、アプリケーショングループを作成した後、ユーザー接続や追加容量のためにセッションホストを追加する必要があると説明されています。(Microsoft Learn)
実務上は、次のようなタイミングでこの手順が重要になります。
- 新規にAzure Virtual Desktop環境を構築する
- 既存ユーザー数の増加に合わせてホスト数を増やす
- 繁忙期やプロジェクト単位で一時的に容量を増やす
- 標準管理からSession host configurationを前提とした運用へ設計を見直す
- Azure LocalやAzure Extended Zonesを含む分散配置を検討する
単に「VMを増やす」作業ではなく、ホストプールの管理方式、認証方式、ネットワーク、ライセンス、監視、登録キーの有効期限まで含めて確認する必要があります。
今回の更新で管理者が最初に見るべきポイント
今回の公式情報で特に重要なのは、セッションホストの追加方法がホストプールの管理方式に強く依存する点です。Azure Virtual Desktopのホストプールには、大きく分けて「標準管理」と「Session host configurationを使う管理方式」があります。公式ドキュメントでは、Session host configurationを使うホストプールではAzure portalから追加数を指定し、Azure Virtual Desktopが構成に基づいて自動的にセッションホストを作成するとされています。一方、標準管理ではAzure portalでVMを作成して追加する方法に加え、Azure CLI、Azure PowerShell、自動化パイプラインなどで作成したVMを別途ホストプールに登録する方法も選べます。(Microsoft Learn)
| 確認項目 | 影響する内容 | 管理者の判断ポイント |
|---|---|---|
| ホストプールの管理方式 | 追加方法、更新方法、自動化可否 | 既存パイプラインを維持するなら標準管理、標準化と自動作成を重視するならSession host configurationを検討 |
| 追加先の基盤 | Azure、Azure Local、Azure Extended Zones | 同じホストプールにAzure上のホストとAzure Local上のホストを混在できない点に注意 |
| 登録キー | ホストプールへの参加認可 | 展開期間に合わせて有効期限を設定し、期限切れで登録失敗しないようにする |
| マネージドID | Session host configurationでの追加処理 | 2025年11月1日以降の要件として、対象ホストプールで確認が必要 |
| 監視 | デプロイ履歴、Log Analytics | Session host configuration利用時はAzure Resource Managerのデプロイ履歴だけに頼らない |
まず確認すべきなのは、「自社のホストプールがどちらの管理方式か」です。後からSession host configurationを追加できると誤解しやすいですが、Microsoft Learnでは、ホストプールの管理方式は作成時に設定され、後から変更できないと明記されています。Session host configurationなしで作成したホストプールに、後から追加することもできません。(Microsoft Learn)
ホストプールの管理方式による違い
Session host configurationを使うホストプール
Session host configurationは、セッションホストの構成をホストプール側で保持し、その構成に基づいて作成、更新、スケールを管理する方式です。公式情報では、VMイメージ、VM名プレフィックス、リソースグループ、VMサイズ、OSディスク、ドメイン参加、ネットワーク、リージョン、可用性ゾーン、セキュリティタイプ、管理者資格情報、タグ、カスタムPowerShellスクリプトなどが構成情報に含まれると説明されています。(Microsoft Learn)
この方式のメリットは、セッションホストの構成をそろえやすいことです。たとえば、10台のホストを追加するたびにVMサイズ、イメージ、サブネット、ドメイン参加設定を手入力していた環境では、入力ミスや構成差分が発生しやすくなります。Session host configurationを使えば、あらかじめ定義した構成をもとに追加できるため、標準化された運用に向いています。
ただし、制約もあります。Session host configurationを使うホストプールでは、現時点でPowerShellによるセッションホスト追加は利用できず、Azure portalから追加する形になります。公式ドキュメントでは、Session host configuration付きホストプールにセッションホストを追加する場合、PowerShellは利用できないと記載されています。(Microsoft Learn)
また、この管理方式はプール型ホストプールでのみ利用できます。Microsoft Learnでは、Session host configurationを使う場合、Azure Virtual Desktopサービス外の標準管理向けツールでセッションホストの作成、更新、スケールを行うことはできないと説明されています。(Microsoft Learn)
標準管理のホストプール
標準管理は、従来どおり管理者がVM作成、更新、スケール、登録を制御する方式です。既存のIaC、CI/CD、Azure CLI、Azure PowerShell、Configuration Manager、Intune、自社スクリプトなどでセッションホストを管理している組織では、標準管理のほうが運用に合う場合があります。
標準管理では、Azure Virtual Desktopサービスを使ってAzure portalからVM作成と登録を一括で行うこともできますし、別の方法で作成したVMにAzure Virtual Desktop AgentとAgent Boot Loaderをインストールして、登録キーでホストプールに参加させることもできます。公式ドキュメントでは、Azure Virtual Desktop外の自動化パイプラインなどでVMを作成した場合、別途セッションホストとして登録する必要があると説明されています。(Microsoft Learn)
判断基準は明確です。
| 運用方針 | 向いている管理方式 |
|---|---|
| 既存の自動化パイプラインを使い続けたい | 標準管理 |
| VMイメージや設定のばらつきを抑えたい | Session host configuration |
| 動的オートスケールでホストの作成・削除まで任せたい | Session host configuration |
| 独自スクリプトや構成管理ツールで細かく制御したい | 標準管理 |
| これから新規にプール型AVDを設計する | Session host configurationを優先検討 |
影響範囲：誰が対応すべきか
今回の更新ポイントは、Azure Virtual Desktopを利用しているすべての組織に同じ影響があるわけではありません。特に影響が大きいのは、次のような環境です。
既存ホストプールにセッションホストを追加する予定がある環境
ユーザー追加や性能不足に対応するためにホスト数を増やす場合、まずホストプールの管理方式を確認してください。Session host configuration付きのホストプールでは、Azure portalから追加数を指定する流れになります。標準管理のホストプールでは、Azure portalで新規VMを作成して追加するか、外部で作成したVMを登録キーで参加させるかを選びます。(Microsoft Learn)
Azure Localを使う、または検討している環境
Azure Local上にセッションホストを追加する場合、追加の前提条件があります。公式ドキュメントでは、Azure LocalインスタンスがAzureに登録されていること、最低バージョンとして23H2が必要であること、オンプレミスネットワークからAzureへの安定した接続、Windows OSイメージ、論理ネットワークなどが必要とされています。(Microsoft Learn)
また、同じホストプール内でAzure上のセッションホストとAzure Local上のセッションホストを混在させることはできません。これは設計上の重要な制約です。既存のAzure上のホストプールにAzure Localのホストを後から混ぜるのではなく、配置先ごとにホストプールを分ける設計が必要です。(Microsoft Learn)
さらに、Azure GovernmentおよびAzure operated by 21Vianet、中国向けAzureにおけるAzure Local上のAzure Virtual Desktopはプレビュー扱いです。グローバル展開する企業は、商用Azure、政府クラウド、中国リージョンで同一の前提にしないよう注意してください。(Microsoft Learn)
Azure Extended Zonesを使う環境
Azure Extended Zonesにセッションホストを展開する場合は、該当するExtended Zoneにサブスクリプションが登録されていることに加え、展開先仮想ネットワークにアウトバウンドルールを持つAzure Load Balancerが必要です。公式ドキュメントでも、Extended Zonesへの展開にはサブスクリプション登録とロードバランサーのアウトバウンドルールが前提として挙げられています。(Microsoft Learn)
ユーザーに近い場所へ配置して遅延を下げたい場合にExtended Zonesは有効ですが、通常リージョンと同じ感覚で追加できるわけではありません。ネットワーク設計とアウトバウンド通信の確認を先に済ませてください。
設定変更で注意すべきポイント
登録キーの有効期限は展開期間に合わせる
標準管理で外部作成したVMをホストプールに登録する場合、登録キーが必要です。登録キーはセッションホストがホストプールへ参加するための認可情報で、指定した期間だけ有効です。公式ドキュメントでは、対話的な展開では1〜4時間程度、複数日にまたがる段階展開では最大27日までの範囲で展開期間をカバーする有効期限を選ぶ考え方が示されています。期限切れの場合、EXPIRED_MACHINE_TOKENで登録に失敗する可能性があります。(Microsoft Learn)
注意したいのは、長すぎる有効期限を安易に設定することです。登録キーはホストプール参加に関わる重要な情報です。作業期間に必要な長さを確保しつつ、不要に長く保持しない運用にしてください。
また、事前プロビジョニングしたホストを90日以上電源オフのままにすると、マシントークンが期限切れになります。公式ドキュメントでは、影響を受けるVMを90日ごとに少なくとも20分起動し、トークンを自動更新させることが推奨されています。(Microsoft Learn)
Session host configurationではLog Analyticsを有効にする
Session host configurationを使うホストプールでは、診断情報がAzure MonitorのLog Analyticsに記録され、Azure Resource Managerのデプロイ履歴には表示されません。公式ドキュメントでも、Session host configurationを使うホストプールではLog Analyticsを有効にすることが推奨されています。(Microsoft Learn)
これは運用上かなり重要です。障害発生時に「デプロイ履歴を見ても何も分からない」となりやすいため、追加作業の前にLog Analyticsワークスペースとの連携を確認しておきましょう。
WinRMを無効化しない
Azure portalからセッションホストを作成・追加する場合、Windows Remote Management、WinRMを無効化しないことも明記されています。PowerShell DSCがWinRMを必要とするためです。(Microsoft Learn)
セキュリティ強化の一環でWinRMを一律無効化している環境では、AVDのデプロイ処理が失敗する可能性があります。セッションホスト用イメージ、ベースラインポリシー、GPO、Intune構成プロファイルなどでWinRMを制御していないか確認してください。
Microsoft Entra参加ホストはAADLoginForWindows拡張機能を前提にする
Microsoft Entra ID参加のセッションホストを作成する場合、公式ドキュメントでは、Azure portalまたはAzure Virtual DesktopサービスのARMテンプレート使用時に自動で追加・構成されるAADLoginForWindows VM拡張機能を使う方法のみがサポート対象として示されています。(Microsoft Learn)
手動でVMを作成してから後付けで構成する場合は、サポートされる手順から外れないように注意が必要です。特に、Entra ID参加、Intune登録、条件付きアクセス、多要素認証を組み合わせる環境では、ユーザーがサインインできるかを本番追加前に検証してください。
移行期限・期限切れの変更点
旧ARMテンプレート方式のAzure portal体験は2025年9月1日まで
公式ドキュメントには、Azure portal経由でARMテンプレートを使ってセッションホストを作成する従来方式を、2025年9月1日まで利用できる旨が記載されています。2026年7月時点ではこの期限はすでに過ぎています。(Microsoft Learn)
そのため、現在確認すべきことは「これから移行するか」ではなく、次の2点です。
| 確認内容 | 対応 |
|---|---|
| 運用手順書に旧ARMテンプレート方式が残っていないか | 現行のAzure portal手順または標準管理の登録手順へ更新 |
| 自動化パイプラインが旧ポータル体験を前提にしていないか | ARM/Bicep、CLI、PowerShell、Azure Virtual Desktop標準機能のどれで管理するか再整理 |
古い手順書のまま作業すると、ポータル画面や選択肢が一致せず、現場で判断が止まります。定期作業ではなく、年に数回しかホスト追加をしない環境ほど、手順書の更新を優先してください。
Session host configurationではマネージドID要件を確認する
別ドキュメントでは、Session host configurationを構成したホストプールでセッションホストを追加する場合、2025年11月1日以降はマネージドIDが必要になると説明されています。これはAzure Virtual Desktopサービスプリンシパルへの依存を置き換え、より安全な構成にするための変更です。(Microsoft Learn)
2026年7月時点では、この要件もすでに有効と考えて確認すべきです。Session host configurationを使っている、または新規に作成するホストプールでは、マネージドIDの割り当て、必要な権限、Azure Local利用時のReaderアクセスなどを確認してください。
セッションホスト追加の実務手順
Session host configurationを使う場合
Session host configuration付きホストプールでは、作業の中心はAzure portalです。公式ドキュメントでは、Azure portalでAzure Virtual Desktopを開き、対象ホストプールの「Session hosts」から「+ Add」を選び、追加するセッションホスト数を指定して作成する流れが示されています。(Microsoft Learn)
実務では、次の順番で確認すると失敗しにくくなります。
| 手順 | 確認すること |
|---|---|
| 事前確認 | ホストプールがSession host configuration付きか確認 |
| 構成確認 | VMイメージ、サイズ、サブネット、ドメイン参加、セキュリティタイプを確認 |
| 監視確認 | Log Analyticsが有効か確認 |
| 追加数指定 | 追加数と計算後のホストプール合計数を確認 |
| ポリシー確認 | 失敗したセッションホストのクリーンアップポリシー、ドレインモードポリシーを確認 |
| 作成後確認 | Session hosts一覧、ステータス、ユーザー接続テストを確認 |
特に見落としやすいのは、追加前にSession host configurationそのものを確認することです。古いイメージ、想定外のVMサイズ、不要な管理者資格情報、古いスクリプトURLが残っていると、その構成で新しいホストが作成されます。
標準管理でAzure portalから追加する場合
標準管理のホストプールでは、Azure Virtual Desktopサービスを使って、VM作成とホストプール登録を一括で行えます。追加時には、リソースグループ、名前プレフィックス、リージョン、可用性構成、セキュリティタイプ、イメージ、VMサイズ、OSディスク、ネットワーク、ドメイン参加、管理者アカウントなどを指定します。公式ドキュメントでは、名前プレフィックスは最大11文字、OS上のコンピューター名はサフィックス込みで最大15文字と説明されています。(Microsoft Learn)
本番用途では、OSディスクにPremium SSDを使うことが推奨されています。また、Azure Virtual Desktopはパブリック受信ポートを必要としないため、パブリック受信ポートは「No」を選ぶことが推奨されています。(Microsoft Learn)
ここでの失敗例として多いのは、既存ホストと異なるVMサイズやイメージを選んでしまうことです。Microsoft Learnでも、既存セッションホストがある場合は、VMサイズ、イメージ、名前プレフィックスを控え、同じ構成にそろえることが推奨されています。さらに、同一ホストプール内でMicrosoft Entra ID参加とActive Directoryドメイン参加を混在させるべきではないと説明されています。(Microsoft Learn)
自動化パイプラインなどで作成したVMを登録する場合
Azure Virtual Desktop外で作成したVMをセッションホストとして登録する場合は、Azure Virtual Desktop AgentとAzure Virtual Desktop Agent Boot Loaderを各VMにインストールし、登録キーを使ってホストプールに参加させます。公式ドキュメントでは、GUIまたはmsiexecによるコマンドラインで登録できると説明されています。(Microsoft Learn)
Windows Server OSを使う場合は、Remote Desktop Session Hostロールのインストールと再起動も必要です。(Microsoft Learn)
自動化する場合は、登録キーの有効期限を展開期間に合わせること、インストーラーの取得先とバージョンを固定しすぎないこと、登録後にセッションホストの状態がAvailableになるまで待つことが重要です。ステータスが一時的にUnavailableに見える場合もありますが、新しいAgentがある場合は自動的に更新されると説明されています。(Microsoft Learn)
追加後に必ず確認すべき運用項目
ライセンス
セッションホスト追加後は、ライセンス適用を確認してください。Azure Virtual Desktopサービスを使ってセッションホストを作成した場合、適切なAVDライセンスがあればWindowsまたはWindows Serverライセンスが自動適用されます。一方、Azure Virtual Desktop外で作成したホストでは、別途ライセンス適用が必要になる場合があります。Windows Server OSを使う場合は、RDS CALも必要です。Azure Local上のセッションホストでは、利用前にVMのライセンス認証が必要とされています。(Microsoft Learn)
ライセンスは「接続できるか」だけでは判断できません。監査対応やコスト最適化にも関係するため、追加作業後のチェック項目に入れておきましょう。
Microsoft Entra参加ホストのサインイン設定
Azure上のMicrosoft Entra ID参加セッションホストでは、シングルサインオンまたは以前の認証プロトコルの有効化、ユーザーへのRBACロール割り当て、多要素認証ポリシーの確認が必要です。公式ドキュメントでも、ユーザーがVMへサインインできるよう、これらの設定を確認する必要があると説明されています。(Microsoft Learn)
特に条件付きアクセスで「すべてのクラウドアプリ」に強い制御をかけている環境では、AVDクライアントからのサインインが想定どおり通るかを事前に検証してください。
ユーザー接続テスト
セッションホストが一覧に表示されたら、管理画面だけで完了と判断しないでください。実際にAzure Virtual Desktopクライアントからユーザーセッションを開始し、デスクトップまたはRemoteAppに接続できるか確認します。公式ドキュメントでも、ホストプール拡張後はAzure Virtual Desktopクライアントでユーザーセッションとしてホストをテストする流れが示されています。(Microsoft Learn)
確認すべき項目は次のとおりです。
| 確認項目 | 見るポイント |
|---|---|
| セッションホスト状態 | Availableになっているか |
| ドレインモード | 追加直後に意図せず有効になっていないか |
| ユーザープロファイル | FSLogix利用時に正常にマウントされるか |
| アプリ起動 | 業務アプリ、Teams、ブラウザ、Officeが起動するか |
| ネットワーク | 社内システム、ファイルサーバー、DNS解決に問題がないか |
| 監視 | Log Analytics、AVD Insights、アラートに反映されるか |
失敗しやすいポイントと対策
既存ホストと構成がずれる
ホストプール内のセッションホストは、できるだけ同じ構成にそろえるべきです。VMサイズ、イメージ、ドメイン参加方式、エージェント、アプリ構成がずれると、「特定のユーザーだけ遅い」「一部のホストだけアプリがない」といった調査しにくい障害につながります。
対策は、追加前に既存ホストの構成を棚卸しし、差分を意図的なものだけに限定することです。Session host configurationを使う場合も、構成情報が最新かどうかを必ず確認してください。
登録キーの期限切れで登録できない
段階的にVMを作成する場合、登録キーの期限切れが起きやすくなります。特に、夜間バッチ、承認待ち、メンテナンスウィンドウ待ちを挟む環境では注意が必要です。
対策は、展開計画に合わせて有効期限を設定し、27日を超える長期展開では途中で新しい登録キーを発行することです。期限を長くすればよいわけではなく、キーの管理責任者、保管場所、削除タイミングも決めておきましょう。
Session host updateやAutoscaleとの整合性を見落とす
Session host configurationを使う環境では、追加だけでなく更新やスケーリングも同じ設計の中で考える必要があります。Session host updateでは、構成変更後に既存VMを置き換える形で更新が行われ、選択されたホストはドレインモードに入り、同じ数の新しいホストが作成されます。(Microsoft Learn)
また、Dynamic Autoscalingはホストの電源オン・オフだけでなく、セッションホストの作成・削除まで行う方式で、プール型ホストプールかつSession host configurationでのみ利用できます。(Microsoft Learn)
追加作業だけを単独で考えると、後からスケール計画や更新計画と衝突することがあります。特に本番環境では、追加、更新、スケール、メンテナンス時間帯をまとめて設計してください。
管理者向けチェックリスト
セッションホストを追加する前に、最低限次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| ホストプール管理方式 | 標準管理か、Session host configuration付きか |
| 追加方法 | Azure portal、ARM/Bicep、自動化パイプライン、手動登録のどれを使うか |
| 既存構成 | VMサイズ、イメージ、名前プレフィックス、ドメイン参加方式 |
| 権限 | Desktop Virtualization Host Pool Contributor、Virtual Machine Contributorなど必要なRBAC |
| 登録キー | 有効期限、保管方法、期限切れ時の再発行手順 |
| マネージドID | Session host configuration利用時に要件を満たしているか |
| Azure Local | 23H2以上、Azure登録、Azure接続、OSイメージ、論理ネットワーク |
| Azure Extended Zones | サブスクリプション登録、Load Balancer、アウトバウンドルール |
| 監視 | Log Analytics、AVD Insights、アラート |
| ライセンス | Windowsライセンス、RDS CAL、Azure Localの認証 |
| 接続テスト | 実ユーザー権限でAVDクライアントから接続確認 |
このチェックリストを作業前レビューに組み込むだけでも、追加後の接続不可、構成差分、監視漏れ、ライセンス確認漏れをかなり減らせます。
今回の更新を踏まえた実務上の結論
2026年7月2日更新の「Add session hosts to a host pool – Azure Virtual Desktop」で最も重要なのは、セッションホスト追加を「VM追加作業」としてではなく、ホストプール管理方式に応じたライフサイクル管理作業として扱うことです。
標準管理では既存の自動化や柔軟な作成方法を活かせますが、構成差分の管理は運用側の責任になります。Session host configurationでは構成の標準化や動的な運用に向いている一方、後から管理方式を変えられないこと、PowerShellで追加できないこと、Log AnalyticsやマネージドIDの確認が重要になります。
すでに2025年9月1日の旧ARMテンプレート方式の期限、2025年11月1日のマネージドID要件は過去日です。これから対応する管理者は、古い手順を更新し、現行のAzure portal手順、Session host configuration、標準管理、自動化パイプラインの役割を再整理してください。次に取るべき行動は、対象ホストプールの管理方式を確認し、追加手順書と監視・ライセンス・接続テストのチェックリストを現行ドキュメントに合わせて更新することです。
コメント