人材紹介会社で、キャリアアドバイザーごとに選考中の候補者の段階と過去の通過率から今月の成約数を見込み、目標に足りない担当と動かすべき候補者を出す

処理の起点を決める

時間主導型のトリガーを3つ置きます。 毎朝6時台の取り込み、毎週月曜7時台の見込み、毎月1日の通過率の計算し直しです。時間主導型のトリガーは、指定した時間帯の中で動く時刻が少しずれ、一度決まるとその時刻で動き続けます。

月曜の見込みは、取り込みが終わったことを確かめてから動きます。 取り込みが終わると日付をスクリプト プロパティに書き、見込みの実行はこの日付が当日でなければ止まります。 古い状態で出すと、週末の承諾が数えられません。

承諾を今月に数える締めの日付は、目標のシートに月ごとに持たせます。 月末の営業日か暦の末日かで残りの日数が変わるため、式はそこから数えます。

入力データを集める

AIに渡すのは、選ばれた選考の段階・日数・予定と、メモの要旨だけです。 候補者の氏名・連絡先・現職の会社名は、取り込みの段階で落とします。候補者IDは、AIに渡す前にハッシュ値に置き換えます。 一覧の側では、元の候補者IDに戻して表示します。

メモが、理由の候補の質を決めます。 「現職から引き止めがあると話していた」と書いてあれば、AIはそれを候補に挙げられます。メモが無ければ、日数と段階の動きしか言えません。

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

管理システムのCSVは、共有ドライブのフォルダから読みます。フォルダの中の未処理のファイルを開き、中身を文字列として取り出して、CSVを2次元の配列にする関数（Utilities.parseCsv）で表の形にします。管理システムが出すCSVの文字コードがUTF-8でなければ、文字コードを指定して取り出します。

段階の履歴は、上書きせずに足していきます。 管理システムが履歴を出せないなら、毎晩のCSVを前の晩と比べて、変わった選考を履歴に書き足します。

候補者IDのハッシュ値は、Utilities.computeDigest で作ります。 指定したアルゴリズムで要約を計算する関数で、スクリプト プロパティに置いた秘密の文字列を足してから要約します。 桁数の少ないIDを割り出されないためです。

AIへ渡す前に整形する

1. 取り込みの確認 … CSVの行数が前の晩から大きく減っていないかを見ます。半分以下になっていれば、出力の失敗として取り込みません
2. 段階のそろえ方 … 管理システムの段階の名前を、書類選考・一次面接・二次面接・最終面接・内定・承諾・不合格・辞退の8つにそろえます。企業によって面接の回数が違うため、「最終面接」は企業の選考の最後の面接として扱います
3. 通過率の計算（毎月1日） … 過去18か月に各段階に入った選考のうち、承諾に至った割合を、職種区分と企業の速さの区分ごとに計算します。件数が30件に満たない組み合わせは、職種区分だけの値を使います
4. 日数の分布の計算（毎月1日） … 各段階に入った日から承諾した日までの日数を、同じ区分ごとに並べます
5. 滞留の区分 … 選考ごとに、いまの段階に入ってからの日数が、その段階の過去の日数の中央値以内か、9割の値以内か、それを超えているかに分けます。9割の値を超えた選考の通過率は、過去に同じだけ滞留した選考の実績で置き換えます
6. 今月中の確率 … 選考ごとに「承諾に至る確率 × 締めの日までの残りの日数で承諾に届く割合」を計算します。後者は、日数の分布のうち、すでに経った日数を超えたものの中で、残りの日数以内に収まる割合です
7. 成約数の分布 … アドバイザーごとに、今月すでに承諾した件数に、選考中の各選考の確率を合わせた件数の分布を計算します。選考ごとに「承諾する／しない」の二択として、全部の組み合わせの確率を順に足し合わせます
8. 届く確率と区分 … 分布から目標の件数以上になる確率を出し、7割以上を「届く見込み」、3割未満を「届かない見込み」、その間を「五分」とします
9. 今週動かす選考の選び方 … 「届かない見込み」と「五分」の担当について、承諾までの日数の中央値が残りの日数より短く、かつ次の予定日が空いているか最後の連絡から7日を超えている選考を選び、確率の高い順に最大5件とします

3番目から9番目は、すべてスクリプトの式です。 この記事が「予測」と呼ぶのは、この式で出す確率と成約数の分布です。毎週同じ答えが出て、過去の外れ方で確かさを示せることが、経験による読みとの違いです。

7番目は、確率を足しただけで終わらせないための手順です。 足すと「3.2件」という平均は出ますが、目標の3件に届く確率は分かりません。組み合わせを順に足し合わせると、「2件以下が35％、3件が30％、4件以上が35％」の形で出ます。

6番目の「すでに経った日数を超えたものの中で」を落とすと、滞留している選考の確率が高く出ます。 最終面接から20日止まっている選考を、入ったばかりの選考と同じ分布で数えると、「中央値は14日だから今月に入る」と読んでしまいます。

AIに処理させる

させるのは、9番目で選ばれた選考について、止まっている理由の候補を記録から読み、リーダーがアドバイザーに確かめる点を書くことです。

理由の候補には、必ず根拠にした記録の項目を付けさせます。 「最終面接から18日、企業からの結果の連絡の記録が無い（days_in_stage、last_company_contact）」のように、入力のどの項目から言っているかを書かせます。 根拠の項目が入力に無い候補は、スクリプトの側で一覧から外します。

2行目がいちばん起きやすい失敗です。 内定の回答が止まっている候補者について、AIは「他社の選考と迷っている可能性がある」と書きがちです。メモに他社の選考の記載が無ければ、それは確かめようのない推測で、リーダーが面談でそのまま口にすると決めつけになります。 メモに無い事情は、「確かめる点」の側に質問として書かせます。

3行目は、この構成の線引きです。 目標に届かない月ほど承諾をうながしたくなりますが、候補者の転職の判断は、紹介会社の月の目標とは関係がありません。

指示内容を固定する

あなたは人材紹介会社のチームリーダーを補佐する立場です。
今月の成約の見込みは、すでに決まった式で計算されています。
あなたの役割は、今週動かす候補として選ばれた選考について、
止まっている理由の候補と、リーダーがアドバイザーに確かめる点を出すことです。

【入力（選考ごと）】
- 選考ID（ハッシュ値）、職種区分、現在の段階、段階に入ってからの日数
- その段階の過去の日数の中央値と9割の値、今月中に承諾に至る確率
- 次の予定日（無ければ空）、候補者への最後の連絡からの日数、企業からの最後の連絡からの日数
- アドバイザーのメモの要旨（最新のもの）

【してほしいこと】
1. 選考ごとに、候補者の返事待ち／企業の結果待ち／日程の調整待ち／不明 のどれかを選んでください。
2. 止まっている理由の候補を最大2つ、根拠にした入力の項目名を付けて書いてください。
3. 今週の動きの種類を1つ選んでください。
4. リーダーがアドバイザーに確かめる点を1〜2個、質問の形で書いてください。

【厳守事項】
- 確率、成約数、日数を計算し直したり、修正したりしないでください。
- メモに書かれていない候補者の事情（他社の選考、家族の意見、年収への不満など）を、
  理由の候補として書かないでください。必要なら「確かめる点」に質問として書いてください。
- 理由の候補には、必ず evidence に入力の項目名を書いてください。
  evidence を書けない候補は出さないでください。
- 候補者に承諾をうながす文面や、候補者への連絡文を作らないでください。
- アドバイザーの仕事ぶりの良し悪しを書かないでください。
- 推薦の取り下げや、別の求人への切り替えを提案しないでください。
- 手がかりが少なく理由を絞れないときは "no_clear_reason" を true にしてください。

【担当の目標と見込み】{advisor_summary}
【選考ごとの入力】{applications}

「メモに無い事情を書かない」と「確かめる点に質問として書く」を対にしているのが要点です。 禁じるだけだと、AIは他社の選考の話を言い換えて別の欄に入れてきます。出口を用意すると、推測は質問の形に落ち着きます。 アドバイザーが「実は他社の最終面接が来週です」と答えれば、それが確かめられた事情になり、メモに書き足されます。

出力形式を固定する

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

{
  "advisor_code": "CA-17",
  "applications": [
    {
      "application_hash": "",
      "waiting_on": "candidate | company | scheduling | unclear",
      "reason_candidates": [
        { "text": "", "evidence": ["days_in_stage", "last_company_contact_days"] }
      ],
      "action_type": "confirm_company | confirm_candidate | schedule | align_terms | ask_advisor",
      "questions_for_advisor": [""],
      "no_clear_reason": false
    }
  ],
  "advisor_note": ""
}

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

2つ目は、waiting_on で誰の番かを分けられることです。 企業の結果待ちが多い担当と、候補者の返事待ちが多い担当では、リーダーが面談で話すことが違います。 前者は企業の担当の営業との連携、後者は候補者との面談の持ち方の話になります。一覧では waiting_on ごとに件数を数えて担当の行に出します。

3つ目は、no_clear_reason で「分からない」を正式な答えにできることです。 メモが空で手がかりが無い選考は、無理に理由を作らせず、アドバイザーへの質問だけを残します。

システムへ連携する

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

API キーと Webhook の URL、ハッシュ用の秘密の文字列は、コードに書かずスクリプト プロパティに置きます。 スクリプト プロパティはスクリプトのすべての利用者で共有されるため、スクリプトの編集権限は事業部の管理担当に限ります。 Webhook の URL は公開の場所に貼らないよう公式も注意しています。

Chat に送るのは、区分ごとの人数と一覧へのリンクだけです。 「届く見込み 14名、五分 9名、届かない見込み 7名、取り込み未了 0」のように書き、アドバイザーの名前と候補者の情報は載せません。 スペースにはリーダー6名と事業部長だけを入れます。

人が確認する

リーダーが見るのは、自分のチームの「届かない見込み」と「五分」の担当の行です。 「届く見込み」の担当は、見込みの件数と幅を確かめるだけにします。

1. 取り込みの状態を見る … 取り込み未了の印や、選考の件数が急に減った担当がないか。ここがおかしければ、その週の見込みを面談で使いません
2. 動かす選考の理由の候補を読む … 根拠の項目が選考の記録と合っているか、候補がメモと矛盾していないかを見ます
3. 確かめる点を面談用に直す … AIの質問を、自分の言葉に直します。候補者の事情を決めつける言い方になっていないかを見ます
4. 面談で今週の動きを決める … 動きを決めるのはアドバイザーとリーダーです
5. 確かめた事情をメモに残すよう頼む … アドバイザーが管理システムのメモに書き足します

理由の候補は「候補」のまま使い、確かめた結果が管理システムのメモに入れば、翌週の入力に入ります。

目標は、30名をならして1名4分です。 届かない見込みの担当が毎週10名を超えるなら、目標の置き方か通過率の表を先に疑います。

例外に対処する

7行目の扱いが大事です。 Gemini API が止まった朝でも、見込みの数字と届く確率は式で出ているので、一覧は予定どおり出せます。 理由の候補が無くても、リーダーは届かない見込みの担当と動かす選考を知ることができます。

記録を残す

• 取り込んだCSVのファイル名と取り込んだ日時、選考の件数
• 毎月1日に計算した通過率と日数の分布の表と、計算に使った期間と区分の決め方の版
• 毎週の担当ごとの見込みの平均・分布・届く確率・区分
• 月末の実際の承諾の件数と、各週の見込みとのずれ
• AIに渡した入力（ハッシュ値に置き換えたもの）と、返ってきたJSONの全文
• 根拠不一致で外した候補と、リーダーが直した・消した候補

4つ目が、式の確かさの記録になります。 「届く確率7割」の担当が実際に5割しか届いていなければ、通過率の表が甘いということです。

最後の行は、理由の候補の当たり外れを振り返る材料です。 「企業の結果待ち」ばかりが外れるなら、企業からの最後の連絡の日付が入力されていない可能性があります。