採用の実務は、文章を書く仕事より、仕分ける仕事のほうが件数が多くなります。この候補者は要件に合うか。この会社は今回の対象か。この問い合わせは誰に回すか。答えはどれも、はい/いいえか、決まった選択肢の中にあります。
こうした仕分けに向けて設計されたモデルが2026年9月に出ました。TypeSafe AI の Jev です。文章を一切生成せず、型を決めた問いに対して確率つきの判定だけを返します。
以下、Jevを採用活動のどの工程に、どういう形で当てられるかを工程順に見ていきます。実装の手順書というより、人事の側が「自社のどこに置けるか」を見積もるための地図に近い内容です。
Jevは文章を書かず、判定だけを返す
一般的な大規模言語モデルは、問いに対して文章を返します。「この応募は要件を満たしていますか」と聞けば、「満たしています。理由は……」という文が返る。そこから「満たす/満たさない」を取り出す工程が、必ず後ろに要るわけです。
Jevはこの工程を省きました。返すのは選択肢か点数か確率だけで、そのまま業務システムの条件分岐に渡せる形になっています。
当社が9月20日に公表した資料では、対応する判定の種類として分類・振り分け・採点・抽出・分岐の5つを挙げました。応答時間は70〜500ミリ秒。既存の大規模言語モデルと比べて40〜200倍速いとされています。料金は入力100万トークンあたり0.042ドルで、出力には料金がかかりません。当社は同じ日に、Jevを Offers のスキル登録にも追加しています。
出所: 株式会社overflow『Offers、公開から5日の新AIモデル「Jev」をスキル登録に追加』(2026年9月20日公表)。
できないこともはっきりしている
導入の検討で誤解が生まれやすいので、先に書いておきます。
Jevは文章を作れません。スカウト文面の下書きも、面談メモの要約も、不採用通知の文言も、このモデルでは書けない。判定の理由を文章で説明させることもできません。返るのは選択肢と数字だけです。
「なぜそう判定したのか」を知りたい場合は、問いを分割します。ひとつの問いで総合判定を出すのではなく、「必須要件Aを満たすか」「必須要件Bを満たすか」と個別に聞けば、どこで落ちたかが構造として分かる。文章で理由を語らせる代わりに、問いの立て方で説明を作る形になります。
型に収まった値しか返らない点は、利点でもあります。選択肢を3つ与えれば、返るのはその3つのどれかで、存在しない4つ目が出てくることはありません。ただし型に収まることと、中身が合っていることは別の話です。与えた選択肢の中から、間違ったものを選ぶことは起こります。
投げられる問いは3種類
公式ドキュメントが定義している問いの型は3つです。この3つで、採用の仕分けはほぼ表現できます。
型 | 何を聞くか | 返るもの | 採用での例 |
|---|
Noul | この記述は正しいか | 0から1の確率 | 必須要件を満たす経験があるか |
Choice | 並べた選択肢から1つ選ぶ | 選んだ選択肢・各選択肢の確率・確信度 | この応募はどの職種か |
Score | 基準に沿って点数をつける | 点数・確率の分布・確信度 | 募集要件との近さは何点か |
出所: TypeSafe AI 公式ドキュメント『Introduction』(2026年9月21日確認)。
公式ドキュメントによれば、同じ材料に対して複数の問いが並行して評価されます。1件の応募に対して「必須要件を満たすか」「どの職種か」「どのチームに回すか」をまとめて投げられる、ということです。
どの型でも確率が一緒に返る点は、後で触れる線引きの前提になるので覚えておいてください。
採用活動のどこに当てはまるか
工程ごとに整理すると、当てはまる場所は5つに分かれました。
工程 | 投げる問い | 型 | 人に残すもの |
|---|
母集団形成 | この企業・候補者は今回の対象か | Choice / Noul | 誰に声をかけるかの最終判断 |
書類選考 | 必須要件を満たす経験があるか | Noul / Score | 合否そのもの |
振り分け | この応募・問い合わせはどの窓口か | Choice | 例外的な案件の扱い |
文面の点検 | この求人票は社内規定や法令に反していないか | Noul | 表現の最終決定 |
データ整理 | この記録はどの区分か | Choice | 区分そのものの設計 |
以下、それぞれの当てはめ方を順に見ていきましょう。
母集団形成で対象を絞り込む
スカウトの送り先や、営業でいう対象リストにあたる部分です。
ここでJevに渡すのは、企業サイトの本文や候補者のプロフィールといった、公開されているテキストになります。聞くのは「この企業は自社でソフトウェアを開発しているか」「この候補者は募集職種の経験を持つか」といった、テキストを読めば分かる問いです。
母集団形成の工数は、対象を広げるほど増えます。人が1件ずつ見る前に確度の高いものだけを残せれば、後工程に回る件数が減る。ここがJevの置きどころになります。
投げる問いは、こういう形になります。
- Choice「この企業の主な事業はどれか」。選択肢は 自社プロダクト開発/受託開発/SIer/非IT
- Noul「この候補者は、募集職種と同じ領域での実務経験を持つか」
- Score「募集要件との近さを0から4で採点する」。4は必須要件をすべて満たす、0は領域が異なる
注意したいのは、選択肢の設計が結果を決めることです。「テック企業か、そうでないか」の2択にすると、自社サービスも受託も両方やっている会社が必ずどちらかに寄ります。境界にいる相手をどう扱うかを先に決めておかないと、判定が割れたときに手が止まります。
母集団形成の考え方そのものは母集団形成とは?応募を待たない中途採用の設計で整理しました。
書類選考で要件と突き合わせる
いちばん期待が集まる工程ですが、置き方に注意が要ります。
職務経歴書に書いてあること、つまり使った技術、担当した範囲、経験年数は、書類の中で完結しています。「Pythonでの開発経験が3年以上あるか」をNoulで聞けば、根拠は目の前のテキストにある。Scoreを使えば「募集要件との近さ」を点数で返させることもできます。
一方、書いていないことは当たりません。自社の進め方に合うか、入社後に伸びるか、チームで機能するか。これらは職務経歴書に書かれていないので、どれだけ確信度が高く返ってきても、モデルは材料なしに答えていることになります。
ここから引ける線がひとつあります。書類に書いてある事実の突き合わせは任せられる。書類から読み取れない資質の推測は任せられない。 実務では、この線を引いてから工程を設計することになるでしょう。
問いの書き方でいうと、次のように分かれるでしょう。
投げてよい問い | 投げても当たらない問い |
|---|
必須要件に挙げた技術の実務経験が記載されているか | 当社のカルチャーに合いそうか |
マネジメント経験の年数が3年以上と読めるか | 入社後に伸びそうか |
募集ポジションと同じ業界での経験があるか | 転職理由に懸念はないか |
応募書類に必要な項目がそろっているか | 志望度は高そうか |
右の列を投げると、モデルは書かれていない情報を補って答えます。しかも確信度が低く返るとは限りません。材料が無いときほど、自信を持って外すことがある。ここが運用上いちばん危ないところでしょう。
どの窓口に回すかを振り分ける
応募、問い合わせ、面談リクエスト。入口が複数あると、受けた側が仕分ける手間が増えます。
Choiceで「この問い合わせはどの職種か」「どの段階の相談か」を聞けば、回す先は決められます。文面の中に職種名や相談内容が書かれていれば、材料は足りている。
振り分けの誤りは後工程で気づけます。間違った窓口に届いても、受け取った側が回し直せば済む。取り返しがつく工程なので、自動化の線を比較的ゆるく引けます。
間違えたときに何が起きるか。これは置き場所を決めるもうひとつの軸になります。
振り分けを外しても、失うのは回し直す手間だけです。求人票の点検を外しても、書き手に不要な警告が出るだけで、公開前に人が判断します。ところが書類選考の絞り込みを外すと、本来会うべきだった人に会わないまま終わります。落としたことは記録に残っても、落とさなければどうなったかは誰にも分からないままです。
間違いが後工程で拾える場所には自動化を置きやすく、拾えない場所では精度が高くても人が全件見る。工程ごとに線の高さを変える理由がここにあります。
求人票とスカウト文面を点検する
求人票やスカウト文面が、社内の方針や法令の線を越えていないかを見る工程です。
この用途がJevに向くのは、検査したい文章そのものを渡すためです。材料が欠けることがありません。Noulで「この文章は年齢や性別を条件にしていないか」「自社の表記ルールに反していないか」と聞けます。
語のリストによる検査では、禁止語を避けて同じ意味を書いた文が通ってしまいます。意味を読むモデルなら、言い換えた表現も検査の対象にできる。ここは従来の仕組みとの差が出やすいところでしょう。
求人票そのものの書き方は求人票とは?記載事項と食い違いを防ぐ書き方にまとめてあります。
選考記録を区分してデータにする
面談メモ、選考コメント、候補者からの質問。蓄積はされていくものの、区分が付いていないと後から掘り返すのに手間がかかります。
Choiceで区分を付けておけば、後で「どの理由での辞退が多いか」「どの質問が繰り返されているか」を集計できるようになります。分析のための下ごしらえにあたる工程です。
この用途は、間違えたときの損失がいちばん小さくなります。区分を外しても、集計の精度が少し落ちるだけで、誰かの機会が失われるわけではありません。導入の練習として置くなら、ここから始めるのが安全でしょう。
区分の設計そのものは人の仕事として残ります。何を数えたいかを先に決めてから、その単位で区分を作ることになります。
生成AIとの使い分け
どちらかを選ぶ話にはなりません。工程ごとに置き分けます。
採用の仕事 | 向くもの | 理由 |
|---|
スカウト文面の下書き | 生成AI | 出力が文章そのもの |
面談メモの要約 | 生成AI | 答えが型に収まらない |
対象企業・候補者の絞り込み | Jev | 答えが決まった選択肢の中にある |
求人票の表記チェック | Jev | 答えが「反している/いない」の2値 |
問い合わせの振り分け | Jev | 回す先が決まっている |
実務では、両方を直列に置く形が多くなります。判定で件数を絞り、残ったものだけを生成AIか人に回す。順序が逆だと安さの利点が消えるので、判定を前に置くのが基本です。
費用の目安
判断を試す規模では、費用が壁になりにくい水準です。
入力100万トークンあたり0.042ドル、出力は無料。日本語のテキストは1文字あたりおよそ1トークン前後で数えられるので、職務経歴書1件を2,000字として、1件あたり約2,000トークンになります。
これで1,000件を判定すると、200万トークンで約0.084ドル。1件あたり0.1円に届きません。複数の問いを同時に投げても、材料のテキストは共通なので、増えるのは問い文のぶんだけです。
出所: 単価は株式会社overflow『Offers、公開から5日の新AIモデル「Jev」をスキル登録に追加』(2026年9月20日公表)。件数あたりの試算は、その単価から本記事で計算した値です。
速度上限も、採用の実務で当たる水準にはありません。当社が使っている直販の経路では1分あたり1,200リクエストです(提供元は需要に応じて変わると明記しています)。1日数十件から数百件の応募を扱う規模なら、上限は視野に入ってこないでしょう。
使うときの4つの設計
どの工程に置くにしても、設計として決めておきたいことが4つあります。
確信度で自動化の範囲を切る
Jevは判定と一緒に確率を返してきます。この数字を使って、自動で確定させる範囲と人に回す範囲を分けましょう。
たとえば確信度0.8以上を自動確定、それ未満は人が見る、という切り方です。全件を人が見るのと比べて対象が減り、しかも減った分は「機械が自信を持っていた分」になります。
線をどこに引くかは、題材ごとに変わります。移せるのは数字ではなく、確信度の高い範囲と低い範囲で正答率がどれだけ違うかを、自社のデータで先に測るという手順のほうでしょう。
測り方は単純です。過去の判断を正解として100件ほど判定させ、確信度で並べ替える。正解した件の確信度と、外した件の確信度が離れていれば、そのあいだに線を引けます。両者が重なっていたら、その題材では確信度が使えません。材料を足すか、問いを書き直すか、そもそも機械に渡さないかを選ぶことになります。
線は片側だけに引くこともできます。求人票の点検なら「違反の確率が高いときだけ警告を出す」という運用です。誤検知は書き手の手を止めるので、確信が高いときしか鳴らさない。逆に「違反ではない」側は何も起こさず、従来どおり人が見る。この形にしておけば、導入しても現場の手順は今までのままで済むはずです。
判定が止まっても業務を止めない
鍵の失効も、通信の失敗も起こり得ます。判定が返らなかったときに採用の工程が止まる設計にすると、速くするための仕組みが業務の弱点になってしまうでしょう。
判定が得られなければ従来どおり全件が人に回る。この逃げ道を作っておけば、提供元が落ちた日も採用は回ります。
何を機械が決めたかを残す
採用の文脈では、これがいちばん重くなります。
誰の応募が、どの工程で、何を根拠に絞られたのか。記録が無ければ、後から説明できません。判定の結果と、そのときの確信度と、どの問いを投げたかを残しておく。求職者への説明責任にも、社内の振り返りにも、この記録が要ります。
基準を変えたら測り直す
募集要件は動きます。必須スキルが変わる、対象年次が変わる、ポジションが増える。そのたびに問いと基準文の見直しが要ります。
見直したあとは、同じデータで測り直す。基準文をひとこと変えただけで判定が動くことがあるためです。「経験が豊富か」を「同じ領域で3年以上の実務経験があるか」に書き換えると、返ってくる答えは変わります。どちらが正しいかではなく、自社がどちらを聞きたかったのかを確かめる作業になります。
モデルの版が上がったときも同じです。提供元が新しい版を出したら、切り替える前に手元のデータで比べる。精度が落ちても判定は静かに返り続けるので、比べる工程を挟まないと気づかないまま運用が続きます。
説明責任をどう持つか
採用でAIを使うときに、速さや費用より先に問われるのがここです。
求職者から「なぜ落ちたのか」と聞かれたとき、答えられる状態になっているか。社内で「この絞り込みは妥当か」と問われたとき、根拠を示せるか。どちらに答えるにも、判定の記録が要ります。
実務で持っておきたい記録は3つあります。どの問いを投げたか、どういう基準文だったか、返ってきた確信度はいくつだったか。この3点があれば、後から判断の再現ができます。
法規制の側の動きはAI人事とは?人事のAI利用39%、5領域と法規制に整理してあります。採用は人の機会に直接関わる領域なので、規制の対象になりやすい分野です。導入の検討と並行して、自社が何を説明できる状態にしておくべきかを確かめておくとよいでしょう。
任せない線引き
採用は人の人生に関わる判断です。速くなるからという理由だけで機械に渡すと、後で立ち行かなくなります。
任せないほうがよいものを挙げておきます。
- 合否そのもの。落とした理由を説明できなくなります
- 評価の点数化を最終結果にすること。Scoreは参考値として使い、決めるのは人が行う
- カルチャーフィットの判断。書類に書かれていないので、材料がありません
- 取り返しのつかない連絡の送信。不採用通知のような、送ってしまうと戻せない操作
逆に言えば、人が最後に見る前の絞り込みと、人が見落とす点検。この2つがJevの置きどころでしょう。
候補者から自社の採用情報がどう見えているかを外形的に確かめるには、エンジニア採用力チェックが使えます。公開情報(採用ページ・求人票・技術発信)を5指標24項目で採点するので、仕分けを機械に渡す前に、どこに手をつけるべきかを確かめられます。
つまずきやすい置き方
導入がうまくいかないとき、原因はモデルの性能ではなく置き方にありました。
答えが材料に無い問いを投げている。 いちばん多い型です。判定の精度が上がらないとき、まず疑うのは問いの内容ではなく、渡しているテキストに答えが書かれているかどうかになります。
選択肢が排他的になっていない。 「Webエンジニア」「バックエンドエンジニア」を並べると、どちらにも当てはまる候補者で判定が割れます。選択肢は重ならないように設計する必要があります。
基準文が曖昧なまま件数を増やしている。 100件で精度が出ないものは、1,000件でも出ません。件数を増やす前に、基準文を書き直すほうが近道でしょう。
判定を最終結果として扱っている。 人が見る前の絞り込みとして置いたはずが、いつのまにか誰も見ないまま確定している。運用に入ってから起きやすい崩れ方です。
どの工程から始めるか
5つを同時に始める必要はありません。優先順位は、次の2つの掛け合わせで決まります。
ひとつは、正解データがすでにあるか。過去の判断が記録として残っている工程ほど、早く測れます。書類選考の合否や、レビューで差し戻した求人票は、たいてい残っています。
もうひとつは、間違えたときに後工程で気づけるか。気づける工程から入れば、失敗しても損失が小さく収まります。
この2つで並べると、多くの会社では「データ整理」か「振り分け」が最初に来るでしょう。どちらも記録が残りやすく、外しても取り返しがつきます。ここで問いの書き方と確信度の扱いに慣れてから、書類選考のような重い工程へ進む。この順で登るほうが、途中で止まりにくい。
逆に、いきなり書類選考から始めると、正解データの整備と説明責任の設計を同時にやることになるでしょう。できなくはないものの、最初の一歩としては重い。
始め方
導入の前に踏んでおく順番があります。
まず、正解データを探します。 過去に人が書類選考で付けた合否。スカウトを送った企業と送らなかった企業。求人票のレビューで差し戻した箇所。採用の現場には、業務の副産物として判断の記録が溜まっているものです。新しく作らなくても、たいていは手元にそろっているでしょう。
次に、問いと基準文を書きます。 ここが精度を左右します。「この応募は要件を満たすか」だけでは足りません。満たすとはどの状態か、満たさないとはどの状態かを、書類に書かれている言葉で書き分ける必要があります。
この作業は要件定義そのものです。人が判断していたときは「見れば分かる」で済んでいたものが、書き出してみると担当者ごとに違っていた、ということも起こります。機械に渡せるかどうか以前に、この整理自体に価値があるでしょう。
そのうえで、しばらく両方を動かします。 従来の工程と判定を並行させて、食い違った件だけを見る。食い違いが確信度の低い側に寄っていれば、線の位置を変えれば済みます。寄っていなければ、渡している材料が足りていないので、件数を増やしても結論は変わりません。
費用は判断の妨げになりません。入力100万トークンあたり0.042ドル、出力は無料です。数百件を試す程度なら、金額は判断材料に入ってこない水準でしょう。先に重くなるのは、正解データを整える人手のほうです。
なお、当社でもいくつかの仕分け業務で試しました。うまく当たった題材と、確信度を上げても実用に届かなかった題材の両方があります。分かれたのは、渡したテキストの中に判断の根拠が書かれていたかどうかでした。
採用要件としてのJev
最後に、労働市場の側にも触れておきます。
当社がJevをOffersのスキル登録に追加したのは、公開から5日後でした。求職者がプロフィールに登録でき、企業が募集の際にスキル条件として指定できます。
新しいモデルが出てから、それを扱える人を求人票に書けるようになるまでの時間は、以前より短くなっています。事業側が試している段階で、人事側も要件を動かせるかどうか。採用要件を決める立場から見ると、ここが問われる場面が増えていくのでしょう。
人事領域全体でAIがどこに入っているかはAI人事とは?人事のAI利用39%、5領域と法規制で整理しました。
Jevを採用活動に置くなら
Jevは、分類・振り分け・採点のような、答えが型に収まる仕事に向きます。採用の工程でいえば、母集団形成の絞り込み、書類選考での要件の突き合わせ、応募の振り分け、文面の点検、選考記録の整理の5つが当てはまります。
置くときに決めることは4つ。確信度で自動化の範囲を切ること、判定が止まっても業務を止めない形にすること、何を機械が決めたかを記録に残すこと、基準を変えたら同じデータで測り直すことです。
そして、合否そのものと、書類から読み取れない資質の判断は人が持つ。この線を先に引いておけば、速さと説明責任を両立させられます。
導入を検討するなら、精度の数字を他社から借りるより、自社の過去の判断を正解データにして測るほうが早いでしょう。材料が違えば、結果も変わります。