宿泊予約の人数・プラン・到着時刻・要望に合わせて、到着前日に送る案内メールを予約ごとに下書きし、確認が要る予約を拾う

処理の起点を決める

毎日決まった時刻に、時間主導型のトリガーで動かします。 時間主導型のトリガーは毎分から月1回まで設定でき、時刻は1時間の幅で決まります。 11時に設定すると11時から12時のあいだに動きます。予約係が朝の一覧を貼り終えた後で、午後のチェックインの受付より前に下書きがそろう時刻にします。

一覧の貼り付けが遅れた日に備えて、シートに「貼り付け済み」の印の欄を置きます。 スクリプトはこの印が無ければ何もせず、30分後にもう一度見るトリガーを置きます。 古い一覧のまま動くと、前日の予約に二度目の案内を作ることになるからです。

インストール型のトリガーは、作った人のアカウントで動きます。 下書きもそのアカウントに作られるので、予約課の共有アカウントでトリガーを作ります。 個人のアカウントで作ると、下書きがその人のメールの中にでき、他の予約係から見えません。

入力データを集める

質を決めるのは、要望の対応一覧です。 「到着が遅れる」「子ども用の浴衣」「駐車場が2台」「ベビーベッド」のように、館として返事を決めている要望を種類ごとに並べ、返事の文面も決めておきます。 一覧に無い要望は、すべて確認が要るものとして扱います。一覧を増やすほど、確認が要る予約は減ります。

正本の値は、AIへ渡しますが、文面には書かせません。 プランの夕食が「18時から19時30分のあいだに開始」であることはAIに知らせ、文面の中では {{dinner_last_start}} のような差し込み記号で書かせます。 実際の時刻はスクリプトが正本から差し込みます。

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

予約は「翌日到着」のシートから読み、館とプランの値は「正本」のシートを引きます。

プランの名前は、予約管理のシステムの表記と正本の表記をそろえます。 予約サイトごとにプランの名前が少しずつ違うことがあるので、「正本」のシートにシステムのプランのコードの列を持たせ、コードで引きます。 名前で引くと、引けないプランが出ます。

API のキーと、館の問い合わせ先の電話番号はスクリプトのプロパティに置きます。 スクリプトのプロパティは、そのスクリプトのすべての利用者に共有される、アプリ全体の設定値の置き場所です。シートに書くと、一覧を見る人すべてに見えます。

AIへ渡す前に整形する

1. 貼り付けの確認 … 「翌日到着」のシートの日付が翌日であることを確かめます。違えば何もしません
2. 重複の確認 … 同じ予約番号の下書きがすでにある場合は作りません。一覧に下書きの作成日時の列を持たせて確かめます
3. 宛先の確認 … メールアドレスが空、または予約サイトの中継のアドレスと分かるものは、下書きを作らず「電話で案内」として一覧に回します
4. 規則の確認 … 到着予定時刻がプランの夕食の最終の開始時刻より後なら「夕食の時刻の相談」の印を付けます。到着予定時刻が空なら「到着時刻の確認」の印を付けます
5. 人数とプランの条件 … 大人のみのプランに子どもの人数が入っていれば「プランの条件」の印を付けます
6. 要望の欄の個人情報の確認 … 要望の欄に電話番号やカード番号のような文字列があれば、伏せてからAIへ渡します

4番目をAIに渡さない理由は、第5章に書いたとおりです。 時刻の比較はスクリプトで行い、AIには比べた結果だけを「夕食の時刻の相談が要る」として渡します。 AIはその結果を受けて、相談を持ちかける言葉を書きます。

3番目の中継のアドレスの見分け方は、予約の経路の列で決めます。 予約サイトによって、宿泊客の本当のアドレスが渡されるもの、中継のアドレスが渡されるもの、アドレスが渡されないものがあり、どれに当たるかは予約サイトとの契約と設定によります。 経路ごとに「メールで送ってよいか」を「正本」のシートに持たせ、スクリプトはその列だけを見ます。アドレスの形からAIに推測させることはしません。

AIに処理させる

させるのは、要望の仕分けと、予約に合わせた言葉のつなぎを書くことの2つです。

1行目の「迷ったら needs_check」が、この構成でいちばん大事な決めごとです。 館で決めている要望を確認に回しても、予約係が1件余分に見るだけです。確認が要る要望を決めている要望に分けると、厨房が知らないアレルギーに「承りました」と返すことになります。 誤りの重さが違うので、迷ったときの寄せ先を決めます。

5行目で、needs_check の要望には返事を書かせません。 返事を書かせると、どれだけ指示を書いても「対応いたします」「ご用意いたします」に近い言葉が出てきます。確認が要る要望のある予約は、下書きそのものを作らず、予約係が確認してから書く形にします。

指示内容を固定する

あなたは旅館の予約課で、到着前日の案内メールの文面を用意する係です。
下の予約の内容と館の案内だけを使い、書かれていないことを補わないでください。

【予約】人数：大人{adults}名・子ども{children}名／プラン：{plan_name}
【規則の確認の結果】{rule_flags}（例：夕食の時刻の相談が要る）
【要望の欄】{request_text}
【館で返事を決めている要望の種類と、返事の文面】{request_catalog}
【差し込み記号の一覧】{{checkin_time}} {{dinner_start}} {{dinner_last_start}}
  {{dinner_place}} {{parking}} {{pickup_place}} {{front_phone}}

【すること】
1. 要望の欄に書かれた要望を1つずつ分け、上の種類から1つを選んでください。
   種類に無いもの、迷うものは needs_check にし、理由を短く書いてください。
2. greeting に、人数とプランに合わせたあいさつの続きを2文以内で書いてください。
3. 規則の確認の結果に「夕食の時刻の相談」があるときだけ、dinner_note に
   夕食の開始時刻を相談する一文を書いてください。
4. 種類が決まった要望には、request_replies に返事の文面を予約に合わせて整えて書いてください。

【厳守事項】
- 時刻、金額、場所、電話番号は、文面に数字や地名で書かないでください。
  必ず差し込み記号を使ってください。
- needs_check の要望には、返事を書かないでください。
  「承りました」「ご用意します」「対応いたします」など、対応を約束する言葉を使わないでください。
- アレルギー、体調、記念日、送迎の時刻の変更に関わる要望は、種類の一覧にあっても needs_check にしてください。
- 宿泊客の名前は書かないでください。宛名はスクリプトが付けます。
- 予約に書かれていない設備やサービスを案内しないでください。

「アレルギー…は、種類の一覧にあっても needs_check」は、一覧の誤登録への備えです。 予約係が気を利かせて「えび抜き」を一覧に足してしまうことがあります。命に関わる要望は、一覧の状態にかかわらず人が確かめる側に置きます。

「数字や地名で書かない」まで書くのは、差し込み記号の指示だけでは足りないからです。 記号を使えと言っても、AIは自然な文にしようとして「18時ごろ」と書き足してきます。 次の出力形式のところで、それを検査します。

出力形式を固定する

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

{
  "reservation_no": "",
  "requests": [
    { "text": "", "category": "late_arrival | kids_yukata | needs_check",
      "check_reason": "" }
  ],
  "greeting": "",
  "dinner_note": "",
  "request_replies": [""]
}

category の値は、「要望」のシートの種類のコードと needs_check です。スクリプトがその日の「要望」のシートからスキーマの enum を組み立てて渡します。

1つ目の理由は、文面を部品で受け取れることです。 あいさつ、夕食の時刻の相談、要望への返事を別々の項目で受け取り、定型の部品と正本の値をスクリプトが並べて1通にします。 AIが1通を丸ごと書くと、どこが正本の値でどこがAIの文かが分からなくなります。

2つ目は、文面を機械で点検できることです。 スクリプトは組み立ての前に次の点検を行います。

3つ目は、止まった応答を見分けられることです。 安全上の理由で拒否されたときは stop_reason が refusal になり、出力の上限で切れたときは max_tokens になります。どちらも出力がスキーマに沿わないことがあるので、下書きを作らずに確認の一覧へ回します。 enum の値は大文字と小文字だけが違う形で返ることがあるとされているので、比べるときは大文字と小文字を区別しません。

システムへ連携する

API の呼び出しでは、muteHttpExceptions を true にします。 既定では失敗の応答で例外が投げられ、その日の残りの予約が処理されずに止まります。true にすると失敗の応答も返るので、その予約だけを「作成失敗」として一覧に書き、次の予約に進めます。

1回の実行は6分までです。 1日50件の予約を1件ずつAIに渡すと、6分に近づくことがあります。処理した予約番号を一覧に書きながら進め、6分に近づいたら区切って、続きを別のトリガーで動かします。 Google Workspace のアカウントでは、URL Fetch が1日100,000回、メールの読み書きが1日50,000回とされています。

予約管理のシステムには書き込みません。 「送付済み」の印は、スプレッドシートの一覧に付けます。

人が確認する

予約係は、確認の一覧から先に扱います。

1. needs_check の要望がある予約 … 厨房や担当者に確かめ、返事を書いてから送ります。アレルギーは厨房の確認が済むまで返事を書きません
2. 夕食の時刻の相談の印がある予約 … 下書きはできていますが、送る前に厨房が遅い時刻に対応できるかを確かめます
3. 「電話で案内」の予約 … メールアドレスが無い予約に電話します
4. 点検に引っかかった予約 … 正本に無い数字や、約束の言葉が入った文面を直します
5. 下書きを流し読みして送る … 確認の一覧に無い予約の下書きを開き、宛名と人数を見て送ります

5番目も省かないでください。 確認の一覧に無い下書きも、送るのは予約係です。 自動で送る形にすると、予約の一覧の貼り付けの誤り（別の日の一覧を貼った、館を取り違えた）が、そのまま宿泊客に届きます。

目標は、1,500件をならして1件1.2分です。 確認の一覧に回るのは2割前後という想定です。それより多い月は、要望の対応一覧が足りていないか、正本のプランのコードが予約管理のシステムと合っていません。

例外に対処する

8行目は、この構成では拾えません。 下書きを作った後に予約が変わると、下書きは古い内容のまま残ります。 予約の変更を受けた予約係が、その予約の下書きを消すことを手順にします。

記録を残す

• 下書きを作った予約の番号と作成日時、そのとき使った正本のシートの版
• AIが返したJSONの全文と、点検の結果
• 確認の一覧に回った理由と、予約係が行ったこと
• 送付済みの日時と、送った予約係
• 要望の種類ごとの needs_check の件数

1つ目で「正本の版」を残すのは、夕食の時刻や駐車場が季節で変わるためです。 正本を書き換えた日の前後で、どちらの値の文面が送られたかが分からないと、宿泊客から「案内と違った」と言われたときに確かめられません。

最後の行は、要望の対応一覧を育てる材料になります。 同じ種類の要望が毎月 needs_check に回っているなら、館として返事を決めて一覧に足せます。

確認の一覧は、送った後も消さずに残します。 当日のチェックインで「夕食を遅らせる相談をした」「アレルギーは厨房が確認した」といった経緯をフロントが見られるように、予約番号で引ける形にしておきます。 館の中の申し送りそのものは、別の仕組みの仕事です。