社会保険労務士事務所に顧問先からメールで届く依頼を入退社の手続き・給与計算・相談・証明書の発行などに分類して担当者のタスクにし、足りない情報を聞き返す文案を作る

処理の起点を決める

共有のアドレスにメールが届いたことを起点にします。 Gmail の側で、顧問先のドメインから届いたメールに「受付」のラベルを付けるフィルタを作り、Watch emails はそのラベルだけを見ます。営業のメールや配信のニュースが分類に紛れ込まないようにするためです。

シナリオは十数分おきに動く設定にします。1日に3回まとめて開いていた共有のアドレスが、届いて十数分で台帳に載るようになります。月末と月初の偏りにも、1回あたりの件数（Limit）で対応します。

同じスレッドの返信も起点になります。 聞き返したメールに顧問先が返事をくれたとき、それも新しいメールとして拾い、元の依頼の行に「返信あり」を付けて足りない情報が埋まったかを確かめます。 新しい依頼として二重に登録しないよう、スレッドの識別子を台帳に持たせます。

顧問先のドメイン以外から届いたメールは、ラベルが付かず、これまでどおり受付の担当が読みます。 新しい顧問先の担当者が個人のアドレスから送ってくることもあるので、ラベルの付かなかったメールを1日1回眺める時間を受付の担当の手順に残します。

入力データを集める

質を決めるのは、チェックリストの表です。 例えば入社の手続きなら、氏名、生年月日、入社日、雇用形態、所定労働時間と日数、報酬の見込み、扶養する家族の有無、基礎年金番号またはマイナンバーの提出の方法、と並べます。この表が無いと、生成AIは「一般的に必要そうな情報」を挙げ、事務所のやり方と合わない聞き返しになります。

契約の範囲も持たせます。 手続きだけを受けている顧問先から給与計算の依頼が届いたら、分類は「給与計算」にしつつ、台帳に「契約の範囲外」の印を付けて主担当に回します。 断るか受けるかは事務所が決めます。

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

顧問先の特定は、送り主のアドレスで引きます。 署名の社名から推し量らせると、グループ会社の名前の似た顧問先を取り違えます。 一覧に無いアドレスからのメールは、生成AIに渡す前に「顧問先不明」として受付の担当に回します。

添付のファイルは、この構成では中身を読みません。 入社の連絡に履歴書や雇用契約書が付いてくることがありますが、生成AIに渡すのは本文だけにします。 添付があることは台帳に印を付け、主担当が開きます。

AIへ渡す前に整形する

1. 引用と署名を外す … 返信のメールに付いてくる過去のやり取りの引用と、署名の部分を外し、新しく書かれた部分だけにします
2. マイナンバーらしき数字の並びを伏せ字にする … 12桁の数字の並びを伏せ字にしてから生成AIに渡します。伏せ字にしたことは台帳に印を付けます
3. 長さを確かめる … 引用を外しても極端に長いメールは、分割せずに受付の担当へ回します
4. 自動の通知を外す … 顧問先の勤怠のシステムから自動で届く通知は、分類せずに給与計算の担当のフォルダへ移します

引用を外すときは、「-----Original Message-----」「〇〇様 wrote:」のような区切りの行や、行頭の「>」を目印にします。区切りの書き方はメールのソフトによって違うので、外し方は顧問先のメールを見ながら足していきます。 外しきれずに過去の依頼が残ると、同じ依頼が二重に台帳に載ります。

2番目を軽く見ないでください。 顧問先には、マイナンバーをメールの本文に書かないよう案内していても、入社の連絡に書き込んで送ってくることがあります。 伏せ字にしたうえで、受付の担当が顧問先に「別の方法で提出してください」と伝えます。

AIに処理させる

させるのは、メールの中の依頼を1件ずつに分け、決めた種類のどれかに分類し、チェックリストに照らして本文に書かれている情報と書かれていない情報を分けることです。

「証明書の発行」は、誰が出す証明かで中身が変わります。 事業主が出す在職の証明を事務所が文案だけ作るのか、事務所が手続きの控えを探して送るのかは、顧問先との契約で決まっています。生成AIには種類を付けさせるだけにし、どちらの作業かは主担当が台帳を見て決めます。

分類は1件に1つだけにします。 「入社の手続きで、あわせて給与の設定も」のような依頼は、入社の手続きと給与計算の2件に分けます。 1件に2つの種類を付けると、台帳で担当が決まりません。

1行目がいちばん起きやすい誤りです。 「週20時間のアルバイトが入ります」という連絡に、生成AIは「雇用保険の加入が必要です」と書き添えがちです。加入の要否は、労働時間だけでなく雇用の見込みや事業所の状況で決まり、判断を誤ると顧問先に誤った案内が届きます。 下書きにも要否は書かせず、「所定労働時間と雇用の見込み期間を教えてください」と尋ねるだけにします。

指示内容を固定する

Make an API Call で送る要求の本文の、指示の部分を次のように書きます。

あなたは社会保険労務士事務所の受付で、顧問先から届いたメールを
手続きの種類ごとに仕分ける担当です。

【顧問先】{client_name}（契約の範囲：{contract_scope}）
【メール本文】{body_without_quotes}
【種類とチェックリスト】{checklists}

【やること】
1. メールの中の依頼を1件ずつに分ける。1件に1つの種類だけを付ける。
2. 種類を hire / leave / change / payroll / certificate / consultation / other から選ぶ。
3. 対象の従業員の氏名と、依頼に書かれた日付（入社日、退職日、変更日など）を写す。
4. チェックリストの項目ごとに、本文に書かれていれば provided、
   書かれていなければ missing にする。
5. missing がある依頼について、顧問先に聞き返すメールの文案を作る。

【厳守事項】
- 日付、氏名、金額は本文に書かれた文字をそのまま写してください。
  書かれていない情報を、前後の文から推測して埋めないでください。
- 「来月1日」のような書き方は、そのまま写してください。日付に直さないでください。
- 手続きが必要かどうか、保険に加入するかどうかを書かないでください。
- 相談の内容に回答しないでください。consultation に分類し、質問の要点だけを書いてください。
- 聞き返す文案には、missing の項目を尋ねる文だけを書いてください。
  手続きの要否や期限の説明を書かないでください。
- 伏せ字（■）の部分を推測しないでください。
- 迷ったときは other にし、reason に迷った理由を書いてください。

「来月1日を日付に直さない」を書くのは、メールの日付と受信の日付がずれるからです。 月末の夜に書かれて月初に届いたメールの「来月1日」は、受信日から数えると1か月ずれます。日付への直しは、受信日時とあわせて受付の担当が確かめます。

「聞き返す文案に missing を尋ねる文だけ」も大事です。 何も言わなければ、生成AIは丁寧さのつもりで「この方は社会保険の加入対象となりますので」と書き添えます。顧問先はその一文を事務所の判断として受け取ります。

出力形式を固定する

Messages API の JSON outputs（output_config.format に type: "json_schema"）で、次の形を返させます。

{
  "requests": [
    {
      "category": "hire | leave | change | payroll | certificate | consultation | other",
      "employee_name": "", "date_text": "",
      "summary": "",
      "checklist": [ { "item": "", "status": "provided | missing", "value": "" } ],
      "reason": ""
    }
  ],
  "ask_back_draft": "",
  "contains_masked_number": false
}

公式の説明では、JSON outputs は制約付きのデコードでスキーマに合った応答を返し、必須の項目と型が保証されるとされています。読み取りの失敗でシナリオが止まらず、requests の要素をそのまま台帳の行に割り当てられます。

1つ目の理由は、requests を配列にすることで、1通に複数の依頼があっても漏れないことです。 Make の側で配列を1件ずつ台帳の行にします。第3章の（a）の扶養の追加は、ここで2行目として残ります。 配列が空で返ってきたメール（依頼が見つからなかったもの）も捨てずに、受付の担当の確認の欄に1行残します。 お礼だけのメールに見えて、末尾に依頼が書かれていることがあるからです。

2つ目は、category から割り振りと期限を規則で決められることです。

3つ目は、checklist の missing を数えて、着手できる依頼と待ちの依頼を分けられることです。 台帳には「着手可」「情報待ち」の列を作り、missing が0件の依頼だけを主担当がすぐに着手できる依頼として並べます。

システムへ連携する

台帳への書き込みは、依頼ごとに1行です。 列は、受信日時、顧問先、種類、対象の従業員、日付の文字、期限の目安、主担当、着手可／情報待ち、足りない情報、スレッドの識別子、受付の担当の確認です。メール1通を1行にすると、第3章の（a）が台帳の上で再発します。

主担当への通知には、本文を貼りません。 台帳の行へのリンクと、種類・顧問先・着手可か情報待ちかだけを送ります。社内チャットに従業員の個人情報が流れて残ることを避けるためです。

下書きの件名には、元のメールの件名と顧問先の名前を入れます。 受付の担当が下書きの一覧から、どのメールへの聞き返しかをすぐに見分けられるようにします。

人が確認する

1. 台帳の新しい行を見る … 種類と主担当、対象の従業員、日付の文字が本文と合っているかを確かめます
2. 日付を確かめる … 「来月1日」「今月末」のような書き方を、受信日時とあわせて日付に直します。期限の目安はここで確定します
3. 下書きを直して送る … 聞き返す内容が足りているか、事務所の言い回しになっているかを見て送ります
4. other と顧問先不明を処理する … 迷ったものと、一覧に無いアドレスからのものを読んで振り分けます
5. 分類を直したら記録する … どの種類からどの種類に変えたかを残します

2番目を省かないでください。 期限の目安は日付から計算します。日付を取り違えると、5日以内の届出の期限が1か月ずれて台帳に載ります。

目標は、900件をならして1件2分です。 分類が正しく足りない情報の無い依頼は数十秒で確かめ、聞き返しの下書きを直す依頼に数分かけます。

例外に対処する

上から2行目は、件数は少なくても扱いを決めておく必要があります。 伏せ字にしたことを台帳に残し、元のメールをどう保管するかを事務所の規程で決めておきます。

記録を残す

• 受信したメールの識別子と、生成AIに渡した本文（引用と署名を外し、伏せ字にしたもの）
• 生成AIが返したJSONの全文
• タスク台帳の行と、受付の担当が直した分類・日付・主担当
• 下書きと、実際に送ったメールの本文
• 聞き返してから返事が届くまでの日数

メールと台帳を残す期間も決めておきます。 届出の控えと同じく、後から「いつ連絡を受けたか」を問われることがあるからです。受信日時と、聞き返した日と、返事が届いた日が並んでいれば、期限に遅れた理由を顧問先に示せます。

3つ目を残すのは、チェックリストと指示を直すためです。 同じ種類の取り違えが続くなら、種類の名前か説明が実際の依頼と合っていません。月に1回、直された分類を数えて、表と指示を見直します。