Microsoft Intune のデバイス コンプライアンス レポートで重要なのは、「非準拠デバイスの数を見ること」だけではありません。今回確認すべきポイントは、レポートの値がデバイスの最終チェックイン、最後に利用したユーザー、ポリシー単位とデバイス全体の違いに左右されることです。見方を誤ると、実際には別ポリシーで失敗している端末を対象ポリシーの不具合と判断したり、Conditional Access のブロック原因を取り違えたりします。
Microsoft Learn の「Monitor results of your device compliance policies in Microsoft Intune」は、Intune のコンプライアンス ポリシー結果をどこで確認し、どの状態をどう解釈すべきかを整理した管理者向けドキュメントです。対象は Android、iOS/iPadOS、Linux、macOS、Windows など広範囲で、Microsoft Entra Conditional Access と組み合わせている環境では、監視・運用手順に直接影響します。この記事では、2026年7月1日時点で確認すべき実務上の変更点、影響範囲、設定確認、移行・運用上の注意点を整理します。
Microsoft Intune のコンプライアンス監視で今回確認すべき結論
今回のポイントは、新しいボタンや画面だけを覚えることではなく、Intune のコンプライアンス レポートを「アクセス制御の判断材料」として正しく読むことです。
Microsoft Intune のコンプライアンス レポートでは、次の情報を確認できます。
- テナント全体のデバイス コンプライアンス状態
- 個別ポリシーごとの準拠・非準拠状態
- 個別設定ごとの準拠・非準拠状態
- デバイス単位で影響しているポリシーや設定
Microsoft 公式ドキュメントでは、Intune のコンプライアンス レポートが、デバイスがコンプライアンス ポリシーを満たしていないタイミングや、組織内のコンプライアンス関連問題を把握するためのものだと説明されています。対象プラットフォームには Android device administrator、Android AOSP、Android Enterprise、iOS/iPadOS、Linux Ubuntu Desktop 24.04 LTS または 26.04 LTS、macOS、Windows が含まれます。(Microsoft Learn)
管理者が特に確認すべき点は、次の4つです。
| 確認ポイント | 管理者が見るべき理由 | 実務での対応 |
|---|---|---|
| レポート更新はデバイス チェックインに依存する | ポリシー変更直後に結果が反映されないことがある | 変更直後の判定だけで障害扱いしない |
| 最後にチェックインしたユーザーの状態が表示される | 共有端末や複数ユーザー端末で原因を誤認しやすい | UPN、Last contacted、対象グループを併せて確認する |
| Setting 列の値はデバイス報告値である | スクリプトやアプリが返した値を Intune が内容検証しているわけではない | 値だけで管理操作を実行しない |
| ポリシー単位の準拠とデバイス全体の準拠は別物 | あるポリシーでは準拠でも、別ポリシーで非準拠になり得る | Policy compliance と Noncompliant devices を横断して確認する |
「Monitor results of your device compliance policies」とは何か
「Monitor results of your device compliance policies」は、Microsoft Intune で作成したデバイス コンプライアンス ポリシーの結果を監視するための公式ガイドです。
Intune のコンプライアンス ポリシーは、管理対象デバイスが組織の条件を満たしているかを評価するルールです。たとえば、最小 OS バージョン、暗号化、脱獄・root 化、Microsoft Defender for Endpoint などの脅威レベル連携を条件にできます。Microsoft Entra Conditional Access と連携すると、デバイスの準拠状態をもとに社内リソースへのアクセスを許可またはブロックできます。(Microsoft Learn)
つまり、このレポートは単なる棚卸し画面ではありません。ゼロトラスト運用では、次の判断に使う重要な情報源になります。
- どのデバイスが社内リソースにアクセスできる状態か
- どのポリシーが非準拠を発生させているか
- どの設定がユーザー対応や管理者対応を必要としているか
- Conditional Access によるアクセス拒否が妥当か
- ポリシー変更後に想定外の影響が出ていないか
特にグローバル企業では、地域、OS、所有形態、時差、ネットワーク品質によってデバイスのチェックインタイミングが異なります。日本の管理者画面で見える「未評価」や「保留中」が、海外拠点では単にチェックイン前であるケースもあります。
影響範囲：誰が、どの環境で確認すべきか
今回の情報は、Microsoft Intune を使うすべての組織に関係しますが、特に影響が大きいのは次の環境です。
| 影響を受けやすい環境 | 理由 | 優先して確認するレポート |
|---|---|---|
| Conditional Access で「準拠デバイスを要求」している環境 | 非準拠判定がそのままアクセス拒否につながる | Noncompliant devices、Policy compliance |
| 共有 Windows PC やキオスク端末がある環境 | 最後にチェックインしたユーザーの状態が表示されるため、ユーザー起因か端末起因かを誤認しやすい | Device status、Last contacted、Logged in user |
| Android device administrator を残している環境 | 既に非推奨で、GMS ありデバイスでは利用継続リスクが高い | Devices without compliance policy、Android 関連ポリシー |
| カスタム コンプライアンスを使う環境 | Setting 列の値がデバイス側スクリプトの報告値になる | Setting compliance、Noncompliant devices and settings |
| グローバル展開している環境 | 時差、拠点ネットワーク、端末利用頻度でチェックインがずれる | Device compliance trends、Last contacted |
Microsoft 公式ドキュメントでは、コンプライアンス評価は継続的に行われる一方、Intune 管理センター上のレポートはデバイスがサービスにチェックインしたタイミングで更新されると説明されています。したがって、ポリシー割り当てやターゲット変更直後に、レポートがすぐ最新状態を示すとは限りません。(Microsoft Learn)
管理者が最初に見るべき画面
Intune のコンプライアンス状況は、主に3つの入口から確認します。
Devices > Compliance > Monitor
まず確認すべき入口は、Intune 管理センターの Devices > Compliance > Monitor です。
ここでは、デバイス コンプライアンスの全体像を把握できます。公式ドキュメントでは、この画面から次のレポートにアクセスできると説明されています。
- Device compliance status
- Devices without compliance
- Policy compliance
- Setting compliance
Device compliance status タイルでは、Intune に登録されたデバイス全体の準拠状態を確認できます。選択すると Noncompliant devices レポートにつながり、どのデバイスが非準拠なのかを掘り下げられます。(Microsoft Learn)
Devices > Compliance > 対象ポリシー > Monitor
特定のコンプライアンス ポリシーを調査する場合は、Devices > Compliance で対象ポリシーを開きます。
ポリシーを開くと、既定で Monitor タブが表示され、次の情報を確認できます。
| 表示項目 | 使いどころ |
|---|---|
| Device status | そのポリシーを受け取ったデバイスの大まかな状態を見る |
| View report | デバイス名、ログインユーザー、OS、最終接触日時などを確認する |
| Per-setting status | どの設定で準拠・非準拠・エラーが出ているかを見る |
重要なのは、Policy compliance status は、そのポリシーに対する状態であり、デバイス全体の最終的な準拠状態ではないという点です。Microsoft 公式ドキュメントでも、あるポリシーで準拠していても、別のポリシーで非準拠なら Intune はデバイス全体を非準拠と見なす可能性があると説明されています。(Microsoft Learn)
Reports > Device compliance > Reports
運用改善や傾向分析には、Reports > Device compliance > Reports を使います。
Microsoft Intune Reports の公式ドキュメントでは、Device compliance、Device compliance trends、Noncompliant devices and settings、Devices without compliance policy、Settings compliance、Policy compliance などのレポートが整理されています。たとえば Device compliance trends では、30日間のデバイス コンプライアンス傾向を確認できます。(Microsoft Learn)
日々のヘルプデスク対応では Devices > Monitor の Operational レポート、月次レビューやセキュリティ会議では Reports 配下の Organizational レポートを使う、と役割を分けると運用しやすくなります。
コンプライアンス状態の見方
Intune のコンプライアンス状態は、単に「準拠」「非準拠」だけではありません。状態ごとに意味と対応が異なります。
| 状態 | 意味 | 管理者の判断 |
|---|---|---|
| Compliant | 1つ以上のコンプライアンス ポリシー設定を正常に適用している | 通常は対応不要。ただし別ポリシーの状態も必要に応じて確認 |
| In-grace period | 条件を満たしていないが、管理者が設定した猶予期間内 | ユーザー通知、修復手順、期限を確認 |
| Not evaluated | 新規登録直後、ポリシー未割り当て、未チェックインなどで評価されていない | 最終チェックイン、割り当て、対象グループを確認 |
| Not compliant | 1つ以上の設定に失敗、またはユーザーが要件を満たしていない | どのポリシー・設定で失敗したかを調査 |
特に「Not evaluated」は、障害とは限りません。新規登録デバイス、ポリシー更新後にまだチェックインしていないデバイス、ユーザー関連付けのない iOS/iPadOS DEP デバイス、Android Enterprise dedicated devices、DEM アカウントで登録されたデバイスなどで発生する場合があります。(Microsoft Learn)
現場では、Not evaluated を見つけたらすぐにポリシーを変更するのではなく、次の順番で確認するのが安全です。
- デバイスが Intune に登録済みか確認する
- Last contacted が古くないか確認する
- 対象ポリシーが正しいユーザーまたはデバイス グループに割り当てられているか確認する
- フィルターや除外グループで対象外になっていないか確認する
- Conditional Access のブロックと同時発生していないか確認する
レポート結果を誤読しやすいポイント
今回のドキュメントで特に重要なのは、Known reporting behaviors の考え方です。Intune のレポートはリアルタイムの監視カメラではなく、最後に確認できたデバイス状態を表示する運用レポートとして読む必要があります。
ポリシー変更直後は結果がずれることがある
Intune では、デバイス構成の更新、OS バージョン変更、セキュリティ状態の変化、ポリシー割り当て変更、ユーザー サインインなどがコンプライアンス状態に影響します。一方で、レポート更新はデバイス チェックインとポリシー更新サイクルに依存します。(Microsoft Learn)
たとえば、Windows の最小 OS バージョンを変更した直後にレポートを見ると、一部の端末だけが古い状態のまま表示されることがあります。これは、端末がまだチェックインしていないだけの可能性があります。
実務では、ポリシー変更後すぐに「非準拠がゼロにならない」と判断せず、最低限次を確認します。
- 変更日時
- 対象デバイスの Last contacted
- デバイスがオンラインか
- 対象グループへの反映状況
- ユーザーが Company Portal で状態確認を実行したか
共有端末では最後のユーザー状態が見える
公式ドキュメントでは、コンプライアンス レポートはデバイスの最後のユーザーに関連付いた状態を表示すると説明されています。共有端末やマルチユーザー端末では、前に利用したユーザーの状態が見える場合があります。(Microsoft Learn)
たとえば、共用 Windows PC でユーザーAが最後にサインインした後、ユーザーBが問い合わせてきた場合、レポート上のユーザー情報だけを見て判断すると、誤ったユーザーに対応依頼を送ってしまう可能性があります。
共有端末では、次の情報をセットで確認してください。
| 確認項目 | 理由 |
|---|---|
| Logged in user | 表示されているユーザーが現在の利用者とは限らないため |
| Last contacted | 状態がいつのものか判断するため |
| Device ID | 同名端末や再登録端末を区別するため |
| Primary user | 運用上の所有者を確認するため |
| グループ割り当て | ユーザー割り当てかデバイス割り当てかを判定するため |
サマリーと詳細リストの数が一時的に合わないことがある
サマリービューと詳細デバイス一覧は、必ず同じタイミングで更新されるとは限りません。集計値と詳細リストの件数が一時的に合わない場合があります。(Microsoft Learn)
この差分を見つけたときは、すぐに不具合と考えるのではなく、レポート生成時刻、フィルター条件、対象プラットフォーム、最新チェックイン時刻を確認します。監査用に記録を残す場合は、画面キャプチャだけでなく、レポートの生成日時も控えておくと後から説明しやすくなります。
Setting 列の値は「参考情報」として扱う
今回のドキュメントで、セキュリティ運用上もっとも注意すべき点が Device-reported values in compliance reports です。
一部のコンプライアンス レポートでは、Setting 列にデバイスが直接報告した値が表示されます。これはカスタム コンプライアンスや Android アプリ構成レポートなどで表示され、なぜ非準拠と判定されたのかを理解する補助情報になります。ただし、Microsoft 公式ドキュメントでは、これらの値はデバイス側ロジック、アプリ、管理者提供スクリプトなどから生成されるものであり、Intune サービスが内容を検証・強制するものではないと説明されています。(Microsoft Learn)
つまり、Setting 列に表示された値を見て、すぐに次のような対応をしてはいけません。
- 表示された URL をそのまま開く
- 表示されたパスを信頼して管理者権限でアクセスする
- 値だけを根拠に端末をワイプする
- 値だけを根拠にユーザーへ懲戒的な連絡をする
- 値を社外チケットやチャットにそのまま貼り付ける
デバイス報告値には、自由入力テキスト、URL、ファイルパス、ユーザーや環境を識別できる情報が含まれる可能性があります。公式ドキュメントでも、Setting 値を管理操作の唯一の根拠にしないこと、必要以上にコピーや共有をしないことが注意されています。(Microsoft Learn)
実務では、次のように扱うのが安全です。
| 画面に表示された内容 | 推奨対応 |
|---|---|
| OS バージョンや暗号化状態 | Intune の別レポートや端末詳細と照合する |
| スクリプトが返した文字列 | スクリプト定義、実行結果、対象グループを確認する |
| URL | クリックせず、必要なら管理者が別経路で検証する |
| ファイルパス | 端末隔離や調査フローに従って確認する |
| ユーザー識別情報 | チケット転記時は最小限にする |
非準拠端末を調べる実務手順
非準拠端末が発生した場合は、やみくもにポリシーを変更せず、原因を切り分ける順番を固定しておくと対応が安定します。
まず全体影響を見る
最初に見るべきなのは、単一端末ではなく全体傾向です。
Reports > Device compliance > Reports > Device compliance で、Compliance status、OS、Ownership などのフィルターを使って影響範囲を確認します。公式ドキュメントでは、Generate report または Generate again を使って現在データを取得する手順が示されています。(Microsoft Learn)
たとえば、非準拠が Windows だけに集中しているなら、Windows 用コンプライアンス ポリシーや Defender 連携、OS バージョン条件を疑います。Android の個人所有端末だけに集中しているなら、Android Enterprise work profile や登録制限、Company Portal の状態を確認します。
次に該当ポリシーを特定する
全体傾向を見たら、Policy compliance または Policies with noncompliant and error devices を確認します。
Microsoft Intune Reports では、Policy compliance report により、ポリシーごとの準拠・非準拠・未評価・対象外・競合のデバイス数を確認できます。Operational レポートの Policy noncompliance report では、非準拠またはエラーのあるポリシーをヘルプデスクや管理者が迅速に確認できます。(Microsoft Learn)
ここで見るべきなのは、非準拠の数だけではありません。次の観点で判断します。
- 直近で変更したポリシーか
- 特定 OS や特定所有形態に偏っているか
- 新規登録端末だけに発生しているか
- エラー状態が多いか
- 競合が出ていないか
最後に設定単位で原因を見る
ポリシーを特定したら、Per-setting status または Settings compliance で設定単位の原因を確認します。
Settings compliance report は、設定名、プラットフォーム、準拠デバイス数、非準拠デバイス数、未評価、対象外、競合などを表示し、さらに詳細へドリルインできます。(Microsoft Learn)
たとえば「Windows の最小 OS バージョン」で非準拠が多い場合は、端末更新の遅れが原因かもしれません。一方、「デバイス暗号化」で非準拠が多い場合は、TPM、BitLocker、ユーザー権限、Autopilot 展開後のタイミングなどを確認します。
Error 状態の扱いと Conditional Access への影響
コンプライアンス設定が Error を返した場合、すぐに非準拠へ変わるとは限りません。
Microsoft 公式ドキュメントでは、コンプライアンス ポリシーの設定が Error を返した場合、最大7日間はデバイスの既存のコンプライアンス状態が維持されると説明されています。その期間内に設定が Compliant または Not compliant と評価されれば、その結果が反映されます。7日後も Error のままなら、デバイスは Not compliant、またはポリシーに猶予期間がある場合は In grace period になります。(GitHub)
この挙動は、Conditional Access を使っている環境では特に重要です。
| 初期状態 | Error 発生後の動き | 実務上の注意 |
|---|---|---|
| Compliant | 最大7日間は既存状態が維持される | すぐにアクセス拒否されない場合がある |
| Compliant から Not compliant に確定 | 確定後にアクセスがブロックされる可能性 | ユーザー通知と修復手順を先に用意する |
| Error が7日以上継続 | Not compliant または In grace period へ移行 | 放置すると一斉ブロックの原因になる |
| Not compliant から Error | 非準拠状態が続く場合がある | Error になっても自動的に救済されるとは限らない |
管理者は、Error を「一時的な不明状態」として放置するのではなく、次の観点で確認します。
- どの設定が Error か
- 同じ OS や同じモデルで集中しているか
- カスタム コンプライアンス スクリプトの失敗か
- デバイス チェックインが止まっていないか
- 7日を超える前にユーザー対応が必要か
「デバイス全体の準拠」と「ポリシー内の準拠」を混同しない
Intune のコンプライアンス調査でよくある失敗は、Per-setting status で「Compliant」と表示された端末を見て、「この端末は問題ない」と判断してしまうことです。
公式ドキュメントでは、Per-setting status のドリルイン画面に表示される Device compliance 列は、対象ポリシーや対象設定に対する状態ではなく、デバイス全体のコンプライアンス状態を表す場合があると説明されています。つまり、ある設定では準拠していても、別のポリシーで失敗していれば、デバイス全体は非準拠になり得ます。(GitHub)
たとえば、Android のパスワード要件には準拠しているが、最小 OS バージョン要件で非準拠になっているケースがあります。この場合、パスワード設定のレポートだけを見ると「準拠」に見えますが、Conditional Access ではデバイス全体の非準拠によりアクセスが拒否される可能性があります。
原因調査では、次のように画面を横断します。
| 調査したいこと | 見る画面 |
|---|---|
| 端末が全体として準拠か | Device compliance status、Noncompliant devices |
| どのポリシーで失敗しているか | Policy compliance、Policy noncompliance |
| どの設定で失敗しているか | Setting compliance、Per-setting status |
| 最後に状態を送ったタイミング | Last contacted |
| ユーザー起因か端末起因か | Logged in user、Primary user、割り当て方式 |
設定変更として確認すべき項目
今回のドキュメント確認を受けて、すぐに全テナントで設定変更が必要になるわけではありません。ただし、コンプライアンスを Conditional Access と連携している場合は、次の設定を必ず確認してください。
Mark devices with no compliance policy assigned as
もっとも重要なのが、テナント全体の Mark devices with no compliance policy assigned as です。
Microsoft 公式ドキュメントでは、この設定の既定値は Compliant であり、コンプライアンス ポリシーが割り当てられていないデバイスを準拠として扱うと説明されています。一方、Conditional Access と連携する場合は、ポリシー未割り当てデバイスを Not compliant とする設定が推奨されています。(Microsoft Learn)
ただし、既存環境でいきなり Not compliant に変更すると、ポリシー未割り当て端末が一斉に非準拠になり、アクセス拒否につながる可能性があります。変更前に次を実施してください。
- Reports > Device compliance > Reports > Devices without compliance policy を生成する
- 対象デバイスの OS、所有形態、利用部門を確認する
- 必要なコンプライアンス ポリシーを割り当てる
- パイロット グループで Conditional Access の影響を確認する
- ユーザー通知とヘルプデスク手順を準備する
- 本番テナントで設定変更する
Compliance status validity period
Compliance status validity period は、デバイスが受け取ったコンプライアンス ポリシーの状態を指定期間内に報告しない場合、非準拠として扱う設定です。公式ドキュメントでは、既定値は30日で、1日から120日まで構成できると説明されています。(Microsoft Learn)
グローバル環境では、出張者、休眠端末、現場端末、共有端末など、毎日チェックインしないデバイスが存在します。短くしすぎるとアクセス拒否が増え、長くしすぎると実態とかけ離れた準拠状態が残る可能性があります。
判断基準は次のとおりです。
| 環境 | 推奨される考え方 |
|---|---|
| 高セキュリティ部門 | 短めに設定し、端末未接続を早く検知する |
| 一般業務端末 | 既定値を基準に、ヘルプデスク負荷を見て調整する |
| 現場・工場・店舗端末 | ネットワーク接続頻度を踏まえて慎重に設定する |
| 休眠端末が多い環境 | 不要端末の棚卸しと組み合わせて見直す |
Actions for noncompliance
非準拠時のアクションも確認対象です。
Microsoft 公式ドキュメントでは、非準拠時の既定アクションとして「Mark device noncompliant」が自動追加され、削除はできないがスケジュールは調整できると説明されています。また、ユーザーへのメール送信などの追加アクションを構成できます。(Microsoft Learn)
実務では、すぐにブロックするよりも、段階的な対応にしたほうが混乱を避けられます。
| タイミング | アクション例 |
|---|---|
| 0日目 | 非準拠としてマーク、Company Portal で修復手順を表示 |
| 1〜3日目 | ユーザーへメールまたはプッシュ通知 |
| 3〜7日目 | ヘルプデスクまたは部門管理者へ通知 |
| 期限後 | Conditional Access によるアクセス制限、必要に応じて端末対応 |
高リスク端末は即時ブロックが必要な場合もありますが、OS バージョン更新や暗号化完了のようにユーザー操作や再起動が必要な条件では、猶予期間を設けたほうが現実的です。
移行期限・廃止対応で注意すべき点
「Monitor results of your device compliance policies」自体は、特定機能の廃止期限を告知するページではありません。ただし、対象プラットフォームに Android device administrator が含まれているため、Android 管理方式の移行状況は必ず確認すべきです。
Microsoft 公式ドキュメントでは、Android device administrator 管理は非推奨であり、Google Mobile Services にアクセスできるデバイスでは利用できなくなっていると説明されています。また、Google は Android device administrator 管理を2020年に非推奨化し、Intune は GMS にアクセスできる device administrator デバイスのサポートを2024年末で終了すると案内しています。(Microsoft Learn)
Android device administrator が残っている場合は、次の対応を優先してください。
- 新規登録で Android device administrator を使わせない
- Devices > All devices で Android device administrator 端末を抽出する
- 個人所有端末は Android Enterprise personally owned work profile へ移行する
- 会社所有端末は fully managed、dedicated、corporate-owned work profile などの適切な方式を検討する
- 端末移行前にコンプライアンス ポリシーと Conditional Access の影響をテストする
Microsoft は、Android device administrator から personally owned work profile へ移行するために、コンプライアンス設定の Block devices managed with device administrator を使い、対象デバイスを非準拠にしてユーザーを移行フローへ誘導する方法を案内しています。ユーザーは Resolve をタップすると、device administrator の登録解除、work profile への登録、残りのコンプライアンス問題の解消という流れに誘導されます。(Microsoft Learn)
移行時は、即時ブロックではなく猶予期間を設けるのが現実的です。公式ドキュメントでも、Mark device noncompliant のスケジュールを増やすことで、たとえば14日間の猶予を与え、ユーザーがアクセスを失うリスクを抑えながら work profile へ移行できる例が示されています。(Microsoft Learn)
グローバル運用での確認ポイント
グローバル向けに Intune を運用している場合、コンプライアンス レポートは地域ごとに同じ見え方をするとは限りません。管理ポリシーは共通でも、端末の利用実態が異なるためです。
地域ごとの時差とチェックイン遅延を見る
日本時間でポリシーを変更した直後、米国や欧州の端末がまだオフラインであれば、レポートには古い状態が残ります。特にノート PC やモバイル端末は、ユーザーが起動しない限りチェックインしないことがあります。
グローバル展開では、ポリシー変更後の確認タイミングを次のように分けると判断しやすくなります。
| タイミング | 確認内容 |
|---|---|
| 変更直後 | ポリシー保存、割り当て、対象グループの確認 |
| 数時間後 | 早期チェックイン端末のエラー有無 |
| 翌営業日 | 地域別・OS別の非準拠傾向 |
| 数日後 | 長期未チェックイン端末、休眠端末、対象外端末 |
| 月次 | Device compliance trends による傾向レビュー |
所有形態ごとに基準を分ける
会社所有端末と個人所有端末では、同じコンプライアンス条件を適用できない場合があります。たとえば、会社所有 Windows PC では暗号化や Defender の状態を厳格に求める一方、個人所有 Android では work profile 前提で業務データを保護するほうが現実的です。
ポリシーを分ける際は、次の軸で整理します。
- OS
- 所有形態
- 管理方式
- 拠点または国
- 業務リスク
- アクセスするデータの機密度
「全端末に同じ条件」を適用すると、例外対応が増えて運用が破綻しやすくなります。共通ベースラインを作ったうえで、OS と所有形態ごとに最小限の差分を設けるのが現実的です。
ヘルプデスク向けの見方を標準化する
コンプライアンス レポートは、セキュリティ管理者だけでなくヘルプデスクも使います。問い合わせ対応で必要なのは、深い設計情報よりも「どこを見れば原因にたどり着けるか」です。
ヘルプデスク用には、次のような確認順を定義しておくと効果的です。
- ユーザー名またはデバイス名で検索
- Last contacted を確認
- Device compliance が Not compliant か確認
- Policy compliance で失敗ポリシーを確認
- Setting compliance で失敗設定を確認
- Company Portal の表示内容と照合
- 既知の修復手順を案内
- 不明な Setting 値や URL は開かず、管理者へエスカレーション
よくある失敗と回避策
| 失敗しやすい判断 | 問題点 | 回避策 |
|---|---|---|
| 非準拠数だけを見て障害と判断する | チェックイン遅延や集計タイミングの差を無視している | Last contacted と変更日時を併せて見る |
| Setting 列の値をそのまま信頼する | デバイス報告値であり、Intune が内容を検証しているとは限らない | 参考情報として扱い、別レポートで確認する |
| ポリシー単位の Compliant をデバイス全体の Compliant と誤解する | 別ポリシーで非準拠になっている可能性がある | Noncompliant devices と Policy compliance を横断する |
| Mark devices with no compliance policy assigned as を急に Not compliant にする | 未割り当て端末が一斉にアクセス拒否される可能性がある | 事前に Devices without compliance policy を確認する |
| Android device administrator を放置する | GMS あり端末では非推奨・サポート終了済みの管理方式が残る | Android Enterprise などへ移行する |
| 共有端末で表示ユーザーだけを見て対応する | 最後にチェックインしたユーザーが現在利用者とは限らない | デバイス ID、Primary user、サインイン履歴を確認する |
管理者向けチェックリスト
最後に、今回の内容を踏まえて Microsoft Intune 管理者が確認すべき項目をチェックリスト化します。
| チェック項目 | 確認場所 | 完了基準 |
|---|---|---|
| コンプライアンス ポリシー未割り当て端末を確認した | Reports > Device compliance > Devices without compliance policy | 対象端末が把握され、必要なポリシーが割り当て済み |
| Mark devices with no compliance policy assigned as を確認した | Endpoint security > Device compliance > Compliance policy settings | Conditional Access 利用方針と矛盾していない |
| 非準拠端末の主要原因を確認した | Noncompliant devices and settings | OS、所有形態、ポリシー別に原因が分類されている |
| Setting 列の扱いを運用手順に反映した | Setting compliance、カスタム コンプライアンス運用手順 | 値だけで管理操作しないルールが明記されている |
| Error 状態の監視を追加した | Policy compliance、Setting compliance | 7日以上放置される Error を検知できる |
| Android device administrator 端末を棚卸しした | Devices > All devices | 移行対象と例外端末が分かれている |
| ヘルプデスク手順を更新した | 社内ナレッジ、チケットテンプレート | Last contacted、Policy、Setting の確認順が定義済み |
| Conditional Access との関係を確認した | Microsoft Entra Conditional Access、Intune compliance | 非準拠時のブロック条件と通知が説明できる |
まとめ：Intune のコンプライアンス レポートは「原因特定の順番」が重要
Microsoft Intune の「Monitor results of your device compliance policies」で管理者が押さえるべきポイントは、レポート画面の場所だけではありません。重要なのは、コンプライアンス状態がどのタイミングで更新され、どの単位の状態を示しているのかを理解することです。
まずは Devices > Compliance > Monitor で全体像を確認し、次に Policy compliance で失敗しているポリシーを特定し、最後に Setting compliance で原因設定を掘り下げます。カスタム コンプライアンスや Android アプリ構成の Setting 値は参考情報として扱い、値だけを根拠に管理操作をしないことが重要です。
加えて、Conditional Access を使っている環境では、ポリシー未割り当て端末の扱い、非準拠時のアクション、Error 状態の猶予、Android device administrator の残存状況を確認してください。特にグローバル環境では、チェックイン遅延や共有端末のユーザー表示による誤認を前提に、運用手順とヘルプデスク手順を整えることが、不要なアクセス拒否や調査工数の削減につながります。
コメント