スリープ・休止・Modern Standbyと長時間稼働アプリ ── 「夜中に止まっていた」を設計で防ぐ

「監視アプリを夜通し動かしていたはずが、朝見たらグラフが深夜1時で止まっていた」「デスクトップPCでは何か月も安定していた収集ツールが、ノートPCに置き換えた途端に記録が歯抜けになった」── 長時間動き続ける業務アプリの相談で、この症状は定番中の定番です。ログを見ると例外もクラッシュもなく、ただ数時間分の記録がすっぽり抜けている。犯人はアプリのバグではなく、Windowsの電源管理であることが非常に多いのです。

厄介なのは、「スリープ」と一口に言っても中身が1種類ではないことです。従来のS3スリープ、休止状態(S4)、そして近年のノートPCで主流のModern Standby(S0 low power idle)では、アプリから見える止まり方も、対策の効き方も違います。特にModern Standbyは「スリープ中もシステムは動いている」という触れ込みから誤解されがちですが、デスクトップアプリはむしろ積極的に止められます。

この記事では、スリープの種類とスリープ中のアプリの挙動を最低限だけ押さえたうえで、「スリープをさせない」「スリープを前提にする」「決まった時刻に起こす」という3つの設計をどう使い分けるかを、実装例と判断表つきで整理します。

1. まず結論

• Windowsのスリープには従来のS3スリープ・休止状態(S4)・Modern Standby(S0 low power idle)があり、Modern Standby対応機はS1〜S3をサポートしません。自分のPCがどれかは powercfg /a で確認できます。¹²³
• Modern Standby中もデスクトップアプリは動き続けません。DAM(Desktop Activity Moderator)がデスクトッププロセスのスレッドをサスペンドします(セッション0のサービスはスロットリング)。「S0だから動くはず」という前提で設計しないでください。⁴
• スリープ中はスレッドが実行されず、タイマーの期限の数え方もAPIの世代で異なります。Windows 8以降、相対指定のタイマーや待機(SetWaitableTimer の相対指定、SleepEx 等)はスリープ中カウントが進まず、残り時間を復帰後に持ち越します。⁵⁶ .NETのタイマーは .NET 10 まではスリープ時間を数える実装(スリープ中に期限が来ていれば復帰直後に発火)で、.NET 11 から数えない方式に変わります。⁶ 経過時間APIも、スリープ時間を含むもの(GetTickCount、QueryPerformanceCounter=Stopwatch)と含まないもの(QueryUnbiasedInterruptTime)が混在します。⁷⁸
• スリープ中にアイドルになったTCP接続は、NAT・ファイアウォール・ロードバランサーなどの中間機器のアイドルタイムアウトで黙って破棄されていることがあります(例: Azure Load Balancerの既定は4分で通知なしドロップ)。復帰後は再接続前提で設計します。⁹⁴
• スリープを抑止する正攻法は SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED) です。ただし効くのは無操作タイムアウト起因の自動スリープだけで、ユーザーが電源ボタンやふた閉じで指示したスリープは防げません。必要な区間だけ設定し、終わったら必ずクリアします。¹⁰¹¹
• 抑止が効いているかは powercfg /requests で確認できます。PowerCreateRequest 系APIなら要求に理由文字列を付けられ、この一覧に表示されるため運用調査に強くなります。¹²¹³¹⁴
• スリープを前提にするなら、.NETでは SystemEvents.PowerModeChanged、Win32では WM_POWERBROADCAST(PBT_APMSUSPEND / PBT_APMRESUMEAUTOMATIC)で検知します。サスペンド通知の猶予は1アプリあたり約2秒しかなく、バッテリー切迫時は通知なしでスリープすることもあります。^15161718
• 決まった時刻に確実に動かすなら、タスクスケジューラの「タスクの実行時にスリープを解除する」(WakeToRun)が第一候補です。タスク完了までシステムを起きたままにしてくれます。ただし電源オプションのウェイクタイマー許可に依存するため、実機での起床確認が必須です。¹⁹²⁰

2. Windowsのスリープは1種類ではない

最初に、対策を考える前提となる3つの状態だけ押さえます。

S3とS4は「システムが計算タスクを何も実行していない、見かけ上オフの状態」です。¹ 一方Modern Standbyは、スマートフォンの電源モデルに近い方式で、画面オフ中もネットワーク接続を維持したまま低電力で待機し、電源ボタンから1秒未満で復帰します。Modern Standbyをサポートする機種はS1〜S3を使いません。²²¹

ここで重要なのが、Modern Standby対応機に載っているDAM(Desktop Activity Moderator)です。DAMはスタンバイ突入時にデスクトップアプリの実行をS3スリープと同等になるよう抑え込む仕組みで、対話セッションのプロセスは全スレッドがサスペンドされ、セッション0のサービスはスロットリング(大半の時間サスペンドされ、断続的にだけ実行)されます。⁴ つまり「Modern Standbyならスリープ中もアプリが動くのでは」という期待は逆で、アプリ視点ではS3と同じく止まる、しかもS3と違って「システム自体は動いているのにアプリだけ止まる」ため、時刻のずれやタイマー挙動の不整合として現れる、と理解しておくのが安全です。⁴

自分のPC(顧客の現場のPC)がどちらの方式かは、管理者不要で次のコマンドで確認できます。³

> powercfg /a
以下のスリープ状態がこのシステムで利用可能です:
    スタンバイ (S0 低電力アイドル) ネットワークに接続されています
    休止状態
    ...

スタンバイ (S3) と出ればS3機、S0 低電力アイドル と出ればModern Standby機です。「ノートPCに変えたら記録が抜けるようになった」という相談では、まずこれを確認します。

3. スリープ中・復帰後にアプリはどうなるか

3.1. スレッドとタイマー

スリープ中(S3/S4、およびDAMサスペンド中)はスレッドが実行されません。¹⁴ 見落とされがちなのは、タイマーや待機の「期限」がスリープ時間をどう数えるかで、これはAPIの層によって扱いが分かれます。

• Win32の相対タイマー(SetWaitableTimer / SetWaitableTimerEx の相対指定)は、Windows 7以前は低電力状態の時間もカウントに含めていました(スリープ中もカウントダウンが進む)が、Windows 8以降は含めません。スリープをまたいだ相対タイマーは、復帰後に残り時間ぶん待ってから発火します。⁵
• 一方、タイムアウトを指定する待機API(SleepEx / WaitForMultipleObjectsEx など)は、Windows 8以降、スリープ等の非稼働時間をカウントしません。残り時間はスリープをまたいで持ち越されます。⁶
• .NETのマネージドタイマー(System.Threading.Timer 等)の発火タイミングは、ランタイムのバージョンで変わります。Environment.TickCount64 が .NET 10まではスリープ時間を含み(GetTickCount64ベース)、.NET 11からは含まない(QueryUnbiasedInterruptTimeベース)に変更されるためで、変更ドキュメント自身が「復帰直後にタイマーが発火しなくなるコードがあり得る」と注意しています。⁶

つまり「10秒間隔の System.Threading.Timer で計測していたアプリが8時間スリープした」場合、8時間分がまとめて発火することはどのみちありませんが、復帰直後に1回すぐ発火するのか、残り時間を待ってから発火するのかは、APIの層とランタイムのバージョン次第です。どちらにせよスリープ中のサンプルは欠測になります。「復帰直後の発火」に依存して立て直し処理を組むのではなく、第5章の復帰イベントで明示的に再スケジュールするのが安全です。

3.2. 経過時間の計測がずれる

経過時間APIには、スリープ時間を含むものと含まないものが混在しています。

「Stopwatchで10秒たったら次のサンプル」というコードは、スリープをまたぐと「8時間と10秒たった」ことになりますし、逆にTickCountベースの経過判定は .NET 11 移行で挙動が変わります。「処理にかかった時間」はStopwatch、「次に動くべき壁時計時刻」は DateTime/DateTimeOffset で管理し、復帰イベント(第5章)で基準を取り直す、という役割分担にしておくと、スリープにもランタイム更新にも振り回されません。短周期タイマーの設計自体の話は「WindowsでSleep(1)よりイベント待機を優先すべき理由」で扱っています。

3.3. TCP接続は「黙って」死んでいる

スリープ中、アプリは通信できないので接続はアイドルになります。問題は経路上の機器です。NATやファイアウォール、ロードバランサーといった中間機器はアイドルなフローをタイムアウトで破棄しますが、多くの構成では破棄を両端に通知せず黙って落とします。たとえばAzure Load Balancerの既定動作は「アイドルタイムアウト(既定4分)に達したフローをサイレントにドロップ」です。⁹ 社内のルーターや装置側の組み込みTCPスタックにも同種のタイムアウトはあります。

その結果、復帰後のアプリのソケットは一見正常なまま、次の送信でエラーになるか、応答待ちでタイムアウトまで固まります。DAMのドキュメントも、プロセスサスペンドが接続の寿命やハンドシェイクに与える影響を考慮するよう明記しています。⁴ さらにModern Standby機では、バッテリー駆動時は既定でスリープ中のネットワーク活動そのものが静止されます(Adaptive Connected Standby)。²³ 復帰イベントを受けたら接続は疑って破棄・再接続するのが定石です。接続が「生きているように見えて死んでいる」問題の切り分けは「TCP再送で産業用カメラ通信が止まる原因と切り分け」も参考にしてください。

4. スリープを「させない」 ── SetThreadExecutionStateと電源要求

計測中の数時間だけはスリープされては困る、という場合の正攻法が SetThreadExecutionState です。C#からはP/Invokeで呼びます。

using System.Runtime.InteropServices;

internal static class PowerGuard
{
    [Flags]
    private enum EXECUTION_STATE : uint
    {
        ES_CONTINUOUS       = 0x80000000,
        ES_SYSTEM_REQUIRED  = 0x00000001,
        ES_DISPLAY_REQUIRED = 0x00000002,
    }

    [DllImport("kernel32.dll", SetLastError = true)]
    private static extern EXECUTION_STATE SetThreadExecutionState(EXECUTION_STATE esFlags);

    /// <summary>計測開始時に呼ぶ: 自動スリープを抑止する(Endと同じスレッドから呼ぶこと)</summary>
    public static void Begin() =>
        SetThreadExecutionState(EXECUTION_STATE.ES_CONTINUOUS |
                                EXECUTION_STATE.ES_SYSTEM_REQUIRED);

    /// <summary>計測終了時に必ず呼ぶ: 抑止を解除する(Beginと同じスレッドから呼ぶこと)</summary>
    public static void End() =>
        SetThreadExecutionState(EXECUTION_STATE.ES_CONTINUOUS);
}

押さえるべき仕様は次のとおりです。

• ES_CONTINUOUS を付けると、次に ES_CONTINUOUS 付きで呼び直すまで効果が持続します。付けない場合はアイドルタイマーを1回リセットするだけなので、持続させたければ定期的に呼び続ける必要があります。¹⁰
• ES_SYSTEM_REQUIRED はシステムのスリープを、ES_DISPLAY_REQUIRED はディスプレイオフを抑止します。バックグラウンド計測なら前者だけで十分です。画面は消えてよいのに ES_DISPLAY_REQUIRED まで立てるのは電力の無駄です。¹⁰
• ユーザーが電源ボタンを押した・ふたを閉じたことによるスリープは防げません。この関数が効くのは無操作タイムアウト起因の自動スリープだけです。ユーザーの明示操作は尊重すべきである、と公式ドキュメントにも明記されています。¹⁰
• システムは SetThreadExecutionState を呼んだスレッドを数えており、カウントがゼロになりユーザー入力もなければスリープに入ります。¹¹ プロセスが異常終了すれば抑止も消えるので、「抑止したまま解除し忘れて永遠にスリープしないPC」になる心配は再起動すれば解消しますが、逆に言えばクラッシュ耐性の担保にはなりません。
• 名前のとおり、この関数が設定するのは呼び出したスレッドの実行状態です。¹⁰ 設定と解除は同じスレッドで行ってください。async/await の継続は別のスレッドプールスレッドで実行されることがあるため、await を挟んで Begin() と End() を呼ぶ実装では、解除がスリープ抑止を立てたのとは別のスレッドで空振りし、元のスレッドが生きている間ずっと抑止が残り続けます。UIスレッドのように同一性が保証されるスレッドに固定して呼ぶのが安全で、スレッドをまたぐ設計が必要ならこの後で触れるハンドルベースの電源要求APIを使ってください。

Windows 7以降には、同じ目的のより新しいAPIとして電源要求(PowerCreateRequest / PowerSetRequest / PowerClearRequest)もあります。こちらは要求作成時に REASON_CONTEXT で理由の文字列を渡せるのが実務上の利点で、要求種別には PowerRequestSystemRequired のほか、Modern Standby機でのプロセスサスペンドを抑止する PowerRequestExecutionRequired があります。¹⁴¹³ 公式のベストプラクティスは「シナリオ直前にSet、終わったら即Clear、プロセス終了前にハンドルを後始末」です。¹³

ただしModern Standby機には重要な制限があります。バッテリー駆動のModern Standbyシステムでは、SystemRequired/ExecutionRequired要求はスリープタイムアウト超過の5分後に打ち切られます。また電源方式を問わず、ユーザー操作(電源ボタン・ふた閉じ・スタートメニューのスリープ)によるスリープ突入時には要求は終了します。¹³ つまり「ノートPCで、ふたを閉じられても、バッテリーでも動き続ける」はアプリの努力では実現できません。そういう要件は電源設定と運用(ふたを閉じてもスリープしない設定、AC給電)で担保するものです。

抑止が実際に効いているかは、管理者権限のコマンドプロンプトで確認できます。

> powercfg /requests
SYSTEM:
[PROCESS] \Device\HarddiskVolume3\Apps\SensorLogger.exe

powercfg /requests はスリープ・画面オフを妨げている電源要求を列挙するコマンドで、「なぜかスリープしないPC」の調査にも、自アプリの抑止確認にも使えます。¹² 逆に、管理者が powercfg /requestsoverride で特定プロセスの要求を無視する設定を入れられることも知っておいてください。¹² 抑止APIは「お願い」であって絶対ではない、というのが設計の前提です。

最後に行儀の話です。アプリ起動中ずっと ES_CONTINUOUS | ES_SYSTEM_REQUIRED を立てっぱなしにする実装は、ユーザーが設定した電源プランを常駐アプリが恒久的に殺すことを意味します。ノートPCならバッテリーを消耗させ、共有PCなら他の用途にも影響します。抑止は「スリープされては困る処理が実際に走っている区間」だけに絞るのが原則です(公式ドキュメントの例も「録画開始で設定、録画完了でクリア」です¹⁰)。なお、ユーザー側の一時的な回避策としてはPowerToys Awakeがあり、これも内部的には同じ仕組み(実行状態を要求するスレッド)で動いています。²⁴ アプリに抑止を実装するか、運用ツールに任せるかの線引きにも使えます。

5. スリープを「前提にする」 ── 検知・再接続・欠測記録

常駐監視や収集アプリの多くは、スリープを禁止するよりもスリープと共存するほうが筋のよい設計になります。必要なのは「入る前に知る」「復帰を知る」「復帰後に立て直す」の3点です。

.NETでは Microsoft.Win32.SystemEvents.PowerModeChanged が入口です。¹⁵

using Microsoft.Win32;

SystemEvents.PowerModeChanged += OnPowerModeChanged;

private void OnPowerModeChanged(object sender, PowerModeChangedEventArgs e)
{
    switch (e.Mode)
    {
        case PowerModes.Suspend:
            // 猶予は短い: バッファをフラッシュし、計測停止時刻を記録するだけに絞る
            _logger.Info("suspend at {0:O}", DateTimeOffset.Now);
            _collector.Pause();
            break;

        case PowerModes.Resume:
            // 1) 欠測区間をデータとして残す
            _logger.Info("resume at {0:O}", DateTimeOffset.Now);
            // 2) 接続は死んでいる前提で破棄して再接続
            _connection.Reset();
            // 3) 壁時計基準でスケジュールを再計算してタイマーを張り直す
            _scheduler.Rebase(DateTimeOffset.Now);
            // 4) 立て直しが済んでから収集を明示的に再開する(Pauseしたままにしない)
            _collector.Resume();
            break;
    }
}

このイベントには2つの注意点が公式に明記されています。メッセージポンプが回っていないと発生しないこと(Windowsサービスでは隠しフォーム等が必要)、そしてstaticイベントなので購読解除を怠るとリークすることです。¹⁵ GUIアプリなら素直に使えますが、コンソール/サービス型の収集アプリでは、Win32の WM_POWERBROADCAST を受けるメッセージウィンドウを自前で用意するか、HWNDなしでコールバックを受けられる PowerRegisterSuspendResumeNotification を使います(DAM環境での通知もこの経路です)。⁴¹⁶

Win32レベルのイベントの意味も押さえておきましょう。

• PBT_APMSUSPEND: スリープ直前の通知。1アプリあたり約2秒しか猶予がなく、超過するとシステムに中断されることがあります。ここでやるのはフラッシュと時刻記録程度に絞り、ネットワーク越しの後始末のような時間のかかる処理を書いてはいけません。¹⁷¹⁸
• PBT_APMRESUMEAUTOMATIC: 復帰のたびに必ず届く通知。再接続・再スケジュールはここに書きます。²⁵
• PBT_APMRESUMESUSPEND: ユーザーの操作で(またはユーザーが戻ってきて)復帰した場合に、PBT_APMRESUMEAUTOMATICの後に届きます。リモートウェイク等の自動復帰では届かないため、「復帰処理」をこちらだけに書くと無人復帰時に立て直しが走りません。²⁶
• さらに、バッテリー切迫などのクリティカルなスリープ突入では事前通知そのものが来ません。¹⁸ Suspendイベントを受け取れなかったケースでも復帰処理が成立するよう、Resume側を冪等に書いておきます。

もう1つ、復帰対応と同じくらい大事なのが欠測を欠測として記録することです。スリープをまたいだ収集データは「値がない」のではなく「システムが止まっていたので測っていない」のであり、その区間をsuspend/resumeの時刻つきでログとデータの両方に残しておくと、後からグラフの空白を見た人が障害と混同しなくなります。長期稼働アプリのログに何を残すべきかという観点は「産業用カメラ長期稼働クラッシュ調査 - ハンドルリーク編」でも扱っています。

なお、スリープと似た「気づいたら遅くなっていた」系の問題として、Windows 11の効率モード(EcoQoS)による抑制もあります。こちらは「Windows効率モードとは - 緑の葉アイコンとオフにする方法」を参照してください。

6. 決まった時刻に確実に動かす ── タスクスケジューラの起床実行

「深夜2時に集計して転送する」のような時刻起点の処理を、常駐アプリのタイマー+スリープ抑止で実現するのは筋がよくありません。夜通しスリープを殺すことになるからです。この用途はタスクスケジューラの「タスクの実行時にスリープを解除する」(WakeToRun)が本命です。

WakeToRunを有効にしたタスクは、実行時刻にスリープ・休止からコンピューターを起床させ、タスクが完了するまでシステムを起きたままにします(すでに起きていた場合も完了まで維持を要求します)。起床時に画面は消えたままのことがありますが、それで正常です。¹⁹

ただし、起床が成立するには条件があります。公式のトラブルシューティングにも挙げられているとおり、電源オプションの「スリープ解除タイマーの許可」(Allow Wake Timer)が有効であること、BIOS側のウェイク設定が有効であることが前提で、近年のノートPCは省電力設計上ウェイクを許可しない構成も珍しくありません。²⁰ powercfg /waketimers で現在有効なウェイクタイマーを列挙できるので¹²、導入先の実機で「本当に起きるか」を必ず検証してください。自前アプリで起床させたい場合は、SetWaitableTimer の fResume にTRUEを渡すウェイク可能タイマーという手段もあります。このときシステムは自動起床後、無人アイドルタイマー(最低2分)の間だけ起きており、アプリが SetThreadExecutionState で「使用中」を宣言しなければ速やかに再スリープします。起床後の処理が長い場合は第4章の抑止と組み合わせる、というのが正しい合わせ技です。²⁷

タスク自体の実行アカウント・0x1で終わる問題・多重起動防止といった運用設計は「タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計」にまとめています。

7. 判断表 ── 抑止か、復帰対応か、起床か

3つの設計は排他ではなく、アプリ種別ごとに主・従を決めて組み合わせるものです。

判断の軸は2つです。「止まってよい時間帯があるか」(あるならタスクスケジューラ、ないなら電源設定)と、「誰のPCで動くか」(ユーザーの私物・共用ノートで動くアプリほど、抑止ではなく復帰対応に寄せる)です。

8. まとめ

• スリープにはS3・休止(S4)・Modern Standby(S0 low power idle)があり、powercfg /a で判別できます。Modern Standby機でもデスクトップアプリはDAMでサスペンドされるため、「スリープ中も動く」前提は成立しません。
• スリープ中はスレッドもタイマーも進みません。Windows 8以降、相対タイマー・待機はスリープ時間を数えず残り時間を持ち越し、.NETのタイマーも .NET 11 から同じ挙動になります(.NET 10までは復帰直後に発火し得ます)。経過時間APIはスリープ時間を含む/含まないが混在します。経過はStopwatch、壁時計はDateTimeで持ち、復帰時に基準を取り直してください。
• TCP接続は中間機器のアイドルタイムアウトで黙って死にます。復帰イベントで破棄・再接続が定石です。
• 抑止は SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED) を必要区間だけ。ユーザー操作のスリープは防げず、Modern Standby機のバッテリー駆動では5分で打ち切られます。確認は powercfg /requests。
• 復帰対応は SystemEvents.PowerModeChanged / WM_POWERBROADCAST で。サスペンド通知の猶予は約2秒、通知なしのスリープもあるため、Resume側を冪等に書き、欠測区間を記録します。
• 定時実行はタスクスケジューラのWakeToRunが本命。ウェイクタイマーの電源設定と実機での起床確認まで含めて設計してください。

関連記事

• タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計
• WindowsでSleep(1)よりイベント待機を優先すべき理由
• TCP再送で産業用カメラ通信が止まる原因と切り分け
• 産業用カメラ長期稼働クラッシュ調査 - ハンドルリーク編
• Windows効率モードとは - 緑の葉アイコンとオフにする方法

関連する相談領域

合同会社小村ソフトでは、計測・監視・データ収集など長時間稼働するWindowsアプリの設計と実装、「夜中に止まっていた」「記録が歯抜けになる」といった長期稼働特有の不具合の調査を扱っています。スリープ・電源管理が絡む再現しづらい症状の切り分けもご相談ください。

• Windowsアプリ開発
• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

アプリ実行中だけPCをスリープさせないようにするには?

SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED) を処理の開始時に呼び、終了時に SetThreadExecutionState(ES_CONTINUOUS) でクリアするのが基本です。画面も点けたままにしたい場合だけ ES_DISPLAY_REQUIRED を足します。効くのは無操作タイムアウトによる自動スリープだけで、ユーザーが電源ボタンやふたを閉じて指示したスリープは防げません。抑止が効いているかは powercfg /requests で確認できます。

Modern Standbyとは何ですか? 従来のスリープと何が違いますか?

S0 low power idleとも呼ばれる新しいスリープ方式で、システムは低電力ながら部分的に動作し続け、瞬時に復帰できるのが特徴です。Modern Standby対応機は従来のS3スリープをサポートしません。ただし「動き続ける」のはOSが許可した活動だけで、デスクトップアプリはDAM(Desktop Activity Moderator)によりスレッドごとサスペンドされるため、アプリ視点ではS3と同様に止まります。自分のPCがどちらの方式かは powercfg /a で確認できます。

スリープ復帰後にTCP接続が使えなくなるのはなぜですか?

スリープ中はアプリが通信できないため接続がアイドル状態になり、経路上のNAT・ファイアウォール・ロードバランサーなどの中間機器がアイドルタイムアウトでフローを破棄するためです。多くの機器は破棄を通知せず黙って落とすので、アプリ側のソケットは一見正常なまま、復帰後の最初の送受信で初めてエラーになるか、タイムアウトまで固まります。復帰イベントを受けたら接続を疑って作り直すのが定石です。

夜間バッチを確実に動かすにはスリープ抑止とタスクスケジューラのどちらがよいですか?

タスクスケジューラの「タスクの実行時にスリープを解除する」(WakeToRun)が第一候補です。実行時刻にPCを起床させ、タスク完了まで起きたままにしてくれるため、夜通しスリープを殺しておく必要がありません。ただしウェイクタイマーが電源オプションで無効だと起床しないので、「スリープ解除タイマーの許可」の設定と実機での起床確認が必須です。常時スリープ抑止は、その間の電力を無駄にするうえユーザーの電源設定を上書きする行儀の悪い設計になります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。