求人票と労働条件通知書の記載が食い違っていないかを、内定を出す前に点検する

処理の起点を決める

担当者が労働条件通知書の案を作り終えて、3つの書類を貼り付けたときが起点です。自動実行はありません。

交付の前に置いてください。 交付した後で食い違いが見つかると、訂正の通知を出し直すことになります。内定通知と同時に交付する運用なら、内定を出す判断の前に通します。

採用部門ではなく人事が通す運用にしてください。 求人票を書いた側が自分で点検すると、自分の書いた内容を正として見てしまいます。第三者の目が入ることに意味があります。

もう1つの起点として、求人票を出稿する前にも通す形が考えられます。媒体ごとの記載がそろっているかを、出稿前に確かめられます。ただし、この段階では通知書がまだないため、点検できる範囲は媒体間の整合だけです。

入力データを集める

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

求人票： 媒体の管理画面からテキストをコピーします。媒体の入力欄ごとに項目が分かれているため、欄の名前も一緒にコピーしてください。 「仕事内容」「勤務地」「給与」といった欄の名前があると、通知書の項目との対応づけが正確になります。

面接での提示条件の記録： ここが、多くの企業で空です。面接で口頭で伝えた条件が、どこにも残っていません。 Beforeの（f）の原因がここにあります。

この構成を作るなら、面接の記録に条件の欄を1つ足すところから始めてください。 「面接で個別に伝えた条件（勤務地・シフト・賃金など）」という自由記入欄を1つ設けるだけです。空欄のままの面接も多いはずですが、書かれていれば点検できます。

明示事項のチェックリスト： 労働条件通知書に記載が必要な項目を一覧にします。2024年4月からは、すべての労働者に対して「従事すべき業務の変更の範囲」と「就業の場所の変更の範囲」が、有期労働契約では「更新する場合の基準に関する事項」が加わっています。

「変更の範囲」は、雇入れ直後だけでなく、将来の配置転換などの見込みも含めた、契約期間中での変更の範囲を指します。求人票の自由記入欄に書かれることが多いため、通知書の様式の欄と対応づけるのに注意が要ります。

明示事項のチェックリストは、次の形で持ってください。

「一致とみなす条件」の列が、この構成の精度を決めます。 文字列が同じことを求めると、ほとんどの項目が食い違いになります。「範囲内に収まっていればよい」「下限が同じならよい」といった条件を、項目ごとに決めてください。

「ずれの典型」の列も効きます。 過去に起きた食い違いを、項目ごとに1〜2例書いておきます。これがあると、判定の基準が担当者の頭の外に出ます。

表記の対応表： 「東京本社」と「東京都◯◯区◯◯1-2-3」は同じ場所ですが、文字列としては一致しません。これを食い違いとして指摘すると、指摘が多すぎて読まれなくなります。 拠点名と住所の対応表を作っておいてください。

対応表は次の形です。

「社保完備」のような略した表現が、実務ではいちばん厄介です。 求人票では使われますが、通知書では加入する保険を個別に書きます。対応表に入れておかないと、毎回「記載が違う」と指摘されます。

対応表は、運用しながら育ててください。 最初から完全なものを作ろうとすると始まりません。誤指摘が出るたびに1行足す形で十分です。 3か月も運用すれば、誤指摘はほとんど出なくなります。

AIへ渡す前に整形する

1. 媒体ごとの欄の名前の統一 … 「仕事内容」「業務内容」「職務内容」を1つの項目へ対応づけます
2. 金額の正規化 … 「月給25万円〜」「250,000円〜」「月額25万円以上」をそろえます。下限と上限を分けて保持してください
3. 時間の正規化 … 「9:00〜18:00」「午前9時から午後6時」「9時〜18時（休憩60分）」をそろえます
4. 就業規則の参照の展開 … 通知書が「詳細は就業規則第◯条による」と書いている項目は、その条文を一緒に渡します。展開しないと、記載なしと判定されます
5. 個人情報の扱いの確認 … 応募者の氏名・住所・生年月日は、この点検には不要です。伏せてから渡す運用を検討してください
6. 更新案件の前回通知書の追加 … 契約更新の案件では、前回の通知書も一緒に渡します。前回からの変更点を示せると、更新の説明にそのまま使えます
7. 雇用形態の判別 … 正社員／有期／派遣／請負のどれかを先に決めます。形態によって必要な明示事項が変わるため、ここを間違えると点検の範囲が変わります

2の金額の正規化で、下限と上限を分けて保持することが重要です。 求人票の「月給25万円〜35万円」と通知書の「月給280,000円」は、矛盾ではありません。範囲の中に収まっています。 下限と上限を別に持っていないと、この判定ができません。

4の就業規則の展開を忘れると、指摘が大量に出ます。 通知書は「休日は就業規則第◯条による」と書くことが多くあります。条文を渡さないと、休日の記載がないと判定されます。 参照されている条文を、あらかじめテキストで用意しておいてください。

AIに処理させる

「どちらが正しいか」の判定はさせません。 出せるのは「違いがある」までです。

法令に適合しているかの判断もさせません。 「この記載では明示義務を満たしていません」といった判断は、条文と実態を照らして人が行うものです。この構成は、3つの書類の間の整合だけを見ます。

賃金の妥当性、条件の良し悪しも書かせません。 「この賃金は相場より低い」といった記述は、この業務の範囲外です。

「範囲の広狭の指摘」を独立させている理由があります。 求人票が「首都圏の当社事業所」で、通知書が「東京本社」の場合、両者は矛盾していません。しかし、変更の範囲の明示が求められている以上、狭いほうだけを通知することが正しいとは限りません。 配属の予定が東京本社だけなら通知書が正しく、将来的に他拠点への異動がありうるなら求人票のほうが実態に近いことになります。この判断は書類からはできません。 だからこそ、矛盾とは別の区分にして、必ず人が見る形にします。

「表現の違いの分離」も、運用を続けるための設計です。 表記の揺れをすべて食い違いとして出すと、1件あたり10件の指摘が出ます。そのうち9件が「直さなくてよい」ものだと、担当者は一覧を読まなくなります。 対応表に載っている表現は、最初から別枠に落としてください。

指示内容を固定する

あなたは人事の労務担当を支援する担当者です。
下の3つの書類を項目ごとに突き合わせ、食い違いと記載漏れを指摘してください。

【点検する項目】
下の「明示事項のチェックリスト」にある項目だけを点検してください。
リストにない項目は対象外です。

【厳守事項】
- 3つの書類に書かれている内容だけを使ってください。
  書かれていない内容を、一般的な労働条件や就業規則の定めで補わないでください。
- 各項目について、3つの書類それぞれの記載を**原文のまま**抜き出してください。
  要約や言い換えをしないでください。記載がない場合は null にしてください。
- 食い違いは、次の3つに分けてください。
  conflict ... 内容が明確に違う（勤務地が別の場所、賃金の額が違う など）
  wording ... 同じ意味と読めるが表現が違う（「東京本社」と「東京都◯◯区」など）
  scope ... 範囲の広さが違う（求人票は「首都圏の事業所」、通知書は「東京本社」など）
  **迷う場合は conflict ではなく needs_check に入れてください。**
- 記載漏れは、チェックリストの項目のうち通知書に記載がないものだけを挙げてください。
  求人票にないことは漏れとしないでください。求人票と通知書では必要な項目が違います。
- どちらが正しいかを書かないでください。修正案の文章も書かないでください。
- 法令に適合しているかどうかを書かないでください。
- 賃金や条件の水準を評価しないでください。
- 指摘がない項目は「一致」とだけ書いてください。無理に指摘を作らないでください。

【求人票（媒体ごと・欄の名前つき）】
{job_postings}

【面接での提示条件の記録】
{interview_notes}

【労働条件通知書の案】
{notice_draft}

【明示事項のチェックリスト】
{checklist}

【表記の対応表（同じ意味の別の言い方）】
{synonym_table}

【通知書が参照している就業規則の条文】
{work_rules_excerpt}

「迷う場合は conflict ではなく needs_check」の1行が重要です。 食い違いだと断定されると、担当者は必ず確認に回ります。表記の揺れを conflict として大量に出すと、確認の手間が増えるだけです。

「求人票にないことは漏れとしない」も必要です。 求人票と労働条件通知書では、記載が必要な項目が違います。求人票にない項目を「漏れ」として挙げると、指摘が実態と合いません。

「原文のまま抜き出す」の指示も効きます。 「勤務地：東京」と要約されると、元の記載が「東京都内の当社事業所（変更の範囲：首都圏の当社事業所）」だったのか分かりません。変更の範囲は、原文を見ないと判断できません。

出力形式を固定する

チャット画面で使うなら、表形式で受け取れば十分です。API連携まで進める場合は、JSON Schema を指定して出力を固定します。OpenAI API では text: { format: { type: "json_schema", "strict": true, "schema": … } } の形で指定し、strict: true にすると、供給したJSONスキーマに必ず沿った応答が返ります。

{
  "case_id": "",
  "items": [
    {
      "item_name": "",
      "job_posting": [
        { "media": "", "field_label": "", "text": "" }
      ],
      "interview_note": "",
      "notice_draft": "",
      "status": "一致 | conflict | wording | scope | 通知書に記載なし | needs_check",
      "detail": ""
    }
  ],
  "missing_in_notice": [],
  "needs_check": [
    { "item_name": "", "why": "" }
  ],
  "no_findings": []
}

job_posting を配列にしている理由があります。 媒体が4つあれば、同じ項目に4つの記載があります。媒体間で食い違っていることもあるため、1つにまとめず並べて持ちます。

status を6段階にしている点に注意してください。

scope を独立させていることに意味があります。 求人票が「首都圏の当社事業所」で通知書が「東京本社」の場合、これは矛盾ではなく範囲の狭まりです。ただし、変更の範囲の明示が求められている以上、狭いまま通知するのが正しいとは限りません。 必ず人が確認すべき区分です。

システムへ連携する

連携先はありません。 指摘を見ながら、労務管理システムの通知書と、媒体の求人票を手で直します。

強いて仕組みを足すなら、指摘の一覧をスプレッドシートに貼り付け、対応の列を付ける程度です。これを案件ごとに残しておくと、どの項目でずれやすいかが見えます。

求人票の訂正を忘れないでください。 通知書だけ直して媒体を放置すると、次の応募者に同じ食い違いが起きます。一覧に「求人票の訂正」の列を置き、対応したかを記録してください。

交付の記録には、点検を通した証跡を添えると後から役に立ちます。 「聞いていた条件と違う」という申し出があったとき、3つの書類がそろっていたことを示せます。

人が確認する

全件、担当者が1件ずつ確かめます。一括で修正しません。

理由は、どちらが正しいかが書類からは決まらないためです。求人票の「東京都内の事業所」が正なのか、通知書の「東京本社」が正なのかは、面接でのやり取りと配属の予定で決まります。

確認の順序は次のとおりです。

1. conflict … 内容が明確に違う。必ず確認し、どちらかに直す
2. 通知書に記載なし … 明示事項の漏れ。追記する
3. scope … 範囲の広狭。変更の範囲で起きやすい。配属の予定と照らす
4. needs_check … 人が読んで判断する
5. wording … 表記の対応表に追加する。通知書を直す必要は多くの場合ない

5つ目を毎回直そうとしないでください。 「東京本社」と「東京都◯◯区」を毎回そろえる作業に意味はありません。対応表に登録すれば、次回から指摘されなくなります。

例外に対処する

記録を残す

チャット画面で使う場合、記録は自動では残りません。次の3つだけ、残すことをおすすめします。

• 指摘の一覧（conflict と 通知書に記載なし の内容）と、対応の結果
• 求人票を訂正したかどうか
• 表記の対応表への追加履歴

1つ目を案件ごとに残すと、どの項目でずれやすいかが見えます。 「変更の範囲の記載漏れが月に10件ある」と分かれば、求人票の入力欄にその項目を必須で設けるという対策が取れます。AIで見つけ続けるより、そちらのほうが根本的です。

書類そのものを外部サービスの履歴に残したくない場合は、履歴を残さない設定で使ってください。 応募者の個人情報と賃金額が含まれるため、組織の方針に従います。