仕出し・ケータリングの注文をメールとフォームから拾い、日時・人数・料理・配達先・アレルギーを注文票にそろえて、足りない確認事項の返信案を作る

処理の起点を決める

経路が2つあるので、Zap も2本に分けます。 フォーム用とメール用で、取り出しより後の手順は同じ形にそろえます。

フォームは、Catch Hook で受けます。 Zap を作ると固有のURLが発行され、フォームの送信時にそのURLへ送るように設定します。Catch Hook は要求の本文を解析して欄ごとの値にします。このURLを知られると誰でも Zap を動かせるので、 フォームの設定以外に書きません。

メールは、Gmail の New Email Matching Search で受けます。 検索の条件には、フォームの通知メール、仕入先からのメール、請求書の送付など、注文でないことが分かっているものを除く式を書きます。Gmail のトリガーはいずれもポーリングで動くので、受信から Zap が動くまでに少し間があります。 当日の急ぎの注文は、電話でも受けている前提です。

フォームの通知メールを、メール用の Zap で拾わないようにします。 除かないと、同じ注文が2本の Zap で2回処理され、注文票に2行できます。

入力データを集める

質を決めるのは、料理の一覧です。 お客様は「松の弁当」「1,500円の」「いつもの」と書きます。料理の一覧に略称と価格帯を持たせておくと、AIはどの料理かを一覧から選べます。 一覧に無い書き方のときは、料理を「不明」にして確かめます。

アレルギーの項目は、品目の一覧と一緒に定義します。 消費者庁は、容器包装された加工食品について特定原材料を含む旨の表示を義務付けており、2026年4月にはカシューナッツが特定原材料に追加されています。 仕出しの料理がこの表示の対象かどうかとは別に、注文フォームの選択肢と、AIに渡す品目の一覧を、最新の一覧に合わせておきます。 古い選択肢のままだと、新しく加わった品目を書く欄がありません。

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

注文票の照合は、Google Sheets の Lookup Spreadsheet Row で行います。 検索する列にメールアドレスの列を、検索する値に差出人のメールアドレスを指定し、補助の検索列に「状態」を「受付中」として指定します。配達日が先の注文が複数あるお客様には、Lookup Spreadsheet Rows (Advanced) で最大500行までまとめて取り出します。

先の注文は、AIにも渡します。 「20日の弁当を25個に」という連絡が、どの注文の変更かを見分けるためです。ただし、AIに選ばせるのは候補までです。 候補が1つなら注文番号を返させ、2つ以上なら「候補が複数」と返させます。

何日前までの注文かの判定は、AIではなく注文票の数式で行います。 料理ごとの締切の日数と、受付日と配達日の差を比べて「締切超過」の印を出します。受けるかどうかの判断材料なので、決まった計算にしておきます。

AIへ渡す前に整形する

1. 本文の整形 … メールの署名、引用された過去のやり取り、定型の挨拶文を除きます。引用の記号で始まる行と署名の区切りより下を、Zap の前段の手順で落とします（落とし方はメールの書式に合わせて決めます）
2. 受付日の付与 … 「来週の金曜」「明後日」のような書き方を日付に置けるように、受付日を一緒に渡します
3. フォームの欄の値の取り込み … 選ばれた選択肢を、自由記述とは別の入力として渡します
4. 先の注文の要約 … 注文番号、配達日、料理、数だけにして渡します。配達先や電話は渡しません
5. 長さの確認 … 過去のやり取りが何十通も引用されたメールは、先頭から決めた文字数で切り、その旨を注文票に残します

2番目を省かないでください。 受付日が無いと、「来週の金曜」が何日かを決められず、AIは推測します。受付日を渡したうえで、置いた日付と元の表現の両方を返させます。 配達の日付を1週ずれて受けた注文は、取り返しがつきません。

AIに処理させる

させるのは、注文の文面から注文票の項目を取り出し、書かれていない項目を「不明」とし、新しい注文か変更の連絡かを見分けることです。

アレルギーの行が、この表でいちばん大事なところです。 「えびが苦手な方がいます」はアレルギーかもしれず、好みかもしれません。AIに「これはアレルギーではない」と決めさせません。 書かれた言葉をそのまま写し、allergy_status を「申告あり」とします。何も書かれていなければ「不明」で、確認の返信に必ず入ります。

指示内容を固定する

AI by Zapier の指示の欄に、次のように書きます。 出力のフィールドは、項目ごとに名前と型と説明を定義します。

あなたは仕出し・ケータリング店の受付で、届いた注文を注文票に整理する担当です。
次の文面から、注文票の項目を取り出してください。
書かれていることだけを写し、推測で埋めないでください。

【受付日】{received_date}
【差出人】{sender_company} {sender_name}
【フォームで選ばれた値】{form_values}  （メールの場合は空）
【このお客様の受付中の注文】{open_orders}  （注文番号、配達日、料理、数）
【料理の一覧】{menu}
【アレルギーの品目の一覧】{allergen_list}
【文面】{body}

【厳守事項】
- 書かれていない項目は「不明」にしてください。
- アレルギーは、「アレルギーはありません」「なし」と明記されたときだけ allergy_status を
  「なし」にしてください。何も書かれていなければ「不明」です。
  苦手、控えている、などの表現も、書かれた言葉のまま allergy_text に写し、
  allergy_status を「申告あり」にしてください。アレルギーかどうかを決めないでください。
- 配達の日時は、書かれた表現を delivery_text にそのまま写し、受付日をもとに
  日付と時刻に置けるときだけ delivery_datetime に入れてください。
- 料理は料理の一覧から選んでください。一覧に無い書き方なら menu_text に書かれたまま写し、
  menu_id は「不明」にしてください。
- 数は書かれた数のまま写してください。人数から数を計算しないでください。
- 受付中の注文の変更・取消と読めるときは、order_type を change か cancel にし、
  該当する注文番号を target_order に入れてください。候補が2つ以上なら
  target_order は「候補が複数」にしてください。
- フォームで選ばれた値と文面が食い違うときは、conflicts に両方を書いてください。
- 受けられるか、アレルギーに対応できるかを書かないでください。
- missing_items には「不明」になった項目の名前だけを並べてください。

アレルギーの指示を3行に分けて書いているのは、AIが好意的に読むからです。 文面が丁寧で行き届いていると、書かれていないことを「問題ない」と受け取る動き方をします。「明記されたときだけ」と条件で縛ります。

「人数から数を計算しない」も同じ理由です。 「15名の会議」と書かれていても、弁当が15個とは限りません。お茶だけの人、別に頼む人がいます。 数が書かれていなければ「不明」にして聞きます。

出力形式を固定する

AI by Zapier の出力のフィールドを、次の項目で定義します。

{
  "order_type": "new | change | cancel | not_order | unclear",
  "target_order": "",
  "delivery_text": "",
  "delivery_datetime": "",
  "menu_id": "",
  "menu_text": "",
  "quantity": "",
  "address": "",
  "access_note": "",
  "receiver": "",
  "allergy_status": "なし | 申告あり | 不明",
  "allergy_text": "",
  "dish_collection": "",
  "payment": "",
  "conflicts": "",
  "missing_items": ""
}

1つ目の理由は、Paths の条件に使えることです。 経路は次のとおりで、条件を項目の値だけで書けます。

2つ目は、allergy_status を3つの値に限れることです。 自由文で返させると、「特になし」「記載なし」「不明」が混ざり、厨房から見て区別がつかなくなります。 3つの値に限り、注文票の列も同じ3つの値にそろえます。

3つ目は、確認の返信の下書きに missing_items をそのまま差し込めることです。 何を聞くかはAIの出力で決まり、どう聞くかは自社で決めた聞き方の例で決まります。アレルギーが「不明」のときは、聞き方の例の「参加される方に食物アレルギーのある方はいらっしゃいますか」が必ず入ります。

システムへ連携する

確認の返信は下書きで作り、Send Email は使いません。 メールの注文には Create Draft Reply を使ってスレッドを保ち、フォームの注文には返信する元のメールが無いので Create Draft で新しく作ります。

注文票の既存の行は、Zap から書き換えません。 変更の連絡も、元の行の「変更の候補」の列に内容を書くだけで、数や時刻の列は受付の担当が書き換えます。 厨房は数と時刻の列だけを見ているので、確かめる前の変更が仕込みに入りません。

人が確認する

受付の担当が見るのは、注文票に足された行、変更の候補、Gmail の下書きです。

1. 日時と数を見る … 取り出された日時と数を、元の文面と見比べます。特に、受付日から置いた日付は必ず確かめます
2. 締切超過の印を見る … 印があれば、受けるか、時刻の相談をするかを決めます
3. アレルギーの申告を厨房に回す … 「申告あり」の注文は、allergy_text を厨房に見せ、対応できるかを決めてもらいます
4. 変更の候補を反映する … 元の行を確かめて数や時刻を書き換え、候補の列を消します
5. 下書きを直して送る … 聞く項目が多すぎれば絞り、急ぎの注文は電話に切り替えます
6. Dの経路のラベルを見る … 1日1回、ラベルの付いたメールを流し見て、注文が混ざっていないかを確かめます

3番目を省かないでください。 アレルギーに対応できるかは、料理と仕込みと器の扱いで決まり、受付の担当にも判断できません。 厨房が「対応できない」と言えば、その旨を確認の返信に書きます。

目標は、1件あたり5分です。 行と元の文面の見比べに2分、下書きの手直しと送信に2分、変更の候補とラベルの確認をならして1分という想定です。

例外に対処する

上の1行目が、運用でいちばん多い例外です。 常連のお客様ほど「いつもの」と短く書きます。前回の注文と同じものとして埋めることはしません。 前回と同じかを、電話か返信で一度確かめます。

記録を残す

• 注文の受付日時、経路（フォーム／メール）、差出人
• AI by Zapier に渡した本文と、返ってきた項目の全文
• 注文票に足した行と、変更の候補、担当が反映した変更の内容と日時
• 下書きの文面と、担当が送った文面
• アレルギーの申告と、厨房の対応の可否
• Zap の実行履歴（失敗した手順と、その注文）

3つ目で、反映した変更を残すのは、当日の数の食い違いを調べるためです。 「25個に増やしたはず」と言われたとき、いつ、どの連絡を、誰が反映したかで答えられます。

5つ目は、厨房の記録としても使います。 同じお客様から次の注文が来たとき、前回の申告を担当が確かめる材料になります。 ただし、前回の申告で今回の確認を省くことはしません。