契約の更新が近い派遣スタッフに更新の意向を聞き、返事を「更新・条件しだい・終了」に仕分けて、派遣先への回答の期限前に担当へ回す

処理の起点を決める

トリガーは3つに分けます。 送る、受ける、追いかける、の3つです。1本のシナリオにまとめると、返事の受信を待つあいだに送信が止まり、どこで止まったかが分かりにくくなります。

起点を終了日ではなく、派遣先への回答の期限に置きます。 終了日から一律に逆算すると、「45日前まで」を求める派遣先の分だけ連絡が遅れます。台帳の期限の列から21日前を求め、そこを起点にします。 受信のトリガーは、専用のラベルに入ったメールだけを見ます。 意向を尋ねるメールの件名に決まった語を入れ、Gmail のフィルタでその件名への返信にラベルを付けておきます。ラベルの外のメールには、この構成は触れません。

入力データを集める

質を決めるのは、いちばん上の行の「状態」の列です。 「未送信」「確認中」「再送済み」「電話対象」「回答済み」の5つの値を決め、シナリオはこの列だけを見て動きます。状態を持たないと、同じスタッフに毎朝メールが届きます。

前回の意向は、仕分けの材料ではなく、担当者が読むために持ちます。 前回も「時給しだい」と言っていたスタッフなら、営業は今回こそ交渉の材料をそろえて臨めます。AIには前回の意向を渡しません。 渡すと、今回の返事が短いときに前回の内容で補うおそれがあるからです。

送った文面は、AIに渡します。 「次回も同じ条件で更新を希望されますか」と聞いたのに対する「はい」と、「何かご希望はありますか」に対する「はい」では、意味が変わります。

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

送信の側は、台帳の Search Rows で拾います。 条件は「状態が未送信」かつ「回答の期限が今日から21日以内」です。拾った行ごとに Send an email を呼び、送信に成功した行だけを Update a Row で「確認中」に書き換えます。

受信の側は、送信元のアドレスで台帳の行を引きます。 スタッフが別のアドレスから返事をすることがあるので、引けなかったものはAIに渡さず、コーディネーターの確認待ちに回します。 氏名で引き直すことはしません。同姓同名のスタッフの台帳に書き込む事故を避けるためです。

掛け持ちのスタッフは台帳に2行あります。 2行出たら両方の派遣先の名前をAIに渡し、返事がどちらについてのものかを書き出させます。

AIへ渡す前に整形する

1. 引用部分の削除 … 返事の下にこちらの問いの文面が引用されていることが多いので、引用の記号と、決まった区切りの行より下を落とします
2. 署名の削除 … 携帯電話の自動の署名や、他社での勤務先の署名を落とします
3. 空の返事の検知 … 本文が空、または引用だけの返事は、AIに渡さず「読み取れない」にします
4. 添付の確認 … 返事に添付があれば、本文だけを仕分けに使い、添付があったことを台帳に書きます
5. 台帳の行の特定 … 送信元のアドレスで行を引きます。0行なら確認待ち、2行以上なら派遣先の名前を並べて渡します
6. 状態の確認 … 状態が「回答済み」の行への返事は、仕分けをせずに担当者へ回します。派遣先へ回答した後の意向の変化だからです
7. 個人情報の絞り込み … AIに渡すのは返事の本文と派遣先の名前、送った文面だけです。氏名・住所・時給の現在値は渡しません

1番目を軽く見ないでください。 引用が残ったまま渡すと、こちらが書いた「次回も同じ条件で更新を希望されますか」という文を、スタッフの言葉として読むことがあります。 スタッフが「はい」と1語だけ返したとき、引用を落とせていれば短い返事として正しく扱えます。

6番目は、意向が変わったという連絡です。 回答済みの後に「やっぱり辞めたい」と来たものを仕分けて台帳に書き込むと、派遣先に回答した内容と台帳が食い違います。 人が受け止めて、派遣先にどう伝えるかを決めます。

AIに処理させる

させるのは、返事を4つに仕分けることと、仕分けの根拠にした文と、本人が挙げた条件を書き出すことだけです。

conditional を広く取ります。 「少し考えさせてください」は、更新でも終了でもありません。迷っているということ自体が、担当者が電話をする理由になります。 「更新したいけれど、通勤が少しつらいです」のように、更新の意思に気がかりが添えられているものも conditional です。

unclear には、問いに答えていない返事を入れます。 「了解です」は、メールを受け取ったことへの返事かもしれません。更新の意思として読まないでください。

2行目がいちばん起きやすい失敗です。 短い返事を「消極的」と読むことがあります。行間を読むのは人の仕事です。

指示内容を固定する

あなたは人材派遣会社で、派遣スタッフから届いた返事を読み、
契約の更新についての本人の意向を仕分ける担当です。
返事に書かれていることだけで判断してください。推測で補わないでください。

【こちらが送った問い】{sent_message}
【派遣先の名前（複数あれば両方）】{client_names}
【スタッフの返事（引用と署名は除去済み）】{reply_body}

【仕分け（intent）】
- renew ........ 同じ条件で続けるとはっきり書いている
- conditional .. 続ける意思はあるが、条件・迷い・気がかりが書かれている
- end .......... 続けないとはっきり書いている
- unclear ...... 上のどれとも決められない。問いに答えていない
迷ったときに renew や end を選ばないでください。conditional か unclear にしてください。

【厳守事項】
- 文面の調子、短さ、絵文字の有無から意向を推し量らないでください。
- 「了解です」「承知しました」だけの返事は unclear です。
- 「考えさせてください」「相談したい」は conditional です。
- conditions には、本人が挙げた条件を本文の言葉のまま入れてください。
  言い換え、要約、まとめをしないでください。条件が無ければ空の配列にしてください。
- evidence には、intent の根拠にした文を本文からそのまま写してください。
- 体調、けが、家族の事情、職場の人間関係、ハラスメント、妊娠・出産、
  収入の困りごとに触れていれば sensitive を true にしてください。
  その内容を要約したり、evidence に写したりしないでください。
- 派遣先が2つあるときは、返事がどちらについてのものかを target_client に書き、
  決められなければ intent を unclear にしてください。
- 更新すべきか、条件を受け入れるべきかについて、意見を書かないでください。
- 返事が契約の更新と関係のない内容（勤怠の連絡、給与の質問など）なら
  intent を unclear にし、off_topic を true にしてください。

「迷ったときに renew や end を選ばない」を明記しないと、どちらかに寄せます。 仕分けを求められると、4つのうち中間の2つを避けて、はっきりした答えを出そうとします。この構成で困るのは、迷っている人を「更新」に入れてしまうことです。

sensitive の内容を写させないのも理由があります。 体調や職場の人間関係に触れた返事の根拠の文が、台帳の列に残り、営業や派遣先との打合せの資料に流れていくのを防ぎます。 印だけを立て、中身は担当のコーディネーターが本文で読みます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力を使うと、決めたJSONスキーマに沿った応答が返り、必須の項目の抜けや型の違いが起きないとされています。

{
  "staff_id": "",
  "intent": "renew | conditional | end | unclear",
  "conditions": [
    { "topic": "wage | days | hours | duties | commute | other", "quote": "" }
  ],
  "evidence": "",
  "sensitive": false,
  "off_topic": false,
  "target_client": "",
  "route": "care | negotiate | replace | ack | check"
}

1つ目の理由は、intent と route を別の層に置けることです。 intent はAIが埋め、route はルーターが規則で決めます。

care をいちばん上に置きます。 「更新します。ただ最近体調が悪くて」という返事は、intent が renew でも、受け付けましたと自動で返す前に人が読むべきものです。

2つ目は、conditions の topic で集計ができることです。 今月の「条件しだい」のうち時給の話がいくつ、勤務日数の話がいくつあるかが数えられ、派遣先ごとに交渉の材料をまとめられます。 quote には本人の言葉がそのまま残ります。

3つ目は、台帳の列にそのまま書けることです。 意向の列には intent を日本語に置き換えた「更新」「条件しだい」「終了」「確認待ち」を書き、備考欄の自由な書き方をやめます。 今月の更新の見込みが、列の集計で出ます。

システムへ連携する

スタッフ管理システムには書き込みません。 この構成が出すのは意向の仕分けまでで、更新の確定は、派遣先への回答が済んだ後に人が登録します。 書き込みを足すと、AIの仕分けがそのまま契約の情報になります。

受け付けの返信は、最初は下書きにします。 renew の仕分けが安定したことを1〜2か月見てから、送信に切り替えるかを決めます。conditional と end には、自動の返信を作りません。 条件のある人に定型文の「承知しました」を返すと、条件が受け入れられたと読まれます。

人が確認する

人が連絡するのは、care、negotiate、check と、返事の無いスタッフだけです。 ack は台帳の一覧で人数と名前を流し見ます。

1. care を最初に読む … 本文を開き、電話で話すかどうかを決めます。更新の話より先に、本人の状況を聞きます
2. negotiate の条件を営業と共有する … quote を見て、派遣先と話せる条件か、話せないかを決めます。本人への返事は、派遣先と話した後にします
3. check を読み直す … 意向として読めるものは担当者が台帳を直し、読めないものは電話します
4. 電話の対象を回る … 期限4日前の一覧に載ったスタッフに電話し、結果を台帳に書きます
5. 仕分けを直したら記録する … どの仕分けを、どれに変えたかを残します

2番目の順番を守ってください。 先に本人へ返すと、条件が通ったものと思って待たせます。

目標は、360名をならして1名4分です。 「更新」と返す人が半数を超え、その確認が数十秒で済む想定です。それより多い月は、check が多いか、返事の無い人が多いかのどちらかです。 問いの文面か送る時期を見直します。

例外に対処する

下から3行目を見落としがちです。 期限の列が空の行は、送信の条件に一度も当たらず、黙って対象から外れ続けます。 期限が空の行の数を毎朝知らせるのは、この穴をふさぐためです。

記録を残す

• 送った問いの文面と、送った日時・宛先
• 受け取った返事の本文（引用と署名を落とす前のもの）と受信日時
• AIが返したJSONの全文（intent、conditions、evidence、sensitive）
• ルーターが決めた route と、通知した先
• 人が仕分けを直した記録 … どの仕分けを、どれに変えたか
• 再送した日時と、電話の対象に載せた日時
• 派遣先へ回答した日と、そのときの意向

最後の行は、雇止めの扱いに関わります。 厚生労働省のページでは、3回以上契約が更新されている場合や1年を超えて継続して勤務している人について、契約を更新しない場合は、使用者が30日前までに予告しなければならないとされています。スタッフに伝えた日と派遣先へ回答した日を残すのは、この時期の管理を後から確かめられるようにするためです。

sensitive が立った返事の本文は、閲覧できる人を担当のコーディネーターと責任者に絞ります。 台帳の列には印だけを残し、本文はメールの側に置いたままにします。