Microsoft Intune の「カスタム コンプライアンス設定」は、標準のコンプライアンスポリシーだけでは判定できない Windows / Linux デバイスの状態を、JSON ファイルと検出スクリプトで評価できる機能です。結論から言うと、管理者がまず確認すべきなのは「対象 OS」「JSON とスクリプトの対応関係」「Conditional Access への影響」「レポート値の扱い」「Linux のサポートバージョン」です。
特に、Linux 端末を Intune 管理に含めている組織や、Windows 端末で BIOS、TPM、独自エージェント、社内セキュリティ設定などを条件にアクセス制御したい組織では、今回の公式情報をもとに設計を見直す価値があります。カスタム コンプライアンス設定は「検出」はできますが「修復」は自動で行いません。ユーザーに何を直してもらうか、管理者がどのレポートを信頼するかまで決めておくことが重要です。なお、対象の Microsoft Learn ページ上では最終更新日が 2026年5月20日と表示されているため、本稿では 2026年7月1日時点で確認すべき公式情報として整理します。(Microsoft Learn)
Microsoft Intune のカスタム コンプライアンス設定とは
Microsoft Intune のカスタム コンプライアンス設定は、Intune に標準搭載されているデバイス コンプライアンス項目を補完する仕組みです。標準ポリシーにない設定でも、管理者が用意した検出スクリプトで端末状態を取得し、JSON ファイルで定義した条件と照合して、デバイスを「準拠」または「非準拠」として評価できます。(Microsoft Learn)
たとえば、次のような要件に向いています。
| 判定したい内容 | 標準ポリシーだけでは足りない理由 | カスタム コンプライアンスでの考え方 |
|---|---|---|
| BIOS バージョンが社内基準以上か | 機種別の細かい基準を標準項目で表現しにくい | PowerShell で BIOS バージョンを取得し、JSON で最小バージョンを指定する |
| TPM が有効か | 標準項目と社内監査項目を合わせて見たい | TPM の状態をスクリプトで返し、Boolean で評価する |
| 特定の社内エージェントが存在するか | 独自ツールは Intune 標準テンプレートにない | ファイル、サービス、プロセスなどを検出して準拠条件にする |
| Linux の特定設定が基準を満たすか | Linux の管理項目は Windows より限定されやすい | POSIX 準拠シェルスクリプトなどで値を取得し、JSON でルール化する |
重要なのは、カスタム コンプライアンス設定は「設定を適用する機能」ではなく「状態を判定する機能」だという点です。非準拠になった端末を自動修復したい場合は、構成プロファイル、スクリプト配布、Endpoint Privilege Management、社内手順書など、別の仕組みと組み合わせる必要があります。
今回確認すべき主な更新ポイント
今回の公式情報で管理者が押さえるべきポイントは、単に「カスタム項目を追加できる」ことではありません。実務上は、サポート対象、評価タイミング、レポートの読み方、移行が必要な Linux バージョンの有無を確認する必要があります。
| 確認項目 | 管理者への影響 | 取るべき対応 |
|---|---|---|
| 対象プラットフォーム | Windows と一部 Linux ディストリビューションが対象 | 管理対象 OS が対応範囲内か棚卸しする |
| JSON と検出スクリプトが必須 | どちらか一方だけでは機能しない | 設定名、データ型、戻り値を事前に設計する |
| Conditional Access に影響 | 非準拠判定がアクセスブロックにつながる | 本番適用前にパイロットグループで検証する |
| レポート値は端末側が報告 | スクリプトが返した値を Intune が完全検証するわけではない | レポート値だけを根拠に強い管理判断をしない |
| RHEL 8 の扱い | Linux 管理環境では移行計画が必要 | RHEL 9 または RHEL 10 への移行対象を確認する |
カスタム コンプライアンス設定は、組織のセキュリティ基準を Intune の標準項目に合わせるのではなく、Intune 側に社内基準を持ち込める点が強みです。一方で、設計を誤ると「本来ブロックすべき端末が準拠になる」「ユーザーが突然アクセスできなくなる」「レポートの値を過信して誤対応する」といった問題につながります。
影響範囲：対象 OS とクラウド要件
公式情報では、カスタム コンプライアンス設定の対象として Windows と Linux が示されています。Windows は Windows Home を除く Windows が対象です。Linux では Ubuntu Desktop 24.04 LTS / 26.04 LTS、Red Hat Enterprise Linux 9 / 10 が対象として示されています。(Microsoft Learn)
| 区分 | 対象 | 注意点 |
|---|---|---|
| Windows | Windows Home を除く Windows | PowerShell スクリプトを利用する |
| Linux | Ubuntu Desktop 24.04 LTS / 26.04 LTS | Linux 用の検出スクリプトと JSON が必要 |
| Linux | Red Hat Enterprise Linux 9 / 10 | RHEL 8 利用環境は移行計画を確認する |
| クラウド参加状態 | Microsoft Entra joined、Microsoft Entra hybrid joined、Microsoft Entra registered / Workplace joined | WPJ 端末ではユーザーコンテキストの PowerShell スクリプトが無視される点に注意 |
Windows の BYOD や Workplace Join 端末を含めている組織では、スクリプトの実行コンテキストに注意が必要です。公式情報では、WPJ デバイスではデバイスコンテキストの PowerShell スクリプトは動作する一方、ユーザーコンテキストの PowerShell スクリプトは無視されると説明されています。(Microsoft Learn)
実務では、次のように判断すると安全です。
| 管理シナリオ | 推奨判断 |
|---|---|
| 会社支給 Windows 端末を厳格に判定したい | Microsoft Entra joined または hybrid joined を前提に、デバイスコンテキストで検出する |
| BYOD Windows 端末も対象にしたい | WPJ でユーザーコンテキストが使えない前提で、取得できる値を限定して設計する |
| Linux 端末を対象にしたい | 対応ディストリビューションと Intune アプリの状態を先に確認する |
| グローバル拠点で利用する | RemediationStrings に en_US を必ず含め、日本語や現地語も追加する |
設定変更の要点：JSON と検出スクリプトを分けて設計する
カスタム コンプライアンス設定は、主に次の2つで構成されます。
| 構成要素 | 役割 | 失敗しやすいポイント |
|---|---|---|
| 検出スクリプト | デバイス上で設定値を取得し、Intune に返す | 戻り値の形式が JSON と一致しない、実行時間が長い、権限不足で値が取れない |
| JSON ファイル | どの値を、どの条件で準拠とするか定義する | SettingName の大文字小文字違い、DataType の不一致、ユーザー向け修復メッセージ不足 |
Windows では PowerShell スクリプトを使い、Linux では POSIX 準拠のシェルスクリプトを使います。公式情報では、各コンプライアンスポリシーが利用できるスクリプトは1つですが、1つのスクリプトで複数の設定を検出できると説明されています。(Microsoft Learn)
JSON で必ず意識すべき項目
JSON ファイルでは、少なくとも次の項目を正しく設計します。
| 項目 | 内容 | 実務上の注意 |
|---|---|---|
| SettingName | 判定対象の設定名 | 大文字小文字が区別されるため、スクリプトの戻り値と完全一致させる |
| Operator | 比較条件 | IsEquals、GreaterEquals など、対応演算子の範囲で設計する |
| DataType | 値の型 | Boolean、String、Version などを実データに合わせる |
| Operand | 準拠とみなす値 | バージョン比較では文字列ではなく Version を検討する |
| MoreInfoUrl | ユーザー向け詳細ページ | 社内ナレッジや修復手順に誘導する |
| RemediationStrings | 非準拠時の表示文 | en_US は必須。日本語環境では ja_JP も用意する |
公式情報では、JSON ポリシーは最大 100 KB、ルールは最大 100 個までとされています。また、対応する演算子として IsEquals、NotEquals、GreaterThan、GreaterEquals、LessThan、LessEquals が示され、DataType には Boolean、Int64、Double、String、DateTime、Version が含まれます。(Microsoft Learn)
JSON の簡易例
以下は、BIOS バージョンと TPM の有無を確認する例です。実運用では、機種ごとの BIOS バージョン基準や、ユーザーが参照する社内手順ページを必ず自社環境に合わせてください。
{
"Rules": [
{
"SettingName": "BiosVersion",
"Operator": "GreaterEquals",
"DataType": "Version",
"Operand": "2.3",
"MoreInfoUrl": "https://intranet.example.com/device/bios-update",
"RemediationStrings": [
{
"Language": "en_US",
"Title": "BIOS must be updated to version 2.3 or later. Detected value: {ActualValue}.",
"Description": "Follow the internal BIOS update guide."
},
{
"Language": "ja_JP",
"Title": "BIOS をバージョン 2.3 以上に更新してください。検出値: {ActualValue}",
"Description": "社内の BIOS 更新手順に従って対応してください。"
}
]
},
{
"SettingName": "TPMChipPresent",
"Operator": "IsEquals",
"DataType": "Boolean",
"Operand": true,
"MoreInfoUrl": "https://intranet.example.com/device/tpm",
"RemediationStrings": [
{
"Language": "en_US",
"Title": "TPM must be enabled.",
"Description": "Enable TPM according to your device model guide."
},
{
"Language": "ja_JP",
"Title": "TPM を有効化してください。",
"Description": "端末モデル別の手順に従って TPM を有効化してください。"
}
]
}
]
}設定手順：本番適用前にスクリプトを登録してからポリシーを作成する
カスタム コンプライアンス設定は、いきなりコンプライアンスポリシー画面だけで完結するわけではありません。先に検出スクリプトを Intune に登録し、その後でコンプライアンスポリシーからスクリプトと JSON を選択します。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 検出したい項目を決める | 標準コンプライアンス項目で代替できないか確認する |
| 2 | 検出スクリプトを作成する | Windows は PowerShell、Linux は対応するスクリプトを用意する |
| 3 | スクリプトの戻り値を確認する | JSON の SettingName、DataType と一致しているか確認する |
| 4 | JSON ファイルを作成する | en_US の修復メッセージ、日本語環境なら ja_JP も追加する |
| 5 | Intune 管理センターにスクリプトを登録する | Endpoint security > Device compliance > Scripts から追加する |
| 6 | コンプライアンスポリシーを作成する | Custom Compliance を有効化し、スクリプトと JSON を指定する |
| 7 | パイロットグループに割り当てる | いきなり全社展開せず、数十台単位で検証する |
| 8 | レポートと Conditional Access 影響を確認する | 非準拠時に本当にブロックされる範囲を確認する |
Windows の場合は Custom Compliance を Require にし、事前に登録した検出スクリプトを選択して JSON ファイルをアップロードします。Linux の場合は Settings picker で Custom Compliance を追加し、Require Custom Compliance を True にしたうえで、検出スクリプトとルールファイルを指定します。Linux のコンプライアンスポリシーはユーザーグループではなくデバイスグループへの割り当てが前提になる点も確認が必要です。(Microsoft Learn)
スクリプト設計で失敗しやすいポイント
カスタム コンプライアンス設定で最も多い失敗は、JSON ではなくスクリプト側にあります。スクリプトが正しい値を返せない、値の型が違う、出力が長すぎる、実行権限が足りないといった問題です。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| JSON は正しいのに非準拠になる | SettingName とスクリプトの戻り値名が一致していない | 大文字小文字を含めて完全一致させる |
| エラー 65009 が出る | 不正な JSON として評価されている | スクリプト出力を短くし、JSON 形式を検証する |
| Linux で値が取得できない | ユーザーコンテキストで動作し、昇格が必要な値を読めない | 取得可能な範囲に絞るか、別の管理方式を検討する |
| Windows で期待した値にならない | 32bit / 64bit PowerShell、実行ユーザー、署名要件の違い | スクリプト登録時の実行設定を明示する |
| 一部端末だけ評価が遅い | チェックインや評価サイクルのタイミング | 即時反映を前提にせず、運用手順に待ち時間を含める |
公式情報では、スクリプトは Intune に事前登録し、Windows では PowerShell、Linux では環境に応じたインタープリターを利用できると説明されています。制限として、スクリプトサイズと出力はそれぞれ 1 MB 以下、実行時間は Linux で 5 分以内、Windows で 10 分以内とされています。(Microsoft Learn)
さらに、コンプライアンスポリシー作成に関する公式情報では、検出スクリプトの出力が 2048 文字を超えると切り詰められ、不正な JSON としてエラー 65009 につながる可能性があるとされています。複数項目を1本のスクリプトで検出できるとはいえ、戻り値は必要最小限に絞るべきです。(Microsoft Learn)
Conditional Access への影響：本番適用前に必ず段階展開する
カスタム コンプライアンス設定の結果は、標準のコンプライアンス設定と同じように、デバイスのコンプライアンス状態に影響します。Microsoft Learn では、カスタム コンプライアンス設定を Conditional Access の判断に使えると説明されています。つまり、JSON の条件を満たさない端末は、設計次第でメール、Teams、SharePoint、業務アプリへのアクセスを失う可能性があります。(Microsoft Learn)
そのため、次の順序で展開するのが現実的です。
| フェーズ | 対象 | 実施内容 |
|---|---|---|
| 検証 | IT 管理者のテスト端末 | スクリプト戻り値、JSON 検証、レポート表示を確認する |
| パイロット | 情報システム部門、限定ユーザー | 非準拠時の表示文、修復手順、問い合わせ数を確認する |
| 条件付き展開 | 一部拠点、特定デバイス種別 | Conditional Access の影響を限定して確認する |
| 全体展開 | 全対象デバイス | 例外グループ、緊急解除手順、監査ログ確認を用意して適用する |
特に避けたいのは、初回から Conditional Access の「準拠デバイスを要求」と組み合わせて全社展開することです。スクリプトの小さな不具合でも、アクセス障害として表面化します。最初は「レポートで検知する」運用に近い形で開始し、非準拠理由と修復手順が安定してからアクセス制御に組み込むと安全です。
レポートの見方：端末が報告した値を過信しない
カスタム コンプライアンス設定の結果は、Intune 管理センターのデバイス コンプライアンス レポートで確認できます。非準拠デバイスと設定のレポートでは、OS プラットフォームを選び、対象デバイスや設定単位で状態を確認できます。(Microsoft Learn)
ただし、レポートに表示される「Setting」列などの値は、端末側のスクリプトやアプリケーションが報告した値です。Microsoft Learn では、これらの値は Intune によって検証・強制されるものではなく、文脈情報として扱うべきだと説明されています。外部 URL、ファイルパス、自由記述の値が含まれる可能性もあるため、レポート値だけを根拠に管理操作を行わないよう注意が必要です。(Microsoft Learn)
実務では、次のように扱うと安全です。
| レポート情報 | 使い方 | 避けるべき対応 |
|---|---|---|
| 準拠 / 非準拠の状態 | Conditional Access 影響の確認に使う | 例外理由を確認せず一括ブロックする |
| 検出された ActualValue | トラブルシューティングの手がかりにする | 端末が返した URL をそのまま開く |
| 非準拠の設定名 | 修復手順の案内に使う | スクリプトの正当性確認なしにユーザー責任にする |
| 最終チェックイン日時 | 反映遅延の判断に使う | 直近変更が即時反映されないことを障害扱いする |
また、レポートは端末のチェックインやポリシー更新タイミングに依存します。ポリシーを変更した直後にすべての画面が同時に更新されるとは限らないため、運用手順では「確認する画面」と「待機する時間」を明確にしておく必要があります。
評価サイクルと反映タイミング
Windows デバイスがカスタム コンプライアンス設定を含むポリシーを受け取ると、Intune Management Extension の有無を確認し、必要に応じてインストールします。その後、PowerShell スクリプトのダウンロード、実行、結果のアップロードが行われます。公式情報では、新規または更新された PowerShell スクリプトの確認と、検出スクリプトの実行は 8 時間ごととされています。ユーザーがデバイスで Check Compliance を選択した場合はスクリプト実行が行われますが、その時点で新規または更新されたスクリプトを確認するわけではありません。プッシュ通知でカスタム コンプライアンスをオンデマンド実行することもできません。(Microsoft Learn)
この仕様を踏まえると、管理者は次のような説明をユーザーやヘルプデスクに用意しておくべきです。
| 状況 | 想定される原因 | 案内例 |
|---|---|---|
| 修復したのにまだ非準拠 | 評価サイクル待ち | 「反映まで時間がかかる場合があります。同期後も改善しない場合は連絡してください」 |
| スクリプトを更新したのに結果が変わらない | 端末が新しいスクリプトをまだ取得していない | 「次回のチェックイン後に再評価されます」 |
| Linux ユーザーが改善を確認したい | Intune アプリ側で更新操作が必要 | 「Intune アプリで Refresh を実行してください」 |
| Windows ユーザーが改善を確認したい | Company Portal から同期できる | 「Company Portal で同期を実行してください」 |
「設定を直したのにすぐアクセスできない」という問い合わせは発生しやすいため、非準拠時の修復メッセージには、作業手順だけでなく「反映に時間がかかる場合がある」ことも含めると混乱を減らせます。
トラブルシューティング：まず見るべきエラーコード
カスタム設定が評価されない場合、Microsoft Learn では次のエラーコードが示されています。(Microsoft Learn)
| エラーコード | 意味 | 管理者が確認すべきこと |
|---|---|---|
| 65007 | Script returned failure | スクリプトがエラー終了していないか、例外処理が不足していないか |
| 65008 | Setting missing in the script result | JSON に定義した SettingName がスクリプト出力に含まれているか |
| 65009 | Invalid json for the discovered setting | スクリプト出力が正しい JSON 形式か、出力が長すぎないか |
| 65010 | Invalid datatype for the discovered setting | JSON の DataType と実際の戻り値の型が一致しているか |
Windows では、PowerShell スクリプトの最後に return $hash | ConvertTo-Json -Compress のような形で圧縮された JSON を返す設計が重要です。途中でログや余計な文字列を標準出力に出してしまうと、Intune が戻り値を正しい JSON として解釈できなくなる可能性があります。
Linux では、スクリプトがユーザーコンテキストで実行される点に注意します。公式情報では、Linux の検出スクリプトはユーザーコンテキストで実行され、昇格が必要なシステムレベル設定を確認できない例が示されています。(Microsoft Learn)
移行期限と Linux 管理で確認すべきこと
今回の「カスタム コンプライアンス設定」自体について、公式情報上で新たな強制移行期限が示されているわけではありません。既存の Windows / Linux 向けカスタム コンプライアンス設計をすぐに作り直す必要がある、という内容ではありません。
一方で、Linux 管理環境では RHEL のサポートバージョンを確認する必要があります。Microsoft Intune の新機能情報では、RHEL 9 LTS と RHEL 10 LTS のサポートが示され、RHEL 8 LTS のサポートは 2026年7月に終了すると説明されています。既に登録済みの RHEL 8 デバイスは登録状態を維持するとされていますが、管理者には対応バージョンへのアップグレード通知が推奨されています。(Microsoft Learn)
| 対象 | 期限・状態 | 管理者の対応 |
|---|---|---|
| カスタム コンプライアンス設定そのもの | 公式情報上、新たな移行期限は確認できない | 既存ポリシーの JSON、スクリプト、割り当てを点検する |
| RHEL 8 LTS | 2026年7月に Intune サポート終了予定 | RHEL 9 / 10 への移行計画を作成する |
| RHEL 9 / 10 | サポート対象 | 新規 Linux 管理の標準候補にする |
| Ubuntu Desktop 24.04 / 26.04 LTS | サポート対象 | 端末棚卸しで対象外バージョンを洗い出す |
グローバル企業では、国や拠点ごとに Linux ディストリビューションが異なることがあります。Intune のポリシーを作る前に、デバイス インベントリで OS 名、バージョン、登録状態、利用者、拠点を一覧化し、対応対象と例外対象を分けておくと移行が進めやすくなります。
管理者がすぐ確認すべきチェックリスト
カスタム コンプライアンス設定を導入済み、またはこれから導入する管理者は、次の順番で確認すると効率的です。
| 優先度 | 確認項目 | 判断基準 |
|---|---|---|
| 高 | 対象 OS がサポート範囲内か | Windows Home、対象外 Linux、RHEL 8 が残っていないか |
| 高 | Conditional Access と連動しているか | 非準拠時にどのアプリがブロックされるか把握できているか |
| 高 | JSON とスクリプトの対応が取れているか | SettingName、DataType、戻り値が一致しているか |
| 高 | 非準拠時の修復文が具体的か | ユーザーが読んで次に何をすべきか分かるか |
| 中 | スクリプト出力が短く安定しているか | 余計なログ、長い配列、自由記述を返していないか |
| 中 | レポート値を過信していないか | 端末報告値を補助情報として扱っているか |
| 中 | Linux ポリシーの割り当てが正しいか | デバイスグループに割り当てているか |
| 低 | 多言語対応ができているか | en_US に加え、ja_JP や各拠点言語を用意しているか |
特に優先度が高いのは、Conditional Access との関係です。カスタム コンプライアンス設定は、単なる監査項目ではなく、アクセス制御の入口になり得ます。非準拠判定の影響を把握しないまま全社展開すると、業務アプリへのアクセス障害として表面化します。
実務でのおすすめ設計
カスタム コンプライアンス設定は便利ですが、何でも詰め込むほど運用が難しくなります。おすすめは、1つのポリシーに「同じ目的のルール」だけをまとめることです。
たとえば、次のように分けると、レポート確認や障害切り分けがしやすくなります。
| ポリシー例 | 含める項目 | 分ける理由 |
|---|---|---|
| Windows firmware compliance | BIOS、TPM、Secure Boot 関連 | ハードウェア起因の非準拠として扱いやすい |
| Windows security agent compliance | EDR、VPN、社内エージェント | ソフトウェア配布・修復チームと連携しやすい |
| Linux baseline compliance | 対応ディストリビューション、暗号化、パスワード要件 | Linux 管理者がまとめて確認しやすい |
| Regional exception policy | 特定拠点や特殊端末向け条件 | グローバル標準と例外を混在させない |
逆に、BIOS、EDR、ネットワーク、ユーザー設定、拠点例外を1つのスクリプトと JSON に詰め込むと、非準拠時の原因特定が難しくなります。最初は小さく始め、安定したら範囲を広げる方が安全です。
まとめ：まずは「影響する端末」と「ブロック条件」を確認する
Microsoft Intune のカスタム コンプライアンス設定は、Windows / Linux デバイスに対して、標準項目では表現しにくい社内セキュリティ基準を適用できる強力な仕組みです。JSON ファイルで準拠条件を定義し、検出スクリプトで実際の端末状態を返すことで、BIOS、TPM、社内エージェント、Linux 固有設定などをコンプライアンス判定に組み込めます。
一方で、カスタム コンプライアンスは Conditional Access に影響するため、設計ミスがそのままアクセス障害につながります。管理者は、対象 OS、RHEL 8 の移行要否、JSON とスクリプトの整合性、評価サイクル、レポート値の扱いを確認したうえで、必ずパイロット展開から始めるべきです。
次に取るべき行動は明確です。まず Intune 管理センターで Windows / Linux の対象デバイスを棚卸しし、RHEL 8 や対象外 Linux が残っていないか確認してください。そのうえで、既存または新規のカスタム コンプライアンス ポリシーについて、スクリプト出力、JSON のルール、非準拠時のユーザー案内、Conditional Access のブロック範囲を順番に点検しましょう。
コメント