氷の卸が飲食店から届く注文と変更の連絡を Apps Script と AI で読み、定期の注文に反映して配達の順の一覧と配達の伝票を作る

処理の起点を決める

トリガーは2つです。

①10分ごとの時間主導型のトリガー。 受注用の Gmail から、まだ処理していない連絡を探して1件ずつ処理します。インストール型のトリガーの種類（時間主導型、スプレッドシートの編集・変更、フォームの送信、カレンダーなど）に Gmail の受信は無いので、 短い間隔で探しに行く形にします。10分ごとなら、店からの連絡が締めの直前に届いても、締めまでに確認の一覧に出せます。

②毎日16時台の時間主導型のトリガー。 締めのあとに、翌日の配達の一覧と伝票を作ります。定時のトリガーは設定した時刻から1時間の間でばらつくので、16時に設定すると16時台のどこかで動きます。動く前に、①がその日の最後の連絡まで処理し終えているかを確かめます。 未処理のラベルが残っていれば、先に①の処理を呼んでから一覧を作ります。

締めの後に届いた連絡は、翌々日以降の配達として扱います。 ①は止めずに動き続け、締めの後の連絡には「締め後」の印を付けて確認の一覧に出します。明日の配達に入れるかは、配車の担当が積み込みの余裕を見て決めます。

どちらもインストール型のトリガーで、作った人のアカウントで動きます。 受注用の Gmail を読むので、受注用のアカウントでトリガーを作ります。 個人のアカウントで作ると、その人の受信箱を読みに行ってしまいます。

トリガーの合計の実行時間に気をつけます。 個人のアカウントでは1日90分、Google Workspace では1日6時間です。10分ごとに1日144回動くので、1回が数十秒でも個人のアカウントでは上限に近づきます。 受注用のアカウントは Google Workspace にし、連絡の無い時間帯（深夜）は処理を何もせずに終えるようにします。

入力データを集める

AIに渡すのは、連絡の本文と、その店の定期の数、品目の一覧、今日の日付と曜日です。 店の台帳の置き場所や鍵の情報は渡しません。店の特定もAIにはさせず、差出人のアドレスでスクリプトが行います。

その店の定期の数を渡すのは、(a) の読み分けのためです。 定期が角氷3袋の店から「明日5袋で」と来たら、「明日だけ5袋（2袋の追加）」と読むのが自然です。AIはこの数を見て、連絡が定期に対する変更かどうかを判断します。

今日の日付と曜日を渡すのは、「明日」「月曜」「来週から」を日付に直すためです。 ただし、日付への直しはスクリプトでも確かめます（後述）。

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

1. Gmail を検索する … GmailApp.search('label:受注-未処理', 0, 20) のように、未処理のラベルが付いたスレッドを20件ずつ取ります。公式の説明は、件数が分からず多くなりうるときは範囲を指定して取るよう案内しています
2. 未処理のラベルを付ける … 受注用のアドレスに届いたメールに、Gmail のフィルタで「受注-未処理」のラベルを付けておきます
3. 店を引き当てる … 差出人のアドレスで店の台帳を引きます。受注のフォームから来たメールは、本文の店のコードの欄で引きます
4. 定期の数を引く … その店の曜日ごとの品目と数を、明日から7日分の表にします
5. Claude API を呼ぶ … UrlFetchApp.fetch で Messages API を呼びます。muteHttpExceptions を true にして、失敗の応答でも例外で止めずに処理の記録へ書きます
6. ラベルを付け替える … 書き分けが終わったら「受注-未処理」を外し「受注-処理済み」を付けます。失敗したものは未処理のまま残します

ラベルを付け替えるのは、成功したときだけにします。 そうすれば、未処理のラベルが残っている数が、そのまま処理できていない連絡の数になります。

1回の実行は6分までです。 20件ずつ取るのは、1件ごとにAIを呼ぶ時間を見込んで、6分に収めるためです。残りは次の10分後に処理されます。

AIへ渡す前に整形する

1. 引用と署名を外す … 返信のメールに付いてくる前のやりとりの引用と、店の署名を外します。前の連絡の数をAIが今回の連絡と取り違えないようにするためです
2. 全角の数字をそろえる … 「５袋」「五袋」を数字に直す前に、全角の数字を半角にします
3. 日付の表を作る … 今日から7日分の「日付・曜日・その日の定期の数・定休日か」の表を作り、AIに渡します
4. 店が引き当たらない連絡を外す … AIに渡さず、確認の一覧へ回します
5. 同じ連絡の二重送信を見つける … 同じ店から同じ本文が10分以内に2通来たら、2通目を「重複の疑い」にします

3番目の日付の表が、日付の読み違いを減らします。 「月曜」と書かれても、それが今週の月曜か来週の月曜かは、今日の曜日しだいです。7日分の日付と曜日を並べて渡せば、AIは表から選ぶだけで済みます。 定休日も表に入れておけば、「定休日の配達の追加」という矛盾にも気づけます。

AIに処理させる

させるのは、連絡の本文から、品目・数・配達日・連絡の種類を1行ずつ取り出すことだけです。

連絡の種類を add と set_day に分けているのが、(a) への答えです。 「明日5袋追加で」は add で5袋を足し、「明日5袋で」は set_day で5袋にします。どちらか決められないときは unclear にして、人に回します。 定期が3袋の店で読み違えると、8袋と5袋で3袋の差が出ます。

指示内容を固定する

あなたは氷の卸の受注の事務として、飲食店からの連絡を読み、注文の変更を取り出します。

【この店の定期の注文（今日から7日分）】
{schedule_table}    （日付｜曜日｜品目ごとの定期の数｜定休日か）
【品目の一覧（コード｜品名｜単位｜よく使われる呼び方）】
{item_list}
【今日】{today}（{weekday}）
【連絡の本文】
{message}

【やること】
連絡の本文から、変更を1行ずつ取り出してください。1つの連絡に複数の変更があれば、
すべて別の行にしてください。

【type の選び方】
- add ............ その日だけ、定期の数に足す（「追加」「あと2袋」など）
- set_day ........ その日だけ、この数にする（「明日は5袋で」など）
- reduce ......... その日だけ、定期の数から減らす
- skip ........... その日は配達しない（休み・臨時休業）
- change_regular . これから先の定期の数を変える（「来月から」「今後は」「毎週〜に」など）
- inquiry ........ 注文の変更ではない質問
- unclear ........ 上のどれか決められない
add と set_day のどちらか迷ったら unclear にしてください。

【厳守事項】
- 配達日は【この店の定期の注文】の表の日付から選んでください。表に無い日は空にし、
  flags に date_unclear を入れてください。
- 数を計算しないでください。「あと2袋」は quantity=2、type=add のまま返します。
- 書かれていない品目を、定期の品目で補わないでください。
  品目が書かれていない「明日多めに」などは unclear にしてください。
- 定休日の日付への add・set_day は、そのまま返したうえで flags に closed_day を入れてください。
- 本文の引用部分（「>」で始まる行）は読まないでください。
- 推測で埋めないでください。書かれていないことは空にしてください。

「add と set_day のどちらか迷ったら unclear」を明記しているのは、ここがいちばん間違えやすいからです。 書かないと、AIは文の調子からどちらかを選びます。選んだほうが外れていたとき、配達の現場で初めて分かります。

「多めに」を unclear にさせるのも同じです。 何袋が「多め」かは店ごとに違い、事務が電話で確かめるしかありません。

出力形式を固定する

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

{
  "changes": [
    { "type": "add", "item_code": "KAKU-1K", "quantity": 2,
      "date_from": "2026-11-06", "date_to": "2026-11-06",
      "slot": "", "source_text": "明日は宴会なので角氷あと2袋" },
    { "type": "skip", "item_code": "", "quantity": null,
      "date_from": "2026-11-09", "date_to": "2026-11-09",
      "slot": "", "source_text": "月曜は臨時休業です" }
  ],
  "flags": [],
  "inquiry_text": ""
}

スクリプトは、受け取った行を次のように書き分けます。

1つ目の理由は、明日だけの変更と定期の変更を、書く先で分けられることです。 自由文で受けると、どこに書くかを人が判断し直すことになります。

2つ目は、source_text で確認が速くなることです。 確認の一覧で、本文のどの部分からその行を取り出したかが一目で分かります。

enum の値は、大文字・小文字が変わって返ることがあるとされているので、スクリプトでは小文字にそろえてから比べます。数値の範囲の制約（minimum など）は構造化出力で使えず400になるので、数が0以上かはスクリプトで確かめます。停止の理由が max_tokens のときは出力がスキーマに合わないことがあるので、end_turn 以外なら結果を使わずに未処理のまま残します。

システムへ連携する

配達の一覧は、店の台帳の「便」と「配達の順」で並べるだけです。 同じ便の中では配達の順の数字の小さい店から並べ、置き場所と時間帯と鍵の有無を一覧に載せます。 運転手が一覧だけで動けるようにするためです。

積み込みの数は、便ごとに品目の合計を出します。 製氷会社からの仕入れの数は、全便の合計に予備を足して配車の担当が決めます。

伝票のシートには、店ごとに次の欄を並べます。 店名、配達日と便、品目ごとの数（定期の数と、変更があればその内容）、置き場所、受け取りの印の欄です。変更があった品目には「本日追加2」「本日休み」のように変更の中身を印字します。 店の人が受け取りのときに、いつもと数が違う理由をその場で確かめられ、「頼んでいない」という行き違いが減ります。伝票の通し番号は、配達日・便・配達の順から作り、同じ伝票を二度印刷しても番号で気づけるようにします。

人が確認する

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

1. 確認の一覧（随時） … unclear・inquiry・店が引き当たらない連絡・締め後の連絡を、事務が見ます。電話で店に確かめてから、日ごとの注文の表に手で書きます
2. 定期の変更の候補（毎日） … 事務が本文と見比べて承認すると、定期の注文の表に入ります。承認するまで、定期の数は変わりません
3. 配達の一覧と積み込みの数（締めのあと） … 配車の担当が、休みの店が抜けているか、積み込みが車に載るかを見て、伝票を印刷します

1番目は、締めの直前に集中します。 15時台に確認の一覧が増えたら、事務は他の作業より先にここを片付けます。 締めを過ぎると、明日の配達に入れるかの判断が配車の担当に移ります。

目標は、600件をならして1件1分です。 そのまま書き分けられた連絡は配達の一覧で数秒、確認の一覧に入った連絡は電話を含めて数分かかります。

例外に対処する

上の4行が大半を占めます。 どれもAIの読み違いというより、連絡の書き方と台帳の整い方の問題です。 確認の理由を月ごとに数え、多い理由から台帳とお店への案内を直します。

記録を残す

• 連絡の本文（Gmail に残る）と、処理済みにした日時
• AIに渡した日付の表と、返った JSON の全文
• 日ごとの注文・休み・定期の変更に書いた行と、もとになった連絡
• 定期の変更を承認した人と日時、承認の前と後の定期の数
• 確認の一覧で人が直した内容
• Claude API のエラーの応答と再試行の回数

3つ目で「もとになった連絡」を行ごとに残すのは、配達のあとの問い合わせに答えるためです。 「頼んだ数と違う」と言われたとき、どの連絡からその数になったかを、その場で示せます。

4つ目の定期の数の前と後は、月末の請求の確かめにも使います。 定期の数がいつ変わったかが分からないと、月の途中で数が変わった店の請求を説明できません。処理の記録は少なくとも請求の確定まで残し、 古い記録は月ごとに別のシートへ移して、スクリプトが毎回読む表を軽く保ちます。