印刷会社が校正刷りの発送の記録から、戻りの期限が近い客への催促のメールを Apps Script と Gemini で下書きし、印刷の枠に間に合う戻りを営業日で追う

処理の起点を決める

時間主導型のトリガーを1つ置き、everyDays(1) と atHour(8) で毎朝動かします。 公式の説明では、nearMinute() を指定しないと分はランダムに決まります。8時台のどこかで動けばよく、営業事務が始業する9時には一覧と下書きがそろっています。

休日は動かしても何もしないで終えます。 トリガーの設定では会社の休日を指定しないので、Apps Script の最初で会社の休日の表を見て、休日なら読み込みをせずに終わります。 連休の明けの朝には、休み中に期限が来た案件がまとめて超過として拾われます。

トリガーは、営業事務の共用のアカウントで作ります。 下書きはトリガーを作ったアカウントの Gmail に入るので、営業個人のアカウントで作ると、催促がその営業の下書きに散らばります。 失敗したときの通知も共用のアカウントに届くようにし、受信箱を誰が見るかを決めておきます。

入力データを集める

質を決めるのは、工程の日数の表です。 色校正の戻りの後は色の調整があるので修正に2営業日、PDFの文字の修正なら1営業日、というように、製造の担当が普段の段取りから決めた日数を入れます。 この表が無ければ、期限は担当の営業の数え方のままです。

メールのスレッドの ID を、発送の記録に持たせます。 校正のPDFを Gmail で送ったときに、営業事務がそのスレッドの ID を写しておく運用にします。返信を探すときに、件名ではなくスレッドで引けるようにするためです。 宅配便で校正刷りを送った案件は、送り状の控えの番号を入れます。

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

発送の記録、印刷の予定表、工程の日数、休日は、Apps Script のスプレッドシートのサービスで読むだけです。 客からの返信は Gmail から探します。

戻りの期限は、次のように数えます。

返信の確かめ方は2段にします。 スレッドの ID があれば GmailApp.getThreadById() でそのスレッドを開き、発送の日時より後に客のアドレスからのメッセージがあるかを見ます。 スレッドの ID が無い案件は、GmailApp.search() で from: に客のドメイン、本文に案件番号、after: に発送日を入れて探します。公式の説明では、検索の結果が大きすぎると呼び出しが失敗するとされ、ページを分けて取る search(query, start, max) の形を使うよう書かれています。 1回に10件までに絞って取ります。

営業個人のアドレスに来た返信は、共用のアカウントからは見えません。 これは仕組みでは埋まらないので、営業には、客から校正の返信が来たら共用のアドレスに転送してもらう決まりにします。

AIへ渡す前に整形する

1. 状態で絞る … 戻り日が入っている校正、案件が保留・取消の校正は外します
2. 期限を計算する … 印刷の予定日が空の案件は、期限を計算できないので「予定日なし」にします
3. 重複を外す … 催促の記録に、同じ案件・同じ校正の回・同じ段階の行があれば外します。段階が進んだときだけ、新しい催促を作ります
4. 返信を見る … 上の2段の確かめ方で返信を探し、あれば「返信あり」にして下書きを作りません
5. 同じ客をまとめる … 同じ客の同じ担当者に、同じ日に2件以上の催促があれば1通にまとめ、案件ごとに期限を並べます
6. 日付を整える … 期限を M月d日（曜日） の形にし、曜日は Apps Script が日付から計算して付けます
7. 記号に置き換える … 宛名を {{宛名}}、案件名を {{案件名_1}}、校正の回を {{校正回_1}}、期限を {{戻り期限_1}}、担当の営業を {{担当営業}} のような番号付きの記号にします

4番目を前処理に置くのは、AIを呼ぶ前に止めるためです。 返信がある案件にAIで催促の文面を作っても、捨てるだけです。

AIに処理させる

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

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

2行目がいちばん起きやすい失敗です。 AIは親切に「お戻しが遅れた場合、納期が2営業日ほど後ろにずれる見込みです」と書き足します。どれだけずれるかは、ほかの案件の枠と印刷機の空きで決まり、営業と製造が相談してはじめて言えることです。 書いてよいのは、「担当の営業から改めてご連絡します」までです。

指示内容を固定する

system_instruction に次の指示を入れ、input に事実の束を渡します。

あなたは印刷会社の営業事務として、校正をお送りしたお客様に、お戻しをお願いするメールの下書きを書きます。
渡す「事実の束」だけを使って書いてください。

【書き方】
- 宛名は {{宛名}} と書き、customer_type に合わせて敬語の向きを決めてください。
  direct …… 直取引の企業のご担当者
  agency …… 制作会社のディレクター。業界の言葉（初校・再校・念校）をそのまま使ってよい
  association …… 団体の事務局。業界の言葉には短い言い換えを添える
- stage に合わせて本文を書いてください。
  before …… お戻しの期限が近いことの確認。「行き違いでしたらご容赦ください」を添える
  due …… 本日がお戻しの期限であることのお知らせ
  overdue …… 期限を過ぎていることのお知らせと、担当の {{担当営業}} から改めてご連絡する旨
- 日付・曜日は、事実の束の記号（{{戻り期限_1}} など）をそのまま置いてください。
  数字で日付を書かないでください。曜日も書かないでください。
- 案件名・校正の回も記号のまま置いてください。
- items が複数あるときは、番号の順に1件ずつ並べてください。
- return_method_texts にある文は、意味を変えずに入れてください。

【書かないこと】
- 遅れたときの新しい納期、印刷の日、作業の日数
- 追加の費用、特急の対応
- お客様を責める言い方（「再三」「至急」など）
- 校正の中身や、直す箇所についての言及

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

「新しい納期を書かない」を明記しないと、overdue の文面にほぼ必ず納期の見込みが入ります。 客にとって最も知りたいことだからこそ、AIは先回りして書きます。営業と製造が決めていない日付が客の手元に残ると、それが約束として扱われます。

出力形式を固定する

Gemini API の Interactions の構造化出力で、次の形の JSON を受け取ります。 公式の説明では、POST /v1beta/interactions の本文の response_format に、mime_type を application/json とし、schema を入れて渡します。

{
  "subject": "【校正のお戻しのお願い】{{案件名_1}}",
  "body": "{{宛名}}\n\nいつもお世話になっております。\n{{案件名_1}}の{{校正回_1}}につきまして、お戻しの期限が{{戻り期限_1}}となっております。\n…",
  "stage": "before",
  "placeholders_used": ["{{宛名}}", "{{案件名_1}}", "{{校正回_1}}", "{{戻り期限_1}}"],
  "notes": []
}

stage は enum で before・due・overdue に絞り、事実の束の段階と同じかを検査します。 構造化出力を使う理由は、件名と本文と使った記号を別の項目で受け取り、placeholders_used と事実の束の記号を突き合わせられることです。

本文の長さの制約は、スキーマに書いても効きません。 公式の説明では、minLength・maxLength などはエラーにならずに外され、クライアントの側で確かめるよう書かれています。 本文が600字を超えたら「要確認」にする検査を Apps Script に置きます。また、出力は JSON として正しい形でも、値が意味の上で正しいかはアプリの側で確かめるよう書かれています。

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

5行目で「納期」の語を拾うのは、AIが新しい納期を書いたときの網です。 「納期に間に合わせるため」のような、書いてよい使い方でも止まりますが、止まった下書きを営業事務が読めば済みます。 拾い漏らすより、止まりすぎるほうを選びます。

システムへ連携する

下書きは GmailApp.createDraft(recipient, subject, body, options) で作ります。 オプションの cc に担当の営業のアドレスを入れ、客が返信したときに営業にも届くようにします。 name には会社名と「営業部」を入れます。

呼び出しの回数は月に300回前後です。 URL の取得の上限（個人のアカウントで1日20,000回、Workspace で1日100,000回）には届きません。気をつけるのは1回の実行が6分までという上限で、Gmail の検索は1件ずつ時間がかかるので、連休の明けで候補が多い朝は、処理した案件に印を付けて続きを次の実行に回します。

人が確認する

1. 「返信あり」を先に見る … 返信を開き、校正の戻りなら戻りの欄に日付を入れます。質問や修正の相談の返信なら、担当の営業に回します
2. 「予定日なし」を見る … 印刷の予定表に予定日が入っていない案件です。製造の担当に予定日を入れてもらいます
3. overdue の下書きは、担当の営業が読む … 印刷の枠の相談が要るので、営業が電話を入れるかどうかを決めてから送ります
4. 赤の「要確認」を見る … 事実の束に無い日付が本文にある下書きです
5. 送る … 営業事務が Gmail から送り、催促の記録に送った日時を入れます

1番目を省かないでください。 返信の確かめは機械の仕事ですが、返信の中身が戻りなのか、「明日戻します」という連絡なのかは、人が読まないと分かりません。 後者なら戻りの欄は埋めず、催促の記録に「戻る予定の連絡あり」と残します。

目標は、300件をならして1件2分です。 before の下書きは読んで送るだけで1分ほど、overdue は営業とのやり取りを含めて5分ほどです。時間を使うのは「返信あり」の中身を読むところです。

例外に対処する

4行目の宅配便の戻りは、Gmail では見えません。 校正刷りが受付に届いていても、営業事務の手元に渡るまで戻りの欄が埋まりません。overdue の催促を送る前に、受付の受け取りの記録を見ます。

記録を残す

• 実行の日時、拾った案件の数、作った下書きの数、作らなかった案件とその理由
• 案件ごとの戻りの期限と、計算に使った印刷の予定日・工程の日数の行
• 事実の束（記号に置き換えた後のもの）と、Gemini が返した JSON
• 検査の結果（記号の抜け・余り、日付の食い違い、避ける言葉、字数）
• 営業事務と営業が下書きを直したかどうかと、直した箇所の種類
• 送った日時と、送った後に戻った日（催促から戻りまでの日数）

最後の行が、工程の日数の表を直す材料になります。 before の催促を送った後、ほとんどの客が翌日に戻すなら、期限の前営業日の催促は効いています。 戻りが期限を過ぎがちな客の区分が分かれば、その区分だけ催促を1営業日早めます。