Microsoft Entra IDの「グループ」には「ユーザーグループ」と「デバイスグループ」の2種類があり、どちらも動的メンバーシップ グループ（以下、動的グループ）として設定できます。
動的グループとは、ルールに基づいて、グループのメンバー（ユーザーやデバイス）を自動的に追加・削除する機能で、活用すれば手作業による管理が不要になり、メンテナンスの自動化や追加漏れなどのヒューマンエラーを防ぐことができます。
今回はデバイスグループに焦点を絞り、Microsoft Intune利用時に便利に活用できる動的グループについて、いくつかご紹介したいと思います。
なお、ユーザーは「Microsoft 365 グループ」と「セキュリティグループ」の両方に参加できますが、デバイスは「セキュリティグループ」のみに参加できる仕様ですので、本項では「デバイスのセキュリティグループ」についてご説明していきます。
1.前提条件
動的グループを利用するには、Microsoft Entra ID P1 または P2 ライセンスが必要です。これらを含むライセンス（例えば Microsoft 365 Business Premium や Enterprise Mobility+Security E3 など）でも利用可能です。
2.設定方法
Microsoft Entra 管理センターのグループ作成画面にてメンバーシップの種類を「動的デバイス」に設定すると「動的クエリの追加」から設定することができます。
3.パターン別設定方法
パターン1： 会社端末を抽出する
❓️ 課題:会社貸与端末のみに当てたいセキュリティポリシーがある（BYODは除外したい）
💡 解決策: デバイスの所有者（deviceOwnership）属性で「会社所有」端末だけのグループが作成できます。
💡 解決策: デバイスの所有者（deviceOwnership）属性で「会社所有」端末だけのグループが作成できます。
1(device.deviceOwnership -eq "Company")
パターン２： 特定メーカーのデバイスを抽出する
❓️ 課題:対象メーカーだけに適用したいポリシーがある
💡 解決策: デバイス製造元（deviceManufacturer）でメーカー別グループを作成できます。例では「LENOVOグループ」を作成しています。
💡 解決策: デバイス製造元（deviceManufacturer）でメーカー別グループを作成できます。例では「LENOVOグループ」を作成しています。
1(device.deviceManufacturer -eq "LENOVO")
パターン3： 仮想デバイスを抽出する
❓️ 課題:ストレージ暗号化(Bitlocker)を必須とするコンプライアンスポリシーを適用しているが、仮想マシンの場合、コンプライアンスNGとなってしまう
💡 解決策: デバイスモデル（deviceModel）で仮想デバイスを抽出して、例外として設定します。
💡 解決策: デバイスモデル（deviceModel）で仮想デバイスを抽出して、例外として設定します。
1(device.deviceModel -startsWith "Virtual") or (device.deviceModel -startsWith "Cloud")
パターン4： 特定拠点のデバイスを抽出する
❓️ 課題:特定の拠点のみにポリシーを適用したい (デバイス名は拠点ごとに命名ルールがある）
💡 解決策:命名ルールがあればデバイス名（displayName）で実現できます。例えば大阪支店にあるPCのデバイス名が「OSK-」で始まる場合は以下ルールで抽出できます。
💡 解決策:命名ルールがあればデバイス名（displayName）で実現できます。例えば大阪支店にあるPCのデバイス名が「OSK-」で始まる場合は以下ルールで抽出できます。
1(device.displayName -startsWith "OSK-")
パターン5： ABM登録済iOS端末の特定
❓️ 課題:ABMに登録されているデバイスを特定したい。
💡 解決策: 登録プロファイル名（enrollmentProfileName）を使い、ABM経由で登録された端末だけを抽出できます。
💡 解決策: 登録プロファイル名（enrollmentProfileName）を使い、ABM経由で登録された端末だけを抽出できます。
1
(device.enrollmentProfileName -eq "（Intuneで設定したABMプロファイル名）")
パターン6： Intune未登録の Windows端末を検出したい
❓️ 課題:Intuneに登録されていないWindows端末を把握したい。
💡 解決策: デバイスのOS（deviceOSType）が「Windows」かつ、参加の種類（deviceTrustType）が「Microsoft Entra joined」であり、かつ MDM（deviceManagementAppId）が「Intune」で管理されていないデバイスを抽出することで把握できます。
💡 解決策: デバイスのOS（deviceOSType）が「Windows」かつ、参加の種類（deviceTrustType）が「Microsoft Entra joined」であり、かつ MDM（deviceManagementAppId）が「Intune」で管理されていないデバイスを抽出することで把握できます。
1(device.deviceManagementAppId -ne "0000000a-0000-0000-c000-000000000000") and (device.deviceTrustType -eq "AzureAD") and (device.deviceOSType -eq "Windows")
4.正しく動作するか確認するには
動的グループのルールを作成したら、実際にどのデバイスが該当するか事前に確認することができます。動的クエリ設定画面にて「ルールの検証」をクリックすると、テスト用のデバイスを選択する画面が表示されます。
ここで「＋デバイスの追加」をクリックして特定のデバイスを選択すると、そのデバイスが作成したルールに一致するかどうかを確認することができます。
特に複雑な条件式を使用する場合や、複数の条件を組み合わせる場合は、この検証機能を使って事前にテストすることをお勧めします。
5.注意点
動的グループは便利ですが万能ではないため、静的グループと使い分けるために、以下の特性を理解しておくことが重要です。
- 手動で追加・削除はできない
- 動的グループのメンバーは「ルール」に基づいて自動構成されます。「このPCだけ例外的にグループから外したい」と思っても、手動での個別除外はできません。
- 反映は即時ではない
- 動的グループのメンバーシップはリアルタイムではありません。新しいデバイスがルールに一致しても、グループのメンバーとして反映されるまで数分～24時間以上かかる場合があります。即時性を求められるセキュリティポリシーには注意が必要です。
また、既に Entra に登録済のユーザーやデバイスではなく、新規に追加される場合は、なおさら想定通りのタイミングで反映されない場合も多いです。キッティングプロセスで動的グループを活用される場合も多いと思いますが、実際にオンボーディングシナリオをテストして、想定どおりの処理となることをしっかり確認しましょう。
6.まとめ
動的デバイスグループは、Intune運用の自動化とセキュリティ強化の第一歩です。 「手動では管理しきれない」「ルールで明確に分けられる」ものから動的グループに置き換えていくのが成功の鍵です。まずは管理しやすい簡単な動的グループから試してみてはいかがでしょうか。
