Difyで書類選考を自動化する｜AIが「一般的な優秀さ」で判定してしまう問題への対処【AI活用検証vol.38】

書類選考は、担当者によって基準がぶれやすい作業です。同じ職務経歴書でも、見る人が変われば評価が変わる。そして応募が増えるほど、スクリーニングに時間を取られます。

Difyで選考ワークフローを構築し、履歴書・職務経歴書をインプットすると項目別に評価が出力されるプロトタイプを作りました。動かしてみて分かったのは、AIは放っておくと「一般的な優秀さ」で判定してしまうという問題です。

この検証の概要

本記事は自社での検証記録です。スクリーニング工数の削減率などの定量測定は行っていないため、数値は掲載していません。

結論：AIは「その求人にとっての優秀さ」を知らない

この検証で最も重要な発見がこれです。

求人のターゲットによって、AIの評価基準がブレやすいことが分かりました。たとえばバックオフィス職とAI講師職では、求める人物像がまったく違います。

それにもかかわらず、AIは特定の求人軸に沿わない「一般的な優秀さ」で判定してしまいます。学歴が高い、経歴が華やかといった汎用的な指標に引っ張られるのです。

しかし採用の現場では、「優秀だが、この職種には合わない」という判断が日常的に発生します。ここを間違えると、スクリーニングとして機能しません。

対策：事業と会社の情報を前提として注入する

対応として必要になるのが、前提情報として詳細な事業・会社情報を注入することです。

どんな事業をしていて、その職種が何を担い、どんな人が活躍しているのか。この文脈がないと、AIは一般論で評価します。評価基準を職種ごとに具体化して渡す必要があります。

スコアリングの設計

プロトタイプでは、5つの評価項目に対して重み付けを行うスコアリングロジックを実装しました。

あわせて検討しているのが、評価項目を星1〜5で可視化する仕組みです。合計点に応じて星の数を決めます（例：9〜10点で星5）。

点数のままだと解釈が人によって変わるため、星に丸めることで判断の速度を上げるという設計です。

この取り組みを始めた背景

もともとはIndeed APIを使った応募者情報の自動取得を検討していましたが、パートナー申請が停滞していました。

そこで、API連携を待たずに工数削減を先行させるという判断で、この選考ワークフローの構築に着手しています。応募者情報の取得が手動でも、評価の部分だけ自動化すれば効果は出るためです。

外部要因で止まっている部分を待たず、自社で完結する範囲から着手するという進め方です。

今後の展望

この基盤は、次の段階を見据えて作っています。

• 2次選考・最終選考へのエスカレーション
• 面接動画の解析

書類選考の自動化は入口であり、選考プロセス全体をデータで繋ぐための土台という位置づけです。

よくある質問

AIの評価はそのまま使えますか？

前提情報を十分に与えないと、求人軸に沿わない「一般的な優秀さ」で判定されます。事業内容や職種の詳細を前提として注入したうえで、初期スクリーニングの参考にする位置づけが現実的です。

なぜ求人ごとに評価がブレるのですか？

AIは「その求人にとっての優秀さ」を知らないためです。バックオフィスとAI講師では求める人物像が違いますが、文脈がなければ汎用的な指標で評価してしまいます。

点数ではなく星を使うのはなぜですか？

点数のままだと解釈が人によって変わるためです。合計点に応じた星の数（例：9〜10点で星5）に丸めることで、直感的に判定できる形を目指しています。

Indeedとの連携はどうなりましたか？

API利用が停滞していたため、そこを待たずに評価部分の自動化を先行させました。応募者情報の取得が手動でも、スクリーニングの工数は削減できます。

まとめ

• Difyで選考ワークフローを構築し、項目別評価を出力するプロトタイプが完成
• 5つの評価項目に重み付けしたスコアリングと、星1〜5による可視化を設計
• 最大の課題は「一般的な優秀さ」で判定されてしまうこと。求人軸に沿わない評価になる
• 対策は詳細な事業・会社情報を前提として注入すること。文脈がないとAIは一般論で評価する
• Indeed連携の停滞を待たず、自社で完結する範囲から着手した

AIに評価を任せるとき、判断基準は自分たちで定義して渡す必要があります。「優秀な人を選んで」では、自社にとっての優秀さは伝わりません。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の採用業務へのAI活用を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。