行政書士事務所が顧客の建設業・産業廃棄物の許可の更新と決算変更届の期限を台帳から拾い、Apps Script と Claude で案内のメールの下書きを作る

処理の起点を決める

毎月1日の朝に1回動かします。 時間主導型のトリガーで onMonthDay(1) と atHour(7) を指定します。公式の説明では、atHour() の例が「5時〜6時の間に動く」と書かれ、nearMinute() を指定しないと分はランダムに決まります。 7時ちょうどに動く前提にはせず、職員が出勤する9時までに終わっていればよい作りにします。

1日が土日でも動かします。 下書きは Gmail に残るだけなので、職員が月曜に見れば足ります。営業日に合わせて動かす日を変える仕組みは作りません。 作ると、祝日の扱いで動かない月が出ます。

トリガーは、作った人のアカウントで動きます。 公式は、インストール型のトリガーは作成した人のアカウントで実行されるとしています。事務所の共用のアカウント（案内の送り主になるアカウント）で作ります。 職員個人のアカウントで作ると、下書きがその職員の Gmail に入り、退職や異動で止まります。

失敗しても画面には出ません。 トリガーで動いた処理が失敗すると、所有者に「Summary of failures for Apps Script」という件名のメールが届きます。共用のアカウントの受信箱を誰が見るかを決めておきます。 あわせて、処理ログのシートに「どの顧客の行で止まったか」を日本語で書きます。

月の途中で台帳を直したときのために、手で動かせる関数も用意します。 新しく受任した顧客の満了が近いと分かったとき、その顧客の行だけで下書きを作り直せるようにします。

入力データを集める

質を決めるのは、締切の設定と案内の記録です。 締切の設定が無ければ、「満了の何日前に書類をそろえれば間に合うか」を計算できません。案内の記録が無ければ、同じ段の案内を毎月作り続けます。

締切の設定は、法令の期限そのものではなく、事務所の都合を入れます。 建設業許可の更新の申請は満了の30日前までですが、事務所が書類を作って顧客に押印をもらうには、さらに数週間かかります。 「満了の60日前までに書類をもらう」のように、逆算した日を許可の種類ごとに入れます。

顧客の会社名と担当者の名前は台帳にありますが、AIには渡しません。 渡すのは段・許可の種類・書類の名前・顧客の区分だけで、宛名は下書きを作るときに Apps Script が差し込みます。

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

すべて同じスプレッドシートの中にあるので、Apps Script のスプレッドシートのサービスで読むだけです。 外のシステムから取ってくるものはありません。

段は次の規則で決めます。

決算変更届の期限は、事業年度の終わりから4か月以内です。 決算月の末日に4か月を足した日を期限とし、決算が終わって1か月ほどで税理士の決算書ができるころに案内を出します。 決算月を変えた顧客は、台帳の決算月を直さないと期限がずれます。

同じ顧客に複数の許可があれば、1通にまとめます。 建設業許可と、2つの都道府県の産業廃棄物の許可が同じ月に段に入ったなら、3つを1通の下書きの中で箇条に分けて書きます。 1許可1通にすると、顧客には同じ日に3通届きます。

AIへ渡す前に整形する

1. 状態で絞る … 「受任済み」と「不要」（廃業・許可の取り下げ）の行は外します
2. 段を決める … 満了の日と今日の差から、上の表の段を1つ決めます。複数の段に当たるときは、近いほうの段にします
3. 重複を外す … 案内の記録に同じ許可・同じ段の行があれば外します
4. 日付を計算する … 満了の日、申請の締切（建設業許可は満了の30日前）、依頼の締切（締切の設定から逆算）を yyyy年M月d日 の形にします
5. 依頼の締切が過ぎていないか見る … 過ぎていれば、その顧客は下書きを作らず「要電話」として確認の一覧に出します
6. 顧客ごとに束ねる … 同じ顧客の行を1つにまとめ、許可ごとの事実を並べます
7. 記号に置き換える … 会社名を {{会社名}}、担当者の名前を {{担当者}}、日付を {{満了日_1}} {{依頼締切_1}} のような番号付きの記号にします

5番目を省かないでください。 案内が何かの理由で遅れ、依頼の締切をもう過ぎている顧客にメールを送ると、「○日までにお送りください」と過ぎた日を書いた文面が届きます。 その顧客は、メールではなく電話で話す相手です。

7番目の記号に番号を付けるのは、許可が複数あるためです。 建設業許可の満了の日と、産業廃棄物の許可の満了の日を、どの箇条にどちらを書くかをAIに選ばせません。 箇条の順番と記号の番号を Apps Script の側で決めておきます。

AIに処理させる

させるのは、記号の入った事実の束から、案内のメールの件名と本文を作ることだけです。

AIに書かせないことのほうが大事です。

2行目がいちばん起きやすい失敗です。 AIは親切に「なお、更新には経営業務の管理責任者の要件を……」と書き足します。一般論としては正しくても、その顧客の事情に合うとは限らず、行政書士の確認を経ない法令の説明になります。 書いてよいのは、事実の束にある書類の名前と段の目的だけです。

指示内容を固定する

あなたは行政書士事務所の事務の職員として、顧客に送る案内のメールの下書きを書きます。
渡す「事実の束」だけを使って書いてください。

【書き方】
- 宛名は {{会社名}} {{担当者}} 様 と書いてください。名前を推測しないでください。
- 日付は、事実の束にある記号（{{満了日_1}} {{依頼締切_1}} など）をそのまま本文に置いてください。
  数字で日付を書かないでください。曜日も書かないでください。
- 許可が複数あるときは、事実の束の番号の順に箇条を分けてください。
  箇条1には _1 の記号だけ、箇条2には _2 の記号だけを使ってください。
- 用意する書類は、事実の束の documents にあるものだけを、そのままの名前で並べてください。
- 段（stage）ごとの目的：
  renewal_first …… 更新の時期が近いことと、これから書類をお願いすることを伝える
  renewal_request …… 用意する書類と、事務所に届けてほしい日（依頼締切）をはっきり伝える
  renewal_remind …… 締切が近いことを丁寧に伝え、状況を返信か電話で知らせてほしいと頼む
  annual_report …… 決算が終わったことにふれ、決算の書類の送付と期限を伝える
- 顧客の区分が new のときは、案内を事務所から送る理由を一文添えてください。

【書かないこと】
- 許可の要件、手続きの流れ、法令の条文の説明
- 報酬・費用・手数料の金額
- 「必ず更新できます」「問題ありません」のような請け合い
- 事実の束に無い書類、無い許可

【notes】
事実の束の中で食い違って見えるもの、文面を書くのに足りないものがあれば、
notes に短く書いてください。無ければ空の配列にしてください。

【事実の束】{facts_json}

「数字で日付を書かない」を明記しないと、AIは記号を値に見立てて「令和○年○月○日」と書き直すことがあります。 書き直された日付は、正しいかどうか誰にも分かりません。記号のまま返させ、値は後から機械が入れます。

「箇条1には _1 の記号だけ」も同じ理由です。 許可が2つあるとき、AIが満了の日の記号を入れ違えると、建設業許可の箇条に産業廃棄物の許可の満了の日が入ります。 検査で拾えるよう、箇条と記号の番号を対応させます。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 スキーマは output_config.format に type: "json_schema" で渡します。

{
  "subject": "建設業許可の更新と決算変更届のご案内",
  "body": "{{会社名}}\n{{担当者}} 様\n\nいつもお世話になっております。…\n\n1. 建設業許可（{{許可番号_1}}）\n 有効期間の満了日：{{満了日_1}}\n 書類のご送付のお願い：{{依頼締切_1}}まで\n ・…",
  "placeholders_used": ["{{会社名}}", "{{担当者}}", "{{満了日_1}}", "{{依頼締切_1}}"],
  "notes": []
}

構造化出力を使う理由は2つです。 1つは、件名と本文と使った記号を別の項目で受け取れることです。本文を正規表現で切り分けるより確実です。もう1つは、placeholders_used と事実の束の記号を突き合わせられることです。

スキーマに文字数の上限は書きません。 公式の説明では、文字列の長さの制約（minLength・maxLength）や数値の範囲の制約は非対応で、使うと400のエラーになります。 本文の長さは Apps Script の検査で見ます。組み立てたスキーマは最後に使ってから24時間保持され、初回の呼び出しだけ時間がかかります。

Apps Script の検査は次のとおりです。

3行目が、AIが日付を書いてしまったときの網です。 記号を置き換えた後の本文から、年・月・日 の並びと / 区切りの日付を拾い、事実の束にある日付と一つずつ照らします。 束に無い日付が1つでもあれば下書きは作りますが、確認の一覧で赤くします。

システムへ連携する

下書きは GmailApp.createDraft(recipient, subject, body, options) で作ります。 オプションには cc・bcc・replyTo・name などがあり、name に事務所名を入れて送り主の表示をそろえます。 Gmail の権限（https://mail.google.com/）が要るので、初回の承認は共用のアカウントで行います。

Claude API の鍵はスクリプトのプロパティに置きます。 コードに直接書くと、スクリプトを共有したときに鍵も渡ります。

呼び出しの回数は月に数十回です。 Apps Script の URL の取得の上限は個人のアカウントで1日20,000回、Workspace のアカウントで1日100,000回とされ、この構成で上限に当たることはありません。 気をつけるのは1回の実行が6分までという上限のほうで、顧客が多い月は途中で止まりえます。処理した顧客の行に印を付け、止まったら続きから動く作りにします。

人が確認する

1. 確認の一覧の「要確認」と「要電話」から見る … 記号の抜け、日付の食い違い、notes のある顧客。「要電話」は依頼の締切を過ぎた顧客で、メールは作っていません
2. 下書きの宛先を確かめる … 顧客の情報のメールアドレスが、担当者の交代で古くなっていないか
3. 日付と許可番号を台帳と見比べる … 置き換えた値が台帳の行と同じか。1通に許可が複数あるときは箇条ごとに見ます
4. 書類の一覧が段に合っているか見る … 顧客ごとの事情（役員の交代、営業所の移転）で書類が増えるなら書き足します
5. 送る … 職員が Gmail から送り、案内の記録に送った日を入れます

3番目を省かないでください。 検査は記号と日付の形を見ていますが、台帳の満了の日そのものが間違っていれば、正しく置き換えた間違った日付が届きます。 許可通知書の写しと台帳を年に1回見比べることとあわせて、送る前に一度は目で見ます。

目標は、60件をならして1件3分です。 「要確認」の無い下書きは2分ほどで読んで送れ、時間を使うのは要確認の数件と、書類を書き足す顧客です。

例外に対処する

1行目が、この構成でいちばん大事な分かれ道です。 締切を過ぎた顧客に機械的なメールを送ると、顧客は「まだ間に合う」と受け取ります。 間に合うかどうかは行政書士が都道府県の窓口の事情も含めて判断することで、メールの文面で決めることではありません。

記録を残す

• 実行の日時、読んだ台帳の行の数、段に入った許可の数、作った下書きの数
• 顧客ごとの事実の束（記号に置き換えた後のもの）と、Claude が返した JSON
• 検査の結果（記号の抜け・余り、日付の食い違い、notes）
• 職員が下書きを直したかどうかと、直した箇所の種類（書類の追加、言い回し、日付）
• 送った日と、顧客から依頼を受けた日
• 「要電話」になった顧客と、電話した日と結果

4つ目が、指示文を直す材料になります。 職員が毎回同じ言い回しを直しているなら、それはプロンプトの段の目的の書き方を変える合図です。 日付を直しているなら、台帳か締切の設定に誤りがあります。

5つ目と6つ目を並べると、段の時期が合っているかが分かります。 初回の案内から依頼までに毎回4か月以上かかる顧客が多いなら、初回の段を180日より前に出すことを考えます。