クリーニング店に届く集配の依頼をメールとフォームから読み取り、集配の予定表に並べて、地域ごとの回り順の案を作る

処理の起点を決める

入口ごとにトリガーを分けます。 フォームは回答のたびに動くフォーム送信のトリガー、メールは10分ごとの時間主導型のトリガーです。電話で受けた依頼は受付の担当がフォームに打ち込むので、電話の依頼もフォームの経路に乗ります。

メールの拾い方は、Gmail の検索の文字列で決めます。受付のアドレスで、集配の依頼らしいメール（件名や送信元の常連の事業者）に「集配依頼」のラベルを自動で付けるフィルタを Gmail 側に置き、スクリプトは label:集配依頼 -label:集配_取込済 で探します。処理が終わったスレッドには「集配_取込済」のラベルを付けます。 付けるのは予定表への書き込みが成功したときだけにし、ラベルの付いていないものが、そのまま未処理の数になります。

GmailApp の search は、スレッド全体が大きすぎると失敗するとされ、ページ指定の版（search(query, start, max)）が案内されています。ページ指定の版で、1回に読む件数の上限を決めておきます。

前日16時のトリガーは、回り順の案だけを作ります。 依頼の取り込みとは別の処理にしておくと、取り込みで止まった1件が回り順の案まで止めることがありません。

入力データを集める

質を決めるのは、顧客台帳と地域表です。 台帳に駐車や訪問の注意事項が無いと、回り順の案を直すときに店長の記憶に頼ることになります。地域表が無いと、地域を決めるのにまたAIや地図を使うことになり、判断の筋道が毎回変わります。 地域は表で機械的に決めるのが、この構成の決まりです。

予定の枠を表で持つのは、受けすぎを見るためです。 時間帯ごとの件数が目安を超えたら、予定表のその枠に色を付けます。受けるかどうかを決めるのは人ですが、超えていることに気づくのは機械にさせます。

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

フォームの経路では、欄で分かれている項目をAIに渡しません。 氏名や電話は欄のまま正しいので、AIに通すと書き換わる余地が増えるだけです。AIに渡すのは、自由記入の品目と備考だけにします。メールの経路は本文に全部が書かれているので、本文全体を渡します。

顧客台帳の照合は、メールアドレスが先、電話番号が後、氏名は使いません。 同姓の顧客や、店名と代表者名が混ざる事業者があるからです。どちらでも引けなければ「新規」として扱い、新規の顧客は必ず受付の担当が確かめる行にします。

Geocoder の geocode は住所からおおよその地点を返し、results の各結果に formatted_address と緯度・経度が入ります。setRegion と setLanguage で日本と日本語に設定し、結果が1件でなければ「確認」の印にします。

AIへ渡す前に整形する

1. 引用と署名の除去 … メールの本文から「>」で始まる行と、「-- 」以下の署名を落とします。過去のやり取りの日付や品目を、今回の依頼として読ませないためです
2. 文字の正規化 … 全角の数字・英字を半角に、丁目・番地の「－」「ー」「の」の表記をそろえます
3. 基準日の付与 … 受信日時（フォームは送信日時）と、そこから14日分の日付と曜日の一覧を作り、AIに一緒に渡します
4. 顧客の引き当て … 台帳で引けた顧客は、顧客コードと台帳の住所を一緒に渡します
5. 重複の検知 … 同じ顧客で、同じ希望日の依頼が予定表にすでにあれば「重複の疑い」の印を付けます

3番目を軽く見ないでください。 「来週の火曜」「明後日」は、いつ送られたかで日付が変わります。基準日と曜日の一覧を渡さないと、AIは今日の日付を知らないまま日付を作ります。 一覧の範囲外の日付は、選べないようにします。

AIに処理させる

させるのは、依頼の文面を決まった項目に分けることと、書かれていない項目を「書かれていない」と返すことだけです。

右端の列が、この構成でいちばん大事な区別です。 空と ambiguous は、どちらも受付の担当が顧客に聞き直すものですが、空は「書いてもらう」、ambiguous は「どちらかを選んでもらう」で、聞き方が違います。分けて返させると、聞き直しの文面がそのまま決まります。

3行目がいちばん起きやすい失敗です。 台帳の住所と文面の住所が少し違うと、AIは台帳の住所に寄せて書きたがります。引っ越した顧客の新しい住所が、その瞬間に古い住所で上書きされます。 違っていれば違っていると返させ、どちらが正しいかは人が顧客に確かめます。

指示内容を固定する

あなたはクリーニング店の受付で、集配の依頼の文面を予定表の項目に分ける担当です。
渡された文面に書かれていることだけを取り出してください。推測で埋めないでください。

【取り出す項目】
1. request_type：集荷（pickup）／お届け（delivery）／両方（both）／不明（unknown）
2. name：氏名または屋号。文面の表記のまま
3. address：住所。文面の表記のまま
4. preferred_date：希望日。下の【基準日と日付の一覧】から選ぶ
5. time_slot：午前（am）／午後（pm）／夜間（night）
6. items：品目と点数の組。点数が書かれていなければ count は null
7. notes：しみ抜き、急ぎ、不在時の置き場所など、作業や訪問の注意事項

【厳守事項】
- 書かれていない項目は空（文字列は ""、数は null）にしてください。
  台帳の情報、過去の依頼、一般的な傾向から埋めないでください。
- 住所は文面の表記のまま写してください。番地を補う、表記を直す、
  台帳の住所に置き換える、のいずれもしないでください。
  台帳の住所と違う場合は address_differs を true にしてください。
- 希望日は【基準日と日付の一覧】にある日付からだけ選んでください。
  「来週の火曜」などの言い方は一覧の曜日で日付に直し、
  date_evidence に元の言い方をそのまま写してください。
  1日に決められない（「来週のどこか」「火曜か水曜」）ときは
  preferred_date を空にし、date_status を ambiguous にしてください。
- 時間帯が「夕方」「お昼ごろ」など3つの枠に当てはまらないときは
  time_slot を空にし、slot_status を ambiguous にしてください。
- 「冬物いろいろ」のように点数が無いものは、品目だけを写し count を null にしてください。
  点数を見積もらないでください。
- 料金、仕上がり日、受けられるかどうかには触れないでください。
- 集配の依頼でない文面（料金の質問、苦情、営業のメール）は、
  is_request を false にし、ほかの項目は空にしてください。
- 1通に複数の依頼（別の日、別の住所）があるときは、requests に分けて並べてください。

【基準日と日付の一覧】{base_date_and_calendar}
【顧客台帳で引けた情報】{customer_record}
【依頼の文面】{request_text}

「台帳の住所に置き換えない」を明記しないと、置き換えます。 台帳の情報を一緒に渡しているので、何も言わなければ、より整った台帳の表記を「正しい住所」として選びます。禁じるのは、台帳を根拠に文面を書き換えることそのものです。 それでも台帳を渡すのは、address_differs を判定させるためです。

「点数を見積もらない」も同じ理由です。 「冬物いろいろ」から「5点」を作られると、予定表の上では点数がそろって見え、聞き直すべき依頼が聞き直されなくなります。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。 公式の説明では、output_config.format に type: "json_schema" とスキーマを渡すと、スキーマに沿った出力が返ります。

{
  "is_request": true,
  "requests": [
    {
      "request_type": "pickup | delivery | both | unknown",
      "name": "",
      "address": "",
      "address_differs": false,
      "preferred_date": "2026-10-20",
      "date_status": "ok | missing | ambiguous",
      "date_evidence": "来週の火曜",
      "time_slot": "am | pm | night | ",
      "slot_status": "ok | missing | ambiguous",
      "items": [ { "item": "ワイシャツ", "count": 5 } ],
      "notes": ""
    }
  ]
}

1つ目の理由は、date_status と slot_status で聞き直しの印が機械的に決まることです。 どちらかが missing か ambiguous なら、スクリプトが予定表の「聞き直し」の列に印を付けます。印を付けるかどうかをAIに書かせないので、規則を変えるときはスクリプトだけを直します。

2つ目は、requests を配列にしておけることです。 事業者は「火曜に制服、金曜にタオル」のように1通で複数の依頼を書きます。1通を1行にすると、2つ目の依頼が消えます。

3つ目は、date_evidence で確認が速くなることです。 受付の担当は、日付が元の言い方から正しく直っているかを、メールを開かずに一覧で読めます。

公式の説明では、スキーマでは additionalProperties を false にする必要があり、数の範囲（minimum・maximum）や文字列の長さの制約は使えません。点数の上限や住所の長さは、受け取った後にスクリプトで確かめます。 また、出力が max_tokens で途中で切れたときはスキーマに沿わないことがあるとされているので、stop_reason を見て、切れていれば人に回します。

システムへ連携する

顧客台帳には書き込みません。 文面の住所が台帳と違っても、台帳を直すのは人が顧客に確かめた後です。スクリプトが書くのは予定表だけにします。

回り順の案の作り方は、次のとおりです。 翌日の依頼を時間帯と地域でまとめ、店を出発点と到着点にして、Geocoder で引いた緯度・経度を addWaypoint(latitude, longitude) で立ち寄り先に加え、setOptimizeWaypoints(true) で経路を取ります。返ってきた区間（legs）の終点の位置を、立ち寄り先の緯度・経度と突き合わせて、訪問の順番を読み取ります。 公式のページには立ち寄り先の数の上限が書かれていないので、1回の経路に入れる件数は地域と時間帯で分けて小さく保ち、試しの段階で何件まで通るかを確かめます。

Maps の経路の検索には1日の上限があります。 公式の割り当ての表では、Google Map の経路検索（Direction query）は個人のアカウントで1日1,000回、Google Workspace のアカウントで1日10,000回です。回り順の案は時間帯と地域の組ごとに1回なので、1日数十回に収まります。 1回の実行は6分までなので、前日の処理は時間帯ごとに分けて動かします。

API キーはスクリプトのプロパティに置き、コードに書きません。

人が確認する

人が開くのは、印の付いた行だけです。 印の付いていない行は、一覧で件数と時間帯の偏りを流し見ます。

1. 「聞き直し」を先に片づける … missing は書いてもらう、ambiguous は選んでもらう。前日の15時までに顧客へ連絡し、16時の回り順の案に間に合わせます
2. 「確認」を見る … 住所が地図で1か所に決まらない、台帳の住所と違う、新規の顧客。台帳を直すのは、顧客に確かめてからです
3. 「重複の疑い」を見る … メールと電話の両方で届いた依頼か、本当に2回の依頼かを確かめます
4. 回り順の案を確定する … 店長かドライバーが、時間の約束と駐車の事情を足して順番を直します

4番目を省かないでください。 地図の上で最短の順番は、開店前に回るはずの美容室を11時に置くことがあります。案のまま渡すと、約束の時間を守れない1件が出ます。

目標は、900件をならして1件1分です。 印が2割を大きく超える月は、フォームの欄か地域表を疑います。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの読み違いではなく、依頼の書き方と、地域表・台帳の整い方の問題です。

記録を残す

• 元の文面（メールのスレッドのID、フォームの回答の行）と受信日時
• AIに渡した基準日と、顧客台帳の引き当ての結果
• Claude API が返したJSONの全文と stop_reason
• 予定表に書いた行と、付けた印
• 人が直した記録 … どの項目を、何から何に変えたか。回り順をどう入れ替えたか
• 時間帯・地域ごとの件数と、回り順の案から外した依頼の数

5つ目の「回り順をどう入れ替えたか」が、地域表と台帳を育てる材料になります。 同じ顧客をいつも先頭に動かしているなら、それは台帳の注意事項に書くべき事情です。店長の頭の中にあった段取りが、記録として表に移っていきます。

ログは予定表とは別のシートに置き、文面の全文は保存期間を決めて消します。