本記事はあくまでトラブル発生時の記録とその過程のまとめであり、厳密な検証を目的としたものではありません。
M.2 NVMe SSD→USB変換（Realtek RTL9210B）で発生した認識不具合
2026年3月はSSD絶賛高騰中
2025年11月のブラックフライデーのセール終了後くらいから、AI需要で品薄になり、市販のPCパーツが突然、超高騰状態になりました。
メモリやら、SSDやらが、2026年3月時点では24〜25年前半の値段と比較すると、軽く2倍、酷いものだとそれ以上の価格に値上がりしています。
動画データなどを放り込む（SATAのSSD）ストレージが新たに欲しくなったんですが、SSDを買うには相場が上がりすぎていて、2TBで一万円くらいの時に買ってUSB変換ケースに入れ、取り敢えずデータだけ入れて放置していたNVMeを、本格的に外付けとして利用することにしました。
本来、外付け利用が目的ならスピードはそこまで求めていないので、元々ケース入りでNANDチップが剥き出しでなく保護されている2.5インチのSATAの方が都合がいいのですが、その時は同容量だとM.2のNVMeの方がたまたま安かったのでそちらを購入したんです。
需要と供給の差でしょうか。しかし、後にこれが失敗だったと後悔することになります。
データを入れてしばらく放置、久しぶりに接続したら認識しない
それぞれUSB変換ケースに入れて外付けのようにした2TBのSSD2本は、中に動画データのバックアップを放り込んでありました。
バックアップなので、データを入れた後はPCから抜いてそのまま放置していました。
その期間はざっと2年ほど。外付けディスクとして本格的に運用する前に、1回中身を確認しておこうとUSBポートに繋ぎました。
すると、なんということでしょうか。SSDが認識しなくなっていました。
SSDはあまりに長期間通電しないと中身が消える危険性があるとは知っていましたが、2年くらいなら問題ないだろうと高を括っていたら、最悪な不具合発生です。
元データは別のSATAディスクにあるし、このSSDのデータは消えたかもしれないけど、ほとんど新品に近いSSDなのでディスク自体は壊れてはいないだろう。
一度再フォーマットをかければまた使えるようになるし、大丈夫だろうと軽く考えていました。
しかし、Windowsの「ディスクの管理」では容量が見えないし、フォーマットも領域解放・確保も何もできません。
Linuxのターミナルでローレベルのコマンドを使えばもう少し詳細がわかるかとLinuxに繋いでいろいろ試してみても、容量が見えたり見えなかったり、繋がったり繋がらなかったり、そんな状態でした。
※ 以下はLinuxで確認した際のログですが、「デバイスは見えるのに容量が取得できない」状態になっていることが分かります。
GPT fdisk (gdisk) version 1.0.10 Problem opening /dev/sdc for reading! Error is 2. The specified file does not exist!USB機器は認識しているけど、その先のストレージが存在しない？
[sdc] Read Capacity(10) failed
Sense Key : Illegal Request
Add. Sense: Invalid command operation code
[sdc] 0 512-byte logical blocks: (0 B/0 B)「容量教えて」と聞いたら、変換チップが「そのコマンド知らん」と返してくる状態。
usb disconnect → reconnect → また失敗接続が非常に不安定（電力 or ファーム）。
sudo gdisk -l /dev/sdc GPT fdisk (gdisk) version 1.0.10 The protective MBR's 0xEE partition is oversized! Auto-repairing. Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sdc: 4000797360 sectors, 1.9 TiB Model: RTL9210B-CG Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 6D3D0DB6-DDF8-43F4-A181-1D22EC2518AB Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 4000797326 Partitions will be aligned on 8-sector boundaries Total free space is 2703 sectors (1.3 MiB) Number Start (sector) End (sector) Size Code Name 1 34 32767 16.0 MiB 0C01 Microsoft reserved ... 2 32768 4000794623 1.9 TiB 0700 Basic data partition接続が不安定ながら、中が見えることもある。
GPT fdisk (gdisk) version 1.0.10 Problem reading disk in BasicMBRData::ReadMBRData()! Warning! Read error 22; strange behavior now likely! Warning! Read error 22; strange behavior now likely! Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. *************************************************************** Disk is too small to hold GPT data (0 sectors)! Aborting! 接続されているUSBの認識はOK。デバイス名も出る（/dev/sdc）。
でも容量が読めない（0 sectors）。読み込みエラー連発で、切断→再接続のループ。
――と、ログが物語る通り、まともに認識もされず、正常に動作していない状態です。
ちなみに、2台のSSDは以下。
- ADATA LEGEND 700 2TB
- TEAMGROUP TM8FP6002T 2TB
搭載コントローラーの種類は不明ですが、同メーカーではなく製品としては別物です。
それなのに、両方とも同様の症状が発生しました。
NVMe SSDの省電力状態が問題？
調べてみると、NVMe SSDには複数の電源状態（Power State）があるようでした。
代表的には以下のような段階があります。
- PS0 フルパワー
- PS1 軽い省電力
- PS2 省電力
- PS3 深い省電力
- PS4 深休眠 (Deep Power State)
どうもPS3〜PS4になるとコントローラ停止に近い状態になり、レジスタ応答も遅くなり、復帰には再初期化が必要になるようです。
なぜUSB変換（ブリッジ）で問題が出るかというと、NVMe→USBブリッジは内部で、
USB Mass Storage / UASP
↓
SCSIコマンド
↓
NVMeコマンド
――という変換をしているためです。
しかし多くのUSB変換用ブリッジは、NVMeのPower State管理を完全にはサポートしていないようです。
その結果、
SSD
↓
深い省電力状態
↓
USBブリッジが復帰コマンドを出せない
↓
容量取得失敗
↓
Read Capacity failed
――という状態になるようです。
特に起きやすい条件は以下。
- 長期間未通電
- ノートPC用NVMe
- 省電力強めのSSD
- 安いUSBブリッジ
中古SSDや長期保管SSDで、比較的よく発生する症状のようです。
NVMeをUSBに変換するブリッジでは、一度SSDが深い省電力状態（NVMe Power State）に入ってしまうと復帰させることができず、容量取得に失敗するケースが多々あるようです。
NVMe→USB変換ブリッジではSSDを完全制御できない
SATA→USBの変換とNVMe→USBの変換を同じように考えていたんですが、どうもSATAと違い、NVMeのUSB変換はかなりシビアで、ブリッジとSSDコントローラーの相性が強く出るようです。
さらに、ブリッジ越しではエラー状態のSSDを復旧させるのも難しいようです。
要するに、NVMe→USBに変換したSSDを外付けとして常用するのは、不具合が生じやすいということですね。
これから外付けとして使うSSDは、可能な限りSATAを買うことにします。
ちなみに私が使ったのは、Amazonで売っている「ORICO M.2 SSD 外付けケース」で、ブリッジチップにRTL9210が使われているタイプです。
レビューを見ると、「認識しない」「ケーブルが細くて電力が不安定」といった内容が一定数あり、そこそこの割合で不具合が発生している模様。
ポチップ
一応、ケース故障や相性も疑い、JMS583チップを使った別のUSB変換でも試してみましたが、結果は同じでした。
ポチップ
NVMe→USB変換ブリッジは、総合的に安定性はいまいちのようです。
「絶対に動く」とは考えないほうが良さそうです。
M.2 NVMe SSDを復活させる
USB変換でどうしようもなくなったSSDですが、ブリッジとの相性的な問題で認識されなくなっただけなので、PCのスロットに直挿しすればリセットがかかり、多くの場合は正常に復帰します。
ただし、マザーボードを直接触る必要があるので、少し面倒ではあります。
普段使いのメイン機は触りたくないので、代わりに家で眠っていたSandy Bridge世代のCore i3のPCを引っ張り出し、NVMe SSDをPCIeに変換する基板を使ってスロットに挿し、Windows 10のインストールISOで起動して確認したところ、SSDは普通に認識していました。見事復活です。
NVMe→PCIe変換基板は単なる配線なので、認識しないことはほぼありません。安定性は抜群です。
x4の方が高速ですが、x1なら短いスロットにも挿せるのが利点ですね。速度が出ない分、発熱が低くなるというメリットもあります。
ポチップ
ポチップ
結局、2枚のSSDは壊れていたわけではなく、USB変換だと認識しなくなっていただけでした。
そして2枚ともデータは無事でした。
また、USB変換チップの方も特に故障している様子はありませんでした。
ついでなので、i3-2120TのPCに64GBのSATA SSDを取り付け、そこにWindows 10 IoTの評価版を入れて、NVMe SSD 2TBを2枚接続し、バックアップ用ファイルサーバーとして活用することにしました。
2026年ですが、Sandy Bridge世代のPCも用途次第ではまだまだ現役です。
詳しくは別記事「2026年にSandy Bridgeデビュー、Windows 10を32年まで使う」にて。
本当はLinux（Debian）を入れたかったのですが、H61マザーにPS/2キーボードを接続したところ、BIOSでは認識するものの、Debianのインストーラでは認識せず使えなかったため断念。
後にUSBキーボードでインストールし、
sudo nano /etc/default/grub
で、
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
を
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.dumbkbd i8042.notimeout i8042.direct i8042.kbdreset"
に変更したところ、PS/2キーボードも正常に認識して動作しました。
まとめ、最後に
今回の件で分かったのは、NVMe SSDをUSB変換で外付け運用する場合、見た目やスペックがしっかりしていて、製品説明に特に注意書きがなくても、長期間安定して使えるとは限らないということです。
特に長期間未通電の状態からの復帰や、省電力状態に入った際の挙動については、USB変換ブリッジ側の実装や相性に大きく依存してしまい、最悪の場合、今回のように「デバイスは見えるのに容量が取得できない」という厄介な状態になることもあります。
同様の構成であれば、他の環境でも同様の不具合が発生する可能性は十分にあると考えられます。
また、この手の変換ケースはヒートシンクが付属していても、結局はケース内部に熱がこもりやすく、SSDが効率的に冷却されているとは言い難い構造です。ディスククローンなどの一時的な用途であれば問題になりにくいですが、常時接続の外付けストレージとして使うにはやや不安が残ります。
温度については、使用中にサーモグラフなどで測っておけばよかったのですが、今回はそこまで検証できていません。発熱との関連性も含めて、今となっては少し惜しいところです。
結果として、NVMe SSDは可能な限りマザーボード直結で使い、外付け用途であれば安定性や放熱面で有利なSATA SSDを選んだ方が無難だと感じました。
今回のように一見故障のように見えても、環境を変えることで復帰するケースもあるため、同様の症状が出た場合は慌てて廃棄せず、一度は直挿しでの確認を試してみることをおすすめします。
