「スリープに入れたのに、10分ほどで勝手に起動する」。Windows 10 Homeでは未適用の更新プログラムや電源設定、デバイスの待機機能が複合してこの症状を引き起こします。本記事は原因の切り分けから恒久対策、再発防止の運用までを“Home版でも実行可能”な具体策で徹底解説します。
Windows 10 Homeが「更新プログラム待ち」で勝手にスリープ解除される問題の全体像
症状の大半は、以下の3系統のいずれか(または複合)で発生します。
- デバイス発火型:マウス・キーボード・Bluetooth・LANなどのハードウェアがスリープ解除信号(Wake)を送る。
- タイマー発火型:Windows Updateや自動メンテナンス、セキュリティ関連のスリープ解除タイマー(Wake Timer)が発火する。
- プラットフォーム設定型:UEFI/BIOSのWake on LAN/RTCやModern Standby(S0ix)特性による想定外の復帰。
正しい順序で原因を潰すと短時間で解決できます。以下の手順は「安全」「恒久」「再現検証」の3観点で構成しています。
最短で直す“決め打ち”チェックリスト(時間がない人向け)
- スリープ解除タイマーを無効化(AC/DCとも)。
- 直近の解除要因を確認し、該当デバイスの「このデバイスで…解除」をオフ。
- Update Orchestratorの「スリープ解除で実行」チェックを外す。
- アクティブ時間を就寝帯を外す形で広めに設定。
- ノートPCは必要に応じて休止状態(ハイバネーション)を優先。
原因の特定:まず「誰が起こしたか」を突き止める
コマンドで足跡(イベント)を拾う
管理者権限のコマンドプロンプトを開き、以下を実行します。
powercfg /devicequery wake_armed
powercfg /lastwake
powercfg /waketimers
powercfg /requests
wake_armed:スリープ解除を許可されているデバイス一覧。/lastwake:最後にスリープを解除した要因。/waketimers:有効なスリープ解除タイマーの一覧。/requests:スリープを抑止しているプロセス/ドライバの把握。
とくにWindows Update関連では、MoUsoCoreWorker.exeやMusNotification.exeが「実行要求」「タイマー」を保持しているケースが多いです。
イベント ビューアーで時系列を確認
「イベントビューアー → Windowsログ → システム」でPower-Troubleshooter(イベントID: 1)をたどると、デバイス名やタイマーが記録されています。時刻と一致するイベントを複数追うと、再発のパターン(約10分間隔など)が見えてきます。
解決策1:原因デバイスを無効化(最も効果的な一次対処)
デバイス マネージャーで解除許可を外す
- スタートを右クリック → デバイス マネージャー。
- 該当デバイス(マウス、キーボード、Bluetooth、ネットワークアダプター等)をダブルクリック。
- [電源の管理] タブ → 「このデバイスでコンピューターのスタンバイ状態を解除できるようにする」のチェックを外し、OK。
「解除されても再発する」場合、複数デバイスが許可されている可能性があります。特に以下は容疑が濃い“常連”です。
| デバイス | 典型症状 | 推奨設定 |
|---|---|---|
| ネットワーク アダプター(有線) | 数分~十数分で復帰、Updateやバックアップのタイミングと連動 | 「スタンバイ解除を許可」をオフ。詳細設定で「Wake on Magic Packetのみ」を有効 |
| Bluetooth 無線 | BLEデバイスの接続・再接続時に復帰 | 解除許可をオフ。省電力/ウェイク関連の拡張項目も見直し |
| HID(マウス/キーボード) | 机の振動・ペット・掃除機で誤復帰 | キーボードのみ許可、マウスは不許可 など使い分け |
| USB ハブ/コントローラ | 接続/切断の揺らぎで復帰 | 必要最小限のポートのみ解除許可 |
ネットワーク アダプターの拡張設定(Realtek/Intel等)
「デバイスの詳細設定(詳細タブ)」にある以下の項目も見直します。
- Wake on Magic Packet(有効)
- Wake on Pattern Match(無効)
- システムのスリープからのウェイク(必要に応じて無効)
Pattern Matchが有効だと、ブロードキャストやマルチキャストでも復帰してしまうことがあります。
解決策2:スリープ解除タイマーを無効化(Windows Updateの自動復帰を止める基本戦略)
GUIから設定する(Homeで確実・安全)
- コントロール パネル → システムとセキュリティ → 電源オプション。
- 使用中のプランで[プラン設定の変更] → [詳細な電源設定の変更]。
- [スリープ] → [スリープ解除タイマーの許可]を
- バッテリ駆動:無効
- 電源接続時:無効
コマンドで一括適用(上級者/スクリプト運用向け)
REM AC電源(接続時)で無効
powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_SLEEP AWAKETIMERS 0
REM バッテリ駆動時で無効
powercfg /SETDCVALUEINDEX SCHEME_CURRENT SUB_SLEEP AWAKETIMERS 0
powercfg /SETACTIVE SCHEME_CURRENT
反映後はpowercfg /waketimersで「アクティブなスリープ解除タイマーがありません」となることを確認します。
解決策3:Windows Updateの「スリープ解除で実行」を抑制
タスク スケジューラでUpdate Orchestrator系を点検
- 「タスク スケジューラ」を起動。
- タスク スケジューラ ライブラリ → Microsoft → Windows → UpdateOrchestrator。
- 代表的なタスク(Reboot、Schedule Scan、USO_UxBrokerなど)を開き、[条件]タブ → 「タスクを実行するためにスリープ解除する」のチェックを外す。
一部のタスクはOSにより再生成・再設定されることがあります。スリープ解除タイマーそのものを無効化(解決策2)しておくと、再生成されても実害を抑えられます。
通知系プロセスの“実行要求”を抑制(必要時のみ)
まれにMoUsoCoreWorker.exeなどがpowercfg /requestsで実行要求を保持し続けることがあります。影響が大きい場合、次の一時的オーバーライドが有効です。
powercfg /requestsoverride process MoUsoCoreWorker.exe execution
powercfg /requestsoverride process MusNotification.exe execution
オーバーライドは強い措置です。大規模アップデート直後など、必要なタイミングだけに留め、通常運用では解除タイマー無効化とアクティブ時間の調整を優先しましょう。
アクティブ時間を正しく設定する
- 「設定 → 更新とセキュリティ → Windows Update → アクティブ時間の変更」。
- 就寝時間帯をアクティブ時間外に置くよう調整(例:作業 09:00–23:00)。
アクティブ時間は再起動の自動化タイミングに影響します。これだけではスリープ解除の全制御はできませんが、再起動が絡む復帰の抑制に役立ちます。
補足策:自動メンテナンスとメディア再生の干渉を避ける
自動メンテナンスの時刻と「スリープ解除で実行」
- 「コントロール パネル → セキュリティとメンテナンス → メンテナンス → 自動メンテナンス」。
- 開始時刻の変更で就寝帯を避ける。可能なら「スケジュールされたメンテナンスの実行のためにスリープ解除する」のチェックを外す。
メディア関連のスリープ抑止を解消
powercfg /requestsで「DISPLAY」「SYSTEM」「AWAYMODE」がメディアアプリで保持されていないか確認し、アプリ側の設定でスリープ抑止を解除します。
休止状態(ハイバネーション)を活用:物理的な解除信号を最大限ブロック
ノートPCや外部デバイスが多い環境では、スリープより休止状態の方が安定します。休止状態を有効化するには:
powercfg /h on
電源ボタンや蓋の動作を「休止状態」に割り当てると、誤復帰のリスクをさらに下げられます。もっとも、RTC(目覚まし)による復帰が可能な機種もあるため、「解除タイマー無効化」との併用が前提です。
UEFI/BIOS側の見直し:OSを超えたWake設定を封じる
- Wake on LAN(WoL):不要なら無効。遠隔起動を使う場合は「Magic Packetのみに反応」に限定。
- Wake on PCI-E/USB:不要なポートのWakeを無効化。
- Wake on RTC:スケジュール時刻で自動起動する機能。未使用なら無効。
- ErP/Deep Sleep:S4/S5での待機電力を抑え、不要なウェイクをほぼ遮断。
UEFI設定を変える前に、写真撮影やメモで現状値を残しておくと復旧が容易です。
よくある誤解と正しい回避策
- 誤:アクティブ時間を広げれば勝手に起動は止まる → 誤り。アクティブ時間は再起動の自動化タイミングの指標で、スリープ解除タイマーやデバイス解除とは別物です。
- 誤:マウスの解除許可だけ外せばよい → 多くのケースでネットワーク/Bluetoothが犯人。必ず
powercfg /lastwakeで実犯を特定。 - 誤:Update Orchestratorのタスクを無効にすれば完全解決 → OSが再生成するため再発しやすい。解除タイマー無効化が基礎対策。
ケーススタディ:3つの代表パターンと処方箋
ケース1:MoUsoCoreWorker.exeが居座り、10分前後で起きる
症状:powercfg /requestsでMoUsoCoreWorker.exeが実行要求を保持。/waketimersにUpdate関連が表示。
対処:解除タイマーをAC/DCとも無効化(解決策2)。一時回避として/requestsoverrideで実行要求を抑制。大型アップデート適用後はオーバーライド解除を検討。
ケース2:有線LANがパターンマッチで復帰
症状:イベントID 1の情報に「Intel/Realtek NIC」等が記録。スイッチやNASの定期ブロードキャストで復帰。
対処:デバイス マネージャーで解除許可を外し、「Wake on Magic Packetのみ」を有効にしてPattern Matchを無効化。
ケース3:Bluetooth周辺機器が不安定で復帰
症状:スリープ直後~数分で復帰。/lastwakeにBluetoothデバイス名。
対処:解除許可を外す。周辺機器のファーム更新やUSBドングル延長ケーブルでノイズを軽減。
運用まで含めた“再発しない”設計図
- 週1回の手動更新デー(例:金曜夜)を設け、「更新の確認 → 適用 → 再起動」まで一気に実施。
- 就寝前は休止状態を選択。翌朝の復帰とバッテリー消費を最小化。
- 電源プランをエクスポート:変更履歴を残し、乱れたらインポートで復元。
powercfg -export "%USERPROFILE%\Desktop\MyPlan.pow" SCHEME_CURRENT powercfg -import "%USERPROFILE%\Desktop\MyPlan.pow"
トラブルシューティングの標準手順(保存版)
powercfg /lastwakeで直近の犯人を特定。powercfg /waketimersとイベントID 1でタイマーとデバイスの両面を確認。- 該当デバイスの解除許可をオフ。NICはPattern Match無効・Magic Packetのみ。
- 解除タイマーをAC/DCとも無効へ。
- Update Orchestratorの「スリープ解除で実行」をオフ。
- 自動メンテナンスの時刻を就寝帯から外す。
- 必要なら休止状態を既定化。
- UEFI/BIOSのWoL/RTCを見直す。
- 再度スリープ → 15分待機 →
/lastwakeで再検証。
よく使うコマンド早見表
| コマンド | 用途 | メモ |
|---|---|---|
powercfg /lastwake | 直近の解除要因の表示 | デバイス名やタイマー情報を取得 |
powercfg /devicequery wake_armed | 解除許可デバイス一覧 | 疑わしいデバイスの洗い出し |
powercfg /waketimers | 有効な解除タイマー確認 | Update/メンテナンスの関与を把握 |
powercfg /requests | スリープ抑止要因の確認 | 動画再生や更新通知の居座りを検出 |
powercfg /requestsoverride | 抑止要因の個別無効化 | 一時的措置。常用は避ける |
powercfg /SETACVALUEINDEX ... AWAKETIMERS 0 | AC時の解除タイマーを無効 | GUIと同等だがスクリプト適用に向く |
powercfg /SETDCVALUEINDEX ... AWAKETIMERS 0 | バッテリ時の解除タイマーを無効 | ノートPCでは必須 |
powercfg /h on | 休止状態の有効化 | 夜間の誤復帰リスク低減 |
Home版ならではのポイント:グループポリシーが使えない時の工夫
Windows 10 Homeではローカル グループ ポリシー エディター(gpedit.msc)が原則使えません。そこで、電源プランとデバイス/タスクの調整に軸足を置くのが現実的かつ安全です。再起動ポリシー相当の挙動を求めたくても、無理にレジストリを書き換えるより、解除タイマー無効化+手動更新の運用の方が副作用が少なく、管理も簡単です。
「更新は後回しにしたい」派の安全運用術
- 毎週一度だけ更新をまとめて適用:手動で「更新の確認 → ダウンロード → インストール → 再起動」まで実施。
- 就寝前に更新の有無を確認し、あれば休止状態、なければ通常のスリープでもOK。
- 大規模アップデート(機能更新)週は、翌朝の作業に影響しないよう就寝前にインストール→再起動まで終える。
セキュリティパッチの長期見送りは危険です。スリープ解除の問題を封じつつ、更新の実施タイミングを“自分で決める”のがベストプラクティスです。
トラブルが続く場合の掘り下げチェック
- Modern Standby(S0ix)機種かどうか:S3スリープよりネットワーク接続維持が積極的で、復帰に見える挙動が起きやすい。対策は変わらず解除タイマー無効+デバイス許可の見直し。
- 周辺機器のファーム/ドライバ更新:古いBluetoothドングルやUSBハブがノイズ源になる例は意外と多い。
- バックアップ/同期アプリ:常時監視系は
powercfg /requestsで抑止を確認。夜間はスケジュールを外す。
ロールバック(設定を戻す)手順
- 解除タイマー:電源オプションで「無効」→「有効(重要なウェイクタイマーのみ)」へ戻す。
- デバイスの解除許可:必要なもの(リモート作業で使うキーボード等)だけ“許可”に戻す。
- Update Orchestratorの条件:再び「スリープ解除で実行」にチェックを付与(必要になった場合)。
- UEFI/BIOSのWoL/RTC:遠隔起動が必要になったら「Magic Packetのみ」に限定して再有効化。
「まとめ」—再発しないための要点
- まず犯人特定:
/lastwakeとイベントID 1で原因を“記録”から突き止める。 - 土台の封じ込め:解除タイマー無効でWindows Updateの自動起床にストッパーをかける。
- 物理ルートの遮断:デバイスの解除許可を最小化、NICはMagic Packetのみ。
- 運用で仕上げ:週1手動更新+就寝前は休止状態で、静かな夜を取り戻す。
付録:質問と回答(FAQ)
Q. 「スリープ解除タイマーの許可」を“重要なウェイクタイマーのみ”にすれば十分?
A. まずは完全に無効を推奨。問題が解消したら、必要に応じて“重要のみ”に緩めて動作を確認してください。
Q. Wake on LANを残したいが、勝手に起動してほしくない
A. NICの詳細設定でMagic Packetのみに限定し、Pattern Match等の広い条件を無効化します。デバイス側の解除許可は残してOKです。
Q. 10分間隔で起きるのはなぜ?
A. Update関連のリトライやバックグラウンド通知が一定間隔で試行するためです。解除タイマー無効化+Update Orchestratorの「スリープ解除で実行」オフで止まることが多いです。
Q. 休止状態からも起きる?
A. 一部機種ではRTCウェイクで可能です。解除タイマーを無効にし、UEFIのWake on RTCをオフにすれば実質的に防げます。
実行手順の再掲(この通りにやれば直る)
powercfg /lastwakeと/waketimersで現状を記録。- 電源オプションで解除タイマー:AC/DCとも無効。
- デバイス マネージャーで解除許可を外す(特にNIC/Bluetooth/マウス)。
- タスク スケジューラ → UpdateOrchestrator配下の「スリープ解除で実行」チェックを外す。
- 自動メンテナンスの時刻を就寝帯の外へ。
- 必要に応じて
powercfg /requestsoverrideで一時回避。 - 就寝時は休止状態を活用。
- 再テスト:15分放置 →
/lastwakeで再確認。問題が消えていれば完了。
最後に:安全面の注意
- Wake機能を広く止めると、遠隔起動(WoL)が必要な場面で反応しなくなります。要件に応じて最小限のみ許可しましょう。
- 更新を長期にわたり止めるのはリスクです。週1の手動更新をルーティン化しましょう。
- 変更前に電源プランのエクスポートやUEFI設定の控えを残すと復旧が容易です。
関連コマンド/設定スニペット集(コピペ用)
:: 直近のウェイク要因
powercfg /lastwake
:: 有効なウェイクタイマー
powercfg /waketimers
:: スリープ抑止要因
powercfg /requests
:: ウェイクタイマーを無効(AC/DC)
powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_SLEEP AWAKETIMERS 0
powercfg /SETDCVALUEINDEX SCHEME_CURRENT SUB_SLEEP AWAKETIMERS 0
powercfg /SETACTIVE SCHEME_CURRENT
:: USO系通知の一時オーバーライド(必要時のみ)
powercfg /requestsoverride process MoUsoCoreWorker.exe execution
powercfg /requestsoverride process MusNotification.exe execution
:: 休止状態を有効化
powercfg /h on
ここまで実施してもなお勝手にスリープ解除される場合は、UEFI/BIOS側でWake on LAN/Wake on RTCなどが有効になっていないかを確認してください。とくにデスクトップPCではマザーボードの初期値でWoLが有効なことがあり、ルーターやNASのブロードキャストで復帰する事例が見られます。

コメント