Microsoft Intuneで端末を部署・用途・所有区分ごとに管理したい場合は、デバイスカテゴリを使うと管理しやすくなります。結論から言うと、Intuneの「Categorize devices into groups」は、カテゴリを作成するだけで完結する機能ではありません。カテゴリ名をもとに、Microsoft Entra IDの動的デバイスグループ、またはIntuneの割り当てフィルターと組み合わせて、ポリシーやアプリの割り当て対象を整理する仕組みです。
2026年5月21日時点で確認した公式情報では、Intune管理センターでデバイスカテゴリを作成し、必要に応じてMicrosoft Entraセキュリティグループや割り当てフィルターを使う流れが示されています。特に重要なのは、Intune内のポリシー・アプリ割り当てだけに使うなら割り当てフィルター、条件付きアクセスやライセンスなど他サービスでも使うなら動的グループという使い分けです。なお、Microsoft Learnの該当ページでは「Last updated on 2026-05-20」と表示されています。日本時間で2026年5月21日に確認・社内展開する場合は、管理資料には確認日も併記しておくとよいでしょう。 (Microsoft Learn)
Microsoft Intuneのデバイスカテゴリとは
Microsoft Intuneのデバイスカテゴリは、Intuneで管理しているデバイスを「営業部」「経理部」「共有端末」「店舗端末」「BYOD」など、組織に合った分類で整理するための機能です。公式ドキュメントでは、カテゴリを作成し、そのカテゴリに該当するデバイスを対応するIntune上のデバイスグループへ自動的に追加できると説明されています。カテゴリを有効に使うには、Intune管理センターでカテゴリを作成し、Microsoft Entra ID側で動的セキュリティグループを設定するのが基本です。 (Microsoft Learn)
たとえば、以下のような分類に向いています。
| 分類例 | 活用シーン |
|---|---|
HR | 人事部向けのアプリ、VPN、セキュリティ設定を配布する |
Sales | 営業部のモバイル端末に特定の業務アプリを割り当てる |
Store-Kiosk | 店舗や受付の共有端末に制限付き構成を適用する |
BYOD | 個人所有端末に対して、会社所有端末より軽い制御を行う |
Engineering | 開発部門向けに開発ツールや追加ポリシーを配布する |
ポイントは、カテゴリが単なるメモ欄ではないことです。カテゴリ名を動的グループや割り当てフィルターの条件に使うことで、ポリシー適用やアプリ配布の対象を実務に近い単位で制御できます。
何が変わるのか：カテゴリ管理は「動的グループ前提」から「フィルター併用」へ整理される
今回の公式情報で管理者が特に確認すべき点は、デバイスカテゴリの作成方法そのものよりも、カテゴリを使ったターゲティング方法の選び方です。
従来の基本的な流れは、Intuneでデバイスカテゴリを作成し、Microsoft Entra IDで device.deviceCategory -eq "HR" のようなルールを持つ動的デバイスグループを作成する方法でした。公式ドキュメントでも、HRカテゴリのデバイスを自動グループ化する例として、この構文が示されています。 (Microsoft Learn)
一方で、Intuneのポリシーやアプリ割り当てだけにカテゴリを使う場合は、動的グループではなく割り当てフィルターを使う選択肢が明確に示されています。割り当てフィルターは、デバイスのチェックイン時に評価され、グループメンバーシップ処理に依存しません。条件付きアクセス、ライセンス、Autopilotプロファイル割り当てなど、Intune以外の用途にも同じ分類を使う場合は、引き続き動的グループが必要です。 (Microsoft Learn)
つまり、今回の確認ポイントは次のように整理できます。
| 確認項目 | 管理者が取るべき判断 |
|---|---|
| Intuneのポリシー・アプリ配布だけに使う | 割り当てフィルターを優先して検討する |
| 条件付きアクセスやライセンスにも使う | Microsoft Entra IDの動的グループを使う |
| 既存の動的グループが多数ある | すぐ削除せず、利用先を棚卸ししてから移行する |
| カテゴリ名を変更する予定がある | 動的グループのルール、フィルター条件、運用手順書を同時に更新する |
| 承認制の管理運用をしている | Multi Admin Approvalの対象にならないか確認する |
対象者と影響範囲
デバイスカテゴリは、Intune管理者だけでなく、Microsoft Entra ID、セキュリティ、ヘルプデスク、運用自動化担当にも影響します。カテゴリ名はポリシー配布の条件に使われるため、名前の変更や削除がそのまま配布対象の変化につながる可能性があります。
| 対象者 | 主な影響 |
|---|---|
| Intune管理者 | デバイスカテゴリの作成、編集、削除、カテゴリ別ポリシー割り当ての設計が必要 |
| Microsoft Entra ID管理者 | 動的デバイスグループのルール作成・更新が必要 |
| セキュリティ管理者 | 条件付きアクセスにカテゴリ由来のグループを使っている場合、影響確認が必要 |
| ヘルプデスク | ユーザーがポータルサイトでカテゴリを選ぶ手順を案内する場面が増える |
| 開発者・自動化担当 | Microsoft Graph APIでカテゴリを取得・作成する処理の権限とエラー処理を確認する必要 |
| エンドユーザー | Company PortalアプリまたはWebサイトでカテゴリ選択を求められる可能性がある |
対応プラットフォームは、Android、iOS/iPadOS、macOS、Windowsです。Windowsデバイスの利用者はCompany Portal Webサイトでカテゴリを選択し、その他のプラットフォームではCompany Portalアプリへのサインイン時にカテゴリ選択のプロンプトが表示されます。 (Microsoft Learn)
デバイスカテゴリを使う前に決めるべきこと
設定作業に入る前に、カテゴリ設計を決めておくことが重要です。思いつきでカテゴリを作ると、後からカテゴリ名の変更、重複、配布ミスが起きやすくなります。
カテゴリ名は「ポリシー適用の単位」で決める
カテゴリは、組織図をそのまま写すよりも、Intuneで何を分けて配布したいかを基準に決めるほうが実務向きです。
たとえば、営業部とマーケティング部に同じセキュリティ設定と同じアプリを配布するなら、別々のカテゴリにする必要はありません。逆に、同じ営業部でも「会社所有PC」と「個人所有スマートフォン」で管理レベルが違うなら、部署より所有区分を優先したカテゴリ設計が適しています。
避けたいカテゴリ名の例は、次のようなものです。
| 避けたい例 | 理由 |
|---|---|
その他 | 何が含まれるか分からず、ポリシー適用の根拠が曖昧になる |
一時対応 | 後から削除されず、恒久運用に残りやすい |
営業部2026 | 年度変更のたびにルール修正が必要になる |
HR と HumanResources の併用 | 同じ意味のカテゴリが分裂し、対象漏れが起きる |
カテゴリ名は、短く、意味が明確で、長期間使えるものにしましょう。おすすめは、Dept-HR、Dept-Sales、Use-Kiosk、Own-BYOD、Own-Corporate のように、分類軸が分かる接頭辞を付ける方法です。
ユーザーにカテゴリ選択を見せるか決める
公式ドキュメントでは、Company PortalアプリまたはWebサイトにアクセスしたエンドユーザーへ、デバイスカテゴリ選択のプロンプトを表示する必要があるか事前に判断するよう案内されています。表示したくない場合は、カテゴリを作成する前にカスタマイズプロファイルでブロックする必要があります。 (Microsoft Learn)
ユーザーに選ばせる方式は、BYODや部署別の自己申告には便利です。一方で、誤選択が起きると、本来とは違うポリシーやアプリが配布される可能性があります。特にセキュリティ制御に直結するカテゴリは、ユーザー任せにしない設計が望ましいです。
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| ユーザーに選ばせる | BYOD、学校、部門自己申告が必要な環境 | 誤選択、未選択、問い合わせ増加に注意 |
| 管理者が設定する | 会社所有端末、キオスク、特権ユーザー端末 | 登録後の運用フローを整備する必要 |
| 自動化で設定・確認する | 大量展開、定期棚卸し、標準化された端末配布 | Graph API権限、監査ログ、例外処理が必要 |
管理センターでの基本設定手順
デバイスカテゴリの設定は、大きく分けて「カテゴリ作成」「分類条件の作成」「割り当てへの利用」「確認」の4段階です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Intune管理センターでデバイスカテゴリを作成 | カテゴリ名と説明を標準ルールに合わせる |
| 2 | 動的グループまたは割り当てフィルターを作成 | Intune内だけか、他サービスでも使うかで選ぶ |
| 3 | アプリ、構成プロファイル、準拠ポリシーなどへ割り当て | テスト対象から段階的に展開する |
| 4 | Devices > All devicesでカテゴリ列を確認 | 未割り当てや誤分類の端末を確認する |
公式手順では、Intune管理センターにサインインし、Devices から Manage devices を展開して Device categories を選択し、Create で新しいカテゴリを追加します。カテゴリ名と説明を入力し、必要に応じてスコープタグを割り当てます。作成したカテゴリ名は、次のステップでMicrosoft Entraセキュリティグループを作るときに使用します。 (Microsoft Learn)
動的グループと割り当てフィルターの使い分け
デバイスカテゴリを使うときに最も迷いやすいのが、Microsoft Entra IDの動的グループを使うべきか、Intuneの割り当てフィルターを使うべきかという点です。
結論はシンプルです。Intuneの中だけで使うなら割り当てフィルター、Intune以外でも使うなら動的グループです。
| 比較項目 | 動的グループ | 割り当てフィルター |
|---|---|---|
| 主な用途 | 条件付きアクセス、ライセンス、他サービスとの連携、Intune割り当て | Intune内のアプリ・ポリシー割り当て |
| 評価の仕組み | Microsoft Entra IDのグループメンバーシップとして評価 | デバイスのチェックイン時に評価 |
| カテゴリ条件の例 | device.deviceCategory -eq "HR" | (device.deviceCategory -eq "Engineering devices") |
| 向いている環境 | セキュリティやライセンス制御にも使う環境 | Intuneのターゲティングを細かくしたい環境 |
| 注意点 | グループ評価の遅延やルール管理が発生する | 条件付きアクセスやライセンスの対象には使えない |
割り当てフィルターでは、deviceCategory プロパティを使ってカテゴリに基づく条件を作れます。公式のプロパティリファレンスでは、完全一致の -eq、部分一致の -contains、複数値指定の -in などが示されています。対象プラットフォームはAndroid、iOS/iPadOS、macOS、Windowsを含みます。 (Microsoft Learn)
動的グループのルール例
HRカテゴリのデバイスをMicrosoft Entra IDの動的デバイスグループに追加する場合は、次のようなルールを使います。
device.deviceCategory -eq "HR"このグループを条件付きアクセス、ライセンス、Intuneの割り当てなど複数用途に使う場合は、動的グループを維持する価値があります。ただし、カテゴリ名を変更した場合は、このルールも必ず更新してください。公式ドキュメントでも、カテゴリを編集した場合は、そのカテゴリを参照するMicrosoft Entraセキュリティグループを更新するよう注意されています。 (Microsoft Learn)
割り当てフィルターのルール例
Intuneのアプリやポリシー割り当てだけに使うなら、次のような割り当てフィルターを作成できます。
(device.deviceCategory -eq "Engineering devices")部分一致でまとめたい場合は、次のような条件も使えます。
(device.deviceCategory -contains "Engineering")ただし、部分一致は便利な反面、意図しないカテゴリまで含める可能性があります。たとえば Engineering に一致させると、Engineering-Test や Old-Engineering のようなカテゴリも対象になる可能性があります。重要なポリシーでは、できるだけ完全一致を使うほうが安全です。
展開前に確認すべき設定
本番展開前には、以下のチェックリストを使って確認するとミスを減らせます。
| 確認項目 | 確認内容 |
|---|---|
| カテゴリ設計 | 部署、用途、所有区分など分類軸が混在していないか |
| カテゴリ名 | 大文字・小文字、略称、スペース、表記ゆれを標準化しているか |
| ユーザー表示 | Company Portalでカテゴリ選択を見せるか、ブロックするか決めているか |
| 動的グループ | device.deviceCategory を参照するルールが正しいか |
| 割り当てフィルター | deviceCategory 条件が対象プラットフォームで使えるか |
| 既存ポリシー | 既存のグループ割り当てと新しいフィルターが競合しないか |
| Multi Admin Approval | カテゴリの作成・編集・削除に承認が必要な運用になっていないか |
| スコープタグ | 地域別・部門別の管理者に見せる範囲が適切か |
| テスト端末 | 各カテゴリに最低1台の検証端末を用意しているか |
| ロールバック | 誤分類時に元に戻す手順を用意しているか |
特にMulti Admin Approvalを有効にしている環境では注意が必要です。公式ドキュメントでは、Tenant Configurationの保護対象としてデバイスカテゴリの作成・編集・削除が含まれており、保護されたリソースの変更は別の管理者の承認が完了するまで適用されません。 (Microsoft Learn)
緊急変更が多い組織では、承認者グループ、連絡経路、業務上の理由の書き方をあらかじめ決めておきましょう。Multi Admin Approvalでは、新しい要求や状態変更に対する通知が送信されないため、急ぎの変更では承認者へ別途連絡する運用が必要です。 (Microsoft Learn)
既存環境での移行・見直しポイント
すでにIntuneを運用している環境では、デバイスカテゴリを新規導入するよりも、既存の動的グループやポリシー割り当てとの関係整理が重要です。
既存の動的グループをすぐ削除しない
「割り当てフィルターが使えるなら、動的グループを削除してよい」と考えるのは危険です。動的グループは、Intune以外にも条件付きアクセス、ライセンス割り当て、他のMicrosoft 365サービスで使われている可能性があります。
まずは、カテゴリベースの動的グループがどこで使われているかを棚卸ししましょう。Intuneのアプリやポリシーだけに使われているなら、割り当てフィルターへの移行候補になります。条件付きアクセスやライセンスにも使っているなら、その動的グループは残す必要があります。
カテゴリ名の変更は影響が大きい
カテゴリ名は、動的グループのルールや割り当てフィルターの条件に使われます。そのため、HR を Human Resources に変更するだけでも、参照しているルールを更新しなければ対象外になる可能性があります。
カテゴリ名を変える場合は、次の順番で進めると安全です。
| 順番 | 作業 |
|---|---|
| 1 | カテゴリを参照している動的グループ、フィルター、ポリシーを一覧化する |
| 2 | 新カテゴリ名を決め、命名ルールに反映する |
| 3 | テスト端末で新カテゴリを割り当てる |
| 4 | 動的グループまたはフィルター条件を更新する |
| 5 | ポリシー適用結果を確認する |
| 6 | 旧カテゴリを削除する前に未分類端末が出ないか確認する |
公式ドキュメントでは、カテゴリを削除した場合、そのカテゴリが割り当てられていたデバイスは Unassigned と表示されると説明されています。削除前には、対象デバイスを別カテゴリへ移すか、未割り当てになっても問題ないかを確認してください。 (Microsoft Learn)
登録済みデバイスへの影響を確認する
デバイス登録後にカテゴリを構成する場合、ユーザーにカテゴリ選択が必要になることがあります。公式情報では、iOS/iPadOSまたはAndroidデバイスがカテゴリ設定前に登録済みだった場合、ユーザーはCompany Portal Webサイト上で通知を受け、次回Company Portalアプリ利用時にカテゴリを選択する必要があるとされています。 (Microsoft Learn)
展開前には、ヘルプデスク向けに次の案内を用意しておくと混乱を防げます。
Company PortalアプリまたはWebサイトでカテゴリ選択が表示された場合は、
自分の所属部門または端末用途に合うカテゴリを選択してください。
判断できない場合は、選択前にITサポートへ問い合わせてください。ただし、ユーザーの選択ミスがセキュリティ設定に直結する環境では、自己申告ではなく管理者側でカテゴリを設定する運用を検討しましょう。
開発者・自動化担当が確認すべきMicrosoft Graph APIのポイント
デバイスカテゴリは、Microsoft Graph APIでも扱えます。公式のGraph v1.0ドキュメントでは、GET /deviceManagement/deviceCategories によるカテゴリ一覧取得、POST /deviceManagement/deviceCategories によるカテゴリ作成が示されています。Graph APIでIntuneを操作するには、テナントに有効なIntuneライセンスが必要です。 (Microsoft Learn)
自動化スクリプトや社内ツールを作る場合は、次の点を確認してください。
| 確認項目 | 実装上の注意 |
|---|---|
| APIバージョン | 可能な限りMicrosoft Graph v1.0を使う |
| 権限 | 読み取りは DeviceManagementManagedDevices.Read.All、作成・更新は DeviceManagementManagedDevices.ReadWrite.All など、必要最小限にする |
| カテゴリ名 | 動的グループやフィルター条件で使うため、表記ゆれを検出する |
| ID管理 | API操作ではカテゴリID、運用ルールでは表示名が使われる場面があるため両方記録する |
| 変更監査 | 誰が、いつ、どのカテゴリを作成・変更したかを追跡できるようにする |
| 失敗時処理 | Multi Admin Approvalや権限不足で即時反映されないケースを考慮する |
Graphのbeta APIについては、Microsoftが「より頻繁に変更される可能性があり、可能な場合はv1.0の利用を推奨する」と説明しています。業務システムや本番運用の自動化では、beta前提の処理を避け、v1.0で利用できるAPIを優先しましょう。 (Microsoft Learn)
よくあるトラブルと対処法
デバイスカテゴリの運用で起きやすいトラブルは、カテゴリ作成そのものよりも、分類後の割り当てや反映確認に関するものです。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| デバイスが期待したグループに入らない | カテゴリ名と動的グループのルールが一致していない | device.deviceCategory -eq "カテゴリ名" の文字列を確認する |
| ポリシーが適用されない | フィルター条件に一致していない、またはデバイスがまだチェックインしていない | フィルター条件とデバイスのカテゴリ列を確認し、チェックイン後に再確認する |
| カテゴリ列が見えない | All devicesの列設定にCategoryが追加されていない | Devices > All devices でColumnsからCategoryを追加する |
| ユーザーからカテゴリ選択の問い合わせが増えた | Company Portalでカテゴリ選択を表示する設計になっている | 事前案内を出すか、必要に応じてカスタマイズプロファイルで制御する |
| カテゴリ変更が反映されない | Multi Admin Approvalの承認待ち、またはグループ評価待ち | 承認状態、動的グループ、フィルター評価を順に確認する |
| カテゴリ削除後に端末が未割り当てになった | 削除したカテゴリに端末が紐づいていた | 削除前に別カテゴリへ移動する運用に変更する |
割り当てフィルターを使っている場合は、関連付けられている割り当てを確認することも重要です。公式ドキュメントでは、Assignment filtersのAssociated Assignmentsタブで、そのフィルターを使用しているアプリやポリシー、割り当てモードを確認できると説明されています。 (Microsoft Learn)
実務でおすすめの展開手順
本番環境で安全に導入するなら、いきなり全社展開せず、段階的に進めるのが現実的です。
| フェーズ | 作業 | 成功基準 |
|---|---|---|
| 設計 | カテゴリ命名ルール、分類軸、利用先を決める | カテゴリ一覧と利用目的が文書化されている |
| 検証 | 1〜2カテゴリでテスト端末に適用する | カテゴリ列、グループ、フィルター評価が想定どおり |
| 小規模展開 | 1部門または1拠点に展開する | ユーザー問い合わせ、誤分類、適用漏れを把握できる |
| 本番展開 | 対象部門・端末へ段階的に広げる | 重要ポリシーの適用状況をレポートで確認できる |
| 運用定着 | 月次または四半期でカテゴリを棚卸しする | 不要カテゴリ、未割り当て端末、表記ゆれが減っている |
最初の検証では、セキュリティ影響の大きいポリシーではなく、リスクの低いアプリ配布や表示確認から始めると安全です。カテゴリの誤選択やルールミスが見つかっても、影響を限定できます。
管理者が今すぐ確認すべきこと
Microsoft Intuneのデバイスカテゴリは、端末を見やすく整理するだけでなく、アプリ配布、構成プロファイル、準拠ポリシー、条件付きアクセス設計にも関係する重要な分類軸です。
まず確認すべきことは、次の3点です。
1つ目は、既存のデバイスグループやポリシー割り当てで、すでにカテゴリ相当の分類をしていないかを棚卸しすることです。重複した分類軸を増やすと、運用が複雑になります。
2つ目は、カテゴリを動的グループで使うのか、割り当てフィルターで使うのかを決めることです。Intuneの中だけで使うなら割り当てフィルターを優先し、条件付きアクセスやライセンスにも使うなら動的グループを使いましょう。
3つ目は、カテゴリ名の変更や削除を軽く扱わないことです。カテゴリ名はルール条件に使われるため、変更時には動的グループ、割り当てフィルター、運用手順書をまとめて更新する必要があります。
小さく始めるなら、まずは「会社所有端末」と「個人所有端末」、または「通常端末」と「共有端末」のように、管理方針が明確に違う2〜3カテゴリから設計すると失敗しにくくなります。分類の目的を明確にし、テスト端末で適用結果を確認してから本番展開へ進めましょう。
コメント