「退職した社員が、いまだに前職の Slack を見られる」「辞めたエンジニアの GitHub アカウントが、ソースコードにアクセスできる状態で残っている」――こうした状態は、特別な事故ではなく、多くの中堅企業の「普通」です。 IPA（情報処理推進機構）が公表する内部不正の調査では、営業秘密の漏えい経路として「中途退職者による漏えい」が最多に挙がっています（IPA「企業における営業秘密管理に関する実態調査」）。退職そのものより、退職時にアカウントを止めきれていないことが、実害につながります。

連載「バイブコーディング危機」は、ここまでで AI に自社システムを書かせるリスクと、その防衛策の実装を整理してきました。本記事の第 19 回は、運用の基盤にあたるテーマ――退職時の SaaS アカウント剥奪（オフボーディング）です。バイブコーディングで自社システムやツールを増やした中堅企業ほど、「誰がどのサービスに、どんな権限でアクセスしているか」を把握しきれず、退職時に止め忘れが起こりやすくなります。

本記事では、退職時の剥奪が漏れる 5 つの構造、SSO + SCIM による自動失効の仕組み、30 分で終わる Offboarding チェックリスト、SLA（対応期限）の設計、元社員アクセスの検知、多要素認証の鍵回収、FAQ を、IPA 内部不正防止ガイドライン・NIST SP 800-63・各 ID 基盤の公式文書を一次ソースに整理します。「人を疑う」のではなく、辞めた人にアクセス権が残らない仕組みを当たり前にしましょう、という趣旨です。

目次

  1. なぜ退職時のアカウント剥奪は漏れるのか
  2. 剥奪が漏れる5つの構造
  3. SSO + SCIMで「自動失効」を実現する
  4. 30分で終わるOffboardingチェックリスト
  5. Offboarding SLA（対応期限）の設計
  6. 元社員アクセスの検知と多要素鍵の回収
  7. 入社時（オンボーディング）から仕込む
  8. 中堅・中小企業が陥りやすい5つの失敗
  9. 国内・国際の文脈：IPA・NIST・ID基盤
  10. よくある質問（FAQ 10問）
  11. 参考一次ソース
  12. まとめ
  13. 関連記事

なぜ退職時のアカウント剥奪は漏れるのか

退職時のアカウント剥奪は、一見すると単純な作業に見えます。しかし実際には、サービスの数だけ止める作業が発生し、その全体像を誰も把握していないことが、漏れの根本原因です。

サービスが増えすぎて全体が見えない

クラウドサービス（SaaS）は、部署ごと・プロジェクトごとに、情シスを通さず導入されることが珍しくありません。Slack・GitHub・AWS・各種 SaaS・自社開発したツール――その数は中堅企業でも数十から百を超えることがあります。退職時に「全部止めた」と言える状態にするには、そもそも全サービスのリストがないと不可能です。

退職処理は「人事」と「IT」の間で落ちる

退職処理は、人事部門と情シス部門の連携で進みますが、その間に作業が落ちることがよくあります。人事は「退職手続きは済んだ」と思い、情シスは「連絡が来ていないから止めていない」という状態です。「誰がいつまでに何を止めるか」が決まっていないと、止め忘れが起こります。

個別 ID 管理だと止め忘れる

各サービスに個別のアカウントを作っている場合、退職者 1 人につき数十のアカウントを 1 つずつ無効化する必要があります。手作業の数が多いほど、止め忘れの確率は上がります。特に、めったに使わないサービスや、本人しか使っていなかった自社開発ツールは見落とされがちです。

退職者は最大の内部リスク要因の一つ

IPA の調査では、営業秘密の漏えい経路として中途退職者が最も多く挙げられています。これは退職者個人を疑うべきという話ではなく、退職という節目でアクセス権を確実に止める仕組みがないことが、構造的なリスクだということです。

要点：退職時の剥奪漏れは「担当者がうっかりした」個別の失敗ではなく、サービスの可視化・部門連携・自動化の欠如という構造の問題です。仕組みで解く必要があります。

剥奪が漏れる5つの構造

退職時にアクセス権が残ってしまう典型的なパターンを 5 つ整理します。自社で当てはまるものがないか確認してください。

1. 個人アカウントで契約した SaaS

担当者が自分のメールアドレスや個人名義で契約・登録した SaaS は、会社が把握できず、退職時に止められません。クレジットカードの引き落としだけが続く、ということも起こります。

2. 共有アカウント・共有パスワード

複数人で 1 つのアカウントを共有していると、退職者だけのアクセスを止められません。パスワードを変えない限り、退職後もログインできてしまいます。

3. 自社開発（バイブコーディング）ツールのアカウント

社内で作った業務ツールには、ID 基盤と連携していない独自のログイン機能がついていることが多く、退職時の一括失効の対象から漏れます。作った本人が退職する場合、誰も止め方を知らない、ということすら起こります。

4. API キー・アクセストークン・SSH 鍵

人のアカウントを止めても、その人が発行した API キーやアクセストークン、SSH 鍵が生きたままだと、システム経由でアクセスが続きます。クラウドや GitHub のトークンは特に見落とされがちです。

5. 私物端末・私物クラウドに残ったデータ

私物の端末やクラウドストレージに業務データが同期されていると、アカウントを止めてもデータ自体は手元に残ります。BYOD（私物端末の業務利用）を認めている場合は、退職時のデータ削除の取り決めが必要です。

構造何が残るか主な対策
個人アカウント契約会社が知らない SaaS許可サービスの一元管理・棚卸し
共有アカウント退職者も使えるログイン個別アカウント化・SSO 化
自社開発ツールID 基盤外のログインID 基盤連携・退職時の手動停止リスト
API キー・鍵システム経由のアクセス発行台帳・退職時の失効
私物端末・クラウド手元のデータBYOD 規程・退職時のデータ削除確認

SSO + SCIMで「自動失効」を実現する

剥奪漏れを根本から減らす最も効果的な方法が、SSO（シングルサインオン）と SCIM（アカウント自動連携）の組み合わせです。

SSO（シングルサインオン）とは

SSO は、1 つの ID で複数のサービスにログインできる仕組みです。社員は ID 基盤（Microsoft Entra ID / Google Workspace / Okta / OneLogin など）に 1 回ログインすれば、連携した各 SaaS に個別のパスワードなしでアクセスできます。退職時には、ID 基盤のアカウントを 1 つ止めるだけで、連携した全サービスへのログインを一括で止められます。

SCIM（自動プロビジョニング）とは

SCIM（System for Cross-domain Identity Management）は、ID 基盤での利用者の追加・変更・削除を、各 SaaS へ自動で反映する標準的な仕組みです。SSO がログインを束ねるのに対し、SCIM はアカウントそのものの作成・無効化を自動化します。退職で ID 基盤のアカウントを無効化すると、SCIM 連携した各 SaaS のアカウントも自動で無効化されます。

SSO と SCIM の役割の違い

仕組み役割退職時の効果
SSOログインを 1 つの ID に束ねるID 基盤を止めれば各サービスにログインできなくなる
SCIMアカウントの作成・無効化を自動連携各サービスのアカウント自体が自動で無効化される

両方を組み合わせると、「ID 基盤のアカウントを 1 つ無効化すれば、退職者は連携した全サービスから締め出される」状態になります。これが「漏れゼロ化」の核心です。

標準規格に支えられている

SSO は SAML や OIDC（OpenID Connect）、アカウント連携は SCIM という標準規格で支えられています。NIST のデジタルアイデンティティガイドライン（SP 800-63 シリーズ）は、こうした認証とフェデレーション（ID 連携）の技術要件を整理しており、ID 基盤を設計する際の参照になります（NIST SP 800-63 Digital Identity Guidelines）。

すべてを SSO に載せきれない場合

現実には、SSO や SCIM に対応していない SaaS や自社開発ツールも残ります。これらは 「SSO に載らないサービスのリスト」を別途作り、退職時に手動で止める対象として明示します。「すべてを自動化できない」前提で、自動化できないものを可視化しておくことが大切です。

30分で終わるOffboardingチェックリスト

ID 基盤が整っていれば、退職時の剥奪は 30 分程度で完了できます。以下は中堅企業向けのチェックリスト例です。最終出社日の当日、または退職時刻に合わせて実施します。

即時（〜10分）：アクセスを止める

  1. ID 基盤のアカウントを無効化：SSO/SCIM 連携の全サービスが一括で止まる
  2. メール・チャットのログインを止める：Microsoft 365 / Google Workspace のサインインをブロック
  3. VPN・社内ネットワークのアクセスを止める

個別停止（〜20分）：SSO に載らないものを止める

  1. SSO 非連携の SaaS を個別に無効化：「SSO に載らないリスト」に沿って 1 つずつ
  2. 自社開発ツールのアカウントを停止：ログイン機能を持つ社内ツール
  3. GitHub / クラウドのトークン・API キー・SSH 鍵を失効
  4. 共有アカウントのパスワードを変更：退職者が知っていた共有 ID

確認・記録（〜30分）：止め残しと回収

  1. 物理的な鍵・社員証・セキュリティキーを回収：FIDO2 キーなどの認証デバイス
  2. 私物端末・私物クラウドのデータ削除を確認：BYOD 規程に沿って
  3. 実施結果を記録：誰が・いつ・何を止めたかを台帳に残す

チェックリストを「使える」ものにする

このチェックリストは、退職が決まった時点で人事から情シスへ自動で連絡が回る仕組みとセットにすると機能します。連絡が口頭やメール任せだと、繁忙期に抜けます。退職処理のワークフローに、IT 剥奪のステップを組み込むことが、漏れをなくす近道です。

Offboarding SLA（対応期限）の設計

「いつまでに止めるか」を決めていないと、退職後何日も、ときには何ヶ月もアカウントが生き続けます。これを防ぐのが SLA（対応期限）の設計です。

退職の種類で期限を分ける

退職の種類アクセス停止の目安
通常退職（円満・引き継ぎあり）最終出社日の終業時刻に停止
即日退職・トラブル退職通知を受けた即時に停止
異動・休職必要な権限のみ残し、不要権限は即時調整

トラブルを伴う退職では、最終出社を待たずに即時停止できる体制が重要です。即時停止できるかどうかは、SSO/SCIM が整っているかで大きく変わります。

SLA を守れる体制にする

SLA は数字を決めるだけでなく、守れる体制とセットにします。

  • 退職決定 → 人事から情シスへ自動通知（ワークフロー化）
  • 剥奪担当者と代理を決めておく（担当者が休みでも止まらない）
  • 月次で「退職者のアカウントが残っていないか」を点検する

退職者アカウントの定期点検

SLA を設定しても、運用がずれることはあります。月次で、退職者リストと有効アカウントを突き合わせる点検を行い、止め残しがないかを確認します。これは連載第 21 回（ログ保存・監査体制）や第 23 回（IT 棚卸し）とも直結します。

元社員アクセスの検知と多要素鍵の回収

剥奪を徹底しても、見落としは起こり得ます。「止め忘れがあっても気づける」仕組みを持つことで、被害を最小限にできます。

退職後のログインを検知する

ID 基盤や主要 SaaS のログインログを監視し、退職者のアカウントでログインが発生したら警告するルールを設定します。多くの法人向け ID 基盤には、こうした条件付きアクセスやアラートの機能があります。退職者の最終出社日以降のサインインは、止め残しか、不正アクセスのサインです。

多要素認証デバイスの回収

FIDO2 セキュリティキーなどの物理的な認証デバイスは、退職時に必ず回収します。回収できない場合は、ID 基盤側でそのデバイスの登録を削除します。スマートフォンの認証アプリ（TOTP）も、アカウント無効化とあわせて無効化します。

サービスアカウント・共有鍵の棚卸し

退職者が管理していたサービスアカウント（人ではなくシステム用のアカウント）や、共有していた鍵・トークンは、退職を機に所有者の付け替えと再発行を行います。「前任者が作ったまま誰も触れない鍵」を残さないことが、長期的なリスク低減につながります。

内部不正への抑止力

退職時の剥奪を確実に行い、それを社内に周知することは、内部不正への抑止力にもなります。「辞めても権限が残る」状態は不正の余地を生みますが、「退職時に確実に止まる」運用が定着すれば、その余地自体が消えます。

入社時（オンボーディング）から仕込む

退職時の剥奪をスムーズにする鍵は、実は入社時の設計にあります。

入社時に SSO 経由で権限を付与する

入社時から、すべての業務アクセスを ID 基盤経由（SSO/SCIM）で付与しておけば、退職時に「ID 基盤のアカウントを止めれば全部止まる」状態が自然に保たれます。入社時に個別アカウントをばらまくと、退職時に回収できなくなります。

権限は「最小限」から始める

入社時に必要以上の権限を渡さない「最小権限の原則」を徹底すると、退職時に止めるべき範囲も小さくなり、漏れにくくなります。これは連載第 3 回（認可漏れ）で扱った考え方と同じです。

入社・異動・退職を「同じ台帳」で管理する

入社・異動・退職を、同じアカウント台帳の上で管理すると、「今この人が持っている権限の全体像」が常に見える状態になります。退職時には、その台帳に沿って止めるだけで済みます。

中堅・中小企業が陥りやすい5つの失敗

1. 退職連絡が情シスに届かない

人事だけで退職処理が完結し、情シスに連絡が来ないケースです。退職処理のワークフローに IT 剥奪のステップを組み込みます。

2. SSO を入れずに個別アカウントを止め回る

サービスごとに手作業で止めるため、必ずどこかを止め忘れます。SSO + SCIM で一括失効できる状態を目指します。

3. API キー・トークンを止め忘れる

人のアカウントは止めても、その人が発行した鍵やトークンが生き残るケースです。発行台帳を作り、退職時に失効します。

4. 共有アカウントのパスワードを変えない

共有 ID のパスワードを変えないため、退職者がログインし続けられるケースです。共有アカウントは個別化し、やむを得ない場合は退職時にパスワードを変更します。

5. 止めた「つもり」で点検しない

剥奪したつもりでも、止め残しは起こります。月次で退職者リストと有効アカウントを突き合わせる点検を行います。

国内・国際の文脈：IPA・NIST・ID基盤

退職時のアカウント管理は、国内外の枠組みでも重視されています。

IPA「組織における内部不正防止ガイドライン」

IPA は「組織における内部不正防止ガイドライン」を公開しており、退職などで不要になった ID とアクセス権をただちに削除することを求めています（IPA「組織における内部不正防止ガイドライン」）。同ガイドラインは、10 の観点・33 項目の具体的な対策を整理しており、退職時の権限失効はその中核に位置づけられています。中途退職者が営業秘密漏えいの最多経路であるという調査結果も、対策の重要性を裏づけます。

NIST「SP 800-63 Digital Identity Guidelines」

米 NIST の SP 800-63 シリーズは、認証（800-63B）とフェデレーション（800-63C）の技術要件を整理しています（NIST SP 800-63 Digital Identity Guidelines）。SSO/SCIM を含む ID 基盤を設計する際の国際的な参照となります。

ID 基盤各社の公式文書

Microsoft Entra ID・Google Workspace・Okta などの ID 基盤は、SSO・SCIM・条件付きアクセスの設定手順を公式に公開しています（Microsoft「アプリのプロビジョニング（SCIM）」）。自社で導入する際は、利用する基盤の最新の公式ドキュメントを一次情報として確認してください。

よくある質問（FAQ 10問）

Q1. うちは小さい会社なので、SSO まで入れる必要はないのでは？

A. 規模が小さくても、SaaS の数は意外に多く、退職時の止め忘れは起こります。まずは Microsoft 365 や Google Workspace に含まれる ID 基盤機能を使い、主要なサービスから SSO 化するだけでも、剥奪漏れは大きく減ります。

Q2. SSO を入れれば、退職時は何もしなくてよいのですか？

A. ほぼ自動化できますが、SSO に対応していない SaaS や自社開発ツール、API キー・共有アカウントは残ります。「SSO に載らないリスト」を作り、退職時に手動で止める対象として管理してください。

Q3. 退職した社員がまだログインできるのに気づきました。今すぐ何をすべき？

A. まず ID 基盤のアカウントと、把握できる全サービスのアクセスを即時停止してください。次にログインログを確認し、退職後にアクセスがなかったかを調べます。被害が疑われる場合は、関係者と相談して記録を保全します。

Q4. API キーや SSH 鍵まで管理するのは大変では？

A. 大変ですが、人のアカウントだけ止めても鍵が生きていれば意味がありません。誰がどの鍵・トークンを発行したかの台帳を作り、退職時に失効する運用を最初に決めておくと、負担を平準化できます。

Q5. 即日退職やトラブル退職には、どう備えればよいですか？

A. 最終出社を待たず、通知を受けた即時にアクセスを止められる体制が重要です。これは SSO/SCIM が整っていれば「ID 基盤のアカウントを 1 つ止める」だけで実現できます。即時停止できるかどうかが、トラブル退職への備えの差になります。

Q6. 私物端末で仕事をしていた社員の退職時は、どうすればよいですか？

A. BYOD（私物端末の業務利用）を認めている場合は、退職時に業務データを削除する取り決めをあらかじめ規程化しておきます。可能なら、業務データを端末に残さない仕組み（クラウド側に置く・MDM で管理する）を入社時から用意します。

Q7. 共有アカウントを使っているのですが、どう管理すればよいですか？

A. 原則は個別アカウント化です。どうしても共有が必要な場合は、退職時にパスワードを変更する運用を徹底し、誰が知っているかを台帳で管理します。共有アカウントは退職時の最大の漏れ要因の一つです。

Q8. 退職処理が人事と情シスでバラバラです。どう連携すればよいですか？

A. 退職処理のワークフローに「IT アクセス剥奪」のステップを明示的に組み込み、退職決定時に人事から情シスへ自動で連絡が回るようにします。口頭やメール任せにすると、繁忙期に抜けます。

Q9. どのくらいの期限で止めればよいという基準はありますか？

A. 通常退職なら最終出社日の終業時刻、即日・トラブル退職なら通知を受けた即時が目安です。重要なのは数字を決めるだけでなく、その期限を守れる担当・代理・通知の仕組みをセットにすることです。

Q10. まず何から始めればよいですか？

A. (1) 全 SaaS・ツール・鍵のリストを作る、(2) 主要サービスを SSO 化する、(3) 30 分チェックリストと退職連絡のワークフローを整える、の順がおすすめです。完璧を目指すより、止め忘れの多い箇所から潰していくのが現実的です。

参考一次ソース

  1. IPA「組織における内部不正防止ガイドライン」（不要 ID・権限のただちの削除）
  2. IPA「企業における営業秘密管理に関する実態調査」（漏えい経路として中途退職者が最多）
  3. NIST「SP 800-63 Digital Identity Guidelines」（認証・フェデレーションの技術要件）
  4. Microsoft「アプリのユーザープロビジョニング（SCIM）」
  5. Google Workspace「SSO とアカウント管理（管理者ヘルプ）」
  6. Okta「Lifecycle Management（SCIM プロビジョニング）」
  7. 経済産業省「サイバーセキュリティ経営ガイドライン」

まとめ

  1. 退職者が前職の SaaS にアクセスし続けられる中堅企業は珍しくなく、IPA の調査では中途退職者が営業秘密漏えいの最多経路です
  2. 剥奪が漏れるのは個人の失敗ではなく、サービスの可視化・部門連携・自動化の欠如という構造の問題です
  3. 漏れを根本から減らす核心は SSO + SCIM による自動失効――ID 基盤のアカウントを 1 つ止めれば全サービスから締め出せます
  4. SSO に載らない SaaS・自社開発ツール・API キー・共有アカウントは、別リストで手動失効の対象として管理します
  5. 退職時は 30 分チェックリストで「止める → 個別停止 → 回収・記録」を完了させます
  6. SLA（対応期限）を退職の種類別に決め、退職連絡の自動化・担当の二重化・月次点検とセットで守ります
  7. 入社時から SSO 経由・最小権限で権限を付与すれば、退職時の剥奪は自然にスムーズになります

退職は誰にでも訪れる節目です。「辞めた人にアクセス権が残らない」を当たり前にすることは、退職者を疑うためではなく、会社と取引先の情報を守り、辞めていく人を不要な疑いから守るためでもあります。

退職時のアカウント剥奪・ID基盤の整備を相談したい方へ

GXO の バイブコーディング監査 + ID 基盤整備サービスでは、中堅企業向けに次のようなご相談を承っています。

  • SaaS・ツール・鍵の棚卸し：いま誰が何にアクセスできるかの可視化
  • SSO + SCIM の導入支援：Microsoft Entra ID / Google Workspace / Okta などの選定・設定
  • Offboarding チェックリスト・SLA の設計：30 分手順と退職連絡ワークフローの整備
  • 元社員アクセスの検知設定：ログ監視・条件付きアクセスの設計
  • 入社時オンボーディングの最小権限設計：退職時に止めやすい権限付与の仕組みづくり

→ 30 分無料相談を予約する

関連記事

著者: GXO株式会社 初回公開: 2026 年 6 月 8 日 最終更新: 2026 年 6 月 8 日 連載: バイブコーディング危機 第 19 回（全 30 回予定 / 第 4 週・防衛策の実装編）