送迎運行管理システムを「GAS+Web」で作る(第4弾)タブレットによる表示の実装
今回は、これまで電話で受け付けた予約データを「車載タブレットでどう見せるか」にフォーカスします。
第1〜3弾までは、主に「データをどう登録するか/どう連携するか」が中心でしたが、第4弾ではようやくドライバー視点の画面が登場します。
1. これまでのおさらい
このシリーズでは、送迎バス・送迎車向けの「送迎運行管理システム」を、GAS(Google Apps Script)+Webアプリ+スプレッドシートで作っていく様子をまとめています。
第1弾:当日電話受付の即時登録まで
第2弾:ドライバーへのメール送信と「OK」返信連携まで
第3弾:予約のキャンセル・便変更・乗り場変更の実装
ここまでで、
電話で受けた内容を即時登録
ドライバーへメールで通知
「OK」ボタンで確認を返信
予約のキャンセル/便変更/乗り場変更の処理
といった「受付〜共有〜変更」までの流れが一通りつながりました。
2. 第4弾のゴール:タブレットで「最新の予約状況」を見る
第4弾では、入力されたデータを車載タブレットで閲覧できる仕組みを実装します。
タブレット側は、直接スプレッドシート(データベース)にアクセスして、常に最新の予約状況を表示します。
画面はタブ切り替え式になっており、次の4つの画面を用意しています。

予約一覧:全便の予約一覧を見る
号車別:号車(車両)別に、自分が担当する便の予約を見る
ログ:入力した予約・変更の履歴を見る
全便人数:便ごとの乗車人数を一覧で確認する
タブレットの画面上部にタブ(ボタン)を並べておき、「予約一覧」「号車別」「ログ」「全便人数」をタップすると、それぞれの表に切り替わるイメージです。
下記からタブレット(横)で操作している動画を見ることができます
3. タブレットで表示する主な項目
タブレットで表示する「予約一覧」「号車別」テーブルは、基本的に同じ構成です。
(号車別は、それを特定の車両で絞り込んでいるイメージ)
「予約一覧」「号車別」で使う項目
予約ID : 予約日ごとに連番を付与して管理
例:R_1128-003(11月28日の3件目の予約、という意味です)
顧客名 : 乗車される方のお名前
発車時刻 : 「乗車地」での発車時刻
乗車地 : 発車場所
今回のサンプルデータでは、順番確認用に末尾に番号を付与
降車地 : 降車場所
こちらも順番確認のため末尾に番号を付与
ステータス : 「追加」「キャンセル」など
備考 : 特別に伝えたい内容(大きな荷物あり、耳が不自由 など)
4. 「予約一覧」の表示ルール
「予約一覧」は、全便の予約をまとめて確認するための画面です。
ドライバーだけでなく、配車担当者や管理者が使うことも想定しています。

主な表示ルールは次の通りです。
合計人数を表示
便ごとなどの単位で「合計人数」を計算して表示
このとき「キャンセル分」は人数に含めない
出発順にソート
便の出発順(発車時刻)にソート
同一乗車地は「降車順」でソート
同じ乗車地の中では、降車地の順序で並び替え
実際の運行順に近い形で、上から順に確認できる
キャンセル行の扱い
「キャンセル」の行は、グレー表示にして視認性を落とす
最終行に表示
5. 「号車別」:ドライバー専用の絞り込みビュー
「号車別」タブは、特定の車両(号車)に紐づく予約だけを表示するタブです。

基本的なテーブル構成・ソートルールは「予約一覧」と同じ
表示されるデータが「自分の担当便だけ」に絞り込まれている
ドライバーから見ると、
「自分が運転する号車の、今日の予約状況だけをサッと見たい」
というニーズが強いため、この「号車別」ビューを用意しています。
6. 「ログ」:入力・変更の履歴を見る
「ログ」タブでは、予約の追加・変更・キャンセルなどの履歴を簡易的に表示します。

表示している項目は次の通りです。
発生日時 : その操作をした日時(入力した日付・時刻)
予約ID : R_1128-003 のような形で、予約日ごとの連番
顧客名
便名
変更内容 :「新規予約」「キャンセル」「乗り場変更」「備考の変更」など
運行中にトラブルがあった場合でも、「いつ」「誰の予約に対して」「どんな変更があったか」をすぐに遡れるようにするのが目的です。
7. 「全便人数」:便ごとの乗車数を一覧で確認
「全便人数」タブでは、便ごとに乗車人数を一覧表示します。
行:便名
列:乗車人数
配車・運行管理者が、
今日どの便が混んでいるか
増便が必要な便はどこか
といった判断をするときに役立ちます。
8. 新規・変更したシート構成
タブレット表示のために、スプレッドシート側にもいくつか変更を行っています。
新たに追加したシート
日付管理 : 対象日の管理・切り替え用
車両一覧 : 号車・車両IDなどの一覧
全便表示F : 「全便人数」タブ用の集計結果を置くシート
予約_TB : タブレット用に整形した「予約一覧」データを置くシート
ログ_TB : タブレット用に整形した「ログ」データを置くシート
変更したシート
予約テーブル
「順序(降車地)」 を最終列に追加
この「順序(降車地)」を使って、同じ便の中で降車順にソートできるようにします




9. タブレット表示のキモ:query関数で並び順をコントロール
本シリーズでは「プログラムでごりごり並び替える」のではなく、スプレッドシートの QUERY 関数で表示順をコントロールしています。
予約_TB シートの A1 セルに設定している式
=query(
'予約テーブル'!A:O,
"select A,B,D,E,F,G,H,I,K where A is not null order by I asc,D asc ,E asc,O asc",
1
)この1行で、タブレット用の「きれいに並んだ予約一覧」がほぼ完成します。
query関数の内容を分解してみる
1.範囲指定
'予約テーブル'!A:O
元データとなる範囲
「予約テーブル」シートの A列〜O列 全部が対象
2. 取得する列の指定
select A,B,D,E,F,G,H,I,K
先ほど説明した項目のうち、実際にタブレットで使う列だけを指定
予約ID・顧客名・便名・発車時刻・乗車地・降車地・ステータス・予約日・備考など
3. 行の条件
where A is not null
A列(予約IDなど)が空欄でない行だけを対象にします
これにより、途中の空行やテンプレート行などは自動的に除外されます
4. 並び順の指定(order by)
order by I asc, D asc, E asc, O asc
ここが「表示順コントロール」の肝です。
I列:予約日 → 日付順に並べる
D列:便名 → 便名ごとにまとめる
E列:発車時刻 → 便の中で発車時刻順に並べる
O列:順序(降車地)→ 同じ便・同じ乗車地の中で、降車順に並べる
これらを組み合わせることで、
「日付 → 便 → 発車時刻 → 降車順」
という、運行現場で見やすい並び方を、プログラムを書かずに実現しています。
10. なぜ「プログラム」ではなく「query関数」を使っているのか
本来であれば、GAS側で配列をソートして表を作る方法もあります。
しかし、今回はあえて query関数を前提にした実装 にしています。その理由は次の通りです。
プログラムを書かなくて良い
並び替えロジックをコードで書くと、それなりのボリュームになります
query関数なら、スプレッドシート上の1行で完結します
リアルタイムで反映される
スプレッドシートのquery関数は、元のデータが更新されると自動で再計算されます
「5分ごとにGASのトリガーで再計算」などを考えなくてよいので、リアルタイム性が高く、運用もシンプルです
実行負荷・処理時間を減らせる
GASで定期的に集計・ソート処理を走らせると、そのぶん実行時間とリソースを消費します
query関数はシート側で計算してくれるので、GASの実行回数を抑えられます
AIに作ってもらいやすい
パターンが単純なので、「こういう条件で並び替えたい」とAIに指示すれば、かなりの部分を自動生成してもらえます
今回も実際にAIに依頼して作成しています
11. タブレットで使用する時
タブレットで使用するには、WEBアプリのURLをメールで送信しホーム画面に登録して使用します。

また、今回は実装していないが、実際に使用するときはログイン機能も実装します。
12. まとめ:タブレット表示が入るとシステムが一気に“現場仕様”になる
第4弾では、タブレットでの表示を中心に、
4つのタブ(予約一覧/号車別/ログ/全便人数)
タブレット用に整形するシート構成(予約_TB、ログ_TB、全便表示F など)
予約テーブルへの「順序(降車地)」列の追加
query関数による表示順コントロール
といった内容を実装しました。
ポイントは、複雑なロジックの多くを「query関数」に任せている点です。
GASのコードは最小限にして、スプレッドシートの機能で「リアルタイム集計+並び替え」を実現することで、
開発コストを抑えつつ
現場がすぐ使える形で
後からの修正もしやすい
というバランスを狙っています。
13. 次回 (号車別リスト プリント)
次回は、出庫時に号車別リストをプリントアウトする機能を実装する予定です。
タブレットだけで情報伝達は事足りるが、実際の現場では秒を争う場面が多々あります。
例えば、混雑している駅で一瞬停車し乗車する場面では、タブレットで乗車する人を確認し記録を残すことは難しいです。
こんな時は紙によるリストの方がはるかに便利です。
また、タブレットは落として故障する可能性もあります。
「うちの送迎業務にも使えそうかも?」と思った方は、ぜひ第1弾から順に読み返してみてください。
14. 最後に
これは私の設計思想でがあるが、「人間は必ずミスをする、機械は故障する可能性がある」ということを常に考えて、重要な部分はフェールセーフ(保険のようなもの)を持たせる。
今回のシステムだと情報を伝える手段として下記の4つを備えている
メール送信 : 当日分は全てメールを送信する
電話連絡 : 出発が近い予約を受け付けた時に電話をする
タブレットで最新情報を確認する
メールにOK返信がない場合で出発時刻が近くなったらアラートを表示する(実装予定)
このようにすることにより、たとえドライバーがメールを見てない可能性がある時でも確実に情報を伝えることができるシステムに仕上げています。
