MBR2GPTで「Cannot find OS Partition(s) for disk 0」？

「mbr破壊」という言葉で検索する人って、だいたい“MBRを触ったら起動しなくなるのでは？”という不安が強いと思います。私もMBR2GPTで「Cannot find OS Partition(s) for disk 0」が出たとき、まさに「これ以上やったらMBR壊して詰むかも…」と手が止まりました。ここでは、MBRが“破壊されたように見える”典型パターンと、やる前にできる安全策を体験ベースで補足します。 まず、MBRが壊れたと誤解しやすいのが「ブート構成データ（BCD）の不整合」です。ディスク自体は生きているのに、起動に必要な情報が参照できず、結果としてOSパーティションを見失います。MBR2GPTは変換条件が厳しめで、パーティションの状態やブート情報に少しでもズレがあると止まります。ここで無理に手動修復（diskpartで割り当て→Bootフォルダ確認→bcdeditで不正エントリ削除…）をやると、コマンドの打ち間違いで状況を悪化させやすく、「MBR破壊した」と感じる展開になりがちでした。 私が“破壊を防ぐために”意識したのは次の3点です。 1) 事前にバックアップを取る 変換作業は「成功すれば一瞬」でも、失敗したときの復旧コストが高いです。可能ならシステムイメージ（丸ごと）か、最低でも重要データの退避を先に。OCRにもあるAOMEI Backupperのようなバックアップツールを使うと、心理的にもだいぶ落ち着きます。 2) 変換前にディスクの状態を確認する ディスク管理で、OSパーティションとシステム予約済み領域がどう見えているかを確認しました。パーティション構成が複雑（回復領域が多い、余計な未割り当てが挟まる等）だと、MBR2GPTがエラーになりやすい印象です。「OSパーティション認識エラー」というのは、こういう“見え方のズレ”でも起きます。 3) 手動修復が不安なら、GUIで安全に進める コマンドでのdiskpart/BCD修復は、慣れていないと本当に難しいです。私は一度、ドライブ文字の割り当てを間違えそうになって中断しました。そういうときは、Partition Assistantのように直感的にMBR→GPT変換できる方法の方が、結果的に“破壊リスク”を下げられると感じました。 結論として、「mbr破壊」が怖いなら、焦ってコマンドで突っ込むより、(1)バックアップ→(2)ディスク状態の整理→(3)分かりやすい手段で変換、の順が安心です。エラーが出ても“ディスクが即死した”とは限らないので、落ち着いて原因（BCD不整合/認識エラー）を疑うのがポイントでした。