Microsoft Intune の「Create device compliance policies in Microsoft Intune」は、デバイスを「準拠」と判定する条件を作成し、非準拠時の通知・猶予・アクセス制御につなげるための重要な設定です。結論から言うと、今回管理者が優先して確認すべきなのは、新機能をただ試すことではなく、既存のコンプライアンスポリシーが現在の対応プラットフォーム、非準拠時アクション、Conditional Access、レポート運用に合っているかを棚卸しすることです。
Microsoft Learn の対象ページは、Intune 管理センターでデバイスコンプライアンスポリシーを作成する手順、割り当て、非準拠時アクション、更新反映の考え方を整理した公式ドキュメントです。GitHub 上の履歴では 2026年7月1日に「Metadata updates」のコミットが確認できますが、Microsoft Learn のページ表示では「Last updated on 2026-05-20」となっています。機能変更の断定ではなく、2026年7月時点の公式情報として運用確認に使うのが安全です。(GitHub)
Microsoft Intune のデバイスコンプライアンスポリシーとは
Microsoft Intune のデバイスコンプライアンスポリシーは、管理対象デバイスが組織のセキュリティ要件を満たしているかを評価するためのルールです。たとえば、OSバージョン、暗号化、脱獄・root化の有無、脅威レベル、パスワード要件などを条件にして、デバイスを「準拠」または「非準拠」として扱います。Microsoft Entra Conditional Access と組み合わせると、非準拠デバイスから社内リソースへのアクセスを制限できます。(Microsoft Learn)
重要なのは、コンプライアンスポリシーは設定を適用する機能ではなく、状態を判定する機能だという点です。BitLocker を有効にしたい、パスワード設定を強制したい、特定の構成を配布したい場合は、デバイス構成プロファイル、セキュリティベースライン、Endpoint security ポリシーなどと組み合わせる必要があります。コンプライアンスポリシーだけを作成しても、端末側の設定が自動的に修正されるわけではありません。
今回確認すべき更新ポイント
2026年7月時点で確認すべきポイントは、ポリシー作成画面そのものよりも、対応プラットフォーム、カスタムコンプライアンス、非準拠時アクション、割り当て、レポートの見直しです。
| 確認項目 | 公式情報で確認できる内容 | 管理者が取るべき対応 |
|---|---|---|
| 対応プラットフォーム | Android device administrator、Android AOSP、Android Enterprise、iOS/iPadOS、Linux、macOS、Windows などが対象 | 既存ポリシーが現在の管理方式に合っているか確認する |
| Android device administrator | GMS にアクセスするデバイスでは Android device administrator 管理が非推奨かつ利用不可 | Android Enterprise など別の管理方式への移行状況を確認する |
| Linux 対応 | Linux では Ubuntu Desktop 24.04 LTS / 26.04 LTS、Red Hat Enterprise Linux 9 / 10 が記載されている | Linux デバイス管理を行う場合、対応ディストリビューションと割り当て方式を確認する |
| カスタムコンプライアンス | Windows と Linux で、JSON と検出スクリプトを使ったカスタム評価が可能 | スクリプト出力、JSON、エラー時の監視方法を事前に検証する |
| 非準拠時アクション | 既定で「Mark device noncompliant」が含まれ、メール、プッシュ通知、リモートロック、リタイアリスト追加などを設定可能 | いきなり遮断せず、猶予期間と通知設計を作る |
| 割り当て | Linux ポリシーはユーザーベース割り当てに対応せず、デバイスグループへの割り当てのみ | Linux 用のデバイスグループ設計を見直す |
| レポート | デバイス状態、ポリシー別状態、設定別状態、非準拠デバイスを確認可能 | 適用後24時間程度は反映遅延を前提に監視する |
対象ページでは、ポリシー作成時に選べるプラットフォームとして Android、iOS/iPadOS、Linux、macOS、Windows などが示され、Linux では Ubuntu Desktop 24.04 LTS / 26.04 LTS、Red Hat Enterprise Linux 9 / 10 が記載されています。また、Linux のコンプライアンスポリシーはユーザーグループではなくデバイスグループへの割り当てが必要です。(Microsoft Learn)
影響範囲：誰が、どのデバイスで影響を受けるか
影響を受けるのは、Intune に登録され、コンプライアンスポリシーの対象になっているユーザーまたはデバイスです。特に Microsoft Entra Conditional Access と連携している環境では、ポリシーの判定結果が Exchange Online、SharePoint Online、Teams、業務アプリなどへのアクセス可否に影響します。Intune のコンプライアンス状態を Conditional Access に使うには、Microsoft Entra ID P1 または P2 が必要です。(Microsoft Learn)
実務上の影響は、次の3つに分けて考えると整理しやすくなります。
| 影響範囲 | 具体例 | 注意点 |
|---|---|---|
| エンドユーザー | 非準拠になると Company Portal に警告が出る、または社内リソースにアクセスできなくなる | 通知文が分かりにくいとヘルプデスク問い合わせが増える |
| ヘルプデスク | 「なぜTeamsに入れないのか」「なぜメールが見られないのか」という問い合わせが増える | 非準拠理由をレポートで追える状態にしておく |
| 管理者 | ポリシー割り当て、猶予期間、Conditional Access、通知テンプレートの整合性確認が必要 | 既存ポリシーの重複や競合を放置すると原因調査が難しくなる |
特に注意したいのは、「ポリシー未割り当てのデバイス」をどう扱うかです。Intune のテナント全体設定には、コンプライアンスポリシーが割り当てられていないデバイスを準拠とみなすか、非準拠とみなすかを決める設定があります。Microsoft は Conditional Access と組み合わせる場合、明示的に準拠確認済みのデバイスだけを許可するため、この設定を「Not compliant」にすることを案内しています。(Microsoft Learn)
管理者が最初に確認すべき設定
既存環境を見直す場合は、いきなり新しいポリシーを作るより、現在のポリシーとテナント設定を確認する方が安全です。
| 確認場所 | 確認する内容 | 判断基準 |
|---|---|---|
| Endpoint security > Device compliance > Compliance policy settings | ポリシー未割り当てデバイスの扱い | Conditional Access を使うなら「Not compliant」を検討 |
| Devices > Compliance | 既存のデバイスコンプライアンスポリシー | OS別、用途別、地域別に分かりすぎていないか確認 |
| Devices > Compliance > Monitor | 非準拠デバイス、ポリシー未割り当てデバイス | 例外端末や未管理端末が混ざっていないか確認 |
| Reports > Device compliance | 設定別・デバイス別の非準拠理由 | どの設定で失敗しているかを特定 |
| Microsoft Entra Conditional Access | 準拠デバイス要求の有無 | Intune 側の猶予期間とアクセス制御が矛盾していないか確認 |
コンプライアンス状態の有効期間も見落としやすい設定です。Intune では、デバイスが一定期間コンプライアンス状態を報告しない場合に非準拠として扱う設定があり、既定値は30日、設定可能範囲は1〜120日です。長すぎると休眠端末が準拠のまま残りやすく、短すぎると一時的にオフラインだった端末が非準拠になりやすくなります。(Microsoft Learn)
デバイスコンプライアンスポリシーの作成手順
Microsoft Intune 管理センターでの基本的な作成手順は次のとおりです。
| 手順 | 操作 | 実務上のポイント |
|---|---|---|
| 1 | Microsoft Intune admin center にサインイン | 最小権限の管理者ロールで作業する |
| 2 | Devices > Compliance > Create policy を選択 | Endpoint security 側の画面と混同しない |
| 3 | Platform を選択 | Windows、macOS、iOS/iPadOS、Android Enterprise、Linux など、OSごとに分ける |
| 4 | Basics で名前と説明を入力 | 後から見ても対象と目的が分かる命名にする |
| 5 | Compliance settings を構成 | 最初は最小限の条件で開始し、段階的に厳格化する |
| 6 | 必要に応じて Custom Compliance を追加 | Windows / Linux では JSON と検出スクリプトの事前準備が必要 |
| 7 | Actions for noncompliance を設定 | 通知、猶予、遮断の順番を設計する |
| 8 | Scope tags を設定 | 地域別・部門別管理がある場合に活用する |
| 9 | Assignments で対象グループを指定 | 本番前にパイロットグループで検証する |
| 10 | Review + create で作成 | 作成後はレポートで反映状況を確認する |
公式手順では、Devices から Compliance に進み、Create policy を選択してプラットフォームを指定します。Android Enterprise では、Fully managed、Dedicated、Corporate-owned work profile、Personally-owned work profile など、プロファイル種別の選択も必要です。(Microsoft Learn)
ポリシー名は運用で検索しやすくする
コンプライアンスポリシーは、数が増えるほど管理が難しくなります。ポリシー名には、OS、用途、対象範囲、重要条件を入れておくと、レポートや問い合わせ対応で迷いにくくなります。
例：
WIN-Compliance-BitLocker-MinOS-Global-v1
iOS-Compliance-Passcode-Jailbreak-Sales-v1
AndroidEnterprise-Compliance-PatchLevel-BYOD-v1
Linux-Compliance-CustomScript-Developers-v1避けたい名前は、「Windows Policy」「Compliance Test」「新しいポリシー」などです。作成者以外が見たときに、対象デバイスや目的が分からない名前は運用負荷を増やします。
カスタムコンプライアンスを使う場合の注意点
Windows と Linux では、Intune に組み込まれた標準項目だけでなく、JSON と検出スクリプトを使って独自のコンプライアンス条件を評価できます。たとえば、特定のエージェントが稼働しているか、社内標準の設定ファイルが存在するか、独自のセキュリティ設定が満たされているかを判定できます。(Microsoft Learn)
ただし、カスタムコンプライアンスは便利な反面、設計を誤るとトラブルの原因になります。
| 注意点 | 内容 | 対応策 |
|---|---|---|
| JSON とスクリプトの整合性 | JSON が期待する値とスクリプト出力が合わないと評価に失敗する | 事前にテスト端末で出力を確認する |
| スクリプト出力の上限 | 検出スクリプトの出力は 2048 文字に制限され、超過すると JSON が切り詰められ、エラー 65009 につながる可能性がある | 出力を必要最小限にし、大きなルールは複数ポリシーに分割する |
| 実行間隔 | Windows では Intune Management Extension がスクリプトを定期的に実行する | すぐに反映されない前提で検証する |
| 1ポリシー1スクリプト | 1つのカスタムコンプライアンスポリシーで使える検出スクリプトは1つ | 複数条件を1つのスクリプトで返すか、ポリシーを分ける |
公式情報では、Windows では PowerShell スクリプト、Linux では POSIX 準拠のシェルスクリプトを使い、JSON が準拠とみなす値やユーザー向けメッセージを定義します。また、カスタムコンプライアンスの結果も、標準のコンプライアンス設定と同じく Conditional Access の判断に利用できます。(Microsoft Learn)
非準拠時アクションは「通知」「猶予」「遮断」の順で設計する
デバイスコンプライアンスポリシーには、非準拠時アクションを設定できます。すべてのコンプライアンスポリシーには、既定で「Mark device noncompliant」が含まれ、通常は非準拠を検出するとすぐにデバイスを非準拠として扱います。必要に応じて、この既定アクションのスケジュールを変更し、ユーザーが修正するための猶予期間を設けることができます。(Microsoft Learn)
| アクション | 用途 | 注意点 |
|---|---|---|
| Mark device noncompliant | デバイスを非準拠として扱う基本アクション | Conditional Access と連携しているとアクセス遮断に直結しやすい |
| Send email to end user | ユーザーに修正を促す | ユーザープロファイルのメールアドレスを使うため、メール未設定だと送信されない |
| Send push notification | Company Portal アプリなどに通知する | 配信遅延や未配信の可能性があり、緊急通知には向かない |
| Remotely lock | 非準拠デバイスをリモートロックする | 対応プラットフォームが限られる |
| Add device to retire list | 非準拠デバイスをリタイア候補に追加する | 実際のリタイアは管理者が明示的に実行する必要がある |
非準拠時アクションのスケジュールは、Intune 管理センターでは 0.25 日単位の小数を指定できます。たとえば 0.25 は6時間、0.5 は12時間です。0.33 のような別の小数値を使う場合は Microsoft Graph での構成が必要です。(Microsoft Learn)
実務で使いやすい非準拠時アクションの例
いきなり全社でアクセス遮断すると、端末側の更新遅延やユーザーの理解不足によって問い合わせが急増します。まずは通知と猶予を組み合わせ、段階的に制御を強めるのが現実的です。
| シナリオ | 設定例 | 狙い |
|---|---|---|
| OSバージョンが古い | 0日目にメール、2日目に非準拠扱い | ユーザーに更新時間を与える |
| セキュリティパッチ不足 | 0日目にメール、3日目に再通知、5日目に非準拠扱い | 業務影響を抑えながら更新を促す |
| 高リスク端末 | 0日で非準拠、Conditional Access でアクセス制限 | 情報漏えいリスクを優先して即時遮断 |
| BYOD端末 | メール通知と Company Portal で修正手順を案内 | ユーザー自身で修正しやすくする |
| 共有端末・キオスク端末 | ユーザー通知より管理者通知を重視 | 利用者ではなくIT部門が対応する前提にする |
通知メールを使う場合は、テンプレートの文面も重要です。「デバイスが非準拠です」だけではユーザーは行動できません。「Windows Update を実行してください」「Company Portal を開いてデバイスを同期してください」「修正後も反映に時間がかかる場合があります」など、具体的な操作を入れておくと問い合わせを減らせます。
InGracePeriod と最終的な準拠状態の考え方
猶予期間を設定すると、デバイスが実際には条件を満たしていなくても、すぐに最終的な非準拠扱いにならず、InGracePeriod として表示される場合があります。公式ドキュメントでは、非準拠状態であっても猶予期間が未来の日付なら InGracePeriod になり、猶予がない場合や期限切れの場合は NonCompliant になると説明されています。(Microsoft Learn)
複数のコンプライアンスポリシーが同じデバイスに割り当てられている場合、Intune は状態ごとの重大度に基づいて最終的な準拠状態を決めます。重大度は、Unknown、NotApplicable、Compliant、InGracePeriod、NonCompliant、Error の順に高くなり、複数ポリシーの中で最も重大度が高い状態がデバイス全体の状態として扱われます。(Microsoft Learn)
この仕組みを理解していないと、「あるポリシーでは準拠なのに、デバイス全体では非準拠」という状況に戸惑います。レポートを見るときは、デバイス全体の状態だけでなく、どのポリシーのどの設定で失敗しているかまで確認してください。
レポートで見るべきポイント
ポリシー作成後は、必ずレポートで状態を確認します。Intune では、デバイス全体の準拠状態、ポリシー別の状態、設定別の状態、個別デバイスの詳細を確認できます。(Microsoft Learn)
| レポート観点 | 見るべき内容 | 判断例 |
|---|---|---|
| Device compliance status | 全体の Compliant / Not compliant / In grace period | 非準拠が急増していないか確認 |
| Devices without compliance | コンプライアンスポリシー未割り当て端末 | 本来対象にすべき端末が漏れていないか確認 |
| Policy compliance | ポリシー単位の適用状況 | 新規ポリシーが意図した対象に届いているか確認 |
| Setting compliance | 設定ごとの失敗状況 | どの条件が非準拠の原因か確認 |
| Last contacted | 最後に Intune と通信した日時 | オフライン端末や休眠端末を切り分ける |
レポートの反映は、デバイスのチェックインやポリシー更新サイクルに依存します。公式ドキュメントでは、ポリシー対象のデバイスがチャートに表示されるには、デバイスがオンラインでチェックインし、ポリシーを処理して状態を報告する必要があり、最大24時間かかる場合があると説明されています。(Microsoft Learn)
また、レポートに表示される設定値には、デバイス側のスクリプトやアプリケーションが報告した自由形式の値が含まれる場合があります。公式ドキュメントでは、こうした値は Intune が検証・強制するものではないため、管理操作の唯一の根拠にしないよう注意しています。(Microsoft Learn)
移行期限と非推奨項目で注意すべきこと
今回の「Create device compliance policies」ページ自体に、全管理者が一律で対応すべき新しい移行期限が明記されているわけではありません。ただし、関連する重要な非推奨・変更予定はあります。
まず、Android device administrator 管理は、Google Mobile Services にアクセスするデバイスでは非推奨かつ利用不可とされています。該当する Android 端末が残っている場合は、Android Enterprise の Personally-owned work profile、Fully managed、Corporate-owned work profile、Dedicated device など、用途に合う管理方式へ移行する必要があります。(Microsoft Learn)
さらに、Intune の「In development」情報では、Android 13 以降のデバイスに対する Google Play の Strong Integrity 定義変更について、Microsoft Intune が 2026年10月31日までに変更を適用すると案内されています。Android 13 以降で過去12か月以内のセキュリティ更新がないデバイスは、Strong Integrity を満たさなくなり、アプリ保護ポリシーやコンプライアンスポリシー、Conditional Access によって業務リソースへアクセスできなくなる可能性があります。(Microsoft Learn)
Android Enterprise のコンプライアンスポリシーでセキュリティパッチレベルやデバイス整合性を条件にしている環境では、2026年10月31日を単なる将来予定ではなく、端末棚卸しとパッチ運用を見直す期限として扱うべきです。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| コンプライアンスポリシーを構成ポリシーと誤解する | 条件を作ったのに端末設定が修正されない | 設定適用は構成プロファイルやセキュリティポリシーで行う |
| ポリシー未割り当てデバイスを Compliant のままにする | 管理対象外の端末がアクセスできる可能性が残る | Conditional Access 利用時は Not compliant を検討する |
| 初日から全社に強制する | Teams やメールに入れない問い合わせが急増する | パイロットグループ、通知、猶予期間を使う |
| 動的デバイスグループだけに依存する | 登録直後にポリシーが届くまで遅延する | 初期適用はユーザーグループやフィルターも検討する |
| Linux ポリシーをユーザーグループに割り当てようとする | 意図どおり適用できない | Linux はデバイスグループ割り当てで設計する |
| カスタムコンプライアンスの出力が大きすぎる | JSON が無効になり、65009 などのエラーにつながる | 出力を短くし、ルールを分割する |
| プッシュ通知を緊急連絡に使う | 通知遅延や未配信で対応が遅れる | 緊急性が高い場合はメール、ポータル、別の運用連絡を併用する |
| レポート反映を即時と考える | 「設定したのに反映されない」と誤判断する | チェックイン、同期、最大24時間程度の反映遅延を前提に見る |
特に大規模環境では、ポリシーの「厳しさ」よりも「説明可能性」が重要です。なぜ非準拠になったのか、誰が直せるのか、いつアクセスが止まるのかをユーザーとヘルプデスクが理解できない設計は、運用で破綻しやすくなります。
グローバル環境での設計ポイント
グローバル向けに Microsoft Intune のコンプライアンスポリシーを運用する場合は、国・地域、OS、デバイス所有形態、サポート体制の違いを前提に設計します。
| 設計観点 | 推奨される考え方 |
|---|---|
| 地域別の猶予期間 | ネットワーク品質や時差を考慮し、全地域一律の即時遮断は避ける |
| 通知言語 | 主要拠点の言語に合わせて通知テンプレートを用意する |
| BYOD と会社所有端末 | BYOD はユーザー修正手順、会社所有端末はIT部門対応を重視する |
| OS別ポリシー | Windows、macOS、iOS/iPadOS、Android、Linux を無理に1つの基準で扱わない |
| 例外管理 | 役員端末、検証端末、共有端末などは例外理由と期限を記録する |
| Conditional Access | いきなり本番遮断せず、レポート確認後に段階的に適用する |
グローバル運用では、完璧な1本のポリシーを作るより、標準ポリシー、地域差分、例外管理、期限付き除外を整理する方が現実的です。例外が多い場合は、ポリシーが厳しすぎるか、デバイス更新運用が追いついていない可能性があります。
管理者向けチェックリスト
公開情報を確認した後は、次の順番で見直すと効率的です。
- すべての主要OSに明示的なコンプライアンスポリシーが割り当てられているか
- 「ポリシー未割り当てデバイス」を Compliant のままにしていないか
- Conditional Access と非準拠時アクションの猶予期間が矛盾していないか
- Android device administrator 管理の端末が残っていないか
- Android 13 以降の端末で、セキュリティ更新が長期間止まっているものがないか
- Linux ポリシーをデバイスグループに割り当てているか
- Windows / Linux のカスタムコンプライアンスで、JSON とスクリプト出力を検証済みか
- 検出スクリプトの出力が 2048 文字を超えないように設計されているか
- 非準拠通知メールの宛先、文面、ロケール、差出人ブロック対策を確認したか
- Devices > Compliance > Monitor と Reports > Device compliance を定期確認する運用があるか
まとめ：まずは「作成」より「棚卸し」から始める
Microsoft Intune の「Create device compliance policies in Microsoft Intune」は、新しいポリシーを作るための手順書であると同時に、既存のコンプライアンス運用を見直すための基準にもなります。特に2026年7月時点では、Android device administrator の非推奨、Android 13 以降の Strong Integrity 変更予定、Linux 対応範囲、カスタムコンプライアンスの制限、非準拠時アクションの設計を確認しておく価値があります。
次に取るべき行動は、新しいポリシーを急いで作ることではありません。まず既存ポリシーを一覧化し、ポリシー未割り当てデバイス、非準拠デバイス、古いAndroid管理方式、Conditional Accessとの連携状況を確認してください。そのうえで、少数のパイロットグループに対して通知と猶予期間を設計し、レポートで影響を確認してから段階的に本番展開するのが安全です。
コメント