退職・異動の人事データを起点に、各SaaSのアカウントと権限の残りをエージェントが確かめ、停止漏れの一覧と停止依頼票を作る

処理の起点を決める

人事システムに退職・異動が登録されたことを起点にします。 人事システムが登録の通知を Webhook で送れるなら、それを n8n で受けます。送れない場合は、人事システムから毎朝出力される退職・異動の一覧を読みます。

Webhook を使う場合も、毎朝の定時実行を残します。 通知が届かなかった登録を拾い直すためです。毎朝、前日までに登録された退職・異動と、処理済みの記録を突き合わせ、処理されていないものだけを流します。

確かめる日は1回ではありません。 退職は登録した日に一度、最終出社日の翌日にもう一度確かめます。登録の時点ではまだアカウントを使っているのが正常で、止まっていないことが問題になるのは最終出社日を過ぎてからです。 異動も、異動日の前と後で2回確かめます。

入力データを集める

質を決めるのは、台帳の「利用者を引く鍵」の列です。 SaaSによって、利用者をメールアドレスで引けるもの、独自のIDでしか引けないもの、表示名でしか探せないものがあります。鍵が分かっていれば、エージェントは最初から正しい引き方で道具を呼べます。

部署の標準の権限表は、異動のためだけに要ります。 異動先の標準に無い権限が、外す候補になります。この表が無いと、異動の確認は「全部残っている」としか言えません。

データの取得方法を決める

エージェントに渡す道具は4つで、すべて読み取りだけです。

Microsoft Graph のユーザー取得は、既定では一部のプロパティしか返しません。 既定で返るのは表示名やメールなど限られたもので、それ以外は $select でプロパティを指定する必要があるとされています。accountEnabled や部署は、$select に書かないと返りません。

アクセス許可は、アプリケーションの許可で User.Read.All が最小とされています。 退職日時の employeeLeaveDateTime を読むには User-LifeCycleInfo.Read.All が別に要るとされています。accountEnabled の読み書きの最小の組み合わせは User.EnableDisableAccount.All と User.Read.All とされていますが、この構成は書き込みをしないので、書き込みの許可は付けません。 読み取りに要る許可は、自社の環境で確かめてください。

ユーザーが存在しなければ、404 Not Found が返るとされています。これは「アカウントが無い」という情報で、エラーではありません。道具の側で 404 を not_found という結果に直してから、エージェントに返します。

Google Workspace の Directory API では、ユーザーの suspended が停止の状態を表します。 suspensionReason は suspended が真の場合だけ返り、lastLoginTime は ISO 8601 形式の日時とされています。スーパー管理者かどうかの isAdmin、委任管理者かどうかの isDelegatedAdmin もあります。停止されていても管理者の印が残っていないかは、この2つで見ます。

Directory API には、delete、update、signOut などのメソッドもあります。 道具に割り当てる認証情報は読み取りの範囲に限り、get と list 以外を呼べない形にします。

AIへ渡す前に整形する

1. 対象者の鍵をそろえる … 社員番号、メールアドレス、旧姓のメールアドレス、別名を1つの表にまとめます
2. 候補のSaaSを絞る … 台帳と申請記録から、その人が使っていたSaaSを出します。全社で使うSaaSは、台帳に無くても必ず候補に入れます
3. 日付の段階を決める … 最終出社日または異動日と、今日の日付を比べ、「前」か「後」かを決めます
4. 標準の権限表を引く … 異動なら、異動元と異動先の部署の標準の権限を取ります
5. API の無いSaaSを分ける … 台帳で管理APIが無いものは、エージェントに回さず unverified の候補にします
6. 同じ人の重複を除く … 異動と退職が同じ月に続けて登録された場合は、新しいほうだけを流します

1番目を軽く見ないでください。 結婚などでメールアドレスが変わった人は、古いアドレスでSaaSに登録されたままのことがあります。新しいアドレスで引いて「無い」と出ても、古いアドレスで残っています。

3番目の日付の段階は、エージェントに渡さず、ワークフローが決めます。 日付の比較をエージェントに任せると、最終出社日の前に「止まっていない」と判定することがあります。

AIに処理させる

させるのは、候補のSaaSごとに正しい道具と引き方を選び、アカウントと権限の状態を集めて、決まった形で返すことだけです。

3行目がいちばん起きやすい失敗です。 道具が何も返さなかったとき、エージェントは「このSaaSにアカウントはありません」とまとめたくなります。引き方が誤っていただけのアカウントが、そのまま残ります。

指示内容を固定する

あなたは情報システム部で、退職・異動した社員のSaaSのアカウントが
残っていないかを確かめる担当です。止める作業はしません。確かめるだけです。

【対象者】{employee}   ← 社員番号・メール・旧アドレス・種別・日付・部署
【候補のSaaS】{candidate_saas}   ← 台帳の行（利用者を引く鍵・管理APIの有無）
【日付の段階】{phase}   ← before_last_day ／ after_last_day

【進め方】
1. 候補のSaaSを1つずつ確かめてください。台帳にある「利用者を引く鍵」で
   道具を呼んでください。
2. 見つからないときは、社員番号、旧アドレスの順に引き直してください。
   それでも見つからなければ found を not_found にしてください。
3. Entra ID と Google Workspace は、候補に無くても必ず確かめてください。
4. 返った値だけを書いてください。値が返らない項目は unknown にしてください。

【厳守事項】
- 見つからなかったことを「アカウントは無い」と言い換えないでください。
  not_found と、どの鍵で引いたかをそのまま書いてください。
- 停止済みに見えても、管理者の権限（isAdmin、isDelegatedAdmin、
  各SaaSの管理者ロール）が残っていれば、その値を書いてください。
- 止めるべきかどうかを書かないでください。判定は後で行います。
- 道具が返した値を推測で補わないでください。
- 台帳に無いSaaSの手がかりは hints に挙げるだけにしてください。
- 同じ道具を同じ引数で2回呼ばないでください。

「見つからなかったことを、無いと言い換えない」を明記しないと、まとめの文で消えます。 道具の結果には not_found と書かれていても、最後の要約で「残っているアカウントはありませんでした」と書きます。禁じるのは、要約の段階での言い換えそのものです。

「同じ道具を同じ引数で2回呼ばない」は、繰り返しの上限のためです。 Max Iterations の既定は10です。候補のSaaSが多い人では、同じ呼び出しを繰り返すと、全部を確かめる前に上限に届きます。 上限は、候補の数に合わせて広げます。

出力形式を固定する

エージェントの出力は、出力パーサーで次の形の JSON に固定します。

{
  "employee_id": "",
  "event": "leave | transfer",
  "phase": "before_last_day | after_last_day",
  "checks": [
    {
      "saas": "",
      "lookup_key_used": "email | employee_id | old_email",
      "found": "found | not_found | unverified",
      "account_state": "active | suspended | archived | deleted | unknown",
      "roles": [],
      "admin_role_remaining": "yes | no | unknown",
      "last_login": "",
      "evidence": ""
    }
  ],
  "hints": [ { "saas": "", "source": "", "detail": "" } ]
}

1つ目の理由は、事実と判定を別の層に置けることです。 checks はエージェントが埋め、判定は Code ノードが規則で付けます。

2つ目は、lookup_key_used で引き方を後から確かめられることです。 not_found の行を人が見るとき、どの鍵で引いて見つからなかったのかが分かれば、別の鍵で引き直すだけで済みます。

3つ目は、admin_role_remaining を独立の欄にしたことです。 停止済みでも管理者の印が残っているものは、ほかの欄に埋もれると見落とします。

Tools Agent では、決まった出力の形を求める設定を有効にすると、出力パーサー（Structured など）をつなぐ必要があるとされています。

システムへ連携する

どのつなぎ先にも、書き込みの権限を渡しません。 停止の API を呼べる認証情報を n8n に置かないことが、エージェントが止めてしまう経路を物理的に無くす方法です。

停止依頼票の送付は、人の承認を挟みます。 n8n には、AI Agent が特定の道具を実行する前に人の承認を求める仕組みがあり、Slack、Microsoft Teams、Gmail、Microsoft Outlook などで承認の依頼を送れるとされています。承認すればAIが指定した入力で道具が実行され、拒否すれば取り消されて実行されないとされています。依頼票を送る道具にこの承認を付け、担当者が文面と宛先を確かめてから送ります。

人が確認する

人が見るのは、判定が付いた一覧の全件です。 件数は月40件で、1件の一覧は数行から十数行です。

1. unverified を先に見る … 管理APIの無いSaaSと、見つからなかったもの。管理画面で直接確かめます
2. must_stop と must_revoke の根拠を確かめる … evidence を読み、止める対象が正しい人か、同姓同名の別人でないかを見ます
3. hints を見る … 台帳に無いSaaSの手がかり。本当に使っていたら台帳に足し、確かめる対象に加えます
4. 停止依頼票を承認して送る … 宛先の管理者と期限を確かめます
5. 判定を覆したら記録する … keep を must_stop にした、またはその逆の理由を残します

2番目の「別人でないか」を省かないでください。 同じ表示名の社員がいる会社では、表示名で引くSaaSで別人のアカウントが返ることがあります。別人のアカウントを止める依頼は、その人の業務を止めます。

例外に対処する

上から3行目までが大半を占めます。 どれも AI の問題ではなく、台帳の鍵と管理APIの有無の問題です。 unverified の理由を数えれば、台帳のどこを直せばよいかが分かります。

記録を残す

• 退職・異動の登録の内容と、受け取った日時
• 候補にしたSaaSの一覧と、その根拠（台帳の行・申請記録）
• エージェントが呼んだ道具、引数、返った結果の順番
• checks の JSON と、Code ノードが付けた判定
• 停止依頼票の文面、承認した人、送った日時
• 停止の期限後の再確認の結果
• 人が判定を覆した記録と、その理由

3つ目は、AI Agent ノードの Return Intermediate Steps で出力に含められます。 どの道具をどの順で呼んだかが残り、「なぜこのSaaSは見つからなかったのか」を後から追えます。

最後の行は、規則を直す材料になります。 同じ種類の覆しが続くなら、判定の規則か標準の権限表のほうが実態と合っていません。