Enterprise 利用で組織外部の人とコラボレーションをする方法を考える(Entra 運用編)

はじめに

企業でお仕事をしているときに、組織外部の人とコラボレーションをする機会があると思います。
その時に、毎回問題になるのは、組織外部の人と、どうやってセキュアにコラボレーションをするかということです。

このコラボレーション実現の方法の一つとなり得るものとして、外部 ID に対する Azure Virtual Desktop(AVD) のサポートが、2025 年 11 月に GA されました。
参考: Azure Virtual Desktop の新機能 - Azure外部 ID に対する Virtual Desktop のサポートが一般公開されました

この外部 ID を AVD で利用するためのルールや設定、運用などについて、複数回シリーズで紹介しています。

今回は外部 ID を利用した場合の Entra ID とセッションホストの運用に関する注意点を中心に紹介していきます。

これまでの関連シリーズ

• 第一章：Enterprise 利用で組織外部の人とコラボレーションをする方法を考える(ライセンス編)
• 第二章：Enterprise 利用で組織外部の人とコラボレーションをする方法を考える(外部 ID で AVD 利用編)
• 第三章(本記事)：Enterprise 利用で組織外部の人とコラボレーションをする方法を考える(Entra 運用編)

TL;DR

• 外部 ID で AVD を利用するには、セッションホストの Entra ID 参加 と SSO 構成 が必須。Active Directory Domain Services/Entra Domain Services によるドメイン参加は外部 ID では利用できない
• Entra ID 参加には AADLoginForWindows 拡張機能 が唯一サポートされる手段であり、同名ホスト名が Entra ID に残っていると再登録が失敗する 制約がある
• セッションホスト (VM) を削除しても Entra ID 上のデバイスは自動削除されない ため、VM 削除と合わせて Entra ID 側のデバイス削除も運用フローに組み込む必要がある
• PowerShell (Microsoft Graph + Az モジュール) を使えば、Azure VM として存在しない孤立デバイスを一覧化し、クリーンアップ対象を特定できる

補足
この記事では、AADLoginForWindows 拡張機能の利用時に、Entra ID 上のデバイス名に同名のものがあるとエラーになることを記載しています。
この記事ではAVDにフォーカスしていますが、通常のVM 単体で利用する場合も同じ問題が起きますので、参考としてください。

外部 ID を AVD で利用する際の制限

まずは、外部 ID を利用する際に Entra ID に関連する制限を整理します。

公式ドキュメントから、AVD で外部 ID を利用する際の Entra ID に関連した制約を抜き出すと、以下のような制約が主要な制約として見受けられます。

サポートされている ID と認証方法 - 外部 ID より引用:

セッション ホスト参加の種類: セッション ホストはEntra参加している必要があります。
シングル サインオン: ホスト プールに 対してシングル サインオン を構成する必要があります。

つまり、セッションホスト(Azure VM) は Entra ID 参加 であり、シングルサインオンが構成されているというのが条件です。

AVD では、オンプレミス の Active Directory Domain Services (ADDS) や、 Entra ID Domain Services も利用可能ではあるのですが、外部 ID に関しては、これらのドメインコントローラへアカウントが同期されません。

そのため、Entra ID 参加が必要という条件が必須となるものと想定されます。

AVD のEntra ID 参加方法

では、どのようにしてセッションホストを Entra ID に参加させるかとなります。

ここに関しては、後続の説明の都合も兼ねて、通常の Azure VM と セッションホストのそれぞれの方法をまず、説明いたします。

一般の Azure VM の場合

一般の Azure VM の場合は、大きく二つの方法があります。

Windows OS 上から Entra ID 参加をする方法

これはわかりやすく、OS にログインして、設定 -> アカウントの「職場または学校へのアクセス」から実施する方法となります。

公式ドキュメントではありませんが、すでに、設定方法をわかりやすくまとめていただいている記事がありましたので、こちらをご参照いただくのがよいかと思います。

Microsoft Entra Join の手順 (Windows 11)

補足
Microsoft の公式ドキュメント(既定のエクスペリエンスの間に新しい Windows デバイスを Microsoft Entra に参加させる) では、OOBE の画面で設定する方法が記載されていましたが、Azure VM の場合は、OOBE のエクスペリエンスを利用できないため、利用できません。

Azure VM の拡張機能を利用する方法

もう一つの方法は、AADLoginForWindows 拡張機能を利用する方法です。

この設定方法は、例えば、Azure Portal から Azure VM をデプロイする際に、以下のオプションをチェックすると、拡張機能が自動的にインストールされ、Entra ID 参加が行われます。

AVD のセッションホストの場合

AVD のセッションホストを Entra ID に参加させる場合は、AADLoginForWindows 拡張機能を用いる方法のみとなります。

例えば、Azure Portal からセッションホストを追加する場合は、仮想マシンをホストプールに追加する際に、「参加するドメイン」の設定で、「参加するディレクトリを選択する」箇所で、「Microsoft Entra ID」を選択すると自動的にこの拡張機能がインストールされます。

注意
AVD のセッションホストを Entra ID 参加にする場合は、この手順しかサポートされていないことが、ドキュメントにも記載されています。

Portal の設定方法を記載したタブではわかりづらいので、Azure PowerShell や Azure CLI のタブを選択してみてください。
Azure Virtual Desktop の展開 - 前提条件

参加済みセッション ホストMicrosoft Entra作成する場合は、AADLoginForWindows VM 拡張機能を使用してのみサポートされます。これは、Azure Virtual Desktop サービスでAzure portalまたは ARM テンプレートを使用するときに自動的に追加および構成されます。

具体的な注意点

ここまで、AVD のセッションホストを Entra ID 参加させる場合は、AADLoginForWindows 拡張機能が必須であることを説明しました。

これ自体も注意点ですが、AADLoginForWindows 拡張機能を利用することによる注意点もありますので、まとめます。

具体的には、AADLoginForWindows 拡張機能を利用すると、Entra ID 上に参加済みのデバイスと同名のホスト名の登録ができないという点となります。

Microsoft Entra ID と Azure Roles Based Access Control を使用して、Azureで Windows 仮想マシンにサインインします - デバイス名は既に存在します

なお、Entra ID 自体には、ホスト名の重複を禁止するような仕様はないため、以下の画像のように、同一ホスト名のデバイスを複数作成すること自体は可能です。

つまり、ホスト名の重複禁止に関しては、AADLoginForWindows 拡張機能を利用する際の制約となります。

なぜこれが注意が必要か

結論だけを書くと、Entra ID 上にVMの情報が残り続けてしまうことに関連する内容となります。
以下、詳細に説明します。

Entra ID 上のデバイス情報の削除

まず一つの大きな注意点は、Entra ID 上のデバイス情報の管理です。

AVD のセッションホストの管理において、セッションホストを追加した場合、前述のAADLoginForWindows 拡張機能を利用して Entra ID 参加します。

そのため、セッションホストは自動で Entra ID 上にデバイスが登録されます。

一方で、ホストプールからセッションホストを削除したり、セッションホスト(VM) 自体を削除したりした場合、Entra ID 上からデバイスは自動削除されません。

つまり、Entra ID 上で実際に存在しないデバイスが残り続けてしまいます。

この場合、以下のような問題が発生する可能性があります。

• Entra ID のリソース数のクォータ (既定値 300,000) を超えてデバイス情報が残り、セッションホストを追加時にエラーとなる
• 自分で名前を決めてセッションホストを追加する場合、既に Entra ID に登録済みのデバイス名を使ってしまい、AADLoginForWindows 拡張機能の条件でエラーとなる

つまり、AVD のセッションホストの削除と合わせて、Entra ID 上のデバイス削除も行う運用を考える必要があります。

Entra ID 上のデバイス情報を削除し忘れると、Entra ID 上で実際には利用されていないデバイスが大量に残る可能性があります。(とくに スケーリング プランを利用している場合は、この傾向が顕著となる可能性があります)

AVD セッションホストの命名ルール

個人用のセッションホストをデプロイする場合は、あまり気にしないでよいことかもしれませんが、プール型のマルチセッションのセッションホストを運用するときは注意が必要な点があります。

それは、スケーリング プランなどでセッションホストの追加を自動で実施すると、セッションホスト(VM) 名が -NN のようになり、末尾の数字がインクリメントされていきます。

この際、NN 部分の数字は、Windows OSのコンピュータ名の15文字制約の上限に当たるまで、自動でインクリメントされます。
途中で スケーリング プランなどで、セッションホストを削除しても、消したセッションホスト名を再利用することはなく、新たにインクリメントした値が使われます。

ここでの注意点は以下の通りです。

• OSコンピュータ名の上限 15文字を超えると、スケーリング プランによるセッションホストの自動追加が失敗する
• VM 削除時には、同様に Entra ID 上のデバイスが削除されないため、存在しないデバイス名が Entra ID 上に残り続けてしまう

つまり、ここでも、Entra ID 上のデバイス名が残り続ける問題が発生します。

ここがポイント

外部 ID を利用しない場合、Entra ID 参加は必須ではありませんでした。

このため、既存のドメインコントローラを使って、既存のドメインコントローラにドメイン参加しているケースが多いかと思います。

この場合、ドメインコントローラに対して同名のホスト名でドメイン参加すると、コンピュータが上書きされるなどが行われて、問題が顕在化しにくかったものと思います。(そもそも ADDS のドメイン内のオブジェクトの上限数も Entra ID の既定値と比べて非常に大きいです。)

一方で、外部 ID を利用すると、セッションホストの AADLoginForWindows 拡張機能を用いたEntra ID 参加が必須になることから、AADLoginForWindows 拡張機能の制約でエラーとなる場合が発生するようになり、注意が必要となります。

注意
前述の通りの条件なので、エラーにならないことが多いかと思いますが、古い環境や Entra ID に使っていないデバイス情報が残ること自体は問題であります。
そのため、AADLoginForWindows 拡張機能を使っていない場合でも、同様の状況が発生している場合は、対処することをご検討ください。

対策

Entra ID 上に削除したデバイス情報が残らないように運用することが対策となります。

しかし、実際運用すると消し忘れなどで、既に利用していない Entra ID 上のデバイスが残ってしまうことが起きるかと思います。

この場合、不要なデバイス情報を削除する必要があります。

例えば AVD の場合は、PowerShell を用いて以下のコマンドを順次実行することで、目的の情報を取得できます。

具体的には、現在のサブスクリプション内で「Azure VM としては存在しないが、過去に AVD から Entra ID 上に登録されたデバイス」の一覧と、そのリソース ID を取得します。

# Microsoft Graph にデバイス情報を取得する権限でログイン
Connect-MgGraph -Scopes "Device.Read.All"

# VMリソース情報を取得するために、Azureにもログイン
Connect-AzAccount

# Entra ID 上の AVD 関連のデバイス情報を取得
# 非公式の情報ではありますが、検証を行った2026年05月現在、AADLoginForWindows 拡張機能を用いてAVDをデバイス登録すると、SystemLabels フィールドにAzureVirtualDesktop の値が入るようなので、これを利用してフィルターしている。
# また同様にこちらも非公式情報ではありますが、PhysicalIds フィールドに、Azure のリソース ID の情報が含まれていますので、こちらも利用しています。
$entraAVDDevices = Get-MgDevice -All -Property 'Id,DisplayName,DeviceId,SystemLabels,PhysicalIds,ApproximateLastSignInDateTime' | `
     Where-Object { $_.SystemLabels -contains 'AzureVirtualDesktop' } | `
     Select-Object DisplayName, DeviceId, ApproximateLastSignInDateTime, `
         @{ Name = 'AzureResourceId'; Expression = { `
             $_.PhysicalIds | `
               Where-Object { $_ -match '^\[AzureResourceId\]:' } | `
                 ForEach-Object { $_ -replace '^\[AzureResourceId\]:' } | `
                 Select-Object -First 1 `
         }}

# Azure の現在のサブスクリプションに存在する VM 一覧を取得
$existingVMIds = (Get-AzVM).Id

# Entra ID 上のデバイス一覧で、Azure VMリソースとしては存在しないものを一覧化
$orphanedDevices = $entraAVDDevices | Where-Object { `
    $_.AzureResourceId -ne $null -and `
    $_.AzureResourceId.ToLower() -notin $existingVMIds `
}

# 最終的な情報を出力
$orphanedDevices | Format-Table DisplayName, DeviceId, ApproximateLastSignInDateTime, AzureResourceId -AutoSize

#成功すると以下のような出力が得られます
#DisplayName  DeviceId    ApproximateLastSignInDateTime AzureResourceId
#-----------  --------    ----------------------------- ---------------
#avdext-sh-0  <デバイスID> 2026/05/02 7:22:16            <リソースID>
#avdext-lab-0 <デバイスID> 2026/05/17 3:00:36            <リソースID>

上記の出力結果から、実際に Entra ID 上のデバイス情報を削除すると、目的の作業は完了となります。

まとめ

この記事では、外部 ID を用いてAVDを運用する際の注意点を記載しました。

具体的には、Entra ID 上のデバイス情報の管理に注意が必要となりますので、一つの参考としていただけますと幸いです。

参考

• サポートされている ID と認証方法 - 外部 ID
• サポートされている ID と認証方法 - シングル サインオン (SSO)
• Microsoft Entra ID と Azure Roles Based Access Control を使用して、Azureで Windows 仮想マシンにサインインします - デバイス名は既に存在します
• Microsoft Entra Join の手順 (Windows 11)
• 方法: Microsoft Entra ID で古くなったデバイスを管理する
• Microsoft Entra サービスの制限と制約

ドキュメントフィードバック

今回も検証や調査を実施するにあたりまして、以下のドキュメントについて、よりわかりやすくすることができるのではないかと考えましたので、Microsoftにフィードバックさせてもらいました。

Deploy Azure Virtual Desktop - Prerequisites

(投稿した英語文)
In the Prerequisites section, the following important information is provided under both the Azure PowerShell and Azure CLI tabs:

===
If you want to create Microsoft Entra joined session hosts, we only support this using the AADLoginForWindows VM extension, which is added and configured automatically when using the Azure portal or ARM template with the Azure Virtual Desktop service.
===
However, this information does not appear under the Azure Portal tab. I believe this detail is particularly important for customers who plan to deploy Microsoft Entra ID–joined session hosts.

I recommend that Microsoft include the same information in the Azure Portal tab to ensure consistency and to help users avoid configuration issues.

(日本語訳)
Prerequisites（前提条件） セクションでは、Azure PowerShell タブと Azure CLI タブの両方に、次のような重要な記述があります。
===
If you want to create Microsoft Entra joined session hosts, we only support this using the AADLoginForWindows VM extension, which is added and configured automatically when using the Azure portal or ARM template with the Azure Virtual Desktop service.
===
しかし、Azure Portal タブにはこの情報が記載されていません。
特に Entra ID 参加のセッションホストを利用したいユーザーにとっては非常に重要な情報 であるため、ここに記載がないのは混乱を招く可能性があります。

そのため、Azure Portal タブにも同様の情報を追記することを Microsoft に強く推奨します。