Microsoft Intune の「Create discovery scripts for custom compliance policy」で重要なのは、カスタム準拠ポリシーを作る前に、端末側で設定値を取得する discovery script と、判定条件を定義する JSON ルールを正しく組み合わせることです。結論として、確認した公式情報の範囲では、この機能に対する廃止や強制的な移行期限は示されていません。影響を受けるのは、Windows または Linux デバイスで独自の準拠条件を評価し、その結果を Microsoft Intune のコンプライアンスポリシーや Conditional Access の判断に使っている管理者です。(Microsoft Learn)
なお、Microsoft Learn の該当ページは確認時点で最終更新日が 2026年5月20日と表示されています。本記事では、2026年7月1日時点で管理者が確認すべき公式仕様として、影響範囲、設定変更の有無、運用上の注意点、次に取るべき確認作業を整理します。(Microsoft Learn)
Microsoft Intune のカスタム準拠 discovery script とは
Microsoft Intune の custom compliance discovery script は、標準の準拠ポリシーだけでは評価できない端末状態を、管理者が用意したスクリプトで取得する仕組みです。
たとえば、次のような条件を確認したい場合に使います。
- 特定の BIOS バージョン以上か
- TPM が有効か
- 社内指定のセキュリティエージェントが存在するか
- Linux デバイスで特定の設定値を確認できるか
- 標準テンプレートにない独自のセキュリティ要件を満たしているか
Microsoft の公式説明では、Windows デバイスでは PowerShell スクリプトを使い、Linux デバイスでは必要なインタープリターが端末にインストールされ、適切に構成されていれば任意の言語のスクリプトを実行できます。スクリプトはカスタム準拠ポリシーの一部としてデバイスに配布され、ポリシー評価時に JSON ファイルで定義された設定値を検出して Intune に返します。(Microsoft Learn)
重要なのは、discovery script は「修復するためのスクリプト」ではなく、「準拠判定に必要な値を返すためのスクリプト」だという点です。非準拠状態を自動修復したい場合は、Intune の Remediations など、検出と修復を分けて実行できる別機能の利用も検討します。Remediations は検出スクリプトと修復スクリプトを組み合わせ、ユーザーが問題に気づく前に一般的なサポート課題を修正するための機能です。(Microsoft Learn)
今回確認すべき更新ポイント
今回のポイントは、単に「スクリプトをアップロードできる」という話ではありません。実務では、スクリプトの出力形式、JSON との名前一致、実行時間、権限、レポートの見方まで含めて設計しないと、意図しない非準拠判定や Conditional Access のブロックにつながります。
| 確認項目 | 管理者が見るべきポイント | 実務上の影響 |
|---|---|---|
| 対象プラットフォーム | Windows と Linux が対象。Windows Home は対象外。Linux は Ubuntu Desktop 24.04 LTS / 26.04 LTS、Red Hat Enterprise Linux 9 / 10 が対象 | 対象外 OS にポリシーを広げても想定通り評価できない |
| スクリプト形式 | Windows は PowerShell。Linux はインタープリターと shebang の準備が重要 | 端末側の実行環境が不足すると準拠評価に失敗する |
| ポリシーとの関係 | 1つの compliance policy には 1つの discovery script だけを指定できる | 複数チェックは 1本のスクリプトにまとめる設計が必要 |
| JSON との整合 | JSON の SettingName とスクリプトの戻り値名を一致させる | 大文字小文字の違いでも評価エラーにつながる |
| 出力形式 | Windows は圧縮された 1行の JSON 出力が必要 | 余計なログ出力や改行があると失敗しやすい |
| 権限 | Linux の discovery script はユーザーコンテキストで実行される | root 権限が必要な設定確認には向かない |
| スコープタグ | スクリプトアップロードのワークフローは scope tags をサポートしない | 既定の scope tag 権限を持つ管理者で作業する必要がある |
| レポート値 | device-reported values は Intune が内容を検証しない | 表示値だけを根拠に管理操作をしない |
Microsoft Learn では、discovery script はポリシー作成前に Intune へ追加する必要があり、各 discovery script は 1つの compliance policy でのみ使用でき、各 compliance policy も 1つの discovery script だけを含められると説明されています。割り当て済みのスクリプトは、ポリシーから外すまで削除できません。(Microsoft Learn)
影響範囲：誰が対応すべきか
今回の内容で特に確認すべきなのは、次のような管理者です。
- Microsoft Intune で Windows または Linux の compliance policy を運用している
- 標準の compliance settings では足りない項目を独自に評価している
- device compliance を Conditional Access の条件に使っている
- グローバル環境で複数 OS、複数言語、複数地域の端末を管理している
- 過去に作成した PowerShell や Linux スクリプトをそのまま流用しようとしている
Microsoft Intune の custom compliance settings は、組み込みの準拠設定にない条件を Windows と Linux の管理対象デバイスで評価するための機能です。評価結果は組み込みの準拠設定と同じように compliance state に影響し、Conditional Access の判断にも使えます。つまり、スクリプトの小さな不備が、ユーザーの Microsoft 365 や社内リソースへのアクセス制御に波及する可能性があります。(Microsoft Learn)
特に注意したいのは、「情報収集だけのつもり」で作ったカスタム準拠設定が、結果としてアクセス制御の条件になってしまうケースです。Conditional Access と組み合わせている環境では、テストグループで十分に検証してから、本番ユーザーや本番デバイスに展開してください。
移行期限や強制変更はあるのか
確認した公式情報の範囲では、「Create discovery scripts for custom compliance policy」自体に対する廃止、移行期限、即時の強制設定変更は示されていません。したがって、すでにカスタム準拠ポリシーを運用している場合でも、期限に追われて一斉移行する類の更新ではありません。(Microsoft Learn)
ただし、期限がないから放置してよいわけではありません。むしろ、次の観点で棚卸しするタイミングです。
| 確認対象 | 見直す理由 |
|---|---|
| 既存の discovery script | 出力形式、実行時間、不要なログ出力、例外処理を確認する |
| JSON ルール | SettingName、DataType、Operator、Operand が実態と合っているか確認する |
| Conditional Access | 非準拠時にどのリソースがブロックされるか確認する |
| 非準拠アクション | いきなりブロックせず、通知や猶予期間を使うべきか判断する |
| 管理者権限 | scope tags 非対応の影響で作成・編集できない管理者がいないか確認する |
| グローバル展開 | en_US と ja_JP など、ユーザー向け説明文の言語を整備する |
特に大規模環境では、カスタム準拠ポリシーを「技術的に作れるか」ではなく、「非準拠になったユーザーが自力で復旧できる説明になっているか」まで確認することが重要です。
対象プラットフォームと前提条件
Microsoft Intune の custom compliance settings は、Windows と Linux を対象にしています。公式情報では、Windows は Windows Home を除くデバイス、Linux は Ubuntu Desktop 24.04 LTS / 26.04 LTS、Red Hat Enterprise Linux 9 / 10 が対象として示されています。(Microsoft Learn)
また、カスタム準拠設定を使うには、discovery script と JSON ファイルの両方を準備する必要があります。スクリプトは端末上で設定値を検出し、JSON はその値が準拠かどうかを判断するルールを定義します。(Microsoft Learn)
| 構成要素 | 役割 | 例 |
|---|---|---|
| Discovery script | 端末上で実際の値を取得して Intune に返す | TPMChipPresent: true、BiosVersion: 2.4 |
| JSON file | 返された値を準拠・非準拠として判定する | TPMChipPresent が true なら準拠 |
| Compliance policy | スクリプトと JSON を組み合わせて対象デバイスに割り当てる | Windows 10/11 向けカスタム準拠ポリシー |
| Conditional Access | compliance state をアクセス制御に利用する | 非準拠デバイスから Exchange Online をブロック |
ライセンス面では、Intune の compliance policy を作成・運用するには Microsoft Intune subscription が必要です。Conditional Access を使う場合は Microsoft Entra ID P1 または P2 が必要と説明されています。(Microsoft Learn)
Discovery script を追加する基本手順
公式手順では、discovery script は compliance policy を作る前に Microsoft Intune admin center へ追加します。管理者は Endpoint security > Device compliance > Scripts > Add に進み、対象プラットフォームを選択してスクリプトを登録します。(Microsoft Learn)
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | Microsoft Intune admin center にサインインする | 必要な権限を持つ管理者で作業する |
| 2 | Endpoint security > Device compliance > Scripts > Add を開く | Windows または Linux を選ぶ |
| 3 | Basics でスクリプト名を入力する | 用途、OS、判定項目が分かる名前にする |
| 4 | Settings で Detection script を追加する | Intune は構文エラーやプログラムエラーを検証しない |
| 5 | Windows の場合は実行オプションを設定する | ユーザー資格情報、署名チェック、64bit PowerShell を確認する |
| 6 | 作成を完了する | compliance policy 作成時に選択できるようになる |
ここで失敗しやすいのは、スクリプトをアップロードしただけで安心してしまうことです。公式ドキュメントでは、Intune はスクリプトの構文やプログラムエラーを検証しないと説明されています。アップロード前に、必ず分離された検証環境で実行結果を確認してください。(Microsoft Learn)
Windows 向け discovery script の設計ポイント
Windows デバイスでは PowerShell スクリプトを使います。公式情報では、Windows の PowerShell script は結果を 1行で返すために、最後の行で ConvertTo-Json -Compress を使う必要があると説明されています。(Microsoft Learn)
実務では、次のような形で「戻り値のプロパティ名」と「JSON の SettingName」を一致させます。
$result = [ordered]@{
TPMChipPresent = $false
SecureBootEnabled = $false
}
try {
$result.TPMChipPresent = (Get-Tpm).TpmPresent
}
catch {
$result.TPMChipPresent = $false
}
try {
$result.SecureBootEnabled = Confirm-SecureBootUEFI
}
catch {
$result.SecureBootEnabled = $false
}
return $result | ConvertTo-Json -Compressこの例では、Intune に返される JSON は次のような 1行の形式になります。
{"TPMChipPresent":true,"SecureBootEnabled":true}注意点は、途中で Write-Host やデバッグ用の文字列を出さないことです。スクリプト出力に余計な文字列が混ざると、Intune 側で JSON として解釈できず、評価エラーにつながります。
また、Windows のスクリプト設定では、既定では System context で実行されます。Run this script using the logged on credentials を Yes にするとサインイン中のユーザーコンテキストで実行されますが、ユーザーがサインインしていない場合は System context に戻ります。64bit PowerShell Host の使用有無も選べるため、レジストリやプログラムファイルの参照先が 32bit / 64bit で変わるスクリプトでは必ず確認してください。(Microsoft Learn)
Linux 向け discovery script の設計ポイント
Linux では、スクリプトの先頭に shebang を入れて、使用するインタープリターを明示します。公式情報では Bash を使う場合は #!/bin/bash、Python を使う場合は #!/usr/bin/python3 または #!/usr/bin/env python3 のように指定する例が示されています。(Microsoft Learn)
たとえば Python を使う場合は、次のように JSON を明示的に出力できます。
#!/usr/bin/env python3
import json
import platform
result = {
"KernelVersion": platform.release()
}
print(json.dumps(result, separators=(",", ":")))Linux で最も見落としやすいのは実行コンテキストです。公式ドキュメントでは、Linux の discovery script はユーザーコンテキストで実行され、昇格が必要なシステムレベル設定は確認できないと説明されています。例として /etc/sudoers の state/hash のような確認は制限に該当します。(Microsoft Learn)
そのため、Linux 向けカスタム準拠では、次の条件を満たす項目から始めると安全です。
- 一般ユーザー権限で読める情報
- 出力が短く安定している情報
- OS バージョン、カーネルバージョン、ユーザー領域の設定など
- 端末ごとの差異が少なく、JSON ルール化しやすい項目
逆に、root 権限が必要なファイル、秘匿情報、ユーザー個人情報、端末ごとに形式が大きく変わる値は避けた方がよいです。
JSON ファイルで必ず合わせる項目
Custom compliance の JSON ファイルでは、スクリプトが返す設定値をどの条件で準拠とみなすかを定義します。公式情報では、正しくフォーマットされた JSON には SettingName、Operator、DataType、Operand、MoreInfoURL、RemediationStrings が必要とされています。SettingName は大文字小文字を区別します。(Microsoft Learn)
| JSON 項目 | 意味 | 実務での注意点 |
|---|---|---|
SettingName | スクリプト出力のキー名 | 大文字小文字まで一致させる |
Operator | 判定方法 | IsEquals、GreaterEquals などを使う |
DataType | 値の型 | Boolean、String、Version などを実態に合わせる |
Operand | 準拠とみなす値 | 文字列と Boolean を混同しない |
MoreInfoURL | ユーザー向けの詳細案内 URL | 社内手順ページを指定すると復旧しやすい |
RemediationStrings | 非準拠時に表示する説明 | 少なくとも en_US が必要。日本語環境では ja_JP も用意する |
JSON には最大 100KB、最大 100ルールという制限があります。サポートされる演算子は IsEquals、NotEquals、GreaterThan、GreaterEquals、LessThan、LessEquals で、データ型は Boolean、Int64、Double、String、DateTime、Version が示されています。(Microsoft Learn)
グローバル環境では、RemediationStrings の言語設計が重要です。公式情報では ja_JP もサポート言語に含まれていますが、en_US は少なくとも 1つ必要です。日本本社と海外拠点の両方に展開するなら、最低限 en_US と ja_JP を用意し、非準拠理由と復旧手順がユーザーに伝わるようにします。(Microsoft Learn)
スクリプト制限と出力サイズで注意すべき点
Discovery script にはサイズと実行時間の制限があります。公式情報では、スクリプトのサイズは 1MB 以下、スクリプト出力も 1MB 以下、実行時間は Linux が 5分以内、Windows が 10分以内と説明されています。(Microsoft Learn)
一方で、compliance policy 作成手順の公式ページでは、discovery script output は 2,048文字に制限され、超過すると切り詰められて invalid JSON となり、エラー 65009 につながる可能性があるとも記載されています。(Microsoft Learn)
実務上は、より厳しい前提で設計するのが安全です。つまり、戻り値は「必要最小限のキーと値だけ」にし、長い配列、ログ、複数行メッセージ、診断情報を含めないようにします。
| 避けるべき出力 | 理由 | 代替案 |
|---|---|---|
| 長いログ全文 | JSON として無効になりやすい | 準拠判定に必要な値だけ返す |
| インストール済みアプリ一覧 | 文字数が膨らみやすい | 特定アプリの有無だけ Boolean で返す |
| URL やファイルパスの羅列 | レポート上の扱いに注意が必要 | 管理者向けログは別手段で収集する |
| 端末固有の詳細情報 | 個人情報・環境情報を含む可能性がある | compliance 判定に不要な情報は返さない |
| 複数行 JSON | Windows では 1行出力が必要 | ConvertTo-Json -Compress を使う |
よくある失敗と原因
カスタム準拠ポリシーは柔軟ですが、失敗パターンも明確です。公式情報では、custom settings が評価されない場合のエラーとして、65007、65008、65009、65010 が示されています。(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 と戻り値の型が合わない | Boolean を文字列 "true" で返していないか確認する |
| スクリプトが選択できない | 画面表示や作成フローの問題 | 画面を更新し、改善しない場合はポリシー作成をやり直す |
| 修正後すぐ準拠にならない | 評価・同期タイミングの問題 | 最大 8時間程度の遅延を考慮する |
特に多いのは、PowerShell で Boolean を返しているつもりが文字列になっているケースです。JSON 側で DataType を Boolean にしているなら、スクリプト出力も true / false の Boolean として返す必要があります。
レポート値をそのまま信用しすぎない
2026年の Intune 管理では、compliance report の見方も重要です。Microsoft は、compliance report の Setting column に表示される device-reported values は、custom compliance や Android app configuration reporting などで追加の文脈を示すものだと説明しています。ただし、その値はデバイス側のロジックや管理者が用意したスクリプトから報告されるもので、Intune サービスが内容を検証・強制するわけではありません。(Microsoft Learn)
管理者は、レポートに表示された値を「調査の手がかり」として扱い、単独で管理操作の根拠にしないようにします。公式情報でも、device-reported values には自由形式のテキスト、URL、ファイルパスが含まれる可能性があり、独立して検証していないリンクや外部指示に従わないよう注意が示されています。(Microsoft Learn)
たとえば、スクリプトが返した値に外部 URL が含まれていたとしても、その URL を管理者がそのままクリックしてはいけません。社内の信頼済み手順、Intune admin center、Microsoft Defender portal、端末ログなど、管理者が信頼できる別経路で確認するべきです。
Conditional Access と組み合わせるときの注意点
Custom compliance settings の結果は、組み込みの compliance settings と同じように device compliance state に影響します。Microsoft の公式情報では、custom compliance settings は組み込み設定と同じように Conditional Access decisions に使用でき、全体として compound rule set を形成すると説明されています。(Microsoft Learn)
そのため、次のような展開は避けた方が安全です。
- 初回から全社ユーザーに割り当てる
- 非準拠時に即時ブロックする
- スクリプトの例外処理が不十分なまま Conditional Access と連動させる
- ユーザー向け復旧メッセージが英語だけ、または抽象的すぎる
- 端末の一時的な状態を厳格なアクセス条件に使う
おすすめは、段階的な展開です。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | IT 管理者の少数デバイス | スクリプト出力と JSON 判定を確認する |
| パイロット | 情シス、セキュリティ部門、一部ユーザー | 非準拠理由と復旧手順が伝わるか確認する |
| 限定展開 | 重要度の低いリソースから適用 | Conditional Access の影響を測る |
| 本番展開 | 対象デバイス全体 | 監視、通知、例外運用を含めて運用する |
特に、非準拠時のアクションでは猶予期間や通知メールを活用します。Microsoft の compliance policy 作成手順では、非準拠デバイスに対して通知メール、ロック、リタイアなどのアクションを構成できることが説明されています。(Microsoft Learn)
Windows と Linux で設計を分けるべき理由
同じ custom compliance でも、Windows と Linux では設計の考え方が異なります。
| 観点 | Windows | Linux |
|---|---|---|
| スクリプト | PowerShell | Bash、Python など |
| 実行コンテキスト | 既定は System context。設定によりユーザーコンテキストも可能 | ユーザーコンテキスト |
| 代表的な確認項目 | TPM、Secure Boot、BIOS、レジストリ、サービス状態 | OS 情報、ユーザー権限で読める設定、アプリ状態 |
| 注意点 | 32bit / 64bit PowerShell、署名、出力の 1行 JSON | shebang、インタープリター有無、昇格不要な項目に限定 |
| 失敗しやすい点 | 余計な出力、型不一致、レジストリ参照先の違い | root 権限が必要なファイルを読もうとする |
Windows では、スクリプト実行権限や PowerShell Host のビット数が問題になりやすいです。Linux では、そもそもその端末に Python や Bash などの実行環境があるか、ユーザー権限で必要な値を読めるかが重要になります。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
既存環境で custom compliance discovery script を使っている、またはこれから使う場合は、次の項目を確認してください。
| チェック項目 | 合格基準 |
|---|---|
| 対象 OS | Windows / 対象 Linux ディストリビューションに限定されている |
| スクリプト名 | 目的、OS、判定内容が分かる名前になっている |
| 出力形式 | 1行の JSON で、不要なログが混ざっていない |
| 出力サイズ | 必要最小限で、長い文字列や一覧を返していない |
JSON の SettingName | スクリプト出力のキー名と大文字小文字まで一致している |
JSON の DataType | 実際の戻り値の型と一致している |
| 実行時間 | Windows 10分以内、Linux 5分以内に確実に終わる |
| Linux 権限 | ユーザーコンテキストで読める項目だけを評価している |
| Windows 実行設定 | System / user context、署名、64bit Host を確認している |
| 非準拠メッセージ | ユーザーが次に何をすべきか分かる内容になっている |
| Conditional Access | いきなり本番ブロックにならないよう段階展開している |
| レポート運用 | device-reported values を単独の根拠にしていない |
このチェックリストで 1つでも不安がある場合は、全社展開前にテストグループで再検証するべきです。特に Conditional Access と連動する環境では、スクリプトの失敗が「単なるエラー」ではなく「業務リソースにアクセスできない」という影響につながります。
使い分けの判断基準
Custom compliance discovery script は便利ですが、すべての端末チェックに使うべきではありません。目的によって、Intune の標準 compliance settings、custom compliance、Remediations、レポート系機能を使い分けます。
| やりたいこと | 向いている選択肢 | 理由 |
|---|---|---|
| OS バージョンや暗号化など標準項目を評価したい | 標準 compliance settings | 標準機能の方が保守しやすい |
| 標準にない独自条件でアクセス可否を判断したい | Custom compliance | compliance state と Conditional Access に反映できる |
| 問題を検出して自動修復したい | Remediations | 検出スクリプトと修復スクリプトを組み合わせられる |
| 端末の状態を広く可視化したい | レポート・インベントリ系機能 | 準拠判定にせず情報収集に集中できる |
| 一時的な調査をしたい | 限定的なスクリプト運用 | 本番の compliance state に影響させない方が安全 |
判断の軸は、「その値でアクセスを止めるべきか」です。アクセス制御に使うほど重要な条件なら custom compliance が候補になります。一方、単に状況を把握したいだけなら、compliance policy に組み込む前に別の収集方法を検討した方が安全です。
まとめ：まずはスクリプト、JSON、アクセス制御の3点を見直す
Microsoft Intune の custom compliance discovery script は、標準の準拠設定では足りないセキュリティ要件を補う強力な仕組みです。一方で、スクリプトの戻り値、JSON ルール、実行権限、レポートの扱いを誤ると、意図しない非準拠判定や Conditional Access のブロックにつながります。
確認した公式情報の範囲では、今回の内容に対する強制移行期限は示されていません。ただし、既存のカスタム準拠ポリシーをそのまま放置するのではなく、次の順番で点検するのが現実的です。
- 既存の discovery script が短く安定した JSON を返しているか確認する
- JSON の
SettingName、型、演算子、ユーザー向けメッセージを確認する - Conditional Access と非準拠アクションの影響範囲を確認する
- Windows と Linux で実行コンテキストや権限の違いを確認する
- device-reported values を過信せず、管理者の検証手順を用意する
まずは本番ポリシーを変更する前に、テスト用のデバイスグループでスクリプト出力と JSON 判定を再確認してください。カスタム準拠ポリシーは、正しく設計すれば Intune の標準機能を補完できますが、運用ルールなしに広げるとトラブルの原因になります。小さく検証し、影響範囲を明確にしてから段階的に展開することが、最も安全な進め方です。
コメント