税理士事務所が顧問先から毎月集める通帳・領収書・請求書の提出状況を Make で追い、顧問先ごとの不足の一覧と催促の文面を作る

処理の起点を決める

毎月5日・10日・15日の朝8時に動かします。 Make のシナリオのスケジュールには、一定の間隔、1回、毎日、平日、毎週、毎月、日付の指定、手動などの選択肢があり、日付の指定か毎月で、月の決まった日に動かせます。 書類が上がるたびに動かす作りにはしません。催促は顧問先にとって決まった日に来るほうが分かりやすく、担当者も決まった日の朝に下書きをまとめて見られるからです。

巡回の前の確認を1回足します。 巡回監査のある顧問先は、予定日の3営業日前にも数えます。毎日朝に動くシナリオを別に作り、提出状況表の巡回の予定日が3営業日後の顧問先だけを処理します。

担当者が手で動かせるようにもしておきます。 顧問先から「いま上げた」と電話があったときに、その顧問先だけを数え直せるよう、提出状況表の顧問先の行に「再確認」の欄を置き、手動で動くシナリオがその行だけを処理します。

入力データを集める

質を決めるのは、必要書類の一覧です。 「通帳」とだけ書くのではなく、口座ごとに1行を作り、種類のフォルダも口座ごとに分けます。 口座が3つの顧問先で通帳のフォルダが1つだと、1つ上がっただけで「届いた」になります。数え方は一覧の作り方でしか正しくなりません。

催促を止める印を持たせます。 「今月は休業」「決算の資料は別に預かる」「社長が入院中」のように、催促してはいけない事情がある顧問先です。印が付いた顧問先は、数えるだけで下書きを作りません。 理由は担当者が書きます。

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

Search Rows には、1回の実行で返す件数の上限（Limit）があります。 公式の説明では、Limit は1回の実行サイクルで返す結果の最大の数とされています。240件の顧問先を1回で処理するなら、Limit を顧問先の数より大きくしておきます。 小さいままだと、表の後ろの顧問先が黙って処理されません。

Gmail の検索は、顧問先の連絡先と日付で絞ります。 本文は先頭の500文字だけを取り、添付と署名より後は渡しません。 AIが要るのは「いつ・何と返事があったか」で、メールの全文ではありません。

ファイルの中身は取りません。 数えるのはファイルの有無と数だけです。書類の中身をAIに渡さないことで、顧問先の口座の明細や取引先の名前が外へ出る経路がなくなります。

AIへ渡す前に整形する

1. 月のフォルダの有無の確認 … フォルダが無ければ「フォルダ未作成」として担当者の一覧に載せ、下書きを作りません
2. 不足の決定 … 必要書類の一覧の行ごとに、種類のフォルダのファイルが1つ以上あれば「届いた」、無ければ「未着」とします。任意の書類は不足に入れません
3. 催促を止める印の確認 … 印が付いていれば、数えて書き込むだけにします
4. 催促の回数の決定 … 今月の催促の数を提出状況表から取り、今回が何回目かを決めます
5. 巡回までの日数の計算 … 巡回の予定日までの営業日の数を出します。日数の計算はシナリオの式で行い、AIに渡すのは結果の数だけです
6. 前回の返事の整形 … 届いた日時と本文の先頭500文字にし、引用の行（「>」で始まる行）を落とします

2番目をシナリオの式で決めるのが、いちばん大事です。 不足の一覧は催促の中身そのものです。ここが1つずれると、届いている書類を催促するメールの下書きができ、担当者が直さずに送れば顧問先の信頼を失います。 式なら、同じフォルダには必ず同じ答えが出ます。

AIに処理させる

させるのは、決まった不足の一覧と事情を受け取り、顧問先ごとの催促のメールの件名と本文、担当者向けのメモを書くことです。

4行目の調子は、段階を事務所が決めます。 1回目は「ご案内」、2回目は「再度のお願い」、3回目以上か巡回まで3営業日以内なら「巡回に間に合わせるためのお願い」。AIに調子を任せると、回数が増えるほど言葉が強くなりすぎるか、逆にいつまでも丁寧すぎるかのどちらかに寄ります。

4行目が、いちばん起きやすい失敗です。 前回の返事が「バタバタしていてすみません」だけでも、AIは気を利かせて「近日中にお送りいただけるとのことで」と書きます。顧問先が言っていない約束を、事務所の側が書くことになります。

指示内容を固定する

あなたは税理士事務所の職員として、顧問先へ月次の書類の提出をお願いする
メールの下書きを書きます。下の情報だけを使ってください。推測で補わないでください。

【書くもの】
- subject：件名。「{year_month}分 ご提出のお願い」を基本にし、
  下の「調子の段階」に合わせて言葉を選んでください。
- body：本文。呼びかけ、不足の書類の一覧、期限、上げ方、署名の順に書いてください。
- staff_note：担当者だけが読むメモ。前回の返事に事情が書かれていれば
  要点を1〜2文で書いてください。無ければ空にしてください。

【調子の段階】{tone_level}
- 1：ご案内として、短く丁寧に。
- 2：再度のお願いとして。前回の案内に触れる。
- 3：巡回に間に合わせるためのお願いとして。巡回の日と、そろわない場合に
  巡回の場で記帳が終わっていない状態になることを、責める言い方を避けて書く。

【厳守事項】
- 不足の書類は、下の「不足の一覧」のとおりに、1行ずつ並べてください。
  書類を足したり、減らしたり、まとめたり、言い換えたりしないでください。
- 期限と巡回の日は、下に書かれた日付をそのまま使ってください。
  ほかの日付を書かないでください。
- 前回の返事に、送る日や時期の約束が書かれていれば、それに触れてください。
  約束が書かれていなければ、約束があったように書かないでください。
- 前回の返事の意味が読み取れない場合は、本文で触れず、staff_note に
  「返事の意味を確認してください」と書いてください。
- 延滞の料金、契約の解除、罰則をにおわせる言い回しを使わないでください。
- 「使わない言い回しの一覧」にある言葉を使わないでください。
- 署名は下の「署名」をそのまま使ってください。

【顧問先の呼びかけ】{salutation}
【不足の一覧】{missing_items}
【期限】{due_date}
【巡回の予定日】{visit_date}（巡回まで {days_to_visit} 営業日）
【今月の催促の回数】今回が {reminder_no} 回目
【前回の返事】{last_reply}
【上げ方の案内】{upload_guide}
【使わない言い回しの一覧】{ng_phrases}
【署名】{signature}

「書類を足したり、減らしたり、まとめたり、言い換えたりしない」を明記しないと、一覧が整理されます。 「〇〇銀行の通帳」と「△△銀行の通帳」を「各銀行の通帳」にまとめると、顧問先はどの口座が足りないのか分からず、全部をもう一度上げ直します。

「約束があったように書かない」は、前の節で挙げた失敗を止める1行です。 禁止だけでなく、読み取れないときの行き先（staff_note）を用意すると、AIが本文で補わずにメモへ回します。

調子の段階を数字で渡しているのは、段階の判断をシナリオに置くためです。 回数と巡回までの日数から段階を決める式はシナリオにあり、事務所が方針を変えるときは式を直すだけで済みます。

出力形式を固定する

次の形のJSONで受け取ります。 Make an API Call で Messages API を呼び、output_config.format に type: "json_schema" で次の形を指定します。

{
  "subject": "",
  "body": "",
  "staff_note": "",
  "mentioned_promise": true
}

構造化出力は、いまの公式の書き方に合わせます。 公式の説明では、スキーマを output_config.format に type: "json_schema" で渡すとされ、以前の output_format の指定は非推奨で、いずれ使えなくなるとされています。また、スキーマでは数値の minimum・maximum、文字列の minLength・maxLength などに対応していないとされているので、件名の長さの上限はスキーマに書かず、シナリオの側で確かめます。

JSON にする理由の1つ目は、Gmail の下書きにそのまま入れられることです。 subject を件名へ、body を本文へ入れます。自由文で受けると、件名と本文の切れ目をシナリオで探すことになります。

2つ目は、staff_note を顧問先へのメールから切り離せることです。 担当者向けのメモが本文に混ざると、「社長がご入院中のため」のような事務所の内側の言葉が顧問先へ届きます。 別の項目にしておけば、メモは担当者への一覧にだけ載ります。

3つ目は、mentioned_promise で照合できることです。 前回の返事が空なのに true が返れば、本文で約束を作った疑いがあるので、担当者への一覧に「本文の確認を」と印を付けます。

シナリオの側で、本文に不足の一覧の書類名がすべて含まれるかを確かめます。 1つでも欠けていれば、下書きを作らずに担当者への一覧に「不足の一覧と本文が合わない」と載せます。

システムへ連携する

顧問先の処理の振り分けは Router で行います。 Router はシナリオの流れを複数の経路に分け、経路は並行ではなく順に処理されるとされています。経路ごとにフィルタを置き、「不足なし」「催促を止めている」「不足あり」に分けます。どの条件にも当たらない顧問先は、フォールバックの経路で担当者の一覧に「状況を確認してください」と載せます。

担当者への一覧は Aggregator でまとめます。 集約は複数のバンドルを1つにまとめ、Group by に式を入れると、その値ごとに1つのバンドルを出すとされています。担当者のメールアドレスで Group by し、担当者ごとに1通の一覧を送ります。

会計ソフトには触りません。 書類が届いた後の記帳は、これまでどおり担当者が行います。

人が確認する

人が見るのは、次の3つの場面です。

1. 担当者が下書きを開いたとき（全件） … 不足の一覧と本文、前回の返事への触れ方を確かめ、直して送るか、送らないかを決めます
2. staff_note に事情が書かれた顧問先 … 入院・休業・担当の交代などの事情があれば、催促を止める印を付けるか、電話に切り替えるかを決めます
3. 担当者への一覧で印が付いたもの … 「フォルダ未作成」「不足の一覧と本文が合わない」「本文の確認を」の印の付いた顧問先を見ます

送信を自動にしないのは、催促が顧問先との関係そのものだからです。 不足の数え方が正しくても、顧問先がいま催促を受けたくない事情は、フォルダにも提出状況表にも出てきません。 担当者が下書きを読む数分が、その事情に気づく最後の機会です。

目標は、240件をならして1件4分です。 不足が無い顧問先は担当者の手が動かず、下書きを読んで送るだけの顧問先は1〜2分、staff_note に事情がある顧問先や印の付いた顧問先は10分ほどかかります。4分を大きく超える月は、必要書類の一覧が実態とずれています。

例外に対処する

下から1行目は、黙って起きる失敗です。 表の後ろの顧問先が処理されなくても、エラーは出ません。処理した顧問先の数を毎回数えて一覧の先頭に載せれば、240件に届かない日にすぐ気づきます。

記録を残す

• シナリオが動いた日時と、処理した顧問先の数
• 顧問先ごとの種類別の「届いた／未着」と、そのときのファイルの数と最終の更新日時
• AIに渡した不足の一覧・調子の段階・前回の返事の先頭と、返ってきたJSONの全文
• 下書きを作ったか、作らなかったならその理由
• 担当者が送ったか、送らなかったか、本文をどれくらい直したか
• 催促を止める印を付けた日と理由

5つ目は、文面の決まりを育てる材料です。 担当者が毎回同じところを直しているなら、署名や呼びかけ、使わない言い回しの一覧が足りていません。送らなかった下書きが多い顧問先は、催促より電話のほうが合っている顧問先です。