時計・宝飾店が修理の受付台帳から、見積の回答待ち・工程の遅れ・完成をお客様への連絡文にし、連絡が止まっている修理を毎朝拾う

処理の起点を決める

毎朝7時台に、時間主導型のトリガーで動かします。 Apps Script の時間主導型のトリガーは毎分から月に1回までの間隔で動かせ、公式のページでは、9時に設定すると9時から10時のあいだのどこかで動き、その時刻が日ごとに保たれるとされています。店が開く前に確認の一覧ができているよう、早い時刻に置きます。

台帳の更新のたびに動かす作りにはしません。 修理担当は1日のうちに何度も台帳を直し、状態を間違えて付けて直すこともあります。更新のたびに連絡文を作ると、間違えた状態のまま下書きができます。 1日1回、前日の終わりの状態で判断するほうが、誤った連絡が出にくくなります。

インストール型のトリガーは、作った人のアカウントで動きます。 公式のページにそう書かれており、Gmail の下書きもそのアカウントにできます。トリガーは担当者個人ではなく、本部の修理の窓口の共用のアカウントで作ります。 お客様へのメールの差出人もこのアカウントになるので、お客様の返信は窓口に集まり、 店ごとの担当に振り分けます。トリガーが失敗すると失敗のまとめのメールが届くので、その宛先も共用のアカウントになります。

休業日にも動かします。 下書きは翌営業日に送ることになりますが、日数の数え方は暦の日で決めているので、 休業日に動かさないと休み明けに2日分の判定がまとめて出ます。

入力データを集める

質を決めるのは、「状態が変わった日」の欄です。 経過日数はこの日から数えるので、状態を更新したときに日付を直し忘れると、 連絡の時期がすべてずれます。台帳の側で、状態の欄を変えたら日付の欄が空になる形の入力の決まりにし、日付が空の修理は判定せずに一覧に出します。

「最後に連絡した日と種類」は、同じ連絡を二度出さないために持ちます。 回答の再度のお願いは7日おきに2回まで、のような決まりを、この欄で数えます。

「連絡を控える」の欄は、お客様の事情を店が知っているときのためです。 入院している、海外にいる、贈り物のため家族に知られたくない、といった事情があれば、担当がこの欄に印を付け、その修理は連絡文を作りません。

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

シートは範囲を一度に読み、スクリプトの中で判定します。 預かり中の修理は常に400件前後あり、1行ずつ読むと遅くなります。判定の結果と作った下書きの印は台帳には書き戻さず、確認の一覧と処理ログにだけ書きます。 台帳は修理担当が直す表で、スクリプトが書き込むと、担当の入力と書き込みがぶつかります。担当が一覧に「送った」の印を付けたときだけ、台帳の「最後に連絡した日と種類」を担当の操作で更新します。

AIへ渡す前に整形する

1. 対象の絞り込み … 引き渡し済みと返却を除き、「連絡を控える」に印のある修理を除きます
2. 日付の確認 … 「状態が変わった日」が空、または未来の日付の修理は判定せず、一覧に「日付の確認」と出します
3. 経過日数の計算 … 状態が変わった日から今日までの日数と、完成の予定日からの超過日数を出します
4. 連絡の種類の決定 … 連絡の規則に照らし、連絡の種類と何回目かを決めます。最後に連絡した日から規則の間隔がたっていなければ作りません
5. 止まっている修理の判定 … 目安の日数を過ぎた修理を拾い、お客様への連絡が要るか、送り先への問い合わせが要るかを分けます
6. 事実の表を作る … 品物、症状、修理の内容、送り先の種類（メーカー・職人・工房）、遅れの理由、店の情報を並べ、見積の金額・完成の予定日・回答の期限・引き取りの期限は【見積金額】【完成予定日】のような記号にします
7. お名前を外す … お客様のお名前と連絡先は事実の表に入れません。宛名は【お客様名】の記号にします

4番目の「間隔がたっていなければ作らない」を省かないでください。 これが無いと、見積回答待ちの修理に毎朝お願いの下書きができ、担当が下書きを消す作業に追われます。

6番目の記号は、見積の連絡でとくに効きます。 見積には「オーバーホール」「部品の交換」のような内訳と金額が並びます。内訳の名前は事実の表に入れ、金額は記号にします。 AI は「【内訳1の金額】」のように書き、合計も【見積金額】として書くので、AI が足し算をする余地がありません。

AIに処理させる

させるのは、決まった連絡の種類と事実の表から、お客様への連絡文を書くことです。

3行目の遅れのお知らせが、この構成でいちばん気を遣う文面です。 遅れの理由の欄が空なら、理由には触れず、「確認ができしだい改めてご連絡します」と書かせます。 理由を作らないことと、根拠の無い見込みの日を書かないことを、指示で分けて禁じます。

5行目の「保管料や処分」は、店の預かりの規約に関わります。 長く引き取られない修理品の扱いは、受付のときにお渡しした控えの規約で決まっています。その文言は店の情報のシートに規約のとおりに持たせ、そのまま差し込みます。 AI に言い換えさせません。

指示内容を固定する

あなたは時計・宝飾品の専門店で、修理をお預かりしているお客様に
連絡文を書く担当です。以下の「連絡の種類」と「事実の表」だけを使って、
メールの本文と、電話で伝える要点を書いてください。

【書き方】
- body：メールの本文。宛名は【お客様名】様とする。
    丁寧な敬語で、1段落は100字程度まで、全体で4段落以内。
- phone_points：電話で伝える要点を3行で。
- 金額・日付・期限は、事実の表の記号をそのまま本文に置く。
- 最後に、受付の店名と【受付番号】を書く。

【厳守事項】
- 金額、日付、日数、期限を数字で書かないでください。必ず記号を使ってください。
  合計を計算しないでください。合計は【見積金額】と書いてください。
- 事実の表の delay_reason が空のときは、遅れの理由に触れないでください。
  「確認ができしだい改めてご連絡いたします」と書いてください。
- 新しい予定日の記号が事実の表に無いときは、見込みの日や期間を書かないでください。
- 修理を勧める、急がせる表現を書かないでください。
  見積の回答では、修理をしない場合の返却も選べることを必ず書いてください。
- 修理ができるかどうか、保証が使えるかどうかを書かないでください。
- 事実の表にない部品名・作業名・原因を書かないでください。
- 【規約の文言】の記号がある場合は、その位置に記号だけを置いてください。
- 書けない事情があるときは、body を空にし、needs_review に理由を書いてください。

【連絡の種類】{notice_type}（{count} 回目）
【事実の表】{facts}

「合計を計算しない」を明記しているのは、内訳を渡すと足し算をしたがるためです。 内訳が「オーバーホール【内訳1の金額】」「ガラス交換【内訳2の金額】」と並んでいると、AI は合計を自分で出して書こうとします。合計も記号で渡し、計算そのものを禁じます。

「返却も選べることを必ず書く」は、修理を急がせないための書き方です。 見積の連絡は、お客様にとって修理するかどうかを決める知らせです。選べることを毎回書くと、文面が押し付けに読まれにくくなります。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 公式のページでは、output_config.format に type: "json_schema" を指定し、オブジェクトには additionalProperties: false を付けることとされています。

{
  "repair_id": "R-2026-1043",
  "notice_type": "estimate_request | estimate_reminder | delay | ready | pickup_reminder",
  "subject": "",
  "body": "",
  "phone_points": ["", "", ""],
  "used_tokens": ["【お客様名】", "【見積金額】", "【回答期限】"],
  "mentions_reason": false,
  "needs_review": ""
}

1つ目の理由は、記号の使い方をスクリプトで検算できることです。

最後の行で、大文字と小文字を区別せずに比べます。 公式のページでは、列挙型の値は大文字小文字だけが違う形で返ることがあるとされているためです。また構造化出力は数値の最小値・最大値の制約に対応しないとされているので、本文の長さや段落の数はスクリプトの側で確かめます。

2つ目の理由は、件名と本文を分けて差し込めることです。 件名には【受付番号】と品物を入れ、お客様が過去のメールを探しやすい形にそろえます。

システムへ連携する

API の呼び出しでは muteHttpExceptions を true にします。 公式のページでは、これを true にすると失敗の応答でも例外を投げず、応答を返すとされています。応答のコードを見て、混み合いなら時間をおいてやり直し、それ以外の失敗はその修理を「下書きなし」で一覧に載せます。 連絡が要ることは規則で決まっているので、下書きが無くても一覧からは落としません。 API キーはスクリプトのプロパティに置きます。公式のページでは、スクリプトのプロパティはそのスクリプトの利用者全員で共有され、スクリプトの間では共有されないとされています。

Gmail は下書きまでです。 createDraft は宛先・件名・本文のほか、差出人の表示名や返信先などを指定して下書きを作れるとされています。表示名には店の名前を入れ、返信先は修理の窓口のアドレスにします。 このメソッドを使うには https://mail.google.com/ のスコープの承認が要るとされているので、最初の承認は窓口の共用のアカウントで行います。

人が確認する

全件を、受付の店の修理担当が読んでから送ります。 確認の一覧は店ごとに分かれ、上から「確認待ち」「見積の回答のお願い」「遅れのお知らせ」「完成のご案内」「止まっている修理」の順に並びます。

1. 確認待ちを先に片づける … 記号の誤り、理由の作り込み、日付の確認
2. 見積の連絡は金額を1度見る … 差し込まれた【見積金額】を、送り先の見積書と見比べます。台帳への転記の誤りは、ここでしか見つかりません
3. 遅れのお知らせは理由を確かめる … 欄の理由がお客様に伝えてよい内容か。送り先の社内の事情をそのまま書いていないか
4. 送る・電話する … 送ったら一覧に印を付け、台帳の「最後に連絡した日と種類」を更新します
5. 止まっている修理を送り先に問い合わせる … 分かったことを「遅れの理由」の欄に書きます。翌朝の連絡文に反映されます

2番目を省かないでください。 スクリプトは台帳の値を正しく差し込みますが、台帳の値そのものが送り先の見積と違っていれば、正しく差し込まれた誤りになります。 金額を伝える連絡だけは、元の見積書と1度見比べます。

1件2分を目安にします。 完成のご案内は読んで送るだけで1分かからず、見積と遅れの連絡は見比べと確かめで数分かかります。

例外に対処する

最後の行は、Apps Script の上限から来ます。 公式の上限の表では、スクリプトの実行時間は1回あたり6分で、トリガーで動かした合計の実行時間は Google Workspace のアカウントで1日6時間です。1日の連絡は20〜30件ほどなので多くは1回で終わりますが、月初や連休明けは件数が増えるので、30件ずつ作り、残りは1回きりのトリガーで続きを作ります。 トリガーはユーザー・スクリプトごとに20個までとされているので、続きのトリガーは動いたら消します。 また、メールの受信者の数には1日あたりの上限があるとされていますが、この構成は下書きを作るだけで、送るのは人です。

記録を残す

• 実行の日時、判定した修理の件数、連絡の種類ごとの件数、止まっている修理の件数
• 修理ごとの判定の理由（状態、経過日数、当てはまった規則）
• AI に渡した事実の表と、AI が返した JSON の全文（差し込む前のもの）
• 検査の結果と、確認待ちにした理由
• 担当が送った・電話した日時と、直した箇所
• 止まっている修理について、送り先に問い合わせた日と答え

2つ目の判定の理由が、問い合わせへの答えを速くします。 お客様から「連絡が来ない」と言われたとき、その修理が規則のどこに当たり、いつ何を作ったかがすぐに分かります。

最後の行は、送り先ごとの目安の日数を見直す材料になります。 同じ送り先で毎回止まっていると出るなら、目安が短すぎるか、送り先の側の手順に理由があります。