社員紹介の推薦を受けて、紹介者のコメントと候補者の経歴を募集要件と照らし、カジュアル面談の前に確かめる論点を Azure OpenAI でまとめる

処理の起点を決める

起点は、採用管理の仕組みに推薦が登録されたことです。 Webhook を出せる仕組みならそれを受け、出せないなら Azure Functions のタイマーで数分おきに新しい推薦を取りに行きます。推薦は届いたその日のうちに面談の設定に進めたいので、1日1回のまとめての処理にはしません。

職務経歴書が添付されていない推薦は、処理を止めて待ちます。 紹介者のコメントだけで要約を作ると、要件ごとの欄がほぼ「紹介者の見立て」か「不明」になり、面談者には紹介者の印象を整えただけの資料が渡ります。 添付が届いた時点で処理を再開します。

推薦の職種が変わったときも、作り直します。 採用担当が別の職種のほうが合うと判断して職種を変えたら、新しい職種の要件で要約をやり直します。前の職種で作った資料は、面談メモ欄に残しません。 2つの職種の資料が並ぶと、面談者がどちらの要件で話せばよいか迷います。

候補者が辞退したときは、処理の途中でも止めます。 採用管理の仕組みで推薦の段階が「辞退」に変わったら、下書きを消し、確認待ちの通知も取り下げます。

入力データを集める

質を決めるのは、募集要件の書き方です。 「主体性がある」「コミュニケーション力が高い」のような要件は、書類からは照らせません。要件が抽象的だと、どの欄も「不明」か「紹介者の見立て」になります。 最初の準備は、必須要件を「何を、どの規模で、どれくらいの期間やったか」の形に直すことです。

紹介者のコメントには、一緒に働いた期間と立場を必ず書いてもらいます。 同じ「優秀」でも、同じチームで3年一緒だった人の見立てと、勉強会で一度話しただけの人の見立てでは重みが違います。受付フォームの項目を足すのが早い対策です。

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

公開のプロフィールは、プログラムで取りに行きません。 候補者が推薦に添付を認めた範囲だけを、採用担当が貼ります。候補者が知らないところで、ネット上の情報を集める仕組みにはしません。

職務経歴書の文字は、段落と箇条書きの区切りを残して取り出します。 根拠の照合（第5章の5番目）で、AIが写した一節を元の文から探すために使います。

AIへ渡す前に整形する

1. 推薦の重複を確かめる … 同じ候補者が別の社員から推薦されていないか、氏名と連絡先で確かめます。重複していれば先の推薦に紐付けます
2. 職務経歴書の文字を取り出す … 画像だけのPDFで文字が取れないときは、採用担当に知らせて処理を止めます
3. 外す話の候補に印を付ける … 語の一覧に当たる箇所を、紹介者のコメントと職務経歴書の両方で探し、位置を記録します
4. 氏名と連絡先を記号に置き換える … 候補者と紹介者の氏名、電話番号、メールアドレスを「候補者」「紹介者」に置き換えてから渡します
5. 要件を引く … 推薦された職種の必須要件・歓迎要件を、番号付きで並べます
6. 長さを確かめる … 職務経歴書が極端に長いときは、直近10年分の職歴を先に、それ以前を後に並べ替えます

3番目は、AIに任せきりにしないための仕組みです。 語の一覧で印を付けた箇所は、AIの出力の「外した箇所」と突き合わせます。語の一覧で見つかったのにAIが外していないものがあれば、資料を止めて採用担当に回します。

語の一覧は、14事項を社内の言葉に直して作ります。 「奥さん」「ご両親」「実家」「持ち家」「社宅」「出身」「信仰」のような語で、完全に拾うことは目指しません。 語の一覧が拾い、AIが外し、採用担当が見る、の3つが重なることで漏れを減らします。語の一覧は、半自動化の期間に外れた例を見て足していきます。

AIに処理させる

させるのは、要件ごとの3つの区分への仕分けと、確認論点の列挙です。

右端の列のうち、いちばん大事なのは「不明」を残すことです。 職務経歴書に「チームで開発」としか書かれていないとき、AIは紹介者の「チームを引っ張っていた」を根拠に「リーダー経験あり」と書きがちです。書類に無ければ、紹介者の見立ての欄に入れ、事実の欄は「不明」のままにします。

4行目が起きやすい失敗です。 紹介者のコメントに「家庭の事情で」とあると、AIは「家族の事情による転職」と要約に入れます。転職の理由は面談で本人が話すことで、紹介者の推し量りを資料にすると、面談者が家族の話題に触れます。

指示内容を固定する

あなたは採用担当の補助として、社員紹介で届いた推薦を、
カジュアル面談の前に面談者へ渡す資料に要約します。
合否や適否を判断する立場ではありません。

【要約の仕方】
- 募集要件の1項目ごとに、次の3つに分けて書いてください。
  fact ......... 職務経歴書に書かれている事実
  referrer_view  紹介者のコメントに書かれている見立て
  unknown ...... どちらにも書かれていないこと
- fact と referrer_view には、根拠にした一節を原文のまま quote に写してください。
- 職務経歴書に書かれていないことを fact に書かないでください。
  紹介者のコメントだけが根拠なら、referrer_view に書いてください。
- 紹介者のコメントから、一緒に働いた期間と立場を relationship に写してください。
  書かれていなければ「関係の記載なし」としてください。

【確認論点】
- 面談で本人に聞けば確かめられる問いだけを、5つまで挙げてください。
- unknown の項目と、referrer_view だけが根拠の項目から作ってください。
- 問いは仕事の経験と役割についてだけにしてください。

【資料に載せないこと】
- 家族（職業・続柄・健康・学歴・収入など）、住まい（住宅の種類・近隣など）、
  本籍・出生地、生活環境・家庭環境、宗教、思想・信条、支持政党、
  尊敬する人物、購読新聞・愛読書、労働組合や社会運動に関すること。
- これらに当たる記載があったら、要約にも論点にも入れず、
  excluded に「どの入力の、どの一節を外したか」だけを書いてください。
- 迷ったら外して excluded に書いてください。

【禁止事項】
- 合否、適否、要件を満たす度合い、点数を書かないでください。
- 転職の理由を推し量って書かないでください。
- 紹介者を評価しないでください。

【募集要件】{requirements}
【紹介者のコメント】{referral_comment}
【職務経歴書】{resume_text}

「迷ったら外して excluded に書く」を入れるのは、外すかどうかを人が決めるためです。 外しすぎたものは採用担当が戻せますが、載せてしまったものは面談者が読んだ時点で取り消せません。 誤る方向を、取り返せるほうに寄せます。

載せないことの一覧は、公正採用選考特設サイトの14事項を写しています。 「プライバシーに配慮して」と書くだけでは、AIは住まいの話を「通勤の事情」として残します。項目を名指しで並べます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "position_code": "ENG-BE-03",
  "relationship": "前職で同じチーム。約2年",
  "requirements": [
    {
      "req_id": "M1",
      "level": "must",
      "fact": "決済APIのバックエンドを3年担当",
      "fact_quote": "決済APIのバックエンド開発（2021年4月〜2024年3月）",
      "referrer_view": "障害対応で頼りにされていた",
      "referrer_quote": "障害のときはまず彼に聞くという雰囲気でした",
      "unknown": ""
    }
  ],
  "questions": [
    { "text": "障害対応で、どこまでを一人で判断していたか", "from": ["M1"] }
  ],
  "excluded": [
    { "source": "referral_comment", "snippet": "（家族に関する記載）" }
  ]
}

1つ目の理由は、出どころを項目として分けられることです。 fact と referrer_view が別の項目なので、画面では色を変えて出せます。 面談者は、どれが書類の事実で、どれが紹介者の見立てかを一目で見分けられます。

2つ目は、根拠の照合ができることです。 fact_quote と referrer_quote を元の文から探し、見つからなければその要件の行に印を付けて採用担当に回します。

3つ目は、excluded で外したことを記録できることです。 snippet には外した一節そのものを入れず、「家族に関する記載」のような種類だけを入れます。外した中身を、別の場所に残さないためです。

スキーマの制限に合わせます。 公式のページでは、オブジェクトのプロパティは最大100個、入れ子は最大5レベルで、文字列の minLength・maxLength・pattern・format、配列の minItems・maxItems は使えないとされています。論点を5つまでに抑えるのは指示で行い、受け取った後にプログラムで数を確かめます。 出力のキーはスキーマと同じ順に並ぶので、画面の並びもスキーマで決めます。

確定した資料は、面談者には次のような形で見せます。

【推薦】バックエンドエンジニア（ENG-BE-03）　紹介者との関係：前職で同じチーム。約2年
【必須要件】
 M1 決済APIの開発経験　　　事実：決済APIのバックエンドを3年担当
　　　　　　　　　　　　　 紹介者の見立て：障害対応で頼りにされていた
 M2 設計レビューの経験　　　不明（書類にも紹介者のコメントにも記載なし）
【歓迎要件】
 W1 クラウドの運用経験　　　事実：AWS での運用を1年
【面談で確かめたいこと】
 1. 障害対応で、どこまでを一人で判断していたか（M1）
 2. 設計の段階でどのように関わっていたか（M2）
【資料から外した記載】1件（採用担当が確認済み）

面談者には excluded の中身を見せず、件数と「確認済み」だけを出します。 外したことは伝わり、何を外したかは伝わらない形です。「不明」の行は空欄にせず、「記載なし」と明示します。 空欄だと、書き忘れなのか確かめていないのかが面談者に分かりません。

システムへ連携する

面談者には、確定した資料だけが見えます。 採用担当が確定するまでは、AIの下書きは採用担当だけが見られる場所に置きます。

紹介者に追加で聞くときは、採用担当が自分の言葉で聞きます。 論点の一覧を紹介者へそのまま送ることはしません。紹介者にとっては、自分の推薦が審査されているように読めるからです。

人が確認する

人が確かめるのは、すべての推薦です。 資料は面談者へ渡る前に、必ず採用担当が読みます。

1. 外した箇所を先に見る … excluded と、前処理で語の一覧が印を付けた箇所を突き合わせます。AIが外していない印があれば、資料から外します
2. 事実の欄の根拠を確かめる … fact_quote が職務経歴書のどこにあるかを見ます。照合で印が付いた行は、必ず原文を開きます
3. 論点を直す … 面談者が聞きやすい言葉に直し、職種の事情で外せない論点があれば足します
4. 確定する … 確定した資料だけが面談メモ欄に入ります

1番目を先にするのは、読んでしまう前に外すためです。 採用担当も、要約を読み進めてから外す話に気づくと、それを知った状態で論点を直すことになります。

目標は1件6分です。 外した箇所の確認に1分、事実の根拠の確認に2分、論点の手直しと確定に3分という見込みで、第10章はこれに合わせています。

例外に対処する

最後の行は、AIの問題ではなく運用の問題です。 紹介者が面談者の上司だと、面談者は紹介者の見立てを否定しにくくなります。社内の名簿で紹介者の部署を引き、資料に出すだけで、採用担当が面談者を選び直せます。

記録を残す

• 推薦の受付番号、職種コード、処理した日時
• AIへ渡した入力（氏名と連絡先を記号に置き換えた後のもの）と、返ってきたJSON
• 根拠の照合の結果と、語の一覧の印との突き合わせの結果
• 採用担当が直した箇所と確定した資料
• 外した箇所の種類と件数（中身は残さない）

外した箇所の中身を残さないのは、残すと別の場所に同じ情報が溜まるからです。 種類と件数だけを残し、「家族に関する記載が月に何件あったか」を見ます。件数が多ければ、紹介者への案内を見直す材料になります。

保存期間は、採用管理の仕組みの候補者の記録に合わせます。 不採用や辞退になった候補者の記録を消すときに、この仕組みのログも同じ時期に消します。