面接の評価コメントを候補者ごとにそろえて、合否会議の比較表にする

処理の起点を決める

合否会議の前日を起点にします。会議が週1回で、かける候補者が決まっているので、時刻で回すのがいちばん簡単です。

面接が終わるたびに1件ずつ処理する形も考えられますが、この業務では向きません。 面接官3名のうち1名しか書いていない段階で処理しても、比較表になりません。「そのポジションの面接が全員分そろったこと」を条件にします。

そろっていない候補者は、処理せずに「未提出の面接官がいる」という一覧に出します。催促は人がします。

入力データを集める

観点の定義が、この構成の質を決めます。 「コミュニケーション能力」とだけ書いてあると、割り付けがぶれます。「社内外の関係者と、前提の違う相手に説明できるか」のように、何を見る観点なのかまで書いてください。

観点は5〜7個に収めます。多すぎると、1つの観点に当たるコメントが1文もない状態が増え、比較表が空欄だらけになります。

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

評価コメント： 採用管理システムの書き出し機能でCSVを取り、スプレッドシートに置きます。APIがある場合は直接取っても構いませんが、週1回・数十件の規模なら、書き出しで足ります。

募集要件の観点： ポジションごとにスプレッドシートの1シートとして持ちます。求人票をそのまま貼るのではなく、観点として整理し直したものを置きます。 ここが準備作業の中心です。

面接の段階： コメントと一緒に取ります。同じ内容でも、一次面接の所見と最終面接の所見では重みが違うため、比較表には段階を出します。重みづけはAIにさせず、人が見るときに分かるようにするだけにします。

AIへ渡す前に整形する

1. 候補者ごとにまとめる … 面接官3名分のコメントを、候補者IDで1つにまとめます。この時点では要約しません。 原文をそのまま持ちます
2. 文に分ける … 割り付けは文の単位で行います。1文に複数の観点が混ざる場合があるため、1文が複数の観点に割り付くことを許します
3. 点数と文章を分ける … 5段階の点数が併記されている場合、点数はそのまま比較表に載せ、AIには文章だけを渡します。 点数は要約する対象ではありません
4. 観点の定義を添える … 観点の名称だけでなく定義文も一緒に渡します。名称だけだと、面接官ごとの語感で割り付けがぶれます
5. 候補者を混ぜない … 1回の処理に渡すのは1名分だけにします。複数名を同時に渡すと、比較や順位付けが出力に混ざります

AIに処理させる

4つ目の「未評価の明示」が、この構成でもっとも重要な処理です。 観点に当たる記述が1文も無い場合、AIは何も書かないのではなく、「触れられていない」と書きます。 表の空欄は「評価が低い」とも「見ていない」とも読めますが、明示されていればどちらか分かります。

6つ目も、この業務では外せません。 評価コメントには、募集要件と関係のない記述が混ざることがあります。要約に混ぜてはいけません。 詳しくは次の項と第13章で書きます。

指示内容を固定する

あなたは中途採用の合否会議に出す候補者比較表の下書きを作る担当者を支援する立場です。
1名の候補者について、面接官が書いた評価コメントを、
募集要件の観点ごとに割り付けて、要約と引用にしてください。

【厳守事項】
- 評価を新しく作らないでください。書かれていないことを補わないでください。
  「おそらくこう考えたのだろう」という推測を書かないでください。
- 観点に対応する記述が1つも無い場合は、coverage を not_mentioned にし、
  finding を空にしてください。
  記載がなければ不明とし、評価が低いという意味に書き換えないでください。
- finding には必ず evidence を添えてください。
  引用は面接官のコメントの原文をそのまま写してください。
  要約した文を引用に入れないでください。
- 面接官によって見立てが分かれている観点は divergence を true にし、
  双方の引用を evidence に並べてください。どちらが正しいかを判断しないでください。
- 次の内容は、コメントに書かれていても finding にも evidence にも入れないでください。
  本籍地・出生地、家族の職業や収入、住宅の状況、生活環境、
  宗教、支持政党、思想信条、尊敬する人物、購読新聞や愛読書、
  容姿や体型の印象、性別や年齢を理由にした記述。
  これらは uncovered_comments に reason を out_of_scope として退避してください。
- 候補者どうしを比べないでください。
  順位付け、推薦、合否の意見、採用すべきかどうかを書かないでください。
- どの観点にも当てはまらないコメントは、捨てずに uncovered_comments に
  reason を criteria_unmatched として残してください。
- 定義していないキーを足さないでください。

【募集要件の観点（名称と定義）】
{criteria}

【候補者の評価コメント（面接官名と面接段階つき）】
{comments}

「記載がなければ不明とする」という指示が、この構成の要です。 これを入れないと、AIは空欄を嫌って「特段の言及はないが、問題はないものと思われる」といった文を書きます。 書かれていないことを書かれたことにする出力は、合否の判断材料として使えません。

観点外の記述を列挙して禁じるのも必要です。厚生労働省は、公正な採用選考の基本として、「応募者が、求人職種の職務遂行上必要な適性・能力をもっているかどうか」という基準で採用選考を行うことが必要だとしています。そのうえで、本人に責任のない事項（本籍地、家族の職業など）と、本来自由であるべき事項（宗教、支持政党といった思想・信条にかかわること）は、職務遂行能力と関係がないものとして挙げられています。要約という作業は、混ざっていたものを短くまとめて目立たせてしまいます。 禁止を明示的に書きます。

出力形式を固定する

{
  "candidate_id": "",
  "position_id": "",
  "criteria": [
    {
      "name": "",
      "coverage": "evaluated | not_mentioned",
      "finding": "",
      "divergence": false,
      "evidence": [
        { "assessor": "", "stage": "", "quote": "" }
      ]
    }
  ],
  "uncovered_comments": [
    { "assessor": "", "quote": "", "reason": "criteria_unmatched | out_of_scope" }
  ],
  "needs_confirmation": []
}

構造化する理由は、表に並べるためです。 候補者ごとに文章で返ってくると、比較表に載せるのは結局人の作業になります。観点の配列として返せば、観点を行・候補者を列にした表は機械的に組めます。 スキーマを固定しておけば、候補者によって観点が増減することもありません。

coverage を finding と別のキーにしていることが、設計の中心です。 要約の文が空かどうかで判断させると、「特に問題なし」のような当たり障りのない文で埋められてしまいます。 評価されたのかどうかを、要約とは独立した値として出させます。比較表では、not_mentioned の欄を空欄ではなく「未評価」と表示します。

evidence に面接官名と面接段階を持たせます。「この要約は誰の、どの段階の発言か」が表の上で分かります。 一次面接の1名だけが触れた観点と、3名全員が触れた観点では、読み方が変わるためです。

uncovered_comments を残すのは、捨てられたコメントを人が見られるようにするためです。観点の定義が足りないと、ここに大量に溜まります。溜まり方そのものが、観点を直す手がかりになります。

システムへ連携する

採用管理システムへの書き戻しはしません。 比較表は会議のための一時的な資料であり、選考記録の正本は採用管理システムに残っている評価コメントのほうです。 要約を正本に混ぜると、あとから原文と要約のどちらが記録なのか分からなくなります。

比較表には原文へのリンクを載せます。 会議で「その引用の前後は」と聞かれたときに、その場で開けます。

人が確認する

全件、人が確認します。合否会議の事務局が、会議の前に必ず1回通します。

理由は、要約が原文を言い換えてしまうためです。「懸念が残る」と「不安が大きい」は、比較表の上では同じくらいの重さに見えますが、面接官が書いたのはどちらかです。 判断の材料である以上、原文との距離は人が見ます。

確認を速くするための設計が重要です。

• 要約の下に evidence の引用を展開して並べる（原文を開かせない）
• divergence が true の観点を上に出す（議論の中心になるため）
• not_mentioned を空欄ではなく「未評価」と文字で表示する
• uncovered_comments の件数を候補者ごとに出す（多いときは観点を疑う）
• 要約に含まれるが引用に無い語に印を付ける（言い過ぎの検出）

確認にかかる時間の目標は、1件10分です。 それ以上かかるなら、観点の定義が曖昧か、面接官のコメントが短すぎて要約する材料がありません。

例外に対処する

記録を残す

• 入力した評価コメントの原文（採用管理システムの記録がそのまま正本）
• AIが作った比較表の案と、evidence の引用
• 人が直した箇所と、直した内容
• uncovered_comments に落ちたコメントと、その理由
• out_of_scope として退避された記述の件数（中身は保存先を分けて限定する）
• 合否会議で使った比較表の版と、日付

3つ目を残すと、この構成の弱点が見えます。同じ観点で毎回要約を直しているなら、その観点の定義が曖昧です。 直した箇所の傾向が、そのまま観点の書き直しにつながります。

out_of_scope の中身の扱いには注意が要ります。 退避したものは、職務と関係がないと判断された記述です。件数は運用改善のために見ますが、中身をそのまま採用担当全員が読める場所に置くと、避けたかったものを別の場所に作ることになります。 アクセス範囲を限定してください。