選考を終えた候補者へのアンケートの回答を、面接官の印象・連絡の速さ・選考の分かりやすさの区分に分類して、毎月の改善点の一覧を採用担当に届ける

処理の起点を決める

回答ごとの分類は、Google Forms の Watch Responses で新しい回答を拾って始めます。 シナリオの実行間隔は15分にします。気になる記述を「その日のうちに」採用責任者へ届けるには、1日1回では遅すぎます。 一方で、1件ずつ即時に動かす必要もありません。

月末の集計は、毎月1日の朝にシナリオBを動かします。 前の月の1日から末日までに書き込まれた行を対象にします。月の途中で区分の定義を変えた場合は、変えた日を区分の定義の表に記録し、集計の注記に出します。

人が手で動かす入口も1つ置きます。 採用会議の前に、月の途中までの件数を見たいときのために、シナリオBを期間を指定して動かせるようにします。

入力データを集める

質を決めるのは、区分の定義の表です。 区分の名前だけを渡すと、「日程調整が何度も変わった」を連絡の速さに入れるか選考の分かりやすさに入れるかが、回答によって揺れます。区分ごとに「入れる話」と「入れない話」の例を2〜3行ずつ書きます。 第3章の（a）の物差しのずれは、ここで止めます。

段階と面接官の対応を個人名にしないのは、意図してのことです。 「二次面接・エンジニア職・今月」のグループ単位で声を返し、個々の面接官の特定は採用責任者が必要なときに行います。

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

回答は Watch Responses で新しいものを拾います。 拾い漏れや二度拾いに備えて、回答IDを分類の一覧の行に必ず入れ、同じ回答を二度分類していないかを書き込み前に Search Rows で確かめます。 月に一度、フォームの回答の数と分類の一覧の回答IDの数を List Responses で突き合わせ、抜けがないかも見ます。

区分の定義は、Google Sheets の Get Range Values で毎回読みます。 シナリオの中に区分を書き込まないのは、区分を直すたびにシナリオを直すことになるからです。 表を直せば、次の回答から新しい定義で分類されます。

月末の集計は、Search Rows で前の月の行を取り、Array aggregator でまとめます。 Source Module を Search Rows にし、Group by に区分のコードを入れると、区分ごとに声の配列が出ます。件数は配列の長さで数え、AIには数えさせません。 職種と段階の内訳は、区分と職種、区分と段階の組み合わせで同じようにまとめます。

AIへ渡す前に整形する

1. 回答の形をそろえる … 3つの自由記述の欄を、設問の名前を付けて1つの入力にまとめます。空の欄は「回答なし」と明記します
2. 氏名・連絡先らしい文字列を伏せる … メールアドレス、電話番号の形の文字列を ［連絡先］ に置き換えます。「〇〇さん」の形は ［人名］ に置き換えます
3. 短すぎる回答を分ける … 「特になし」「ありがとうございました」だけの回答は、AIに渡さず「記述なし」として一覧に書きます
4. 重複を除く … 回答IDが分類の一覧にすでにあれば処理しません
5. 区分の定義を付ける … いまの区分の定義の表を、入力に添えます

2番目は、外へ出す情報を減らすための処理です。 アンケートでは氏名を聞いていませんが、候補者が自由記述に自分の名前や面接官の名前を書くことがあります。 面接官の名前を伏せても分類には困りません。区分は話の中身で決まるからです。

3番目で、AIに渡す件数は1〜2割減ります。 何も書かれていない回答にAIの判断を挟む意味はありません。「記述なし」も件数としては数え、回答率の分母に入れます。

AIに処理させる

させるのは、1件の回答を話ごとに区切り、それぞれに区分・向き・印を付け、根拠の原文を写すことだけです。

右端の列の「迷えば印を付ける」は、区分とは逆の向きの決め方です。 区分は迷えば unclear にして人が付けますが、印は迷えば付けて、人が外します。 印の付け漏れは、問題のある面接がそのまま次の候補者に続くことを意味するからです。

fair_selection の手がかりは、厚生労働省の公正採用選考特設サイトに載っている事項です。 本籍・出生地、家族（職業・続柄・健康・病歴・地位・学歴・収入・資産など）、住宅状況、生活環境・家庭環境、宗教、支持政党、尊敬する人物、愛読書などを面接でたずねることは、就職差別につながるおそれがあるとされています。 同じサイトでは、ハローワークが把握した指摘のうち家族に関することの質問が多くを占め、面接の空気を和らげるために聞いてしまうケースが多いとも書かれています。「雑談で家族のことを聞かれた」という書き方も、印の対象にします。

1行目がいちばん大事です。 月末の改善点の一覧で「連絡の速さの悪い声が先月の2倍」と書くのは、分類の一覧から数えた数字でなければなりません。

指示内容を固定する

あなたは採用グループで、選考を終えた候補者のアンケートの
自由記述を分類する担当です。
書かれていることだけで判断し、推測で補わないでください。

【手順】
1. 回答を「話」ごとに区切ってください。1つの文に良い話と
   悪い話が入っていれば、2つの話に分けてください。
2. それぞれの話に、区分の定義から区分を1つ選んでください。
   どれにも当てはまらないときは other、決められないときは
   unclear にしてください。
3. それぞれの話に、向きを positive / negative / mixed /
   neutral から選んでください。皮肉か本音か分からなければ
   unclear にしてください。
4. 根拠として、その話の部分の原文をそのまま写してください。
   言い換えたり要約したりしないでください。

【印の付け方】
- 面接で、本籍・出生地、家族、住宅、生活環境、宗教、支持政党、
  尊敬する人物、愛読書など、仕事の適性・能力と関係の無いことを
  たずねられたと読める記述には fair_selection を付けてください。
  雑談の中でたずねられたと書かれていても付けてください。
- 威圧的・侮辱的な言動があったと読める記述には harassment を
  付けてください。
- 返事や連絡を求めている記述には contact_request を付けてください。
- 迷ったときは印を付けてください。外すのは人が行います。

【厳守事項】
- 件数や割合を書かないでください。
- 面接官の名前や、面接官を特定できる手がかりを推測しないで
  ください。［人名］は伏せられたまま扱ってください。
- 候補者の年齢・性別・国籍などを推測しないでください。
- 印を付けた記述が違法か、不適切かを判断しないでください。
- 区分の定義に無い区分を作らないでください。

【区分の定義】{categories}
【選考の段階・職種・結果の区分】{meta}
【自由記述】{answers}

「雑談の中でたずねられたと書かれていても付ける」を明記しないと、印が落ちます。 候補者は「雑談で家族の話になりました。和やかでした」と良い声として書くことがあり、向きが positive だと印まで付けなくなります。 向きと印は別の判断であることを、指示の側で分けます。

「外すのは人が行う」と書くのも同じ理由です。 迷ったときの扱いを書かないと、AIは印を付けない側に倒れます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "response_id": "",
  "has_text": true,
  "items": [
    {
      "seq": 1,
      "category": "interviewer | response_speed | process_clarity | scheduling | job_info | other | unclear",
      "polarity": "positive | negative | mixed | neutral | unclear",
      "flags": ["fair_selection | harassment | contact_request"],
      "quote": ""
    }
  ],
  "needs_review": false
}

1つ目の理由は、items で1件の回答を話ごとに持てることです。 分類の一覧には items の要素を1行ずつ書き、回答IDと話の番号で結びます。月末の集計は話の数で数え、回答の数とは分けて示します。

2つ目は、category と polarity を決まった値に絞れることです。 構造化出力のスキーマで enum を使うと、区分の定義に無い区分が返ってきません。 Claude API の構造化出力では、オブジェクトの additionalProperties を false にする必要があり、minimum や maxLength のような数や長さの制約はサポートされないとされています。長さの確認は、受け取った後にワークフローで行います。

3つ目は、quote で確認が速くなることです。 担当者は回答の全文を読まずに、話ごとの抜き書きと区分を並べて見るだけで済みます。 ワークフローの側で、quote が元の記述にそのまま含まれるかを確かめ、含まれなければ needs_review を立てます。

月末の改善点の一覧は、次の形の表で書き出します。 件数の列はワークフローが数えた値をそのまま入れ、AIが書くのは「改善点の案」と「代表的な声」の列だけです。

代表的な声は、件数の多い区分から1〜2件ずつ選ばせ、抜き書きが分類の一覧にある quote と一致するかをワークフローで確かめます。 一致しない声は一覧に載せません。

システムへ連携する

採用管理システムとはつなぎません。 アンケートは氏名を聞かない作りなので、候補者の応募の記録と回答を結ぶ必要がありません。 結ぶ仕組みを足すと、回答した候補者が特定できるようになり、正直な回答が減ります。

チャットへの通知には、印の種類と回答IDだけを載せます。 抜き書きは載せず、採用責任者が分類の一覧を開いて読みます。チャットの履歴に記述が広く残らないようにするためです。

人が確認する

人が見るのは、needs_review が立った回答と、月末の改善点の一覧です。 それ以外の回答は、分類の一覧を区分ごとに流し見ます。

1. 印の付いた回答を、その日のうちに見る … 採用責任者が抜き書きを読み、事実の確認が要るかを決めます。確認するなら、該当する面接のグループの面接官から話を聞きます
2. unclear の回答に区分を付ける … 採用担当が付け、どの区分にしたかを記録します
3. 月末の改善点の一覧を確かめる … 代表的な声が区分の件数の傾向と合っているか、偏った声だけが選ばれていないかを見ます
4. 直したら記録する … AIの区分を人が変えた件数を区分ごとに数えます

1番目の判断を、AIにも採用担当にも任せないでください。 印の付いた記述が本当に問題のある質問だったかは、記述だけでは分かりません。 候補者の受け止め方と面接官の意図が違うこともあります。事実の確認は、採用責任者が面接官と話して行います。

4番目の件数は、区分の定義を直す材料です。 特定の区分で人の付け直しが多ければ、その区分の「入れる話・入れない話」の例が足りていません。

目標は、240件をならして1件1.5分です。 印の付いた回答の確認には1件10分以上かかることもありますが、多くの回答は流し見で終わります。

例外に対処する

6行目は、運用を始める前に決めておくことです。 匿名のアンケートに「連絡がほしい」と書かれても、返す手段がありません。回答画面と送付のメールに、選考についての問い合わせ先を書いておきます。

4行目の構造化出力のエラーは、スキーマを書き換えたときに起きやすいものです。 使えない制約を足すとリクエストが400で返るとされています。エラーになった回答を落とさず、未処理として残すことが大事です。

記録を残す

• 回答IDと、拾った日時、処理した日時
• AIに渡した入力（伏せた後の記述と区分の定義の版）と、受け取ったJSONの全文
• 分類の一覧の行（話ごとの区分・向き・印・抜き書き）
• 人が区分や印を変えた記録 … どの話を、どれからどれに変えたか、誰が変えたか
• 印の付いた回答への対応の記録（確認したか、面接官と話したか、結果）
• 月末の集計の結果と、改善点の一覧の版

2つ目で区分の定義の版を残すのは、比較のためです。 区分を直した月の前後では、同じ記述でも入る区分が変わります。どの版で分類したかが無いと、月ごとの比較が意味を持ちません。

5つ目の対応の記録は、アクセスできる人を絞ります。 面接官の言動に関わる記録なので、採用責任者と人事部長だけが見られる別の表に置きます。