IT/AI救済センター

コラム / セキュリティ /

退職者のIT資産棚卸し完全マニュアル ─ Google Workspace・Microsoft 365・SaaS 30本の解約と権限剥奪の48時間

📖 約12分 / 公開日: 2026/05/28

退職者対応で最も多い事故は、メール転送設定の放置でも、Slackの最終投稿でもありません。退職から2週間以上、本人のアカウントが生きたまま外部から到達可能な状態が続くこと。これが現場で頻発しています。

中小企業のIT管理者を支援する中で、退職処理が完了した「つもり」のアカウントを棚卸ししたことがあります。従業員45名の会社で、退職済み12名のうち7名のGoogle Workspaceアカウントが停止されておらず、うち3名は退職後1ヶ月以上、外部メールクライアントから受信可能な状態でした。1名はGitHub組織のメンバーに残り、private リポジトリへの read 権限が生きていました。当人が悪意を持っていなくても、退職者のPCがマルウェアに感染すれば、その瞬間に企業データへ到達される経路になります。

退職者処理を48時間で終わらせる、というのが現実的な目標値です。即日(数時間以内)にやるべきこと、24時間以内にやるべきこと、48時間以内に完了させること、72時間以内に解約コストを最終化すること。この4段階で整理すると現場が回ります。

## 退職通知から2時間以内 ─ 最優先の権限停止

最初に止めるのは認証基盤の起点です。Google Workspace か Microsoft 365、どちらをID Provider にしているかで初手が変わります。Google Workspace の場合、管理コンソールから対象ユーザーを「停止(Suspend)」する。削除ではない。停止であれば、メール・Drive・カレンダーへのアクセスは即座に切れますが、データは保持されます。Microsoft 365 なら、Entra ID(旧Azure AD)でサインインをブロックし、すべてのアクティブセッションを失効させる。これだけで SAML / OIDC 連携している大半の SaaS から弾き出されます。

認証基盤を止めただけでは不十分です。SAML を通っていないアプリ、個別のローカルアカウントを持つサービスがある。Slack のレガシーゲストアカウント、GitHub の Personal Access Token、AWS IAM ユーザー、データベースの直接接続アカウント。これらは個別の停止が必要です。特に GitHub は、本人の個人アカウントが組織メンバーとして招待されている場合、組織から削除しない限り private リポジトリへのアクセスが残り続けます。

パスワードマネージャの共有Vaultにも注意が必要です。1Password Business、Bitwarden、LastPass のいずれを使っていても、退職者が共有Vault に格納されていたパスワードを記憶している可能性がある。共有していた SaaS のパスワードはすべて即日変更してください。MFA で守られていても、SMS や認証アプリの引き継ぎが正しく行われていない場合、リカバリ経路から侵入される可能性があります。

## 24時間以内 ─ デバイスと外部キーの失効

貸与PCは物理回収を待たず、リモートで MDM(Jamf、Intune、Kandji など)からロックします。回収前にローカル管理者権限を剥奪し、企業データを格納するボリュームを暗号化キーごと無効化する。BitLocker や FileVault のリカバリキーを企業側が保持しているか、ここで初めて分かることが多い。退職処理は、平時の管理体制の品質検査でもあります。

APIキー・アクセスキー・サービスアカウントの棚卸しが、ここで本気の負荷になります。AWS IAM のアクセスキー、Google Cloud のサービスアカウントキー、Stripe / Twilio / SendGrid / OpenAI / Anthropic の API キー。退職者個人の名前で発行されているキーは、すべてローテーション対象です。CI/CD パイプライン、cron ジョブ、Lambda 関数、Cloudflare Workers のシークレットに紛れ込んでいたら、置き換え作業も発生する。これを退職通知の段階で予測できる企業は少ないのですが、退職者がインフラ担当だった場合、ここの工数が数日単位で膨らみます。

メール転送ルールは見落とされやすい盲点です。退職者が事前に外部アドレスへの自動転送を仕掛けていた場合、アカウントを停止しても転送設定によっては機能し続けるケースがあります。Google Workspace なら管理者監査ログから転送設定の一覧を抽出してください。Microsoft 365 なら Exchange Online の Transport Rule と個別のメールボックスルールの両方を確認する。

## 48時間以内 ─ SaaS 30本の棚卸しと解約

中小企業の現場で実数を見ると、社員1人あたりの個別 SaaS 契約は平均で18〜32本です。SSO 連携している主要なものが10本、個別ID/PWで使っているマイナーなものが20本以上ある、というのが典型的な姿。退職者の SaaS 棚卸しを真面目にやると、IT 管理者が把握していなかったツールが必ず2〜5本出てきます。

棚卸しの起点は3つ。SAML/OIDC ログをID Provider から抽出する、経費精算システムからSaaS の支払い履歴を引く、当人のメールから 「ようこそ」「Welcome」「Invitation」を含むメールを抽出する。3つ目が最も効きます。退職者本人のメールボックスを読むのは抵抗があるかもしれませんが、就業規則と情報セキュリティポリシーに明記されていれば実施可能です。

ライセンス課金型のSaaS は、退職者ライセンスをそのまま放置すると年間で重い金額になります。Slack Business+ が1ユーザー1,925円/月、Notion Plus が1,650円/月、Figma Organization が4,500円/月、Asana Business が3,300円/月、Linear Standard が10ドル/月、1Password Business が7.99ドル/月。これらを退職者分そのまま継続すると、1名あたり年間で20〜30万円台になります。退職者5名分を1年放置していたら、それだけで100万円超の無駄が発生します。

ライセンスを「他の人に振り替えて使う」というのも一定範囲では合理的ですが、ベンダー側で「アクティブユーザー数」で課金されている場合、退職者シートを残しても課金が止まらない契約が混じります。年次契約で前払い済みのものは、解約しても返金がないことが多い。解約効果が出るのは更新月の前月までに通知できたケースだけ。ここを誤ると「解約手続きしたのに翌年も請求された」という事故が起きます。

## 72時間以内 ─ 知識資産の保全と引き継ぎ

権限剥奪が終わったあと、退職者しか知らない知識を回収するフェーズに入ります。Notion / Confluence / Google Drive の個人スペースに置かれている資料、Slack の DM で完結していた業務の経緯、特定のチームメンバーしか知らないシステム構成。これらは本人がいるうちに、または最終出社日の前後で吸い上げる必要があります。

業務知識の棚卸しテンプレートを30分で書ける形にしておくと、退職者本人にも書いてもらいやすい。担当業務、現在止まっているタスク、外部ベンダー連絡先、契約更新日と契約担当者、本人だけが持っているアカウント、個人で契約していて会社業務に使っていたツール。この6項目で大半が拾えます。

## 棚卸しのコスト感と推奨ツール

手作業でやり切ると、退職者1名あたり管理者の工数で6〜10時間かかります。年間退職者が10名いる規模だと、それだけで管理者の1ヶ月分以上の時間が消える。これを自動化したい場合、現実的な選択肢は3つあります。

BetterCloud は SaaS Operations の専用ツールで、Google Workspace と Microsoft 365 を起点に100本以上のSaaSの権限管理を自動化できます。中小企業向けの最小構成で月20万円台から。Torii は SaaS 棚卸し特化で、シャドーITの発見が強い。月15万円台から。Nudge Security はオフボーディングのワークフロー自動化が得意。月10万円台から始められます。

社員50名以下の企業で月20万円の自動化ツールは過剰、と判断するのが普通です。その場合、棚卸し対象 SaaS のリストを Notion か Google Sheets で台帳化し、退職処理時のチェックリストを Asana / Linear / Notion のテンプレートとして保持する。退職処理開始時にテンプレートからタスク群を複製する。これだけで実務はかなり回ります。

## 退職者対応で絶対にやってはいけない3つのこと

1つ目は、退職者アカウントの即時削除。データが消えると、税務・労務・法務の調査が必要になった時に取り戻せない。停止(Suspend)にとどめ、3〜12ヶ月の保管期間を経てから削除する運用にしてください。日本の労働基準法では賃金台帳の保管が3年、税法では帳簿の保管が7年、と業務記録の保管期間がそれぞれ定められています。メールやチャットも業務記録として扱われる場合があります。

2つ目は、退職者本人にパスワード変更を依頼すること。退職者が変更後のパスワードを管理者に共有する保証はなく、共有された後で再度変更される可能性もある。管理者側で強制的にパスワードリセットし、再ログインを不可にする運用以外、選択肢はありません。

3つ目は、引き継ぎを口頭で済ませること。「あの件は引き継ぎ済みです」と言われて、3ヶ月後に「誰も知らない」が発覚する事例を何度も見ています。最終出社日の前日までに、引き継ぎ完了の記録を文書化し、引き継ぎ先の本人に「受け取りました」とテキストで残してもらう。これだけで事故が3割減ります。

## 退職対応を組織能力として持つ

退職者処理は、平時の情シス体制と SaaS 管理品質の鏡です。退職処理が乱れる組織は、平時のアクセス管理も乱れている。逆に、退職処理が48時間で完了する組織は、入社時のオンボーディング、平時の権限管理、シャドーITの早期発見も、ほぼ間違いなく機能しています。

退職対応のチェックリストを整備するのは、退職処理のためではなく、組織のIT統制を可視化し、平時の運用品質を上げるための投資です。中小企業がISMS(ISO 27001)取得を進める際にも、A.9(アクセス制御)とA.8(資産管理)の要件で必ず確認される領域。整備しておけば、認証取得時にもそのまま使えます。

退職処理で困っている、または、退職者のアカウントが正しく停止されているか確信が持てない、という状態にあるなら、今すぐ Google Workspace か Microsoft 365 の管理コンソールを開いて、停止済みユーザー一覧と過去90日のサインインアクティビティを照合してください。停止済みのはずのアカウントから直近30日にサインインがあれば、停止処理の漏れか、または外部からの不正アクセスのいずれかです。後者であれば、48時間以内にインシデント対応の体制を立ち上げる必要があります。

関連コラム

具体的な状況をご相談ください

記事の内容に該当しそうなら、まずは60分の無料相談でご相談を。

60分無料相談を予約
緊急 AI診断 60分予約