保育園・幼稚園向けの保育料管理システムは、6段階で進めます。前半は要件整理、方式の選定、設計・開発で、後半はテスト、稼働、定着です。
料金ルールを先に整理しておくと、各段階の判断がぶれにくくなり、請求額の根拠を示せるシステムに近づきます。
▼全体ガイドの記事
・保育園・幼稚園向け保育料管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
保育園・幼稚園向け保育料管理システムの役割
保育料管理システムは、園児台帳、契約、登降園実績、料金マスタをつなぎ、請求計算から集金、入金消込、未収管理までを支える仕組みです。
請求額の根拠を明細と履歴で説明できるよう、設計しておくことが大切です。
請求書発行と園務データの連携
園児ごとの請求から入金突合までを正確に扱うには、連携させる園務データを役割別に整理しておくことが要ります。
- 園児情報：園児、保護者、家族、兄弟姉妹、在籍期間、認定区分の管理
- 料金と利用実績：月極、延長、一時預かり、預かり保育、給食、教材、行事、おむつ代などの扱い
- 請求と入金：登降園時刻や利用日数と、口座振替、カード、コンビニ、振込、現金の結果の突合
この構成にすると、毎月のExcel転記を減らせるうえ、スマートフォンやメールで保護者に内訳を通知できます。また、園側では、締め処理、承認、修正履歴、未収一覧を残せます。
保育士は登降園や利用実績など現場の事実を入力します。金額の計算と請求の確定は、別の権限に分ける設計が適しています。
保育園と幼稚園で異なる料金ルールと必要帳票
施設の種別によって、利用料の計算方法や自治体への提出内容が変わります。料金設計では、次の条件を分けて確認します。
- 施設区分：保育園、幼稚園、認定こども園、企業主導型、認可外の区分
- 料金区分：無償化対象と、園が徴収する実費の区別
- 園児ごとの条件：認定、利用時間、兄弟条件、減免、上限、日割り、返金の確認
- マスタ運用：適用開始日と終了日を持たせる設計と、複数園での共通設定・園ごとの例外の区別
こども家庭庁の案内では、3〜5歳児、住民税非課税世帯の0〜2歳児、幼稚園の預かり保育、認可外施設の上限を分けて扱っています。また、送迎費、食材料費、行事費などは保護者負担となる場合があります。
締め日後の修正も、確認項目に加えておきます（出典：こども家庭庁「幼児教育・保育の無償化について」、2026年8月確認）。
適用開始日と終了日を持たせておくと、年度更新や制度改正の後も過去の請求計算を保てます。また、複数園を運営する法人では、料金マスタの変更を本部が承認します。
保育園・幼稚園向け保育料管理システムの進め方
機能一覧を先に決めるより、現行の請求業務と例外処理を明らかにしてから進めるほうが、失敗しにくくなります。
6段階のそれぞれで成果物と判断基準を決め、未決事項を次の段階に持ち越さないことが大切です。持ち越すと、後の段階で手戻りが生じやすくなります。
フェーズ1：要件整理による料金ルールと業務の正本の確定
要件整理では、現行の資料と承認の流れを確認します。そのうえで、どの資料を集め、どの業務を整理の対象にするかをまとめます。
- 資料：園児台帳、契約書、料金表、減免申請、登降園データ、請求書、領収書の収集
- 会計・行政資料：口座振替結果、会計仕訳、自治体提出帳票の確認
- 業務フロー：「誰が、いつ、何を確定し、誰が承認するか」の取り決め
- 料金分類：固定費、実績連動、減免・無償化、兄弟・世帯、日割り・返金、締め処理の区分
要件定義書には、転園・退園、月途中の入園、長期欠席の扱いを書きます。また、延長時間の修正や一時利用、兄弟まとめ請求も含めます。さらに、過徴収の返金と未収の再請求も、要件定義書に記載します。
判断基準は、担当者が変わっても同じ金額を再現できること、明細で根拠を説明できること、制度改正にマスタの変更で対応できることです。
導入の目的は、測定できる形で定めます。たとえば、月末の請求確定時間、修正請求件数、未収確認件数、現金取扱量を減らす形にします。
フェーズ2：選定によるSaaS・パッケージ・スクラッチの比較
方式は、自園の規模や連携要件に合わせて選びます。候補は5つあり、1園で早く始めるか、複数園や自治体との連携まで見据えるかで、向く方式が変わります。
- SaaS・クラウド：1園で早く始めたい場合の候補
- パッケージ拡張：パッケージへの設定追加の検討
- 連携開発：複数園の本部管理や、自治体・会計との深い連携が必要な場合の検討
- 個別開発：標準機能で足りない業務要件が多い場合の検討
- ハイブリッド：既存機能と個別の連携開発の組み合わせ
スクラッチ開発に進む前に、CSV、API、帳票設定で代替できる範囲を確かめておきます。そのうえで、比較の際は各社に同じテストケースを示します。
例として、月極料金に延長2時間、給食費、教材費、兄弟割引を加えたケースを示します。さらに、欠席日の日割り、無償化対象外の実費、前月未収も加え、締め後に返金する場面まで提示します。
計算の結果に加えて、料金の変更者と承認者、再計算、明細、入金消込、履歴の確認方法も、実演してもらいます。
フェーズ3：設計・開発による計算と権限の仕組みの確定
設計では、データの関係と料金マスタの条件を定義します。あわせて、計算履歴を保てる設定にしておく必要があります。
- データ：園児、保護者、世帯、施設、クラス、認定、契約、料金、実績、請求、入金、返金を結ぶ設計
- 料金条件：対象施設・年齢、曜日、時間帯、適用期間、上限、割引、課税区分を持たせる設計
- 版管理：制度変更の前後を比べられるよう、マスタを上書きしない設計
画面は役割ごとに、現場の実績入力、事務・本部の料金設定と請求確定、園長の承認、保護者向けの明細と決済に分けます。
保育士に請求額を手入力させると、入力の負担が増え、誤りも起きやすくなります。そのため、現場の事実を入力すると金額が自動で計算される設計を優先します。また、金額の計算と請求の確定は、現場の入力と権限を分けておくのが適しています。
納品物には、画面仕様、データ項目、権限、連携仕様、エラー時の再送手順を含めてもらいます。
フェーズ4：テストによる通常処理と例外処理の同条件での検証
テストでは、請求額が正しく再現され、その根拠を説明できるかを検証します。そのためには、テスト条件を漏れなく揃えることが欠かせません。
- 請求ケース：月極、延長、預かり、一時利用、兄弟割引、減免、無償化の組み合わせ
- 例外ケース：欠席、日割り、月途中の入退園、返金、繰越、未収、再請求の場面
- 連携ケース：口座振替の失敗や重複取込の場面
自治体や施設種別が違うときは、同じ園児情報を使い回さず、制度ごとに期待結果を分けます。
受入テストには、園長、事務、現場職員、本部経理が参加し、可能であれば保護者代表も加わります。
テストの記録には、入力と期待額、実結果を残します。さらに、差異、対応者、再テスト日も記録します。
締め処理後の修正権限や、承認前後の状態、修正前の履歴を確認します。加えて、CSVの再取込と障害時の復旧も試しておきます。
請求月をまたぐ修正が、過去の帳票に正しく反映されるかも、稼働前に試します。
フェーズ5：稼働による移行・締め日・障害時の運用の切り替え
稼働前には、移行の対象と検証方法を決めておきます。完了の条件は、請求照合と未収残高の突合までとします。
- 移行データ：園児・家族・兄弟・在籍履歴、契約、料金マスタ、未収残高、口座情報
- 移行管理：個人情報の変換ルール、件数確認、重複検出、旧システム照合、廃棄方法、責任者の決定
- 完了判定：代表園児の請求額が旧帳票と一致し、未収残高も合うこと
本番切替は、請求締め日の直前を避けて行い、試験運用の期間を設けます。最初の1〜2回は、旧手順と新システムを並行して照合します。差異がなくなってから、新システムを正本にします。
停止時間や通信障害に備え、紙の暫定記録と後からの再入力を決めておきます。決済結果の再取込と問い合わせ先も、あわせて決めます。
保護者には、請求明細の見方や決済の登録方法、問い合わせ窓口を事前に案内します。
フェーズ6：定着による制度改正と日々の改善の管理
稼働後は、担当者だけに操作が偏らないよう、定着に必要な教育と変更管理を整えます。
- 教育・支援：役割別マニュアル、短時間研修、問い合わせ対応の用意
- 月次確認：運用の定期的な振り返りと、日々の改善
- 変更管理：制度改正や料金改定の調査、マスタ変更、テスト、承認それぞれの担当
変更前後の料金表、テスト結果、承認記録を保管しておくと、翌年度の更新や監査の際に経緯をたどれます。
定着の度合いは、導入直後の操作回数よりも業務指標で測ります。対象は、請求確定時間、手修正件数、未収確認日数です。請求問い合わせや口座振替エラーの再処理時間、現金取扱量も、あわせて見ます。
こども家庭庁は、2026年度からこども誰でも通園制度を全国の自治体で実施すると案内しています（出典：こども家庭庁「こども誰でも通園制度について」、2026年8月確認）。
時間単位利用や一時利用を扱う園は、将来のスポット課金や自治体連携も見据えて、拡張性を確保します。
保育園・幼稚園向け保育料管理システムの費用相場と内訳
費用は、施設数、園児数、料金ルールの複雑さによって変わります。登降園、会計、決済、自治体との連携、データ移行、保守の範囲によっても差が出ます。
公開価格のあるSaaSと個別開発の見積もりは、総額をそろえて比べます。比べる際は、初期費用と月額に加えて、決済手数料や端末も比べます。移行、導入支援、制度改正対応を含めた総額で判断します。
クラウド型の初期費用と月額費用の比較
公開価格を確認したリサーチノートでは、単一施設向けのSaaSについて、次の金額を比較の起点としています。
- 一般的な比較幅：初期費用0円から数十万円
- 基本機能とオプション：必要なオプション込みで月額おおむね5,000円から3万円程度
- CoDMON基本料：初期0円から、定員30名まで月3,300円、31〜60名は5,500円、61〜100名は8,800円（税込）
- 複数オプションパック：定員31〜100名で月33,000円（税込）と案内
料金は、定員や必要な機能、端末によって変わります。初期設定、データ移行、サポートの有無でも差が出ます。そのため、必要な機能を足した月額と年間の決済手数料を合わせて比べます。
CoDMONの請求管理や保育料計算などはオプションです（出典：株式会社コドモン「ご利用料金について」、2026年8月確認）。
個別開発の機能範囲ごとの推定レンジ
保育料管理だけの公開統計は少ないため、ここでの金額は、リサーチノートに基づく推定です。参照したのは、一般的な業務システムの工程比率、公開SaaS価格、公的連携案件です。
保育料管理に固有の実績相場とまでは断定できません。要件の複雑さを把握するための初期予算として使い、実際の見積もりで確認します。
- 設定・帳票・CSV連携：初期50万〜300万円、期間1〜3か月程度
- 1園向け新規構築：園児台帳、延長料金、請求、入金管理を含み、初期300万〜800万円、3〜6か月程度
- 複数園・本部向け：会計・給付費・自治体連携、複雑な権限や監査ログを含め、800万〜2,000万円、6〜12か月程度
- 自治体・大規模法人向け：複数制度、API、移行、冗長化、24時間運用を含め、2,000万〜5,000万円超、12〜18か月程度になる可能性
1園向けの場合でも、登降園、保護者通知、決済、複数の例外計算を加えるほど、上限に近づきます。
見積もりは、要件定義の後に取ります。その際は、工程ごとに、どこまでを誰が受け持つかを分けて示してもらいます。
ランニングコストと補助制度を含めた3年TCO
3年間の総額は、次のランニング費用と補助制度の条件を含めて比べます。
- 月額・決済：利用料と、口座振替・カード決済の手数料
- 運用費：端末購入・レンタル、通信、保守、サポート、制度改正、帳票変更、追加ユーザー、保管、バックアップ、教育費
- 補助条件：対象機能、補助率、施設ごとの回数、申請時期、事業者負担、交付決定前の契約可否（自治体に確認）
複数園にしたり、オプションを足したりすると、月額が積み上がる場合があります。個別開発も、将来の変更費や保守費を含めて比べます。
リサーチノートが確認した令和7年度の補助基準額の例は、1機能20万円、2機能40万円です。3機能では60万円、4機能では80万円となります。端末購入を組み合わせる場合は、70万〜130万円です（出典：こども家庭庁「令和7年度保育関係補正予算の概要」、2026年8月確認）。
これらの条件は自治体によって異なります。そのため、補助金を差し引いた金額で先に契約しないようにします。
見積もりを取る際のポイントとチェックリスト
見積額だけを見ると、機能ごとの別料金や、移行・テスト・制度改正対応の抜けを見落としがちです。
計算ルールやデータ、画面、帳票、連携から保守まで、同じ粒度で記載します。そのうえで、各社が何を含み、何を含まないかを明示できる資料を用意します。
要件とRFPに入れる計算・移行・運用の確認項目
要件資料は、計算、データ、連携、移行、権限、運用の観点で揃えます。各社の対応範囲を比べられるよう、項目を記載します。
- 計算：施設種別、認定、料金、単価、期間、上限、減免、兄弟、日割り、返金、締め日。
- データ：園児、保護者、家族、在籍、登降園、実績、請求、入金、未収、決済。
- 連携・帳票：保護者通知、会計・自治体・口座振替、CSV・API仕様、失敗時の再送。
- 移行：対象と件数、重複確認、旧環境との照合、移行後の廃棄。
- 権限・安全：職員、園長、本部、経理、自治体、保護者の権限、ログ、承認、退職者停止、復元、障害時手順。
さらに、研修やマニュアル、問い合わせ窓口を確認します。制度改正時の設定や解約時のデータ返却、保守応答時間も、導入後の担当範囲まで比べられるよう確かめます。
複数社比較で使う同じ実データとデモシナリオ
方式の違う会社に同じ前提を伝えると、追加費用を含めて比べやすくなります。依頼の際は、必要な情報を揃えておきます。
- 候補：保育業務SaaS、パッケージ設定会社、個別開発や連携に強いSI会社
- 施設情報：園児数、施設数、職員数、月間請求・決済件数、希望稼働時期
- 既存環境：現行システム、保護者アプリの有無、会計ソフト、自治体帳票
評価は、機能適合、料金の柔軟性、期間、移行支援、操作性の観点で点をつけます。連携、安全性、制度改正、保守、データ返却も、同じ基準で採点します。
デモでは、請求前の差異確認、修正承認、保護者への再通知を実際に見せてもらいます。入金消込を一括で処理できるかも、あわせて確かめます。
事例については、何施設で使われているかに加えて、業務時間の導入前後と対象期間も聞きます。
セキュリティとベンダーロックインの契約上の備え
子どもの氏名や住所、家族関係、認定、決済情報を扱うため、安全管理は、SSL対応より広い範囲で確かめます。見るのは、権限の管理、データの保護、事故時の対応の3点です。
- アクセス管理：職員・本部・自治体・保護者の権限と多要素認証。
- データ保護：通信・保存時の暗号化、操作ログの保管・分析、脆弱性対応、バックアップ頻度と復元テスト。
- 事故対応：障害連絡、保管期間、削除、委託先・再委託先、事故報告体制。
個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」を踏まえておきます（2026年8月確認）。
必要な情報だけを集めるとともに、保管期間、削除手順、委託・再委託先を契約に記載します。事故時の報告体制も、契約に落とし込みます。
解約時は、園児、請求、入金、未収、操作履歴のデータを、どの形式で返すか、費用はいくらかを確認します。設定情報や帳票定義を受け取れるかも、あわせて確かめます。
API連携では、データの正本、更新の頻度、重複防止キー、再送の方法を決めます。障害時には、どこまでを誰が受け持つかも決めておきます。複数園化や施設追加、制度改正、決済変更も、契約前に想定します。
よくある質問（FAQ）
導入を検討する園長や法人本部、事務担当者から寄せられやすい質問を取り上げます。
費用や機能は、自園の料金ルールと運用体制に当てはめて判断します。
保育料管理だけならスクラッチ開発が必要ですか？
1園で標準的な保育料、延長、実費、請求、口座振替を扱う場合は、スクラッチ開発に頼らなくても、SaaSやパッケージ設定で対応できる可能性があります。
自治体独自制度、本部会計、複数法人統合、既存基幹との深い連携など、標準機能で足りない部分が多い場合に、個別開発やハイブリッドを検討します。
保育料管理システムに補助金は使えますか？
使える可能性はありますが、対象や募集時期は年度や自治体によって異なります。保育所等ICT化推進等事業のように、補助基準額が示される年度もあります。
契約・支払いの時期、対象機能、端末や導入支援、補助率、上限は、自治体へ確認します。不採択になっても運用できる予算と契約条件にしておくことが大切です。
Excelや紙の請求データを移行できますか？
移行できる場合は多いものの、形式や対象年数、園児・世帯・兄弟の名寄せ、未収残高、料金マスタの変換が課題になります。
現役園児、在籍履歴、契約、請求、入金、未収に対象を分け、旧帳票との照合条件を決めます。個人情報の受け渡しと廃棄の方法を定めたうえで、件数と代表ケースの請求額を確認します。
導入期間はどのくらい見込めばよいですか？
SaaS設定と移行だけであれば1〜3か月、帳票やCSV連携を加える場合は3〜6か月が目安です。
複数園や、会計・自治体・決済との連携を含む個別開発は、6〜12か月程度です。ただし、これは一般的な工程の初期目安で、要件の確定、園のデータ準備、テストへの参加、補助金の時期によって変わります。
希望の稼働月から逆算し、要件整理と移行準備の期間を確保してください。
まとめ
開発では、機能を増やす前に、料金ルール、例外、請求承認の内容を先に整理します。入金消込、未収対応、制度改正の担当も決めておきます。6段階の成果物と完了条件も、あわせて確認します。
料金ルールと例外処理の一覧化
施設種別ごとに、無償化と実費、延長・預かり・一時利用を分けて整理します。兄弟条件、減免、日割り、返金も、同じテストケースで確かめられる形にします。
費用は、クラウド、設定・連携、個別開発に分けて捉えます。月額に加えて、移行、決済、端末、保守、制度改正対応も含めた3年TCOで比べます。
最初の一歩は現場の請求業務の洗い出し
相談の前に準備しておくと、話を具体的に進めやすくなります。
- 集める資料：請求書、料金表、登降園実績、入金結果、未収一覧、自治体様式
- 作るケース：通常の請求と例外時の請求の整理
現場、本部経理、園長、情報システム担当が資料を見ながら、残す業務、変える業務、システムに任せる業務を決めます。そうすると、見積もりの精度と定着率が高まります。
その先に目指すのは、保育士と保護者の負担を減らし、園が請求の根拠を説明できる仕組みです。
▼全体ガイドの記事
・保育園・幼稚園向け保育料管理システム開発の完全ガイド
▼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を創業。