民泊の運営代行会社が予約サイトの確定の通知メールから予約の中身を取り出し、清掃の手配と鍵の受け渡しの案内を Make で作る

処理の起点を決める

共有のメールアドレスに予約サイトからの通知が届いたことを起点にします。 Watch emails を15分ごとに動かし、Gmail の検索の書き方で from: に3つのサイトの送信元を並べて絞ります。宿泊者からのメッセージの転送や、広告のメールは拾いません。

拾ったメールにはラベルを付けます。 「処理済み」のラベルを付けるのはシナリオが最後まで通ったときだけにします。途中で止まったメールにはラベルが付かないので、受信箱の未処理の数がそのまま残りの数になります。

既読にする設定は使いません。 担当が先にメールを開いて既読にしてしまうと、「未読だけを拾う」設定では拾われなくなります。拾うかどうかの印は、既読ではなくラベルで持ちます。

15分ごとにしているのは、当日の予約があるからです。 予約サイトによっては当日のチェックインの予約も受け付けるので、1日1回の実行では清掃の手配が間に合いません。シナリオの最後に、チェックインが24時間以内の予約には手配表で「急ぎ」の印を付け、担当の通知の宛先にも知らせます。

入力データを集める

質を決めるのは、物件の台帳の表示名の列です。 予約サイトの物件の名前は、掲載のときに付けた宣伝の文句が入った長い名前のことがあり、サイトごとに少しずつ違います。 台帳に表示名が無いと、取り出した名前から物件を引けません。

案内のひな形は、鍵の受け渡しの方法ごと・言語ごとに持ちます。 案内の文面は AI に書かせず、ひな形に取り出した値を差し込むだけにします。物件の流れを AI が言い換えると、本人確認の手順が抜けることがあるからです。

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

通知のメールは Watch emails が本文ごと渡します。本文は HTML のことが多いので、Make の側で文字だけにしてから AI に渡します。 表の形の HTML を文字にすると項目名と値が離れることがあるため、改行を残す形で文字にします。

変更と取消は、予約番号で手配表を引きます。 予約番号は予約サイトごとに形が違うので、手配表には予約サイトの名前と予約番号の2つを並べて持ち、2つで引きます。 番号だけで引くと、別のサイトの同じ番号に当たることがあります。

Search Rows の Limit は1にしません。 同じ予約番号の行が2つ以上あったら、それ自体が書き写しの誤りの印です。2つ以上返ったら要確認の一覧に回します。

清掃の日時は、取り出した値と台帳から Make が決めます。 決め方は次のとおりです。

終わりの期限を手配表から引くのは、同じ日にチェックアウトとチェックインが重なる物件があるからです。 次の予約が同じ日の夕方なら、清掃の枠は数時間しかありません。依頼の下書きに期限を書いておけば、清掃の担当が段取りを組めます。 寝具のシーツやカバーは宿泊者が入れ替わるごとに洗濯したものと取り替える必要があるとされているので、組数は人数から出して依頼に書きます。

AIへ渡す前に整形する

1. 送信元の確認 … 3つの予約サイトの送信元か確かめます。違えば処理しません
2. 本文を文字にする … HTML を改行つきの文字にし、画像や署名の部分を外します
3. 長さの確認 … 本文が長すぎるときは、予約の中身が書かれた範囲だけを切り出します。切り出せなければ要確認に回します
4. 宿泊者の連絡先を伏せる … 本文に電話番号やメールアドレスがあれば、AI に渡す前に「［連絡先］」に置き換えます
5. 同じメールの二度目を外す … メールの ID が処理済みの一覧にあれば処理しません

4番目は、取り出しに連絡先が要らないためです。 宿泊者への連絡は予約サイトのメッセージで行うので、この構成は連絡先を持ちません。

5番目は、Watch emails の取りこぼしを手で拾い直したときのためです。 同じ通知で手配表に2行できるのを防ぎます。

AIに処理させる

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

物件の表示名を物件コードに直させないのは、照合を台帳でするためです。 AI に物件を当てさせると、似た名前の物件に寄せて答えることがあります。表記のまま取り出させ、台帳の表示名と完全に一致するかを Make で見ます。

指示内容を固定する

あなたは民泊の運営代行会社で、予約サイトからの通知メールを読む担当です。
渡されたメールの本文だけを読み、予約の中身を取り出してください。

【通知の種類の選び方】
- confirmed ... 新しい予約が確定した通知
- modified .... 日付・人数・物件などが変わった通知
- cancelled ... 予約が取り消された通知
- other ....... 予約の中身を含まない通知（レビューの依頼、精算のお知らせなど）
- unknown ..... どれか判断がつかない
件名だけで決めず、本文の書き方で判断してください。

【厳守事項】
- 本文に書かれていることだけを取り出してください。
  書かれていない項目は null にしてください。推測で埋めないでください。
- 物件の名前は、本文の表記をそのまま写してください。
  短くしたり、別の物件の名前に直したりしないでください。
- 日付は YYYY-MM-DD に直してください。曜日だけで日付を決めないでください。
  年が書かれていないときは、受信日時より後で最も近い日付にし、
  year_inferred を true にしてください。
- 人数は大人と子どもを分けて、本文の数字をそのまま入れてください。
  合計しか書かれていなければ guests_total だけに入れてください。
- 変更の通知では、何が何から何に変わったかを changes に並べてください。
  変更の後の値だけでなく、前の値も書かれていれば写してください。
- 取消の通知では、取り消された予約の宿泊日を写してください。
- 電話番号やメールアドレス、［連絡先］の伏せ字を元に戻そうとしないでください。
- 鍵、暗証番号、入室の方法について何も書かないでください。

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

「件名だけで決めず、本文の書き方で判断する」が、この指示でいちばん効く一文です。 予約サイトによっては、変更の通知の件名が確定の通知とほとんど同じです。本文に「変更前」「変更後」のような書き方があるかで分けさせます。

年が書かれていないときの扱いを書いているのは、年末年始の予約のためです。 12月に届いた1月の予約を、その年の1月と取り違えないようにします。year_inferred が true のものは、担当が手配表で確かめます。

出力形式を固定する

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

{
  "notice_type": "confirmed | modified | cancelled | other | unknown",
  "channel": "",
  "reservation_no": "",
  "listing_name": "",
  "check_in": "2026-11-14",
  "check_out": "2026-11-16",
  "year_inferred": false,
  "adults": 3,
  "children": 1,
  "guests_total": null,
  "arrival_time": "16:00",
  "language": "en",
  "changes": [
    { "field": "check_out", "before": "2026-11-15", "after": "2026-11-16" }
  ]
}

1つ目の理由は、notice_type でルーターを分けられることです。 Make のルーターは各ルートを順に評価し、どの条件にも当たらないものはフォールバックのルートに流れるとされています。confirmed・modified・cancelled の3つのルートを置き、other と unknown はフォールバックで要確認の一覧に落とします。

2つ目は、changes で変更の中身が手配表に残ることです。 「チェックアウトが1日延びた」なら、清掃の日も1日ずらす必要があります。清掃の担当への依頼の下書きに、変更の前後をそのまま書けます。

3つ目は、null が要確認の合図になることです。 宿泊日か人数が null なら、清掃の手配表に行を足さずに要確認に回します。

手配表の1行は次の形にします。

システムへ連携する

清掃の依頼はメールの下書きまでにします。 送るのは担当です。取消の通知で行を消さず、取消の印を付けるだけにするのも、後で経緯を追えるようにするためです。

宿泊者への案内は、手配表の欄に下書きを書くだけにします。 予約サイトの多くは宿泊者とのやり取りをサイトのメッセージで行うので、担当が下書きを写して送ります。

人が確認する

1. 要確認の一覧を先に見る … 定員の超過、台帳に無い物件、日付や人数の null、year_inferred が true のもの、同じ予約番号の行が2つ以上あるもの
2. 新しい行の日付と人数を、通知と見比べる … 手配表の行から通知のメールへのリンクを開いて確かめます
3. 清掃の依頼の下書きを送る … 清掃の日時と担当を確かめて送ります
4. 到着の案内を予約サイトのメッセージで送る … 下書きを写し、宿泊者の言語に合っているかを見ます
5. 到着の日に本人確認を行い、鍵の受け渡しを伝える … 本人確認を終えた宿泊者にだけ伝えます

1番目の定員の超過は、担当が判断します。 子どもの数え方や、予約サイトの側の設定の誤りのこともあるので、自動で断ったり、予約サイトに連絡したりしません。

2番目を省かないでください。 取り出しの誤りでいちばん困るのは、日付が1日ずれることです。1日ずれた清掃の依頼は、宿泊者が着いた後に清掃の担当が来る形で表に出ます。 通知を開いて、日付の2つと人数だけは目で見比べます。

目標は、300件をならして1件3分です。 取消は印を確かめるだけで終わり、新しい予約と変更は、行と2つの下書きを確かめて送る時間です。

例外に対処する

上の3行が大半を占めます。 どれも AI の問題ではなく、台帳と予約サイトの設定のずれの問題です。 予約サイトで物件の名前を変えた日に、台帳の表示名も直す決まりにします。

記録を残す

• 拾った通知のメールの ID、受信日時、送信元、件名
• AI が返した JSON の全文と、要確認に回した理由
• 手配表の行に加えた変更（足した・直した・取消の印）と、その前の値
• 清掃の依頼と到着の案内を送った日時と送った担当
• 本人確認を行った日時と方法（宿泊者名簿の側に記録）

3つ目で「直す前の値」を残すのは、変更が何度も入る予約があるためです。 日付が2度変わった予約で、清掃の担当に何を伝えたかを後から追えるようにします。

2つ目の要確認の理由は、月に一度まとめて数えます。 「台帳に無い物件」が多ければ台帳の手入れが、「unknown」が多ければ予約サイトの通知の書式の変更が疑われます。理由ごとの件数が、直す場所を教えてくれます。

宿泊者名簿と旅券の写しは、この構成とは別に保存します。 宿泊者名簿は届出住宅か営業所・事務所に備えて3年間保存する必要があるとされています。手配表に名簿の中身を写さないでください。