Intune の「検出／修復（Proactive Remediations）」で“毎日16:00に実行”を設定したのに、端末によって実行されたりされなかったりする——。本記事では、検出／修復スクリプトがいつ走るのか（スリープ・電源OFF・フタ閉じ・タイムゾーン・UTC設定・実行コンテキスト）を、運用で困らない観点で整理します。
Intune の「検出（Detection）／修復（Remediation）」は“いつ動く”のかを先に結論で整理
Microsoft Intune の Proactive Remediations（現在は「Remediations」と表記されることもあります）は、ざっくり言うと「指定した頻度・時刻で検出スクリプトを走らせ、問題があると判定した場合に修復スクリプトを走らせる」仕組みです。
ただし、現場でハマりやすいのは「毎日16:00」と設定しても、16:00ちょうどに必ず走るとは限らない点です。理由は単純で、端末側の状態（起動中・スリープ・オフライン）と、Intune 管理拡張機能（Intune Management Extension：IME）による実行タイミングが絡むためです。
| 知りたいこと | 結論（運用で使える言い方） |
|---|---|
| 検出スクリプトは毎日16:00に実行される？ | 端末が起動していて実行可能な状態なら「その時刻付近」に実行。スリープや電源OFFなら16:00には実行されず、復帰後に遅延実行になりやすい。 |
| 14日以上未再起動なら修復が実行される？ | 検出が「修復が必要」と判定したら修復がトリガーされる。ただし修復も端末が実行可能な状態であることが前提。 |
| スリープ／電源OFF／フタ閉じのときは？ | 基本は動かない。スケジュール時刻に寝ていたら、その時刻には走らず、起きて Intune にチェックインできる状態になってから動く。 |
| 複数タイムゾーン端末がある場合、16:00はどの16:00？ | スケジュールの「Use UTC（UTC を使用）」がOFFなら端末ローカル時刻の16:00。ONならUTCの16:00固定で全端末が実行（ローカル時刻はバラバラ）。 |
| 「ログオン資格情報で実行」は No のままでよい？ | 再起動など端末全体に効く処理を確実に動かすなら、一般的にNo（SYSTEM 実行）が安全。ユーザーUI操作が必須なら Yes を検討。 |
「毎日16:00」なのにズレる理由：スケジュール＝“端末が動ける時に実行される約束”
Intune の検出／修復は、クラウド側が秒単位で端末へ「今すぐ実行」を強制するというより、端末側の Intune 管理拡張機能（IME）が実行条件を満たしたタイミングで動くと捉える方が実態に近いです。
そのため、次の条件が揃って初めて「スケジュール通りに見える」動きになります。
- 端末が起動中で、OSが通常稼働している（スリープ・休止・電源断ではない）
- ネットワーク的に Intune と通信できる（オフライン・社外でVPN必須などは遅れやすい）
- IME が動作している（サービス停止・インストール不良がない）
逆に言えば、スケジュール時刻に端末が眠っていたり、ネットワークに出られなかったりすると、「実行できる状態になった後」に遅延実行されることがあります。これが「16:00にしたのに翌朝動いた」「端末ごとに実行時刻が違う」の正体です。
検出（Detection）と修復（Remediation）はセットだが、動く順番と前提がある
あなたが作った構成（14日以上未再起動を検出し、条件に応じて再起動）は、検出／修復の典型パターンです。実行の流れは次の通りです。
- スケジュール（例：毎日16:00）を迎える
- 端末が実行可能なら検出スクリプトが実行される
- 検出結果が「要修復」なら修復スクリプトが実行される
- 修復が成功したかどうかが端末から報告される
ここで重要なのは、修復は“検出の判定”がトリガーであること、そして検出も修復も端末が実行可能であることが前提だということです。端末がスリープなら、検出が走らない＝修復も走りません。端末が復帰して検出が走ったタイミングで、必要なら修復も続いて走ります。
質問1：検出スクリプトは「毎日16:00」に実行されるのか
管理画面で「毎日 16:00」と設定した場合の実務上の解釈は、次の通りです。
- 16:00ちょうど保証ではない（端末状態やチェックインの影響で前後する）
- 端末が起動していて実行可能なら、16:00付近で実行される
- スリープ／電源OFF／オフラインなら、その時刻には実行されず遅延しやすい
「毎日16:00に必ず走らせたい」という要件が強いほど、Intune のスケジュール設定だけでは不足しがちです。端末側の電源管理（スリープ抑制、あるいは特定時刻に起こす運用）もセットで考えると、実行時刻のブレを小さくできます。
| スケジュール時刻（16:00）の端末状態 | その瞬間に実行される？ | 現場でよくある挙動 |
|---|---|---|
| 起動中（ログオンあり/なし） | 実行されやすい | 16:00前後で検出が走り、必要なら修復も続く |
| スリープ（フタ閉じ含む） | 基本実行されない | 翌朝起床後・ログオン後などに遅延して実行される |
| 休止状態（ハイバネーション） | 実行されない | 復帰後に遅延実行（スリープよりさらに遅れやすいことも） |
| 電源OFF | 実行されない | 次回起動後に遅延して実行される |
| 起動中だがオフライン | 実行が遅れることがある | ネットワーク復帰・VPN接続後に実行される |
質問2：14日以上未再起動なら修復は実行されるのか
結論として、検出が「14日以上再起動されていない」と判定すれば、修復は実行されます。ただし、修復の実行にも前提があります。
- 端末が実行可能（起動中でOSが動いている）
- IME が動作している
- （多くの場合）端末が Intune と通信できる状態である
実務では「検出で引っかかっているはずなのに修復が走らない」ケースの多くが、端末がスリープしがち・オフラインになりがち・IMEが何らかで止まっている、のいずれかです。
また、検出／修復スクリプトの設計上の注意点として、一般的には次のように扱います。
- 検出スクリプト：問題なしなら正常終了、問題ありなら「修復が必要」とわかる形で終了（終了コードや出力）
- 修復スクリプト：実際に状態を直し、成功／失敗を返す
この「検出が“修復が必要”と判定するロジック」が正しく書けていれば、14日ルールは素直に運用できます。
質問3：スリープ／電源OFF／フタ閉じのときはどうなる？（その状態でも動くのか）
まず大前提として、PowerShell スクリプトが動くには Windows が動いている必要があります。スリープや休止、電源OFFの状態では、CPU/OSの実行が止まるため、その瞬間にスクリプトを走らせることはできません。
実際の運用でのポイントは「その時刻に走らなかった分はどうなるか」です。ここは次の理解が役に立ちます。
- スケジュール時刻に寝ていた場合、“その回は未実行”になり、復帰後に遅延して実行されることが多い
- 復帰後も、即時に走るとは限らず、チェックインやIMEの都合で少し時間が空くことがある
- ユーザーが毎日フタを閉じっぱなしの端末は、実行タイミングが翌日・週明けに偏るなどの現象が起きやすい
特に「フタ閉じ＝スリープ運用」のノートPCが多い環境では、16:00固定よりも、次のような設計が実務で効きます。
- “ユーザーが起きている時間帯”（例：午前中）にスケジュールする
- OSの電源設定で、業務時間帯はスリープしにくくする（会議中の放置で寝るのを減らす）
- 再起動が必須なら、通知と猶予、再通知、延期回数などをスクリプト側で設計する
| 状態 | スクリプトは動く？ | 「毎日16:00」運用での注意 |
|---|---|---|
| スリープ（S3） | 動かない | 復帰後に遅延実行。実行時刻のブレが大きくなりやすい。 |
| フタ閉じ（多くはスリープ相当） | 動かない | ノートPC中心の環境では“夕方実行”のつもりが翌朝実行になりがち。 |
| 休止（ハイバネーション） | 動かない | 復帰まで実行されないため、最も遅延しやすい。 |
| 電源OFF | 動かない | 次回起動後。実行が数日飛ぶことも普通に起きる。 |
質問4：複数タイムゾーン端末がある場合、16:00 はローカル？UTC固定？
ここは Intune の設定項目で結論が決まります。スケジュール設定にある「Use UTC（UTC を使用）」のON/OFFがすべてです。
Use UTC が OFF の場合：端末のローカル時刻で 16:00
Use UTC をOFFにすると、各端末が属するタイムゾーンの「16:00」で動きます。日本の端末は日本時間の16:00、米国東部の端末は米国東部時間の16:00というように、運用担当としては直感的です。
Use UTC が ON の場合：UTCの 16:00 固定で全端末に配布
Use UTC をONにすると、基準が UTC になるため、世界中の端末が同じ瞬間（UTC 16:00）に実行しようとします。結果として、端末のローカル時刻はバラバラになります。
| 端末のタイムゾーン例 | Use UTC OFF（ローカル16:00） | Use UTC ON（UTC16:00固定） |
|---|---|---|
| 日本（UTC+9） | 日本時間 16:00 | 日本時間 01:00（翌日）になる |
| 英国（UTC+0） | 英国時間 16:00 | 英国時間 16:00（同じ） |
| 米国東部（UTC-5） | 米国東部時間 16:00 | 米国東部時間 11:00 になる |
あなたの要望が「各拠点の端末で“ローカルの16:00”に動かしたい」なら、Use UTC はOFFで問題ありません。逆に「全社で同一瞬間に一斉実行したい（統計や検証の都合で同時刻が必要）」なら、Use UTC をONにします。
質問5：「ログオン資格情報で実行」は No のままでよいか
この設定は、スクリプトの実行主体をユーザーコンテキスト（ログオン中ユーザー）にするか、システムコンテキスト（SYSTEM）にするかを決める重要項目です。
今回の目的は「14日以上未再起動の端末を再起動させる」なので、運用上は次の考え方が安全です。
- ユーザーがサインインしていない状況でも修復（再起動）を確実に動かしたい → 「ログオン資格情報で実行：No」がおすすめ
- ユーザーの画面に高度な通知（トースト、UI、ユーザー操作）が必須 → 「Yes」も検討（ただし未ログオン時に動かない・動きが変わるリスクを考慮）
| 項目 | No（SYSTEM で実行） | Yes（ログオンユーザーで実行） |
|---|---|---|
| ユーザー未サインインでも動く | 動く | 動かない／動きが制限されることがある |
| 再起動など端末全体の操作 | 得意 | 権限不足や制限が出る可能性 |
| ユーザーにUI通知を出す | 工夫が必要（shutdown のメッセージ、別タスクなど） | 得意（ユーザーセッションで表示しやすい） |
| ユーザープロファイル（HKCU等）操作 | 不得意（ユーザー依存の設定は扱いづらい） | 得意 |
| ネットワークアクセス時の主体 | 端末アカウント（コンピューター）寄り | ユーザーアカウント寄り |
あなたの要件にある「ユーザーがサインイン中なら、強制再起動の10分前に通知してから再起動」は、必ずしも「Yes」が必須ではありません。たとえば SYSTEM 実行でも、再起動を10分後に予約してメッセージを表示する方法（例：shutdown コマンド）で要件を満たせる場合があります。運用の確実性（未ログオンでも動く）を優先するなら、まずは No を軸に設計するのが堅実です。
「16:00に動かない」運用事故を減らす設計ポイント
端末が“寝ている”前提で、遅延実行でも困らないようにする
スリープが多い端末は、スケジュール通りに動きません。そこで、次のように設計しておくと事故が減ります。
- 再起動の猶予を長めに取り、ユーザー業務に食い込まないようにする（例：10分→30分、あるいは当日中の任意タイミング選択など）
- 「業務時間外にだけ実行」のような条件をスクリプトに入れる（例：18:00〜08:00だけ再起動実施）
- 実行が遅延しても意味がある判定にする（例：「14日以上」なら翌朝の実行でも問題ない）
“毎日16:00”にこだわるなら、電源設計もセットで考える
もし「16:00に必ず近い時間で動かす」こと自体が重要なら、次のどちらかが現実的です。
- 端末の電源設定で、16:00前後はスリープしない運用に寄せる（会議室PC・共有PCなどは特に有効）
- ユーザー運用（退席時はログオフではなくロック、フタ閉じ禁止の時間帯を作る等）をガイドする
Intune は便利ですが、電源断やスリープをまたいで「クラウドが端末を起こして確実に実行」までは担保しません。ここを期待しすぎると、実行タイミングのズレが“仕様なのに事故”になります。
今回の要件（14日未再起動→状況に応じて再起動）をスクリプト設計で堅くする
ここでは「こうしておくと運用が安定しやすい」という観点で、実装の考え方をまとめます。コードは環境に合わせて調整してください。
検出：稼働日数（uptime）で 14日超を判定する
検出では、OSの最終起動時刻から経過日数を計算し、14日を超えたら「要修復」と判定します。
# Detection (例): 14日以上再起動されていないか判定
$lastBoot = (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime
$uptime = (Get-Date) - $lastBoot
# 14日 = 14 * 24 * 60 * 60
if ($uptime.TotalDays -ge 14) {
Write-Output ("UptimeDays={0:N1} (Need remediation)" -f $uptime.TotalDays)
exit 1
} else {
Write-Output ("UptimeDays={0:N1} (OK)" -f $uptime.TotalDays)
exit 0
}ポイントは、検出の結果がログで追えるように、経過日数を出力しておくことです。あとから「なぜ修復が走ったのか」「本当に14日超だったのか」を説明しやすくなります。
修復：ユーザー未サインインなら即再起動／サインイン中なら10分前通知→再起動
修復スクリプトでは、まず「ログオン中のユーザーがいるか」を判定し、分岐します。
- ユーザー未サインイン：即時（または短時間）で再起動
- ユーザーサインイン中：10分前通知を出して、10分後に再起動
# Remediation (例): ログオン有無で分岐して再起動
# ※運用前に必ず検証してください（テスト端末・テストグループ推奨）
$cs = Get-CimInstance -ClassName Win32_ComputerSystem
$loggedOnUser = $cs.UserName
if ([string]::IsNullOrWhiteSpace($loggedOnUser)) {
# ユーザー未サインイン → すぐ再起動（例：60秒後）
shutdown.exe /r /t 60 /c "メンテナンスのため再起動します（ユーザー未サインインのため即時実施）。" /f
exit 0
} else {
# ユーザーサインイン中 → 10分前通知して再起動
# shutdown のコメントはユーザーに表示されるため、通知として使えることがあります
shutdown.exe /r /t 600 /c "端末の稼働日数が14日を超えました。10分後に再起動します。保存して作業を終了してください。" /f
exit 0
}上記は一例です。環境によっては、ユーザーへの見え方（通知UI）が期待通りでないことがあります。その場合は、トースト通知や社内向けツール（Teams通知・社内エージェント）を使うなど、通知方法を別途設計してください。
運用を強くする追加アイデア（オリジナルの実務ポイント）
「再起動させたい」だけだと、現場では反発や事故が起きがちです。次の工夫を入れると、運用が安定します。
| 工夫 | 効果 | 実装の方向性 |
|---|---|---|
| 業務時間外だけ再起動 | 会議中の強制再起動を避ける | 現在時刻を見て、時間帯外は「次回へ持ち越し」にする |
| 延期（Defer）を数回だけ許可 | ユーザー体験とセキュリティのバランス | レジストリ等に延期回数を保存し、上限超で強制 |
| 再起動前に保存猶予を十分確保 | データ損失の苦情を減らす | 10分→30分、再通知を入れる等 |
| 「未再起動14日」を可視化 | なぜ再起動が必要か説明できる | 検出ログに uptime を出し、管理側も確認できるようにする |
64-bit PowerShell host はどうする？（地味に差が出る設定）
端末が64bit Windowsで、レジストリやシステム情報取得などを正確に扱いたい場合は、一般的に「64-bit PowerShell host で実行：Yes」が無難です。32bitで動かす理由がない限り、64bitを選ぶことで意図しないリダイレクト（例：レジストリの Wow6432Node 側を見てしまう）を避けやすくなります。
実行状況の確認方法： “動いているはず” をやめて、証跡で追う
検出／修復は「端末が動ける時に動く」ため、実行時刻がズレるのは珍しくありません。だからこそ、運用では実行結果を追える導線が重要です。
管理者が確認したい代表的なポイント
- 対象端末で検出が最後にいつ走ったか
- 検出が「要修復」を返しているか
- 修復が成功しているか（再起動が実際に行われたか）
- スリープやオフラインで遅延していないか
トラブルシュートの切り分け表
| 症状 | よくある原因 | まず見るポイント |
|---|---|---|
| 16:00に動かない端末がある | スリープ／電源OFF／オフライン | その時間帯に端末が起きているか、ネットワークに出られるか |
| 検出は走るが修復が走らない | 検出が「要修復」と判定していない／判定条件ミス | 検出スクリプトの出力と判定ロジック（境界値：13.9日など） |
| 修復は走ったが再起動されない | 通知後にユーザーが作業継続／権限やコマンド仕様の想定違い | 修復スクリプトの実行主体（SYSTEM/ユーザー）、実行コマンドの動作検証 |
| 海外拠点だけ変な時間に動く | Use UTC の設定が想定と逆 | スケジュール設定の「Use UTC」ON/OFF |
| ユーザー未サインイン時に動かない | 「ログオン資格情報で実行：Yes」にしている | 実行設定を No（SYSTEM）へ見直す |
運用に落とし込むためのおすすめ設定例（今回のケース）
「14日未再起動を検出して、状況に応じて再起動」という目的に寄せた場合、まずは次の設定が扱いやすいことが多いです。
| 設定項目 | おすすめ | 理由 |
|---|---|---|
| スケジュール | 毎日 16:00（ただし端末運用により調整） | 日次で状態を見られる。スリープが多いなら午前中の方が安定することも。 |
| Use UTC | OFF（ローカル16:00） | 拠点ごとに同じ“体感時刻”で運用しやすい。 |
| ログオン資格情報で実行 | No | ユーザー未サインインでも確実に動かしやすい。再起動など端末制御に向く。 |
| 64-bit PowerShell host | Yes | 64bit OSの情報取得やレジストリ操作の齟齬を減らす。 |
まとめ：Intune の検出／修復は「端末が動ける時に動く」。設計は“遅延前提”がうまくいく
最後に、今回の5つの疑問に対する要点を、運用の言葉でまとめます。
- 「毎日16:00」は厳密な時刻保証ではなく、実行可能な状態ならその付近で動くと理解する
- 検出で条件に合致すれば修復はトリガーされる（ただし端末が起動して実行できることが前提）
- スリープ／フタ閉じ／電源OFFではその時刻に動かない。復帰後に遅延実行になりやすい
- タイムゾーンはUse UTC のON/OFFで決まる。ローカル16:00にしたいならOFF
- 再起動のような端末制御は、まずは「ログオン資格情報で実行：No（SYSTEM）」を軸に考える
「実行されるはず」ではなく、「どういう条件なら確実に実行され、どんな時に遅延するか」を前提に組むと、Proactive Remediations は“壊れる前に直す”運用の強い武器になります。
コメント