退職者アカウントを見つけたら即削除?|人事データとの差分の振り分け方

公開日 : 

share :

人事部で退職者のチェックリストを作っていても、辞めた社員のアカウント(業務で使うツールにログインするためのIDなど)が、会社のどこかに残っていないとは言い切れません。チェックリストに載っていないところで、部門ごとに使い始めたツールがあるかもしれないからです。

退職した社員のアカウントが残っていないかを確かめるには、人事データと、メールや会計など、インターネット上で使う業務ツール(SaaS)のユーザー一覧を突き合わせ、人事データでは退職になっているのにSaaSに残っているアカウントを、差分として出す方法があります。ただ、見つけたアカウントをすぐ消してよいのか、消す前に何を確認するのかは、判断の基準がなければ決められません。

基準を考える手がかりになるのが、IPA(情報処理推進機構)の『中小企業の情報セキュリティ対策ガイドライン第4.0版』です。このガイドラインは、異動や退職のときに権限を見直すことと、誰にどの権限を付与しているかを管理することを求めています。

本記事では、人事データとユーザー一覧の差分を表計算ソフトで出す手順と、見つけたアカウントを停止・変更・移管後削除・保留の4つに振り分ける考え方を整理します。

【本記事の要点】

  • 退職チェックリストは、対象のSaaS一覧が古いと削除漏れが起きる
  • 人事データとユーザー一覧は、基準日時をそろえ、従業員IDを軸に差分を出す
  • 改姓・再雇用・外部委託・共有IDなどの誤検出は、自動で消さず人が確認する
  • 差分は停止・変更・移管後削除・保留に振り分け、担当・期限・証跡を記録する

退職チェックリストだけでは漏れる理由:SaaSアカウントの削除漏れ

退職チェックリストと部門ごとに分散したSaaSを突き合わせ、一覧にないサービスを確認する図解

退職チェックリストがあっても、なぜ削除漏れは起きるのでしょうか。この章では、チェックリストの対象が古くなる構造と、IPAのガイドラインが求めるID管理を整理します。

チェックリストの対象が古いと、削除漏れが起きる

退職チェックリストは、載っているツールのアカウントを順に削除・停止していく道具です。裏を返せば、チェックリストに載っていないものは、退職の手続きで一度も確認されません。次のようなものは、載りにくい代表例です。

  • 各部門が、会社の把握しないところで契約したSaaS
  • 共有フォルダ(ファイルを共有する保管場所)
  • 外部委託先に渡したアカウント

一覧が古いかどうかは、契約と請求から確かめられます。経理の支払い明細や請求書から、いま料金を払っているサービス名を拾い、チェックリストの対象と見比べてみましょう。

IPAの『中小企業のための実例で学ぶサイバーセキュリティリスク事例集』(2026年3月)は、外部から見える情報を診断した126社のうち101社で資格情報(ID・パスワードなど)の流出が検出されたとし、すぐできる対策に、使わなくなったアカウントの削除を挙げています。

IPAのガイドラインが求めるID管理

IPAの『中小企業の情報セキュリティ対策ガイドライン』第4.0版(2026年3月公開)は、IDの発行・変更・削除の手続を定め、必要最小限で割り当てるよう求めています。共有IDはなるべく避け、使う場合は利用者の特定が前提です。異動・退職にともなう権限変更や削除漏れを防ぐため、権限の見直しルールと付与状況の管理・監視も求めています。

IT資産については、一覧や台帳を作り、定期的な見直しを習慣にすることが示されています。つまり、IPAが示しているのは管理の目的と要件です。人事データとSaaSのユーザー一覧をCSVで突き合わせる方法、照合キー、実施の頻度は示されていません。

出典・参照:

人事データとユーザー一覧の差分の出し方:CSV突合の準備

人事データとSaaSのユーザー一覧を照合キーで突き合わせ、複数サービスの差分を抽出する図解

人事データとSaaSのユーザー一覧の差分を出すには、どのデータを、どの順でそろえればよいのでしょうか。この章では、基準日時、照合キー、対象とするサービス、個人情報の扱いを順に整理します。

基準日時をそろえる

人事データとSaaSのユーザー一覧は、同じ日時に抜き出します。抽出する時刻がずれると、入社・異動・退職の処理が途中の人が、正当な差分として表示されてしまうからです。

出力した日時は、ファイル名か記録表に残しましょう。原本のCSVは読み取り専用で保存し、加工は別のファイルで行います。原本を直接書き換えると、後から差分の根拠をたどれなくなります。

照合キーは従業員IDと補助キー

人事データとSaaSのユーザー一覧を結びつける軸(キー)は、従業員IDにします。メールアドレスだけで照合すると、改姓や別名アドレスで誤判定が起きるためです。

役割項目使い方
主キー従業員ID照合の軸にする
補助キー業務用のメールアドレス従業員IDが一覧にない場合の手がかりにする
併せて見る項目雇用区分、所属、契約終了日照合結果が正しいかを確かめる

CSVは、サービスごとに列名、文字コード、日時の形式が異なります。そのまま突き合わせることはできないため、次の手順でそろえます(この作業を正規化といいます)。

  1. 原本とは別のシートに、従業員ID、メールアドレス、状態(有効か停止か)、最終利用日の4列を作る
  2. 各サービスのCSVから該当する列をコピーし、すべてのサービスで同じ形に並べる
  3. 人事データで退職になっている従業員IDやメールアドレスを、VLOOKUPやXLOOKUPといった表計算ソフトの検索関数で、サービス側の表から探す
  4. 見つかり、かつ状態が有効のままの行を、退職者のアカウントが残っている候補として抜き出す

主要3サービスから差分を出す

最初から全サービスを対象にすると、取得だけで手が止まります。人事データと、全社員が使う主要な3サービス(たとえば、メール・グループウェア、会計や給与、顧客管理)から始めましょう。

管理者権限がないとユーザー一覧を出せないサービスもあるため、誰が一覧を出せるのかを先に確認しておくことが前提です。ユーザー一覧は、各サービスの管理画面にある、ユーザー(メンバー)を管理する画面から、CSVなどで書き出せるサービスが多くあります。書き出し方はサービスごとに違うため、ヘルプで「ユーザー一覧のエクスポート」にあたる項目を探すか、提供元に確認しましょう。

見つける差分は、次の4種類です。

差分の種類見つけ方
退職者の有効なID人事データでは退職になっているのに、SaaS側で有効なまま残っている
異動前の権限在籍者のSaaS権限が、いまの所属や役割より広い
在籍者に紐づかないIDSaaS側にあるが、人事データのどの従業員IDとも対応しない
過剰な管理者権限管理者権限を持つIDのうち、現在の役割に必要のないもの

ただし、この突き合わせで見つかるのは、ユーザー一覧を取り出したサービスのアカウントだけです。会社が契約を把握していないサービス(部門が独自に使い始めたツールなど。シャドーITとも呼ばれます)は、そもそも一覧を取り出せないため、アカウントが残っていても見つかりません。

そうしたサービスを見つける方法は、第1章「退職チェックリストだけでは漏れる理由」で詳しく説明しました。ここで手順だけ振り返ります。

  1. 経理の支払い明細や請求書から、会社が料金を払っているサービス名を拾い出す
  2. 拾い出したサービスを、退職チェックリストの対象と見比べ、載っていないものを見つける
  3. 載っていなかったサービスのユーザー一覧も取り出し、同じように人事データと突き合わせる

個人情報の扱い

人事データとユーザー一覧には、氏名、所属、雇用状態、メールアドレス、最終利用日といった、従業員の個人情報や行動の記録が含まれます。突合を始める前に、見る人、保存する場所、保存する期間を決めておきましょう。

表計算ソフトの代わりに、外部の無料の突合ツールへ実データを載せる場合は、ブラウザ内で処理するとうたうツールであっても、同じ3点を自社で確認してからにします。

観点自社の表計算ソフトで作業する場合外部の無料ツールを使う場合
見る人作業に必要な担当者だけに限る利用規約で、提供者がデータをどう扱うと定められているか
保存する場所全員が見られる共有フォルダには置かない通信で、データがどこへ送られるか
保存する期間作業が終わったら、決めた期間のあとに削除するデータがツール側に残るか、削除できるか

出典・参照:

誤検出しやすいID:改姓・再雇用・外部委託・共有IDの確認

改姓や外部委託、共有ID、botなどの候補を人が確認して自動削除を止める図解

人事データとユーザー一覧を突き合わせて、食い違いとして出てきたID(差分)は、すべて退職者の削除漏れなのでしょうか。実際には、退職者ではないのに差分に出てしまう、削除してはいけないIDが混ざります。これを誤検出といいます。

次の表は、誤検出が起きる代表的な原因を7種類に整理したものです。差分に出たIDがこの表のどれかに当てはまる場合は、削除せず、確認が必要なIDとして扱います。

種類誤検出の理由確認の方法
氏名の変更(改姓など)結婚などで氏名が変わり、氏名をもとにしたメールアドレスも変わると、人事データとSaaS側の登録が一致せず、別人に見える従業員IDと、旧姓・旧アドレスの記録で確認する
再雇用一度退職した人が戻ったため、古いIDと新しいIDの両方が残り、古いIDが退職者として差分に出る雇用区分と契約期間で、有効なIDを確定する
同姓同名氏名で照合すると、同じ名前の別人を退職者と取り違える従業員IDと所属で確認する
別名アドレス業務用のメールアドレスとは別のアドレス(別名)で登録されていて、人事データと一致しない別名の一覧を管理者に出してもらう
外部委託・派遣従業員ではないため人事データに載らず、在籍していても差分に出る委託契約と担当部門に確認する
共有ID複数人で使うため特定の個人に紐づかず、人事データに対応する従業員がいない利用者を特定できるか、管理者は誰かを確認する
サービスアカウント・bot連携やシステム運用のために、人の代わりに自動で動く仕組みが使うIDで、個人ではない作成者、用途、連携先を確認する

共有IDは、IPAのガイドラインもなるべく避けるよう求めています。使う場合は利用者を特定できる状態にしたうえで、差分に出たときは管理者への確認が前提です。サービスアカウントやbotを退職者と取り違えて止めると、連携していた業務が止まります。

差分は、見つけた時点では「確認が必要な候補」です。誤検出の可能性があるIDを、突合の結果だけで自動削除する運用は避け、人が確認してから処理します。次の章で、確認した後の処理を4つに分けます。

出典・参照:

差分の振り分け:「停止・変更・移管後削除・保留」の4区分

確認済みのアカウント差分を停止、権限変更、データ移管後の削除、保留へ振り分ける図解

見つけたアカウントは、すぐ削除してよいのでしょうか。この章では、差分を4つの区分に振り分ける考え方と、確認する内容、記録する項目を整理します。

停止と削除は別の処理

退職者のアクセスを遮断する作業は、早く進めるべきです。ただし、サインインの停止、セッションの失効(ログイン中の状態を終わらせること)、権限の剥奪は「停止」であり、データを移した後に行うアカウントの完全な「削除」とは、別の処理として考えます。

次の表は、差分を4つの区分に振り分けたものです。

区分当てはまる差分処理確認すること
停止確認できた退職者の有効なIDサインインの停止、セッションの失効、権限の剥奪退職日、本人のIDであること
変更異動前の権限が残る在籍者、過剰な管理者権限現在の役割に合わせた権限への付け替え異動後の所属、役割、権限の承認者
移管後削除停止済みで、データの移管と保全の確認が済んだIDデータを移した後の完全な削除移管先、保全の要否、期限
保留誤検出の疑いがあるID、共有ID、bot、外部委託のID削除せず、担当者が確定するまで置く持ち主、用途、再判定の期限

退職者のIDは、まず停止から始めます。データの移管や保全が済んだものだけが、移管後削除の対象です。判断がつかないIDは、削除せず保留にし、期限を決めて再判定します。

データ移管・保全の確認と、期限付きの保持

削除の前に、アカウントの中にあるデータの扱いを決めましょう。例として、Microsoft 365の公式文書が案内している内容を整理します。

対象公式文書の案内
メール残したい場合は、アカウントを削除する前に別の場所へ移す
OneDriveのデータ残したい場合は、別の場所へ移す
削除後の復元削除後の一定期間は、アカウントを復元できる
メールの保持Enterpriseと呼ばれる法人向けの契約(Office 365 Enterprise E3など)では、削除したユーザーのメールの内容を「非アクティブメールボックス」として保持できる
転送設定や共有メールボックスにしたアカウントその機能にアカウントが必要なため、削除しない

出典・参照:

保持の方法や期間は、製品と契約によって異なるため、自社の契約での扱いを削除の前に確認しましょう。確認の観点は、次のとおりです。

  • メールの引き継ぎ先と、転送や共有メールボックスの設定
  • 顧客や契約に関わるデータ、ファイルの所有者
  • 自動化の仕組みなど、そのIDで動いている連携
  • 監査ログ(操作の履歴)の保存と、法令や調査のためにデータを消さずに残す必要があるか

削除の時期については、個人情報保護委員会のFAQ(Q9-22)が、退職者の個人情報も、取得時に特定した利用目的の範囲であれば利用できるとしています。一方で、利用目的が達成され、利用する必要がなくなったときは、消去の請求に応じる義務があると考えられるとも説明しています。

つまり、削除を急ぐ必要がない一方、無期限に残し続けることも適切ではないのです。停止し、移管や保全の要否を判断し、期限を決めて保持してから削除する。この順序で進めます。保持の期間は、契約、業務の事情、法令によって異なるため、全社共通の数字は置かず、自社で決めた期間を記録に残しましょう。

記録に残す項目

処理の記録を残しておけば、後から「なぜ消したのか、なぜ残したのか」を説明できます。記録表には、次の項目を持たせます。

項目内容
基準日時人事データとユーザー一覧を取得した日時
従業員ID照合に使った従業員ID(氏名は記録表に持たせず、IDで管理する)
SaaS名とアカウント対象のサービス名と、アカウントのID
差分の種類退職者の有効ID、異動前の権限など
処理区分停止、変更、移管後削除、保留
判断の理由誤検出の確認結果、例外にした理由
担当者と期限処理する人と、完了させる期限
完了日と証跡処理した日と、画面の保存などの証跡の置き場所

出典・参照:

まとめ:差分は消す前に4つへ振り分け、記録を残す

退職者のアカウントを探すとき、まず見直すのは、退職チェックリストそのものです。リストに載っていないサービスのアカウントは、退職の手続きで一度も確認されません。経理の支払い明細から使っているサービスを拾い、人事データとユーザー一覧を突き合わせれば、リストの外にあるアカウントにも気づけます。

ただし、差分に出たアカウントが、すべて消してよいアカウントとは限りません。改姓や再雇用、外部委託、共有IDなどは、退職者ではないのに差分に出ることがあるからです。そのため、見つけたアカウントは、停止・変更・移管後削除・保留の4つに分け、誰がいつまでに何をしたかを記録に残します。

退職者のアクセスはすぐ止め、削除はデータの移管と保全を確かめてから行う。この順序を決めておけば、情報を守りながら、業務に必要なデータも失わずに済みます。

手作業での確認が追いつかなくなったときは、SSOなどによる自動化を検討します(自動化の進め方は、別の記事で扱います)。

まずは、人事データと主要3サービスのユーザー一覧を、同じ日に取り出してみてはいかがでしょうか。出てきた差分を4つの区分に振り分けるところまで、手元の表計算ソフトで試してみましょう。

山田 元樹

執筆者

株式会社MU 代表取締役社長

山田 元樹

社名である「MU」の由来は、「Minority(少数)」+「United(団結)」という意味。企業のDX推進・支援を過去のエンジニア経験を活かし、エンジニア + 経営視点で行う。DX推進の観点も含め上場企業をはじめ多数実績を持つ。