Windows 10とLinux Mintのデュアルブートが「OSが見つからない」になったときの復旧ガイド：EFI消失・SSD未認識まで一気に切り分ける

ノートPCでWindows 10とLinux Mintをデュアルブートしていたのに、スリープ復帰後や青画面の直後から「No OS found（OSが見つからない）」で起動不能になるケースは珍しくありません。特に多いのが、UEFI起動に必須のEFI領域（ESP）が壊れる／参照が飛ぶ、そして復旧作業中に「そもそも内蔵SSDが見えない」という二段構えのトラブルです。
この記事では、MintのUSB起動環境だけでできる切り分けから、EFI復旧・GRUB再導入・Windowsブート修復まで、順番どおりに実行すれば迷いにくい手順をまとめます。

Windows 10とLinux Mintのデュアルブートが「OSが見つからない」になったときの復旧ガイド：EFI消失・SSD未認識まで一気に切り分ける

まず押さえる：原因は大きく3系統

同じ「OSが見つからない」でも、原因はだいたい次のどれかに収まります。

UEFI設定が変わった／起動順序が壊れた（Windows Boot ManagerやGRUBのエントリが消えた）
EFIシステムパーティション（ESP）が破損・不足・マウント不能（Linuxのブート設定が書けない、または消えた）
内蔵SSD自体が認識されていない（物理故障・接続不良・BIOS設定・暗号化/RAID設定など）

ここを混同すると遠回りになります。特に「ディスク管理ツールが内蔵ドライブを見ない」場合は、ブート修復以前に“ドライブ認識”の問題を先に解決する必要があります。

Step 1：BIOS/UEFIで内蔵SSDが見えるか確認（最重要）

Mint USBを挿す前に、まずUEFI画面で以下を確認します。

Storage / NVMe / SATA情報に1TB SSDが表示されるか
ブートモードが UEFI になっているか（Legacy/CSMに変わっていないか）
Secure Boot の状態（オンでも動く構成はありますが、復旧時はオフが楽なことが多い）
SATA Mode（AHCI/RAID/Intel RST など）
- Windows側でRST（RAID）に寄った設定だと、Linuxから見えないことがあります

UEFI画面でもSSDが見えないなら、OSやGRUBの問題ではなく、物理・設定レベルの可能性が高いです。まずはUEFIでSSDが表示される状態に戻す（設定・接続・故障切り分け）ことが先決です。

Step 2：MintのライブUSBで「ドライブ認識」を切り分ける

Mintライブ起動後、ターミナルで次を確認します。

lsblk
sudo fdisk -l
NVMe機なら ls /dev/nvme*
可能なら sudo smartctl -a /dev/nvme0n1（smartmontoolsがなければ導入）

ここで内蔵SSDが 一切出てこない 場合、よくある原因は次の通りです。

UEFIでSATA/Storage設定が変わった（AHCI⇔RAID/RST）
Secure BootやTPM絡みで起動ディスク扱いが変化
省電力復帰の不具合でNVMeがハング（完全シャットダウンで復帰することも）
物理的なSSD故障・コネクタ不良

一方、ドライブは見えるがEFIが見当たらない（EFIパーティションが出ない、または空に見える）なら、次のステップでEFI復旧を狙えます。

Step 3：EFI（ESP）が小さすぎ問題も疑う

デュアルブートで意外と多い落とし穴が、Windows標準で作られたEFI領域が小さいことです。
Windows単体なら足りるサイズでも、Linux（GRUB）や複数カーネル、追加ブートローダーが入ると容量が逼迫し、更新時に書き込み失敗→ブート構成が壊れる流れが起きがちです。

目安としてEFI領域は 300MB以上（できれば500MB程度） あると安定します。100MB前後だと不安が残ります。

Step 4：手堅い復旧ツール「Boot-Repair」を使う（簡単ルート）

「より強力なツールが欲しい」という場面で定番なのが Boot-Repair です。
ライブ環境から起動して、GRUB再導入やEFIエントリ修復を自動化できます。ブート修復の第一選択として有効です。

ただし注意点があります。

内蔵SSDが認識されていない状態ではBoot-Repairでも直せません
先にStep 1〜2でドライブ認識を解決してください。
自動修復は便利ですが、ディスク構成が複雑だと意図しない書き換えをすることがあります。重要データがある場合は、可能ならバックアップを優先します。

Step 5：手動で直す場合の王道（EFIマウント→GRUB再導入→UEFI登録）

SSDが見えていて、Linuxのルート（/）パーティションも存在するなら、手動復旧が確実です。流れは以下。

ルートパーティションをマウント
EFIパーティション（FAT32、フラグESP）を /boot/efi にマウント
chrootでMint環境に入りGRUBを再インストール
efibootmgr でUEFIブートエントリを確認・修復

典型的には「EFIが壊れていた」「EFIにGRUBが消えた」「UEFIのエントリが消えた」のどれかが直ります。

Step 6：Windows側のブートも戻したい場合（共存を安定させる）

デュアルブート復旧でやりがちなのが、GRUBだけ直してWindowsが起動しない、またはその逆です。安定させるコツは次の考え方です。

UEFI上では基本的に
Windows Boot Manager と GRUB の両方がEFI領域に存在するのが正常
GRUBからWindowsをチェーンロードして起動するか、UEFIの起動メニューで切り替える

Windowsの回復環境で修復するなら、EFIにWindowsのブートファイルを再配置する手順（bcdboot等）が王道ですが、環境依存が大きいので、まずは「Windows Boot ManagerのエントリがUEFIに残っているか」を確認するのが先です。

Step 7：再発防止の設計：安定するデュアルブートの作り方

コメントでも触れられがちな結論はシンプルです。

可能なら WindowsとLinuxは別ディスク が最も安定
物理的に分離できると、片方の更新や修復がもう片方に波及しにくいです。
同一ディスク運用なら
- EFI領域は 余裕のあるサイズ（300〜500MB以上）
- Linuxの/boot/efiマウント設定を適切に維持
- 大型更新前にバックアップ（特にEFI領域）

そしてインストール順は原則として Windows→Linux。Windowsを後から入れるとブート周りを上書きしがちで、復旧作業が増えます。

まとめ：最短で直すための優先順位

最後に、迷わないための優先順位だけ整理します。

UEFIでSSDが認識されているか（見えないなら設定/物理を優先）
ライブUSBで SSDとパーティションが見えるか
EFI領域（ESP）が存在・マウントできるか（サイズ不足も疑う）
まずは Boot-Repairで自動修復（SSDが見える前提）
ダメなら EFIマウント→GRUB再導入→UEFI登録 の手動ルート
再発防止は 別ディスク運用 or EFI領域拡張＋管理徹底

この順番を守るだけで、「ブート修復を頑張っているのにディスクが見えていない」という空回りを避けられます。デュアルブートは壊れやすい領域がはっきりしているので、切り分けさえ正しければ復旧の成功率は一気に上がります。