面接の評価シートの点数とコメントを毎月集計し、面接官ごとの甘辛と評価のぶれ、根拠の薄いコメントを拾って評価会議と面接官研修の資料にする

処理の起点を決める

時間主導型のトリガーを、毎月1日の朝6時台に1つ置きます。 前月末の面接の評価シートは、翌日に出されることもあります。1日の朝ではまだ出ていないシートがあるため、月末の最終日の面接は翌月の集計に回します。 「面接日が前月の25日まで」を前月分とし、26日以降は翌月分に入れます。

処理は3つの段に分けます。 1段目で取り出し・選考結果とのつなぎ・伏せ字、2段目でコメントの判定、3段目で甘辛とぶれの計算と一覧への書き出しです。2段目の途中で6分に近づいたら、どのシートまで送ったかをスクリプト プロパティに残して止まり、 同じ朝の15分後から15分おきに置いた続きのトリガーで再開します。

会議の日程に合わせて、手で動かすこともできるようにします。 会議が月の半ばにある場合は、前月分を早めに出したいことがあります。手で動かすときは、対象の期間を設定のシートに書いてから実行します。

判定は同じシートについて二度行いません。 判定の結果を書いたシートには judged の印を付け、期間を変えて手で動かしても、判定済みのシートは送らずに結果を読むだけにします。

入力データを集める

AIに渡すのは、評価シート1枚の点とコメントと、その職種の評価の基準だけです。 面接官の名前も、候補者の合否の結果も渡しません。面接官の名前を渡すと、前月までの判定に引っ張られます。 合否を渡すと、見送った候補者のコメントを厳しく判定するようになります。

評価の基準のシートが、判定の質を決めます。 「主体性が4」とは、どういう行動を話した人か。基準が点ごとの行動で書かれていれば、AIはコメントが基準のどの行動に当たるかを見て、点との食い違いを判定できます。 基準が「主体性がある」だけなら、食い違いは判定できません。

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

評価シートの回答は、スプレッドシートの範囲をまとめて読み、面接日で前月分を絞り込みます。甘辛の計算には直近3か月分も読みます。 件数の少ない面接官の計算に使うためです。

選考結果の CSV は、採用管理の仕組みから月末に採用担当が出して共有ドライブに置きます。 採用管理の仕組みの API が使えれば自動で取れますが、使えるかは仕組みによります。CSV の置き忘れに備え、ファイルの更新日が前月末より前なら処理を止めて知らせます。

Claude API は UrlFetchApp で呼び、鍵はスクリプト プロパティに置きます。 プロパティはキーと値の文字列で保存されます。muteHttpExceptions を true にして、失敗の状態コードでも応答を受け取り、送り直すかを決めます。

AIへ渡す前に整形する

1. 期間の絞り込み … 面接日で前月分（26日〜25日）を取り出します
2. 選考結果とのつなぎ … 候補者IDで選考結果をつなぎます。つながらないシートは「ID不一致」として数え、判定はしますが甘辛の計算には入れません
3. 伏せ字 … コメントの中の候補者の氏名、前職・現職の会社名、学校名を ［伏せ字］ に置き換えます。氏名は採用管理の仕組みの CSV の氏名と照らし、会社名と学校名は応募書類の項目と照らします
4. 点数の確認 … 5項目と総合の点が1〜5の整数かを確かめ、外れていれば「点数不正」としてそのシートを外します
5. 同席の組の作成 … 同じ候補者・同じ段階を2名で見たシートを組にします
6. 空欄のコメントの扱い … コメントが空欄の項目は、AIに送らず empty として数えます

3番目を省かないでください。 評価のコメントには「△△社でのプロジェクトで」と前職が書かれることがよくあります。判定に会社名は要らず、研修の事例に使うときには必ず消す必要があります。 AIに渡す前に消しておけば、事例の候補にも残りません。

6番目で空欄をAIに送らないのは、空欄に何かを判定させないためです。 空欄を送ると、AIは「記述がないため根拠なし」と書くだけでなく、点から推して「おそらく〜と評価した」と補うことがあります。 空欄は空欄として数えます。

AIに処理させる

させるのは、評価シート1枚について、項目ごとのコメントの根拠の種類と、点との食い違いを判定し、研修の事例に向くかの印を付けることです。

根拠の種類で迷ったときに impression にしないのは、面接官に対して公平にするためです。 印象と判定されたコメントの率は、評価会議で面接官ごとに示されます。迷ったものを印象に寄せると、短く書く癖のある面接官の率が実際より高く出ます。 迷ったものは unclear にして、率の計算から外します。

いちばん起きやすい失敗は、4行目です。 「主体性が高い」とだけ書かれた欄に、AIは「プロジェクトを自ら推進した経験から」と補って behavior と判定することがあります。補った根拠で判定すると、印象だけのコメントが行動の記述として数えられ、その面接官の率が下がります。 根拠にした語句をコメントからそのまま写させ、写した語句がコメントの中に本当にあるかをスクリプトで確かめます。

指示内容を固定する

あなたは人事部の採用担当で、面接官が書いた評価シートのコメントを点検する立場です。
面接官の良し悪しや、候補者の合否を判断する立場ではありません。

【この職種の評価の基準】{criteria}
（5項目それぞれについて、1〜5の点ごとに、どういう行動を話した人がその点かの目安）

【根拠の種類（項目ごとに1つ）】
- behavior .. 候補者が面接で話した行動・事実・数字の記述がある
              例：「前のチームで障害が続いた月に、自分から週次の振り返りを始めた」
- impression  印象や形容だけで、行動の記述がない
              例：「主体性を感じた」「論理的」「感じが良い」
- hearsay ... 応募書類の内容を写しただけで、面接で確かめた記述がない
- unclear ... 上のどれと決めきれない

【点との食い違い（項目ごとに1つ）】
- consistent ... コメントの行動が、付けた点の基準とおおむね合う
- inconsistent . コメントの行動が、基準で2点以上離れた点に当たる
- unclear ...... コメントだけでは基準と照らせない

【厳守事項】
- コメントに書かれていない行動や事実を補わないでください。
- evidence には、判定に使った語句をコメントからそのまま写してください。
  コメントに無い言葉を evidence に書かないでください。
- 迷ったときは impression ではなく unclear を選んでください。
- 点数を付け直したり、候補者の合否を判断したりしないでください。
- 面接官の評価の癖や良し悪しを書かないでください。
- ［伏せ字］の中身を推測しないでください。
- 項目の id をそのまま返し、項目を増やしたり減らしたりしないでください。

【評価シート（項目の id、項目名、点、コメント）】{sheet}

「迷ったら unclear」と「evidence はコメントからそのまま」が、この指示の2本の柱です。 前者は面接官ごとの率を公平にするため、後者は書かれていない根拠を補わせないためです。どちらも、面接官本人に数字を見せたときに「それは自分のコメントのどこから言っているのか」と聞かれて答えられるようにする仕掛けです。

評価の基準を毎回のプロンプトに入れるのは、職種ごとに基準が違うからです。 エンジニアの「専門性4」と営業の「専門性4」は別の行動です。基準を渡さずに食い違いを判定させると、AIは一般的な感覚で点を当てます。

出力形式を固定する

次の形のJSONで受け取ります。 output_config.format の type を json_schema にし、evidence_type と consistency と example_tag を enum で列挙します。

{
  "sheet_id": "EV-2026-09-0217",
  "items": [
    {
      "item_id": "initiative",
      "evidence_type": "behavior",
      "consistency": "consistent",
      "evidence": "障害が続いた月に自分から週次の振り返りを始めた",
      "example_tag": "good_example"
    }
  ]
}

1つ目の理由は、evidence をスクリプトで照合できることです。 evidence の文字列が、伏せ字済みのコメントの中にそのまま含まれるかを確かめます。含まれなければ、AIが補った根拠です。 その項目の判定を unclear に置き換え、「根拠不一致」として記録します。

2つ目は、項目ごとの判定を面接官ごとに数えられることです。 evidence_type が impression の率、consistency が inconsistent の率を、面接官ごとにスクリプトが数えます。AIは1枚ずつしか見ていないので、面接官の癖を言うことはできません。 癖は数えた結果から人が読みます。

3つ目は、出力を確かめる手順がはっきりすることです。 公式の説明では、stop_reason が refusal のときは出力がスキーマに合わないことがあり、max_tokens のときはJSONが途中で切れるとされています。end_turn 以外の応答は使わず、そのシートを送り直しの待ちに入れます。

一覧のシートには、面接官ごとに次の列を並べます。 甘辛とぶれはスクリプトの計算です。

システムへ連携する

評価シートの回答には書き込みません。 判定済みの印は、結果の一覧のシートの側に sheet_id と並べて持ちます。面接官が出した評価そのものに手を入れる経路を作らないためです。

結果の一覧のシートは、採用担当だけが開けるようにします。 面接官ごとの数字が入ったシートを面接官全員に共有すると、会議での伝え方を決める前に数字だけが広まります。 会議では、採用担当が選んだ数字と事例だけを資料に写します。

人が確認する

1. 件数不足と ID 不一致を先に見る … 数字が出ていない面接官と、選考結果とつながらないシートを確かめます
2. 甘辛の大きい面接官の組を見る … 差が大きい面接官について、どの組で差が出ているかを1組ずつ見ます。 相手の面接官が極端なだけ、ということがあります
3. 根拠不一致の項目を見る … AIが補った根拠を出した項目です。判定を直すかを決めます
4. 事例の候補から選ぶ … 研修や会議で見せる事例を選び、伏せ字が十分か、候補者が特定されないかを読みます
5. 伝え方を決める … 面接官ごとの数字を、会議で全員に見せるか、本人に個別に伝えるかを決めます

2番目を省かないでください。 甘辛は相手との差なので、相手の面接官が辛ければ、こちらが甘く見えます。 組の相手が偏っていないかを見てから、本人に伝えます。

目標は、360枚をならして1枚1分です。 人が見るのは甘辛の大きい面接官の組と、根拠不一致の項目と、事例の候補で、残りは一覧を流し見る、という想定です。

例外に対処する

いちばん多いのは、1行目と4行目です。 候補者IDの書き間違いと、二次面接の件数の少ない面接官です。どちらもAIの問題ではなく、フォームの作りと面接の組み方の問題です。 候補者IDを選択式にし、同じ面接官どうしが固定で組まないように面接を割り振るほうが、甘辛の数字が早く安定します。

記録を残す

• 処理した期間、評価シートの枚数、判定したシートの数、外したシートの数と理由
• 項目ごとの判定（evidence_type、consistency、evidence、example_tag）と、根拠不一致の記録
• 面接官ごとの甘辛・ぶれ・率と、計算に使った組の候補者IDの一覧
• そのとき使った評価の基準の版と、プロンプトの版
• 会議で示した数字と事例、伝え方（全体か個別か）
• 研修を受けた面接官の、受講の前後の数字

3つ目で組の候補者IDを残すのは、面接官から「どの候補者のことか」と聞かれたときに答えるためです。 数字だけを示して根拠をたどれないと、すり合わせの会議が数字の信頼の話で終わります。

最後の行は、研修の効果を見る材料です。 研修の後に印象だけのコメントの率が下がったか、同席の相手との差が縮んだか。ただし件数が少ないうちは、上下は偶然の範囲に収まります。 3か月以上並べてから読みます。