SaaS ごとの利用者とログインの記録を n8n で毎日ためて、使われていないライセンスの候補を判定し、本人への回収の案内まで出す

処理の起点を決める

トリガーは2つに分けます。 毎日深夜にサインインの記録をためる流れと、月初に判定と案内をする流れです。1つにまとめると、月初の処理の不具合で毎日の取り込みまで止まり、判定の材料が欠けます。

毎日の流れは Schedule Trigger で2:00に動かし、前日の0:00から23:59までを取ります。 月初の流れは、Schedule Trigger の Months の間隔で毎月1日の8:00にします。

タイムゾーンを最初に確かめてください。 Schedule Trigger はワークフローのタイムゾーン、無ければインスタンスのタイムゾーンで動き、自前で立てた n8n の既定は America/New York です。 そのままだと「2:00」が日本の昼過ぎになり、「前日」の範囲が13〜14時間ずれます。ワークフローの設定で Asia/Tokyo にします。

入力データを集める

質を決めるのは、申請の理由と過去の返答の記録です。 日数と在籍の区分だけなら規則で判定できます。AI に読ませる意味は、自由記述の「決算のときだけ」を読み分けるところにあります。

基準日数は SaaS ごとに変えます。 チャットなら30日、経費精算なら60日、監査対応の道具なら180日。同じ日数で見ると、頻度の低い SaaS ほど誤って候補に上がります。

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

サインインの記録は、HTTP Request ノードで Microsoft Graph を呼びます。 認証は、Entra ID に登録したアプリの OAuth2 の資格情報で行います。

サインインの記録は、必ず期間で絞って取ります。 公式の説明でも、要求がタイムアウトしないように $filter で期間を付けるよう書かれています。1回に返るのは最大1,000件で、続きは @odata.nextLink に入ります。HTTP Request ノードのページ送りを「Response Contains Next URL」にし、Next URL に {{ $response.body["@odata.nextLink"] }} を入れます。

22本の appId を SaaS 台帳に持たせ、Code ノードでその記録だけを残します。 そのうちstatus.errorCode が0（成功）のものだけを取り、利用者 × SaaS ごとに一番新しい createdDateTime を Data Table に Upsert します。

割り当ての一覧には、グループで割り当てたものが混ざります。 principalType が Group の行は人ではないので、グループのメンバーを別に引いて人に展開します。

シングルサインオンの無い8本は、担当者が書き出した CSV をワークフローが読みます。 列名が SaaS ごとに違うので、SaaS 台帳に列の対応を持たせ、Code ノードで同じ形にそろえます。

AIへ渡す前に整形する

1. 時刻を日本時間にそろえる … Graph の日時は ISO 8601 の UTC です。日数を数える前に日本時間に直し、日付の境目で1日ずれないようにします
2. 利用者を社員番号に結び付ける … サインインの記録のメールアドレスと、人事データのメールアドレスで結び付けます。改姓や異動でアドレスが変わった人は、userId で結び付け直します
3. 日数を計算する … 最後のサインインから今日まで、割り当ての日から今日までの日数を出します
4. 基準を超えた人を拾う … SaaS 台帳の基準日数を超えた人、割り当てから30日以上たって一度もサインインしていない人を拾います
5. 規則で先に分ける … 割り当てから30日未満の人は「新規」として外し、SaaS 台帳の共用・連携用のアカウントの一覧に載るものは「対象外」にします
6. 休職中の人を保留にする … 人事データで休職中の人は、規則で保留にし、AI に回しません
7. 申請の理由と過去の返答を付ける … その人 × その SaaS のものを引いて付けます

5番目と6番目を AI より先に置くのは、規則で決められることを AI に任せないためです。

AIに処理させる

させるのは、規則で決まらなかった人について、5つの区分のどれに当たるかを判定し、根拠にした記録を写し、案内文の下書きを作ることだけです。

AI に読ませる理由は、自由記述の表現がそろっていないからです。 「Q末だけ」「決算期に利用」「3・6・9・12月」「監査対応用」はどれも季節の利用ですが、規則の言葉で拾おうとすると、書き方の数だけ条件が要ります。 逆に「当面」「しばらく」「いずれ使う」は、使う時期を示していないので季節の利用には当たりません。

3行目が一番起きやすい失敗です。 部署が「営業」で SaaS が「設計の道具」だと、「営業職には不要」と書いて回収候補にしがちです。

指示内容を固定する

あなたは情報システム部門で、SaaS のライセンスの見直しを手伝う立場です。
渡された記録だけを見て、この利用者のライセンスがどの区分に当たるかを判定してください。
回収するかどうかは決めません。推測で埋めないでください。

【区分】
- reclaim_candidate ... 基準日数を超えて使っておらず、使う予定を示す記録が無い
- hold_seasonal ....... 申請の理由や過去の返答に、決まった時期にだけ使う旨が書かれている
- hold_project ........ 案件や期間の終わりが書かれており、今日がその前である
- out_of_scope ........ 共用・連携用のアカウントと台帳の注記から読める
- needs_review ........ 記録どうしが食い違う、材料が足りない、判断がつかない
迷ったときは needs_review を選んでください。reclaim_candidate を選ばないでください。

【厳守事項】
- 日数は【計算結果】の値をそのまま使ってください。日付から数え直さないでください。
- 「当面」「しばらく」「いずれ」は、使う時期を示していないので hold_seasonal にしないでください。
- 部署・役職・職種から、その SaaS が要るか要らないかを推測しないでください。
- 次に使う時期が書かれていなければ next_use_period を「不明」としてください。
- evidence には、根拠にした記録の文面をそのまま写し、どの記録かを source に書いてください。
- 過去の返答で「使い続ける」と答えている場合は、その日付と内容を evidence に入れてください。
- 案内文は本人あてに、です・ます調で、最後のサインインの日と、返事の期限を入れてください。
  回収が決まったような書き方をしないでください。「使い続ける場合はボタンを押してください」
  のように、本人が選べる形にしてください。

【利用者】{user}
【SaaS】{saas_name}（基準日数 {threshold_days} 日）
【計算結果】最後のサインインから {days_since_signin} 日、割り当てから {days_since_assigned} 日
【申請の理由】{request_reason}
【過去の返答】{past_answers}
【台帳の注記】{saas_note}
【返事の期限】{reply_deadline}

「迷ったら reclaim_candidate を選ばない」を明記しないと、回収候補に寄ります。 「見直しを手伝う」という役割を与えると、AI は減らす方向の答えを出そうとします。見直しの目的は減らすことではなく、使っていないものを確かめることだと、区分の選び方で示します。

「日数を数え直さない」を入れるのは、数え直した値が計算のノードの値と食い違うと、確認する人が迷うからです。

出力形式を固定する

次の形のJSONで受け取ります。 n8n の Structured Output Parser に JSON Schema で定義します。このノードは JSON Schema の $ref に対応していないので、定義は1つの塊に展開して書きます。

{
  "user_id": "",
  "saas_id": "",
  "category": "reclaim_candidate | hold_seasonal | hold_project | out_of_scope | needs_review",
  "next_use_period": "",
  "evidence": [
    { "source": "request_reason | past_answer | saas_note", "text": "" }
  ],
  "conflicts": [],
  "notice_draft": {
    "subject": "",
    "body": ""
  }
}

1つ目の理由は、category を後段の規則で読み替えられることです。 「hold_seasonal の人には案内を送らず、次の季節が過ぎた月にもう一度見る」「reclaim_candidate だけを案内の対象にする」といった扱いは、ワークフローの分岐で決めます。 扱いを変えても、AI の指示は直しません。

2つ目は、evidence に記録の種類が付くことです。 担当者は一覧で「申請の理由にこう書いてあるから季節の利用」と読めます。記録を開き直さずに、判定が妥当かを確かめられます。

3つ目は、conflicts で食い違いを拾えることです。 申請の理由に「プロジェクト期間のみ」とあるのに、前回「今後も使う」と答えているような場合で、category に関係なく人が見る一覧に回します。

システムへ連携する

本人への案内は、Microsoft Outlook ノードの Send and Wait for Response で送ります。 応答の形は Approval、Free Text、Custom Form の3つがあり、ここでは Custom Form で「使い続ける」「返してよい」の選択と、任意の一言の欄を作ります。 Limit Wait Time で待つ期間を14日にし、期限を過ぎたら返事が無いものとしてワークフローを再開させます。

Microsoft Graph へは書き込みません。 割り当てを外す権限をワークフローに持たせると、判定の誤りがそのまま誰かの仕事を止めます。 外すのは担当者が各 SaaS の管理画面で行い、外したことを返答の記録に書きます。権限も、サインインの記録を読む AuditLog.Read.All と、割り当てを読む Application.Read.All だけにします。

人が確認する

人が見るのは2回です。 案内を送る前と、ライセンスを外す前です。

1. 案内を送る前に、SaaS ごとの一覧を見る … reclaim_candidate の人に案内を送ってよいかを確かめます。役員・顧客対応の窓口になっている人など、案内の送り方に配慮が要る人はここで外します
2. needs_review と conflicts のある人を見る … 記録を開き、区分を決めます。決めた区分と理由を返答の記録に残します
3. 返事を見て、外すかを決める … 「返してよい」と答えた人は外します。「使い続ける」と答えた人は、次の見直しで同じ質問が届かないよう、返答の記録に期間を残します
4. 返事の無い人を部門長に回す … 14日で返事が無い人だけを部門ごとにまとめ、部門長に送ります。返事が無いことを理由に、担当者だけで外さないでください

4番目が信頼の分かれ目です。 休暇で14日メールを見ない人はいます。返事が無いだけで外すと、次の案内が読まれなくなります。

例外に対処する

上から6行目は見落とされやすい例外です。 List signIns が返すのは対話型のサインインと成功したフェデレーションのサインインで、画面を開いたまま使う SaaS では、使っていても記録が残らないことがあります。

記録を残す

• 毎日の取り込みの結果（取った件数、ページ数、失敗した日）
• 最終サインインの台帳（利用者 × SaaS ごとの最後の日と、その日を取り込んだ日）
• 月初の判定の入力（日数、在籍の区分、申請の理由、過去の返答）と AI の出力の全文
• 担当者が区分を変えた記録（どの人を、どの区分から、どの区分に、なぜ）
• 案内を送った日時、返事の内容と日時、返事の無かった人
• ライセンスを外した日と、外した担当者
• 外したあと30日以内に、同じ人から再び利用の申請があったか

最後の行が、基準日数を直す材料になります。 外してすぐ申請し直された人が多い SaaS は、基準日数が短すぎます。