結婚式場が Web 招待状の出欠の返信を Make で集め、席次と料理・引出物の数を更新して、アレルギーの申告を厨房に回す

処理の起点を決める

シナリオ①は、Google Forms の Watch Responses で、新しい返信を拾うところから始まります。 フォームは新郎新婦ごとに作らず、式場で1つのフォームを使い、招待コードで組とゲストを分けます。 組ごとにフォームを作ると、シナリオも組の数だけ要り、締め切りの過ぎた組のフォームを閉じ忘れます。

実行の間隔は、Make の既定では15分ごとです。返信の取りまとめは急ぎではありませんが、アレルギーの申告は早く厨房に届くほど良いので、既定の間隔のままにします。短くできる間隔はプランによって違います。

シナリオ②は、毎朝の定時実行です。 Make のスケジュールの設定で、毎朝9時に動かします。プランナーが出社して最初に見る一覧に、今日やることがそろっている状態にします。式場は土日が繁忙なので、平日だけでなく毎日動かします。

入力データを集める

質を決めるのは、フォームの作り方です。 アレルギーの欄に、食品表示の制度で表示が義務付けられている特定原材料（えび、カシューナッツ、かに、くるみ、小麦、そば、卵、乳、落花生）の9品目を選択肢として並べ、そのほかは自由記入にします。選択肢で受けた分はAIを通さずにそのまま使えるので、AIが抜き出すのは自由記入とメッセージの欄に書かれた分だけになります。

引出物のセットの区分は、新郎新婦が決めて一覧に入れておきます。 親族・上司・友人などで引出物を分けるのはよくあることで、その区分を返信から推し量ることはしません。

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

返信は、Watch Responses が返す回答をそのまま使います。 招待コードで招待客の一覧を Search Rows で引き、1件だけ当たったときに、その行を Update a Row で書き換えます。

同伴者は、1人ずつ招待客の一覧の行に分けます。 「同伴者2名（妻、長男5歳）」という返信なら、本人の行の下に2行を足し、それぞれに料理の区分を付けます。行を分けておけば、席次表の作成ソフトに読み込むときも、1人1席として扱えます。

席次表の作成ソフトには、招待客の一覧を書き出したファイルを読み込みます。 ソフトによって読み込める形式が違うので、ここは利用環境に応じた個別の作業になります。書き出すのは「出席」の行だけにし、欠席と未返信の行は席次表に入れません。席次が決まったら、卓番号を招待客の一覧に書き戻し、厨房の一覧の卓の列にも反映させます。

AIへ渡す前に整形する

1. 招待コードの確かめ … 一覧に1件だけ当たるかを見ます。当たらなければ「照合できない返信」に回します
2. 二重の返信の確かめ … 同じ招待コードで2回目の返信が来たら、上書きせずに印を付けます。出欠を変えた返信の可能性があるので、プランナーが確かめます
3. 自由記入が空かの確かめ … 自由記入とメッセージの欄が両方とも空なら、AIを呼びません
4. メッセージの欄の扱い … メッセージの欄は新郎新婦へのお祝いの言葉が中心ですが、要望が書かれることがあるので、AIに渡して要望の有無だけを見させます
5. 締め切りの確かめ … 最終の人数の確定日を過ぎた返信は、一覧に書き込む前にプランナーに知らせます

3番目で呼び出しの回数が大きく減ります。 自由記入の欄に何も書かないゲストが多いので、AIを呼ぶのは返信の一部だけです。「特になし」「なし」だけの欄も、空として扱います。

4番目は、見落としを防ぐための前処理です。 メッセージの欄の「おめでとう！当日は娘（3歳）も連れて行きます。乳製品が食べられません」という一文を、お祝いの言葉として読み飛ばさないために、必ずAIに通します。

2番目の二重の返信は、締め切りの近くに増えます。 「出席」で返したあとに予定が変わって「欠席」で返し直す、同伴者を1人足して返し直す、という返信です。機械で上書きすると、前の返信で厨房の一覧に載せたアレルギーの行だけが残り、欠席したゲストの料理を厨房が用意することになります。2回目の返信が来たら、招待客の一覧の行と厨房の一覧の行の両方に印を付け、プランナーがどちらを正とするかを決めてから書き換えます。新郎新婦がゲストから電話で聞いた変更も、同じ印の付いた行としてプランナーが入れます。

AIに処理させる

させるのは、自由記入とメッセージの欄から、次の項目を抜き出すことだけです。

アレルギーと「苦手な食材」は分けて抜き出させます。 「えびが苦手」はアレルギーではないかもしれず、「えびのアレルギー」は命に関わるかもしれません。ゲストの書き方のまま、どちらに入れたかを分けて返させ、迷ったものはアレルギーの側に入れさせます。

1行目がいちばん大事な線引きです。 「少しなら大丈夫」とゲストが書いても、それを厨房がどう扱うかは別の話です。AIは書かれた言葉を写すだけにし、程度を言い換えさせません。

指示内容を固定する

あなたは結婚式場で、招待客からの出欠の返信を取りまとめる担当です。
返信の自由記入の欄とメッセージの欄から、料理と当日の準備に関わる情報を抜き出してください。
書かれていないことを推測で埋めないでください。

【抜き出すもの】
- children：同伴のお子様。書かれた呼び方（長男、娘など）と年齢を、
  書かれたとおりに。年齢が書かれていなければ age_text を空に
- allergies：アレルギーの申告。誰の（本人・同伴者の呼び方）、何の食材か、
  原文の書き方を original_text にそのまま
- severity_text：程度について書かれた言葉を原文のまま（「エキスもだめ」など）
- dislikes：アレルギーではなく苦手・食べない食材
- dietary：宗教上の理由、菜食などの食事の制限
- assistance：車椅子、授乳の場所、席の位置などの要望
- other_requests：上に当てはまらない要望を原文のまま

【厳守事項】
- アレルギーか苦手かが書き方から決められないときは、allergies に入れ、
  uncertain を true にしてください。
- 程度を言い換えたり、軽く書き直したりしないでください。原文のまま写してください。
- 料理を出してよいか、どう対応するかは書かないでください。
- 年齢から料理の種類を決めないでください。年齢を写すだけにしてください。
- お祝いの言葉だけで要望が無ければ、すべての配列を空にしてください。
- 新郎新婦へのお祝いの言葉は抜き出さないでください。

【フォームのアレルギーの選択肢で選ばれたもの】{allergy_choices}
【同伴者の人数】{companions}
【自由記入の欄】{free_text}
【メッセージの欄】{message}

「迷ったものはアレルギーに入れて uncertain を true」は、見落としの側に倒さないための一文です。 苦手をアレルギーと扱う誤りは、プランナーの確認の電話1本で直りますが、アレルギーを苦手として扱う誤りは、厨房まで届きません。

フォームの選択肢をAIに渡しているのは、重複を見分けるためです。 選択肢で「卵」を選び、自由記入にも「卵はゆで卵もだめです」と書いたゲストの申告を、別々の2件として厨房に出さないようにします。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "children": [
    { "label": "長男", "age_text": "5歳" }
  ],
  "allergies": [
    { "person": "長男", "food": "卵", "original_text": "長男が卵アレルギーです。卵が入ったものは食べられません",
      "severity_text": "卵が入ったものは食べられません", "uncertain": false }
  ],
  "dislikes": [],
  "dietary": [],
  "assistance": [
    { "type": "seat", "original_text": "ベビーカーを置ける席だと助かります" }
  ],
  "other_requests": []
}

1つ目の理由は、料理の区分を機械的に付けられることです。 age_text から数字を取り出し、式場の決まりの表（たとえば未就学児はお子様用のプレート、小学生はお子様の料理）に当てはめて区分を付けます。「小学2年」のように数字だけでは決まらない書き方は、区分を空にしてプランナーに回します。

2つ目は、厨房の一覧に1申告1行で載せられることです。

厨房は「確定」の行だけを見て対応を決めます。 「確認待ち」の行は、厨房にとっては「これから確定する可能性がある申告」の予告で、食材の手配の準備に使えます。

3つ目は、uncertain で確認の順番を決められることです。 プランナーは uncertain が true の申告から先にゲストに確かめます。

システムへ連携する

ゲストには自動で返事を送りません。 返信を受け付けた旨の画面はフォームの側で表示し、アレルギーの確認の連絡はプランナーが行います。ゲストへの連絡の窓口を、新郎新婦とプランナーに一本化しておくためです。

厨房の発注の仕組みにも書き込みません。 最終の人数と確定したアレルギーは、確定日にプランナーが厨房に伝え、厨房が発注します。

人が確認する

アレルギーの申告は、全件をプランナーが確かめます。 厨房の一覧の「確認待ち」の行を見て、ゲスト（連絡先を預かっていなければ新郎新婦を通して）に、食材と程度を確かめます。

1. uncertain の申告を先に確かめる … アレルギーか苦手かが分からないもの。多くは「苦手なだけです」で取り下げになります
2. 程度を確かめる … 「エキスもだめか」「調理器具の共用はどうか」を、厨房と決めた聞き方で確かめます
3. 行を「確定」にする … 確かめた内容を行に書き足し、確認したプランナーと日を入れます
4. 区分が空のお子様を確かめる … 年齢が書かれていない、または数字で決まらないお子様の料理の区分を決めます
5. 二重の返信と照合できない返信を見る … 出欠を変えた返信か、別のゲストの返信かを確かめます

1番目から3番目は省けません。 厨房が対応を決めるには、文字で書かれた申告だけでは足りないことが多く、ゲストに確かめた内容が「確定」の行に書かれていることが、厨房との約束です。

目標は、1,500件をならして1件1分です。 自由記入が空で照合が済んだ返信は、一覧を流し見て数秒で終わり、アレルギーの申告がある返信は確認の連絡を含めて10分前後かかります。

例外に対処する

API が応答しないときも、出欠の書き込みは止めません。 出欠と同伴者の人数はフォームの決まった欄から書き込めるので、AIが止まっても、料理と引出物の数は更新されます。 止まるのは自由記入の抜き出しだけで、それはプランナーが原文を読めば済みます。

8行目は、気づきにくい止まり方への備えです。 接続の再認証が切れると、返信は届いているのに一覧が更新されません。毎朝、フォームの回答の数と一覧の返信済みの数を突き合わせると、止まった日のうちに気づけます。

記録を残す

• フォームの返信の原文（フォームの回答として残る）
• AIに渡した自由記入とメッセージの欄と、返ってきたJSONの全文
• 招待客の一覧の書き込みの記録（いつ、どの返信で、何を書き換えたか）
• 厨房の一覧の行と、状態の変わった記録（確認待ち→確定、取り下げ）
• プランナーがゲストに確かめた内容と、確認した日

4つ目と5つ目は、当日に何かあったときに経緯を追うためです。 どの申告を、誰が、いつ確かめ、厨房にどう伝えたかが残っていれば、当日の料理の判断の根拠を示せます。

挙式が終わった組の記録は、式場で決めた期間で消します。 招待客の住所やアレルギーは、婚礼が終われば式場が持ち続ける理由の薄い情報です。