>
>
公開日
退職者のアカウント削除は、IdPの停止だけで完了と判断せず、各SaaSに残る利用経路まで確かめます。退職者リストとの突合、ローカルアカウントや個人メール登録の扱い、所有データとAPIトークンの引き継ぎ、証拠保全を踏まえた無効化・削除の判断、毎月の再確認までを情シス担当者向けに解説します。
退職者のアカウント削除とは
本記事では、退職者のアカウント削除を、IdPの停止後に各SaaSの利用経路を確かめ、無効化または削除まで判断する作業として扱います。対象は、企業の情報システム部門（情シス）の担当者・管理者です。IdP（Identity Provider）は利用者を認証し、その結果を各SaaSに渡す仕組みです。退職者アカウントの無効化を依頼した記録だけでなく、各サービスの状態を照合し、削除漏れを判定するところまでを対象にします。
本記事のポイント
IdPの停止結果と各SaaSの状態は分けて判定します。
退職者リストとSaaSのアカウント一覧を突き合わせます。
所有データ・連携と証拠保全を整理してから削除を判断します。
情報は2026年10月22日時点です。出典を付した事実以外の照合方法・判定基準は編集部の提案です。
完了判断では、IdPの処理成功だけを理由に対応を終了しません。各SaaSの利用経路を確認でき、無効化または削除の結果を記録できた場合に完了とします。状態を確認できないサービスがあれば「未確認」として残し、担当者と再確認日を決めます。所有データや連携、証拠保全の扱いが決まっていなければ、削除の判断は保留し、利用停止の確認と切り分けます。
対象範囲を絞るため、入退社の全体手順は入退社フローテンプレート、SaaS棚卸し全体はSaaS棚卸しの手順、IDaaSの基礎はIDaaSの解説をご参照ください。ここからは、IdPの停止結果と各SaaSの実際の状態を分けて整理します。
IdPで止めても残るアカウント
内閣官房国家サイバー統括室は2026年10月9日の「不正アクセスによる漏えい等の事案を踏まえた対応について」で、退職者・異動者や利用されていない不要なアカウントを速やかに無効化するよう求めています（推奨）。同日公開のIPAの注意喚起も、利用中の外部サービスごとに、削除・無効化されているはずのアカウントが有効化されていないかを確認するよう求めています（推奨）。
IdPで停止した退職者も、各SaaSのアカウント状態とIdP以外の利用経路を分けて確認します。退職者のアカウント削除・停止を確認する際は、認証経路が止まったかとSaaS側のアカウントが無効になったかを別の確認項目として扱います。
確認対象 | IdP側の結果だけでは確定しない事項 | SaaS側で参照する情報 | 判定後の対応 |
|---|---|---|---|
SAML・SCIM非対応 | アカウントの無効化状況と利用できる認証経路 | ユーザー一覧、アカウント状態、認証設定 | 有効ならSaaS側で停止処理を行い、状態が不明なら未解決にします。 |
ローカル認証 | IdPを介さない認証の許可状況 | 認証方式の設定、対象ユーザーへの適用範囲、停止記録 | 別経路が許可されていれば停止対象とし、遮断を確認できなければ未解決にします。 |
個人メール登録 | 退職者本人との対応関係、業務利用の有無、アカウント状態 | 登録メール、ユーザー識別情報、組織への所属情報、利用記録 | 本人との対応と業務利用が確認できれば停止対象とし、特定できなければ未解決にします。 |
SAML・SCIM非対応のSaaS
SAML・SCIM非対応のSaaSは、IdP側の結果とは別に、SaaS側の管理情報で停止状況を判定します。SAMLは認証連携、SCIMはアカウントの作成・更新・無効化などの管理連携に使う仕組みです。
両者は役割が異なるため、対応の有無だけで停止結果を決めません。対応している場合も、対象アカウントが連携範囲に含まれるか、処理結果とSaaS側の状態が一致するかを照合します。連携処理の成功表示だけで完了にせず、SaaS側で無効状態を確認できなければ未解決に残します。
IdPで止めても安心できない理由は、仕様にも書かれています。Microsoft Entra IDの公式ドキュメントは、アプリが独自に発行したセッショントークンはEntra ID側から直接失効できず、アプリ側で失効させる必要があると説明しています。自動プロビジョニングに対応していないアプリについては、手動でアカウントを停止する手順を用意するよう勧めています。SCIMの仕様（RFC 7643）も、ユーザーの有効・無効を示すactive属性の最終的な意味はサービス提供者が決めるとしています。
ローカルアカウント
ローカルアカウントでは、SaaS独自のID・パスワードなど、IdPを介さない認証が許可されているかを切り分けます。会社メールで登録されていても、それだけでIdP経由の利用に限定されているとは判断しません。
管理者が参照できる認証設定と対象ユーザーの状態を照合し、設定がそのユーザーにも適用されているかを見ます。設定画面の表示は構成を把握する材料であり、実際の利用可否を試した結果とは別です。ログイン済みのセッションがIdPの停止後も残る場合があるため（前節）、SaaS側でセッションを無効にできるかも確認し、不明な経路は未解決として残します。
個人メールで作ったアカウント
個人メールで作ったアカウントは、利用可否より先に、退職者本人と業務利用との対応関係を確定させます。個人メール登録だから必ずログインできるとも、会社のIdP停止と無関係とも断定しません。
管理者権限で取得できる登録情報や組織への所属情報、利用記録を照合材料にします。表示名だけが一致する場合は本人と決めつけず、対応関係が不明な対象として担当部署へ引き継ぎます。業務利用の対象と確認できたものは、SaaS側の状態と認証経路を同じ基準で判定します。
完了扱いにするのは、SaaS側で無効状態を確認でき、IdP以外の利用経路も整理できた対象です。アカウント状態または本人との対応関係が不明なら、未解決に分けて不足情報と担当者を記録します。退職者の認証情報を使った代理ログインは確認方法にせず、管理者権限で取得した情報を判定の根拠として残します。
▲ IdPの認証停止後もSaaS側にアカウントや独立した認証経路が残る構造
退職者リストと各SaaSのアカウント一覧を突き合わせる手順
退職者リストを基準に各SaaSのアカウント一覧を照合し、残存と未解決を分けて処理します。対象は既に把握しているSaaSに限定し、退職者本人との対応関係と、アカウントの利用可否を別々に判定します。会社メールが一致しないアカウントや、取得範囲が足りず見つからないアカウントを、対応完了に含めない運用にします。
退職者の対象期間と識別情報の確定
照合に着手する時点で、対象とする退職日の期間を決め、人事側で確定した退職者リストを用意します。社員番号などの退職者識別子、退職日、氏名、会社メール、所属部門を基準情報として整理します。過去の会社メールや別名が記録されている場合は、現在のメールとは分けて照合候補に加えます。氏名は検索の補助に使い、氏名だけの一致では削除対象を確定しません。
各SaaSの一覧取得
管理画面からアカウント一覧を出力できるなら、そのデータを使って照合します。出力できなければ、管理画面で退職者ごとに対象を検索し、表示された識別子・登録メール・状態を記録します。どちらの場合も、照会した組織・ワークスペース、検索条件、取得日時を作業記録に残します。有効なユーザーだけを表示している場合は、停止済みなどの状態も含めて確認できる範囲に切り替えます。取得できない項目は推測で埋めず、未確認として扱います。
本人との対応付け
会社メールが一致する場合は、退職者リストの識別情報と矛盾がないかを照合し、対応するSaaS側のユーザー識別子を記録します。メールが一致しても所属などに食い違いがあれば、本人確定を保留します。別名や個人メールで登録されている場合は、利用申請の記録や管理者・所属部門が保有する情報で対応関係を確かめます。対応を裏付けられれば同じ退職者にひも付け、確定できなければ「未解決：本人未確定」とします。候補が複数ある場合も、氏名から選んで削除せず、候補と不一致の内容を管理者・所属部門へ引き継ぎます。
有効状態と権限の判定
本人との対応が確定したアカウントは、有効・無効・削除済みなどの表示に加え、利用可否と付与権限を照合します。退職後も利用可能と判断できるものは「残存」、利用停止を確認できたものは「停止済み」と記録します。権限が残っている場合は、判定欄にその内容も追記します。状態の表示だけでは利用可否を判断できない場合は「未解決：状態未確認」とし、SaaS管理者へ判断に必要な情報を引き継ぎます。
対応後の再取得・再判定
残存アカウントへの停止・削除対応後は、一覧を再取得します。出力できない場合は管理画面を再表示し、対象のユーザー識別子を使って状態を再照合します。操作した事実と、操作後に確認できた状態は分けて記録します。停止を確認できれば「停止済み」、削除の実施記録と対象との対応を確認できれば「削除済み」とし、期待した状態になっていなければ対応を継続します。確認日時は再判定した時刻に更新します。
「一覧に見当たらない」と「削除済み」は同じ判定にしません。不在を判定材料にできるのは、照会した組織・ワークスペース・取得範囲に対象アカウントが含まれると判断できる場合です。その場合も、削除の裏付けがなければ「対象範囲内で不在」と記録し、削除済みと区別します。別のワークスペースや表示対象外の状態が未照会なら、「未解決：取得範囲不足」として対象範囲を補い、再照合します。
照合結果は、退職者とSaaSアカウントの組み合わせごとに下表へ記入します。同じ退職者に複数のアカウントが対応する場合は行を分け、別名や個人メールのアカウントも個別に追跡します。空欄は記入用です。
退職者識別子 | 退職日 | SaaS名 | SaaS側のユーザー識別子 | 登録メール | アカウント状態 | 確認日時 | 判定 | 担当者 |
|---|---|---|---|---|---|---|---|---|
判定欄には、残存・停止済み・削除済み・対象範囲内で不在・未解決を記入し、未解決には理由を添えます。別の作業記録に照合根拠、取得範囲、次の対応を残せば、担当者が交代しても判断を追えます。未解決の行には引き継ぎ先と回答期限を設定し、回答が得られた時点で本人との対応付け、または一覧取得から再開します。
▲ 退職者リストと各SaaSのアカウント一覧を突き合わせて判定する手順
所有データとAPIトークン・連携の引き継ぎ
本人のアクセス停止を維持したまま、所有データとAPIトークン・連携の引き継ぎを進めます。退職者のアカウント削除では、本人が利用できないことと、後任が業務を継続できることを別の完了条件にします。
所有データの移管
所有データは、所有者と後任の管理権限を整理し、管理者による移管が可能なら移管後に後任が参照できることまで確かめます。
引き継ぎ対象がある場合は、ファイルやフォルダーなどの対象物、現在の所有者、後任、必要な操作権限を一覧にまとめます。後任に閲覧権限があるだけで管理操作ができない場合は、業務に必要な権限を分けて設定します。移管後は後任のアカウントで対象を開き、更新や共有設定の変更など、担当業務に必要な操作を試します。
移管方法が未確定なら、本人のアクセス停止を維持したまま、対象データの保持を管理者側で検討します。データを残す判断と、退職者アカウントを削除する判断は分離します。保持する場合は、管理責任者と保持理由、削除を判断する時期を記録し、移管の方法が決まらないことを理由に、本人のアカウントを再び有効にはしません。
APIトークンの整理
APIトークンは必要な処理の継続可否で整理し、必要なら管理主体を切り替え、不要なら失効させて連携を解除します。
APIトークンとは、サービス間の処理などで使う認証情報です。人が画面からログインするための権限とは分けて、発行元、利用する処理、管理責任者を整理します。本人用トークンを残すことは、引き継ぎの代わりになりません。JPCERT/CCは10月8日の注意喚起で、APIトークンには必要最小限の権限だけを付与し、適切な有効期限を設けること、不要になったトークンや漏えいが疑われるトークンを速やかに無効化できるようにすることを挙げています（推奨）。
継続する処理があるなら、サービスで認められる方法に従い、後任または適切な管理主体の認証情報へ切り替えます。切り替え後に予定した処理の実行と結果を確かめ、旧トークンの失効までを完了条件にします。
外部連携と共有リンクの整理
外部連携と共有リンクは、引き継ぎ先だけでなく、退職者や私用アドレスに利用経路を残さないかも確認して整理します。
退職前に業務データの共有リンクを私用のメールアドレスへ送っておけば、アカウントを止めた後もデータを取得できてしまいます。退職者が作成した共有リンクと、私用アドレスを含む共有先は、アカウントの停止とは別に洗い出します。
共有先や公開範囲を見直して業務を継続できるなら、必要な相手だけが利用できる設定へ切り替えます。既存リンクの利用者を限定できない場合は、そのリンクを無効化し、必要な共有先へ新しい経路を案内します。作業時は、次の表に引き継ぎ先と確認結果を記録すると、未完了の対象を区別できます。
対象物 | 引き継ぎ先 | 切り替え後の確認 | 不要な場合の処置 |
|---|---|---|---|
所有データ | 後任・管理責任者 | 参照と必要な管理操作 | 保持要否を判断して削除 |
APIトークン | 後任・適切な管理主体 | 処理結果と旧トークンの失効 | 失効・連携解除 |
外部サービス連携 | 業務の管理責任者 | 接続先・権限・処理結果 | 接続を解除 |
共有リンク | 後任・必要な共有先 | 許可した相手の利用可否 | リンクを無効化 |
削除と無効化のどちらにするか
侵害調査やデータ保全が必要な場合は、本人の利用を止めたうえで、削除より先に保全対象を整理します。退職者のアカウント削除は、削除件数ではなく、本人が利用できないこと、必要な業務データを引き継げること、調査に必要な記録を残せることを完了条件にします。
無効化とは、アカウントを残したまま本人の利用を停止する処理です。削除とは、アカウント自体を取り除く処理を指します。ただし、無効化による停止範囲、データやログの保持範囲、削除後の復元可否、連携への影響は、全SaaSで共通ではありません。名称だけで判断せず、対象サービスの管理画面と公式仕様を判断材料にします。
個人情報保護委員会のガイドライン（通則編）10-6が現行で「講じなければならない措置」とする技術的安全管理措置は、（1）アクセス制御、（2）アクセス者の識別と認証、（3）外部からの不正アクセス等の防止、（4）情報システムの使用に伴う漏えい等の防止の4つです。同委員会は2026年10月7日の注意喚起の別紙で、「手法の例示」の見直し予定内容を先取りして示しました（確定は2027年4月の予定）。そこでは、人事異動や退職など組織体制の変更時にアクセス権限を適切に変更すること、定期的な監査などでアクセス権限を棚卸しすることが例示されています。いずれも見直し予定の手法の例示で、アカウントの即時削除を求めるものではありません。
比較軸 | 無効化 | 削除 |
|---|---|---|
判断する目的 | 本人の利用を止め、保全や移管の判断に必要な時間を確保します。 | 調査・業務・保持の条件を満たしたアカウントを整理します。 |
データ・ログへの影響を調べる箇所 | 管理画面と公式仕様で、停止範囲、保持対象、ログの閲覧・出力機能を調べます。 | 削除仕様で、消去対象、残る記録、復元可否、関連データの扱いを調べます。 |
業務への注意点 | 所有データや連携処理の継続可否を調べ、影響があれば移管まで停止状態を維持します。 | 共有データや連携への影響を整理し、後任者の業務に支障がない状態で実行します。 |
処理を進める条件 | 保全・移管が未完了なら、本人の利用を止める手段として選びます。 | 調査上の留保がなく、移管と組織の保持条件を満たした場合に進めます。 |
復元できることを前提には削除しません。削除後に必要なデータや記録を参照できる根拠が揃わない場合は、無効化などで利用停止を維持し、削除を留保します。保留時には担当者と再判断の条件を記録します。記入例は「担当：SaaS管理者、再判断日：保留開始から30日後、エスカレーション先：調査案件は情シス責任者と法務、例外承認者：情報セキュリティ責任者」です。ログやデータの保持期間は自社の文書管理規程に定めた年数に合わせ、規程にない場合は法務に確認してから設定します。こうして、停止したまま管理対象から外れる状態を防ぎます。
利用停止から削除までの判断フロー
不審な利用の有無で処理を分岐させ、調査対象でなければ移管と保持条件を満たした段階で削除工程へ進みます。
本人の利用を停止します。不審な利用や調査案件があれば、利用停止と調査担当への引き継ぎを優先します。通常の退職処理とは分け、削除の判断者を明確にします。
保全対象を整理します。調査担当と必要なログ、アカウント識別情報、共有設定を特定します。取得・保持できる対象を管理機能と公式仕様で照合し、保全後に削除可否を判断します。
移管と保持条件を判定します。調査対象でなければ、業務データの移管完了と組織の保持条件への適合を判断します。どちらかが未完了なら、利用停止を維持して削除を留保します。
条件が揃った対象を削除します。削除の実施者、実施日時、判断根拠を記録します。調査対象だった場合は、調査担当が保全結果を了承し、削除を留保する理由が解消した後に進めます。
削除前の証拠保全
IPAは10月9日の注意喚起で、異常なアカウントを見つけた場合は速やかにセキュリティインシデントと判定し、専門のセキュリティベンダーに詳細調査を依頼するよう強く推奨しています。サービスごとにログの保有期間が異なることにも注意を促しています。このため本記事では、侵害の疑いがあるアカウントは削除せず無効化で止め、調査担当が了承するまで削除しないことを提案します。削除で何が失われるかはサービスの仕様によるため、管理機能で取得・保持できる対象を確かめます。
ログだけでなく、記録と本人を結び付けるアカウント識別情報、当時の共有設定も保全対象として整理します。取得した記録には対象、取得日時、取得者を添え、閲覧者を調査担当などに限定して保管します。必要な対象を取得できない場合は、その不足を調査担当へ伝え、削除以外の保全方法を決めるまで留保します。業務データの移管とは別に保全の完了を判定すれば、引き継ぎが済んだことだけを理由に調査中のアカウントを削除する誤りを防げます。
▲ 不審な利用の有無やデータ移管・保持要件に応じたアカウント削除の判断フロー
毎月の確認
毎月の確認では、新たな退職者だけでなく、前月からの未解決分と後から把握したアカウントも再照合します。国家サイバー統括室は定期的にアカウントや権限設定を確認すること、IPAはアカウント棚卸の運用見直しを挙げていますが、頻度は定めていません。毎月という頻度は編集部の提案です。
初回対応の漏れを追う場合は、削除件数だけでなく、退職者と各SaaSのアカウントの対応を確認できた範囲と、未解決の持ち越しを記録します。前月の未解決一覧を起点にすれば、新たな退職者の処理に埋もれた対象も追跡できます。
実施順 | 作業と役割分担 | 記録する内容 |
|---|---|---|
対象データの更新 | 担当者が退職者リスト、各SaaSのアカウント一覧、前月の未解決一覧を取得し、後から把握した対象も追加します。 | 取得日、対象SaaS、一覧の取得範囲を残します。 |
差分の照合 | 担当者が前月との差分を照合します。退職者との対応関係が不明なら、所属部門が旧メールアドレスや利用情報を補います。 | 対応を確認できた対象と、確認できない対象を分けます。 |
残存・未解決への対応 | SaaS管理者が現在の状態を判断し、未処理なら所定の削除・無効化を実施します。判断材料が足りなければ確認先を決めます。 | 対応内容、未解決の理由、担当者、期限を残します。 |
処理後の再判定 | SaaS管理者が処理結果を確認し、担当者が一覧を更新します。結果を確認できない対象は翌月へ持ち越します。 | 完了・未解決の区分と、判定の根拠を残します。 |
月次管理では、退職者との対応が取れ、予定した処理の結果まで確認できた対象を「完了」とします。対応関係、現在の状態、処理結果のいずれかが不明なら「未解決」です。該当アカウントがないと判定する場合も、対象の管理画面などで確認した範囲を記録します。
一覧を自動取得できるなら月次照合に利用し、取得対象外のSaaSは担当者が管理画面で補完します。取得方法が違っても、完了と未解決の判定区分は共通にします。管理表には「退職者／SaaS／アカウント／対応関係／現在の状態／判定／根拠／担当者／期限」を設け、未解決には次の対応も記入すると、そのまま翌月の確認対象に使えます。利用可能な残存アカウントが見つかった場合は、月次の締めを待たずに管理者へ対応を引き継ぎます。
アジアクエストの導入事例
アジアクエスト（従業員数は国内単体461名、2025年12月末時点）は、2023年5月頃にマネーフォワード Adminaを導入しました。導入前は、退職者が出るたびに20以上のSaaSの管理画面へ1つずつログインし、アカウントの有無を確認して削除していました。導入後はAdminaの画面上から直接アカウントを削除できるようになり、確認から削除にかかる時間を約8割削減したと同社は説明しています（発表資料、導入事例）。
一覧の取得や削除を集約できる場合も、取得の対象外になるSaaSの補完と、処理後の再確認は残ります。
まとめ
退職者のアカウント削除は、次の3点で確認します。
IdPでの停止と、各SaaS側のアカウント・セッションの状態は別に確認します。SAML・SCIMに対応していないSaaS、ローカルアカウント、個人メールで作ったアカウントは特に漏れやすい対象です。
退職者リストと各SaaSのアカウント一覧を照合し、確認できなかった対象は未解決として翌月に持ち越して追います。
所有データ・APIトークン・共有リンクの引き継ぎと証拠の保全が済むまでは無効化で止め、削除はその後に判断します。
まとめ
退職者のアカウント削除は、IdP停止だけで完了とせず、各SaaSの状態まで突き合わせます。所有データ・連携の引き継ぎと証拠保全を整理したうえで、無効化・削除を判断する運用が基本です。未解決分は毎月再照合し、対応が済むまで追跡します。
まずは、直近の退職者リストと取得済みのSaaSアカウント一覧を照合してください。対応関係が不明なものは、調査対象として残します。管理方法を見直す場合は、本記事の照合表と月次の管理表を自社の運用に合わせて整え、次の月次確認から使い始めます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
