Windows11,23H2でシャットダウン休止状態ができなくなってしまう問題が発生

Image:Unsplash(Sunrise King)
Windows 11 バージョン 23H2の環境で、「シャットダウン」や「休止状態」を選んだにもかかわらず、なぜか再起動してしまう――そんな症状の報告が、2025年末から2026年初頭にかけて急増している。表面的には単なる「電源メニューの不調」に見えるが、その背景にはセキュリティ機能と電源管理の複雑な連携、そして累積更新プログラムの品質問題が絡み合っていることが、ユーザーやメディアの検証から徐々に見えつつある。

Windows 11 23H2で何が起きているのか

まず現象を整理しておく必要がある。典型的なケースでは、ユーザーがスタートメニューや電源ボタンから「シャットダウン」あるいは「休止状態」を選択すると、画面は一度ブラックアウトし、普段の電源オフとほとんど同じ挙動を見せる。ところが数秒後、マシンが勝手に再起動を開始し、Windowsのロゴやメーカーのスプラッシュ画面が表示され、通常の起動シーケンスに戻ってしまう。

従来から、ドライバの不具合や高速スタートアップ、あるいはスリープ関連のトラブルで「完全に電源が落ちない」「スリープから復帰してしまう」といった問題は散発的に存在していた。しかし、今回特徴的なのは、特定の累積更新プログラムを境に、23H2環境で似たような症状を訴えるユーザーが一気に増えている点だ。 しかも、個別のメーカー機種や特定のドライバに限定されず、自作機からビジネス向けノートまで幅広い構成で再現していることが、フォーラムやQ&Aサイトの書き込みから読み取れる。

一部のユーザーは、休止状態に限って問題が発生し、シャットダウンは正常に動作すると報告しているのに対し、別のユーザーはその逆で「シャットダウンだけが必ず再起動になる」と証言している。 このばらつきは、ACPIレベルの電源ステートの扱いが、ハードウェアやファームウェア、セキュリティ機能の有効／無効によって微妙に変化していることを示唆している。

累積更新とセキュリティ機能の“衝突”

今回のシャットダウン不具合の発端として、複数のメディアやユーザーが指摘しているのが、2026年1月前後に配信された累積更新プログラムだ。具体的なKB番号としては、KB5073455を適用した後から電源が落ちなくなったという報告が多く、これをアンインストールすると「元に戻った」とするケースが相次いでいる。​

この更新には、System Guard Secure Launch や仮想化ベースのセキュリティ（VBS）、Device Guard といった高度な防御機構に関連する変更が含まれていたとされる。 Secure Launch は、UEFIレベルでOS起動前にシステムの整合性を検証する仕組みであり、VBSやCore Isolationなどと組み合わせることで、ブートキットや脆弱なドライバからシステムを守る役割を担っている。

しかし、これらのセキュリティ機能は、CPUの仮想化支援機能、メモリ保護、ファームウェアのブートフローなど、ハードウェアの低レベルなコンポーネントと密接に結びついている。累積更新によってブートパスや検証タイミングが変化すると、電源オフや休止への遷移時にも、同様の検証やハンドシェイクが発生する場合がある。 その結果、シャットダウン処理の最終段階で「再度初期化し直す」ような挙動がトリガーされ、意図せぬ再起動として表面化している可能性が指摘されている。

興味深いのは、企業向けの構成やIoTデバイス、あるいは一部の事前構成済みのビジネスPCなど、セキュリティ機能が標準で積極的に有効化されている環境ほど、この不具合が出やすいとされている点だ。 一方で、HomeエディションでVBSやSecure Launchを無効にしているような自作PCでは、同じ更新を適用しても問題が起きないケースがある。 つまり、更新プログラムそのものというより、「更新内容 × セキュリティ構成 × ファームウェア」の組み合わせによって、発症の有無が変わっている構図だと考えられる。

Microsoft自身も、公式ドキュメントやRelease Healthの情報として、特定の累積更新の後に一部のWindows 11 PCでシャットダウンできない、あるいは意図せず再起動してしまう問題が発生していることを認めている。 また、将来の更新によって修正を提供する方針が示されており、実際に1月後半〜2月にかけて、問題のあるパスを修正したとみられる更新（KB5077797など）が順次配信されているとの報道も見られる。

現時点で現実的な対処法

ユーザー視点で重要なのは、「原因の理屈」よりも「今、どう回避・軽減できるか」だろう。根本的な解決はMicrosoft側の修正に委ねられるとしても、日々の運用に支障が出ないよう、いくつか実用的な対策が考えられている。

まず第一に試すべきなのは、最新の更新プログラムを適用することだ。問題を引き起こした累積更新の後続として、電源管理まわりの修正が含まれた新しいKBが配信されている場合、Windows Updateからそれを取り込むだけで症状が収まることがある。 特に、2026年1月後半以降に公開された累積更新やプレビュー更新では、シャットダウンに関する修正が含まれているとされており、適用後に「再起動ループ」が解消したという報告が複数挙がっている。​

それでも改善しない場合、Secure Launch や VBS、Core Isolation といったセキュリティ機能を一時的に無効化する方法が検討されることがある。具体的には、UEFI/BIOSの設定画面から「Secure Launch」や「Intel TXT」に相当する項目を無効にし、再起動後にWindows側の「デバイス セキュリティ」画面で仮想化ベースのセキュリティやメモリ整合性をオフにする、といった手順だ。 実際、この手法でシャットダウンが正常に動作するようになったという声は多いが、その代償として攻撃耐性が下がる可能性があるため、特に企業環境では情報システム部門のポリシーと相談しながら慎重に判断する必要がある。

もう一つの現実的な回避策としては、グラフィカルな電源メニューではなく、コマンド経由でシャットダウンを実行するというものがある。具体的には、管理者権限のコマンドプロンプトやPowerShellで「shutdown /s /t 0」を実行すると、今回のバグに影響されず、きちんと電源が落ちるケースが報告されている。 この方法は特に、休止やスリープは諦めてでも確実にシャットダウンしたいユーザーにとって実用的であり、ショートカットを作成してタスクバーなどにピン留めして使うという運用も考えられる。​

最後の手段としては、問題の発端となった累積更新そのものをアンインストールし、以前の状態に戻すという選択肢もある。KB5073455のアンインストール後に再起動問題が解消したという具体的なユーザー報告が複数存在しており、時間的な因果関係もはっきりしている。 ただし、累積更新にはセキュリティ修正も同梱されているため、アンインストールによって脆弱性が再び露出するというリスクがある。したがって、この方法は「どうしても仕事で休止を使わざるを得ない」「修正版更新の配信までの一時的な措置」といった前提で行うのが望ましい。修正版の累積更新（例: KB5077797）がリリースされた時点で、速やかにそちらへ切り替えることが推奨される。​

設定変更前に確認しておきたいポイント

実際に記事として書く場合、読者に対して「いきなり設定をいじる前に、何を確認すべきか」を整理して提示しておくと親切だ。まず重要なのは、問題が発生し始めた時期と、その直前に適用された更新プログラムの履歴である。Windowsの設定画面から「Windows Update」→「更新の履歴」を開けば、最近インストールされた累積更新やドライバ更新の一覧が確認できる。 ここで、症状が出る直前にインストールされたものと、ユーザーの記憶とを照らし合わせれば、「更新がトリガーなのか、別の要因なのか」をある程度切り分けられる。

次に押さえておきたいのが、Windowsのエディションとセキュリティ機能の有効状態だ。ProやEnterprise、Education、あるいはIoT向けSKUでは、初期設定やグループポリシーでVBSやDevice Guardが有効化されているケースがあり、今回のシャットダウン問題に巻き込まれやすい土壌が整っている。 逆に、個人向けのHomeエディションで、仮想化ベースのセキュリティがオフのままという構成では、同じ更新を当てても再起動ループが発生しない場合がある。 記事の中で「自分の環境がどのタイプに属するのか」を簡単に確認する方法を紹介しておけば、読者は自身のリスクレベルを把握しやすくなるだろう。

最後に、「どの操作で必ず再起動になるのか」という現象のパターンも重要だ。シャットダウンだけが駄目なのか、休止もスリープも同様なのか、あるいはACアダプタ接続時とバッテリ駆動時で挙動が変わるのか、といった情報は、原因がOS側なのかファームウェアやドライバ側なのかを推測するヒントになる。 記事では、読者に簡単なチェックリストを提示し、「自分の症状がどのパターンに近いか」を確認させたうえで、対応策の章に誘導する構成にするとわかりやすい。

「セキュリティと安定性」の綱引きとして描く

今回の23H2におけるシャットダウン問題は、単なるバグレポートにとどまらず、Windows 11が目指している方向性と、その副作用としての複雑さを象徴する事例としても捉えられる。Microsoftは、ファームウェアレベルの攻撃や脆弱なドライバを封じ込めるため、Secure Launch やVBS、Core Isolationといった機能を積極的に推進している。 これらは長期的にはセキュリティの底上げにつながるものの、OSとハードウェア、そしてサードパーティ製ソフトウェアとの境界に、これまで以上の負荷をかけているのも事実だ。

シャットダウンや休止といった基本機能の信頼性が揺らげば、ユーザー体験は一気に悪化する。特に、ノートPCを持ち歩くユーザーにとって、休止状態が使えないことはバッテリ持続時間や作業再開のスムーズさに直結する問題だ。今回の不具合は、Windowsの進化が「セキュリティの強化」と「日常動作の安定性」という二つの軸の上でどのようにバランスを取るべきか、あらためて問いかける出来事になっていると言えるだろう。