退職者アカウントの削除漏れを防ぐチェックリスト

「本日付で退職しました」という連絡を人事から受け、あわてて対象者のメールアカウントを止め、社内チャットから外し、共有フォルダの権限を削除する——多くのひとり情シス担当者が、この作業を「そのつど手作業」でこなしています。1人や2人の退職ならまだしも、繁忙期や複数名が重なるタイミングでは、どのアカウントをどこまで対応したか、記憶と勘だけでは追いきれなくなってきます。

「あのクラウドサービスのアカウントは消したっけ」「あの人が管理者権限を持っていたSaaS、権限は剥奪したはず」——退職者対応が一段落したあとに、こうした不安がふと頭をよぎった経験がある方は少なくないはずです。そして実際に、数ヶ月後の棚卸しで、退職済みのはずの元従業員のアカウントがログイン可能な状態のまま残っていた、という事例は珍しくありません。

本記事では、退職者のアカウント削除を都度手作業で行っている担当者向けに、なぜ削除漏れが起きるのか、放置するとどんな具体的なリスクがあるのかを警察庁・IPAの公的データで裏付けたうえで、削除漏れを構造的に防ぐためのチェックリストと運用の作り方を解説します。「気をつける」という精神論ではなく、仕組みとして漏れを防ぐことを目標にします。

結論: 退職者アカウントの削除漏れは「個人の注意力」では防げない

先に結論を書きます。退職者アカウントの削除漏れは、担当者の注意不足が原因ではなく、多くの場合「対象アカウントの一覧が存在しない」という構造上の問題から発生します。人間の記憶に頼って「あのサービスとこのサービスを止めればいいはず」と対応している限り、契約したことすら忘れているSaaSや、本人が個人的に部門アカウントとして使っていたクラウドサービスは、対応リストにそもそも上がってきません。

したがって、削除漏れを防ぐために本当に必要なのは、「気をつける」ことではなく、次の2つです。

1. 会社が契約している全アカウント・全サービスの一覧を、日頃から維持しておくこと
2. 退職が決まった時点で、その一覧を元に「誰が」「いつまでに」「何を」対応するかを定型化したチェックリストで進めること

この2つが揃って初めて、担当者が変わっても、繁忙期でも、同じ水準で退職者対応ができるようになります。本記事の後半では、実際に使えるチェックリストの雛形を提示しますが、その前提として、まず「なぜ放置してはいけないのか」を一次情報で確認しておきます。

退職者アカウントの放置は何が問題なのか: 公的データで見る実態

「退職者のアカウントを消し忘れたところで、本人がわざわざ不正アクセスするとは思えない」と感じる方もいるかもしれません。しかし、警察庁が令和8年3月に公表した最新の統計を見ると、この楽観は裏付けられません。

警察庁・総務省・経済産業省が毎年公表している「不正アクセス行為の発生状況」によると、令和7年に検挙された不正アクセス禁止法違反事件のうち、他人のID・パスワードを盗用する「識別符号窃用型」の手口が399件と、検挙件数全体の90%以上を占めています。その手口の内訳を見ると、次のような結果が示されています。

令和7年における不正アクセス行為（識別符号窃用型）の手口別検挙件数を見ると、「パスワードの設定・管理の甘さにつけ込んで入手」が最も多く（84件）、次いで「フィッシングサイトから入手」（77件）、「他人から入手」（75件）、「識別符号を知り得る立場にあった元従業員や知人等による犯行」（61件）の順となっている。

つまり、「識別符号（IDやパスワード）を知り得る立場にあった元従業員や知人等による犯行」は、不正アクセスの手口の中で4番目に多い、無視できない類型です。前年（令和6年）はこの手口が107件で全体の2番目に多い手口だったこともあり、年による増減はあるものの、退職者・元従業員が関与する不正アクセスは、決して特殊な事例ではなく、継続的に一定数発生し続けている構造的なリスクだと分かります。

この数字が示しているのは、「退職者本人が悪意を持って侵入する」ケースだけではありません。元従業員が知っていたID・パスワードの組み合わせが、何らかの経路で第三者に渡り、それが悪用されるケースも含まれます。パスワードを使い回している場合、退職者本人に悪意がなくても、その人物が過去に使っていた認証情報が別の不正アクセス事件の材料になってしまう可能性があるということです。

IPAも「内部不正防止」の観点でアカウント管理を重視している

IPA（独立行政法人 情報処理推進機構）が公開している「組織における内部不正防止ガイドライン」でも、退職者・異動者に関するアカウント管理は、内部不正対策の重要な柱の一つとして位置づけられています。同ガイドラインでは、業務上の必要性に応じてアクセス権を付与・変更・削除する「アクセス権の管理」や、退職者による情報の持ち出し・不正利用を防ぐための「人事異動・退職者管理」が、組織が講じるべき基本的な対策の一つとして挙げられています。

ここで整理しておきたいのは、退職者アカウント管理のリスクは大きく2つの側面に分かれるという点です。

• 外部からの不正アクセスの踏み台になるリスク: 前述の警察庁データが示す通り、放置されたアカウントの認証情報が、第三者による不正アクセスに悪用される
• 退職者本人による内部不正のリスク: 円満退職でない場合や、転職先が競合にあたる場合など、退職者本人が在職中の権限を使って情報を持ち出す、あるいは退職後もログインし続ける

どちらのリスクも、根本的な対処法は同じです。退職が決まった時点で、対象者が持っていたすべてのアカウント・権限を、速やかに無効化することです。「速やかに」という点が重要で、退職日から数週間、数ヶ月経ってからの対応では、その間ずっとアカウントが有効な状態で放置されていることになります。

なぜ削除漏れが起きるのか: 4つの構造的な原因

削除漏れは、担当者の不注意という単純な話ではなく、いくつかの構造的な原因が重なって発生します。自社がどの原因に当てはまるかを確認してみてください。

原因1: 対象アカウントの全体像が把握できていない

最も根本的な原因です。システム管理台帳が整備されていない、あるいは存在していても更新されておらず、「この会社にどんなクラウドサービス・システムが存在し、誰がどのアカウントを持っているか」を正確に把握できていない状態です。この状態では、退職者対応のたびに「思い出せる範囲」でしか対応できません。数年前に試験導入して使われなくなったツールや、特定の部署だけがひっそり契約しているSaaSは、担当者の記憶から漏れやすく、削除漏れの温床になります。

原因2: 退職者本人しか知らないアカウントが存在する

現場の担当者が、情シスへの申請や共有をせずに、個人の判断でクラウドサービスを契約・利用しているケースです。シャドーITと呼ばれるこの状態では、そもそも情シス側にアカウントの存在自体が伝わっていないため、退職時にも対応漏れが起きて当然といえます。特に、無料プランや個人契約から始まったツールが、いつの間にか業務の一部で使われるようになっているケースは要注意です。

原因3: 退職の連絡と情シスへの共有にタイムラグがある

人事・総務が退職の事実を把握してから、情シス担当者（多くの場合、総務と兼任）にその情報が伝わるまでに時間差があると、対応が後手に回ります。特に、情シスと人事が別の担当者である場合、「退職者対応リスト」のような明確な引き継ぎフローがなければ、連絡自体が漏れてしまうことすらあります。

原因4: チェックリストが存在せず、対応範囲が担当者の記憶頼みになっている

同じ担当者が長く対応していれば大きな問題にならないかもしれませんが、担当者が変わったり、繁忙期に複数の退職が重なったりすると、「何を対応すればよいか」の判断が個人の経験値に依存してしまいます。これは属人化の典型的なパターンで、退職者対応というプロセス自体が属人化している状態です。チェックリストという「外部化された記憶」がなければ、担当者が変わるたびに対応品質がばらつきます。

これら4つの原因は独立しているように見えて、実は根っこでつながっています。土台となる「全体像の把握」ができていなければ、チェックリストを作ろうにも対象が定まらず、結局は担当者の記憶頼みに逆戻りしてしまうのです。

削除漏れを防ぐための土台: アカウント台帳を先に作る

チェックリストの前に、まず取り組んでおきたいのが「誰が」「どのサービスの」「どんな権限を」持っているかを一覧化した台帳です。これがないままチェックリストだけを運用しても、「一覧にない未知のアカウント」は永遠に見落とされ続けます。

台帳に最低限含めておきたい項目は次の通りです。

• サービス名・システム名: 契約しているSaaS、社内システム、クラウドストレージなど
• 管理者/一般ユーザーの別: そのアカウントが管理者権限を持つか、一般利用者かの区分
• 利用者名: 誰がそのアカウントを使っているか
• 認証方式: 個別ID・パスワード方式か、シングルサインオン（SSO）でまとめて管理されているか
• 契約・課金の単位: 個人ごとの課金か、部署単位・全社契約か
• 管理担当部署: そのサービスの契約主体はどの部署か（情シスが把握していない部署契約のサービスがないか）

すでにIT資産管理の一環でIT資産台帳を作成している場合は、その台帳に「利用者」の列を追加するだけで、退職者対応にそのまま転用できます。まだ台帳が存在しない場合は、退職者対応をきっかけに、まずは自分が把握している範囲だけでもよいので着手することをおすすめします。完璧な一覧を最初から目指す必要はなく、退職が発生するたびに「このサービスも追加しなければ」という気づきを積み重ねていく形で構いません。

台帳がゼロの状態から着手する場合は、いきなり退職者対応と並行して作ろうとせず、まず現状把握を優先してください。会社全体のシステム棚卸しの進め方は、別記事『社内システムの現状調査（棚卸し）のやり方』で詳しく解説しています。

退職者アカウント削除チェックリスト

ここからが本題です。台帳が整った、あるいは整備中という前提で、退職が決まった際に実際に使えるチェックリストを、対応の時系列に沿って整理します。自社の状況に応じて、項目を過不足なく調整してください。

フェーズ1: 退職が決まった時点（退職日の2〜4週間前が目安）

• [ ] 退職者が利用しているすべてのアカウント・システムを台帳から洗い出す
• [ ] 退職者が管理者権限を持つサービスがないか確認する（クラウドの管理コンソール、SNSアカウント、ドメイン管理画面など）
• [ ] 退職者しか把握していない業務・手順がないか、本人にヒアリングする
• [ ] 引き継ぎが必要なデータ（メール、ファイル、顧客情報など）の所在を確認する
• [ ] 退職者が個人契約・個人アカウントで業務利用しているサービスがないか確認する（シャドーITの洗い出し）

フェーズ2: 退職日当日〜翌営業日

• [ ] メールアカウントを無効化する（完全削除ではなく、まずログイン不可の状態にする）
• [ ] 社内チャットツール（Slack、Teams等）からアカウントを削除、または無効化する
• [ ] 業務システム・クラウドサービスの個別アカウントを無効化する
• [ ] VPN・リモートアクセスの権限を削除する
• [ ] 社用スマートフォン・パソコンを回収し、MDM（モバイルデバイス管理）でリモートロックまたはデータ消去を行う
• [ ] 建物への入退室カード・鍵を回収し、権限を削除する
• [ ] 多要素認証（多要素認証（MFA））の登録情報（登録済み電話番号・認証アプリ）を削除する
• [ ] 共有フォルダ・クラウドストレージへのアクセス権限を削除する
• [ ] 社用クレジットカード・経費精算システムのアカウントを停止する

フェーズ3: 退職後1〜2週間以内

• [ ] メールの転送設定・自動応答の要否を判断し、設定する（顧客対応の引き継ぎが必要な場合）
• [ ] 退職者が管理者だった各種アカウントの管理者権限を、後任または他の担当者に正式に移管する
• [ ] 退職者名義になっているドメイン・サーバー・SaaS契約の名義変更を進める
• [ ] 退職者のメールアドレス宛に届く重要な連絡（取引先、行政機関等）の転送・引き継ぎ先を確認する
• [ ] 台帳の「利用者」欄を更新し、退職者の名前を削除・後任者に変更する

フェーズ4: 退職後1〜3ヶ月をめどに実施

• [ ] 業務への影響がないことを確認したうえで、無効化していたアカウントの完全削除を検討する
• [ ] 削除・無効化したアカウント一覧と対応日を記録として残す
• [ ] 台帳と実際の状況にズレがないか、棚卸しの一環で再確認する

フェーズ4で触れている通り、アカウントは「退職日にいきなり完全削除」ではなく、まず無効化（ログイン不可にする措置）にとどめ、業務影響がないことを確認してから完全削除に進む、という2段階の対応をおすすめします。アカウントを完全削除すると、紐づくメール履歴やファイルの所有権ごと失われてしまう場合があり、退職後にその情報が必要になって困るケースがあるためです。

特に見落とされやすいアカウント・権限

チェックリストに沿って対応していても、次のようなアカウントは見落とされがちです。意識的に確認しておく価値があります。

• ドメイン・サーバーの契約名義: 会社のドメインやレンタルサーバーの契約が、担当者だった個人名義・個人メールアドレスのままになっているケース。退職者本人にしかログインできない管理画面が存在すると、後から取り戻すのに手間がかかります
• 外部連携サービスのAPIキー・アカウント: 決済代行、メール配信、分析ツールなど、システム間連携のために発行されているAPIキーやサービスアカウントは、個人が管理していることに気づかれにくい領域です
• 業務で使っていた個人のクラウドストレージ・メモアプリ: シャドーITの一種で、業務データが会社の管理外のクラウドに残ったままになる
• 取引先・顧客とやり取りしていたSNSアカウント: 会社の公式SNSを個人のスマートフォンで運用していた場合、ログイン情報の引き継ぎが必要です
• 社内Wikiやナレッジベースの編集権限: 削除ではなく無効化にとどめるべきか、そのまま権限を残すか判断が分かれやすい領域です
• 定期実行しているバッチ処理やRPA（自動化ツール）の実行アカウント: 退職者個人のアカウントで動いていた自動処理が、アカウント無効化と同時に止まってしまうケース。事前に実行アカウントの棚卸しをしておく必要があります

これらは、通常の「メールとチャットを止めればよい」という発想だけでは対応が漏れやすい領域です。台帳を作る段階で、こうした「見えにくいアカウント」も意識的に含めておくことが、削除漏れを防ぐポイントになります。

退職者対応フローをテンプレート化する

チェックリストを毎回ゼロから思い出しながら作るのではなく、一度テンプレートとして固定してしまうことをおすすめします。具体的には、次のような形にすると運用しやすくなります。

• 退職者対応チェックリストをスプレッドシートやドキュメントで用意し、退職が発生するたびにコピーして使う: 毎回同じ項目から漏れなくチェックできます
• 人事・総務からの退職連絡フォーマットを決めておく: 「退職日」「最終出社日」「担当していたシステム・業務」を必ず記載してもらう項目にしておくと、情シス側の初動が早くなります
• 対応担当者を明確にしておく: 「誰が」「いつまでに」対応するかを、テンプレート上で割り当てられるようにしておきます。ひとり情シス体制であっても、フェーズごとに人事・総務と役割分担を明文化しておくと、自分が休んでいる間の対応漏れも防げます

このテンプレート化は、エスカレーションが必要な場面（退職者と連絡が取れない、名義変更に時間がかかる等）を早期に発見する仕組みとしても機能します。テンプレートに沿って淡々と進めていく中で、「この項目だけ完了しない」という状態が可視化されれば、それが問題化する前に対処に動けます。

円満退職ではない場合の追加対応

すべての退職が円満とは限りません。トラブルを伴う退職や、懲戒的な事情がある場合は、通常の退職者対応チェックリストに加えて、次のような点により注意を払う必要があります。

• アカウント無効化のタイミングを早める: 通常は退職日当日〜翌営業日での対応でも問題ありませんが、トラブルを伴う退職では、退職の意思表示があった時点、あるいは最終出社日の前に、業務上支障のない範囲でアクセス制限を検討することも選択肢になります
• データの持ち出し履歴を確認する: クラウドストレージやメールのダウンロード履歴、外部への転送履歴などを、可能な範囲で確認しておきます
• 重要な契約・取引先情報へのアクセスを優先的に制限する: 顧客リストや契約書、価格情報など、競合に流出した場合の影響が大きい情報へのアクセス権限を最優先で削除します
• 法務・経営層と連携する: 秘密保持義務や競業避止義務に関する契約内容を確認し、必要に応じて法的な対応方針を法務・顧問弁護士と相談します

こうした対応は、通常の退職者対応以上に迅速さが求められます。IPAの内部不正防止ガイドラインでも、退職者による情報の持ち出しは、組織が想定しておくべき典型的な内部不正のパターンとして位置づけられています。日頃から「トラブルを伴う退職が起きたら、通常フローに加えて何を追加対応するか」を、あらかじめ決めておくと、実際に起きたときに慌てずに動けます。

削除漏れが発覚したときの対処法

チェックリストを整備していても、過去の退職者対応で漏れが見つかることはあります。棚卸しの過程で「もう退職しているはずの人のアカウントが有効なままだった」と気づいた場合、慌てず次の順番で対応してください。

ステップ1: まず無効化し、被害の有無を確認する

見つけた時点で、まずアカウントをログイン不可の状態に無効化します。次に、そのアカウントに直近のログイン履歴やアクセス履歴がないかを確認します。多くのクラウドサービスやSaaSは、管理画面から直近のログイン日時や操作ログを確認できる機能を備えています。退職後に不審なログインがなかったかを、まずここで確認します。

ステップ2: 影響範囲を洗い出す

そのアカウントが、どの範囲のデータ・システムにアクセスできる権限を持っていたかを確認します。管理者権限を持つアカウントだった場合は、他のアカウントの設定が変更されていないか、新しい管理者アカウントが不正に追加されていないかも合わせて確認しておくと安心です。

ステップ3: 記録を残し、再発防止策につなげる

いつ、どのアカウントの削除漏れに気づき、どう対応したかを記録に残します。この記録は、単なる事後処理の証跡としてだけでなく、「なぜこのアカウントは台帳やチェックリストから漏れていたのか」を振り返る材料にもなります。原因が「そもそも台帳に載っていなかった（シャドーITだった）」のか、「台帳にはあったがチェックリストの実行時に見落とした」のかによって、再発防止の打ち手が変わってきます。前者であれば台帳の棚卸し範囲を広げる必要がありますし、後者であればチェックリストの運用方法そのものを見直す必要があります。

ステップ4: 経営層への報告が必要かを判断する

漏れていたアカウントに、顧客の個人情報や機密性の高い情報へのアクセス権限が含まれていた場合は、単独で判断せず、経営層や必要に応じて法務にも状況を共有することをおすすめします。実際に情報が持ち出された形跡がなくても、「一定期間、退職者がアクセス可能な状態が続いていた」という事実自体は、経営判断が必要な情報です。担当者ひとりで抱え込まず、早めに共有する姿勢が、結果的に会社全体のリスク管理につながります。

このように、削除漏れの発覚は「失敗」ではなく、台帳やチェックリストの精度を上げるための貴重な機会でもあります。見つけた漏れを個人のミスとして片付けず、仕組みの改善につなげる視点を持っておくと、同じ漏れの再発を防ぎやすくなります。

よくある誤解を整理する

退職者アカウント管理について、担当者自身や経営層が誤解しやすいポイントを整理しておきます。

誤解1: 「メールアカウントさえ止めれば十分」

メールは重要な対応対象ですが、それだけでは不十分です。クラウド会計ソフト、顧客管理システム、社内チャット、共有ストレージなど、退職者がアクセスできていたすべてのサービスが対象になります。特に、退職者が個別に契約・利用していたSaaSは見落とされやすい領域です。

誤解2: 「退職者は善良な人だから大丈夫」

前述の警察庁データが示す通り、退職者・元従業員が関与する不正アクセスは、悪意の有無にかかわらず発生し得ます。退職者本人の人柄の問題ではなく、「認証情報が有効なまま残っている」という状態そのものがリスクです。信頼と、アカウントを有効なまま残すことは、別の問題として切り分けて考える必要があります。

誤解3: 「一度削除フローを作れば、あとはずっとそのまま使える」

会社が新しいクラウドサービスを契約するたびに、削除チェックリストの対象は増えていきます。半年〜1年に一度は、チェックリストの項目に漏れがないか、実際に使っているサービス一覧と突き合わせて見直すことをおすすめします。チェックリストも、台帳と同様に「作って終わり」ではなく、更新し続ける前提の運用物です。

誤解4: 「退職者対応は人事の仕事で、情シスは言われたことだけやればよい」

退職の事実確認や社会保険・給与関連の手続きは人事の領域ですが、アカウント・権限の削除という技術的な対応は情シス側の責任範囲です。人事から情シスへの連絡フローが曖昧なままだと、「言われていないから対応していない」という抜け漏れが起きやすくなります。退職者対応は人事と情シスの共同プロジェクトだという前提を、双方で共有しておくことが重要です。

ひとり情シス体制での運用を続けるコツ

チェックリストと台帳を整備した後、これを形骸化させずに運用し続けるためのポイントを整理します。

• 退職が発生していない時期にも、定期的に台帳の内容を見直す: 半年に一度など、退職とは無関係のタイミングでも棚卸しの機会を設けておくと、日頃の記録の甘さに早めに気づけます
• 新規サービス契約時に「利用者情報」を必ず記録する習慣をつける: 新しいSaaSを契約するたびに、台帳への追記を後回しにしないルールを自分の中で決めておきます
• 人事異動時にもチェックリストの一部を流用する: 退職ほど厳格でなくても、部署異動があった場合は不要になった権限を見直す機会になります。退職者対応と同じ発想で、権限の棚卸しに使えます
• 経営層に、対応状況を定期的に共有する: 退職者対応が滞りなく行われていることを、簡単な報告としてでも経営層に伝えておくと、必要な予算やツール導入の判断材料になります

これらは、退職者対応に限らず、社内システム管理全般に共通する考え方です。「都度その場で対応する」から「仕組みで漏れなく対応する」へと発想を切り替えることが、ひとり情シス体制における最大のリスクヘッジになります。

まとめ

退職者アカウントの削除漏れは、担当者個人の注意力の問題ではなく、「対象アカウントの全体像を把握できていない」「対応手順が定型化されていない」という構造上の問題から生まれます。警察庁の最新データが示す通り、識別符号を知り得る立場にあった元従業員による不正アクセスは、令和7年時点でも手口別で4番目に多い、無視できない規模で発生し続けています。

削除漏れを防ぐためには、まず会社が契約しているアカウント・サービスの全体像を台帳として整理し、そのうえで退職時のチェックリストをフェーズごとに定型化しておくことが有効です。本記事で示したチェックリストを土台に、自社の実情に合わせて項目を調整し、退職が発生するたびにコピーして使えるテンプレートとして運用してみてください。

アカウント管理台帳がまだ整っていない場合は、あわせて『中小企業のIT資産管理の始め方』も参考にしてください。「何があるかを把握したうえで対策する」という順序は、退職者アカウント管理でも共通する考え方です。