SaaSの契約数と利用状況を突き合わせて、使われていないライセンスを洗い出す

処理の起点を決める

毎月1日の定期起動にします。Google Apps Script の時間主導型トリガーで月次の実行を設定します。

退職者のアカウント確認だけは、月1回では遅いことがあります。人事システムの退職者情報を週次で取得し、該当アカウントが残っているサービスを知らせる処理を別に動かしてください。 費用の棚卸しと、アカウントの停止は、必要な速さが違います。

入力データを集める

4番目の在籍データが、この構成でもっとも重要な入力です。 これが無いと、アカウントが誰のものかを判定できません。

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

APIのあるサービス： アカウント一覧と最終ログイン日を取得します。項目名はサービスごとに違うため、取得後に共通の形へ整えます。

APIのないサービス： 管理画面からCSVを書き出し、所定のフォルダへ入れます。この手作業は残ります。 40本のうち半数程度はここに当たると見ておいてください。書き出し手順をサービスごとに手順書にしておくと、担当が替わっても回ります。

Google Workspace の利用状況： Reports API から取得します。日付を指定して取る形のため、当日や前日のデータはまだ揃っていないことがあります。 数日前の日付を指定する設計にしてください。

人事の在籍データ： 人事システムから月次（退職者は週次）で書き出します。メールアドレスで突合できる形にしておくことが前提です。 氏名での突合は同姓同名で誤ります。

AIへ渡す前に整形する

1. 項目名の統一 … 「ライセンス」「シート」「メンバー」を1つの項目に揃えます
2. 日付形式の統一 … サービスごとに表記が違います
3. アカウントの名寄せ … 会社のメールアドレスを軸に、別ドメインや個人アドレスで登録されたアカウントを拾います
4. 共有アカウントの識別 … info@、sales@ のような共有アカウントを別扱いにします。個人に紐づかないアカウントは、退職者判定の対象外にします
5. 無料枠の分離 … 無料プランのアカウントは費用の対象外ですが、情報の管理の対象にはなります

3番と4番を飛ばすと、退職者判定の結果が信用されなくなります。

AIに処理させる

解約や減数の提案を書かせないでください。 「このサービスは解約できます」と書かれた一覧が回ると、業務部門との関係が悪くなります。出すのは「3か月間ログインがありません。今後も必要かご確認ください」までです。

指示内容を固定する

あなたは情報システム部でSaaSの棚卸しを担当しています。
サービスごとの利用状況、契約台帳、在籍データを渡します。
確認すべき点を整理してください。

【厳守事項】
- 解約、減数、プラン変更を提案しないでください。
  事実と、部署に確認すべき点だけを書いてください。
- 「不要」「無駄」といった評価を書かないでください。
  利用がないことと、不要であることは違います。
- 最終ログイン日が取得できないサービスは「利用状況不明」としてください。
  利用がないと判定しないでください。
- 在籍データに無いアカウントは、まず「要確認」としてください。
  退職者と断定するのは、退職日が確認できる場合だけです。
- 共有アカウントは個人の利用状況で判定しないでください。
- 契約数と割り当て済み数の差は、計算した値をそのまま書いてください。
  金額の試算をしないでください。
- 機能が重なるサービスの指摘は、どの機能が重なるかを具体的に書いてください。

【契約台帳】
{contracts}

【利用状況（サービス別）】
{usage_data}

【在籍データ】
{hr_data}

「利用がないことと、不要であることは違う」という前提を書いておくことが大切です。 年に2回の監査対応でしか使わないサービスは、11か月間ログインがありません。

出力形式を固定する

{
  "service": "",
  "contract_seats": 0,
  "assigned_accounts": 0,
  "active_accounts": 0,
  "usage_available": true,
  "findings": [
    {
      "type": "未利用 | 退職者の可能性 | 要確認 | 契約数の差 | 機能の重複",
      "account": "",
      "detail": "",
      "last_login": ""
    }
  ],
  "questions_for_department": [],
  "renewal_date": "",
  "days_to_renewal": 0
}

usage_available が false のサービスは、判定の対象から外して一覧に表示します。 「利用状況が取れないサービス」として可視化しておくことに意味があります。

days_to_renewal は、確認を急ぐべきサービスを見分けるために持ちます。年間契約は更新日を過ぎると1年動かせません。

システムへ連携する

契約台帳を自動で書き換えないでください。 台帳は契約の記録であり、突合の結果で上書きするものではありません。

人が確認する

全件、人が確認します。 判断は3つに分かれます。

1つ目だけは、費用の話とは切り離して急いでください。 残っていること自体が問題になります。

例外に対処する

記録を残す

• サービスごとの契約数・割り当て数・利用者数（月ごと）
• 判定結果と、人が変更した内容
• 部署への照会と回答
• 停止したアカウントと停止日
• 解約・減数した内容と、その後の請求額

1番目を月ごとに残すと、推移が見えます。 契約数が増え続けているサービス、利用者が減り続けているサービスが分かり、更新の交渉材料になります。

利用状況のデータは、個人がいつ何を使ったかの記録でもあります。保存期間と閲覧範囲を決めてください。