Optane Memory H10が突然死──HP Spectreのデータ復旧を2週間試した全記録

Seagate Basic 6TB 外付けHDD HD-SGDA6U3-B

ポチップ

● 写本（イメージファイル）の保存先 → 大容量の外付けHDD
壊れたSSDと同容量以上が必須。自分は6TBを使いました（容量に余裕があると作業用コピーも置けて安心）。

JOREST 24個精密ドライバーセット（トルクス対応）

ポチップ

● ノートPCを分解する → 精密ドライバーセット
HP Spectreの裏蓋・M.2固定ネジを外すのに必要。トルクス（T5）が含まれるセットを選ぶこと。手持ちが無いと最初の一歩が踏めません。

KIOXIA(旧東芝メモリ) USBフラッシュメモリ 32GB 国内サポート正規品 KLU202A032GL

ポチップ

● 起動メディア用 → USBメモリ
WinPE・WinRE・Ubuntu Live・Windows11インストールと用途は複数ありますが、使うのは一度に1つずつ。焼いて使い終わったら次の用途に焼き直せば、1本で足ります（並行して使いたい時だけ複数あると楽）。最低8GB以上のものを1本ですが、もし持ってなくて購入するならもうちょっと大きいのの方が使い勝手良いと思います。定番のUSBメモリを挙げておきます。

WD_BLACK SN7100 1TB NVMe M.2 SSD（WDS100T4X0E）

ポチップ

● 取り外したSSDの保管 → 静電防止袋
これは100円ショップのものでOK。基板むき出しのSSDを安全に保管するために用意しておきます。

機材をイチから買い揃える出費＋作業用PCの調達＋自分の時間 ── これらを業者費用と天秤にかけるのが、自力でやるか業者に依頼するかを判断する1つの目安になります。

原本を「写本」として保全する

データ復旧の鉄則は「原本を絶対に書き換えないこと」。まずSpectreからSSDを取り外して、原本に余計な操作を加えない状態にしました。手順は以下です。

A. SSDを取り外して外付け化する

Spectre x360 13の分解手順は、PC WatchのSSD換装記事が写真付きで分かりやすかったので参考にしました。裏蓋の開け方やネジの位置はこちらが詳しいです。

Spectre本体の裏蓋を開ける（ネジはTorx T5×2 + プラス #00×4。リアのゴム足の下に隠しネジがあるので注意。最後は樹脂ヘラで爪を外す）
M.2スロットに装着されている内蔵SSD（Optane H10）の固定ネジを外して、SSDを斜めに引き抜く
取り外したSSDを外付けM.2 NVMeケース（前述のUGREEN製を使用）に装着 → 付属のUSB-Cケーブルで別のPCに接続

HP Spectreを分解して裏蓋を外した内部 — Spectre x360の裏蓋を外したところ。バッテリー・冷却ファン・基板が見える（SSDは左側中央の金属板の下に挿さっている）

ここで別PC側でSSDが「ディスクの管理」やデバイスマネージャに見えるかを確認します。見えない場合はケース側or USBケーブルの問題なので、別のケーブル・別のポートで試してください。

Optane H10は「外付けケース非対応」（でも今回は見えた）

じつはIntelは公式にOptane H10の外付けケース利用を「非対応」としています。自分のUGREENケースでは運よく「1TBの単一ドライブ」として認識できましたが、見えていたのはNAND（1TB）側だけ。Optane（32GB）側は外付けでは出てきません。この時点では気づきませんでしたが、これが後の「個人データが出てこない」原因にもなります。

B. セクター単位の「生イメージ」を作る

ここがいちばん大事なところです。普通の「フォルダごとコピー」では欠損したファイルや削除済みデータの残骸が拾えないので、SSD全体を1ビットも漏らさず1つの大きなファイルにコピーする「セクター単位のイメージ化」が必要です。

イメージ化には専用ツールを使います。自分はDMDE（DM Disk Editor）のFree Editionを使いました。データ復旧の定番ソフトで、無料版でもセクター単位のフルイメージ作成ができます。GUI操作なので、コマンドが苦手でも大丈夫です（管理者権限で起動）。

DMDE公式サイトからFree Editionをダウンロードし、管理者として実行
起動直後のデバイス選択画面で「物理デバイス」を選び、外付け化したOptane H10（容量で見分ける）を選択
メニューのツール →「セクタをコピー」（Copy Sectors）を開く
コピー元＝デバイス全体、コピー先＝「ファイル（イメージ）」を選び、保存先にspectre_full.binを指定して開始

イメージ作成の注意点

保存先は対象SSD以上の空きがある別ドライブに（イメージ元と同じSSDはNG）
数時間〜半日かかる。USB3.0以上で繋ぎ、処理中はスリープさせない
SSDが応答不良だと読めないセクタが出ることも。DMDEはエラーを飛ばして続行できる（自分は最後まで通りました）

完了すると、SSD容量とほぼ同じサイズ（自分の1TB SSDで約954GB）のspectre_full.binという「原本イメージ」（写本）が出来上がります。このサイズは使っているSSDの容量で変わるので、自分の環境に読み替えてください。原本SSDはここで静電防止袋に入れて保管しました。

DMDEはイメージスキャンとしても使うので、後のステップを行うためにインストールしたまま残していました。

C. 写本も「直接いじる」のはNG ── 作業前に都度コピー

このあとchkdskなど書き込みを伴う操作も出てきます。写本（原本イメージ）に直接かけると上書きされてやり直せなくなるので、書き込み操作を行う際は必ず別に「作業用コピー」を取って、そのコピーに対して操作してください。

具体的には、写本（spectre_full.bin）を別の場所にrobocopyやCopy-Itemでコピーして、そのコピー（=作業用コピー）に対してchkdsk等を走らせる運用にしました。

# 写本を別フォルダに複製（空きがあれば同じドライブでもOK。自分は同じEドライブ内に作りました）
# robocopy /J（バッファなしI/Oで大容量に強い）を使用
robocopy E:\Spectre_Recovery\ E:\Spectre_Recovery_Work\ spectre_full.bin /J

# 以降のステップ（TestDisk + chkdsk 等）はこのコピーに対して実行
# 何度でも E: の写本から作業用コピーを取り直せる

こうしておけば、原本イメージ（写本）はずっと無傷のまま保たれ、何度でも作業のやり直しが効きます。データ復旧で一番怖いのは「やり直しが効かなくなる」ことなので、ここは省略厳禁です。

このあとのコマンドのパスについて

以降に出てくるコマンドは、作業用コピーがE:\Spectre_Recovery_Work\spectre_full.binにある前提で書きます（自分の環境がこれだったため）。保存場所を変えた人は、各コマンドのE:\Spectre_Recovery_Work\…の部分を自分のパスに読み替えてください。

段階1：OSごと元通りに復活できるか

一番欲しいゴールは「壊れる前の状態でそのまま起動」。まずはこれが可能かを確かめます。Spectre本体にSSDを装着し直して、PC本体側から直接アクセスを試みました。普通のWindowsはそもそも起動できないので、用途別に3種類の起動用USBを作って順に試します。

なお、起動用USB（Windowsの回復・インストール系）から修復を試したときには、起動の入口（ブートマネージャー）までは進むのに、その先で「winload.efiが見つからない（0xc000000e）」で止まりました。これはWindows本体が入ったC:に手が届いていないサインで、切り分けで見た「C:がRAW」とも符合します。

事前準備：BIOS設定とキーボード対策

各種USBから起動する前に、SpectreのBIOSでSecure BootをDisableにしておきます。Secure Bootが有効だと、Microsoft公式署名のないUSB（カスタムWinPEやUbuntu Live等）が弾かれて起動できません。

電源ON直後にF10を連打 → BIOS画面に入る
「Security」タブ → 「Secure Boot Configuration」→ Disableに変更 → F10で保存して再起動
※救出作業が完了したら、Secure Bootは必ずEnableに戻す（セキュリティのため）

HP SpectreのBIOS設定 Boot Options画面 — HP SpectreのBIOS設定画面。USBブートの可否やSecure Bootの状態はここで確認・変更する

各USBから起動するときは、電源ON直後にF9連打でブートメニューを開き、起動したいUSBを選択します。

⚠️ 内蔵キーボードが効かない時の対処

自分の場合、作業中に内蔵キーボードが反応しなくなる場面がありました（WinPE・Linuxいずれでも症状あり）。キーが効かないと当然どこにも進めません。

対処としてUSBハブ経由で外部キーボードを接続すれば普通に入力できました。SpectreのUSB-AポートにUSBハブを挿して、そこに外部キーボードを繋ぐだけ。同じ状況になったらUSBハブ + 適当な外付けキーボードを用意すればOKです。

WinPE + Intel RST統合USBで起動診断

WinPEはUSBから起動できる超軽量のWindowsです。ただしOptane H10はIntel RSTのドライバを組み込まないと「ただの2つの別デバイス」に見えてしまうので、WinPEにドライバを統合してから焼く必要があります。

MicrosoftのWindows ADKとWinPE add-onをインストール
IntelのRSTドライバ（SetupRST.exe）を入手し、SetupRST.exe -extractdriversで中身（INF）を取り出す
WinPEを作ってRSTドライバを統合し、USBに書き込む（下記）

# WinPEの素体を作成
copype amd64 C:\WinPE_amd64

# Intel RSTドライバのINFを展開（インストールはせず中身だけ取り出す）
SetupRST.exe -extractdrivers C:\IntelRST

# boot.wim をマウント → RSTドライバを統合 → アンマウント
Dism /Mount-Image /ImageFile:C:\WinPE_amd64\media\sources\boot.wim `
     /Index:1 /MountDir:C:\WinPE_amd64\mount
Dism /Add-Driver /Image:C:\WinPE_amd64\mount /Driver:C:\IntelRST /Recurse
Dism /Unmount-Image /MountDir:C:\WinPE_amd64\mount /Commit

# USB化：MakeWinPEMedia は DiskPart エラーで失敗したので、
# media フォルダを空USB（例：E:）へ xcopy でまるごとコピーした
xcopy C:\WinPE_amd64\media\*.* E:\ /s /e /h /f /y

このUSBからSpectreを起動（F9でブートメニュー）したところ ── 起動した瞬間にstorport.sysのブルースクリーン（BSoD）でした。統合したRSTドライバが起動時にOptaneを初期化しにいき、応答しないOptaneを待ち続けてストレージ処理の土台（storport.sys）がタイムアウト → 青画面、という流れです。コマンド画面にすらたどり着けませんでした。

HP純正の回復環境（WinRE）でも試す

「自作のWinPEがダメでも、HP純正の回復環境（WinRE）ならOptane H10前提で作られているはず」と考え、取得済みイメージからHPのWinREを取り出してUSB化しました。結論から言うと実りませんでしたが、流れとして記しておきます。

結果はまったく同じstorport.sysのブルースクリーン。これで「HPのカスタマイズが原因ではなく、Intel RSTドライバが“死んだOptane”に触りにいくこと自体が原因」とハッキリしました。Windows系の起動環境はこれで打ち止めです。

Ubuntu Live USB（Linux）で直接ハードに当たる

Windows系が全滅したので、OSをLinuxに切り替えて、別系統のドライバからOptaneに直接話しかけてみました。ここでまずバージョン選びにハマります。

Ubuntuはバージョンがシビアだった

新しめの22.04 / 26.04は起動スピナーで止まって進まず（Ice Lake世代のグラフィック周りが原因らしい）。古い18.04.6でようやく起動できました。ただし最初期の18.04.0はカーネルが古すぎてIce Lake非対応で、これも起動せず。Spectre世代では18.04.6がちょうど良い版でした。

焼きはRufus（パーティション構成「GPT」/ ターゲット「UEFI」/ ファイルシステムFAT32）、Ubuntu 18.04.6のISOを使用。Secure BootはDisableのままです。起動後、ターミナルでOptaneに話しかけてみると ──

# PCIe一覧でOptaneの存在を確認 → 見える
sudo lspci -nn | grep -i optane
# → Intel Corporation Device 2522（Optane側）が表示される

# NVMeとしてアクセスできるか → 応答しない
sudo dmesg | grep -i nvme
# nvme nvme1: pci function 0000:59:00.0
# nvme nvme1: Device not ready; aborting initialisation
# nvme nvme1: Removing after probe failure status: -19

「lspciでは見えるのに、nvmeでは応答しない」。status -19は「そんなデバイスは応答しない」という意味のエラーです。ここからカーネルの省電力設定を変えたり、PCIをリセット／再スキャンしたりと手を尽くしましたが、最後は再スキャンでカーネルごとフリーズ（強制電源オフ）。これは制御チップが完全に応答不能なときの典型的な反応です。

玄関先に人影は見えるのに、ノックしてもインターホンを鳴らしても無反応 ── そんなイメージ。SSDの中で交通整理をする「コントローラ」（制御チップ）が死んでいて、データ本体が無事でも外から取り出せない状態です。Intel自身もOptane H10のハング不具合を認知しており、症状が一致しました。

WinPE・HP回復環境・Linuxと3通り総当たりして、すべて行き止まり。Optaneの制御チップが死んでいて、OSを起動する道も、Optaneのデータを直接読む道も完全に塞がれている ── ここでようやく段階1（OSごと復活）は不可能と確定しました。残るは段階2（データだけでも救出）です。

段階2：データだけでも救い出す

OSごとの復活は諦め。ここからは「個人データだけでも救い出せないか」の総力戦です。準備で作った写本（の作業用コピー）に対して、あらゆる手を順に試していきます。

① 定番のファイル復元ソフトをひと通り試す

写本の作業用コピーに対して、定番ツールを順に投入していきました。

これら復元ソフトは「物理ディスクではなく『イメージファイル』を読み込ませる」機能を持つので、写本（の作業用コピー）に対して安全に走らせられます。

A. EaseUS / R-Studio / DMDEで全体像を把握

まず「そもそもパーティション構成はどう見えているか」を確認します。EaseUS Data Recovery Wizard（トライアル無料、プレビューまで可）・R-Studio（同上）・DMDE（イメージ取得に使ったものと同じ。Standard版なら復元スキャンも可）で、それぞれ写本を開きます。

EaseUS：起動 → 上部メニュー「ディスクイメージファイルを選択」→ spectre_full.binを指定 → スキャン開始
R-Studio：起動 → メニュー「Drive」→「Open Image File」→ spectre_full.binを指定 → 表示された仮想ドライブ右クリック → Scan
DMDE：起動 → デバイス選択画面で「ディスクイメージ（Disk Image）」→ spectre_full.binを指定 → 一覧から対象パーティションを選んで「フルスキャン（Full Scan）」を実行

並行してTestDiskでファイルシステムの中核（MFT）が壊れていないか確認。TestDiskは公式サイトからzipでダウンロードして展開、コマンドプロンプトから実行できます。

# TestDisk でイメージファイルを開く
testdisk_win.exe E:\Spectre_Recovery_Work\spectre_full.bin

# 起動後の操作（キーボードのみ）:
# 1. [Proceed] でログ作成（[No Log]でもOK）
# 2. 対象を選択 → [Proceed]
# 3. パーティションテーブル形式: [Intel] または [EFI GPT]
# 4. [Analyse] → [Quick Search]
# 5. パーティションが見つかったら [P] でファイル一覧表示
#    → MFT が読めれば「ファイルシステム自体は健全」

結果：パーティションテーブルは読め、Cドライブと認識できる領域も存在。MFTも「健全」判定。「ファイルシステムの致命傷ではないのか？」という感触を得て、次へ進みます。

B. PhotoRecでファイル単位の補完スキャン

次にPhotoRec（TestDiskと同梱の無料ツール、ファイルシステムを介さず破片からファイルを拾い直す）でディープスキャンをかけます。

# PhotoRec でイメージファイルをスキャン
photorec_win.exe E:\Spectre_Recovery_Work\spectre_full.bin

# 起動後の操作:
# 1. [Proceed] → 対象選択 → [Proceed]
# 2. パーティション選択 → [Search]
# 3. ファイルシステム種別: [Other] (NTFSの場合)
# 4. スキャン範囲: [Whole] (全体スキャン)
# 5. 保存先フォルダを指定 → [C] で開始
# 6. 数時間〜半日待つ（1TB なら 6〜10時間目安）

出てきたのは古いシステムファイル・キャッシュ・ログの破片ばかり。最近の個人ファイル（写真、ドキュメント、コード等）は1つも出てきません。「ツールが浅いのか、データがそもそも残ってないのか」を判別するため、次のステップへ。

C. TestDisk + chkdskで「ブート領域の再構築」を狙う

ここで重要な発見がありました。SSDの「目次ページ」にあたるブートセクタを調べると、本来約952GBあるはずのCドライブ領域を「約90GB」と誤って報告していたのです。EaseUSやR-Studioが領域の大部分を見落としていたのは、これが原因でした。そこでTestDiskのRebuild BS（ブートセクタ再構築）で正しいサイズに直します。これは書き込みを伴う操作なので、必ず「もう一つ作業用コピーを作って」から実行してください（準備の「写本は直接いじらない」注意）。

# 別名のコピーを作って、それに対して Rebuild BS をかける
Copy-Item E:\Spectre_Recovery_Work\spectre_full.bin `
          E:\Spectre_Recovery_Work\rebuild_attempt.bin

# TestDisk の Rebuild BS フロー
testdisk_win.exe E:\Spectre_Recovery_Work\rebuild_attempt.bin
# 起動後:
# 1. [Proceed] → 対象選択 → [Intel/EFI GPT]
# 2. [Advanced] → 対象パーティション選択
# 3. [Boot] → [Rebuild BS] → [Write] → [Yes]
# 4. TestDisk 終了後、Windows のディスクの管理で
#    rebuild_attempt.bin をマウント → chkdsk /f X:

chkdsk /fの結果は強烈で、「81,205個のファイル（約27GB）が復活した」と表示されます。復活ファイルはWindowsのfound.000という特殊フォルダ（マウントしたドライブのルート直下）にまとめて出力されました。

これ、もしかして助かったやつでは…？

ところがfound.000を開いて中身を順に確認したところ、復活した8万件のファイルは、ほぼすべて2020年8月8〜9日の日付でした。これはSpectreが工場出荷された頃のWindowsシステムファイルやHPのプリインストール環境。自分が日常で書き溜めたドキュメント、撮った写真、コードはゼロ件です。歓喜は数時間で蒸発しました。

D. DiskGeniusのディープスキャンで結果を裏取り

「TestDisk系の限界なのか、そもそもデータが残っていないのか」をハッキリさせるため、別系統のDiskGenius（公式サイト、無料版で復元プレビュー可）でクラスタを1つずつ舐めるスキャンを実行。

DiskGenius起動 → メニュー「Disk」→「Open Virtual Disk Files」→ spectre_full.bin
マウントされた仮想ディスクを右クリック →「Recover Lost Files」
スキャンモードで「Complete Recovery」（deep scan、数時間がかり）にチェック → Start
完了後、左ペインの「Deleted Files」「Recovered Files」を順に確認

結果はほぼ同じ ── 出荷時データ中心、最近の個人ファイルはゼロ。「ツールを変えても出てくるものは変わらない」と確定したので、原因はファイル復元ソフト側ではなく、SSD（NAND側）に最近のデータがそもそも書かれていない可能性を疑い始めます。

② 業務用ソフトで本格スキャン ── 個人データの行方も判明

個人で買える範囲で一番強力な復旧ソフト2本を投入しました。どちらもデータ復旧業者も使うレベルのプロ向けで、ライセンスは買い切りで数万円〜ですが、スキャンまでは無料で行えます。2バージョン試してみて、もし下位バージョンでいけそうなら安くなるので両バージョンを試しました。

Recovery Explorer Professional（SysDev Laboratories製）：RAIDやフラッシュメモリの低層復旧に強い
UFS Explorer Professional Recovery（同社の上位版）：暗号化ボリュームや特殊なファイルシステムにも対応

共通の操作手順は以下です（両ツールで同じ流れ）。

起動 → メニュー「File」→「Open Disk Image」→ 写本の作業用コピーを指定
仮想ディスクが左ペインに展開される → NTFSパーティションを右クリック →「Start scan / Search for lost data」
スキャンオプション：「Thorough scan」 / 「Carving」を有効化（時間はかかるが取りこぼし最小化）
暗号化ボリューム検出オプションを有効化（UFS Explorerの場合）
スキャン完了後、左ペインの「Lost & found」「Reconstructed files」を順に確認 → 必要なファイルを右クリック「Save to」で別ドライブに保存

各スキャンに数時間ずつかかります。2本の結果がほぼ完全に一致することから、結果の信頼性も担保されました（=どちらかのツールが浅かった可能性も否定）。

スキャン結果（2本一致）

取得できたデータ量：30.42GB
取得できたファイル数：110,292ファイル
中身の中心：2020年8月のWindows / HPプリインストール環境（=工場出荷時のデータ）
個人ファイル（写真・ドキュメント・コード等）：ゼロ

つまり「個人で買えるソフトでNAND側から取り出せる上限は30GBぶん、しかも中身は出荷時データ」とハッキリしました。最近の個人ファイルは、やはりこちら側には存在しません。

そして、このスキャン中に決定的な手がかりを拾います。復元できたファイルの中にIntelOptaneData\usage_stats.dbという、Optaneキャッシュが「有効」で動いていたことを示すファイルがあったのです。

個人データはどこへ？ ── 怪しいのは「高速倉庫（Optane）」側

冒頭で触れたとおり、Optane H10は最近よく使うデータをまず高速倉庫（Optane・32GB）に置き、あとから通常倉庫（NAND）へ書き写す仕組みでした。usage_stats.dbは、そのキャッシュが現役で動いていた証拠。つまり最近の個人データは、NANDに書き写される前に高速倉庫（Optane）側に多く残っていた可能性が高い ── そしてOptane側は、段階1でコントローラごと死んだ場所です。

2本のプロ向けソフトが完全に同じ結果を出したことで、「ツールが浅くて出ないわけではない」ことはハッキリしました。この時点での見立ては「欲しいデータは、開かずの金庫（段階1で死んだOptane）の中」。── ただ、この見立ては“半分”しか当たっていなかったと、このあと思い知ることになります。

これで自分のスキルと装備でできることは、本当に全部やった気がする…

③「920GBの中身が不自然」── BitLockerを疑って実測する

ここまでで、自分のSSD（約1TB）から取り出せたのは30GBぶんだけ。「残りの920GBは壊れていて読めないから」だと当然のように思っていましたが、ここで違和感に気付きます。

容量的におかしくないか？920GBが全部「読めない」って、物理的にどうなってるんだ？

Optaneに入っているとしても入っているのは32GB分だけ。大部分は約1TBのNAND側に入っているはず、だがいくらいろんなツールでそれをスキャンしても、出荷時のデータしか出てこない。この現象は何なんだろう…とかなり頭を悩ませました。

頭をよぎったのがBitLocker（フルボリューム暗号化）の存在でした。そういえば最初の切り分けでCドライブが「RAW」だったのも、暗号化されていれば説明がつく…。あれが伏線だったのかもしれない、と。

確かめる方法は「中身のバラつき度合い（ランダムさ）を測る」こと。普通のデータ・空き領域・暗号文では、その数値（エントロピー）が大きく異なるので、実測すればBitLockerかどうかを切り分けられるはずです。専用ツールは無いので、PowerShellで簡単な測定スクリプトを用意しました。

スクリプトの核は以下です（写本の作業用コピーを一定間隔でサンプリングし、各ブロックのランダムさを算出）：

# エントロピー測定スクリプトの核（PowerShell）
# 写本の作業用コピーに対して、一定間隔でブロックを抜き取り、各ブロックのエントロピーを算出
$path = 'E:\Spectre_Recovery_Work\spectre_full.bin'
$blockSize = 64KB
$strideMB = 1GB  # 1GBごとに1ブロックをサンプリング（高速化のため）

$fs = [System.IO.File]::OpenRead($path)
$buf = New-Object byte[] $blockSize
$results = @()

while ($fs.Position -lt $fs.Length) {
    $n = $fs.Read($buf, 0, $blockSize)
    if ($n -lt $blockSize) { break }

    # バイト値ごとの出現頻度をカウント
    $freq = New-Object int[] 256
    foreach ($b in $buf[0..($n-1)]) { $freq[$b]++ }

    # シャノンエントロピー算出: H = -Σ p_i * log2(p_i)
    $entropy = 0.0
    foreach ($c in $freq) {
        if ($c -gt 0) {
            $p = $c / $n
            $entropy -= $p * [Math]::Log($p, 2)
        }
    }
    $results += [PSCustomObject]@{ Offset = $fs.Position; Entropy = [Math]::Round($entropy, 3) }

    # 次のサンプリング位置までシーク
    $fs.Position = $fs.Position + ($strideMB - $blockSize)
}
$fs.Close()
$results | Export-Csv entropy_map.csv -NoTypeInformation

# 集計
$avg = ($results.Entropy | Measure-Object -Average).Average
$high = ($results | Where-Object { $_.Entropy -gt 6.0 }).Count
$zero = ($results | Where-Object { $_.Entropy -lt 0.1 }).Count
Write-Host ("平均: {0:N3} / 高エントロピー(>6): {1}/{2} / ゼロ近傍: {3}/{2}" -f `
    $avg, $high, $results.Count, $zero)

あとは、このスクリプトを写本の作業用コピーに対して実行するだけ。最後に平均エントロピーと「ランダムさが高い（＝暗号文の疑いがある）ブロックがどれくらいあるか」が表示されます。なお、これは全バイトを読むのではなく1GBごとに64KBだけ抜き取る“間引き検査”なので、約1TBの写本でも現実的な時間で終わります（暗号化の有無＝データの分布を見るにはこれで十分）。

そして実行結果を見て、画面の前で固まりました。

エントロピー測定で見えた「93%が暗号文」── 前提崩壊

「データのバラつき度合い」は、専門的にはエントロピーと呼ばれ、0〜8の数値で表します。雑に言うと「中身がどれくらいランダムか」のスコアです。

0近く：何も書かれていない真っ白なノート（空き領域はこれ）
5〜7：文章・写真・実行ファイルなど普通のデータ
8近く：完全にデタラメに見える文字列。暗号文や圧縮データはこの数値

「920GBが空き」ならスコアは0近くで固まるはずです。ところが結果は ──

完全な空き領域：わずか7.25%
平均スコア：7.407 / 8.0（ほぼ暗号文の特徴）
サンプルの93.1%がスコア6を超え（=ほぼ暗号文）
普通のファイル相当（スコア1〜6）：たった0.1%

920GBは「空き」ではなく、ランダムにしか見えない暗号文データが物理的に充填されていた ── つまりBitLockerでフルボリューム暗号化されていた、と確定しました。

ちなみに、Windows標準の診断コマンド（manage-bde）でBitLockerの有無を調べても、今回のような状態では「保護なし＝BitLockerなし」と誤って表示されます。理由は同じで、判定に必要な「鍵情報」が壊れた倉庫（Optane）側にあって、NAND側からは見つけられないから。途中の診断で見抜けなかったのも、これが原因でした。

「実測しないで前提を信じる」ことの危うさを思い知った瞬間でした。

なぜ「回復キー48桁」だけでは復号できないのか

BitLockerと判明。しかも自分の場合、回復キー48桁は手元にありました。壊れた直後に本体を診断していたとき、「念のため」とMicrosoftアカウントの回復キーページから控えておいたものです。これで普通は救えそうに思えますよね。実際、自分も最初はそう思いました。

でもBitLockerの仕組みは「金庫の中にもう一つ金庫がある」二重金庫構造になっていて、回復キーは「一番外側の金庫の暗証番号」でしかありません。データ本体にたどり着くにはあと2段階あります。

BitLocker復号の「鍵チェーン」を金庫に例えると

回復キー48桁＝外側の金庫を開ける暗証番号
VMK＝外側の金庫の中の、内側の金庫を開けるための鍵
FVEK＝内側の金庫の中の、データを復号するための最終的な鍵
データ本体＝最終的に欲しい宝物

「暗証番号 → 内側の鍵 → 中の鍵 → 宝物」と3段階で開けていかないとデータには触れません。今回の致命傷は、VMKとFVEKの保管場所が、まるごと壊れた方の倉庫（Optane）に置いてあったこと。手元の写本（NANDイメージ）は「宝物が入った内側の金庫」だけ持っている状態で、それを開ける鍵が物理的に取り出せません。

「じゃあ鍵を作り直せばいいんじゃ？」と思いますよね。でもVMK / FVEKは完全にランダムに作られた長い文字列で、仮にスーパーコンピューターで総当たりしても、宇宙の年齢を何兆倍にした時間が必要と言われるレベル。鍵そのものを物理的に取り戻す以外、宝物にたどり着く道はありません。

最後の砦：データ復旧業者という選択肢

自力ルートが尽きた以上、残るのは「業者にOptaneから鍵を物理回収してもらう」一択です。日本国内でOptane H10 + BitLockerに対応できる業者を調査したところ、LIVEDATA（秋葉原）が候補に挙がりました。

同型番HBRPEKNX0203AHのOptane H10復旧成功実績を事例として公開
業務用復旧装置（PC-3000）保有、コントローラ故障にも対応可能
初期診断・見積もり無料、成果報酬制（失敗なら費用なし）

そこで実際に問い合わせて、簡易見積もりをもらいました。預けるのはSSD本体だけでOK、BitLockerも回復キーがあれば復号 → ファイル単位で抽出 → 別メディアに納品まで対応とのこと。肝心の概算費用は ── おおよそ十数万〜30万円（税込）、復旧できなければ費用は不要（成果報酬）。プライバシーマーク取得の業者で、データを預ける上での安心材料も確認できました。

同型番の復旧実績がある業者が国内に存在するという事実は、「自力で詰んでも、最後の砦は確実にある」という意味で精神的に大きな安心材料でした。

段階3：諦めて、新SSDで再出発

冒頭で書いた通り、自分にとって本当に大事なデータはクラウドやGitHubにバックアップ済みで、ローカルに残っていたのは「あったら嬉しい程度」のデータ。十数万〜30万円規模（業者の見積もり）× 数週間〜数ヶ月の結果待ちを、自分のデータの価値と天秤にかけると、自分の場合は釣り合わない、というのが結論でした。

これはあくまで自分のケースの判断です。同じ機種・同じ故障に遭遇しても、業務データや家族写真など「絶対に取り戻したい」データが入っていれば、迷わず業者に依頼すべき場面だと思います。LIVEDATAは同型番の実績を公開しているので、自分の状況がもっとシビアだったら問い合わせていました。

自力でやり切った。気持ちよく諦められる。

ただし元のSSD（Optane H10）は捨てずに保管。技術が進歩したり、いつか気が向いた時に試せる可能性をゼロにはしたくないので、静電防止袋に入れて保管しています。

【追記 2026-08-26】コメントでいただいた情報共有：取り外して1か月後にOptaneが復活したケース

公開後、同じようにOptaneが認識しなくなった方から、その後どうなったかをコメントで教えていただきました。SSDを本体から取り外したまま1か月ほど置いておいたところ、Optaneが再び反応するようになったそうです。そのまま元のx360に戻し、本記事と同じWinPE + Intel RST統合USBから起動。BitLockerの回復キーで暗号化を解き、robocopyで外付けHDDに全データを吸い上げることができたとのことでした。

自分の環境では、WinPEからの起動はブルースクリーンで弾かれ、BitLockerも、回復キーは手元にあったもののOptaneが読めないせいで鍵情報に届かず復号できませんでした。Optaneが読める状態に戻れば、そのどちらも通る可能性があるということになります。

もちろん、全員が取り外して1か月置けば直るというわけではありませんし、1か月待つことを推奨するものでもありません。こういうケースもあるということで、参考情報として追記しておきます。

その後、換装先のSSDとしてWD_BLACK SN7100（1TB NVMe）を購入、Spectreに取り付けてWindows 11をクリーンインストール。Windowsライセンスは本体に紐付いていてネット接続するだけで自動認証完了。Spectreは新品同様にサブ機として復活しました。

死んだOptane Memory H10と換装したWD_BLACK SN7100の比較 — 下が今回死んだOptane Memory H10（HBRPEKNX0203AH）、上が換装したWD_BLACK SN7100 1TB。複雑な複合SSDから、素直な単一NVMeに乗り換えた

使ったのは以下です。純粋にSpectre向けと考えると多少オーバースペックですが、今後も長く使い続けることを考え、以下にしました。