# 紛失・故障時のインシデント対応の実務ガイド｜抜け漏れを防ぐチェックリストと記録項目を整える
端末の紛失・故障対応で最も危険なのは、担当者が何もしないことではなく、複数の担当者が別々の表やチャットで対応し、「遠隔ロック済み」「回線停止済み」「交換済み」のどれかを事故完了と思い込むことです。端末、アカウント、データ、安全、業務復旧には別々の完了条件があります。
本稿は、社用スマートフォン、タブレット、ノートPCの事故を受け付けるサービスデスク、情報システム、セキュリティ、総務・資産管理向けの実行チェックリストです。事故前の準備、最初の聞き取り、紛失・盗難と故障・電池異常の分岐、遠隔操作、個人データ評価、代替端末、発見端末の再受入れ、終結監査を一つのincident_idで追えるようにします。
チェック1：事故前に管理状態を証明できるようにする
事故後に「暗号化されていたはず」「MDMに入っていたと思う」と確認するのでは遅すぎます。平時の資産台帳へ、事故判断に必要な項目を同期します。
- •asset_id、serial、IMEI、電話番号
- •所有区分、利用者、所属、上長、現在地
- •OS、暗号化、画面ロック、MDM登録・最終接続
- •SIM・eSIM、通信契約、回線管理者
- •SSO、VPN、端末証明書、MFA登録方式
- •ローカル保存を許すデータ区分
- •保険、保証、修理窓口、回収拠点
- •電池・リコール・修理履歴
- •代替端末の優先度と業務継続手段
月次で台帳とMDM、ID管理、通信契約を突合し、暗号化不明、最終接続超過、利用者不一致を例外として直します。事故対応訓練用の端末・アカウントを用意し、本番顧客や本番通知先を使わないことも準備へ含めます。
チェック2：一次受付で事実と推測を分ける
受付者は、利用者を責める質問ではなく、次の判断に必要な事実を短時間で集めます。
- •発見日時、最終確認日時、最終正常利用日時
- •発生場所、移動経路、現在の候補場所
- •紛失、盗難疑い、故障、破損、電池異常の申告
- •端末種別、識別子、電話番号、会社・個人所有
- •電源・通信・位置情報・MDMの現在状態
- •画面ロックと本人が知る暗号化状態
- •保存・閲覧したデータ、利用中の高権限サービス
- •MFA通知、不審ログイン、第三者接触の有無
- •発熱、膨張、異臭、煙、浸水、負傷の有無
- •すでに行った捜索、再起動、充電、遠隔操作
「紛失に違いない」は分類、「電車内で最後に使用した」は事実、「座席に置いたと思う」は本人推測として別欄へ書きます。受付時刻、受付者、本人確認方法を記録し、incident_idを利用者へ返します。
本人確認ができない場合
端末を失った本人は通常のMFAを使えないことがあります。上長からの申告だけでパスワード再設定をせず、事前登録した代替連絡先、社員情報、対面確認など複数の手段を組み合わせます。本人確認未完了でも、高リスクなセッションの一時停止は緊急権限者が判断できるようにします。
一件の記録を後から再現できる形にする
チャット本文をそのまま事故台帳にせず、event_id、incident_id、occurred_at、observed_at、recorded_at、actor、source、action、target、resultを構造化します。利用者の証言、MDMの自動記録、管理者の操作、外部事業者の回答をsourceで区別し、訂正時は元の記録を消さず訂正理由と承認者を追加します。
日時はタイムゾーン付きで保存し、海外出張や夏時間でも順序を再現できるようにします。添付画像やログにはハッシュ、取得元、取得日時、閲覧権限、保存期限を付けます。個人情報や位置情報を含むため、事故対応に不要な人へcase全体を共有しません。経営報告には必要な集計を渡し、個別の位置履歴や認証情報を無制限に転載しない設計にします。
一つのフィールドへ長文で「対応済み」と書くのではなく、端末、認証、回線、データ、安全、復旧を別状態にします。各状態にはowner、due_at、evidence_id、approved_byを持たせます。こうすると、端末が発見済みでもデータ評価が未完了、代替端末は配布済みでも旧証明書が有効、といった残件を機械的に抽出できます。
エスカレーションは重大度だけでなく期限超過でも発火させます。たとえば、高権限セッションの停止結果が30分確認できない、遠隔コマンドが1時間unreachable、影響件数が算定不能のまま4時間経過した場合に、代理権限者やセキュリティ責任者へ自動通知します。通知を出したことではなく、受領・担当割当・次回更新時刻まで確認します。
チェック3：安全を最初の分岐にする
端末が膨張、異常発熱、異臭、発煙、焼損している場合は、情報確認より人身安全を優先します。
- •[ ] 充電・通電・圧迫・分解を止めた
- •[ ] 周囲の人を離し、施設の緊急手順へ連絡した
- •[ ] 無理に持ち運ばず、安全担当の指示を得た
- •[ ] 通常の返送箱や一般ごみへ入れないよう案内した
- •[ ] 負傷・延焼・周辺被害を別の安全事故として記録した
- •[ ] メーカー、専門事業者、施設管理へ引き継いだ
総務省消防庁のリチウムイオン電池火災の案内では、強い衝撃や高温下での放置などが主な出火原因として示され、出火時は周囲への周知と身の安全確保を最優先としています。社内チェックリストは消火方法を一律に断定せず、施設の防災計画と消防の指示へ接続します。
チェック4：紛失・盗難の初動を時刻順に記録する
最初の15分
- •[ ] incident_idと暫定重大度を登録した
- •[ ] 利用者・端末・最終位置を照合した
- •[ ] 単独で危険な場所へ回収に行かないよう案内した
- •[ ] MDM最終接続、暗号化、ロック状態を保存した
- •[ ] 高権限・決済・管理者アクセスの有無を確認した
- •[ ] 当番責任者、上長、セキュリティへ通知した
1時間以内
- •[ ] 紛失モード・ロック・位置確認の判断と結果を記録した
- •[ ] SSO、VPN、メール、クラウドのセッションを評価した
- •[ ] SIM・eSIM・回線、電話転送、SMS認証を確認した
- •[ ] 顧客・従業員・認証データの影響範囲を仮置きした
- •[ ] 交通機関・施設・警察等の受付番号を記録した
- •[ ] 次回更新時刻と責任者を決めた
24時間以内
- •[ ] ログ、利用履歴、データ種類、対象件数を更新した
- •[ ] ワイプ・保全・捜索継続の判断を承認した
- •[ ] 外部報告・本人通知の要否を専門担当へ付議した
- •[ ] 代替端末と業務継続手段を安全に用意した
- •[ ] 未確認項目ごとに取得元と期限を置いた
時間目標は社内初動用です。法的な報告期限や契約上の通知期限とは分け、事故時点の最新基準を担当者が確認します。
チェック5：遠隔操作をコマンド単位で追跡する
MDM操作ログには、操作名、対象端末、要求者、承認者、要求日時、配信日時、応答、完了日時、失敗理由を残します。
状態は少なくとも次に分けます。
- •requested：要求を登録した
- •queued：配信待ち
- •delivered：端末へ届いた
- •acknowledged：端末が受け付けた
- •completed：成功を確認した
- •failed：失敗した
- •unreachable：期限まで接続されない
- •cancelled：承認により取り消した
「ワイプ済み」はcompletedだけに使います。unreachableなら、セッション、証明書、回線、アカウントを端末外で止め、再接続時の動作と監視期限を残します。位置情報は取得権限、目的、保存期限を確認し、関係のない担当者へ共有しません。
チェック6：端末外の認証経路を閉じる
端末をロックしても、ブラウザセッション、MFA、証明書、API鍵、SIMが利用できる場合があります。
- •[ ] SSOと主要SaaSのアクティブセッションを失効した
- •[ ] VPN・Wi-Fi・端末証明書の信頼を外した
- •[ ] MFA登録、パスキー、復旧コードを見直した
- •[ ] メール転送、共有権限、代理アクセスを確認した
- •[ ] API鍵、SSH鍵、開発・管理用秘密情報を評価した
- •[ ] SIM・eSIM・回線とSMS認証を停止・移管した
- •[ ] 高リスク操作の監視ルールを追加した
パスワード変更とセッション失効は別作業です。パスワード変更後も既存セッションが残るサービスがあるため、サービスごとの管理機能を使います。変更範囲が広い場合は、利用者の業務復旧に必要な順序も記録します。
チェック7：故障端末はデータ・安全・修理を分ける
起動しない端末はデータが消えた端末ではありません。受付時に症状を記録し、利用者へ再起動、初期化、分解、私的修理店への持込を繰り返させません。
故障処理票には次を記録します。
- •症状、発生操作、エラー、最終正常時刻
- •落下、浸水、発熱、異臭、電池膨張
- •暗号化、バックアップ、法務保全の有無
- •診断・修理でデータへアクセスする範囲
- •端末、SIM、ストレージ、交換部品の引渡記録
- •修理事業者、受付番号、配送・封印
- •消去可否、消去失敗、物理破壊の判断
- •修理後検査、再構成、廃棄・売却の行先
電源が入らないため消去を確認できない場合は、failedまたはnot_verifiedとします。故障を理由に資産台帳から削除せず、ストレージや基板を含む最終処理まで追います。
チェック8：個人データ影響を判断できる材料をそろえる
個人情報保護・法務担当へ「端末をなくした」だけを渡しても判断できません。次を一つの評価票へ集めます。
- •データの種類、対象者、概算件数と算定根拠
- •ローカル保存、同期、キャッシュ、通知表示の状態
- •暗号化方式、鍵の保護、画面ロック、MDM
- •第三者取得・閲覧・改変の事実またはおそれ
- •不正アクセス、窃取、不正目的を示す情報
- •セッション、回線、遠隔操作、発見状況
- •影響を受ける権利利益、顧客・委託先契約
- •判断日時、判断者、未確認事項、次回見直し
個人情報保護委員会の漏えい等の対応と資料で、報告対象、報告先、速報・確報、本人通知の現在の案内を確認します。暗号化だけで自動的に結論を出さず、事故時の法令、委任先、業界規制、契約を専門担当が評価します。
チェック9：外部引渡しをチェーン・オブ・カストディで残す
交通機関、警察、修理会社、物流会社、保険会社との受渡しをincident_idとasset_idへ結びます。
- •引渡元・引渡先の組織、担当、連絡先
- •引渡・受領日時と場所
- •端末・SIM・付属品の識別子と数量
- •外装状態、封印番号、梱包写真
- •追跡番号、受付番号、修理番号、届出番号
- •データアクセスと部品交換の許可範囲
- •旧媒体・交換部品の返却または処理条件
- •次の責任者、期限、未解決事項
配送の配達完了は、個体受領や消去完了ではありません。受領拠点で封印、識別子、状態を照合し、予定外の端末やSIMを例外にします。
チェック10：代替端末は新規貸与として設定する
事故端末と同じ権限を急いで複製すると、不要な高権限や古いMFAを引き継ぎます。
- •[ ] 本人確認と上長の業務必要性を確認した
- •[ ] 新asset_id、貸与者、返却条件を登録した
- •[ ] MDM、暗号化、OS、必須設定を検査した
- •[ ] 新しいMFA・証明書を安全に登録した
- •[ ] 必要最小限の権限から復旧した
- •[ ] データの復元元・範囲・実行者を記録した
- •[ ] 旧端末との同時有効状態を解消した
代替調達では、必要性能、納期、保証、管理適合性を先に決めます。事故対応とデータ処理を終えた後、比較条件を固定して[PC相場を確認する](/pc-search)ことはできますが、未消去の事故端末を下取りへ出して費用を相殺してはいけません。
チェック11：発見端末を隔離して再受入れする
発見連絡を受けた時点で紛失状態を解除しません。誰が、どこで、いつ、どの状態で発見し、誰が受領したかを記録します。
再受入れ項目は次です。
- •asset_id、serial、IMEIの一致
- •外装、封印、SIM、付属品
- •最終接続と発見後の操作
- •MDM、OS、暗号化、改変兆候
- •SSO・アプリ・データのアクセスログ
- •マルウェア・証明書・設定の検査
- •初期化・再構成・資格情報再発行の判断
- •警察・施設等からの受領証
業務へ戻す場合は、検査者と承認者、再登録日時を残します。安全や完全性を証明できなければ再構成し、旧資格情報を復活させません。
チェック12：三つのケースで分岐を確認する
ケースA：電車内で暗号化スマートフォンを紛失
22時に利用者が報告し、MDM最終接続は21時35分、強固な画面ロックと暗号化は確認済みでした。受付は紛失モード、回線停止、SSOセッション失効を実施し、位置情報と交通機関の受付番号を記録しました。翌朝発見されても、受領・ログ確認・再構成までcaseを閉じません。
ケースB：顧客先でノートPCへ飲料をこぼした
利用者は電源操作を止め、現地責任者とITへ報告しました。外装は濡れていましたが発熱・膨張なし。法務保全対象ではないこと、バックアップを確認し、封印して契約修理先へ渡しました。修理受付だけで完了せず、交換ストレージの扱い、修理後の暗号化・MDM再登録、顧客先での周辺被害を別々に確認しました。
ケースC：保管中タブレットのバッテリーが膨張
倉庫担当者は充電・圧迫・通常配送を止め、周囲を立入制限して施設安全担当へ連絡しました。写真撮影のために端末へ近づくことを優先せず、専門事業者の指示で処理しました。資産管理は端末番号、同一ロット、保管温度、充電履歴を確認し、同型機を予防点検へ回しました。
チェック13：終結前に四系統を照合する
一人の責任者が、端末、アクセス、データ、安全・業務の四系統を読み合わせます。
- •[ ] 端末の所在、回収、修理、廃棄または未回収判断がある
- •[ ] 回線、SSO、MFA、証明書、セッションが正しい状態である
- •[ ] データ影響、報告・通知判断、保全・消去記録がある
- •[ ] 人身・電池・施設事故の対応が必要部署で完了している
- •[ ] 代替端末、復元、業務権限の復旧が検査済みである
- •[ ] 外部引渡しと資産台帳が一致している
- •[ ] 未解決項目に責任者、期限、承認がある
- •[ ] 次回レビュー日と再発防止策を登録した
一項目でも根拠がなければclosedにせず、contained、monitoring、recovery、exceptionなど実態に合う状態を使います。管理職の口頭了解で未回収端末を完了へ移しません。
チェック14：品質指標でチェックリスト自体を改善する
件数だけでなく、手順が機能したかを測ります。
- •報告から受付までの中央値・90パーセンタイル
- •受付から高リスクアクセス停止判断までの時間
- •暗号化・MDM・利用者が不明だった端末の割合
- •queued・unreachableのまま期限超過した遠隔操作
- •外部引渡し証跡の欠落率
- •caseの再オープン率と理由
- •同種事故の再発率
- •訓練で連絡先・権限へ到達できた割合
速さを上げるために記録を省いていないか、記録を増やして封じ込めが遅れていないかを両方見ます。四半期ごとに代表caseを抽出し、受付から終結まで第三者が再現できるか監査します。
IPAの従業員の初動対応に関する実践例を参考に、自社で起こり得るシナリオと証拠保全を組み合わせて演習します。訓練は専用アカウントと模擬連絡先で行い、本番の消去・メール・顧客通知を発生させません。
まとめ：チェックの数ではなく、判断と証拠をつなぐ
紛失・故障対応のチェックリストは、項目へ印を付けるための帳票ではありません。事故前の管理状態、一次受付、四つの影響、遠隔操作、認証、個人データ、安全、外部引渡し、代替、再受入れ、終結をincident_idで結び、誰がいつ何を根拠に判断したかを再現するための仕組みです。
特に、遠隔ワイプの指示と成功、配送完了と個体受領、端末交換と事故終結を混同しないことが重要です。安全異常は人命を優先し、個人データは専門担当が最新基準で評価します。三つのケースを使って定期的に演習し、見つかった台帳・権限・連絡網の弱点を上流の配布・設定・教育へ戻すことで、次の事故を速く小さく処理できます。