採用担当が選考の辞退の連絡と候補者アンケートの自由記述を選考の段階ごとに要約し、選考の進め方の改善の論点を毎月作る

処理の起点を決める

毎月の第1営業日の朝に、前月の分をまとめて動かします。 辞退が届くたびに動かすことはしません。1件ずつの要約は、傾向として並べて初めて意味を持つからです。届くたびに動かすと、採用の担当がその1件の要約を読んで、候補者に何かをしたくなります。

対象は前月の1日から末日までに「辞退」になった候補者と、その期間に届いたアンケートの回答です。 前月の末日に届いた辞退の連絡が、採用管理システムで翌月の1日に「辞退」にされることがあります。辞退の日付は採用管理システムの状態の変更日ではなく、連絡が届いた日で取ります。

定例の1週間前までに論点の下書きが出るように、第1営業日に動かします。 人事の企画が引用を確かめる時間を、定例の前に取るためです。

入力データを集める

質を決めるのは、区分の一覧の定義です。 「選考の速さ」と「面接の内容」の境目を決めておかないと、AIも人と同じように迷います。定義は「何が書かれていたらこの区分か」の形で書き、例文を2つずつ付けます。

各段階の日付を持たせるのは、選考の速さを件数で確かめるためです。 「連絡が遅かった」という記述が多い月に、一次面接から結果の連絡までの日数が実際に延びていたかを、Python が日付から出します。記述と日数を並べると、論点の重みが分かります。

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

メールは、候補者の記録とひも付けてから使います。 ひも付けの鍵は、候補者のメールアドレス、紹介会社のメールの件名にある候補者の番号の順です。どちらでもひも付かないメールは、要約に回さず人事の企画に一覧で返します。

アンケートの回答は、候補者にひも付けません。 匿名で答えてもらっているからです。本人が選んだ段階と経路だけで集計し、辞退の連絡とは別の束として扱います。 書き方や日付から誰の回答かを割り出すことはしません。

AIへ渡す前に整形する

1. ひも付け … 辞退の連絡を候補者の記録に結び、段階・経路・日付を付けます
2. 記号への置き換え … 候補者の氏名、メールアドレス、電話番号、現職と内定先の社名を、C-0412 や 社A のような記号に置き換えます
3. 署名と引用の除去 … メールの署名、過去のやり取りの引用部分を外し、その回の本文だけにします
4. 書き手の印付け … 本文の書き手が候補者本人か、紹介会社の担当者かを、送信元で印を付けます
5. 紹介会社のメールの分割 … 「候補者からは〜と伺っています」の部分と、担当者の所感の部分が分けられるものは分けます
6. 空の記述の除外 … アンケートで自由記述が空、または「特になし」だけのものは要約に回さず件数だけに入れます
7. 区分の一覧の版の固定 … その月に使う区分の一覧の版を記録します

2番目を省かないでください。 内定先の社名は、候補者の転職先という個人の情報です。論点を作るのに、どの会社に決めたかは要りません。 「同業の他社」か「異業種」かが要るなら、置き換えの際に区分だけを残します。

4番目と5番目は、この構成の中心です。 送信元で書き手が分かっても、紹介会社のメールの中には候補者の言葉と担当者の見立てが混ざります。分けられないものは、全体を担当者の言葉として扱います。

AIに処理させる

AIの仕事は2回に分けます。 1回目は1件ずつの要約と区分、2回目は段階ごとの論点の下書きです。

1回目（1件ずつ）

not_stated を付けられるようにしておくのが要です。 「他社で内定をいただいたため」には、なぜ他社にしたのかが書かれていません。これを「条件」や「選考の速さ」に推して入れると、件数が実際より多く出ます。 理由の書かれていない辞退は、書かれていないものとして数えます。

2回目（段階ごと）

Python が数えた区分と段階ごとの件数、前月との差、1回目の要約と引用の候補を渡し、段階ごとに改善の論点を3つまで書かせます。論点には、根拠にした件数（Python の値）と引用の記号を付けさせます。

2行目がいちばん起きやすい失敗です。 「他社決定」とだけ書かれた辞退を渡すと、何も言わなければ「選考期間が長く、他社が先に内定を出したと考えられる」と書いてきます。もっともらしいほど、定例でそのまま話されます。

指示内容を固定する

1回目の指示の例です。

あなたは人事部の採用グループで、選考の辞退の連絡とアンケートの
自由記述を読み、理由を整理する立場です。渡された本文に書かれて
いることだけをもとに答えてください。推測で補わないでください。

【区分の一覧（版 {category_version}）】{categories}

【答えること】
1. summary ........ 書かれている理由を1〜2文で
2. category ....... 区分の一覧から1つ。当てはまらなければ other
3. speaker ........ candidate／agent_view／unclear
4. reason_stated .. stated／not_stated
5. quote .......... category の根拠にした文をそのまま1つ
6. process_remarks  選考の進め方に関わる具体的な記述（無ければ空）

【厳守事項】
- 理由が書かれていない場合（「一身上の都合」「他社に決めた」だけ
  など）は reason_stated を not_stated にし、category は other に
  してください。なぜそうしたのかを推測しないでください。
- 「〜と伺っています」「〜のようです」など、紹介会社の担当者が
  候補者について述べている文は speaker を agent_view にしてください。
  候補者本人の言葉として扱わないでください。
- 書き手が本人か担当者か分からない場合は unclear にしてください。
- quote と process_remarks は本文をそのまま写してください。
  言い換えたり要約したりしないでください。
- 候補者・面接官・担当者の人柄や能力を評価しないでください。
- 記号（C-0412、社A など）を元の名前に戻そうとしないでください。
- アンケートの回答（source が survey のもの）について、誰が書いた
  かを推測しないでください。

【この記録の情報】段階: {stage} 経路: {channel} 種類: {source}
【本文】{text}

「なぜそうしたのかを推測しない」を明記しないと、not_stated は付きません。 理由の書かれていない文を渡すと、選考の段階と日付の情報から理由を組み立てようとします。段階と経路を渡しているのは集計のためで、理由を推すためではないことを、指示の側で止めます。

「〜と伺っています」を例に挙げているのは、紹介会社のメールの典型の言い回しだからです。 何も言わなければ、担当者の文も候補者の言葉として candidate が付きます。

出力形式を固定する

1回目は次の形の JSON で受け取ります。

{
  "record_id": "C-0412",
  "source": "decline_mail | ats_form | agent_mail | survey",
  "stage": "first | second | final | offer",
  "channel": "own_site | job_board | agent | referral",
  "summary": "",
  "category": "",
  "speaker": "candidate | agent_view | unclear",
  "reason_stated": "stated | not_stated",
  "quote": "",
  "process_remarks": ""
}

2回目は、段階ごとの論点を次の形で受け取ります。

{
  "month": "2026-10",
  "stage": "first",
  "points": [
    { "title": "", "basis_count_ref": "", "quote_refs": ["C-0412", "S-0087"],
      "speaker_mix": "candidate_only | includes_agent_view", "note": "" }
  ]
}

1つ目の理由は、speaker と reason_stated で件数を分けて数えられることです。 Python が区分ごとに「本人の言葉」「担当者の見立て」「理由の記載なし」に分けて数えると、定例の資料で「条件」の辞退のうち何件が本人の言葉かを示せます。

2つ目は、論点の根拠に戻れることです。 quote_refs から1回目の quote を引き、資料の論点の下に原文を並べます。引用は記号で持ち、資料に載せるときに人事の企画が確かめます。

3つ目は、speaker_mix で論点の重みが分かることです。 担当者の見立てだけでできた論点は、紹介会社との打ち合わせで確かめる論点として資料に分けて載せます。

スキーマの制約は Python で確かめます。 構造化出力のスキーマには文字列の長さの制約を書けないため、summary が長すぎないか、points が3つ以内かは受け取った後に調べます。quote が本文に含まれているかも、文字列の一致で確かめます。 含まれていなければ、その引用は資料に使いません。

システムへ連携する

採用管理システムには書き戻しません。 1件ずつの要約を候補者の記録の理由の欄に入れると、採用の担当が次の選考でその候補者を見るときに、AIの要約が目に入ります。 再応募の候補者の選考に、前回の辞退の要約が影響しないようにします。

1回目は Message Batches API、2回目は通常の呼び出しにします。 2回目は段階の数（4つ）しかなく、結果をすぐに見て直したいからです。

人が確認する

人が確かめるのは、論点と、論点に使う引用です。

1. 論点ごとに引用を開く … quote_refs の原文を読み、論点の言い方が原文から離れていないかを確かめます
2. 件数を確かめる … 論点の根拠の件数が、Python の集計表の値と同じかを見ます
3. agent_view を含む論点を分ける … 担当者の見立てを含む論点は、紹介会社と確かめる論点として載せます
4. 引用の言い回しを確かめる … 引用から候補者が分かるおそれがあれば、資料に載せる前に言い換えるか外します
5. 区分を直したら記録する … 1回目の区分を人が直したものは、どの区分からどの区分へ変えたかを残します

4番目を省かないでください。 「最終面接で〇〇部長に言われた一言」のような引用は、面接官と候補者の両方が分かります。定例には採用に関わる多くの社員が出るので、引用はそのまま貼りません。

1回目の要約は、全件は読みません。 区分ごとに数件ずつを抜き出して読み、区分の付き方がずれていないかを見ます。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、辞退の連絡の受け方と紹介会社とのやり取りの書き方の問題です。 紹介会社に「候補者の言葉はかぎかっこで書いてほしい」と頼むと、分けられる割合が上がります。

8行目は、要約の流れに乗せないでください。 面接での不適切な言動の申告は、傾向として数える話ではなく、1件ずつ事実を確かめる話です。

記録を残す

• 書き出した辞退の一覧とアンケートの回答（記号に置き換える前の元のもの。権限を絞った場所に）
• 記号と候補者の対応表（人事部の採用グループだけが見られる場所に）
• 1回目の JSON と、2回目の JSON
• Python の集計表（区分・段階・経路・speaker・reason_stated ごとの件数）
• 区分の一覧の版
• 人が区分を直した記録と、資料に載せなかった引用とその理由
• 定例で決めた改善の案と、その後の月の件数の変化

2つ目を分けて持つのは、要約の側に個人の情報を持ち込まないためです。 1回目と2回目の JSON には記号しか入らず、記号を戻せるのは対応表を見られる人だけになります。

最後の行が、この構成の本当の成果物です。 改善の案を決めた後に、その段階の辞退の区分がどう変わったかを毎月並べると、直したことが効いたかが分かります。