ユースケース

履歴書スクリーニング

必須要件の充足を確認し、総合的なフィットをスコア化します。経験をでっち上げさせません。

問題

キーワード検索は水増しした職務経歴書を有利にし、転職経験者を不利にします。

回答に対してコードが行うこと

必須要件が明らかに欠けているときだけ不採用にします。それ以外は面接へ。

まず必須要件、次にフィット

state は構造化された役割(must_have と nice_to_have のリスト)と履歴書のテキストを運びます。質問は 2 つ:meet_must_have(履歴書はすべての必須要件を満たすか)と fit(weak、possible、strong にわたるスコア)。分けることが重要なのは、両者は振る舞いが違うからです:必須要件の充足はチェックリストの検証です — Node.js の 5 年と 2 つの課金システムに対する TypeScript、Postgres、API 設計 — 一方の fit は、しきい値が所有する段階的な判断です。

キーワードではなく人間を面接する

不採用にするのは、必須要件が明らかに欠けているときだけです(高信頼度で低い meet_must_have の確率)。それ以外はみな先へ進みます — キーワードスクリーニングが不利にする転職経験者こそ、意味的読解の狙いです。nice_to_have のリストは state に残します:fit のスコアはそれを吸収しますが、パイプラインが埋まるにつれ "possible" の自分の基準は動かせます。

履歴書スクリーニング特有の落とし穴

公平性はここでは法的な表面です:スコアは振り分け、人は決め、必須要件による不採用は操作的でなければなりません — 欠けた能力であって、カルチャーフィットの雰囲気ではありません。本人識別データ(氏名、住所、生年月日)を判断の呼び出しに送らないこと。必須要件の充足確認には不要です。そして criteria は四半期ごとに見直します:資格は古くなり、実態が nice-to-have であるような必須要件は、キーワードによるバイアスです。

リクエストの形状

これは、このプリセットについて Playground が送る完全なリクエストです — 自分のサーバーが Bearer キー付きで /v1/systemone に送るのと同じ JSON です。

curl
curl https://jevai.website/api/v1/systemone \
  -H "Authorization: Bearer $JEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "state": {
    "role": {
      "title": "Backend engineer",
      "must_have": [
        "TypeScript",
        "Postgres",
        "API design"
      ],
      "nice_to_have": [
        "Workers",
        "payments"
      ]
    },
    "resume": "5 years Node.js, shipped two billing systems, strong TypeScript and Postgres. No public-cloud certs."
  },
  "questions": {
    "meet_must_have": {
      "type": "noul",
      "instructions": "Does the resume cover every item in `role.must_have`?"
    },
    "fit": {
      "type": "score",
      "instructions": "How strong is this candidate for the role?",
      "criteria": [
        "Weak",
        "Possible",
        "Strong"
      ]
    }
  }
}'

このユースケースに関する FAQ

これはリクルーターを置き換えますか?
いいえ — スケールが悪い部分を先取りするだけです:一次の必須要件の充足確認。最終候補者を落とす判断は人間が行い続け、fit スコアは不採用の山ではなく面接準備に行きます。
キーワードのゲーム化はどう防ぎますか?
モデルは意味を読むため、両刃の剣です:"shipping billing systems" はスキル一覧より強く読めます。must_have の項目は道具の名前だけではなく能力として state に書いてください。呼び出しは水増しよりも中身を評価します。
履歴書はセンシティブなデータですか?
はい。ゲートウェイは回答を計算するためにリクエストをモデルへ転送し、内容は保持しません — それでも、フローの中で応募者の同意を取り、判断に必要なものだけを送ってください。
Playground で実行する