Microsoft Intune の「Windows compliance settings in Microsoft Intune」は、Windows デバイスを“準拠”と判定するために使える設定項目を整理した公式リファレンスです。今回確認すべき結論は、2026年7月1日の公式 GitHub 履歴では大規模な設定追加や移行期限の追加ではなく、メタデータ更新が確認できる点です。一方で、実務上の影響は小さくありません。Windows 11、Windows 10、Windows Holographic for Business、Surface Hub を Intune で管理している組織は、BitLocker、Secure Boot、TPM、OS バージョン、Microsoft Defender、Defender for Endpoint、WSL、条件付きアクセスとの連携を改めて点検する必要があります。(GitHub)
Microsoft Intune の Windows compliance settings とは
Microsoft Intune の Windows compliance settings は、Windows デバイスが組織のセキュリティ要件を満たしているかを判定するための設定群です。Intune 管理センターで Windows 10 以降向けのコンプライアンスポリシーを作成すると、OS バージョン、BitLocker、Secure Boot、コード整合性、TPM、ファイアウォール、ウイルス対策、Microsoft Defender for Endpoint のリスクスコアなどを条件として指定できます。(Microsoft Learn)
ここで重要なのは、コンプライアンスポリシーは設定を強制適用する機能ではなく、条件を満たしているかを評価する機能だという点です。たとえば「BitLocker を必須」にしただけでは、BitLocker を有効化する構成プロファイルの代わりにはなりません。BitLocker を有効化する設定は構成プロファイルやエンドポイントセキュリティポリシーで配布し、コンプライアンスポリシーでは「有効になっているか」を判定します。
Microsoft Entra Conditional Access と組み合わせると、準拠していないデバイスから Microsoft 365 や業務アプリへのアクセスをブロックできます。Microsoft 公式ドキュメントでも、Intune の準拠状態は Microsoft Entra ID に報告され、条件付きアクセスの「Require device to be marked as compliant」でアクセス制御に使えると説明されています。(Microsoft Learn)
2026年7月1日の更新ポイント
2026年7月1日の GitHub 履歴では、MicrosoftDocs/memdocs リポジトリで「Metadata updates (#20499)」というコミットがあり、対象ファイルの一つとして intune/device-security/compliance/ref-windows-settings.md が含まれています。差分を見る限り、このファイルでは ms.collection などのメタデータ整理が行われており、Windows compliance settings の設定項目そのものが追加・削除された変更ではありません。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 対象ドキュメント | Windows compliance settings in Microsoft Intune |
| 対象サービス | Microsoft Intune |
| 2026年7月1日の確認内容 | GitHub 上でメタデータ更新を確認 |
| 設定項目への直接影響 | 大きな追加・削除は確認できない |
| 移行期限 | この更新に伴う新たな移行期限は確認できない |
| 管理者が見るべき点 | 既存の Windows 準拠ポリシーが現在の運用・OS 更新・条件付きアクセス設計と合っているか |
つまり、今回の更新は「新機能が追加されたので急いで設定を変える」という類のものではありません。ただし、公式リファレンスの整理をきっかけに、既存の Windows コンプライアンスポリシーを棚卸しする価値はあります。特に、条件付きアクセスと連携している環境では、準拠判定の設計ミスがそのまま業務アプリへのアクセス可否に影響します。
影響範囲：Windows だけでなく HoloLens と Surface Hub も対象
公式ドキュメントでは、この Windows compliance settings の対象として、Windows、Windows Holographic for Business、Surface Hub が示されています。Windows Holographic for Business と Surface Hub は通常の PC と同じように扱える部分もありますが、サポートされる設定には制限があります。(Microsoft Learn)
| 対象 | 主な確認ポイント |
|---|---|
| Windows 10 / Windows 11 | OS バージョン、BitLocker、Secure Boot、TPM、Firewall、Defender、Defender for Endpoint のリスクスコア |
| Windows Holographic for Business | デバイス暗号化など、対応設定が限定される点 |
| Surface Hub | Microsoft Entra 参加、Intune 登録、条件付きアクセス連携の可否 |
| 共同管理デバイス | Configuration Manager Compliance の評価対象になるか |
Surface Hub については、Windows Team OS を実行する Surface Hub では Microsoft Defender for Endpoint とパスワードのコンプライアンスポリシーが現時点でサポートされないため、該当設定は既定の Not configured にするよう公式ドキュメントで案内されています。(Microsoft Learn)
グローバル企業では、会議室端末、HoloLens、共有端末、キオスク端末などが同じ Intune テナントに混在しがちです。PC 向けの厳格なポリシーをそのまま特殊デバイスへ割り当てると、意図しない非準拠やアクセスブロックにつながる可能性があります。
設定変更で特に確認すべき領域
Windows compliance settings は項目数が多いため、すべてを同じ重要度で見ると運用が複雑になります。まずは、アクセス制御やヘルプデスク問い合わせに直結しやすい項目から確認するのが現実的です。
OS バージョン管理：最小・最大・有効なビルド範囲を使い分ける
Windows compliance settings では、最小 OS バージョン、最大 OS バージョン、モバイルデバイス向け OS 要件、有効な OS ビルド範囲を指定できます。特に「Valid operating system builds」は、複数の Windows リリースに対して許可するビルド範囲を設定できるため、単純な最小バージョン指定より柔軟です。(Microsoft Learn)
実務では、次のように使い分けると管理しやすくなります。
| 目的 | 推奨する考え方 |
|---|---|
| 古い OS を排除したい | Minimum OS version を使う |
| 未検証の新ビルドを一時的に止めたい | Maximum OS version を慎重に使う |
| Windows 10 / Windows 11 の複数バージョンを許可したい | Valid operating system builds を使う |
| パッチレベルを厳密に管理したい | 月次更新の検証後に許可範囲を更新する |
注意点は、最大 OS バージョンを厳しく設定しすぎると、新しい Windows 更新を適用した端末が非準拠になり、業務アプリへアクセスできなくなる可能性があることです。最大値は「新バージョンを絶対に止めたい」明確な理由がある場合に限定し、通常は最小バージョンや有効なビルド範囲を中心に設計する方が安全です。
また、複数の OS ビルド範囲を指定した場合、Company Portal の修復メッセージには技術的制約により最初の範囲だけが表示されることがあります。許可する Windows ビルド範囲は、社内ポータルやヘルプデスク手順書にも明記しておくと、ユーザー対応がスムーズになります。(Microsoft Learn)
BitLocker と暗号化：似た設定を混同しない
Windows compliance settings には、BitLocker を要求する設定と、データストレージの暗号化を要求する設定があります。どちらも暗号化に関係しますが、評価の仕組みが同じではありません。
公式ドキュメントでは、データストレージ暗号化の設定はデバイス上の暗号化の存在を汎用的に確認するもので、現在 Intune がサポートする暗号化チェックは BitLocker のみと説明されています。一方、より堅牢な確認には、TPM レベルで BitLocker 状態を検証する Require BitLocker の利用が案内されています。(Microsoft Learn)
実務上は、次のように考えると分かりやすいです。
| 設定 | 役割 | 注意点 |
|---|---|---|
| Require BitLocker | BitLocker 状態を Device Health Attestation で評価 | 評価は起動時に測定されるため、暗号化後に再起動が必要になる場合がある |
| Encryption of data storage on a device | デバイスのデータストレージ暗号化を確認 | より厳密な BitLocker 検証には Require BitLocker を検討 |
よくある失敗は、BitLocker を有効化するポリシー配布直後にコンプライアンスポリシーを厳しくし、暗号化完了や再起動前の端末を大量に非準拠にしてしまうケースです。新規展開時は、構成プロファイルで BitLocker を有効化し、状態が安定してから準拠判定と条件付きアクセスに接続する流れが安全です。
Secure Boot、コード整合性、TPM：古い端末の洗い出しに使う
Device health では、Secure Boot、コード整合性、BitLocker などを評価できます。Secure Boot は信頼された状態で起動することを確認し、コード整合性はドライバーやシステムファイルの整合性を検証します。TPM については、TPM バージョンが存在するかを準拠条件として確認できます。(Microsoft Learn)
ここで気を付けたいのは、古い端末や特殊なハードウェアを含む環境です。公式ドキュメントでは、Secure Boot の要求設定は一部の TPM 1.2 および 2.0 デバイスでサポートされ、TPM 2.0 以降をサポートしないデバイスではポリシーステータスが Not Compliant と表示される場合があると説明されています。(Microsoft Learn)
いきなり全社に適用するのではなく、次の順序で進めると失敗を減らせます。
| 手順 | 実施内容 |
|---|---|
| 事前調査 | Intune のデバイス一覧で OS、モデル、TPM、暗号化状態を確認 |
| パイロット | IT 部門や代表部門の端末に限定して評価 |
| 除外設計 | 古い端末、共有端末、検証端末を一時的に除外 |
| 調達基準反映 | 新規 PC の要件に TPM 2.0、Secure Boot、Windows 11 対応を明記 |
| 条件付きアクセス連携 | 非準拠時の影響を確認してから段階的に適用 |
ファイアウォール：グループポリシーとの競合に注意する
Windows Firewall を Require にすると、Windows Firewall が有効であり、ユーザーが無効化できないことを準拠条件として扱えます。ただし、既存のグループポリシーでファイアウォールを無効化したり、すべての受信トラフィックを許可したりしている場合、Intune 側で有効化する構成を配布していても、コンプライアンス評価では Not compliant になる可能性があります。公式ドキュメントでも、グループポリシーが Intune ポリシーを上書きするケースが説明されています。(Microsoft Learn)
ハイブリッド環境では、Intune の設定だけを見て「有効にしているはず」と判断しないことが重要です。Active Directory の GPO、セキュリティベースライン、ローカル設定、サードパーティ製セキュリティ製品が競合していないかを確認してください。
Microsoft Defender と Defender for Endpoint：準拠判定をアクセス制御に使う
Windows compliance settings では、Microsoft Defender Antimalware、セキュリティインテリジェンスの更新状態、リアルタイム保護などを確認できます。また、Microsoft Defender for Endpoint と統合している場合は、デバイスのマシンリスクスコアを準拠条件として使えます。(Microsoft Learn)
Defender for Endpoint のリスクスコア設定では、Clear、Low、Medium、High などのしきい値を選べます。厳しくするほどセキュリティは高まりますが、検知発生時に業務アプリへのアクセスが止まりやすくなります。最初から Clear を全社適用するのではなく、まずは Low または Medium を基準にし、検知内容、部門影響、復旧手順を見ながら調整するのが現実的です。
条件付きアクセスと組み合わせるときの注意点
Microsoft Intune のコンプライアンスポリシーは、条件付きアクセスと連携して初めて強いアクセス制御になります。Microsoft 公式ドキュメントでは、デバイスが Intune に登録されると Microsoft Entra ID に登録され、準拠状態が Microsoft Entra ID に報告されるため、条件付きアクセスがその状態を使ってアクセスを許可またはブロックできると説明されています。(Microsoft Learn)
ただし、ここで設計ミスが起きると影響が大きくなります。特に確認すべきなのは、テナント全体の「Mark devices with no compliance policy assigned as」です。この設定は、コンプライアンスポリシーが割り当てられていないデバイスを Compliant と見なすか、Not compliant と見なすかを決めます。既定では Compliant ですが、条件付きアクセスを使う場合は Not compliant にすることが推奨されています。(Microsoft Learn)
| 設定 | 意味 | 実務上の判断 |
|---|---|---|
| Compliant | ポリシー未割り当て端末も準拠扱い | 検証環境や初期導入では扱いやすいが、本番のアクセス制御では抜け道になりやすい |
| Not compliant | ポリシー未割り当て端末を非準拠扱い | 条件付きアクセスと組み合わせる本番環境では基本的にこちらを検討 |
本番環境で Not compliant に変更する場合は、事前に「Devices without compliance policy」レポートを確認してください。ポリシー未割り当て端末が多い状態で切り替えると、想定外のアクセスブロックが発生します。
管理者が確認すべき実務チェックリスト
今回の公式情報を受けて、Microsoft Intune 管理者は次の順番で点検すると効率的です。
| 確認項目 | 具体的な確認内容 | 優先度 |
|---|---|---|
| ポリシー割り当て | Windows 端末に適切なコンプライアンスポリシーが割り当てられているか | 高 |
| 未割り当て端末 | Devices without compliance policy に端末が残っていないか | 高 |
| OS バージョン | Windows 10 / Windows 11 の許可ビルド範囲が現行の更新運用と合っているか | 高 |
| BitLocker | 暗号化構成と準拠判定が両方設計されているか | 高 |
| Secure Boot / TPM | 古い端末や特殊端末が大量に非準拠にならないか | 中 |
| Firewall | GPO と Intune ポリシーが競合していないか | 中 |
| Defender | リアルタイム保護、定義更新、MDE リスクスコアのしきい値が妥当か | 高 |
| Surface Hub / HoloLens | PC 向けポリシーをそのまま割り当てていないか | 中 |
| 条件付きアクセス | 非準拠時にどのアプリがブロックされるか把握しているか | 高 |
| ユーザー通知 | 非準拠時のメール、Company Portal 表示、問い合わせ先が整備されているか | 中 |
特に「ポリシー未割り当て端末」「OS ビルド範囲」「BitLocker の再起動待ち」「Defender for Endpoint のリスクスコア」は、運用トラブルに直結しやすい項目です。
非準拠時の運用設計も同時に見直す
コンプライアンスポリシーを強化するだけでは、現場は回りません。非準拠になったデバイスに対して、ユーザーが何をすればよいか、管理者がどのレポートを見るべきかを決めておく必要があります。
Intune では、非準拠時のアクションとして、デバイスを非準拠としてマークする、ユーザーへ通知メールを送る、一定期間後にリモートロックやリタイアを行うといった設定が可能です。Microsoft 公式ドキュメントでも、非準拠時のアクションやメール通知、スケジュール設定について説明されています。(Microsoft Learn)
おすすめは、いきなりブロックするのではなく、次の段階を踏むことです。
| フェーズ | 実施内容 |
|---|---|
| 可視化 | まずはコンプライアンスレポートで影響端末を把握する |
| 通知 | ユーザーに修復手順と期限を知らせる |
| 猶予 | OS 更新、BitLocker 暗号化、Defender 修復に必要な期間を設ける |
| 制御 | 条件付きアクセスで重要アプリから段階的に保護する |
| 定着 | 月次更新、端末交換、例外申請の運用に組み込む |
Microsoft 公式ドキュメントでは、Intune の準拠レポートで全体の準拠状態、個別設定の状態、個別ポリシーの状態、デバイス単位の詳細を確認できると説明されています。特に Windows compliance settings を調整した後は、ポリシー単位の「Per-setting status」を見ると、どの設定が非準拠を生んでいるかを特定しやすくなります。(Microsoft Learn)
移行期限はあるのか
今回確認した 2026年7月1日のメタデータ更新に関して、Windows compliance settings の設定変更に伴う新たな移行期限は確認できません。したがって、管理者が直ちに移行作業を行う必要がある更新ではありません。(GitHub)
ただし、移行期限がないからといって放置してよいわけではありません。Windows 10 / Windows 11 のライフサイクル、月次更新、セキュリティベースライン、Defender for Endpoint の運用、条件付きアクセス設計は継続的に変わります。コンプライアンスポリシーは一度作って終わりではなく、少なくとも四半期ごと、または Windows の機能更新・セキュリティ基準変更のタイミングで見直すべきです。
よくある失敗と回避策
コンプライアンスポリシーを構成プロファイルの代わりにしてしまう
コンプライアンスポリシーは「状態を評価する」機能です。BitLocker、Firewall、Defender の有効化そのものは、構成プロファイル、エンドポイントセキュリティポリシー、セキュリティベースラインなどで別途設計してください。
最大 OS バージョンを厳しくしすぎる
Maximum OS version を使うと、想定より新しい Windows ビルドが非準拠になります。パッチ展開のスピードが速い組織では、最大バージョン指定が運用の足かせになることがあります。利用する場合は、検証リングや例外グループを用意してから適用しましょう。
条件付きアクセスを先に強制してしまう
準拠ポリシーを作成した直後に条件付きアクセスでブロックすると、暗号化待ち、再起動待ち、ポリシー未受信、レポート反映待ちの端末まで業務停止になる可能性があります。Microsoft 公式ドキュメントでも、Intune はデバイスのチェックイン時に準拠状態を評価し、ユーザーは Company Portal から同期してポリシー更新を確認できると説明されています。(Microsoft Learn)
共有端末や特殊端末を通常 PC と同じ扱いにする
Surface Hub、HoloLens、キオスク、共有 PC は、通常のユーザー端末と同じ準拠条件にすると失敗しやすい領域です。対象デバイスの用途ごとにグループを分け、割り当てる設定を最小限から始める方が安全です。
次に管理者が取るべきアクション
まず、Intune 管理センターで Endpoint security > Device compliance を開き、Windows 向けコンプライアンスポリシーの割り当て、非準拠端末、未割り当て端末を確認してください。次に、Windows compliance settings の中でも、OS バージョン、BitLocker、Secure Boot、TPM、Firewall、Defender、Defender for Endpoint のリスクスコアを重点的に見直します。
今回の 2026年7月1日の更新は、設定項目の大幅変更ではなくメタデータ整理として見るのが妥当です。しかし、Windows compliance settings は条件付きアクセスと結びつくと、単なるレポートではなく業務アプリへの入口を制御する重要な判断材料になります。新機能の有無だけを見るのではなく、「自社の Windows 端末をどの状態なら信頼できると判断するのか」を明文化し、構成プロファイル、コンプライアンスポリシー、条件付きアクセス、ユーザー通知を一体で設計することが重要です。
コメント