人材派遣会社で、派遣スタッフの勤怠の未提出と未承認を毎週拾い、事情を見て本人と派遣先の担当者のどちらに催促するかを決めて送る

処理の起点を決める

シナリオの予定で動かします。 Make のシナリオは、決まった間隔、1回だけ、毎日、平日、毎週、毎月、指定した日、必要なときだけ、のいずれかで動かせます。通常の週は「毎週」で月曜の朝に、締めの前の週は「指定した日」で毎朝に動かします。 締めの日は月ごとに決まっているので、指定した日を月に一度入れ直すか、毎日動かして、シナリオの最初で「今日は催促する日か」を日程のシートで確かめる形にします。後者のほうが入れ忘れがありません。

動かす時刻は、勤怠の書き出しが終わった後にします。 書き出しが終わる前に動くと、前の日の状態で催促してしまいます。シナリオの最初で、勤怠の状態のシートの「書き出し日時」が今日かを確かめ、古ければ止めて勤怠担当に知らせます。

催促を送る時刻も考えます。 スタッフへのメールは勤務の前に読まれることが多く、派遣先の担当者は始業後に読みます。本人への催促は朝、派遣先への下書きは朝のうちに作ってコーディネーターが午前中に送る流れにしています。

入力データを集める

質を決めるのは、コーディネーターのメモです。 「10/6〜10/17 入院。勤怠は退院後にまとめて入力と本人から連絡あり」と書かれていれば、その期間の未提出は催促しません。メモが無ければ、AIも事情を知りようがありません。 事情を聞いたら1行でもメモに書く運用が、この構成の前提です。

派遣先の「不在の予定」も同じです。 承認者が出張や休みで不在と分かっていれば、代理の承認者に送るか、戻る日まで待つかを決められます。

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

Make の Google Sheets のモジュールで読みます。 公式のページでは、Google Sheets のアプリには行を探す「Search Rows」、行を足す「Add a Row」、行を直す「Update a Row」などがあり、Search Rows では AND と OR を使って条件を指定でき、1回の実行で返す件数の上限を指定する項目があるとされています。

件数の上限は必ず大きめに設定し、上限に届いたら知らせます。 上限に届いたまま気づかないと、一覧の後ろのほうのスタッフが毎週催促されないことになります。

見出しの行を使う設定にします。 公式のページでは、表に見出しがあると設定すると見出しの行は出力に含まれず、無いとすると列が A、B、C… という名前になるとされています。列の名前で値を扱えるよう、どのシートも1行目を見出しにしておきます。

AIへ渡す前に整形する

1. 書き出しの日時を確かめる … 勤怠の状態が今日の書き出しでなければ止めます
2. 同じスタッフの複数の週をまとめる … 2週分が未提出なら、催促は1件にして週を並べます
3. 就業の状態で外す … 休業中・就業終了のスタッフは対象から外し、記録に「対象外」と残します
4. 何回目かを数える … 催促の記録から、同じスタッフと週への催促の回数を数えます
5. 締めまでの営業日を数える … 日程のシートから、承認がそろうべき日までの営業日を出します
6. 承認者の不在を確かめる … 派遣先の一覧の不在の予定が今日を含むなら、代理の承認者を候補にします
7. メモを短くする … 直近60日のメモを新しい順に並べ、決めた長さまでに切ります

3番目と4番目と5番目は、AIに渡す前にスクリプトの側で決めておきます。 就業の状態、回数、残りの営業日は表から確実に出せる事実で、AIに数えさせる理由がありません。AIには、その事実と、メモという「表にならない事情」を合わせて判定させます。

AIに処理させる

させるのは、1件について次の3つを決めることだけです。

相手の選び方の基本は、状態で決まります。 未提出と差し戻しは本人、提出済み未承認は承認者です。AIが変えてよいのは、メモや不在の予定に事情があるときだけです。 承認者が不在なら代理へ、入院のメモがあれば止める、という具合です。

3行目が、この判定でいちばん大事な制約です。 2週分の未提出が続いているだけで「体調不良の可能性があるので止める」と判定すると、本当に忘れているスタッフに催促が届かなくなります。 止めてよいのはメモに事情が書かれているときだけで、事情が分からないものは送るか、担当へ回すかのどちらかです。

指示内容を固定する

あなたは人材派遣会社の勤怠担当です。派遣スタッフの勤怠の催促について、
相手と、送ってよいかを判定してください。文面は書かないでください。

【基本の相手】
- 未提出・差し戻し … 本人（staff）
- 提出済み未承認 … 派遣先の承認者（client）

【基本から変えてよいのは、次の場合だけです】
- メモに、本人が入力できない事情（入院、療養、忌引など）が書かれている
  → action は hold、recipient は coordinator
- メモに、本人が期限内にまとめて入力すると連絡があった旨が書かれ、
  締めまでの営業日が3日以上ある → action は hold
- 承認者の不在の予定が今日を含み、代理の承認者がいる
  → recipient は client_deputy
- 承認者の不在の予定が今日を含み、代理がいない → recipient は coordinator
- メモに、派遣先と勤怠の扱いを話し合っている旨がある → recipient は coordinator

【厳守事項】
- メモに書かれていない事情を推し量らないでください。
  未提出が続いているだけで、体調不良などと判断しないでください。
- 判断の根拠にしたメモの文を evidence にそのまま写してください。
  基本の相手のままなら evidence は空にしてください。
- 相手は【派遣先の一覧】にある人の中からだけ選んでください。
- 迷ったら action は unclear、recipient は coordinator にしてください。

【勤怠の状態】{status}（対象の週：{weeks}、差し戻しの理由：{reject_reason}）
【何回目の催促か】{count}　【締めまでの営業日】{days_left}
【就業の状態】{employment_status}
【派遣先の一覧】{approvers}（不在の予定と代理を含む）
【コーディネーターのメモ（直近60日）】{memos}

「基本から変えてよいのは、次の場合だけ」と書いているのが要です。 判定の自由を広く渡すと、メモのささいな書きぶりで止めてしまいます。変えてよい場合を列挙し、それ以外は基本どおりにします。

氏名はメモの中にしか出てきません。 スタッフの氏名とメールアドレスは渡さず、スタッフIDだけで扱います。メモの中の人名は残りますが、宛先を組み立てるのは Make の側で、AIの判定に氏名は要りません。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 Make の Anthropic Claude のアプリには、文章を送る「Create a Prompt」のほかに、任意の API を呼べる「Make an API Call」があります。構造化出力を使うため、Make an API Call で Messages API を呼び、output_config.format に JSON の形を指定します。 公式のページでは、オブジェクトに additionalProperties: false を付けることとされています。

{
  "staff_id": "S-20431",
  "recipient": "staff | client | client_deputy | coordinator",
  "action": "send | hold | unclear",
  "evidence": "10/6〜10/17 入院。勤怠は退院後にまとめて入力と本人から連絡あり",
  "note": ""
}

1つ目の理由は、ルーターの条件にそのまま使えることです。 Make のルーターは、フィルターの条件で行き先を分けます。recipient と action の組み合わせごとにルートを作り、文章を読まずに振り分けます。

予備のルートを必ず作ります。 公式のページでは、予備のルート（fallback route）は、ほかのすべてのルートの条件に当たらないデータを処理するとされています。本人への3回目の催促や、思わない値が返ってきたものが、どこにも行かずに消えるのを防ぎます。 また、ルートは並行ではなく順に処理されるとされているので、担当へ回すルートを先に置き、止めるべきものが先に拾われる順にします。

2つ目の理由は、列挙の値を確かめられることです。 公式のページでは、列挙の値が大文字小文字だけ違う形で返ることがあるとされています。ルーターの条件は大文字小文字を区別しない比べ方にします。

3つ目は、evidence で止めた理由を担当が読めることです。 確認の一覧に evidence が並ぶので、コーディネーターはメモを開き直さずに判断できます。

システムへ連携する

本人へは自動で送り、派遣先へは下書きにします。 Make の Gmail のアプリには、送る「Send an email」と、下書きを作る「Create a draft email」、下書きを送る「Send a draft email」があります。派遣先への催促は、コーディネーターが下書きを開いて送ります。 顧客への連絡を、担当の知らないところで送らないためです。

文面は相手と回数ごとに3種類ずつ持ちます。 本人への1回目は「入力のお願い」、2回目は「締めの日のお知らせを添えたお願い」、派遣先への催促は「承認のお願いと、派遣元から請求する旨」です。3回目以降は自動で送らず、担当へ回します。

人が確認する

1. 確認の一覧を毎朝見る … 担当のコーディネーターが、自分のスタッフの分だけを見ます。evidence を読み、止めるか送るかを決めます
2. 派遣先への下書きを送る … 宛先と週を確かめて送ります。承認者が変わっていれば、派遣先の一覧を直します
3. 止めたものの期限を決める … 入院などで止めたものは、いつ再開するかを催促の記録に書きます
4. 判定を覆したら記録する … 止めるべきでないものを止めていた、またはその逆なら、記録に印を付けます

本人への1回目・2回目は人を通しません。 メモに事情が無く、基本どおりの判定のものは、そのまま送ります。人の時間は、派遣先への連絡と事情のあるものに集めます。

4番目の印は、指示を直す材料になります。 止めすぎていれば変えてよい場合の書き方を絞り、送りすぎていればメモの書き方をコーディネーターに伝えます。

例外に対処する

上から2行目は見落としやすい失敗です。 Search Rows の件数の上限に届いたまま気づかないと、一覧の後ろのスタッフが毎週抜けます。 拾った件数が上限と同じなら必ず知らせる条件を、シナリオの最後に置きます。

3回目以降を自動で送らないのは、催促が効いていない合図だからです。 同じ文面を3回送っても入力されないなら、メールが読まれていないか、何か事情があります。 電話か派遣先での声かけに切り替える判断は、コーディネーターに任せます。

記録を残す

• 実行の日時、拾った件数、ルートごとの件数
• 1件ごとに、渡した事実（状態、回数、残りの営業日、就業の状態、不在の予定）とメモの範囲
• AIが返した JSON の全文
• 送った文面の種類、宛先、送った日時、下書きを作った日時
• 担当が止めた・送った・覆した記録と、止めたものの再開の予定
• 締めの日に残った未承認の件数

3つ目を残すのは、止めた理由を後から説明するためです。 「なぜ自分には催促が来なかったのか」「なぜ入院中に催促が来たのか」と聞かれたとき、その日にどのメモを根拠に判定したかを示せます。

最後の行が、この構成の効き目を測る数字です。 締めの日に残る未承認が月を追って減っていれば、催促が早く正しい相手に届いているということです。