税理士・社会保険労務士の事務所で、顧問先ごとの決算月と届出の状況から翌月の期限を洗い出し、顧問先ごとの案内メールの下書きを毎月作る

処理の起点を決める

毎月18日の朝に動かします。 ClockTriggerBuilder の onMonthDay(18) と atHour(7) で組みます。18日にしているのは、担当者が19日から下書きを確かめ、20日ごろに送れるようにするためです。 月の初めに送ると早すぎて顧問先が忘れ、月末だと資料の準備が間に合いません。

nearMinute() を指定しなければ分は任意に決まり、atHour() で指定した時刻のあたりで動きます。朝のうちに終わればよいので、ずれは問題になりません。

1回の実行は6分までです。 150社分の期限の洗い出しは数秒で終わりますが、OpenAI API を150回呼ぶと6分を超えることがあります。 そこで、期限の洗い出しと案内の作成を分け、案内は担当者ごとに分けた5回の実行で作ります。最初の実行が終わるたびに、after() で次の実行を予約します。

入力データを集める

質を決めるのは、前回の連絡の備考です。 「前回、賃金台帳の送付が期限の2日前だった」「経理の担当が替わった」「メールより電話を好む」といった、担当者の頭の中にあった顧問先ごとの事情を、ここに一言ずつ書いておきます。AIが顧問先ごとに書き分ける材料は、この欄しかありません。

期限の表の「当てはまる条件」は、顧問先の一覧の列の名前で書きます。 「決算月＝翌月の2か月前」「納期の特例＝あり かつ 翌月＝7月」「36協定の有効期間の終わり＝翌月中」のような書き方です。条件をコードではなく表で読むことで、事務所の税理士や社会保険労務士が自分で規則を足せます。

期限の表は、たとえば次のような行になります。

36協定の行の「期限」は、有効期間の終わりの日として置いています。 次の有効期間が始まるまでに届出を済ませる必要があるので、事務所の作業の締めとして終わりの日を使い、送付の目安を早めに取ります。 どこを期限として案内するかは、事務所の社会保険労務士が決めます。

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

すべて同じスプレッドシートの中にあるので、SpreadsheetApp で読むだけです。外から取ってくるデータはありません。

休日の表は、事務所で毎年12月に翌年分を入れます。 祝日はカレンダーから取ることもできますが、どの日を休日として扱うかを事務所の表で持つほうが、期限の根拠を後から説明できます。

OpenAI API は UrlFetchApp.fetch() で呼びます。 method を post、contentType を application/json、headers にAPIキー、muteHttpExceptions を true にして、失敗したときも応答の中身を読めるようにします。

AIへ渡す前に整形する

1. 翌月の暦を作る … 翌月の日付ごとに、土日か、休日の表にあるかの印を付ける
2. 期限を洗い出す … 顧問先ごとに、期限の表の規則を上から当てはめ、当たった規則と期限の日付を出す
3. 期限を休日の翌日にずらす … 期限が土日・休日に当たるものを、次の平日に動かす。ずらしたかどうかを残す
4. 送付の目安日を出す … 期限の何日前に資料を送ってほしいかを、期限の表から計算する。目安日も休日なら前の平日にする
5. 一覧の食い違いを分ける … 従業員数が10人以上なのに納期の特例が「あり」、36協定の有効期間の終わりが空欄、決算月が空欄、などを確認事項にする
6. 期限の無い顧問先を分ける … 翌月に当たる規則が1つも無い顧問先には案内を作らない

3番目と4番目で、ずらす向きが逆なことに注意してください。 期限は後ろへずらし、顧問先に頼む送付の目安日は前へずらします。目安日を後ろへずらすと、事務所の作業の日数が減ります。

5番目の食い違いは、AIに渡しません。 「特例の要件に当たらなくなったかもしれない」という話は、担当者が顧問先に確かめてからする話で、案内のメールで先に伝えることではありません。

AIに処理させる

させるのは、顧問先ごとに、式で出した期限と資料の一覧を、案内メールの件名と本文にすることだけです。

1行目がいちばん大事な線引きです。 決算月を見て「申告の期限は○日ですね」とAIが自分で計算すると、延長の届出がある顧問先や、休日でずらした期限で外れます。期限の日付は渡したものを写すだけにし、その写し間違いも7番目で式と突き合わせます。

指示内容を固定する

あなたは税理士・社会保険労務士の合同事務所の担当者として、
顧問先に翌月の期限を案内するメールの下書きを作ります。

【すること】
- 渡された「期限の一覧」を、日付の早い順に並べて本文に書く
- 期限ごとに、用意してほしい資料と、事務所への送付の目安日を書く
- 「前回の連絡の備考」に書かれた事情があれば、本文の最後に一言添える
- 件名は「【{翌月}の期限のご案内】{顧問先名}様」とする

【厳守事項】
- 期限の日付と送付の目安日は、期限の一覧に書かれた文字列をそのまま写してください。
  日付を計算し直したり、曜日を書き足したりしないでください。
- 期限の一覧に無い期限や手続を書き足さないでください。
- 税額、還付、手続をしなくてよいかどうかなど、判断を伴うことを書かないでください。
- 備考から読み取れない事情を推測で書かないでください。
  確かめたいことがあれば、本文には書かずに questions_for_staff に入れてください。
- 敬語は丁寧に、ただし1通の本文は400字程度までにしてください。
- mentioned_items には、本文に書いた期限ごとに item_id と、本文に書いた日付の文字列を
  そのまま入れてください。

【顧問先】{client_name}（{client_type}）
【担当者】{staff_name}
【期限の一覧】{deadline_items}
（item_id、期限の名前、期限の日付、休日でずらしたか、用意してほしい資料、送付の目安日）
【前回の連絡の備考】{notes}

「曜日を書き足さない」まで書くのは、AIが親切のつもりで曜日を足すからです。 日付は正しくても、曜日だけが外れた案内が顧問先に届きます。曜日が要るなら、式で出して期限の一覧に入れて渡します。

mentioned_items を返させるのは、7番目の突き合わせのためです。 本文から日付を正規表現で拾うより、AIに「どの期限をどの日付で書いたか」を別に申告させ、本文にその文字列があるかと、式の日付と一致するかの両方を確かめるほうが確実です。

出力形式を固定する

次の形のJSONで受け取ります。 Responses API の text.format に type: "json_schema"、strict: true で渡し、オブジェクトにはすべて additionalProperties: false を付け、すべての欄を required にします。

{
  "client_id": "C-0412",
  "subject": "【11月の期限のご案内】株式会社○○様",
  "body": "",
  "mentioned_items": [
    { "item_id": "CORP_TAX_RETURN", "date_text": "11月30日" },
    { "item_id": "WITHHOLDING_MONTHLY", "date_text": "11月10日" }
  ],
  "questions_for_staff": []
}

JSONで受ける1つ目の理由は、日付の突き合わせを機械でできることです。 Apps Script は次の3つを確かめ、1つでも外れたら下書きにしません。

2つ目の理由は、questions_for_staff を本文と分けられることです。 備考から読み取れない事情を本文に書かせると、推測が顧問先に届きます。質問は確認の一覧の別の列に出し、担当者が答えてから必要なら本文に足します。

断られた場合は、refusal が output_text の代わりに返るとされています。 応答が途中で切れた場合（incomplete）も含めて、JSONとして読めなかったものは下書きにせず、担当者へ回します。

システムへ連携する

顧問先の一覧には書き込みません。 送った記録は確認の一覧の側に残し、顧問先の一覧を直すのは業務管理の担当と担当者です。 食い違いを見つけても、一覧を自動で書き換えることはしません。

下書きの replyTo には担当者のアドレスを入れます。 顧問先が返信すると、共有アドレスではなく担当者に届きます。資料の送付の連絡が担当者に直接届くほうが、その後のやり取りが早く済みます。

人が確認する

1. 確認の一覧で、担当者へ回されたものを先に見る … 日付の突き合わせで外れたもの、JSONとして読めなかったもの。手で書くか、作り直します
2. 一覧の食い違いを見る … 納期の特例の要件、36協定の有効期間の空欄など。顧問先に確かめてから、顧問先の一覧を直します
3. 担当者への質問に答える … 答えた内容を必要なら本文に足します
4. 下書きを読んで送る … 期限の一覧と見比べ、顧問先ごとの一言が当たっているかを見ます
5. 送った後に、前回の連絡の備考を更新する … 次の月の下書きの材料になります

5番目を省かないでください。 備考が更新されないと、毎月同じ一言が添えられた案内が届きます。 顧問先はそれで、事務所が自動で送っていることに気づきます。

担当が替わった月は、引き継いだ担当者が備考を先に読みます。 下書きに添えられた一言は前の担当者が残した備考から来ているので、新しい担当者が顧問先とまだ話していない内容が、本文に入っていることがあります。 その一言は、あいさつを兼ねて自分の言葉に直してから送ります。

目標は、1社4分です。 下書きを読み、期限の一覧と見比べて送るだけで済む状態にします。4分で終わらない担当者は、受け持ちの顧問先の備考が空か、一覧の食い違いが多いかのどちらかです。

例外に対処する

上の3行が、最初の数か月に多く出ます。 顧問先の一覧の空欄は、これまで担当者の頭の中で補われていたものです。案内の作成が止まることで、一覧の空欄が初めて見えるようになります。 埋めるたびに、翌月から止まる件数が減ります。

記録を残す

• 顧問先ごと・月ごとに、当てはまった規則の番号と期限の日付、休日でずらしたかどうか
• AIに渡した期限の一覧と、AIが返したJSONの全文
• 日付の突き合わせの結果（一致／外れた項目）
• 担当者が下書きを直したかどうかと、直した箇所の要約
• 送った日と、送った担当者
• 一覧の食い違いと、確かめた結果

1つ目で規則の番号を残すのは、期限の根拠を後から説明するためです。 顧問先から「なぜこの日なのか」と聞かれたときに、どの規則を当て、休日でずらしたのかを示せます。 期限の表の規則を直したときも、どの顧問先に影響したかを追えます。

4つ目は、プロンプトを直す材料です。 同じ直しが何度も出ていれば、指示か期限の表の書き方を変えます。