記事を公開した理由
今回の事象は、OSの修復が必要になったときに初めて利用する機能であるため、通常のWindows Update後の確認では気づきにくい性質があります。
しかし、障害が発生した際にセーフモードや起動オプションが利用できない状態は、復旧作業に重大な支障をきたします。
そのため、読者の皆様にも回復環境（WinRE）が正常に動作しているかどうかを必ず確認することを強く推奨します。
特に、
セーフモードで起動できるかどうか
は最低限確認しておくべき項目です。
動画解説
記事公開時の版になっています。その後の再作成は行っていません。
※ 7分39秒
まとめ（2026/08/25 確定版）
今回の修復策について（確定）
- 2026年8月定例更新後に発生した「Startup Settings が表示されず通常起動にフォールバックする」事象は、リプレースインストール（修復インストール）により正常に復旧することを確認しました。
- セーフモード自体は正常に起動できるため、WinRE 本体の破損ではなく、WinRE 内部モジュールと OS 本体の呼び出し経路の不整合が原因である可能性が高いと判断しています。
- 今回の検証では、PC設定 → 回復 → スタートアップ設定を経由したセーフモード呼び出しが、リプレースインストール後に正常へ復旧することを複数回確認しました。
- Microsoft 以外のサービスを一時的に無効化した状態、および再度有効化した状態のいずれにおいても、セーフモード起動は正常であり、サードパーティ製サービスの競合が主因である可能性は低いと判断しています。
- 暫定策として提示していた msconfig・bcdedit（advancedoptions）・USB回復ドライブ によるセーフモード起動は、あくまで「回避策」であり、恒久的な修復には至りません。
- 今回の検証結果を踏まえ、一般ユーザー向けの修復策としては、安全性が高く再現性も確保できる「上書きインストール（リペアインストール）」を第一候補とすることを推奨します。
- なお、リプレースインストールにより問題が解消されたため、障害発生環境下での再現性が失われ、深層修復（BCD再構築・SafeOS DU再適用・回復パーティション再構成など）の検証は行えません。
今回の事象の要点（確定版）
- 2026年8月定例更新後、私の環境でStartup Settings の UI が表示されず通常起動に戻る例外挙動を確認しました。
- セーフモード自体は正常に起動できるため、WinRE 本体の破損ではなく、呼び出し経路の不整合が原因である可能性が高いと判断しています。
- 回復環境（WinRE）内の他の項目にも影響が出ている可能性があるため、読者の皆様にも回復環境の正常性確認を強く推奨します。
- 今回の事象は、WinRE 内部モジュールのバージョン不一致や SafeOS DU の適用状況によって発生し得る構造であり、Windows 10 / Windows 11（24H2以前）でも同様の事象が起こり得ます。
- 今回の検証結果により、恒久的な修正方法は「上書きインストール（リペアインストール）」であることが確定しました。
手元PCで発生した事象
私の環境（Windows 11 25H2・2026年8月定例更新適用済み）では、以下の事象が確認できました。
■ PC設定 → 回復 → 「PC の起動をカスタマイズ」から WinRE に入った場合
– 「トラブルシューティング」
– 「詳細オプション」
– 「スタートアップ設定」
と進み、再起動すると本来はセーフモード選択画面（4/5/6）が表示されるはずです。
しかし今回の更新後は、
セーフモード選択画面が表示されず、通常起動にフォールバックする
という例外挙動が発生しています。
このような状態では、起動オプション以外の項目にも齟齬が発生している可能性があり、回復環境全体の信頼性が低下していることが懸念されます。
憂慮される事態
■ セーフモードを利用したトラブルシューティングができない
起動時のオプションが表示されないため、
– セーフモード
– セーフモード（ネットワーク）
– セーフモード（コマンドプロンプト）
などが利用できなくなります。
■ WinRE内の他の項目にも齟齬が発生している可能性
スタートアップ設定が正常に呼び出せない場合、
– システム修復
– コマンドプロンプト
– イメージ復元
など、他の項目にも影響が出ている可能性があります。
■ WinREそのものが破損しているケースもあり得る
2026年は回復環境（WinRE）・SafeOS・Secure Boot証明書の更新が継続しており、
回復環境の構成不整合が発生しやすい状況です。
そのため、回復環境が正常に動作しているかどうかの確認を強く推奨します。
暫定策（第一報）
現時点では、私の環境で確認できた事象に対する暫定的な回避策を記載します。
恒久的な修正方法については後日検証します。
■ OSが起動している場合にセーフモードを使う
1. システム構成（msconfig）からセーフモード起動を指定する
→ セーフモード自体は正常に起動できることを確認済み。
■ 2. コマンドで起動オプションを強制表示する
Windowsの旗マークが出る前に、古い起動オプション（F8相当）を表示させる設定。
※ コマンドプロンプト（管理者）で実行します。
bcdedit /set advancedoptions on
※元に戻す場合（標準の起動オプションに戻す）
以下のコマンドを実行すると、Windows 10/11 の標準設定である「bootmenupolicy standard」に戻ります。
bcdedit /set advancedoptions off
■ OSが起動不可能になっている場合にセーフモードを使う
1. USB回復ドライブまたはインストールメディアを利用する
外部WinREから起動することで、内部の起動オプションUIの異常を回避できます。
2. 外部WinREのコマンドプロンプトから起動オプションを設定する
Windows 7時代のF8メニューが必要な場合は、前述の bootmenupolicy legacy を外部WinREから設定します。
※ただし、回復環境そのものが破損している場合には効果がない可能性があります。
現時点で考えられる修正／回復策（未検証）
以下は、現時点で「有効である可能性がある」と考えられる手段を、手軽で安全なものから順番に並べた一覧です。
※まだ検証できていないため、正式な回復策としては扱いません。
番外：今回の齟齬発生の原因仮説（暫定）
今回の事象は、WinRE 本体が破損したのではなく、OS本体側の「WinRE呼び出し機能」または WinRE の保存場所（番地）に関する整合性が失われている可能性が高いと考えられます。WinRE 自体は正常に起動するため、Startup Settings の呼び出し経路のみが不整合を起こしている構造が最も自然です。
今回の原因仮説を推定した理由（深掘り）
（クリックで展開します）今回の原因仮説を推定した理由（深掘り）
発生事由の推定
Startup Settings を呼び出した際、画面に「白い細い線が一瞬だけ表示されて消える」という挙動が確認できます。これは、Windows がウィンドウの初期化だけ行い、描画対象の番地が存在しないため即座に破棄したときに発生する典型的な動作です。
この挙動は、WinRE 本体（winre.wim）が破損している場合には発生しません。WinRE が壊れている場合は WinRE 自体が起動できなくなるため、今回のように WinRE へは正常に入れるが Startup Settings だけが失敗する、という状態とは一致しません。
そのため、今回の事象は「WinRE 本体の破損」ではなく、OS 本体 → WinRE の呼び出し経路、または WinRE 内部の Startup Settings モジュールの番地情報が不整合を起こしている可能性が最も高いと考えられます。
さらに、2026年8月定例更新では SafeOS Dynamic Update（DU）が適用されており、WinRE 内部モジュールや起動ハンドオフに影響する更新が含まれています。DU の適用が中途半端だった場合、OS が参照する WinRE の番地と、WinRE 内部の実際の番地が一致しなくなる可能性があります。
以上の理由から、今回の齟齬は「WinRE の破損」ではなく「呼び出し経路または番地情報の不整合」が最も自然な原因であると推定しています。
発生理由の推定から考慮した他季節な回復手法予測
私の手元で検証していきますが、上記推定より、以下の手法を優先して検証していくことになるかと考えます。お急ぎでご自分の手元でも検証したいという方は、どうぞご参考ください。
- ① WinRE の再登録（reagentc /disable → /enable）
最も優先度が高いと考えられる手法です。OS が参照している WinRE の番地（パス）がズレている場合、再登録によって整合性が回復する可能性があります。特に SafeOS DU の適用が中途半端だった場合、OS 側が新しい WinRE を参照し、実体が古いままという不整合が起こり得ます。 - ② reagentc /info による WinRE パスの確認
OS 側が参照している WinRE のパスと、実際の WinRE（winre.wim）が存在する場所が一致しているかを確認します。もし一致していない場合、Startup Settings の呼び出しが失敗し、今回のような「白い線 → 即破棄 → 通常起動」挙動が発生します。 - ③ DISM（オンライン）による OS 基盤の整合性確認
オンライン DISM は OS 本体の上層を修復するため、今回のような「WinRE 呼び出し経路の不整合」には届かない可能性があります。ただし、軽微な整合性の乱れであれば改善する可能性があるため、比較的安全な手段として候補に入ります。 - ④ DISM（オフライン）による OS 起動基盤の修復
オフライン DISM は OS の起動基盤（ブートローダー、ハンドオフ、BCD まわり）まで修復できるため、今回のような「呼び出し経路の不整合」に対して有効である可能性があります。上級者向けの手法ですが、最も構造的に筋が通っています。 - ⑤ SafeOS Dynamic Update（DU）の整合性確認
2026年8月定例更新では SafeOS DU が適用されており、WinRE 内部モジュールや起動ハンドオフに影響する更新が含まれています。OS 側だけ新しく、WinRE 側が古いままという状態は、今回の挙動と完全に一致します。必要に応じて WinRE の再適用や上書きが検討されます。
■ WinREの再登録（危険度：低・比較的安全）
回復環境が正しく登録されていない場合に有効な可能性があります。
※ OSが起動している状態で、コマンドプロンプト（管理者）を使用します。
reagentc /info
reagentc /disable
reagentc /enable
※ 回復パーティションが正しく存在しない場合は、再登録が失敗することがあります。
■ DISMによる回復環境の修復（危険度：低〜中）
OS本体や回復環境のイメージに破損がある場合に有効な可能性があります。
※ OSが起動している状態で、コマンドプロンプト（管理者）を使用します。
Dism /Online /Cleanup-Image /RestoreHealth
※ WinRE側の破損が原因の場合は、別途 WinRE イメージの修復が必要になる可能性があります。
上級者向け
以下は、上級者向けの手法です。「上書きインストール（修復インストール）（危険度：中〜高）」は例外として、その他の手法は理解できないまま利用しないでくださいね。
【SFCとDISM】究極奥義「オフライン実行」でOSを徹底修復-完全解説版【2025/08/12】
【SFCとDISM】究極奥義「オフライン実行」でOSを徹底修復-実行手順抽出版【2026/04/10】
■ BCDストアの再構築（危険度：中・慎重に実施）
起動構成（BCD）が破損している場合に有効な可能性があります。
※ WinRE またはインストールメディアから「コマンドプロンプト」を開いて実行します。
bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd
※ BitLocker が有効な環境では回復キーが必要になる場合があります。
■ SafeOS Dynamic Updateの再適用確認（危険度：中）
2026年は SafeOS（WinREの基盤）に対する更新が継続しており、更新の不整合が発生している可能性があります。
確認手順：
winverで OS ビルドを確認reagentc /infoで WinRE のバージョンを確認- OS本体と WinRE のビルドが一致しているか確認
※ 不一致がある場合、累積更新または SafeOS DU の再適用が必要になる可能性があります。
■ 上書きインストール（修復インストール）（危険度：中〜高）
OSのシステムファイルを広範囲に修復する方法です。ユーザーデータを保持したまま Windows を再インストールします。
手順：
- Microsoft公式サイトから最新の Windows 11 インストールメディアを取得
- OS起動中にセットアップを実行
- 「個人用ファイルとアプリを引き継ぐ」を選択
- インストールを開始
※ 回復環境の破損が広範囲の場合に有効な可能性があります。
■ 回復パーティションの再構成（危険度：高・最終手段）
回復パーティションが破損・欠落している場合に必要となる可能性があります。
※ 高度な操作のため、慎重に行う必要があります。
一般的な流れ：
- ディスクのパーティション構成を確認（diskpart または「ディスクの管理」）
- 回復パーティションが存在しない場合は新規作成（500MB〜1GB程度）
- WinREイメージ（Winre.wim）を新しいパーティションへ配置
reagentc /enableで回復環境を再登録
※ 誤操作でデータを失う可能性があるため、バックアップを推奨します。
確定版の修正／回復策
途中経過（2026/08/24 ）
今回の事象について、以下の検証を行いました。
現時点で判明していることは、「WinRE 本体は正常だが、Startup Settings の呼び出し経路が壊れている可能性が高い」という点です。
■ 1. セーフモード起動状態から「スタートアップ設定」を呼び出し
結果： 失敗（通常起動にフォールバック）
WinRE 内部の「Startup Settings」モジュールのみが呼び出せず、UI が表示されない状態を確認しました。
■ 2. SFC → DISM → SFC（OS本体の整合性チェック）
結果： すべて正常（異常なし）
OS 本体の破損ではないことが確定しました。
起動基盤または WinRE 呼び出し経路側の問題である可能性が高いと判断しています。
■ 3. bcdedit /set advancedoptions on
結果： 起動オプションが表示され、セーフモード起動は成功
Startup Settings の UI 呼び出しは壊れているものの、セーフモード自体は正常に起動できることが確定しました。
■ 4. WinRE の再登録（reagentc /disable → /enable）
結果： 効果なし
WinRE のパス不整合ではないことが確認できました。
WinRE 本体（winre.wim）は正常に起動できるため、呼び出し経路の不整合が最も自然な原因と判断しています。
現時点で読者の方にお伝えできる要点
- WinRE 本体は壊れていません。
ただし、WinRE 内部モジュールのバージョンが OS 本体と一致していない可能性があり、
過去の Windows でも同様の“内部バージョン不一致による修復失敗”が発生した例があります。
SafeOS DU の適用状況によっては、今回のような Startup Settings の呼び出し失敗を引き起こす場合があります。 - OS 本体も SFC/DISM により正常であることを確認済みです。
- 「Startup Settings」の呼び出し経路のみが不整合を起こしている可能性が高い状況です。
- セーフモード自体は正常に起動できます。
- 暫定策として
bcdedit /set advancedoptions onによる起動オプションの強制表示は有効です。 - WinRE の再登録（
reagentc）では今回の事象は解消しませんでした。
今後の検証方針について（重要）
今回の事象は、WinRE 内部モジュールのバージョン不一致が疑われるため、この後に行う深い層の修復（BCD 再構築・オフライン DISM・回復パーティション再構成など）は、一般ユーザーには危険性が高い操作になります。
また、私の環境では現在の「不整合が再現している状態」そのものが貴重な一次情報であり、高度な修復を実行して問題が解消されてしまうと、最も安全な修復方法であるリプレースインストール（上書きインストール）の検証ができなくなる可能性があります。
そのため、私自身の検証方針としても、危険性の高い深層修復は行わず、安全性が高く再現性も確保できる「上書きインストール（リペアインストール）」を優先して検証します。
上書きインストールは、OS の起動基盤と WinRE の内部モジュールを最新状態に再構成できるため、今回のような内部バージョン不一致の解消に最も適しています。
なお、上書きインストール（リペアインストール）で修復できなかった場合に限り、研究目的として深層修復の検証を行う可能性があります。
これはあくまで私の環境での追加検証であり、一般ユーザー向けの推奨策ではありません。
※ 実行前に必ずデータのバックアップを推奨します。
検証環境とリプレース（修復）インストール実行（2026/08/25）
今回の事象が発生した検証環境
今回の「Startup Settings が表示されず通常起動にフォールバックする」事象は、以下の構成のPCで発生・検証を行いました。
- CPU： AMD Ryzen 5 5600（6コア12スレッド）
- メモリ： 24GB
- マザーボード： ASUS B450M-PLUS GAMING
- グラフィック： MSI GeForce RTX 3050
- ストレージ（システム）： Intel SSD 7 NVMe（1TB M.2）
- ストレージ（データ）： HDD 3台（計8TB）
- EFIパーティション： 500MB（EFIは元々100MB → 500MBに拡張済み）
- 回復パーティション： 1.49GB（拡張済み）
- Secure Boot： 有効
- FastBoot： 無効（M/B機能・検証時に明示的に無効化）
- BitLocker： 無効
- OS： Windows 11 Pro 64bit（25H2対応）
- SafeOS DU： 2026年8月定例更新適用済み（OS本体と WinRE のビルド一致）
EFI・回復パーティションともに十分な容量を確保している環境で発生しているため、今回の事象は「回復パーティションの容量不足」が原因ではないと考えられます。
ただし、以下の検証では、操作実行時にMicrosoft 以外のサービスを一時的に無効化しています。そのため、2026年8月定例更新の適用時に、Microsoft 以外のサービスが有効状態であったことによる競合の影響で更新処理が失敗した可能性については、現時点では完全には排除できません。
リプレース（修復）インストール実行（2026/08/25）
準備
- 2026/08/25版 Windows 11（25H2）ISO を用意
- OS高速スタートアップおよびマザーボード側の FastBoot を無効化
- 「システム構成（msconfig）」から、Microsoft 以外のサービスを一時的に無効化
リプレースインストール
- セットアップ開始時に表示される「ダウンロードの方法を変更」を展開し、続いて表示される「更新プログラム、ドライバー、オプション機能をダウンロードしてインストールするかどうか」の選択項目を開き、「今は実行しない」を選択してリプレースインストールを開始（※文言は環境により若干異なる場合があります）
- 所要時間：約30分
- インストール完了後、RITR（回復時の自動修復）が有効に戻っていたため、従来通り無効化
リプレースインストール直後の確認： PC設定の回復から「スタートアップ設定」経由でセーフモードを呼び出し、正常に起動できることを確認しました。
初回 Windows Update 実行
- GUI上で 100％ まで進行した後の再起動時に、従来見られた「適用中」の黒画面が表示されないという、私の環境では初めて見る挙動を確認
- 所要時間：約10分
初回 Windows Update 適用後の確認： 再度、 PC設定の回復から「スタートアップ設定」経由でセーフモードを呼び出し、正常に起動できることを確認しました。
Microsoft 以外のサービスを再度有効化
何らかのサードパーティ製サービス由来で「スタートアップ設定」画面の表示に影響が出ていた可能性も考慮し、以下の手順で切り分けを行いました。
- 「システム構成（msconfig）」から無効化していた Microsoft 以外のサービスを再度有効化
- その状態で、PC設定の回復から「スタートアップ設定」経由でセーフモードを呼び出し、正常に起動できることを確認
この結果から、今回の事象は「サードパーティ製サービスの競合」が主因ではない可能性が高いと判断しています。
まとめ（2026/08/25 時点）
- リプレースインストール（修復インストール）により、PC設定の回復から「スタートアップ設定」を経由したセーフモード起動が正常に復旧したことを確認しました。
- Microsoft 以外のサービスを一時的に無効化した状態、および再度有効化した状態のいずれにおいても、セーフモード起動は正常であり、サービス競合が主因である可能性は低いと考えられます。
- 今回の検証方法では、修復インストール時および Windows Update 適用時の干渉を極力排除したため、「障害発生環境下での再発・再現性」を確認することはできませんでした。
検証不可能になった修復手法について
今回のリプレースインストールにより、私の環境では問題が解消され再現性が失われたため、以下の手法については「実際に障害が発生している状態での検証」が行えなくなりました。
- BCDストアの再構築
- SafeOS Dynamic Update（DU）の再適用確認
- 回復パーティションの再構成
これらの手法は構造的には有効である可能性がありますが、いずれも起動基盤や回復環境に対する深い操作を伴うため、一般ユーザー向けの推奨策とはせず、現時点では「研究目的の候補」として位置付けます。
一般的な読者の方には、今回の検証結果を踏まえ、安全性が高く再現性も確保できる「上書きインストール（リペアインストール）」を第一候補の修復策として検討することを推奨します。
記事改定履歴
2026/08/25（確定版）
- 今回の事象（Startup Settings が表示されず通常起動にフォールバックする）について、リプレースインストール（修復インストール）により正常に復旧することを確認しました。
- 「検証環境とリプレース（修復）インストール実行（2026/08/25）」セクションを新規追加し、検証結果・再現性・サービス競合の可能性・恒久的な修復策を確定版として反映しました。
- 暫定版で提示していた「未検証」「後日反映」などの表現を削除し、記事全体を確定版の内容に統一しました。
- 記事冒頭の注意書きを修正し、本記事は本版をもって内容確定とする旨を明示しました。
2026/08/24
暫定策（第一報）の「■ 2. コマンドで起動オプションを強制表示する」で紹介していた
bcdedit /set {default} bootmenupolicy legacy および
bcdedit /set {default} bootmenupolicy standard
について、私の環境（特に 25H2）では動作が安定しなかったため、以下のコマンドに変更しました。
bcdedit /set advancedoptions onbcdedit /set advancedoptions off
また、「確定版の修正／回復策」セクションに、今回の検証で判明した途中経過を追加しました。
コメント