各部門の月次の人員数と人件費の計画・実績を集計し、差の大きい部門と理由の候補を経営企画の月次報告のコメントにまとめる

処理の起点を決める

時間主導型のトリガーを30分ごとに1つ置き、第3〜第5営業日だけ処理します。 営業日の判定は、会社の休日の一覧のシートを見て行います。それ以外の日は、何もせずに終わります。 時間主導型のトリガーは、指定した時間帯の中で動く時刻が少しずれます。

処理を始める条件は、3つのCSVがそろったことです。 人件費の集計、在籍者と入退社・異動の一覧、採用の進捗の3つが、その月の日付のファイル名でフォルダにあるかを見ます。1つでも欠けていれば待ち、第5営業日の朝になっても欠けていれば、Chat に「未着」と知らせます。 人件費だけで差を出すと、理由の候補が何も書けない部門が並びます。

同じ月の処理は1回だけにします。 処理が終わると、その月を「処理済み」としてスクリプト プロパティに書きます。人事の担当がCSVを差し替えたときは、ファイルの更新日時が処理済みの日時より新しいかを見て、その月を処理し直します。 コメント案のシートは、前の版を残してから上書きします。

入力データを集める

AIに渡すのは、件数と金額の集計だけです。 社員の名前・社員番号・個人の給与は、CSVの段階で含めません。入退社と異動も、部門ごとの件数と発令日だけを渡します。 「誰が辞めたか」は、差を説明するのに要りません。

計画の内訳が、説明の質を決めます。 人件費の計画が合計だけだと、1人あたりの差を内訳に分けられず、「1人あたりが高い」以上のことが言えません。 計画のシートに、残業代・賞与の引当・法定福利費・派遣と業務委託費の内訳を持たせます。

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

CSVは、共有ドライブの人件費のフォルダから読みます。フォルダの中のファイルを一覧にし、その月の3つのファイルを開いて中身を文字列として取り出し、CSVを2次元の配列にする関数（Utilities.parseCsv）で表の形にします。 給与の仕組みのCSVの文字コードがUTF-8でなければ、文字コードを指定して取り出します。

部門コードは、計画のシートと照らしてから使います。 期中の組織の変更で、給与の仕組みと計画のシートで部門コードがずれることがあります。計画に無い部門コードが出たら、その部門の差は計算せず、「組織変更の確認」として一覧に出します。 対応表のシートに、新旧の部門コードの組を持たせます。

AIへ渡す前に整形する

1. そろいの確認 … 3つのCSVの部門の数が計画の部門の数と合うか。合わない部門は「組織変更の確認」にします
2. 人件費の差 … 部門ごとに、実績から計画を引きます
3. 人数による差 … （月の平均の在籍者数の実績 − 計画の人数）× 計画の単価
4. 1人あたりの差 … 人件費の差 − 人数による差
5. 1人あたりの差の内訳 … 残業代・賞与の引当・法定福利費・基本給と手当の、1人あたりの計画との差に月の平均の在籍者数を掛けたもの。派遣・業務委託費は、人数に入らないので別の行で出します
6. 差の大きい部門の選び方 … 人件費の差が計画の3％以上かつ50万円以上、または人数の差が2名以上の部門
7. 少人数の部門のまとめ … 月の平均の在籍者数が5名未満の部門は、1人あたりの差と内訳を出さず、事業部の単位に足し合わせてから6番目の基準で選び直します
8. AIへ渡す数字の用意 … 選んだ部門について、分解の数字、入退社・異動の件数と発令日、残業時間の前年同月比、採用の計画と進捗を部門ごとにまとめます

3番目から7番目は、すべてスクリプトの式です。 差の分け方を式にすると、同じ差がどの月も同じ言葉で説明される下地ができます。

3番目で月末ではなく月の平均の在籍者数を使うのは、月の途中の入退社を正しく数えるためです。 20日に入社した人は、月末の人数には1名として入りますが、人件費には3分の1か月分しか入りません。月末の人数で割ると、入社の多い月ほど1人あたりの人件費が低く出ます。 月の平均の在籍者数を人事の仕組みが出せない場合は、在籍の日数から計算します。

7番目は、計算の都合ではなく個人の情報を守るための手順です。 少人数の部門の1人あたりの差は、ほぼ個人の給与の変化です。AIに渡す前の段階で、出さない形にします。

AIに処理させる

させるのは、選ばれた部門について、分解された差を入退社・異動・残業・採用の動きと結び付けて理由の候補を挙げ、月次報告のコメントの下書きを書くことです。

コメントの型を決めておくのが要点です。 「（部門）の人件費は計画比（差）。主に（人数による差／1人あたりの差）で、（理由）による。」の2文に収めます。型がそろうと、経営会議で月をまたいで見比べられます。

理由の候補には、必ず根拠にした入力の項目名と数字を付けさせます。 「中途入社の計画3名に対し入社済み1名（hiring_plan、hiring_joined）」のように書かせ、根拠の項目が入力に無い候補は、スクリプトの側で外します。

2行目がいちばん起きやすい失敗です。 1人あたりの差が大きい部門について、AIは「昇給の影響と考えられる」と書きがちです。入力に昇給の情報は無く、少人数の部門なら特定の個人の話に読まれます。 内訳で説明できない1人あたりの差は、「確かめる点」に質問として書かせます。

指示内容を固定する

あなたは会社の経営企画部で、月次報告の人件費の欄のコメントを書く担当を補佐します。
差の金額と、人数による差・1人あたりの差・内訳への分解は、すでに式で計算されています。
あなたの役割は、その差の理由の候補と、コメントの下書きと、部門に確かめる点を出すことです。

【入力（部門ごと）】
- 人件費の計画・実績・差、人数による差、1人あたりの差とその内訳
- 計画の人数、月の平均の在籍者数、休職者数
- 入社・退職・異動の入り・異動の出の件数と発令日
- 残業時間と前年同月の時間
- 採用の計画数・入社済み・内定済み・選考中

【コメントの型】
「（部門名）の人件費は計画比（差の率）。主に（人数による差／1人あたりの差）で、（理由）による。」
2文以内。理由が分からないときは「理由は確認中。」とする。

【厳守事項】
- 差の金額、率、分解の数字を計算し直したり、修正したりしないでください。
- 個人の昇給・評価・退職の事情を推測しないでください。
- 入力に無い事情（市場の賃金、景気、部門の方針など）を理由の候補にしないでください。
  必要なら「確かめる点」に質問として書いてください。
- 理由の候補には、必ず evidence に入力の項目名と数字を書いてください。
  evidence を書けない候補は出さないでください。
- 人員の計画の見直しや、配置の変更を提案しないでください。
- 「事業部まとめ」と書かれた行は、1人あたりの差に触れないでください。

【部門ごとの入力】{departments}

「事業部まとめの行は1人あたりの差に触れない」を入れているのは、前処理の7番目と対です。 スクリプトの側で数字を渡していなくても、AIは人数と人件費の差から1人あたりを計算して書いてくることがあります。 指示でも禁じ、スキーマにもその欄を作りません。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力を使い、/v1beta/interactions への要求の response_format に、mime_type を application/json、schema に下の形のスキーマを入れて渡します。

{
  "dept_code": "D-2310",
  "is_rollup": false,
  "main_driver": "headcount | per_capita | mixed",
  "main_component": "overtime | bonus_accrual | welfare | base_pay | contractor | none",
  "reason_candidates": [
    { "text": "", "evidence": [{ "field": "hiring_joined", "value": "1" }] }
  ],
  "comment_draft": "",
  "questions_for_dept": [""],
  "likely_to_continue": "yes | no | unknown"
}

1つ目の理由は、evidence をスクリプトで照合できることです。 field に書かれた項目名が入力に本当にあり、value が入力の数字と一致するかを確かめます。一致しない候補は外し、「根拠不一致」として記録します。 構造化出力は JSON の形を守りますが、値の正しさはアプリケーションで確かめるよう、公式の説明にもあります。

2つ目は、main_driver と main_component で、スクリプトの計算とAIの読みを突き合わせられることです。 人数による差が1人あたりの差より大きいのに per_capita と返ってきたら、AIが数字を読み違えています。 スクリプトの計算と合わない行には印を付け、コメント案を人が先に読むよう並べます。

3つ目は、likely_to_continue で翌月の報告につなげられることです。 採用の遅れのように来月も続く差に印が付いていれば、翌月のコメント案を作るときに、前月の理由として入力に足せます。

システムへ連携する

UrlFetchApp.fetch() は、method に post、contentType に JSON、headers に API キー、payload に要求の本文を入れて呼びます。muteHttpExceptions を true にすると、失敗の応答でも例外を投げずに応答を返します。 状態コードを見て、その部門を次の実行で再試行するかを決めます。

API キーと Webhook の URL は、コードに書かずスクリプト プロパティに置きます。 スクリプト プロパティはスクリプトのすべての利用者で共有されるため、スクリプトの編集権限は人事と経営企画の担当に限ります。 Webhook の URL は公開の場所に貼らないよう公式も注意しています。

Chat に送るのは、件数とシートへのリンクだけです。 「差の大きい部門 9、事業部まとめ 2、確かめる点あり 4、組織変更の確認 1」のように書き、部門ごとの金額は載せません。

人が確認する

経営企画の担当が、コメント案を全部読んでから月次報告に貼ります。 経営会議に出る文章なので、AIの下書きをそのまま貼ることはしません。

1. 取り込みの状態を見る … 「未着」「組織変更の確認」が無いか。あれば人事の担当に確かめてから先に進みます
2. 印の付いた行を先に読む … main_driver がスクリプトの計算と合わない行、根拠不一致で候補が外れた行
3. 確かめる点を部門に聞く … AIが「記録からは分からない」とした部門だけに聞きます
4. コメントを直す … 部門から聞いた事情を足し、型に沿っているかを見ます
5. 事業部まとめの行を見る … 少人数の部門の個人の事情が読み取れる書き方になっていないかを確かめます

5番目は、経営企画の担当が最後の砦になる確認です。 スクリプトとAIの両方で防いでいますが、部門名と理由の組み合わせだけで個人が分かることがあります。 「育児休業からの復帰」のような理由は、少人数の部門では書かない約束にします。

目標は、40部門をならして1部門9分です。 差の小さい部門は数字を見るだけで数十秒、差の大きい部門はコメント案を読んで直すので10分を超え、部門に聞く部門はさらに長くかかります。

例外に対処する

6行目の扱いが大事です。 Gemini API が止まった月でも、差の分解は式で出ているので、担当者は数字から自分でコメントを書けます。 これまでの手作業より短い時間で済みます。

記録を残す

• 取り込んだCSVのファイル名と更新日時、部門の数
• 部門ごとの差と分解の数字と、そのとき使った計画の版と計算の式の版
• AIに渡した入力と、返ってきたJSONの全文
• 根拠不一致で外した候補と、main_driver が合わなかった行
• 担当者が直した後のコメントと、部門に聞いた内容
• 少人数のため事業部にまとめた部門の一覧

5つ目が、翌月の入力の材料になります。 部門に聞いて分かった事情（期中の組織変更、計画に無かった増員の承認など）を記録しておけば、翌月は同じ質問をせずに済みます。