公共施設予約システムの開発は、現状と例外の整理、標準機能と差分の選定から始まり、設計・開発、テスト、稼働、定着へと進みます。
この流れで進めると、住民と職員が使い続けられる運用につながります。全体像は、完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・公共施設予約システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
公共施設予約システム開発の全体像
公共施設予約システムは、住民向けの予約画面と職員向けの管理画面をつなぐ業務システムです。利用申請から実績管理までを、継続して処理します。
開発の成否を分けるのは、画面の見た目よりも、自治体ごとに異なる制度や現場の例外を運用できるルールに整理できるかどうかです。
予約カレンダーにとどまらない行政業務の範囲
住民側は、施設や部屋を検索し、空き状況を確認したうえで、仮予約、本予約、抽選申込を行います。予約変更、キャンセル、決済、領収書発行、履歴確認、メール通知も扱います。
職員側は、施設・部屋・附帯設備、利用目的、料金、休館日を設定します。予約開始日、抽選ルール、減免条件を設定し、申請審査や利用許可を行います。加えて、入金確認、返金、統計出力、告知、問い合わせ対応も担います。
住民向けと職員向けのどちらか一方だけを先に決めると、受付後の審査や例外処理が手作業に戻りやすくなります。
住民UXと職員UXを同じ業務フローで考える視点
住民の利便性と職員の作業削減を別々に考えると、食い違いが出ます。そこで、4つの面を一つの流れで確かめます。
- 住民の申請：スマートフォンから24時間、申請できる仕組みにします。
- 職員の設定：料金変更や減免承認を、ベンダーに頼らず行えること。
- 利用者への案内：登録、抽選結果、支払い期限を分かりやすく示して、問い合わせを減らします。
- 成果の評価：住民の利便性と職員の作業削減を、一つの指標で見ること。
藤沢市の2025年事例では、施設ごとに分かれた利用者IDと紙中心の予約対応を見直しました。そのうえで、共通ID、キャッシュレス、電子キーボックス、多言語、備品予約をクラウドでまとめています（出典: NTTデータ北海道・ServiceNow Japan、2025年）。
公共施設予約システム開発の進め方
開発は、要件整理と選定から始めます。続いて、設計・開発、テスト、稼働の順に進め、定着で締めくくります。この順なら、制度とシステムのずれを早い段階で見つけられます。
各段階では、住民、施設職員、会計担当、情報政策担当、指定管理者の確認を挟みます。一方的にフェーズを進めないことが大切で、確認を挟まずに進めると、制度との食い違いが後になって表面化しかねません。
フェーズ1: 要件整理による現状と例外の洗い出し
制度と現場の食い違いは、後工程で追加開発として表に出てきます。着手前に、施設の決まりや例外から運用条件まで、5つの面で現状を洗い出します。
- 施設と制度：施設、管理主体、利用者区分、料金、減免、抽選に関する決まり。キャンセル、許可、支払期限、返金条件も含みます。
- 施設ごとの差：体育館、公民館、文化ホール、テニスコートの利用単位や予約開始時期。共通ルールと固有ルールを分けて把握します。
- 現在の業務：電話や窓口、紙、既存システムの担当者、確認時期、内容、出力帳票。業務フローにまとめ、機能の優先順位を決めます。
- 規模と移行：施設数・部屋数、月間予約件数、ピーク時の同時アクセス。利用者・団体数や、過去予約の移行範囲も見ます。
- 運用条件：決済、返金・消込、指定管理者の権限、障害時の代替受付。保存期間、監査ログ、稼働希望日も押さえます。
減免の承認者や抽選後の空き枠などの例外は、文章で定義しておきます。団体代表者の変更や重複申請、未収金も、例外の対象です。例外処理を明文化しておくと、後工程の追加開発を抑えられます。
フェーズ2: 選定での標準機能と差分の見極め
方式ごとに得意な範囲と確認事項が違うため、候補を比べる際は、4つの方式の特徴を押さえておきます。
- 標準パッケージ：短期間かつ低コストで始めやすい方式です。
- クラウドSaaS：サーバー保守やバージョンアップの負担を抑えやすい方法です。
- PaaS・ローコード：職員が設定変更しやすい一方、ライセンス単位や改修範囲の確認が必要です。
- スクラッチ開発：制度に合わせやすい反面、初期費用と将来の保守・改修費が大きくなりやすい方法です。
RFIやRFPでは、必須機能と加点機能を分けたうえで、同じデモシナリオを使って各社を比べます。
たとえば、団体が抽選に申し込み、当選後に減免を申請する場面を想定します。そのうえで、承認後のカード決済、キャンセルと返金、職員による監査ログの確認まで実演してもらいます。
機能数だけでなく、職員が設定を変えられる範囲、移行作業をどこまで誰が受け持つか、障害時に誰へどう連絡するかを確認します。さらに、契約終了時のデータ返却方法も比べます。
フェーズ3: 設計・開発による運用ルールの画面への落とし込み
制度を画面と機能に落とし込むには、設計と開発の段階で5つの要素を確かめます。
- 画面とデータ：住民向けWeb画面と職員向け管理画面。認証、会員、施設、料金、予約の各データベース。
- 業務機能：抽選・承認ワークフローや通知、決済。帳票、分析、外部機器連携も含みます。
- 安全性：管理者MFA、最小権限、暗号化、操作ログ、バックアップ、復旧手順。カード番号は自社DBに保持しません。
- 職員による設定：施設追加、休館日や料金の変更、抽選枠・減免条件の変更を、設定画面で行えるかどうか。
- 段階的な受け入れ：複数機能を扱う場合は、基本予約と追加機能を分けて受け入れます。
利用者の氏名・連絡先・利用履歴を扱うため、個人情報の保護は非機能要件に含めます。また、カード決済では、決済代行のトークン化やホスト画面を使う方法が安全です。
藤沢市の事例のように、機能を段階的に受け入れると、稼働日への影響を抑えやすくなります。対象は、共通ID、キャッシュレス、電子キーボックス、多言語、備品予約などです。
フェーズ4: 制度とデータの組み合わせの検証
テストでは、予約から実績集計までの流れを通して確認します。制度やデータの組み合わせを網羅するには、次の3種類を検証します。
- 正常系：登録、空き状況確認、仮予約、承認、決済、領収書。通知、実績集計も含みます。
- 異常系：重複当選、期限超過、減免否認、キャンセル料、決済失敗。返金、二重申請も検証します。
- 利用条件：施設種別、曜日、時間帯、利用目的、団体区分を組み合わせたテストデータ。
通信断や職員の権限不足も、異常系で検証します。移行テストでは、利用者の重複名寄せや団体代表者、過去予約を照合します。未収・返金と利用許可番号も確認対象です。
移行では件数の一致だけでなく、データの内容も確認します。本番の個人情報をテスト環境へ持ち出す範囲と、マスキングの方法を決めてください。
稼働判定の前に、脆弱性診断、権限テスト、バックアップからの復旧テスト、障害連絡訓練を終えておきます。
フェーズ5: 稼働での並行運用と住民への周知
稼働前後の準備と運用は、次の4つに分けて進めます。
- 事前準備：最終移行、アカウント通知、職員研修、窓口担当者への説明、住民向け案内。
- 並行運用：電話・窓口の代替受付と旧データの参照手順を、一定期間残しておきます。
- 稼働判定：利用者が予約を完了でき、職員が当日の受付・承認・入金確認を処理できるかを確認します。
- 初動の確認：問い合わせ、決済エラー、予約重複、通知未達、職員の手戻りを、毎日の確認対象にします。
旧システムをすぐに止めると、新システムで登録や決済ができない住民への対応が滞ります。そこで、利用登録が必要な施設では、登録場所と本人確認の方法を施設ごとに明示します。
重大障害の判断基準と連絡先は、一本にまとめておきます。特に、スマートロックや電子キーボックスを使う場合は、通信障害時の開錠方法と鍵の管理責任者も決めておく必要があります。
フェーズ6: 定着でのKPIと改善サイクルの運用
導入後も効果を確かめて改善を続けるため、指標と運用を4つの面で決めておきます。
- 予約と施設：オンライン予約率、予約完了率、施設稼働率、キャンセル率。
- 業務と品質：電話・窓口件数、職員の受付時間、決済エラー率、問い合わせ解決時間、障害復旧時間。
- 改善の仕組み：運用マニュアル、問い合わせ分類、定例レビュー、改善要望の優先順位付け。
- 年度ごとの点検：個人情報の保存期間、委託先のアクセス権、監査ログ、バックアップ、データ返却。
予約完了率が低い場合は、画面や入力項目に問題があると考えられます。また、窓口件数が減っても、職員が手作業で補正しているなら、改善はまだ完了していません。
料金や休館日の変更を毎回有償改修にしないためには、設定で対応できる範囲を契約時に確認しておきます。
公共施設予約システムの費用相場とコストの内訳
費用は、施設数、利用者数、移行件数、決済、外部連携、スマートロックの有無で変わります。カスタマイズと保守の範囲も、金額を左右します。
ここに示す金額は、全国統一の公定価格ではありません。2025〜2026年に公開された自治体案件とベンダーの掲載価格から整理した目安です。
予算要求や比較の出発点として使い、対象施設と運用条件を示したうえで、見積もりを取ります。
公開案件から見る初期費用と5年総額の目安
公開価格から、規模別の費用感をつかめます。ただし、個別案件の条件と、価格に含まれる範囲は分けて見ます。
- 小規模な標準パッケージ・クラウド：初期90万円〜500万円程度、月額0〜5.5万円程度の掲載例。
- 複数施設の自治体クラウド：初期400万円〜1,500万円程度、5年総額1,000万円〜3,000万円程度が検討レンジ。
- 中〜大規模の再構築・機器連携：初期2,000万円〜3,500万円程度、月額50万円〜70万円程度の案件例。
小規模の掲載価格は、一ベンダーの価格表であり、自治体調達の平均ではありません。実額は、決済審査や施設ごとの初期設定、データ移行によって変わります。研修や窓口の有無も影響します。
小松島市の2026年公募は、導入上限405.3万円、2027〜2031年度の5年運用・保守上限1,026万円です。この2つを合わせた合計上限は1,431.3万円（税込）です（出典: 小松島市「公共施設予約システム導入業務」、2026年）。
また、貝塚市の公募では、構築費と2027年2月から26か月の運用費などの合計上限を771.7万円（税込）としています（出典: 貝塚市「公共施設予約システム導入事業」、2026年）。
いずれも当該案件の上限で、ほかの自治体にそのまま当てはまる金額ではありません。中〜大規模案件では、姫路市が2026年に再構築業務を2,359.5万円（税込）で契約しました。
同市のサービス利用料は、月額68.2万円（税込、予定）で、利用期間は5年です（出典: 姫路市「公共施設予約システム再構築事業に係る公募型プロポーザル」、2026年）。
単純に合算すると、5年の利用料だけで約4,092万円になります。再構築費と合わせると約6,451.5万円ですが、決済手数料や追加機器費が含まれるとは限りません。
見落としやすいランニングコストの内訳
見積もりでは、初期費用と稼働後の費用を分けて見ます。月額の安さだけで判断しないよう、次の費目も確認します。
- 導入時：要件定義、設定、開発、移行、名寄せ。操作研修、マニュアル作成も含みます。
- 運用時：月額利用料、保守、問い合わせ窓口、決済手数料、SMS送信料。
- 設備・追加対応：ドメイン、証明書、鍵・端末、脆弱性診断、追加改修。
契約によっては、施設の追加や利用者数の増加で従量課金が発生します。その対象となる条件は、見積書で確認します。
5年総額には、初期費用と月額固定費、利用量に応じた変動費を含めます。さらに、決済手数料や機器更新費、制度変更の改修費、緊急対応費も合算します。
契約終了時のデータ返却費も確認します。また、個人情報の保存期間や削除・返却の方法は、費用と契約条件に影響します。
初年度の費用に加えて、年度ごとに予算を組めるかを確かめます。
公共施設予約システムの見積もりを取る際のポイント
見積もりの精度は、依頼書にどこまで具体的な前提条件を書けるかで変わります。施設数だけを示して「一式」の見積もりを頼まず、各社に同じ条件を提示してください。
業務量や運用ルール、移行範囲のほか、連携、セキュリティ、導入後の体制も、依頼書に明記します。
公開案件では、機能要件確認書、非機能要件一覧、デモシナリオ、評価基準を用意する例もあります。
要件定義書と見積条件を同じ資料にまとめる方法
各社に同じ前提で見積もってもらうため、依頼資料には次の5つの条件をそろえて書きます。
- 施設と予約条件：施設・部屋・附帯設備、料金、休館日。予約可能期間、抽選方法、利用者区分も挙げます。
- 申請と移行条件：減免、承認者、キャンセル・返金、決済、通知。利用者数、過去予約件数、移行項目、文字コード、重複データも記します。
- 実現方法：「対応可能」な機能を標準設定、追加設定、個別開発、外部サービスに分けます。
- 非機能要件：稼働・保守時間、目標復旧時間、バックアップ頻度、同時アクセス数、MFA。脆弱性診断、監視、障害報告、監査ログも入れます。
- データと委託先：データ保管場所、契約終了時の返却形式、事業者・委託先の管理。アクセス制御、インシデント報告、監査証跡も含みます。
地方公共団体向け情報セキュリティポリシーのガイドラインは、2025年3月に改定されました。同ガイドラインは、RFPにセキュリティ条件を落とし込む根拠として参照できます（出典: 総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」改定版、2025年）。
複数社を同じシナリオと5年総額で比べる方法
価格と運用への適合性を公平に比べるには、共通の評価軸とシナリオを使います。
- 実績と機能：公共施設予約の実績、標準仕様や自治体向け要件への適合、職員が行える設定変更。
- 運用体制：移行や決済・返金の経験、指定管理者の権限分離、問い合わせ体制。
- 比較シナリオ：「抽選から返金まで」「職員の料金変更」「障害時の窓口受付への切替」を実演します。
- 5年総額：初期費用、月額固定費、利用者数・施設数に応じた従量費、決済手数料。移行、研修、保守、機器、追加改修、終了時のデータ返却費も含めます。
- 責任の範囲：障害復旧、更新、制度変更、第三者サービス停止時の代替策と、判断主体・費用負担。
SaaS、PaaS、個別ホスティングでは、責任の範囲が異なります。「クラウド対応」の一言からは、その違いは読み取れません。そこで、実務シナリオで実際に操作してもらうと、カタログ記載からは見えない操作性を判断できます。
契約前に確認したい失敗しやすいリスク
契約後の運用負担や改修漏れを防ぐには、次のリスクを事前に確認しておくことが要ります。
- 業務要件の後回し：住民向け画面を優先しすぎて、施設例外や減免、返金、利用許可、会計消込が後回しになりがちです。
- 受け入れと保守：現場代表者が要件定義と受入テストに加わり、標準機能、運用補完、個別開発を切り分けます。
- 納品物：個別開発の場合は、設計書とテスト仕様書を納品条件に含めて、保守をしやすい状態にします。
- 問い合わせ対応：受付時間、一次切り分け、緊急度、SLA。代替受付、復旧連絡、住民への告知方法も決めておきます。
- 個人情報：利用目的、保存期間、権限、委託先、削除・返却方法の確認。
個人情報の扱いは、個人情報保護委員会のガイドラインを参照して確認します（出典: 個人情報保護委員会「個人情報保護法ガイドライン（行政機関等編）」）。契約終了時には、データの削除・返却手順を定め、データが残り続けるのを防ぎます。
よくある質問（FAQ）
導入前によく相談される質問への答えです。費用や期間は施設数と制度差分で変わるため、目安と見積もり条件を分けて考えてください。
公共施設予約システムの開発期間はどのくらいですか？
標準パッケージの初期設定、決済審査、データ移行、研修までであれば、1〜3か月程度が目安です。複数施設でカスタマイズする場合は、3〜8か月程度です。
再構築や機器連携、大規模なデータ移行がある場合は、6〜12か月以上かかることもあります。その際は、条例や運用の整理、住民への周知、旧システムとの並行期間も計画に含めます。
フルスクラッチ開発とパッケージ導入はどちらがよいですか？
独自の抽選や減免、料金計算のほか、複数の基幹連携や機器連携を標準機能で解決できない場合は、個別開発が候補になります。
ただし、全機能を最初から作る必要はありません。予約や通知、利用者管理には標準パッケージを使い、制度上の差分だけを追加する方法もあります。
標準機能で足りない差分の件数、将来改修の頻度、職員の設定変更ニーズを比べ、費用と保守のバランスで判断します。
高齢者などオンライン予約が難しい住民にはどう対応しますか？
オンライン化しても、電話や窓口での支援をすぐには廃止しないのが基本です。そのうえで、施設窓口での登録、職員による代理予約、操作説明、紙の案内を用意します。
障害時の代替受付も設け、誰がどの条件で代理操作したかをログに残します。画面の文字サイズやキーボード操作、読み上げ、多言語も確認します。
決済方法を含めて、住民が予約を完了できるかを受入テストで確かめます。
個人情報と決済の安全性はどのように確認しますか？
利用目的、権限、保存期間、委託先、削除・返却方法は、仕様書と契約書に記載します。氏名や連絡先、団体情報、利用履歴を扱うためです。
管理者のMFAや最小権限、通信・保存データの暗号化、操作ログ、バックアップを確認します。あわせて、復旧訓練、脆弱性診断、インシデント報告も見ておきます。
カード番号は予約システムに保存せず、決済代行のトークン化やホスト画面を使います。加えて、3Dセキュアなどの認証対応と障害時の手順も確認しておくと安全です。
まとめ
導入前に押さえる判断基準
公共施設予約システムの開発は、予約画面を作ることに加えて、行政業務の再設計でもあります。受付、抽選、利用許可、減免、決済。返金、会計、監査、指定管理者の役割まで含めて見直します。
現状と例外を整理したうえで、標準機能と制度差分を分けてください。続いて、同じシナリオを使って製品と開発会社を比べます。
稼働後の定着までを含めた成果の確認
費用は、初期費用だけでなく5年総額で判断します。総額には、月額利用料や決済手数料、移行、研修を含みます。さらに、機器、保守、追加改修も入れます。
契約終了時のデータ返却も、費用に含めて考えます。各フェーズで判断の基準を定め、予約完了率と職員の手戻りを継続して測れば、導入後もサービスを改善していけます。
▼全体ガイドの記事
・公共施設予約システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。