リファレンスチェックの依頼と回収を回して、選考記録に残す

処理の起点を決める

起点は2つ、見張りが1つです。

1つ目の起点で、必ず同意の記録を確かめてください。 同意の日付と範囲が空欄の行は、そこで止めます。エラーとして採用担当に知らせ、案件を先へ進ませません。 ここを「後から埋めればよい」にすると、同意の無いまま依頼状が下書きされ、誰かが気づかずに送ります。

2つ目の起点は、フォームの送信とメールの受信の両方を見ます。 推薦者にフォームを使ってもらうほうが整理は楽ですが、メールで返したい人に強いることはできません。 どちらでも受け取れる形にしてください。

3つ目の見張りが、期限切れの放置を防ぎます。 期限を過ぎた案件を毎日拾い、再依頼の下書きを作ります。再依頼は1回までにしてください。 推薦者は無償で協力してくれている社外の人です。催促が重なると、次に別の候補者で依頼したときに応じてもらえなくなります。

2回目の期限も過ぎたら、催促ではなく採用担当へ知らせます。 「この推薦者からは回答が得られていない」という事実を最終選考へ持っていくのも、1つの結論です。回答が無いことを、無理に埋めないでください。

入力データを集める

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

同意の記録： この構成の入口なので、形を決めておきます。

「開示の範囲」と「本人への開示の可否」を、依頼の前に決めておいてください。 推薦者から「候補者本人に伝わりますか」と聞かれることがあります。その場で決めると、案件ごとに答えが変わります。

聞いてよい観点の定義： 募集要件から質問を作る土台です。厚生労働省は、応募者が求人職種の職務遂行上必要な適性・能力をもっているかどうかという基準で採用選考を行うことを求めています。観点はこの基準の内側だけで作ります。

5つ目の観点は、答えにくい形で聞かないでください。 「また働きたいか」は推薦者にとって重い問いです。理由まで求めず、答えたい人が答えられる形にしておきます。

聞いてはいけない事項の一覧： ここを作る作業が、導入でいちばん重い部分です。区分と、実際に出てくる言い回しの両方を書いてください。

区分名だけでは足りません。 「宗教」と書いてあっても、実際の回答は「毎週日曜は集まりがあるので」という形で届きます。過去の回答から、実際に出てきた言い回しを10例ほど拾って一覧に添えてください。 想像で書くと、現実の文章と噛み合いません。

推薦者の情報： 氏名・連絡先・勤務先は、依頼状を作るときだけ使います。回答の要約を生成AIへ渡す段では、識別子に置き換えます。 関係（前職の上司／同僚／取引先）と在籍期間の重なりは、要約の文脈として必要なので残します。

AIへ渡す前に整形する

1. 同意の記録の照合 … 候補者の識別子で同意の行を引き、日付と範囲が埋まっているかを確かめます。空欄なら、ここで止めます
2. 識別子への置き換え … 候補者と推薦者の氏名・連絡先・勤務先を、候補者の識別子と推薦者の識別子に置き換えます
3. 回答の本文の取り出し … メールの返信からは、引用された依頼状の本文と署名を落とします。フォームからは設問ごとの回答をそのまま取ります
4. 質問との対応づけ … 回答の各部分が、どの質問への答えかを対応させます。メールの返信では、質問の順番どおりに書かれているとは限りません
5. 重複と再送の判定 … 同じ推薦者から2通目が届いた場合、追記なのか差し替えなのかを判定します
6. 回答の長さの確認 … 極端に短い回答と長い回答を、後の処理で区別できるよう記録します

2の置き換えが、外部へ渡す範囲を決めます。 氏名を渡さなくても、観点ごとの要約は作れます。渡さずに済むものを渡さないのが、この構成の基本の形です。

3の署名落としは、見落としやすい部分です。 メールの署名には推薦者の勤務先と電話番号が入っています。これを落とさないと、2の置き換えが意味をなくします。

4の対応づけは、生成AIに任せてよい部分です。 「1つ目の質問について」と番号で書いてくれる人ばかりではありません。文章で通して書かれた回答から、どの観点に触れているかを拾わせます。

AIに処理させる

4つの処理をさせます。

（1）募集要件から質問を組み立てる

募集要件を読み、上の観点ごとに質問文を作ります。質問は5〜7問に絞ってください。 推薦者は無償で協力しています。10問を超えると、一問あたりの答えが薄くなります。

職種によって、厚くする観点が変わります。 管理職なら「担当した業務の範囲」を組織の規模で聞き、専門職なら「実際の成果と関与の度合い」を技術の範囲で聞きます。募集要件に書かれている責任の範囲から、どの観点を厚くするかを決めさせます。

聞いてはいけない事項に当たる質問を作らせないことが、1段目の守りです。 「残業への対応はいかがでしたか」は、家庭の事情を引き出す質問になりかねません。「期限の管理はいかがでしたか」に言い換えます。 禁止する区分をプロンプトに並べ、その区分に触れる質問を出力しない制約を置きます。

（2）依頼状の下書きを作る

質問と、同意の記録の内容から文面を作ります。入れる要素は決まっています。

「断れること」を必ず書いてください。 推薦者には答える義務がありません。義務があるかのような文面にすると、無理に答えてもらうことになります。

（3）回答を観点ごとに要約し、引用を添える

観点ごとに、要約と原文の引用を並べます。引用は言い換えずに、原文をそのまま写させてください。 要約だけでは、担当者が元の言い回しを確かめられません。

触れられていない観点は、not_mentioned として残します。 ここを「評価が低い」と読み替えないでください。推薦者が触れなかった理由は、知らなかった、思い当たらなかった、書く時間がなかった——いろいろあります。 出力の段階で low と not_mentioned を別の値にしておけば、読む側が混同しにくくなります。

（4）聞いてはいけない事項の点検

回答の中に、一覧の区分に当たる記述が無いかを見ます。当たる記述は、要約の本文に含めず、別の欄へ分けます。 区分と、なぜ当たるのかを添えます。

合否の推薦はさせません。 「採用に値する」「見送るべき」「懸念がある」といった記述を禁じてください。出すのは観点ごとの要約と引用までです。 推薦者の回答に評価が書かれていても、それは推薦者の意見として引用の形で残すだけで、要約が結論を出す形にはしません。

指示内容を固定する

回答を要約する側の指示です。

あなたは人事本部の採用グループで、リファレンスチェックの記録を整理する担当者です。
推薦者から返ってきた回答を、観点ごとに整理してください。

【厳守事項】
- 候補者の合否を推薦しないでください。
  「採用に値する」「見送るべき」「懸念が大きい」と書かないでください。
  出すのは観点ごとの要約と、その根拠になる原文の引用までです。
- 回答に書かれていないことを推測で補わないでください。
  「この職種であれば一般にこうだろう」と書かないでください。
  記載が見当たらない観点は coverage を not_mentioned としてください。
- not_mentioned を低い評価として扱わないでください。
  触れられていないことは、できていないことではありません。
- 事実として確かめられない事項は「不明」としてください。
  在籍期間や役職が回答から読み取れない場合、推定の年数を書かないでください。
- 次に当たる記述は、要約の本文に含めないでください。
  かわりに flagged へ、原文とどの区分に当たるかを書いてください。
  ・本人に責任のない事項（本籍地、出生地、家族の職業や収入）
  ・本来自由であるべき事項（宗教、支持政党、思想信条、人生観）
  ・健康状態、私生活、労働組合の活動
- flagged に入れた記述を、findings の summary や quote へ重ねて書かないでください。
- 引用は回答の原文をそのまま写してください。言い換えないでください。
- 1つの観点の要約は120字以内にしてください。
- 推薦者や候補者の氏名、連絡先、勤務先を出力に書かないでください。
  入力では識別子で示されています。そのまま使ってください。

【募集要件（職務遂行上の観点）】
{job_requirements}

【今回の質問（観点と質問文）】
{questions}

【推薦者の属性（関係、在籍期間の重なり。氏名と勤務先は含みません）】
{referee_profile}

【推薦者の回答（原文）】
{answer_text}

【聞いてはいけない事項の一覧（区分と、実際に出てきた言い回し）】
{prohibited_items}

「記載が見当たらない観点は不明とする」の指示が、この構成の芯です。 生成AIは、空欄を一般論で埋めようとします。リファレンスチェックでこれをされると、推薦者が言っていないことが言ったように見えます。

「flagged に入れた記述を、要約へ重ねて書かない」も外せません。 分けたつもりが、要約の中に言い換えられて残っていては意味がありません。テストで必ず確かめてください。

質問を組み立てる側の指示にも、同じ禁止を置きます。

募集要件から、推薦者に聞く質問を5〜7問作ってください。
- 職務遂行上必要な適性・能力に関する質問だけにしてください。
- 本籍地、家族の状況、思想信条、宗教、支持政党、健康状態、私生活、
  労働組合の活動に触れる質問を作らないでください。
- 答えを引き出す形で間接的に聞くこともしないでください。
- 募集要件に書かれていない能力について質問しないでください。

出力形式を固定する

{
  "candidate_id": "",
  "job_id": "",
  "referee": {
    "referee_id": "",
    "relation": "former_manager | former_colleague | former_client",
    "overlap_months": 0,
    "overlap_period": ""
  },
  "consent": {
    "recorded": true,
    "date": "",
    "scope": ""
  },
  "findings": [
    {
      "aspect": "",
      "summary": "",
      "quote": "",
      "coverage": "answered | not_mentioned"
    }
  ],
  "flagged": [
    {
      "text": "",
      "category": "responsibility_free | freedom | health | private_life | union",
      "reason": ""
    }
  ],
  "overall_note": "",
  "needs_human": {
    "required": true,
    "reason": ""
  }
}

構造化する理由は、記録の粒度をそろえるためです。 文章のまま記録すると、担当者ごとに長さも順番も変わります。観点を配列の要素にしておけば、候補者が違っても同じ並びで読めます。 最終選考で複数の候補者を並べるとき、これが効きます。

consent を出力に含めているのは、記録そのものに同意の事実を残すためです。 後から「この記録は同意を得て集めたものか」と問われたとき、記録の中に答えがある形にします。

coverage を answered と not_mentioned の2値にした点が重要です。 ここに low を混ぜると、触れられていないことと評価が低いことが同じ列に並びます。触れられていない観点は、評価の材料ではありません。

flagged に入った記述は、選考記録の本体に残さないでください。 別の場所に「そういう記述があったので除いた」という事実だけを残します。理由は単純で、記録に残せば人事の判断材料になってしまうからです。 「使わない」と決めても、目に入れば影響します。目に入らない形にするのが、確実な方法です。

overall_note は、事実の整理だけを書く欄です。 「回答は2つの観点にのみ触れている」「在籍期間の重なりは8か月」といった記述にとどめます。推薦や合否の示唆を書かせないでください。

システムへ連携する

推薦者へ自動で送らないことを、設計の前提にしてください。 依頼状も再依頼も、下書きまでです。推薦者は候補者の現在の勤務先の同僚である可能性があります。 誤送信の影響が候補者に及びます。

採用管理システムへの書き戻しは、記録の確定後に一度だけです。 途中経過を書き戻すと、確定していない要約が最終選考の画面に出ます。flagged の内容は、書き戻しの対象に含めないでください。

フォームは案件ごとに作り直さず、質問文を差し込む形にしてください。 組み立てた質問を設問として流し込みます。回答が設問ごとに分かれるので、質問との対応づけが要らなくなります。

人が確認する

採用担当の確認は、2か所に必ず残します。

1つ目が最重要です。 宛先の誤りは、他の誤りと性質が違います。候補者の転職活動が、本人の意図しない相手に知られます。 取り消せません。下書きを開いて、宛先を目で確かめてから送ってください。

6つ目は、両方向に間違えます。 「家族で登山が趣味だと話していた」が私生活として拾われることもあれば、「お子さんの学校の関係で」が拾われずに残ることもあります。最初の数十件は、flagged に入ったものと入らなかったものの両方を見てください。

確認を速くするための設計が効きます。

• 観点ごとに、要約と引用を左右に並べる
• not_mentioned の観点を、答えのあった観点と分けて下に置く
• flagged は別の画面に置き、選考記録の本体と同じ場所に出さない
• 推薦者が2名いる場合、同じ観点を縦に並べて見比べられるようにする
• 確定のボタンを押すまで、採用管理システムへ何も書かない

3つ目が、この構成の要の部分です。 flagged を選考記録と同じ画面に並べると、「除いた」ことにならなくなります。確認のときにだけ開く場所へ置き、確認が済んだら原文を残さない形にしてください。

例外に対処する

「同意の記録が無い」は、他の例外と扱いを変えてください。 再試行も代替処理もありません。止めるのが正しい動きです。

記録を残す

この記録は、選考の根拠として後から読まれます。

「除いた事実」で原文を残さないことが、この設計の眼目です。 件数と区分だけを残せば、点検が働いたことは確かめられます。原文まで残せば、除いた意味がありません。

「担当者の修正」の記録が、精度を上げる材料になります。 どの観点の要約がよく直されているかが分かれば、プロンプトの指示を足せます。毎回同じ直し方をしている箇所は、指示で吸収できます。

保存期間と閲覧範囲を決めてください。 推薦者の回答は、候補者の選考が終われば役目を終えます。採用グループと最終選考の面接官の外へ出さない設定にしてください。