Microsoft Entra のグループを Microsoft Intune の割り当てに使っている管理者がまず押さえるべき結論は、今回の公式情報は「すぐに移行が必要な破壊的変更」ではなく、Intuneで使うMicrosoft Entraグループの設計を見直すための重要な整理だという点です。特に、ポリシーやアプリの対象を決めるときは、何でも動的グループで分けるのではなく、Securityグループ、All users / All devices、割り当てフィルターを使い分けることが実務上のポイントになります。
Microsoft Intune は、ユーザーやデバイスを地域、部門、ハードウェア特性などで整理するために Microsoft Entra ID のセキュリティグループを利用します。さらに、Intune管理センターのグループ画面は Microsoft Entra のグループUIと連携しており、Intuneで作成したグループは Microsoft Entra や Microsoft 365 など、同じグループUIを共有する製品からも見える構成です。(Microsoft Learn)
Microsoft Entra の「Add groups to organize users and devices for Microsoft Intune」で確認すべき更新ポイント
2026年7月1日付の公式リポジトリ履歴では、対象ドキュメントに対して「Metadata updates」として更新が確認できます。内容面では、Intuneで使うグループの作成、権限、メンバーシップ、All users / All devices、割り当てフィルターの使い分けが整理されています。(GitHub)
| 確認項目 | 公式情報で押さえる内容 | 管理者への影響 |
|---|---|---|
| 更新の性質 | 2026年7月1日の履歴はメタデータ更新として確認できる | 直ちに設定変更が必要な機能変更ではなく、運用設計の再確認が中心 |
| Intuneで使うグループ | IntuneではMicrosoft Entra IDのセキュリティグループを使う | Microsoft 365グループを安易に割り当て対象にしない |
| 権限管理 | グループ作成者、所有者、十分なEntra RBAC権限を持つユーザーがグループを管理できる | Intune管理者権限を広く配らず、Groups Administratorなど最小権限を検討する |
| メンバーシップ | Assigned、Dynamic User、Dynamic Deviceを用途で選ぶ | 手動管理、属性ベース自動化、デバイス自動分類を分けて設計する |
| All users / All devices | Intune内だけで使える仮想グループ | 全社標準ポリシーでは動的グループを乱立させず、仮想グループを活用する |
| 割り当てフィルター | OS、メーカー、モデル、所有形態、デバイスカテゴリなどの条件ではフィルターが有効 | Intune専用のデバイス絞り込みは、動的デバイスグループよりフィルターを優先検討する |
| 移行期限 | 対象ドキュメント上、本件に伴う強制移行期限は確認できない | 期限対応ではなく、既存設計の棚卸しとして進める |
今回のポイントは「グループを作れるか」ではなく、どの単位で割り当てると、後から運用しやすく、誤配布や遅延を減らせるかです。特に大規模テナントでは、グループ数、入れ子構造、動的グループのルール、除外設定の組み合わせが複雑になるほど、アプリやポリシーの配布トラブルを追跡しにくくなります。
影響範囲：Intuneのポリシー、アプリ、RBAC割り当てに関係する
この更新内容の影響を受けるのは、Microsoft Entraそのものを単独で使っている管理者だけではありません。Intuneで次のような割り当てを行っている組織は、グループ設計を確認する価値があります。
| 対象 | 影響する場面 | 確認すべきこと |
|---|---|---|
| デバイス構成プロファイル | Windows、macOS、iOS/iPadOS、Android向け設定の配布 | 対象グループがユーザー用かデバイス用か明確か |
| コンプライアンスポリシー | 暗号化、OSバージョン、パスコードなどの準拠条件 | All devicesやフィルターで十分ではないか |
| アプリ配布 | 必須アプリ、利用可能アプリ、アンインストール割り当て | アプリごとに重複グループを作りすぎていないか |
| Endpoint Security | セキュリティベースライン、ウイルス対策、ファイアウォール | 本番適用前にパイロットグループで検証しているか |
| Intune RBAC | Endpoint Security Managerなどの管理ロール割り当て | 動的グループではなく、手動管理のAssignedグループにしているか |
| グローバル拠点管理 | 国、地域、部門、デバイス所有形態ごとの展開 | 地域名だけでなく用途が分かる命名になっているか |
Intuneでは、ポリシーやアプリの割り当て、管理者が表示・管理できる範囲の制御に Microsoft Entra グループが使われます。Microsoftのパフォーマンス推奨でも、Intuneにおけるグループはアプリやポリシーなどの割り当て対象であり、RBACのスコープグループにも関係すると説明されています。(Microsoft Learn)
設定変更の有無：新しい必須設定ではなく、既存設計の見直しが中心
今回の情報から、既存テナントに対して自動的に何かが変更される、または特定日までに移行しなければならない、という内容は確認できません。管理者が対応すべきことは、既存のグループ設計が現在のMicrosoft推奨に合っているかを確認することです。
特に確認したいのは、次の4点です。
| 確認ポイント | 望ましい状態 | 見直しが必要な例 |
|---|---|---|
| グループ種類 | Intuneで使う対象はSecurityグループ | Microsoft 365グループをそのままIntune割り当てに使おうとしている |
| ユーザーとデバイスの分離 | ユーザー用、デバイス用を分けている | 1つのグループにユーザーとデバイスを混在させている |
| 動的グループの用途 | 条件が必要な場面だけに使う | OSやメーカーだけの単純条件で大量の動的グループを作っている |
| 所有者と説明 | 所有者、用途、変更責任者が分かる | グループ名だけでは何に使われているか分からない |
公式ドキュメントでは、Intuneで使うグループはセキュリティ有効化されたグループである必要があり、通常は作成時にGroup typeをSecurityに設定します。また、既定のMicrosoft 365グループはセキュリティ有効ではなく、メンバーとしてサポートするのはユーザーのみで、Intuneではサポートされないと説明されています。(Microsoft Learn)
Intuneで使うMicrosoft Entraグループの選び方
Intuneのグループ設計で失敗しやすいのは、「部署別」「OS別」「アプリ別」「地域別」など、思いついた単位でグループを増やしてしまうことです。最初に決めるべきなのは、そのグループを何のために使うのかです。
| 方式 | 向いている用途 | 避けたい使い方 |
|---|---|---|
| Assignedグループ | 管理者ロール、パイロット配布、例外対象、少人数の明示管理 | 数千台規模の端末を手作業で維持する |
| Dynamic Userグループ | 部門、国、職種などユーザー属性に基づく自動分類 | Intune RBACのような特権付与に広く使う |
| Dynamic Deviceグループ | Autopilotプロファイル、Intune以外でも使うデバイス分類 | OS種別だけのIntune専用分類を大量に作る |
| All users | 全ユーザー向けアプリ、全社標準のユーザー対象ポリシー | 一部ユーザーだけに配るポリシーの代替にする |
| All devices | 全端末向けコンプライアンス、ベースライン、共通構成 | 除外条件を複雑なグループだけで処理する |
| 割り当てフィルター | OS、モデル、メーカー、所有形態、デバイスカテゴリでの絞り込み | Conditional Accessやライセンス割り当てなどIntune外の用途に使う |
Dynamic Userグループを使う場合、動的グループのメンバーになる各ユーザーにはMicrosoft Entra ID P1ライセンスが必要です。一方、デバイスベースの動的グループに含まれるデバイスには特定のEntra IDライセンスは不要とされています。(Microsoft Learn)
管理者権限は「Intune Administratorを配る」より最小権限で考える
グループ作成や編集を誰に許可するかは、Intune運用の安全性に直結します。公式ドキュメントでは、既定ではMicrosoft EntraのユーザーアカウントがEntra RBACロールなしで新しいグループを作成・構成でき、その権限はIntune管理センターのGroupsノードにも及ぶと説明されています。一方で、他のユーザーが作成したグループを編集・管理するための最小の組み込みロールとして、Groups Administratorが挙げられています。(Microsoft Learn)
実務では、次のように役割を分けると管理しやすくなります。
| 役割 | 推奨される権限設計 | 理由 |
|---|---|---|
| Intune全体管理者 | Intune Administratorを限定的に付与 | すべてのIntune設定に影響するため |
| グループ管理担当 | Groups Administratorを検討 | グループ編集だけなら過剰なIntune権限を避けられる |
| 部門IT担当 | 所有者として対象グループだけ管理 | 部門単位のメンバー管理を委任しやすい |
| ヘルプデスク | 必要に応じて閲覧権限や限定ロール | 誤って配布対象を変えるリスクを下げる |
重要なのは、グループを編集できる人は、Intuneポリシーの配布対象を実質的に変えられるという点です。たとえば「全社Windows端末」グループに誤って個人所有端末を追加すれば、意図しない構成プロファイルやアプリが配布される可能性があります。
グループ作成手順：Intune管理センターで作っても実体はMicrosoft Entraグループ
Intune管理センターからグループを作成すると、実際にはMicrosoft Entra ID上にグループが作成されます。公式手順では、Microsoft Intune admin centerにサインインし、Groups > New groupから作成します。(Microsoft Learn)
| 手順 | 操作 | 実務上の注意 |
|---|---|---|
| 1 | Intune管理センターにサインイン | グループ作成・管理に必要な権限を持つアカウントを使う |
| 2 | Groups > New groupを選択 | 表示されるNew GroupペインはMicrosoft Entra側と同じUI |
| 3 | Group typeでSecurityを選ぶ | Intune割り当て用の基本設定 |
| 4 | Group nameを入力 | 例：INTUNE-WIN11-PILOT-DEVICES のように用途を明確にする |
| 5 | Group descriptionを入力 | どのポリシー、アプリ、管理範囲で使うかを書いておく |
| 6 | Membership typeを選ぶ | Assigned、Dynamic User、Dynamic Deviceから用途で選ぶ |
| 7 | 必要に応じてOwnersを追加 | 作成者だけに依存しないよう、運用責任者を複数設定する |
| 8 | Createを選択 | 作成後、IntuneとEntraの両方から確認できる |
命名は地味ですが、グローバル運用では特に重要です。たとえば Sales だけでは、国なのか部門なのか、アプリ配布用なのかRBAC用なのか分かりません。INTUNE-JP-SALES-USERS-APPS、INTUNE-GLOBAL-WIN11-CORP-DEVICES のように、サービス、地域、対象、用途を入れると、後から監査しやすくなります。
ユーザーとデバイスを同じグループに混在させない
公式ドキュメントでは、ユーザーとデバイスを同じグループに含めることは、Intune展開時のポリシー競合や予測しにくい動作につながる可能性があるため避けるよう明記されています。(Microsoft Learn)
たとえば、次のような設計は避けるべきです。
| 悪い例 | 起こり得る問題 | 改善例 |
|---|---|---|
Tokyo-Office にユーザーとPCを混在 | ユーザー対象ポリシーとデバイス対象ポリシーの判定が分かりにくい | Tokyo-Users と Tokyo-Devices に分ける |
| アプリ配布用グループにユーザーと共有端末を混在 | 必須アプリや利用可能アプリの表示が想定とずれる | ユーザー配布かデバイス配布かを先に決める |
| RBAC用グループにデバイスを含める | 管理ロール割り当ての意図が不明確になる | 管理者ユーザーだけのAssignedグループにする |
「人に配るもの」と「端末に配るもの」は、管理の考え方が違います。Microsoft 365 Appsのようにユーザー単位で配布したいもの、BitLockerやファイアウォール設定のように端末単位で適用したいものを、最初に分けて設計してください。
All users / All devices は全社配布の土台として使える
Intuneには、Microsoft Entraで作成するグループとは別に、Intune管理センター内で使える仮想グループとしてAll usersとAll devicesがあります。All usersはIntuneライセンスを持つすべてのユーザー、All devicesはIntuneに登録されたすべてのデバイスを自動的に含みます。(Microsoft Learn)
この2つは、全社標準のベースラインに向いています。
| 使い方 | 例 | 補足 |
|---|---|---|
| All devices | 全端末に最低限のコンプライアンスポリシーを配布 | その上で特定条件だけフィルターや追加グループで調整する |
| All users | 全ユーザーにCompany Portalや標準アプリを配布 | 対象外ユーザーがいる場合はライセンスや除外設計を確認する |
| All devices + フィルター | Windows端末だけに構成プロファイルを配布 | 動的な「全Windows端末」グループを作らずに済む |
| All users + フィルター | 特定端末条件でアプリ構成を絞り込む | ユーザー対象とデバイス条件を分けて管理しやすい |
Microsoftのパフォーマンス推奨では、All users / All devicesはIntuneの仮想グループであり、Microsoft Entra IDからIntuneへ継続的に同期する必要がないため、通常のEntraグループより管理オーバーヘッドが低いと説明されています。(Microsoft Learn)
動的デバイスグループより割り当てフィルターを優先すべき場面
今回の内容で特に実務的なのは、OS種別やメーカー、モデル、所有形態などの単純なデバイス条件であれば、動的デバイスグループではなく割り当てフィルターを検討するという点です。
Microsoftは、Intuneポリシーやアプリをデバイスプロパティに基づいて割り当てる場合、割り当てフィルターを使うことで対象範囲を細かく絞れると説明しています。フィルターはデバイスの登録時、チェックイン時、またはポリシー評価時に評価されます。(Microsoft Learn)
| やりたいこと | 従来ありがちな設計 | 見直し後の設計 |
|---|---|---|
| Windows端末だけにポリシー配布 | All Windows Devices 動的デバイスグループを作る | All devicesに割り当て、Windows条件のフィルターを適用 |
| 会社所有端末だけに制限を適用 | 所有形態別の動的グループを作る | All devices + ownership条件のフィルター |
| Surface端末だけに設定配布 | モデル名ベースの動的グループを作る | All devices + model/manufacturer条件のフィルター |
| iPadだけにアプリを配布 | iPad動的グループを作る | ユーザーグループ + iPad条件のフィルター |
Microsoftのパフォーマンス推奨では、OS種別、メーカー、モデル、所有形態、デバイスカテゴリのような単純なデバイスプロパティを使う場合、Intuneだけで使う動的デバイスグループより割り当てフィルターを検討するよう説明されています。動的グループは、Autopilotプロファイル、Conditional Access、ライセンス割り当てなど、Intune以外のワークロードでも使う場合には引き続き必要です。(Microsoft Learn)
大規模環境ではグループ同期の遅延も考慮する
グローバル企業や10万台規模の大規模Intune環境では、グループの設計がそのまま配布速度やトラブル調査のしやすさに影響します。Microsoftのパフォーマンス推奨では、大きなグループほどMicrosoft Entra IDとIntune間のメンバーシップ更新に時間がかかる可能性があり、通常の更新は5分以内に行われるものの即時ではないと説明されています。(Microsoft Learn)
特に注意したいのは、次のようなケースです。
| ケース | リスク | 対策 |
|---|---|---|
| グループに追加してすぐ端末登録を開始する | 登録時点で対象判定が間に合わない可能性がある | グループ追加後、反映時間を見込んでから登録する |
| 10万メンバー超の大規模グループを初めて使う | 初回同期に時間がかかる可能性がある | パイロット、段階展開、All devices活用を検討する |
| 大きな入れ子グループを一度に変更する | Intune側のターゲティング処理に負荷がかかる | 変更を分割し、展開時間帯を管理する |
| アプリごとに専用グループを量産する | Intuneが監視するグループ数が増え非効率 | 同じ対象ならグループを再利用する |
Microsoftは、同じ対象に対してポリシーごと・アプリごとに重複グループを作るのではなく、同じグループオブジェクトを複数ポリシーで再利用することを推奨しています。たとえば、Engineeringユーザー向けに10個のポリシーを配るなら、同じEngineeringグループを使う方が、10個の別グループを作るより効率的です。(Microsoft Learn)
移行期限：本件に伴う強制移行日は確認されていない
管理者が気になる「いつまでに対応すべきか」については、対象の公式情報から、本件に伴う強制移行期限や廃止日は確認できません。したがって、緊急対応として全グループを作り直す必要はありません。
ただし、次の条件に当てはまる場合は、次の四半期や大規模展開前のタイミングで見直す価値があります。
| 見直し対象 | 優先度 | 理由 |
|---|---|---|
| ユーザーとデバイスが混在するグループ | 高 | Intune割り当ての予測が難しくなる |
| Microsoft 365グループをIntune割り当てに使っている設計 | 高 | 既定のMicrosoft 365グループはIntuneでサポートされない |
| OS別だけの動的デバイスグループ | 中 | All devices + フィルターで置き換えられる可能性がある |
| アプリごとに重複した対象グループ | 中 | グループ数が増え、同期・運用が非効率になる |
| 所有者不明のグループ | 中 | 退職や異動時に変更責任者が不明になる |
| 入れ子が深いグループ | 中 | 実効メンバーを把握しにくく、変更影響が読みづらい |
移行というより、既存の割り当て設計を棚卸しし、危険な設計から順に直すという進め方が現実的です。
管理者が確認すべきチェックリスト
まずは、Intune管理センターとMicrosoft Entra管理センターで、実際に使われているグループを一覧化します。すべてを一度に直すのではなく、ポリシー配布やセキュリティ設定に関係するものから優先してください。
| チェック項目 | 確認方法 | 問題がある場合の対応 |
|---|---|---|
| Intune割り当てに使うグループがSecurityか | グループの種類を確認 | Securityグループへ置き換えを検討 |
| ユーザーとデバイスが混在していないか | Membersでオブジェクト種類を確認 | ユーザー用・デバイス用に分離 |
| Dynamic Userグループにライセンス要件を満たしているか | メンバー数とEntra ID P1ライセンスを確認 | ライセンス不足や対象条件を見直す |
| 単純なデバイス条件に動的グループを使っていないか | ルールにOS、モデル、所有形態だけが使われていないか確認 | All devices + 割り当てフィルターへ移行を検討 |
| アプリごとに重複グループを作っていないか | AppName_Required などの命名を検索 | 同一対象の共通グループへ統合 |
| 除外設定でユーザーグループとデバイスグループを混在させていないか | AssignmentsのInclude / Excludeを確認 | フィルターでInclude / Excludeする設計へ変更 |
| 所有者が複数いるか | Ownersを確認 | 管理責任者とバックアップ担当を追加 |
| グループ説明があるか | Descriptionを確認 | 用途、対象、関連ポリシー、変更ルールを記載 |
| 入れ子グループが複雑すぎないか | Members内のグループメンバーを確認 | 大規模な入れ子変更は段階的に実施 |
| 本番前にパイロットがあるか | パイロット用Assignedグループを確認 | 小規模検証後にAll devicesや本番グループへ展開 |
Microsoftは、ユーザーグループに割り当ててデバイスグループを除外する、またはその逆のように、IncludeとExcludeでユーザーグループとデバイスグループを混在させる設計を推奨していません。代わりに、ユーザーグループへ割り当てたうえで、適切なデバイスを割り当てフィルターで含める、または除外する方法が推奨されています。(Microsoft Learn)
よくある失敗と回避策
Microsoft 365グループをIntune用に使ってしまう
Microsoft 365グループは、TeamsやSharePointなどの共同作業には便利ですが、Intuneのポリシー配布対象としては注意が必要です。既定ではセキュリティ有効ではなく、デバイスをメンバーにできません。Intuneで使う前提なら、最初からSecurityグループとして設計する方が安全です。(Microsoft Learn)
動的グループを増やしすぎる
「Windows端末」「会社所有端末」「Surface端末」「日本拠点端末」のように、条件ごとに動的デバイスグループを作り続けると、どのポリシーがどの端末に届くのか追いにくくなります。Intuneだけで使う条件なら、All devicesを土台にして割り当てフィルターで絞る方がシンプルです。
グループ名だけで用途を判断している
Win11-Test、Sales-PC、Mobile-Users のような名前だけでは、誰が管理し、どのポリシーに使い、いつ削除してよいのか分かりません。グループ名に加えて、Descriptionに「用途」「対象」「関連ポリシー」「変更責任者」「最終確認日」を入れておくと、監査や引き継ぎが楽になります。
RBAC用グループを動的条件で作る
管理者ロールの付与に動的グループを使うと、ユーザー属性の変更で意図せず権限が付与・解除される可能性があります。Endpoint Security ManagerなどのIntune管理ロールを割り当てる場合は、明示的にメンバーを管理できるAssignedグループを使う方が安全です。公式ドキュメントでも、特権ロールの割り当て例として、手動メンバーのグループで対象を限定する考え方が示されています。(Microsoft Learn)
グループに追加してすぐ展開結果を判断する
グループメンバーシップの反映は即時とは限りません。Microsoftの推奨では、Microsoft EntraからIntuneへの更新は通常5分以内ですが即時ではなく、端末登録の割り当てにも影響する可能性があります。検証時は、グループ追加直後に結果が出ないからといって、すぐにポリシーや条件を変更しないようにしてください。(Microsoft Learn)
グローバル環境での実務的な設計例
グローバル企業では、国、地域、部門、端末所有形態、OS、管理責任者が複雑に絡みます。おすすめは、組織構造をそのままグループに写すのではなく、Intuneで実際に割り当てる単位に合わせてグループを作ることです。
| シナリオ | 推奨設計 | 理由 |
|---|---|---|
| 全社共通の最低限コンプライアンス | All devicesに割り当て | 全端末に適用しやすく、専用動的グループが不要 |
| 日本法人の営業ユーザーにアプリ配布 | INTUNE-JP-SALES-USERS のAssignedまたはDynamic User | ユーザー単位のアプリ利用に向く |
| Windows 11会社所有端末だけに設定配布 | All devices + Windows 11 / corporate owned フィルター | OS・所有形態条件はフィルターで管理しやすい |
| Autopilotプロファイルの割り当て | Dynamic Deviceグループ | AutopilotのようなIntune以外の対象判定では動的グループが必要 |
| セキュリティ管理者のロール付与 | INTUNE-RBAC-ENDPOINT-SECURITY-ADMINS のAssignedグループ | 特権付与は手動承認しやすい |
| 拠点別ヘルプデスクの管理範囲 | RBACとスコープ設計を組み合わせる | グループ変更が管理範囲に影響するため責任分界が必要 |
ポイントは、部門や国で分けるグループと、OSや所有形態で絞るフィルターを混ぜないことです。組織条件はグループ、端末条件はフィルター、全社共通はAll users / All devicesという役割分担にすると、後から読み解きやすくなります。
既存環境を見直す進め方
既存環境では、いきなりグループを削除したり置き換えたりしないでください。まず、どのグループがどのIntune割り当てで使われているかを確認し、影響の大きいものから段階的に改善します。
| フェーズ | 作業 | 成果物 |
|---|---|---|
| 現状把握 | IntuneのAssignmentsとEntraグループを棚卸し | グループ用途一覧 |
| リスク分類 | 混在グループ、Microsoft 365グループ、重複グループを抽出 | 改善優先度リスト |
| 設計方針決定 | Assigned、Dynamic、All devices、フィルターの使い分けを決める | グループ設計ルール |
| パイロット | 小規模な端末・ユーザーで新設計を検証 | 展開結果と例外一覧 |
| 段階移行 | 既存割り当てを新グループまたはフィルターへ変更 | 変更履歴 |
| 定期監査 | 四半期ごとに所有者、用途、不要グループを確認 | グループ台帳 |
この手順なら、移行期限がない更新でも、運用改善として着実に進められます。特に、セキュリティベースライン、コンプライアンスポリシー、必須アプリ、管理者ロールの割り当ては影響が大きいため、最初に確認してください。
まとめ：Microsoft Entraグループは「作成」より「割り当て設計」が重要
Microsoft Entra の「Add groups to organize users and devices for Microsoft Intune」は、Intuneで使うグループの基本を再確認するための重要な公式情報です。今回の更新で強制移行や破壊的変更が確認されているわけではありませんが、既存のIntune運用でグループが増えすぎている組織ほど、見直し効果は大きくなります。
管理者が次に取るべき行動は明確です。まず、Intuneで使われているグループを棚卸しし、Securityグループになっているか、ユーザーとデバイスが混在していないか、単純なデバイス条件を動的グループで処理していないかを確認してください。そのうえで、全社共通はAll users / All devices、組織単位はMicrosoft Entraグループ、端末条件は割り当てフィルターという役割分担に整理すると、グローバル環境でも運用しやすいIntune設計になります。
コメント