酒蔵が見学・試飲の予約を Make で受け、AI で人数・言語・日時から受入の可否を判定して案内のメールを作る

処理の起点を決める

自社サイトの依頼フォームの送信と、代表アドレスへの依頼のメールの2つを起点にします。 フォームは送信のたびに Make の Custom webhook の URL へ項目を送ります。メールは Gmail の Watch emails で、「見学の依頼」のラベルを見張ります。ラベルは Gmail のフィルタで、件名や本文に「見学」「tour」「visit」が含まれるものに付けます。

フォームの側は即時、メールの側は15分おきにします。 フォームは送った人がその場で受付の確認を待っているので、すぐに受付の控えを返したいからです。メールは15分おきでも、英語の話せる社員の出勤日を待っていたいまよりずっと早く返ります。

Webhook には待ち行列があります。 公式のページでは、即時に処理されなかったデータは Webhook の待ち行列にため、その上限は契約のクレジット1万ごとに667件、最大1万件で、あふれた分は受け取らないとされています。また、受け取れる要求は10秒あたり300件までです。シナリオを止めたまま放置すると、その間の依頼は待ち行列にたまり続けます。 止めるときは、フォームの側に受付の停止を出します。

入力データを集める

質を決めるのは、受入の条件の書き方です。 条件は、例えば次のような表で持ちます。1行に1つの条件を書き、AIにはこの番号で結果を返させます。

季節の列があるのは、造りの時期の決まりを通常の時期の依頼に書き添えないためです。 希望の日付の季節の区分は、枠の台帳から引いてAIに渡します。AIに日付から季節を決めさせません。 造りの時期の始まりと終わりは年によって数日ずれ、台帳の側で決めているからです。

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

メールの依頼は、日付が「11月の週末」のような幅で届きます。 まず希望の日付の候補をAIに読み取らせ、その日付で枠の台帳を引いてから、条件の照合を呼びます。 呼び出しは2回になりますが、枠の情報なしで判定させるより確かです。

枠の台帳は、日付と回の2つで1行です。 残りの人数は台帳のシートの式で出しておき、シナリオはその値を読むだけにします。残りを Make の中で数え直さないのは、担当が台帳に手で書き込んだ電話の予約も、同じ式に入るからです。

AIへ渡す前に整形する

1. 重複の確認 … フォームは送信の時刻とメールアドレス、メールはメッセージIDで依頼の記録を引き、記録があれば止めます
2. 返信の引用を落とす … メールの返信では、前に送った案内の全文が下に付いてきます。引用の部分を落とし、依頼した人が書いた部分だけにします
3. 言語の印 … 本文の言語をAIに見分けさせる前に、フォームの言語の欄があればそれを優先します
4. 枠と季節の用意 … 希望の日付ごとに、回・残り・案内の言語・季節の区分を表にして渡します
5. AIに渡す範囲を絞る … 電話番号と住所は渡しません。名前は案内のメールの宛名にだけ使い、判定の呼び出しには渡しません

2番目を落とすと、前の案内に書いた条件を、依頼した人の要望として読みます。 前の案内に「大型バスは駐車場に入れません」と書いてあると、引用を残したまま渡すと、大型バスで来るという依頼に見えてしまいます。

5番目で名前を判定に渡さないのは、名前から年齢や国籍を推し量らせないためです。 人数の内訳は、依頼の文に書かれた数字だけから読み取らせます。

AIに処理させる

させるのは、依頼の文を読み取ることと、受入の条件に1つずつ照らすことの2つです。

not_stated を用意するのが、この構成でいちばん大事な区別です。 運転する人の数が書かれていない依頼は、条件 C8 を満たさないのではなく、まだ聞いていないだけです。 not_met と混ぜると、聞き返せば受けられる依頼を断ることになります。

運転する人の数は、とくに推し量らせません。 「家族4人で車で行きます」とあれば、運転する人は少なくとも1人いそうに見えます。それでも数は書かれていないので null にし、案内のメールで聞き返します。 道路交通法は、酒気を帯びて運転するおそれのある者に酒類を提供することを禁じています。誰が運転するかを決めるのは依頼した人で、AIではありません。

指示内容を固定する

あなたは酒蔵の直売所で、蔵見学・試飲の予約の依頼を受け付ける担当です。
下に渡す依頼の文を読み、受入の条件に1つずつ照らしてください。
受け入れるかどうかは決めないでください。条件ごとの結果だけを返します。

【すること】
1. 人数の内訳を、依頼の文に書かれた数字だけから写す。
   adults_20plus（20歳以上）、under_20（20歳未満）、
   drivers（運転する人）、preschool（小学生未満）、total（合計）。
2. 希望の日時を、第1〜第3希望の順に、日付と回に直す。
3. 依頼の言語と、案内に望む言語を書く。
4. 車いす・ベビーカー・大型バス・アレルギー・団体・旅行会社など、
   特記事項を依頼の文のとおりに写す。
5. 受入の条件の番号ごとに、結果を次から選ぶ。
   - met：依頼の内容がその条件を満たす
   - not_met：依頼の内容がその条件に反する
   - not_stated：判断に要る情報が依頼に書かれていない
   - not_applicable：その条件の季節が、希望の日の季節と違う

【厳守事項】
- 数が書かれていない内訳は null にする。「家族」「車で」「子ども連れ」
  などの言葉から、人数や運転する人の数を推し量らない。
- 「学生」「子ども」と書かれていても、20歳未満かどうかを決めない。
  数字で書かれていなければ under_20 は null にする。
- 季節の区分は、渡した枠の表の値を使う。日付から自分で決めない。
- 情報が足りない条件を not_met にしない。not_stated にする。
- 枠の残りを数えない。受け入れるかを書かない。
- 決まりの例外を認める書き方をしない。
- 確認したいことは questions に、依頼した人への質問の形で書く。

【受入の条件】{conditions}
【希望の日の枠（回・残り・案内の言語・季節の区分）】{slots}
【これまでのやり取り】{history}
【今回の依頼】{request}

「推し量らない」を言葉の例まで挙げて書くのは、AIが親切に埋めようとするからです。 「家族4人で車で」とあれば drivers: 1 と書きたくなります。1と書かれた依頼は、聞き返しの対象から外れてしまいます。 例を挙げて禁じると、null が返る割合がはっきり上がります。

「受け入れるかを書かない」も同じ理由です。 枠の表を渡すのは条件の照合のためで、結論は規則の側にあります。

出力形式を固定する

次の形の JSON を返させます。

{
  "request_id": "",
  "language": { "request": "ja | en | other", "guide_wanted": "ja | en | unknown" },
  "party": {
    "total": 5, "adults_20plus": 3, "under_20": 2,
    "drivers": null, "preschool": 0
  },
  "preferred": [
    { "rank": 1, "date": "2026-11-14", "time_slot": "10:00" }
  ],
  "special": ["wheelchair"],
  "checks": [
    { "condition_id": "C8", "result": "met | not_met | not_stated | not_applicable", "evidence": "" }
  ],
  "questions": ["当日運転される方は何名でしょうか。"],
  "is_group_or_agency": false
}

1つ目の理由は、checks と判定を別の層に置けることです。 checks はAIが埋め、受け入れるかはワークフローが規則で決めます。規則は次のとおりです。

2つ目は、数の確かめをワークフローで行えることです。 total と内訳の足し算が合うか、total が定員を超えないかを、Make の式で確かめます。構造化出力は数値の範囲の制約を持てないので、範囲の確かめはここで行うしかありません。

3つ目は、選んだ値の照らし方を決めておけることです。 公式のページでは、構造化出力は文字列の enum の大文字・小文字までは保証せず、スキーマと大文字・小文字だけが違う値が返ることがあるとされています。met と Met が混ざってもルーターが落とさないように、比べるときは小文字にそろえてから比べます。

システムへ連携する

ルーターのルートは、担当が見る→別の回の提案と聞き返し→受入→フォールバックの順に並べます。 公式のページでは、ルートは同時ではなく1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックのルートが処理するとされています。担当が見るルートを先頭に置くのは、旅行会社の団体の依頼が、受入のルートまで流れないようにするためです。

受入のルートでは、先に枠の台帳に仮の予約を書いてから案内を送ります。 書き込みに失敗したら案内を送りません。仮の予約は48時間で消える印を付け、依頼した人が返事をくれたら確定にします。 聞き返しのルートでも仮の予約を書き、返事を待つ間に別の依頼が入って枠が埋まらないようにします。

案内のメールは、決まった型の受入だけを自動で送ります。 決まった型とは、個人で6名まで、日本語の回か英語の回への英語の依頼、特記事項なし、not_stated なしのものです。それ以外はすべて下書きにします。

人が確認する

直売所の担当が確かめるのは、下書きに回ったものと担当へ回ったものです。

1. 担当へ回ったものを先に見る … 団体・旅行会社・車いす・大型バスの依頼です。枠をまとめて押さえるか、別の日を勧めるかを決めます
2. 聞き返しの下書きを確かめる … questions が依頼の文に合っているかを見ます。運転する人の数の聞き返しは、必ず残します
3. 別の回の提案を確かめる … 勧める回の残りを台帳で見ます
4. 送る … Gmail の画面から送り、依頼の記録の送り方を書き換えます

自動で送った分は、毎晩、件数と宛先を流し見ます。 受入の条件を書き換えた日と、造りの時期の始まりの週は、自動送信を止めてすべてを下書きにします。 季節の決まりが案内に正しく書き添えられるかを確かめるためです。

当日の受付では、依頼の記録の内訳をもとに試飲の札を配り分けます。 二十歳未満ノ者ノ飲酒ノ禁止ニ関スル法律は、酒類を供与する営業者に年齢の確認その他の必要な措置を求めています。依頼の時点の内訳は事前の目安で、試飲の前の年齢の確認は当日の人の仕事です。

例外に対処する

上の3行が大半を占めます。 どれもAIの誤りではなく、フォームの欄の作り方と枠の台帳の持ち方の問題です。 内訳の足し算が合わない依頼が多いなら、フォームの人数の欄を内訳ごとに分けるほうが早く効きます。

記録を残す

• 依頼の元の項目とメールの本文（引用を落とす前のもの）
• AIに渡した受入の条件の版と、枠の表
• 返ってきた JSON の全文と stop_reason
• 規則が出した判定と、そのときの枠の残り
• 送った案内の本文と、送り方（自動送信／下書き／担当へ）
• 仮の予約を書いた日時と、確定・取り消しの日時

2つ目で条件の版を残すのは、造りの時期の決まりが年ごとに変わるからです。 「去年は仕込み蔵に入れた」と言われたとき、そのときどの条件で案内したかが分かります。

最後の行は、聞き返しの書き方を見直す材料になります。 48時間で消えた仮の予約が多いなら、質問が1回で答えにくい形になっています。