人材紹介会社で新しい求人を受けたときに、過去の求人票と企業ヒアリングの記録を職種・条件・業界で探し、書き方の参考と不足しがちな条件を担当に返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは毎晩の定時です。 前日に作成・改訂された求人票、候補者からの質問の記録、推薦と応募の件数を取り出します。改訂は求人を出してから数週間続くので、新しい求人だけでなく、改訂のあった求人も毎晩取り直します。

検索は、法人担当が「過去の求人を見る」を押したときに動きます。 ヒアリングの記録を案件管理の仕組みに残した直後に押してもらいます。求人票を書き終えてから見ても、企業に追加で確かめる機会が残らないためです。 ヒアリングの当日中に追加の質問を企業に送れれば、求人票を出すまでの日数が延びません。

過去6年分の約1万2千件は、別に一括で取り込みます。 古い求人票は今の明示の基準を満たしていないことがあるので、作成日を検索結果に必ず出し、令和6年4月より前の求人票には印を付けます。

入力データを集める

質を決めるのは、改訂の履歴です。 「何が後から書き足されたか」は、最初の版と最後の版を比べないと分かりません。項目ごとに版が残る仕組みなら、比べるのは機械的にできます。 版が残らず上書きされる仕組みなら、取り込みを始めた日から差分をためていきます。

推薦と応募の件数は、書き方の参考を選ぶときの手がかりに使います。 ただし件数は、求人の条件や企業の知名度で大きく変わります。件数が多い求人票が、書き方の良い求人票とは限りません。 まとめでは件数を並べるだけにし、良し悪しの判断はさせません。

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

求人票と改訂の履歴、候補者からの質問は、案件管理の仕組みから文字で取り出します。企業から受け取った求人依頼書のファイルは取り込みません。 求人依頼書には社外秘の組織図や年収の内訳が書かれていることがあり、検索の材料には求人票の項目で足ります。

索引の項目は、次のように持たせます。

job_text に term_vector を持たせるのは、more_like_this を速くするためです。 公式のドキュメントでは、索引に登録するときに term_vector を保存しておくと、検索のときに文を解析し直さずに重要な語を取り出せるため、大幅に速くなるとされています。

AIへ渡す前に整形する

1. 書き足された項目の取り出し（取り込み時） … 最初の版で空だった、または「応相談」だった項目が、後の版で埋まったものを amended_fields にします
2. 質問の仕分け（取り込み時） … 候補者からの質問を、Claude で条件の種類に仕分けます
3. 企業名の伏せ（取り込み時） … 求人票の文に出てくる企業名・製品名を、業界と規模の言葉に置き換えた写しを検索用に持ちます
4. ヒアリングの記録の整え（検索時） … 担当者の書いたメモから、企業名と担当者の氏名を伏せてから like に入れます
5. 職種名の同義語 … 「CS」「カスタマーサクセス」などを辞書でそろえます

1番目の「応相談」を空として扱うのが要点です。 最初の版に「リモート：応相談」と書かれ、後の版で「週2日まで」と書かれた求人は、ヒアリングの時点では決まっていなかったということです。これを書き足しとして数えないと、聞き漏れやすい条件の件数が少なく出ます。

3番目で企業名を伏せるのは、別の企業の求人を参考にするためです。 法人担当がまとめを読むのは、書き方を学ぶためで、他社の求人の中身を新しい企業に伝えるためではありません。

AIに処理させる

AIの仕事は2か所です。取り込み時の質問の仕分けと、検索時のまとめです。 似た求人を探すのも、書き足しを数えるのも検索基盤で、明示の有無は規則で見ます。

1行目がいちばん外せない線です。 似た求人票を渡して「参考にして書いて」と頼むと、AIは過去の求人の条件を含んだ文を書きます。「残業月20時間程度」が、今回の企業に確かめていないまま求人票に載ることになります。

5行目は、古い求人票を取り込むときに必ず起きます。 何年も前の求人票には、今の社内の表記基準では使わない条件の書き方が残っていることがあります。取り込みの段で印を付け、まとめの対象から外します。

指示内容を固定する

取り込み時（候補者からの質問の仕分け）：

あなたは人材紹介会社で、求人に寄せられた候補者からの質問を整理する担当です。
質問の文に書かれたことだけを根拠に、どの条件についての質問かを仕分けてください。

【条件の種類】
- remote：リモートワーク、出社の頻度
- transfer：転勤、勤務地の変更
- overtime：残業の時間、残業代、固定残業代
- probation：試用期間と、その間の条件
- evaluation：評価、昇給、賞与
- job_scope：業務の範囲、配置転換、担当の変更
- other：上のどれでもないもの

【厳守事項】
- 1つの質問に複数の条件が含まれるときは、すべての種類を返してください。
- 質問の文に書かれていない意図を推測しないでください。
- 候補者の氏名や経歴に触れないでください。

検索時（まとめ）：

あなたは人材紹介会社の法人担当の調べものを助ける係です。
渡された検索結果と集計だけを根拠に、過去の似た求人を整理してください。

【今回のヒアリングの記録（企業名は伏せてあります）】{hearing}
【過去の似た求人】検索結果として渡します
【似た求人で後から書き足された項目の件数】{amended_counts}
【似た求人で質問の多かった条件の件数】{question_counts}
【明示が必要な事項のうち、ヒアリングの記録に無いもの】{missing_required}

【書くこと】
1. 仕事内容の書き分け方の違い（求人番号と作成日を添える）
2. 書き足しの多かった項目と、質問の多かった条件（件数を添える）
3. ヒアリングで確かめる項目の一覧（明示が必要な事項を先に）

【厳守事項】
- 求人票の文を書かないでください。言い回しの例も作らないでください。
- 今回の企業の条件を推測しないでください。
- 過去の求人の条件の値（時間、日数、金額）を、今回の参考として書かないでください。
- 推薦や応募の件数から、求人票の良し悪しを評価しないでください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の求人票を1つの search_result にし、source に求人番号、title に職種名と作成日、content に仕事内容と必須の経験を項目ごとに別のテキストブロックで入れます。 公式の説明では、引用は content のテキストブロックを単位に付くので、まとめのどの文がどの求人のどの項目から来たかが分かります。この仕組みは Amazon Bedrock でも使えます。

出力形式を固定する

検索の要求は、次のように組みます。

{
  "query": {
    "bool": {
      "must": {
        "more_like_this": {
          "fields": ["job_text"],
          "like": "{hearing_text}",
          "min_term_freq": 1,
          "max_query_terms": 30,
          "minimum_should_match": "30%"
        }
      },
      "filter": [ { "term": { "job_family": "customer_success" } } ]
    }
  },
  "size": 5,
  "aggs": {
    "top_similar": {
      "sampler": { "shard_size": 50 },
      "aggs": {
        "amended": { "terms": { "field": "amended_fields" } },
        "questions": { "terms": { "field": "question_topics" } }
      }
    }
  }
}

min_term_freq を1にするのは、ヒアリングの記録が短いためです。 公式のドキュメントでは、既定は2で、入力の中でこれより少なく出てくる語は無視されます。短いメモでは、大事な語ほど1回しか出てきません。 minimum_should_match の既定は30%です。

size は5で、まとめに渡すのは上位5件です。 一方、集計は sampler で各シャードの上位50件に限ります。書き方の参考は少数で足り、傾向を数えるにはある程度の件数が要るので、2つを分けます。

まとめは、次の形のJSONで受け取ります。

{
  "hearing_id": "H-2026-10-0233",
  "references": [
    { "job_id": "J-2024-08812", "created_at": "2024-09-02",
      "point": "業務を導入期・定着期・拡大期に分けて書いている",
      "pre_2024_04": false }
  ],
  "often_amended": [ { "field": "remote", "count": 21, "examples": ["J-2025-01177"] } ],
  "often_asked": [ { "topic": "overtime", "count": 17, "examples": ["J-2024-10421"] } ],
  "to_confirm": [ { "item": "就業の場所の変更の範囲", "reason": "required_missing" } ]
}

1つ目の理由は、to_confirm を、規則の結果と傾向の結果で分けられることです。 reason が required_missing なら明示が必要な事項の欠け、often_amended なら過去の傾向です。前者は必ず確かめ、後者は担当者の判断で確かめます。

2つ目は、pre_2024_04 で古い求人票を見分けられることです。 令和6年4月より前の求人票は、業務の変更の範囲などが書かれていないのが普通です。参考にするのは書き分け方で、明示の事項の書き方は参考にしません。

システムへ連携する

まとめは表示するだけで、案件管理の仕組みの求人票の項目には書き込みません。 求人票の画面に自動で値が入ると、確かめていない条件がそのまま出る経路ができます。

上位を企業ごとに1件までにする並べ直しは、Lambda の側で行います。 検索では上位20件ほどを取り、同じ client_id の2件目以降を落としてから5件に絞ります。集計のほうは並べ直さず、sampler の範囲のまま数えます。 同じ企業の求人で何度も同じ項目が書き足されていれば、それも傾向の1つだからです。

人が確認する

1. 明示が必要な事項の欠けを先に見る … required_missing の項目は、ヒアリングのあとで企業に必ず確かめます
2. 傾向の項目を選ぶ … 書き足しや質問の多かった条件のうち、今回の企業で確かめるものを担当者が選びます
3. 参考の求人を開く … 引用を辿り、書き分け方を確かめます。条件の値は参考にしません
4. 求人票を書いて社内の確認に回す … 明示の事項が法令に合っているかは、社内の担当が確認します

1件あたり8分を目安にします。 まとめを読み、参考の求人を1〜2件開き、企業への確認の項目を決めるまでの時間です。企業に確かめる時間と、求人票を書く時間は含めていません。

2番目で全部を確かめようとしないでください。 書き足しの多い条件を毎回すべて企業に聞くと、ヒアリングのあとの質問が長くなり、企業の採用担当の負担になります。 件数の多い上位の2〜3項目と、明示が必要な事項の欠けに絞ります。

例外に対処する

2行目は、取引の多い企業で必ず起きます。 同じ企業の求人は語が似るので、上位を独占します。参考にしたいのは書き方の幅で、1社の書き方ではありません。

記録を残す

• 取り込んだ求人票の版と、取り出した書き足しの項目
• Claude が返した質問の仕分けと、担当者が直した仕分け
• 検索ごとのヒアリングの記録（伏せたあと）、上位の求人、集計の結果
• Claude に渡した検索結果と、返ってきたまとめと引用
• 担当者が企業に確かめた項目と、確かめた結果
• 求人を出したあとの書き足しの件数

最後の行が、この構成の効き目を測る材料です。 まとめを見て書いた求人で、出したあとの書き足しが減っているかを、職種ごとに半年単位で見ます。