従業員が退職したとき、
「メールアドレスは停止したが、他のシステムのアカウントまで確認できていない」
「担当者が使っていたSaaSが分からない」
「退職した社員のアカウントが社内システムに残り続けている」
といった状態になっていないでしょうか。
退職者アカウントの管理では、単純にメールアドレスを削除するだけでは不十分です。
実際には、
- Google WorkspaceやMicrosoft 365
- 社内システム
- 顧客管理システム
- 勤怠管理システム
- クラウドストレージ
- Slackなどのコミュニケーションツール
- GitHubなどの開発サービス
- 外部SaaS
- VPN
- APIキー
- 共有アカウント
- PCやスマートフォン
など、退職者がアクセスできる対象をまとめて確認する必要があります。
重要なのは、退職が発生するたびに担当者が思い出しながら対応するのではなく、
「退職日になったら、必要なアクセス権が確実に停止される」
仕組みを作ることです。
この記事では、退職者アカウントを放置しないための管理方法、退職時に確認すべき項目、権限剥奪のタイミング、SSO・ID管理による効率化、社内システムでの設計方法まで具体的に解説します。
退職者アカウントを放置すると何が問題なのか
退職者アカウントを残したままにすると、不要なアクセス経路が社内に残り続けます。
例えば、
退職
↓
Googleアカウントは停止
↓
しかし顧客管理システムは利用可能
↓
以前のログイン情報でアクセスできる
という状態です。
退職者本人によるアクセスだけが問題ではありません。
使用されていないアカウントの認証情報が第三者に取得されれば、不正アクセスに利用される可能性もあります。
また、アカウントが残り続けることで、
- 誰が現役社員なのか分からない
- ライセンス料金を払い続ける
- 権限状況を把握できない
- 監査時の確認に時間がかかる
- 情報管理ルールが形骸化する
といった運用上の問題も発生します。
そのため、退職者アカウント管理は「退職時の事務作業」ではなく、企業のアクセス権管理の一部として設計する必要があります。
退職者アカウント管理では「削除」より先に無効化を考える
退職時には、
「アカウントをすぐ削除すればよい」
と考えることがあります。
しかし、実際の業務では即時削除が適切とは限りません。
例えば退職者のアカウントに、
- 過去のメール
- 顧客とのやり取り
- 作成したファイル
- 担当案件
- 業務履歴
などが紐づいている可能性があります。
そのため一般的には、
退職
↓
ログインできない状態にする
↓
データや所有権を引き継ぐ
↓
必要な保存期間を確認する
↓
アカウントを削除
という順序を検討します。
「利用停止」と「データ削除」を分けて考えることがポイントです。
退職者アカウント管理の基本フロー
退職が決まったときの基本的な流れは、次のように整理できます。
- 退職者が利用しているシステムを確認する
- 退職日時を確定する
- 引き継ぐデータと権限を整理する
- 退職時にアカウントを無効化する
- 有効なセッションやトークンを失効させる
- システムごとの権限を削除する
- データ・ファイルの所有権を移行する
- 端末や認証情報を回収・無効化する
- 一定期間後に不要なアカウントを削除する
- 対応結果を記録する
重要なのは、これらを担当者の記憶だけに頼らないことです。
1．退職者が利用しているシステムを洗い出す
最初に確認するのは、
「その社員が何にアクセスできるのか」
です。
例えば営業担当者なら、
- Google Workspace
- Slack
- CRM
- 案件管理システム
- 経費精算システム
- 勤怠管理システム
- ファイル共有
- MAツール
- Web会議サービス
などを利用しているかもしれません。
エンジニアなら、さらに、
- GitHub
- AWS
- Azure
- Google Cloud
- Vercel
- サーバー
- VPN
- データベース
- CI/CD
- 監視サービス
などが加わることがあります。
SaaSが増えるほど退職処理は難しくなる
特に注意したいのが、会社全体で利用サービスを把握できていないケースです。
例えば社員が独自に、
無料トライアル
↓
自分の会社メールで登録
↓
そのまま業務利用
していると、情報システム担当者がその存在を把握できないことがあります。
退職者アカウント管理を改善するには、退職処理だけではなく、
「会社でどのシステムを利用しているのか」
というSaaS管理も必要になります。
2．退職日の「いつ」アクセスを止めるか決める
退職者アカウント管理では、日付だけでなく時刻も重要です。
例えば最終出社日が3月31日の場合、
3月31日 0:00
3月31日 12:00
3月31日 18:00
4月1日 0:00
では、アクセスできる時間が異なります。
そのため、
「退職日の業務終了時に停止」
など、会社としてルールを決めます。
有給休暇を消化する場合などは、
最終出社日
退職日
が異なる場合もあります。
どちらをアクセス停止日とするのか、業務上の必要性を確認して決めることが重要です。
3．アカウントを無効化する
退職者の利用を止めるときは、まずアカウントを無効化する方法があります。
例えば、
active = true
となっている社員を、
active = false
に変更するような考え方です。
社内システムであれば、
退職者
↓
アカウント無効
↓
ログイン不可
という状態にします。
この方法なら、過去のデータや担当履歴を残しながら、新しいログインを停止できます。
4．既存のログインセッションも終了させる
アカウントを無効化しても、すでにログイン済みの状態が残っている可能性があります。
例えば、
PC
↓
1週間前にログイン
↓
ブラウザにセッションが残っている
↓
退職後も画面を開ける
といった状況です。
そのため退職処理では、
アカウント停止
＋
既存セッションの無効化
まで考える必要があります。
システムによっては、
- セッション
- アクセストークン
- リフレッシュトークン
- ログイン済み端末
などが関係します。
自社でWebシステムを開発する場合も、
「ユーザーを無効化したら、その瞬間から利用できなくなるか」
を確認しておくことが重要です。
5．システムごとの権限を削除する
アカウントと権限は分けて考える必要があります。
例えば、
Google Workspace
→ 停止済み
CRM
→ アカウントが残っている
AWS
→ IAM権限が残っている
GitHub
→ Organizationに残っている
という状態では、アクセス権を完全に停止したことにはなりません。
退職者ごとに、
「何のアカウントを持っているか」
ではなく、
「何にアクセスできるか」
を確認することが重要です。
6．ファイルやデータの所有権を引き継ぐ
アカウントを削除する前に確認したいのが、業務データの所有権です。
例えば退職者が、
- 顧客資料
- 契約書
- スプレッドシート
- 営業資料
- プロジェクトファイル
- ソースコード
- ダッシュボード
などを所有している場合があります。
そのため、
退職者
↓
上司・後任者へデータ移行
↓
所有権変更
↓
アカウント削除
という順序を検討します。
先にアカウントを削除してしまうと、必要なデータへのアクセスや復旧に手間がかかる可能性があります。
7．メールの扱いを決める
退職者のメールアドレスについても運用ルールが必要です。
例えば、
担当者Aが退職
↓
顧客が担当者Aへメール
↓
誰にも届かない
という状態になると、業務上の問題が発生します。
そのため一定期間、
- 後任者へ転送する
- 共有メールへ転送する
- 自動返信で後任者を案内する
などを検討します。
ただし、個人のメールボックスを誰がどこまで閲覧するかについては、会社の規程や業務上の必要性も考慮する必要があります。
8．共有アカウントのパスワードを変更する
見落とされやすいのが共有アカウントです。
例えば、
admin@example.com
のような共通アカウントを複数社員で利用していた場合、退職者だけを無効化できません。
そのため退職時には、
- 共有アカウントの確認
- パスワード変更
- MFA再設定
- 利用者の見直し
などが必要になることがあります。
可能であれば、
全員で同じID・パスワードを使用する
運用そのものを減らし、個人アカウント＋権限管理へ移行した方が管理しやすくなります。
9．APIキーやアクセストークンも確認する
エンジニアやシステム管理者の退職では、通常のログインアカウント以外にも注意が必要です。
例えば、
- APIキー
- Personal Access Token
- SSHキー
- デプロイ用トークン
- データベース認証情報
- クラウドアクセスキー
- Webhook用シークレット
などです。
退職者が個人用に発行した認証情報が残っていると、アカウントを停止しても別経路からアクセスできる場合があります。
特に開発環境では、
「誰の認証情報でシステムが動いているか」
を確認しておくことが重要です。
理想は、個人ユーザーの認証情報を本番システムの処理へ使用しない設計です。
10．会社支給端末を回収・無効化する
退職時にはシステム側だけでなく、端末も確認します。
例えば、
- ノートPC
- スマートフォン
- タブレット
- セキュリティキー
- ICカード
などです。
端末に、
- ログインセッション
- ファイル
- Cookie
- VPN設定
- SSHキー
- 認証アプリ
などが保存されている可能性があります。
そのため、
アカウント
＋
権限
＋
認証情報
＋
端末
をまとめてオフボーディングの対象として考えます。
「削除漏れ」を防ぐには人事情報を起点にする
退職者アカウント管理でよくある問題は、
人事
↓
退職を把握
情報システム
↓
数日後に知らされる
各システム管理者
↓
さらに後から対応
という情報伝達の遅れです。
この問題を防ぐには、
「退職者が発生した」
という情報を起点に必要な処理が動く仕組みを作ります。
例えば、
人事システム
↓
退職日登録
↓
情シスへタスク作成
↓
各システムの停止処理
↓
完了確認
という業務フローです。
人数が多い組織では、可能な範囲で自動化することも検討できます。
SSOを導入すると退職者アカウント管理を集約しやすい
複数の社内システムを利用している会社では、SSO（Single Sign-On：シングルサインオン）やIdP（Identity Provider：認証基盤）を導入すると、アカウント管理を整理しやすくなります。
例えば、
社員
↓
会社の共通アカウント
↓
勤怠管理
↓
顧客管理
↓
案件管理
↓
社内Webシステム
という構成です。
退職時には認証基盤側でユーザーを無効化することで、連携しているシステムへのアクセスをまとめて制御しやすくなります。
ただし、
「SSOにしたから退職者管理は完了」
ではありません。
SSOに対応していないSaaS、共有アカウント、APIキー、ローカルアカウントなどは別途管理が必要です。
SCIMなどでアカウントの作成・無効化を連携する
SSOは主に「認証」を統一する仕組みです。
さらにアカウントの作成や無効化まで連携したい場合、対応サービスではSCIMなどを利用したプロビジョニングを検討できます。
例えば、
人事情報
↓
IdP
↓
SaaSへユーザー作成
退職
↓
IdPでユーザー無効化
↓
対象SaaSも無効化
という仕組みです。
これにより、管理者が複数の管理画面を開いて一件ずつアカウントを停止する作業を減らせる可能性があります。
ただし、利用するIdPやSaaSが対応しているか確認が必要です。
社内Webシステムでは「退職済み」をどう設計する？
自社で顧客管理システムや案件管理システムを開発している場合、社員テーブルから退職者を単純に削除してしまうと問題になることがあります。
例えば案件データに、
案件A
担当者：山田太郎
という情報が保存されていたとします。
山田さんが退職したからと社員データそのものを削除すると、過去案件の担当者を確認できなくなる可能性があります。
そのため、例えば社員データに、
- 在籍
- 休職
- 退職
などの状態を持たせる方法があります。
退職者データの例
- 社員ID：E00125
- 氏名：山田太郎
- ステータス：退職
- 退職日：2026-03-31
- ログイン可能：false
このようにすれば、
過去の担当履歴
→ 残る
新規案件への担当者設定
→ 不可
ログイン
→ 不可
という制御ができます。
退職者を選択肢から除外する
社内システムでは、ログインを停止するだけでは不十分な場合があります。
例えば案件登録画面の担当者選択欄に、
山田太郎（退職済み）
がずっと表示されていると、誤って新規案件の担当者として登録してしまう可能性があります。
そのため、
在籍社員
→ 担当者候補に表示
退職社員
→ 過去履歴では表示
→ 新規選択肢には表示しない
という設計が考えられます。
これは顧客管理、案件管理、人事管理、申請・承認システムなどで重要なポイントです。
退職者が承認者になっている場合も確認する
申請・承認システムでは、さらに注意が必要です。
例えば、
社員
↓
課長承認
↓
部長承認
というワークフローで、課長が退職したとします。
承認ルートを変更しないままだと、
申請
↓
退職者へ承認依頼
↓
ログインできない
↓
申請が止まる
という問題が発生します。
退職処理では、
- 承認者
- 担当者
- 管理者
- 通知先
- データ所有者
として登録されている箇所も確認します。
退職者アカウント管理は「入社・異動・退職」で設計する
退職だけを個別に管理するより、
入社
異動
退職
をまとめた「アカウントライフサイクル」として考える方が合理的です。
入社
必要なアカウントを作成
↓
部署に応じた権限を付与
異動
旧部署の権限を削除
↓
新部署の権限を追加
退職
ログイン停止
↓
全権限を削除
↓
データ引き継ぎ
↓
一定期間後にアカウント削除
この流れを標準化すると、権限の付けっぱなしも防ぎやすくなります。
権限は「最初に追加する」だけでなく定期的に棚卸しする
アカウント管理では退職者だけを確認すればよいわけではありません。
例えば社員が、
営業部
↓
管理部へ異動
したにもかかわらず、以前のCRMアクセス権が残っているケースがあります。
これを繰り返すと、在籍社員であっても不要な権限が蓄積します。
そのため、
- 半年ごと
- 四半期ごと
- 組織変更時
など、会社に合ったタイミングでアカウントと権限を棚卸しする方法があります。
【コピペ用】退職者アカウント管理チェックリスト
退職時の確認項目として、次のチェックリストを利用できます。
基本情報
- 退職者氏名：
- 所属部署：
- 最終出社日：
- 退職日：
- アクセス停止日時：
- 後任者：
- 対応担当者：
共通アカウント
- Google Workspace：
- Microsoft 365：
- SSO / IdP：
- メール：
- Slack / Teams：
- VPN：
業務システム
- 勤怠管理：
- 経費精算：
- 顧客管理：
- 案件管理：
- 会計システム：
- 人事システム：
- 社内ポータル：
- その他SaaS：
開発・インフラ
- GitHub / GitLab：
- AWS：
- Azure：
- Google Cloud：
- Vercelなどのホスティング：
- データベース：
- VPN：
- SSHキー：
- APIキー：
- Personal Access Token：
データ
- メール引き継ぎ：
- ファイル引き継ぎ：
- ドキュメント所有権：
- 顧客担当変更：
- 案件担当変更：
- 承認者変更：
共有認証情報
- 共有アカウント：
- 共通パスワード：
- MFA：
- APIキー：
- その他認証情報：
端末
- PC返却：
- スマートフォン返却：
- タブレット返却：
- セキュリティキー返却：
- ICカード返却：
最終確認
- アカウント無効化：
- セッション無効化：
- 権限削除：
- データ移行：
- ログ確認：
- 一定期間後の削除予定日：
- 対応完了記録：
退職者アカウント管理をExcelで行う場合の注意点
社員数が少なければ、最初はExcelやGoogleスプレッドシートでも管理できます。
例えば、
| 社員 | 退職日 | Slack | CRM | GitHub | 完了 | |
|---|---|---|---|---|---|---|
| 山田太郎 | 3/31 | 済 | 済 | 済 | 済 | 済 |
という管理です。
ただし社員数やシステム数が増えると、
- 更新漏れ
- 誰が対応したか分からない
- 最新版が分からない
- 対応期限を過ぎる
- SaaS追加時にチェック項目が更新されない
といった問題が発生しやすくなります。
一定規模になったら、ワークフローやID管理システムによる仕組み化を検討するとよいでしょう。
退職処理を業務システムで自動化する例
例えば社員管理システムに退職日を登録するとします。
退職日登録
↓
情報システム担当へ通知
↓
退職処理タスクを自動作成
↓
対象システム一覧を表示
↓
各担当者が処理
↓
未完了なら通知
↓
すべて完了するとクローズ
という業務フローを作ることができます。
さらにAPI連携できるサービスでは、
退職処理
↓
アカウント無効化
↓
結果を記録
まで自動化できる場合があります。
すべてを自動化する必要はありません。
重要なのは、
「何を自動化し、何を人が確認するか」
を整理することです。
退職者アカウント管理でよくある失敗
メールだけ停止して完了する
Microsoft 365やGoogle Workspaceを止めても、個別に作成したSaaSアカウントが残っている可能性があります。
利用システム全体を確認する必要があります。
アカウントを先に削除してしまう
必要なメールやファイル、担当履歴まで確認できなくなることがあります。
まずアクセスを停止し、データ移行後に削除する流れを検討します。
ログイン済みセッションを確認していない
新規ログインを停止しても、既存セッションが利用できる可能性があります。
セッションやトークンの扱いまで確認します。
共有アカウントを忘れる
個人アカウントを停止しても、退職者が共有パスワードを知っていればアクセスできる可能性があります。
共有アカウントの利用状況も確認しましょう。
APIキーを見落とす
特に開発者・管理者では、通常のアカウント以外の認証情報を持っていることがあります。
APIキーやSSHキーなども棚卸し対象です。
担当者・承認者を変更していない
ログイン停止だけ行い、案件や申請の担当者が退職者のままになっているケースがあります。
業務データ上の役割も後任者へ引き継ぎます。
対応した証拠が残っていない
「たぶん削除した」
という状態を避けるため、
- 誰が
- いつ
- どのシステムを
- どう処理したか
を記録できる仕組みを作ります。
退職者アカウント管理に関するよくある質問
退職者アカウントはすぐ削除するべきですか？
必ずしも即時削除が適切とは限りません。
まずログインやアクセスを停止し、メール・ファイル・担当データなどの引き継ぎを行った後、会社の保存ルールに従って削除する方法があります。
最終出社日と退職日のどちらで停止すればよいですか？
業務上いつまでアクセスが必要なのかを確認して決めます。
有給休暇の消化などで最終出社日と退職日が異なるケースもあるため、会社として「アクセス停止日時」を明確にすることが重要です。
アカウントを無効化すれば十分ですか？
対象システムによります。
既存セッション、APIキー、共有アカウント、端末など、アカウント以外のアクセス経路が残っていないか確認する必要があります。
退職者のデータは削除した方がよいですか？
業務履歴として残す必要がある情報と、不要になった個人情報を分けて考えます。
例えば過去案件の担当者履歴は必要でも、ログイン権限は不要です。
保存期間については、扱う情報や法令、契約、社内規程なども踏まえて判断します。
SSOを導入すれば退職者管理は自動化できますか？
SSOによって認証を集約すると管理しやすくなりますが、すべてが自動化されるわけではありません。
SaaS側のユーザー無効化、共有アカウント、APIキー、端末などは別途確認が必要です。
プロビジョニングに対応するサービスであれば、アカウント作成・無効化の自動化範囲を広げられる場合があります。
退職者アカウントを管理する専用システムは必要ですか？
社員数や利用システム数が少なければ、チェックリストでも運用できます。
一方、
- 社員の入退社が多い
- SaaSが多い
- 部署ごとに利用システムが違う
- 対応漏れが発生している
- 誰が処理したか記録したい
という場合は、ワークフローやID管理システムによる仕組み化を検討する価値があります。
hiro-dev-labではアカウント・権限管理の業務整理から相談できます
退職者アカウント管理の問題は、単純に「削除ボタンを押し忘れた」という問題ではありません。
根本には、
- 利用システムを把握できていない
- 人事と情報システム部門が連携していない
- 権限管理ルールがない
- 退職処理がチェックリスト化されていない
- SaaSごとに個別管理している
- 社内システムに退職者を扱う仕組みがない
といった業務設計の問題があることがあります。
hiro-dev-labでは、現在の運用を確認したうえで、
- As-Is（現在の退職処理）の整理
- To-Be（理想的な退職処理）の整理
- 利用システムの棚卸し
- アカウント管理フローの整理
- 権限設計
- SSOを含む認証設計
- 退職処理ワークフローの設計
- 管理画面・機能一覧の整理
- Webシステム開発
- APIによる業務自動化
などから相談できます。
例えば現在、
人事からメールで退職連絡
↓
情シス担当者がExcelを確認
↓
複数の管理画面へログイン
↓
手作業でアカウント削除
↓
完了したかどうかは担当者しか分からない
という状態なら、
退職者登録
↓
必要な処理を自動でタスク化
↓
対象システムごとに対応
↓
未対応を可視化
↓
完了履歴を保存
という仕組みに整理することもできます。
重要なのは、最初から大規模なID管理システムを導入することではありません。
現在どこで削除漏れや確認漏れが発生しているのかを整理し、必要な範囲から仕組み化することが重要です。
まとめ
退職者アカウント管理では、メールアドレスを停止するだけでは不十分です。
少なくとも、
- 利用しているシステムを洗い出す
- アクセス停止日時を決める
- アカウントを無効化する
- 既存セッションを失効させる
- システムごとの権限を削除する
- データ・所有権を引き継ぐ
- 共有アカウントを確認する
- APIキーなどの認証情報を確認する
- 端末を回収・無効化する
- 対応結果を記録する
という観点で整理するとよいでしょう。
そして最も重要なのは、退職が発生するたびに担当者が手作業で思い出す運用から脱却することです。
入社・異動・退職を一つのアカウントライフサイクルとして整理し、
人事情報
↓
アカウント
↓
システム
↓
権限
を連動させることで、退職者アカウントの放置を防ぎやすくなります。
社員数や利用サービスが増えてきた企業では、Excelによるチェックだけでなく、SSO、ID管理、ワークフロー、自動化などを組み合わせて、退職者のアクセス権を確実に停止できる仕組みを検討するとよいでしょう。