Microsoft Intuneの公式ドキュメント更新「Update script run status reporting explanation」でまず押さえるべき点は、新機能の追加ではなく、macOS向けシェルスクリプトの実行ステータス報告の読み方が明確化されたことです。特に重要なのは、Script frequencyで定期実行を設定していても、Intune管理センター上のステータスや最終更新日時が毎回更新されるとは限らない点です。
セキュリティ管理者、コンプライアンス担当者、エンタープライズIT部門は、Last updatedを「直近の実行時刻」として扱っていないかを確認してください。今回の更新は、監視ダッシュボード、監査証跡、障害対応手順の見直しにつながる実務的な変更として読むべきです。
Microsoft Intuneの公式ドキュメント更新で何が変わったか
2026年4月29日のMicrosoftDocs系GitHubコミットでは、Microsoft IntuneのmacOSシェルスクリプトに関するドキュメント run-shell-scripts-macos.md が更新されました。コミットの内容は、スクリプト実行ステータスの報告説明を明確化するもので、差分としては1ファイルの1行更新です。つまり、Intuneサービス側に新しい設定項目が追加されたというより、既存のレポート仕様を誤解しないための説明強化と見るのが適切です。(GitHub)
対象となるのは、Microsoft IntuneでmacOSデバイスに配布するシェルスクリプトの監視です。Microsoft Learnの該当ページでは、スクリプトの実行状況を確認する場所として、Device statusとUser statusが示されています。(Microsoft Learn)
今回の更新で実務上重要なのは、次の読み替えです。
| 誤解しやすい読み方 | 正しい読み方 |
|---|---|
| Script frequencyを毎日にすると、レポートも毎日更新される | 実行頻度とレポート上の更新頻度は同じではない |
| Last updatedは直近の実行時刻を示す | Last updatedは、Intuneに報告されたステータス更新の時刻として扱う |
| Successが続いていれば、毎回成功した証拠になる | Successは直近で報告されたステータスであり、毎回の実行履歴そのものではない |
| タイムスタンプが古いのでスクリプトが止まっている | ステータスが変わっていないだけの可能性がある |
変更点の核心：ステータスは毎回ではなく「変化したとき」に報告される
公式ドキュメントの重要な説明は、選択したScript frequencyに関係なく、スクリプト実行ステータスは前回報告からステータスが変わった場合に報告される、という点です。たとえば、ある実行で成功し、次の実行で失敗した場合は、Intuneがステータスと最終更新日時を現在の実行情報で更新します。一方、同期をまたいでもステータスが変わらない場合、最終更新日時は初回実行から7日ごとに更新される説明になっています。(Microsoft Learn)
実務では、次のように解釈すると安全です。
| 実際の状態 | Intune上の見え方 | 避けたい判断 | 正しい対応 |
|---|---|---|---|
| 毎日実行され、毎回Success | StatusはSuccessのまま、Last updatedは毎回変わらない可能性がある | 「毎日実行されていない」と即断する | ステータス変化ベースの報告仕様として読む |
| SuccessからFailureに変わった | StatusとLast updatedが更新される | 「一時的な表示遅延」と軽視する | 重要スクリプトなら障害として調査する |
| Failureが継続している | Failureのまま、時刻だけでは変化が分かりにくい場合がある | 「新しい失敗が出ていない」と放置する | 失敗継続としてログと原因を確認する |
| Last updatedがScript frequencyと一致しない | レポート更新が実行頻度に追従していないように見える | 「Intuneの実行頻度設定が効いていない」と判断する | 実行頻度と報告更新を分けて確認する |
この仕様は、監視設計に大きく関わります。特に「Last updatedが24時間以上古い場合にアラートを出す」といった単純な条件は、macOSシェルスクリプトでは誤検知を生みやすくなります。
影響を受ける範囲はmacOS向けシェルスクリプト
今回のドキュメント更新は、Microsoft Intune全体のすべてのレポート仕様を変更するものではありません。対象は、macOSデバイスに対してIntuneから配布するシェルスクリプトの監視説明です。
Microsoft Learnでは、macOS向けシェルスクリプトを使う前提として、Intune管理下のmacOSデバイス、macOS 12.0以降、直接インターネットに接続できること、スクリプトが#!で始まることなどが示されています。さらに、シェルスクリプトはMicrosoft Intune management agent for macOSによって実行されるため、エージェントの状態も確認ポイントになります。(Microsoft Learn)
一方で、Intuneにはほかにもコンプライアンスポリシー、構成プロファイル、カスタム属性、アプリ配布レポートなど複数の管理・報告機能があります。今回の説明をそれらへそのまま当てはめるのは避けるべきです。
| 確認したいこと | 主に見る機能 | 注意点 |
|---|---|---|
| macOSシェルスクリプトの成功・失敗 | ScriptsのDevice status / User status | ステータスは毎回更新されるとは限らない |
| macOS端末から値を収集したい | Custom attributes for macOS | データ型、出力サイズ、Result列の扱いを確認する |
| 端末が社内基準を満たすか判断したい | コンプライアンスポリシー | スクリプト成功だけをコンプライアンス証跡にしない |
| 障害原因を追いたい | ログ収集、Intune agentログ | レポート表示だけで原因特定しない |
セキュリティ管理者が確認すべきポイント
セキュリティ管理者にとって最も危険なのは、Successを「毎回のセキュリティチェックが成功した証拠」として扱うことです。Intune上のステータスは重要なシグナルですが、すべての実行履歴を表す監査ログではありません。
たとえば、macOS端末でEDRエージェントの存在確認、暗号化設定の確認、禁止アプリの検出、セキュリティ設定ファイルの配置確認を行っている場合、ステータスがSuccessのままでも、毎回の実行結果を詳細に証明しているとは限りません。
確認すべき項目は次の通りです。
| 確認項目 | 見直す理由 | 実務上の対応 |
|---|---|---|
| 重要スクリプトの一覧 | どのスクリプトがセキュリティ判断に使われているか把握するため | EDR、暗号化、権限、構成確認系を優先して棚卸しする |
| exit codeの設計 | IntuneではゼロがSuccess、非ゼロまたは不正なスクリプトがFailedとして扱われるため | 判定条件を曖昧にせず、異常時は確実に非ゼロで終了する |
| ローカルログ出力 | Intuneのステータスだけでは詳細な原因を追いにくいため | 重要スクリプトは短く読みやすいログを残す |
| Failure時の通知 | ステータス変化は重要な検知ポイントになるため | SuccessからFailureへの変化を優先度高で扱う |
| Last updatedベースのアラート | 誤検知や見落としを防ぐため | タイムスタンプ単独ではなく、端末の稼働状況やログと組み合わせる |
簡単な例として、次のように「判定結果」と「ログ」を分けて設計すると、Intuneの画面だけに依存しない運用にできます。
#!/bin/zsh
LOG_DIR="/Library/Logs/Company"
LOG_FILE="${LOG_DIR}/intune-security-check.log"
mkdir -p "$LOG_DIR"
echo "$(date -u +"%Y-%m-%dT%H:%M:%SZ") check start" >> "$LOG_FILE"
# 実際の環境では、EDR製品や管理対象アプリの正しいパスに置き換える
if [ -d "/Applications/YourSecurityAgent.app" ]; then
echo "$(date -u +"%Y-%m-%dT%H:%M:%SZ") success: security agent found" >> "$LOG_FILE"
exit 0
else
echo "$(date -u +"%Y-%m-%dT%H:%M:%SZ") failure: security agent not found" >> "$LOG_FILE"
exit 1
fiこの例では、Intuneに対してはexit 0またはexit 1で明確に結果を返し、詳細はログに残します。監査や障害調査で必要になるのは、単なるSuccess表示ではなく「何を確認し、どの条件で成功・失敗と判断したか」です。
コンプライアンスチームが見直すべき監査証跡
コンプライアンスチームは、手順書や監査資料の表現を見直す必要があります。特に、Last updatedを「直近の制御実行日時」と書いている場合は注意が必要です。今回の説明に沿うなら、より正確には「Intuneに報告されたスクリプト実行ステータスの更新日時」と表現するのが安全です。
監査対応で問題になりやすいのは、次のような記載です。
| 避けたい記載 | 問題点 | 推奨される表現 |
|---|---|---|
| Last updatedにより毎日の実行を確認している | ステータスが変わらない場合、毎回更新されるとは限らない | Last updatedはIntune上のステータス更新時刻として確認する |
| Successなので端末は準拠している | Successはスクリプトの終了コードであり、準拠状態全体ではない | 準拠判断はコンプライアンスポリシーや追加証跡と組み合わせる |
| 7日以内の更新があるため毎日実行済み | 7日ごとの更新仕様と混同している | 実行頻度の確認にはログや別の収集方法を併用する |
| Failureが更新されていないので解消済み | ステータスが変わっていないだけの可能性がある | Failure状態の継続として扱い、原因と復旧状況を記録する |
監査向けには、GitHubのコミットID、Microsoft Learnの参照ページ、社内で確認した日時を記録しておくと、グローバル拠点や外部監査人との認識合わせがしやすくなります。GitHub上のコミット日は2026年4月29日ですが、Microsoft Learnページ側の表示更新日とは一致しない場合があります。ドキュメントの反映タイミングをめぐる議論を避けるため、参照元を明示してレビュー記録を残すのが現実的です。(GitHub)
エンタープライズITが見直すべき運用設計
エンタープライズ環境では、Intuneの画面を複数チームが見ます。セキュリティチーム、デバイス管理チーム、ヘルプデスク、監査対応チームが同じStatusやLast updatedを見ていても、解釈が異なると対応にズレが出ます。
まず見直すべきなのは、監視ダッシュボードとチケット起票条件です。
| 運用項目 | 見直し前にありがちな条件 | 見直し後の考え方 |
|---|---|---|
| 障害アラート | Last updatedが24時間以上古い | ステータス変化、端末稼働状況、ログ収集可否を組み合わせる |
| チケット起票 | Failureを検出したら一律起票 | 重要度、対象台数、継続時間で優先度を分ける |
| ヘルプデスク手順 | 古いタイムスタンプを異常として案内 | ステータスが変化していない可能性を説明に含める |
| 月次レビュー | Success率だけを見る | Failure遷移、未報告端末、ログ取得状況も確認する |
| グローバル運用 | 各地域が独自に解釈する | 共通の読み方をRunbookに明記する |
特に多拠点運用では、時差も考慮してください。米国時間で作成された公式更新を日本時間で確認する場合、日付の見え方が変わることがあります。変更管理チケットには「確認日」「参照した公式ソース」「対象テナント」「対象スクリプト」をセットで残すと、後から説明しやすくなります。
今すぐ実施したい確認手順
今回の更新を受けて、いきなり全スクリプトを修正する必要はありません。まずは、誤解が障害や監査リスクにつながるスクリプトから順に確認します。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | macOS向けシェルスクリプトを棚卸しする | セキュリティ、監査、初期セットアップ、運用補助に分類する |
| 2 | Device status / User statusの使い方を確認する | ユーザー割り当てかデバイス割り当てかを見誤っていないか見る |
| 3 | Last updatedを使うアラートを洗い出す | 実行時刻として扱っている条件があれば修正候補にする |
| 4 | Failure時の対応手順を確認する | ログ収集、再実行、端末確認の流れが明確か見る |
| 5 | 重要スクリプトのexit codeを確認する | 成功時は0、異常時は非ゼロで返す設計になっているか確認する |
| 6 | パイロット端末で挙動を確認する | Success継続、Failure遷移、Failure継続を分けて観察する |
| 7 | 監査資料とRunbookを更新する | Last updatedの説明を公式仕様に合わせる |
パイロット検証では、同じスクリプトをいきなり本番全体へ展開しないことが重要です。少数のテストMacを用意し、SuccessからFailureへ変化するケース、Failureが継続するケース、Successが継続するケースを分けて確認すると、Intuneの表示を正しく理解できます。
ログ収集の設計も合わせて確認する
Microsoft Learnでは、macOSシェルスクリプトのトラブルシューティングとしてログ収集の手順も説明されています。ログ収集では、フルパスの指定、セミコロン区切り、圧縮後60MBまたは25ファイルまでといった条件が示されています。また、ログはIntune管理エージェントの次回チェックイン時に収集され、このチェックインは通常8時間ごとと説明されています。(Microsoft Learn)
ログ収集で失敗しやすいポイントは、実務でもよく起きます。
| 失敗しやすいポイント | 例 | 対策 |
|---|---|---|
| 相対パスで指定する | logs/check.log | /Library/Logs/Company/check.logのように絶対パスで指定する |
| 区切り文字を間違える | カンマ、改行、スペースで区切る | 複数パスはセミコロンのみで区切る |
| ログサイズが大きすぎる | 長期間追記し続ける | ローテーションや上書き設計を入れる |
| 許可されない拡張子を使う | 独自拡張子のまま保存する | .logや.txtなど許可された形式にする |
| 成功時に何も残さない | Failure時だけログを書く | 成功時も最低限の確認結果と日時を残す |
Intuneのステータスは全体把握に向いていますが、障害原因の特定にはログが必要です。特にセキュリティ系スクリプトでは、ログに「確認対象」「判定条件」「結果」「実行日時」を残しておくと、監査とトラブルシューティングの両方で役立ちます。
Custom attributesとの使い分け
macOS端末から具体的な値を収集したい場合は、シェルスクリプトのステータスだけでなく、Custom attributes for macOSの利用も検討します。Microsoft Learnでは、カスタム属性プロファイルのスクリプトは管理対象Mac上で8時間ごとに実行され、戻り値はResult列に表示されると説明されています。(Microsoft Learn)
使い分けの目安は次の通りです。
| 要件 | 向いている機能 | 理由 |
|---|---|---|
| 成功・失敗だけを見たい | macOSシェルスクリプト | exit codeで状態を簡潔に判断できる |
| バージョン番号や設定値を収集したい | Custom attributes | スクリプトの出力値をResultとして扱える |
| 準拠・非準拠をポリシーとして扱いたい | コンプライアンスポリシー | 端末の準拠状態として管理しやすい |
| 詳細な原因を追いたい | ログ収集 | レポートでは見えない実行内容を確認できる |
たとえば「セキュリティエージェントが存在するか」だけならシェルスクリプトのSuccess / Failureで足ります。一方、「セキュリティエージェントのバージョン」「設定プロファイルの値」「最後にローカルで確認した日時」を収集したい場合は、Custom attributesやログを組み合わせたほうが運用しやすくなります。
よくある誤解と正しい対応
Script frequencyの設定は意味がなくなったのか
意味がなくなったわけではありません。Script frequencyはスクリプトの実行スケジュールに関わる設定です。ただし、Intune管理センター上のステータス表示が、毎回の実行に合わせて更新されるとは限りません。実行頻度とレポート更新頻度を分けて考える必要があります。
Last updatedが古い場合は異常なのか
必ずしも異常とは限りません。ステータスが変わっていない場合、Last updatedが実行頻度どおりに更新されないことがあります。ただし、端末が長期間オンラインになっていない、Intune管理エージェントが正常に動作していない、スクリプトが受信されていないといった別の問題もあり得ます。Last updatedだけで判断せず、端末状態、エージェント状態、ログを合わせて確認してください。
Successはコンプライアンス準拠の証拠になるのか
単独では不十分です。Successは、スクリプトがゼロの終了コードを返したことを示すステータスとして扱うべきです。コンプライアンス準拠の証跡に使う場合は、スクリプトの判定条件、ログ、カスタム属性、コンプライアンスポリシーなどと組み合わせて説明できる状態にしておく必要があります。
Windows向けスクリプトや他のIntuneレポートにも同じ考え方を適用すべきか
今回のコミットで直接扱われているのは、macOS向けシェルスクリプトのドキュメントです。Windows向け機能、Remediations、構成プロファイル、コンプライアンスポリシーなどへ自動的に拡大解釈しないでください。各機能の公式ドキュメントでレポート仕様を確認するのが安全です。
今回の更新を受けた実務アクション
Microsoft Intuneの公式ドキュメント更新「Update script run status reporting explanation」は、小さな文言修正に見えて、運用上は重要です。特に、macOSシェルスクリプトをセキュリティ確認や監査証跡に使っている組織では、StatusとLast updatedの解釈を誤ると、誤検知、見落とし、監査説明の弱さにつながります。
まず実施すべきことは、macOS向けシェルスクリプトを棚卸しし、重要度の高いものから監視条件を見直すことです。次に、Last updatedを「直近の実行時刻」として扱っているダッシュボード、アラート、手順書を修正します。最後に、Failure時に原因を追えるよう、exit code設計とログ収集の仕組みを整備してください。
今回の更新を正しく反映できれば、Intuneのレポートを過信せず、かといって不要なアラートにも振り回されない運用に近づけます。読むべきポイントはシンプルです。Script frequency、実行ステータス、Last updated、監査証跡は同じ意味ではない。この前提をチーム内で共有することが、次に取るべき最も重要なアクションです。
コメント