クラウドサービス

Windows 365 Cloud PC

専有または共有の Windows 環境を月額ライセンスで配る SaaS 型 Cloud PC。Intune と Entra ID に統合し、AVD より基盤運用を抽象化する。

基礎運用上の優秀性セキュリティコスト最適化
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. ライセンスと方針の割り当てからCloud PCを自動作成する。
  2. 端末はEntra IDへ参加し、Intuneへ自動登録される。
  3. 割り当て解除後の猶予と削除条件を変更前に確認する。

解決する課題

物理 PC を調達・キッティング・配送せずに、ユーザー1人ひとりに専有の Windows 環境をクラウドから渡したい場面で使います。新入社員のオンボーディング、派遣・委託先、BYOD(私物端末)、在外拠点などで、端末にデータを残さず標準化された業務環境を即座に配布できます。

  • 端末を選ばず、個人専有の Windows 環境をどこからでも使いたい
  • 業務データを端末ではなくクラウド側に集約し、情報漏えいを防ぎたい
  • VDI(仮想デスクトップ基盤)の設計・運用を避け、シンプルに人数分だけ配りたい
  • 費用をユーザー単位の固定月額にして予算を立てやすくしたい
  • 既存の Intune / Entra ID 管理の中に、物理 PC と同じ感覚で組み込みたい

主要概念と用語

  • Cloud PC: ユーザーに専有で割り当てられる仮想の Windows PC。1ユーザー1台が基本で、状態が永続する
  • Windows 365 Enterprise: Intune と統合し、カスタムイメージ・ネットワーク構成・きめ細かい管理ができる企業向けエディション
  • Windows 365 Business: 最大300席で、Intuneなしでも始められる小規模向けエディション
  • プロビジョニングポリシー: どのイメージ・ネットワーク・割り当て先で Cloud PC を払い出すかを定義するテンプレート
  • ライセンス(サイズ): vCPU・メモリ・ストレージの組み合わせで決まる固定月額のプラン。ユーザーに割り当てると Cloud PC が払い出される
  • Microsoft Entra 参加 / ハイブリッド参加: Cloud PC を ID 基盤にどう参加させるか。クラウド完結かオンプレ AD 連携かを選ぶ
  • Azure Network Connection(ANC): Cloud PC を利用者の Azure 仮想ネットワークに接続し、オンプレや社内リソースへ到達させる構成(Enterprise)
  • Windows アプリ / ブラウザ接続: 各種クライアントや Web ブラウザから Cloud PC へ接続する経路
  • Windows 365 Flex(旧 Frontline): 2026年5月に改称された交代利用向けの提供形態。Dedicatedは1ライセンスで最大3人に専用Cloud PCを割り当て、同時に1人だけ利用する。Sharedはプールの非永続Cloud PCを複数人で共有し、1ライセンスにつき同時に1人だけ利用する

仕様・制限・クォータ

  • Cloud PC は1ユーザー1台の専有が基本で、AVD のようなマルチセッション共有とは設計思想が異なる
  • 選べるスペックはサイズ(vCPU・メモリ・ストレージ)の定義済みプランから選ぶ形で、任意の VM サイズを自由指定するわけではない
  • ID 基盤は Microsoft Entra ID を前提とし、オンプレ資産に到達するにはハイブリッド参加や Azure Network Connection を併用する
  • Enterprise は Intune での管理が前提。Business は Intune なしでも開始できるが、規模や機能に上限がある
  • Business は最大300席。Flex Dedicatedは1ライセンスで最大3台を割り当てられるが同時利用は1台、Flex Sharedは共有プールの1セッションが単位になる
  • 利用には対象ユーザーへのライセンス割り当てが必要で、割り当てが Cloud PC のプロビジョニングを起動する
  • カスタムイメージのサイズや、テナントあたりのプロビジョニング規模には実用上の上限があるため、大規模展開時は分割を検討する

内部の仕組み

横にスクロール

利用者へのライセンスとプロビジョニング方針の割り当てから、Cloud PCの作成、Entra参加、Intune登録、利用開始までの流れ
ライセンス、利用者グループ、プロビジョニング方針の組み合わせが作成を起動します。解除後の猶予はエディションとFlexの方式で異なるため、対象差分と削除条件を変更前に確認します。

Windows 365 は AVD の技術基盤の上に構築された SaaS 型のレイヤーです。AVD では利用組織がホストプールや VM を構成しますが、Windows 365 ではそれらが Microsoft 側で抽象化され、利用者は「ユーザーにサイズを割り当てる」だけで専有 Cloud PC が払い出されます。

  • 管理者は プロビジョニングポリシーでイメージとネットワークを定義し、対象ユーザーにライセンスを割り当て
  • 割り当てを起点に Microsoft が Cloud PC を自動プロビジョニングし、Entra ID に参加させる
  • ユーザーは Windows アプリやブラウザから接続し、専有の Windows デスクトップにサインインする
  • 接続はリバース接続を用い、Cloud PC 側で受信用のパブリックポートを開ける必要がない
  • Enterprise では Intune がポリシー適用・更新・アプリ配布を担い、物理 PC と同じ管理面に統合される
解除方法で猶予の有無が変わる

Enterprise/BusinessやFlex Dedicatedでは、ライセンスまたは対象割り当ての解除後に通常7日間の猶予を経てプロビジョニング解除へ進みます。一方、Flex Sharedのグループ割り当て解除は猶予なしで削除に進む場合があります。Enterpriseの保持スナップショット復元もライセンス期限切れが対象で、管理者によるライセンス削除は対象外です。

AVD との関係

Windows 365 は AVD の上に乗った SaaS です。AVD が「部品(ホストプール・VM・スケーリング)を組み立てる IaaS 寄り」なのに対し、Windows 365 は「ユーザーにサイズを割り当てるだけの完成品」。設計の自由度より運用のシンプルさと費用の予測性を優先する場合に向きます。

設計パターン / ベストプラクティス

  • まずクラウド完結を検討: オンプレ依存がなければ Entra 参加だけで始め、ネットワーク構成を最小化する
  • オンプレ到達は ANC で接続: 社内リソースが必要な場合のみ Azure Network Connection で仮想ネットワークに接続する
  • イメージは標準化: 業務アプリ導入済みのカスタムイメージをプロビジョニングポリシーに紐づけ、配布を均質化する
  • 管理は Intune に集約: 更新・コンプライアンス・アプリ配布を Intune ポリシーで一元化し、物理 PC と同じ運用に乗せる
  • 規模に応じてエディション選択: 小規模で手早く始めるなら Business、Intune 連携や細かい制御が要るなら Enterprise を選ぶ
  • 交代利用は Flex: 状態保持が必要ならDedicated、都度初期化できる共有端末ならSharedを選び、同時利用数とプロファイル要件を先に決める

運用・監視

  • Microsoft Intune 管理センター / Windows 365 の管理画面で、Cloud PC の状態・プロビジョニングの成否・接続状況を確認する
  • プロビジョニング失敗時は、イメージ・ネットワーク接続(ANC)・ライセンス割り当て・Entra 参加の各要素を切り分ける
  • 接続できないときは、ID 認証・クライアント側のネットワーク・必要な送信通信を確認する
  • 更新やアプリ配布は Intune ポリシーで行い、物理 PC と同じパッチ運用に統合する
  • 利用状況や接続品質は エンドポイント分析などのレポートで継続的に把握する

コスト

Windows 365 の最大の特徴は、サイズ別の固定月額でユーザーあたりの費用が予測しやすい点です。AVD のように VM の稼働時間で課金されるのではなく、ライセンス単位で課金されます。

  • ユーザー単位の固定月額のため、予算化と按分が容易
  • スペックをサイズプランで選ぶだけで、VM サイズやスケーリングを設計する必要がない
  • 常時専有が不要な交代制利用者は Windows 365 Flexを使い、同時利用数に合わせてライセンスを見積もる
  • 利用が断続的で稼働時間を細かく絞れるなら、従量課金の AVD のほうが安くなるケースもあるため用途で選ぶ
  • 別途、オンプレ接続用のネットワークや、配信するアプリのライセンス費用は考慮する
固定費の前提を理解する

Cloud PC は割り当てている間、使っていなくても固定月額が発生します。短時間しか使わない・稼働を細かく絞りたい用途では、稼働時間で課金される AVD のほうが安い場合があります。利用パターンに応じて Windows 365 と AVD を使い分けましょう。

セキュリティ

  • データを端末に残さない: 画面情報だけを転送するため、私物端末や社外からのアクセスでもローカルに業務データが残りにくい
  • Microsoft Entra ID + 条件付きアクセスで、多要素認証・端末準拠・場所ベースのアクセス制御を強制する
  • リバース接続により Cloud PC の受信ポートを開けずに済み、攻撃面を縮小できる
  • Intune によるコンプライアンスポリシー・更新適用・Defender 連携で、エンドポイントを保護する
  • RBAC でプロビジョニングやユーザー割り当てなどの管理権限を分離する
  • ディスクの暗号化や、クリップボード・ドライブリダイレクトの制御で、データの持ち出し経路を制限する
アンチパターン

Cloud PC を「物理 PC の置き換え」とだけ捉え、ID 側のアクセス制御を後回しにするのは危険です。クラウドからどこでも接続できる以上、条件付きアクセスによる多要素認証と端末準拠の強制が入口の要になります。ID を固める前に広く配布しないようにしましょう。

関連サービス・比較

同じ Azure 上で Windows 環境を配信するサービスとして Azure Virtual Desktop(AVD) と比較されます。専有 PC を固定月額で配る Windows 365 に対し、AVD は共有も含めた柔軟な構成と従量課金が特徴です。

観点Windows 365 Cloud PCAzure Virtual Desktop
提供形態SaaS 型の専有 Cloud PCVDI / DaaS の基盤を組み立てる
割り当て1ユーザー1台の専有専有とマルチセッション共有を選べる
課金サイズ別の固定月額VM の稼働時間に応じた従量課金
管理Intune で物理 PC と同様に管理ホストプールや VM を利用組織が管理
向く用途予測可能な常時利用と運用の簡素化稼働の最適化や柔軟な構成が要る用途
使い分けのまとめ

予測可能な固定月額で1人1台を配り、運用をできるだけ単純にしたいなら Windows 365。稼働時間の最適化やマルチセッションによる集約、細かいインフラ制御が要るなら AVD。他クラウドでは専有デスクトップを配る AWS WorkSpaces が近い位置づけです。

ハンズオン / CLI例

Windows 365 の Cloud PC は主に Intune / Windows 365 管理センターや Microsoft Graph で管理します。CLI からは Azure CLI の az rest で Microsoft Graph を呼び出せます。

# サインインして対象テナントを選択
az login

# Cloud PC 関連の API は Microsoft Graph 経由で呼び出す
# プロビジョニングポリシー一覧の取得
az rest \
  --method get \
  --url "https://graph.microsoft.com/v1.0/deviceManagement/virtualEndpoint/provisioningPolicies"

# 払い出し済み Cloud PC の一覧を取得
az rest \
  --method get \
  --url "https://graph.microsoft.com/v1.0/deviceManagement/virtualEndpoint/cloudPCs"

Azure Service

Windows 365 Cloud PCを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

エンドユーザー / VDI

比較で見る軸

クラウド: Azure / カテゴリ: エンドユーザー / VDI / 難易度: basic

導入後に効く点

端末はEntra IDへ参加し、Intuneへ自動登録される。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
エンドユーザー / VDI
難易度
basic
関連資格
設計柱
operational / security / cost

判断チェックリスト

  • 自社の用途が「エンドユーザー / VDI / operational」に近いか確認する。
  • 強みである「ライセンスと方針の割り当てからCloud PCを自動作成する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

エンドユーザー / VDIoperationalsecuritycost