はじめに
企業がテレワーク環境やセキュアなエンドユーザコンピューティング環境を構築する際、仮想デスクトップ（VDI）と並んで頻繁に検討される技術が 「RDSH（Remote Desktop Session Host）」 です。
VMware Horizon（2024 年に Omnissa Horizon にリブランド）などの仮想化ソリューションを導入・設計するにあたり、「VDI 方式と RDSH 方式のどちらを採用すべきか」「RDSH 環境を構築すると具体的に何ができるのか」「Microsoft の RDS CAL はどう絡むのか」 といった疑問を抱くインフラ担当者は少なくありません。
本記事では、RDSH の基本概念や VDI 方式とのアーキテクチャの違い、設計時に押さえておきたい RDS CAL（Microsoft 側のライセンス）要件、そして Omnissa Horizon を利用してアプリケーションをユーザに配信（公開アプリ）する設定の全体フローを整理します。
- RDSH（Remote Desktop Session Host）の基本概念と仕組み
- リソース割り当てや管理面から見る「RDSH 方式」と「VDI 方式」の違い
- RDSH 利用に必要な RDS CAL（Per User / Per Device）の要件
- Omnissa Horizon における公開アプリケーション機能の概要
- RDSH サーバを用いたアプリケーション公開設定の全体フロー
- RDSH 設計時に押さえておきたい制約と落とし穴
RDSH（Remote Desktop Session Host）の基本概念
RDSH（リモートデスクトップセッションホスト）は、Windows Server OS に標準搭載されている 「リモートデスクトップサービス（RDS）」 を構成する役割（サーバコンポーネント）の 1 つです。
通常、PC やサーバの OS は 1 人のユーザが占有して利用しますが、RDSH を有効化したサーバでは、複数のユーザがネットワーク経由で同時にログインし、それぞれ独立したセッション（デスクトップ画面やアプリケーション操作）を持つ ことが可能になります。
このように、サーバ側の OS やアプリケーションを複数人で共有して利用する仕組みは 「SBC（Server Based Computing）方式」 と呼ばれます。実際のデータ処理やアプリケーション実行はすべてサーバ側で行われ、ユーザの手元の端末には画面の描画情報のみが転送されるため、情報漏洩の防止や端末管理の簡素化につながります。
参考: Supported Configurations for Remote Desktop Services – Microsoft Learn
“Each user and device that connects to a Remote Desktop Services session host or Azure Virtual Desktop session host running Windows Server needs a Remote Desktop Services (RDS) client access license (CAL).”
（Windows Server で動作するリモートデスクトップサービスのセッションホストまたは Azure Virtual Desktop のセッションホストに接続する各ユーザおよびデバイスには、RDS CAL が必要です）
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-supported-config
RDSH の対応 Windows Server バージョン
RDSH は Windows Server の主要なバージョンに搭載されています。2026 年時点でサポート中のバージョンは以下のとおりです。
| Windows Server バージョン | リリース | サポート状況 |
|---|---|---|
| Windows Server 2016 | 2016 年 | メインストリーム終了、延長サポートのみ |
| Windows Server 2019 | 2018 年 | メインストリーム終了、延長サポートのみ |
| Windows Server 2022 | 2021 年 | サポート中 |
| Windows Server 2025 | 2024 年 11 月 | サポート中（最新） |
RDSH を新規構築する場合、Windows Server 2022 または 2025 を選択するのが一般的です。
RDSH 方式と VDI 方式の違い
エンドユーザにリモートワーク環境を提供する際、RDSH（SBC 方式）と並んで比較・検討されるのが VDI（Virtual Desktop Infrastructure）方式 です。
両者の最大の違いは、「OS とハードウェアリソースの割り当て方」 にあります。RDSH が 1 つのサーバ OS を多人数で「共有」するのに対し、VDI はユーザごとに個別のクライアント OS（Windows 10 / 11 など）搭載の仮想マシンを「専有」して割り当てます。
アーキテクチャと特徴の比較
| 比較項目 | RDSH（SBC 方式） | VDI 方式 |
|---|---|---|
| OS 環境 | 1 つのサーバ OS を複数人で共有 | ユーザごとにクライアント OS を専有 |
| リソース | サーバリソースを全ユーザで共有 | ユーザ（仮想マシン）ごとに個別に割り当て |
| 集約率（参考値） | 高い（軽負荷で 50〜100 ユーザ／ホスト） | 低い（仮想マシン 1 台＝ 1 ユーザ） |
| コスト | 集約率が高く、インフラ費用を抑えやすい | 仮想マシン単位でリソースが必要になり高価 |
| パフォーマンス | 他ユーザの高負荷処理の影響を受けやすい | 独立したリソースのため他者の影響を受けにくい |
| 運用管理 | サーバ OS への 1 回の作業で済むため容易 | 仮想マシンごとのパッチやイメージ管理の手間が大きい |
| アプリ互換性 | サーバ OS 非対応のアプリは利用不可 | 通常の Windows アプリがそのまま動作しやすい |
| 必要なライセンス | RDS CAL + Horizon CCU など | Horizon CCU など（RDS CAL は不要） |
第 3 の選択肢: マルチセッション Windows と DaaS
近年は、上記 2 方式に加えて以下のような選択肢も存在します。
| 方式 | 特徴 | 主なサービス例 |
|---|---|---|
| マルチセッション Windows | クライアント OS（Windows 10 / 11）でマルチセッション動作する仕組み | Azure Virtual Desktop（AVD）、Windows 365 |
| DaaS（Desktop as a Service） | クラウド事業者が VDI/RDSH 基盤を SaaS として提供 | Omnissa Horizon Cloud、Citrix DaaS、Amazon WorkSpaces |
Azure Virtual Desktop（AVD）の「Windows 11 マルチセッション」 は、サーバ OS を使わずに Windows 11 でマルチセッションを実現できる選択肢として広がっています。Omnissa Horizon は オンプレミス・ハイブリッド環境での RDSH/VDI 提供 に強みがあり、選定にあたっては以下の基準で検討します。
選定基準（簡易フロー）
| ユースケース | 推奨方式 |
|---|---|
| 業務アプリの利用が中心、コストを抑えたい | RDSH（公開アプリ） |
| 個別の Windows 環境が必要、設定の自由度を重視 | VDI |
| クラウドベースで運用したい、Microsoft 365 親和性重視 | AVD / Windows 365 |
| 完全マネージドで運用負荷を最小化したい | DaaS（Horizon Cloud / Citrix DaaS など） |
オンプレミスでの自前運用を前提とすると、業務アプリ提供は RDSH、フル Windows 環境提供は VDI、という使い分けが基本的な判断軸になります。
RDSH 利用に必要なライセンス（RDS CAL）
RDSH を本番運用する際に見落としがちなのが、Microsoft 側のライセンスである「RDS CAL（Remote Desktop Services Client Access License）」 です。Horizon の同時接続ライセンス（CCU）とは別に、Microsoft 標準のライセンスとして必要になります。
参考: License Remote Desktop Services with Client Access Licenses (CALs) – Microsoft Learn
“Each user and device that connects to a Remote Desktop Services session host or Azure Virtual Desktop session host running Windows Server needs a Remote Desktop Services (RDS) client access license (CAL).”
（Windows Server で動作するリモートデスクトップサービスのセッションホストまたは Azure Virtual Desktop のセッションホストに接続する各ユーザおよびデバイスには、RDS CAL が必要です）
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-client-access-license
Per User CAL と Per Device CAL の違い
RDS CAL には 2 種類のライセンスモデルがあり、利用形態によって使い分けます。
| 項目 | Per User CAL | Per Device CAL |
|---|---|---|
| 紐づけ対象 | ユーザ単位（AD アカウント） | デバイス単位 |
| 適している環境 | 1 人 1 台以上のデバイス、自宅 / 外出先からも利用 | シフト制で同じ端末を複数人が利用 |
| 動作要件 | ドメイン参加環境のみ利用可 | ワークグループ環境でも利用可 |
| 再割り当て | 90 日間以上の継続利用後に再割り当て可 | 比較的柔軟に再割り当て可 |
| トラッキング | RD Licensing Manager でユーザ単位に追跡 | デバイス単位で追跡 |
ドメイン参加環境では Per User CAL の利用が一般的ですが、ワークグループ環境では Per Device CAL のみが利用可能 という制約があります。誤って Per User で導入すると、60 分でセッションが強制切断される事象が発生します。
CAL の互換性ルール（後方互換のみ）
RDS CAL は 「新しいバージョンの CAL は古い RDSH に使えるが、古い CAL で新しい RDSH には接続できない」 という後方互換のルールがあります。
| RDSH 側 OS | RDS 2019 CAL | RDS 2022 CAL | RDS 2025 CAL |
|---|---|---|---|
| Windows Server 2019 | ✅ | ✅ | ✅ |
| Windows Server 2022 | ❌ | ✅ | ✅ |
| Windows Server 2025 | ❌ | ❌ | ✅ |
加えて、RD ライセンスサーバ自体の OS バージョンも、保有する CAL と同等またはそれ以降である必要 があります。例えば、Windows Server 2025 用 CAL は Windows Server 2022 のライセンスサーバにはインストールできません。RDSH を Windows Server 2025 に新規構築する場合は、ライセンスサーバも 2025 に揃えることが推奨されます。
120 日の猶予期間
RDSH 役割をインストールしてから 120 日間 は、ライセンスサーバが無くてもクライアントが接続可能な「猶予期間」が設けられています。猶予期間が終了するとライセンスサーバなしでは接続できなくなるため、運用開始前にライセンスサーバの構築と CAL の導入 を済ませておくことが必要です。
Horizon ライセンスとの関係
Omnissa Horizon の同時接続ライセンス（CCU）は 「Horizon を経由した接続権」のみを提供 するもので、Microsoft 側の RDS CAL は別途必要です。両者は補完関係にあり、両方が揃って初めて RDSH を合法的に運用できます。
| ライセンス | 提供元 | 役割 |
|---|---|---|
| Omnissa Horizon CCU | Omnissa | Horizon 経由での接続権 |
| Windows Server CAL | Microsoft | サーバへの基本的な接続権 |
| RDS CAL | Microsoft | リモートデスクトップセッションを開く権利 |
RDS CAL の購入・運用の詳細については、関連記事『Windows Server のリモートデスクトップ同時接続数を増やす手順と RDS CAL の違い』も参考にしてください。
RD ライセンスサーバの構築（概要）
RDSH 環境のライセンス管理に必要な RD ライセンスサーバの構築は、以下の流れで進めます。
- Windows Server に 「リモートデスクトップライセンス」役割 を追加
- Microsoft Clearinghouse でアクティベーション（インターネット接続が無い場合は電話または Web ブラウザ経由）
- RDS CAL のインストール（購入したライセンスキーを RD Licensing Manager から登録）
- RDSH ホスト側で、グループポリシーまたはローカル設定でライセンスサーバを指定
- RD Licensing Diagnoser で疎通とライセンス発行状況を確認
ライセンスサーバは RDSH と同居することも可能ですが、本番環境では独立した冗長構成のサーバを推奨します。
Omnissa Horizon における RDSH のユースケース
Omnissa Horizon（2024 年までの旧称: VMware Horizon）において RDSH 環境を構築する最大の目的は、「公開デスクトップ（Published Desktop）」 および 「公開アプリケーション（Published Application）」 機能の利用です。
Omnissa Horizon 全体のアーキテクチャやリブランド後の最新状況については、関連記事『Omnissa Horizon（旧 VMware Horizon）への移行と PowerCLI 自動化』も参考にしてください。
公開デスクトップと公開アプリケーション
| 機能 | 提供されるもの | ユースケース例 |
|---|---|---|
| 公開デスクトップ | Windows Server のデスクトップ画面全体 | 共通端末の代替、シンクライアント運用 |
| 公開アプリケーション | RDSH 上の特定アプリケーションのウィンドウのみ | 業務アプリのみ配信、レガシーアプリの安全な利用 |
特に需要が高いのが 公開アプリケーション機能 です。これは、ユーザに Windows のデスクトップ画面全体を提供するのではなく、RDSH サーバ上にインストールされた特定のアプリケーションのウィンドウのみ をユーザの端末へ配信する仕組みです。
公開アプリケーションが有効なケース
- レガシー業務アプリケーションの安全な配信: 古いバージョンのブラウザや専用クライアントを、ユーザ端末を選ばず利用させたい
- ヘビーアプリの軽量端末からの利用: CAD や統計解析など、ローカルでは動作が重い処理を軽量端末から利用させたい
- 集中管理によるパッチ適用: アプリケーションのアップデートを RDSH 側で 1 回実施するだけで、全ユーザに反映できる
- データ持ち出し対策: データはサーバ側に留まるため、エンドポイントからのデータ流出リスクを抑制できる
ユーザはローカル PC のアプリと同様の操作感で、サーバ上のアプリケーションを操作できます。
Omnissa Horizon でのアプリケーション公開設定の全体フロー
Omnissa Horizon 環境で RDSH サーバを構築し、公開アプリケーションを配信するまでの流れは以下のとおりです。Horizon 8 系列の構成では インスタントクローン方式での自動ファーム展開 が標準的なアプローチになっています。
参考: Farms, Multi-Session Hosts, and Published Desktops and Applications – Omnissa Documentation
Omnissa Horizon の公式ドキュメントでは、ファーム・マルチセッションホスト・公開デスクトップ／アプリケーションの構成手順が体系的に整理されています。
https://docs.omnissa.com/bundle/Desktops-and-Applications-in-HorizonV2406/page/FarmsMultisessionHostsPublishedDesktopsApps.html
ベースとなる Windows Server（2022 または 2025）に 「リモートデスクトップセッションホスト（RDSH）」の役割を追加 します。続いて、ユーザに配信したいアプリケーション（業務ソフトや特定のブラウザなど）をインストールします。
最後に、Horizon Connection Server と通信を行うための Omnissa Horizon Agent（2412 以降。それ以前は VMware Horizon Agent）をインストールします。インストール時のオプションでは以下の選択を推奨します。
- Instant Clone Agent: 選択を推奨（インスタントクローン方式での展開に必要）
- 接続先の Connection Server FQDN を指定
エージェント導入完了後、デプロイの基準となる スナップショット を取得します。
Horizon Console（旧称: Horizon Administrator）にログインし、以下の手順でファームを作成します。
- 左ペイン [Inventory] → [Farms] を選択
- 右ペインの [Add] をクリックし、ファーム作成ウィザードを起動
- ファームタイプの選択
- 自動ファーム（Automated Farm）: インスタントクローンによる自動展開（推奨）
- 手動ファーム（Manual Farm）: 既存の RDSH ホストを手動登録
- 自動ファーム選択時は Instant Clone を選択し、vCenter とゴールデンイメージ（Step 1 で作成したマスター VM のスナップショット）を指定
- ホスト数（Maximum Machines）と、待機状態で確保するホスト数（Minimum Number of Ready Machines）を設定
- AD コンテナ（OU）と命名パターンを指定して完了
ファームとは、同じ用途を持った RDSH ホストをグループ化して管理する単位 です。インスタントクローンを利用すると、ゴールデンイメージから自動的に複数の RDSH ホストが展開されます。クローン展開の仕組みについては、関連記事『Horizon 8 インスタントクローンとリンククローンの違いと移行の落とし穴』も参考にしてください。
ファームの準備ができたら、配信するアプリケーションを定義する アプリケーションプール（Application Pool） を作成します。
- 左ペイン [Inventory] → [Applications] を選択
- [Add] → [Add from Installed Applications] を選択
- ファームを選択すると、インストール済みアプリケーション一覧 が自動取得される
- 公開したいアプリケーションを複数選択し、必要に応じて表示名（Display Name）を変更して [Submit]
- プール作成後、Active Directory のユーザまたはグループに対して 権限の割り当て（Entitlement） を実行
設定完了後、ユーザ端末から Omnissa Horizon Client（旧 VMware Horizon Client）を使って Connection Server へログインします。権限が正しく割り当てられていれば、画面上に公開アプリケーションのアイコンが表示されます。アイコンをクリックし、アプリケーションが正常に起動・操作できるかを確認します。
接続テストでは、以下の点を併せて確認することをおすすめします。
- アプリケーションが想定どおり起動するか
- ファイルの保存先（個人用フォルダ、ネットワークドライブ等）が適切に設定されているか
- 印刷リダイレクト、クリップボード共有が機能しているか
- 複数ユーザの同時接続時にパフォーマンス問題が発生しないか
RDSH 設計時の制約と落とし穴
RDSH は集約率の高さや運用管理の容易さといった利点がある一方、設計段階で押さえておかないとハマる制約があります。代表的なポイントを整理します。
制約 1: サーバ OS 非対応のアプリは動作不可
RDSH のセッションは Windows Server 上で動作する ため、クライアント OS（Windows 10 / 11）専用のアプリケーションは動作しません。設計前に以下を確認する必要があります。
- 対象アプリケーションが Windows Server 上での動作をサポートしているか
- アプリケーション提供元のライセンス条項で 「複数ユーザ同時利用」「サーバ OS 上での動作」が許諾されているか
- Microsoft Office デスクトップ版を RDSH 上で利用する場合、Microsoft 365 Apps for enterprise 等の共有コンピュータライセンス対応プラン が必要
レガシーな業務アプリの中には、サーバ OS 上での動作が公式にサポートされていないものもあります。実機での検証をおすすめします。
制約 2: 同一コレクション・同一ファーム内の OS バージョン統一
Microsoft の公式仕様として、同一の RDS コレクション内のセッションホストはすべて同じ Windows Server バージョンで揃える 必要があります。Omnissa Horizon の RDS ファームでも同様の制約があり、ファーム内に Windows Server 2022 と 2025 のホストを混在させることはできません。
| 構成 | サポート可否 |
|---|---|
| 同一ファーム内すべて Windows Server 2022 | サポート |
| 同一ファーム内すべて Windows Server 2025 | サポート |
| 同一ファーム内に 2022 と 2025 が混在 | サポートされない |
| 別ファームで 2022 と 2025 を併存 | サポート |
Windows Server のメジャーバージョンアップを行う際は、新バージョン用の別ファームを構築して並行運用 → 段階的に切り替え という移行アプローチが現実的です。
制約 3: 1 ファームと 1 デスクトッププールの 1 対 1 関係
Omnissa Horizon の仕様として、1 つの RDS ファームは 1 つのデスクトッププール（Published Desktop）にしか紐づけられません。複数のデスクトッププールから同じファームを共有することはできません。
ただし、アプリケーションプール（Published Application）は同じファームから複数定義可能 です。「アプリケーションは複数公開、デスクトップは 1 つだけ」という運用は問題なく実装できます。
制約 4: GPU 対応の留意点
CAD や 3D 描画など GPU を活用するアプリケーションを RDSH で動作させる場合、以下の選択肢があります。
| GPU 提供方式 | 概要 |
|---|---|
| 物理 GPU の直接利用 | 物理サーバに搭載した GPU を、その RDSH ホストから直接利用 |
| Discrete Device Assignment（DDA） | Hyper-V ホストの物理 GPU を VM に割り当て |
| NVIDIA vGPU | 物理 GPU を仮想化し、複数 VM で共有 |
NVIDIA vGPU は 別途 NVIDIA 側のライセンス が必要であり、Omnissa Horizon との連携でも独自の構成が求められます。RDSH 上での GPU 利用を計画する場合は、ハードウェア・ライセンス・ハイパーバイザの 3 軸で要件を確認する必要があります。
制約 5: 1 ホストあたりのユーザ数とリソース見積もり
RDSH 1 台あたりの収容ユーザ数は、ワークロードに大きく依存します。一般的な参考値は以下のとおりです。
| ワークロード | 1 ホストあたりの目安ユーザ数 |
|---|---|
| 軽負荷（メール・Web ブラウジング中心） | 50〜100 ユーザ |
| 中負荷（Office アプリ・業務システム） | 30〜50 ユーザ |
| 高負荷（CAD・動画編集・大量データ処理） | 10〜20 ユーザ |
これはあくまで目安であり、実環境では POC（概念実証）を実施して 実際のワークロードでの収容数を測定する ことが推奨されます。
制約 6: 印刷・USB リダイレクトのトラブル
公開アプリケーション運用で頻繁に発生するのが、印刷とローカルデバイスのリダイレクト に関するトラブルです。代表的な事象としては以下があります。
- ユーザのローカルプリンタが RDSH 側に正しくリダイレクトされない
- 印刷ジョブが大量にスプールされて RDSH 側のディスクが逼迫
- USB デバイス（スキャナ、トークン等）の認識不可
対策としては、Omnissa の Horizon Smart Policies や Microsoft 純正の RD Easy Print ドライバの活用、ユニバーサルプリント環境の導入などがあります。設計段階でリダイレクト要件を整理しておくことが運用負荷の抑制につながります。
ホスト側のリソース逼迫が発生した際の挙動については、関連記事『VMware メモリバルーニングとは｜仕組みと esxtop での確認手順』も参考にしてください。
まとめ
本記事では、RDSH の基本概念から VDI との違い、RDS CAL ライセンス要件、Omnissa Horizon でのアプリケーション公開、設計時の制約までを整理しました。
- RDSH は 1 つの Windows Server OS を複数人で共有する SBC（Server Based Computing）方式 の技術
- VDI と比較して 集約率が高くインフラコストを抑えやすい が、サーバ OS 非対応アプリは動作しない
- Microsoft の RDS CAL（Per User / Per Device） が必須で、Horizon ライセンスとは別に確保する必要がある
- RDS CAL は 後方互換のみ。Windows Server 2025 RDSH には RDS 2025 CAL が必要
- Omnissa Horizon の RDSH は Horizon Console から自動ファーム（インスタントクローン）方式で展開 するのが標準的
- 1 つの RDS ファームは 1 つのデスクトッププールにしか紐づけられない（アプリケーションプールは複数可）
- 1 ホストあたりの収容ユーザ数はワークロード依存。POC による実測 を強く推奨
以上、最後までお読みいただきありがとうございました。
