人材派遣会社に派遣先とスタッフから届く勤怠の修正依頼メールを、打刻漏れ・残業の修正・休暇の振替などに分類して、勤怠担当のタスクにする

処理の起点を決める

勤怠の共有のアドレスへのメールの到着を起点にします。 ただし Zap は受信箱を直接見ません。Gmail のフィルタで、共有のアドレス宛てのメールに「勤怠修正/受付」のラベルを付け、 そのラベルが付いたことで Zap を動かします。

ラベルを挟む理由は2つあります。1つは、先に書いたとおり New Labeled Email が付いた時期を問わず拾うことです。もう1つは、人が手でラベルを付けても動くことです。 担当者の個人のアドレスに直接届いた依頼も、共有の受信箱に転送してラベルを付ければ、同じ流れに乗ります。

注意が1つあります。 New Labeled Email は、ラベルの付いた会話に返信が来たときにも動きます。派遣先へ確認のメールを送り、その返事が同じ会話に届くと、返事のメールがもう一度、新しい依頼として流れてきます。 第7章の前処理で、件名と会話の履歴から「確認への返事」を見分けて除きます。

入力データを集める

質を決めるのは、送り主の台帳とスタッフの台帳です。 送り主が派遣先の担当者かスタッフ本人かが分からないと、確認が要るかどうかを決められません。 スタッフの台帳に氏名の読みが無いと、「わたなべ」と書かれた依頼を「渡辺」と「渡部」のどちらに付けるか決まりません。

締めの日は派遣先ごとに違うことがあります。 月末締めの派遣先と20日締めの派遣先が混ざっていれば、タスクの期日は派遣先の締めの日から決めます。 この一覧が無いと、全件が月末の期日になり、20日締めの依頼が後回しになります。

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

送り主の台帳は、アドレスで引きます。 スタッフ本人が個人のアドレスから送ってくることがあるので、スタッフの台帳には登録したアドレスを持たせておきます。 台帳に無いアドレスからの依頼は「送り主不明」とし、本人の確認をしてから扱います。

スタッフは氏名で引き、補助の検索列に派遣先を使います。 Lookup Spreadsheet Row は、探す列と値に加えて補助の検索列と値を指定できます。同じ氏名のスタッフが別の派遣先にいることがあるので、氏名だけで引きません。 派遣先の担当者からのメールなら、派遣先は送り主の台帳から分かります。

AIへ渡す前に整形する

1. 確認への返事を除く … 件名が「Re:」で始まり、会話のIDがタスクの一覧にすでにあるものは、新しい依頼として扱わず、そのタスクの行に「返事あり」と付けます
2. 引用と署名を落とす … 返信の引用部分と署名を本文から取り除きます。引用の中の過去の依頼を、もう一度読ませないためです
3. 添付ファイルの有無を印にする … 修正の一覧を表計算のファイルで送ってくる派遣先があります。添付があれば印を付け、本文だけで分類させずに人へ回します
4. 受信日を渡す … 「昨日」「先週の金曜」を人が後から解釈できるよう、受信日時を必ず一緒に残します

1番目を省くと、確認のやりとりがすべて新しい依頼になります。 派遣先が「確認しました、19時で正しいです」と返すたびにタスクが1行増え、同じ修正を二度直すことになります。

AIに処理させる

させるのは、メールを修正の件ごとに分け、件ごとに種類を決め、書かれている項目を写すことだけです。

種類の見分け方は、分類の手引きに例文で書きます。 「休みの日に出た」は休日出勤、「シフトが早番から遅番に変わった」はシフトの変更です。第3章の（d）で人によって違っていた見分けを、ここで1つに決めます。

1行目と2行目が、いちばん起きやすい失敗です。 日付と時刻は給与と請求の数字に直結します。推測で埋まった値は、正しく見えるので確認をすり抜けます。 書かれていなければ空欄にし、問い合わせの下書きに回します。

指示内容を固定する

あなたは人材派遣会社の勤怠担当で、勤怠の修正依頼メールを整理する立場です。
メールの本文に書かれていることだけを根拠にしてください。推測で補わないでください。

【やること】
1. メールに含まれる修正の依頼を、スタッフ1名・1日ごとの件に分けてください。
2. 件ごとに、修正の種類（correction_type）を次から1つ選んでください。
   missed_punch（打刻漏れ）／overtime（残業の修正）／leave_swap（休暇の振替・取得）／
   holiday_work（休日出勤）／late_early（遅刻・早退）／break（休憩の修正）／
   shift_change（シフトの変更）／cancel（以前の依頼の取り消し）／other
3. 件ごとに、スタッフ名、対象の日付、修正前の時刻、修正後の時刻を写してください。

【厳守事項】
- 日付は本文に書かれたとおりに写してください。「昨日」「先週の金曜」を
  日付に直さないでください。その場合は date_explicit を false にしてください。
- 時刻は本文に書かれたものだけを写してください。書かれていなければ空欄にし、
  missing_fields にその項目名を入れてください。
- スタッフ名は本文の表記のまま写してください。漢字を推測しないでください。
- 修正を認めるべきか、派遣先の確認が要るかは書かないでください。
- 1通に複数の件があれば、すべて分けてください。まとめないでください。
- evidence には、その件を読み取った本文の一部をそのまま写してください。
- 勤怠の修正の依頼が含まれないメール（お礼、質問だけ、営業の連絡など）は、
  items を空にし、not_a_request を true にしてください。

【分類の手引き】{classification_guide}
【受信日時】{received_at}
【メール本文（引用と署名は除去済み）】{body}

「日付に直さない」と書かないと、AIは親切に日付を計算します。 受信日時を渡しているので、「先週の金曜」から日付を出すことはできてしまいます。月をまたぐ週や、週の始まりを日曜とするか月曜とするかで、1週間ずれた日付が入ります。 日付を直すのは、受信日時を見た担当者です。

「まとめないでください」は、派遣先からのまとめのメールのためです。 5名分の修正が書かれたメールを1件にまとめられると、タスクの一覧に1行しか載らず、残りの4名分が漏れます。

出力形式を固定する

AI by Zapier の出力のフィールドを、次の形で定義します。

{
  "not_a_request": false,
  "items": [
    {
      "correction_type": "missed_punch | overtime | leave_swap | holiday_work | late_early | break | shift_change | cancel | other",
      "staff_name": "",
      "date_text": "",
      "date_explicit": true,
      "time_before": "",
      "time_after": "",
      "missing_fields": [],
      "evidence": ""
    }
  ]
}

1つ目の理由は、1通のメールを件の数だけ行に分けられることです。 items の要素1つが、タスクの一覧の1行になります。行に分ける手順をワークフローの側に持たせるので、 派遣先のまとめのメールでも、件の数だけタスクが立ちます。

2つ目は、Paths の条件をこの値と台帳の値だけで書けることです。

分岐の条件は重ならないように書きます。 Paths の分岐は左から順に実行され、条件を満たした分岐はすべて動きます。 B と C の条件が重なると、同じ件に派遣先への確認とスタッフへの問い合わせが両方作られます。C に当たるものは、項目がそろってから B を判断するので、B の条件に「missing_fields が空」を入れています。

3つ目は、date_text を書かれたまま残せることです。 タスクの一覧には「先週の金曜」とそのまま載り、担当者は受信日時を見て日付を決めます。 推測で埋めた日付より、空欄のほうが安全です。

システムへ連携する

件ごとの処理は Looping by Zapier で回します。 line items からループを作ると、ループの後ろの手順はすべて1件ごとに動き、 1件ごとに別の Zap の実行として履歴に残ります。行の追加も Paths も件ごとに動くので、5名分のメールなら5つのタスクと、それぞれの段取りができます。

ラベルの付け替えをループの前に置くのは、この性質のためです。 ループの後ろに置くと、件の数だけ同じ操作が動きます。Paths を足すとそれが最後の手順になる制約もあるので、全件に一度だけ要る操作は、分類が成功した直後に済ませます。「勤怠修正/受付」のラベルが残っているメールが、そのまま分類に失敗した一覧になります。 行の追加の失敗は、タスクの一覧の会話のIDと「起票済み」のメールを毎朝突き合わせて拾います。

勤怠の仕組みには書き込みません。 勤怠の修正は、タスクの一覧を見た担当者が画面で行います。AIが読み違えた時刻が、そのまま給与に入る経路を作らないためです。

人が確認する

人が見るのは、タスクの全件です。 ただし受信箱を読む仕事ではなく、1行のタスクと元のメールの根拠の文を照らす仕事です。

1. 期日の近い順にタスクを開く … 締めの日が近いものから並べます
2. 根拠の文と元のメールを照らす … スタッフ名、日付、時刻が本文どおりかを見ます。date_explicit が false のものは、受信日時から日付を決めて書き込みます
3. 勤怠の仕組みで直す … 直したら、タスクの行に完了の印と直した日時を付けます
4. 返信の下書きを直して送る … 分岐BとCの下書きを読み、必要なら書き直して送ります
5. 分類を直したら記録する … 種類を変えたら、訂正の列に残します

2番目を省かないでください。 AIは「19:30」を「19:00」と写し違えることがあります。30分の違いは、給与の訂正と派遣先への請求の出し直しの両方になります。

目標は、900件をならして1件1分です。 そのまま直せる件は根拠の文を見るだけで数十秒、下書きの件は文面を読んで送るので数分かかります。締めの前の週に1分を大きく超えるなら、問い合わせの下書きが多すぎないか、つまり日付の書かれていない依頼が増えていないかを見ます。 派遣先に依頼の書き方の見本を配るほうが、AIの指示を直すより効きます。

例外に対処する

最後の行で、ラベルを残すのが要点です。 失敗したメールのラベルを付け替えてしまうと、受信箱の上では処理済みに見えて、タスクの一覧には無いという状態になります。第3章の（b）と同じ漏れが、自動化の中で起きます。

記録を残す

• 元のメール（Gmail に残る。会話のIDをタスクの一覧に記録する）
• AIの出力（items の全体）と、そのとき使った分類の手引きの版
• タスクの一覧の各行（種類、スタッフ、日付、時刻、期日、段取り、完了の日時）
• 人が直した記録 … 種類、日付、時刻のどれを、何から何に変えたか
• 送った返信の日時と、派遣先の確認が取れた日時
• Zapier の Zap の実行の履歴

4つ目の記録が、分類の手引きを直す材料になります。 AI by Zapier は実行のたびに学習する仕組みではないので、同じ誤りを止めるには、手引きの例文を人が足すしかありません。

5つ目は、派遣先ごとの確認の速さを見るためです。 確認の返事が締めの日に間に合わない派遣先が続くなら、確認の段取りそのものを派遣先と相談します。