Azure Virtual Desktop で Start VM on Connect、自動スケーリング、App Attach、セッション ホストの更新を使っている場合、今回確認すべきポイントは「Azure Virtual Desktop サービス プリンシパルまたはマネージド ID に、必要なロールが正しいスコープで付与されているか」です。単にロール名を知るだけでは不十分で、どの ID に付与するか、サブスクリプション スコープが必要か、マネージド ID へ移行済みかまで確認する必要があります。
本記事では、2026年6月末時点の Microsoft Learn「Assign Azure RBAC roles or Microsoft Entra roles to a service principal」の内容をもとに、Azure 管理者が実務で確認すべき影響範囲、設定変更、移行期限、失敗しやすいポイントを整理します。なお、日本語版ページの更新表示は 2026年6月30日です。(Microsoft Learn)
Azure Virtual Desktop のロール割り当てで何が重要なのか
Azure Virtual Desktop の一部機能では、Microsoft のサービスがユーザー環境内の VM、ストレージ、ホスト プールなどを操作するために、Azure RBAC ロールまたは Microsoft Entra ロールをサービス プリンシパルへ割り当てる必要があります。
対象になりやすい機能は次の4つです。
| 機能 | ロール確認が必要になる主な場面 | 確認を怠った場合に起きやすい問題 |
|---|---|---|
| App Attach | Azure Files を使い、セッション ホストが Microsoft Entra ID 参加の場合 | アプリ パッケージの参照やマウントに失敗する |
| 自動スケーリング | セッション ホストの起動・停止・作成・削除を Azure Virtual Desktop に任せる場合 | スケーリング プランが期待どおり動作しない |
| セッション ホストの更新 | セッション ホスト構成を使って VM イメージやサイズを更新する場合 | ホスト作成・更新が止まる、または更新処理が失敗する |
| Start VM on Connect | ユーザー接続時に停止中 VM を自動起動する場合 | ユーザー接続時に VM が起動しない |
重要なのは、これらが「管理者ユーザーへの権限付与」ではなく、Azure Virtual Desktop サービスが利用する ID への権限付与である点です。Azure RBAC では、ユーザー、グループ、サービス プリンシパル、マネージド ID などのセキュリティ プリンシパルに対して、特定のスコープでロールを割り当てます。スコープは管理グループ、サブスクリプション、リソース グループ、リソース単位で設定できますが、広く付ければよいわけではなく、必要最小限のロールとスコープを選ぶのが基本です。(Microsoft Learn)
今回の更新ポイントは「サービス プリンシパル」と「マネージド ID」の使い分け
対象ページでは、Azure Virtual Desktop のロール割り当て先として、主に次の2種類を扱っています。
| 割り当て先 | 位置づけ | 実務上の判断 |
|---|---|---|
| Azure Virtual Desktop サービス プリンシパル | Azure Virtual Desktop サービスをテナント内で表す ID | App Attach、自動スケーリング、Start VM on Connect では引き続き重要 |
| マネージド ID | ホスト プールなど Azure リソースに紐づく ID | セッション ホスト構成・セッション ホスト更新では優先的に確認する |
Microsoft Learn では、マネージド ID は Azure Virtual Desktop ホスト プールでプレビューとして扱われており、システム割り当てマネージド ID とユーザー割り当てマネージド ID を利用できます。一方で、App Attach、自動スケーリング、Start VM on Connect は、マネージド ID ではなく Azure Virtual Desktop サービス プリンシパル方式でロールを割り当てる必要がある機能として整理されています。(Microsoft Learn)
つまり、管理者が取るべき行動は「全部をマネージド ID に置き換える」ではありません。機能ごとに次のように切り分ける必要があります。
| 利用している機能 | 基本方針 |
|---|---|
| Start VM on Connect | Azure Virtual Desktop サービス プリンシパルに必要な RBAC ロールを付与する |
| 従来の電源管理型自動スケーリング | Azure Virtual Desktop サービス プリンシパルにサブスクリプション スコープでロールを付与する |
| 動的自動スケーリング | サービス プリンシパルの RBAC と、セッション ホスト構成側のマネージド ID 要件を両方確認する |
| App Attach | Azure Files 利用条件に応じて、対象サービス プリンシパルへのロール付与を確認する |
| セッション ホストの更新 | ホスト プールのマネージド ID 有無を重点的に確認する |
確認すべきサービス プリンシパルのアプリケーション ID
Azure Virtual Desktop では、登録時期や過去の利用状況によって、エンタープライズ アプリケーション名が「Azure Virtual Desktop」または「Windows Virtual Desktop」と表示されることがあります。さらに、Azure Virtual Desktop classic と Azure Resource Manager ベースの Azure Virtual Desktop を両方使っていた環境では、似た名前のアプリが複数見える場合があります。
そのため、名前だけで判断せず、アプリケーション ID とオブジェクト ID を確認してからロールを割り当てることが重要です。対象ページでは、次のアプリケーション ID が示されています。(Microsoft Learn)
| サービス プリンシパル名 | アプリケーション ID |
|---|---|
| Azure Virtual Desktop / Windows Virtual Desktop | 9cdead84-a844-4324-93f2-b2e6bb768d07 |
| Azure Virtual Desktop Client / Windows Virtual Desktop Client | a85cf173-4192-42f8-81fa-777a763e6e2c |
| Azure Virtual Desktop ARM Provider / Windows Virtual Desktop ARM Provider | 50e95039-b200-4007-bc97-8d5790743a63 |
特に注意したいのは、Azure portal 上で同じような名前のエンタープライズ アプリケーションが複数表示されるケースです。この場合は、Microsoft Entra ID で対象アプリを検索し、プロパティのオブジェクト ID を控えてから、IAM のメンバー選択画面で一致するものだけを残すのが安全です。
必要な管理者権限
ロールを付与する側の管理者にも、当然ながら十分な権限が必要です。
| 操作 | 必要な権限 |
|---|---|
| Azure RBAC ロールを割り当てる | Microsoft.Authorization/roleAssignments/write 権限。代表例は Owner または User Access Administrator |
| Microsoft Entra ロールを割り当てる | Privileged Role Administrator または同等の権限 |
| Azure CLI / Azure PowerShell で作業する | Azure Virtual Desktop 用の CLI 拡張機能、Az.DesktopVirtualization モジュール、または Azure Cloud Shell |
対象ページでは、Azure RBAC ロール割り当てにはサブスクリプションに対する Microsoft.Authorization/roleAssignments/write が必要であり、Microsoft Entra ロール割り当てには Privileged Role Administrator または同等権限が必要とされています。(Microsoft Learn)
実務では、作業者に Owner を一時付与する運用も見られますが、監査や権限分離の観点では User Access Administrator や Role Based Access Control Administrator を使い、作業後に不要な権限を外すほうが安全です。
機能別に確認すべきロールとスコープ
Start VM on Connect はサブスクリプション スコープが必須
Start VM on Connect を使う場合、Azure Virtual Desktop サービス プリンシパルに Desktop Virtualization Power On Contributor ロールを割り当てます。ポイントは、リソース グループやホスト プールではなく、対象のホスト プールとセッション ホスト VM を含む Azure サブスクリプションをスコープにすることです。Microsoft Learn では、サブスクリプションより低いスコープに割り当てると、接続時の VM 起動が正しく機能しないと説明されています。(Microsoft Learn)
| 項目 | 内容 |
|---|---|
| 割り当て先 | Azure Virtual Desktop サービス プリンシパル |
| 主なロール | Desktop Virtualization Power On Contributor |
| 推奨スコープ | 対象 VM を含む Azure サブスクリプション |
| 失敗例 | コスト削減のつもりで VM を停止したが、ユーザー接続時に起動しない |
この機能は「ユーザー体験」に直結します。ロール不足は管理画面上の設定ミスとして見えにくく、ユーザーから「接続できない」「起動が遅い」という問い合わせで発覚しがちです。
自動スケーリングは方式によって必要ロールが変わる
Azure Virtual Desktop の自動スケーリングでは、電源管理型と動的自動スケーリングで必要な権限が異なります。
電源管理型のスケーリング プランでは、Azure Virtual Desktop サービス プリンシパルに Desktop Virtualization Power On Off Contributor ロールを、サブスクリプション スコープで割り当てる必要があります。サブスクリプションより低いスコープにすると、自動スケーリングが正しく動作しないとされています。(Microsoft Learn)
動的自動スケーリングでは、セッション ホスト VM の作成・削除・更新・起動・停止まで行うため、Desktop Virtualization Power On Off Contributor に加えて Desktop Virtualization Virtual Machine Contributor も必要になります。これもサブスクリプション スコープでの割り当てが前提です。(Microsoft Learn)
| 自動スケーリング方式 | 必要な主なロール | 注意点 |
|---|---|---|
| 電源管理型 | Desktop Virtualization Power On Off Contributor | VM の起動・停止が中心 |
| 動的自動スケーリング | Desktop Virtualization Power On Off Contributor、Desktop Virtualization Virtual Machine Contributor | VM の作成・削除・更新も対象 |
動的自動スケーリングでは、ネットワーク要件も見落としやすい点です。Microsoft Learn では、動的自動スケーリングがセッション ホスト作成時に Azure Virtual Desktop Agent をデプロイするため、移行が完了するまで wvdhpustgr0prod.blob.core.windows.net へのアクセスが必要であり、アクセスできない場合は CustomerVmNoAccessToDeploymentPackageException で失敗すると説明されています。(Microsoft Learn)
App Attach は Azure Files と Entra 参加の組み合わせに注意
App Attach では、アプリケーションをセッション ホストやイメージへ直接インストールせず、アプリケーション パッケージをユーザー セッションへ動的にアタッチします。運用上はイメージ肥大化を抑えられる一方で、パッケージを置くファイル共有へのアクセス権が重要になります。
セッション ホストが Microsoft Entra ID 参加で、Azure Files を使用する場合、Microsoft Learn では Reader and Data Access ロールを Azure Virtual Desktop と Azure Virtual Desktop ARM Provider の両方のサービス プリンシパルへ割り当てる必要があるとされています。また、今後の更新では Azure Virtual Desktop ARM Provider サービス プリンシパルへの割り当てが不要になる予定であることも記載されています。(Microsoft Learn)
| 確認項目 | 実務での見方 |
|---|---|
| セッション ホストの参加方式 | Microsoft Entra ID 参加か、AD DS 参加か |
| パッケージ配置先 | Azure Files か、別の SMB 共有か |
| ロール付与先 | Azure Virtual Desktop と Azure Virtual Desktop ARM Provider を確認 |
| 将来変更 | ARM Provider への割り当てが不要になる可能性を運用手順に反映 |
App Attach のトラブルでは、アプリ登録やパッケージ形式ばかり確認しがちですが、Azure Files、RBAC、サービス プリンシパルの組み合わせを最初に確認すると原因切り分けが早くなります。
セッション ホストの更新はマネージド ID 移行を重点確認
セッション ホストの更新では、ホスト プール内の既存 VM が割り当て解除または削除され、更新された構成で新しい VM が作成されます。対象にできる変更には、VM イメージ、VM サイズ、ディスクの種類、セキュリティの種類、ドメイン参加資格情報、Intune 登録、ローカル管理者資格情報、カスタム PowerShell スクリプトなどが含まれます。(Microsoft Learn)
この機能は「パッチを1台ずつ当てる」仕組みではなく、標準化した構成でセッション ホストを作り直す発想に近いものです。そのため、手動で追加したファイル、レジストリ、証明書などは、イメージ、Intune、グループ ポリシー、カスタム構成スクリプトに含めておかないと更新後に失われます。(Microsoft Learn)
また、セッション ホストの更新では次の制限も確認が必要です。
| 注意点 | 管理者が取るべき対応 |
|---|---|
| 更新中は既存 VM が置き換わる | 事前にテスト ホスト プールで検証する |
| 自動スケーリングと競合する可能性 | 更新前に自動スケーリングを無効化し、完了まで維持する |
| Azure Monitor Agent が自動で入らない場合がある | Azure Policy などで自動展開を設計する |
| グローバル Azure クラウドのみ利用可能 | Azure Government や 21Vianet 運営の Azure では利用可否を別途確認する |
| Key Vault のプライベート ネットワーク アクセス | マネージド ID が必要になる |
Microsoft Learn では、セッション ホストの更新に関して、Key Vault のプライベート ネットワーク アクセスにはマネージド ID が必要であること、また Azure Government や 21Vianet 運営の Azure では利用できないことが制限事項として示されています。(Microsoft Learn)
移行期限として見るべきポイント
今回のロール割り当て確認で最も重要な移行観点は、セッション ホスト構成を使うホスト プールでマネージド ID が必要になる流れです。
Microsoft の Azure Virtual Desktop 新機能情報では、セッション ホスト構成を使うホスト プールについて、2025年9月19日以降の新規作成、2025年10月15日以降の既存構成更新、2025年11月15日以降のセッション ホスト作成で、マネージド ID が追加されていない場合に制限が発生する予定として案内されていました。(Microsoft Learn)
一方、マネージド ID 構成ページの日本語版では、セッション ホスト構成で構成されたホスト プールでは、2025年11月1日からセッション ホスト追加にマネージド ID が必要になると記載されています。(Microsoft Learn)
| 日付 | 対象 | 管理者の見方 |
|---|---|---|
| 2025年9月19日 | セッション ホスト構成を使う新規ホスト プール作成 | 新規作成時にマネージド ID が前提になる |
| 2025年10月15日 | 既存ホスト プールのセッション ホスト構成更新 | マネージド ID 未追加だと構成更新が止まる可能性がある |
| 2025年11月1日または11月15日 | 既存ホスト プールへのセッション ホスト追加 | 2026年時点では、猶予期間ではなく移行済み確認の段階 |
日付表記に差があるため、運用判断では最新の Microsoft Learn と Azure portal の表示を確認してください。ただし、どちらの記載に基づいても、2026年時点では「今後対応すればよい」段階ではありません。セッション ホスト構成を使うホスト プールは、マネージド ID が割り当て済みか、必要な RBAC が付与されているかを優先的に点検すべきです。
Azure portal でロールを割り当てる基本手順
Azure portal で Azure Virtual Desktop サービス プリンシパルへ Azure RBAC ロールを割り当てる場合は、次の流れで確認します。
| 手順 | 作業内容 |
|---|---|
| 1 | Microsoft Entra ID を開き、対象サービス プリンシパルのアプリケーション ID で検索する |
| 2 | 該当するエンタープライズ アプリケーションを開き、名前とオブジェクト ID を控える |
| 3 | サブスクリプションを開き、Access control (IAM) からロール割り当てを追加する |
| 4 | 必要なロールを選択する |
| 5 | メンバー選択で先ほどのエンタープライズ アプリケーションを指定する |
| 6 | 同名アプリが複数ある場合は、オブジェクト ID が一致するものだけを残す |
| 7 | Review + assign で割り当てを完了する |
この流れは、対象ページで説明されている Azure portal 手順を実務向けに整理したものです。特に、同じ名前のアプリが複数ある場合にオブジェクト ID で確認する手順は省略しないでください。(Microsoft Learn)
PowerShell と Azure CLI での割り当て例
運用環境では、手作業よりも PowerShell や Azure CLI で手順を残すほうが監査しやすくなります。対象ページでは、Azure Virtual Desktop サービス プリンシパルに対して、アプリケーション ID を指定して RBAC ロールを割り当てる例が示されています。(Microsoft Learn)
PowerShell の例です。
Get-AzSubscription
$subId = "<SubscriptionID>"
$parameters = @{
RoleDefinitionName = "Desktop Virtualization Power On Off Contributor"
ApplicationId = "9cdead84-a844-4324-93f2-b2e6bb768d07"
Scope = "/subscriptions/$subId"
}
New-AzRoleAssignment @parametersAzure CLI の例です。
subId="<SubscriptionID>"
az role assignment create \
--assignee "9cdead84-a844-4324-93f2-b2e6bb768d07" \
--role "Desktop Virtualization Power On Off Contributor" \
--scope "/subscriptions/$subId"Start VM on Connect の場合は、ロール名を Desktop Virtualization Power On Contributor に変更します。動的自動スケーリングの場合は、Desktop Virtualization Power On Off Contributor に加えて Desktop Virtualization Virtual Machine Contributor も確認します。
Microsoft Entra ロールを割り当てる場合の注意点
Azure RBAC ロールは Azure リソースへのアクセスを制御します。一方、Microsoft Entra ロールはテナントやディレクトリに関わる権限です。対象ページでは、Azure Virtual Desktop サービス プリンシパルへ Microsoft Entra ロールを割り当てる場合、Azure portal の Microsoft Entra ID から「Roles and administrators」を開き、対象ロールを選んでサービス プリンシパルを追加する手順が示されています。(Microsoft Learn)
実務では、次の点を確認してください。
| 確認項目 | 理由 |
|---|---|
| 本当に Entra ロールが必要か | Azure リソース操作だけなら Azure RBAC で足りる場合が多い |
| Privileged Role Administrator 権限で作業しているか | Entra ロール割り当てには高い権限が必要 |
| サービス プリンシパル名ではなくアプリケーション ID で検索したか | 同名アプリの誤選択を避けるため |
| 永続付与が必要か | 一時的な検証で過剰権限を残さないため |
管理者が今すぐ確認すべきチェックリスト
Azure Virtual Desktop を運用している管理者は、まず以下の順番で確認すると効率的です。
| 確認順 | チェック内容 | 判断基準 |
|---|---|---|
| 1 | 対象機能の棚卸し | Start VM on Connect、自動スケーリング、App Attach、セッション ホスト更新を使っているか |
| 2 | 対象ホスト プールの特定 | 本番、検証、リージョン、サブスクリプションごとに一覧化する |
| 3 | サービス プリンシパルの確認 | アプリケーション ID とオブジェクト ID で正しい ID を確認する |
| 4 | ロールとスコープの確認 | 機能ごとにサブスクリプション スコープが必要か確認する |
| 5 | マネージド ID の確認 | セッション ホスト構成を使うホスト プールに ID があるか確認する |
| 6 | 失敗ログの確認 | 自動スケーリング、ホスト作成、App Attach、接続時 VM 起動の失敗履歴を見る |
| 7 | IaC・手順書の更新 | 新規ホスト プール作成時に同じ設定を再現できるようにする |
特に複数サブスクリプションで Azure Virtual Desktop を運用している場合、「1つのサブスクリプションでは動くが、別のサブスクリプションでは動かない」という差分が発生しやすくなります。自動スケーリングや Start VM on Connect は、対象のホスト プールとセッション ホストを含む各サブスクリプションでロール割り当てが必要です。(Microsoft Learn)
よくある失敗と回避策
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| Start VM on Connect が有効なのに VM が起動しない | Power On Contributor をリソース グループや VM にだけ付けている | サブスクリプション スコープで Azure Virtual Desktop サービス プリンシパルに付与する |
| 自動スケーリングが一部ホストでだけ失敗する | 対象サブスクリプションにロールがない、またはネットワーク要件を満たしていない | サブスクリプション単位でロールと必要エンドポイントを確認する |
| App Attach でパッケージ参照に失敗する | Azure Files と Entra 参加の組み合わせでサービス プリンシパルの権限が不足 | Reader and Data Access の割り当て先を確認する |
| 同名の Azure Virtual Desktop アプリに誤って割り当てた | classic 利用履歴や名称変更の影響で複数表示される | アプリケーション ID とオブジェクト ID で照合する |
| セッション ホスト更新後に設定が消えた | VM が作り直され、手動カスタマイズが引き継がれていない | イメージ、Intune、GPO、カスタム構成スクリプトへ組み込む |
| ユーザー割り当てマネージド ID を外したのに権限が残る | ホスト プールとの関連付け解除では、マネージド ID 自体の RBAC は削除されない | 不要なロール割り当ても別途棚卸しして削除する |
マネージド ID の削除について、Microsoft Learn では、システム割り当ては削除時に関連メタデータが自動削除される一方、ユーザー割り当てではホスト プールとの関連付けだけが削除され、マネージド ID に割り当てられたアクセス許可は変更されないと説明されています。(Microsoft Learn)
グローバル環境での運用ポイント
グローバル企業や複数リージョン運用では、単一テナント・単一サブスクリプションよりも確認漏れが起きやすくなります。次の観点で標準化しておくと、後からの障害対応が楽になります。
| 観点 | 標準化すべき内容 |
|---|---|
| サブスクリプション設計 | AVD 用サブスクリプションごとに必要ロールをテンプレート化する |
| リージョン | ホスト プール、スケーリング プラン、App Attach の配置ルールを明確にする |
| ID 管理 | サービス プリンシパル方式とマネージド ID 方式を混在させず、機能別に設計する |
| 変更管理 | ロール追加・削除をチケット化し、割り当て後に検証ログを残す |
| 監査 | 定期的に Azure Virtual Desktop 関連のロール割り当てをエクスポートする |
| クラウド種別 | Azure Government、21Vianet、中国クラウドなどでは機能提供状況を別途確認する |
特にセッション ホスト更新は、公式ドキュメント上でグローバル Azure クラウドのみ利用可能とされている制限があります。多国籍環境では「本社テナントでは使えるが、政府クラウドや中国クラウドでは同じ前提で使えない」可能性を設計段階で確認してください。(Microsoft Learn)
次に取るべき対応
今回の更新ポイントは、Azure Virtual Desktop に新しい画面が増えたというより、既存機能を安全に動かすための ID と権限の再点検です。
まずは、Start VM on Connect、自動スケーリング、App Attach、セッション ホスト更新を使っているホスト プールを一覧化してください。次に、対象サブスクリプションで Azure Virtual Desktop サービス プリンシパルに必要な Azure RBAC ロールが付いているか、セッション ホスト構成を使うホスト プールにマネージド ID が割り当てられているかを確認します。
最後に、確認結果を IaC、運用手順書、変更管理フローへ反映してください。Azure Virtual Desktop の権限設定は、一度動けば終わりではありません。新しいホスト プール、新しいサブスクリプション、動的自動スケーリングの導入、App Attach の拡張時に同じミスを繰り返さないよう、機能別のロール割り当て表を運用標準として持つことが最も実務的な対策です。
コメント