Intune のデバイス コンプライアンス ポリシーは、もう「端末の健康診断」をするだけの機能ではありません。2026年4月8日に更新された Microsoft Learn のゼロトラスト手順では、デバイス コンプライアンス ポリシーで最小要件を定義し、その結果を Microsoft Entra 条件付きアクセスで実際のアクセス許可・遮断に使う流れがより明確に示されました。つまり、ポリシーを作るだけでは不十分で、条件付きアクセスまでつないで初めて統制として機能します。この記事では、今回の更新の意味と、Intune のデバイス コンプライアンス ポリシーが条件付きアクセスの適用レイヤーとして重要度を増し続ける理由、さらに今すぐ見直すべき設定と運用の勘所を実務目線で整理します。 (Microsoft Learn)
2026年4月8日の更新で何が重要なのか
今回の更新で押さえるべきポイントは、新しい設定項目が大量に増えたことではなく、Intune のデバイス コンプライアンス ポリシーと Microsoft Entra 条件付きアクセスの役割分担がよりはっきりしたことです。手順3では「最小要件を定義して準拠・非準拠を判定する」こと、手順4では「その結果を使って準拠したデバイスだけを通す」ことが明示されています。Microsoft の Zero Trust 展開ガイドでも、レイヤー3が Compliance policies、レイヤー4が Require healthy and compliant devices と整理されており、評価と適用が連続した設計として扱われています。 (Microsoft Learn)
以下は、更新ガイダンスを管理者向けに実務へ置き換えた要約です。 (Microsoft Learn)
| 項目 | ガイダンスが強調していること | 実務でやること |
|---|---|---|
| コンプライアンスポリシー | OS バージョン、暗号化、パスワード、脱獄・root 化などの最小要件を定義する | プラットフォームごとに要件を明文化して配布する |
| 条件付きアクセス | 準拠状態を使ってアクセス可否を判断する | 「Require device to be marked as compliant」を段階的に有効化する |
| 運用 | グループ整合、猶予期間、競合回避、テストが必要 | レポート専用モードと What If で先に影響確認する |
なぜ Intune のデバイス コンプライアンス ポリシーは条件付きアクセスの適用レイヤーとして広がるのか
コンプライアンス判定がそのままアクセス制御の条件になる
Intune はデバイスの状態を評価して、Microsoft Entra ID に準拠情報を渡します。条件付きアクセス側は、その情報を使ってアクセスを許可またはブロックします。ここが重要で、コンプライアンスポリシー単体は「評価」まで、条件付きアクセスは「執行」まで担当します。この分離があるからこそ、同じ準拠シグナルを Microsoft 365、SaaS、オンプレミス アプリまで横展開しやすいのです。 (Microsoft Learn)
ゼロトラスト導入の標準手順に組み込まれた
Microsoft の Zero Trust deployment approach with Microsoft Intune では、レイヤー1がアプリ保護、レイヤー2が登録、レイヤー3がコンプライアンス、レイヤー4が準拠デバイス要求、レイヤー6がデバイス リスク監視という順番で整理されています。つまり、コンプライアンスは単独機能ではなく、ゼロトラストを前進させる途中の必須レイヤーです。評価だけで終わらせず、条件付きアクセスで適用する前提が、公式の標準設計になっています。 (Microsoft Learn)
静的な設定だけでなく、リスク信号まで取り込める
Intune のデバイス コンプライアンス ポリシーは、最低 OS バージョンや暗号化の有無のような静的条件だけでは終わりません。Microsoft は、Mobile Threat Defense パートナーや Microsoft Defender for Endpoint のリスク情報をコンプライアンス判定に取り込み、それを条件付きアクセスでも使える構成を案内しています。さらに、Windows と Linux ではカスタム コンプライアンスも使えるため、標準 UI にない独自要件まで広げられます。これが「単なる設定チェック」から「柔軟な適用レイヤー」へ広がっている大きな理由です。 (Microsoft Learn)
Intune だけで管理していない端末も取り込みやすい
実環境では、すべての端末を Intune 単独で管理しているとは限りません。Microsoft はサードパーティの device compliance partner 連携をサポートしており、たとえば Jamf Pro や Kandji、Omnissa Workspace ONE UEM などの管理基盤から得た準拠情報も Microsoft Entra ID に渡して条件付きアクセスへ利用できます。さらに NAC 連携では、Wi-Fi や VPN などオンプレミス寄りのアクセス制御にも準拠状態を使えます。守備範囲が広いからこそ、コンプライアンスポリシーの重要度が上がっています。 (Microsoft Learn)
BYOD では MAM、管理端末ではコンプライアンスという住み分けがしやすい
Microsoft は Zero Trust のレイヤー1として、未登録 BYOD 向けの app protection policies を先に置いています。その上で、端末の OS 状態や暗号化、root 化、BitLocker まで見たい場合に、登録済みデバイス向けのデバイス コンプライアンス ポリシーへ進みます。この順番があるため、BYOD を全部フル管理に寄せなくても、必要な範囲だけ段階的に厳しくできます。コンプライアンスが広がるのは、厳格化しやすいからだけでなく、導入を分けやすいからでもあります。 (Microsoft Learn)
管理者が今すぐ見直すべき設定と運用ポイント
運用で差が出るのは、プラットフォーム別の細かなルールより先に、テナント全体の前提設定とロールアウト方法です。特に Microsoft Learn が強く勧めているのは、未割り当て端末の扱い、非準拠アクション、グループ整合、テストです。 (Microsoft Learn)
| 見直し項目 | 推奨 | 理由 |
|---|---|---|
| 未割り当てデバイスの扱い | 「Compliant」の既定値を放置せず、条件付きアクセスを使うなら「Not compliant」を検討する | ポリシー未配布の端末が準拠扱いのままだと抜け道になりやすい |
| Compliance status validity period | 既定の 30 日を前提にせず、業務影響に応じて見直す | 長期間チェックインしない端末を自動的に非準拠へ落とせる |
| Actions for noncompliance | いきなり 0 日で全面遮断せず、メール通知や猶予期間を組み合わせる | セキュリティを保ちながらヘルプデスク負荷を抑えやすい |
| コンプライアンスと CA の対象グループ | 同じユーザー／デバイス群にそろえる | グループ不一致は想定外の通過や遮断を生みやすい |
| テストと例外 | Report-only、What If、break-glass 除外を先に設定する | 誤設定によるロックアウトを防ぎやすい |
補足すると、条件付きアクセスのポリシーは Intune ではなく Microsoft Entra ID 側で作成されます。また、条件付きアクセスを使うには Intune に加えて Microsoft Entra ID P1 または P2 が必要です。加えて、Microsoft は有効化前に少なくとも 1 台の準拠端末を用意し、緊急用アカウントを除外し、まず Report-only で影響を確認する流れを推奨しています。なお、「Require device to be marked as compliant」を有効にしても、新規の Intune 登録そのものは妨げられません。 (Microsoft Learn)
導入シナリオ別にどう考えるべきか
BYOD 中心の組織
BYOD が多いなら、最初から全員にフル MDM と厳格なデバイス コンプライアンス ポリシーを求めるより、まずはアプリ保護ポリシーで業務データを守る構成が現実的です。個人端末のプライバシーを保ちつつ Outlook や Teams の業務データだけを保護できるため、導入ハードルが低くなります。そのうえで、端末の暗号化や OS バージョンまで条件付きアクセスで見たい利用者だけを登録＋コンプライアンスへ進めると、摩擦を抑えながら強度を上げられます。 (Microsoft Learn)
企業管理 PC・モバイル中心の組織
企業所有端末が中心なら、Intune のデバイス コンプライアンス ポリシーを中核に置くのが王道です。最低ラインとしては OS バージョン、パスワード・PIN、暗号化、jailbreak/root 化の確認が出発点になります。より厳しくするなら、Windows の BitLocker、Secure Boot、Code Integrity、TPM、macOS や Windows の Firewall など、プラットフォームごとの強化項目を追加していく形が扱いやすいです。ここで重要なのは、「構成プロファイルで設定を配る」と「コンプライアンスで評価する」を混同しないことです。設定を配るのは構成、守れているかを見るのがコンプライアンス、という役割分担で設計したほうが破綻しません。 (Microsoft Learn)
Jamf など他社 MDM を併用する組織
macOS を Jamf Pro で管理している、あるいは部門ごとに別の MDM が混在しているなら、無理にすべてを Intune へ寄せなくてもかまいません。Microsoft はサードパーティの device compliance partner をサポートしており、他社 MDM の準拠情報を Microsoft Entra 条件付きアクセスに流し込む設計が可能です。既存運用を生かしつつ、アクセス統制だけを共通化できるため、現場の反発を抑えながらゼロトラストへ寄せやすくなります。 (Microsoft Learn)
独自要件が多い組織
「標準の UI だけでは要件を満たせない」という組織では、Windows と Linux 向けの custom compliance も検討に値します。JSON と discovery script で独自基準を定義できるため、監査要件や社内標準に合わせてコンプライアンス判定を拡張できます。標準機能だけで無理に運用をねじ曲げるより、ここで柔軟性を持たせたほうが長続きします。 (Microsoft Learn)
失敗しやすいポイント
最も多い失敗は、デバイス コンプライアンス ポリシーを作っただけで安心してしまうことです。公式ガイドでも、コンプライアンスは評価を行うレイヤーであり、ブロックを実行するのは条件付きアクセスだと整理されています。ポリシー作成だけで終えると、「非準拠は見えているのにアクセスは止まらない」という中途半端な状態になります。 (Microsoft Learn)
次に多いのが、0日ブロックで一気に本番投入することです。Intune では既定で「Mark device noncompliant」が 0 日になっており、そのままだと端末が非準拠になった瞬間に条件付きアクセスが効きやすくなります。猶予期間、メール通知、再通知の順で組むだけでも、利用者体験と運用負荷は大きく変わります。 (Microsoft Learn)
三つ目は、ブラウザーや認証フローの癖を見落とすことです。Microsoft Entra は一部ブラウザーでクライアント証明書を使ってデバイス状態を識別し、初回サインイン時に証明書選択が必要になります。Windows の Edge InPrivate は非準拠扱いになることがあり、device-code OAuth flow ではデバイス状態を条件にした grant control が使えません。パイロットでここを見ないと、「端末は準拠なのにブラウザー経由で通らない」という問い合わせが増えます。 (Microsoft Learn)
四つ目は、利用者に回復手順を渡していないことです。Company Portal では Windows の「Check access」や iOS の「Check status」によって、要件の再確認や是正導線の表示ができます。管理者側でコンプライアンスを厳しくするほど、利用者側のセルフリカバリー導線を整えておかないと、ヘルプデスクが詰まります。 (Microsoft Learn)
迷ったらこの順番で進める
- まず、BYOD・企業所有・他社 MDM 管理端末に分けて、MAM で十分な端末と、MDM 登録＋デバイス コンプライアンス ポリシーが必要な端末を分けます。 (Microsoft Learn)
- 次に、各プラットフォームで最低限見る項目を決めます。OS バージョン、パスワード・PIN、暗号化、root/jailbreak から始め、必要なら BitLocker、Firewall、Secure Boot、TPM などを追加します。 (Microsoft Learn)
- そのうえで、未割り当てデバイスの扱い、状態有効期限、非準拠アクションをテナント全体で決めます。特に「未割り当てでも準拠扱い」の既定値は早めに見直す価値があります。 (Microsoft Learn)
- Microsoft Entra 側で条件付きアクセスを作成し、「Require device to be marked as compliant」を Report-only から始めます。break-glass アカウントを除外し、コンプライアンス側と同じグループを対象にします。 (Microsoft Learn)
- パイロット利用者には Company Portal での再チェック手順まで案内し、実際にどんな問い合わせが来るかを確認してから本番化します。 (Microsoft Learn)
- 本番化後に、MTD、Defender のリスク情報、サードパーティ MDM、custom compliance、NAC 連携を順に追加していくと、無理なく適用範囲を広げられます。 (Microsoft Learn)
今回の Microsoft の更新が示しているのは、Intune のデバイス コンプライアンス ポリシーを「あると便利な設定集」ではなく、「条件付きアクセスを成立させる前提データ」として扱うべきだということです。まずは未割り当て端末の扱い、猶予期間、グループ整合、Report-only の4点から見直してください。そこを押さえるだけでも、Intune のデバイス コンプライアンス ポリシーは、単なるチェック機能から、実効性のあるアクセス統制へ変わります。 (Microsoft Learn)
コメント