旅館・ホテルが送迎バスの予約をフォームで受け、Apps Script と AI で便ごとの人数と荷物をまとめ、備考を読んで運転手向けの運行表を作る

処理の起点を決める

1つ目は、フォームの送信です。 Apps Script のインストール型のトリガーには、Google フォーム側の送信のトリガーと、回答先のスプレッドシート側の送信のトリガーの2種類があります。スプレッドシート側を使い、回答の行が書かれた後で動かします。 電話で受けた予約も、フロントが同じフォームに入れます。入口を1つにしないと、紙で受けた予約が運行表から漏れます。

2つ目は、前日の夕方の時間主導型のトリガーです。 翌日の便ごとに運行表を作ります。公式のページでは、時間主導型のトリガーの時刻は少しずれることがあり、9時に設定すると9時から10時のあいだに動くとされています。運転手に渡すのが17時なら、16時台に設定し、17時までに必ず終わっている形にします。

3つ目は、当日の朝の時間主導型のトリガーです。 前日の夕方以降に入った申込みと取り消しを拾い、運行表を作り直します。作り直したときは、前の版との差だけをフロントに知らせます。

インストール型のトリガーは、作った人のアカウントで動くとされています。フロントの共用のアカウントで作ります。 担当者個人で作ると、その人の退職で止まります。

入力データを集める

質を決めるのは、下の2つです。 便と車の表に荷物の目安が無ければ、人数が定員に収まっていても荷物で積めない便を拾えません。メモの決まりが無ければ、AI がどの事情を運転手向けとして拾うかが毎回変わります。

メモの決まりは、運転手とフロントで作ります。 「待ち合わせ場所が改札と違う」「歩行に補助が要る」「長さのある荷物」「ペットのキャリー」「遅れたときの連絡の仕方」など、運転手が駅で知っておきたい種類を並べます。 料理の好みや記念日のように、送迎に関係しない備考は運転手向けにしません。

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

フォームの回答は、送信のイベントから受け取ります。公式のページでは、スプレッドシート側の送信のイベントは、質問の名前と値をまとめた namedValues、書き込まれた範囲を表す range、シートの並びどおりの values などを持つとされています。質問の名前で値を取る namedValues を使います。 フォームに質問を足しても、列のずれで値を取り違えません。

同時の送信に備えて、台帳に書く部分を1件ずつにします。 公式のページでは、LockService はコードの一部への同時のアクセスを防ぐもので、getScriptLock() はどの利用者が動かしたかにかかわらず同時の実行を止めるとされています。予約の確認メールを一斉に送った直後は、申込みが重なります。 同じ便の人数を足して書き込むまでをロックで囲まないと、2件が同時に「定員に収まる」と判定されます。ロックは waitLock か tryLock を呼んで初めて取れるとされています。

AIへ渡す前に整形する

1. 宿泊予約の番号を確かめる … 到着予定の一覧に無い番号は、AI に渡さずフロントの確認の一覧に載せます
2. 日付を照らす … 往路の便の日付が宿泊日と、復路が出発日と合うかを見ます
3. 二重の申込みをまとめる … 同じ番号・同じ往復の申込みが2件あれば、後のものを正とし、前のものに「置き換え済み」と書きます
4. 人数を足す … 便ごとに大人・子ども・乳幼児を分けて足し、乗車定員と比べます。乳幼児を定員にどう数えるかは、宿が決めて便と車の表に書いておきます
5. 荷物と車いすを足す … 大型の荷物の数と車いすの数を足し、荷物の目安と、車いすを載せたときの座席と比べます
6. 備考を整える … 空の備考、「特になし」「なし」だけの備考は AI に渡しません
7. 名前と連絡先を外す … AI に渡す前に、代表者の名前・電話番号・メールアドレスを外し、宿泊予約の番号だけにします。備考の中に書かれた電話番号も、数字の並びを見て伏せます

4番目と5番目は、すべて Apps Script が数で決めます。 定員に収まるかを AI に判定させると、子どもの数え方や車いすの扱いで揺れます。AI に渡すのは、この結果を添えて、メモの文脈を分からせるためです。

AIに処理させる

させるのは、備考を読んで、運転手向けのメモを1〜2行で書くことと、フロントが確かめるべき事柄に印を付けることです。

右端の front_check は、フロントが電話で確かめるための印です。 AI が迷ったものをメモにしてしまうと、運転手が駅で間違った前提で待ちます。迷ったら書かずに、フロントに回します。

6行目を明記しないと、AI は「足が不自由な方」のように言い換えます。 運転手に要るのは「乗り降りで手を貸す」という行動で、宿泊客の体の状態を表す言葉ではありません。

指示内容を固定する

あなたは温泉旅館のフロントで、送迎バスの運転手に渡すメモを作る立場です。
渡された備考と便の情報だけを見て書いてください。推測で埋めないでください。

【あなたがすること】
1. 備考から、運転手が駅や宿の前で知っておくべき事柄を拾い、
   driver_memo に1〜2行で書く
2. フロントが宿泊客に確かめるべき事柄があれば、front_check に入れる

【運転手向けにする事柄（メモの決まり）】{memo_rules}

【書き方】
- 運転手がとる行動で書く（「改札を出た西口のロータリーで待つ」
  「乗り降りの際に手を貸す」「後部の荷室に長い荷物を積む」）
- 1行は30文字程度まで。敬語は要らない
- 数（人数・荷物の個数）は書かない。数は別の欄に入る

【厳守事項】
- 人数、荷物の数、定員に収まるかを判定し直さないでください。
- 便を替える、車を足す、といった結論を書かないでください。
- ペット、車いす、大きな荷物を受け入れられるかを判断しないでください。
- 病名、障害、体の状態を表す言葉を書かないでください。
  備考に書かれていても、運転手がとる行動だけを書いてください。
- 料理、記念日、部屋の希望など、送迎に関係しない事柄は
  driver_memo に入れず、other_dept に true を付けてください。
- 備考の時刻が便の時刻と合わないときは、front_check に入れてください。
- 場所や程度が曖昧なときは、driver_memo に書かず front_check に入れてください。
- evidence には、根拠にした備考の文をそのまま写してください。

【便の情報】{trip_info}
【確かめ済みの結果】{checked_facts}
【備考】{remarks}

「数は書かない」を入れないと、AI はメモに「3名様、スーツケース2個」と書きます。 その数が台帳の数と食い違うと、運転手はどちらを信じるかで迷います。数の出どころを1つにするための一文です。

「行動で書く」は、運転手が運転席で読む紙だからです。 「お祖母様がご高齢のため」と書かれても、何をすればよいかは分かりません。「乗り降りの際に手を貸す」なら、駅で迷いません。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 公式のページでは、output_config.format に type: "json_schema" を指定し、オブジェクトには additionalProperties: false を付けることとされています。

{
  "booking_id": "",
  "driver_memo": [
    { "category": "meeting_point | mobility | cargo | animal | timing",
      "text": "",
      "evidence": "" }
  ],
  "front_check": [
    { "reason": "unclear_place | unclear_assist | time_mismatch | other",
      "question": "",
      "evidence": "" }
  ],
  "other_dept": false
}

1つ目の理由は、メモと印を別の欄に分けられることです。 driver_memo は運行表に、front_check はフロントの確認の一覧に、Apps Script がそれぞれ差し込みます。運転手の紙に、フロント向けの質問が混ざりません。

2つ目は、category で運行表の並びを決められることです。 待ち合わせ場所は便の欄の先頭に、乗り降りの補助は名前の横に、荷物は荷室の欄に、と運転手が目を向ける位置に置けます。

3つ目は、question をフロントの電話にそのまま使えることです。 「備考に到着が17時50分とありますが、駅発の便は17時30分と18時30分です。どちらにしますか」のような1文が、確認の一覧に並びます。

数値の最小値・最大値の制約はスキーマに書けないとされています。 数を AI に返させない設計が、ここでも効きます。

システムへ連携する

宿泊予約の管理の仕組みには書き込みません。 送迎の台帳は宿泊予約の番号でつながっているだけで、送迎の取り消しが宿泊の取り消しに波及する経路はありません。

Claude API の呼び出しは、失敗の応答でも止まらないようにします。 UrlFetchApp.fetch の muteHttpExceptions を true にすると、失敗の応答でも例外を投げないとされています。応答の番号を見て、失敗なら備考の原文を運行表のメモの欄にそのまま入れ、フロントの確認の一覧に載せます。 API のキーはスクリプトのプロパティに置きます。

運行表は、便ごとに1つの表にします。 列は「代表者の名前」「大人・子ども・乳幼児」「大型の荷物」「車いす・ベビーカー」「メモ」で、表の上に便の時刻・合計の人数・定員との差を置きます。印刷しても、タブレットで見ても読めるよう、1便を1画面に収めます。

【駅発 15:30 マイクロバス】 合計 21名（定員29）／大型の荷物 11個（目安12）／車いす 0
待ち合わせ：改札を出た西口ロータリー（1組は東口 → メモ参照）

代表者      大人 子 乳  荷物  補助    メモ
A様          2   1  0    2   －      東口の階段下で待つ。ベビーカーを荷室へ
B様          4   0  0    3   －      －
C様          2   0  0    1   杖     乗り降りの際に手を貸す。前方の席へ
D様          3   2  1    3   ベビー  長い荷物（釣り竿のケース）を荷室の奥へ
…
フロントで確認中：E様（到着の時刻を確認中。決まり次第電話）

「フロントで確認中」の行を運行表に残すのは、運転手が駅で声をかけられたときに答えられるようにするためです。 確認中の組を運行表から消すと、駅で待っている宿泊客を運転手が知らないまま出発します。載せたうえで、確定していないことを分かる形にします。

人が確認する

フロントが開くのは、確認の一覧に載った予約だけです。 定員に収まり、備考が無いか、備考があっても front_check の無い予約は、運行表に載るだけです。

1. 定員超え・荷物超えを先に見る … ワゴン車を足すか、宿泊客に電話して前後の便を勧めるかを決めます
2. front_check を見る … question を使って宿泊客に電話かメールで確かめ、台帳の備考を直します
3. other_dept の付いた予約を回す … 料理や記念日の備考を宿泊の担当に回します
4. 前日の夕方に運行表を見る … 車の割り当てを決め、メモが運転手に伝わる書き方になっているかを流し見ます

4番目でメモを直したら、直したことを残します。 「行動で書けていない」「送迎に関係ない事柄が入った」のような直しがたまると、メモの決まりと指示の文を直す材料になります。

目標は、600件のうちフロントが電話をかけるのを1割前後に抑えることです。 それを大きく超える月は、フォームの選択肢（待ち合わせ場所、荷物の種類）が実態に合っていません。選択肢を足せば、備考に書かれる事情そのものが減ります。

例外に対処する

最後の行を自動にしないでください。 遅れの連絡を受けて便を自動で替えると、運転手の手元の運行表と食い違います。当日の変更は、人が電話で決めて、決めた後に台帳を直します。

上限は、公式の表で実行時間が1回6分、トリガーの合計が Google Workspace のアカウントで1日6時間、外部への呼び出しが1日10万回です。 1日に20件ほどの申込みなら、いずれにも遠く届きません。

記録を残す

• 申込みごとの、フォームの回答の原文と受け付けた日時
• 照合の結果（宿泊予約の番号、二重の申込み、定員と荷物の判定）
• AI に渡した入力（名前と連絡先を外した後のもの）と、返ってきた JSON の全文
• フロントが直したメモと、直した理由
• 便ごとの運行表の版（前日の夕方の版と、当日の朝の作り直しの版）
• 便ごとの実際の乗車の人数（運転手が戻ってから書く）

5つ目で版を残すのは、運転手が持っている紙がどの版かを後から確かめるためです。 当日の朝に作り直したのに古い版で出発した、ということが起きます。版に作った時刻を入れ、運転手に渡すときに時刻を見せます。

最後の行は、便と車の表を直す材料です。 申込みの人数と実際の乗車の人数の差が大きい便は、申込まずに乗る宿泊客が多いか、取り消しが届いていません。