アカウント管理を台帳からアプリへ｜申請・付与・回収の確認

退職者のアカウントについて「回収を依頼しました」と記録されていても、その人がもうサインインできないとは限りません。依頼を受けた担当者が判断し、対象SaaSで操作し、反映後のアクセスを確かめて、ようやく回収を確認できます。

アカウント管理の台帳をシステム化するなら、従業員一人を一行で管理するだけでは足りません。利用者・サービス・権限の組み合わせを記録単位にし、「回収依頼済」「回収判断済」「反映確認済」を分けるのが要点です。ただし、アクセスを止めたあと、アカウントまで一律に削除してよいのでしょうか。退職後もデータを残す必要があるサービスでは、停止と削除の間に別の判断が要ります。

アカウント管理の台帳をシステム化する対象条件

この設計が向くのは、異動・退職を起点に総務や人事部門が回収を依頼し、情報システム部門などが複数のSaaSで操作する業務です。とくに、申請者・判断者・実施者が分かれる、回収操作が手動である、グループ経由の権限がある、退職後データの保持要否をサービスごとに決める、といった条件が重なる場合に適します。

一方、単一サービスだけを扱い、人事情報との連携によって停止まで自動化され、例外も対象サービス側で完結するなら、独自アプリに細かな状態を持たせる意義は小さくなります。先に「誰が、どのサービスの、どの権限を、どこまで確認するのか」を定めるべきです。Excelから移すこと自体が目的になっている場合は、Excel管理からシステムへ移行する進め方も判断材料になります。

アプリ化の対象は、採用や退職手続全体ではありません。人事イベントを受け取った後のアカウント起票から、対象ごとの実施照合までです。この境界を決めると、人事情報の原本とアカウント実施記録を二重管理せずに済みます。

「依頼済」と「反映確認済」の間を分ける

判断と実施を別状態にする根拠は、実際のアクセス管理製品にも見られます。以下の公式情報は2026年9月23日時点で確認したものです。Microsoft EntraやGoogle Workspaceの記述は各製品固有の仕様であり、その状態名や機能を自社アプリの標準機能として一般化するものではありません。ここでは、判断と反映が別工程になり得ること、停止・削除・保存が同じ処理ではないことを確かめる材料にします。

Microsoftのアクセスレビューの管理とアクセスレビューの完了では、レビュー担当者の判断後にレビューを終了し、変更を適用する工程が分かれています。手動適用時の状態もCompleted、Applying、Result appliedと移るため、判断が終わったことと、結果が反映されたことは同義ではありません。

しかも、結果を適用できない場合があります。Microsoftの公式情報は、同期元がオンプレミスのグループ、ネストしたグループ経由の権限、利用者を検出できない場合などを挙げ、否認された利用者がアクセスを保持することもあると説明しています。ならば、台帳側で「回収判断済」を最終状態にするのは危うい。対象サービス側で実際に利用できる範囲（実効アクセス）を照合し、成功または失敗を記録する必要があります。

業務アプリでは、たとえば次の状態を分けます。

• 回収依頼済：異動・退職を起点に対象レコードが作られ、実施担当へ依頼された
• 回収判断済：停止、割り当て解除、削除、保存継続などの処置が決まった
• 操作済：対象サービスで処置を実行したが、反映確認はまだ終わっていない
• 反映確認済：対象サービス側で意図した実効アクセスになったことを確かめた
• 要再対応：反映しない、別経路の権限が残る、確認できないなどの理由で再対応が必要になった

状態を増やすだけでは、回収の取りこぼしは防げません。誰が何を確かめたら次へ進めるかを定め、「反映確認済」へ変える際は確認者、確認日時、確認方法を残します。実施者と確認者を分ける運用なら、両者を同じ担当欄で上書きせず、別々に記録します。「要再対応」には失敗理由と次の担当を持たせ、自動連携の成否だけでは実効アクセスを確かめられない構成では、サービス側の管理画面や許可された確認手段による照合を完了条件にします。

一人一行ではなく、利用者・サービス・権限で記録する

一人の退職者に対して回収依頼は一件でも、処置は一つとは限りません。あるサービスでは個人の割り当てを外し、別のサービスではアカウントを停止し、さらに別のサービスではデータを保存してアクセスだけを止める可能性があります。利用者の行に「回収済」とだけ書くと、この差が消えます。

NIST SP 800-53 Rev. 5のAC-2 Account Managementは、各アカウントについて許可された利用者、グループ・ロール所属、アクセス認可を指定し、方針に従って作成・有効化・変更・無効化・削除する統制を示しています。また、アカウントが不要になった場合や利用者の退職・異動、利用目的や業務上その情報を知る必要性（need-to-know）の変更時に担当者などへ通知し、人事上のプロセスとアカウント管理を整合させること、組織が定めた頻度で適合性をレビューすることも示します。

この考え方から、条件に該当する業務では、レコードの主な単位を「利用者 × サービス × 権限」とする設計が導けます。持たせる項目は次のように整理できます。

付与記録も同じ単位で持つのは、回収時に「何が付いていたか」を照合するためです。異動では、利用者そのものを無効にするより、旧所属で不要になった権限だけを外し、新所属で必要な権限を付ける場合があります。利用者単位の完了欄では、その差分を表せません。

停止済・削除済・保存継続を決める判定表

では、退職後の処置をどう決めるか。一律削除なら簡単ですが、簡単であることと適切であることは同じではありません。Microsoft Entraのアプリへのアクセス除去方法では、特定利用者・グループの割り当て解除、全利用者のサインイン停止、アプリ自体の削除を別の方法として示しており、それぞれ対象と結果が異なります。退職者一人の回収を目的に、全利用者の停止やアプリ自体の削除を選ばないよう、操作対象を確認します。

さらにGoogle Workspaceの退職者アカウントのアーカイブでは、対応エディションとArchived Userライセンスがある場合、管理対象アカウントへのサインインを不可にしながら利用者データを保持できます。これは削除とは異なる、条件付きの保存方法です。

停止・削除・保存継続は、回収処理の進み具合ではなく、保持要件と対象サービスの仕様から決める処置です。条件を確認できる業務では、次の判定表を設計候補にできます。

この表は全社共通の必須状態でも、唯一の最小構成でもありません。削除前の保存義務、復旧可能性、契約エディションやライセンス、サービスの削除仕様を確認し、組織の方針に合わせて条件を確定します。とくに「保存継続」は単なる放置と区別し、アクセス停止を確認したうえで、保持の根拠と見直し条件を記録する必要があります。

データ処置の判断を保留する場合も、アクセス停止の可否は分けて確認します。停止できる条件が確認済みなら、停止結果と未決定のデータ処置を別々に記録します。

異動・退職から実施照合までの手順

運用は、人事イベントから対象を起票しただけでは閉じません。次の流れなら、依頼と実施の間にある停滞を見つけやすくなります。

1. 異動・退職の確定情報を受け、対象利用者の回収案件を起票する
2. 付与記録からサービスと権限の組み合わせを抽出し、回収対象を確定する
3. 各対象について、停止・削除・保存継続・判断保留を判定する
4. 処置と操作条件が確定した対象について、実施担当が対象サービスで操作し、操作結果を記録する
5. 対象サービス側の実効アクセスを照合し、反映確認済または要再対応にする
6. 全対象が反映確認済になったことを確認し、案件を完了する
7. 組織が定めた頻度のレビューで、現存アカウントと記録の不一致を確認する

案件の完了条件は「依頼を送った」でも「担当者が操作した」でもなく、対象となった組み合わせがすべて反映確認済であることです。ただし、判断保留が許される業務なら、それを隠して完了に含めず、責任者と未確認事項が見える状態で管理します。

通知や一覧も、この完了条件から逆算します。総務には案件全体の未完了、実施担当には自分の操作待ち、確認担当には操作済・未確認、管理責任者には判断保留と要再対応を見せます。単に期限超過を色付けするのではなく、次に動く担当と止まっている理由を結び付ける設計が必要です。

アプリ化の前に決める境界

既製SaaS、kintoneのような業務基盤、自社向けWebアプリのどれを選ぶかは、状態や例外をどこまで自社業務に合わせるかで変わります。選択肢の整理には、SaaS・kintone・独自開発の違いと選び方も参照できます。

自社向けWebアプリにする場合も、対象SaaSの停止や削除を自動で実行できるとは限りません。連携方法、移行対象、閲覧・更新権限、データ出力、各サービスでの操作と確認の範囲は、契約前に切り分ける必要があります。最初から全アカウントを対象にせず、手動回収が残り、担当分担と実施確認が必要な業務から範囲を定める方法もあります。

アカウント管理の台帳をシステム化する目的は、名簿を画面に置き換えることではありません。退職者一人の行に「依頼済」と残っている状態を、サービスと権限ごとの「反映確認済」へ分解し、停止済・削除済・保存継続の根拠まで追えるようにすることです。その条件が自社の運用に当てはまるなら、業務アプリの相談で、対象業務ひとつから記録単位と完了条件を整理できます。