送迎運行管理システムを「GAS＋Web」で作る（第3弾）予約のキャンセル・便変更・乗り場変更の実装
1. 前回までの確認
このシリーズでは、「送迎バス・送迎車の運行／予約管理システム」を
GAS（Google Apps Script）＋Webアプリ＋スプレッドシート でゼロから作っていく過程をまとめています。
第1弾では
当日電話受付の内容をWeb画面から入力し、スプレッドシートに即時登録
キャッシュを導入し検索機能を高速化
第2弾では
受付画面で予約を登録したタイミングで、該当する車両に搭載しているタブレット宛てにメールを自動送信
ドライバーがメール本文の「OK」ボタンを押すと、スプレッドシートの「変更ログ」に『OK』と『返信時刻』を自動記録
ここまでで、「追加登録＋ドライバー確認」の一連の流れが出来上がっています。
2. 今回の到達点：追加以外の機能を実装
現場で実際に運用してみると、「追加」だけでは足りないことがすぐにわかります。
予定が変わって キャンセルしたい
もっと早い・遅い便に 便を変更したい
送迎場所が変わったので 乗り場を変更したい
などなど、「変更」は日常茶飯事です。
そこで第3弾では、受付担当がWeb画面から次の3つを行えるようにしました。
キャンセル：予約をキャンセルする
便変更：別の便に変更する
乗り場変更：乗車地 or 降車地を変更する
重要なのは、見た目だけ変われば良いのではなく、データベースにどう記録するか という設計です。
「あとから見返しても、何がいつどう変わったか追えること」を意識して作っています。
3. データベースへの格納方法
今回追加した3つの操作（キャンセル／便変更／乗り場変更）について、
スプレッドシート側ではどのように記録しているか を整理しておきます。
3-1. キャンセル：ステータスを「追加 → キャンセル」に変更
キャンセルは、一見「行を削除すればいいのでは？」と思いがちですが、
今回は 「削除しない」設計 にしています。
対象の予約は「予約テーブル」に残したまま
ステータス列だけを「追加 → キャンセル」に変更
こうすることで、
単純に削除されたリストだとそれ以前の情報との差異に気づきづらい
どの便がキャンセル多発なのか
といったことを 履歴として確認できる ようになります。
また、前回までに作成した「変更ログ」にも、
キャンセルしたタイミングをきちんと記録することで、後からのトレースがしやすくなります。
3-2. 便変更：キャンセル＋新規追加の2ステップで扱う
「便変更」は、単なる「時間の書き換え」ではありません。
たとえば、
元々「10:00発 A便」を予約していたお客様を
「11:00発 B便」に変更したい
というケースを考えます。
今回のシステムでは、この操作を 1回の入力で次の2つとして扱います。
変更前の便をキャンセル
「予約テーブル」のステータスを「キャンセル」に変更
変更ログに「キャンセル」として1行記録
変更後の便を新規追加
「予約テーブル」に新しく1件追加
変更ログに「追加」として1行記録
そのため、同じお客様の「便変更」操作でも、
変更ログには「キャンセル」と「追加」の2行が残る 形になります。
これにより、
「どの便からどの便へ移動したのか」
「いつ・誰がその操作をしたのか」
「元の便は最終的に空席になったのか」
などを後からきちんと確認できるようになります。
システム的には少し手間が増えますが、
運行管理・クレーム対応の観点からは非常に重要な設計 です。
3-3. 乗り場変更：乗車地・降車地の書き換え
「乗り場変更」は、便自体はそのままで、乗車地・降車地だけを変えるパターン です。
「予約テーブル」の
「乗車地」列
「降車地」列
を、受付画面からの入力内容で上書きします。
この時も、もちろん 変更ログに「乗り場変更」の記録を残す ようにしておけば、
「いつ」「どの予約の」「どの乗り場が」「どう変わったか」
を後から確認できます。
4. 動画デモの内容
実際の操作を行った動画を下記から見ることができます。
(1) 動画 : キャンセル
「顧客検索」画面で氏名を入力し選択
「キャンセル」ボタンをクリックし予約を確認して、登録する(図 1-1 )
「予約テーブル」シートでステータスが「キャンセル」に変わる(図 1-2 )
「変更ログ」シートに「キャンセル」と日時が追記される(図 1-3 )
(2) 動画 : 便変更
「顧客検索」画面で氏名を入力し選択
「便変更」ボタンをクリックし変更する予約を選択
変更先の便を指定して「予約内容の確認」を行い登録する(図 2-1 )
実行すると…
元の予約が「キャンセル」扱いになる(図 2-2 )
新しい便として予約が1件追加される(図 2-2 )
「変更ログ」には、「キャンセル」「追加」の2行が追加される(図 2-3 )
(3) 動画 : 乗り場変更
「顧客検索」画面で氏名を入力し選択
「乗り場変更」ボタンをクリックし変更する予約を選択(図 3-1 )
新しい「乗車地 / 降車地」を選択して「予約内容の確認」を行い登録する
「予約テーブル」の乗車地・降車地だけが書き換わる(図 3-2 )
変更ログには「乗り場変更」として1行記録される(図 3-3 )
「便はそのまま、乗る場所だけ変える」ケースが、
どのようにDBに反映されるかがイメージしやすくなると思います。
5. 次回の予定：車載タブレット向け画面の実装へ
今回で、受付側で予約を入力・変更する際に必要な基本機能 はほぼ一通り揃いました。
追加（第1弾、第2弾）
キャンセル（第3弾）
便変更（第3弾）
乗り場変更（第3弾）
次回は、いよいよ 「車載のタブレットで見ることができる画面」 を実装していく予定です。
ドライバーがタブレットで、
自分の担当便の最新予約一覧を確認できる
直前の変更（キャンセル・便変更・乗り場変更）も反映された状態で見られる
メール既読の「OK返信」もタップだけで完結できる
といった、現場で実際に使えるUI をGAS＋Webで作っていきます。
「受付側の入力」と「ドライバー側の閲覧」がつながることで、
システムとしてようやく「送迎運行管理システムらしい」姿になってきます。
第4弾も、具体的な画面イメージやスプレッドシートとの連携方法を交えながら解説していく予定ですので、
よろしければ引き続きお付き合いください。
6. まとめ
今回の第3弾では、現場で必須となる「変更系」の機能を一気に実装しました。
予約を「削除」してしまうのではなく、
ステータス変更（追加 → キャンセル）で履歴を残す設計
便変更を、
「キャンセル1件＋新規追加1件」として扱い、変更ログも2行残す
後から「どこからどこへ」移動したかを追えるようにしたこと
乗り場変更では、
便そのものは変えずに乗車地・降車地だけを更新
それもログに残すことでトレース性を確保したこと
これらはすべて、
「現場で安心して使えるようにする」
「後から見返したときに運行の流れを説明できるようにする」
ための設計方針です。
GAS＋スプレッドシート＋Webアプリという構成でも、
設計次第でここまで“ちゃんとした”運行管理に近づけることができます。
次回は、このデータ構造を活かしてドライバー用タブレット画面を作っていきます。
受付・運行管理・ドライバーが、それぞれ自分の画面から同じデータを共有できる世界を、
一緒に形にしていければと思います。
