会社説明会の参加者を一人ずつ状態で追い、アンケートの回収から選考の案内、日程の確保までを回して、人が見るべき人だけを採用担当に上げる

処理の起点を決める

毎朝9時の定時実行を起点にします。 説明会の直後にだけ動かす形にはしません。参加後の連絡は、翌日、3日後、1週間後と時間差で必要になるためです。毎朝、全員の状態を読み直す形にすると、どの時点の連絡も同じ仕組みで回ります。

ただし、エージェントに渡すのは全員ではありません。取りまとめのシナリオが先に、次の2つに当てはまる人だけを抜き出します。

• 前日から状態が変わった人 … アンケートに答えた、応募した、面談を予約した、返信してきた
• 次の連絡の予定日が今日の人 … 前回の一手で予定日を入れておいた人

この絞り込みを、エージェントの外で機械的に行います。 300名全員を毎朝エージェントに渡すと、何もすべきでない人についても判断が走り、利用料と誤った送信の機会が両方増えます。

送信してよい時間帯も決めておきます。 平日の9時から19時の間だけ送り、土日と夜間に予定日が来た人は次の送信可能時刻に回します。応募者にとって、夜遅くに届く採用の連絡は印象を下げます。

入力データを集める

質を決めるのは、いちばん下の型の一覧です。 エージェントは型のIDを選ぶだけなので、用意されていない場面には何も送れません。 型が足りない場面では人に上げるしかなく、上がる人が増えます。最初に、どの状態にどの型を送るかを採用担当が書き出します。

応募の状況は、参加者一覧とメールアドレスで突き合わせます。 説明会の申込と応募で別のアドレスを使う人がいるので、一致しなかった人は「応募なし」と決めつけず、「照合できない」として扱います（例外処理で後述）。

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

取りまとめのシナリオが、4つの場所から順に読み集めます。

面談の予約は、Google カレンダーの予約スケジュールで受けます。 予約の長さと空き時間を決めて予約ページを作り、参加者がそこから予約します。予約フォームでは氏名とメールアドレスが必須で、項目を足すこともできます。 予約されると確認メールが自動で送られ、リマインダーは最大5件まで送れるとされています。この構成では、面談の前日の連絡を予約スケジュールのリマインダーに任せ、エージェントからは送りません。 同じ連絡が二重に届くのを防ぐためです。

採用管理システムとは、CSVでつなぎます。 製品によってはAPIで応募の状況を取れるものもありますが、ここではどの製品でも取れる書き出しのファイルを前提にします。 APIが使える環境なら、取りまとめのシナリオの読み込み部分だけを差し替えます。

AIへ渡す前に整形する

1. 状態の更新 … 読み集めた事実から、参加者一覧の状態の列を機械的に更新します（後述の状態の一覧）
2. 抽出 … 状態が変わった人と、予定日が今日の人だけを抜き出します
3. 規則による除外 … 配信停止の人、再案内が上限の2回に達した人、選考中で採用管理システム側の連絡に移った人を外します
4. 返信の切り出し … 返信メールから引用部分と署名を落とし、参加者が書いた本文だけにします
5. 自由記述の長さの確認 … アンケートの自由記述と返信の本文を、決めた文字数で切り詰めます
6. 渡さない情報の除去 … 電話番号、住所、生年月日の列は渡しません

1番目を、エージェントにやらせない点が大事です。 「応募したか」「予約したか」は事実で、表を照らせば決まります。事実の判定をAIに任せると、照合の誤りがそのまま案内の誤りになります。 エージェントに渡すのは、機械で決めた状態と、人の言葉で書かれた部分だけです。

状態は次の8つに決めます。

AIに処理させる

させるのは、一人ずつ状態と本人の言葉を読み、次の一手を1つ選ぶことです。 選べる一手は次の6つに限ります。

エージェントらしさが出るのは、replied と自由記述のある人です。 返信の本文が「日程を変えたい」なら予約ページの再案内の型、「もう他社に決めました」なら追いかけを終える close、「勤務地について相談したい」なら escalate。本人の言葉を読み、どの一手に当たるかを決めるのがAIの仕事です。 状態だけで決まる人は、規則の表どおりに一手が決まります。

最後の行は、法令にかかわる線です。 職業安定法に基づく指針では、本籍、出生地その他社会的差別の原因となるおそれのある事項や、思想及び信条、労働組合への加入状況は、特別な必要がある場合を除いて収集してはならないとされています。自由記述に書かれていたとしても、エージェントがそれを要約して履歴に残せば、収集したのと同じことになります。

指示内容を固定する

エージェントの指示（instructions）に入れる文面の例です。

あなたは採用部で、会社説明会の参加者への連絡の順番を決める担当です。
参加者一人ずつについて、次の一手を1つだけ選んでください。
文面を書くことはあなたの仕事ではありません。

【選べる一手】
- send_template ... 型の一覧から1つを選んで送る
- check_booking ... 面談の予約状況を調べ直す
- wait ........... 今日は送らず、予定日を延ばす
- escalate ....... 採用担当へ上げ、この人への自動送信を止める
- close .......... 追いかけを終える
- no_action ...... 何もしない

【必ず escalate にする場合】
- 本人の言葉に、質問・相談・苦情・事情の説明が含まれる
- 選考の条件、待遇、勤務地、配属についての問い合わせ
- 体調、家族、障害、通院など、配慮を求める内容
- 型の一覧に、この場面に合う型が無い
- 自分の判断に自信がない
迷ったときに send_template を選ばないでください。

【厳守事項】
- 型の一覧に無い型IDを作らないでください。
- 型の本文を変えたり、言葉を足したりしないでください。
- 選考の合否、優先して追うべき人かどうかを書かないでください。
- 本人の言葉から年齢、家族構成、出身地、国籍、思想信条などを
  推し量らないでください。reason にも書かないでください。
- 「辞退します」「連絡は不要です」と読める言葉があれば close を選び、
  理由に本人の言葉をそのまま短く写してください。
- 状態の列は事実です。あなたの判断で書き換えないでください。
- reason には、選んだ根拠を1文で書いてください。
  本人の言葉を写すときは、判断に使った部分だけにしてください。

【この参加者の状態】{state}
【前回の一手と日付】{last_action}
【再案内の回数】{remind_count}／上限2回
【本人の言葉（返信・自由記述）】{user_text}
【型の一覧】{templates}

「迷ったときに send_template を選ばない」を明記しないと、送る側に寄ります。 型の一覧が与えられていると、近い型を見つけて選ぶほうが仕事をしているように見えるためです。送らない誤りは採用担当が拾えますが、送った誤りは取り消せません。

「reason に書かない」を属性の禁止と並べて書いているのも同じ理由です。 判断に使わなくても、理由の欄に「家族の介護のため」と要約されれば、それが履歴に残ります。

出力形式を固定する

次の形のJSONで受け取ります。 Make AI Agents では、応答をプレーンテキストのほか、自分で定義したデータ構造で返させることができます。

{
  "attendee_id": "",
  "state": "replied",
  "action": "send_template | check_booking | wait | escalate | close | no_action",
  "template_id": "",
  "next_contact_date": "YYYY-MM-DD",
  "escalate_reason": "question | consideration | complaint | no_template | low_confidence | ",
  "reason": ""
}

1つ目の理由は、一手を後段で検める層を置けることです。 action が send_template でも、取りまとめのシナリオがもう一度、配信停止と回数の上限、型IDが一覧にあるかを確かめてから送ります。エージェントの判断と、送ってよいかの判定を別の層に置きます。

2つ目は、escalate_reason で上がった理由の内訳が数えられることです。 no_template が多ければ型が足りていません。question が多い回は、説明会の中で説明しきれていない話題があります。採用担当が直す先が、理由の内訳で分かります。

3つ目は、next_contact_date で次の起動が決まることです。 エージェントが「3日後にもう一度見る」と決めたら、その日付が参加者一覧に入り、トリガーの抽出条件に当たります。予定日の無い人は、次に状態が変わるまで読み直されません。

システムへ連携する

道具にするシナリオは4本です。

send_template_mail の入力に、本文を持たせません。 受け取るのは型IDだけで、本文は道具のシナリオが型の一覧から引いて差し込みます。エージェントがどう判断しても、型にない文面は送れない作りにします。 道具の説明欄には「型IDを1つ受け取り、その型を送る」と書き、入力の説明に型IDの一覧の場所を書きます。

採用管理システムへは書き込みません。 応募から先は採用管理システムの側の連絡に移り、この構成は応募と面談の予約までを運ぶ役です。

人が確認する

人が開くのは、escalate で上がってきた人だけです。 Slack の採用担当のチャンネルに、参加者ID、回、理由の区分、本人の言葉の該当部分が届きます。

1. consideration と complaint を先に見る … 配慮を求める連絡と苦情は、その日のうちに人が返事をします
2. question に返事をする … 答えを書いて送り、同じ質問が多ければ型の一覧に答えの型を足します
3. no_template と low_confidence を見る … どの一手が正しかったかを決め、手で送るか、型を足します
4. 返事が済んだら状態を戻す … 参加者一覧で、その人の自動送信を再開するかを決めます

週に1回は、エージェントが選んだ一手の一覧を流し見ます。 送った人の中に、本当は上げるべきだった人がいないかを見ます。最初の1か月は、送信を止めて一覧だけを出す運用にしてください。 エージェントの選び方が採用担当の感覚と合うかを確かめてから送信を有効にします。

目標は、300名をならして1人2分です。 上がってくるのは1〜2割という想定で、それより多い月は、型が足りないか、説明会で説明しきれていない話題があります。

例外に対処する

上の2行が大半を占めます。 照合できない人に「ぜひご応募ください」と送ると、すでに応募した人を軽んじることになります。分からないときに送らない、を例外処理の基本にします。

記録を残す

• 実行ごとの抽出結果（誰を、なぜエージェントに渡したか）
• エージェントへの入力と、返ってきたJSONの全文
• 規則の側で止めた記録（配信停止、回数の上限、時間帯）
• 送った型IDと送信日時、送信結果
• 人に上げた記録と、採用担当が行った対応
• 型の一覧の版（どの文面の型を送ったか）

最後の行は、文面を後から直すためです。 型の本文を書き換えると、過去に何を送ったかが分からなくなります。型を直すときは新しい型IDにし、古い型は残します。

Make AI Agents には、エージェントの段階ごとの考え方を確かめられる Reasoning のパネルがあるとされています。試行の期間は、上がってきた人と、送った人の両方について、このパネルで判断の筋を見ます。 保存の期間は、職業安定法に基づく指針が、収集目的に照らして保管する必要がなくなった個人情報を破棄又は削除することを求めている点を踏まえ、採用の年度が終わったら消す運用を決めておきます。