Microsoft Intuneのデバイスコンプライアンスポリシーは、管理対象デバイスが会社のセキュリティ要件を満たしているかを判定し、必要に応じてMicrosoft Entra Conditional Accessでアクセス制御に使うための重要な仕組みです。今回確認すべき要点は、単に「ポリシーを作る」ことではありません。未割り当てデバイスの扱い、非準拠時の猶予と通知、レポートの読み方、Windows/Linuxのカスタムコンプライアンス、第三者MDMからの移行まで含めて見直す必要があります。
2026年5月時点のMicrosoft Learn公式情報では、IntuneがID・デバイス・アプリをMicrosoft Entra Conditional Accessにつなぎ、デバイスのコンプライアンス状態をアクセス判断に使う考え方が整理されています。なお、関連するMicrosoft Learnの更新日はページごとに異なり、Intune core conceptsとarchitectureは2026年5月21日更新、デバイスコンプライアンスポリシー概要は2026年4月15日更新、作成手順・非準拠アクション・監視・カスタム設定・第三者コンプライアンスパートナーの各ページは2026年5月20日更新として公開されています。(Microsoft Learn)
Microsoft Intuneのデバイスコンプライアンスポリシーとは
Microsoft Intuneのデバイスコンプライアンスポリシーとは、Windows、macOS、iOS/iPadOS、Android、Linuxなどの管理対象デバイスに対して、組織が求めるセキュリティ条件を満たしているかを評価するルールセットです。たとえば、最小OSバージョン、暗号化、パスワード、脱獄・root化の有無、Microsoft Defender for Endpointなどの脅威レベルを条件にできます。Intuneの公式概要では、コンプライアンスポリシーは「管理対象デバイスの構成を評価するルールと条件」と説明されています。(Microsoft Learn)
重要なのは、コンプライアンスポリシーは「設定を配布する機能」ではなく、デバイスが条件を満たしているかを判定する機能だという点です。BitLockerを有効化する、Wi-Fi設定を配る、ブラウザー設定を変更するといった構成変更は、通常はデバイス構成プロファイルやセキュリティベースラインなどで行います。コンプライアンスポリシーは、その結果としてデバイスが要件を満たしているかを確認し、準拠・非準拠の状態を返します。
この準拠状態は、Microsoft Entra Conditional Accessと組み合わせると実務上の意味が大きくなります。たとえば「準拠済みデバイスのみExchange OnlineやSharePoint Onlineへアクセスを許可する」という制御が可能になります。Intuneのcore conceptsでも、デバイスがIntuneへチェックインしてコンプライアンス状態を報告し、その状態がMicrosoft Entra IDへ渡され、Conditional Accessのアクセス判断に使われる流れが示されています。(Microsoft Learn)
変更点として押さえるべきポイント
今回の公式情報で管理者が特に見るべきなのは、大きなUI変更というよりも、コンプライアンス運用で誤解されやすい箇所が明確化されている点です。特に、テナント全体設定、非準拠時アクション、レポートの見え方、カスタムコンプライアンス、第三者MDM連携は、運用事故につながりやすい領域です。
| 確認ポイント | 影響する範囲 | 管理者が取るべき対応 |
|---|---|---|
| ポリシー未割り当てデバイスの扱い | 全デバイス、Conditional Access | 「Compliant」のままにするか、「Not compliant」に変更するかを設計する |
| Compliance status validity period | 長期間チェックインしない端末 | 既定値のままでよいか、運用実態に合わせて見直す |
| 非準拠時アクション | ユーザー通知、ロック、退役 | 即時ブロックではなく、猶予期間と通知を組み合わせる |
| レポートの反映タイミング | 監査、ヘルプデスク対応 | チェックイン前の状態を「設定ミス」と誤認しない |
| カスタムコンプライアンス | Windows/Linux、開発・自動化担当 | スクリプト、JSON、出力制限、検証方法を確認する |
| 第三者MDM連携 | Jamf、Workspace ONEなど利用環境 | MDM authorityと移行手順を確認する |
最初に確認すべきテナント全体設定
デバイスコンプライアンスポリシーを見直す際、個別ポリシーより先に確認したいのが、IntuneのCompliance policy settingsです。これは各デバイスに割り当てる個別ポリシーとは別に、テナント全体でコンプライアンスの動作を決める設定です。Microsoft Learnでは、管理場所として「Endpoint security > Device compliance > Compliance policy settings」が案内されています。(Microsoft Learn)
Mark devices with no compliance policy assigned as
最も重要なのが、Mark devices with no compliance policy assigned asです。これは、明示的なデバイスコンプライアンスポリシーが割り当てられていないデバイスを、Intuneが準拠と見なすか非準拠と見なすかを決める設定です。公式情報では、既定値は「Compliant」であり、Conditional Accessと組み合わせる場合は「Not compliant」へ変更することで、確認済みの準拠デバイスだけにアクセスを許可しやすくなると説明されています。(Microsoft Learn)
ただし、ここをいきなり「Not compliant」に変更すると、ポリシー未割り当ての端末が一斉に非準拠になり、メール、Teams、SharePoint、業務アプリにアクセスできなくなる可能性があります。特に、Autopilot登録直後の端末、共有端末、キオスク端末、検証用端末、買収・統合直後の端末がある環境では注意が必要です。
実務では、次の順番で進めるのが安全です。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | Devices without compliance policyのレポートを確認 | 未割り当て端末数を見ずに設定変更する |
| 2 | OS別に最低限のコンプライアンスポリシーを作成 | Windowsだけ作り、macOSやモバイルを忘れる |
| 3 | パイロットグループへ割り当て | All users / All devicesへ即時展開する |
| 4 | Conditional Accessはレポート専用または限定対象で検証 | 本番ユーザーを突然ブロックする |
| 5 | 未割り当て端末が減った後に「Not compliant」へ変更 | ヘルプデスク周知なしに切り替える |
Compliance status validity period
もう一つ重要なのが、Compliance status validity periodです。これは、デバイスが受け取ったコンプライアンスポリシーについて、一定期間内に正常に状態を報告しない場合に非準拠として扱う設定です。公式情報では、既定値は30日、設定可能範囲は1〜120日とされています。(Microsoft Learn)
この値は、セキュリティと業務継続性のバランスに直結します。短すぎると、長期出張、休職、予備端末、倉庫保管端末などが非準拠になりやすくなります。一方で長すぎると、長期間チェックインしていない危険な端末が「以前の準拠状態」のまま扱われやすくなります。
目安としては、常時利用されるPCやスマートフォンは既定値を基準にし、工場端末・共有端末・特殊用途端末は利用頻度に応じて別ポリシーや別グループで管理するのが現実的です。
デバイスコンプライアンスポリシーで設定できること
デバイスコンプライアンスポリシーでは、プラットフォームごとに異なる条件を設定します。Windows、macOS、iOS/iPadOS、Android Enterprise、Linuxなどで指定できる項目が異なるため、1つの共通ポリシーですべてのOSをまとめて管理するのではなく、OS別・用途別に分けて設計する必要があります。公式手順でも、ポリシー作成時にプラットフォームを選択し、各プラットフォーム用の設定を構成する流れになっています。(Microsoft Learn)
代表的な設定例は次のとおりです。
| 設定例 | 主な目的 | 実務での使いどころ |
|---|---|---|
| 最小OSバージョン | 古いOSの利用を防ぐ | サポート切れOSや脆弱なバージョンの排除 |
| 最大OSバージョン | 未検証の新OSを制御 | 大型アップデート直後の業務アプリ互換性確認 |
| デバイス暗号化 | 紛失・盗難時の情報漏えい対策 | WindowsのBitLocker、macOS/iOS/Androidの暗号化確認 |
| パスワード・PIN要件 | 端末ロックの強制 | BYODやモバイル端末の基本対策 |
| 脱獄・root化検出 | 改変端末の排除 | モバイル端末の業務利用制御 |
| 脅威レベル | EDR/MTDのリスク反映 | Microsoft Defender for Endpointなどと連携したアクセス制御 |
| カスタムコンプライアンス | 標準項目にない要件の判定 | 独自アプリ、設定ファイル、サービス状態の確認 |
注意したいのは、コンプライアンスポリシーの一部設定が、デバイス構成ポリシーで管理している設定と競合する可能性がある点です。公式概要でも、コンプライアンスポリシーの構成がデバイス構成ポリシーの設定を上書きする場合があるとされています。(Microsoft Learn)
たとえば、構成プロファイル側でパスワード要件を緩く設定し、コンプライアンスポリシー側でより厳しい条件を要求すると、ユーザーから見ると「設定は配られているのに非準拠になる」状態が起こります。ポリシー設計時は、配布する設定と判定する条件を同じ設計書で管理することが重要です。
非準拠時アクションは「即ブロック」だけで考えない
デバイスが非準拠になった場合、IntuneではActions for noncomplianceを使って、一定のスケジュールに基づく対応を設定できます。公式情報では、各コンプライアンスポリシーには「Mark device noncompliant」が既定で含まれ、既定では0日、つまり即時に非準拠としてマークされます。追加アクションとして、メール通知、リモートロック、退役リストへの追加、プッシュ通知などが用意されています。(Microsoft Learn)
ここでよくある失敗は、非準拠になった瞬間にConditional Accessでアクセスを止め、ユーザーに何を直せばよいか知らせない設計です。セキュリティ上は厳しく見えますが、実運用では問い合わせが急増し、ヘルプデスクが原因を切り分けられなくなります。
おすすめは、重要度に応じて段階を分けることです。
| 非準拠の種類 | 推奨アクション | 理由 |
|---|---|---|
| OSバージョン不足 | 1〜3日の猶予、メール通知 | ユーザーが更新する時間を確保する |
| パスワード未設定 | 短い猶予、Company Portal案内 | ユーザー操作で解消できる |
| 暗号化無効 | 猶予付き通知、状況によりアクセス制限 | 暗号化完了に時間がかかる場合がある |
| 脱獄・root化 | 原則即時非準拠 | リスクが高く、業務利用を継続させにくい |
| 長期間未チェックイン | 非準拠化、棚卸し対象化 | 紛失・放置・退職者端末の可能性がある |
非準拠アクションのスケジュールは、管理センターでは0.25刻みの小数を使える場合があり、0.25は6時間、0.5は12時間に相当します。その他の小数値を使う場合はMicrosoft Graphでの構成が案内されています。(Microsoft Learn)
メール通知にも注意点があります。Intuneはエンドユーザーのプロファイルにあるメールアドレスを使い、UPNそのものを使うわけではありません。メールアドレスが登録されていない場合、通知は送信されません。また、通知メールは[email protected]から送信されるため、メールセキュリティ製品やトランスポートルールでブロックされないか確認が必要です。(Microsoft Learn)
プッシュ通知は便利ですが、緊急連絡手段として過信してはいけません。公式情報でも、Company PortalアプリやIntuneアプリのプッシュ通知は遅延したり届かなかったりする可能性があり、緊急メッセージには依存しないよう注意されています。(Microsoft Learn)
Conditional Access連携で影響を受ける範囲
Microsoft Intuneのデバイスコンプライアンスポリシーは、単体では「準拠」「非準拠」を判定する仕組みです。しかし、Microsoft Entra Conditional Accessと組み合わせると、非準拠デバイスからのアクセスをブロックできます。公式概要では、デバイスがIntuneに登録されるとMicrosoft Entra IDにも登録され、コンプライアンス状態がMicrosoft Entra IDに報告されると説明されています。Conditional Accessで「Require device to be marked as compliant」を設定すると、その状態に基づいてアクセス可否が判断されます。(Microsoft Learn)
影響を受けやすいのは、次のようなサービスです。
- Exchange Online
- SharePoint Online
- OneDrive for Business
- Microsoft Teams
- Microsoft 365 Apps
- Entra ID連携のSaaSアプリ
- 社内WebアプリやVPN連携アプリ
特に注意すべきなのは、ポリシー未割り当て端末、共有端末、キオスク端末、プライマリユーザーのない端末です。Intuneのレポートでは、デバイスターゲットのポリシーで最後のチェックイン時にユーザーがサインインしていない場合、System accountがユーザーとして表示されることがあります。共有端末やマルチユーザー端末では、レポート上のユーザーと実際に困っているユーザーが一致しないことがあるため、ヘルプデスクは「最後にチェックインしたユーザー」を前提に切り分ける必要があります。(Microsoft Learn)
レポートを見るときの注意点
コンプライアンス運用で誤解されやすいのが、レポートの反映タイミングです。Intuneはデバイス状態を継続的に評価しますが、管理センター上のレポートはデバイスのチェックインやポリシー更新サイクルに依存します。公式の監視ページでも、レポートはデバイスがIntuneサービスへチェックインしたタイミングで更新され、直近の割り当て変更やターゲット変更がすぐ反映されない場合があると説明されています。(Microsoft Learn)
つまり、ポリシーを割り当てた直後に「Not evaluated」「Pending」「Unknown」が出ても、必ずしも設定ミスとは限りません。オンライン端末がチェックインし、ポリシーを受け取り、評価結果を返すまで待つ必要があります。個別ポリシーのDevice statusでは、デバイスがポリシーを受け取り、処理し、状態を報告するまで最大24時間かかる場合があるとされています。(Microsoft Learn)
また、レポート内の「Setting」列など、デバイスやスクリプト側から報告される値は、Intuneが内容を検証・強制するものではありません。公式情報では、これらの値は自由形式のテキスト、URL、ファイルパスなどを含む可能性があり、管理操作の唯一の根拠にしないよう注意されています。(Microsoft Learn)
ヘルプデスク向けには、次の確認フローを用意しておくと対応が安定します。
| 確認順 | 見る場所 | 判断ポイント |
|---|---|---|
| 1 | Devices > Compliance > Monitor | 全体で非準拠が急増していないか |
| 2 | Devices without compliance policy | ポリシー未割り当て端末がないか |
| 3 | 個別ポリシーのMonitor | どのポリシーで落ちているか |
| 4 | Per-setting status | どの設定が原因か |
| 5 | Last contacted | 最近チェックインしているか |
| 6 | Company Portal / Intuneアプリ | ユーザー側に修復案内が出ているか |
Windows/Linuxのカスタムコンプライアンスで開発者が見るべき点
WindowsとLinuxでは、Intuneの標準項目だけでは判定できない条件を、カスタムコンプライアンス設定で評価できます。公式情報では、WindowsとLinux向けにカスタムコンプライアンスを利用でき、JSONファイルと検出スクリプトを使って独自の準拠条件を定義すると説明されています。対象LinuxとしてはUbuntu Desktop 24.04 LTSまたは26.04 LTS、Red Hat Enterprise Linux 9または10が示されています。(Microsoft Learn)
たとえば、次のような用途が考えられます。
- 特定の社内エージェントがインストールされているか
- 指定サービスが起動しているか
- 独自証明書や設定ファイルが存在するか
- レジストリや構成ファイルの値が基準を満たしているか
- Linux端末で許可されたディストリビューション・バージョンか
WindowsではPowerShellスクリプト、LinuxではPOSIX準拠のシェルスクリプトを使います。スクリプトはJSONで定義された設定値を検出し、その結果をIntuneへ返します。カスタムコンプライアンスの結果は、標準のコンプライアンス設定と同じようにConditional Access判断に使えるため、開発者や自動化担当者は「単なるレポート用スクリプト」ではなく「アクセス可否に影響する判定ロジック」として扱う必要があります。(Microsoft Learn)
特に重要なのが、検出スクリプトの出力サイズです。コンプライアンスポリシー作成手順の公式情報では、Discovery script outputは2048文字に制限され、超過すると出力が切り詰められて無効なJSONとなり、コンプライアンス評価でエラー65009が発生する可能性があるとされています。(Microsoft Learn)
開発者・自動化担当者は、次の点を確認してください。
| 項目 | 確認内容 |
|---|---|
| スクリプト出力 | 2048文字以内に収める。詳細ログを標準出力に出しすぎない |
| JSONの型 | 数値、文字列、真偽値の型を実データと一致させる |
| エラー処理 | 想定外の例外時にも壊れたJSONを返さない |
| ルール分割 | 大量の判定を1ポリシーへ詰め込まず、用途別に分ける |
| セキュリティ | デバイス報告値を管理操作の唯一の根拠にしない |
| テスト | 本番Conditional Access適用前に限定グループで検証する |
WindowsではIntune Management Extensionが関係します。公式情報では、Windowsデバイスがカスタム設定を含むコンプライアンスポリシーを受け取るとIntune Management Extensionを確認し、未導入ならMSIを実行してインストールすると説明されています。また、PowerShellスクリプトの確認や実行は8時間間隔で行われ、Push通知でカスタムコンプライアンスをオンデマンド実行することはできません。(Microsoft Learn)
Android device administrator利用環境は移行計画が必要
Android device administrator、いわゆるAndroid DA管理を使っている環境は要注意です。公式の作成手順や非準拠アクション、監視ページでは、Google Mobile ServicesにアクセスできるデバイスではAndroid device administrator管理が非推奨となり、利用できなくなっているため、別のAndroid管理方法への移行が推奨されています。(Microsoft Learn)
実務では、Android Enterpriseへの移行を前提に、端末の用途ごとにプロファイルタイプを分ける必要があります。個人所有の仕事用プロファイル、会社所有のフルマネージド、専用デバイス、会社所有の仕事用プロファイルでは、適用できるコンプライアンス項目や非準拠時アクションが異なります。
移行時に見落としやすいのは、同じ「Android」でも、ポリシー、グループ、登録方式、ユーザー体験が変わることです。特に共有端末や専用端末では、ユーザーグループではなくデバイスグループを使った割り当てを検討しないと、コンプライアンス評価やレポートが期待どおりにならない場合があります。
第三者MDM・コンプライアンスパートナー利用時の注意点
Jamf Pro、Kandji、BlackBerry UEM、Ivanti、Omnissa Workspace ONEなど、第三者のデバイスコンプライアンスパートナーを使っている環境では、Intune単体のコンプライアンスポリシーだけを見ても全体像を把握できません。公式情報では、第三者コンプライアンスパートナーが収集したコンプライアンス状態をMicrosoft Entra IDへ追加し、Intuneが収集する結果とあわせてConditional Accessに利用できると説明されています。(Microsoft Learn)
特に重要なのは、パートナーを追加すると、対象ユーザーグループに割り当てられたデバイスについて、そのパートナーがMDM authorityになる点です。Intune側だけでポリシーを作っても、対象範囲や管理権限の前提を誤ると、期待どおりに準拠状態が反映されません。(Microsoft Learn)
第三者MDMからIntune MDMへ移行する場合は、ローカルでMDMプロファイルを削除するだけでは不十分です。公式情報では、移行時に第三者MDM側で退役アクションを開始し、Microsoft Entra IDでMDM列がNoneになったことを確認してからIntune MDMへ登録する流れがベストプラクティスとして示されています。クリーンアップが完了していない端末がIntuneに登録されたままの場合、Intuneは自分のコンプライアンスポリシーを適用し、第三者ポリシーを無視するとされています。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
Microsoft Intuneのデバイスコンプライアンスポリシーを安全に見直すなら、次の順番で確認するのがおすすめです。
| チェック項目 | 確認場所 | 合格ライン |
|---|---|---|
| 未割り当てデバイスの扱い | Endpoint security > Device compliance > Compliance policy settings | Conditional Access利用環境では「Not compliant」へ移行できる状態になっている |
| 有効期間 | Compliance status validity period | 業務端末のチェックイン頻度と合っている |
| OS別ポリシー | Devices > Compliance | Windows、macOS、iOS/iPadOS、Android、Linuxごとに必要なポリシーがある |
| グループ割り当て | 各ポリシーのAssignments | 共有端末・専用端末・Linux端末で割り当て方式が適切 |
| 非準拠時アクション | Actions for noncompliance | 通知、猶予、ブロックの順序が設計されている |
| Conditional Access | Microsoft Entra admin center | いきなり全社ブロックせず、段階適用されている |
| レポート確認 | Devices > Compliance > Monitor / Reports > Device compliance | 非準拠原因をポリシー単位・設定単位で追える |
| カスタムコンプライアンス | Windows/Linuxポリシー | JSON、スクリプト、出力制限、エラー時動作を検証済み |
| Android DA | Android関連ポリシー | Android Enterpriseへの移行計画がある |
| 第三者MDM | Tenant administration > Connectors and tokens | MDM authorityと移行手順が整理されている |
展開時に失敗しやすいパターン
いきなりAll usersやAll devicesへ適用する
コンプライアンスポリシーは、適用した瞬間にユーザー体験へ影響する可能性があります。特にConditional Accessと連携している場合、非準拠判定は単なる警告ではなく、実際のアクセスブロックにつながります。
本番展開では、まずIT部門、次に一部部署、最後に全社という段階展開が安全です。あわせて、ポリシー名には対象OS、目的、条件を含めると、後からレポートを見たときに原因を追いやすくなります。
例：
WIN-Compliance-BitLocker-MinOSiOS-Compliance-NoJailbreak-MinOSAndroidEnterprise-Compliance-WorkProfileLinux-Compliance-AllowedDistro-Custom
レポートの遅延を設定ミスと判断する
Intuneのレポートはリアルタイム監視ツールではありません。デバイスのチェックイン、ポリシー更新、レポート反映のタイミングがずれることがあります。公式の監視情報でも、サマリーと詳細一覧が同時に更新されない場合があると説明されています。(Microsoft Learn)
ポリシー変更直後に「反映されない」と判断する前に、Last contacted、同期状態、対象グループ、フィルター、ポリシー割り当てを確認しましょう。必要に応じて、ユーザーにCompany PortalアプリやIntuneアプリから同期を実行してもらう運用手順も用意しておくと、問い合わせ対応が早くなります。
ユーザーに修復方法を伝えていない
非準拠状態だけを表示しても、ユーザーは何を直せばよいか分かりません。メール通知テンプレートやCompany Portalの案内では、原因と操作手順を具体的に書く必要があります。
悪い例：
デバイスが非準拠です。対応してください。
良い例：
このデバイスはOSバージョンが組織の基準を満たしていません。設定アプリからOSアップデートを実行し、完了後にCompany Portalを開いて「同期」を実行してください。更新が完了しても解消しない場合は、端末名と表示されたエラーを添えてヘルプデスクへ連絡してください。
このように書くと、ユーザー自身で解消できるケースが増え、ヘルプデスクの一次対応も短縮できます。
実務でおすすめの展開手順
デバイスコンプライアンスポリシーを新規導入または見直す場合は、次の流れが現実的です。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | 管理対象OS、登録方式、未割り当て端末、既存CAを棚卸し | デバイス一覧、既存ポリシー一覧 |
| 設計 | OS別・用途別に準拠条件を決める | コンプライアンス設計書 |
| 検証 | IT部門や検証グループへ限定適用 | 非準拠理由、通知文、修復手順 |
| 段階展開 | 部署・拠点・端末種別ごとに展開 | 展開スケジュール |
| CA連携 | レポート専用または限定対象から開始 | アクセス制御ルール |
| 運用化 | レポート監視、例外処理、問い合わせ対応を定着 | 運用手順書、FAQ |
最初から厳しい条件を作り込むより、まずは「最低限守るべき条件」を全端末に広く適用し、運用が安定してから条件を強化するほうが失敗しにくくなります。たとえば、WindowsではBitLocker、最小OSバージョン、Defenderリスクレベルを基本にし、次の段階でカスタムコンプライアンスを追加する、といった進め方です。
まとめ：まずは未割り当て端末とConditional Accessの影響を確認する
Microsoft Intuneのデバイスコンプライアンスポリシーは、端末のセキュリティ状態を可視化するだけでなく、Microsoft Entra Conditional Accessと連携して業務データへのアクセス可否を左右します。そのため、設定変更は「セキュリティ強化」だけでなく「業務停止リスク」も含めて判断する必要があります。
まず確認すべきなのは、ポリシー未割り当てデバイスがどれだけあるか、Compliance policy settingsで未割り当て端末をどう扱っているか、Conditional Accessで準拠デバイス必須にしている範囲です。そのうえで、OS別ポリシー、非準拠時アクション、レポート監視、カスタムコンプライアンス、第三者MDM移行を順番に見直しましょう。
次に取るべき行動は、Intune管理センターで「Devices without compliance policy」と各ポリシーのMonitorを確認し、未割り当て端末と非準拠理由を一覧化することです。そこからパイロット展開、通知文の整備、Conditional Accessの段階適用へ進めれば、セキュリティを高めながらユーザー影響を抑えた運用に近づけます。
コメント