会社PC・業務スマホ紛失時の初動対応｜情報漏えい確認チェックリスト

冒頭要約

会社PCや業務スマホを紛失したときは、端末を探すことと、会社のデータ・アカウントを守ることを並行して進めます。紛失しただけで情報漏えいと断定はできませんが、端末内のファイルだけでなく、ログイン済みのメール、SaaS、クラウド、VPNへ第三者がアクセスできる可能性も確認が必要です。

最初に、端末名、利用者、紛失推定時刻、最終確認場所、MDM登録、暗号化、画面ロック、最終同期を記録します。そのうえで、リモートロック、端末アクセスの遮断、セッション失効、ログ保全を進め、選択的ワイプまたは全消去は影響を確認して判断します。

この記事は、利用者、情シス、SaaS管理者、開発者向けの実務ガイドです。「最初の15分」は着手する作業の目安で、15分探してから報告する、全項目がそろうまでロックや失効を待つという意味ではありません。

• 利用者：直ちに報告

  安全な別端末から正式窓口へ。最後に見た時刻と気付いた時刻、資産番号を分けて伝える。

• 情シス：端末を保護

  OS・登録方式と最終通信を確認。可能なロック・消去を承認し、受付と結果を区別する。

• 管理者：アクセスを止める

  IdPと重要SaaSのセッション・鍵を確認。端末の通信待ちとは別に封じ込めを進める。

OS・登録方式で違う、遠隔操作の確認ポイント

2026年10月20日の公式資料に基づく範囲です。管理対象なら全機種で同じ操作ができるとは限りません。画面に同名の操作があるかだけでなく、対象端末・登録方式・前提条件を確認します。

根拠はIntune Remote lock、Intuneの遠隔操作トラブルシュート、AppleのManaged Lost ModeとRemote wipe、Googleの紛失端末管理です。これらを自社の端末で動作確認したという表示ではありません。

---

会社PC・業務スマホの紛失をインシデントとして扱う理由

端末紛失で確認する対象は、物理端末だけではありません。実務では次の3つを分けて評価します。

確認対象	主なリスク	代表的な確認事項
端末内データ	ローカルファイル、メールキャッシュ、ダウンロード、認証情報の閲覧	ディスク暗号化、画面ロック、保存データ、ブラウザ保存情報
クラウドアクセス	ログイン済みセッション、トークン、VPN、SaaSへの継続アクセス	IdP、メール、ストレージ、GitHub、クラウド、VPNのセッション
端末管理経路	ロック、位置確認、ワイプ、準拠判定が届かない	MDM登録、最終同期、通信状態、遠隔操作の受付・完了状態

保存データの暗号化は端末内データのリスクを下げますが、ロック解除済みの状態、ブラウザのセッション、同期済みクラウドデータまで自動的に保護するものではありません。逆に、遠隔ワイプを実行しても、各SaaSが発行したセッションやトークンまで必ず失効するとは限りません。

そのため、端末側の対応とアカウント側の対応を別の作業として記録します。

---

読者別の影響：誰が何をするか

読者	最初にすること	見落としやすい点
利用者	安全な端末から社内へ報告し、端末情報と紛失状況を伝える	自分でMDM登録を削除する、会社アカウントへ何度もログインする
情シス・ヘルプデスク	資産台帳、MDM、暗号化、画面ロック、最終同期、端末準拠を確認する	遠隔コマンドが保留中なのに完了扱いする
CSIRT・セキュリティ担当	端末内データ、クラウドセッション、不審操作、報告要否を評価する	端末消去を急ぎ、時刻や管理ログを残さない
SaaS・IdP管理者	対象ユーザーのセッション、トークン、端末、MFA、監査ログを確認する	IdPの失効だけで各SaaSの独自セッションも終了したと考える
開発者・クラウド管理者	GitHub、クラウド、CI/CD、VPN、SSH鍵、開発用トークンを確認する	ローカル環境にだけ保存された秘密情報や管理者セッション

個人所有端末を業務利用している場合は、会社データと個人データの範囲を明確にします。端末全体の消去が可能とは限らず、仕事用プロファイルや管理対象アプリだけを削除する選択肢もあります。

---

まず確認すること：最初の15分チェックリスト

1. 紛失状況を記録する

• 紛失または盗難に気付いた時刻と、最後に端末を確認した時刻。
• 最後に確認した場所、移動経路、公共交通機関、施設、社外訪問先。
• 端末種別、資産管理番号、機種、OS、電話番号、会社名義か個人所有か。
• 電源・通信・バッテリーの推定状態、オフラインになる可能性。
• 置き忘れ、盗難、第三者が触れた形跡など、確認できた事実と推測の区別。

2. 端末の防御状態を確認する

• MDMまたはエンドポイント管理へ登録されているか。
• BitLocker、FileVault、端末暗号化などが有効だったか。
• 画面ロック、PIN、パスコード、生体認証、自動ロックが設定されていたか。
• MDMの最終チェックイン時刻、準拠状態、OSバージョン。
• ローカル管理者権限、共有アカウント、自動ログインの有無。

3. 端末内に何があったか確認する

• 顧客情報、個人情報、契約書、設計書、ソースコード、秘密情報を保存していたか。
• メールやクラウドストレージをオフライン利用できる状態だったか。
• ブラウザにパスワード、セッション、パスキー、クライアント証明書を保存していたか。
• VPN設定、SSH鍵、APIキー、個人アクセストークン、回復コードがあったか。
• 外部メディア、SDカード、USBストレージを装着していたか。

4. クラウド側のアクセスを確認する

• IdP、メール、主要SaaSの最近のサインインと端末情報。
• 紛失推定時刻以降のファイル閲覧、ダウンロード、共有、送信、権限変更。
• 見覚えのないMFA登録、パスキー、回復先、OAuthアプリ。
• GitHub、クラウド管理画面、VPN、CI/CDなど高影響サービスのセッション。
• 端末準拠や条件付きアクセスで遮断できる範囲。

5. 遠隔操作の状態を分けて記録する

状態	意味	次の行動
受付済み	管理画面から操作を送信した	受付時刻、実施者、対象端末、操作内容を記録する
保留中	オフラインで未受信、または実行結果がまだ報告されていない可能性がある	未実行・完了のどちらも断定せず、ログ・最終通信・追加の確認結果を照合する
完了	端末が操作を受信し、管理画面で完了を確認した	完了時刻と結果を保存し、セッション・ログ確認を続ける
失敗・非対応	機種、登録方式、通信状態などにより実行できない	代替策、SaaS遮断、通信回線停止、エスカレーションを検討する

Microsoftの公式情報では、オフライン端末へのRetireやWipeは保留になり、接続するまで実行されない場合があります。一方、リセット・管理解除前に端末が結果を報告できず、実行後もPending表示が残る場合もあります。Pendingは成功の証明でも未実行の証明でもありません。ボタンを押した事実、管理画面の表示、別の根拠で確認できた結果を分けて残し、証拠がなければ「未確認」とします。未確認のまま端末レコードを削除しません。

---

初動対応：安全に進める順番

手順1. 報告と証跡保全

1. 利用者は、別の信頼できる端末から社内の正式な連絡先へ報告する。
2. 情シスは資産台帳とMDMで対象端末を特定し、最終同期、暗号化、準拠状態を保存する。
3. 紛失推定時刻の前後を含め、IdP、SaaS、VPN、EDR、メールのログ保持期限を確認する。
4. 実施したロック、失効、ワイプ、回線停止などを時刻付きで1つのタイムラインへ記録する。

インシデント時の証拠保全を使うと、取得したログ、操作前後、未確認事項、引き渡し先を整理できます。

以下の手順番号は担当作業を整理するためで、すべてを直列で終えてから次へ進む指示ではありません。報告後はログ保全、端末保護、アカウント保護を担当者で分担します。

手順2. 端末をロックし、アクセス条件を厳しくする

• MDMの機能と端末の登録方式を確認し、対応していれば紛失モードまたはリモートロックを実行する。
• 端末を非準拠または無効として扱い、条件付きアクセスやVPNで新しい接続を止める。
• 画面に表示する連絡先は、個人の携帯番号ではなく、会社の代表窓口や回収用番号を検討する。
• 位置情報を扱う場合は、社内規程、プライバシー、警察・施設管理者との連携を確認し、利用者が単独で回収へ向かわない。

AppleのManaged Lost ModeやMicrosoft IntuneのLost Modeは、対応する管理・監視対象端末で遠隔ロックや位置確認を支援します。ただし、利用できる機能はOS、所有区分、登録方式、事前設定によって異なります。管理画面に操作が表示されるか、公式仕様と自社構成の両方を確認します。

手順3. セッションとトークンを失効する

• IdPで対象ユーザーのセッション失効を行い、必要に応じて端末オブジェクトを無効化する。
• メール、ストレージ、チャット、CRM、GitHub、クラウドなど、重要SaaSの独自セッションを確認する。
• アクセストークン、リフレッシュトークン、個人アクセストークン、アプリパスワード、SSH鍵を棚卸しする。
• パスワードやMFAを変更する場合は、本人確認、既存セッションの挙動、回復手段を確認する。

Microsoft Entra IDの公式ガイドでも、IdPが発行したトークンと、各アプリが独自に発行したセッションCookieは同じではないと説明されています。端末のRetireやパスワード変更だけで対応完了にせず、重要サービス側のセッションも確認します。

手順4. ロック・選択的ワイプ・全消去を選ぶ

選択肢	主な目的	適する状況	注意点
紛失モード・リモートロック	利用を止め、回収可能性を残す	端末が管理済みで、短時間に回収できる可能性がある	対応OS・登録方式に制約があり、オフラインでは届かない場合がある
仕事用アカウント・管理データの消去	個人データを残し、会社データを削除する	BYOD、仕事用プロファイル、管理対象アプリを利用している	管理対象外アプリ、ローカルコピー、SaaSセッションが残らないか確認する
端末全体のワイプ	端末上のデータと設定を広く消去する	回収可能性が低い、機密性が高い、盗難の可能性が高い	個人データ、証跡、位置確認、再利用手順への影響を承認者と確認する

「最も強い操作をすぐ実行する」ことが常に最適とは限りません。端末の所有区分、暗号化、ロック状態、回収可能性、保存データ、管理経路、法務・人事上の要件を確認し、誰が判断したかを記録します。

手順5. 影響確認と復旧

• 紛失推定時刻以降の不審なログイン、ダウンロード、共有、送信、権限変更を確認する。
• SIM/eSIMを利用する端末は、通信事業者への回線停止と、SMS認証への影響を確認する。
• 回収された端末は、利用者へすぐ戻さず、改ざん、構成変更、管理状態、ログを確認する。
• 代替端末では、本人確認後にMDM登録、暗号化、更新、MFA・パスキーの再登録を行う。
• インシデントの判定、未確認事項、再発防止、利用者への連絡を記録してクローズする。

回線停止と遠隔操作の関係：管理コマンドには通信が必要なため、モバイル回線を止めると届く経路が減る可能性があります。ただし、遠隔操作のために不正利用が疑われる回線を無条件で維持するという意味ではありません。回線・SMS認証のリスク、Wi-Fi等の別経路、コマンド状態を情シスと通信事業者へ共有し、並行してアカウントを保護します。この判断は編集部の運用整理です。

回収後、業務利用を再開する条件

発見した場所だけで安全とは判定しません。端末管理担当が、物理状態・構成・管理状態・更新状況と、紛失中のサービス利用を確認します。ワイプを送信済みなら、回収後の通信で遅れて実行され得ることも確認し、独断で起動・再ログインしないよう利用者へ伝えます。

• 遠隔コマンドの状態と今後の実行可能性を確認した。確認できない場合は未確認のまま管理担当へ引き継いだ。
• 暗号化・画面ロック・MDM登録・必要な更新を確認した。必要なら承認済み手順で再構築した。
• 漏えい疑いの鍵・トークン・セッションの対応と、再発行・回復手段を確認した。
• 紛失中に確認できたログの範囲と欠損を記録し、業務再開の承認者・残課題・次回確認日を決めた。

架空例：「端末は受付で回収／WipeはPending／SaaS独自セッションは未確認」なら、回収済みだけでクローズしません。管理担当がコマンド状態を照合し、SaaS管理者が独自セッションを確認するまで、端末の再利用と該当アクセスの再開を保留します。

---

やること・やらないこと・記録すること

やること

• 紛失に気付いた時刻と最後に端末を確認した時刻を分けて記録する。
• 端末側とアカウント側の封じ込めを並行する。
• 遠隔操作の「送信」「保留」「完了」「失敗」を分ける。
• 高権限アカウント、顧客・個人情報、秘密情報がある場合は早期にエスカレーションする。
• 回収後も端末の状態と紛失中のクラウド操作を確認する。

やらないこと

• 利用者が単独で端末の位置へ向かい、第三者から回収しようとしない。
• 管理画面の端末レコードやユーザーを先に削除しない。
• 遠隔ワイプを送信しただけで、情報漏えいリスクがなくなったと判断しない。
• 位置情報、個人情報、端末識別子を広いチャットやメールへ貼らない。
• 確認できていない被害、閲覧、ダウンロード、第三者利用を断定しない。

記録すること

• 端末、所有者、資産番号、OS、MDM登録方式、暗号化、画面ロック。
• 紛失推定時刻、報告時刻、最終同期、遠隔操作の送信・完了時刻。
• 保存されていた可能性があるデータ、認証情報、利用サービス。
• 失効したセッション、トークン、鍵、停止した回線。
• 確認したログ、期間、タイムゾーン、未確認事項、次回確認時刻。
• 判断者、承認者、CSIRT・法務・人事・管理者への連絡状況。

---

判断基準：いつ重大インシデントとして扱うか

優先度	条件	推奨対応
緊急	暗号化・画面ロックが無効、または解除された状態で盗難の可能性がある	端末とアカウントを同時に封じ込め、CSIRT・責任者へ即時報告する
緊急	管理者、経理、人事、IdP、クラウド、GitHubなど高権限セッションが残っている	全セッション・トークンを確認し、重要サービスの操作ログを保全する
高	顧客情報、個人情報、ソースコード、秘密鍵、APIキー、回復コードを保存していた	データ損失イベントとして影響範囲と外部報告要否を評価する
高	紛失後の不審サインイン、ダウンロード、共有、MFA変更、権限変更がある	アカウント侵害を含むインシデントへ切り替え、関連アカウントまで調査する
高	MDM未登録、最終同期が古い、遠隔操作が失敗・非対応・長時間保留	遠隔封じ込めへ依存せず、アカウント・回線・SaaS側の遮断を強化する
中	暗号化・ロック・MDMが有効で遠隔ロックも完了し、不審操作が確認されない	監視と記録を続け、回収・ワイプ・代替端末の判断を担当者が行う

暗号化やMDMが有効でも、ただちに「影響なし」にはしません。何を確認できたか、何が確認できないか、遠隔操作が完了したか、クラウド側に異常がないかを根拠として残します。

---

端末紛失の記録テンプレート

報告日時:
紛失・盗難に気付いた日時:
最後に端末を確認した日時・場所:
端末種別・資産番号・利用者:
会社所有／個人所有:
OS・機種・電話番号:
MDM登録方式・最終同期:
暗号化・画面ロック・端末準拠:
保存データ・利用サービス:
高権限アカウント・トークン・鍵:
紛失モード／ロックの送信・完了時刻:
選択的ワイプ／全消去の判断と承認者:
失効したセッション・トークン:
回線停止・SIM/eSIM対応:
確認したログと対象期間:
不審な操作の有無:
確認できていない事項:
CSIRT・法務・人事への連絡:
次回確認日時・担当者:

テンプレートには推測を書き込まず、「確認済み」「利用者申告」「管理画面で保留中」「未確認」のように情報の状態を添えます。

---

よくある誤解

「暗号化されていれば情報漏えいは起きない」

暗号化は、電源停止中やロックされた端末から保存データを読み出されるリスクを下げます。一方、ロック解除中、脆弱なパスコード、ログイン済みSaaS、メールのオフラインキャッシュなど、別の経路は残る可能性があります。

「端末をワイプすればセッションも全部消える」

端末上のデータ消去と、クラウドサービス側のセッション・トークン失効は別です。IdP、メール、SaaS、GitHub、クラウドなどで、対象端末と利用者のセッションを確認します。

「リモート操作を押したので対応は完了」

端末がオフラインなら保留になり、実行後も報告されずPending表示が残る場合があります。表示だけで完了・未実行を断定せず、管理ログや回収後の確認を照合します。端末消去の結果にかかわらず、クラウド側の残るアクセスは別に確認します。

「端末が見つかったら、そのまま業務へ戻してよい」

紛失中に第三者が触れた可能性、管理状態の変化、不審なサインイン、構成変更がないかを確認します。必要に応じて再プロビジョニング、パスワード・鍵の変更、ログレビューを行います。

「個人所有端末でも会社が端末全体を消去できる」

実際に可能な操作は、OS、仕事用プロファイル、管理方式、事前同意、組織のポリシーで異なります。個人データへの影響を含め、管理画面の表示と公式仕様を確認してから実施します。

---

関連用語・関連ページ

• MDMとは: 端末設定、アプリ、暗号化、準拠状態、紛失時操作を集中管理する仕組み。
• 端末準拠: 端末の暗号化、OS、管理状態などをアクセス判断へ使う考え方。
• セッション失効・トークン失効: 端末を消去するだけでは残りうるアクセスを止める対応。
• インシデント対応の基本: 検知、封じ込め、根絶、復旧、振り返りの流れを学ぶ。
• 漏えい疑い初動テンプレート: 顧客情報や秘密情報が端末にあった場合の報告・記録に使う。
• 退職者アカウント確認チェックリスト: 端末返却、SaaS、共有鍵、開発基盤を横断して確認する。
• SaaS権限棚卸しチェックリスト: 紛失端末から利用できたSaaSと権限を確認する。
• セッションハイジャックが疑われるときの初動対応: 不審なセッションやトークン利用がある場合の確認手順。
• パスキーとパスワードの違い: 端末紛失時の回復を含め、認証方式の違いを理解する。
• パスキーが使えない時の復旧手順: 保存先の回復、利用先の登録、既存セッションを分けて確認する。
• 端末紛失の関連用語をクイズで確認: MDM、準拠、失効、回復の判断を復習する。
• セキュリティニュース・実務解説一覧: 他の初動対応ガイドを探す。

---

公式情報・参考情報

公開資料の照合・本文更新日：2026年10月20日。製品条件の比較と編集部による運用判断例を区別しています。実端末の遠隔操作・位置取得・消去確認、個別の報告義務判断は行っていません。

• NIST SP 800-124 Rev. 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise - 組織支給・個人所有端末を含む、端末管理と保護のライフサイクル指針。
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - 検知、対応、復旧をサイバーリスク管理へ組み込むための指針。
• Microsoft Intune: Device actions - ロック、位置確認、Retire、Wipeなどの公式リファレンス。
• Microsoft Intune: Remote lock - 対応OSと前提条件。Windowsではこのアクションを利用できない。
• Microsoft Intune: Troubleshoot device actions - オフライン端末の保留状態とRetire後のトークンの扱いを説明する公式ガイド。
• Microsoft Entra ID: Revoke user access in an emergency - 緊急時のユーザー、端末、トークン、アプリセッションの失効手順。
• Apple Platform Security: Managed Lost Mode and remote wipe - 管理対象Apple端末の紛失モードと遠隔消去の仕様。
• Google Workspace: Remotely manage lost or stolen work devices - 紛失端末の確認、ロック、仕事用アカウント・端末データ消去の公式手順。

---

まとめ

会社PC・業務スマホの紛失対応では、端末を遠隔操作するだけでなく、端末内データ、クラウドセッション、管理経路の3つを分けて確認することが重要です。

気付いたら直ちに報告し、端末特定、防御状態の確認、可能な端末保護、セッション失効、ログ保全を並行します。ワイプは、所有区分、回収可能性、データ機密性、管理方式、証跡への影響を確認し、判断者と根拠を記録して実施してください。

報告には漏えい疑い初動テンプレートを使い、端末・アカウント・管理経路の確認範囲を添えてください。平時の備えとして「あとで読む」に保存すれば進捗ページから再開できます。サイトへの保存は会社への報告・ロック・消去を実行するものではありません。