概要
採用応募のエントリーシート（ES）や履歴書を AI エージェントで事前評価する仕組み。実装で大事なのは単なるキーワード検索を超える設計を持つこと——応募者の経験や能力が自社の求める人物像にどれだけ適合するかを多角的に評価できるかが鍵になる。
最終的な合否判定を丸ごと AI に委ねてはいけない。 AI には「人間が面接や最終判断を下すための素材」を整えさせる、というのが基本の位置づけである。
全体の流れ
- 構造化・抽出 — 職歴・スキル・アピールポイントなどを整理する
- 評価基準との照合 — AI エージェントがスコアリングと理由付けを行う
- 結果の出力 — 要約・推奨度・面接での深掘り質問を提案する
導入ステップ
1. 評価基準（ルーブリック）の言語化
AI は「あいまいな良し悪し」を判断できない。人間が暗黙に判断してきた基準を明文化する。
- 必須条件（Must） — 業務経験年数、特定の資格、語学力など
- 歓迎条件（Want） — プロジェクトマネジメント経験、特定ツールの使用経験など
- コンピテンシー（行動特性） — 主体性、論理的思考力、問題解決能力など
この 3 層に整理すると、後段で「必須条件を満たしているか」と「加点要素をどれだけ持っているか」を分けて評価できる。
2. 評価プロンプトの設計
役割（ペルソナ）と評価軸、出力フォーマットを明示する。
「あなたは採用担当のベテラン面接官です。提供された応募者の ES を読み、以下のルーブリックに基づいて 1〜5 段階で評価し、その根拠を記述してください。また、面接で確認すべき疑問点を 3 つ挙げてください。」
実運用では、評価根拠を**「ES のどの記述に基づくか」まで含めて出力させる**とハルシネーション対策になる。
3. 技術構成の選定
- 既存ツール・SaaS — AI スクリーニング機能を備えた ATS（採用管理システム）や採用特化型サービス。導入が最速だがカスタマイズ性は制限される
- 自社開発（API 連携） — LLM API を社内の管理システムに組み込む。柔軟だが実装コストがかかる。PDF からのテキスト抽出（OCR）や長文を JSON へ構造化する処理をあわせて実装する
評価軸設計の落とし穴
- 転職回数（ジョブホッピング）の扱い — 回数そのものを減点要素にすると、業界慣行や事情を無視した機械的な選別になる。何を評価したいのか（定着性か、経験の幅か）を分けて基準化する必要がある
- 希望年収と職能レベルのギャップ — ギャップの存在自体を落とす理由にせず、オファーレンジ設計の材料として扱う。職種別の年収ベンチマークと突き合わせる
運用上の注意点
- Human-in-the-Loop を必須にする — AI の出力は判断材料であって判断ではない。最終決定は人間が下す
- 根拠の出典を強制する — スコアだけでなく「ES のどの記述に基づくか」を出させる
- 公平性への配慮 — 評価軸が特定属性に不利に働かないか、定期的に出力を監査する
- 記録を残す — 評価根拠を保存し、後から説明できる状態にしておく
AI 評価ならではのメリット
- 大量の応募書類に対して評価軸を揃えた一次評価ができる
- 人間のレビュー前に面接での深掘り質問案が用意される
- ルーブリックが明文化されることで、暗黙知だった採用基準そのものが可視化・議論可能になる
関連ページ
- AI エージェント — エージェント設計の基礎
- スケーラブル・オーバーサイト — 人間が AI の出力を監督する枠組み
- RAG — 根拠付き出力によるハルシネーション対策
ソース記事
- AIエージェントで採用ES・履歴書を事前スクリーニングする仕組みの作り方 — 2026-07-23