Azure · Remote Desktop Design
VDIからAzureへ——Windows 11リモートデスクトップ環境を低コストで安全に構築するExpressRoute接続・20台規模・NSG/固定IP/ゼロトラスト前提
現在オンプレのVDI(仮想デスクトップ基盤=サーバー上に仮想PCを集約して配信する仕組み)で使っているWindows 11端末を、Azure上のデスクトップで代替する構成を検討します。AzureならWindows Serverをクライアントに見立てるのではなく、本物のWindows 11(Enterpriseマルチセッション)を、ライセンス持ち込みなしで利用できる のが利点です。本稿は、ExpressRoute(オンプレとAzureをつなぐ専用線)経由で社内にアクセスするリモートワーク環境を、アクセス方式(RDPは適切か)・ネットワーク設計・20台規模のコスト最適化 の観点で整理し、低コストかつ一定のセキュリティを保つ構成を提案します。
規模:約20台
接続:ExpressRoute
土台:NSG・固定IP・ゼロトラスト
情報時点:2026年7月
Contents
1 結論サマリ
アクセスは「生のRDP(3389番ポートを直接インターネットに開ける)」は不適切。 本命は AVD(Azure Virtual Desktop)のreverse connect ——受信ポートを一切開けず、セッションホストから外向きのHTTPS(443番)だけで接続 する方式。RDPプロトコル自体は使うが、TLS(通信の暗号化)トンネルの中を通るため、3389番を晒さずに済む。
低コスト最優先なら AVD の Windows 11 Enterprise マルチセッション+オートスケール 。1台のVM(仮想サーバー)を複数人で共有し、夜間・週末は自動で停止(課金停止)できるため、20人規模では専用PCを20台常時起動するより大幅に安い。
運用を最小化し費用を固定したいなら Windows 365(Cloud PC) 。1人あたり月額固定で、インフラ管理がほぼ不要。「常時使う・台数が読める」用途に向く。
ネットワークはNSG(ネットワークセキュリティグループ=通信の許可/拒否ルール)で受信を最小化(3389番は閉じる) 、社内接続はExpressRoute経由 、Azure内はゼロトラスト(Entra IDの条件付きアクセス+多要素認証) 、外向き通信の制御が要るならAzure Firewall を追加。
2 なぜAzure=「本物のWindows 11」なのか
従来のRDS(リモートデスクトップサービス)は、Windows Serverをクライアントのように見せて複数人で使う方式でした。UIや対応アプリがクライアントWindowsと微妙に異なるのが難点です。
Azureでは Windows 11 Enterprise マルチセッション (1台のVMに複数ユーザーが同時ログインできる、クライアント版Windows 11のOS)が使える。Serverを見立てたクライアントではなく、本物のWindows 11のUI・互換性 で運用できる。
ライセンスは、対象の Microsoft 365/Windows Enterprise(E3・E5、Business Premium など)を持っていれば追加のRDS CAL(サーバー接続ライセンス)を持ち込まずに AVD/Windows 365 を利用できる。「Windowsライセンスを別途調達する」手間が要らないのが実務上の利点。
VDIをオンプレで維持すると、ハードウェア更新・ハイパーバイザー保守・容量設計を自前で抱える。Azureに寄せるとこの物理・基盤運用が消え、必要なときだけ動かす 従量モデルに変えられる。
※ ライセンスの適用可否はエディションや契約により細かく異なります。導入前に自社のM365/Windowsライセンスが AVD/Windows 365 の対象かを必ず確認してください(本稿は一般的な整理です)。
3 【重点】アクセス方式の比較——RDPは適切か
「クライアントへの接続はRDPで良いか、もっと安く良い方法はないか」への回答。結論から言うと、“RDPプロトコルを使うこと”自体は問題ないが、“3389番を直接開ける生RDP”は避ける 。同じRDPでも「どう通すか」で安全性とコストが大きく変わります。
方式 受信ポート コスト感 評価
生RDP (VMにグローバルIP+3389番開放)3389番を開放 安いが… 非推奨 。総当たり攻撃・脆弱性の標的になる典型。20台分の管理も重い
AVD reverse connect (Azure Virtual Desktop)受信開放なし (外向き443番のみ)従量・最安化しやすい 本命 。ブローカー(接続を仲介する基盤)経由でRDPをTLSトンネル化。3389を晒さない。マルチセッション+自動停止で安い
Windows 365 (Cloud PC)受信開放なし(同上) 月額固定 有力 。1人1台のCloud PCに443番経由で接続。運用最小・費用予測が容易
Azure Bastion+RDP 受信開放なし(443番) 時間課金+転送量 △ 主に管理者がIaaS VMへ安全にRDP/SSHする 用途。20人の常用デスクトップ配信の主役ではない
VPN+RDP(素のVM) VPN経由でRDP VM常時起動で高くなりがち △ 作れるが、20台の個別VM運用・パッチ・容量管理が重く、コスト最適化もしにくい
要点: AVD/Windows 365 は「RDPをやめる」のではなく、RDPを“受信ポートを開けずに”安全に通す 仕組み。Microsoftもセッションホストで3389番の受信を開けないことを推奨 しています。つまり「RDPで適切か?」への答えは、“生RDPは不可・AVD/Windows 365という形のRDPが正解” 。回線が良ければ RDP Shortpath(UDPで直接つなぎ体感を上げる補助機能)も併用できます。
4 推奨アーキテクチャ(構成図)
AVD(マルチセッション)を主役に、社内へは ExpressRoute で到達する構成。受信は開けず、外向き443番と ExpressRoute の内部通信だけで成立します。
利用者(自宅PC/社給端末)
│ ① 外向き HTTPS(443) だけ
│ ※受信ポート開放なし・reverse connect
▼
┌─────────────────────────────┐
│ AVD 基盤(接続を仲介するブローカー・ゲートウェイ) │ ← Microsoft管理
└─────────────────────────────┘
│ ② 443でセッション確立(RDPをTLSで内包)
▼
┌──────────── Azure VNet(仮想ネットワーク) ─────────────┐
│ サブネット: セッションホスト │
│ ┌──────────────┐ Windows 11 マルチセッション │
│ │ Session Host VM ×2〜3 │ (1台を複数人で共有) │
│ └──────────────┘ │
│ · NSG: 受信=AVDに必要な最小のみ / 3389は閉 │
│ · Entra ID 条件付きアクセス+MFA(ゼロトラスト) │
│ · 送信の固定IP: NAT Gateway or Azure Firewall │
│ │ ③ 社内リソースへ │
└──────────────┼───────────────────────┘
│ ExpressRoute(専用線・暗号化された内部経路)
▼
オンプレ社内ネットワーク(ファイルサーバ・基幹 等)
· 受信許可は「Azure側の固定送信元IP」に限定
①② :利用者→AVDは外向き443番のみ 。VMに受信ポートを開けないので、インターネットからの直接攻撃面がほぼ無い。
③ :社内へは ExpressRoute 経由。オンプレ側は「Azureからの固定の送信元IP 」だけを許可すれば、アクセス元を絞れる(要件の「固定IP」はここで効かせる)。
5 ネットワーク・セキュリティ設計
NSG(通信の許可/拒否ルール)
受信:3389番(RDP)はインターネットから閉じる。 AVDに必要な受信のみに絞る(reverse connectのため、そもそも受信開放は最小)。
送信: AVD基盤との通信に必要なMicrosoftの宛先(サービスタグで指定)と、ExpressRoute経由の社内宛先に限定。不要な外向きは既定拒否に寄せる。
固定IP(アクセス元の特定)
セッションホストからの外向き通信の送信元IPを固定 する(NAT Gateway=多数のVMの送信を1つのIPにまとめる仕組み、または Azure Firewall のパブリックIP)。これにより、オンプレや外部SaaS側で「このIPだけ許可」という制御ができる。
受信側は前述のとおり開けないため、固定IPは主に「Azureから社内・外部へ出ていく通信の身元を固定する」 目的で使う。
ゼロトラスト(境界を信頼せず毎回検証)
Entra ID(旧Azure AD=クラウドのID基盤)の条件付きアクセス で、「誰が・どの端末で・どこから」を毎回検証。多要素認証(MFA=パスワード+αで本人確認)を必須 に。
デバイスのコンプライアンス(会社管理端末か・OS更新済みか)を条件に加えると、私物端末からの無条件接続を防げる。
Azure内のサブネット間・リソース間も「必要な通信だけ許可」を徹底(VMに直接グローバルIPを付けない、管理接続はBastion経由 等)。
Azure Firewall(必要に応じて)
外向き通信をFQDN(ドメイン名)単位でフィルタ したい、複数VNetの通信を一元管理したい、送信の固定IPと検査を1か所で行いたい——といった要件が出たら追加を検討。
20台規模でシンプルさとコストを優先するなら、まずはNSG+NAT Gatewayで開始し、統制要件が固まってからAzure Firewallを足す のが無駄がない(Azure Firewallは常時稼働で相応の固定費がかかるため)。
6 コスト最適化——オートスケール具体設定とクロスポイント試算
同じ20人でも、方式と運用で費用は数倍変わります。「常時20台をフルスペックで起動」を避けるのが最大の勘所。ここではオートスケールの具体設定と、Windows 365との費用クロスポイント(損益分岐)まで踏み込みます。
6-1. 基本方針
マルチセッションで台数を圧縮: Windows 11マルチセッションなら、1台のVMに複数人(業務が軽ければ1台に6〜10人程度が目安)を収容できる。20人ならセッションホスト2〜3台 で足りることが多く、専用20台より土台が小さい。
オートスケール(自動停止): 業務時間外・週末はセッションホストを自動で停止すれば、その間のコンピューティング課金が止まる 。平日日中だけ稼働なら、24時間×30日換算に対して実稼働は3割前後に落とせる。
ストレージ・プロファイルの最適化: ユーザープロファイル(個人設定やデータ)はFSLogix(プロファイルを別ディスクに分離する仕組み)で切り離し、VM側は使い捨てにできる。ディスクは必要十分なサイズに。
予約割引: 常時起動が避けられない部分(管理系VM等)は1年/3年の予約(Reserved Instances=前払いで単価を下げる契約)で単価を下げる。
6-2. オートスケール(スケーリングプラン)の具体設定
AVDのオートスケールはスケーリングプラン(Scaling Plan) という単位で作り、ホストプール(セッションホストの集まり)に割り当てます。1日を4つのフェーズ に分け、それぞれで「何台を起動しておくか」「どのくらい混んだら増やすか」を決めます。
フェーズ 時間帯の例(平日) 負荷分散方式 主な設定値(例)
ramp-up (立ち上がり)7:30〜9:00 breadth-first(幅優先=複数ホストへ均等配分し体感を優先) 最小稼働ホスト 20% /容量しきい値 60%
peak (ピーク)9:00〜17:00 breadth-first 容量しきい値 80% (混んだら増設)
ramp-down (縮小)17:00〜19:00 depth-first(深さ優先=1台に寄せ集めて空いたホストを止める) 最小稼働ホスト 10% /容量しきい値 90% /サインアウト猶予・通知あり
off-peak (夜間・休日)19:00〜翌7:30・週末 depth-first 最小稼働ホスト 0% (=全台停止/課金停止)
各パラメータの意味(つまずきやすい所):
容量しきい値(capacity threshold): ホストプール全体の「席の埋まり具合」が何%を超えたら次のホストを起動するか。例:しきい値80%・1台100セッション想定なら、80セッションを超えたら増設。
最小稼働ホスト(%): そのフェーズで最低限起動しておく割合。off-peakを0% にすると全台停止できるが、ログイン中の利用者は保護される(勝手に落とさない)。
ramp-downのサインアウト制御: 縮小時に「切断中セッションの扱い」「強制サインアウトまでの待ち時間」「利用者への通知メッセージ」を設定。残業中の人を突然切らないよう猶予を持たせる。
負荷分散: ピークはbreadth-first で体感優先、縮小・夜間はdepth-first で1台に集約して停止台数を増やす、が定石。
設定手順(ポータルの流れ): ①Azure Portal →「Azure Virtual Desktop」→「スケーリングプラン」を作成(リージョン・タイムゾーン・ホストプール種別=プール)→ ②スケジュール(上表の4フェーズ)を追加 → ③対象ホストプールに割り当て、「オートスケールを有効化」にチェック 。重要な権限: AVDサービスがVMを起動/停止できるよう、サブスクリプションに「Desktop Virtualization Power On Off Contributor」ロール を付与しておく(これを忘れると自動停止が動かず、常時起動で課金が続く典型ミス)。
IaCで管理するなら: スケーリングプランはARM/Bicep/Terraform(azurerm_virtual_desktop_scaling_plan 等)でコード化でき、フェーズ・しきい値・スケジュールをレビュー可能な差分として残せる。20台規模でも、設定のブレ防止と再現性のためにコード管理を推奨。
6-3. コストのクロスポイント試算(平日8時間・一般企業の想定)
「AVD(従量)とWindows 365(固定)はどこで逆転するのか」を、平日8時間利用という一般的な企業の想定 で試算します。金額は2026年7月時点の公開情報に基づく“目安” で、実額はSKU・リージョン・為替・割引・密度で動きます。必ず料金計算ツールで再計算してください。
前提(目安) 値
Windows 365 Enterprise(2vCPU/8GB/128GB)月額 約 ¥6,120/人・固定
AVD セッションホストの1人あたり実効コンピュート単価 (プール集約後・2vCPU/8GB相当の取り分) 約 ¥15/人・時間 (D2as_v5級の従量を目安)
AVD のストレージ/プロファイル/監視 等の固定分 約 ¥1,000/人・月
稼働時間(平日8時間+立上げ余裕で約10時間×21営業日) 約 210 時間/月 (夜間・休日は停止)
AVDの1人あたり月額(概算式):
AVD月額/人 ≒ 実効時間単価 × 稼働時間 + 固定分
= ¥15 × 210h + ¥1,000
≒ ¥3,150 + ¥1,000 = 約 ¥4,150 /人・月
Windows 365(固定) = 約 ¥6,120 /人・月
→ 平日8時間運用(約210h)では AVD(約¥4,150)< W365(¥6,120)
= AVDが月あたり 約¥2,000/人 安い
クロスポイント(損益分岐の稼働時間): AVDがW365と並ぶ稼働時間 H を解くと——
¥15 × H + ¥1,000 = ¥6,120
15H = 5,120 → H ≒ 約 340 時間/月
月の総時間は約730h。340h ≒ 全体の 約47%。
・平日 約16時間/日まで(=340h/月)→ AVDが安い
・それを超える(ほぼ終日・24時間・休日も稼働)→ W365が有利に
読み方: 一般的な「平日8時間(+立上げ)=月約210時間」の使い方なら、AVDの方が2〜3割安い 。逆にシフト勤務で終日近く回す・24時間運用・週末も常用 といった高稼働では、固定額のWindows 365が逆転して有利になります。クロスポイントは“1日あたり約16時間・月340時間前後” が目安。
試算を動かす3変数: ①密度(1ホストあたり何人) ——収容人数が増えるほど実効時間単価が下がり、AVDがさらに有利。②VM SKU ——重い業務で上位VMにすると単価が上がりクロスポイントは手前(短時間)に寄る。③予約割引 ——常時起動部分に効かせるとAVD側が下がる。金額は必ず自社パラメータでAzure料金計算ツールに入れ直すこと (本試算は2026年7月時点の目安)。
7 AVD と Windows 365 の選定
観点 AVD(Azure Virtual Desktop) Windows 365(Cloud PC)
課金 従量(VMの稼働時間+ストレージ)。止めれば安くなる 1人あたり月額固定 。使っても使わなくても一定
コストが有利な条件 利用時間にムラがある/夜間停止できる/マルチセッションで集約できる 常時フル利用・台数と使い方が一定・運用を最小化したい
運用の重さ やや重い(スケール設定・イメージ管理・容量設計)。柔軟性は高い 軽い (1人1台のPCとして配布・管理)。細かなチューニングは限定的
デスクトップ形態 マルチセッション(共有)も個人専用も選べる 個人専用のCloud PC(1人1台)
20台での目安 低コスト最優先ならこちら (プール+自動停止)手離れ・固定費・単純さ重視ならこちら
迷ったら:「夜間・週末は使わない/同時利用にムラがある」ならAVD、「日中ずっと全員が使う・情シス工数を割けない」ならWindows 365 。両者は排他ではなく、一般利用者はAVDで集約、常時利用の特定部署だけWindows 365 のような併用も可能。
8 段階導入と注意点
利用実態の把握 :同時利用のピーク人数、利用時間帯、必要スペック(動画/設計系か軽作業か)を測る。ここでAVD/W365の損益分岐が決まる。
小さく検証(PoC) :セッションホスト1〜2台+数名で、ExpressRoute経由の社内アクセス・体感・アプリ互換を確認。
セキュリティ土台を先に :Entra ID条件付きアクセス+MFA、NSGで3389閉、送信固定IP、を最初から。後付けにしない。
コスト運用を仕込む :オートスケール(自動停止)とプロファイル分離を導入時から。
本番展開 :20台規模へ拡大。監視(サインイン・パフォーマンス・コスト)を継続。
落とし穴: ①3389番をうっかり開ける (AVDでは不要。開けると攻撃面が一気に増える)。②オートスケール未設定で常時起動 し、想定外の課金。③ライセンス対象の思い込み(AVD/W365の適用可否は事前確認)。④ExpressRouteの帯域・冗長を過小評価(全員の画面転送が乗る)。
9 まとめ/出典
アクセスは生RDP(3389開放)を避け、AVD reverse connect(受信開放なし・外向き443のみ) が本命。RDPをやめるのではなく「安全に通す」。
20台の低コスト最優先は AVDマルチセッション+オートスケール 。手離れ・固定費なら Windows 365 。利用実態で選ぶ。
土台はNSGで受信最小化・3389閉/送信固定IP/ExpressRoute経由の社内接続/Entra IDゼロトラスト(条件付きアクセス+MFA) 。統制要件が育ったら Azure Firewall を追加。
機能名・価格・ライセンス条件(2026年7月時点)は変更され得ます。設計・見積り時は各公式ドキュメントとAzure料金計算ツールで最新をご確認ください。