人事評価の上司のコメントを、評価基準との整合と偏った表現で点検し、書き直しの案を返す

処理の起点を決める

一次評価の締め切りの翌朝の定時に、その月の対象者をまとめて処理します。 上司が書いている途中のコメントを点検しないために、締め切りを合図にします。締め切りは会社ごとに違うので、会社ごとの締め切りの日を設定の一覧に持ち、その翌朝に動かします。

締め切り後に提出された遅れの評価シートは、毎朝の差分として拾います。 前日までに点検した社員番号を記録しておき、まだ点検していない評価シートだけを処理します。 遅れて出てきたものほど急いで書かれていることが多いので、取りこぼさないようにします。

上司が差し戻しを受けて直したコメントも、もう一度点検します。 直したコメントが再提出されたら、直した箇所だけでなく全体を点検し直し、前回の指摘が解消されたかを確かめます。 直した結果、別の偏った表現が入ることがあるからです。

入力データを集める

質を決めるのは、評価基準の評点の定義です。 「A：期待を上回る成果を上げた」だけでは、コメントと照らす手がかりになりません。「A：担当店舗の課題を自ら見つけ、改善の取り組みを提案し、実行した」のように行動の例が書かれていれば、コメントにその種の事実があるかを見られます。

表現の点検の一覧は、区分ごとに「指摘する書き方」と「指摘しない書き方」を対にして書きます。

右の列の書き方を、そのまま書き直しの手本にもします。 指摘しない書き方の例が無いと、AIは属性や休業に触れた文をすべて消す案を作り、評価の対象期間のような必要な事実まで消えます。

勤務の状況は、区分だけを渡します。 休業の理由（育児か介護か病気か）は渡しません。AIに理由を渡さなくても、コメントの中で休業が評点の理由として書かれているかは読めます。 渡す情報を絞るほど、扱いの重さが下がります。

本人の自己評価は、食い違いの手がかりとして渡します。 自己評価で書かれた成果に上司のコメントが一言も触れていない場合、本人が評価のフィードバックで納得しにくくなります。ただし、自己評価が正しいとは扱いません。

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

書き出しの方式は、人事評価のシステムによって違います。 API を持つ製品もあれば、管理画面からの CSV の書き出ししかない製品もあります。この部分は利用している評価のシステムに応じた個別の実装になります。 管理画面の書き出ししか無ければ、人事が毎朝書き出して決まったフォルダに置き、それを起点にします。

氏名は書き出しの段階で外せるなら外します。 外せない場合は、Azure Functions が受け取った直後に社員番号に置き換え、氏名を Azure OpenAI に渡しません。

AIへ渡す前に整形する

1. 氏名の置き換え … 評価対象者の氏名を社員番号に置き換えます
2. コメントの中の氏名の置き換え … コメントの本文に書かれた本人や同僚の氏名を、「本人」「同僚A」に置き換えます。社員名簿の氏名と照合して置き換えます
3. 評価基準の選択 … 等級と職種から、合う評価基準を選びます
4. 空欄の確認 … コメントが空、または数文字しかない評価シートは、AIに渡さず「記入不足」とします
5. 再提出の判定 … 前回点検したものと同じ社員番号なら、前回の指摘を添えます
6. 版の記録 … 使った評価基準と表現の点検の一覧の版を記録します

2番目を忘れないでください。 「〇〇さんと比べて」のように、コメントの本文には同僚の氏名が出てきます。評価対象者の氏名だけを置き換えても、同僚の氏名がそのまま渡ります。

AIに処理させる

させるのは、コメントを3つの観点で点検し、引用を示し、書き直しの案を作ることです。

一番下の行が、この構成でいちばん大事な区別です。 mention_only は属性や休業に触れているだけ、linked_to_rating は評点の理由として書かれているということです。前者は表現の見直しで済むことが多く、後者は評点の付け方の問題です。 法律は、育児休業をしたことや、妊娠・出産に関する事由を理由とする不利益な取扱いを禁じています。

2行目がいちばん起きやすい失敗です。 「お客様対応を頑張った」を書き直させると、AIは「クレームの対応で、お客様の話を最後まで聞き、代替の提案をして納得を得た」のような具体例を書きます。読みやすいので、上司はそのまま採用します。 本人がフィードバックで読み、「そんなことはしていない」となれば、評価そのものが信用を失います。

指示内容を固定する

あなたは人事部で、一次評価で上司が書いた評価コメントを校正する担当です。
評価対象者を評価するのではありません。書かれた文章だけを点検してください。

【点検の観点】
1. rating_mismatch …… 評点の定義とコメントの内容が合っていない
2. no_evidence ……… 行動・成果・場面の記述がなく、抽象的な言葉だけになっている
3. biased ………… 表現の点検の一覧の区分に当たる表現がある
4. personality ……… 人格や性格を否定する表現、断定的な決めつけがある

【属性に触れる表現の扱い】
- 属性や休業・時短勤務への言及が、評点の理由として書かれていれば link を linked_to_rating に、
  触れているだけなら mention_only にしてください。
- 休業・時短勤務の区分は {leave_flag} です。理由は渡していません。推測しないでください。

【書き直しの案の厳守事項】
- コメントに書かれていない事実、行動、成果、数字を足さないでください。
- 具体的な事実が足りない箇所は「【具体的な行動を記入】」「【成果の数字を記入】」のように空けてください。
- 属性への言及は、評価に必要なければ削る案にしてください。
- linked_to_rating の指摘があるコメントは、書き直しの案を作らず rewrite を空にしてください。
- 評点を変える提案をしないでください。

【その他の厳守事項】
- quote には、指摘の根拠にしたコメントの部分を、一字一句そのまま写してください。
- 評価対象者や上司の人物像を書かないでください。
- 違法かどうかの結論を書かないでください。
- 迷ったときに「問題なし」にしないでください。unclear にしてください。

【等級・職種】{grade} {job}
【評価基準（版：{criteria_version}）】{criteria}
【表現の点検の一覧（版：{list_version}）】{expression_list}
【評価項目ごとの評点とコメント】{ratings_and_comments}
【本人の自己評価】{self_review}
【前回の指摘（再提出の場合）】{previous_findings}

「書かれていない事実を足さない」と「空けて返す」を両方書いているのは、禁止だけでは埋めてくるからです。 足すなと言うだけでは、事実のない書き直しの案を作れず、言い回しだけを飾った案になります。空ける場所を指定すると、上司が何を書き足せばよいかが分かる案になります。

linked_to_rating のときに書き直しの案を作らせないのも、同じ理由です。 文章だけを整えた案があると、上司はそれを貼って再提出し、評点の理由に属性が使われていたという事実が文章から消えます。

出力形式を固定する

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

{
  "employee_no": "",
  "criteria_version": "",
  "items": [
    {
      "item_name": "",
      "rating": "",
      "findings": [
        { "type": "rating_mismatch | no_evidence | biased | personality | unclear",
          "quote": "", "category": "", "link": "linked_to_rating | mention_only | none",
          "reason": "" }
      ],
      "rewrite": ""
    }
  ],
  "self_review_gaps": [""]
}

公式の説明では、構造化出力ではすべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する必要があり、スキーマには最大5段の入れ子が持てるとされています。上の形はこの範囲に収めています。

1つ目の理由は、引用をプログラムで照合できることです。 Azure Functions が quote を元のコメントと突き合わせ、見つからない指摘は採用しません。 書き直しの案の中の「【】」の数も数え、空けた箇所が上司に分かるようにします。

2つ目は、AIの指摘と点検の結果を別の層に置けることです。 AIは findings を埋め、評価シートの結果は規則で決めます。

3つ目は、項目ごとに書き直しの案を持てることです。 評価項目が5つあっても、直すのは1項目だけということが多くあります。差し戻しのコメントに、直す項目と案だけを貼れます。

システムへ連携する

評価のシステムへの書き戻しは作りません。 差し戻しの操作を自動にすると、人事が確かめる前の指摘が上司に届きます。 特に escalate のものは、文章で戻すより先に人事の責任者が話すべきものです。

点検の一覧のリストは、人事の運用チームだけが見られるようにします。 評点とコメントと指摘が並んだ一覧は、社員の処遇に直結する情報です。

人が確認する

1. escalate を最初に見る … 元のコメントを読み、属性や休業が評点の理由として書かれているかを確かめます。確かなら、人事の責任者が上司と話します
2. return の指摘を確かめる … 引用と理由を読み、指摘が妥当かを見ます。書き直しの案に事実が足されていないかを必ず見ます
3. review を読む … AIが決められなかった箇所を、人が決めます
4. ok は一覧で流し見る … 評点とコメントの冒頭を読み、違和感のあるものだけ開きます
5. 指摘を覆したら記録する … どの指摘を、なぜ外したかを残します

2番目の後半を省かないでください。 書き直しの案に「【】」が1つも無いのに、元のコメントより具体的になっていたら、事実が足されています。 その案は使わず、空ける形で作り直させます。

目標は、300件をならして1件3分です。 ok は1分足らず、return は指摘と案を確かめて差し戻しを送るまで数分かかります。

例外に対処する

最後の行を軽く見ないでください。 評点の列とコメントの列がずれると、別の人の評点とコメントを照らすことになり、すべての指摘が誤りになります。 書き出しの列の数と見出しを毎回確かめます。

記録を残す

• 書き出したデータのファイル名と日時、社員番号の一覧
• 使った評価基準と表現の点検の一覧の版
• Azure OpenAI に渡した入力（氏名を置き換えた後のもの）と、返ってきたJSONの全文
• 人事が指摘を覆した記録 … どの指摘を、なぜ外したか
• 差し戻した日時と、再提出のコメント
• escalate の対応の記録 … 誰が上司と話し、評点がどうなったか

4つ目は、表現の点検の一覧を直す材料になります。 特定の区分で外す指摘が多ければ、その区分の例が広すぎます。 一覧を直すと、上司に届く的外れな指摘が減ります。

記録の保存期間は、評価の記録と同じにします。 点検の記録だけが評価の記録より長く残ると、処遇の議論で、点検の記録が評価の記録の代わりに読まれることが起きます。