子育て支援システムの発注は、対象業務を切り分け、要件と責任分界を明確にしたうえで、見積を同じ条件で比べる順に進めると、導入後の行き違いを防げます。
流れとしては、発注形態を選び、RFPで要件を伝え、契約と費用を確認し、委託先を比べ、導入計画へと進みます。
▼全体ガイドの記事
・子育て支援システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
子育て支援システムの発注・外注で最初に決める全体像
子育て支援システムは、ひとつの製品だけを指す言葉ではありません。対象業務を切り分けずに相談すると、自治体向け基幹を探しているのに園向けSaaSを提案されるなど、行き違いが生じます。
自治体基幹・園向けICT・保護者接点の切り分け
子育て支援システムは、自治体の制度運用、園の日常業務、保護者への案内を支えます。そのため、3層それぞれの担当範囲を見極めておく必要があります。
- 自治体基幹：台帳、認定、施設・入所管理、保育料算定、給付費の請求・審査・支払、通知・統計帳票、国との連携
- 園向けICT：園児名簿、登降園、欠席連絡、電子連絡帳、午睡・健康観察、指導計画、保護者連絡、請求管理
- 保護者接点：制度・相談窓口の検索、利用申込、予約、助成申請、申請状況確認、プッシュ通知
自治体基幹が住民記録や税、福祉などと連携する場合は、情報政策部門も発注体制に加えます。さらに、3層を同時に外注する場合も、各データの正本を持つシステムを決めます。
発注目的と利用者の定義
発注の最初に、誰の、どの負担を、どの指標で減らすかを決めておきます。審査時間、園職員の二重入力、保護者の窓口来庁など、目的によって機能の優先順位は変わります。
特に、オンライン申請率だけを目標にすると、入力途中の離脱や申請後の紙による不備確認を見落とすことがあります。対象者は、利用する立場ごとに分けます。
- 自治体職員、園長、保育士
- 施設管理者、保護者
- 事業者、審査・支払担当
利用者ごとに、必要な権限や端末、通信環境を整理しておくと、委託先へ伝える要件が具体的になります。支援が必要な場面と代替手段も、あわせて書き出します。
発注形態の選び方とパッケージ・SaaS・スクラッチの違い
発注形態は、初期費用だけでなく、標準化、データ移行、5〜7年の総保有コストまで含めて比べます。自治体基幹と園の業務システムでは、適した方式が異なります。
自治体基幹の標準準拠パッケージ
自治体基幹では、標準仕様に沿うパッケージを中心にし、固有制度や住民向け機能を切り分けます。
- 標準機能：標準仕様に沿うパッケージが基本候補
- 機能区分：必須、オプション、自治体独自の追加機能の区別
- 住民向け機能：住民ポータルや連携基盤へ切り分けた標準外機能
こども家庭庁は、「子ども・子育て支援システム標準仕様書（第2.0版）」を2026年1月30日に公開しました。機能要件と帳票要件は、この仕様書で確認できます（出典：こども家庭庁、2026年）。
また、標準パッケージ本体に過剰なカスタマイズを加えない設計を、委託先に依頼します。相談予約、地域サービス検索、申請状況の見える化を外付けにすると、制度改正への対応を進めやすくなります。
園向けSaaSと保護者アプリの分割発注
園業務は既存SaaS、保護者向け機能は独自アプリに分けて、自治体基幹とは別に発注できます。
- 園向けSaaS：登降園、連絡帳、欠席連絡、請求、保護者通知の担当
- 基幹との連携：APIや標準データによる接続と、園児ID、施設ID、同意、更新責任者の明記
- 独自アプリ：制度情報、通知停止、端末変更、アクセシビリティ、多言語、問い合わせ、ストア審査まで含む範囲
デジタル庁の子育て支援制度レジストリは、2025年11月にアプリ事業者とのAPI連携を開始し、2026年1月には民間アプリの連携も始まりました（出典：デジタル庁、2026年）。
そのため、制度情報を重複して管理するか、レジストリを使うかを、RFPで確認しておきます。
スクラッチ開発は独自価値への限定
スクラッチ開発は、既製パッケージでは実現しにくい自治体独自の価値に適しています。たとえば、相談支援や予約、給付などが該当します。地域サービスや制度横断検索も、そうした例に含まれます。
認定や給付などの標準仕様の機能を一から作ると、制度改正のたびに検証と改修が必要になります。その結果、移行費や保守費も増えやすくなります。
「基幹は標準準拠パッケージ、住民接点は外付け、データ連携は共通API」という構成も選べます。見積では、初期費用に加えて、法改正や脆弱性対応、データ返却などを含む5〜7年の総額を求めます。終了時の移行支援も、そこに含めます。
RFPと要件整理の出発点となる業務・データ・連携
RFPは、現状業務と課題、必須条件を伝え、提案範囲や評価方法も示す文書です。共通条件が曖昧だと、各社の見積は前提も範囲も異なるため、価格を比べにくくなります。
現行業務の繁忙期と例外処理の洗い出し
入所から年度更新までの担当者の動きを追い、例外時に増える確認作業も洗い出します。
- 通常業務：入所申込、認定変更、退所、保育料算定、給付費請求、審査、通知、年度更新
- 例外・繁忙期：不備差し戻し、世帯変更、転園、DV等支援措置、制度改正、年度末の集中処理
- 実作業：紙の確認、電話照会、Excel集計、承認者の押印など、画面一覧では見えにくい負荷
業務フローには、入力者と確認者、決裁者を書き入れます。加えて、データの発生元と保存期間も記載します。帳票、連携先、処理時間も、忘れずに入れておきます。
保護者の入力を園が確認し、自治体が認定して別システムが請求に使う場合は、不備を検知する場所と修正の担当も決めておきます。
標準仕様とのFit＆Gapの整理
標準仕様第2.0版の要件を、現行機能と照合します。対応状況は次の区分で整理すると、提案を同じ基準で比べられます。
- 標準で対応：標準仕様の機能で実現
- 設定で対応：設定変更で実現
- 追加開発が必要：標準外の開発で実現
- 対象外：標準仕様の対象外として整理
- 要確認：対象範囲や対応可否の確認
独自事業は、標準機能の改修、外部サービス、連携処理に分けて考えます。独自要件を標準本体に埋め込むと、標準改定やベンダー変更のときに影響が広がります。そのため、標準部分を継続して更新できる構造を、RFPの条件にします。
RFPに入れる非機能・移行・運用の条件
個人情報を扱うシステムを安定して運用するため、性能や安全性、移行後の責任まで条件をそろえておきます。
- 性能・継続性：処理件数、同時接続数、稼働・応答時間、バックアップ、障害復旧
- セキュリティ：認証、権限、ログ、暗号化、脆弱性管理、監査、再委託
- 利用環境：データセンター、アクセシビリティ、多言語対応
- 移行：現行データの件数・期間、欠損・重複、クレンジング、リハーサル、年度切替、並行稼働
- 運用：研修、問い合わせ窓口、法改正対応、契約終了時の返却形式
子どもの氏名や住所、所得を扱う可能性があります。加えて、世帯の情報や、健康・発達、相談記録も扱うことがあります。
そのため、情報の重要度に応じてアクセス範囲を分けます。さらに、条件が曖昧なままだと、移行直前や稼働後に追加費用が発生します。
発注前に決める契約形態と責任分界
発注は工程ごとに分ける方法があり、調査や要件定義、設計・開発などが対象になります。成果物と判断点が明確な工程は請負、変化が多い工程は準委任や運用サービスとし、工程の性質に応じて契約を選ぶと管理しやすくなります。
請負・準委任・SaaS利用の工程別の使い分け
契約形態によって、検収の対象や確認事項は異なります。工程の性質に合わせて、次のとおり確認します。
- 請負：要件定義書、設計書、プログラム、テスト結果、移行計画書などの検収対象
- 準委任：会議体、課題管理、成果物、報告頻度の合意
- SaaS：利用料に含まれる機能、初期設定、データ移行、追加アカウント、API、サポート、障害対応、バックアップ、解約時のデータ出力の範囲
請負は、合意した成果物の完成を求める工程で使います。準委任は、協議しながら要件を詰める調査や伴走支援に適しています。ただし、準委任では作業時間の確保と目的の達成を分けて考えます。
SaaSは、月額または年額の利用料を支払う形態です。特に、開発委託と組み合わせる場合は、障害の一次窓口と原因調査の責任者を一つに決めます。
追加変更と制度改正の費用ルール
契約書では、標準仕様の改定や法改正と、自治体独自の制度変更、発注者都合の追加要望を分けて書きます。それぞれについて、費用の負担と見積の承認、納期、緊急対応の扱いを記載します。
変更票には、目的と影響範囲、画面や帳票、連携への影響を記録します。テスト範囲や費用も書き込みます。納期と承認者も、あわせて記録します。また、口頭での依頼は受け付けない運用にします。
変更が年度切替に集中しないよう、月次の変更審査と、制度改正前の臨時レビューを設定します。
移行・保守・障害対応の境界
移行、保守、障害対応の担当範囲は、契約前に工程ごとに決めておきます。
- データ移行：抽出、クレンジング、変換、検証、承認それぞれの担当者を示した工程表
- データ返却：契約終了時に、CSVなど再利用できる形式で返す条件
- 保守・障害対応：受付時間、重大度別の回答・復旧目標、停止、バックアップ、訓練、脆弱性対応、再委託、事故報告、ログ保管の取り決め
移行では、受託者が変換プログラムを作り、発注者がデータの正しさを確認し、旧システム側が抽出形式を用意する場合があります。また、バックアップでは保存世代数も確認します。
千葉市の標準準拠移行・運用保守の公告では、参加条件に情報セキュリティや品質管理が挙げられています。同種同規模の履行実績やプロジェクト管理者なども条件です（出典：千葉市の政府公共調達公告、2024年）。
子育て支援システムの費用相場と見積の内訳
費用は、人口や施設数、年間申請件数で変わります。連携数や移行データ量、標準仕様との差分も影響します。クラウド構成や契約期間も、費用を左右する要素です。
ここで示す金額は、全国一律の定価ではなく、公開調達や調査を基にした予算検討用の目安です。委託先には、同じ前提条件で内訳を求めます。園向けICTと自治体基幹では費用の幅が異なるため、分けて検討します。
園向けICTの月額数千円から数万円台の費用幅
園向けICTの費用は、利用園数や設備、連携範囲で変わります。次に挙げる目安と、調査結果を照らし合わせて検討します。
- 1園向け：初期設定費0〜30万円程度、利用料は月1〜5万円程度、導入期間2週間〜3か月
- 端末・Wi-Fi：別途で、園の規模や建物により10万〜100万円程度の整備費が発生する可能性
- 複数園：保護者アプリや請求連携を含む場合、初期50万〜500万円程度、月額10万〜100万円程度
- 調査結果：ICT導入園210園の月額利用料とWi-Fi整備費が参考になる
札幌市私立保育園連盟の2025年調査では、月額利用料「1万円〜2万円未満」が30％、「2万円〜3万円未満」が19％でした。また、保護者から徴収する園は5％で、Wi-Fi整備費は累計20万円未満が最多でした（出典：札幌市私立保育園連盟「令和6年度 保育園・認定こども園のICT化に関する調査報告書」、2025年）。
SaaSは、月額の利用料だけでなく、初期設定や端末も含めて比べます。研修や保護者サポートも、合算して比較します。
自治体の標準準拠移行の費用規模：数千万円から数億円
標準準拠パッケージ移行の費用と期間は、自治体の規模や連携範囲で異なります。
- 中小自治体：初期・移行費1,000万〜8,000万円程度、年額の運用保守500万〜3,000万円程度、期間9〜18か月
- 大規模自治体：初期・移行費5,000万〜3億円程度、年額2,000万〜1億円程度、期間18〜36か月
- 千葉市の公告事例：移行・運用保守業務の公開調達例として参照できる
- 大規模案件の条件：外部連携、独自機能、データ整備、並行稼働、ガバメントクラウド対応で範囲が広がる
千葉市の標準準拠システム移行・運用保守業務は、契約締結日から2030年12月31日までです。参考価格は、税込4億1,822万7,000円以内として公告されています（出典：千葉市の政府公共調達データベース、2024年）。
ただし、これは大都市の長期契約の個別事例で、自治体全体の相場を示すものではありません。移行費と長期保守費は、分けて考えます。
初期費用だけでなく5〜7年のTCOで見る総額
見積では、作業の項目ごとに費用を分けて求めます。導入時の作業は、要件定義から並行稼働まで多くの項目に分かれます。
- 導入時：要件定義、Fit＆Gap、設定、開発、連携、帳票、データクレンジング、移行、端末、テスト、研修、並行稼働
- 運用時：監視、法改正、障害対応、バックアップ、ライセンス、クラウド利用料
- 契約終了時：データ返却と移行にかかる費用
一方で、合計額だけの見積では、作業が別項目に隠れている可能性があります。5〜7年のTCOには、毎年の保守やクラウド費、制度改正対応を加えます。さらに、端末更新や追加アカウント、API利用料も含めます。
また、研修の追加回数や、監査・セキュリティ対応も、TCOに加えておきます。特に、独自改修の保守料やデータ返却費が高い構成では、初期費用が低くても、長期の総額が逆転する場合があります。
委託先の選定と見積比較で確認すべきポイント
委託先は、知名度や提示価格だけで決めず、標準仕様への適合や、同規模の自治体や同数の園での実績を確認します。移行・保守の体制、連携設計、現場定着の支援も、あわせて確かめます。
提案書とヒアリングで確かめ、実績については担当範囲と現在の保守担当も尋ねます。
標準化・移行・保守の経験
候補会社の経験は、標準適合やデータ移行、長期保守の観点から確かめます。
- 標準適合：第2.0版への適合状況、必須・オプション機能、標準外機能の外付け方針の資料
- 要件対応：データ要件・連携要件への対応資料
- 移行：リハーサル回数、エラー処理、年度切替、旧システムとの並行稼働
- 保守：制度改正の収集と反映、障害時の自治体・園・保護者への説明体制
主担当の代わりや担当交代、契約終了時の引き継ぎも確かめます。再委託先についても、あわせて確認します。
特に、長期の委託では、担当者の人数よりも、継続して支えられる体制かどうかを見ます。
同じWBSと前提条件による見積の比較
各社の見積条件をそろえたうえで、価格差が生じた作業と前提を追える形で比べます。
- 比較表：作業、成果物、数量、単価、工数、担当、納期、前提、除外事項、再委託、追加費用
- 移行費：抽出、変換、クレンジング、ツール、テスト・本番移行、検証、手戻り対応の区分
- 評価：技術点と価格点の分離、追加開発、現場支援、返却、法改正の費用
- デモ：共通シナリオによる処理時間、不備表示、権限変更、帳票、問い合わせ対応の比較
見積の項目がそろうと、価格差がどこから生じたかを追えます。
機能だけでなく定着と撤退条件を含む評価表
評価は、機能の適合だけでなく、操作性や運用、導入後の効果まで同じ基準で行います。
- 提案評価：機能適合、標準化、連携、セキュリティ、移行、操作性、アクセシビリティ、保守、費用、実績、プロジェクト管理、研修、問い合わせ対応
- 利用画面：職員画面の入力項目とエラー表示、保護者画面のスマートフォン、多言語、通信不安定時の入力
- 受付・審査：入力完了率、不備・差し戻し率、窓口来庁回数、審査時間の計測
- 運用効果：給付費請求の手作業時間、問い合わせ件数、園職員の記録時間を、導入前後で測る
- 見直し：KPI未達時に、設定、研修、運用、追加開発のどこで対応するかを定例会で決める
2026年時点の発注で確認したい標準化・API・データ連携
2026年の発注では、機能一覧に加えて、標準仕様の更新や自治体間のデータ要件を見据えます。さらに、保護者向けAPIや施設業務の電子化、要支援家庭のデータ連携も視野に入れます。また、新しいサービスを加える場合も、基幹データと責任分界を保ちます。
標準仕様とデータ要件の版の固定
RFPには、参照する標準仕様の版を明記し、要件もその版に合わせて示します。提案時に版が変わった場合の差分確認方法も、あらかじめ決めておきます。
標準準拠の証明として、適合状況や未対応項目、対応予定を資料で提出してもらいます。自治体独自の要件との関係も、あわせて示してもらいます。
制度改正にともなう帳票やデータ項目の変更に備え、設定変更で対応する範囲とプログラム改修が必要な範囲を分けます。そのうえで、更新を誰がいつどのテストで確認するか、運用設計に含めます。
制度情報レジストリとAPI連携の更新責任
制度情報を正確に届けるため、レジストリの更新担当と、アプリ側の連携条件を決めておきます。
- レジストリ：未就学児向け124種類が対象。自治体登録情報をAPIで提供する（出典：デジタル庁、2025年11月時点）
- 更新責任：登録・承認・更新部署を定める。情報が古いと保護者に誤った情報が届く（出典：デジタル庁、2025年11月時点の対象制度と2026年の運用情報）
- API条件：認証、取得頻度、キャッシュ、障害時表示、有効期限、リンク変更、通知判定の確認
- 非利用時：情報の出典、更新履歴、公開承認、誤情報の訂正手順の用意
アプリを外注する場合は、これらの連携条件をRFPに記載します。
子ども・家庭情報の連携と人による確認
子ども・家庭情報を連携するときは、データの管理と人による確認を、一体で設計します。
- データ管理：利用目的、法的根拠、対象、保存期間、権限、本人・保護者への説明、誤判定の訂正方法
- 人の確認：不一致や欠落による支援の遅れを防ぐための、職員による抽出候補の確認
- 安全対策：MFA、通信・保存時の暗号化、操作・閲覧ログ、権限棚卸し、バックアップ、脆弱性診断、再委託管理、事故報告
- 自動判定：AIや自動判定を使う場合も、給付や支援可否を機械だけで決めず、職員が根拠を確認し記録できる画面
RFPには、子ども・家庭情報の連携に必要な安全要件と運用方法を明記します。
発注後の進め方と失敗を防ぐ導入計画
委託先を決めた後は、要件定義を終えるだけでなく、現場で使える状態になるまでを計画します。自治体基幹の移行は9〜18か月、大規模な移行や連携は18〜36か月を想定することがあります。
ただし、期間はデータの品質や年度切替によって変わります。調達手続や研修の回数も、期間に影響します。
代表園や代表手続での先行検証
全施設を一斉に切り替える前に、代表園や複数の手続で、PoCや先行稼働を行います。検証する場面と指標は、あらかじめそろえておきます。
- 対象：規模や運用が異なる園、複数の申請、認定変更、給付費請求
- 指標：保護者の入力完了率、不備率、職員の記録時間、審査時間、問い合わせ件数
- 利用環境：小さなスマートフォン画面、通信不安定、外国語、支援者による代理入力
そのうえで、園職員には繁忙時間帯に操作してもらい、迷いや確認漏れ、紙へ戻る箇所を記録します。問題が見つかった場合は、追加開発の前に業務手順や入力項目を見直します。
移行リハーサルと並行稼働の工程
本番の前には、データの抽出から取込までを複数回行い、件数照合とサンプル確認で検証します。年度切替では、旧年度の履歴や新年度の認定・施設情報の整合を確認します。通知書や請求データ、統計の整合も、確認の対象にします。
また、移行に失敗した場合に旧システムへ戻せる期限と、その判断者を決めておきます。研修も本番直前の一度で終わらせず、対象者に合わせて分けます。
- 研修対象：管理者、現場職員、問い合わせ担当
- 用意するもの：マニュアル、短い操作動画、よくある質問、障害時の紙運用
- 稼働後：一定期間の問い合わせ窓口の強化と、ログや問い合わせをもとにした未利用機能や二重入力の削減
よくある質問
子育て支援システムの発注前には、対象範囲や費用、契約について質問が寄せられます。標準化や運用についての疑問も、少なくありません。
子育て支援システムの開発はパッケージとスクラッチのどちらがよいですか？
自治体基幹では、標準仕様への適合と制度改正への追従を優先し、標準準拠パッケージを中心にする方法が現実的です。一方で、独自の相談や予約、情報発信などは、外付け開発やSaaSで補うと、標準本体の保守負担を抑えやすくなります。
RFPにはどのような項目を入れるべきですか？
まず、現状業務と課題、対象範囲、標準仕様との差分を含めます。そのうえで、機能や帳票、データの要件を書き、連携の要件も加えます。
非機能やセキュリティ、移行の条件に加えて、研修や保守、終了時の返却条件も書きます。年間処理件数や施設数、既存データの状態も示すと、各社が同じ条件で見積を作れます。外部連携先や制度改正、追加変更のルールも、あわせて伝えます。
見積金額が会社ごとに大きく違うときはどう比較すればよいですか？
各社の見積は、機能や工数、移行対象を同じ様式に並べて比べます。連携や保守も同じ様式に入れ、制度改正への対応や除外事項も、価格差の前提として確認します。
初期費用だけでなく、5〜7年のTCOで比べます。データ返却や追加開発も、比較の対象にします。研修や障害対応も、同じ基準で確認します。
同じ業務シナリオのデモと、実績のヒアリングを組み合わせて判断します。
まとめ
発注前に決める3層と責任分界
自治体基幹、園向けICT、保護者接点を分け、標準仕様と独自要件の差分を整理します。
パッケージやSaaS、スクラッチなどを組み合わせる場合も、データの正本とAPIを明確にします。セキュリティや移行の扱い、保守や終了時の返却も決めておきます。
同じ条件の見積と現場検証による委託先の選定
見積と現場検証では、費用の総額と導入後の使いやすさを合わせて確認します。
- 費用比較：園向けSaaSは月額数千円〜数万円台、自治体移行は数千万円〜数億円規模。対象と期間で変わる
- 長期総額：公開事例をそのまま予算にしない、要件定義、移行、連携、テスト、研修、保守を含む5〜7年のTCOでの比較
- 現場検証：代表園や代表手続での使い勝手とKPIの確認、導入後の改善を支援できるかどうか
▼全体ガイドの記事
・子育て支援システム開発の完全ガイド
▼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を創業。