AOMEI PreOS後にWindowsが起動しない原因と復旧手順：0x0000007B（INACCESSIBLE_BOOT_DEVICE）を直す

Windowsのパーティションを縮小してFedoraとデュアルブートにしようとしたところ、AOMEIのPreOS（再起動して実行される特殊モード）で処理が中断し、その後Windowsが極端に不安定になり、最終的に「0x0000007B」や「Ntfs関連（ntfs.sys等）」のエラーで起動不能になる――これは珍しくないトラブルです。
結論から言うと「かなりまずい状態」になり得ますが、手順を踏めば復旧できる可能性は十分あります。この記事では、なぜ起きるのか、何から確認し、どう直すかを“失敗しやすい順”にまとめます。

AOMEI PreOS後にWindowsが起動しない原因と復旧手順：0x0000007B（INACCESSIBLE_BOOT_DEVICE）を直す

まず症状を整理：0x0000007Bは何が起きているのか

ブルースクリーンの 0x0000007B は、多くの場合 INACCESSIBLE_BOOT_DEVICE（起動ディスクにアクセスできない） を意味します。要するに、Windowsが起動時に必要なストレージ（SSD/HDD）や、その中のシステム領域を正しく読めていません。

パーティション操作の直後に起きる場合、原因はだいたい次のどれかに集約されます。

パーティションの境界/メタデータが不整合（移動・縮小の途中失敗でNTFS情報が壊れる）
EFI/回復/予約領域など“見えにくい領域”が変更され、起動構成が崩れる
ブート関連（BCD/EFI）が参照するパスがズレた
ディスク暗号化（BitLocker）や高速スタートアップと干渉
BIOS設定（SATAモード/UEFI設定）の変化が偶然重なった

AOMEIがPreOSで動くのは、Windowsが稼働したままでは移動できない領域（Cドライブの先頭側など）を扱うためです。つまりPreOS中断は「途中でディスクの地形を変えたまま止まった」可能性があり、起動不能に直結します。

「縮小できるのに20GBしか空かない」根本原因

Windows標準のディスクの管理で縮小量が小さくなるのは、空き容量が十分あっても “動かせないファイル”が末尾付近に残る からです。代表例は以下です。

ページファイル（仮想メモリ）
休止状態ファイル
システム保護（復元ポイント）
断片化したMFTなどNTFSメタデータ

これを理解せずに外部ツールで強引に大きく縮小すると、今回のような事故が起きやすくなります。

最優先：データを守る（ここを飛ばすと取り返しがつかない）

すでに起動不能なら、まずは「直す」より「守る」が先です。

可能なら別PCでWindowsインストールUSB（または回復ドライブ）を作成
起動できたら回復環境（WinRE）へ入り、最悪に備えて
重要データを外付けへ退避（USB SSD/ HDD など）
Fedoraのインストール作業はいったん中止（追加の書き込みで悪化し得る）

修復作業の途中でchkdsk等が走ると、壊れ方によっては「失われたファイルの整理」が起き、状況が不可逆に変わる場合があります。だからこそ先に退避が鉄則です。

いちばん簡単に直る可能性がある確認：BIOS/UEFI設定

0x0000007Bは、作業のタイミング次第でBIOS設定の変化が重なって発生することがあります。以下を確認します。

UEFIで起動しているか（Legacy/CSMに変わっていないか）
SATAモード（AHCI/RAID/Intel RST など）が変わっていないか

もし以前と違っていれば、元に戻して再起動します。これだけで復帰するケースもあります。

Windows回復環境（WinRE）での王道手順

WindowsインストールUSBから起動し、
「コンピューターを修復する」→「トラブルシューティング」→「詳細オプション」を開きます。

1) スタートアップ修復（起動修復）

最初に試す価値があります。BCDやブート周りの軽微な崩れなら自動で直ることがあります。

2) システムの復元

AOMEI導入前後で復元ポイントが残っていれば有効です。パーティション変更そのものは戻らない場合もありますが、起動関連の整合が戻って起動することがあります。

3) コマンドプロンプトで段階的に修復

自動修復でダメなら、次の順に“被害を広げにくい”ものから試します。

ディスクチェック（ファイルシステム整合）
chkdsk C: /f
※環境によってWindowsのドライブ文字が変わるので、diskpart→list volで確認してから実行します。
システムファイル検査（オフライン）
sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
ntfs関連の破損がある場合に効くことがあります。
ブート構成の再作成（UEFI想定）
EFIパーティションに起動ファイルを入れ直す手段です。
代表的には bcdboot C:\Windows /l ja-jp を使いますが、EFIパーティションの割り当てが必要なこともあります。
（ここは手順を誤ると起動構成をさらに壊すリスクがあるため、データ退避後に行うのが安全です）

ここまでで直らない場合、パーティションそのものの不整合が重い可能性があります。

「バックアップに戻す」が最短ルートになることがある

今回のケースでは、PreOS中断後に極端なラグやフォーカス喪失が出ています。これはOSの動作以前に、ディスクI/Oが不安定だったり、システム領域が損傷している兆候です。
もし パーティション操作前にAOMEI等でバックアップを作っていた なら、復旧は「修復」より バックアップ復元 が早く確実です。起動不能系は“整合が戻ったように見えても再発する”ことがあるため、時間を節約できます。

直った後に同じ事故を防ぐ：Fedoraデュアルブートの安全な進め方

復旧できたとしても、次の一手を誤ると再発します。安全策はこうです。

Windows標準機能で縮小できる範囲でまず確保（小さくてもよい）
さらに必要なら、先にWindows側で
休止状態OFF、ページファイル調整、復元ポイント整理、再起動、最適化（デフラグ相当）
などを行い、縮小可能量を増やす
それでも足りない場合は、外部ツールを使う前に
完全バックアップ（イメージ） を取る
Linuxインストール時は、EFI領域を消さない/フォーマットしない（既存を共有するのが基本）

「300GB空いているのに縮小できない」はWindowsの仕様上よくある話なので、焦って強引なツールに頼るほど危険度が上がります。

まとめ：やるべき優先順位

追加の操作を止め、可能ならデータを退避
BIOS/UEFI設定（UEFI・SATAモード）を確認
WinREの起動修復→復元→chkdsk/sfcの順に試す
バックアップがあるなら復元が最短
復旧後は、縮小の前準備とバックアップを徹底して再挑戦

「Is it that bad?」に対しては、“放置や手当たり次第の修復は悪化し得るので危険”が答えです。ただし、正しい順番で対処すれば救える見込みはあります。復旧が最優先なので、まずはデータ保全と回復環境からの修復を進めてください。