人材派遣会社に派遣先から届く受注のメールから、職種・人数・期間・時給・就業条件を受注票にそろえ、足りない確認事項の返信案を作る

処理の起点を決める

受注用のアドレスに、新しいメールが届いたことを起点にします。 Gmail の側で、受注のメールに「受注」のラベルが付くようにフィルタを作り、Watch emails はそのラベルだけを見ます。営業担当の個人のアドレスに届いた受注は、担当が受注用のアドレスに転送する決まりにします。

実行の間隔は15分ごとにします。 受注は午前中に集中し、早く返信した派遣会社から決まっていく業務なので、1日1回のまとめ処理にはしません。「取得時に既読にする」の設定を有効にし、拾ったメールを二度処理しないようにします。

派遣先の担当からの返信も、同じラベルに入ります。 件名に受注番号を入れて返信してもらう形にし、受注番号のあるメールは新しい受注ではなく、既存の受注票の更新として扱います。

入力データを集める

質を決めるのは、派遣先マスタの送信元のアドレスの列です。 派遣先の担当が替わったり、現場の責任者が個人のアドレスから送ってきたりすると、派遣先を引けません。引けなかったものは、担当営業の確認待ちに回します。

抵触日の通知の受領日を派遣先マスタに持たせるのは、新しい受入れの受注を見分けるためです。 東京労働局の資料では、派遣契約の締結に当たって、あらかじめ事業所単位の抵触日の通知を受けることとされています（法第26条第5項）。受領日が空の事業所からの受注には、確認事項として挙げます。

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

本文の引用部分は落とします。 返信のメールには過去のやり取りが下に引用されていて、そのまま渡すと古い条件が今回の条件として取り出されます。 「-----Original Message-----」や「〇〇 wrote:」より下を切ります。

添付のExcelは、シートの中身を表の形のテキストにして渡します。 派遣先の様式は項目名の位置がばらばらなので、セルの位置で決め打ちせず、項目名と値の並びのままAIに読ませます。

AIへ渡す前に整形する

1. 引用部分と署名を落とす … 返信の引用より下と、送信者の署名を切ります。署名の電話番号を就業場所の電話番号と取り違えないためです
2. 派遣先を決める … 送信元のアドレスで派遣先マスタを引きます。引けないものは 派遣先不明 の印を付けます
3. 既存の受注の更新かを見分ける … 件名に受注番号があれば、既存の受注票の更新として扱います
4. 前回の受注を添える … 「前回と同じ」「前回同様」のような語があれば、直近の受注票を一緒に渡します
5. 添付をテキストにする … Excel は表の形のテキストに、PDF は本文を取り出して渡します
6. スタッフの個人情報を落とす … 派遣先が「前回来てくれた〇〇さんをまた」と書いていても、氏名はAIに渡さず 指名あり の印に置き換えます
7. 重複の除去 … 同じ派遣先から同じ件名のメールが短い間に2通来たら、後のものを更新として扱います

6番目は、第1章の注意の印と同じ考え方です。 特定のスタッフの指名は、派遣先が派遣労働者を特定する行為との関係を確かめる必要があります。扱いを決めるのは派遣元責任者で、AIは印を付けるところまでです。

AIに処理させる

させるのは、受注票の項目を取り出し、根拠の文を写し、足りない項目と注意が要る記載に印を付け、確認の返信案を書くことです。

幅のある人数をそのまま写させるのには理由があります。 東京労働局の資料には、派遣契約で派遣人数を「〇人〜〇人」と定めていたことが指導の事例として挙がっています。幅のまま受注票に入れ、確認事項として人数を確かめる返信を作らせます。

注意の印は、次の5つです。

東京労働局の資料では、派遣先は派遣労働者を特定することを目的とする行為をしないよう努めなければならない（法第26条第6項）とされ、派遣元は紹介予定派遣の場合を除きその行為に協力してはならないとされています。 具体的には事前面接、履歴書等の提出要請、年齢・性別を限定すること、が挙げられています。日雇派遣（日々又は30日以内の期間を定めて雇用する労働者の派遣）は例外を除き禁止、港湾運送・建設・警備・病院等における医療関係などの業務への派遣は禁止とされています。

指示内容を固定する

あなたは人材派遣会社で、派遣先から届いた受注のメールを受注票にそろえる担当です。
メールの本文と添付に書かれていることだけを使ってください。推測で埋めないでください。

【受注票の項目】{項目の定義}
【派遣先マスタの情報】{派遣先名、事業所、就業場所の住所、抵触日の通知の受領日}
【直近の受注（参考）】{直近3件の受注票}

【取り出し方】
- 項目ごとに value と、根拠にした本文の文をそのまま evidence に写してください。
- 書かれていない項目は status を missing にしてください。
  直近の受注の値で埋めないでください。
- 本文に「前回と同じ」などとある場合だけ、直近の受注の値を candidate に入れ、
  status を same_as_previous にしてください。
  今回のメールに別の値が書かれている項目は、changed に挙げてください。
- 人数や期間に幅がある場合は、幅のまま写し、確認事項に挙げてください。
- 時給・人数・時間を計算したり換算したりしないでください。

【注意の印】
- 年齢・性別の限定、事前の面接・顔合わせ、履歴書の事前提出の依頼があれば
  flags に「特定行為のおそれ」を入れ、その条件を受注票の項目に写さないでください。
- 港湾運送、建設、警備、病院等の医療関係の業務と読める記載があれば「禁止業務のおそれ」。
- 派遣期間が30日以内と読める場合は「日雇派遣のおそれ」。
- 抵触日の通知の受領日が空なら「抵触日の通知なし」。
- 特定のスタッフの指名があれば「指名あり」。
- 法令に違反するかどうかの結論は書かないでください。

【確認の返信案】
- flags が空のときだけ作ってください。
- missing の項目と、幅のある項目、changed の項目だけを、箇条書きで丁寧に聞いてください。
- 受注を引き受けた、手配を約束した、と読める文を書かないでください。
- 件名の先頭に受注番号 {受注番号} を入れてください。

【メールの本文】{本文}
【添付の内容】{添付}

「直近の受注の値で埋めない」を明記しないと、空欄がほとんど無い受注票が出ます。 一見よくできているように見えますが、今回のメールに書かれていない値が前回から入り込んでいます。 same_as_previous と candidate に分けておけば、担当営業がどれを前回から引いたかを一目で見分けられます。

「flags が空のときだけ返信案を作る」のは、注意の印が付いた受注の返信は人が一から書くべきだからです。 年齢の限定を含む受注に、AIが他の項目だけを丁寧に聞く返信を作ると、限定を受け入れたように読めてしまいます。

出力形式を固定する

次の形のJSONで受け取ります。 形は Claude API の構造化出力で固定します。構造化出力は output_config.format に json_schema を渡して使い、スキーマに沿った応答が返るとされています。Make では、Anthropic Claude のアプリの Make an API Call で呼びます。

{
  "order_no": "J-2026-1043",
  "client_code": "C0217",
  "items": [
    { "name": "working_hours", "value": "9:00〜17:30（休憩60分）",
      "status": "ok | missing | same_as_previous | from_master",
      "candidate": "", "evidence": "就業時間は9時から17時半、昼休み1時間です" }
  ],
  "changed": [ { "name": "hourly_rate", "previous": "1,600円", "now": "1,700円" } ],
  "to_confirm": ["時間外労働の有無と上限", "指揮命令者の部署と役職"],
  "flags": [],
  "reply_draft": ""
}

1つ目の理由は、status で担当営業の確認の順番が決まることです。 missing と same_as_previous を先に見て、ok は根拠の文を流し読みすれば足ります。

2つ目は、flags でルーターの経路を分けられることです。 flags が空でなければ注意の経路、to_confirm が空でなければ返信案の経路、どちらも空なら担当営業の確認だけ、と規則で決まります。

3つ目は、changed で前回からの変更が見えることです。 時給や就業時間の変更は、請求とスタッフの給与の両方に響きます。変更の一覧を受注台帳の別の列に置き、請求の担当にも見えるようにします。

システムへ連携する

スタッフの管理システムへは書き込みません。 受注票が「手配可」になってから、コーディネーターが管理システムに入れます。確認が済んでいない受注で手配が動き出さないように、経路を分けておきます。

返信は下書きまでにします。 Make の Gmail のモジュールにはメールを送るものもありますが、この構成では使いません。

人が確認する

すべての受注票を担当営業が確かめてから「手配可」にします。

1. missing と same_as_previous を先に見る … 前回から引いた値が今回もそのままでよいかを、必要なら派遣先に確かめます
2. changed を見る … 時給や時間の変更が、請求と給与の担当に伝わるようにします
3. 返信案を直して送る … 聞く項目に漏れが無いか、聞き方が失礼でないかを見ます
4. 注意の印は派遣元責任者が対応を決める … 年齢・性別の限定や事前面接の依頼には、派遣先への説明の仕方を決めて、人が返信を書きます
5. 項目がそろったら「手配可」にする … コーディネーターはこの印を見て手配を始めます

4番目を省かないでください。 注意の印が付く受注は月に数件ですが、ここで受けてしまうと、その後の手配がすべてその条件で進みます。

目標は、1件あたり6分です。 受注票と根拠の文の確認、返信案の手直しに5分、注意の印と前回からの変更の確認に1分という想定です。

例外に対処する

いちばん上の行が、始めた直後にいちばん多く起きます。 派遣先の担当は替わりやすく、現場の責任者が直接送ってくることもあります。フォールバックに入るたびにマスタにアドレスを足せば、数か月で減っていきます。

記録を残す

• 受け取ったメールの本文と添付（Gmail に残る）と、受注番号との対応
• AIが返したJSON（項目、根拠の文、changed、to_confirm、flags）
• 担当営業が直した受注票の確定版と、直した項目
• 返信を送った日時と、派遣先から返事が来た日時
• 注意の印の付いた受注と、派遣元責任者が決めた対応
• 「手配可」にした日時と、した人

5つ目の記録は、後から説明を求められたときの材料になります。 年齢の限定を含む受注にどう対応したかが残っていれば、派遣元として協力していないことを示せます。