By Brock McKenna on 9月 30, 2026
仮想デスクトップでの印刷は、あるギャップを埋めることで機能します。ユーザーのセッションはデータセンター内のサーバーで実行され、プリンターは通常ユーザーの近くにある別のネットワーク上に存在します。この境界を越えて印刷ジョブを転送し、ドキュメントをプリンターが理解できるデータに変換する仕組みが必要です。
この問題を解決するには3つの方法があり、それぞれが難しさを別の場所に移すことで対処します。どの方法を採用しているかを理解すれば、これまで経験した印刷の失敗のほとんどを説明できます。
理論上では、どのアプローチも単純に思えます。実際には、それぞれが異なるトレードオフを伴います。
仮想デスクトップ印刷の仕組み
1. Printer Redirection in AVD, Citrix, and RDS
プリンターリダイレクションは、ユーザーのローカルデバイスにインストールされているプリンターを仮想セッションにマッピングする仕組みです。ユーザーが接続するとローカルプリンターがセッションのプリンター一覧に表示され、セッション内で印刷されたジョブはリモートディスプレイチャネル（AVDではRDPおよびHTML5、RDSではRDP、CitrixではICA）を通じてクライアントに戻され、クライアントがプリンターへ送信します。
これはデフォルトの方法で追加のインフラは不要ですが、起こりやすい3つの問題を引き起こします。
ドライバーの不一致。 セッションホストにはリダイレクトされたプリンター用のドライバーが必要で、なければ汎用ドライバーに置き換えられます。イメージにドライバーが含まれていないと、プリンターが表示されないか、誤った機能で表示されます。これがゴールデンイメージにプリンタードライバーがどんどん蓄積される理由であり、どれか1つを削除すると必ず何かが壊れる原因にもなります。
プリンター名の変更。 プールされたマルチセッション環境では、リダイレクトされたプリンター名にセッション固有のサフィックスが付くことがよくあります。固定のプリンター名に印刷するよう設定されたアプリケーション（典型的には基幹業務ERP）はそのプリンターを見つけられません。アプリケーションは有益なエラーを表示せず、単に印刷されないだけです。
ジョブがセッションの境界を2回越える。 ドキュメントはセッション内でレンダリングされ、レンダリングされた出力がクライアントに戻されます。レンダリングされた印刷データは元のドキュメントよりはるかに大きいため、画面描画（ピクセル）用に割り当てられていたセッション帯域幅を消費してしまいます。
次のアプローチは、セッション内のドライバー数という別の問題に対処します。
2. 仮想デスクトップ環境でのユニバーサルプリンタードライバー
ユニバーサルプリンタードライバーは、セッション内に1つのドライバーを導入してあらゆるプリンターに対応します。印刷ジョブは中間フォーマットにレンダリングされ、その後クライアントかプリントサーバーで変換される仕組みです。
これでイメージの肥大化は抑えられます。ドライバーが40個ではなく1つで済むからです。ただし帯域は改善されません。レンダリング済みのジョブは依然としてセッション境界を越えて送られるため、実装次第では帯域負荷がむしろ増すことがあります。
加えて、機能面での上限が出ます。ユニバーサルドライバーは共通機能のサブセットしか露出しないため、給紙トレイ選択、ステープル、穴あけ、会計コードなどが動作しなくなることが多いです。それが影響するのは、例えばトレイ3のレターヘッドに印刷する経理チームや、特定の用紙を必要とする法務チームのようなユーザーです。
リダイレクトもユニバーサルドライバーも魅力的でない場合は、より直接的な選択肢があります。セッションホスト自身にプリンターへ直接接続させる方法です。
3. 仮想デスクトップセッションからのダイレクトIP印刷
セッションホストがIP経由でネットワークプリンターへ直接印刷し、リダイレクトもクライアント介在も行わない方法です。
セッションホストとプリンターが同一ネットワーク内にある単一拠点の導入ではシンプルに機能しますが、それ以外では現実的でなくなることが多いです。たとえばAVDのホストプールが西ヨーロッパで稼働し、プリンターがマンチェスターの支社にある場合、「ダイレクトIP」はAzureのサブネットからサイト間VPNを経由してプリンターのVLANへルートを張ることを意味します。その結果、印刷ジョブは印刷者から数メートル先のデバイスへ届くためにネットワークを大きく回り道することになります。
また、各プリンターがセッションホストから個別に到達可能である必要があり、このネットワークアクセスモデルには多くのセキュリティチームが懸念を持ちます。
3つのVDI印刷モデルの概要
AVD、Citrix、RDS環境で印刷がうまくいかないのはなぜか？
理由はシンプルです。いずれの環境もドライバーをセッション内に残しており、セッションはドライバーを置くには最悪の場所だからです。
セッションホストは共有でプールされ、頻繁に再作成されるマシンです。そこでは印刷スプーラーがサードパーティ製のドライバーコードを読み込みます。イメージ内の各ドライバーは、次回のWindowsアップデートで互換性リスクになり得ます。ドライバーの競合が起きると、そのホスト上の全ユーザーの印刷が停止し、個別のユーザーだけの問題になりません。さらに、起動時間を短くするためにITチームが最小化したゴールデンイメージに、プリンターが別の場所にあるという理由だけで大量のプリンタードライバーが残ってしまいます。
セキュリティ面でも問題があります。セッション側の印刷スプーラーは他のスプーラーと同様、SYSTEM権限で動作し、RPCを受け付け、サードパーティ製のコードを読み込みます。Microsoftによれば、MSRCに報告されたWindowsのセキュリティ問題の約9%が印刷スタックに起因します。これを数十人が利用するマルチセッションホスト上で動かすのは、プリントサーバーで動かすより改善とは言えません。
そこで別の疑問が出てきます。セッション内での印刷を扱いやすくするのではなく、レンダリングをセッションの外で行うとしたらどうでしょうか？
VDI印刷のレンダリングをセッション外に移すと何が変わるか？
印刷ジョブがセッションの外でレンダリングされれば、前述の3つのモデルはいずれも不要になります。これらのモデルが解決しようとしていた問題自体が発生しなくなるからです。
これが、ezeepが行うアーキテクチャの転換です。
ezeepでは、印刷ジョブはドキュメントとしてセッションを離れ、Cloud renderingによって6,000以上のメーカー製ドライバーを備えたライブラリを参照してレンダリングされます。レンダリングされた出力はアウトバウンド専用接続を介してプリンター設置場所のezeep Hubへ届けられ、そこで印刷されます。RDPやICAチャネルを通ってセッション側に戻ることは一切ありません。
具体的な影響は次のとおりです。
- ゴールデンイメージにプリンタードライバーを含める必要がなくなります。 イメージの容量が小さくなり、ドライバー互換性を意識する必要がなくなります。
- セッションチャネル上の印刷トラフィックがなくなります。 ユーザー体験に割り当てた帯域幅が印刷トラフィックに消費されなくなります。
- ログオン時のプリンターのマッピングが不要になります。 プリンターはEntra IDまたはGoogle WorkspaceでIDベースに割り当てられ、ユーザーにはIDに応じたプリンターが表示されます。
- セッション側にサードパーティ製ドライバーコードを含む印刷スプーラーが存在しなくなります。 これは、Windows Server 2025およびWindows 11 24H2のセッションホストに導入されるWindows Protected Printモードがブロックする対象がなくなることも意味します。
ezeepは、Azure Virtual Desktop、Windows 365、Citrix、Parallels、Omnissa Horizonに対応しています。ドイツ最大の酪農協同組合であるDMK Groupは、4,000人以上のユーザーが利用するAzure Virtual Desktop環境全体でezeepを導入しています。
この問題は新しいものではなく、ezeepが最近になって取り組み始めた課題でもありません。
ここで重要なのはThinPrintの系譜です。ezeepはThinPrintの技術を基盤としています。ThinPrintは1990年代からターミナルサービスやCitrix環境での印刷に取り組んできました。このアプローチは、長年にわたってこの問題が繰り返し失敗する様子を見続けてきた経験に基づいています。
話は冒頭の「境界」の問題に戻ります。ユーザーはある場所にいて、セッションは別の場所にあり、プリンターはさらに別の場所にあります。問題は、この複雑さをどこで処理するかに尽きます。
