ハイヤー会社が予約の表から、予約の確認と前日の配車の案内のメールを Apps Script と Claude で下書きし、変更と配車の確定を漏れなく伝える

処理の起点を決める

2つの時間主導型のトリガーを置きます。 1つは予約の確認のためのもので、everyMinutes(15) で15分ごとに動かします。もう1つは前日の案内のためのもので、everyDays(1) と atHour(16) で毎日1回動かします。公式の説明では、atHour() の例は「5時〜6時の間に動く」と書かれ、nearMinute() を指定しないと分はランダムに決まります。 前日の案内は16時台のどこかで動く前提にし、配車の確定を15時半までに終える決まりにします。

予約の表への入力そのものをきっかけにはしません。 公式は、スクリプトの実行や API のリクエストではトリガーが動かないとしています。Web のフォームから別の仕組みで行が足される予約は、編集のトリガーでは拾えないことがあります。 15分ごとに状態の列を見に行く作りにすれば、入り方が電話でもフォームでも同じに扱えます。

トリガーは、予約センターの共用のアカウントで作ります。 インストール型のトリガーは作った人のアカウントで動くとされています。係個人のアカウントで作ると、下書きがその係の Gmail に入り、休みや退職で止まります。 失敗すると所有者に「Summary of failures for Apps Script」という件名のメールが届くので、共用のアカウントの受信箱を誰が見るかを決めておきます。

15分ごとのトリガーは、動く回数が多くなります。 トリガーの合計の実行時間は個人のアカウントで1日90分、Workspace で1日6時間とされています。窓口の8時から19時の外は表を読まずに終えます。

入力データを集める

質を決めるのは、用途ごとの決まりと案内の写しです。 用途ごとの決まりが無ければ、空港の送迎で便の遅れのときの待ち方を書くか、葬儀の送迎でどの言葉を避けるかを、AIが毎回自分で決めることになります。案内の写しが無ければ、変わった点を出せません。

用途ごとの決まりには、会社の取り決めを入れます。 たとえば空港の送迎なら「到着の便が遅れたときは、便の到着に合わせてお待ちします」「到着口を出たところで、お名前を書いた札を持ってお待ちします」のような、会社として約束していることだけを書きます。約束していない待ち時間や料金の扱いを、AIが書き足さないようにするためです。

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

すべて同じスプレッドシートの中にあるので、Apps Script のスプレッドシートのサービスで読むだけです。 配車システムや外の予約サイトから直接取ってくるものはありません。

変わった点は、次の項目だけを比べます。

宛先が変わった予約は下書きを作りません。 秘書の交代やホテルの担当の替わりで宛先が変わることはありますが、入力の誤りで別の法人のアドレスが入っていることもあります。 宛先の変更は、受付の係が電話で確かめてから案内を作り直します。

AIへ渡す前に整形する

1. 状態で絞る … 「取消」「仮予約」の行は外します。取消の予約は、取消の連絡の下書きを別に作るか、係が電話で伝えます
2. 重複を外す … 案内の写しに、同じ予約番号・同じ案内の種類の行があれば外します。変わった点があるときだけ、前日の案内を作り直します
3. 時刻を整える … 迎えの時刻を H時mm分、利用日を M月d日（曜日） の形にします。曜日は Apps Script が日付から計算して付けます
4. 変わった点を出す … 案内の写しと今の予約を、上の表の項目で比べ、変わった項目の名前と、前の値・今の値を並べます
5. 記号に置き換える … 宛先の名前を {{宛名}}、乗る人を {{ご利用者}}、時刻を {{迎え時刻}}、場所を {{迎え場所}}、乗務員を {{乗務員名}}、車両を {{車両}} に、変わった点の前の値と今の値を {{変更前_1}} {{変更後_1}} のような番号付きの記号にします
6. 言語を決める … 予約の表の言語の列が英語なら、英語の文面を求めます。名前と場所は記号のままなので、訳す必要がありません

3番目で曜日を Apps Script が付けるのは、AIが曜日を書き足すと1日ずれることがあるためです。

5番目の記号に番号を付けるのは、変わった点が2つ以上あるためです。 時刻と迎えの場所が同時に変わった予約で、どちらの前の値をどちらに書くかをAIに選ばせません。

AIに処理させる

させるのは、記号の入った予約の事実から、案内のメールの件名と本文を作ることだけです。

AIに書かせないことのほうが大事です。

3行目がいちばん起きやすい失敗です。 AIは親切に「交通事情により遅れる場合もご安心ください」「お荷物はトランクにお積みします」と書き足します。一般には当たり前に見えても、会社として約束していないことが文面に入ると、それがお客様との約束になります。 書いてよいのは、用途ごとの決まりにある文だけです。

指示内容を固定する

あなたはハイヤー会社の予約センターの係として、お客様に送る案内のメールの下書きを書きます。
渡す「事実の束」だけを使って書いてください。

【書き方】
- 宛名は {{宛名}} と書き、宛先の種類（recipient_type）に合わせて敬語の向きを決めてください。
  self …… ご本人宛て。「お迎えにあがります」
  secretary …… 秘書・総務の方宛て。「{{ご利用者}}のお迎えにあがります」
  hotel …… ホテルのご担当者宛て。宿泊のお客様のお名前は {{ご利用者}} と書く
  funeral …… 葬儀社のご担当者宛て
- 日付・曜日・時刻は、事実の束の記号（{{利用日}} {{迎え時刻}} など）をそのまま置いてください。
  数字で日付や時刻を書かないでください。曜日も書かないでください。
- 迎えの場所・行き先・乗務員・車両も記号のまま置いてください。名前を推測しないでください。
- notice_type が confirm のときは予約の確認、day_before のときは前日の案内を書きます。
  day_before のときだけ、{{乗務員名}} と {{車両}} を入れてください。
- changes が空でないときは、本文の最初に「ご予約の内容から変わった点」を置き、
  変わった項目ごとに {{変更前_n}} → {{変更後_n}} の形で、番号の順に1行ずつ書いてください。
- rules にある文は、意味を変えずに本文に入れてください。avoid_words にある言葉は使わないでください。
- language が en のときは英語で書いてください。記号はそのまま残してください。

【書かないこと】
- 運賃・料金・待ち時間の料金
- rules に無い約束（遅れたときの扱い、荷物の扱い、無料のサービスなど）
- 道路の混み具合、所要時間の見込み
- 乗務員の人柄・経歴・年齢

【notes】
事実の束の中で食い違って見えるもの、文面を書くのに足りないものがあれば、
notes に短く書いてください。無ければ空の配列にしてください。

【事実の束】{facts_json}

「数字で時刻を書かない」を明記しないと、AIは記号を値に見立てて「午前8時30分」と書き直すことがあります。 書き直された時刻は、予約の表と合っているかどうか誰にも分かりません。記号のまま返させ、値は後から機械が入れます。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 スキーマは output_config.format に type: "json_schema" で渡します。

{
  "subject": "【前日のご案内】{{利用日}} {{迎え時刻}} お迎えのハイヤーについて",
  "body": "{{宛名}}\n\nいつもご利用いただきありがとうございます。\n\nご予約の内容から変わった点\n1. お迎えの時刻：{{変更前_1}} → {{変更後_1}}\n\n明日のお迎えは次のとおりです。\n・ご利用日：{{利用日}}\n・お迎えの時刻：{{迎え時刻}}\n・お迎えの場所：{{迎え場所}}\n・乗務員：{{乗務員名}}\n・車両：{{車両}}\n…",
  "placeholders_used": ["{{宛名}}", "{{利用日}}", "{{迎え時刻}}", "{{迎え場所}}", "{{乗務員名}}", "{{車両}}", "{{変更前_1}}", "{{変更後_1}}"],
  "notes": []
}

構造化出力を使う理由は2つです。 1つは、件名と本文と使った記号を別の項目で受け取れることです。本文を正規表現で切り分けるより確実です。もう1つは、placeholders_used と事実の束の記号を突き合わせられることです。前日の案内で {{乗務員名}} が抜けていれば、検査で止まります。

スキーマに文字数の上限は書きません。 公式の説明では、文字列の長さの制約（minLength・maxLength）や数値の範囲の制約は非対応で、使うと400のエラーになります。 配列の要素の数の制約も minItems の0と1しか使えません。本文の長さは Apps Script の検査で見ます。スキーマを初めて使うときは組み立ての分だけ時間がかかり、組み立てた結果は最後に使ってから24時間保持されます。

Apps Script の検査は次のとおりです。

3行目が、AIが時刻を書いてしまったときの網です。 記号を置き換えた後の本文から、時・分 の並び、: 区切りの時刻、月・日 の並びを拾い、事実の束にある値と一つずつ照らします。 束に無い時刻が1つでもあれば下書きは作りますが、確認の一覧で赤くします。

システムへ連携する

下書きは GmailApp.createDraft(recipient, subject, body, options) で作ります。 オプションには cc・bcc・replyTo・name などがあり、name に会社名と「予約センター」を入れて送り主の表示をそろえます。 法人の予約で、秘書と本人の両方に送ってほしいと言われている場合は、cc に入れる宛先を予約の表の列で持ちます。Gmail の権限（https://mail.google.com/）が要るので、初回の承認は共用のアカウントで行います。

呼び出しの回数は月に1,000回前後です。 予約の確認と前日の案内で1件2回、変わった点による作り直しを足しても、URL の取得の上限（個人のアカウントで1日20,000回、Workspace で1日100,000回）には届きません。 気をつけるのは1回の実行が6分までという上限で、前日の案内で翌日の予約が多い日は、処理した予約に印を付け、残りは次の実行で続けます。

人が確認する

1. 確認の一覧の「配車未確定」と「宛先の変更」から見る … どちらも下書きを作っていません。配車の係に確定を頼むか、お客様に電話で宛先を確かめます
2. 赤の「要確認」を見る … 事実の束に無い時刻が本文にある下書きです。AIが時刻を書き足したか、値の入れ違いです
3. 変わった点のある下書きを見る … 変更前と変更後が、電話で受けた変更の内容と合っているか。変更を受けた係に一言聞けるなら聞きます
4. 前日の案内の乗務員と車両を配車の表と見比べる … 置き換えた値が配車の表の行と同じか
5. 送る … 係が Gmail から送り、案内の写しの表に送った日時を入れます

4番目を省かないでください。 検査は記号と時刻の形を見ていますが、配車の表の予約番号そのものを入れ違えていれば、正しく置き換えた違う乗務員の名前が届きます。 同じ時刻に同じ法人の予約が2件ある日は、とくに見ます。

目標は、480件をならして1件3分です。 予約の確認は1分ほどで読んで送れ、前日の案内は乗務員と車両を見比べて2分ほどです。時間を使うのは、変わった点のある予約と、配車未確定の予約です。

例外に対処する

4行目の当日の予約は、メールにしません。 前日の16時を過ぎて入った予約は、お迎えまで数時間しかないことが多く、メールを読む前に車が着くことがあります。 乗務員と車両は電話で伝え、予約の表に「電話で案内済み」と残します。

記録を残す

• 実行の日時、読んだ予約の数、作った下書きの数、作らなかった予約とその理由
• 予約ごとの事実の束（記号に置き換えた後のもの）と、Claude が返した JSON
• 検査の結果（記号の抜け・余り、時刻の食い違い、避ける言葉、notes）
• 案内を作ったときの予約の内容の写し（次の案内で比べるため）
• 係が下書きを直したかどうかと、直した箇所の種類（言い回し、用途ごとの文、時刻、乗務員）
• 送った日時と、お客様からの問い合わせの有無

5つ目が、指示文と用途ごとの決まりを直す材料になります。 係が葬儀の送迎の案内で毎回同じ言い回しを直しているなら、それは避ける言葉の一覧に足す合図です。 乗務員の名前を直しているなら、配車の表の入れ方に誤りがあります。