社員紹介の受付から選考の進捗までを回して、紹介した社員へ状況を返す

処理の起点を決める

起点は3つです。ここを3つに絞ることが、最初の設計です。

チャットやメールを直接のトリガーにしません。 そこから始めると、紹介者が誰かの確定と本人の同意の確認が、自由文の読み取りに依存します。読み取りを間違えると、報奨金の支払先が違う人になります。

口頭の紹介は、代理入力で受けます。 「あとでフォームから出しておいてください」と言うと、半分は出ません。聞いた人が、その場で紹介者の名前を入れて代理で入れます。 代理入力のものは紹介者本人へ確認の1通が飛び、紹介者が「自分が紹介した」と認識している状態が記録に残ります。なおトリガー2は、半自動化の段階では人が段階の列を変えることを起点にします。

入力データを集める

この表でいちばん大事なのは、1行目と4行目が別の場所にあることです。 候補者の情報は1行目に、紹介者へ返すための情報は4行目にあります。文面を作るときは4行目だけを読みます。 同じテーブルに全部を入れると、全列を渡す事故が起きます。

「本人に話をしたか」は3択で聞きます。 「話した」「まだ話していない」「本人から言われて出した」。2番目を選んだ紹介は、候補者へ連絡しません。 社員名簿を引くのは紹介者の確定のためで、同姓の社員も退職済みの名前も、報奨金の支払条件に直結します。

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

受付フォームの回答は、接続したテーブルに自動で入ります。 取得のための処理を書く必要がありません。

求人一覧には、募集の状態の列を必ず持たせてください。 締め切った求人が残っていると、無い募集に候補者を当てることになります。

段階の列は、次の5つだけにします。 received（受け付けた）、contacted（本人と連絡がついた）、in_process（選考が進んでいる）、closed（結果が出た）、joined（入社が決まった）。書類選考、一次面接と細かく分けません。 細かくするほど、紹介者へ返す情報が選考の中身に近づきます。段階の粒度が線引きの一部です。

AIへ渡す前に整形する

1. 必須項目の確認 … 紹介者、候補者の氏名、本人に話をしたか、が空なら受け付けません
2. 受付番号の採番 … REF-2026-0231 のような通し番号を振り、以降は氏名でなくこの番号で扱います
3. 紹介者の確定 … 社員名簿と突き合わせ、社員番号と部署を入れます。無ければ人へ回します
4. 代理入力の確認 … 紹介者本人へ確認の1通を送り、台帳に「未確認」の印を残します
5. 同意の確認 … 「まだ話していない」なら止めます。この状態では候補者へ連絡しません
6. 重複の照合 … 氏名と連絡先の組み合わせで、既に応募している人かを見ます
7. 求人一覧の絞り込み … 募集の状態が「受付中」の行だけを渡します
8. レコードの分離 … 候補者の情報を持つレコードと、紹介者へ返す情報を持つレコードを分けます

8番目を省かないでください。 省くと、あとの工程で「候補者の情報を渡さない」ために毎回列を選ぶことになり、選び忘れは必ず起きます。 2番目の受付番号も同じ道具です。 紹介者は自分が誰を紹介したか知っているので番号で通じ、AIには氏名が渡りません。

AIに処理させる

させることは2つだけです。どちらも判断ではありません。

2行目の入力の欄を見てください。候補者に関する情報が1つもありません。

最後の行が、いちばん見落とされます。 候補を出せと言われたAIは、経験が合わない求人にもそれらしい理由を付けて3つ埋め、採用担当がその3つから選んでしまいます。 合わない求人で選考を受けた候補者は二度とその会社を受けず、紹介した社員にもその話が伝わります。「今は該当する募集がありません」と正しく言えることが、この機能の半分です。

指示内容を固定する

1つ目は、ポジションの突き合わせです。

あなたは採用担当者を補助する立場です。社員紹介で入ってきた候補者の情報と、
現在募集中のポジション一覧を見て、当てはまりそうな求人の候補を挙げてください。

【厳守事項】
- 候補は最大3件です。無理に3件を埋めないでください。
- 当てはまる求人が無い場合は position_matches を空の配列にし、
  no_match_reason に「なぜ当てはまらないか」を1文で書いてください。
  これは正しい回答です。空で返すことを避けようとしないでください。
- 書かれていない経験、年数、スキル、年収、待遇を推測しないでください。
- 合否、適性、採用すべきかを書かないでください。あなたが出すのは
  「どの求人の要件と、書かれている経験が重なるか」だけです。
- reason には、求人の要件のどの記述と、紹介内容のどの記述が重なるかを、
  それぞれ原文から引いて書いてください。言い換えないでください。
- confidence は high / medium / low から選び、経験の記述がほとんど無い
  場合は low にしてください。
- 必須項目の記載が無い場合は、missing_fields にその項目名を入れてください。

【紹介の内容】{referral_text}　【募集中のポジション一覧】{open_positions}

「空で返すことを避けようとしないでください」を明記しないと、必ず3件埋まります。 「最大3件」とだけ書くと、上限の指示として読まれます。

2つ目は、紹介者へ返す文面の下書きです。入力に候補者の情報が無いことを確かめてください。

あなたは人事部の採用担当として、社員紹介をしてくれた社員へ、
選考の状況をお知らせする短い文面の下書きを書きます。

【あなたが受け取る情報】
- 受付番号 / 紹介してくれた社員の名前 / 現在の段階 / 前回お知らせした日からの日数
  （段階は received / contacted / in_process / closed / joined のいずれか）

【厳守事項】
- 候補者の氏名、連絡先、経歴、現職、応募先のポジション名を書かないでください。
  これらはあなたに渡されていません。思い出そうとしないでください。
  候補者を指すときは「ご紹介いただいた方」と受付番号だけを使ってください。
- 選考の評価、面接の様子、見送りの理由、提示した条件を書かないでください。
  段階が closed の場合も、書くのは「結果が出た」ことと、
  改めて人事から連絡する旨だけです。
- 段階から推測して先の見通しを書かないでください。
  「次は面接になりそうです」「順調のようです」と書かないでください。
- 日程、時期、いつまでに結果が出るかを書かないでください。
- 本文は200文字以内、3文以内にしてください。
- 前回から日数が空いている場合は一言触れ、理由を推測しないでください。
- 段階に対応する次の言い回しから外れないでください。
  received：受け付けたこと／contacted：ご本人と連絡がついたこと／
  in_process：選考が進んでいること／closed：結果が出たこと、改めて連絡すること／
  joined：入社が決まったこと、お礼、報奨金について人事から案内すること

【受付番号】{referral_id}　【紹介してくれた社員】{referrer_name}
【段階】{stage}　【前回お知らせした日からの日数】{days_since_last}

「思い出そうとしないでください」を入れている理由があります。 同じやり取りの中に前の呼び出しの内容が残っていると、渡されていないはずの氏名が文面に出ます。文面を作る呼び出しは、突き合わせの呼び出しと完全に別にしてください。

「先の見通しを書かないでください」も必要です。 段階が in_process だとだけ渡しても、文面を書けと言われれば「順調に進んでいるようです」と書きます。順調かどうかは渡されていません。 紹介者はその一文を本人に伝え、落ちたときに二重に気まずくなります。

出力形式を固定する

2つの呼び出しは、それぞれ別のJSONで受け取ります。まず突き合わせのほうです。

{
  "referral_id": "",
  "referrer": { "employee_no": "", "name": "", "department": "", "on_roster": true },
  "consent": { "told_candidate": "yes | no | from_candidate" },
  "entry_route": "form | proxy",
  "position_matches": [
    { "job_id": "", "job_title": "", "reason": "", "confidence": "high | medium | low" }
  ],
  "no_match_reason": "",
  "missing_fields": [],
  "needs_human": true
}

次に、文面のほうです。候補者に関する項目が1つも無いことを確かめてください。

{
  "referral_id": "",
  "referrer_name": "",
  "stage": "received | contacted | in_process | closed | joined",
  "message_subject": "",
  "message_body": ""
}

この2つを1つのJSONにまとめないでください。 まとめた瞬間、文面を作る呼び出しが候補者の項目を持つスキーマを受け取ります。スキーマに項目があれば、AIはそこを埋めようとします。

受け取りは、Claude API の structured outputs を使います。 output_config.format に json_schema 型の指定とスキーマを渡す形で、制約付きデコードによって型と必須項目が保証されるとされています。この構成で効くのは enum です。 enum、const、required、additionalProperties（オブジェクトでは false である必要があります）がサポートされており、stage を5つの値の enum にしておけば、それ以外の段階名が出てきません。 線引きが、スキーマの側で担保されます。

一方で、縛れないものもあります。 minLength / maxLength などの文字列の制約と、minimum / maximum などの数値の制約はサポートされず、配列の minItems は 0 と 1 だけです。つまり「本文は200文字以内」はスキーマでは縛れません。 指示に書いたうえで、送信の前に機械で文字数を数えます。

その検査のついでに、もう1つ照合してください。 受付台帳が持っている候補者の氏名、現職の会社名、連絡先の文字列が message_body に含まれていないかを見て、含まれていたら送らずに人へ回します。 入力に渡していない以上、本来は出るはずがありません。出たときに気づける仕掛けです。

システムへ連携する

採用管理システムにつながないことが、この構成の安全装置です。 自動で登録できると、本人の同意が取れていない紹介が応募者として登録される経路ができます。

報奨金の期限の持ち方には、注意が要ります。 Delay by Zapier で待たせたくなりますが、遅延は最大で1か月（30日）までとされており、入社から6か月後の期日は持てません。期限は台帳の列として持ち、毎日の定時実行で当日到来分を拾います。 遅延中にZapのステップを変更すると続行されず、Zapを止めると処理が実行されないとも記載されています。半年待たせる作りは、そもそも壊れやすいのです。

人が確認する

人が確認するのは3か所です。件数ではなく、場所で決めます。

1. ポジションの決定 … 候補の3つ（または空）を見て決めます。空で返ってきたときに「無理に当てない」と決められるのは人だけです
2. 候補者へ連絡してよいか … 「本人に話をしたか」の回答と、代理入力の確認の返事を見ます
3. 紹介者へ送る文面 … 全件です。1通も自動で送りません

3番目は Request Approval で挟みます。

On timeout を Skip and continue にしないでください。 承認のステップを飛ばして先へ進むと、承認されていない文面が、そのまま次の送信のステップへ流れます。 End run にしておけば送られずに終わり、翌日の定時実行が未送信として拾います。

待ち時間を2日程度にしているのは、承認が滞ることを前提にしているからです。 採用担当は2名で兼務で、承認できない日は必ずあります。 そのときに「勝手に送られる」のではなく「送られずに残る」ほうに倒します。なお、承認を完了できるのは1名だけとされているため、2名を指定しても二重に送られません。

例外に対処する

上から2行目までが、運用で最も多く出ます。 どちらもAIの精度の問題ではなく、制度と受付の決めごとの問題です。 「本人に話していない紹介をどう扱うか」を先に決めていないと、その場の判断で候補者へ連絡してしまいます。

8行目を軽く見ないでください。 選考が1か月動かないことは普通にあり、何も返さないと、紹介者からは「止まっている」のか「忘れられている」のか区別がつきません。 これが第3章の（c）への直接の対策です。

記録を残す

• 受付番号、受付日時、経路（フォーム／代理入力）、紹介者の社員番号
• 「本人に話をしたか」の回答と、いつ本人の応募の意思が確認できたか
• 代理入力の確認の1通と、紹介者からの返事
• ポジションの候補と、採用担当が最終的に選んだ求人
• 段階の変化の履歴と、変わった日
• 紹介者へ送った文面の全文、承認した人、承認の日時
• 文面を作るときにAIへ渡した入力の全文
• 報奨金の条件、期限、支払の記録

最後から2行目が、この構成でいちばん大事なログです。 渡した入力を残しておけば、候補者の情報を渡していないことを、後から確かめられます。 「渡していないはずです」と言うのと、記録を開いて見せるのは、意味がまったく違います。