# データ消去の標準業務フロー｜受付・隔離・実行・検証・証明書・引渡しをつなぐ

データ消去の事故は、消去ソフトの性能だけでなく、工程間の受け渡しで起きます。回収した端末が未消去棚と消去済み棚で混ざる、証明書に別のシリアル番号が載る、ツールが失敗した端末を売却バッチへ含める、委託先へ渡した台数は合うが個体が違う、といった問題です。安全な運用には、対象個体が受付から最終引渡しまで一方向に進み、各工程の完了条件を満たさなければ次へ移れない仕組みが必要です。

本記事では、情報システム、IT資産管理、セキュリティ、総務、委託管理、内部監査の担当者向けに、データ消去依頼、回収受付、未消去隔離、保存要否確認、方式選択、実行、独立検証、証跡確定、再利用・売却・返却・廃棄、会計・契約終了までを標準業務フローにします。100台を一括処理する例も使い、差異・失敗・故障・オフラインをどの状態へ戻すか具体化します。

フローの状態と進行条件を固定する

「処理中」「完了」だけでは、どの作業が残っているか分かりません。次の状態を個体単位で持ちます。

  1. 消去依頼済み：利用終了理由と対象が登録された
  2. 回収・受領待ち：現物はまだ管理区域へ到着していない
  3. 未消去隔離：現物と個体IDを確認し、安全区域へ保管した
  4. 保留：データ移行、法務、事故調査、所有確認を待っている
  5. 方式判定済み：媒体・分類・用途に合う承認方式を決めた
  6. 消去実行中：作業を開始し、結果は未確定
  7. 消去失敗：成功条件を満たさず隔離した
  8. 実行成功・検証待ち：ツール結果は成功、独立確認前
  9. 証跡確定：対象・方式・結果・証明書を照合した
  10. 引渡し可能：資産・契約面の条件も満たした
  11. 売却・返却・廃棄・再配布済み：次の管理者へ移った
  12. 終了：証跡、会計、契約、台帳まで閉じた

状態変更には資産ID、実施者、日時、作業案件、保管場所を残します。複数端末をバッチ処理しても、個体状態を一括上書きしません。

未消去から証跡確定まで一方通行にする

成功品を未消去区域へ戻す必要がある場合は、通常の逆戻りではなく、理由・承認付きの再開処理にします。証跡確定後に個体番号の誤りが見つかった場合も、既存記録を消さず、訂正案件を作り、影響するバッチ全体を再検証します。

工程1：消去依頼で利用終了と対象母集団を確定する

依頼時に「PC100台」とだけ登録すると、作業後にどの100台だったか検証できません。予定段階でも資産ID、利用者、所在、媒体、終了理由を一覧化します。

依頼の入力項目

  • •消去依頼番号、依頼部門、情報所有者
  • •資産ID、モデル、シリアル番号・IMEI
  • •端末・媒体種別、容量、暗号化状態
  • •現在の利用者、所在、所有区分
  • •退職、更新、修理、売却、リース返却などの理由
  • •再配布、外部売却、返却、廃棄など消去後用途
  • •データ分類、保存・移行の要否
  • •希望期限、契約期限、引渡し予定

依頼時点で個体不明の箱がある場合は、数量だけで完了させず「識別待ち」として受入後に母集団を確定します。

工程2：現物回収と受領を二者で照合する

利用者・拠点から現物を受け取ったら、依頼一覧と個体を照合します。配送追跡の配達完了は、社内の受領完了ではありません。

受領手順

  1. 箱・封印・配送番号、受領日時、受領者を記録する
  2. 外装の破損・開封・数量差異を確認する
  3. 資産ラベルとシリアル番号・IMEIを現物から読む
  4. 依頼一覧との一致、重複、予定外個体を確認する
  5. SIM、SDカード、外付け媒体、増設ドライブを確認する
  6. 膨張・水濡れ・破損など安全上の危険を隔離する
  7. 未消去ラベルを付け、管理区域の棚へ移す
  8. 依頼母集団を実受領個体で確定する

不足、過剰、別個体があれば処理を止め、送付元へ確認します。予定外端末を空いているバッチへ追加しません。

工程3：未消去区域でチェーン・オブ・カストディを開始する

消去前の端末はデータを保持している前提で扱います。一般在庫、修理品、消去済み品と物理的に分けます。

保管統制

  • •未消去区域の入退室者を限定する
  • •棚・箱・封印番号と個体一覧を紐付ける
  • •受領、移動、作業持出し、返却を記録する
  • •端末を無断で起動・ネットワーク接続しない
  • •充電・安全確認を承認された区域で行う
  • •故障・膨張媒体を耐火・安全手順に従い分離する
  • •日次で理論残高と現物件数を照合する

未消去端末数は、前日残高＋受領－作業持出し－保留移動などで説明できるようにします。総数だけでなく個体IDの集合を照合します。

工程4：保存・調査・契約上の保留を確認する

消去は取り消せないため、データ移行と保存義務を先に確認します。担当者の口頭回答だけで進めません。

開始ゲート

  • •業務責任者が利用終了とデータ移行を承認した
  • •法務・監査から訴訟保全や調査保全の指示がない
  • •セキュリティ事故のフォレンジック保全が完了した
  • •リース・修理契約のデータ処理条件を確認した
  • •バックアップ・クラウド同期先の扱いを決めた
  • •アカウント・回線・暗号鍵の関連処理を確認した

保留端末には保留理由、指示者、開始日、再確認日、解除条件を付けます。期限なく未消去棚へ放置しません。

工程5：媒体・データ・用途から消去方式を判定する

承認方式表を使い、媒体種別、モデル、暗号化、故障状態、データ分類、消去後用途を入力して方式を選びます。

判定順序

  1. 媒体と関連記憶領域を特定する
  2. データ分類と外部移転の有無を確認する
  3. 暗号化と鍵管理の前提を確認する
  4. 製品仕様と承認済みサニタイズ機能を確認する
  5. Clear、Purge、Destroyの組織基準へ対応させる
  6. 検証方法と成功条件を決める
  7. 失敗時の代替方式を決める
  8. 実行者・確認者・設備を割り当てる

NISTのSP 800-88 Rev. 2は、情報の機密性に応じた媒体サニタイズプログラムと、Clear・Purge・Destroyなどの考え方を示しています。社内では媒体・モデル別に承認した方式へ落とし込みます。

工程6：作業バッチを作り、個体と設定を凍結する

異なる媒体・方式・データ分類を一つのバッチへ混ぜると設定誤りが起きます。同じ承認条件で処理できる個体だけをまとめます。

バッチ記録

  • •バッチID、作業予定日時、作業場所
  • •対象個体ID一覧と件数
  • •媒体・モデル・容量・暗号化の共通条件
  • •データ分類と消去後用途
  • •承認方式、ツール、設定、バージョン
  • •実行者、確認者、承認者
  • •予定検証方法とサンプル数
  • •失敗時の停止基準

作業開始後の個体追加・削除は、変更理由と二者確認を必要とします。ツールへ読み込むCSVと台帳の対象一覧について、件数と個体IDのハッシュまたは差分を確認します。

工程7：実行前の個体・設定を読み合わせる

消去開始直前に、作業端末、対象媒体、バッチ、ツール設定を照合します。

プレフライトチェック

  • •[ ] 作業台上の個体がバッチ一覧と一致する
  • •[ ] 資産IDと媒体識別子をスキャンした
  • •[ ] 別媒体・追加ドライブ・SDカードを見落としていない
  • •[ ] 承認済みツールとバージョンである
  • •[ ] 適切な方式・対象領域・検証設定を選んだ
  • •[ ] 必要な暗号化・鍵情報を確認した
  • •[ ] ログ時刻と作業者アカウントが正しい
  • •[ ] 作業区域、電源、ネットワーク、設備が安全である

対象選択を作業者の目視だけに頼らず、バーコードや媒体識別子を使ってバッチと突合します。

工程8：消去・破壊を実行し、原ログを保存する

実行中は端末を別バッチへ移動させず、個体ごとの開始・終了・エラーを記録します。

実行記録

  • •作業開始・終了時刻
  • •実行端末・ポート・作業者
  • •ツール、方式、設定、バージョン
  • •対象媒体識別子、容量、検出領域
  • •進捗、警告、終了コード
  • •再試行、電源断、接続変更
  • •生成された原ログの場所と整合性情報

暗号化消去では鍵消去結果と旧データへのアクセス不能を、物理破壊では対象部品、破壊方式、処理結果、残渣管理を記録します。

工程9：成功・失敗・判定不能を個体単位で分ける

バッチ全体が完了しても、一部個体が失敗している場合があります。個体ごとの終了コードと成功条件を評価します。

結果分類

  • •実行成功：承認方式の成功条件を満たした
  • •成功・警告あり：追加確認が必要で検証待ち
  • •実行失敗：再処理または代替方式が必要
  • •判定不能：ログ欠落、対象不一致、電源断などで結果を証明できない
  • •対象外：事前承認された理由でバッチから除外した

失敗・判定不能は赤色ラベルなどで明確にし、成功品と別棚へ隔離します。バッチの一部失敗を成功率の注記だけで済ませません。

工程10：失敗原因を切り分け、同じ母集団を止める

一台の失敗が媒体故障なのか、ツール設定の誤りなのかで影響範囲が異なります。

切り分け手順

  1. 原ログ、接続、電源、媒体状態を保存する
  2. 対象ID・方式・設定の誤りを確認する
  3. 同一バッチの未処理・成功品を一時保留する
  4. 同じモデル・ファームウェア・ツール条件を抽出する
  5. 再処理、別承認方式、物理破壊を選ぶ
  6. セキュリティ責任者が代替処理を承認する
  7. 再実行後に別担当者が結果を確認する
  8. 必要に応じて過去バッチを遡って再検証する

読み出せない媒体を「データなし」と判定せず、論理消去できない場合のDestroy基準へ進めます。

工程11：独立検証で対象・方式・結果を確認する

確認者は作業者の成功表示を眺めるのではなく、バッチの対象と結果を独立して照合します。

検証項目

  • •台帳・バッチ・作業台・ログの個体IDが一致する
  • •承認方式、ツール、設定、バージョンを使った
  • •対象領域・容量・関連媒体に漏れがない
  • •成功条件を満たし、警告が解消されている
  • •暗号化消去の鍵管理前提を満たす
  • •サンプル検証が計画どおり実施された
  • •失敗・除外・再処理の理由と承認がある
  • •原ログが改ざんしにくい場所へ保存された

サンプルで不備が見つかった場合は、その一台だけ直さず、同じ原因を共有するバッチ全体へ検証範囲を広げます。

工程12：証明書を生成し、台帳と集合照合する

証明書は作業完了の宣言ではなく、個体・方式・結果を追跡する索引です。

証明書・台帳の照合

  1. 台帳の消去対象ID集合を出力する
  2. 作業ログの成功ID集合を出力する
  3. 証明書明細のID集合を出力する
  4. 搬出・次工程予定のID集合を出力する
  5. 四つの差分と重複を機械的に確認する
  6. 件数と個体が一致したら確認者が証跡確定する

証明書には資産ID、媒体識別子、方式、ツール、日時、実行者、確認者、結果、証明書番号を含めます。証明書へ秘密データそのものを記載しません。

個人情報保護委員会の通則ガイドラインは、機器・電子媒体を廃棄した記録を保存し、委託時には確実な削除・廃棄を証明書等で確認する重要性を示しています。

工程13：引渡し可能判定と次用途へ移す

消去証跡だけでなく、資産・契約・安全面を確認してから再配布、売却、返却、廃棄へ移します。

引渡し可能ゲート

  • •証跡確定済みで、失敗・保留がない
  • •端末と証明書の個体IDが一致する
  • •MDM、アカウント、証明書、回線を解除した
  • •所有・リース・修理契約上の条件を満たす
  • •膨張・破損など輸送上の危険を判定した
  • •次用途、引渡先、予定日、承認者が決まっている

再配布する場合は新しい環境として初期設定・MDM登録を行い、古い利用者の関連が残らないことを確認します。

工程14：外部委託の受領から証明書まで追跡する

委託時も社内と同じ状態を追跡します。搬出時点で自社処理を終了しません。

委託フロー

  1. 承認済み個体一覧と箱・封印番号を作る
  2. 引渡し側と運送者が数量・封印を確認する
  3. 委託先受領時に個体・封印差異を報告させる
  4. 作業施設、方式、再委託先を確認する
  5. 消去・破壊の個体別結果を受領する
  6. 失敗・不一致を即時報告させ、隔離を確認する
  7. 証明書・ログと自社台帳を照合する
  8. 監査・サンプル確認後に委託案件を閉じる

個人情報保護委員会のデータの消去に関する注意喚起は、復元不可能な手段による消去と、外部委託時の必要かつ適切な監督を示しています。再委託先を含め、実作業を把握します。

工程15：売却・返却・廃棄・会計を完了する

次用途ごとに必要な証跡を回収します。

再配布

  • •新利用者、MDM、設定、資産状態を登録する
  • •旧利用者・旧証明書・旧アカウントが残っていない

売却

  • •買受明細、個体、価格、入金を照合する
  • •所有権移転日と資産台帳を更新する

リース返却

  • •返却先受領、契約番号、台数、追加費用を確認する
  • •返却完了と契約終了を記録する

廃棄・リサイクル

  • •破壊・処理証明、残渣・再資源化の記録を受領する
  • •処分費、会計除却、契約終了を確認する

消去完了から次用途完了までの滞留日数を測り、証跡済み端末が倉庫に長期滞留しないようにします。

100台バッチの具体例

売却予定100台を受領したところ、台帳一致96台、予定外2台、未着2台だったとします。最初のバッチ母集団は96台で確定し、予定外2台は識別待ち、未着2台は回収待ちに残します。

96台の方式判定で、Purge対象88台、暗号鍵の前提不足で別方式へ回す4台、故障でDestroy対象4台となりました。88台を実行した結果、成功85台、失敗2台、ログ欠落で判定不能1台なら、証跡確定へ進めるのは85台だけです。

失敗2台が同じモデル・ファームウェアだった場合、同条件の成功品12台も保留し、設定と製品仕様を再確認します。判定不能1台はログがなければ成功扱いにせず再処理します。故障4台は破壊工程と残渣証跡を別に追跡します。

最終的に96台すべてが証跡確定しても、予定外2台と未着2台は元の100台案件に残ります。「処理96台完了」を「案件100台完了」と報告しないことが重要です。

日次・バッチ終了チェックリスト

日次

  • •[ ] 未消去区域の理論残高と個体集合が一致する
  • •[ ] 保留・失敗・証跡待ちに担当者と期限がある
  • •[ ] 作業持出しと返却を記録した
  • •[ ] 予定外・未着・重複を通常バッチへ混ぜていない
  • •[ ] 高リスク差異を責任者へ報告した

バッチ終了

  • •[ ] 開始時と終了時の母集団を説明できる
  • •[ ] 全個体が成功・失敗・除外・保留のいずれかにある
  • •[ ] ツール・設定・ログ・検証が承認基準を満たす
  • •[ ] 失敗原因の影響範囲を確認した
  • •[ ] 証明書と台帳の個体集合が一致する
  • •[ ] 次用途と引渡し可能判定が記録されている
  • •[ ] 実行者とは別の確認者が終了を承認した

まとめ：消去フローは個体が次工程へ進める条件を管理する

データ消去の標準化では、作業手順だけでなく、個体が受付、未消去隔離、保留、方式判定、実行、検証、証跡確定、引渡し可能へ進む条件を固定します。失敗・判定不能を成功品から分け、同じ原因を共有するバッチを止め、台帳・作業ログ・証明書・搬出明細の個体集合を照合することで、件数は合うのに端末が違う事故を防げます。

売却へ進める端末は、証跡確定、MDM・回線解除、所有・契約処理を確認してから[中古端末の買取相場を確認する](/kaitori-search)と状態・数量・処理費を比較します。最初の改善として、未消去区域、消去失敗棚、証跡待ち棚の現物と台帳を個体IDで照合し、期限のない滞留を抽出してください。