「LLMに投げるだけ」では採用マッチングAIは機能しない｜評価設計とフィードバック学習で精度を生む方法
はじめに —— 「イメージと違う人が高スコアで出てくる」問題
ChatGPTに評価項目とプロンプトを書かせて、応募者を10人ずつスコアリングさせている。ところが上位5人の中に、現場が「うちのカルチャーには合わない」と判断する人が混じる。評価項目を見直してみても、なぜか同じ結果。
既存のAIスカウトを使っている企業も同じ症状を抱える。「おすすめ候補」を開くと、なぜかイメージと違う候補者が並ぶ。マッチングロジックの中身は見えず、調整しようがない。「AIに任せられない」と感じて、結局は手作業に戻ってしまう。
採用マッチングAIで起きる「精度が出ない」という問題の正体は、LLMの性能不足ではない。評価項目の言語化、コンテキスト設計、フィードバック学習のいずれか（または複数）が抜け落ちていることに起因する構造的な問題だ。
本記事では、採用マッチングAIで精度が出ない3つの構造的原因と、精度を生むための設計要素を、自社で運用可能なレベルまで分解して整理する。
なぜ採用マッチングAIで「イメージと違う人」が高スコアになるのか —— 3つの構造的原因
採用マッチングAIで「思った通りの人が出てこない」と感じるとき、原因は概ね以下の3つに分類できる。
原因1: 評価項目が言語化されていない
「いい人」「ハイパフォーマー候補」「カルチャーフィット」というキーワードを採用要件として持っている企業は多い。だが、それを 採点可能な粒度まで言語化できているか は別問題だ。
| 言語化が不十分な状態 | 採点可能な状態 |
|---|---|
| 「自走できる人」 | 「過去2年で、未経験領域のプロジェクトを自分で提案して立ち上げた経験がある」 |
| 「コミュニケーション能力が高い」 | 「複数部署と直接やり取りした経験がある／成果に対して関係者を巻き込んだ事例がある」 |
| 「カルチャーフィット」 | 「フィードバックを受けて行動を変えた事例がある／合議より検証で意思決定する組織での経験がある」 |
評価項目が「自走できる人」レベルの抽象のままLLMに投げると、LLMは過去学習の一般的な解釈で重みづけをしてしまう。結果として「世間一般にハイパフォーマー風に見える人」が高スコアになり、自社にとって本当に欲しい人物像とズレる。
ここで重要なのは、「言語化していないこと」が悪いのではなく、「言語化していないことに気づいていない」状態でAIを動かしてしまっていることだ。AIに評価させる前に、自社の採用責任者と現場で「具体的にどういう経験・行動・スキルが該当するか」を擦り合わせる工程が抜け落ちると、どれだけ高性能なLLMを使っても精度は出ない。
原因2: 言語化されていても、コンテキスト・タスク設計が悪い
評価項目を言語化できていても、それでも「イメージと違う人」が出てくるケースがある。この場合の原因は、LLMへのコンテキスト・タスクの渡し方にある。
LLMは与えられた情報を文脈として解釈するが、そのコンテキストの構造が雑だと、評価項目の重みづけが歪む。典型的な失敗例:
- 評価項目と採点基準が分離している: 「必要な経験は○○、加点要素は△△」とリストで渡すだけで、各項目の点数配分（必須項目は満点20点、加点要素は10点など）が指示されていない
- 判断材料が不足している: 履歴書の自由記述欄だけ渡して評価させる。職務経歴書の中で何に注目すべきか、どの記述から何を読み取るべきかの指示がない
- 出力フォーマットが緩い: 「総合点」だけ求めると、LLMは内部で雑に計算して数値を返す。項目別スコア＋根拠の記述を求めれば、LLMが各項目を分けて評価する意識が働く
- 評価のズレを許容する余地がある: 「総合的に判断してください」とすると、LLMは過去学習の一般論を混ぜ込む。「以下の評価項目以外は考慮しないでください」と明示する必要がある
LLMは指示通りに動く一方で、指示に書かれていない部分は自由に解釈する。コンテキスト設計が雑だと、その自由解釈の余地で精度が落ちる。
原因3: フィードバックループがなく、最適化が起きない
3つ目の原因は、現場の合否判断がモデルに戻らないこと。
仮に評価項目もコンテキスト設計もうまく組めたとしても、実運用で必ず「この人は高スコアだったが、実際の面接で違和感があった」「逆に低スコアだったが現場で会ってみたら欲しい人だった」というケースが出る。
このギャップこそが、本来モデルが学習すべき情報だ。だがDIYのChatGPT運用や、フィードバック機構を持たない既存AIスカウトでは、この情報が次のスコアリングに反映されない。
結果として:
- 同じ評価項目で同じ問題が再発する
- 採用担当者は「AIスコアは参考程度」と感じ、判断材料としての価値が下がる
- 候補者の選別ロジックが初期の人間の想定に固定され続ける（事業や組織の変化に追随できない）
採用マッチングは、応募者の集合と組織の状態が常に変化する動的な問題だ。学習が止まったマッチングAIは、時間とともに精度が下がる。
DIYと既存AIスカウトの限界 —— 3つのアプローチを比較する
ここまで整理した3原因に対して、現状のアプローチがどこまで対応できているかを比較する。
| 項目 | DIY（ChatGPT直叩き） | 既存AIスカウト（多くの製品） | 評価設計＋フィードバック型 |
|---|---|---|---|
| 評価項目の言語化 | ユーザー自身が記述（粒度不問） | 製品が用意したテンプレに記入 | 構造化フレームで言語化を強制 |
| 採点基準の明示 | プロンプトに含めるかは任意 | 内部処理で見えない | 重みづけ・閾値を明示的に設計 |
| 減点項目の扱い | 加点と混在 | 製品依存（多くは扱えない） | 減点項目を別軸で管理 |
| コンテキスト設計 | プロンプト技術に依存 | ブラックボックス | コンテキスト設計を製品側で標準化 |
| 出力の透明性 | スコアの根拠は薄い | 「おすすめ理由」が抽象的なことが多い | 項目別スコアと根拠を出力 |
| フィードバック学習 | なし（毎回ゼロから） | 製品によるが効果実感は限定的 | 合否判断を入力にしてモデル更新 |
| 評価軸の調整 | プロンプトを書き直す | UI上の制限内でのみ可能 | 評価項目の追加・重みづけ変更が即時反映 |
| 採用と現場の評価軸 | 揃いにくい（個別にAIに投げる） | 採用担当が独占しやすい | フレームの共有で揃う |
DIYは柔軟性は高いが、評価設計とフィードバック学習を自社で構築する負担が大きい。既存AIスカウトの多くはマッチングロジックがブラックボックスで、調整しようとしても触れる範囲が限られる。
「精度を生む3要素」を意図的に組み込んだ仕組みでないと、運用を回しても精度が上がっていかない構造になっている。
精度を生む3要素 —— 評価設計／コンテキスト設計／フィードバック学習
ここからは、採用マッチングAIで精度を生むための3つの設計要素を、実装可能なレベルで分解する。
要素1: 評価項目の構造化 —— 「定義」「重みづけ」「減点条件」を別軸で持つ
評価項目は、自由記述ではなく 構造化フレーム で言語化する。構造化のパターンには複数あるが、共通する設計原則は以下の3つ:
- 項目ごとの定義を行動・経験レベルで明確にする
- 項目別の重みづけを人間側で先に決める（LLMに「総合判断」させない）
- 減点条件を加点項目と別軸で持つ（「これがあれば失格／減点」を分離する）
代表的な構造化パターンを2つ示す。どちらでも上記3原則を満たせるが、運用設計が異なる。
パターンA: 必須／加点／失格の3区分型
| 区分 | 役割 |
|---|---|
| 必須要件 | これがなければ対象外（合計点でスクリーニング） |
| 加点要件 | あれば差別化要因として加点 |
| 失格条件 | 1つでも該当すれば失格扱い |
パターンB: 評価項目（重みづけ）＋減点項目型
| 構成 | 役割 |
|---|---|
| 評価項目（複数）＋ 各項目の重みづけ | スコアの加点軸。項目ごとに定義と重みを設定 |
| 減点項目（複数） | スコアから引く別軸。「合致したら－N点」「合致したら失格」など段階を設計可 |
パターンAはシンプルで導入しやすい。一方、パターンBは「重みづけの細かい調整」「減点の段階設計（軽い違反は減点／重大な違反は失格）」が可能で、運用が深まるほど細かい意思を反映できる。
どちらを採るかは運用負荷と要求精度のバランスで決める。重要なのは 「項目別の重みづけと減点条件が別軸として明示されていること」 で、これが守られていればフレームの形式は問わない。
以下、要素1の例として 必須／加点／失格の3区分型 を使うが、自社運用では同じ思想を「評価項目＋重みづけ＋減点項目」の構成で実装してもよい。
| 軸 | 項目例（SaaS企業のセールス職） |
|---|---|
| 必須要件 | BtoB営業3年以上 / 前年度予算達成 / 国内勤務可能 |
| 加点要件 | 無形商材の経験 / インサイドセールス→フィールドセールスの移行経験 / 採用面接や育成への関与経験 |
| 失格条件 | 職務経歴の空白が18ヶ月以上で説明がない / 年収レンジが提示帯の1.3倍以上 |
3つの区分に分けると、重みづけが自然に決まる。必須要件を満たさない候補者はそもそも対象外、加点要件で優先順位をつける、失格条件は1つでも該当すれば除外する。LLMに任せていた重みづけの判断を、人間側で先に決めておく構造になる。
要素2: コンテキスト設計 —— LLMへのタスクの渡し方
評価項目を構造化したうえで、LLMへの渡し方を設計する。
Bad: コンテキスト設計が雑な例
以下の応募者を評価してください。
評価項目: BtoB営業経験、予算達成、無形商材経験。
[応募者の経歴]
...
Good: コンテキスト設計が整理された例
あなたは{企業名}の採用担当アシスタントです。
以下の応募者を、指定の評価項目のみに基づいて評価してください。
評価項目以外の要素（学歴・性別・年齢など）は判断に含めないでください。
[必須要件 (合計60点)]
- BtoB営業経験 3年以上 (20点)
- 前年度の予算達成 (20点)
- 国内勤務可能 (20点)
[加点要件 (合計40点)]
- 無形商材の経験 (15点)
- インサイドセールス→フィールドセールスの移行経験 (15点)
- 採用面接や育成への関与経験 (10点)
[失格条件]
- 職務経歴の空白が18ヶ月以上で説明がない
- 年収レンジが提示帯の1.3倍以上
[応募者の経歴]
...
[出力フォーマット]
- 必須要件の項目別の点数と根拠（経歴のどの記述から判断したか）
- 加点要件の項目別の点数と根拠
- 失格条件該当の有無と理由
- 合計点（失格該当の場合は0点）
- 総合所見（3-5行）
Goodの例では:
- 評価項目以外を判断に入れない指示で、LLMの自由解釈を抑える
- 各項目の点数配分を明示し、重みづけをLLMに委ねない
- 根拠の記述を求めることで、LLMが項目別に評価する意識を持つ
- 出力フォーマットを固定し、後段の集計・比較を自動化しやすくする
このレベルでコンテキストを設計すると、同じ応募者を複数回評価しても出力の揺れが小さくなり、運用上の信頼性が上がる。
要素3: フィードバック学習 —— 合否判断をモデルに戻す
3つ目は最も実装が難しい要素だ。
実装の選択肢は3段階ある:
Level 1: 評価項目の更新（人間によるルールベース更新）
合否判断のズレが出たら、評価項目を見直す。「過去2年で〜の経験」を「過去3年で〜の経験」に変える、新しい項目を追加する、減点項目を新設する、など。手動だが確実に学習が積み上がる。
Level 2: 重みづけの自動調整
合否判断と各項目スコアの相関を分析し、項目の重みを自動更新する。「加点要件Aは合格者に多いから配点を増やす」「必須要件Bは差がつかないから配点を減らす」など。
Level 3: モデルチューニング
合否判断のデータをLLMのファインチューニング用データセットとして蓄積し、自社専用のスコアリングモデルを育てる。最も精度が出るが、データ量と運用コストが必要。
DIYで取り組む場合、最低でもLevel 1は必須。Level 2以降は運用負荷との兼ね合いだ。重要なのは、「フィードバックを次のスコアリングに反映する仕組み」を持っていること自体。仕組みがなければ、どれだけ評価項目を磨いても運用2-3ヶ月でズレが固定化する。
実装の落とし穴 —— Good/Bad対比
3つの設計要素を踏まえ、実装でつまずきやすいポイントを整理する。
| 領域 | Bad（ありがちな失敗） | Good（精度を生む設計） |
|---|---|---|
| 評価項目 | 「コミュニケーション能力」など抽象表現 | 「複数部署と直接交渉した経験がある」など行動レベルで言語化 |
| 採点基準 | 5段階評価（高すぎ・低すぎは少ない） | 必須要件合計100点・加点要素20点など、合計値で判別する設計 |
| 加点と減点の扱い | 加点項目に減点要素を混ぜている | 加点と減点を別軸で持ち、減点は段階設計（軽い／重大／失格） |
| 候補者の母集団 | スカウト送信前にAIで絞り込んでいる | スカウト後の返信者をAIで評価する（応募行動を経た母集団に対して使う） |
| コンテキスト | 「総合的に判断してください」 | 「以下の評価項目以外は判断材料にしないでください」と明示 |
| 出力形式 | 総合スコアのみ | 項目別スコア＋根拠＋総合所見 |
| 評価のズレ対応 | スコアの揺らぎを許容している | 同じ応募者を3回評価し、揺らぎが10%超なら原因究明 |
| フィードバック | 採用担当者の頭の中だけに残る | 評価項目／重みづけ／プロンプトを定期的に更新する仕組み |
| 採用担当と現場 | 採用担当だけがAIを触る | 評価項目を現場と擦り合わせ、フィードバックも現場から取る |
| 透明性 | AIスコアの根拠が見えない | 項目別スコアと根拠が候補者ごとに表示される |
| 運用継続性 | 一度作って放置 | 月1回は評価項目をレビューする運用ルーチン |
特に重要なのは「スカウト前の絞り込みではなく、応募行動後の評価に使う」という点。スカウト前にAIで絞ると、AIの評価項目が偏っていた場合にそもそも応募してこない候補者が多発する。応募してきた候補者を評価するフェーズで使うと、応募行動という人間の意思を経た母集団に対する精度向上になる。
SAIRAIの視点 —— 「採用と現場の評価軸を揃える」という設計思想
ここまでの3要素は、Tasonalが「AIスカウト」機能で採用している設計思想と直結する。
Tasonalの設計の出発点は、採用と現場の評価軸を揃える ことにある。
採用担当が「どんな人が欲しいか」を評価項目として言語化しても、現場の責任者が見ると「ちょっと違う」と感じる。これが採用後のミスマッチや、選考途中での評価ブレを生む。評価項目を構造化して共有することは、採用と現場が同じテーブルで議論するための共通言語を作る作業だ。
Tasonalの現状の実装は、評価項目ごとの定義と重みづけ、それに減点項目を別軸で持つ構成 だ。本記事のパターンBに近い。評価項目それぞれに行動レベルの定義を書き、項目ごとの重みを設定し、減点項目（「これがあれば減点」「これがあれば失格」）を別途用意することで、加点と減点が混ざらない構造になっている。さらに、必須／加点の合致度を別軸で取れるようにする改修も進めており、運用の細かさをさらに高められる方向で進化させている。
そのうえでLLMにコンテキストを渡し、項目別スコアと根拠を出力させる。最終判断は人が行う。AIは「判断材料を構造化された形で揃える」ことに徹し、「合否を決める」役割は人間に残す。
そして、面接後の合否判断と採用後のパフォーマンスデータを評価項目にフィードバックする。事業の変化、組織の変化、市場の変化に応じて評価項目自身が更新されていく。運用するほど精度が上がる仕組み にすることが、採用マッチングAIの本来の姿だと考えている。
これは Tasonal の機能だけが持つ思想ではない。自社運用でも、評価項目の構造化（定義・重みづけ・減点条件）、コンテキスト設計、フィードバック学習の3要素を意図的に組み込めば、同様の精度向上は実現できる。重要なのは、「LLMに丸投げ」ではなく「設計された運用フロー」としてマッチングAIを位置づける ことだ。
まとめ —— 採用マッチングAIは「設計と運用」で精度が決まる
採用マッチングAIで「イメージと違う人が高スコアになる」問題は、LLMの性能不足ではなく以下の3つの構造的原因に起因する:
- 評価項目が言語化されていない —— 「いい人」が抽象のまま、LLMが独自解釈で重みづけ
- 言語化されていてもコンテキスト・タスク設計が悪い —— LLMへの渡し方で精度が落ちる
- フィードバックループがなく最適化が起きない —— 合否判断がモデルに戻らない
精度を生むための設計要素は:
- 評価項目の構造化（項目ごとの定義／重みづけ／減点条件を別軸で持つ）で重みづけを人間側で先に決める
- コンテキスト設計（評価項目以外を判断に入れない指示、項目別配点、根拠付き出力）でLLMの自由解釈を抑える
- フィードバック学習（評価項目更新／重みづけ調整／モデルチューニングの3レベル）で運用するほど精度を上げる
DIYで取り組む場合は、まず評価項目の言語化から始める。項目ごとの定義を行動・経験レベルで書き、重みづけを設定し、減点項目を別軸で持つ。現場と擦り合わせる工程を必ず入れる。それだけで、LLMに投げる前の「精度の上限」が大きく変わる。
「AIに任せきれない」と感じている企業の多くは、AIの性能ではなく 評価設計の不在 に課題を抱えている。設計を直せば、精度は出る。
採用と現場の評価軸を揃えたまま回せる、Tasonalのスカウト機能。評価項目ごとの定義・重みづけと減点項目を別軸で管理する設計、項目別スコアリング、フィードバック学習を標準搭載しています。
