運行ダイヤが頻繁に変わるローカルバス会社でも“更新コストを大幅削減” できる!─ ヘッドレスCMS+Google Sheetsで時刻表をラクラク自動反映

毎週のように変わるダイヤを、そのたびに PDF を差し替えて……
── そんな“更新地獄”に悩むローカルバス会社は少なくないでしょう。
POG lab. Web Factory ディレクターのナカタです。
実は私の自宅近くのコミュニティバスでも、先々月と今月に立て続けてダイヤ改定がありました。そのたびに停留所の掲示板へ貼られている PDF 時刻表が張り替えられ、これを作成している方はどれだけ大変なのだろうかと考えました。
これが今回ご紹介するシステム発想の原点です。
道路工事・地域イベント・スクールカレンダー……。運行ルートに影響する要素が多いと、時刻表の差し替えは月次どころか週次対応になることも多いでしょう。担当者が手作業で PDF ファイルを作成 → サイトにアップ → SNS で告知、という流れは、公開まで時間がかかり、ヒューマンエラーもつきまといます。
そこで今回は、ヘッドレスCMS+Google Sheets を使って「運行ダイヤをシートで更新 → 数分後にサイトへ自動反映」する仕組みを構築した想定事例をご紹介。導入コストを抑えつつ、更新作業を大幅削減する手順とポイントを具体的にまとめました。
現状の課題──PDF 更新地獄のリアル
- 多くの自治体サイトでは、いまも PDF 形式で時刻表を公開しています。
- PDF だとスマホ閲覧時に拡大・スクロールが必須で UX が悪い。
- 一覧検索や乗換アプリ連携が難しいため 問い合わせ電話が減らない。
- 更新フローが属人化し、担当者が休めない。
PDFは配布資料としては便利ですが、ウェブ表示用のフォーマットとしては限界があります。
解決のカギは「データと表示の分離」
従来型 CMS(WordPress など)は “投稿=表示” が一体化しています。対して ヘッドレスCMS は、投稿したデータを API 経由で配信し、フロントエンド(Next.js など)が自由にレイアウトします。※1
ポイントは「見た目を作る(フロント)部分を分けておく」こと。 こうすると、データを直すだけで自動でホームページが書き換わる仕組みにできて、バス会社のように更新が多い業務と相性が良いです。
ソリューション全体
[運行担当] → Google Sheets
│ (API & Webhook)
▼
Headless CMS (Strapi)
│ (GraphQL)
▼
Frontend (Next.js+SWELL ブロック)
│ (CI/CD: Netlify)
▼
本番サイト&キャッシュ配信
- Google Sheets: ダイヤを行列で入力。担当者は Excel 感覚。
- Strapi: シート→CMS 同期は自動。データモデルは「路線」「便」「停留所」。
- Next.js:
getStaticProps
で GraphQL を取得し静的生成。ページごとに再生成(ISR)で爆速&SEO◎。 - Netlify: シート変更 → Webhook → Netlify Build → 公開まで 約3分。
実装ステップ
1. Google Sheets 側の下準備
- 見出し行に
route_id / route_name / stop_name / departure_time / arrival_time / service_day
を設定。 - [AppScript] で変更トリガーを検知し、JSON に変換して CMS の REST エンドポイントへ POST。
- バリデーションで時刻フォーマットを強制(
HH:mm
)。
スプレッドシートの編集履歴がそのまま「運行変更ログ」になるので、紙の差替履歴管理が不要に。
2. Strapi(または WP Headless)設定
- Content-Type Builder で Route / Timetable / Stop モデルを作成。
timetable
にweek_pattern
フィールドを持たせると、平日・休日・臨時便を API レベルで分割可能。 - Google Sheets から受信した JSON を
controllers
で上書き or 追加。 - Role & Permission を限定し、外部からの書き換えをブロック。
3. フロントエンド(Next.js)
export async function getStaticProps() {
const { data } = await fetchGraphQL(`{
timetables(sort: "departure_time:ASC") {
route { route_name }
stop_name
departure_time
service_day
}
}`);
return { props: { timetables }, revalidate: 60 }; //60秒毎に再生成
}
- ISR で “ほぼリアルタイム” 更新を担保しつつ、完全静的よりビルド時間を短縮。
- UI は SWELL のブロックを React コンポーネント化しインポート。
[table-of-contents]
を独自実装し、停留所名でアンカー生成。
4. CI/CD & 監視
- Netlify Build Hook URL を AppScript の最後に POST。
- Build 成功の Slack 通知 → 担当者に確認フロー。
- UptimeRobot で 24h 監視、5xx エラー時に自動ロールバック。
運用フローと業務負荷の推移
フェーズ | 旧フロー | 新フロー | 時間削減 |
---|---|---|---|
ダイヤ改定リスト作成 | Excel 手打ち | Google Sheets 直接編集 | -30% |
PDF 作成 | PowerPoint → PDF 書き出し | 不要 | -100% |
サイト更新 | CMS ログイン → メディア差替 → 公開 | Webhook 自動 | -100% |
告知 | Twitter 手動 | Netlify Deploy Hook → Zapier で自動投稿 | -90% |
合計 | 約1.5h/改定 | 約15分/改定 | -83% |
※想定試算です。
更新作業が 1.5 時間 → 15 分に短縮。担当者一人分の稼働を確保でき、問い合わせ応答や安全運行計画に時間を振り向けられました。
1~2時間程度でも、長い期間で見れば大きな削減になります。
リスクと注意点
- データ精度:担当者がシートでタイプミスすると即公開される。→ 入力制限 & 二重承認ワークフローで回避。
- オフライン対応:通信障害時でも PDF を落とせるよう、静的バックアップを自動生成。
- 法令順守:道路運送法に基づく運行情報掲示義務は従来の掲示板+サイト両方でカバー。
- 権限管理:Strapi へ外部 API 書き込みを許可する場合、IP 制限 & JWT を必須に。
まとめ ── “時刻表はデータ”と捉え直す
- ローカルバス会社こそ、ヘッドレスCMSの恩恵が大きい
- Google Sheets を使えば、現場の担当者が専門知識ゼロで更新
- CI/CD 自動化で ヒューマンエラーを大幅削減
「うちも同じ課題がある……」と感じたら、ぜひ POG lab. にご相談ください。
参考文献
- Makoto Shimizu「爆速サイト構築に挑戦1.ヘッドレスCMSを導入」
- note「AppSheet × Make.com の自動化の落とし穴?」