評価プロセスを生成AIで （半）自動化する！人事評価 x AIの境界実験

AIエージェント 働き方 生成AI 組織

この記事は、Insight Edge Advent Calendar 2025の24日目の記事です！

生成AIを活用した人事評価のモチベーション

今日はクリスマスイブですね！妻へのプレゼントに毎年悩む Insight Edge CTOの猪子です。

マネージャの仕事の中で、 「一番精神的に重い仕事」は何かと聞かれたら、多くの人が「人事評価」と答えるのではないでしょうか。 人事評価の中には以下の悩みが有るかと思います。

  • 日常業務の合間に大量の評価資料を読む
  • 評価の妥当性に悩む
  • フィードバックで相手の人生に影響を与える責任

一方で、生成AI・AIエージェントを活用して、「人事評価」を効率化・活用していきたいという思いを持っているマネージャは多いかと思います。

では、評価という重要な責務を持つ仕事を、どこまでAIに任せてよいのか？
本記事では、その問いに対して行った 人事評価 × AI の境界実験を、マネージャ視点で考察します。

尚、本記事はあくまで思考実験であり、Insight Edgeでは現段階（2025/12現在）で人事評価のための情報収集・判断に生成AIは導入しておりません

人事評価でマネージャが本当にやるべきこと

まず整理したいのは、評価業務の中で、マネージャにしかできないことは何かです。

評価プロセスを分解すると、次の3つに分かれます。

  1. 情報を集め、整理する
  2. 評価軸に照らして考える
  3. 最終判断し、対話する

このうち、3. 最終判断と対話する はマネージャの仕事であり、AIに任せてはいけません。 そもそも、AIに代替される・代替すべき業務は社会的な利害が小さいもの(社会的な抵抗が小さいもの）が良いという調査結果*1もあります。　 評価される方も生成AI・AIエージェントに評価されるということで納得感も低くなるかと思います。

1,2に相当する下記の業務は「判断」ではなく「作業」に近い側面もあるので、ここを効率化・最適化することで、マネージャの判断を代替するのではなく、判断するための情報を収集・整理し、判断に集中させる 事を目的としています。

  • 膨大な記録を読む
  • 評価基準に沿って整理する
  • フィードバック文を下書きする

whole_process

では、具体的にどの様に生成AIを活用していくのかを説明していきます。

1. 情報を集め、整理する

ここは、評価に必要な材料を漏れなく集め、評価者が読みやすい形に整える工程です。
Insight Edgeの前提となる環境（Slack / Google Drive / Google Meet / GitHub）に沿って、評価実務に必要な情報に落としこんでいきます。

1-1. 集める情報の“型”を先に決める

評価に必要な情報を集めるため、まず 評価のエビデンスの型を定義します。

エビデンスの型の定義例

  • 成果：何が達成されたか（QCD改善・リリース・契約・感謝）
  • 行動：どう進めたか（巻き込み、意思決定、課題解決）
  • 影響：誰にどう効いたか（顧客、チーム、プロダクト）
  • リスク/失敗：何がうまくいかなかったか、どうリカバリしたか

おそらくどの企業でも目標管理/MBO（Management By Objectives）に近しい物を運用していると思います。これらの情報はその中で設定している達成指標、達成基準、達成計画等と同等の位置づけになるので、そちらと照らし合わせながら定義するとよいでしょう。

この「型」に沿って、Slack/Google Drive/GitHub/Google Meetの情報を拾いに行きます。

1-2. データソース別に“拾い方”を固定する

1-2-1. Slack（進捗、意思決定、巻き込みの証拠）

狙い：日常の行動・推進力・コミュニケーションの根拠を拾う。

取得単位 - 評価期間全量だとノイズが多いので以下でフィルターする

  • 月次スライス
  • プロジェクトチャンネル単位
  • キーワード抽出（例：決定, リリース, インシデント等）

具体的な集め方 - 対象者ごとに「評価対象チャンネル一覧」を作る（1.1で定義した型の行動=達成計画に紐づく - 収集したSlackログをタグ付けする - 1.1の達成指標や達成基準に関連付ける - “引用可能な根拠”として残すため、要約だけでなく原文リンク/スレッドIDを保持する

※検索に当たっては、UbieさんがOSSとして公開しているSlack MCPサーバを利用するのが便利です。

出力フォーマット（例）

  • 重要スレッド一覧（リンク付き）
  • 週/月ごとの「意思決定ログ」
  • “本人の寄与”が見える発言抜粋（短くまとめる）

1-2-2. Google Drive（各種成果物：提案資料、プロジェクト計画書、会議資料、開発ドキュメント等）

狙い：成果物の質、構造化力、論理性、アウトプット量の根拠を拾う。

取得単位

  • 評価対象プロジェクトのフォルダを起点に、評価対象者が作成・更新している期間内更新ファイルを抽出
  • “最終成果”だけでなく、成果に至るプロセスが見える資料も拾う

具体的な集め方

  • プロジェクトの「成果物ディレクトリ」を固定化（命名規則があると取得しやすい）
    • 01_企画・計画/, 02_設計/, 03_開発/, 04_運用保守/, 99_その他/
  • ファイル本文だけでなく、メタ情報も収集し解析する
    • 作成者、最終更新日、コメント数、閲覧者（取れる範囲で）
  • 議事録は“要点”だけでなく 決定事項（Decision）/TODO/担当 を抽出しておく

※弊社ではGemini Enterpriseを採用しており、Google Drive内のドキュメント抽出に活用しています。

出力フォーマット（例）

  • 成果物カタログ（リンク、1行要約、本人の役割）
  • 主要な意思決定（どのドキュメントで決まったか追える様に）
  • レビュー/コメントの反映履歴（改善の証拠）

1-2-3. Google Meet（合意形成・調整の証拠）

狙い：対話・ファシリテーション・合意形成の根拠を拾う（各種会議体/1on1等）。

注意：録音/文字起こしはプライバシー・規程・同意が絡むので慎重に。 実務では「議事録（Google MeetだとGeminiの文字起こし等）」として扱うのが安全です。

具体的な集め方

  • Meet → 議事録（Drive）へのリンクを必ず残す運用に寄せる
  • 議事録から以下を抽出
    • 決定事項
    • 合意までの争点
    • その場での宿題と回収状況

出力フォーマット

  • 争点→意思決定→結果の流れ（短いタイムライン）
  • 本人がファシリした会議の一覧（回数・成果）

1-2-4. GitHub（コード、レビュー、品質、運用貢献の証拠）

狙い：実装力・品質・チーム貢献（レビュー）・改善の根拠を拾う。

取得単位

  • PR（作成、レビュー、マージ）
  • Issue（起票、クローズ、ディスカッション）
  • リリース、hotfix、incident対応（タグや関連Issue）

具体的な集め方

  • 対象者の期間内アクティビティを収集し、意味のある単位に圧縮
    • PRは「件数」より「代表PR 3〜5本」を選ぶ（影響が大きいもの）
    • レビューは「指摘の質」「他者の成長支援」が見えるコメントを抽出
  • 重要なのは「何をやったか」だけでなく
    • なぜそうしたか（設計意図）
    • どんなトレードオフだったか
    • どういう効果（実装効率・負債の改善等）を産み出したか を紐づけること

※GithubのIssue / コメントの収集にはGithub APIを利用し、そこからRAGを構築します

出力フォーマット（例）

  • 代表PRリスト（リンク、目的、影響、難易度、本人の役割）
  • 効果（ブロッカー解消、品質向上、ナレッジ共有）

2. 評価軸に照らして考える

ここは「評価する」工程に近いので、生成AIにやらせる範囲を明確にします。
生成AIは 仮評価（案）と根拠の整理・提示まで。最終判断は人間です。

2-1. 評価軸を整理する

1で設定した成果や達成基準、そのプロセス・過程と評価基準を紐づけます。

達成基準例

  • 推進（オーナーシップ）
  • チャレンジ（挑戦）
  • 協働（巻き込み、合意形成）
  • 品質（再現性、運用品質）
  • 成長（学びと改善）等

各企業に置いてはそれぞれの項目にはレベル要件が規定されていると思うので、それと1で設定した型を結びつけます。

※Insight EdgeのValue（やりぬく・やってみる・みんなでやる）を評価基準の観点として置いています。

2-2. エビデンス → 評価基準 へのマッピング

生成AIにやらせるのは「点数付け」ではなく、 エビデンスの対応付けです。

エビデンス1件ずつ以下を処理していきます。 - どの評価観点に効くかを分類（複数可） - 効き方を短く説明（なぜその観点か？）

これら整理された情報を元に、評価点を「人間」が設定していきます。

2-3. バイアス検知

評価はバイアスが入りやすい領域です。
決定は人間が行いますが、決定のバイアスを見える化する点に生成AIを活用するのは良いでしょう。

  • 直近の出来事に引っ張られていないか
  • 目立つ成果だけに寄っていないか
  • Slack発言量で過大評価していないか
  • 期待役割の差を織り込んでいるか

生成AIに「この評価案に潜むバイアス可能性」を列挙させ、 最後に評価者が確認するフローを入れるのがおすすめです。

それでもAIに任せてはいけないこと

この机上実験で、「ここは絶対に人間がやるべきだ」と再確認した点もあります。

1. 最終評価の決定

評価は「点数」ではなく「意思決定」です。

  • 昇給/昇格/役割変更

これらは人の人生に直結します。AIが決めてはいけません。

2. 感情を伴う対話

評価面談は一方通行の情報伝達では無く、評価対象者へのフィードバックや、相手のWillを確認し、個人の成長を促す場です。

  • 評価者のWillやモチベーション
  • フィードバックの受け取り方

これを感じ取れるのは人間だけです。

3. 文脈・空気感の判断

  • プロジェクトの難易度
  • チーム内の役割
  • 見えない貢献 等

もちろんデータ化しきれない情報もあります。それらを考慮し、判断出来るのは人間だけです。

導入時にマネージャが気をつけるべきこと

透明性を確保する

  • どの情報を使っているか
  • どこまでAIが関与しているか

これを説明できない状態で使うべきではありません。

小さく試す

いきなり全社導入は危険です。

  • 一部チーム
  • 一部プロセス
  • PoCとして

マネージャ自身が納得し、制御できる形で進めることが重要です。

生成AIはマネージャを楽にするのか？

結論として、生成AIはマネージャを「楽に」しますが、「軽く」はしません。

  • 判断の責任
  • 人に向き合う覚悟

これは変わりません。ただし、

  • 評価に必要な情報を収集・整理する

この負荷を生成AIに任せることで、マネージャの業務を軽減し 本来やるべき仕事に集中できる ようになります。

おわりに：評価の主役は誰か

評価の主役は、常に「人」です。

あなたの評価業務では、どの部分が一番つらいでしょうか？

そこから生成AI導入を考えてみるのが、最も安全で、現実的な第一歩だと思います。

*1:内閣府 第1章　AIで変わる労働市場 https://www5.cao.go.jp/j-j/sekai_chouryuu/sh24-01/s1_24_1_0.html