Microsoft Intuneでデバイス構成プロファイルを作成した後、実際にユーザーや端末へ反映させるには「割り当て」が必要です。2026年5月時点の公式情報で押さえるべき要点は、単にグループへ配布するだけでなく、ユーザーグループ・デバイスグループ・除外グループ・割り当てフィルターを正しく使い分けることです。特に、動的デバイスグループを除外条件に使う構成や、ユーザーグループとデバイスグループを混在させた除外は、意図しないポリシー適用につながる可能性があります。(Microsoft Learn)
この記事では、Microsoft Learnの「Assign device profiles in Microsoft Intune」に基づき、Microsoft Intuneでデバイスプロファイルや各種ポリシーを割り当てる際の変更点、影響範囲、管理者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。
Microsoft Intuneの「Assign device profiles」は何を説明しているのか
Microsoft Intuneの「Assign device profiles in Microsoft Intune」は、Intune管理センターで作成したデバイス構成プロファイルやポリシーを、ユーザーまたはデバイスのグループへ割り当てる方法を説明する公式ドキュメントです。
対象はデバイス構成プロファイルだけではありません。公式情報では、Intuneで作成・割り当てできるポリシーとして、アプリ保護ポリシー、アプリ構成ポリシー、コンプライアンスポリシー、条件付きアクセス関連のポリシー、デバイス構成プロファイル、登録ポリシーが挙げられています。対象プラットフォームはAndroid、iOS/iPadOS、macOS、Linux、Windowsです。(Microsoft Learn)
重要なのは、この記事が「割り当て手順」だけでなく、どのグループに割り当てるべきか、どのように除外すべきか、割り当てフィルターをどこで使うべきかまで扱っている点です。Intune運用では、設定内容そのものよりも、対象範囲の設計ミスが障害の原因になりやすいためです。
2026年5月時点の主な確認ポイント
2026年5月時点の公式情報で特に確認したいのは、以下の4点です。
| 確認ポイント | 管理者への影響 |
|---|---|
| 割り当て先はユーザーグループかデバイスグループか | 設定が「人について回る」のか「端末に固定される」のかが変わる |
| 除外グループの組み合わせ | サポートされない組み合わせでは、想定どおり除外されない可能性がある |
| 動的デバイスグループの扱い | グループメンバーシップ反映の遅延により、初回登録時に不要なポリシーが適用される可能性がある |
| 割り当てフィルターの活用 | OS、メーカー、モデル、所有形態、デバイスカテゴリなどで対象を絞り込みやすい |
Microsoft Learnの該当ページでは、ポリシーを保存した時点で割り当てが有効になり、対象デバイスがIntuneサービスへチェックインしたタイミングで設定を受け取ると説明されています。つまり、「Review + Save」まで進めても、最後の「Save」を実行するまでは実際の割り当ては完了しません。(Microsoft Learn)
デバイスプロファイル割り当ての基本手順
Microsoft Intuneでデバイス構成プロファイルを割り当てる基本手順は、次の流れです。
| 手順 | 操作内容 | 確認すべきこと |
|---|---|---|
| 1 | Microsoft Intune admin centerにサインイン | ポリシーを割り当てられるRBAC権限があるか |
| 2 | Devices > Manage devices > Configurationを開く | 対象プロファイルが正しいか |
| 3 | 対象プロファイルのProperties > Assignments > Editを選択 | 既存の割り当て・除外を確認 |
| 4 | Included groupsまたはExcluded groupsにMicrosoft Entraグループを追加 | ユーザーグループとデバイスグループを混在させていないか |
| 5 | Review + Saveを選択 | この時点ではまだ割り当ては確定しない |
| 6 | Saveを選択 | 保存後、対象デバイスのチェックイン時に反映される |
「All users」と「All devices」の両方を選ぶと、追加のMicrosoft Entraグループを指定するオプションが無効になる点にも注意が必要です。全社配布のような広範囲な割り当てでは、意図しない端末やユーザーに影響しないよう、まずパイロットグループで検証するのが安全です。(Microsoft Learn)
ユーザーグループとデバイスグループの使い分け
Intuneの割り当て設計で最も重要なのが、ユーザーグループとデバイスグループの使い分けです。
ユーザーグループに割り当てるべきケース
ユーザーグループへの割り当ては、設定を「ユーザーに付けたい」場合に適しています。たとえば、あるユーザーが会社貸与のWindows PC、Surface、iPadを使っている場合、ユーザーグループに割り当てたポリシーは、そのユーザーが利用する複数デバイスに適用される可能性があります。
代表的な例は次のとおりです。
| シーン | ユーザーグループが向いている理由 |
|---|---|
| OneDriveやOfficeの設定を利用者単位で統制したい | ユーザーがどの端末を使っても同じ業務設定を適用しやすい |
| ヘルプデスクのショートカットを全社員に配布したい | 端末ではなく利用者に紐づく業務導線だから |
| メール、証明書、アプリ設定をユーザー単位で管理したい | ユーザーIDと利用権限の関係が強いから |
公式情報でも、メールやユーザー証明書のように「ユーザーに属する機能」はユーザーグループへ割り当てるという考え方が示されています。(Microsoft Learn)
デバイスグループに割り当てるべきケース
デバイスグループへの割り当ては、設定を「端末に固定したい」場合に適しています。誰がサインインしても同じ設定を適用したい端末、共有端末、キオスク端末、現場利用端末などが典型例です。
| シーン | デバイスグループが向いている理由 |
|---|---|
| 受付用PCや共有タブレットを固定設定にしたい | 利用者が変わっても端末の役割は変わらない |
| DFCIでBIOSや起動オプションを制御したい | ハードウェア寄りの設定で、ユーザーではなく端末に紐づく |
| 特定のWindows端末だけEdgeのダウンロードを禁止したい | 端末の用途に基づく制御だから |
| 工場、店舗、医療現場の共有端末を管理したい | シフト勤務などで利用者が固定されない |
実務では、「誰が使うか」ではなく「端末の用途が何か」で判断するとミスが減ります。端末そのもののセキュリティ状態や業務用途を固定したい場合は、デバイスグループを検討しましょう。
Azure Virtual Desktop multi-sessionではスコープに注意する
Azure Virtual DesktopのWindows multi-sessionをIntuneで管理する場合は、通常の物理端末とは少し考え方が異なります。公式情報では、仮想マシンに対して、デバイスCSPはデバイスグループを、ユーザーCSPはユーザーグループを対象にする必要があると説明されています。(Microsoft Learn)
この点を無視すると、「設定を作成したのに反映されない」「一部ユーザーにだけ効かない」といった切り分けが難しい問題につながります。AVD multi-session環境では、設定カタログやCSPのスコープがユーザーなのかデバイスなのかを確認してから割り当て先を決めるべきです。
除外グループで失敗しやすいポイント
Intuneでは、ポリシー割り当て時にIncluded groupsとExcluded groupsを指定できます。ただし、除外グループは万能ではありません。
特に注意すべきなのは、ユーザーグループとデバイスグループをまたいだ除外です。たとえば、ユーザーグループにポリシーを割り当て、特定のデバイスグループを除外するような構成は、サポートされない、または推奨されないケースがあります。
| 割り当ての考え方 | 推奨度 | 理由 |
|---|---|---|
| ユーザーグループに割り当て、ユーザーグループを除外 | 高 | ユーザー単位で評価しやすい |
| デバイスグループに割り当て、デバイスグループを除外 | 高 | デバイス単位で評価しやすい |
| ユーザーグループに割り当て、デバイスグループを除外 | 低 | Intuneが意図どおりユーザーとデバイスの関係を評価できない可能性がある |
| デバイスグループに割り当て、ユーザーグループを除外 | 低 | デバイスに対するユーザー除外が想定どおり機能しない可能性がある |
| 動的デバイスグループを除外に使う | 要注意 | グループメンバーシップ計算の遅延で、除外前にポリシーが配布される可能性がある |
公式情報では、動的デバイスグループの除外は、遅延に敏感なシナリオでは推奨されないとされています。新規登録端末がIntuneに登録された直後、Microsoft Entra IDの動的グループに入る前にポリシーが配布されてしまう可能性があるためです。(Microsoft Learn)
失敗例：新入社員用端末だけ除外したつもりが適用される
よくある失敗例は、全デバイス向けの構成プロファイルから、新入社員研修用端末だけを動的デバイスグループで除外する構成です。
端末登録直後は、まだ動的グループのメンバーシップが反映されていない場合があります。その間に端末がIntuneへチェックインすると、本来除外したいポリシーが先に適用される可能性があります。
このような場合は、動的デバイスグループで除外するのではなく、割り当てフィルターで端末プロパティを評価する設計を検討します。
割り当てフィルターを使うべき場面
Microsoft Intuneの割り当てフィルターは、グループだけでは表現しづらい対象条件を、デバイスやアプリのプロパティで絞り込む機能です。公式情報では、割り当てフィルターはグループメンバーシップ処理に依存しないため、グループサイズ、ルールの複雑さ、メンバーシップ評価のタイミングに影響されにくいと説明されています。(Microsoft Learn)
割り当てフィルターが特に有効なのは、次のような条件です。
| 条件 | 例 |
|---|---|
| OSで絞りたい | Windows端末だけ、iOS/iPadOS端末だけ |
| OSバージョンで絞りたい | 特定バージョン以上のWindows端末だけ |
| メーカーやモデルで絞りたい | Surfaceシリーズだけ、特定メーカー端末だけ |
| 所有形態で絞りたい | 会社所有端末だけ、個人所有端末を除外 |
| デバイスカテゴリで絞りたい | 営業部門端末、共有端末、研修用端末など |
たとえば、会社所有のiOS/iPadOS端末だけにポリシーを適用したい場合、ユーザーグループにポリシーを割り当てたうえで、割り当てフィルターで「会社所有端末」を条件にする設計が考えられます。これにより、同じユーザーが個人所有のiPhoneと会社貸与のiPadを持っている場合でも、対象を絞り込みやすくなります。
動的デバイスグループから割り当てフィルターへ移行を検討すべきケース
すべての動的デバイスグループを廃止すべき、という意味ではありません。Autopilotプロファイルの対象指定、条件付きアクセス、ライセンス付与、Intune以外のワークロードで使っているグループは、引き続き必要になる場合があります。
一方で、次の条件に当てはまる場合は、割り当てフィルターへの移行を検討する価値があります。
| 移行を検討する条件 | 理由 |
|---|---|
| グループがIntuneのポリシー・アプリ割り当てにしか使われていない | 他サービスへの影響が少ない |
| ルールがOS、メーカー、モデル、所有形態、カテゴリなど単純な端末属性で構成されている | 割り当てフィルターで表現しやすい |
| 新規登録直後の即時反映が重要 | 動的グループの計算遅延を避けやすい |
| 除外グループの複雑化で運用が分かりにくい | フィルター条件として整理しやすい |
Microsoftのパフォーマンス推奨情報でも、単純なデバイスプロパティを使う動的デバイスグループは、Intuneだけで利用するなら割り当てフィルターを使うことが推奨されています。(Microsoft Learn)
RBACとスコープタグも同時に確認する
デバイスプロファイルの割り当てを変更する前に、RBACとスコープタグの確認も必要です。Intuneでは、管理者がどのリソースを見られるか、どの操作を実行できるかをRBACで制御できます。Microsoftは、日常的なIntune管理でGlobal AdministratorやIntune Administratorを使うのではなく、必要最小限のIntune組み込みロールやカスタムロールを使うことを推奨しています。(Microsoft Learn)
特に分散IT体制では、スコープタグの設計が重要です。スコープタグは、特定のITチームが管理対象のポリシー、アプリ、デバイスだけを扱えるようにするために使います。公式情報では、構成プロファイルなどのIntuneオブジェクトにスコープタグを割り当てられると説明されています。(Microsoft Learn)
確認すべきRBAC・スコープタグ項目
| 確認項目 | 実務上のチェックポイント |
|---|---|
| 管理者ロール | Policy and Profile Managerなど、必要な権限だけを付与しているか |
| 管理対象範囲 | 対象ユーザー・対象デバイスがScope Groupsに含まれているか |
| 除外グループ | RBACのスコープ内に除外グループが含まれているか |
| スコープタグ | 拠点別、部門別、国別の運用に合うタグ設計になっているか |
| 特権ロール | Global AdministratorやIntune Administratorを常用していないか |
除外グループを使う場合、そのグループがRBACロール割り当てのスコープに含まれているかも確認が必要です。権限設計と割り当て設計がずれていると、管理者が意図した対象を編集・確認できないことがあります。
Windows CSPのポリシー削除時の挙動に注意
Windowsデバイス向けの構成プロファイルでは、CSPの挙動も重要です。公式情報では、Windowsのポリシー設定はConfiguration Service Provider、つまりCSPに基づき、レジストリキーやファイルにマップされると説明されています。(Microsoft Learn)
注意したいのは、ポリシーを削除したり割り当てを外したりしても、必ず元の既定値に戻るとは限らない点です。CSPによっては、既存の値が残る場合があります。
たとえば、Microsoft Edgeの特定設定をIntuneで制御していた場合、ポリシーを外しただけではユーザーがすぐ自由に変更できる状態に戻らないことがあります。この場合、単に割り当てを削除するのではなく、該当設定を「Not configured」にした新しいポリシーを作成して割り当てる対応が必要になる場合があります。
展開前に確認すべきチェックリスト
本番展開前には、次のチェックリストを使って割り当て設計を確認してください。
| 項目 | 確認内容 |
|---|---|
| 対象の考え方 | ユーザーに紐づく設定か、端末に固定する設定か |
| 割り当て先 | ユーザーグループ、デバイスグループ、All users、All devicesのどれか |
| 除外条件 | ユーザー/デバイスのグループ種別を混在させていないか |
| 動的グループ | 登録直後の遅延が問題にならないか |
| 割り当てフィルター | OS、モデル、所有形態、カテゴリで絞り込めないか |
| RBAC | 作業者に必要最小限の権限があるか |
| スコープタグ | 管理者が対象プロファイルを表示・操作できるか |
| 競合 | 同じ設定を複数プロファイルで制御していないか |
| 検証 | IT部門や一部端末でパイロット展開したか |
| ロールバック | 適用解除時のCSP挙動を確認したか |
特に大規模テナントでは、グループの入れ子や大きなグループ変更がIntuneのターゲティング処理に影響する可能性があります。グループを増やし続けるのではなく、仮想グループ、既存グループの再利用、割り当てフィルターを組み合わせて、シンプルな設計にすることが重要です。(Microsoft Learn)
展開後の確認方法
ポリシーを保存した後は、対象デバイスがIntuneへチェックインしてから適用状況を確認します。構成プロファイルの状態確認では、Devices > Manage devices > Configuration > Monitorタブから、Configuration policy assignment failures reportを確認できます。このレポートは、割り当て済み構成ポリシーのエラーや競合のトラブルシューティングに役立ちます。(Microsoft Learn)
また、割り当てフィルターを使っている場合は、Devices > All Devices > 対象デバイス > Filter evaluationで、評価されたフィルター、評価日時、Match/No match、Include/Excludeモード、評価されたプロパティなどを確認できます。フィルター評価結果は、評価時点からIntune管理センターに表示されるまで最大30分かかる場合があります。(Microsoft Learn)
トラブル時に見るべき場所
| 症状 | 確認場所 | 見るべきポイント |
|---|---|---|
| ポリシーが適用されない | 対象デバイスのDevice configuration | 対象プロファイルが一覧にあるか |
| 一部端末だけ適用されない | Filter evaluation | フィルターがNo matchになっていないか |
| 除外した端末に適用された | AssignmentsとExcluded groups | 動的グループの反映遅延がないか |
| 設定が競合している | Configuration policy assignment failures | 同じ設定を複数プロファイルで制御していないか |
| 条件付きアクセスが原因か不明 | Microsoft Entraサインインログ | Intuneのフィルター評価だけで判断しない |
なお、フィルター評価レポートはMicrosoft Entra Conditional Accessの評価結果を表示しません。条件付きアクセスによるブロックやアクセス制御を調べる場合は、Microsoft Entra側のサインインログも確認する必要があります。(Microsoft Learn)
管理者・開発者が取るべき次のアクション
Microsoft Intuneのデバイスプロファイル割り当てで、今すぐ確認すべきことは明確です。
まず、既存の構成プロファイルを棚卸しし、割り当て先がユーザーグループなのかデバイスグループなのかを確認します。次に、除外グループでユーザーとデバイスを混在させていないか、動的デバイスグループの反映遅延が問題になりそうな設計がないかを見直します。
そのうえで、OS、メーカー、モデル、所有形態、デバイスカテゴリなどの条件で対象を絞っている動的デバイスグループがあれば、割り当てフィルターへの移行を検討しましょう。最後に、RBAC、スコープタグ、監視レポート、ロールバック手順を確認し、パイロット展開から段階的に本番へ広げるのが安全です。
Intuneの割り当て設計は、作成したポリシーの品質と同じくらい重要です。設定を「誰に効かせるのか」「どの端末に効かせるのか」「いつ除外が評価されるのか」を明確にすると、意図しない配布や未適用を大幅に減らせます。
コメント