求人媒体から届く応募通知を読み取って、応募者台帳に一本化する

処理の起点を決める

採用専用メールボックスへの新着メールを起点にします。Make のシナリオは、メールの受信を監視して後続の処理を走らせる形になります。

ここで重要なのは、採用専用のメールアドレスを1つ用意し、すべての媒体の通知先をそこに向けることです。個人のメールボックスを監視対象にすると、無関係なメールが大量に流れ込み、フィルタの条件が複雑になります。

自社採用ページのフォームからの応募も、同じアドレスへ通知が飛ぶようにしておきます。ハローワークのように通知メールが出ない経路は、担当者が受け取った紹介状をこのアドレスへ転送する運用にします。

入力データを集める

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

メール本文： ワークフローツールのメール監視で本文と添付を取得します。HTMLメールの場合はタグが混ざるため、テキスト部分を取り出してからAIへ渡します。

添付ファイル： 履歴書がPDFで添付される媒体があります。Claude API はPDFをそのまま入力として受け取れます。1リクエストあたりの上限は、リクエスト全体で32MB、ページ数は600ページ（コンテキストウィンドウが100万トークン未満の場合は100ページ）です。応募1件あたりのPDFは数ページなので、この上限に当たることはまずありません。

管理画面にしか情報がない媒体： 通知メールに「管理画面で確認してください」としか書かれていない媒体があります。この場合、自動化できるのは「応募があったこと」と「受信日時」だけです。 無理にログインを自動化せず、台帳には「詳細は管理画面」と記録して、担当者が開く運用にします。媒体側にAPIやCSV出力があるなら、そちらを先に確認してください。

AIへ渡す前に整形する

1. 応募通知の判別 … 送信元アドレスと件名のパターンで、応募通知だけを通します。媒体からのお知らせメール、請求書、営業メールが同じアドレスに届きます
2. 署名・定型文の除去 … メール末尾の媒体の広告文や免責事項を落とします。AIへ渡すテキストが短くなり、抽出の精度も上がります
3. 文字化けの補正 … 一部の媒体は環境依存文字を使います。氏名の旧字体（髙、﨑など）が化けていないかを確認します
4. 媒体の特定 … 送信元アドレスから媒体名を決め、後段の抽出で「この媒体はこの並び」というヒントとして渡します

AIに処理させる

合否の判断や、応募者の適性の評価はさせません。 ここでAIにさせているのは、書いてあることを決まった形に直す作業だけです。書類選考の所見づくりは別の業務なので、混ぜないでください。

指示内容を固定する

あなたは採用担当の事務処理を支援する担当者です。
求人媒体から届いた応募通知メールの本文と添付書類から、応募者台帳に
入れる項目を抜き出してください。

【厳守事項】
- メールと添付に書かれていないことは書かないでください。
  書かれていない項目は null にし、reason に「記載なし」と書いてください。
- 氏名は本文の表記をそのまま使ってください。旧字体を新字体に直さないでください。
- 電話番号はハイフンを除いた数字だけにしてください。先頭の0を落とさないでください。
- 応募拠点は、下の店舗マスタにある店舗コードからのみ選んでください。
  マスタにない拠点名が書かれている場合は null にし、reason に元の表記を書いてください。
- 応募職種も、下の職種マスタのコードからのみ選んでください。
- 応募者の適性、合否、人物評価は書かないでください。
- 経歴の要約は、書かれている事実だけを3行以内でまとめてください。
  推測や補足を足さないでください。

【重複の判定】
- 下の「既存の応募者（氏名または電話番号が近いもの）」と照らして、
  同一人物の可能性を high / medium / low で返してください。
- 電話番号が完全一致するなら high です。
- 氏名だけが一致し、電話番号が違う場合は medium にしてください。同姓同名があります。

【媒体】
{media_name}

【メール本文】
{mail_body}

【店舗マスタ】
{store_master}

【職種マスタ】
{job_master}

【既存の応募者（氏名または電話番号が近いもの・上位10件）】
{existing_candidates}

「マスタにない拠点名は null にする」の1行が重要です。 ここを書かないと、AIは「◯◯駅前店」を近そうな店舗に勝手に寄せます。応募先の店舗を間違えると、別の店長に通知が飛び、応募者は連絡を受けられません。

出力形式を固定する

{
  "applicant_name": "",
  "applicant_kana": "",
  "phone": "",
  "email": "",
  "birth_date": "",
  "job_code": "",
  "store_code": "",
  "preferred_hours": "",
  "career_summary": "",
  "media_name": "",
  "applied_at": "",
  "duplicate_check": "high | medium | low",
  "duplicate_of": "",
  "needs_review": [],
  "reason": ""
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format に json_schema を渡すことで、応答をスキーマに沿った形に制約できます。項目が欠けたり、余計な説明文が前後に付いたりしなくなるため、後段でそのまま台帳へ書き込めます。

電話番号を数値型にしないでください。 先頭の0が落ちます。文字列で受け取ります。

システムへ連携する

抽出結果を応募者台帳へ1行追記します。台帳はスプレッドシートを想定しています。列は次の構成です。

店舗への通知は、店舗マスタの店長アカウントへチャットで送ります。本文は氏名・職種・希望時間帯・経歴要約の4項目に絞ります。個人情報を含むため、通知先は店長個人のチャットにし、店舗の共有チャネルへは流さないでください。

一次連絡の下書きは、台帳の行から定型文に差し込んで作ります。この部分は生成AIを通さなくても実装できます。

人が確認する

全件の目視は不要ですが、次の3つは必ず人が見ます。

1. duplicate_check が high または medium の行 … 二重連絡を防ぐため、同一人物かを人が確定します
2. needs_review に項目が入っている行 … 拠点や職種がマスタに寄せられなかった応募です
3. 店舗への通知が返ってきた行 … 店長から「この職種は募集していない」と返ってくることがあります

それ以外の行は、台帳に入った状態から一次連絡へ進んで構いません。ここを全件確認にすると、削減効果がほとんど残りません。 抽出の正しさは、後述する精度の実測で担保します。

例外に対処する

記録を残す

応募者の個人情報を扱うため、保存する場所と期間をあらかじめ決めてください。

• 応募通知メールの原本（採用専用メールボックス内）
• AIの抽出結果（生のJSON）
• 人が修正した項目と、修正前後の値
• 店舗への通知の送信記録
• 台帳の行ごとの作成日時・更新日時

修正前後の値は、抽出の精度の実測値になります。「氏名はそのまま通るが、拠点は2割修正されている」と分かれば、店舗マスタの表記ゆれを増やすという次の手が決まります。

不採用となった応募者の情報をいつ削除するかも、この段階で決めておきます。台帳が1本になるということは、消すときも1か所で済むということです。