応募の中身を経路ごとに仕分けて、どの媒体にいくら出すかの材料を毎月作る

処理の起点を決める

2つのトリガーを組み合わせます。

（1）応募が採用管理システムへ登録されたとき

仕分けをその場で行います。面接の判断より前に区分が付いている状態にします。

ただし、区分を採用担当に見せるかどうかは、慎重に決めてください。 見せると、担当者の判断が区分に引きずられます。 「志望の具体性が低い」と表示されていると、それだけで面接に呼ばない判断をしかねません。

推奨は、面接の判断の後に見せることです。 仕分けは裏で行い、集計にだけ使います。判断への介入を避けられます。

（2）月末のスケジュール

経路 × 職種 × 区分で集計します。前月・前年同月との比較も、ここで作ります。

月末の日付は、面接と採用の結果が確定してからにしてください。 応募から採用まで2〜4週間かかります。当月の応募の結果は、翌月末にならないと出ません。

この時間差を、集計の設計に織り込んでください。 「当月の応募件数と区分」と、「2か月前の応募の採用の結果」を別の表にします。

もう1つの起点として、四半期の見直しがあります。 区分の定義そのものを見直します。月次では細かすぎ、年次では遅すぎます。

入力データを集める

データの取得方法を決める

区分の定義が、この構成の質を決めます。 「質が高い」ではなく、次の軸で分けてください。

「志望の具体性」だけが、生成AIを使う判定です。 他はすべて入力欄から機械的に取れます。

「質」という言葉を区分に使わないでください。 「経験3年以上」は事実ですが、「質が高い」は評価です。評価の言葉を区分に入れると、記録が差別的な意味を持ちかねません。

志望の具体性の判定基準も、明文化してください。

「条件のみ」を否定的に扱わないでください。 勤務時間を重視する応募が悪いわけではありません。パートの募集では、むしろ条件が合うことが重要です。

「採用に至らなかった理由」の分類も決めてください。

この内訳が、媒体の評価を大きく変えます。 「連絡がつかない」が多い媒体と、「面接後の辞退」が多い媒体では、打つ手がまったく違います。

この表を最初に作っておくことが、集計を使える形にします。 数字が出てから「どうすればよいか」を考え始めると、月次の判断に間に合いません。

「掲載の文面で明確にする」が3つ出てくることに注意してください。 媒体そのものの問題ではなく、自社の掲載内容の問題であることが多くあります。 配分を変える前に、文面を直すほうが効く場合があります。

出稿の費用も、次の粒度で持ってください。 媒体ごとの月額だけでなく、職種ごと・掲載の枠ごとに分けられるなら分けてください。 1つの媒体の中でも、掲載の枠によって応募の性格が違います。

AIへ渡す前に整形する

1. 個人を特定する情報の除去 … 氏名、連絡先、住所の詳細、生年月日を外します。仕分けに不要です
2. 経路の正規化 … 媒体の名前の表記をそろえます
3. 職種の正規化 … 「介護職」「ケアスタッフ」「介護スタッフ」を1つにそろえます
4. 構造化された項目の判定 … 資格、勤務できる曜日と時間、通える範囲を、計算で判定します
5. 募集条件との合致の判定 … 応募先の施設・職種の条件と照らします。計算で行います
6. 自由記入の抽出 … 志望動機と、その他の自由記入を取り出します
7. 応募日と結果の紐づけ … 面接・採用の結果が出た時点で、応募の区分と紐づけます

1の個人情報の除去を、必ず最初に行ってください。 志望の具体性の判定に、氏名も連絡先も要りません。応募者IDで扱ってください。

年齢も渡さないでください。 区分に年齢を含めないことが、この構成の設計の前提です。

4と5を計算で行うことが重要です。 「月・水・金の9時から15時」が募集条件と合うかは、計算で決まります。生成AIに判定させると、ぶれる余地を作るだけです。

AIに処理させる

計算処理にさせること（生成AIには任せない）：

Gemini API にさせること：

応募者を評価させません。 「意欲が高い」「長続きしそう」といった記述を絶対に出させないでください。根拠のない評価が記録に残ることは、差別的な取扱いにつながる恐れがあります。

採否の判断もさせません。 「面接に呼ぶべき」「見送るべき」といった記述を禁じてください。

年齢・性別・国籍・家族の状況に基づく判断もさせません。 これらの属性を渡さないことが前提ですが、自由記入から読み取って判断することも禁じてください。

媒体の評価もさせません。 「この媒体は質が低い」といった記述を出させないでください。集計は数字で示すものです。

指示内容を固定する

役割と禁止事項は system_instruction に書きます。

【system_instruction】
あなたは人事部で応募の内容を仕分ける担当者です。
応募の自由記入から、決められた区分に仕分けることが役割です。

【厳守事項】
- 応募者を評価しないでください。
  「意欲が高い」「長続きしそう」「熱意が感じられる」「向いていない」
  と書かないでください。
  **根拠のない評価が記録に残ることは、差別的な取扱いにつながります。**
- 採否を判断しないでください。
  「面接に呼ぶべき」「見送るべき」と書かないでください。
- 年齢・性別・国籍・家族の状況に基づく判断をしないでください。
  自由記入にこれらが書かれていても、区分の判定に使わないでください。
  該当する記述があった場合は、区分に反映せず「記載あり」とだけ示してください。
- 健康状態や障害に関する記述を、区分の判定に使わないでください。
- 媒体を評価しないでください。
  「この媒体は質が低い」と書かないでください。
- 区分は、下の「区分の定義」の選択肢からだけ選んでください。
  定義にない区分を作らないでください。
- 判定できない場合は「不明」を選んでください。
  推測で区分を決めないでください。
- 「条件のみ」の区分を否定的に扱わないでください。
  勤務条件を重視する応募は、パートの募集では適切です。
  区分は事実の分類であって、良し悪しの判定ではありません。
- 区分を選んだ理由を、自由記入のどの部分に基づくかで示してください。
  該当箇所を示せない場合は「不明」にしてください。
- 与えられていない情報を推測で補わないでください。
  経験年数が書かれていなければ「不明」としてください。

【区分の定義（軸 / 区分 / 判定の基準）】
{classification_rules}

【応募の自由記入（志望動機・その他）】
{free_text}

【職歴の記述】
{work_history}

【応募先の職種と施設の種類】
{job_context}

「応募者を評価しない」の指示が、この構成でもっとも重要です。 採用の場面で、根拠のない人物評価が記録に残ることは、法令上も社内の運用上も問題になります。 この禁止は、テストで必ず確認してください。

「年齢・性別・国籍に基づく判断をしない」も同様です。 これらの情報を渡さない設計が前提ですが、自由記入に「子育て中です」「定年後の再就職です」と書かれていることがあります。 そこから判断させないでください。

「条件のみを否定的に扱わない」の指示を入れる理由があります。 志望動機に「土日休みを希望」としか書かれていない応募を、「意欲が低い」と扱うと、パートの採用では見当違いになります。 区分は事実の分類です。

「判定できない場合は不明」の指示も外せません。 自由記入が空欄の応募は一定数あります。無理に区分を付けると、集計が歪みます。

出力形式を固定する

{
  "application_id": "",
  "channel": "",
  "job_type": "",
  "classifications": [
    {
      "axis": "",
      "category": "",
      "basis_text": "",
      "confidence": "high | low"
    }
  ],
  "motivation_specificity": "specific | job_general | conditions_only | none",
  "motivation_basis": "",
  "experience_type": "same_field | other_field | none | unknown",
  "template_text_detected": false,
  "additional_conditions_from_text": [],
  "protected_attribute_mentioned": false,
  "unclassifiable_reason": ""
}

Gemini API で構造化した出力を得るには、response_format にオブジェクト型を指定して mime_type を application/json にし、schema にスキーマを渡します。 対応するのは JSON Schema の一部で、string / number / integer / boolean / object / array / null の型と、title / description、オブジェクトの properties / required / additionalProperties、文字列の enum / format、数値の enum / minimum / maximum、配列の items / prefixItems / minItems / maxItems が使えます。

すべての JSON Schema の機能に対応するわけではありません。 また、非常に大きなスキーマや深くネストしたスキーマは受け付けられないことがあります。

protected_attribute_mentioned を持たせている理由があります。 自由記入に年齢や家族の状況が書かれていた場合、区分には反映せず、フラグだけを立てます。 この記述を判断に使っていないことを、記録として残せます。

basis_text を必ず持たせてください。 どの記述に基づいて区分を選んだかが分かると、担当者が判定の妥当性を確かめられます。

template_text_detected は、媒体の定型文をそのまま送っている応募です。 これ自体は悪いことではありませんが、媒体の応募の仕組み（ワンクリック応募かどうか）の違いを表します。 集計の材料になります。

confidence が low の判定は、集計から外すか、別に数えてください。 無理に区分を付けた判定が混ざると、集計が歪みます。

システムへ連携する

区分を記録するだけで、採否に関わる処理は一切行いません。

応募者へ自動で連絡しないでください。 この構成は集計のためのものです。応募者とのやり取りに一切関与しません。

区分を面接の判断の前に見せないでください。 「志望の具体性が低い」と表示されていると、担当者の判断が引きずられます。 採用管理システムの画面で、面接の可否を入力した後に表示する設定にしてください。

それが難しい場合は、区分を採用管理システムへ書かず、集計用の記録にだけ残してください。

出稿の費用は、経理の情報から取ります。 媒体ごとの月額を集計表に載せることで、1件あたり・1名あたりの費用が計算できます。

人が確認する

担当者の確認は、2つの場面で行います。

（1）区分の妥当性の抜き取り確認

月に一度、30件を無作為に選んで、区分が妥当かを確かめます。

3つ目を最優先で確かめてください。 「意欲が感じられる」といった記述が記録に残ると、採用の記録として問題になります。

（2）月次の集計の確認

「採用に至らなかった理由の内訳」がいちばん実務に効きます。 「連絡がつかない」が3割を超える媒体があれば、応募のしやすさと本気度の関係を疑えます。

配分の判断は人が行います。 数字は材料です。媒体との関係、掲載の条件、地域の事情を踏まえた判断が要ります。 数字だけで打ち切ると、翌月に応募が急減することがあります。

例外に対処する

「区分が面接の判断の前に表示される」は、必ず避けてください。 この構成の目的は集計であって、選考の支援ではありません。判断に介入すると、応募者に不利益が生じる恐れがあります。

記録を残す

この記録は、出稿の配分を決める材料になります。

• 応募ごとの区分と、その根拠
• confidence が low だった件
• 抜き取り確認の結果と、訂正した区分
• 面接・採用の結果（区分と紐づけたもの）
• 経路 × 職種 × 区分の月次の集計
• 出稿の費用と、1名あたりの採用費用
• 配分の判断と、その理由

「配分の判断と、その理由」を記録してください。 「A媒体を減らしてB媒体を増やした」という判断と、その後の結果を突き合わせると、判断が当たっていたかが分かります。

応募の内容は個人情報です。 氏名や連絡先を含まない形で集計用の記録を持つ設計にしてください。区分の記録は、応募者IDと紐づく形で採用管理システムに残ります。

採用に至らなかった応募者の情報の保管期間を決めてください。 自社の個人情報の取扱いについての公表内容に沿った期間にします。集計用の記録は、個人を特定できない形にすれば長く持てます。

評価の記録を残さないことが、この構成の設計の要です。 区分は事実の分類です。「意欲が高い／低い」といった評価の記録が残ると、後から問題になりえます。