結論は、退職処理の完了条件を「Entra IDの無効化」だけにしないことです。IDソース、Entra ID、SSO、SCIM、SaaS側ID、ローカル認証、セッションを分け、最後に対象SaaSで利用不能になったことを確認します。
なぜアカウントが残るのか
Microsoft Entra IDのサインインをブロックすれば、Entra IDを通る新しい認証は制御できます。しかし、SaaS側のユーザーオブジェクトを無効化または削除するには、別途プロビジョニングの設計が必要です。さらに、SaaSがローカル認証を持つ場合や、既存セッションをどう扱うかは、対象製品の仕様確認が必要です。
公式情報で確認できること
Microsoftは、EntraプロビジョニングサービスがSCIM 2.0エンドポイントを使用して、SaaSアプリのユーザーとグループを作成・更新・削除できると説明しています。一方、ギャラリーアプリでは最適化により動作が異なる場合があるため、個別アプリのチュートリアル確認が必要です。
現場で起きる典型的なずれ
人事連絡、Entra ID無効化、SaaS失効の完了時刻が別々です。
退職票には「処理済み」、Entra IDは無効、プロビジョニングログも成功。それでも、対象SaaSの既存セッション、個人アクセストークン、ローカル認証、直接付与ロールが残ることがあります。担当者が見るべきなのはチェック欄ではなく、各制御が実際に失効した時刻と確認者です。
最初に確認する六つの点
- 退職情報の確定時刻と、Entra IDへ反映される時刻
- 対象SaaSへの割り当てがユーザー単位かグループ単位か
- SCIMプロビジョニングの対象範囲と最終実行結果
- 対象外になったユーザーへ送られる操作が無効化か削除か
- SaaS側にEntra IDを通らないローカル認証があるか
- 残存セッションやAPIトークンの失効方法が定義されているか
「SSOできない」だけで削除完了と判断すると、アプリ側の利用者一覧、課金対象、データ所有権、ワークフロー担当者に退職者が残る可能性があります。実際の残存可否はSaaSごとに確認します。
解決までの進め方
- 対象アプリを特定する退職時に停止すべきSaaS、管理者アカウント、共有ID、API資格情報を一覧化します。
- 起点とスコープを確認する人事情報からEntra ID、グループ、アプリ割り当てまでの連鎖を図にします。
- 削除動作を分けるサインインブロック、割り当て解除、無効化、論理削除、物理削除を区別します。
- 試験するテストユーザーで正常系、対象外化、削除、再雇用、誤削除時の復旧を確認します。
- 完了証跡を残す誰が、いつ、何を確認し、例外を誰が承認したかを記録します。
支援で整備する主な成果物
退職時ID処理表、SaaS別失効方式一覧、SCIMスコープ・属性表、削除試験計画と結果、例外台帳、責任分界表、監査提示用の証跡索引。
相談が必要な状態
- 退職者一覧とSaaS利用者一覧を突合したことがない
- SCIMは有効だが、対象外化や削除の試験記録がない
- ローカルIDとSSO利用者が混在している
- アカウント削除が各部門の手作業に依存している
- 監査で退職日とアクセス停止時刻を説明できない
確認した公式情報
Microsoft Learn：How Application Provisioning works in Microsoft Entra ID
ページ更新日：2025年3月4日。確認日：2026年9月3日。
機能、ライセンス、削除動作はアプリ、契約、テナント構成により異なります。個別環境を確認せずに動作を断定しません。