人材紹介のキャリアアドバイザーが候補者を推薦する前に、求人企業ごとの過去の選考結果と見送りの理由を探し、通りやすい経歴と見送られやすい点を根拠の記録付きで返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、案件管理の仕組みで選考の結果が登録されたことを起点にします。 書類、一次、二次、最終のどの段階の結果でも取り込みます。「書類は通ったが一次で見送り」という経過そのものが、企業が何を見ているかを表すためです。 結果を通知できない仕組みなら、毎晩、結果の登録日で絞った一覧を取りに行きます。

過去の約3万件は、別に一括で取り込みます。 このときは法人担当の確認が取れないので、仕分けに「未確認」の印を付けます。企業の採用方針が変わっていることがあるので、推薦日も検索結果に必ず出します。

検索は、キャリアアドバイザーが推薦の画面で「過去の選考を見る」を押したときに動きます。 推薦文を書く前に押してもらいます。推薦文を書き終えてから見ても、経歴のどこを伝えるかを直す時間が残らないためです。

入力データを集める

質を決めるのは、理由の文の書き方です。 「総合的に判断」とだけ書かれた見送りは、何も教えてくれません。法人担当が企業に理由を聞くときに、経験・志向・条件のどれかを聞く習慣をつけることが、この構成のいちばんの準備です。

候補者の氏名・生年月日・連絡先・現職の社名は、最初から取り込みの対象にしません。 経歴の要約は、業界と職種と年数の言葉で書きます。同じ候補者が別の企業に推薦された記録を、検索基盤の中で結びつけることもしません。

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

選考の記録は、案件管理の仕組みから文字で取り出します。職務経歴書のファイルそのものは取り込みません。 推薦のときに書いた推薦文から、経歴の要約だけを作ります。

索引の項目は、次のように持たせます。

reason_text を検索の点数に使わないのは、理由の言葉で当たった記録は、経歴が近いとは限らないためです。 「マネジメント経験不足」で当たった記録が、まったく違う職種のものということが起きます。

AIへ渡す前に整形する

1. 経歴の要約の作成（取り込み時） … 推薦文から、直近の職種、業界、経験年数、商材、マネジメントの有無、資格だけを取り出します
2. 個人を特定する言葉の除去 … 氏名、現職と前職の社名、学校名、生年を正規表現と Claude の確認で伏せます
3. 理由の仕分け（取り込み時） … 企業からの理由の文を4つの区分に分けます
4. 適性・能力と関係のない事柄の分離 … 仕分けで当たった文は、索引に入れず、法人担当の確認の一覧に入れます
5. 求人の版の付与 … 推薦日に効いていた求人の版を記録に付けます
6. 検索の入力の確認 … キャリアアドバイザーが入れた経歴の要約に、氏名や社名が入っていれば伏せてから検索します

4番目を軽く見ないでください。 厚生労働省の公正採用選考のページでは、採用選考は応募者の適性・能力に基づいた基準により行うことが基本とされ、本籍・出生地、家族、住宅状況、宗教、支持政党などを把握することが就職差別につながるおそれがある14事項として挙げられています。企業からの理由にこうした事柄が書かれていたら、それを「傾向」として検索に出すと、差別につながる判断を仕組みが広めることになります。

2番目で現職の社名を伏せるのは、候補者を特定しないためです。 「〇〇社でSaaSの新規開拓」と書けば、同じ業界の人には誰か分かります。社名は業界と規模の言葉に置き換えます。

AIに処理させる

AIの仕事は2か所です。取り込み時の仕分けと、検索結果のまとめです。

1行目がいちばん外せない線です。 似た経歴の3件が全部書類で見送られていると、AIは「この候補者は書類で見送られる可能性が高い」と書きたくなります。その一文で推薦をやめると、候補者の機会が、数件の過去の記録で閉じます。

3行目は、指示に入れないと起きます。 「マネジメント経験不足」で見送られた例を見せると、AIは「推薦文でリーダー経験を強調しましょう」と書き、事実以上に書く方向の提案になりがちです。

指示内容を固定する

取り込み時（理由の仕分け）：

あなたは人材紹介会社で、求人企業から届いた選考結果の理由を整理する担当です。
理由の文に書かれたことだけを根拠にしてください。推測で埋めないでください。

【仕分けの区分】
- skill：経験、スキル、実績、資格に関すること
- preference：志向、転職の理由、条件（年収、勤務地、働き方）の合わなさ
- process：選考の進め方（日程、他の候補者との比較、募集の停止）
- non_merit：本人の適性・能力と関係のない事柄（本籍・出生地、家族、住宅、
  生活環境、宗教、思想・信条、支持政党、労働組合など）

【厳守事項】
- 1つの文に複数の区分が含まれるときは、文を分けてそれぞれに区分を付けてください。
- non_merit に当たる文は、内容を要約せず、該当箇所の位置だけを返してください。
- 理由の文に書かれていない理由を足さないでください。
  「総合的に判断」とだけあれば、区分は unknown にしてください。
- 候補者の人柄や性格を表す言葉を、区分の名前にしないでください。

検索時（結果のまとめ）：

あなたは人材紹介会社のキャリアアドバイザーの調べものを助ける係です。
渡された検索結果だけを根拠に、この企業の過去の選考を並べてください。

【推薦先の求人】{job}
【推薦したい候補者の経歴の要約】{career}
【過去の推薦（結果ごとに最大3件）】検索結果として渡します
【理由の区分ごとの件数】{reason_counts}

【書くこと】
1. 結果ごとに、各推薦の経歴の要約、到達した段階、理由（記録番号と推薦日を添える）
2. 通った推薦と見送られた推薦で、経歴の要約に書かれた違い
3. 推薦日が求人の改定より前の記録には、その旨

【厳守事項】
- 今回の候補者が通るか、見送られるかを書かないでください。
- 推薦するべきか、やめるべきかを書かないでください。
- 推薦文で経歴をどう書くかを提案しないでください。
- 件数の多い見送りの理由を、今回の候補者に当てはめないでください。
- 候補者の人柄や性格に触れないでください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の推薦を1つの search_result にし、source に推薦番号、title に結果の区分と到達した段階と推薦日、content に経歴の要約と理由の文を別々のテキストブロックで入れます。 引用はテキストブロックを単位に付くので、まとめのどの文が経歴から、どの文が企業の理由から来たかが分かります。

出力形式を固定する

取り込み時の仕分けは、次の形のJSONで受け取ります。

{
  "recommendation_id": "RC-2025-020417",
  "client_id": "C-0381",
  "job_family": "sales_saas",
  "stage_reached": "first_interview",
  "outcome": "rejected_interview",
  "reasons": [
    { "class": "skill | preference | process | non_merit | unknown", "span": [0, 42] }
  ],
  "career_summary": "",
  "non_merit_flag": false,
  "unconfirmed": false
}

1つ目の理由は、outcome を決まった値に限れることです。 collapse で束ねる項目は、値の揺れがあると束が割れます。「一次NG」「一次見送り」「1次不合格」を1つの値にそろえるのは、取り込みの段で行います。

2つ目は、reasons を区分と位置で持てることです。 理由の文の中のどの部分がどの区分かを位置で残すので、引用のときに non_merit の部分を除いて渡せます。

3つ目は、non_merit_flag で、企業ごとの件数を数えられることです。 同じ企業から繰り返し届くなら、法人担当がその企業の採用担当と話す材料になります。

検索の要求は、次のように組みます。

{
  "query": {
    "bool": {
      "must": { "match": { "career_summary": "{career}" } },
      "filter": [
        { "term": { "client_id": "C-0381" } },
        { "term": { "job_family": "sales_saas" } }
      ]
    }
  },
  "collapse": {
    "field": "outcome",
    "inner_hits": { "name": "top3", "size": 3, "sort": [ { "_score": "desc" } ] }
  },
  "aggs": { "reasons": { "terms": { "field": "reason_class" } } }
}

集計は collapse の影響を受けません。 ドキュメントでは、collapse は上位の検索結果だけに効き、集計には効かないとされています。結果ごとに3件だけを見せながら、理由の区分の件数は、絞った範囲の全件で数えられます。 逆に、hits.total は束ねる前の件数なので、画面には「経歴の近い推薦 全N件のうち、結果ごとに上位3件」と書きます。

システムへ連携する

inner_hits を何組も足さないようにします。 ドキュメントでは、inner_hits の要求が多いと検索がかなり遅くなることがあるとされています。束は結果の区分の4つだけ、inner_hits は1組にします。

ページの送り方にも注意します。 collapse を search_after と使うときは、束ねる項目と並べ替えの項目が同じで、並べ替えは1つだけとされています。この構成では送る操作は作らず、もっと見たいときは案件管理の仕組みで元の一覧を開きます。

人が確認する

確認は2か所です。取り込み時の法人担当と、検索時のキャリアアドバイザーです。

1. 法人担当が仕分けを確定する … 区分の付け方と経歴の要約を確かめます。non_merit_flag の記録は必ず開き、企業への伝え方を決めます
2. キャリアアドバイザーが推薦を決める … 結果ごとの一覧と理由を読み、推薦するか、推薦文で何を伝えるかを自分で決めます
3. 求人の改定より前の記録は割り引いて読む … 必須の条件が変わっていれば、当時の見送りの理由は今は当てはまらないことがあります
4. 迷うときは法人担当に聞く … 一覧を見たうえで聞くので、「この人は通りそうですか」ではなく「この記録の理由は今も生きていますか」と聞けます

1件あたり4分を目安にします。 一覧とまとめを読み、必要なら元の記録を1件開く時間です。まとめの文を候補者にそのまま伝える運用にはしません。 候補者に伝えるのは、キャリアアドバイザーが選んだ言葉です。

例外に対処する

4行目が、この構成でいちばん大事な例外です。 見送りの理由に書かれた事柄が企業の側の問題でも、それを避けて推薦する人を選べば、紹介会社が差別に加わることになります。 検索の段で見せないことで、その選び方ができない仕組みにします。

記録を残す

• 取り込んだ記録の推薦番号、結果の登録日、取り込んだ日時
• Claude が返した仕分けのJSONと、法人担当が確定したときに直した区分
• non_merit_flag の記録と、法人担当が決めた企業への対応
• 検索のたびの求人、伏せたあとの経歴の要約、結果ごとの上位3件、理由の区分の件数
• Claude に渡した検索結果と、返ってきたまとめと引用
• キャリアアドバイザーが推薦したか、しなかったかと、その後の選考の結果

最後の行は、仕組みの効き目を測る材料です。 一覧を見たうえで推薦した人の書類の通過率が、見なかったときと比べてどう動いたかを、半年ごとに確かめます。