グランピング施設が予約の確定の通知を Make で受け、食材・アクティビティ・送迎の手配の一覧を作って、前日の準備の漏れを防ぐ

処理の起点を決める

シナリオは2つに分けます。 1つ目は通知ごとに動くシナリオ、2つ目は毎日決まった時刻に3つの表を作るシナリオです。

1つ目は Gmail の Watch emails で通知を拾います。 フィルターには、条件を選ぶ簡単なフィルターと、Gmail の検索の書き方で指定する方法があり、1回に扱う上限は500件以下とされています。Gmail の検索の書き方で、2つの予約サイトと自社の予約の仕組みの送信元だけに絞ります。 15分ごとに動かします。

拾ったメールにはラベルを付けます。 「処理済み」のラベルは、予約の台帳への書き込みまで通ったときだけ Update email labels で付けます。既読にする設定は使いません。 事務の担当が先にメールを開いても拾えるようにするためです。

2つ目は、Make のスケジュールで毎日15時に動かします。 スケジュールには、一定の間隔、1回だけ、毎日、平日、毎週、毎月、日付の指定、手動の実行の設定があるとされています。「毎日」を選びます。 15時にしているのは、仕入先に人数を伝える締めが夕方だからです。時刻の設定がどのタイムゾーンで動くかは、組織とシナリオの設定で確かめます。

入力データを集める

質を決めるのは、プランと枠と便の表の表示名の列です。 予約サイトのプランの名前は、季節の宣伝の言葉が付いて長くなり、同じプランでもサイトによって名前が違います。 表示名を並べておけば、抜き出した名前から施設のコードを引けます。

予約の後の問い合わせは、事務の担当が転送します。 宿泊者が後から「子どもがそばアレルギーでした」と連絡してくることがあります。このメールを、件名に予約番号を入れて決まったアドレスに転送すると、1つ目のシナリオが変更として拾います。

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

通知のメールは Watch emails が本文ごと渡します。本文が HTML のときは、Make の側で改行を残す形で文字にしてから渡します。

変更と取消は、サイトの名前と予約番号の2つで引きます。 番号の形はサイトごとに違い、番号だけで引くと、別のサイトの同じ番号に当たることがあります。 Search Rows の Limit は1にせず、2つ以上返ったら要確認に回します。

送迎の便は、Make が決めます。 抜き出した駅の到着の時刻より後で、最も早い便です。便の時刻と定員は便の表から引き、到着の時刻が書かれていなければ便を決めずに印を付けます。

AIへ渡す前に整形する

1. 送信元の確認 … 予約サイトと自社の予約の仕組みの送信元か確かめます
2. 本文を文字にする … HTML を改行つきの文字にし、広告や署名を外します
3. 転送のメールの確認 … 転送されたメールは、件名の予約番号を Make が読み、本文と一緒に渡します
4. 連絡先を伏せる … 電話番号とメールアドレスは「［連絡先］」に置き換えてから渡します
5. 同じメールの二度目を外す … メールの ID が処理済みの一覧にあれば処理しません

4番目は、抜き出しに連絡先が要らないためです。 宿泊者への確かめは、予約サイトのメッセージか、台帳から事務の担当が電話で行います。

アレルギーの記載は、前処理で手を加えません。 改行や句読点も含めて、本文のまま渡します。

AIに処理させる

させるのは、通知のメールから予約の中身を抜き出すことだけです。

アレルギーの記載は、要約も分類もさせません。 「卵」「乳」のような品目に分けさせると、「加熱したものも不可」「同じ鉄板で焼いたものも避けたい」といった程度の記載が落ちます。 料理長が対応を決めるのに要るのは、品目の名前より、その程度の記載です。

子ども・幼児の区分は、サイトの書き方のまま写させます。 予約サイトによって「子ども（小学生）」「子ども（3歳〜12歳）」「添い寝」と区分が違います。区分の名前を child_labels に写させ、どの区分を子ども向けのプランに数えるかは、プランと枠と便の表に施設が書いておきます。 AI に年齢から区分を決めさせると、サイトごとの決まりとずれます。

指示内容を固定する

あなたはグランピング施設の事務所で、予約の通知メールを読む担当です。
渡されたメールの本文だけを読み、予約の中身を抜き出してください。
書かれていないことを推測で埋めないでください。

【通知の種類】
- confirmed ... 新しい予約が確定した通知
- modified .... 日付・人数・プラン・オプションなどが変わった通知、
                 予約の後の追加の連絡
- cancelled ... 予約が取り消された通知
- other ....... 予約の中身を含まない通知
- unknown ..... 判断がつかない
件名だけで決めず、本文の書き方で判断してください。

【厳守事項】
- アレルギー・食べられないもの・体質についての記載は、本文の文のまま、
  全部を allergy_notes に写してください。要約しない、品目に分けない、
  言い換えない。誰についての記載か書かれていれば、それも含めて写してください。
- アレルギーについての記載が無ければ allergy_notes は空にしてください。
  「なし」と書かれていれば、その文を写してください。
- プラン・オプション・アクティビティの名前は本文の表記のまま写してください。
- 人数は大人・子ども・幼児を分けて、本文の数字をそのまま入れてください。
  合計しか書かれていなければ guests_total だけに入れてください。
- 日付は YYYY-MM-DD にしてください。年が無いときは受信日時より後で
  最も近い日付にし、year_inferred を true にしてください。
- 時刻が書かれていないアクティビティは、time を null にしてください。
- 送迎の希望は、駅の名前と到着の予定の時刻が書かれていれば写してください。
- 変更の通知では、何が何から何に変わったかを changes に並べてください。
- ［連絡先］の伏せ字を戻そうとしないでください。

【受信日時】{received_at}
【送信元】{from}
【件名】{subject}
【本文】{body}

「『なし』と書かれていれば、その文を写す」を入れているのは、空と「なし」を分けるためです。 自社の予約の仕組みでは、アレルギーの欄が必須で「なし」と書かれます。予約サイトでは欄が無いことがあり、空は「聞いていない」という意味です。 料理長の表で、この2つを分けて見せます。

出力形式を固定する

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

{
  "notice_type": "confirmed",
  "channel": "サイトA",
  "reservation_no": "",
  "check_in": "2026-11-21",
  "nights": 1,
  "year_inferred": false,
  "tent": "ドームC",
  "adults": 2, "children": 2, "infants": 0, "guests_total": null,
  "child_labels": ["子ども（小学生）"],
  "meal_plans": [ { "name": "", "count": 4 } ],
  "allergy_notes": ["娘（7歳）が卵アレルギーです。加熱したものも食べられません。"],
  "activities": [ { "name": "サウナ貸切", "date": "2026-11-21", "time": "16:00", "people": 2 } ],
  "shuttle": { "station": "", "arrival_time": "14:32", "people": 4 },
  "changes": []
}

1つ目の理由は、notice_type でルーターを分けられることです。 Make のルーターは各ルートを順に処理し、ほかのどの条件にも合わないものをフォールバックのルートで処理するとされています。確定・変更・取消の3つのルートを置き、other と unknown はフォールバックで要確認に落とします。

2つ目は、allergy_notes が配列で残ることです。 予約の台帳には原文の文を1つのセルに並べ、料理長の表にはそのセルをそのまま写します。 変更で追加の連絡が来たら、前の文を消さずに後ろに足します。

連泊の予約は、泊まる夜ごとに分けて台帳に書きます。 nights が2以上なら、Make が夜ごとの行を作り、2泊目の夕食のプランが1泊目と違う予約は、meal_plans に夜の日付を付けて返させます。 1つの行のままだと、2泊目の食材が3日前の集計から漏れます。

3つ目は、2つ目のシナリオで Group by を使えることです。 予約の台帳の行を Search Rows で取り、Array aggregator の Group by にプランのコードを入れれば、プランごとの人数の合計の表ができます。

スキーマには、範囲の制約を書きません。 Claude の構造化出力は、数値の minimum・maximum や文字列の長さの制約に対応しておらず、使うと400のエラーになるとされています。人数が0より大きいか、宿泊日が今日より後かは、ルーターの条件で確かめます。 オブジェクトには additionalProperties: false を付けます。

調理の人数表の1行は次の形にします。

システムへ連携する

仕入先への人数の連絡は、自動で送りません。 調理の人数表を事務の担当が確かめてから、いつもの方法で伝えます。取消の通知で行を消さず、印を付けるだけにするのも、後で経緯を追えるようにするためです。

15時より後に届いた変更は、翌朝の要確認に載せます。 3日後の到着の予約に変更が入ったら、2つ目のシナリオの後でも1つ目のシナリオが台帳を直し、「表を作った後の変更」の印を付けます。 事務の担当が朝に見て、調理・アクティビティ・送迎の担当に口頭で伝えます。

人が確認する

1. 要確認の一覧を先に見る … 表示名が表に無いプラン、unknown の通知、同じ予約番号の行が2つ以上あるもの
2. 新しい行を通知の原文と見比べる … 宿泊日・人数・プランを見ます
3. 料理長がアレルギーの記載を読む … 原文の文を読み、対応できるか、宿泊者に確かめるかを決めます
4. 枠と便の超過を決める … 定員を超えた枠は時刻をずらす案を、送迎は増便か別の便を決め、宿泊者に連絡します
5. 3つの表を各担当に渡す … 食材の人数は事務の担当が仕入先に伝えます

3番目を省かないでください。 アレルギーの対応は、宿泊者の健康に関わります。抜き出しが正しくても、対応できるかは料理長にしか決められません。 料理長の確認の列が「未」のままの予約がある日は、表を渡さない決まりにします。

4番目の送迎の連絡は、到着の前日までに済ませます。 便が変わったことを宿泊者が知らないと、駅で待つことになります。連絡したかどうかを送迎の便の表の列に残し、運転手はその列を見て乗る人を確かめます。

目標は、300件をならして1件4分です。 取消は印を確かめるだけ、確定は行と原文を見比べる数分、アレルギーや枠の超過のあるものはさらにかかります。

例外に対処する

下から3行目は、調理の人数表で効いてきます。 子ども向けのプランがあるので、内訳が分からないと食材の量が決まりません。

最後の行は、抜き出す項目を増やしすぎないための行です。 要望はさまざまで、項目を足すほど指示が長くなり、肝心のアレルギーと人数の抜き出しがぶれます。 要望は原文のまま1つの欄に置き、人が読みます。

記録を残す

• 拾った通知のメールの ID、受信日時、送信元、件名
• Claude が返した JSON の全文
• 予約の台帳の行に加えた変更と、その前の値
• 毎日の3つの表と、作った時刻
• 料理長のアレルギーの確認の結果と、宿泊者に確かめた内容
• 要確認に回した理由

3つ目で「直す前の値」を残すのは、人数が何度も変わる予約があるためです。 食材を注文した時点の人数と、当日の人数を比べられます。

5つ目は、事務所の台帳とは別の場所に保存してもよい情報です。 アレルギーの対応の記録は、料理長と事務所が見られれば足ります。