「退職した社員のアカウントを削除し忘れていた」——そのことに気づいたのが半年後だった、というケースが中小企業では珍しくありません。退職者のメールアカウントが生きたまま放置され、社内ファイルサーバーにアクセスできる状態が続いていた、あるいはクラウドサービスに前の社員のIDでログインできてしまった、という話は、情報漏洩インシデントの報告書に繰り返し登場します。
IPA（情報処理推進機構）の調査によると、内部不正による情報漏洩の起点として「退職者・元従業員によるアクセス」が上位に挙がっており、その多くがアカウント削除漏れに起因しています。しかし中小企業では退職手続きが総務担当者の経験則に頼っていることが多く、担当者が変わるたびに対応品質がばらつきます。
この記事では、中小企業の情シス兼任担当者・経営者・士業事務所の所長を対象に、退職者アカウントの削除漏れを防ぐオフボーディング手順書の作り方を、具体的なステップ・比較表・チェックリストとともに解説します。一度整備しておけば、次の退職者が発生したときも担当者が変わっても、同じ品質で対応できる仕組みを構築できます。
退職者アカウント削除漏れが引き起こすリスクの実態
退職者のアカウントが残ったまま放置されることは、単なる「消し忘れ」ではなく、会社に深刻な損害をもたらす可能性があります。リスクは大きく3つに分類できます。
第一に、情報漏洩リスクです。 退職した社員が悪意を持ってアクセスする可能性は、一般に考えられているより高い数字です。特に、退職の背景に給与トラブルや人間関係の問題があった場合、元社員が顧客リストや見積書、設計データを持ち出すリスクが高まります。メールアカウントが有効なままであれば、外部からでもアクセスができてしまいます。
第二に、セキュリティホールとしての悪用リスクです。 使用されていないアカウントは、不正アクセスの足がかりにされやすい標的です。パスワードが変更されないまま放置されていると、フィッシングや辞書攻撃で突破される可能性があります。退職者のアカウントが外部から侵入した攻撃者に使われた場合、「正規のアカウント」として活動するため、検知が非常に困難になります。
第三に、コンプライアンス・法的リスクです。 士業事務所では顧客の個人情報・財務情報を大量に扱います。退職した職員のアカウントが有効なまま残っていた場合、個人情報保護法上の「安全管理措置」が取られていないと判断され、行政指導や監査での指摘対象になる可能性があります。2022年の個人情報保護法改正で漏洩時の報告義務が強化されており、体制不備が露見するリスクは以前より高くなっています。
Before（現状）: 退職のたびに担当者の記憶とメモで対応。削除漏れが3件発生しても気づかないまま1年が経過する。
After（改善後）: 手順書と確認チェックリストで体系的に対応。退職翌営業日までに全アカウントの削除確認が完了し、記録が残る。
このリスクを「自社には関係ない」と判断できる中小企業はほとんど存在しません。社員数が5名でも50名でも、使っているクラウドサービスやメールシステムがあれば、退職者アカウントの問題は発生します。
中小企業で削除漏れが起きる3つの構造的な原因
削除漏れが繰り返される背景には、担当者の怠慢ではなく、組織の構造的な問題があります。現場でよく見られるパターンを3つに整理します。
原因1: アカウントの全体像を誰も把握していない
中小企業では、部署ごとに使うクラウドサービスが異なり、営業はSalesforce、経理はfreee、全員でGoogleワークスペース、個別にはSlack、Zoom、GitHubなど、気づけば10種類以上のサービスを契約している、というケースが一般的です。これらすべてを「誰のIDが登録されているか」一覧で把握できている会社は少数です。退職手続きで「メールとPCは回収した」と終わってしまい、外部サービスのアカウントが残る原因になります。
原因2: 退職手続きの担当者と権限付与の担当者が異なる
退職手続きは総務・人事が担当し、システム権限の付与・削除は情シス兼任（あるいはIT担当）が担当するという分業が一般的です。しかし両者の間に情報連携のルールがなく、総務が「○月○日付で退職」と社内周知してもIT担当に正式な依頼が届かない、という状況が頻繁に起きます。メールでの周知を見落とした、伝言が途中で止まった、といったヒューマンエラーが削除漏れにつながります。
原因3: 確認を取る仕組みがない
「削除した」という行為に対して、「本当に削除されているか」を確認するフローが存在しないことも大きな問題です。担当者が削除操作をしたつもりでも、サービス側の仕様でアカウントが「無効化」にとどまっていた、削除申請の承認が必要だったがされていなかった、という技術的な見落としもあります。削除後のスクリーンショットや確認記録を残す習慣がなければ、後から問題が起きたときに追跡ができません。
この3つの原因に対応する手段が「オフボーディング手順書」です。手順書があれば、誰が担当しても同じ手順・同じ品質で対応できます。次のセクションから、具体的な作り方を解説します。
オフボーディング手順書の作り方ステップ
オフボーディング手順書は、A4用紙1枚で収まるシンプルなものから始めることをお勧めします。完璧を求めて作成が止まるより、80点の手順書を今週中に完成させる方が、セキュリティリスクの軽減に直結します。以下の3ステップで進めてください。
1. アカウント棚卸しリストの整備
手順書を作る前に、まず「自社でどのアカウントが存在するか」を洗い出します。これをアカウント棚卸しリストと呼びます。カテゴリ別に整理すると漏れが減ります。
・デバイス系: 会社支給PC・スマートフォン・タブレット・ICカード・物理鍵のロッカー鍵など
・メール・コミュニケーション: 社内メール（Exchange、Gmail Workspace等）・Slack・Microsoft Teams・Chatworkなど
・業務システム: 会計ソフト（freee、弥生等）・CRM（Salesforce、HubSpot等）・勤怠管理・人事システムなど
・クラウドストレージ: Google Drive・OneDrive・Dropbox・Box・社内NASの共有フォルダなど
・開発・IT系: GitHub・GitLab・AWS・Azure・GCP等のクラウドインフラなど（IT系企業の場合）
・外部サービス: 名刺管理アプリ・SNS公式アカウントの管理者権限・ECサイト管理画面など
このリストは「社員台帳」と紐づけて管理します。入社時に付与されたアカウント一覧を記録しておき、退職時にはその一覧を見ながら削除確認を進めます。Excelで十分です。列の例: サービス名 ／ ログインIDの形式（例: 社員番号@company.com）／ 削除操作の担当部署 ／ 削除方法（管理コンソールURL等）／ 削除確認の方法。
棚卸しで見落としやすいのが「共有アカウント」です。SNS公式アカウントやAmazonビジネスの管理者アカウントを退職した社員と共用していた場合、削除ではなくパスワード変更が必要です。退職後に当該社員がパスワードを知っている状態を放置するのは同様のリスクをはらんでいます。
2. 退職手続きフローの標準化
アカウント棚卸しリストができたら、次は退職が発生したときの手続きフローを定めます。退職が決まった時点から実際のアカウント削除完了まで、誰が・いつ・何をするかを明記します。
標準的なフロー例（退職日の2週間前から退職翌日まで）:
・退職確定時（2週間前まで）: 人事・総務がアカウント棚卸しリストを参照し、IT担当者に「退職予定通知書」をメールで送付。通知書には氏名・退職日・付与済みアカウント一覧を添付する
・退職1週間前: IT担当者が棚卸しリストに基づき、各サービスの削除作業スケジュールを立てる。サービスによっては退職日当日まで利用が必要なもの（メール・社内チャット）と即時停止可能なものを分類する
・退職日当日: 業務終了後に「即時削除」対象のアカウント（クラウドストレージ・外部サービス管理権限等）から削除を開始。デバイスの返却を確認する
・退職翌営業日: メールアカウントを削除または無効化（引継ぎ期間が必要な場合は上長が代理受信設定を完了させてから）。全アカウントの削除確認記録を手順書の確認シートに記入し、IT担当者のサイン（電子サインでも可）を得て完了とする
フローの重要なポイントは、「削除依頼の起点を人事・総務に固定すること」です。IT担当者が退職情報を自分で察知する体制は、伝達ミスの原因になります。退職が決まった段階で必ず人事・総務から正式な通知が来る仕組みを作ってください。
3. 削除確認記録の作成と保存
削除作業が完了したことを記録し、一定期間保存することも手順書の重要な要素です。記録がなければ、後日トラブルが起きたときに「削除した・していない」の水掛け論になります。
確認記録には最低限、以下の4点を含めます。
・退職者氏名・退職日・確認実施日
・削除したアカウント一覧（サービス名・削除実施日・削除確認方法）
・削除を確認した担当者名
・確認方法の記録（管理画面スクリーンショット、システムの操作ログ等）
記録の保存期間は最低1年を目安にしてください。万が一インシデントが発生したときに「いつ削除したか」を証明できる記録は、企業として責任を果たしたことの証明になります。士業事務所であれば、個人情報保護の安全管理措置として記録の存在を外部監査や顧客への説明に使えます。
対応すべきアカウント・権限の種類と削除優先度の比較
退職者アカウントといっても、削除の優先度と方法はサービスによって大きく異なります。以下の比較表を参考に、自社の棚卸しリストの「優先度」列を設定してください。
| サービス種別 | リスク度 | 削除優先度 | 削除方法の目安 | 注意点 |
|---|---|---|---|---|
| 社内メール（Gmail/Exchange） | 高 | 退職当日 | 管理コンソールからアカウント削除または無効化 | 引継ぎが必要な場合は転送設定を先に完了させる |
| クラウドストレージ（Drive/OneDrive） | 高 | 退職当日 | 管理者権限でアカウント削除、ファイルを別オーナーに移管 | ファイルが消えるので移管先を事前確認する |
| 業務チャット（Slack/Teams） | 中 | 退職翌営業日以内 | ワークスペース管理者がメンバーを削除・非アクティブ化 | 過去の会話履歴はチャンネルに残る仕様が多い |
| 会計・人事システム | 高 | 退職当日 | 管理者がユーザー削除またはアクセス権限剥奪 | 財務データへのアクセスが残ると情報漏洩リスクが高い |
| CRM（Salesforce等） | 高 | 退職当日 | ライセンス解除・ユーザー非アクティブ化 | 顧客情報を保有するため最優先で対応する |
| SNS公式アカウント管理権限 | 高 | 退職当日 | 管理者権限を剥奪、必要ならパスワード変更 | 共用アカウントはパスワード変更が対応策 |
| VPN・リモートアクセス | 高 | 退職当日 | 証明書失効・ユーザーアカウント削除 | 外部からのアクセス手段のため最高優先度で対応する |
| クラウドインフラ（AWS/Azure等） | 非常に高 | 退職当日（即時） | IAMユーザー削除またはアクセスキー無効化 | 悪用されると高額の課金被害が発生する可能性がある |
| 名刺管理アプリ | 中 | 退職後1週間以内 | アカウント削除または共有権限の解除 | 顧客の連絡先情報が含まれるため軽視できない |
| 物理的なアクセス手段（ICカード・鍵） | 高 | 退職当日（返却） | ICカードは失効処理、鍵は回収・シリンダー交換検討 | 返却忘れは物理的侵入リスクに直結する |
特にクラウドインフラ（AWS・Azure・GCP）は、管理者権限を持つ退職者が後からリソースを削除・大量にデータをダウンロードするなど、金銭的・情報的な被害が即座に発生する恐れがあります。エンジニアが在籍する企業は、退職日当日にIAMアクセスキーの無効化・削除を最優先で対応してください。
よくある質問
Q1. 退職者が自分でアカウントを使い続けることはできるのですか？
メールアドレスやパスワードを知っており、アカウントが有効な状態であれば技術的には可能です。アカウント削除前に自宅PCやスマートフォンで認証情報を保存していた場合、退職後でもサービスにアクセスできます。だからこそ、退職当日に削除・無効化するルールが重要です。「退職したのだからアクセスしないだろう」という性善説に依存することは、セキュリティ管理の放棄と同義です。
Q2. 小規模な士業事務所でも手順書は必要ですか？
必要です。むしろ規模が小さい事務所ほど担当者が少なく、退職時の引継ぎが属人的になりやすいため、手順書による標準化が有効です。税理士・社労士・行政書士事務所は顧客の個人情報・財務情報を扱うため、個人情報保護法上の「安全管理措置」の一環として、退職者アカウント管理手順の整備が求められます。手順書を作ること自体が、顧客への説明責任を果たすことにもなります。
Q3. アカウントを削除するとデータも消えてしまいますか？
サービスによって仕様が異なります。例えばGoogle Workspaceでは、ユーザーを削除すると当該ユーザーのGoogle Driveファイルも削除されます（管理者がデータ移管を行わない場合）。Microsoft 365でも、ライセンスを削除するとOneDriveのデータが一定期間後に消える場合があります。退職者のアカウントを削除する前に、業務上必要なファイル・メールを別のアカウントまたは共有フォルダに移管する作業を先に行ってください。棚卸しリストに「データ移管が必要か」の列を追加しておくと確認漏れを防げます。
Q4. 「無効化」と「削除」はどちらが推奨ですか？
セキュリティ観点では削除が推奨ですが、実務上は「無効化→一定期間後に削除」という2段階が現実的です。退職直後に削除すると、引継ぎで発覚した問題への対応や、送られてきたメールの確認ができなくなります。無効化（ログイン不可にする）で当面のリスクを封じ、1か月後を目安にデータ移管を確認してから完全削除する、という運用が多くの中小企業で採用されています。ただし「無効化のまま半永久的に残す」は厳禁です。削除期限を手順書に明記してください。
Q5. 退職者が「個人で使っていたサービス」と「会社で付与したサービス」の区別がつきません。どう対応すればよいですか？
入社時のオンボーディング手続きで、会社が付与するアカウントの一覧を本人に渡し、署名で受領確認を取る運用が最も確実です。事後的な対処としては、社内メールドメイン（@company.co.jp）で登録されているアカウントを各サービスの管理コンソールで検索する方法があります。プライベートのメールアドレスで登録された業務利用アカウントは発見が難しいため、入社時の整備が根本的な解決策です。
オフボーディング実施前の確認チェックリスト
以下のチェックリストを、退職手続きの際に人事・IT担当者が共同で確認してください。すべてにチェックが入った状態が「削除完了」の定義です。
・アカウント棚卸しリストを最新状態に更新したか: 退職者が使用していたすべてのサービスを洗い出し、リストに記載した
・データ移管が必要なサービスを特定し、移管を完了したか: Google Drive・OneDrive・メールアーカイブ等のファイルを業務継続に必要な範囲で移管済み
・VPN・リモートアクセス手段を退職当日に無効化したか: 外部からのアクセス手段が残っていないことを管理コンソールで確認した
・クラウドインフラ（AWS/Azure/GCP）のIAMアクセスキーを無効化・削除したか: 退職日当日に操作し、残存するアクセスキーがないことをユーザー一覧で確認した
・メール・チャット・業務システムのアカウントを無効化または削除したか: 管理コンソールでステータスを確認した（「無効」または「削除済み」であることを目視確認）
・SNS公式アカウント・外部サービスの管理者権限を剥奪またはパスワード変更したか: 共用アカウントについてはパスワードを変更し、退職者が知っていた認証情報を無効にした
・物理デバイス（PC・スマートフォン・ICカード）を回収したか: 返却チェックリストに受領者のサインを取得した
・削除確認記録を作成し、担当者のサインを得て保存したか: 確認実施日・削除したサービス一覧・確認方法（スクリーンショット等）を記録ファイルに保存した
・削除未完了のサービスがある場合、完了予定日と担当者を記録したか: 引継ぎ期間中のみ有効とするサービスは、期限と責任者を明示した
・1か月後の最終確認スケジュールを設定したか: 無効化にとどめたアカウントの完全削除期限をカレンダーに登録した
このチェックリストは、手順書に添付して毎回使用してください。退職のたびに新しいシートを用意し、完了後は保存します。記録が蓄積することで、「自社のどのサービスで対応漏れが起きやすいか」が見えてきます。年に1回、棚卸しリストそのものを見直す機会にも活用できます。
まとめ：今週中に着手できる最初の一歩
退職者アカウントの削除漏れは、「起きてから対処する問題」ではなく「仕組みで防ぐ問題」です。大がかりなシステム投資は必要ありません。必要なのは、アカウント棚卸しリストを1枚作ること、退職手続きの通知フローを人事・IT担当者の間で合意すること、そして確認チェックリストを印刷して手続きのたびに使うことです。
本記事で解説した内容を整理すると、以下の3点が核心です。
・アカウント棚卸しリストが出発点: 自社のすべてのサービス・アカウントを一覧にする。これがなければ削除漏れは防げない
・フローは「通知の起点」を固定する: 人事・総務からIT担当者への正式な通知ルートを決め、それ以外のルートに依存しない
・記録が事後の説明責任を支える: 削除確認記録を保存しておくことが、インシデント対応・監査・顧客説明の証拠になる
手順書は100点のものを目指す必要はありません。今ある状況でできる80点の手順書を今週中に作成し、次の退職者が発生したときに試してみてください。使いながら改善することで、半年後には自社の実情に合った本格的なオフボーディング体制が整います。
セキュリティポリシーの整備やアクセス権限管理でお困りの場合は、お気軽にご相談ください。中小企業の規模感・予算感に合わせた実務的なアドバイスを提供しています。
