退職者のアカウントが、本人が職場を去った後もしばらく有効なままになっていた――そんな状況に気づいたとき、多くの総務担当者はどこから手をつければよいか分からず、ログを開いても何を見ればよいか判断できないまま時間だけが過ぎていきます。「対応していませんでした」では済まないプレッシャーを感じながらも、外部の専門家を呼ぶ余裕もない。
そうした現場の制約を前提に、この記事では「退職申し出〜最終出社日〜退職後」という時間軸に沿って、ログで何を確認すべきかと権限をいつ・どの順番で停止・削除すべきかを具体的に整理します。
Contents
なぜ権限停止・削除は遅れるのか――現場に潜む構造的な理由
アクセス権限の停止・削除が後回しになる原因は、担当者個人の問題というより、職場の運用構造にある場合があります。この章では、その構造を正確に把握することで、「どこを変えれば解決できるか」を考える起点とします。
「引き継ぎが終わるまで待ってほしい」という現場プレッシャー
退職者がアカウントを持ち続けてしまう理由のひとつが、「引き継ぎ期間中に業務が止まる」という現場の反発です。営業担当者が顧客フォルダにアクセスできなくなった瞬間に引き継ぎが止まる、という恐れから、総務担当者は「最終出社日まで待つ」という判断を取りがちです。しかし実際には、最終出社日を過ぎた後もアカウントが放置されているケースが生まれるのは、「引き継ぎが終わったら削除する」という曖昧な申し送りが誰にも引き継がれないからです。
引き継ぎの都合と情報セキュリティの要件を両立するには、「全か無か」ではなく段階的な権限の絞り込みと、最終的な無効化のタイミング設定が必要です。何を先に停止・制限し、何を最後まで残すかの優先順位が社内に存在しないまま、担当者が退職のたびに個別対応を繰り返しているのが現状です。
フローが属人化し、記録が残らない
退職者への対応手順が文書化されておらず、「メールで連絡した」「口頭で伝えた」という形で処理が完結している組織では、後から「いつ、誰が、どのシステムのアカウントを無効化したか」を確認する術がありません。情報システム担当者が1名しかいない、あるいは兼任担当者が窓口を担っている中堅企業では特にこの傾向が強く、退職フローの中にセキュリティ手順が組み込まれていないことが多いです。
この構造が放置されると、退職済みの元社員のアカウントが相当期間にわたって有効なまま残り続けるリスクが蓄積します。対策の入口は、専門知識ではなく「誰が・いつ・何を確認したか」を記録に残す仕組みを退職フローに組み込むことです。
退職申し出から退職後まで―時間軸で見るログ確認と権限停止・削除のマップ
退職手続きの各フェーズで、何をログで確認し、どの権限を停止・制限すべきかを時間軸ごとに整理します。「引き継ぎを止めない」という現場制約を前提にしながら、証跡を残せる最小限の対応セットを示します。
フェーズ1：退職申し出〜退職受理時点
退職の申し出を受けた時点が、セキュリティ対応の起点です。まだ誰も権限を変更していないこの段階で、現状のアクセス権限と直近のアクセス履歴を記録・保全することが最初の行動です。この時点でやるべきことは次の3点です。
- 対象者が現在アクセスできるシステム・フォルダ・ファイルの一覧を書き出す
- 退職申し出日の前後1〜2週間分のアクセスログをエクスポートして保存する
- 退職申し出日以降のアクセスログを確認する運用について、社内規程や情報セキュリティ規程に基づき、必要な範囲で周知・記録する
この段階では一律に権限を停止する必要はありませんが、特権権限や引き継ぎに不要な権限は早めに見直す必要があります。また、アクセスログが記録・確認される運用であることを、社内ルールとして明確にしておくことが重要です。
フェーズ2：引き継ぎ期間中（最終出社日の前）
引き継ぎ期間は、業務の継続と情報管理の両立が求められる最も難しいフェーズです。引き継ぎに必要なアクセスを残しつつも、不要な権限は段階的に絞り込む必要があります。そのうえで、異常なアクセスパターンを定期的に確認する体制を取ることが重要です。この期間中にログで確認すべき異常の目安は以下のとおりです。
- 通常業務の範囲を超えた大量のファイルダウンロード
たとえば、普段の操作量と比べて明らかに多い件数のファイルをまとめてダウンロードしていないかを確認します。 - 引き継ぎ対象業務と無関係なフォルダへのアクセス
担当外の顧客情報、財務データ、人事情報などにアクセスしていないかを確認します。 - 深夜・休日など通常勤務時間外のログイン
業務上必要のない時間帯にログインしていないかを確認します。 - 短時間に多数のフォルダを横断するアクセス
通常の業務では発生しにくい範囲のアクセスがないかを確認します。
引き継ぎ期間中の権限停止・制限の考え方は「業務継続に直接必要なもの以外は先に絞り込む」です。具体的には、担当業務に関連するフォルダのみに読み書き権限を限定し、引き継ぎ業務に不要な全社共有の機密フォルダや人事・財務関連フォルダへのアクセスは、引き継ぎ開始時点で停止または制限します。現場から「業務が止まる」という反発が出る場合は、「引き継ぎ対象業務に限定した最小権限への変更」として説明することで、現場の合意を取りやすくなります。
フェーズ3：最終出社日
最終出社日は、権限の大部分を停止する実行タイミングです。この日に退職者本人の立ち会いのもとでアカウントの状態を確認し、以下の手順を実行します。
- 業務用端末の返却と同時に、その端末からのセッションを強制ログアウトする
- クラウドストレージ・メール・VPN・社内ポータルなど、主要システムのアカウントを当日中に無効化またはロックする。削除は、ログやデータ保全への影響を確認したうえで行う
- 無効化・ロックの実行日時と担当者名を記録する
- 最終出社日の操作ログを即日エクスポートして保全する
この段階で必ず注意が必要なのは、「退職日（保険・給付の手続き上の日付）」と「最終出社日」が異なるケースです。アカウントの無効化は、業務利用が終了する最終出社日または業務最終日を基準に行うことが、アクセス可能期間を最小化するうえで重要です。業務利用が終了しているにもかかわらず退職日まで待つ運用は、アカウントが不要に有効な期間を生みやすくなります。
フェーズ4：退職日以降〜1週間以内
最終出社日にアカウントを無効化した後も、1週間以内に残存アクセスの確認を行います。これは、無効化の作業が正常に完了しているかを確認するためのチェックです。
- 無効化したはずのアカウントで、退職日以降にログイン試行や操作ログが残っていないかを確認する
- 複数のシステムを横断して、停止・削除漏れがないかリスト照合する
- 不審なログインが確認された場合は、即座にアカウント無効化・セッション強制終了・関連システムの確認を行い、その記録を保全する
この1週間以内の確認を「退職フローの最終ステップ」として明示的に組み込んでいる企業は少ないですが、「対応した」という事実を証明するための証跡として、この確認記録が後から重要な意味を持ちます。
アクセスログで何を見るべきか―確認観点の整理
「ログを見る」と一口に言っても、何を異常と判断するかの基準がなければ、ログを開いても判断できません。この章では、退職予定者のアクセスログを確認する際の具体的な観点を整理します。
「量」「範囲」「時間帯」の3軸で異常を判断する
退職予定者のアクセスログで確認すべき異常は、次の3軸で評価できます。
①量の異常： 通常時と比べてダウンロード件数・操作件数が急増していないかを確認します。退職申し出後に急にファイルのダウンロード量が増えた場合、意図的な持ち出しの可能性があります。「いつもと比べてどうか」という相対評価が基本になるため、退職申し出前の通常期のログも比較対象として保存しておくことが重要です。
②範囲の異常： 普段アクセスしていなかったフォルダや、担当業務と無関係なデータに接触していないかを確認します。過去のアクセス履歴と比較して、新たに接触しているフォルダやファイルを特定します。
③時間帯の異常： 勤務時間外（深夜・休日・就業前後）のアクセスがないかを確認します。退職が決まってから就業時間外に大量操作が行われている場合は、業務目的以外の動機が疑われます。
ログが「証跡」として機能するための保管方法
アクセスログは、何かが起きた後に「証拠として提出できる状態」にあることが重要です。ログを証跡として機能させるためには、以下の点に注意します。
- ログのエクスポートは、退職前後の早い段階で行う
- エクスポートしたログは、対象者がアクセスできないストレージに保管する
- ログファイルには「エクスポート日時・エクスポートした担当者名・対象期間」を記録しておく
- 退職後のログ保管期間は、社内規程・契約・取り扱う情報の性質に応じて定め、必要に応じて数年単位で保管することを検討する
複数システムの停止・削除漏れを防ぐ――横断チェックリストの作り方
退職者対応で最も多い失敗は、「メールアカウントは停止したが、クラウドストレージのアカウントが残っていた」という形での停止・削除漏れです。この章では、システムを横断した権限停止の漏れをなくすための考え方を整理します。
自社が使用しているシステムをすべて書き出す
まず、自社で退職者がアクセスできる可能性があるシステムをすべてリスト化します。一般的な中堅企業で対象になるシステムの例は次のとおりです。
- メール（社内メールサーバーまたはクラウドメール）
- クラウドストレージ（ファイル共有・ドキュメント管理）
- VPN（リモートアクセス環境）
- 業務システム（ERPや顧客管理システムなど）
- 社内ポータル・グループウェア
- ビジネスチャットツール
- 外部サービス（共有アカウントを使っている場合）
この一覧に「担当部署」「アカウント管理者（誰が停止・削除操作を行えるか）」「停止・削除の実行手順（どこで操作するか）」を付記したリストを1枚作成しておくことで、退職者が出るたびにこのリストを使って順番に処理を進められます。
SSOが導入されている場合・されていない場合の注意点
SSOが導入されている場合は、IdP（ID管理基盤）側でアカウントを無効化することで、連携対象サービスへの新規ログインをまとめて制御しやすくなります。ただし、SSOに連携していないシステム、既存セッション、ローカルアカウント、APIトークンなどが残る場合もあるため、個別の確認・停止作業は必要です。
SSOを導入していない環境では特に、「どのシステムを、誰が、どの順番で停止するか」をリストに明記しておくことが重要です。SSOを導入している環境でも、「このシステムはSSOに含まれているか・含まれていないか」をリストに明記しておくことで、停止漏れを防ぎやすくなります。
SSOや管理者によるユーザー管理機能を備えたクラウドストレージ製品を活用することで、退職時のアカウント停止・権限変更を管理者側で実行しやすい環境を整えられます。たとえばFleekdriveでは、管理者によるユーザーアカウント管理機能が提供されています
「属人運用」から脱する―仕組み化できる部分を特定する
退職のたびに担当者が個別対応を繰り返す属人運用から抜け出すには、「何を標準化し、何を記録に残すか」という設計が必要です。専任の情シス担当者がいない環境でも実現できる、最小限の仕組み化ポイントを整理します。
退職フローに「セキュリティ手順」を組み込む
人事や総務が管理する退職手続きのチェックリストに、以下の項目を追加します。
- 退職申し出受理日：対象者のアクセス権限リストを作成し、ログの確認を開始した日付と担当者名を記録する
- 引き継ぎ開始日：不要な権限の絞り込みを実施し、実施内容を記録する
- 最終出社日：全システムのアカウント無効化・ロックを実行し、完了を確認した担当者名と日時を記録する
- 退職日から1週間以内：残存アクセスの有無を確認し、問題なしまたは対処内容を記録する
この4点を退職手続きチェックリストに組み込むだけで、「誰がいつ何をしたか」という証跡が蓄積されます。高度なシステムを使わなくても、既存のExcelや共有ドキュメントに記録欄を追加するだけで、最低限の証跡管理として機能します。
ログの確認を「定期スポットチェック」として習慣化する
退職者が発生していない時期でも、在職中の社員のアクセスログを定期的に確認する習慣を持つことで、退職時だけ急に確認しようとしたときの「比較対象がない」問題を解消できます。月1回程度、異常なアクセスがないかをスポットチェックする運用を取り入れることを検討してください。
Fleekdriveのようなクラウドストレージ製品では、ファイルの操作ログ（アクセス・ダウンロード・共有操作など）を管理者が確認できる機能があります。AIを活用した異常検知機能を持つ製品も存在します。このような機能を活用することで、手動チェックの負担を減らしながら異常の早期発見に役立てられます。
まとめ
退職者のアクセスログ確認と権限停止・削除は、専門的な知識がなくても、「時間軸に沿った手順を決めること」と「記録を残すこと」の2点を実践するだけで、現状よりリスクを低減しやすくなります。引き継ぎ期間中の段階的な権限設計の詳細については、退職予定者によるデータ持ち出しを物理的に防ぐ｜管理者が行うべき防止策をあわせてご参照ください。
