社用車の予約をフォームで受け、Apps Script と AI で車の重なりと運転者の条件を確かめ、行き先と時間に合わせた注意事項を運転者に返す

処理の起点を決める

フォームの送信を起点にします。 Apps Script のインストール型のトリガーには、Google フォーム側の送信のトリガーと、回答先のスプレッドシート側の送信のトリガーの2種類があります。この構成ではスプレッドシート側を使います。 回答の行がシートに書かれた後で動くので、その行の位置をそのまま予約台帳の行として扱えます。

2つ目の起点は、確認の一覧のシートでの承認の印です。 スプレッドシートにはインストール型の編集のトリガーがあり、総務や安全運転管理者がチェックボックスに印を付けたことで動かせます。印が付いた行だけを、カレンダーへの登録とメールの送信に回します。

3つ目は、毎朝の時間主導型のトリガーです。 当日と翌日の予約を見直し、期限が切れた車や運転者の予約が残っていないかを確かめます。時間主導型のトリガーの時刻は少しずれることがあり、9時の設定なら9時から10時のあいだに動くとされています。朝礼の前に見たいなら6時台にします。

インストール型のトリガーは、作った人のアカウントで動くとされています。 担当者個人で作ると異動で止まるので、総務の共用のアカウントで作ります。 失敗したときは、まとめのメールがそのアカウントに届きます。

入力データを集める

質を決めるのは、下の2つです。 現場の台帳に片道の距離が無ければ、長距離かどうかの印が付けられません。注意事項の一覧が無ければ、AI に文を作らせることになり、運転者に届く文が毎回変わります。

注意事項の一覧は、安全運転管理者と総務で作ります。 「片道100kmを超える日帰り」「戻りが20時を過ぎる」「冬に積雪のおそれのある地域へ行く」「長さのある資材を積む」などの条件と送る文を1行ずつ書きます。閾値は会社が決めるもので、ここの数字は例です。

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

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

同時の送信に備えて、処理を1件ずつにします。 LockService はコードの一部への同時のアクセスを防ぐもので、getScriptLock() は利用者にかかわらず同時の実行を止めるとされています。月曜の朝は、同じ車に同時に2件入ってどちらも「空いている」と判定されることがあります。 カレンダーを引いてから仮の予定を入れるまでをロックで囲みます。ロックは waitLock か tryLock を呼んで初めて取れるとされています。

getEvents は、タイムゾーンを指定しないと時刻をスクリプトのタイムゾーンで解釈するとされています。 スクリプトの設定を Asia/Tokyo にしてから作ります。

AIへ渡す前に整形する

1. 予約番号を振る … 日付と連番で振り、フォームの回答の行に書き戻します
2. 日時を確かめる … 戻りが出発より前、出発が過去、30日より先の予約は、AI に渡さず本人に戻します
3. 運転者を引く … 社員番号で運転者の台帳を引きます。見つからなければ、その時点で「総務が確認」にします
4. 台帳の条件を確かめる … 社内の運転の許可、免許の有効期限が戻りの日より後か、運転できる車の種類、乗車の定員と同乗者の人数を数で比べます
5. 車の期限を確かめる … 車検と定期点検の期限が戻りの日より後か、11月から3月の山間部行きでスタッドレスが付いているかを見ます
6. 重なりを確かめる … 選んだ種類の車のカレンダーを順に引き、空いている車を割り当てます。全部埋まっていれば「空きなし」とし、空いている時間帯を添えます
7. 行き先を引く … 現場名で現場の台帳を引き、片道の距離と地域の印を付けます。台帳に無い行き先は「距離不明」とします
8. 名前を外す … AI に渡す前に、運転者の氏名と社員番号を外し、予約番号だけにします

4番目から6番目は、すべて Apps Script が数で決めます。 AI に渡すのは、この結果を「事実」として添えるためで、判断させるためではありません。

AIに処理させる

させるのは、文で書かれた部分を読んで、選択した項目や台帳の事実との食い違いを見つけることと、注意事項の一覧から当てはまる番号を選ぶことです。

右端の unclear と maybe は、総務の確認に回すための印です。 AI が迷ったものを「問題なし」に寄せると、そのまま確定して運転者に届きます。迷ったときは人に回す、を出力の形で決めておきます。

5行目が最も効く制約です。 番号で選ばせれば、運転者に届く文は安全運転管理者が書いた文だけになります。

指示内容を固定する

あなたは建設会社の総務部で、社用車の予約の中身を確かめる立場です。
渡された予約の文と、すでに確かめた事実だけを見て判定してください。
推測で埋めないでください。

【あなたがすること】
1. 荷物・人数・時間・行き先の4つについて、備考などの文と、
   選択した項目・割り当てた車の事実が食い違っていないかを判定する
2. 注意事項の一覧から、この予約に当てはまる番号を選ぶ

【判定の選び方】
- ok ......... 文と選択・事実が合っている。または文にその話題が無い
- mismatch ... 文と選択・事実が明らかに食い違っている
- unclear .... 文の読み方が2通り以上あり、合っているか決められない
迷ったときに ok を選ばないでください。

【注意事項の選び方】
- 一覧の「条件の説明」に予約が当てはまる番号だけを applies に入れる
- 当てはまるか迷う番号は maybe に入れる
- 一覧に無い注意事項を作らないでください。文を書き換えないでください

【厳守事項】
- 時間の重なり、免許・車検の期限、定員は確かめ済みです。判定し直さないでください。
- 予約を断る、確定する、といった結論を書かないでください。
- 交替の運転者が要るかどうかを判断しないでください。
- 運転者の体調、経験、性格について書かないでください。
- 荷物の長さや重さが文に書かれていなければ、推測せず unclear にしてください。
- evidence には、判定の根拠にした文をそのまま写してください。
- question には、総務が本人に聞き直すときの短い質問を1文で書いてください。
  食い違いが無いときは空にしてください。

【予約】{booking}
【割り当てた車の事実】{vehicle_facts}
【確かめ済みの結果】{checked_facts}
【行き先の情報】{destination_facts}
【注意事項の一覧】{notice_list}

「確かめ済みです。判定し直さないでください」を書かないと、AI は定員や期限にも意見を言います。 その意見が Apps Script の結果と食い違うと、どちらを信じるかを総務が迷うことになります。役割を分けたことを、指示の文でも念を押します。

「体調、経験、性格について書かない」は、備考に「寝不足ですが」と書く社員がいるためです。 本人の状態を AI が評価した形にせず、そうした記載は総務が原文を読んで直接話します。

出力形式を固定する

Gemini API の構造化出力で、次の形の JSON を受け取ります。 公式のページでは、/v1beta/interactions に送る要求に response_format を付け、mime_type に application/json を、schema に受け取る形を書くとされています。

{
  "booking_id": "",
  "checks": [
    { "topic": "cargo | passengers | time | destination",
      "status": "ok | mismatch | unclear",
      "evidence": "",
      "question": "" }
  ],
  "notices": {
    "applies": [""],
    "maybe": [""]
  }
}

checks には topic の4つを1つずつ並べます。notices の applies と maybe には、注意事項の一覧の番号（「N-03」など）だけを入れます。

1つ目の理由は、振り分けを規則で決められることです。 AI が返すのは食い違いの有無と番号までで、「そのまま確定」「総務が確認」「安全運転管理者へ」は Apps Script が規則で決めます。

2つ目は、status に列挙の値だけを許せることです。 公式のページでは、文字列に enum を付けられるとされています。status を ok／mismatch／unclear に限れば、「たぶん大丈夫」のような値で振り分けが止まりません。 注意事項の番号も、一覧の番号を enum に並べておけば、一覧に無い番号は返りません。

応答は、保存しない設定で呼びます。 公式のページでは、Interactions API は既定で要求を保存し、store=false にすると保存しない動きになるとされています。予約の文は、会話を続ける必要の無い1回ごとの判定なので、store=false を付けます。

システムへ連携する

カレンダーへの登録は、承認の後か「そのまま確定」の後だけです。 createEvent には説明と場所を付けられるとされているので、予定の説明に予約番号と運転者の社員番号を入れ、場所に行き先を入れます。 招待のメールは既定で送らないとされているので、運転者への連絡はメールで別に送ります。

Gemini API の呼び出しは、失敗の応答でも止まらないようにします。 UrlFetchApp.fetch の muteHttpExceptions を true にすると、失敗の応答でも例外を投げないとされています。応答の番号を見て、失敗なら「総務が確認」に回し、AI の結果欄を空にしておきます。 API のキーはスクリプトのプロパティに置き、コードに書きません。

運転者へのメールは、確定した予約にだけ送ります。 本文は予約の内容と注意事項の文で、AI の question や evidence は入れません。

人が確認する

総務が開くのは「総務が確認」の予約だけです。 「そのまま確定」の予約は、確認の一覧で件数と車と行き先を流し見るだけにします。全件を開く設計にすると、第10章の12.0時間には収まりません。

1. mismatch を先に見る … evidence と question を読み、本人に聞き直すか、車を替えるかを決めます
2. unclear と maybe を見る … 備考の原文を読み、自分で判断がつけば確定し、つかなければ聞き直します
3. 台帳の問題を見る … 免許の期限切れ、車検の期限、空きなしは、本人と上長に連絡します
4. 確定の印を付ける … 印を付けた時点でカレンダーに入り、運転者にメールが届きます

安全運転管理者は「安全運転管理者へ」の予約を見ます。 長距離・夜間・積雪の印が付いたもので、交替の運転者を付けるか、出発の時刻を早めるか、別の日にするかを決め、決めた内容を確認の一覧の欄に書いてから印を付けます。

AI の判定を覆したら、その理由を1行残します。 たまった記録は、注意事項の一覧と車の事実の書き方を直す材料になります。 総務が開くのは2割前後が目標で、超える月はフォームの選択肢か現場の台帳が足りていません。

例外に対処する

取り消しと変更をフォームの外で受けないでください。 カレンダーの予定を直接消すと、予約台帳と食い違ったまま残ります。

上限は、公式の表で実行時間が1回6分、トリガーの合計が Workspace で1日6時間、予定の作成が1日1万件、MailApp の宛先が1日1,500です。 1日十数件の予約なら遠く届きません。

記録を残す

• 予約番号ごとの、フォームの回答の原文と受け付けた日時
• Apps Script が確かめた結果（重なりの相手の予約番号、台帳の照合の結果、距離と地域の印）
• AI に渡した入力（名前を外した後のもの）と、返ってきた JSON の全文
• 振り分けの結果と、そのときの注意事項の一覧の版
• 人が判定を覆した記録 … どの項目を、どう変えたか、その理由
• 安全運転管理者が決めた内容（交替の運転者、出発時刻の見直し）
• 運転者に送ったメールの本文と送信の日時

4つ目で「注意事項の一覧の版」を残すのは、一覧が季節や事故の後に書き換わるためです。 同じ番号の文が変わっても、後から「何を伝えたか」を当時の文で確かめられます。 運転日誌やアルコールチェックの記録とも、同じ予約番号で突き合わせられる形にしておきます。