PC廃棄のデータ消去：SSD・HDD別の方式と証明書で照合すべき項目
SSDで上書き消去が効かない理由をディスクイメージとLUKSで確かめ、Clear/Purge/Destroyの選び方、証明書と台帳の照合、リース返却と委託の確認点をまとめました。
PC廃棄のデータ消去とは、手放すPCの記憶装置から業務データを「現実的な労力では読み出せない状態」にし、その事実を台帳と証明書で後から説明できるようにする作業です。ファイルを消してごみ箱を空にすることでも、Windowsを初期化することでもありません。HDDとSSDでは効く方法が違い、特にSSDでは昔ながらの上書きツールが記憶領域の一部に届かないため、方式の選び方から見直す必要があります。
対象は、リース満了や入れ替えで数十台単位のPCを返却・廃棄する情シス担当者です。読み終えると、機器の種類ごとにどの方式を選ぶか、業者から受け取るデータ消去証明書のどこを台帳と突き合わせるか、リース返却と外部委託で何を確認するかが決まり、そのまま稟議に添付できる1枚の社内手順を作れます。消去の仕組みは、Ubuntu 26.04 上で作ったディスクイメージとLUKSボリュームで実際に確かめた結果を載せています。
この記事でわかること
- SSDで上書き消去が信用できない理由と、代わりに使うサニタイズコマンド・暗号消去の位置づけ
- NIST SP 800-88 の Clear / Purge / Destroy を HDD・SSD・故障機・リース機に当てはめた判断表
- BitLocker の鍵を消すだけで済ませてよい条件と、済ませてはいけない条件
- データ消去証明書に必須の記載項目と、資産台帳との照合方法
- 回収から台帳クローズまでを1枚にまとめた社内手順
PC廃棄のデータ消去で「削除」と「初期化」が足りない理由
ファイルを削除しても、ファイルシステムは「この領域は空いている」と記録を書き換えるだけで、中身のバイト列は次に上書きされるまで残ります。クイックフォーマットも同じで、作り直すのは管理情報の部分です。これを手元で確かめるために、256MBの空のディスクイメージを作り、100MB目の位置に機密データに見立てた文字列を書き込んでから ext4 でフォーマットしました。
sudo apt install -y cryptsetup-bin e2fsprogs nvme-cli hdparm
cryptsetup --version
cryptsetup 2.8.4 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
nvme version
nvme version 2.16 (git 2.16)
libnvme version 1.16.1 (git 1.16.1)
hdparm -V
hdparm v9.65
mkfs.ext4 -V
mke2fs 1.47.2 (1-Jan-2025)
Using EXT2FS Library version 1.47.2mkdir -p ~/erase-lab && cd ~/erase-lab && truncate -s 256M disk.img && ls -l disk.img
-rw-r--r-- 1 ryoma ryoma 268435456 Sep 29 07:52 disk.img
cd ~/erase-lab && printf "CONFIDENTIAL-payroll-2026-ryoma" | dd of=disk.img bs=1M seek=100 conv=notrunc status=none && grep -a -c "CONFIDENTIAL-payroll" disk.img
1
cd ~/erase-lab && mkfs.ext4 -q -F -E nodiscard disk.img && grep -a -c "CONFIDENTIAL-payroll" disk.img
1フォーマット後も grep が1件ヒットしています。-E nodiscard は「使わなくなった領域を装置に通知しない」指定で、TRIMを使わないHDDでのフォーマットに相当します。管理情報だけが新しくなり、100MB目の文字列には一切触れていません。廃棄前に「フォーマットしたから大丈夫」と報告された端末は、この状態だと考えてください。
次に、同じ文字列を書き直してから、今度は既定の設定（discard あり）でフォーマットしました。
cd ~/erase-lab && printf "CONFIDENTIAL-payroll-2026-ryoma" | dd of=disk.img bs=1M seek=100 conv=notrunc status=none && grep -a -c "CONFIDENTIAL-payroll" disk.img
1
cd ~/erase-lab && mkfs.ext4 -q -F disk.img; grep -a -c "CONFIDENTIAL-payroll" disk.img; echo "grep exit=$?"
0
grep exit=1
cd ~/erase-lab && du -h --apparent-size disk.img && du -h disk.img
256M disk.img
17M disk.img今度は0件です。見かけのサイズは256Mのまま、実際に確保されている領域は17Mに減っており、mke2fs が空き領域を「破棄」したことがわかります。ここで結論を急がないでください。このイメージはホストのファイルシステム上のファイルなので、破棄された領域は本当に解放されました。ところが実物のSSDでTRIMが送られた場合、OSから見えるのは「その番地を読むとゼロが返る」という論理上の結果だけです。SSDの内部では、書き込みはフラッシュの別の場所に振り替えられ、古いデータが入ったセルはガベージコレクションで消去されるまで残ることがあります。OS側から読み直して何も出てこないことは、SSDの物理的な中身が消えた証拠になりません。
SSDで上書きツールが信用できない仕組み
上書きツールは、OSが使う通常の読み書き命令で、見えている番地（LBA）を端から端まで書き換えます。HDDはLBAとプラッタ上の位置がほぼ固定なので、全LBAを書けば旧データの場所も書き換わります。SSDはそうなっていません。同じLBAへの書き込みは毎回フラッシュの別のページに行き、どのページがどのLBAかはコントローラの対応表が決めます（ウェアレベリング）。さらに、ユーザーに見せている容量とは別に予備の領域（オーバープロビジョニング）を持っていて、ここには通常の命令ではアクセスできません。
NIST SP 800-88 の2025年9月の改訂版（Rev. 2）も、予備セルとウェアレベリングを持つフラッシュ系の装置では通常の読み書き命令で過去のデータをすべて消すことはできない、という立場を取っています。オーバープロビジョニングのあるSSDに複数回上書きを重ねる運用は避けるべきだとも書かれています。「米国防総省方式（DoD 5220.22-M）で複数回上書き」という仕様書の文言がSSDに対して意味を持たないのはこのためです。同じ改訂で、上書きを何回も重ねる必要はないことも明確にされました。
代わりに使うのは、装置自身に全領域を消させる専用コマンドです。NVMeでは Sanitize コマンドがあり、nvme-cli 2.16 のヘルプには次の動作が並んでいます。
nvme sanitize --help 2>&1 | grep -A4 -- "--sanact"
[ --sanact=<NUM>, -a <NUM> ] --- Sanitize action: 1 = Exit failure
mode, 2 = Start block erase,3 =
Start overwrite, 4 = Start
crypto erase, 5 = Exit media
verification
nvme format --help 2>&1 | grep -- "--ses"
[ --ses=<NUM>, -s <NUM> ] --- [0-2]: secure erase
hdparm -h 2>&1 | grep -E "sanitize-(block-erase|crypto-scramble|status)|security-erase"
--sanitize-block-erase Start block erase operation
--sanitize-crypto-scramble Change the internal encryption keys that used for used data
--sanitize-status Show sanitize status informationNVMeの Sanitize は Block Erase（フラッシュのブロック単位の消去）、Overwrite（装置内部での上書き）、Crypto Erase（内部の暗号鍵の破棄）を選べます。SATA機では hdparm の --sanitize-* 系が同じ役割で、どれを受け付けるかは装置次第です。これらはオーバープロビジョニング領域も含めて装置のファームウェアが処理するので、Rev. 2 の分類では Purge の手段に入ります。その代わり、ファームウェアが正しく実装されているかはメーカーを信用するしかない、という弱点もRev. 2 は明記しています。
実機での実行は次の流れになります。この環境には実物のNVMe SSDがないため、下のブロックはこの環境では実行していません。コンテナ内で nvme sanitize /dev/nvme0n1 --sanact=4 --dry-run を試すと /dev/nvme0n1: No such file or directory で止まるのを確認したところまでです。
sudo nvme list
sudo nvme id-ctrl /dev/nvme0 -H | grep -i -A4 sanicap
sudo nvme sanitize /dev/nvme0 --sanact=4
sudo nvme sanitize-log /dev/nvme01行目で対象のシリアル番号を確認し、2行目で Crypto Erase / Block Erase のどちらに対応しているかを見ます。3行目が消去の開始で、4行目の sanitize-log で完了状態を確認します。NIST の改訂版の立場では、Clear や論理的な Purge の後に中身を全面サンプリングして確かめることは、組織の方針で求めない限り不要だとしています。検証の中心はツールの完了ステータスとエラーの有無なので、sanitize-log の結果は証明書の「検証方法」欄にそのまま書ける記録になります。
SSDに磁気消去（デガウス）を依頼しても効果はありません。改訂版の SP 800-88 はフラッシュ系の装置にデガウスを使わないよう明記しており、「完了」と報告されても中身は何も消えていない例として挙げています。業者の見積書で「磁気消去」がSSDにも一律で適用されていたら、SSD分は物理破壊かサニタイズに差し替えてもらってください。
暗号消去とBitLockerの鍵破棄はどこまで信用できるか
暗号消去は、データそのものではなく暗号鍵を消す方式です。ディスク上には暗号文だけが残り、鍵がなければ読めません。消すのは鍵だけなので数秒で終わるのが利点です。仕組みはLinuxのLUKSで再現できます。32Mのファイルを暗号化ボリュームにし、鍵スロットを消去してから同じパスフレーズで開けるか試しました。
cd ~/erase-lab && truncate -s 32M vault.img && printf "lab-passphrase-0929" > pass.txt && cryptsetup luksFormat --batch-mode --type luks2 --pbkdf pbkdf2 --key-file pass.txt vault.img && echo formatted
formatted
cd ~/erase-lab && cryptsetup luksDump vault.img | grep -E "^Keyslots:|^ [0-9]+: luks2|^Version"
Version: 2
Keyslots:
0: luks2
cd ~/erase-lab && cryptsetup open --test-passphrase --key-file pass.txt vault.img && echo "key OK"
key OK
cd ~/erase-lab && cryptsetup luksErase --batch-mode vault.img && cryptsetup luksDump vault.img | grep -A2 "^Keyslots:"
Keyslots:
Tokens:
Digests:
cd ~/erase-lab && cryptsetup open --test-passphrase --key-file pass.txt vault.img; echo "exit=$?"
No usable keyslot is available.
exit=1luksErase の後は Keyslots の下が空になり、正しいパスフレーズを渡しても No usable keyslot is available. で開けません。パスフレーズはデータ暗号鍵を包んでいる鍵を取り出すためのもので、その包みが消えたからです。BitLockerも同じ多段構造で、データはフルボリューム暗号化キーで暗号化され、それをボリュームマスターキーが包み、さらにTPMや回収パスワードといった保護機能がマスターキーを包んでいます。
ただし、このデモには前提が2つ隠れています。1つ目は「鍵のコピーが他にない」ことです。LUKSのヘッダーをバックアップしていたら、それを書き戻せば開けます。企業のBitLocker運用では回収パスワードを Entra ID や AD DS に預けるのが一般的で、Microsoft のドキュメントによればAD DSの回収パスワードは設計上削除されません。NIST の文書も、鍵がバックアップ・預託されている装置では、鍵の保管先を把握できていない限り暗号消去を信用すべきでないとしています。2つ目は「最初から平文が一度も書かれていない」ことです。運用中の端末で後から「使用済み領域のみ暗号化」の BitLocker を有効にした場合、有効化前に平文で書かれて削除済みになった領域は、上書きされるまで暗号化されずに残るとMicrosoftが注意書きしています。
判断ルールにすると次のとおりです。キッティング時に新品の状態でBitLockerを有効にした端末（キッティングの自動化で最初に暗号化まで済ませている構成）なら、平文が書かれた履歴はありません。この場合はBitLockerによって「紛失しても読めない」状態が保たれているので、廃棄時の本命はSSDのサニタイズで、BitLockerは二重目の防御と位置づけます。途中から暗号化した端末や、暗号化の有無が台帳でわからない端末は、BitLockerを根拠にせず、サニタイズか物理破壊を必ず行います。どちらの場合も「BitLockerだから消去不要」とは扱いません。
端末の暗号化状態は、廃棄前の回収時に管理者権限のPowerShellで確認して記録します。Windows がないためこの環境では実行していませんが、manage-bde の状態表示に「変換状態」と「暗号化の方法」が出るので、「使用済み領域のみ」で途中から有効化されたかどうかの手がかりになります。
manage-bde -status C:
manage-bde -protectors -get C:Windows の「このPCをリセット」→「すべて削除」→「データのクリーニング」は、Microsoft 自身がサポート記事で「消費者向けで、政府や業界のデータ消去基準を満たさない」と書いている機能です。個人用PCの譲渡には便利ですが、社内規程上の消去方式として証明書に書く根拠にはなりません。社員に返却前の作業として頼む場合も、情シス側の消去を省く理由にしないでください。
Clear・Purge・Destroyを機器の種類に当てはめる
NIST SP 800-88 Rev. 2 は消去を3段階に分けています。Clear は通常の読み書き命令での上書きや工場出荷状態へのリセット、Purge は研究所レベルの手段でも復元できない状態にしつつ装置を再利用可能に残す方法（サニタイズコマンド、暗号消去など）、Destroy は破砕・溶解・焼却などで装置ごと使えなくする方法です。可能なら Clear より Purge を使う、というのが改訂版の推奨です。なお Rev. 2 からは媒体ごとの具体的な手順表が本文から外れ、IEEE 2883 など別の規格を参照する形になりました。旧版（2014年の Rev. 1）の付録の表を社内規程に写している場合は、根拠の書き方を見直す時期です。
情シスの実務に落とすと、次の判断表になります。「推奨」は私たちの判断で、条件が外れる場合は右の列に従います。
| 機器の状態 | 上書きツール（Clear） | 装置のサニタイズ・暗号消去（Purge） | 物理破壊（Destroy） | 推奨と例外 |
|---|---|---|---|---|
| HDD・正常に動く | 全LBAの上書き1回で効く | 装置が対応していれば使える | 可 | 上書き1回＋完了ログ。機密度が高い部署の端末は破壊 |
| SATA SSD・正常 | 予備領域に届かない | hdparm の sanitize 系、またはPCメーカーのBIOS消去機能 | 可 | サニタイズ。BIOSで凍結（frozen）状態になり受け付けない機種は破壊に切り替え |
| NVMe SSD・正常 | 予備領域に届かない | nvme sanitize（Crypto Erase / Block Erase） | 可 | サニタイズ。sanitize-log で完了を記録 |
| 基板直付けのストレージ（薄型ノート等） | 予備領域に届かない | メーカー提供の消去機能があるか要確認 | 基板ごと | メーカー機能がなければ基板ごと破壊。取り外して単体破壊はできない |
| 起動しない・認識しない | 実行できない | 実行できない | 必須 | 破壊一択。Rev. 2 も上書きは故障した装置に使えないとしている |
| リース返却機（破壊不可） | HDDなら可 | SSDはこれが唯一の選択肢 | 契約上不可 | サニタイズ＋リース会社側の消去証明書。詳細は後述 |
表で「上書きツール」をSSDの列から外しているのは、フリーソフトの消去ツールを禁止する趣旨ではありません。フリーソフトでも中でATA/NVMeのサニタイズ命令を発行しているものなら Purge に数えられます。社内規程に書くべきなのはツール名ではなく「どの命令で消したか」で、証明書にもその単位で書かせます。
データ消去証明書に書かれていなければならない項目
データ消去証明書は、監査で「この端末のデータはいつ、誰が、どの方式で消したか」を聞かれたときの唯一の証拠です。個人情報保護委員会のガイドライン（通則編）の物理的安全管理措置も、個人データが入った機器の廃棄は復元不可能な手段で行い、廃棄の記録を残し、委託した場合は委託先が確実に消したことを証明書等で確かめる、という流れを示しています。証明書の様式例は NIST SP 800-88 の付録にあり、最低限の記載項目が並んでいます。それを台帳との照合という目的で並べ直したのが次の表です。
| 項目 | 書かせる内容 | 台帳との照合で見るところ |
|---|---|---|
| メーカー・型番 | 記憶装置そのもののメーカー・型番（PC本体とは別） | 台帳の「搭載ストレージ」欄と一致するか |
| シリアル番号 | 記憶装置のシリアル。PC本体のシリアルも併記 | 最重要。PCのシリアルだけの証明書は受け取らない |
| 管理番号 | 社内の資産番号（資産ラベル） | 台帳の主キーで突き合わせる |
| 方式 | Clear / Purge / Destroy のどれか | 判断表の方式と一致するか |
| 手法 | 上書き、Block Erase、暗号消去、破砕など | SSDに「上書き」や「磁気消去」と書かれていないか |
| 使用ツールとバージョン | ソフト名とバージョン、破壊なら装置名 | 後から手法の妥当性を追えるか |
| 検証方法 | 完了ステータスの確認、破壊後の残骸の確認など | 空欄なら差し戻す |
| 実施者・確認者 | 氏名、役職、日付、場所、連絡先、署名 | 回収日より後の日付になっているか |
シリアル番号を記憶装置単位で要求する理由は、PCのシリアルとストレージのシリアルが一致しないからです。保守でSSDを交換したPCは、台帳上は同じ資産番号でも中の記憶装置が別物で、外した古いSSDがどこへ行ったかは証明書のPC単位の記載では追えません。台帳に搭載ストレージのシリアルを持たせる運用は、IT資産管理の台帳づくりの項目に1列足すだけで始められます。
「PC一式 30台 消去済み」のような台数だけの証明書は受け取らないでください。例として、台帳上30台を渡したのに証明書に29行しかなければ、1台は所在不明です。1行1台、シリアル付きであれば、この差分は照合スクリプトで機械的に出せます。NIST の文書も、証明書の価値は搬入から搬出、消去後の行き先までの追跡が途切れないことに依存すると書いています。
リース返却と外部委託で確認すること
リース機は所有権がリース会社にあるので、社内判断で破壊できません。SSD搭載機では Purge（サニタイズか暗号消去）しか選択肢がなく、契約によってはリース会社側でも返却後に消去を行います。契約書で確認するのは、消去をどちらが実施するのか、リース会社の消去証明書にストレージのシリアルが載るのか、返却前に自社で消去してよいのか（BIOSのパスワード解除を求められることが多い）の3点です。返却前に自社でサニタイズし、リース会社の証明書と自社のログを両方保管するのが一番説明しやすい形です。
返却の前に外しておくべき紐付けもあります。Microsoft は、端末が組織を恒久的に離れるときは Windows Autopilot から登録解除し、その前に Intune から端末を削除する順序を示しています。Autopilot の登録はハードウェアハッシュ（本体とストレージのシリアルを含む）で端末とテナントを結び付けているので、残したまま返すと次の利用者のセットアップに自社の設定が絡みます。Intune からの削除、Autopilot の登録解除、BIOSの管理者パスワード解除を返却チェックリストに入れておきます。BitLocker回復キーの管理で Entra ID に鍵を保管している場合は、返却後もその鍵が残ることを前提に、台帳へ「返却済み・鍵は保管先に残存」と記録しておくと、暗号消去を消去の根拠にしなかった理由が監査で説明できます。
廃棄を業者に委託する場合は、委託先の選定と監督が委託元の責任になります。見積り段階で確認するのは次の点です。持ち出し型（引き取り後に業者の施設で消去）か、社内での出張消去か。搬出時に台帳のシリアルと実物を業者と一緒に照合するか。再委託があるか、あるならどこまで証明書に出るか。SSDに適用する手法は何か（磁気消去をSSDに使う業者は除外）。機密度の高い部署の端末だけ出張破壊に分ける、という組み合わせも稟議で通りやすい形です。
社員のPC交換時に「古いPCは各自で初期化してから返却」とだけ周知すると、回収箱に入った時点で誰の端末か、暗号化されていたかがわからなくなります。回収は必ず資産ラベルで受け付け、受け付けた時点で台帳のステータスを「廃棄待ち」に変え、施錠保管に移してください。消去の前の保管期間が一番紛失しやすい区間です。
1枚にまとめる社内手順
ここまでの判断を、情シス1〜2名で回せる手順にまとめます。情報セキュリティポリシーの下位の手順書として置く想定で、各段階の担当と残す記録を決めてあります。
- 申請と対象確定（担当：情シス）：廃棄・返却する資産番号を台帳から抽出し、PCのシリアルと搭載ストレージのシリアルを一覧にする。リース機はリース契約番号も付ける。
- 回収と保管（担当：情シス）：資産ラベルで受け付け、台帳を「廃棄待ち」に変更して施錠保管する。
manage-bde -statusの結果をこの時点で記録する。 - データ退避の確認（担当：利用部門の長）：業務データがクラウドやファイルサーバーに移っていることを利用部門が承認する。消去後の復元はできないので、承認の記録を残す。
- 方式の決定（担当：情シス）：判断表で機器ごとに Clear / Purge / Destroy を決める。故障機と基板直付けで消去機能がない機器は Destroy。
- 消去の実施（担当：情シスまたは委託先）：サニタイズの完了ログ、破壊の場合は残骸の確認記録を残す。
- 証明書の照合（担当：情シス）：証明書のストレージシリアルを台帳と1行ずつ突き合わせ、差分が0であることを確認する。
- 台帳のクローズと承認（担当：情シスの責任者）：台帳を「廃棄済み」「返却済み」に変更し、Intune・Autopilot の登録削除を済ませ、責任者が証明書と台帳の照合結果を確認して承認する。
最後の段階で「責任ある立場の者の確認」を置いているのは、個人情報保護委員会のガイドライン（通則編）の中小規模事業者向けの手法の例示に、廃棄したことを責任ある立場の者が確認する旨が挙がっているためです。証明書と照合結果、承認の記録を同じフォルダにまとめ、資産番号で検索できるようにしておくと、監査で1台ずつ追跡を聞かれたときに数分で答えられます。
よくある質問
パソコンを廃棄する前にデータ消去は必要ですか？
必要です。フォーマットや初期化の後でも、HDDでは元のデータが残ることを本文のディスクイメージで確認しました。個人データを扱う企業では、個人情報保護委員会のガイドラインが機器の廃棄を復元不可能な手段で行うよう求めているので、方式と記録の両方を用意します。
PC内のデータを完全に削除するにはどうすればいいですか？
HDDは全領域の上書き、SSDは nvme sanitize や hdparm の sanitize 系など装置自身に消させるコマンドを使います。SSDに上書きツールだけを使うと予備領域が残ります。機密度が高いもの、故障して命令を受け付けないものは物理破壊にします。
パソコンを処分したいけどデータ消去ができない。どうすればいい？
起動しない、ストレージを認識しないといった理由でコマンドが使えない機器は、物理破壊に切り替えます。取り外せるSSDやHDDは単体で破砕し、基板直付けのものは基板ごと破壊します。自社に設備がなければ出張破壊を業者に委託し、シリアル付きの証明書を受け取ります。
データ消去証明書は自社で発行してもよいですか？
自社で消去したなら、自社の記録として作って構いません。NIST SP 800-88 の様式例も組織内での記録を想定しています。ストレージのシリアル、方式、手法、ツールとバージョン、検証方法、実施者と確認者の署名を1台1行で残し、サニタイズの完了ログを添付すれば、業者の証明書と同じ役割を果たします。
まとめ
SSDでは上書き回数を増やしても予備領域に届かないので、社内規程の根拠を「何回上書きしたか」から「どの命令で、どのシリアルの装置を消したか」に切り替えます。鍵の破棄は、新品時から暗号化していて鍵のコピーを管理できている場合の二重目の防御にとどめます。まずは資産台帳に「搭載ストレージのシリアル」と「BitLocker有効化の時期」の2列を足し、次回の廃棄から証明書を1行ずつ照合してください。