Azure Virtual Desktop Hybrid：Arcサーバーアーキテクチャガイド

Azure Virtual Desktop はその歴史の大半をクラウド専用サービスとして過ごしてきました。AVD のブローカーを使いたければ、セッション ホストは Azure に（最近では Azure Local にも）置くしかなかったのです。Azure Virtual Desktop Hybrid はそのルールを破ります。コントロール プレーンは Azure に残り、セッション ホストは Azure Arc に接続できる任意の Windows マシンで動きます。実際には、既存の Hyper-V、VMware vSphere、Nutanix クラスター、ラックに並んだ物理 Windows Server、あるいは他クラウド上の仮想マシンがそれに当たります。2026 年 5 月に AVD on Arc 対応サーバーのパブリック プレビューについて書いたときは、有望ではあるものの検証専用のリリースでした。2026 年 9 月以降は一般提供となり、それ以来、米国とカナダの IT チームから同じ質問を受け続けています。何がどこで動くのか、費用はいくらか、Azure ホストのセッション ホストと比べて何を失うのか、そしてどう正しく構築するのか。本ガイドは、現行の Microsoft Learn ドキュメントを基準にこれらに答え、さらに顧客から「Hybrid は自社アーキテクチャに合うか」と問われたときに私が適用する設計判断を加えたものです。

Azure Virtual Desktop Hybrid とは何か

Microsoft の Azure Virtual Desktop Hybrid の概要は、この分担を簡潔に述べています。「Azure Virtual Desktop サービスは Azure に残り、アプリケーションとデスクトップはオンプレミスでホストされます。セッション ホストは Azure Arc 対応である必要があります。Azure Arc 拡張機能が AVD コンポーネントをインストールし、デバイスをホスト プールに登録します。」責任分界も同じく明確です。「Microsoft は Azure 内の Azure Virtual Desktop サービスを管理します。お客様はオンプレミスのマシン、ネットワーク、ホスティング インフラストラクチャを管理します。」

何がどこで動くか

4 つのことが順番に起こり、それぞれの場所がアーキテクチャそのものです。

1. 自社インフラストラクチャ上に Windows 仮想マシンまたはヘッドレス物理デバイスをデプロイします。
2. Azure Arc Connected Machine エージェントをインストールします。これによりマシンが Arc 対応サーバーとして Azure に投影されます。
3. そのマシンで Azure Virtual Desktop Arc 拡張機能を実行します。拡張機能が AVD エージェント ソフトウェアをインストールし、マシンをホスト プールに登録します。
4. ユーザーは Windows App で接続します。Azure 内のセッション ホストに接続するときとまったく同じです。

ブローカー、接続ゲートウェイ、ワークスペース、ホスト プール、アプリケーション グループ、診断、Windows App のフィードはすべて Azure のサービスです。Windows セッション、アプリケーション、ユーザー データはホストのある場所に存在します。オンプレミスでインストール、パッチ適用、高可用性化が必要な AVD コントロール プレーン ソフトウェアは一切なく、これがデータセンターでレガシー VDI ブローカーを運用する場合との最大の違いです。

プレビューか GA か

本稿執筆時点で、この機能は一般提供されています。Azure Virtual Desktop の新機能ページには、2026 年 9 月の項に「Azure Virtual Desktop Hybrid」が GA として掲載されており、その前には 2026 年 5 月に「AVD for hybrid environments with Arc-Enabled Servers」というパブリック プレビューの項目があり、プロビジョニングと電源管理はこのリリースに含まれないと注記されていました。この制限は GA でもなくなっていません（後述）が、プレビュー時代の検証用ホスト プール限定という制限はなくなりました。週ごとの経緯を知りたい方のために、AVD 新機能シリーズで各リリースを追い続けています。

サポートされる OS とハードウェア

概要にあるサポート表は、ライセンスと密度の両方の議論を左右するので覚えておくべきものです。

ハイパーバイザーは自由に選べます。Microsoft の表現は「Windows 仮想マシンをサポートする、お好みのオンプレミス ハイパーバイザー」であり、Arc エージェント自身の前提条件ページは VMware（Azure VMware Solution を含む）、Azure Local、「その他のクラウド環境」をサポート対象として挙げ、1 つだけ明確な除外を設けています。すでに Azure で動いている仮想マシンに Arc エージェントをインストールしてはいけません。

Hybrid がやらないこと

ここが大半の設計を決める段落です。概要より：「Azure Virtual Desktop Hybrid は仮想マシンの状態をプロビジョニングも管理もしないため、次の機能はサポートされません。電源管理、自動スケーリング、Start VM on Connect、セッション ホスト構成。」続く一文がその作業をあなたに割り当てます。「組織は、ハイパーバイザー ツール、スクリプト、パートナー ソリューション、またはその他のツールを使ってオンプレミスのセッション ホストをデプロイおよび管理する責任を負います。」

もう 1 つのオンプレミス選択肢である Azure Local 上の Azure Virtual Desktop と比べてみてください。Azure Local は Windows 11 Enterprise マルチセッション、ポータル主導のセッション ホスト プロビジョニング、Azure Marketplace イメージをサポートしますが、Azure Local スタックが必要で、「Azure 外のスタンドアロン サービスとして、マルチクラウド環境で、または他の Azure Arc 対応サーバー上ではサポートされません」。Hybrid はその逆のトレードオフです。任意のハードウェアと任意のハイパーバイザーを得る代わりに、ライフサイクル管理を自前で行い、マルチセッションを諦めます。

前提条件とライセンス

Azure と Azure Arc の前提条件

デプロイ記事は、標準の AVD 要件の上に Hybrid の要件を重ねています。

• サブスクリプションに Microsoft.DesktopVirtualization リソース プロバイダーが登録されていること。ホスト プールを構築する人には Desktop Virtualization Contributor ロールが必要です。
• セッション ホストが Azure Virtual Desktop の必須 URL と Azure Arc のネットワーク エンドポイントに到達できること（いずれもネットワークの節で説明）。
• すべてのセッション ホストに Azure Arc Connected Machine エージェントがインストールおよび構成されていること。
• ホスト プールは 標準 ホスト プールで、Azure ウィザードから仮想マシンを追加しておらず、ID タブでマネージド ID が割り当てられていること。Microsoft は重要事項として「Azure Virtual Desktop Hybrid はセッション ホスト構成をサポートしません」と付記しています。
• ホスト プールのマネージド ID に、Arc 対応サーバーを含むリソース グループへの Reader が必要です。Microsoft は「マネージド ID が Arc リソース グループへの Reader アクセスを持たない場合、将来のリリースではセッション ホストが利用可能にならなくなります」と警告しています。初日に済ませてください。

Arc 側では、前提条件ページが Microsoft.HybridCompute、Microsoft.GuestConfiguration、Microsoft.HybridConnectivity のリソース プロバイダーと、オンボードを実行する人へのリソース グループ上の Azure Connected Machine Onboarding（または Contributor）ロールを要求しています。グループ ポリシーで「サービスとしてログオン」権限をカスタマイズしている場合、NT SERVICE\himds が一覧に含まれていなければエージェントは起動しません。

ID と参加の要件

デプロイ記事は参加の種類を具体的に定めており、Windows Server 中心の組織が最も驚きやすい箇所です。

• Windows クライアント セッション ホスト（Windows 11 または 10 Enterprise）は、Microsoft Entra 参加、Active Directory Domain Services 参加、Microsoft Entra ハイブリッド参加のいずれでも構いません。
• Windows Server セッション ホストは AD DS 参加またはハイブリッド参加でなければなりません。「リモート デスクトップ サービス (RDS) ライセンス サーバーへの依存のため、Microsoft Entra ID のみの参加はサポートされません。」

ユーザー自身は Microsoft Entra ID に存在する必要があります。ID と認証の記事は AD DS にのみ存在する ID を対象外とし、Microsoft Entra Connect で同期されるハイブリッド ID と、Entra 参加ホスト上のクラウド専用 ID をサポートしています。Microsoft は Entra 参加およびハイブリッド参加ホストに対して Microsoft Entra 認証によるシングル サインオンを推奨しています。セッション サインインにスマート カードや Windows Hello for Business を使う場合は Kerberos が用いられるため、クライアントからドメイン コントローラーまたは KDC プロキシへの到達性が必要です。オンプレミス ユーザーに提供するオンプレミス ホストでは通常すでに満たされていますが、リモート ユーザーについては設計事項になります。

ライセンス：3 つの層

Microsoft は Hybrid のライセンスを「ユーザー使用権と Azure Virtual Desktop Hybrid サービス ユーザー ライセンス」と要約しています。私はコスト モデルを作る際に 3 層に分けます。

1. OS ユーザー使用権。 上の表です。Windows Server ホストでは RDS CAL のソフトウェア アシュアランス要件に注意してください。有効な SA のない素の RDS CAL は対象外です。一般向けの AVD ライセンス記事は、ユーザー単位アクセス価格は外部商用目的専用で、Windows Server オペレーティング システムには利用できないと補足しています。
2. Azure Virtual Desktop Hybrid サービス料金。 Azure Virtual Desktop の価格ページはこれを「オンプレミスで Azure Virtual Desktop セッション ホストを実行するためのユーザー単位・月額料金」と説明し、管理とオーケストレーションの機能をカバーするもので、購入には Microsoft アカウント チームへの連絡が必要だとしています。私が確認した時点では金額は表示されていなかったため、ここでは引用しません。ビジネス ケースを作る前に書面で入手してください。
3. Azure Arc アドオン。 Azure Arc の価格ページはコア コントロール プレーン（インベントリ、管理、VM セルフサービス）を無料とし、アドオン サービスは有効化時に課金されると記載しています。Azure Policy ゲスト構成と変更履歴はサーバーあたり月額 6 米ドル、Update Manager、Defender for Servers、ログ取り込みは別のメーターです。有効なソフトウェア アシュアランス付き Windows Server ライセンスを持つ顧客は Update Manager、変更履歴、マシン構成、Windows Admin Center を追加費用なしで利用でき、RDS CAL 要件を満たすために Windows Server ホストにすでに SA が付いている可能性が高い以上、これは重要です。

変わらない点：Windows Server 自体には引き続き OS ライセンスが必要であり（価格ページの脚注に明記）、Windows 11 または 10 Enterprise の使用権はハードウェアではなくユーザーに付随します。

ネットワークと ID の経路

送信エンドポイント

すべてが送信方向です。必須 FQDN とエンドポイントの記事は「すべてのエントリは送信です。Azure Virtual Desktop のために受信ポートを開く必要はありません」と述べ、Arc のネットワーク要件の記事は Connected Machine エージェントが「TCP ポート 443 で Azure Arc へ安全に送信通信する」としています。Microsoft は、AVD エンドポイントがブロックされているデプロイはサポートしないとも明言しています。

セッション ホスト向け AVD リストには、login.microsoftonline.com（TCP 443）、*.wvd.microsoft.com（TCP 443、TCP ベース RDP を含むサービス トラフィック）、*.prod.warm.ingest.monitor.core.windows.net と gcs.prod.monitoring.core.windows.net（エージェント トラフィック）、mrsglobalsteus2prod.blob.core.windows.net（エージェントおよびサイドバイサイド スタックの更新）、TCP 80 の証明書エンドポイント数件、そしてサービス トラフィック用の *.windows.cloud.microsoft、*.service.windows.cloud.microsoft、*.windows.static.microsoft が含まれます。Arc リストはさらに management.azure.com、*.his.arc.azure.com、*.guestconfiguration.azure.com、guestnotificationservice.azure.com、*.servicebus.windows.net、pas.windows.net、*.login.microsoft.com、download.microsoft.com を加え、サービス タグは AzureActiveDirectory、AzureTrafficManager、AzureResourceManager、AzureArcInfrastructure、Storage、AzureFrontDoor.Frontend です。

実際のファイアウォールで作業して得た実務上の注意点を 2 つ。

• AVD リストにある 2 つの Azure ファブリック アドレス 169.254.169.254 と 168.63.129.16 は Azure 内部のものです。Arc 対応ホストではインスタンス メタデータ エンドポイントに設計上到達できません。Hybrid トラブルシューティング記事はこれを想定どおりの動作として記録し、拡張機能は Arc のハイブリッド メタデータ サービスにフォールバックします。これらへのルーティングに午後を費やさないでください。
• TLS インスペクションは致命的です。トラブルシューティング記事には、プロキシが *.wvd.microsoft.com へのトラフィックを書き換えた場合に、ダウンロードしたエージェント MSI の Authenticode 署名検証失敗と WebSocket ハンドシェイク失敗が発生すると記録されています。AVD の URL はバイパス リストに入れてください。

Arc リストの長さにプロキシ チームが難色を示すなら、Azure Arc ゲートウェイが Arc 固有の許可を 7 つの FQDN に減らします。ただし Azure パブリック クラウド専用で、TLS 終端が必要な環境には推奨されないという注意点があります。

RDP Shortpath と遅延

Hybrid のユーザー体験面での根拠は遅延です。セッション ホストがユーザーとアプリケーション バックエンドのすぐ隣にあります。その恩恵を得るにはセッションを UDP で運びたいところです。RDP Shortpath は常に Azure の AVD ゲートウェイ経由の TCP リバース接続トランスポートから始まり、次に UDP の確立を試みます。UDP が成功すれば TCP 経路は破棄され、失敗すれば TCP がフォールバックとして残ります。

• ホストと同じネットワーク上のユーザー（後述のデータ所在地パターンと拠点パターン）はマネージド ネットワークのケースです。ポート 3390 の RDP Shortpath リスナー経由か、受信ポート不要の STUN 経由で直接 UDP 接続します。ここが Hybrid の真価です。TCP フォールバックだと、机から机へのセッションが Azure まで往復してしまいます。
• リモート ユーザーはパブリック ネットワーク向け RDP Shortpath を使います。NAT が許せば STUN による直接接続、そうでなければ UDP 3478 の 51.5.0.0/16 を通る TURN 中継接続です。Microsoft は、TURN 中継はクライアントの物理的な場所に基づいて選択され、UDP がブロックされればセッションは TCP にフォールバックすると述べています。セッション ホスト ネットワークからこのレンジへの送信 UDP 3478 を許可し、TCP ベースの VPN、二重 NAT、強制トンネリングを避けてください。

FSLogix プロファイルの配置

プロファイル ストレージはホストの隣に置きます。オンプレミス AVD の Azure Local 版に対する Microsoft 自身のガイダンスは、セッション ホストと同じネットワーク上の SMB 共有を推奨し、大規模デプロイではストレージとコンピューティングを独立してスケールできるようクラスター外の共有を勧めています。アーキテクチャ センターのリファレンスは、プロファイル共有について「ネットワーク性能と遅延が極めて重要」と付け加えています。同じ物理法則が Hybrid にも当てはまります。カルガリーのセッション ホストがカナダ中部の Azure Files からプロファイル VHDX をマウントすると、サインインごとに往復が追加されます。

FSLogix ストレージの比較は Azure Files、Azure NetApp Files、記憶域スペース ダイレクトを扱い、FSLogix コンテナーはどの SMB 共有でも動作します。AD DS 参加の Hybrid ホストには、AD 統合 SMB を備えた Windows ファイル サーバー クラスターまたは NAS が自然な選択です。Windows クライアント ホストが Entra 参加でクラウド専用ユーザーを使う場合は、クラウド専用および外部 ID 向け FSLogix の GA によって Azure Files のドメイン コントローラー依存が解消されますが、上記の遅延の論点と天秤にかけてください。

リファレンス アーキテクチャ

コンポーネント

パターン 1：データ所在地要件に基づくオンプレミス ホスト

規制対象の組織（カナダの公共部門、医療、金融サービスで最も多く見ます）は、セッション ホスト、プロファイル共有、業務アプリケーションのデータを自社データセンターに置き、ユーザーの大半は社内ネットワーク上にいます。ホストは密度のために SA 付き RDS CAL を組み合わせた Windows Server、AD DS 参加、マネージド ネットワーク向け RDP Shortpath を使います。プライバシー部門には正直に伝えてください。Microsoft の Azure Local ガイダンスは、セッション ホストがオンプレミスにあっても「一部の顧客データ、診断データ、サービス生成データは引き続き Azure に保存される」と述べており、Hybrid のブローカリング メタデータはホスト プールに選んだ Azure リージョンに存在します。

パターン 2：レガシー VDI からの移行中のハードウェア再利用

Citrix または Omnissa Horizon を使い、vSphere や Nutanix のハードウェアにまだ 2～3 年の寿命が残る中堅組織は、まずブローカーを置き換えます。同じ VM を Arc 対応にして AVD ホスト プールに登録し、Windows App がレガシー クライアントに代わり、レガシー コントロール プレーンを廃止します。新しい容量はハードウェアの老朽化に合わせて Azure に構築し、切り替えは一括移行ではなくホスト プール単位で行います。ホスト プールは拠点ごとに分けてください。Microsoft の Azure Local ガイダンスは 1 つのプールに Azure と Azure Local のホストを混在させることを禁じており、負荷分散とトラブルシューティングの明快さのために、私は Hybrid プールにも同じ規律を適用しています。

パターン 3：他クラウド上のホスト

Arc エージェントは「その他のクラウド環境」で動作し、AWS や GCP のインスタンス メタデータを検出すると記録するため、他クラウド上の Windows VM も AVD セッション ホストになれます。用途は聞こえるより狭く、そのクラウド内のデータベースやライセンス サーバーの隣に置かなければならないワークロードや、2 つのデスクトップ ブローカーを 1 つに統合する組織が対象です。TCP フォールバック経路と TURN 中継のエグレス料金をモデル化し、逆方向の除外も忘れないでください。Azure VM は Arc 対応にせず、通常の方法でホスト プールに追加するだけです。

手順：素の Windows マシンから「利用可能」なセッション ホストまで

1. ホスト プールを準備する

Azure portal でセッション ホストを追加せずに標準のプールまたは個人用ホスト プールを作成し、ID タブでマネージド ID を割り当て、ワークスペースとアプリケーション グループを作成または再利用し、ホスト プール ID に Arc リソース グループへの Reader を付与します。

$hostPool    = Get-AzWvdHostPool -Name "<HostPoolName>" -ResourceGroupName "<HostPoolResourceGroup>"
$principalId = $hostPool.IdentityPrincipalId

New-AzRoleAssignment -ObjectId $principalId -RoleDefinitionName "Reader" -ResourceGroupName "<ArcServersResourceGroup>"

2. マシンを構築し Arc にオンボードする

普段のツールで VM または物理サーバーをデプロイします。デプロイ記事はスクリプト、Configuration Manager、ハイパーバイザー管理ソフトウェア、サードパーティ ツールを挙げており、唯一の要件は「稼働中の Windows マシン」であることです。Arc のエージェント概要にある 2 つのルールが VDI 構築には重要です。

• azcmagent パッケージをゴールデン イメージにインストールしてもよいが、イメージ内で azcmagent connect を実行してはいけません。接続済みイメージのクローンは 1 つの Azure リソース ID を共有し、最終的に切断状態となって 429 エラーを出します。
• デプロイ後に自動化で各クローンをオンボードします。azcmagent show で Agent Status が Connected で Tenant ID フィールドが埋まっていることを確認してください。トラブルシューティング記事はテナント ID の欠落を登録の決定的な阻害要因として挙げています。

3. ホストをホスト プールに登録する

登録キー（有効期間は最長 27 日）を生成し、トークンを保護された設定に入れて拡張機能をインストールします。ポータルの経路は Azure Arc > Infrastructure > Machines > 対象マシン > Settings > Extensions > Add > Azure Virtual Desktop Hybrid で、続いてサブスクリプション、リソース グループ、ホスト プールを選びます。PowerShell では Az.DesktopVirtualization と Az.ConnectedMachine モジュールを使います。

$expiresUtc = (Get-Date).ToUniversalTime().AddHours(24).ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ")
$regInfo    = New-AzWvdRegistrationInfo -ResourceGroupName $HostPoolRG -HostPoolName $HostPoolName -ExpirationTime $expiresUtc
$token      = $regInfo.Token

$protectedSettings = @{ registrationToken = $token }

New-AzConnectedMachineExtension -Name 'Microsoft.AzureVirtualDesktop.CloudDeviceExtension' -ResourceGroupName '<ResourceGroupName>' -MachineName '<MachineName>' -Location '<Azure Region>' -Publisher 'Microsoft.AzureVirtualDesktop' -ExtensionType 'CloudDeviceExtension' -ProtectedSetting $protectedSettings

Windows Server では拡張機能がリモート デスクトップ セッション ホストの役割をインストールします。Microsoft のヒントは率直で、拡張機能が「Windows Server に RDSH の役割をインストールした場合、セッション ホストを再起動する」ため、登録中の再起動を避けるには役割をイメージに事前インストールしておきます。Windows 11 では単に RDP を有効化するだけです。

4. 検証する

拡張機能はマシンの 拡張機能 ブレードで Succeeded を報告します。その後、Microsoft によれば「拡張機能が Succeeded を報告してからセッション ホストがホスト プールで利用可能と報告するまで最大 15 分かかることがあります」。ホスト プールから確認します。

Get-AzWvdSessionHost -ResourceGroupName "<Resource Group>" -HostPoolName "<HOST POOL>"

ユーザーをアプリケーション グループに割り当て、Windows App でサインインし、接続情報ダイアログでトランスポートが期待どおり UDP になっていることを確認します。登録に失敗した場合は、C:\ProgramData\GuestConfig\extension_logs\Microsoft.AzureVirtualDesktop.CloudDeviceExtension\ にある拡張機能ログが 6 つのフェーズのどこで壊れたかを教えてくれます。[Fatal] を検索してください。Microsoft が文書化している一般的な原因は、Arc エージェント構成内の不正なプロキシ URL、期限切れまたはテナント違いの登録トークン（「テナント間の登録は許可されません」）、*.wvd.microsoft.com:443 のブローカーに到達できないこと、TLS インスペクションを行うプロキシ、そして同名の古いホストがプールに残っている場合の NAME_ALREADY_REGISTERED です。

運用

パッチ適用とイメージ更新

Microsoft のセッション ホストの Windows 更新管理手法は、世界をインプレース パッチとイメージ ベースのサービスに分けており、Hybrid では選択肢はほぼ決まっています。イメージ ベースの選択肢（セッション ホスト更新、Azure Compute Gallery）は Hybrid にない Azure プロビジョニングに依存するため、インプレースでパッチするか、自前のパイプラインで再構築することになります。

Azure Update Manager は顧客が定義したメンテナンス ウィンドウ内で Arc 接続マシンにパッチを適用し、Windows Server プールにとってはまさに「ドレインしてからパッチ」という望ましいリズムになります。OS バージョンのアップグレードについては、Microsoft の推奨はインプレース アップグレードではなく新しいイメージからの新しい VM なので、月例パッチが整っていてもゴールデン イメージのパイプラインは生かしておいてください。

監視

Azure Virtual Desktop Insights には、ホスト プールとワークスペースの診断設定、Log Analytics ワークスペース、そして全セッション ホスト上のデータ収集ルール付き Azure Monitor エージェントが必要です。Azure Monitor エージェントは Azure Arc 経由でオンプレミスおよび他クラウドのマシンを VM 拡張機能として明確にサポートしているため、Insights ブックは Hybrid ホストでも機能します。Log Analytics の取り込み費用を予算化してください。エージェント自体は無料です。Arc マシンには Azure Resource Health アラートを追加しましょう。15 分以上ハートビートを止めた Arc 対応サーバーはオフライン、ブロック、またはエージェント停止のいずれかであり、それがハイパーバイザー ホストの問題を知らせる最初の信号になることが多いです。

スケーリングと失うもの

自動スケーリングがないということは、夜間にホストの電源を切るスケーリング プランも、個人用デスクトップの Start VM on Connect も、月曜朝の立ち上がりに合わせてホストを作る動的自動スケーリングもないということです。ピークに合わせてサイジングし、メンテナンスにはドレイン モードとホスト プールの負荷分散設定を使い、スケジュール ベースの電源管理が必要ならパートナーのオーケストレーション（プレビュー記事でパートナー エコシステムを取り上げました）をソリューション コストの一部と見なしてください。

Azure ホストのセッション ホストとのコスト比較

Hybrid サービス料金が公表されておらず、ハードウェア コストはあなただけが知るものなので、ここは定性的に留めますが、構成要素は文書化されています。

率直にまとめると、ハードウェアがすでに償却済みでデータを外に出せない場合、またはオンプレミス バックエンドへの遅延が支配的な場合は Hybrid が勝ちます。弾力性、マルチセッションの密度、または少人数の運用チームが必要なら Azure が勝ちます。ユーザー単位のクラウド PC を代わりに検討しているなら、私の Windows 365 と Azure Virtual Desktop の比較がその分岐点を扱っています。

Azure Virtual Desktop Hybrid を使うべきでないとき

• Windows 11 マルチセッションの密度が必要なとき。 Azure または Azure Local を使ってください。Hybrid はクライアント OS ではシングルセッションです。
• 弾力的なコストを求めるとき。 自動スケーリングも Start VM on Connect もないため、オンプレミス ホストは午前 3 時でも午前 10 時でも同じコストです。
• ホストが短命なとき。 Microsoft の Arc 前提条件は「短命（エフェメラル）なサーバーや仮想デスクトップ インフラストラクチャ (VDI) VM で Azure Arc を実行することは推奨しない」と述べています。Arc はハートビートを止めたリソースを片付けず、同名で VM を再作成すると残骸リソースと衝突するからです。Hybrid は長寿命のホストで機能します。非永続でログオフ時に破棄する設計はプラットフォームと戦うことになります。
• Entra のみの環境で Windows Server を使うとき。 Windows Server ホストには AD DS またはハイブリッド参加が必要です。ドメイン コントローラーの廃止が目標なら、Windows 11 Enterprise ホストを使うか、ホストを Azure に置いてください。
• ネットワーク チームがエンドポイントを許可できないとき。 Microsoft は AVD URL がブロックされたデプロイをサポートせず、*.wvd.microsoft.com の TLS インスペクションは登録を壊します。
• ハードウェアがそもそも寿命を迎えているとき。 価値のすべては再利用にあります。これを動かすために新しいサーバーを買うなら、まず Azure か Windows 365 の見積もりを取ってください。

取るべきアクション

1. 設計を提示する前に、Microsoft Learn の Hybrid 概要で GA ステータスと現在の制限を確認します。非サポート一覧（電源管理、自動スケーリング、Start VM on Connect、セッション ホスト構成）は 2 枚目のスライドに載せましょう。
2. ユーザーの使用権を棚卸しします。Windows Server ユーザー（有効な SA 付き RDS CAL または RDS ユーザー SL）と Windows 11/10 Enterprise ユーザー（Microsoft 365 または Windows Enterprise E3/E5、VDA）を分け、Windows Server でユーザー単位アクセス価格を使って提供するつもりだった人がいればフラグを立てます。その組み合わせは利用できません。
3. Microsoft アカウント チームに Azure Virtual Desktop Hybrid のユーザー単位サービス料金を書面で求め、Arc アドオンと Log Analytics 取り込みとともにコスト モデルに加えます。
4. ホスト プールごとに参加の種類を決めます。Windows Server は AD DS またはハイブリッド参加、Entra 参加は Windows クライアント ホストにのみ検討します。Microsoft Entra 認証によるシングル サインオンを有効にします。
5. ファイアウォール変更を 1 つのパッケージとして申請します。AVD セッション ホストの FQDN、Arc エンドポイントとサービス タグ、51.5.0.0/16 への送信 UDP 3478、*.wvd.microsoft.com の TLS インスペクション バイパスです。パイロット ホストから Azure Virtual Desktop Agent URL Tool を実行して証明します。
6. Arc と Desktop Virtualization のリソース プロバイダーを登録し、マネージド ID 付きの標準ホスト プールを構築し、最初のホストが登録される前にその ID に Arc リソース グループへの Reader を付与します。
7. Arc エージェントと RDSH の役割をゴールデン イメージに焼き込み、イメージは Arc に接続しません。各クローンを自動化でオンボードし、azcmagent show がテナント ID を報告することを確認します。
8. パイロット ホストを拡張機能で登録し、利用可能 になるのを待ち、LAN ユーザーとリモート ユーザーの両方でテストして、LAN ユーザーが直接 UDP トランスポートを得ていることを確認します。
9. FSLogix 共有をホストと同じネットワークに置き、Azure ホストのベースラインと比較してサインイン時間を計測します。
10. Azure Monitor エージェント拡張機能経由で Azure Virtual Desktop Insights を接続し、Windows Server プールに Azure Update Manager のメンテナンス ウィンドウをスケジュールし、Arc マシンに Resource Health アラートを設定します。
11. 出口計画を書きます。ハードウェアの退役に合わせてどのホスト プールを Azure または Windows 365 に移すのか、そのトリガーは何かを定めます。

上記の手順を、パイロット用の印刷できるチェックゲートとして使いたい場合は、20 項目の Azure Virtual Desktop Hybrid 準備チェックリストをダウンロードしてください。

手が足りませんか？Big Hat Group は米国およびカナダの組織向けに、2 週間の Hybrid 準備状況アセスメントからレガシー VDI の完全な移行までを対象とする Azure Virtual Desktop アーキテクチャおよびデプロイのコンサルティングを提供しています。ディスカバリー コールを予約して、お客様の環境についてお話ししましょう。

参考資料

• Azure Virtual Desktop Hybrid の概要、Microsoft Learn
• Azure Virtual Desktop Hybrid をオンプレミスにデプロイする、Microsoft Learn
• Azure Virtual Desktop Hybrid セッション ホストのオンボードのトラブルシューティング、Microsoft Learn
• Azure Virtual Desktop の新機能、Microsoft Learn
• Azure Virtual Desktop の必須 FQDN とエンドポイント、Microsoft Learn
• Connected Machine エージェントのネットワーク要件、Microsoft Learn
• Connected Machine エージェントの前提条件、Microsoft Learn
• Azure Connected Machine エージェントの概要、Microsoft Learn
• Azure Arc ゲートウェイでネットワーク構成要件を簡素化する、Microsoft Learn
• RDP Shortpath、Microsoft Learn
• Azure Virtual Desktop の ID と認証、Microsoft Learn
• Azure Virtual Desktop のライセンス、Microsoft Learn
• Azure Virtual Desktop の価格、Microsoft Azure
• Azure Arc の価格、Microsoft Azure
• Azure Local 上の Azure Virtual Desktop、Microsoft Learn
• Azure Local 向け Azure Virtual Desktop リファレンス アーキテクチャ、Azure アーキテクチャ センター
• FSLogix プロファイル コンテナーのストレージ オプション、Microsoft Learn
• Azure Virtual Desktop でマネージド ID を構成する、Microsoft Learn
• セッション ホストの Windows 更新管理手法、Microsoft Learn
• Azure Update Manager の概要、Microsoft Learn
• Azure Monitor エージェントの概要、Microsoft Learn
• Insights を有効にして Azure Virtual Desktop を監視する、Microsoft Learn
• 自動スケーリングのスケーリング プランとシナリオ例、Microsoft Learn