IntuneでWindowsの高速スタートアップを無効化する方法まとめ（設定カタログで見つからない時の最適解）
Windows 10/11 の「高速スタートアップ（Fast Startup）」は、シャットダウン時にカーネル状態を保存して次回起動を速くする仕組みです。一方で、更新適用の遅延、稼働時間が意図せず伸びる、ドライバーや暗号化まわりの切り替えが分かりにくいなど、企業運用では“邪魔になる場面”も少なくありません。
Intuneで一括無効化したいのに、設定カタログで項目が見当たらない——この状況で取り得る現実的な選択肢を、運用目線で整理します。 Microsoft Learn+1
高速スタートアップが運用で問題になりやすい理由
高速スタートアップは「シャットダウン＝完全停止」ではなく、“ハイブリッドシャットダウン”に近い挙動になります。そのため、利用者が毎日シャットダウンしているつもりでも、実際には再起動が長期間行われず、更新や構成変更の反映が遅れる原因になりがちです。更新トラブルの一因として高速スタートアップが絡むケースも指摘されています。 call4cloud.nl+1
企業端末（Dell含むメーカー混在）でよくあるのは次のパターンです。
-
「シャットダウンしたのに不具合が直らない」→ 再起動で直る
-
Windows Updateの適用が進まない／適用後の挙動が不安定
-
起動が速いメリットより、トラブル時の切り分けコストが勝つ
結論：設定カタログ“だけ”で完結しないことが多い
現場感として、設定カタログに「Fast Startupを無効化」という分かりやすいトグルが常に用意されているわけではありません（OS/テンプレ/公開状況で差が出ます）。そのため、多くの組織では スクリプト か カスタム（OMA-URI） のいずれかで制御します。 msnugget+1
ただし「カタログに無い＝MDMでは無理」ではありません。ポイントは、ADMXバック（ポリシーCSP）の経路を使えるかどうかです。
選択肢1：CSP（ADMXバック）をカスタムOMA-URIで構成する
Microsoftのドキュメント上、「Fast startupを制御するポリシー」として Policy CSP - ADMX_WinInit / Hiberboot が提示されています。パスは以下です。
-
./Device/Vendor/MSFT/Policy/Config/ADMX_WinInit/HiberbootMicrosoft Learn
ここが重要で、設定カタログに項目が露出していなくても、カスタムプロファイルでOMA-URIを直接指定して配布できることがあります（環境・適用条件次第）。ドキュメント上の挙動としては、「無効または未構成だとローカル設定に従う」ため、組織として確実に止めたい場合は“無効に固定できる形”を狙う設計が必要です。 Microsoft Learn+1
運用の考え方：
-
できるだけポリシーで制御（監査・再適用が楽）
-
うまく当たらない端末が出るなら、後述のスクリプトで補完
選択肢2：レジストリ（HiberbootEnabled）をPowerShellで無効化する（最も堅い）
高速スタートアップの実体は、よく知られている通りレジストリ値で管理されます。代表的には以下です。
-
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power -
HiberbootEnabled（DWORD）を 1→0 にする Microsoft Learn
Intuneではこれを PowerShellスクリプト（Platform scripts） として配布するか、継続監視したいなら Proactive Remediations（検出＋修復） が定番です。後者は「いつの間にか戻っていた」を検知でき、運用品質が上がります。 Andrew Taylor+1
運用の考え方：
-
一度だけ変えれば良い：Platform scripts
-
ずっと守りたい（監視したい）：Proactive Remediations
-
端末台数が多い／混在環境：Remediationsが安心
「GPOの設定で無効にできる？」に注意
管理テンプレート側に“Fast startup”に見える設定があっても、説明文の通り 有効化方向の強制が中心で、「無効にする＝確実にオフへ固定」とはならないことがあります。結果として現場ではレジストリ方式が選ばれがちです。 ctrlaltnod.com+1
実務でのおすすめ構成（迷ったらこれ）
-
まずは Proactive Remediations で
-
検出：
HiberbootEnabledが 1 ならNG -
修復：0に変更
-
（必要なら）関連設定も併用
-
-
可能なら並行して CSP（ADMX_WinInit/Hiberboot） も試し、当たりが良い環境ではポリシー寄りへ寄せる
-
変更後はヘルプデスク向けに
-
「シャットダウンではなく再起動を促す」運用案内
-
更新トラブル時の切り分け手順
を整備する
-
この流れだと、「設定カタログに無い」問題に引きずられず、短期で確実に統制できます。
まとめ：設定カタログに無ければ、カスタムかスクリプトで“確実に”止める
-
設定カタログに項目が見当たらないケースは現実にある
-
それでも CSP（ADMX_WinInit/Hiberboot）をカスタムOMA-URIで叩ける可能性がある Microsoft Learn
-
最も確実で運用実績が厚いのは レジストリ（HiberbootEnabled）をIntuneでスクリプト/Remediations配布 Andrew Taylor+1
Dellに限らず、企業端末の安定運用を優先するなら「高速スタートアップはオフ」を標準にし、Intuneでは“戻らない仕組み（Remediations）”で固めるのが最短ルートです。
