社員が退職したとき30分以内に完了すべきアクセス権剥奪チェックリスト
退職者のアカウントが翌週も生きていたことに気づいたとき、あるいは「本当に全部消したか」と上長に聞かれて即答できなかったとき——情シス担当者にとって、あの一瞬は特に応える。
M365・Google Workspace・GitHubの操作パスと、SaaS台帳が未整備の環境での落とし穴を、当日の優先順位順に示す。
ソニービズネットワークスが中小企業109社を対象に2025年9月に実施した調査によると、退職者のSaaSアカウント削除漏れが15.6%の企業で発生しています。また、SaaSに起因するセキュリティリスクを感じている担当者は88.0%に上ります。珍しいミスではなく、台帳が整備されていない環境ではほぼ構造的に起きる問題です。
なぜ退職日当日の30分が最重要なのか
内部不正の実行者の51%はシステム管理者だった
IPAの「内部不正による情報セキュリティインシデント実態調査」（2016年）では、内部不正経験者の職務を尋ねたところ、51.0%がシステム管理者（兼務を含む）だったと報告されています。
また、IPAの「企業における内部不正防止体制に関する実態調査」（2023年4月・対象1,179社）では、個人情報漏えいインシデントが発生した企業が36.4%、営業秘密漏えいが発生した企業は35.1%にのぼっています。IPA 10大脅威2024（組織向け）でも、内部不正による情報漏えいは3位に位置しています。
権限を持つ人が最大のリスクになりえる、という構造的な理由がここにあります。退職者はアクセス権を持ったまま組織の外に出ます。退職の瞬間から、その権限は「脅威」に変わる可能性があります。
パスワード変更では既存セッションは切れない
最初に潰しておくべき誤解があります。
Microsoft 365 で退職者対応をするとき、「パスワードをリセットすれば大丈夫」と考えている担当者は少なくありません。しかしこれは正確ではありません。パスワードのリセットは、次回ログイン時にしか効きません。すでに認証済みのセッション——退職者のブラウザやモバイルアプリが持っているアクセストークン——は、パスワードを変えても生き続けます。
M365での正解操作は「サインインのブロック」です（Microsoft Entra 管理センターから実行）。ブロックを実行することで既存のセッションが無効化されます。また、MFA に登録されている認証方法（Authenticator アプリ・電話番号）の削除は、サインインブロックとは別の操作として必要です。
パスワード変更とサインインブロックは別物、という認識が、退職者対応の起点になります。
退職日当日に完了させる7つのステップ（30分目安）
以下のステップは、セッション残存リスクが高い順、つまり対応の優先順位が高い順に並んでいます。
Step 1: M365サインインブロック（所要 2〜3分）
操作パス: Microsoft Entra 管理センター → ユーザー → 対象ユーザーを選択 → プロパティ → 「このユーザーによるサインインをブロックする」にチェック → 変更の保存
これと同時に、対象ユーザーの「すべてのセッションからサインアウト」も実行します。これはパスワード変更とは別の操作です。
あわせて、MFA 登録（Authenticator アプリ・電話番号）の削除も忘れないようにしてください。パスワードとサインインブロックだけを処理して、MFA デバイスをそのままにしておくと、退職者の手元に認証手段が残り続けます。
オンプレミス AD 連携環境の注意点: M365 管理センターから直接アカウントを削除できない場合があります。ローカルの Active Directory 側での操作が必要であることは、Microsoft Learn の公式ドキュメントに明記されています。AD 連携環境では、M365 側だけ操作しても反映されないケースがあります。
Step 2: Google Workspace アカウント停止（所要 2〜3分）
操作パス: admin.google.com → ユーザー → 対象ユーザーを選択 → アカウントの停止（Suspend）
ここで注意が必要なのは、削除（Delete）ではなく停止（Suspend）を先に行うことです。削除前に停止状態を経由することで、ドライブファイルのオーナー権限を後任者へ移管できます。この順序を間違えると、データへのアクセスが失われます。
Google Workspace の仕様として、アカウント削除後はユーザーが所有していたドライブのファイルは20日後に削除が始まります。ただし、削除までの間も管理者がユーザーを復元しない限りそれらのファイルにアクセスすることはできない（Google Admin Help 公式ドキュメントより）ため、削除後すぐにアクセス権の移管を進めてください。
Gmail・共有カレンダー以外に、Looker Studio レポートもアカウント削除の対象になる点を忘れないようにしてください。
Step 3: 業務用 GitHub Organization からの削除（所要 5分）
操作パス: Organization → People → 対象ユーザーを選択 → Remove from organization（GitHub Docs 公式手順）
フォーク残存の落とし穴: GitHub Docs の公式ドキュメントには、「プライベートリポジトリを他の Organization にフォーク済みの場合、Organization 削除後もフォーク経由でアクセス可能なケースがある」という記載があります。Organization からの削除だけでは対処しきれないケースです。
ローカルコピーの問題: GitHub Docs が明記しているとおり、削除しても退職者の手元にあるローカルコピーは技術的に強制削除できません。これに対処できるのは法的な手段——NDA や退職時の誓約書——のみです。
Enterprise 環境で Okta などの IdP と SCIM 連携している場合は、IdP 側のプロビジョニング解除で GitHub の削除も連動させることができます。
Step 4: VPN アクセスの無効化（所要 5分）
VPN を Entra ID（旧 Azure AD）または Google Workspace と SAML/OIDC で連携している場合、Step 1・2 でのアカウントブロックに連動して VPN アクセスも無効化されることがあります。連携状況を確認してください。
連携していない環境では、VPN ベンダーの管理コンソールから手動で削除する操作が必要です。ただし Cisco AnyConnect・Fortinet・Palo Alto GlobalProtect 等、ベンダーごとに管理画面の構成が異なるため、具体的な UI 操作は各ベンダーの公式ドキュメントを参照してください。
Step 5: 情シス管理SaaSのアカウント削除（所要 10〜15分）
このステップが最もリスクが高く、時間もかかります。
ソニービズネットワークスの調査（中小企業109社・2025年9月）によると、調査対象企業の55.1%が SaaS を11個以上利用しています。台帳が整備されていれば順に実行するだけですが、台帳がない場合は HR からの入社時の権限付与記録・請求書・クレジットカード明細を起点にツールを洗い出す必要があります。
チェックの漏れが起きやすいツールとして、Slack・Notion・Figma・Zoom・freee・kintone・Salesforce などが挙げられます。これらの削除 UI の具体的な操作パスはベンダーごとに異なるため、各ツールの管理者向けドキュメントを参照してください。
最もよくある失敗パターンは、部署が独自契約している SaaS の見落としです。 情シスが把握していない SaaS は、情シスが削除することができません。マーケティング部門が個別にクレジットカード払いで契約している Loom や Figma のチームプランは、アカウント台帳に載っていないことが多くあります。
Step 6: メールボックスとOneDriveの引き継ぎ処理（M365）
Microsoft Learn の公式手順にもとづく対応の順序は以下のとおりです。
- 訴訟ホールドの有効化（メールボックス内容の保存）
- メール転送の設定、または共有メールボックスへの変換
- OneDrive・Outlook データへのアクセス権を後任者へ付与
OneDrive の30日猶予についての誤解: ライセンス削除後は30日でデータが消失します。「30日は消えない」と解釈して引き継ぎを後回しにしてしまうケースがありますが、正確には「30日以内に対処しなければ消える」です。ライセンス削除前に後任者へのアクセス権付与を完了させてください。
また、訴訟ホールドを設定せずにアカウントを削除すると、メールボックスは30日で完全に消失します。コンプライアンス上の要件がある場合は、ホールドの設定を先に行ってください。
Step 7: 共有アカウント・認証情報のパスワードローテーション
個人アカウントの処理が終わったあと、忘れられがちなのがこのステップです。
代表メールアドレス・会社の SNS アカウント・社外サービスの共有ログイン情報を退職者が知っていた場合、それらのパスワード変更が必要です。共有アカウントは特定の個人に紐づいていないため、オフボーディングの処理対象として認識されにくいのが原因です。
1Password・Bitwarden Business などのパスワードマネージャーを使っている場合は、Vault のアクセス権剥奪も合わせて実行してください。
退職日から30日以内に対応すること
当日に完了するものと、30日以内に対応するものを分けて考えると整理が楽になります。
M365 ライセンスの削除: Microsoft Learn の公式ドキュメントによると、ライセンス削除後30日間はデータが保持されますが、30日を超えると完全削除されます。Step 6 の引き継ぎ処理が完了したことを確認してから削除してください。
Google Workspace アカウントの削除: 停止（Suspend）から削除（Delete）へ移行します。オーナー権限の移管が完了していることを先に確認してください。
GitHub のメンバーシップデータ: GitHub Docs の記載によると、削除後のメンバーシップデータは3ヶ月間保存されます。3ヶ月以内であれば再招待によりデータを復元できます。
物理的なアクセスの確認: 入館カード・鍵・社用端末の返却確認は、IT 担当だけで完結しない場合があります。総務・HR と連携して、返却状況を記録しておいてください。
ローカルコピーへの法的対処: 前述のとおり、GitHub のローカルコピーはじめ、退職者が手元に持ち出したデータは技術的に強制削除できません。NDA や退職時の誓約書への署名を確認し、法的な根拠を記録として残しておくことが現実的な対処です。
SaaS台帳が整備されていない企業が踏む3つの落とし穴
この手順を属人化なく実行するには、前提となる環境整備が必要です。
落とし穴①: 部署独自契約のSaaSがアカウント台帳に存在しない
情シスが把握していない SaaS は、情シスには削除できません。
ソニービズネットワークスの調査では、退職者アカウント管理の対策が不十分と回答した担当者は17.7%、SaaSに起因するセキュリティリスクを感じる担当者は88.0%でした。「リスクは感じているが対策が追いついていない」という状態が多数派です。
SaaS 可視化ツールを導入している場合でも、API 連携できる SaaS のみが同期対象となり、クレジットカード払いの部門独自契約は検出できないことがほとんどです。
落とし穴②: MFA端末の放置
退職者の個人スマートフォンが MFA の認証器になっている場合、サインインブロックの前に MFA 登録の削除が必要です。
パスワードをリセットするだけでは、MFA デバイスを持っている退職者が認証を突破できるケースがあります。Step 1 で MFA 登録の削除を明示的に手順に入れているのはこの理由です。
落とし穴③: 自動化ツールの導入コストを過小評価する
「Okta を入れれば自動化できる」という話はよく出ますが、費用感を正確に見ておく必要があります。
Okta の料金体系（2026年6月時点）は、Starter が月額6ドル/ユーザー、Core Essentials が月額14ドル/ユーザー（ライフサイクル管理は Core Essentials 以上で標準含有）、Essentials が月額17ドル/ユーザーとなっています。
ただし、AccessOwlのブログ記事によると、100人・80SaaS ツールの企業の実際の年間コストが、Okta 単体の見積もり20,400ドルに対してトータルで220,400ドルに膨らんだという試算があります。SSO Tax と呼ばれる問題で、SaaS 側がシングルサインオン対応プランを上位プランに限定しているために発生します。
Microsoft Entra ID のライフサイクルワークフロー（退職者ワークフローの自動化機能）については、Microsoft Learn の公式ドキュメントによると Entra ID Governance ライセンスが別途必要で、M365 Business Premium には含まれていません。価格は公式ページでは非公開で、問い合わせ対応となっています。
自動化の前提条件として、人事システムとの SCIM または API 連携が必要です。HR データが Excel で管理されている環境では、自動化の恩恵を受けるまでの初期整備コストが予想より高くなります。
このチェックリストをSOPとして組織に定着させるために
SaaS台帳が整備されていれば、当日の Step 5 は「台帳を上から見ていく」だけで完了します。台帳がない場合は、退職者が出るたびに HR・上長・各部門長への確認コストが発生し続けます。
退職者対応を属人化させない、ということは単に「手順書を作る」ことではありません。「誰が抜けても同じ品質で実行できる状態を作る」ことです。
損得の観点で整理すると、退職者アカウントの削除漏れ1件が内部不正に発展した場合のリスク——IPA調査では営業秘密漏えい発生企業が35.1%——と、SOP を整備する初期コストを比較すると、整備後は次の退職者から即座に効きます。
情シス担当者として「退職者が出るたびに不安になる」状態から、「チェックリスト通りに動けば確認が終わる」状態への移行は、上長・監査への説明責任という観点でも意味があります。
次の退職者がいつ出るかはわかりません。整備が遅れている間は、次の退職が潜在的なリスクになり続けます。ただ、「すべてを一度に整備しなければいけない」わけではありません。まず現状どこに穴があるかを把握することが、最初のステップです。
今すぐ全部を整備する必要はありません。まず現状の SaaS 台帳と権限マップがどうなっているかを棚卸しするところから始められます。
現状のSaaS台帳と権限マップ、一度棚卸ししてみませんか
台帳が未整備の状態でも構いません。どこに穴があるかを整理するところからお手伝いします。
よくある質問
Q. パスワード変更だけでは足りないのですか？
A. パスワードリセットは次回ログイン時にしか効きません。既存のブラウザセッションやモバイルアプリのアクセストークンは生き続けます。M365の場合、正解操作は Microsoft Entra 管理センターでの「サインインのブロック」です。
Q. SaaS台帳が存在しない場合はどこから始めますか？
A. HR からの入社時の権限付与記録・クレジットカード明細・請求書をスキャンすることが起点になります。部署ごとの独自契約が見えてくることが多いです。
Q. Okta を導入すれば自動化できますか？
A. ライフサイクル管理機能は Core Essentials（月額14ドル/ユーザー・2026年6月時点・Okta公式）以上で標準含有されています。ただし、SSO Tax の影響で実際の導入コストが見積もりを大幅に上回るケースがあります（AccessOwl調査: 100人・80SaaS企業で Okta 単体見積もり20,400ドル → 実際220,400ドルの試算）。人事システムとの SCIM 連携が整備されていない場合は、初期コストがさらに高くなります。
Q. Google Workspace のアカウントはすぐ削除してよいですか？
A. ドライブのオーナー権限を後任者へ移管してから削除してください。削除後はユーザーが所有していたファイルへのアクセスができなくなります（20日後にファイル削除が始まります）。停止（Suspend）を先に実行し、引き継ぎが完了してから削除（Delete）に移行するのが正しい順序です。
Q. GitHub のローカルコピーはどう対処しますか？
A. GitHub Docs が明記しているとおり、退職者の手元にあるローカルコピーは技術的に強制削除できません。NDA や退職時の誓約書への署名を確認し、法的な対処を記録として残すことが現実的な対応です。