【2026年】デュアルブート トラブルシューティングガイド｜起動しない・消えた時の対処

Linux が起動しない場合の chroot 修復手順

Windows の問題ではなく、Linux 側が原因でデュアルブート環境が機能しなくなることがあります。具体的には、Linux カーネルの更新失敗や GRUB2 の破損により、起動時に「GRUB rescue>」というプロンプトが表示されたり、カーネルパニックが発生したりするケースです。この場合、Windows は正常に動作しているため、Linux 側の OS ファイルシステムが破損していない限り、Live USB を使用してデータを持ち出して修復することが可能です。特に 2026 年では、Linux のセキュリティ更新頻度が高まっているため、更新中の電源断やディスクエラーによる GRUB の不具合が増加傾向にあります。

修復作業の核心は「chroot（変更ルートディレクトリ）」の使用です。これは、Live USB 上の環境を仮設的に Linux のインストール先に変更して、あたかもその OS 上で操作を行っているように見せる機能です。まず Live USB から起動し、lsblk コマンドを使用してパーティション構造を確認します。Linux のシステムが入っているパーティション（例：/dev/nvme0n1p3）と、EFI パーティション（例：/dev/nvme0n1p1）を特定します。誤って他のディスクやパーティションをマウントするとデータの破損につながるため、ID を確認するコマンド blkid も併用して慎重に特定を行います。

マウント完了後、chroot 環境に入り、GRUB の設定ファイルを再生成します。Linux ディストリビューションによって更新コマンドが異なりますが、Ubuntu や Debian ベースでは sudo update-grub、Fedora では sudo grub2-mkconfig -o /boot/grub2/grub.cfg、Arch Linuxでは grub-mkconfig -o /boot/grub/grub.cfg となります。また、カーネル自体に問題がある場合は、apt --fix-broken install や pacman -Syu を実行してパッケージ管理システムを修復します。これらは全て chroot 環境内で行うため、外部の Live 環境の依存関係に影響されず、インストール先の OS の状態を回復させることができます。

Windows が起動しなくなった時の BCD 再構築手順

デュアルブート環境において、Windows 側が起動しなくなるケースは Linux に比べて頻度は低めですが、発生した場合は深刻な影響を受けます。これは主に GRUB2 の設定変更ミスや、Linux 側のパーティション整理（例：GParted によるリサイズ）によって、EFI パーティション内の Windows ブートファイルのパスが正しく参照できなくなることが原因です。また、Windows のセキュリティ更新後に BCD ファイル自体が破損し、起動ウィザードが表示されない状態になることもあります。この場合、Linux 側のデータは守られるため、まずは Windows の回復環境を使用して修復を試みます。

修復手順は「インストールメディアからの起動」から始まります。Windows 11 のインストーラー USB を接続して PC を起動し、セットアップ画面で言語設定を行い、「次へ」をクリックします。この時、画面下部に表示される「コンピューターを修復する」オプションを選択します。ここからトラブルシューティングメニューに入り、「コマンドプロンプト」を開きます。コマンドプロンプトが起動したら、diskpart コマンドを実行してディスク管理ツールに入ります。ここで list disk と入力し、システムのディスクを確認します。通常は Disk 0 が該当しますが、誤操作を防ぐためパーティションサイズや種類で確認を行います。

次に、EFI パーティションを割り当てる必要があります。select disk 0 の後に list partition を実行し、サイズが約 100MB〜500MB で「システム」として認識されているパーティションを探します。これを select partition X（X は番号）で選択し、assign letter=Z を入力して Z ドライブとして割り当てます。これでコマンドプロンプト上で Windows の起動ファイルにアクセス可能になります。その後、bcdboot C:\Windows /s Z: /f UEFI コマンドを実行します。ここで C: は Windows のインストール先、Z: は EFI パーティションのドライブ文字です。このコマンドは BCD ファイルを再作成し、UEFI 環境用のブートエントリを正しく登録する役割を果たします。

パーティションが見えない・認識されない問題

デュアルブートのトラブルには、起動そのもの以前に OS がディスクのパーティション構造を認識しないケースがあります。具体的には GParted や Windows のディスク管理ツールで Linux の ext4 ファイルシステムが NTFS や FAT32 とは異なり表示されない、あるいはファイルとして認識されない現象です。これは主に、Windows の標準ドライバーが Linux のファイルフォーマット（ext4, btrfs 等）をサポートしていないことが原因です。また、BitLocker が有効になっている場合、暗号化されたパーティションが見えない、またはアクセス権限エラーが発生します。

この問題を解決するには、Linux Live USB から起動してパーティションを確認する必要があります。Live システムでは Linux カーネルのネイティブドライバーが使用されるため、ext4 パーティションを正しくマウントできます。sudo fdisk -l や lsblk -f コマンドを実行し、どのデバイスファイル（例：/dev/nvme0n1p3）に Linux のデータが入っているかを確認します。Windows 上でパーティション情報を見たい場合は、Linux パーティションを Windows で読み取り可能な形式に変換する必要はありますが、データバックアップが最優先事項です。誤ってフォーマットしてしまわないよう、マウント操作は慎重に行う必要があります。

2026 年時点では、Windows の WSL（Windows Subsystem for Linux）や第三パーティ製ツールにより、Linux ファイルシステムへのアクセス性が向上しています。しかし、デュアルブート環境でのパーティション認識には限界があり、基本的には各 OS がネイティブで扱うフォーマットに依存します。特に Btrfs や ZFS などの高度なファイルシステムを使用している場合、標準の Windows ツールでは完全に認識できません。この場合、Live USB を使用してデータを別のディスクへバックアップし、その後でパーティションテーブルを再構築することが安全策となります。

時刻のズレと UTC 問題の解決方法

デュアルブート環境において最も頻繁に発生するが、見過ごされやすいトラブルの一つがシステム時刻の不一致です。これは、Windows と Linux が BIOS/UEFI の時計に対して異なるアプローチをとっていることが原因です。Linux は標準的にハードウェアクロックを UTC（協定世界時）として扱い、OS 内でローカルタイムへ変換して表示します。一方、Windows は伝統的にハードウェアクロックをローカルタイム（その国の時刻）として扱う仕様になっており、BIOS の設定と OS の認識が食い違うと、片方の OS で時間が大幅に狂ってしまいます。

この問題を解決するには、両 OS で一貫した時間設定を行う必要があります。一般的な対策は、Linux 側を Windows と同じローカルタイム使用に変更するか、または Windows 側を UTC として扱うようにレジストリを編集する方法です。Linux 側の設定を変更する場合は、timedatectl set-local-rtc 1 --adjust-system-clock コマンドを使用します。これにより Linux は BIOS の時間をローカルとして扱います。2026 年現在では多くのディストリビューションがデフォルトで UTC を推奨していますが、デュアルブートユーザーにとっては互換性が優先されるべきです。

反対に Windows 側を UTC に変更する場合は、レジエディタの編集が必要です。regedit を起動し、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation キーを探索します。ここで RealTimeIsUniversal という DWORD 値を作成し、その値を 1 に設定します。これにより Windows は BIOS の時間を UTC として認識し、システム内でローカルタイムへ変換するようになります。変更後は必ず再起動を行い、両 OS で時刻が同期されているか確認してください。この設定は、デュアルブート環境の安定性を保つために必須の設定となります。

BitLocker とデュアルブートの競合対策

セキュリティ機能である BitLocker（全ディスク暗号化）は、Windows の重要な保護機能ですが、デュアルブート環境では大きな障壁となります。BitLocker が有効な状態では、Linux 側から Windows パーティションにアクセスすることができず、さらに BIOS/UEFI の設定変更や起動順序の変更が BitLocker キーの検証を阻害して、Windows の起動自体をブロックする可能性があります。特に Secure Boot や TPM（Trusted Platform Module）と連携している場合、OS の変更を検知してロックアウトされるケースが増えています。

BitLocker とデュアルブートを共存させるためには、まず BitLocker を一時的に無効化するか、回復キーの管理を徹底する必要があります。Windows 上で BitLocker を「一時停止」した状態で Linux のインストールや更新を行い、完了後に再度有効化します。ただし、この方法ではセキュリティリスクが高まるため、推奨されるのは回復キーを物理媒体（USB ドライブなど）に保存し、紛失しないようにすることです。また、Linux 側で BitLocker をサポートするドライブ管理ツールを使用することで、暗号化された Windows パーティションへのアクセスを試みる方法もありますが、2026 年時点では完全な互換性は保証されていません。

Secure Boot との組み合わせにおいても注意が必要です。BitLocker と Secure Boot が同時に有効な場合、ブートローダーがデジタル署名されていないと起動できません。Linux ディストリビューションは通常 Secure Boot キーを管理していますが、手動でキーを登録する必要がある場合があります。この際、Windows の BitLocker 回復画面が表示されることがあり、混乱を招きます。BitLocker のロック解除後に Windows を正常に起動し、再度 BitLocker を有効化する手順が求められます。

Secure Boot の設定とトラブルシューティング

UEFI セキュリティ機能である Secure Boot は、不正なブートローダーのロードを防ぐための仕組みですが、デュアルブート環境では Linux の GRUB や systemd-boot の署名問題を引き起こすことがあります。2026 年現在では多くの Windows PC で Secure Boot がデフォルトで有効化されていますが、Linux ディストリビューションによっては Secure Boot キーの管理が未対応または制限されている場合があり、起動時に「Boot failed」や「Invalid Signature」というエラーが表示されることがあります。このため、Secure Boot の設定を適切に調整する必要があります。

Secure Boot を無効にする最も簡単な方法は BIOS/UEFI セットアップ画面（通常は F2 や Del キー）で設定を変更することです。しかし、セキュリティリスクを考慮すると、長期にわたり無効化することは推奨されません。代替策として、Linux のブートローダーやカーネルが Secure Boot に対応したキーを持っているか確認します。U[bun](/glossary/bun-runtime)tu や [Fedora](/glossary/dora-fine-tuning) などの主要ディストリビューションは MOK（Machine Owner Key）管理を通じて、独自のブートローダーを PC に登録することが可能です。

MOK Management を使用するには、ブート時に「Press any key to enter MOK management」というメッセージが表示されるため、キーを押して設定画面に入ります。ここで Enroll Key から Linux の署名キーを選択し、有効化します。これにより Secure Boot 有効下でも Linux が起動可能になります。また、BIOS/UEFI ファームウェアのアップデートによって、Secure Boot の動作が変更されることがあるため、トラブル発生時にはファームウェアのバージョンを確認し、Microsoft 公式のリストに含まれているか確認することも重要です。

ブートローダー比較：GRUB2 と systemd-boot

デュアルブートの核心となるのはブートローダーです。一般的に最も知られているのが GNU GRUB（GRand Unified Bootloader）であり、もう一つ近年注目されているのが systemd-boot です。両者には明確な違いがあり、ユーザーのスキルセットや使用する Linux ディストリビューションによって選択が分かれます。GRUB2 は長年の実績と豊富な設定機能を持ち、複雑な起動オプションを管理するのに適しています。一方、systemd-boot（旧称：gummiboot）は軽量で起動が高速であり、設定ファイルがシンプルであるため、特定のシステム構成に特化したいユーザーに適しています。

両者の比較を表 1 にまとめます。GRUB2 はメニュー画面のカスタマイズ性が高く、ネットワークブートやパーティションの多様な指定が可能です。また、多くの Linux ディストリビューションで標準採用されていますが、設定ファイル（grub.cfg）は自動生成されることが多く、直接編集には注意が必要です。システムログの表示や詳細なデバッグ機能も充実しており、起動トラブル時の調査に有用です。

表 1：ブートローダー比較

systemd-boot は、設定ファイルがテキストベースでシンプルであり、直接編集しやすいのが特徴です。そのため、GRUB2 に比べて設定ミスによる起動不能のリスクは低いですが、その分高度な起動オプション（例：複雑なパラメータの渡す）には制限があります。また、Windows 側との互換性も高く、UEFI エントリの管理が直感的であるため、初心者やミニマルなシステムを好むユーザーに推奨されます。

予防策とバックアップの重要性

トラブルシューティングを行う前に、最も重要なのは「予防策」です。デュアルブート環境では、OS の更新やディスク操作によって設定が破損するリスクが常に存在します。これを防ぐためには、定期的なパーティションスナップショットやブートローダーの設定バックアップが不可欠です。Linux では grub-mkconfig で生成された設定ファイルを別媒体に保存し、GRUB2 の設定ファイル自体を編集した際の変更点も記録しておきます。また、Windows 側では回復ドライブを作成し、BIOS/UEFI の設定状態をメモしておくことが推奨されます。

バックアップの具体的な方法として、Live USB から起動して重要ファイルを外部 HDD にコピーすることや、ディスクイメージ作成ツール（例：Clonezilla）を使用してパーティション全体を保存することがあります。特に EFI パーティションの内容は、ブートローダー設定が格納される重要領域であるため、定期的なチェックとバックアップが必要です。2026 年現在ではクラウドストレージとの連携も可能ですが、オフラインでの物理的なコピーが最も安全です。

また、OS の更新を行う際は、必ずデュアルブートの状態を確認してから実行する必要があります。Windows Update 直後に Linux が起動できなくなるケースが多いため、Linux を先に更新し、その後に Windows Update を行う順序が推奨されます。または、更新前に GRUB の設定をリセットする手順を把握しておくことで、万が一の時に迅速に対応できます。

まとめ

デュアルブート環境は、Windows と Linux の両方の良さを活かすための強力なツールですが、その安定性は細心の注意と適切な管理に依存しています。本記事では、2026 年 4 月時点の最新情報を踏まえ、よくあるトラブルとその解決法を体系的に解説しました。以下が記事全体の要点です。

• GRUB の消失: Windows Update 後に GRUB が消える際は、Boot-Repair またはコマンドラインで grub-install を再実行することで復旧可能です。
• 起動不能の修復: Linux 側の起動失敗には chroot 環境での GRUB 再生成を、Windows 側の起動失敗には BCD の再構築を使用します。
• パーティション認識: Windows は Linux ファイルシステムをネイティブでサポートしないため、Live USB を使用して確認・アクセスする必要があります。
• 時刻のズレ: UTC とローカルタイムの設定違いが原因となるため、両 OS で統一した時間設定を行うことが必須です。
• セキュリティ機能: BitLocker や Secure Boot はデュアルブートと競合するため、適切なキー管理や無効化・有効化の切り替えが必要です。

トラブル発生時に慌てず、各手順を論理的に実行することで、多くの問題は解決可能です。しかし、最も確実な対策は定期的なバックアップです。重要なデータは必ず別媒体に保存し、ブートローダーの設定ファイルも保管しておくことで、万が一の際にも迅速にシステムを復旧させることができます。

よくある質問（FAQ）

Q1. GRUB が消えて Windows しか起動しないが、Linux のデータは無事ですか？ A: はい、通常は Linux のデータは安全です。Windows Update により EFI パーティション内のブートエントリ情報だけが書き換えられた可能性が高いです。Live USB から起動して GRUB を再インストール（grub-install コマンド）することで起動メニューを復元できます。

Q2. Windows Update 直後に Linux が起動できなくなりました。どうすればいい？ A: まず Live USB で起動し、GRUB の再設定を行います。Boot-Repair ツールを使うのが最も簡単です。コマンドラインなら chroot 環境で /boot/efi をマウントし、再度 GRUB2 をインストールしてください。

Q3. Linux が起動せず「GRUB rescue>」と表示されます。 A: これは GRUB の設定ファイルが破損しています。Live USB から起動し、Linux パーティションをマウントして update-grub または grub-mkconfig を実行してください。パーティションの UUID 確認も重要です。

Q4. Windows が起動せず青画面になります。 A: BCD（ブート構成データ）が破損している可能性があります。Windows インストールメディアから「コンピューターを修復」→「コマンドプロンプト」で bootrec /fixmbr と bcdboot コマンドを実行してください。

Q5. Linux のパーティションが Windows で見えないのはなぜですか？ A: Windows は Linux 用の ext4 ファイルフォーマットを標準ではサポートしていないためです。Live USB から起動するか、Linux パーティション読み取り専用ツールを使用してください。

Q6. 時刻が OS によって大きくズレます。 A: Windows と Linux の時計設定の仕様が異なるためです。timedatectl set-local-rtc 1 で Linux をローカルタイムに合わせるか、Windows レジストリを編集して UTC に合わせてください。

Q7. BitLocker エラーが出て Linux からアクセスできません。 A: BitLocker が暗号化しているためです。Windows 側で回復キーを入力するか、BitLocker を一時的に無効化して Linux とデュアルブートを再設定してください。

Q8. Secure Boot を有効にしたまま Linux を使えますか？ A: はい、可能です。MOK（Machine Owner Key）を登録することで、Linux のブートローダーの署名を検証させられます。[BIOS/UEFI 画面で MOK Management を使用します。

HSSDTECH TPM 2.0 モジュール SPI 12ピン モジュール インフィニオン SLB9670 Windows 11 アップグレード ギガバイト Z890I AORUS ウルトラコンピューティング セキュア バス ヘッダー キー

ディスクパーティションの基本概念からWindows/Linux両OSでの実践的な分割方法まで完全解説。GPT vs MBR比較、Windows推奨構成（EFI/OS/データ/回復）、Linux推奨構成（root/home/swap分離）、GParted活用法とデュアルブート設計手順。見逃せない最新トレンドも解説。