公共施設予約システムの開発は、空き状況を表示するだけではなく、利用者登録、抽選、利用許可、減免、決済、返金、指定管理者の権限、監査までを一つの業務フローに整える取り組みです。
本記事では、自治体や施設運営者が公共施設予約システムを導入・再構築するときの進め方を、要件整理、製品選定、設計開発、テスト、稼働、定着の6フェーズで解説します。公開案件をもとにした費用相場、見積書で確認する項目、住民と職員の双方が使い続けられるチェックポイントまで、実務でそのまま使える形に整理しています。
▼全体ガイドの記事
・公共施設予約システム開発の完全ガイド
公共施設予約システム開発の全体像

公共施設予約システムは、住民向けの予約画面と職員向けの管理画面をつなぎ、施設の利用申請から実績管理までを継続的に処理する業務システムです。開発の成否は、画面の見た目よりも、自治体ごとに異なる制度や現場の例外を、無理なく運用できるルールとして整理できるかで決まります。
単なる予約カレンダーではなく行政業務を扱います
住民側では、施設や部屋の検索、空き状況の確認、仮予約、本予約、抽選申込、予約変更、キャンセル、決済、領収書発行、利用履歴確認、メール通知を使います。一方、職員側では、施設・部屋・附帯設備、利用目的、料金、休館日、予約開始日、抽選ルール、減免条件を設定し、申請の審査、利用許可、入金確認、返金、統計出力、告知、問い合わせ対応まで行います。どちらか一方の画面だけを先に決めると、受付後の審査や例外処理が手作業に戻りやすくなります。
住民UXと職員UXを同じ業務フローで考えます
利用者がスマートフォンで24時間申請できても、職員が施設ごとの料金変更や減免承認をベンダーへ依頼し続けるなら、導入効果は限定的です。反対に、職員が細かく設定できても、利用者登録が難しく、抽選結果や支払い期限が分かりにくければ、電話・窓口への問い合わせが減りません。藤沢市の2025年事例では、施設ごとに分かれていた利用者IDと紙中心の予約対応を見直し、共通ID、キャッシュレス、電子キーボックス、多言語、備品予約までをクラウドでまとめています(出典: NTTデータ北海道・ServiceNow Japan、2025年)。このように、住民の便利さと職員の作業削減を一つの成果指標として定義することが重要です。
公共施設予約システム開発の進め方

公共施設予約システムの開発は、要件整理、選定、設計開発、テスト、稼働、定着の順に進めると、制度とシステムのずれを早く発見できます。ただし、フェーズを一方的に進めるのではなく、各段階で住民、施設職員、会計担当、情報政策担当、指定管理者の確認を挟むことが大切です。
フェーズ1: 要件整理で現状と例外を洗い出します
最初に、対象施設、管理主体、受付方法、利用者区分、料金、減免、抽選、キャンセル、利用許可、支払期限、返金条件を一覧化します。体育館、公民館、文化ホール、テニスコートでは利用単位や予約開始時期が違うため、「全施設で同じ」と決めつけず、共通ルールと施設固有ルールを分けて記録します。電話・窓口・紙・既存システムから、誰が、いつ、何を確認し、どの帳票を出しているかを業務フローにすると、必要機能の優先順位が見えます。
要件整理のチェックリストには、施設数と部屋数、月間予約件数、ピーク時の同時アクセス、利用者・団体の登録件数、過去予約の移行範囲、決済手段、返金と消込、指定管理者の権限、障害時の代替受付、保存期間、監査ログ、稼働希望日を含めます。特に「減免の承認者」「抽選後に空いた枠の扱い」「団体代表者の変更」「重複申請」「未収金」を文章で定義しておくと、後工程の追加開発を抑えられます。
フェーズ2: 選定で標準機能と差分を見極めます
選択肢は、公共施設予約向けの標準パッケージ、クラウドSaaS、PaaSやローコード、個別開発に大別できます。標準パッケージは短期・低コストで始めやすく、SaaSはサーバー保守やバージョンアップの負担を抑えやすい方法です。PaaSやローコードは職員が設定変更しやすい一方、ライセンスの単位や改修範囲を確認する必要があります。スクラッチ開発は制度への適合度が高い反面、初期費用と将来の保守・改修費が大きくなりやすい方法です。
RFIやRFPでは、必須機能と加点機能を分け、同じデモシナリオで各社を比較します。たとえば「団体が抽選に申し込み、当選後に減免を申請し、承認後にクレジットカードで支払い、キャンセルして返金し、職員が監査ログを確認する」という一連の操作を実演してもらいます。機能数の多さではなく、職員が設定を変更できる範囲、データ移行の責任分界、障害時の連絡体制、契約終了時のデータ返却方法まで比較してください。
フェーズ3: 設計・開発で運用ルールを画面に落とし込みます
設計では、住民向けWeb画面、職員向け管理画面、認証・会員データベース、施設・料金・予約データベース、抽選・承認ワークフロー、通知、決済、帳票、分析、外部機器連携の境界を定めます。利用者の氏名・連絡先・利用履歴を扱うため、管理者MFA、最小権限、暗号化、操作ログ、バックアップ、復旧手順を非機能要件に含めます。カード番号は自社データベースに保持せず、決済代行のトークン化やホスト画面を基本にする設計が安全です。
開発中は、施設職員が実際の設定画面を触り、施設追加、休館日変更、料金改定、抽選枠の変更、減免条件の変更を自分で行えるか確認します。藤沢市の事例のように、共通ID、キャッシュレス、電子キーボックス、多言語、備品予約を同時に扱う場合は、基本予約と追加機能を分けて段階的に受け入れると、稼働日への影響を抑えやすくなります。
フェーズ4: テストで制度とデータの組み合わせを検証します
テストは、画面が開くかを見るだけでは不十分です。正常系では、利用者登録、空き状況確認、仮予約、承認、決済、領収書発行、通知、利用実績集計を確認します。異常系では、抽選の重複当選、支払期限超過、減免の否認、キャンセル料発生、決済失敗、返金、同じ時間帯への二重申請、通信断、職員の権限不足を検証します。施設種別、曜日、時間帯、利用目的、団体区分を組み合わせたテストデータを作成することがポイントです。
移行テストでは、利用者の重複名寄せ、団体代表者、過去予約、未収・返金、利用許可番号を確認し、件数だけでなく内容の一致を照合します。個人情報を含む本番データを使う場合は、テスト環境への持ち出し範囲とマスキング方法を決めます。脆弱性診断、権限テスト、バックアップからの復旧テスト、障害連絡訓練も、稼働判定の前に完了させる必要があります。
フェーズ5: 稼働で並行運用と住民周知を行います
稼働直前には、旧システムからの最終移行、アカウント通知、施設職員の研修、窓口担当者向けの説明、住民向けの利用案内を実施します。旧システムをすぐ停止すると、登録できない住民や決済できない利用者への対応が滞るため、一定期間は電話・窓口での代替受付と、旧データを参照できる手順を残します。利用登録が必要な施設では、登録場所や本人確認の方法を施設ごとに明示してください。
稼働判定は、システムが完成したかではなく、利用者が予約を完了でき、職員が当日の受付・承認・入金確認を処理できるかで行います。開始直後は問い合わせ件数、決済エラー、予約の重複、通知の未達、職員の手戻りを毎日確認し、重大障害の判断基準と連絡先を一本化します。スマートロックや電子キーボックスを連携する場合は、通信障害時の開錠方法と鍵の管理責任者も事前に決めておくことが必要です。
フェーズ6: 定着でKPIと改善サイクルを運用します
稼働後は、オンライン予約率、予約完了率、電話・窓口件数、職員の受付時間、施設稼働率、キャンセル率、決済エラー率、問い合わせ解決時間、障害復旧時間を月次で確認します。オンライン予約率が上がっても、予約完了率が低ければ画面や入力項目に問題があります。窓口件数が減っても、職員が手作業でデータを補正しているなら、業務改善は完了していません。
定着には、職員が自分で設定変更できる運用マニュアル、問い合わせの分類、定例レビュー、改善要望の優先順位付けが必要です。料金や休館日などの変更を毎回有償改修にしないため、設定で対応できる範囲を契約時に確認します。個人情報の保存期間、委託先のアクセス権、監査ログ、バックアップ、契約終了時のデータ返却も、年度ごとの点検項目にしてください。
公共施設予約システムの費用相場とコストの内訳

公共施設予約システムの費用は、施設数、利用者数、移行件数、決済、外部連携、スマートロック、カスタマイズ、保守範囲で大きく変わります。以下は全国統一の公定価格ではなく、2025〜2026年に公開された自治体案件とベンダー掲載価格から整理した目安です。予算要求や比較の出発点として使い、最終的には対象施設と運用条件を提示して見積もりを取得してください。
公開案件から見る初期費用と5年総額の目安
小規模な標準パッケージやクラウドでは、初期費用90万円〜500万円程度、月額0〜5.5万円程度の掲載例があります。ただし、これは一ベンダーの価格表であり、自治体調達の平均ではありません。決済審査、施設ごとの初期設定、データ移行、研修、問い合わせ窓口が含まれるかで実額は変わります。
複数施設の自治体クラウドでは、初期400万円〜1,500万円程度、5年運用を含む総額1,000万円〜3,000万円程度が一つの検討レンジになります。小松島市の2026年公募は、導入上限405.3万円、2027〜2031年度の5年運用・保守上限1,026万円、合計1,431.3万円(税込)です(出典: 小松島市「公共施設予約システム導入業務」、2026年)。貝塚市の公募では、構築費と2027年2月から26か月の運用費などの合計上限を771.7万円(税込)としています(出典: 貝塚市「公共施設予約システム導入事業」、2026年)。いずれも当該案件の上限であり、他自治体にそのまま当てはめる金額ではありません。
中〜大規模の再構築や機器連携では、初期2,000万円〜3,500万円程度、月額50万円〜70万円程度の案件もあります。姫路市は2026年、再構築業務を2,359.5万円(税込)、サービス利用を月額68.2万円(税込、予定)で契約し、サービス利用期間を5年と公表しています(出典: 姫路市「公共施設予約システム再構築事業に係る公募型プロポーザル」、2026年)。単純合算では5年の利用料だけで約4,092万円となるため、再構築費と合わせた総額は約6,451.5万円です。ただし、これは同市の契約条件による計算で、決済手数料や追加機器費を含むとは限りません。
見落としやすいランニングコストを分けて考えます
見積もりでは、初期の要件定義・設定・開発費と、稼働後の月額利用料・保守費を分けます。さらに、データ移行、利用者登録の名寄せ、操作研修、マニュアル作成、問い合わせ窓口、決済代行手数料、SMS送信料、ドメインや証明書、スマートロック・電子キーボックス、端末、脆弱性診断、追加改修を別項目にしてください。月額が安く見えても、施設追加や利用者数の増加で従量課金が発生する契約があります。
5年総額を比較するときは、初期費用、毎月の固定費、利用量に応じた変動費、決済手数料、機器の更新費、制度変更への改修費、障害時の緊急対応費、契約終了時のデータ返却費を合算します。行政機関等の個人情報を扱うため、保存期間と削除・返却の方法も費用と契約条件に影響します。初年度だけでなく、年度ごとの予算化が可能かを確認することが重要です。
公共施設予約システムの見積もりを取る際のポイント

見積もりの精度は、依頼書にどれだけ具体的な前提条件を書けるかで変わります。施設数だけを伝えて「一式」で見積もるのではなく、業務量、ルール、移行範囲、連携、セキュリティ、導入後の体制を同じ様式で各社に提示します。公開案件でも、機能要件確認書、非機能要件一覧、デモンストレーションシナリオ、評価基準を用意して比較する例があります。
要件定義書と見積条件を同じ資料にそろえます
依頼資料には、対象施設・部屋・附帯設備の一覧、施設ごとの料金表、休館日、予約可能期間、抽選方法、利用者区分、減免条件、承認者、キャンセル・返金規則、決済手段、通知方法を添付します。利用者数と過去予約件数、移行するデータ項目、文字コード、重複データの扱いも明記してください。「対応可能」と書かれた機能は、標準設定、追加設定、個別開発、外部サービスのどれで実現するのかを分解して確認します。
非機能要件には、稼働時間、保守時間、目標復旧時間、バックアップ頻度、同時アクセス数、管理者MFA、脆弱性診断、監視、障害報告、監査ログ、データ保管場所、契約終了時の返却形式を含めます。地方公共団体向けの情報セキュリティポリシーに関するガイドラインは2025年3月に改定されているため、クラウド事業者や委託先の管理、アクセス制御、インシデント報告、監査証跡をRFPへ落とし込む根拠として参照してください(出典: 総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」改定版、2025年)。
複数社を同じシナリオと5年総額で比較します
比較社数は、価格だけでなく、公共施設予約の実績、標準仕様や自治体向け要件への適合、施設職員が行える設定変更、データ移行の経験、決済・返金の運用、指定管理者の権限分離、問い合わせ体制で評価します。提案説明では「抽選から返金まで」「職員が料金を変更する」「障害発生時に窓口受付へ切り替える」という実務シナリオを見せてもらうと、カタログ上の機能と実際の使いやすさを切り分けられます。
価格比較表には、初期費用、月額固定費、利用者数・施設数に応じた従量費、決済手数料、移行、研修、保守、機器、追加改修、終了時のデータ返却費を記載します。クラウド対応という言葉だけでは、SaaS、PaaS、個別ホスティングの責任分界は分かりません。障害時の復旧、バージョンアップ、制度変更、第三者サービス停止時の代替策について、誰が費用と判断を負うのかを契約前に明確にしてください。
失敗しやすいリスクを契約前に確認します
よくある失敗は、住民向け画面を優先しすぎて、施設ごとの例外、減免、返金、利用許可、会計消込を後回しにすることです。対策として、現場の代表者を要件定義と受入テストに参加させ、標準機能でできること、運用で補うこと、個別開発することを一覧化します。個別開発を選ぶ場合は、将来の制度変更や担当者交代でも保守できる設計書とテスト仕様書を納品条件に含めてください。
もう一つのリスクは、稼働後に問い合わせや例外処理が職員へ集中することです。導入前に問い合わせ窓口の受付時間、一次切り分け、緊急度の定義、SLA、代替受付、復旧連絡、住民への告知方法を決めます。個人情報保護委員会の行政機関等向けガイドラインを踏まえ、利用目的、保存期間、権限、委託先、削除・返却方法を確認し、契約終了後にもデータが残り続ける状態を避けてください(出典: 個人情報保護委員会「個人情報保護法ガイドライン(行政機関等編)」)。
よくある質問(FAQ)

ここでは、公共施設予約システムの導入前に特に相談されやすい質問へ回答します。費用や期間は施設数と制度差分で変わるため、一般的な目安と、見積もり時に確認すべき条件を分けて考えてください。
公共施設予約システムの開発期間はどのくらいですか?
標準パッケージの初期設定、決済審査、データ移行、研修までなら1〜3か月程度、複数施設でカスタマイズを含む場合は3〜8か月程度が目安です。再構築や機器連携、大規模なデータ移行がある場合は6〜12か月以上かかることもあります。条例・運用ルールの整理、住民周知、旧システムとの並行運用期間を含めて計画してください。
フルスクラッチ開発とパッケージ導入はどちらがよいですか?
独自の抽選、減免、料金計算、複数の基幹連携、機器連携が標準機能で解決できない場合は、個別開発が候補になります。ただし、最初から全機能をスクラッチで作るのではなく、予約、通知、利用者管理などは標準パッケージを使い、制度上の差分だけを追加する方法が費用と保守のバランスを取りやすいです。標準機能で足りない差分の件数、将来改修の頻度、職員の設定変更ニーズを比較して判断してください。
高齢者などオンライン予約が難しい住民にはどう対応しますか?
オンライン化しても、電話・窓口の支援をすぐに廃止しないことが基本です。施設窓口での利用者登録、職員による代理予約、操作説明、紙の案内、障害時の代替受付を用意し、誰がどの条件で代理操作したかをログに残します。スマートフォン画面の文字サイズ、キーボード操作、読み上げ、多言語、決済方法も確認し、住民が予約を完了できるかを受入テストに含めてください。
個人情報と決済の安全性はどのように確認しますか?
利用者の氏名、連絡先、団体情報、利用履歴を扱うため、利用目的、権限、保存期間、委託先、削除・返却方法を仕様書と契約書に記載します。管理者MFA、最小権限、通信・保存データの暗号化、操作ログ、バックアップ、復旧訓練、脆弱性診断、インシデント報告の流れを確認してください。カード番号は予約システムに保存せず、決済代行のトークン化やホスト画面を使い、3Dセキュアなど決済事業者側の認証対応と障害時手順を確認すると安全です。
まとめ

導入前に押さえるべき判断基準をそろえます
公共施設予約システムの開発は、住民向けの予約画面を作るプロジェクトではなく、受付、抽選、利用許可、減免、決済、返金、指定管理者、会計、監査を含む行政業務の再設計です。まず現状と例外を整理し、標準機能と制度差分を分け、同じシナリオで製品と開発会社を比較してください。
稼働後の定着までを成果として確認します
費用は、初期費用だけでなく、月額利用料、決済手数料、移行、研修、機器、保守、追加改修、契約終了時のデータ返却まで含む5年総額で判断します。要件整理から定着まで各フェーズの判断基準を明確にし、住民の予約完了率と職員の手戻りを継続的に測定できれば、導入後も改善できる公共サービスになります。
▼全体ガイドの記事
・公共施設予約システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
