道の駅の農産物直売所が、出荷者ごとの売上と手数料を Apps Script で集計し、売れ筋と残品の傾向を添えた月次のお知らせを出荷者へ届ける

処理の起点を決める

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

ただし、日付だけを条件にはしません。 月初の書き出しと取り込みは人の作業で、休日が重なれば遅れます。スクリプトは最初に取り込み用のシートの「状態」の欄を見て、前月分が「取込済み」になっていなければ何も作らずに担当へ知らせて止まります。 3日から10日まで毎朝見に行き、取込済みになった日に動きます。10日を過ぎたら、その月は動かずに担当へ知らせるだけにします。お知らせは精算書と一緒に届くことに意味があり、振込の後に遅れて届く一言は、出荷者にとって別の書類になってしまいます。

インストール型のトリガーは、作った人のアカウントで動きます。 公式のページにそう書かれており、Gmail の下書きもそのアカウントにできます。トリガーは担当者個人ではなく、事務所で共有している出荷者窓口のアカウントで作ります。 トリガーが失敗すると Apps Script から失敗のまとめのメールが届くので、その宛先も窓口のアカウントになります。

入力データを集める

質を決めるのは、ラベルの発行記録です。 残品の数は「発行したラベルの枚数 − 売れた点数」で出しますが、ラベルを刷り損じて貼らなかった分や、出荷者が持ち帰って翌日貼り直した分も発行枚数に入ります。 そのため残品の数は目安で、お知らせでは「残りやすかった」という傾向として伝え、正確な数として扱いません。 この扱いをプロンプトにも書きます。

出荷者台帳の「お知らせの要否」は、出荷者本人の希望で付けます。 精算書だけでよいという人もいます。希望しない人には作らないのが、出荷者との関係を保つ最初の決まりです。

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

3つの CSV は、事務の担当がスプレッドシートの取り込み用のシートに貼ります。 レジの仕組みとラベル発行機は事務所のパソコンから書き出す形が多く、外から直接は取れません。書き出しを自動にしようとせず、貼る作業を1回に集めるほうが、仕組みが壊れにくくなります。

シートは範囲を一度に読み、スクリプトの中で出荷者コードをキーにまとめます。 1行ずつ読むと、売上の明細が月に数万行になる直売所では1回の実行時間に収まりません。集計の結果は集計のシートに残し、翌月の「前月との比べ」に使います。

AIへ渡す前に整形する

1. 期間と件数の確認 … 明細の日付がすべて前月の範囲にあるか、件数が前月から極端に変わっていないかを見ます。半月分しか貼られていない、といった誤りを最初に止めます
2. 返品・値引きの相殺 … 返品の行は元の売上と相殺し、値引きの行は金額だけを差し引きます。点数は変えません
3. 品目の名寄せ … 出荷者がラベルに入れる品名は「トマト」「とまと」「中玉トマト」と揺れます。品目コードがあればコードで、無ければ品目の対応表で1つにまとめます
4. 曜日と時間帯の付与 … 売上の日時から曜日と時間帯（開店〜正午、正午〜15時、15時〜閉店）を付けます
5. 残品の目安の計算 … 品目・曜日ごとに「発行枚数 − 売れた点数」を出し、0未満は0にします（前日のラベルを貼り直した分）
6. 精算の計算と照合 … 売上合計、税率ごとの合計、手数料（15％）、ラベル代、振込額を計算し、精算書の値と突き合わせます。1円でも違えば確認待ちにします
7. 事実の表を作る … 出荷者ごとに、売れ筋の上位3品目、残りやすかった品目と曜日、前月との比べ、翌月の催事を1行1事実で並べ、【売上点数1】【残品率1】のような記号を振ります

6番目は、お知らせより先に置きます。 照合が合わない出荷者は、お知らせの問題ではなく精算の問題です。事務の担当が精算書を直すまで、その出荷者には何も作りません。

7番目で、数字と言葉を切り離します。 AIに渡すのは「トマト（中玉）｜土曜｜【売上点数1】」のような品目・曜日と記号の組で、金額や点数の生の値は渡しません。 値は差し込みのときにだけ使います。

AIに処理させる

させるのは、事実の表から、出荷者に届けるお知らせを3つの段落で書くことです。

2段落目が、この構成でいちばん気を遣うところです。 残品の話は、書き方によっては出荷者を責めているように読めます。「残りやすかった」という事実を、曜日や時間帯という売場の側の条件と一緒に伝え、 出荷者が自分で次の出し方を考える材料にします。

2行目と3行目は、とくに強く禁じます。 「隣の農家さんは150円で出しています」のような一言は、AIに材料を渡せば書いてしまいます。そもそもほかの出荷者の数字を渡さないことで、書きようをなくしておきます。

指示内容を固定する

あなたは道の駅の農産物直売所の事務所で、出荷者の方へ毎月お送りする
「先月の売場のお知らせ」を書く担当です。
以下の「事実の表」だけを使って、お知らせの本文を3つの段落で書いてください。

【書き方】
- 段落1（best_sellers）：先月よく売れた品目と、よく売れた曜日・時間帯を2〜3文で。
- 段落2（leftovers）：残りやすかった品目と曜日を1〜2文で。
    「残りやすい傾向がありました」のように傾向として書く。
    売場の条件（曜日・時間帯・天候の記載があればそれ）と一緒に書く。
    残品がなかった、または事実の表に残品の行がない場合は空にする。
- 段落3（next_month）：来月の催事・休業日・売場の配置替えを1〜2文で。
- 敬語で、やわらかく。1段落は120字以内。

【厳守事項】
- 数字を本文に直接書かないでください。数を述べるときは、
  事実の表の記号（【売上点数1】など）をそのまま本文に置いてください。
  「約」「以上」「倍」を付けた数も書かないでください。
- 価格、値下げ、出荷量について、勧める・お願いする表現を書かないでください。
- ほかの出荷者のこと、順位、平均との比べを書かないでください。
- 精算の金額、手数料、振込、税について書かないでください。
- 残品を出荷者の責任として書かないでください。
- 事実の表にない品目・出来事・天候を書かないでください。
- 出荷者の名前を書かないでください。宛名は【宛名】と書いてください。
- used_facts には、本文で使った記号をすべて並べてください。
- 事実が少なく書けないときは、本文を空にし、needs_review に理由を書いてください。

【出荷者の区分】{segment}（新規：出荷を始めて3か月以内／通常）
【事実の表】{facts}
【来月の売場の予定】{schedule}

「倍」を禁じているのは、記号を使えと言うだけでは足りないためです。 前月との比べを渡すと、「先月の2倍近く売れました」と計算して書くことがあり、それは集計の表に無い数字です。 前月との比べが要るなら、比べた結果も記号（【前月比1】）で渡します。

出荷者の区分を渡しているのは、新しい出荷者への書き方を変えるためです。 出荷を始めて間もない人には、売れた曜日や時間帯の話をていねいに書くほうが役に立ちます。区分はスクリプトが出荷者台帳の「出荷を始めた月」から決め、AIには区分の名前だけを渡します。

出力形式を固定する

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

{
  "grower_code": "G-0137",
  "segment": "new | regular",
  "best_sellers": "",
  "leftovers": "",
  "next_month": "",
  "used_facts": ["【売上点数1】", "【曜日1】", "【残品率2】"],
  "mentions_price": false,
  "needs_review": ""
}

1つ目の理由は、記号の使い方をスクリプトで検算できることです。 本文に出てくる記号を数え、used_facts と一致するか、すべてが事実の表にある記号かを確かめます。

2つ目は、段落ごとに差し込む場所を決められることです。 メールの本文も、印刷用のシートの枠も、段落の順に並べるだけで形になります。

3つ目は、segment を返させて照合できることです。 公式のページには、列挙型の値は大文字小文字だけ違う形で返ることがあると書かれているので、比べるときは大文字小文字を区別しません。 また構造化出力は数値の最小値・最大値の制約に対応していないため、数の範囲の確かめはスクリプトの側で行います。 スキーマを初めて使うときは文法の準備で遅くなり、その結果は最後の利用から24時間保たれるとされているので、180人分を1日のうちに続けて作る形が合っています。

システムへ連携する

API の呼び出しでは muteHttpExceptions を true にします。 公式のページでは、これを true にすると失敗の応答でも例外を投げないとされています。応答のコードを見て、混み合いならしばらく待ってやり直し、それ以外の失敗はその出荷者を確認待ちに回します。 API キーはスクリプトのプロパティに置きます。公式のページでは、スクリプトのプロパティはそのスクリプトの利用者全員で共有され、スクリプトの間では共有されないとされています。

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

精算書の PDF は、メールに添付しません。 精算書はこれまでどおりレジの仕組みから送り、お知らせは別のメールにします。 1通にまとめると、お知らせの下書きを直すたびに正式な書類を扱うことになり、添付の取り違えが起きたときの影響が大きくなるためです。

人が確認する

全件を担当が読みます。 確認の一覧には、出荷者ごとに区分、宛先、照合の結果、検査の結果、下書きへのリンクが並びます。

1. 確認待ちを先に片づける … 精算の照合が合わないもの、検査で止まったもの、AIが書けなかったもの。照合のずれは、お知らせより先に精算書の担当へ回します
2. 2段落目を読む … 残品の書き方が、出荷者を責める調子になっていないか。売場の条件と一緒に書かれているか
3. 数字を1つ確かめる … 差し込まれた数字のうち1つを、集計のシートと見比べます
4. 直して送る・封入する … メールは下書きを開いて送ります。紙は印刷し、精算書と同じ封筒に入れます
5. 大きく直したら記録する … どの段落を、なぜ直したかを一覧に一言残します

1人3分を目安にします。 読む・直すで2分、送る・封入するで1分です。新規の出荷者は少していねいに読み、通常の出荷者は流し読みに近くなります。

出荷者から電話が来たときに答えられる人が読むことも、この確認の役目です。「土曜にもっと出したほうがいいか」と聞かれたとき、答えるのは売場を知る人で、AIではありません。

例外に対処する

最後の行は、Apps Script の上限から来ます。 公式の上限の表では、スクリプトの実行時間は1回あたり6分で、トリガーで動かした合計の実行時間は個人のアカウントで1日90分、Google Workspace のアカウントで1日6時間です。180人分を1回で作ると6分を超えうるので、30人ずつ作り、残りがあれば数分後に動く1回きりのトリガーを作って続きを作ります。 トリガーはユーザー・スクリプトごとに20個までとされているので、続きのトリガーは動いたら消します。

URL の取得の回数にも上限があります。 個人のアカウントで1日20,000回、Google Workspace で1日100,000回です。180人分なら十分に収まりますが、やり直しを無制限に繰り返す作りにはしません。 1人あたり3回までにします。

記録を残す

• 実行の日時、対象の月、取り込んだ明細とラベル記録の件数
• 出荷者ごとの集計の結果（品目・曜日ごとの点数、金額、残品の目安）
• 精算の照合の結果（スクリプトの計算、精算書の値、差）
• AIに渡した事実の表と記号、AIが返した JSON の全文（差し込む前のもの）
• 検査の結果と、確認待ちにした理由
• 担当が送った・封入した日と、大きく直した段落と理由

3つ目の照合の結果は、精算の側の記録としても使えます。 毎月どの出荷者でずれが出たかが残るので、返品や値引きの入れ方の誤りがどこで繰り返されているかが分かります。

4つ目で差し込む前の JSON を残すのは、誤りの出どころを分けるためです。 出荷者から「書いてある数が違う」と言われたとき、AIの文面の問題か、集計の問題かを、差し込む前と後を比べるだけで切り分けられます。