Microsoftは2026年5月のIntuneサービスリリースで、見逃しやすいコンプライアンスレポートの明確化を静かに発表しました。しかし、組織でカスタムコンプライアンスポリシーやAndroidアプリ構成レポートを使用している場合、何が変更されたか、そしてセキュリティ態勢にとってなぜ重要なのかを正確に理解しておく必要があります。

要約: コンプライアンスレポートのデバイス報告値は参考情報であり、権威ある情報ではありません。 実際に何を意味するのかを説明します。

何が変更されたか

2026年5月18日の週の更新で、Microsoftは特定のコンプライアンスレポートに表示される設定列の解釈方法について、管理者がどう考えるべきかを文書化しました。この列にはデバイス自身が報告した値が直接表示されます。Microsoftのガイダンスは現在、これらを参考情報のみとして扱うべきだと明記し、デバイス報告データを確認するための新しいセキュリティ考慮事項を追加しました。

影響を受けるシナリオは次のとおりです:

  • カスタムコンプライアンスポリシー — PowerShellスクリプトや他のプローブがデバイス状態を収集し、評価のためにIntuneに値を返すもの
  • Androidアプリ構成レポート — 管理対象アプリがコンプライアンス関連レポートに表示される構成データを返すもの

この区別が重要な理由

これは単なるドキュメントの整理ではありません。Microsoftが組織にコンプライアンスアーキテクチャにおける信頼境界についてどう考えるかを求めているシグナルです。

重要なアーキテクチャは次のとおりです: Intuneはコンプライアンス評価者です。ポリシーを展開し、デバイスシグナルを収集し、評価を実行し、Microsoft Entra IDのデバイスオブジェクトにバイナリのisCompliantフラグを書き込みます。Conditional Accessはアクセス決定を行う際にこのフラグを読み取ります — 認証時にデバイスへ直接問い合わせることはありません。

設定列のデバイス報告値は、その評価中にデバイスが主張した生のクレームです。Intuneが独自に検証したものではなく、デバイスが報告した内容です。

なぜ重要なのか? 侵害されたデバイスは理論上、偽造された値を返す可能性があります。権威あるコンプライアンスシグナルはサーバー側の評価結果であり、デバイスの自己報告データではありません。これらの値が参考情報であることを明確化することで、Microsoftは重要な原則を強化しています: デバイスが自身のコンプライアンス状態を正確に報告することは信頼できない。

組織が取るべき対応

カスタムコンプライアンスポリシーを使用している場合:

  • レポートに表示されるスクリプトの戻り値は、コンプライアンスの証明ではなく診断コンテキストです
  • スクリプトを見直し、意味のあるなりすまし困難なシグナルを測定しているか確認してください
  • 異常なデバイス報告値は、Defender for Endpointの脅威レベル、Entraのリスクスコア、ハードウェア構成証明データなど他のシグナルと照合してください
  • コンプライアンス態勢のどの部分がデバイス報告データに依存し、どの部分がサーバー評価シグナルに依存しているかを文書化してください

Androidアプリ構成レポートを使用している場合:

  • レポート内のアプリ返信構成データはデバイス状態の把握に役立ちますが、コンプライアンス決定はIntuneの評価エンジンに属します
  • サーバー側の裏付けなしに、これらの値をアクセスポリシー決定の主要シグナルとして使用しないでください

すべての環境について:

  • 異常なデバイス報告値を合格/不合格の判定ではなく、調査のトリガーとして扱ってください
  • スクリプトベースのカスタムコンプライアンスを補完するため、ハードウェア構成証明(TPM対応シグナル、デバイス正常性構成証明)の階層化を検討してください
  • Conditional Accessポリシーがアプリレベルの回避策ではなく、EntraのisCompliantフラグを通じてコンプライアンスを強制していることを確認してください

変更されていないこと

この更新で変更されないことを明示しておきましょう:

  • コンプライアンス強制は引き続き同じ方法で機能します。 Intuneがコンプライアンスを評価し、結果をEntra IDに書き込み、Conditional Accessがそれを読み取ります。パイプラインは変更されていません。
  • カスタムコンプライアンスポリシーは引き続き正常に機能します。 スクリプトは引き続き実行され、出力は評価され、コンプライアンス状態はEntraに書き込まれます。Microsoftが求めているのは、生の報告値を絶対的な真実ではなくコンテキストとして扱うことだけです。
  • Androidアプリ構成ポリシーは影響を受けません。 ポリシー自体、その展開、強制動作は変更されていません。

全体像

この更新は、Microsoftがゼロトラストストーリーを強化するより広範なパターンの一部です。ゼロトラストの「決して信頼せず、常に検証する」原則はデバイスにも適用されます — 管理対象デバイスも同様です。Microsoftが構築したコンプライアンスアーキテクチャは、デバイス信頼を複数層のサーバー側評価を通じてルーティングします。自己報告されるデバイスデータが弱点だからです。

これを文書で明示することで、Microsoftは組織に対してコンプライアンスプログラムをより慎重に考えるよう促しています。カスタムコンプライアンススクリプトは本当に偽造困難なシグナルを測定していますか? 複数のシグナルを階層化していますか? Conditional Accessポリシーは適切な制御を強制していますか?

成熟した環境の多くは「はい」と答えるでしょう — しかし、これはコンプライアンスポリシーを監査し、ゼロトラスト制御が意図どおり機能しているか(管理センターで緑色表示されているだけでなく)確認する良い契機です。

このガイダンスはまた、Microsoftのデバイス正常性構成証明への継続的投資や、Intune、Defender for Endpoint、Entra ID Conditional Access間のより深い統合にもつながっています。方向性は明確です: より多くのサーバー側検証、より多くの階層化されたシグナル、デバイスが自身について語る内容への依存はより少なく。

Intuneの変更についてサポートが必要ですか? Big Hat Groupは組織のMicrosoft Intune環境の設計、展開、管理を支援します — コンプライアンスポリシーアーキテクチャからゼロトラスト戦略まで。カスタムコンプライアンスポリシーの構築でもConditional Access制御の強化でも、私たちが適切にサポートします。こちらからお問い合わせください。

Big Hat Groupはモダンエンドポイント管理、Microsoft Intune、Microsoft 365展開を専門とするMicrosoftパートナーです。