私は古いパソコンに Windows11 25H2 を入れて使っているのですが、約1年前に文字通り「たった1クリックのミス」で Windows11 が起動できなくなり、最終的に大事なデータがすべて消え去り、クリーンインストールする羽目になりました。
それ以来、バックアップソフトのスケジュール機能を使って、毎週いろいろなデータをバックアップするようにしています。
普段はパソコンの電源はシャットダウンしないでスリープにしているのですが、いつの頃からかは覚えていませんが、バックアップソフトが指定した時刻に自動スリープ解除できないのでスケジュールバックアップが自動実行されず、
- 翌日の午前中に私が手動でスリープ解除してから、前日深夜のスケジュールバックアップの処理が進む
という状態がずっと続いていました。
「出来の悪いWindows11だから仕方がないか。。。」と最近まで諦めていましたが、数ヶ月色々試行錯誤した末、ついにWindows11でバックアップの自動スリープ解除が100%成功するようになりました!
この記事では、Windows11でバックアップソフトが自動実行されない原因と解決策を徹底解説します。
解決策を大まかに書くと、
ググると簡単に見つかる解決策
- 【レジストリ】モダンスタンバイ(S0ix)を無効にする
- 【BIOS】S3(従来のスリープ)を有効にする
- 【レジストリ】高速スタートアップを無効にする
- 【電源オプション】スリープ解除タイマーの許可:有効
に加えて、
- 【電源オプション】システム無人スリープタイムアウト:0分
- 【デバイスマネージャー】キーボード以外のスリープ解除:OFF
※不要なUSBデバイスの復帰によるACPI(電源管理)の干渉を防ぐため - 【デバイスマネージャー】グラフィックボードのドライバー:最適なドライバーに入れ替える
※必ずしも最新のグラフィックドライバーが良いとは限らない
上記全てを修正・設定して、私は自動スリープ解除が100%成功するようになりました。
色々調べてここまでやるのに数ヶ月かかりました><
順番に解説します。
【レジストリ】モダンスタンバイ(S0ix)を無効にする
Winキー + Rにて、
regedit
と入力してエンター
↓
以下のキーへ移動
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power
↓
右側の空白部分で右クリックして、新規 → DWORD(32ビット)値にて、
PlatformAoAcOverride
を
1
に設定して追加する
↓
パソコンを再起動する
(任意)モダンスタンバイ(S0ix)が無効化されたか確認する
PowerShell を開き、以下を実行します。
powercfg /a正常に無効化されていれば、
- S0 低電力アイドル(S0ix) が 利用不可 と表示される
- S3(従来のスリープ) が 利用可能 と表示される※BIOS が対応している場合
■注意■
古いパソコン等の場合、「PlatformAoAcOverride:1」としなくても、後述の手順で BIOS にて S3(従来のスリープ)を有効にするだけでOKな場合もあります。
古いパソコンでは BIOS がモダンスタンバイ(S0ix)をサポートしていない場合があり、その場合は 「PlatformAoAcOverride:1」があってもなくても、BIOS にて S3(従来のスリープ)を有効にすればOKです。
私の古いパソコンではこの記事を書き始めた頃、つまりWindows11でバックアップの自動スリープ解除が100%成功するようになった段階でも「PlatformAoAcOverride:1」は存在していませんでした。
今も存在していません。
上記画像キャプチャを撮るために「PlatformAoAcOverride:1」を追加しただけで、その後「PlatformAoAcOverride」は削除しましたが、古いパソコンの場合はそのまま「PlatformAoAcOverride:1」を残しておいても問題ありません。
新しいパソコンの場合は、「PlatformAoAcOverride:1」を追加しておく必要があるかと思います。
【BIOS】S3(従来のスリープ)を有効にする
BIOSに入る
↓
「Advanced(詳細モード)」に切り替える
↓
ACPI / APM / Power Management 等の項目を探す
■注意■
メーカーによって名称が異なります。
- Advanced → ACPI Settings
- Advanced → Power Management
- Advanced → APM Configuration
- Chipset → ACPI Configuration
- Power → Suspend Mode
- Power → Sleep State
↓
「Suspend Mode」または「Sleep State」を S3 に変更する
ここもメーカーによって名称が異なります。
| BIOS 表記 | 意味 |
|---|---|
| Suspend Mode | スリープ方式の選択 |
| ACPI Sleep State | ACPI のスリープステート |
| S1 / S3 | 古い BIOS に多い表記。S3 が従来のスリープ |
| S3 Only | S3(従来のスリープ)のみ使用 |
| S0 Low Power Idle(Modern Standby) | モダンスタンバイ(S0ix) |
| S3 (Legacy Sleep) | 従来のスリープ(レガシー S3) |
設定すべきは、S3 または S3 Only または S3 (Legacy Sleep) です。
あるいは、S0 Low Power Idle(Modern Standby):無効 にするマザーボードもあります。
S3 が表示されない場合
S3 が表示されない場合、以下のどれかが原因です。
●BIOS が S3 をサポートしていない(最近のノートPCに多い)
この場合、レジストリでモダンスタンバイ(S0ix)を無効にしても S3 は出ません。
特に薄型ノートなど、モダンスタンバイ(S0ix)専用設計のパソコンではS3 が物理的に存在しない、あるいは、BIOS が S3 を ACPI テーブルから完全に削除しているため BIOS に S3 が無ければどうにもなりません。
つまり、ハードウェア仕様のため S3にするのは不可能です。
●Windows がモダンスタンバイ(S0ix)を要求している
レジストリでモダンスタンバイ(S0ix)を無効にすると S3 が出る場合があります。※後述
●BIOS の別項目が S3 を隠している
例、
- PTT(Intel Platform Trust)
- Fast Boot
- CSM(Compatibility Support Module)
- Secure Boot
これらが原因で S3 が非表示になることがあります。
これらの場合は
- PTT(Intel Platform Trust):Disabled(無効)
- Fast Boot:Disabled(無効)
- CSM(Compatibility Support Module):Enabled(有効)
- Secure Boot:Disabled(無効)
にすれば S3がBIOSに表示されるようになる場合もありますが、3つ目
- CSM(Compatibility Support Module):Enabled(有効)
にすると自動的に4つ目
- Secure Boot:Disabled(無効)
となり、セキュアブートが無効になる構成は Windows11 の要件を満たさないため、おすすめしません。
つまり、
- CSM(Compatibility Support Module):Enabled(有効)
- Secure Boot:Disabled(無効)
はおすすめしません。
【レジストリ】高速スタートアップを無効にする
■1つ目
Winキー + Rにて、
regedit
と入力してエンター
↓
以下のキーへ移動
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
↓
HiberbootEnabled をダブルクリックして、 「0」に変更します。
■HiberbootEnabled の値
- 0:高速スタートアップ 無効
- 1:高速スタートアップ 有効(デフォルト)
(任意)高速スタートアップを完全に消す場合
■2つ目
高速スタートアップを 設定箇所の UI から完全に消したい場合は、以下も 0 にします。
Winキー + Rにて、
regedit
と入力してエンター
↓
以下のキーへ移動
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power
↓
HiberbootEnabled をダブルクリックして、 「0」に変更します。
私は1つ目の
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
は「HiberbootEnabled:0」にしてありますが、2つ目の
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power
には「HiberbootEnabled」が存在していません。
2つ目の
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power
側の「HiberbootEnabled」は環境によって存在しない場合があり、高速スタートアップの無効化は1つ目の
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power
側の HiberbootEnabled を 0 にするだけで十分です。
【電源オプション】スリープ解除タイマーの許可:有効
Winキー + Rにて、
control powercfg.cpl
と入力してエンター
↓
「電源オプション」が開くので、現在の電源プラン(例:バランス)の右にある「プラン設定の変更」をクリック
↓
「詳細な電源設定の変更」 をクリック
↓
「スリープ」をクリック
↓
「スリープ解除タイマーの許可」をクリック
ここでスリープ解除タイマーを有効にします。
■ノートパソコンの場合
「スリープ解除タイマーの許可」をクリックして
バッテリ駆動:有効
電源に接続:有効
「重要なスリープ解除タイマーのみ」ではなく 必ず「有効」 に設定します。
ノートパソコンは持っていないので、画像キャプチャがなくてすみません。
m(_ _)m
↓
デスクトップパソコン・ノートパソコン、どちらの場合も「適用」をクリック
↓
「OK」をクリック
↓
電源オプションのウィンドウを閉じて、念のためパソコンを再起動します。
■注意■「重要なスリープ解除タイマーのみ」ではダメです。
Windows11 の「重要なスリープ解除タイマーのみ」は、
- Windows Update
- セキュリティメンテナンス
など、Microsoftが重要と判断したタスクのみ、スリープ解除を許可します。
バックアップソフト(Acronis TrueImage/Hasleo Backup Suite/ Macrium Reflect など)はOS側には重要扱いされないため、「重要なスリープ解除タイマーのみ」ではスリープ解除されないことが多々あります。
必ず「有効」にする必要があります。
【電源オプション】システム無人スリープタイムアウト:0分
Winキーを押して入力欄に
cmd
と入力してエンターは押さない
↓
「cmd.exe」を右クリックして「管理者として実行」をクリック
↓
そうすると管理者権限のコマンドプロンプトが起動しますので、以下のコマンドを実行
powercfg -attributes SUB_SLEEP 7bc4a2f9-d8fc-4469-b07b-33eb785aaca0 -ATTRIB_HIDE ここでパソコンの再起動は不要で、即座に反映されます。
コマンドプロンプトは閉じてしまってOKで、次に電源オプションを開きます。
Winキー + Rにて、
control powercfg.cpl
と入力してエンター
↓
「電源オプション」が開くので、現在の電源プラン(例:バランス)の右にある「プラン設定の変更」をクリック
↓
「詳細な電源設定の変更」 をクリック
↓
「システム無人スリープタイムアウト:0分」に設定します。
■ノートパソコンの場合
バッテリ駆動:0分
電源に接続:0分
ノートパソコンは持っていないので、画像キャプチャがなくてすみません。
m(_ _)m
↓
パソコンを再起動します。
■面倒■【デバイスマネージャー】キーボード以外のデバイスを「スタンバイ解除:OFF」にする
先に補足説明します。
キーボード以外のデバイスを「スタンバイ解除:OFF」にする理由
キーボード以外のデバイス、特にUSBマウス・USBハブ・USBオーディオなどのUSBデバイスが勝手にスリープ解除しても、この時点でスリープ解除されているので、
USBデバイスが勝手にスリープ解除しても、「システム無人スリープタイムアウト:0分」に設定してあれば、バックアップソフトのスケジュールバックアップ等は問題なく進行するのでは?
と疑問に思いますよね?
※デバイスマネージャーの表記は「スタンバイ解除」ですが、ここでは OSのスリープ復帰を指すため「スリープ解除」と表記しています。
私もそう思いましたが、実際は少し違うみたいです。
キーボード以外のデバイスを「スタンバイ解除:OFF」にする目的は、不要なUSBデバイスの復帰による ACPI(電源管理)の干渉を防ぐためです。
色々調べた限りでは、特にUSBマウス・USBハブ・USBオーディオなどのUSBデバイスが勝手にスリープ解除すると、ACPI のスリープ復帰処理が乱れて WakeTimer が失敗する原因になる可能性があります。
Windows の ACPI(電源管理)は非常に繊細で、USBデバイスが勝手にスリープ解除すると、
- ACPI のスリープ復帰処理が乱れる
- WakeTimer の復帰処理が割り込まれる
- バックアップソフトのスケジュール復帰が失敗する
という現象が起きます。
この不要なUSBデバイスの復帰による ACPI(電源管理)の干渉を防ぐために、キーボード以外のデバイスを「スタンバイ解除:OFF」にします。
海外フォーラムや技術情報を調べた限りでは、
はい、マウスも必ず「スタンバイ解除:OFF」にすべきです。
ただし、理由は「マウスが勝手にスリープ解除するから」ではなく、
“マウスがスリープ解除の原因になると WakeTimer の動作に影響する場合があるため” です。
という意見が多く見られました。
マウスやUSBデバイスがスリープ解除の原因になると、WakeTimer の動作に影響する場合があります。
※Microsoft が公式に仕様として明記しているわけではありませんが、実際の検証では、デバイスの誤作動が WakeTimer の復帰処理を妨げるケースが報告されています。
そのため、WakeTimer を安定させたい場合は、キーボード以外のスリープ解除を無効化しておくほうが安全です。
ということで、キーボード以外のデバイスを「スタンバイ解除:OFF」にする手順は以下の通りです。
デバイスマネージャーで「スタンバイ解除:OFF」にする手順
Winキーを押して入力欄に
devmgmt.msc
と入力してエンター
そうするとデバイスマネージャーが開きます。
■例、「マウスとそのほかのポインティング デバイス」の場合
「マウスとそのほかのポインティング デバイス」をクリック
↓
「HID 準拠マウス」等のデバイスを右クリックして「プロパティ」をクリック
↓
「電源の管理」タブを開く
↓
- コンピューターのスタンバイ状態を解除できるようにする:チェックOFF
に変更します。
■注意■
- マウスとそのほかのポインティング デバイス
- ユニバーサル シリアル バス コントローラー(USB)
- ヒューマン インターフェイス デバイス(HID)
- USB Root Hub / Generic USB Hub
等、キーボード以外の USBデバイスの全てに関して、
- コンピューターのスタンバイ状態を解除できるようにする:チェックOFF
に変更するわけですが、確認すべきデバイスの数が超たくさんあるので、けっこう大変です。
特に
- ネットワーク アダプター
- ヒューマン インターフェイス デバイス
- マウスとそのほかのポインティング デバイス
- ユニバーサル シリアル バス コントローラー(USB)
内の全てのデバイスは、しっかり確認することをオススメします。
たいていのパソコンで関係ありそうなデバイスは以下の通りです。
- ■マウスとそのほかのポインティング デバイス
- Bluetooth
- その他 USB デバイス
- ■ネットワークアダプター
- ■ヒューマン インターフェイス デバイス
および、ユニバーサル シリアル バス コントローラー内では
- ■Generic USB HubあるいはUSBハブ
- ■USB ルートハブ(USB 3.0)
- ■汎用 SuperSpeed USB ハブ
- ■汎用 USB ハブ
- ■USB入力デバイス
- USBオーディオ
- USB Wi-Fi
私の場合、上記一覧の中で
- 冒頭に■をつけてあるデバイス
が(キーボード以外で)「電源の管理」タブがあったデバイスです。
デバイスによっては
- コンピューターのスタンバイ状態を解除できるようにする:チェックOFF
が元々チェックOFFになっていて、かつ、グレーアウトしていて変更不可のデバイスもありましたが(たぶん私の場合は)
- 自分でBIOSでそのように設定した
- 昔レジストリを編集した
のどちらかかと思います。
以上のように、(日々の使用や業務に影響ない範囲で)キーボード以外全て
- コンピューターのスタンバイ状態を解除できるようにする:チェックOFF
に変更します。
ただし、「日々の使用や業務に影響ない範囲で」だと解決できない可能性もあります。
■注意■
キーボードは必ず
- 「コンピューターのスタンバイ状態を解除できるようにする:チェックON」
です。
キーボードも
- 「コンピューターのスタンバイ状態を解除できるようにする:チェックOFF」
にしてしまうと、手動でスリープ解除できなくなるのでご注意ください!
なお、上記デバイスマネージャーの全デバイスの画像キャプチャにて、「HID キーボード デバイス]等、末端まで展開してある(開いてある)デバイスが、私の場合で(キーボード以外で)「電源の管理」タブがあったデバイスです。
【デバイスマネージャー】グラフィックボードのドライバー:最適なドライバーに入れ替える※必ずしも最新のドライバーが良いとは限らない
私の古いパソコンのグラフィックボードはGTX960(2015年の Maxwell 世代)です。 今回、自動スリープ解除が失敗する件が解決するまでは、NVIDIA公式のグラフィックドライバー(GPUドライバー)は、
- バージョン581.57(2025年10月)
を使っていましたが、解決策の1つとして
- 472.12(2021年)
に変更しました。
わざわざ古いグラフィックドライバーにバージョンダウンして上書きした理由は、
- スリープ解除失敗の決定的な原因がグラフィックドライバーであるケースが非常に多い
からです。
順番に説明します。
なぜグラフィックドライバーがスリープ解除に影響するのか?
結論から言うと、
- グラフィックドライバーは ACPI(電源管理)と密接に連携しているため
です。
スリープ(S3)→ 復帰の流れでは、GPUは次の処理を行います。
GPU の電源を再投入
↓
PCI Express のリンク状態を再初期化
↓
ディスプレイ出力を再構築
↓
ACPI の復帰シーケンスと同期
このとき グラフィックドライバーが ACPI(電源管理)の期待どおりに動かないと、
- 画面が真っ暗のまま
- WakeTimer が動いても復帰が完了しない
- バックアップソフトのスケジュールが実行されない
といった問題が発生します。
特に、古いGPU(Kepler / Maxwell / Pascal) + 新しいドライバー + 新しい Windows の組み合わせは、電源管理まわりの最適化対象から外れやすく、スリープからの復帰処理が不安定になる、という傾向があります。
■注意■最新のドライバーが最適とは限らない理由
NVIDIAのドライバーは常に最新GPU向けに最適化されるため、古いグラフィックボードで逆に不安定になることがあります。
理由は以下のとおりです。
- 新しいドライバーは RTX3000/4000/5000 など最新世代向けの最適化が中心
- 古い GPU(GTX960 など)は「動けばOK」レベルの維持に留まる
↓
電源管理(ACPI)やスリープ復帰のテスト対象から外れやすい
↓
その結果、古い GPU では古いドライバーの方が安定する
私のパソコン(グラフィックボード:GTX960)の場合、
- 581.57(2025年10月) → WakeTimer 失敗
- 472.12(2021年12月) → 100%成功
となったのは、この典型例です。
つまり、
- 比較的新しいグラフィックボードの場合:最新のグラフィックドライバー(GPUドライバー)でOK
- 古いグラフィックボードの場合:最新のグラフィックドライバーだとスリープ復帰が失敗しやすいので、安定しやすいドライバーにする
ということになります。
GPU世代ごとの”安定しやすいドライバー”の傾向
以下、私が調べた範囲での、GPU世代ごとの”安定しやすいドライバー”の傾向です。
| GPU 世代 | アーキテクチャ | 安定しやすいドライバー |
|---|---|---|
| GTX700 / GTX900 | Kepler / Maxwell | 472.12(2021年) |
| GTX1000 | Pascal | 2022〜2023年版 |
| RTX2000 | Turing | 2023〜2024年版 |
| RTX3000 / RTX4000 / RTX5000 | Ampere / Ada | 最新ドライバーが最適 |
つまり、
- 古いグラフィックボードほど、少し前のドライバー の方が安定しやすい
ということになります。
NVIDIA・AMDの各GPUに関する、世代ごとの安定しやすいドライバーバージョン は後述します。
現在使用中のグラフィックボードの名称・ドライバーのバージョンの調べ方 & どのドライバーを入れるべきか?
まず、
- 現在使用中のグラフィックボードの名称の調べ方
- 現在使用中のドライバーのバージョンの調べ方
を説明します。
その後で、
- どのドライバーを入れるべきか?
を説明します。
現在使用中のグラフィックボードの名称の調べ方
Winキーを押して入力欄に
devmgmt.msc
と入力してエンター
そうするとデバイスマネージャーが開きます。
↓
「ディスプレイアダプター」を開く
↓
そうすると、グラフィックボードの正式名称が表示されます。
現在使用中のドライバーのバージョンの調べ方
そのまま「グラフィックボードの名称」を右クリック
↓
「ドライバー」タブの「バージョン」の箇所の番号をコピーする
上記画像キャプチャですと「バージョン:30.0.14.7212」が正式な呼び方ですが、実際は「バージョン:472.12」のほうが一般的です。
NVIDIAの場合は、下4桁の「4.7212」でもってGoogle等で「グラフィックドライバー 4.7212」と検索すると「バージョン:472.12」がわかるかと思います。
つまり、上記2つの画像キャプチャですと
- グラフィックボード:GTX960
- ドライバーのバージョン:472.12
となります。
●どのドライバーを入れるべきか?(GPU世代ごとの安定しやすいドライバーバージョン)
以下、私が解決した当時に少し調べた限りでの、GPU世代ごとの安定しやすいドライバーバージョンです。
下の表で、自分の「GPU世代」を確認し、右側の「安定しやすいドライバー」を選んでください。
先ほどのデバイスマネージャーの「グラフィックボードの名称」の箇所で、「GeForce」と書いてあれば NVIDIA、「Radeon」と書いてあれば AMD です。
■NVIDIAのグラボの場合
| GPU世代 | アーキテクチャ | 安定しやすいドライバー |
|---|---|---|
| GTX700 / GTX900 | Kepler / Maxwell | 472.12(2021年) |
| GTX1000 | Pascal | 527.xx / 531.xx(2022〜2023年) |
| RTX2000 | Turing | 537.xx / 546.xx(2023〜2024年) |
| RTX3000 / RTX4000 / RTX5000 | Ampere / Ada | 最新ドライバーが最適 |
■AMDのグラボの場合
| GPU世代 | アーキテクチャ | 安定しやすいドライバー |
|---|---|---|
| Radeon RX 400 / 500 | Polaris | Adrenalin 21.11.3(2021年) |
| Radeon RX Vega 56 / 64 | Vega | Adrenalin 22.5.1(2022年) |
| Radeon RX 5000 | RDNA1 | Adrenalin 22.11.2(2022年) |
| Radeon RX 6000 | RDNA2 | Adrenalin 23.5.2(2023年) |
| Radeon RX 7000 | RDNA3 | 最新ドライバーが最適 |
ただし、AMD は NVIDIA と違い、
- 古いGPU(Polaris / Vega / RDNA1)は “2021〜2022 年のドライバー” が安定しやすい
- 新しいGPU(RDNA2 / RDNA3)は最新ドライバーが最適
という傾向があるみたいですので、ご注意ください。
NVIDIA も AMD も共通して、古いGPUでは新しいドライバーが不安定になることがあります。
ただし、(私が調べた限りでは)不安定になる理由の仕組みが少し異なります。
- NVIDIA はGPU世代ごとに最適化が終了するため、古い世代(Kepler / Maxwell / Pascal)では新しいドライバーが最適化されず不安定になりやすいです。
- AMD は「ドライバーの年度(Adrenalin 20xx)」ごとに最適化が変わるため、古い世代(Polaris / Vega / RDNA1)では 2021〜2022 年のドライバーが安定しやすいです。
そのため、どちらのメーカーでも
- 古いGPUほど、少し前のドライバーのほうが安定しやすい
という傾向があります。
ドライバーの入れ替え手順(NVIDIA DDU → クリーンインストール)
スリープ関連の不具合は、グラフィックドライバーの上書きインストールでは改善しないケースが多いです。
理由としては、古いドライバーの設定ファイルやレジストリが残り、電源管理(ACPI)まわりの挙動に影響することがあるためです。
そのため、再現性を高める方法としては、
- DDU(Display Driver Uninstaller)で完全削除 → クリーンインストール
が最も確実です。
ただし、私の環境(GTX960)では、DDU を使わずに
- 581.57(2025年10月) → 472.12(2021年12月)
へ上書きでバージョンダウンしただけで、スリープ解除の不具合が完全に解消しました。
これは、同時に行った電源設定の改善(システム無人スリープタイムアウト:0分、キーボード以外のスリープ解除:OFF)と、472.12 が Maxwell 世代の最終安定版であることが重なった結果と考えられます。
つまり、
- 電源設定の改善で安定した可能性
- ドライバーのバージョン変更で安定した可能性
- 両方が組み合わさって安定した可能性
のいずれも考えられます。
スリープ復帰の不具合は複合要因で発生することが多いため、電源設定とドライバーの両方を見直すのが最も確実です。
スリープ復帰の不具合は複合要因で起きることが多い
なお、今回の私のケースでは「581.57 → 472.12」へのバージョンダウンでスリープ解除が安定しましたが、色々同時に設定変更した項目もあるため、必ずしも「ドライバーだけが原因だった」と断定できるわけではありません。
同時に行った、
- システム無人スリープタイムアウト:0分
- キーボード以外のスリープ解除:OFF
といった電源設定の変更も、自動スリープ解除の成功率を大きく上げる要因です。
そのため、
- 電源設定の改善で安定した可能性
- ドライバーのバージョン変更で安定した可能性
- 両方が組み合わさって安定した可能性
のいずれも考えられます。
スリープ復帰の不具合は複合要因で起きることが多いため、電源設定とドライバーの両方を見直すのが最も確実です。
もちろん、前々から設定してあった
- モダンスタンバイ(S0ix):無効
- S3(従来のスリープ):有効
- 高速スタートアップ:無効
- スリープ解除タイマーの許可:有効
は必須です。
■注意■バックアップと復元(Windows 7)は、自動スリープ解除できない仕様です。。。
Windows10 / 11に標準搭載されている「バックアップと復元(Windows 7)」ですが、これは設計が古く、WakeTimer を発行して自動スリープ解除する機能に対応していません。
そのため、指定した時刻(例:毎週日曜 3:00)に PC がスリープ中の場合、バックアップは開始されず、次にユーザーが手動でスリープ解除したタイミングで遅延実行されます。
実際に私の環境でも、2026/5/10 のバックアップが 3:00 ではなく 11:21 に実行されましたが、これは不具合ではなく、この仕様によるものです。
なお、「Acronis TrueImage」「Hasleo Backup Suite」などのバックアップソフトは
- WakeTimer に対応しているため、スリープ中でも自動的にスリープ解除してバックアップを実行できます。
- バックアップ完了後に再度スリープするように設定可能です。
なお「バックアップと復元(Windows 7)」でバックアップする場合は、タスクスケジューラに「指定時刻にスリープ解除するタスク」を自分で登録することで 指定時刻にスリープ解除してバックアップを実行することは可能ですが、「Acronis TrueImage」「Hasleo Backup Suite」などのバックアップソフトみたいに、バックアップ完了後に再度スリープするようには設定できない、という点に注意が必要です。
AutoHotkeyを使って「バックアップと復元(Windows 7)」のバックアップ完了を監視して、バックアップ完了したらスリープにすることも可能かもしれませんが、日中の使い勝手が悪くなるので私はこのまま放置しています。
Windows11で自動スリープ解除が失敗する原因と解決策は以上です。
なお、Windows11標準の「バックアップと復元(Windows 7)」の使い勝手の悪さだけではなく、
Windows11そのものについても、さまざまな不満の声が多く見られます。
- Explorer(ファイルマネージャー)は、遅い・固まる・右クリックが使いづらい等、色々おかしい
- 設定(設定アプリ)が直感的ではなく、かゆいところに全く手が届かない
- Windows Update のたびに別の不具合が発生することがある
こうした点が、Windows11に対する評価が良くない理由の一つになっているかと思います。
最近も「Windows 11 Insider」ビルドで『Low Latency Profile(※後述)』を実験しているみたいですが、そもそも通常のWindows10 / 11の電源オプションで「バランス」に設定してあれば、『Low Latency Profile』と同じ仕組みで動いているのでは?と私は疑問に思います。

※低遅延プロファイル・・・Windows11のパフォーマンスを改善するために、現在Microsoftが開発中の機能。スタートメニューやコンテキストメニュー表示時、アプリの起動時などにCPUのクロックを1~3秒ほど高めることで、これらの表示速度・起動速度を短縮する効果があるとされています。
実際「電源オプション:バランス」に設定してある私のパソコンは、
- 普段のCPUは1,605MHzで動いている
- Explorerでフォルダをクリックした時やアプリを開く時などは、瞬時に3,510MHzになる
といった挙動です。
私の「Windows11の評価」は
のままです。
