Windowsでタスクスケジューラがスリープ後に実行されない原因と対処｜確認すべき設定と復旧手順

Windowsでタスクスケジューラがスリープ後に実行されないときは、まず「タスク側でスリープ解除を許可しているか」「電源プランでスリープ解除タイマーが有効か」「復帰後の実行条件や権限が厳しすぎないか」の3点を確認すると、ほとんどのケースを切り分けられます。特に、タスクの設定だけを直しても、OS側の wake timer が無効ならPCは起きません。逆にPCが起きても、開始時刻を過ぎたタスクの扱いや実行アカウントの設定が合っていないと、処理自体は走りません。(Microsoft Learn)

この記事では、Windows 10/11で起きやすい原因を「PCが起きない」「起きたがタスクが走らない」「タスクは起動したが中身が失敗する」の3段階で整理します。あわせて、powercfgでの確認方法、更新後に不調になった場合の見方、作り直しまで含めた復旧手順も実務向けにまとめます。Modern Standby対応PCでは従来のS3スリープと挙動が異なるため、その前提も押さえておくと判断が速くなります。(Microsoft Learn)

まず押さえたい結論

• スリープ後に自動実行させたいなら、タスクの WakeToRun だけでなく、電源オプションの スリープ解除タイマー も有効にする必要があります。どちらか片方だけでは足りません。(Microsoft Learn)
• 復帰しても画面が暗いままのことがあります。Microsoftは、タスク実行のためにPCを起こしても 画面は点灯しない場合がある と案内しています。見た目だけで失敗と決めつけないことが大切です。(Microsoft Learn)
• 予定時刻を過ぎたあとの取りこぼしを防ぐには、「開始時刻に間に合わなかった場合、できるだけすぐに実行」 を有効にします。ただし One Time トリガー はこの設定だけで期待どおり再実行されないことがあるため、定期実行のほうが安定します。(Microsoft Learn)
• 原因切り分けは 履歴・Last Run Result・スクリプト単体実行 が近道です。Microsoftも、まず処理本体を単独で試し、必要なら「ユーザーがログオンしている場合のみ実行」に切り替えてセキュリティ コンテキストを切り分ける方法を案内しています。(Microsoft Learn)
• 共有フォルダ、NAS、暗号化ファイル、GUIアプリを扱うタスクは、ログオン方式 と 権限 の影響を受けやすいです。S4Uや「パスワードを保存しない」相当の方式では、ネットワーク資源や暗号化ファイルにアクセスできません。(Microsoft Learn)

Windowsでタスクスケジューラがスリープ後に実行されない主な原因

PCがそもそもスリープ解除されていない

最初の本命はここです。タスクの [条件] にある 「タスクを実行するためにスリープを解除する」 は、時刻になったらTask SchedulerがPCを起こす設定ですが、システム全体では別に wake on timer の電源設定があり、これが無効だと scheduled task のタイマーは使われません。切り分け中は、電源オプションの「スリープ解除タイマーの許可」を [有効] にするのが無難です。Microsoftのドキュメント上、[重要] は内部システムタイマーのみです。(Microsoft Learn)

また、PCがModern Standbyなら、従来のS3スリープ前提で考えると判断を誤ります。Modern Standbyは S0 low-power idle で、S1〜S3を使わない設計です。さらにMicrosoftは、Windows 11 version 24H2以降、一部のModern Standby PCでは過度のバッテリー消費が検出されると多くの wake source を無効化し、電源ボタンやふたの開閉以外で起きにくくなる挙動を案内しています。更新後だけ挙動が変わったなら、この影響を疑う価値があります。(Microsoft Learn)

なお、WakeToRunで起きても 画面は点灯しない 場合があります。「朝見たら画面が黒いままだったので失敗した」と判断しがちですが、実際にはPCはすでにスリープ解除され、タスクだけ実行している可能性があります。画面ではなく、履歴やログファイルで確認してください。(Microsoft Learn)

PCは起きたがタスクが走らない

次に多いのが「PCは起きたのに、タスク本体が走らない」ケースです。まず [設定] の 「スケジュールされた開始時刻に間に合わなかった場合、できるだけすぐにタスクを開始する」 を確認します。これは予定時刻を過ぎたあとでもTask Schedulerが可能になり次第タスクを開始する設定です。ただし、Microsoftの案内では One Time トリガー はこの設定だけでは取りこぼしを回収できないため、スリープ復帰後にも確実に動かしたいなら、毎日・毎時などの繰り返しトリガーにするか、設計を見直したほうが安全です。(Microsoft Learn)

条件タブの絞り込みも見落としやすいポイントです。アイドル時のみ実行、ネットワーク利用時のみ実行、バッテリー駆動中は開始しない、バッテリーに切り替わったら停止する といった条件が有効だと、復帰しても実行条件を満たさず待機や停止になることがあります。ノートPCで再現しやすいので、切り分け中はいったん条件を緩めて結果を見るのが定石です。(Microsoft Learn)

タスクは起動したがアクションが失敗している

履歴を見ると起動はしているのに、スクリプトやアプリの処理が終わっていない場合は、権限・ログオン方式・作業フォルダ を疑います。Microsoftも、まず処理本体を単独実行し、タスクの状態列・History・Last Run Resultを確認するよう案内しています。動作確認では、一時的に 「ユーザーがログオンしている場合のみ実行する」 に変更して、セキュリティ コンテキストの問題かどうかを切り分ける方法が有効です。(Microsoft Learn)

Excelを開く、画面操作を伴うRPA、メッセージボックスを出す、といった 対話型アプリ は、既存の対話セッションで動く InteractiveToken 系の前提と相性がよいです。つまり、ユーザーが未ログオンの状態では安定しにくく、実務上は 「ユーザーがログオンしている場合のみ実行する」 ほうが適しています。逆に、共有フォルダや暗号化ファイルを扱うバッチは、S4Uや 「パスワードを保存しない」 方式だとネットワーク資源にアクセスできません。誰もログオンしていない時間にNASへ取りに行くタスクなら、パスワードを保持する実行アカウントや適切なサービスアカウントを使うべきです。(Microsoft Learn)

また、UACの影響を受ける処理や管理者権限が必要な処理では 「最上位の特権で実行する」 を使い、実行アカウントに Log on as a batch job が与えられているか、逆に Deny log on as a batch job で拒否されていないかを確認します。Microsoftは Access Denied の典型原因として、権限不足、タスクフォルダ権限の変更、資格情報の不整合を挙げています。(Microsoft Learn)

スクリプトで相対パスを使っている場合は、[操作] の 開始（オプション）、または実行アクションの WorkingDirectory を必ず指定してください。Task Scheduler の実行時カレントディレクトリが手動実行時と違うと、同じバッチでも「手動では動くのにタスクでは失敗する」が起きます。(Microsoft Learn)

最短で直す確認手順

次の順で見れば、遠回りしにくくなります。

1. [条件] で 「タスクを実行するためにスリープを解除する」 をオンにします。これがオフだと、時刻が来てもPCは起きません。(Microsoft Learn)
2. 電源オプションの詳細設定で 「スリープ解除タイマーの許可」 を確認し、切り分け中は [有効] にします。タスク側だけ直しても、ここが無効なら復帰しません。(Microsoft Learn)
3. [設定] で 「開始時刻に間に合わなかった場合、できるだけすぐに実行する」 を有効にします。あわせて、トリガーが One Time なら繰り返し型へ見直します。(Microsoft Learn)
4. [全般] で、処理内容に合わせて 実行アカウント と ログオン方式 を選びます。画面操作が必要なら「ユーザーがログオンしている場合のみ実行する」、未ログオンで共有フォルダに触るなら「パスワードを保存しない」方式は避けます。(Microsoft Learn)
5. [全般] の 「最上位の特権で実行する」 を必要に応じて有効にし、実行アカウントの Log on as a batch job 権限も確認します。(Microsoft Learn)
6. [条件] の アイドル時のみ・ネットワーク利用時のみ・バッテリー時の制限 をいったん外して再テストします。ノートPCではここが原因になりやすいです。(Microsoft Learn)
7. [操作] の プログラム/スクリプト、引数、開始（オプション） を見直し、元のスクリプト自体を単体実行して正常終了するか確認します。最後に History と Last Run Result を見ます。(Microsoft Learn)

powercfgで切り分ける

GUIだけでは分かりにくいときは、管理者のコマンドプロンプトで次を実行します。(Microsoft Learn)

powercfg /a
powercfg /waketimers
powercfg /lastwake
powercfg /requests

• powercfg /a は、そのPCで使えるスリープ状態を表示します。ここで S3 なのか Modern Standby(S0 low power idle) なのかを確認できます。(Microsoft Learn)
• powercfg /waketimers は、現在有効な wake timer の一覧です。Microsoftの説明では、wake timer が有効なら期限到来でスリープや休止状態から復帰できます。ここに Regular Maintenance などWindows側のタイマーが出ることもあるので、自分のタスクとシステムメンテナンスを混同しないようにします。(Microsoft Learn)
• powercfg /lastwake は、直前に 何がPCを起こしたか を確認するコマンドです。想定外のキーボード、マウス、NICが起こしていないかを見るときに役立ちます。(Microsoft Learn)
• powercfg /requests は、アプリやドライバーの 電源要求 を表示します。そもそもPCが低電力状態に入りにくい、表示だけ消えている、といった電源周りの混乱を整理できます。(Microsoft Learn)

意図しないデバイス復帰が多いなら、powercfg /devicequery wake_armed で wake を許可されているデバイスを確認し、必要に応じて powercfg /devicedisablewake / powercfg /deviceenableawake を使う方法もあります。(Microsoft Learn)

更新後に急に動かなくなったときの見方

Modern Standbyと24H2の影響を見る

Windows Updateや機能更新のあとにだけ挙動が変わったなら、まず powercfg /a で電源モデルを確認します。Modern Standby 対応機では、Windows 11 version 24H2 以降、過度のバッテリー消費が検出されると多くの wake source が無効化される場合があります。ノートPCなら AC接続で再テスト し、電池駆動時だけ起きないのかを切り分けると判断しやすくなります。(Microsoft Learn)

実行アカウントの権限が変わっていないかを見る

ドメイン環境や共有PCでは、GPO変更やアカウント変更で突然動かなくなることがあります。Microsoftは、Task Scheduler がユーザーを batch job として実行すること、Deny log on as a batch job があるとブロックされること、Access Denied の原因として権限不足や資格情報の不整合があることを案内しています。更新後にだけ失敗する場合も、まずはここを疑う価値があります。(Microsoft Learn)

タスク定義を作り直す

設定は正しいのに挙動だけおかしいときは、タスク定義の作り直しが有効です。Microsoftは、問題のあるタスクを XMLでエクスポートして再登録 する方法を案内しています。更新や資格情報変更のあとに不安定になったときは、同じ設定で作り直したほうが早く復旧することがあります。PowerShellで再登録する場合は、Register-ScheduledTask で ユーザー、パスワード、RunLevel を明示できます。(Microsoft Learn)

よくある失敗パターン

• 画面が消えたままなので失敗したと思い込む
  WakeToRun では画面が点灯しないことがあります。確認すべきは画面ではなく、履歴とログです。(Microsoft Learn)
• One Time トリガーなのに、取りこぼし後の自動再実行を期待する
  この組み合わせは復帰後の再実行でつまずきやすいです。定期トリガーに変えるだけで安定することがあります。(Microsoft Learn)
• GUIアプリを未ログオンで動かそうとする
  Excel操作や画面表示前提の処理は、非対話セッションでは不安定になりがちです。(Microsoft Learn)
• 「パスワードを保存しない」方式でNASや共有フォルダにアクセスしようとする
  この方式はローカル資源向けで、ネットワークや暗号化ファイルが絡むと失敗要因になります。(Microsoft Learn)
• バッテリー・アイドル・ネットワーク条件を付けたまま検証する
  条件が多いほど、スリープ復帰後の再現性は下がります。切り分け中はいったん減らすのが基本です。(Microsoft Learn)
• 相対パスのままタスク化する
  スクリプト本体が正しくても、WorkingDirectory 未設定だけで失敗します。(Microsoft Learn)

迷ったらこの順で進める

最初にやるべきことは、元の複雑なタスクをいったん脇に置き、単純なアクションで 「PCは起きるのか」「起きたあとタスクは起動するのか」 を分けて確認することです。たとえば cmd.exe /c echo %date% %time%>>C:\Temp\task-test.log のような簡単なログ出力タスクを作り、WakeToRun と wake timer の組み合わせを先に検証します。これで起きるなら問題は電源ではなく、元タスクの権限・条件・作業フォルダに絞れます。起きないなら電源設定とModern Standby側、起きるのに処理だけ失敗するならログオン方式と資格情報側を重点的に見直すのが最短です。(Microsoft Learn)