【実録】Macで暗号化した外付けSSDが開けない。無料ツールで約129GBを救出した方法とコマンド

まず結論

• 原因はパスワードではなく、SSDの一部のブロックが読めなくなったことでした。macOS は暗号の鍵情報までたどり着けず、ロックを解除できなくなっていました。
• macOS の仕組みを使わずに APFS を読む libfsapfs で、SSDを読み取り専用で開き、パスワードで解除してファイルを取り出しました。
• 取り出したファイルは SHA-256 で照合しました。全データを完全に復旧できたわけではなく、7件は救出できませんでした。
• 救出後にSSDを初期化し、F3 で書き込んだ約2TBの領域をすべて読み戻して、失われたデータは0でした（今後も故障しないことの保証ではありません）。
• 同じ方法を誰でも試せるように、無料ツール APFS Rescue for Mac として GitHub で公開しています。

そのとき何が起きたか

同じ日の夕方までは、いつもどおりパスワードを入れて開けていました。ところが Mac が再起動したあとから、パスワードを入れてもロックを解除できなくなりました。

どんな症状だったか

ターミナルで暗号化ボリュームの解除ユーザーを確認すると、次のエラーが出ました。

Error getting list of cryptographic users for APFS Volume: Unable to get list of crypto users for this APFS Volume (-69552)

システムのログには「Passphrase incorrect or user does not exist（パスワードが違うか、ユーザーが存在しない）」という記録もありました。これだけを見ると、パスワードを間違えたように見えます。

状態を調べるコマンド

ここからはターミナル（「アプリケーション」→「ユーティリティ」→「ターミナル」）でコマンドを実行します。この章のコマンドはすべて macOS 標準・読み取りのみで、SSDに書き込むことはありません。

1. 外付けディスクの一覧を見る

diskutil list external physical

Apple_APFS と書かれた行の IDENTIFIER（例 disk4s2）を確認します。番号は Mac ごと・接続ごとに変わります。

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk4
   1:         Microsoft Reserved                         16.8 MB    disk4s1
   2:                 Apple_APFS Container disk5         2.0 TB     disk4s2

2. APFS の状態を見る

diskutil apfs list

暗号化されたボリュームの名前（例 disk5s1）と、FileVault: Yes (Locked) を確認します。

+-> Volume disk5s1 XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
    Name:                      X10 Pro (Case-insensitive)
    Mount Point:               Not Mounted
    FileVault:                 Yes (Locked)

3. 解除ユーザーを確認する（-69552 の確認）

diskutil apfs listUsers disk5s1

正常なら Cryptographic user for disk5s1 (1 found) に続いて種類（Disk User など）が表示されます。筆者の場合は -69552 で失敗しました。-69552 の原因は一つではないため、次のログと合わせて判断します。

4. カーネルのログを見る

log show --last 2h --style compact --predicate 'process == "kernel" AND eventMessage CONTAINS[c] "apfs"'

直近2時間の APFS 関連のログです（2h を 1d にすると1日分）。I/O error、err 5、failed to find valid checkpoint が、同じブロック番号で繰り返し出ていないかを見ます。

5. 読み取りエラーの回数を見る

ioreg -r -c IOBlockStorageDriver -w0 -l | grep '"Statistics"'

ディスクごとの "Errors (Read)" を見ます。筆者のSSDは、接続しているだけで 266 回に達していました。増え続けている場合は、アクセスを最小限にしてください。

原因の分析と限界

ログを順番に追うと、次のことが分かりました。

1. 同じ場所で読み取りエラー：再起動の直後から、SSDの同じブロックで I/O error（err 5）が繰り返し出ていた。
2. チェックポイントを検証できない：APFS は最新の状態を記録した「チェックポイント」を確かめようとしたが、読み取りに失敗。古いチェックポイントも参照先がすでに上書きされていて使えなかった。
3. 鍵情報にたどり着けない：その結果、macOS は暗号の鍵情報（keybag）の場所を見つけられず、パスワードを照合する前に失敗していた（ログに APFSVolumeListUUIDsOfUnlockRecords err=2）。

つまり「パスワードが違う」というメッセージは、鍵情報を見つけられなかった結果として出ていたもので、パスワード自体は正しかったのです。市販の復旧ソフトのプレビュー機能では、同じパスワードでファイルの一覧を表示できました。鍵とデータの大部分はSSD上に残っていると判断しました。

最初にやってはいけないこと

libfsapfs による救出

libfsapfs は、APFS の中身を自分で解釈して読むオープンソースのライブラリです。macOS がつまずいた「チェックポイントの検証」とは別の経路で、鍵情報とファイルにたどり着ける可能性があります。

無料で試せる方法を比べた結果です。条件は「元のSSDに一切書き込まない」「追加の購入をしない」「救出先は Mac の内蔵SSD（空き約557GB）」でした。

救出は次の方針で進めました。

1. 読み取り専用で開く：SSDのパーティションを O_RDONLY で開き、書き込むコードを持たない。
2. 再試行しない：読み取りエラーは合計20回・連続3回で止める。一度読めなかった場所は二度と読みにいかない。
3. パスワードを残さない：画面に表示せずに入力し、コマンドやログには書かない。
4. SHA-256 で照合する：読み込みながら計算した値と、保存したファイルを読み直した値を比べる。
5. 大事なフォルダから少しずつ：フォルダ単位で取り出し、止まっても続きから再開する。

中心になるのは、読み取り専用で開いたディスクを libfsapfs に渡し、パスワードで解除する部分です（抜粋・簡略化）。

fd = os.open("/dev/rdisk4s2", os.O_RDONLY)            # 読み取り専用。書き込みはできない
container = pyfsapfs.container()
container.open_file_object(ReadOnlySource(fd))         # read / seek だけを持つ自作のクラス
volume = container.get_volume(0)
volume.set_password(getpass.getpass())                 # パスワードは画面に表示しない
volume.unlock()

完全なソースコード（エラー処理・照合・再開・安全確認を含む）は GitHub で公開しています。

無料ツールの導入

救出に使ったスクリプトを、ほかの人も安全に使えるように作り直したのが APFS Rescue for Mac です（MIT License）。macOS 27.0.1・Apple シリコンで動作を確認しています。

1. Python 3.10 以上を用意する

macOS に入っている python3 は 3.9 のため使えません。Homebrew を使っている場合は次のコマンドで入れます（python.org のインストーラーでも構いませんが、動作は未確認です）。

brew install python@3.12

2. ツールをダウンロードしてセットアップする

GitHub のリリースページ から apfs-rescue-for-mac-1.0.0.zip をダウンロードし、ダブルクリックで展開します。展開したフォルダが「ダウンロード」にある場合は、次の2行を実行します。

cd ~/Downloads/apfs-rescue-for-mac
./setup.sh

フォルダの中に専用の Python 環境を作り、libfsapfs-python を PyPI から入れます（改ざんがないか SHA-256 で確認します。管理者権限は不要です）。

Using Python: /opt/homebrew/bin/python3.12 (3.12.13 arm64)
Successfully installed libfsapfs-python-20260921
libfsapfs 20260921 OK

Installed. Try:  ./apfs-rescue --help

permission denied と出たら chmod +x setup.sh apfs-rescue を実行してからやり直します。

救出の手順

ディスクイメージから救出する場合の流れです。~/Desktop/disk.img は自分のイメージファイルに置き換えます。

1. 中身を確認する（パスワード不要）

./apfs-rescue info ~/Desktop/disk.img

container    : offset=20480 size=1073700864 (1.07 GB)  GPT partition 1 'disk image'
volumes      : 1
  [0] name='RescueTestA'  encrypted/locked=True

2. フォルダの一覧を見る

./apfs-rescue list ~/Desktop/disk.img --depth 1

パスワードを聞かれます（入力は画面に表示されません）。ファイルの中身は読まず、一覧だけを表示します。

3. 必要なフォルダを取り出す

./apfs-rescue extract ~/Desktop/disk.img --dest ~/Desktop/rescued --path "Documents"

元のディスクには書き込みません。救出先（~/Desktop/rescued）にだけ書き込みます。救出先には、取り出すデータ量 + 256MB 以上の空きが必要です。途中で止まっても、同じコマンドをもう一度実行すれば続きから再開します。

DONE rc=0 saved=8 (6.29 KB) skipped_already_ok=0 not_rescued=0 [io=0 dataless=0 ...]
=== result (all runs into this destination) ===
  saved and verified (OK) : 8 files, 6.29 KB

実物のSSDから直接読む場合

イメージを作る空き容量がない場合（筆者もそうでした）は、実物のSSDを直接読めます。ツールはディスクを自動では選びません。

sudo ./apfs-rescue extract /dev/rdisk4s2 --device --dest ~/Desktop/rescued --path "Documents"

ディスクの情報が表示されたあと、確認のためディスク名の入力を求められ、次に暗号化パスワードを入力します。起動ディスク、救出先と同じディスク、マウント中のボリュームがあるディスクは拒否します。読み取りエラーは合計20回・連続3回で自動的に止まります。

救出データの検証

./apfs-rescue verify --dest ~/Desktop/rescued

保存したファイルを読み直し、読み込んだときの SHA-256・サイズと一致するかを確かめます（元のSSDは読みません）。救出できなかったファイルは、_apfs_rescue/not_rescued.tsv に理由と一緒に一覧されます。

筆者の救出結果です。大事なフォルダから順に5回に分け、同じ救出先に追加していきました。数値は各回の実行ログの値です。

• SHA-256：1〜4回目の 37,143 件は、読み込み時の値と保存後の値を照合し、全件一致しました。
• 救出できなかったファイル：7件。うち1件は、クラウドストレージの「クラウドのみ」の状態で、SSD上に中身がないファイル（DATALESS）でした。
• 読み取り速度：約24MB/s（USB接続のSSDを、フォルダ単位で順に読んだ実測値）。
• 形式の確認：PDF・JPEG・PNG・Office文書・MP4 などは、ファイルの構造が正常であることを確かめました。

SSD初期化後の F3 検証

救出したデータを確認したあと、SSDを初期化して、再利用できる状態かを確かめました。ここからは書き込みを伴う操作です。救出が終わる前には絶対に行わないでください。

F3（Fight Flash Fraud） は、ディスクの空き領域全体にテスト用のデータを書き込み、読み戻して壊れていないかを確かめる無料のツールです。

brew install f3

f3write "/Volumes/X10 Pro"
f3read "/Volumes/X10 Pro"

f3write が空き領域をすべてテスト用のファイル（1.h2w など）で埋め、f3read がそれを読み戻して照合します。容量が大きいほど時間がかかります。終わったら、テスト用のファイルは削除して構いません。

筆者のSSDでの結果（2026年10月29日）

初期化した Crucial X10 Pro 2TB での f3read の結果です。

Data OK: 1.82 TB (3904897024 sectors)
Data LOST: 0.00 Bytes (0 sectors)
Corrupted: 0.00 Bytes (0 sectors)
Slightly changed: 0.00 Bytes (0 sectors)
Overwritten: 0.00 Bytes (0 sectors)
Average sequential read speed: 876.13 MB/s
(3904897024 sectors / 36'16")

F3 は 1024 を単位に表示するため、製品表記の「2TB」（1000 を単位）に近い容量が 1.82 TB と表示されます。書き込み（f3write）の時間と速度は記録していません。

注意点と、うまくいかないとき

メッセージは英語で表示されます。よく出るものと対処です（全一覧はツールに同梱の docs/troubleshooting.md）。

終了コードは、0 = すべて成功、1 = 一部を救出できなかった、2 = 安全確認で中止（何も読み書きしていない）、3 = 停止（再実行で再開可）、4 = 予期しないエラー、5 = 解除できなかった、130 = Ctrl-C で中断です。

このツールでできないこと

• 鍵情報や最新の管理情報そのものが読めない場合は救出できません（libfsapfs は古い世代のチェックポイントを選べません）。
• クラウドにしか中身がないファイル（iCloud Drive などの「クラウドのみ」の状態）は救出できません。
• 拡張属性・タグ・アクセス権は復元しません（更新日時は復元します）。
• 公開版は人工的なディスクイメージで検証しました。本物の不良セクタ、クラウドのみのファイル、復旧キーでの解除は、模擬テストまたは未検証です。

教訓とまとめ

• 「パスワードが違う」と表示されても、パスワードが原因とは限らない。 ログを見れば、どの段階で失敗しているかが分かります。
• 修復より先に救出。 First Aid は書き込みを伴います。データを取り出して確認するまでは、元のSSDに書き込まない。
• ツールの機能は、実際に使う版で確かめる。 The Sleuth Kit の暗号化対応は、開発版の情報とリリース版を取り違えていました。
• 暗号化した外付けSSDだけにデータを置かない。 暗号化は大切ですが、壊れたときに取り出す手段が限られます。別の場所へのバックアップが一番の対策でした。

よくある質問

ダウンロード

ダウンロードした ZIP が改ざんされていないかは、次のコマンドで確認できます。表示された値が上の SHA-256 と同じなら問題ありません。

shasum -a 256 ~/Downloads/apfs-rescue-for-mac-1.0.0.zip

参考資料

• libfsapfs（GitHub） — APFS を読むライブラリ（LGPL-3.0-or-later）
• libfsapfs-python（PyPI） — Python から使うためのパッケージ
• F3 — Fight Flash Fraud（GitHub） — ディスクの読み書き検証ツール
• Homebrew — macOS 用のパッケージ管理

本ツールは無保証です。利用によって生じた損害について、作者は責任を負いません。この記事は、実際のトラブルの記録をもとに、個人情報を含まない形で再構成しています。ツールの出力例は、人工的なテストデータで作成したものです。