複数の求人媒体と自社採用サイトの掲載状況をエージェントが毎日見回り、掲載期限切れ・掲載停止・条件の更新漏れ・応募の止まった求人を拾って、採用担当へ対応の案を出す

処理の起点を決める

毎営業日の朝9時30分に、Schedule Trigger で動かします。 媒体のCSVを書き出してフォルダに置くのが9時から9時20分の間という前提で、その後に動かします。Schedule Trigger は、ワークフローのタイムゾーンが設定されていればそれを、なければ n8n のインスタンスのタイムゾーンを使うとされ、セルフホストの既定は America/New York です。 ワークフローに Asia/Tokyo を設定しないと、日本の夜中に動きます。

Schedule Trigger を使うワークフローは、保存して公開（有効化）しないと動かないとされています。作ってテストしただけで止まっている、という形に注意します。

CSVが置かれていないときは、そのまま動かします。 置かれていない媒体は「本日の一覧なし」と通知の先頭に出し、前日の一覧で判定しません。 古い一覧で判定すると、昨日止めた求人を今日も掲載中と出します。

入力データを集める

質を決めるのは、媒体の一覧に自社の求人番号があるかです。 媒体の求人番号だけでは、台帳と突き合わせられません。原稿を入稿するときに、自社の求人番号を媒体の「社内管理用の番号」の欄か原稿の決まった場所に入れる決まりを、最初に作ります。 入っていない求人は、件名と勤務地で突き合わせることになり、間違いが出ます。

台帳の変更履歴は、原因の切り分けに使います。 「台帳では充足、媒体では掲載中」のとき、充足にしたのが今朝なのか2週間前なのかで、対応の急ぎ方がまったく違います。

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

採用サイトのページは、台帳にあるURLだけを取りに行きます。 サイト全体を巡回しません。300件を毎朝取りに行くので、HTTP Request ノードの Batching のオプションで、まとめて送る件数と間隔を決め、自社のサイトに負荷をかけないようにします。

求人ページの状態は3通りで記録します。 200で求人の項目が取れた、200だが「募集は終了しました」の表示になっている、404・410になっている。Google の求人情報の資料では、求人の募集が終わったときは、validThrough を過去の日付にする、ページを削除して404か410を返す、構造化データを外す、のいずれかとされています。 自社サイトがどの方法を取っているかに合わせて、「掲載終了」の判定を作ります。

AIへ渡す前に整形する

1. 媒体のCSVの列をそろえる … 媒体ごとに列名と日付の書き方が違います。媒体ごとの対応表を作り、共通の列（媒体、媒体の求人番号、自社の求人番号、状態、期限、時給、勤務地）に直します
2. 時給と勤務地を比べられる形にする … 「1,500円」「1500円〜」「時給1500円以上」を数値と記号に分けます。範囲で書かれているものは下限と上限を分けます
3. 求人番号で突き合わせる … 台帳1行に対し、媒体ごと・サイトの掲載を横に並べます
4. 規則で候補を出す … 下の表の6種類
5. 前日も出した候補に印を付ける … 対応の一覧で「依頼済み」になっているものは、反映待ちとして別に出します

4番目までを規則にしておくのが、この構成の土台です。 拾うべきものを拾ったかどうかを、後から規則で確かめられます。エージェントは、拾ったものの原因と対応を考える役に限ります。

AIに処理させる

させるのは、候補1件ごとに原因を調べ、対応の種類を決め、依頼文と確認の文面の案を作ることです。

check_ledger を持たせているのが、この構成の要です。 「台帳では募集中、媒体では停止」のとき、台帳の更新を拠点が忘れているだけ、ということがよくあります。台帳を正としながら、台帳自体が古い可能性を案として出せるようにします。 決めるのは人です。

指示内容を固定する

AI Agent ノードの System Message に、次のように書きます。

あなたは人材派遣会社の採用グループで、求人の掲載状況を見回る担当です。
規則で拾われた「候補」1件ごとに、道具を使って原因を調べ、対応の種類と
文面の案を返してください。

【前提】
- 求人台帳を正とします。ただし、台帳が古い可能性があるときは
  check_ledger を選んでください。どちらが正しいかを決めないでください。
- 候補の種類は規則で決まっています。種類を変えないでください。

【調べる順番の目安】
1. 過去の対応の記録を引き、同じ求人に依頼済みの対応があるかを確かめる。
   依頼済みで3営業日以内なら wait を選ぶ。
2. 台帳の変更履歴を引き、変更の日時と変更者を確かめる。
3. closed_but_listed と condition_mismatch は、媒体ごとの一覧を引き、
   同じ求人のほかの掲載先も確かめる。
4. 採用サイトの掲載が関わるときは、求人ページを取り直して確かめる。
5. no_applications は、7日・14日の応募数を引く。

【厳守事項】
- 道具で確かめた事実だけを evidence に書いてください。
  確かめていないことを書かないでください。
- 時給・勤務地・勤務時間の数字は、台帳と掲載に書かれた値をそのまま写してください。
  新しい時給や条件を提案しないでください。
- 応募が止まった理由を断定しないでください。possible_causes に候補として
  書き、根拠になった事実を添えてください。
- 媒体への依頼文には、媒体の求人番号、自社の求人番号、直してほしい項目、
  台帳の値を必ず入れてください。
- 道具で確かめられなかったときは、needs_human を true にし、何が確かめられ
  なかったかを書いてください。
- 掲載を止める・直す・台帳を書き換える操作はしないでください。

【出力】指定のJSONの形で返してください。

「新しい時給を提案しない」を明記しないと、応募が止まった求人に「時給を50円上げる」と書きます。 一見よい案に見えますが、時給は派遣先との契約で決まっており、採用グループが決められるものではありません。 案に数字が出ると、それが決まったことのように拠点へ伝わります。

Max Iterations は、道具を呼ぶ回数の上限として使います。 既定は10回です。候補1件に10回を超えて道具を呼ぶなら、調べ方が定まっていないので、needs_human で人に回します。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "candidate_id": "",
  "job_id": "",
  "media": "media_a | media_b | media_c | own_site",
  "candidate_type": "closed_but_listed | condition_mismatch | expiring | not_listed | no_applications | unmatched",
  "action": "stop_listing | fix_listing | extend_or_close | relist | review_posting | check_ledger | wait",
  "priority": "high | medium | low",
  "evidence": [
    { "source": "ledger | ledger_history | media_list | own_site | applications | past_actions", "fact": "" }
  ],
  "ledger_value": { "status": "", "wage": "", "location": "" },
  "listing_value": { "status": "", "wage": "", "location": "", "expires": "" },
  "possible_causes": [""],
  "draft_to_media": "",
  "draft_to_branch": "",
  "needs_human": false,
  "unverified": ""
}

1つ目の理由は、priority を規則で付け直せることです。 エージェントが出した priority をそのまま使わず、action が stop_listing なら必ず high にする、という規則を後段に置きます。法令に関わるものの優先度を、AIの判断に預けないためです。

2つ目は、evidence の source で、何を見て決めたかが分かることです。 採用担当は、ledger_history と past_actions を見ただけで、拠点の更新忘れか、媒体の反映待ちかを判断できます。

3つ目は、ledger_value と listing_value を並べられることです。 通知では、この2つを横に並べて出します。どこがどう違うかが一目で分かれば、媒体の管理画面を開く前に何を直すかが決まります。

システムへ連携する

書き込むのは対応の一覧だけです。 求人台帳にも媒体にもサイトにも書き込みません。求人ページを取り直す道具は、GET だけにします。 エージェントに渡す道具に、POST や PUT を送れるものを含めないでください。

人が確認する

通知を見て操作するのは、すべて採用担当です。

1. stop_listing を最初に片付ける … 媒体の管理画面で掲載を止め、サイトの掲載を外します。止めた日時を一覧に記録します
2. fix_listing の値を、台帳と見比べてから直す … ledger_value をそのまま入れるのではなく、台帳を開いて確かめます
3. check_ledger と extend_or_close を拠点に送る … 文面の案を直して送ります
4. unmatched を見る … 台帳に無い求人が載っているのは、台帳の登録漏れか、媒体での複製です
5. review_posting は週1回まとめて拠点と相談する

2番目を省かないでください。 ledger_value はエージェントが写した値です。写し間違いはまれでも、時給の1桁の違いは、求職者にとって一番重い誤りです。

目標は、1日36分です。 CSVの書き出しと配置に10分、一覧の確認と判断に20分、依頼と確認の送付に6分という見込みです。

例外に対処する

上から2行目は、媒体の管理画面が変わったときに起きます。 列が1つずれるだけで、時給の列に勤務地が入り、全件が condition_mismatch になります。列の対応表と合わないときは判定を止めるほうが、誤った通知を300件出すより安全です。

記録を残す

• その日に読んだ媒体のCSVと、採用サイトの取得結果（ステータスと項目）
• 規則で出した候補の一覧
• エージェントのJSON出力と、呼んだ道具の順番（Return Intermediate Steps を有効にして残す）
• 採用担当の対応の結果 … 止めた・直した・依頼した・拠点に確認した、とその日時
• 締めた求人が掲載中だった日数 … 台帳を充足にした日時から、すべての掲載が止まった日時まで

最後の行が、この構成の物差しです。 厚生労働省の資料が求めているのは「速やかに」の終了です。何日で止められているかを毎月数えれば、媒体ごとの反映の遅さと、社内の連絡の遅さが分かれて見えます。