求人媒体のスカウトに届いた候補者の返信を、興味あり・条件の質問・辞退・日程調整に分類し、採用担当への通知と返信の下書きを作る

処理の起点を決める

通知メールの受信を起点にします。 共有の受信箱で、媒体ごとの送信元アドレスに「スカウト返信／媒体A」のようなラベルを付けるフィルタを作り、Gmail Trigger はそのラベルだけを見ます。ラベルで絞らないと、媒体のお知らせや請求のメールまで分類に流れます。

見に行く間隔は10分にします。 朝にまとめて処理すると、第3章の（a）がそのまま残ります。Gmail Trigger は既定で未読のメールだけを拾うので、人が先に開いて既読にした通知は拾われません。 読み状態の設定は「Unread and read emails」に変え、拾った通知の識別子を一覧に残して二重の処理を防ぎます。

本文の載らない媒体は、フォームを入口にします。 Form Trigger は、テキスト・テキストエリア・ドロップダウンなどの項目を持つフォームを作れるノードで、認証を「n8n User Auth」にすれば、ログインした人だけが使えます。 項目は「媒体」「スカウトの識別子」「返信の本文」の3つに絞ります。

フォームの「Respond When」は「Workflow Finishes」にします。 貼った人の画面に、分類の結果と下書きがその場で返ります。写した人がそのまま返事を書けるので、通知を待つ必要がありません。

入力データを集める

質を決めるのは、求人票の要点です。 条件の質問に答える下書きは、求人台帳に書かれた要点の範囲でしか作らせません。 要点の列が空だと、下書きは「担当から確認して回答します」ばかりになります。

過去のやり取りは、2通目以降の返信に効きます。 「先ほどの件ですが」で始まる返信は、本文だけでは何の話か分かりません。同じ識別子の前回の種類を添えると、日程調整の続きか条件の質問の続きかを取り違えません。

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

Gmail Trigger の「Simplify」は切ります。 既定の簡略化された応答はメッセージの識別子・ラベル・ヘッダーが中心で、分類に要る本文が手元に来ません。

識別子が取れないときは、求人を推測させません。 職種名が本文に書かれていても、同じ職種の求人は営業所ごとに複数あります。識別子が無い件は担当者を決めず、リーダーへ回します。

AIへ渡す前に整形する

1. 引用の除去 … 返信の下に付いている前回のスカウトの全文を、「----」や「＞」で始まる行、媒体ごとの引用の始まりの定型文で切ります
2. 署名と定型文の除去 … 媒体が自動で付ける「このメッセージは〇〇から送信されました」などの案内文を、媒体ごとの一覧で消します
3. 連絡先の伏せ字 … 本文中の電話番号とメールアドレスを [電話] [メール] に置き換えます。分類にも下書きにも要りません
4. 長さの確認 … 除去の後で本文が空、または数文字しか残らない件は、分類に回さず「その他」に置きます
5. 重複の確認 … 同じ通知の識別子が一覧にあれば、処理しません
6. 自動返信の検知 … 「不在」「自動応答」などの語と、送信元が媒体でないものを外します

1番目を軽く見ないでください。 引用を残したまま渡すと、スカウトの文面に書いた「ぜひ一度お話を」を、候補者の興味ありの言葉として読みます。 返信が「見送ります」の一言でも、下の引用の分量に引っ張られます。

3番目は分類の精度のためではありません。 候補者が返信に携帯番号を書いてくることはよくありますが、種類を決めるのにも、下書きを作るのにも使いません。 使わない個人情報は、AIに渡す前に落とします。

AIに処理させる

させるのは2つです。返信を5つの種類のどれか1つに分けること、種類ごとに返信文の下書きを作ることです。

2つにまたがるときの順は、上から日程調整・辞退・条件の質問・興味ありです。 日時が書かれていれば、質問が添えられていても日程調整にします。日時のある返信は、返事が遅れると候補日が過ぎるからです。 質問は下書きの中で一緒に扱います。

辞退を2番目に置くのは、「辞退するが条件だけ知りたい」を条件の質問にしないためです。 条件の質問に分けると、担当者は前向きな候補者だと思って返事を書きます。

4行目は、職業安定法の指針に沿うためです。 厚生労働省の指針は、労働者の募集を行う者を含む職業紹介事業者等が、業務の目的の範囲内で求職者の個人情報を集めることとし、人種、民族、社会的身分、門地、本籍、出生地その他社会的差別の原因となるおそれのある事項、思想及び信条、労働組合への加入状況を集めてはならないとしています（特別な職業上の必要性がある場合などを除く）。候補者が返信に自分から書いてきても、根拠の一文にも下書きにも写しません。

指示内容を固定する

Text Classifier には、カテゴリーごとに名前と説明を付けます。 説明は上の表の「当たる返信」をそのまま使います。System Prompt Template には次の文を入れます。{categories} はノードが置き換える部分です。

あなたは採用担当の補助として、スカウトへの候補者の返信を1つの種類に分けます。
分ける先は次のとおりです。
{categories}

【1つに決めるときの順】
2つ以上に当たるときは、日程調整 → 辞退 → 条件の質問 → 興味あり の順で、
先に当たるものを選んでください。

【厳守事項】
- 返信の本文だけを見てください。スカウトの文面の引用は取り除いてあります。
  残っていても、候補者の言葉として扱わないでください。
- 「検討します」「また連絡します」のように、前向きとも辞退とも読めない返信は、
  興味ありにしないでください。どれにも当たらないものとして扱ってください。
- 候補者の出身地、本籍、家族、思想・信条、労働組合などの記載があっても、
  分類の根拠にしないでください。

下書きを作る Basic LLM Chain には、種類ごとに別の指示を置きます。 条件の質問の例です。

あなたは{company}の採用担当者として、スカウトへの返信に答える下書きを書きます。
送るのは担当者で、媒体の画面に貼って使います。

【答えてよい範囲】
次の「求人票の要点」に書かれていることだけを答えてください。
要点に無いことは答えず、「担当より確認のうえ、改めてご連絡します」とし、
unanswered に質問の内容を書き出してください。
数字を丸めたり、幅を広げたり、「おおむね」「程度」と言い換えたりしないでください。

【書き方】
- 200字から350字。候補者の名前は {candidate_name} を使い、無ければ「〇〇様」
- 最後に、面談をご希望であれば候補日をいくつかいただきたい旨を一文で添える
- 選考の合否、面接の確約、入社の時期を約束する表現を使わない
- 候補者の連絡先、出身地、家族などには触れない

【求人票の要点】{job_summary}
【候補者の返信】{reply_text}

「要点に無いことは答えない」を、答えられなかった質問の書き出しと組にしています。 答えるなとだけ書くと、「一般的には」と前置きして答えます。書き出す先を用意すると、答えない理由がAIの側で成り立ちます。 書き出された質問は、担当者が現場に聞く項目の一覧になります。

出力形式を固定する

Structured Output Parser で、次の形のJSONを受け取ります。 種類はワークフロー側で Text Classifier の出口から入れます。

{
  "scout_id": "",
  "media": "",
  "category": "schedule | decline | question | interested | other",
  "evidence": "",
  "draft": "",
  "unanswered": [""],
  "needs_attention": false
}

たとえば「興味はありますが、在宅勤務はどのくらいできますか。来週の火曜の夕方なら話せます」という返信なら、次のようになります。

{
  "scout_id": "A-20261007-0153",
  "media": "媒体A",
  "category": "schedule",
  "evidence": "来週の火曜の夕方なら話せます",
  "draft": "〇〇様　ご返信ありがとうございます。在宅勤務は週2日まで可能です（求人票の記載のとおり）。火曜の夕方の具体的な時間は、担当より改めてご連絡します。",
  "unanswered": [],
  "needs_attention": false
}

質問と日時が両方ある返信は、日程調整に分かれ、質問への答えは下書きの中に入ります。 1つに決める順が、ここで効いています。

evidence は分類の根拠にした返信の一文をそのまま写したもの、unanswered は求人票の要点で答えられなかった質問、needs_attention は強い苦情や個人情報の削除の依頼などが含まれるときに立てる印です。

1つ目の理由は、evidence で分類を一目で確かめられることです。 担当者は返信の全文を読む前に、どの一文で「辞退」になったかを見られます。引用の消し損ねで種類を誤ったときも、evidence がスカウトの文面になっているのですぐ分かります。

2つ目は、unanswered が別の欄になることです。 下書きの本文に埋もれると、担当者が現場に聞き忘れます。一覧の列にしておけば、週ごとに「よく聞かれるのに求人票に無いこと」が数えられ、求人票の書き直しにつながります。

3つ目は、needs_attention で通常の流れから外せることです。 「何度も送ってこないでほしい」「登録情報を消してほしい」は、下書きで返す性質のものではありません。印が立った件は下書きを使わず、リーダーへ回します。

Structured Output Parser は JSON の例から形を作る方法と JSON Schema で書く方法を選べますが、例から作るとすべての項目が必須として扱われます。 unanswered は空の配列を返せるように、例には空の要素を1つ入れておきます。

システムへ連携する

媒体の管理画面とはつなぎません。 返事は担当者が画面から送り、送ったら一覧の「送信済み」に印を付けます。媒体に自動で送る経路を作らないことが、この構成の前提です。

求人台帳は読むだけです。 担当者が空欄の求人があっても、ワークフローは埋めません。

人が確認する

担当者は、自分に回ってきた返信の分類と下書きを確かめてから送ります。 確かめる順は次のとおりです。

1. evidence を読む … 根拠の一文が候補者の言葉か、引用の消し損ねかを見ます
2. 種類が合っているかを決める … 違えば一覧で種類を直します。直した記録が、後で分類の説明文を見直す材料になります
3. 下書きを直す … 条件の答えが求人票と合っているかを見ます。unanswered があれば、現場に聞いてから送るか、確認中の旨で先に送るかを決めます
4. 媒体の画面から送り、一覧に印を付ける

辞退の下書きは、読んで送るだけで済むことが多いはずです。 第10章の1件2分は、辞退のように短く済むものと、条件の質問のように確かめる項目が多いものをならした時間です。

日程調整の下書きは、そのまま送れない形にしてあります。 候補日を入れる欄が空いているので、担当者が自分の予定を見て埋めるまで送れません。面談の日時を確定する作業は、この構成の外に置いています。 日程の調整そのものを自動にしたい場合は、UC-0069 の構成につなぎます。

その他に分けられた件は、リーダーが見ます。 件数が増える月は、分類の説明文が実際の返信の書き方に合っていない合図です。

例外に対処する

一番多いのは1行目と3行目です。 どちらもAIの判断の問題ではなく、媒体の通知の書式の問題です。 媒体が通知の書式を変えると、識別子の正規表現と引用の定型文が同時に外れます。「その他」と「識別子なし」が急に増えた日は、まず通知メールの書式を見ます。

記録を残す

• 通知メールの識別子、媒体、受信日時、スカウトの識別子
• 前処理の後の本文（連絡先を伏せ字にしたもの）
• 分類の結果、evidence、下書き、unanswered、needs_attention
• 担当者が種類を直した記録 … どの種類からどの種類へ
• 送信済みの印を付けた日時と、通知を受けてからの経過時間
• 夕方の未送信一覧に載った件

前処理の前の本文は、返信の一覧に残しません。 原文は媒体の管理画面と受信箱にあります。一覧に写すのは、分類と返事に要る範囲までです。

経過時間の記録が、この構成の効き目を測る物差しです。 興味ありと日程調整の返信が、通知から何時間で返事を受けたかを週ごとに見ます。