宿泊の予約が入ったあと、プラン・人数・到着予定に合わせた事前の案内メール（アクセス・駐車場・チェックイン・食事の時間）を作り、到着の数日前に送る

処理の起点を決める

トリガーは2つあり、Zap も2本に分けます。

1本目は、予約の通知メールに「予約通知」のラベルが付いたことを起点にします。ラベルはサイトコントローラーの送信元のアドレスと件名で Gmail のフィルタが付けます。Zapier の説明では、New Labeled Email は検知できる期間に制限が無い一方で、同じスレッドに返信が足されたときにも動くとされているので、通知のメッセージIDで予約の控えを引き、処理済みなら止めます。

2本目は、送付用のカレンダーの予定の開始を起点にします。予定は1本目の Zap が新規の予約のたびに入れます。送付の時刻は朝の10時にそろえ、フロントの日中の担当がいる時間に下書きが届くようにします。

送付の日時が過去になる予約があります。 到着の2日前に入った予約では、3日前の日時がすでに過ぎています。Formatter で出した日時と今の日時を比べ、過ぎていれば今日の次の正時を送付の日時にします。 到着の当日に入った予約は、案内を送らずにフロントのラベルを付けます。

入力データを集める

質を決めるのは、案内の正本です。 段落ごとに1行にし、「プランの種類」「車の有無」「到着予定の時刻」のどれで使うかを列で持たせます。夕食の時間や駐車場の台数を変えたら、直すのは正本の1行だけです。ひな形の文書ファイルのように、版が何通りもある状態をなくします。

予約の控えは、1本目と2本目の Zap をつなぐ場所です。 1本目が書き、2本目が読みます。送る直前に読み直すのはこの控えで、通知メールではありません。 取消と変更は、控えの状態として先に書き込まれています。

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

案内の段落は、条件の値ごとに引きます。 「プランの種類が部屋食」の行、「車あり」の行、「到着が19時以降」の行を、それぞれ Find Records で探します。1回の検索で全部を取ってAIに選ばせることはしません。 選ぶのは条件で決まることなので、検索の条件で済ませます。

送付用の予定は、予約番号を名前に入れて作ります。 Create Detailed Event で、名前を「事前案内 R-123456」のようにし、開始を送付の日時、終了をその15分後にします。2本目の Zap は、Event Start の出力の予定の名前から予約番号を取り出して控えを引きます。 予定の説明欄に宿泊客の名前やメールアドレスを入れないのは、カレンダーを見られる人を予約係より広げないためです。

宿泊客のメールアドレスが通知に載らない予約があります。 予約サイトによっては、通知に宿泊客のアドレスが載らないことがあります。アドレスが写し出せない予約は、送付の予定を入れずに「送付対象外」と控えに書きます。

AIへ渡す前に整形する

1. 重複の確認 … メッセージIDで予約の控えを引き、処理済みなら止めます
2. 通知の種別の確認 … 件名の「新規」「変更」「取消」の語で先に分け、取消はAIを通さずに控えを書き換えます
3. 本文の切り出し … 通知の定型の前置きと末尾を落とし、予約の項目の部分だけを渡します
4. 電話番号と住所を渡さない … 案内に要らない項目は、AI のステップに渡しません
5. 予約番号の照合 … 写し出した予約番号が、件名の予約番号と一致するかを見ます。違えば止めてフロントへ

2番目で取消をAIに通さないのは、取消だけは誤りが許されないからです。 件名の語で決まることを、AIの判断に任せる理由がありません。取消の通知が届いたら、すぐに控えを「取消」にします。

5番目は、写し出しの誤りを機械で見つけるための照合です。 予約番号は送る直前の引き直しの鍵なので、ここが違うと取消の確認が別の予約に対して行われます。

AIに処理させる

AIのステップは2つです。 1本目の Zap で通知から予約の項目を写し出し、2本目の Zap で書き出しと要望への一言を作ります。

1つ目：写し出す項目

プランの種類を unknown にできるようにするのは、案内の段落の選択に直結するからです。 新しいプランの名前は、どの種類かがAIに分からないことがあります。unknown の予約は自動で送らず、下書きに回します。

2つ目：作る文

1行目がこの構成の中心です。 書き出しを書かせると、AIは親切に「夕食は18時からご用意しております」と続けがちです。正本では部屋食は18時と19時の選択制でも、そう書かれます。 事実の段落は正本から差し込み、AIの文には事実を書かせません。

指示内容を固定する

2つ目のステップ（書き出しと一言）の指示：

あなたは温泉旅館の予約係です。到着の数日前に宿泊客へ送る案内メールの、
書き出しの部分だけを書いてください。案内の本文（アクセス・駐車場・
チェックイン・食事の時間）は別に差し込むので、書かないでください。

【書くもの】
- opening：宿泊客の名前、宿泊日、プラン名を入れて、到着を
  お待ちしていることを伝える2〜3文。
- request_note：要望の欄に記載がある場合だけ、要望を受け取ったことと、
  担当から改めて連絡することを伝える1〜2文。
  要望に応じられる、用意する、とは書かないでください。
- late_note：到着予定が {late_threshold} 以降の場合だけ、
  下の「遅い到着のご案内」を確認してほしいと伝える1文。

【厳守事項】
- 時刻・料金・台数・場所などの事実を書かないでください。
  事実は別に差し込みます。
- 料金、取消の条件、支払いについて書かないでください。
- 要望の欄に書かれていないこと（記念日、体調、同行者の事情など）に
  触れないでください。
- 「必ず」「確実に」「無料で」など、約束になる言葉を使わないでください。
- 呼びかけは「{guest_name} 様」、結びの言葉は書かないでください。
- needs_review：要望が空でない、またはプランの種類が unknown、
  または予約の状態が「変更あり」の場合は true にしてください。

【予約の内容】宿泊日：{check_in}／泊数：{nights}／人数：{guests}
　　　　　　　プラン名：{plan_name}／到着予定：{arrival_time}
【要望の欄の原文】{request_text}
【予約の状態】{status}

「要望に応じられると書かない」を名指しで書かないと、AIは「ご用意いたします」と書きます。 記念日のケーキ、アレルギーへの対応、早い到着の荷物の預かりなど、応じられるかどうかを決めるのは旅館です。 書いた瞬間に約束になります。

needs_review をAIにも返させるのは、二重の網にするためです。 下書きに回すかどうかは、本来は Zap の条件で決まります（次の出力形式）。AIの判定と Zap の条件のどちらかが立てば下書きにするので、片方の漏れを片方で拾えます。

出力形式を固定する

2つ目のステップは、Analyze and Return Data の出力項目として次のように定義します。

メールの本文は、Zap の側で次の順に組み立てます。 AIの出力と正本の段落を、決まった順に並べるだけです。

{guest_name} 様

{opening}
{request_note}

【アクセス】{正本：アクセス}
【チェックイン】{正本：チェックイン}
【ご夕食】{正本：プランの種類に合う夕食の段落}
【ご朝食】{正本：朝食}
【お車でお越しの方へ】{正本：駐車場}（車ありの予約だけ）
【遅い到着のご案内】{正本：遅い到着}（該当する予約だけ）
{late_note}

{署名}

項目に分けて受け取る理由の1つ目は、事実の段落とAIの文を混ぜずに済むことです。 案内の事実はすべて正本から差し込まれ、AIの文がどれほど長くても、事実の段落を書き換えることはできません。

2つ目は、下書きに回す条件を Zap で決められることです。

どれにも当たらない予約だけを、Send Email で送ります。 分岐は Paths で、自動で送る分岐と、どの条件にも当たらないときに動くフォールバックの2本です。フォールバックを「下書き」の側に置くので、条件の書き漏れがあっても、自動で送られることはありません。

システムへ連携する

予約システムとサイトコントローラーには書き込みません。 この構成が読むのは通知メールだけで、予約の状態を変えるのは、これまでどおり予約係の操作です。

Gmail の送信の上限に気をつけます。 Zapier の説明では、Gmail の送信の上限を超えると、アカウントが最大24時間止まることがあるとされています。月600件を毎日に分ければ多くはありませんが、同じアドレスで販促のメールを大量に送る運用とは分けておきます。

人が確認する

1. フロントのラベルの付いた下書きを開く … 要望・変更・不明のどれで下書きになったかを控えで見ます
2. 要望への返事を書き足す … 応じられるか、応じられないかを、旅館の決まりに沿って書きます
3. 事実の段落を確かめる … 変更のあった予約は、プランと人数が控えと合っているかを見ます
4. 送って、控えに記録する … 送ったあとで、控えを「送付済み」に書き換えます

自動で送った予約は、毎朝一覧で流し見ます。 前日に送った件数と、送らずに終えた取消の件数を見るだけです。1件ずつは開きません。

導入の直後は、自動で送る予約からも毎日数件を選んで開きます。 正本の段落の組み合わせがプランと合っているか、書き出しに事実が混ざっていないかを見ます。2週間続けて誤りが無ければ、流し見だけに切り替えます。

目標は、600件をならして1件1分です。 自動で送る予約は人の手がかからず、下書きの予約は要望への返事を書くので数分かかります。下書きが全体の2〜3割を超える月は、正本の段落か、プランの種類の対応が足りていません。

例外に対処する

上の2行目が、この構成でいちばん大事な行です。 予約から送付までの時間が長いほど、取消は増えます。送る直前に控えを読み直す一手が、第3章の（c）をなくします。

7行目の宿泊日の変更は、送付の予定の入れ直しが要ります。 Google Calendar の Delete Event で古い予定を消し、新しい到着日から送付の日時を計算し直して予定を入れます。消し損ねても、2本目の Zap が控えの宿泊日と予定の日付を照らすので、古い日付で送られることはありません。

記録を残す

• 予約の通知のメッセージID、受信日時、種別（新規・変更・取消）
• AIが写し出した項目の全文と、作った書き出しと一言
• 送付の日時と、実際に送った日時、送らずに終えた理由
• 使った正本の段落と、その段落を最後に直した日
• 下書きに回した理由と、フロントが送った日時

4つ目で段落を直した日を残すのは、案内の誤りを後から追うためです。 夕食の時間を変えた日より前に送った案内には、古い時間が書かれています。どの予約に古い案内が届いたかを、控えから拾えるようにします。

正本の段落を直したときは、すでに送った予約の扱いも決めます。 夕食の時間の変更のように宿泊客の動きが変わるものなら、控えから送付済みでまだ到着していない予約を拾い、変更の連絡を別に送るかをフロントの責任者が決めます。 自動で送り直すことはしません。