- 一呼吸おいて!
- すぐにアップグレードしない方がいい環境
- より詳細な説明
- EFI 領域が 100MB のまま
- メモリ 8GB 以下
- ストレージ空き容量が 30GB 未満
- 古いストレージ(SATA SSD / HDD)
- 古い BIOS / 古い UEFI の機材
- 最新の AU(累積更新)が適用されていない PC
- Windows 11 の適用要件を満たしていないまま導入した PC
- メーカーが「BIOS 更新推奨」や「Windows 11 対応 BIOS」を出しているのに未更新の機材
- 特殊な構成(BitLocker / WinRE カスタム / 企業向けイメージ)
- ユーザーフォルダをシステムディスク以外に移動している PC
- Servicing Stack(SSU)が古いままの PC
- 以下より特殊な条件
- より詳細な説明
- すぐにアップグレードしない方がいい環境
- Windows 11 Version 26H2 の一般提供開始日
- アップグレード前に必ず整えておくべき環境
一呼吸おいて!
Windows 11(26H2)の一般向け提供が開始されましたが、ここは一呼吸置いてください。
すぐに 26H2 に移行せず、まずは様子見を推奨します。少なくとも 1 ヶ月程度は待つのが安全です。
今後、検証結果などもブログで順次記事化しますが、特に以下に該当する方は、すぐに Windows 11(26H2)へアップグレードしないでください。
すぐにアップグレードしない方がいい環境
| 条件 | 理由・影響 |
|---|---|
| EFI 領域が 100MB のまま | Microsoft 推奨の 250MB を満たしておらず、26H2 は実質 2500MB 以上を前提としている可能性あり。領域不足でアップグレードが失敗しやすい。 |
| メモリ 8GB 以下 | SafeOS 切り替えや展開処理でメモリ不足が起きやすい。AI 機能とメモリを共有するため、アップグレード後の動作も不安定になりやすい。 |
| ストレージの実質空き容量が 30GB 未満 | シャドウコピー・仮想メモリ・一時領域・WinRE 展開領域を含めると不足しやすい。総容量の 1/3 程度の空きが望ましい。 |
| 古いストレージ(SATA SSD / HDD) | I/O が遅く、SafeOS 切り替えや展開処理が遅延し、結果的に失敗率が高くなる。HDD はアップグレード後の動作も重い。 |
| 古い BIOS / 古い UEFI の機材 | 「Windows 11 対応 BIOS」が提供されているのに未更新の場合、ブートローダー更新時の互換性問題で失敗しやすい。 |
| 最新の AU(累積更新)が適用されていない PC | SafeOS や WinRE が古いままアップグレードされ、処理中の不具合が発生しやすい。DU は制御できないため AU の適用が重要。 |
| Windows 11 の適用要件を満たしていない PC | TPM・SecureBoot・CPU 要件未満の機材は失敗率が非常に高い。一見 AU が適用されているように見えても内部では DU が落ちていることがあり、更新が壊れた状態で 26H2 に進むため危険。 |
| 過去に Feature Update で失敗した履歴がある PC | WinSxS・SafeOS・WinRE の内部不整合が残っている可能性があり、26H2 でも同じ箇所で再度失敗しやすい。 |
| メーカーが「BIOS 更新推奨」や「Windows 11 対応 BIOS」を出しているのに未更新 | UEFI の互換性問題が残っている可能性があり、アップグレード失敗のリスクが高い。 |
| 特殊な構成(BitLocker / WinRE カスタム / 企業向けイメージ) | 初期ロールアウト時に最も不具合が出やすい層。環境変数やスクリプトによるカスタマイズがアップグレード処理に影響する。 |
| ユーザーフォルダをシステムディスク以外に移動している PC | C ドライブ側に新しい Users が再生成されることがあり、OneDrive の Known Folder Move と衝突してファイル消失の事故が起きる可能性がある。 |
より詳細な説明
上記の内容について、より具体的な理由や背景、さらに細かな条件まで列挙しています。分量が多くなるため折りたたみ表示にしていますが、可能であれば一度目を通していただくことをおすすめします。アップグレードの成否に関わる重要な要素が含まれています。
※ 以下クリックすると展開します。
各項目の詳細を開く
EFI 領域が 100MB のまま
Windows 11 の Feature Update は EFI 領域に新しいブートローダーや構成ファイルを書き込みます。Microsoft の推奨値はすでに 250MB に引き上げられており、筆者の観察では 26H2 は実質的に 250MB 以上の EFI を前提として最適化されている可能性があります。100MB のままでは領域不足になり、アップグレード失敗の典型例です。
メモリ 8GB 以下
アップグレード処理中は SafeOS への切り替えや展開処理でメモリを多く使用します。さらに Windows 11 の AI 機能(Cocreator など)はメモリを共有するため、8GB の機材ではアップグレード後に動作が極端に重くなる可能性があります。古い CPU と組み合わせると不安定さが顕著になります。
ストレージ空き容量が 30GB 未満
ここで言う「空き容量」は、エクスプローラーに表示される数字だけではありません。シャドウコピー領域・仮想メモリ・一時領域・WinRE の展開領域などをすべて含めた実質的な空き容量です。これらを理解しにくい場合は、最低でも 100GB 程度の空き、または総容量の 1/3 程度の空きがあることが望ましいと考えています。
古いストレージ(SATA SSD / HDD)
古いストレージは I/O が遅く、アップグレード処理全体が長時間化します。タイムアウトが頻発するわけではありませんが、SafeOS 切り替えや展開処理が遅延し、結果的に失敗率が高くなる層です。特に HDD の場合はアップグレード後の動作も重くなります。
古い BIOS / 古い UEFI の機材
メーカーが新しい BIOS を提供している場合は、更新してからでないと不具合が出る可能性があります。UEFI の互換性問題が残っていると、ブートローダー更新時に失敗することがあります。「Windows 11 対応 BIOS」が提供されている場合は必ず更新してください。
最新の AU(累積更新)が適用されていない PC
AU が未適用だと SafeOS や WinRE が古いままアップグレードされます。その結果、アップグレード中の不具合が発生しやすくなります。一般ユーザーは DU を制御できないため、AU の適用状況が最重要です。
Windows 11 の適用要件を満たしていないまま導入した PC
(TPM・SecureBoot・CPU 要件を無視して導入した機材は、Feature Update の失敗率が非常に高い層です。26H2 でも同様の問題が発生する可能性があります。さらに、一見 AU(累積更新)が適用されているように見えても、内部では DU(Dynamic Update)が適用されていないケースがあり、SafeOS や WinRE が古いまま更新が進んでしまうことがあります。内部的には更新が壊れている状態のまま 26H2 に進むことになるため、アップグレード自体を推奨しません。)
メーカーが「BIOS 更新推奨」や「Windows 11 対応 BIOS」を出しているのに未更新の機材
UEFI の互換性問題が残っている可能性があります。特に Windows 11 対応 BIOS が提供されている場合は、更新していないとアップグレードが失敗する可能性が高いです。
特殊な構成(BitLocker / WinRE カスタム / 企業向けイメージ)
初期ロールアウト時は最も不具合が出やすい層です。BitLocker の有効化状態や WinRE のカスタム構成がアップグレード処理に影響することがあります。企業向けに環境変数やスクリプトでカスタマイズしている場合は、十分な検討と事前テストを行ってください。
ユーザーフォルダをシステムディスク以外に移動している PC
(現在でも「プロパティ → 場所」からユーザーフォルダを移動できますが、この方法は Windows 11 の Feature Update と相性が悪く、展開処理が正常に行われない可能性があります。特に Users フォルダを別ドライブへ移動している場合、アップグレード時に C ドライブ側に新しい Users フォルダが再生成されることがあり、OneDrive の Known Folder Move と衝突して ファイルが消失する事故が起きる可能性があります。ProfilesDirectory の変更やシンボリックリンクによる移動も同様に危険です。)
Servicing Stack(SSU)が古いままの PC
過去の Windows 7 SP1 や Windows 10 の大型更新でも、Servicing Stack(SSU)が古いままだとアップグレード前の前処理が正常に行われず、途中で停止する・ロールバックするといった問題が発生していました。Windows 11 でも SSU は AU と同時に更新されるため、AU が適用されていない環境では前処理が古いままアップグレードが進行し、途中でクラッシュする可能性があります。
以下より特殊な条件
SafeOS が古いままの PC
SafeOS はアップグレード中に使用される「別のミニOS」で、Windows 10 時代からSafeOS が古いとアップグレードが途中で止まる・再起動ループになる問題がありました。DU が適用されていない環境では SafeOS が古いまま残るため、26H2 の展開処理で SafeOS 切り替え時に失敗する可能性があります。
WinRE が壊れている・存在しない PC
Windows 10 → 11 の移行期でも、WinRE が壊れている PC はアップグレード中に回復環境の展開ができず、途中で停止する問題がありました。WinRE が壊れている状態は AU では気づきにくく、アップグレード時に初めて問題が表面化する典型例です。
過去のアップグレードでロールバック履歴がある PC
Windows 10 時代から、過去にアップグレードがロールバックした PC は内部構造(WinSxS・SafeOS・WinRE)が不整合のまま残っていることがあり、次のアップグレードでも同じ箇所で失敗する傾向があります。ロールバック履歴がある PC は 26H2 でも再発する可能性が高い層です。
レガシーなドライバ(特に Intel ME / AMD PSP)
Windows 10 → 11 の移行期でも、Intel ME や AMD PSP の古いドライバが残っているとアップグレード中にハードウェア初期化が正常に行われず、SafeOS 切り替えで失敗する例がありました。ファームウェア系ドライバが古いままの PC はアップグレード失敗率が高い層です。
レガシーな周辺機器ドライバ(古いプリンタ・古い USB デバイス)
Windows 10 の大型更新でも、古いプリンタドライバや古い USB デバイスがアップグレード処理を妨げる例がありました。Windows 11 でも同様で、アップグレード前に不要な周辺機器を外すことが推奨されます。
OneDrive の旧同期方式が残っている PC
Windows 10 → 11 の移行期でも、OneDrive の旧同期方式(Groove.exe 時代の設定)が残っているとKnown Folder Move と衝突し、アップグレード後にファイルが消失する例がありました。
OneDrive の設定が古いままの PC は、ユーザーフォルダ移動と組み合わせると特に危険です。
レガシーなレジストリ変更(カスタム設定)が残っている PC
Windows 7 → 10、10 → 11 の移行期でも、レジストリでカスタム設定を行っている PC はアップグレード中に互換性チェックが正常に行われず、途中で停止する例がありました。特に「ProfilesDirectory」「ProgramFilesDir」などの変更は危険です。
Windows 11 Version 26H2 の一般提供開始日
Windows 11 Version 26H2 の一般提供(GA)は、米国時間 2026 年 9 月 29 日に開始され、
日本では 2026 年 9 月 30 日〜10 月 1 日にかけて順次配信されています。
詳細
- 一般提供開始日
米国時間:2026 年 9 月 29 日
日本時間:2026 年 9 月 30 日〜10 月 1 日
Microsoft 公式発表:September 29, 2026 - 配信方法
Windows Update 経由の段階的ロールアウト(controlled feature rollout)対象:Windows 11 Version 25H2 / 24H2「最新の更新プログラムをすぐに入手する」が ON の場合は自動的にダウンロード・インストールとされています。 - 提供対象ビルド番号
現状、26H2 は 2026 年 9 月の定例累積更新(KB5124010)適用後の OS ビルド 26300.9550 に対して配信されているようです。プレビュー更新(2026 年 9 月 22 日配信)を適用している環境では、より早期に表示される可能性があります。 - サポート期間
Home / Pro:24 ヶ月
Enterprise / Education:36 ヶ月
最初の Patch Tuesday:2026 年 10 月 13 日
アップグレード前に必ず整えておくべき環境
Windows 11(26H2)のアップグレードは、SafeOS・WinRE・EFI・ドライバ署名・サービス依存関係など、
複数の層が同時に切り替わる「多層トランザクション」です。
そのため、余計な要素を減らし、OS が本来の構成で処理できる状態を作ることが成功率に直結します。
以下は、最小構成化よりも広い範囲で必ず整えておくべき環境です。
アップグレード適用ラインの考察
以下の構成は「アーリーアダプタとして今すぐ 26H2 を適用したい方」向けの“大丈夫ライン”です。安定してから適用する一般ユーザー向けの最低ラインとは異なりますのでご注意ください。
この程度の構成であれば、Windows 11(26H2)のアップグレードは「ほぼ」確実に安全と考えています。(アップグレード後の安定性まで含めた “大丈夫ライン”)
私の考えではありますが、これより下の構成は「チャレンジャー」と捉え、不都合が発生した際に自力で対処できる方のみがアップグレードを実行する範囲と考えています。
● M/B・チップセット
・Intel:400 シリーズ以降(Z490 / B460 / H470 以上)
・AMD:B550 / X570 以降
※ AI OS 化でストレージ判定が厳密化するため、古いチップセットは避ける。
● CPU
・Intel:第 11 世代以降(Tiger Lake / Rocket Lake)
・AMD:Ryzen 5000(Zen3)以降
※ 第10世代は動作はするものの、AI OS の常駐負荷を考えると推奨ラインには入れない。
● メモリ
・最低 16GB(メモリは32GBを推奨。実質必須に近い)
※ AI 常駐領域・NPU バッファ・GPU UMA が増えるため、16GB は「動作はする」下限。
● GPU
・ディスクリート GPU:RTX 20 シリーズ以降 / Radeon RX 5000 以降
・iGPU のみでも動作はするが、AI 機能の一部が制限される
※ アップグレード時に GPU ドライバの切り替えが走るため、古い世代は不具合が出やすい。
● ストレージ
・OS は「マザーボード直結のストレージ」1 台に配置(増設カード経由不可)
・NVMe は M.2 スロット直結(PCIe 増設ボード経由は避ける)
・総容量 500GB 以上(空き容量は 30GB 以上、できれば総容量の 1/3)
※ SafeOS/WinRE の再構成が安定し、回復領域のズレが起きにくい。
● その他
・EFI 領域は 300MB 以上
・総合ユーティリティ(電源管理・ファン制御・RGB制御など)は一旦削除
・セキュリティソフトは一時停止
・高速スタートアップと M/B の Fast Boot は無効化
AI機能に関する重要な注意(NPU非搭載CPUの場合)
26H2 の新機能には Copilot、Recall、Studio Effects、Live Captions など、
AI を前提とした機能が多数含まれていますが、NPU(Neural Processing Unit)を
搭載していない CPU では、これらの AI 機能が一部または大部分が制限されます。
Ryzen 8000 番台・9000 番台でも「Ryzen AI 非搭載モデル」が存在するため、
型番だけでは AI 機能がフルに使えるとは限りません。
Intel 第 11 世代・第 12 世代、Ryzen 5000/7000 などの NPU 非搭載 CPU では、
以下のような制限が発生します。
・Studio Effects(背景ぼかし・アイコンタクトなど)が利用できない、または遅い
・Recall が利用できない構成がある
・Copilot のリアルタイム処理が CPU にフォールバックし、動作が重くなる
・GPU UMA と合わせてメモリ消費が増え、16GB 構成では余裕がなくなる
AI機能を目的として 26H2 を適用する場合は、NPU 搭載 CPU(Core Ultra / Ryzen AI)
が必須に近いと考えてください。
番外:総合ユーティリティは一旦削除を推奨
メーカー製 PC の総合ユーティリティ(電源管理・ファン制御・最適化ツール)、
GPU のオーバークロック/電力管理ユーティリティ、
そして マザーボードの総合ユーティリティ(電圧管理・ACPI 拡張・ファン制御) は、
Windows 11(26H2)のアップグレード処理と深く競合する可能性があります。
- ACPI(電源管理)への深いフック
- フィルタドライバ・カーネルモジュールの常駐
- GPU / CPU の OC 設定が SafeOS と競合
- 起動時 DLL が WinRE 展開と衝突
- サービス停止では残骸が残るケースがある
これらは「停止」では不十分で、アップグレード中に SafeOS がクラッシュし、
ロールバックが発生する典型例です。
少なくとも 25H2 に対応していない総合ユーティリティは、一旦削除することを強く推奨します。
(再入手できない場合があるため、必要に応じて事前にインストーラーを確保してください)
必ず整えておくべき環境
以下の項目は、Windows 11(26H2)へのアップグレード前に必ず整えておくべき内容です。まずは全体像を確認してください。
- OS・ブート・サービスまわりの整理
- ドライバ・署名・ファームウェアの整理
- ストレージ・EFI・WinRE の健全性確認
- Windows Update の前提条件を整える
- アップグレード方式の選択
- 最低限のバックアップ
| 項目 | 内容 |
|---|---|
| OS・ブート・サービスまわりの整理 | OS 側の高速スタートアップ無効化、マザーボード側 Fast Boot 無効化、msconfig で「Microsoft 以外のサービス」を停止、周辺機器を外して最小構成化。 |
| ドライバ・署名・ファームウェアの整理 | Intel ME / AMD PSP の更新、古いフィルタドライバの確認、IRST / AMD RAID の更新、BIOS / UEFI の最新化(Windows 11 対応 BIOS がある場合は必須)。 |
| ストレージ・EFI・WinRE の健全性確認 | ストレージの実質空き容量 30GB 以上(できれば総容量の 1/3)、EFI 領域 300MB 以上(100MB の場合は拡張)、WinRE の正常性確認。 |
| Windows Update の前提条件を整える | 最新 AU の適用、DU が落ちていないか確認、過去にロールバック履歴がある場合は整合性チェック。 |
| アップグレード方式の選択 | 標準アップグレード方式(できる限り、こちらを推奨)、制限解除型アップグレード方式(/Compat IgnoreWarning)。 |
| 最低限のバックアップ | ユーザーデータのバックアップ、必要に応じてシステムイメージ取得。 |
- ※ EFI領域の拡張については「【コラム】おさらい-EFI 100MB時代の終焉:2026年問題とWindows Update不具合の正体【2026/05/05】」を参照してください。
- ※ AUとDUの確認方法は「【資料】Windows の更新プログラムを“正しく”一覧する-導入された KB を確実に確認/削除するための技術リファレンス【2026/09/08】」を参照してください。
- ※ OSアップグレード前の留意事項全般については「【準備編】Windows Updateに賢く備えるための必須対策まとめ」も参考にしてみてください。
空き領域の確定方法
Windows の「空き容量」は NTFS の未使用領域を示すだけで、シャドウコピー・復元ポイント・WinRE・休止ファイル・仮想メモリ・Windows Update の作業領域などは “空き領域の中で動く”ため、実際に使える空き容量とは異なります。
以下の手順で、アップグレードに必要な「実質空き容量」を推定します。
1. シャドウコピー(VSS)の使用量を確認する
最も空き領域を圧迫するのがシャドウコピーです。PowerShell(管理者)で以下を実行します。
vssadmin list shadowstorage
「Used」が現在シャドウコピーが占有している容量です。
例:Used = 12GB → 表示空き容量から 12GB を差し引きます。
2. 復元ポイント(RITR)の使用量を確認する
復元ポイントが大量にある場合、10〜40GB 程度が空き領域内で消費されます。
vssadmin list shadows
復元ポイントが多い場合は削除を検討します(必要に応じて自己判断)。
3. Windows Update の作業領域を考慮する
AU / DU / SafeOS の更新直前・直後は、一時的に 10〜20GB 程度の作業領域が必要になります。
これは直接確認できないため、推定値として差し引きます。
4. 実質空き容量の計算式
以下の式で「実際にアップグレードに使える空き容量」を推定できます。
実質空き容量 = 表示空き容量
− シャドウコピー使用量
− 復元ポイント使用量
− Windows Update 作業領域(10〜20GB)
例:表示空き 120GB、シャドウコピー 12GB、復元ポイント 18GB、WU 作業領域 20GB
→ 実質空き容量 = 120 − 12 − 18 − 20 = 70GB
※ 実質空き容量が 30GB を下回る場合、アップグレード処理(SafeOS 展開・WinRE 再構成・EFI 書き換え)が失敗する可能性があります。
補足:高速スタートアップと休止ファイル(hiberfil.sys)について
高速スタートアップを無効化しても、休止ファイル(hiberfil.sys)は自動では削除されません。
高速スタートアップは休止ファイルを利用しているだけで、休止ファイル自体はカーネルの状態保持・SafeOS・WinRE・一部の AI 機能など複数の用途に使われるためです。
Windows Update や OS アップグレードが領域不足になった場合でも、休止ファイルが自動削除されることはありません(必要に応じて縮小される場合はあります)。そのため、表示上の空き容量が十分でも、実質空き容量が不足してアップグレードが失敗するケースがあります。
特に Windows 11(26H2)は AI OS の本格統合版であり、休止ファイルが内部処理の一部で利用される可能性があります。アップグレード前に休止ファイルを完全削除することは推奨しません。
高速スタートアップの無効化のみで十分です。
深堀り:エクスプローラー不可視ファイルと可視ファイル-そして作業用空き容量
※ クリックで展開します
Windows Update/OSアップグレード時の空き容量の意味
Windows Update や OS アップグレードが参照する「空き容量」は、NTFS の未使用領域のみです。休止ファイル(hiberfil.sys)や仮想メモリ(pagefile.sys)は NTFS 上の通常ファイルとして
“使用領域” に計上されるため、空き容量の計算には含まれません。
そのため、エクスプローラーで「空き容量 100GB」と表示されている場合、休止ファイルが 40GB あっても、アップグレードに利用できる空き領域は 100GB のままです。休止ファイルは空き領域を消費しないため、実質空き容量から差し引く必要はありません。
アップグレード時に空き領域を消費するのは以下の項目です:
- シャドウコピー(VSS)
- 復元ポイント(RITR)
- Windows Update の作業領域(10〜20GB)
- WinRE の展開領域
これらは “空き領域の中で動く” ため、実質空き容量の計算では差し引く必要があります。
通常の作業時の空き容量の意味
通常の作業時にエクスプローラーで表示される「空き容量」は、NTFS の未使用領域です。休止ファイル・仮想メモリ・システム予約領域などは使用領域側に計上されるため、空き容量の計算には含まれません。
そのため、空き容量が 100GB と表示されている場合は、実際に 100GB の領域がアプリケーション・ファイル保存・一時領域として利用できます。
ただし、シャドウコピーや復元ポイントが増えると、空き領域内で消費されるため、実質的な空き容量が減少することがあります。
アップグレードの際できれば行っておいたほうが良い操作(要約)
- ストレージの実質空き容量を 30GB 以上確保する
詳細な確認方法は「空き領域の確定方法」セクションで解説しています。シャドウコピー・復元ポイント・Windows Update の作業領域を差し引いたうえで、30GB 以上を確保しておくと安全です。 - Intel ME / AMD PSP などの管理系ドライバを更新しておく
古い管理エンジン系ドライバは 26H2(AI OS)で常駐領域が増えた際に不安定要因になります。「ドライバ・署名・ファームウェアの整理」の項目と合わせて確認してください。 - WinRE と EFI の状態を事前に確認しておく
reagentc /infoによる WinRE の有効状態確認、EFI 領域の容量確認(100MB の場合は拡張検討)は、アップグレード時の SafeOS/回復環境再構成の失敗を防ぐうえで重要です。 - 最低限のバックアップを取っておく
ユーザーデータだけでも外部ストレージに退避しておくと、万が一ロールバック不能になった場合でも復旧が容易です。
構成面で「できれば」やっておきたいこと
一度「完全シャットダウン」を行う
- 一度「完全シャットダウン」を行う
高速スタートアップのセッションが残っていると、アップグレード時に古い状態を参照してしまうことがあります。
また、完全シャットダウンを行うことで、UEFI・ACPI・デバイス初期化がすべて再読み込みされ、ハードウェア構成を最新の状態で認識させることができます。(可能な限り、Shiftキー+シャットダウンではなくこちらの方法を取ってください。)shutdown /s /f /t 0アップグレード前に一度だけ完全シャットダウンしておくと、SafeOS が誤った構成情報を参照するリスクを減らせます。
- 可能なら、OS を載せるストレージを一台に絞る
複数ストレージ構成や、増設ボード経由の NVMe からの起動は、SafeOS や WinRE の再構成時に「どのディスクをシステムとみなすか」が複雑になります。アップグレード中だけでも、マザーボード直結のストレージ 1 台から起動する構成にしておくと、意図しないディスク側に OS や回復環境が展開されるリスクを減らせます。
Windows 11 にしている機材でも、元々 M.2 スロットがなく、PCIe 増設ボード(M.2 アダプタ)から OS を起動している構成の人がいます。
結論として、この構成は Windows 11 のアップグレード時に失敗しやすく、ターゲットではないストレージ側に OS をインストールしようとする挙動が発生する可能性があります。
深い仕組みまで踏み込むと読者にとって重くなるため、記事では「アップグレード時はできるだけマザーボード直結ストレージからの起動を推奨する」という表層の注意喚起に留めるのが現実的です。

コメント