ウォーターサーバーの宅配会社がお客様から届く配送日の変更・休止・本数の変更をフォームで受け、Apps Script で配送の予定表を直して確認の連絡を作る

処理の起点を決める

フォームの回答が届くたびに、インストール型のトリガーで動かします。 公式のページでは、フォームの送信のトリガーには、フォームそのものに付けるものと、回答先のスプレッドシートに付けるものの2つがあるとされています。この構成では回答先のスプレッドシートに付けます。 回答の行に処理済みの印を付け、予定表と同じファイルの中で扱えるからです。

同じ時刻に回答が重なっても、予定表は1件ずつ直します。 夕方にはフォームの回答が続けて届き、2つの処理が同じルートの同じ日の積み込みの余裕を同時に見ると、どちらも「余裕あり」と判断して上限を超えます。 Apps Script のロックのサービスには、スクリプト単位のロックがあり、公式のページでは、ロックで守った部分は利用者が誰であっても同時には動かないとされています。余裕を確かめてから予定表を直すまでを、スクリプトのロックで囲みます。 ロックが取れなかった回答は処理済みの印を付けずに残し、後で拾い直します。

拾い直しのために、15分ごとの時間主導型のトリガーも置きます。 処理済みの印が無い回答と、API の失敗で止まった回答を拾います。インストール型のトリガーは作った人のアカウントで動くので、受付の共有のアカウントで作ります。

入力データを集める

質を決めるのは、配送の予定表が先の回まで作られていることです。 AIに渡すのは「次の4回分」の予定で、予定表に来月の行がまだ無ければ、「来月の2回目」を選べません。 予定表は周期に沿って、少なくとも2か月先まで行を作っておきます。

お客様の一覧の氏名・住所・電話番号は、AI に渡しません。 本人の確かめと確認の連絡の宛先にだけ使います。

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

フォームの回答は、トリガーが渡す値から取ります。 公式のページでは、スプレッドシートのフォームの送信のイベントには、質問の名前と値の組の namedValues、シートの並びの値の values、回答が書かれた範囲の range が入っているとされています。range で回答の行が分かるので、その行の横に処理の状態を書き込めます。

予定の候補には、その回の状態も添えます。 すでに「休止」になっている回の休止の申し出は、二重の申し出か、休止の取り消しのつもりで書かれていることがあります。 状態が分かれば、AIは「取り消し」かどうかを読み分けられます。

AIへ渡す前に整形する

1. 処理済みかを見る … 回答の行の印を見ます。済んでいれば何もしません
2. 本人を確かめる … お客様の番号と電話番号の下4桁が一覧と合うかを見ます。合わなければ AI に渡さず「本人未確認」
3. 契約の状態を見る … 解約済み・停止中のお客様は、AI に渡さずに担当へ回します
4. 予定の候補を作る … 次の4回分の予定を、D1〜D4 の番号と、配送日・曜日・本数・状態で並べます
5. 自由記入を整える … 前後の空白と改行をそろえます。本文に電話番号や住所が書かれていれば記号に置き換えます
6. 今日の日付を添える … 「今週」「来月」の手がかりとして、今日の日付と曜日を添えます

4番目の番号は、AIが返す値をそのまま予定表の行に結び付けるためのものです。 番号はスクリプトが付け、AIは番号を選ぶだけです。AIが番号の代わりに日付を返したら、その申し出は「要確認」にします。

6番目の今日の日付は、AIに計算させるためのものではありません。 「今週の分」と書かれたときに、D1 がそれに当たるかをAIが読むための手がかりです。候補を4回分にしているのは、2週に1回のお客様でも「来月の2回目」までが入るからです。 4週に1回のお客様には、同じ4回で約4か月先まで入ります。

AIに処理させる

させるのは、自由記入を申し出ごとに分け、それぞれの種類と対象の回を選ぶことです。

選択の欄より、自由記入を優先させます。 お客様は選択の欄を一番上のものにしたまま、自由記入で本当の申し出を書くことが多いからです。選択と自由記入が食い違うときは、その申し出に「選択と記入が違う」の印を付けさせます。

1行目がいちばん起きやすい失敗です。 「再来週の水曜にしてください」と書かれた申し出を渡すと、今日の日付から計算して「11月11日」のように日付を返します。 数え方を1週ずれれば、別の日に届きます。希望の日は書かれた文字列のまま返させ、日付として読めるものだけをスクリプトが解釈し、読めないものは担当に回します。

指示内容を固定する

あなたはウォーターサーバーの宅配会社の受付の担当です。
お客様から届いた定期配送の変更の申し出を、申し出ごとに分けてください。

【申し出の種類】
change_date（配送日の変更） / skip（1回の休止） / unskip（休止の取り消し） /
change_qty（本数の変更） / change_place（配送先・時間帯の変更） /
cancel（解約） / other（その他）

【対象の回の選び方】
- 【配送予定】の D1〜D4 の中から、申し出が当てはまる回を選んでください。
- 「今後ずっと」「次回以降すべて」などは "all_after" とし、起点の回を from に入れてください。
- 当てはまる回を1つに決められないときは "unclear" にしてください。

【厳守事項】
- 日付を計算しないでください。希望の日は、お客様が書いたとおりの文字列で
  requested_date_text に写してください。書かれていなければ空にしてください。
- 本数は、数字で書かれているときだけ requested_qty に入れてください。
  「多めに」「少なめに」は数ではありません。空にし、needs_review に理由を書いてください。
- 変更できるか、締切に間に合うかを書かないでください。
- 解約の申し出には、引き留めの言葉や手数料の説明を書かないでください。
- 1つの記入に複数の申し出があれば、requests にすべて分けて並べてください。
- 選択の欄と記入の内容が違うときは、記入を優先し、choice_mismatch を true にしてください。
- evidence には、判断の根拠にした記入の一部をそのまま写してください。

【今日】{today}（{weekday}）
【選択の欄】{choice}
【配送予定】{deliveries}
【記入】{free_text}

「日付を計算しない」は、理由も書いたほうが守られます。 実際の運用では、指示の冒頭に「日付は予定表の値を使うので、計算は不要です」と添えます。計算を禁じるだけだと、「念のため」として日付を併記してきます。

出力形式を固定する

OpenAI API の構造化出力で、次の形の JSON を受け取ります。 公式のページでは、strict: true のときはすべての項目を required に入れ、オブジェクトには additionalProperties: false を付けた例が示されており、値が無いことがある項目は null との組み合わせで表すとされています。

{
  "requests": [
    {
      "type": "skip",
      "target": "D2",
      "from": null,
      "requested_date_text": null,
      "requested_qty": null,
      "choice_mismatch": true,
      "evidence": "来月は旅行なので1回お休みにして",
      "needs_review": null
    },
    {
      "type": "change_qty",
      "target": "D3",
      "from": null,
      "requested_date_text": null,
      "requested_qty": 3,
      "choice_mismatch": true,
      "evidence": "その次は3本にしてください",
      "needs_review": null
    }
  ]
}

1つ目の理由は、申し出ごとに決まりを当てはめられることです。

2つ目は、「特定できない」を正しく止められることです。 target が unclear のもの、needs_review に理由のあるもの、requested_date_text が日付として読めないものは、予定表を直さずに担当の一覧に並べます。

all_after は、決まりを満たしても仮の変更にしません。 「今後ずっと3本に」は、予定表の4回分ではなく、お客様の一覧の「1回の本数」そのものを変える申し出だからです。一覧の値を変えると、その先に作られるすべての回に効きます。一覧の書き換えは受付の担当が行い、スクリプトは「契約の内容の変更」として担当に並べるだけにします。

3つ目は、拒否と途中切れを見分けられることです。 公式のページでは、拒否のときは応答に refusal が入り、スキーマに従わないことがあるので、読む前に確かめることとされています。出力の上限で切れたときは status が incomplete になります。どちらもその回答を「要確認」にします。

システムへ連携する

確認の連絡は、下書きまでにします。 公式のページでは、createDraft は宛先・件名・本文に加えて、CC や返信先などを指定して下書きを作れるとされています。受付の担当が仮の変更を確定したら、その下書きを送ります。 確定の前に連絡が届くと、担当が直した内容と食い違うことがあるからです。

連絡の文面は、AIに書かせずにひな形で作ります。 「◯月◯日の配送を休止にしました。次回は◯月◯日、◯本をお届けします」の日付と本数は、予定表の確定した値を差し込みます。 お客様が一番知りたいのは「次はいつ・何本か」で、そこを誤らないことが連絡の目的です。

人が確認する

1. 「本人未確認」を見る … 番号の打ち間違いか、別のお客様の番号かを確かめ、必要なら電話します
2. 仮の変更を一覧で確かめる … 申し出の根拠と直した行を並べて見ます。choice_mismatch のものは記入を読み直します
3. 担当へ回ったものを片付ける … 締切を過ぎたもの、曜日の合わないもの、特定できないものに、お客様へ連絡して決めます
4. 確定して下書きを送る … 確定の印を付け、下書きの日付と本数を見て送ります
5. 解約と積み込みの超過を渡す … 解約は専任の担当、積み込みの超過は配送の責任者へ

目標は、1件2分です。 仮の変更の確定と送信は1件1分足らずで、担当へ回ったものは電話を含めて数分かかります。毎日の配車の締めの前に、仮のまま残っているものが無いようにします。

確かめの一覧は、配送日の近い順に並べます。 翌々日の配送に関わる仮の変更が、来月の分の後ろに埋もれていると、確定が配車の締めに間に合いません。 配送日までの日数と、担当へ回った理由の列を一覧の左に置きます。

例外に対処する

最後の行のやり直しは、Apps Script の上限の中で行います。 公式の上限の表では、スクリプトの実行時間は1回あたり6分、同時に動かせる実行は利用者あたり30まで、外部へのアクセス（URL Fetch）の呼び出しは Google Workspace のアカウントで1日10万回です。月1,500件の申し出なら十分に収まります。

記録を残す

• 回答の行の番号、受けた日時、処理の日時と状態
• AIに渡した予定の候補と、AIが返した JSON の全文
• 申し出ごとの決まりの確かめの結果（締切、曜日、積み込み）と、そのとき使った決まりの値
• 予定表の変更の前と後の値、仮から確定にした担当と日時
• 送った確認の連絡の日時

4つ目の「変更の前と後」は、お客様からの問い合わせに答えるためのものです。 「頼んだのに届いた」と言われたとき、いつ、どの申し出で、何を何に変えたかを1行で示せます。