予約サイトと電話受付代行から届く宴会・貸切の予約通知を予約台帳にそろえ、確認の要る点を店長に知らせる

処理の起点を決める

予約専用アドレスへの通知メールの着信を起点にします。 Gmail Trigger の確認の間隔は5分にします。宴会の予約は当日の朝に人数が変わることがあり、1時間おきでは、仕込みの前に台帳が直りません。

拾う範囲は、Gmail Trigger のフィルタで絞ります。公式のページでは、ラベル、Gmail の検索の書き方（from: など）、既読・未読、送信者で絞れるとされています。この構成では次のようにします。

入力データを集める

質を決めるのは、コースマスタの「予約サイト上の掲載名」の列です。 予約サイトに載せているコース名は、季節ごとの売り文句が付いて店の呼び名と違っています。この列が無いと、毎回「該当コースなし」の確認が店長に飛びます。

店舗マスタの「予約サイト上の店名」も同じです。 「◯◯ 駅前店」「◯◯ 駅前本店」のような違いで店舗が決まらないと、席数の確認もできません。

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

Gmail Trigger は、既定の Simplify（簡略化） がオンだと、メッセージID・ラベル・送信元や件名などのヘッダーを返します。本文が要るので、続けて Gmail ノードの「メッセージの取得（Get）」を Simplify をオフにして呼び、本文を取ります。

台帳の元の行は、Get Row(s) で「経路＋外部の予約番号」の列を値で引きます。 公式のページでは、Get Row(s) は既定で最初の一致だけを返し、すべて返すには「When Filter Has Multiple Matches」を「Return All Matches」にするとされています。同じ予約番号が2行あるのは台帳の異常なので、すべて返させ、2行以上なら要確認にします。

AIへ渡す前に整形する

1. 経路の判定 … 送信元のアドレスを経路の一覧と照らし、経路名を付けます。一覧に無い送信元は、AIに渡さず要確認にします
2. HTMLの除去 … HTMLの通知は Code ノードでタグを外し、表の行は「項目名：値」の形の行に直します
3. 引用と署名の除去 … 電話受付代行の通知に前回のやり取りが引用されていれば、> で始まる行と「以下、前回のご連絡」以降を外します
4. 定型の文の除去 … 予約サイトの通知の末尾にある、規約やキャンセル規定の定型の文を外します。経路ごとに、外す範囲の始まりの語を一覧に持たせます
5. 長さの確認 … 整えた本文が一定の長さを超えるものは、複数の予約がまとまっている可能性があるため、要確認の印を付けたうえで渡します
6. 重複の確認 … 同じメッセージIDのものが処理ログにあれば、処理をやめます

3番目と4番目を省かないでください。 引用の中には前回の人数やコースが書かれており、残すと古い人数を抜き出します。 キャンセル規定の定型の文には「取消」「キャンセル」の語が並ぶので、新規の予約が取消と判定されるもとになります。

AIに処理させる

させるのは、本文から決まった項目を抜き出し、その根拠の語句を写すことだけです。

2行目と3行目が、この構成でいちばん大事な制約です。 幅を丸める、言い換えるという処理は、どちらも読みやすくするための親切に見えますが、店長が電話で確かめるべき理由を、台帳から消してしまいます。

指示内容を固定する

Information Extractor の System Prompt Template に、次のように書きます（公式のページでは、出力の形の指示はノードが自動で付け足すとされているため、ここには項目の意味と禁止事項だけを書きます）。

あなたは飲食店の本部で、宴会・貸切の予約通知を予約台帳に写す担当です。
渡された通知メールの本文だけを根拠に、決められた項目を抜き出してください。

【通知の種類 notice_type】
- new ....... 新しい予約の通知
- change .... すでにある予約の内容が変わった通知
- cancel .... すでにある予約の取消の通知
- not_party . 宴会・貸切ではない通常の席の予約、または予約以外のメール
- unknown ... どれか決められない
キャンセル規定や注意書きの文に「キャンセル」とあるだけでは cancel にしないでください。

【厳守事項】
- 書かれていない項目は空にしてください。推測で埋めないでください。
- 店名とコース名は、本文に書かれた文字のまま写してください。
  店のどの店舗・どのコースに当たるかを決めないでください。
- 人数に幅がある場合（「30名前後」「25〜30名」「確定は前週」）は、
  party_size_min と party_size_max に分けて入れ、party_size_note に原文を写してください。
  1つの数に丸めないでください。
- アレルギー・食事の制限は、原文の語句をそのまま allergies に入れてください。
  言い換え・まとめ・分類をしないでください。「なし」と明記されていれば "なし" と入れます。
- 「軽いものなら大丈夫」「程度は当日確認」のような程度の記載も、原文のまま入れてください。
- 日付は本文のとおりに写し、曜日と日付が食い違う場合は date_note に両方を書いてください。
  どちらが正しいかを決めないでください。
- 変更の通知では、変わった項目を changes に「項目：前→後」の形で書いてください。
  前の値が書かれていなければ「項目：→後」としてください。
- 各項目について、根拠にした本文の語句を evidence にそのまま写してください。
- 1通に複数の予約が含まれていると判断した場合は、multiple_bookings を true にし、
  最初の1件だけを抜き出してください。
- 客への返事や店への提案は書かないでください。

【経路】{source_name}
【受信日時】{received_at}
【本文】{body}

「キャンセル規定の文だけで cancel にしない」を明記するのは、予約サイトの新規の通知に、キャンセル料の規定がほぼ必ず書かれているからです。 前処理で外しきれなかったときの二重の守りです。

出力形式を固定する

Information Extractor の Schema Type を「Define using JSON Schema」にして、次の形を定義します。

{
  "notice_type": "new | change | cancel | not_party | unknown",
  "external_id": "",
  "store_name_raw": "",
  "date": "YYYY-MM-DD",
  "date_note": "",
  "start_time": "HH:MM",
  "end_time": "",
  "party_size_min": 0,
  "party_size_max": 0,
  "party_size_note": "",
  "course_name_raw": "",
  "course_price_raw": "",
  "budget_raw": "",
  "seating": "private_hire | private_room | regular | unspecified",
  "allergies": [""],
  "organizer_name": "",
  "organizer_phone": "",
  "changes": [""],
  "multiple_bookings": false,
  "evidence": { "date": "", "party_size": "", "allergies": "" }
}

required は notice_type と multiple_bookings だけにし、ほかは任意にします。JSONの例から作ると全項目が必須になり、書かれていない項目を何かで埋めようとします。

1つ目の理由は、AIの出力と規則の判定を分けられることです。 JSONはAIが埋め、その後ろの Code ノードが店舗マスタ・コースマスタ・台帳と照らして、次の印を付けます。

印が1つでも付いた行は「要確認」、付かない行は「自動登録」として台帳に入れます。 印の付け方は規則なので、店の席数が変わってもマスタを直すだけで済みます。

システムへ連携する

台帳への書き込みは、新規と変更・取消で分けます。 新規は Append Row で行を足します。変更・取消は、Get Row(s) で見つかった元の行を Update Row で直し、取消は行を消さずに「状態」の列を「取消」にします。 消すと、取消の連絡が来たという記録が台帳から消えます。

店長への知らせは、店舗ごとに宛先を分けます。 店舗マスタに店長のアドレスを持たせ、要確認の行のうち allergy・private_hire_conflict・over_capacity・size_range の印が付いたものだけを店長に送ります。store_unmatched や course_unmatched のような台帳の側の問題は、予約担当にだけ送ります。 店長に台帳の整備の話まで届くと、肝心のアレルギーの知らせが埋もれます。

最後に、処理したメールに Gmail ノードで「n8n処理済み」のラベルを付け、既読にします。 公式のページでは、メッセージの操作に「ラベルの追加」と「既読にする」があります。ラベルが付いていない未読のメールが受信箱に残っていれば、それが未処理の通知です。

人が確認する

人が見るのは「要確認」の行だけです。 自動登録の行は、予約担当が1日2回、一覧で件数と店舗を流し見ます。

1. 予約担当が origin_not_found と multiple を先に見る … 台帳の行が二重になるか、変更が反映されないおそれがあるものです。元の行を探して、手で直します
2. 予約担当が store_unmatched・course_unmatched を直す … 台帳の行を直し、マスタに掲載名が足りなければマスタにも足します
3. 店長が allergy の行を確かめる … 原文の語句を料理長と見て、程度が書かれていなければ幹事に電話で確かめます
4. 店長が private_hire_conflict・over_capacity・size_range を確かめる … 貸切が重なっていれば、どちらを受けるかを決めて幹事に連絡します
5. 直した内容を台帳の「確認者」「確認日時」の列に残す

3番目を省かないでください。 アレルギーの記載は、台帳に入った時点では「書かれていた」という事実にすぎません。どの料理を外すか、調理場で分けられるかは店が決めることで、AIの出力にはその答えがありません。

例外に対処する

上から4行目が、いちばん気をつけるところです。 予約サイトの通知は届く順が入れ替わることがあり、変更が新規より先に来ることもあります。見つからないときに推測で近い行を直すより、保留にして人が探すほうが、台帳の事故が起きません。

記録を残す

処理ログのシートに、1通ごとに次を残します。

• 受信日時、Gmail のメッセージID、経路、件名
• 整えた後の本文（AIに渡したもの）と、AIが返したJSONの全文
• 付いた印と、台帳に入れた区分（自動登録／要確認／入れていない）
• 台帳のどの行を足した・直したか（行の番号と、外部の予約番号）
• 人が直した内容 … どの項目を、何から何へ直したか、誰がいつ直したか
• 店長に送った知らせの宛先と日時

AIに渡した本文を残すのは、抜き出しの誤りを後から確かめるためです。 誤りが前処理で外し損ねた引用のせいか、AIの読み違いかは、渡した本文を見ないと分かりません。

人が直した記録は、月に1回まとめて見ます。 同じ経路の同じ項目で直しが続くなら、プロンプトよりも前処理か、マスタの掲載名に原因があります。直しの多い経路から手を入れます。