自治体の公共施設予約システムをコードで検証する：使えるデータと運用設計のリアルな話

どうも〜おかむーです！今日は自治体が使っている公共施設予約システムについて、エンジニア視点でガリッと解析していきますよ〜

• 3行要約

- 多くの自治体はOPAS系や市独自システムで予約を回していて、UIはあっても機械可読な公開データが乏しい

- 技術的にはAPI化、Webhooks、公開集計（CSV/JSON）で改善できるポイントが多い。決済や認証・データ保持は設計次第でリスクとコストが変わる

- 小さな自治体でも導入できるシンプルなGovTechスタックと運用ルールを提案します！

結論

公共施設予約システムは市民にとって身近なサービスでありながら、データ利活用と運用設計が抜け落ちがちです。要するに「画面で見える情報」と「機械で読み取れる情報」が乖離しているので、API・Webhook・オープン集計を標準にすれば透明性と業務効率が同時に向上します。小さな自治体でも既存のSaaSやマネージドサービスを組み合わせれば現実的に実装可能です！

レポート本文

背景：実例を見てみよう

これ見てくださいよ。豊中市さんの公共施設案内（https://www.city.toyonaka.osaka.jp/shisetsu/annai.html）は市民向け案内がしっかりあるけど、予約の実データを直接ダウンロードできないケースが多いんです。一方、OPAS（https://reserve.opas.jp/）のような共通基盤は便利だけど、自治体ごとにカスタマイズされていてAPIやデータ公開方針がバラバラなんですよね。

要するに、表示できるけど再利用できない、が現場あるあるです。

技術的課題の整理

• 機械可読性：HTMLでレンダリングするだけで、ICS/CSV/JSON出力がない
• APIの有無：自治体やSaaSでREST APIが未提供、あるいは認証が強すぎて外部分析が不可能
• 決済連携：クレジットやコンビニ決済はあるけど、PCI-DSS要件や領収処理が重い
• 個人情報・保存期間：APPIに基づく保持設計が未整備でログや予約履歴が長期保存されがち
• 運用指標の欠如：予約成功率やキャンセル率などのSLO/KPIが公開されていない

技術検証：こう直すと再現性が上がる

1) 最低限の公開API設計（OpenAPI）

例：最低限のエンドポイント設計（要するにこうすれば良いというサンプルです）

openapi: 3.0.1
paths:
/facilities:
get:
summary: 公共施設一覧（集計用）
responses:
'200':
content:
application/json:
schema:
type: array
items:
type: object
properties:
id: {type: string}
name: {type: string}
capacity: {type: integer}
available_from: {type: string, format: date}
/facilities/{id}/bookings:
get:
parameters:
- name: from
in: query
schema: {type: string, format: date}
- name: to
in: query
schema: {type: string, format: date}
responses:
'200':
description: 予約一覧(JSON)

2) Webhookでリアルタイム通知を出す

• 予約作成/キャンセル時に自治体内部の業務系へPOSTする。これでミスやダブルブッキングを即検知できます。

3) 集計はオープンに：自治体は週次/月次の匿名集計CSVを公開

• 例：facility_id, month, bookings_count, cancellations_count, unique_users
• e-Statや地方公共団体のデータカタログ（lg.jp系）へ連携すると利活用が広がります

4) 決済は外部連携で責任分離

• 自治体は決済結果だけ受け取り、カード情報等は決済事業者に保持してもらう（PCI負担軽減）

コードでよくある処理例

PythonでAPIからCSVを落として簡易集計する例：

import requests
import csv
r = requests.get('https://example.city.gov/api/facilities/1/bookings?from=2026-01-01&to=2026-03-31')
bookings = r.json()
with open('bookings.csv','w',newline='') as f:
writer = csv.writer(f)
writer.writerow(['id','date','status'])
for b in bookings:
writer.writerow([b['id'], b['date'], b['status']])

要するに、APIがあればこういう分析は一日で回せます！

運用設計：SLOとデータライフサイクル

• 可用性SLO：予約API 99.5% / 月
• データ保持：予約履歴は最大5年、詳細ログは1年で削除（匿名化ルール付き）
• モニタリング：エラー率、決済失敗率、平均レスポンスタイム

小規模自治体の実装パターン

• フロント：静的サイト + JS でAPI叩く
• 認証：OAuth2 / OpenID Connect（市民向けはマイナポータル連携を検討）
• バックエンド：サーバーレス（Lambda / Cloud Functions）＋RDS/Firestore
• 決済：Stripe Connect や国内決済サービスで代替
• デプロイ：CI（GitHub Actions）でOpenAPI生成とドキュメント公開

まとめ

• 多くの自治体は使いやすいUIを持っている一方で、データの利活用レイヤーが弱い
• APIとWebhook、公開集計を標準にすれば透明性・効率性・外部連携が一気に上がる
• セキュリティや決済は外部事業者と責任を分けつつ、SLOやデータ保持を明確にするのが鍵

おかむーから一言

テクノロジーで市民生活をちょっとだけ便利にするのが俺のミッション！公共システムは叩けば光る部分がいっぱいあるので、一緒に直していきましょう〜