同業他社の求人と処遇の条件を毎月巡回して、自社の募集条件の見直し材料にする

処理の起点を決める

毎月第1営業日を起点にします。月次の定点観測として動かします。

週次にする必要はありません。求人の条件は、そこまで速く変わりません。 月1回で十分に変化を捉えられます。逆に、四半期に1回では遅すぎます。採用の繁忙期に入ってから気づくことになります。

もう1つの起点として、特定の職種で応募が一定期間ゼロだったときに、その職種だけを臨時に観測する形が考えられます。定例の観測と別に走らせると、問題が起きたときの反応が速くなります。

入力データを集める

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

検索条件の設計が、この構成の成否を分けます。 「設計エンジニア」だけで検索すると、業種も規模も違う求人が大量に出ます。次の要素を組み合わせます。

対象ドメインは必ず絞ってください。 allowed_domains を指定せずに検索すると、まとめサイトや古い転載記事が混ざります。主要な求人サイト3〜5つと、採用競合30社の採用ページのドメインに限定するのが実用的です。

自社の応募状況を一緒に見ることが重要です。 「他社より給与が低い」という指摘は、応募が集まっている職種では問題になりません。応募数が少ない職種で、かつ条件差が大きいものが、見直しの候補です。

社内の給与テーブルは、AIへ渡しません。 これは人が比較のときに参照するものです。市場の水準と自社の制度の整合をどう取るかは、人事制度の問題であって、この構成の範囲外です。

AIへ渡す前に整形する

1. 職種の対応づけ … 自社の職種名と、市場で使われている呼び方を対応づけます。「生産技術」が他社では「製造技術」「プロセスエンジニア」と呼ばれていることがあります
2. 検索回数の上限設定 … 1職種あたりの max_uses を決めます。5〜8回程度が目安です。 無制限にすると費用が読めません
3. 取得量の上限設定 … max_content_tokens を設定します。求人ページ1本は数千トークン程度なので、1職種あたり数万トークンに収まるよう調整します
4. 除外対象の指定 … 派遣、業務委託、アルバイトなど、自社の募集形態と違うものを除外する条件を検索語に含めます
5. 自社求人の除外 … 自社の求人が検索結果に出ることがあります。自社のドメインを blocked_domains に入れるか、抽出後に除きます

AIに処理させる

給与の換算には注意が要ります。 「月給35万円〜（賞与年2回）」から年収を出すには、賞与の月数を仮定する必要があります。仮定を置いた場合は、その仮定を必ず出力に含めさせてください。 賞与の記載がない求人は、換算せず「月給のみ記載」として残します。

推薦や提案はさせません。 「給与レンジを50万円引き上げるべきです」とは書かせません。条件の差を示すところまでです。 引き上げの可否は、社内の給与制度と、その職種の採用の優先度で決まります。

指示内容を固定する

あなたは人事部の採用担当を支援する調査担当です。
下の職種について、公開されている他社の求人を調べ、条件を整理してください。

【調査の範囲】
- 下の「対象ドメイン」に含まれるページのみを対象にしてください。
- 検索は最大 {max_searches} 回までにしてください。
- 派遣、業務委託、アルバイト・パートの求人は除外してください。
- 自社（{own_company}）の求人は除外してください。

【厳守事項】
- 取得したページに書かれている内容だけを根拠にしてください。
  一般的な相場観や、知識にある企業情報で補わないでください。
- 各社の条件には、必ず出典のURLを付けてください。出典のない情報を載せないでください。
- 給与は、記載されている表記をそのまま salary_raw に写したうえで、
  年収レンジへの換算を salary_annual_min / max に入れてください。
  換算に仮定を置いた場合（賞与の月数など）は、必ず assumption に書いてください。
  **賞与の記載がない場合、賞与を含めた年収に換算しないでください。**
- 給与の記載がない求人は、salary_annual_min / max を null にしてください。
  推測で数値を入れないでください。
- 求人の掲載日または最終更新日が分かる場合、posted_on に入れてください。
  古い求人（1年以上前）は old_posting を true にしてください。
- その求人が調査対象の職種・業界・地域に合っているかを relevance で示してください。
  合っていないものは除外せず、relevance を low にして残してください。
  **判断の材料として、除外の理由が分かるほうが役に立ちます。**
- 条件の良し悪しを評価しないでください。「魅力的な条件です」と書かないでください。
- 自社が条件をどう変えるべきかの提案を書かないでください。判断は人事部が行います。

【調査する職種】
{job_context}

【検索条件（職種名の言い換え・地域・経験の目安・除外語）】
{search_criteria}

【対象ドメイン】
{allowed_domains}

【自社の現在の募集条件】
{own_posting}

【前回の観測結果】
{previous_observation}

「賞与の記載がない場合、賞与を含めた年収に換算しない」の1行が重要です。 これを書かないと、AIは「月給35万円」を勝手に「年収約500万円（賞与4か月と仮定）」に換算します。その数字で自社と比較すれば、判断を誤ります。

「出典のない情報を載せない」も必須です。 web search ツールは引用が常に有効で、web_search_result_location として URL、タイトル、引用された文（最大150文字）が返ります。web fetch ツールでは引用が既定で無効なので、有効にしたうえで使います。出典が付いていない記述は、モデルが知識から書いた可能性があるということです。

出力形式を固定する

{
  "job_id": "",
  "job_title_own": "",
  "observed_on": "",
  "postings": [
    {
      "company_name": "",
      "job_title": "",
      "url": "",
      "posted_on": "",
      "old_posting": false,
      "salary_raw": "",
      "salary_annual_min": 0,
      "salary_annual_max": 0,
      "assumption": "",
      "location": "",
      "work_style": "",
      "employment_type": "",
      "required_skills": [],
      "preferred_skills": [],
      "selection_process": "",
      "relevance": "high | medium | low",
      "relevance_reason": ""
    }
  ],
  "comparison": {
    "salary_gap_min": 0,
    "salary_gap_max": 0,
    "salary_sample_count": 0,
    "location_note": "",
    "work_style_note": "",
    "requirement_note": ""
  },
  "changes_from_previous": [],
  "data_quality": {
    "postings_found": 0,
    "postings_with_salary": 0,
    "postings_relevant": 0
  },
  "needs_review": []
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format に json_schema を渡すことで、応答をスキーマに沿った形に制約できます。

salary_sample_count と data_quality が重要です。給与が記載されている求人が3件しかないなら、その比較は判断の根拠になりません。 件数を必ず併記してください。「他社より低い」という指摘が2件の比較に基づいているなら、それは指摘として弱すぎます。

relevance が low のものも残す設計にしている点に注意してください。除外してしまうと、なぜ件数が少ないのかが分からなくなります。 「20件見つかったが、業界が違うものが15件だった」と分かれば、検索条件を直す手がかりになります。

システムへ連携する

職種別の比較表をスプレッドシートに作ります。2層にします。

職種サマリー（25行）：

求人明細：

職種サマリーから展開して見る形にします。企業ごとの条件と出典URLが並びます。URLは必ずクリックできる形にしてください。 担当者が元のページを確認できることが、この構成では前提になります。

求人原稿への自動反映はしません。 条件の変更は、社内の給与制度との整合を確認したうえで、人事と現場が決めます。

人が確認する

全件、担当者が出典を確かめます。

理由は、公開情報の取得には誤りが混ざるためです。古い求人が残っている、別の職種の求人を拾っている、給与の換算が実態と違う。こうした誤りは、元のページを見れば分かりますが、表だけを見ていても分かりません。

確認の深さは分けます。

• 有効サンプルが3件未満の職種 … 比較としては使わない。検索条件を見直す
• 給与差が大きい職種 … 出典を1件ずつ開いて確かめる
• assumption に仮定が書かれている求人 … 換算の妥当性を確かめる
• old_posting が true の求人 … 集計から外すかを判断する
• 応募が集まっている職種 … 差があっても優先度は低い

確認を速くするための設計が効きます。

• 有効サンプル数が少ない職種を別に集める
• 給与差が大きい順に並べ、応募状況と並べて表示する
• assumption のある行に色を付ける
• 前回と同じURLの求人には「継続掲載」と印を付ける（新しい情報かどうかが分かる）
• relevance が low のものを別タブに置く（検索条件を直す材料）

例外に対処する

記録を残す

この記録は、条件を見直す判断の根拠になります。

• 観測日ごとの求人一覧（企業名、条件、出典URL、取得日時）
• 給与の換算に置いた仮定
• 自社の条件との差と、有効サンプル数
• 人事の判断（見直し提案／様子見／対象外）と、その理由
• 条件を変更した場合、その前後と、変更後の応募数の推移
• 検索条件の変更履歴

「条件を変更した後の応募数の推移」が、この取り組みの答え合わせになります。 給与レンジを上げて応募が増えたのか、変わらなかったのか。これを記録していないと、次の判断が感覚に戻ります。

出典URLは必ず残してください。求人は掲載が終われば消えます。 半年後に「この数字はどこから来たのか」と聞かれたとき、URLだけでは足りないことがあります。引用された文（cited_text）も一緒に残すと確実です。