自治体向け子育て支援システム開発の進め方/やり方/流れや方法/手法/工程/手順

自治体向け子育て支援システムの開発は、要件整理と選定から定着までの六段階で進みます。途中では、設計・開発、テスト、稼働を順に行います。

対象業務の整理から稼働後の定着まで、段階ごとに何を決めるかを押さえることが、実務に根付く仕組みへの近道です。全体像は完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・自治体向け子育て支援システム開発の完全ガイド

自治体向け子育て支援システム開発の全体像

基幹、住民向けフロント、現場の三層で示した自治体向け子育て支援システムの対象範囲
役割ごとの境界がシステム全体の分担を形づくります。

自治体向け子育て支援システムは、行政内部の基幹業務、住民向けサービス、現場や相談支援の仕組みを組み合わせた総称です。そこで、対象レイヤーと業務の境界を先に決めておくと、機能の重複調達や後からの連携追加を防げます。

三つのレイヤーで見る対象範囲

住民記録や税、児童手当などの業務と連携させる情報には、世帯や児童、保護者が含まれます。きょうだいや所得、住所、在籍情報も、連携の対象です。各データの正本をどのシステムが持つかは、先に決めておきます。

対象範囲は、役割の異なる次の三つのレイヤーに分けて整理します。

  • 基幹:教育・保育給付認定、利用調整、保育料・利用者負担額、施設等利用給付、給付費、徴収、帳票、監査、国・都道府県への報告の処理
  • 住民向けフロント:制度検索、通知、空き情報、電子申請、状況照会、予約の提供
  • 現場:相談受付、アセスメント、サポートプラン、ケース記録、施設給付・監査、放課後児童クラブや地域子育て支援拠点の管理

三つを一つの画面にまとめなくても構いません。その分、二重入力を残さない連携の設計が欠かせません。

標準化と住民サービスの一体的な検討

標準仕様への適合と住民向け制度情報の運用は、別々に進めず合わせて整理します。

  • 標準仕様:RFPに対象版・機能・帳票と独自差分を明記
  • 住民サービス:制度情報を構造化データにし、必要な時期に配信
  • 運用:制度マスタの更新担当と公開承認手順の決定

こども家庭庁の「標準仕様書(子ども・子育て支援)」(2026年)では、第2.0版が2026年1月30日に公開されました。この版は、機能要件に加えて業務フローと帳票要件を定めています。さらに、印字項目や帳票レイアウトも定めています。

また、アプリ事業者向けのAPI連携は2025年11月に始まりました。2026年3月時点では、未就学児向けを中心に124種類の制度類型が対象になっています(出典: デジタル庁「子育て支援制度レジストリ」、2026年)。

ポイント

迷ったときは、どの層がどのデータの正本を持つかで境界を判断します。そうすると、機能の重複や二重入力を残しにくくなります。

自治体向け子育て支援システムの進め方

開発は、要件整理と選定から定着までの六段階で進みます。各段階で決めることは、次の見出しから順に説明します。各段階の完了条件を文書に残し、未確定の事項を次の工程へ持ち越さないようにします。そうすることで、年度切替を含む案件でも品質が安定しやすくなります。

1. 要件整理による現行業務と例外処理の見える化

担当課だけでなく、窓口や施設、委託先にも同じ業務を説明してもらいます。その過程で、紙台帳やExcel、電話などで補っている作業が見つかります。さらに、きょうだい同園や転園などの例外や、DV等の支援措置対象者は、通常のフローと分けて記録します。

  • 業務フロー:申請から審査、認定、利用、給付・徴収、報告までを一覧にする
  • 関係者:窓口、施設、会計、情報政策、委託先、相談員からの業務の確認
  • 例外処理:転園、減免、年度途中変更、支援措置対象者などを通常フローと分けた記録
  • 要件と標準:対象・連携・保存等の整理と、MUST・SHOULD・独自差分の管理

要件表には、対象年度や利用者区分、データの正本を記録します。連携頻度と帳票の出力先、決裁者、保存期間も、同じ表に残します。

障害が起きたときの代替手順も残しておきます。標準仕様と比べるときには、独自機能を追加する理由と、廃止できる業務も明らかにします。

「便利そうな機能」を先に並べると、実際の課題から離れて費用が膨らみやすくなります。

2. 選定での標準適合と連携責任の比較

候補方式は、標準準拠パッケージ、クラウドやLGWAN-ASP、自庁導入です。加えて、住民ポータルの追加開発やスクラッチ開発も候補になります。

  • 構成:基幹パッケージに独自の利用調整・相談・情報発信をAPIで追加
  • 適合性:実データに近いシナリオで標準機能の可否の確認
  • 提案条件:標準仕様第2.0版への対応、連携責任、API・CSV、移行範囲
  • 運用条件:クラウド等の実績、制度改正費、障害時の連絡体制

提案依頼書には、標準仕様第2.0版への対応とデータ・連携要件を記載します。あわせて、住基・税・児童手当・福祉・マイナポータルとの責任分界も書き込みます。

基幹をすべて独自開発するより、この構成のほうが制度改正への追随やベンダー変更を比較的しやすい傾向があります。

提案の条件には、APIまたはCSVの仕様、ガバメントクラウドやLGWANでの運用実績も含めます。さらに、データ移行の範囲や制度改正対応の料金、障害時の連絡体制も含めます。

標準機能が実務を処理できるかは、デモだけでなく、実データに近いシナリオで確認します。そのため、各社には、同じ五つのシナリオを実演してもらいます。

内容は、新規申請、きょうだいの転園、年度途中の減免です。そのほかに、施設給付の差し戻しと支援措置対象者の閲覧制御も含めます。

3. 設計・開発でのデータと権限の確定

画面を作る前に、データモデルと連携、権限を確定します。帳票と年度更新、ログ、バックアップも、同じ段階で決めておきます。

  • 識別子:児童、保護者、世帯、施設、申請、認定、在籍、給付、徴収、相談を整理し、同一人物やきょうだいを結ぶキーの決定
  • データ連携:住所・所得の扱いが異なる場合の同期時期と、不一致時の修正担当の明確化
  • 権限:課・職種・業務・施設・機微性ごとの最小権限の設定
  • 監査・開発:ログを残し、機微情報は匿名化またはマスキング

権限は、閲覧や登録、承認に分けて設定します。帳票・CSV出力と設定変更も、別々に管理します。

操作、閲覧、出力のログは、監査できる形で残します。特に、マイナンバーや支援措置対象者の情報は、テスト環境に持ち込まず、匿名化またはマスキングします。

設計の対象には、受託事業者のアカウントや再委託先の管理、退職者の停止、緊急時の特権IDも含めます。

4. テストにおける年度替わりと例外の重視

テストは、単体と連携、総合の順に進めます。そのあとに、移行と性能、セキュリティ、受入を計画します。

  • 例外シナリオ:所得遅延、差し戻し、転退園、きょうだい同園、請求訂正
  • 年度・帳票:年度をまたぐ認定変更と通知再発行、帳票要件の検証
  • 受入担当:審査・窓口、施設、会計の実務担当者が参加
  • 判定と稼働:業務指標を記録し、重大不具合等があれば判定を保留

正常な新規申請だけでなく、所得情報の遅延や申請の差し戻し、きょうだい同園希望を試します。

国・都道府県向け帳票は、印字項目とレイアウト、集計値を確認します。あわせて、出力権限と再出力履歴も確認します。

判定指標は、処理時間や差し戻し件数、帳票確認時間です。さらに、二重入力の有無と誤操作からの復旧時間も含めます。判定は、「動いた」ことに加えて、これらの指標で行います。

重大な不具合が残っている場合や、移行データの件数が合わない場合、権限設定が未確認のままの場合は、稼働判定を先送りできる基準を契約と計画書に入れます。

5. 稼働での移行・年度切替・代替運用の管理

本番稼働の前に、対象データの抽出と項目変換、欠損確認を行います。そのうえで、重複排除や移行、照合、承認を複数回繰り返します。

移行リハーサルでは、所要時間とエラーを測り、切り戻し条件を決めます。

  • 移行:抽出から照合・承認までを複数回行い、切り戻し条件の決定
  • 年度切替:在籍、認定、施設、徴収、未処理申請、通知履歴の凍結時期の設定
  • 代替運用:問い合わせ先、障害連絡、手作業の帳票、復旧後の再入力の準備

年度末に在籍や認定、施設の情報を凍結する時期は、業務カレンダーに記載します。旧システムをいつ参照専用にするかも、同じカレンダーに入れます。

こども家庭庁の2026年度資料も、自治体・施設向けのアカウント発行と基本情報登録を、運用前の作業として挙げています。

説明会の実施と、利用頻度の高い月次請求業務の確認も挙げられています(出典: こども家庭庁「保育業務施設管理プラットフォーム・保活情報連携基盤」、2026年)。

施設を利用者に含む案件では、自治体職員だけのリハーサルでは足りません。

6. 定着でのKPIと制度改正の運用

窓口と審査、施設、管理者では、使う機能がそれぞれ異なります。そのため、稼働後の研修は一度で終えず、実際のケースで必要な操作を繰り返します。

  • 研修・支援:役割別研修、マニュアル、FAQ、問い合わせ分類、月次改善会議
  • 引き継ぎ:異動後の担当者向けに動画と手順書を用意
  • 効果測定:問い合わせ、審査、二重入力、帳票作成、オンライン申請の測定
  • 制度改正:変更点、影響するマスタ・帳票・テストケース、費用、リリース日を変更管理表に記録

KPIには、窓口・電話の問い合わせ件数、審査時間、二重入力件数を置きます。帳票作成時間やオンライン申請率、施設からの差し戻し率も含めます。

このほか、制度情報の到達率と重大インシデント件数も測ります。導入前と比べて、1か月後、3か月後、6か月後の変化を比較します。

ポイント

迷ったときは、各段階の完了条件を文書にし、決まっていない事項を次の段階に持ち越さないかで判断します。年度切替を含む案件では、この判断が品質の安定につながります。

自治体向け子育て支援システムの費用相場とコストの内訳

5つのシステム構成について、本文記載の推定費用レンジを横棒で比較した図
構成によって見積もりの幅に大きな差が生まれます。

費用は、人口や施設数、対象業務で変わります。さらに、既存ベンダーや移行履歴、帳票によっても違いが出ます。連携数や標準化対応も費用を左右するため、製品の定価を一つの数字で示すのは難しい市場です。

次に示すのは、公開契約額とリサーチノートから整理した推定レンジです。全国共通の相場や、どの自治体にも当てはまる固定価格ではありません。

構成別の推定レンジの幅(500万円〜1億円超)

構成ごとの費用と期間は、次の推定レンジです。連携や帳票確認、職員研修を含めると、パッケージ導入費は上限側に寄りやすくなります。

  • 標準準拠パッケージの設定・小規模移行:500万〜1,500万円程度、4〜9か月
  • 中規模基幹刷新:1,000万〜3,000万円程度、9〜18か月
  • 住民ポータル・アプリ:500万〜2,000万円程度、4〜10か月
  • 相談・ケース管理の独自構築:1,000万〜3,000万円超、9〜18か月程度
  • 基幹から住民アプリまでフルスクラッチ:3,000万〜1億円超、18〜30か月

住民向けポータルやアプリの新規開発には、制度検索と通知、アカウントを含みます。さらに、電子申請API、管理画面、アクセシビリティも含みます。

相談・ケース管理を独自構築する場合は、機微情報の権限、監査、関係機関連携が加わります。

中規模基幹の費用は、データ量や広域入所によって、さらに増える場合があります。独自の利用調整や施設数も、増加の要因になります。

公開契約額の工程ごとの予算検討への活用

公開契約額の例では、同じ移行関連の業務でも金額に差があります。

比べるときは、人口や対象業務、データ量をそろえる必要があります。抽出方法やテストの範囲も、そろえずに比べてはいけません(出典: 各自治体の2025年度契約公表資料)。

  • 東京都北区:子ども・子育て支援システム標準化関連業務は1,427万8,000円
  • 習志野市:データ抽出プログラム作成業務は1,669万5,250円
  • 堺市:標準化移行データ抽出等業務は352万8,800円

制度改正とマスタ更新、帳票修正、試験とリリースだけでも、数百万円規模になり得ます(出典: 札幌市「子ども未来局子育て支援部の契約結果」、2026年)。

札幌市が公表した2026年の給付費支弁台帳の制度改正対応業務は、277万6,400円でした。

初期費用とは別に、年間保守は初期開発費の15〜20%程度を仮置きします。保守の範囲については、制度改正や問い合わせ、監視を確認します。さらに、バックアップと脆弱性対応も含まれるかを見ます。

判断材料としての3〜5年TCO

3〜5年TCOでは、導入や運用の費用と、環境ごとに異なる継続費用を含めて比べます。

  • 導入:要件定義、設定・開発、連携、抽出・クレンジング、移行、帳票、テスト
  • 継続:研修、稼働支援、クラウド・ネットワーク、ライセンス、保守、制度改正
  • 追加・終了:追加施設、解約時のデータ返却
  • 環境別費用:機器更新や閉域接続、監視、災害対策、責任分界を確認

オンプレミスでは、機器更新やバックアップ、災害対策を見積もります。脆弱性対応も、見積もりに入れます。

クラウドでは、利用料と閉域接続、監視を確認します。障害時の責任分界も、あわせて見ておきます。

「データ移行一式」とだけ書かれた見積もりでは、作業の範囲が見えにくくなります。まず、抽出や変換、エラー修正が含まれるかを確かめます。照合やリハーサル、本番移行を含むかも、作業範囲の項目で確認します。

  • 見積区分:初期・移行・月額または年額・標準保守・制度改正
  • 追加項目:追加開発、教育、オプションを分けて記載
  • 作業範囲:抽出、変換、修正、照合、リハーサル、本番移行を明示

作業単位と成果物、回数と前提条件が分かれている見積ほど、後からの追加請求を抑えやすくなります。

ポイント

見積もりを比べるときは、初期費用だけでなく、3〜5年の総額と作業範囲がそろっているかで判断します。そろっていない見積もりは、後からの追加請求が膨らみやすくなります。

見積もりを取る際のポイント

見積もりの前提として提示する業務・システム、移行・日程、導入条件、未確定事項の4項目
条件をそろえると各社の提案を同じ土台で比べられます。

見積もりの精度は、営業資料より発注側が整理した前提条件で決まります。現行業務や対象範囲、データに加えて、連携や帳票、セキュリティも同じ形式で提示します。

移行時期や職員数、施設数をそろえたうえで、比べる対象は機能数よりも、業務完了までの総工数です。

要件とデータの同じ粒度での提示

RFPには、業務・利用者・権限の資料を、同じ粒度で用意します。既存システムや連携、帳票の資料も、そろえて用意します。

  • 業務・システム:業務フロー、対象業務、利用者・権限、既存構成、連携項目
  • 移行・日程:データ件数・保有年数、年度切替日、希望稼働日
  • 導入条件:帳票サンプル、研修対象者、非機能要件を提示
  • 未確定事項:「未確認」と示し、調査工程や追加費用条件を明記

件数が不明な場合は、「未確認」と明示します。そのうえで、調査を見積もりに含めるか、発注前の調査工程として分けます。

住基・税・児童手当・福祉との連携と、マイナポータル申請も対象です。API・CSVやアクセシビリティも、見積もりの対象に入れます。

バックアップや復旧目標、監査ログ、データ返却も確認します。独自の利用調整や減免・加算、広域入所も対象です。きょうだい情報、通知・帳票も、あわせて対象に含めます。

未決定の項目は、仮定条件や追加費用の発生条件、決定期限を見積書に記載してもらいます。

複数社の価格とシナリオによる比較

得意分野の異なる事業者を候補に含めます。対象は、基幹や施設給付・監査、住民向けアプリ、相談・ケース管理などの分野です。

  • 実現方法:同じシナリオで標準機能、設定、追加開発、手作業、将来対応を比較
  • 提案条件:追加費用、納期、担当体制、実績、保守条件を確認
  • 評価軸の例:標準対応25点、業務適合20点、移行・連携20点
  • 継続性と費用:セキュリティ・運用継続15点、導入支援・定着10点、3〜5年TCO10点

配点は、自治体の優先順位に合わせて決めます。なお、点数配分に正解はありません。

価格だけで評価が逆転しないよう、先に仕組みを決めておくと、提案書の見栄えに判断が引っ張られにくくなります。

移行・個人情報・制度改正のリスクの契約への反映

開発の遅れよりも、誤った認定や給付、徴収が住民や施設に及ぼすリスクを重く見ます。通知や閲覧権限の誤りも、リスクとして扱います。個人情報保護委員会の行政機関等向けガイドラインを踏まえます。

  • 情報管理:委託先・再委託先、アクセス権限、暗号化、操作ログを要件化
  • 保護・復旧:バックアップや脆弱性、事故報告、データ削除・返却の取り決め
  • 契約・終了:成果物、検収、障害対応、変更、制度改正費、データ形式を明記
  • 引き継ぎ:標準形式の出力、仕様文書、業務ルールや設定値の保有を確認

契約では、障害の重要度と応答時間を明確にします。切り戻しや仕様変更の手続きも、取り決めておきます。また、第三者製品の更新やサービス終了の際は、データ形式も定めておきます。

APIや連携仕様の文書を自治体が保有できることや、業務ルールと設定値を引き継げることも、ベンダーロックイン対策になります。

ポイント

提案を比べるときは、同じ前提と同じシナリオで、業務の完了までに必要な総工数を基準にすると迷いにくくなります。

よくある質問

発注前に特に相談されやすい質問を取り上げます。費用や期間は対象範囲で変わります。前提をそろえておくと、ベンダーの回答精度を高められます。

標準仕様に対応していれば自治体独自の業務も処理できますか?

標準仕様への対応だけで、すべての自治体独自ルールを自動処理できるとは限りません。

利用調整や減免、地方独自加算の差分を洗い出します。帳票や広域入所の差分も含めて洗い出します。そのうえで、標準機能か設定で対応できるか、追加開発か運用変更が必要かを確認します。

自治体向け子育て支援システムの導入期間はどのくらいですか?

標準準拠パッケージの設定と小規模移行なら4〜9か月、中規模自治体の基幹刷新なら9〜18か月です。基幹から住民アプリまでのフルスクラッチなら18〜30か月程度が推定の目安です。

調達やデータ抽出、年度切替を含むかどうかで、期間は変わります。施設・住民の受入テストを含むかも、期間に影響します。加えて、自治体側の意思決定期間も計画に入れます。

ガバメントクラウドやLGWANで動くシステムを選ぶべきですか?

標準準拠の基幹業務では、ガバメントクラウドやLGWAN-ASPを含めて比較する価値があります。ただし、クラウドであるという理由だけで決めるのは適切とはいえません。

利用料や閉域接続、可用性を評価します。バックアップや災害復旧、障害時の責任分界、施設・住民向けサービスとの接続も確認します。そのうえで、3〜5年の総額と運用体制で判断します。

AIで給付判定や相談対応を自動化できますか?

AIは、制度FAQの下書きや問い合わせ分類、文書検索の補助など、職員の確認を前提とする用途から始めるのが安全です。

給付の可否や要保護判定は、AIだけで決定しません。相談方針や支援措置対象者の扱いも、AIだけに任せません。根拠制度と判断者、承認履歴、訂正方法を記録できる業務設計にします。

まとめ

自治体向け子育て支援システムは、基幹、住民フロント、現場・相談の三層に分けて捉え、要件整理から定着までの六段階で進めます。

標準仕様だけでなく、独自の利用調整や減免、帳票も含めて検証します。年度更新や住基・税・福祉との連携、施設や相談員の実務も、一つの業務フローで確かめます。

六段階の完了条件の管理

まず現行業務と例外処理を洗い出し、標準仕様のMUST・SHOULDと自治体独自の部分を分けます。そのうえで、同じシナリオを使って複数社から提案を受けます。

受入試験と移行リハーサルを行ったうえで、稼働後は問い合わせや審査時間などのKPIで改善を続けます。オンライン申請率や差し戻し率も含めて、継続的に見直します。

見積もりの要点となる3〜5年TCOと移行条件

自治体のシステム構成と追加機能の範囲によって、初期費用の想定は大きく広がります。

  • パッケージ設定・小規模移行:500万〜1,500万円程度
  • 中規模基幹刷新:1,000万〜3,000万円程度
  • 住民サービス・相談支援の追加:500万〜3,000万円超
  • 全体の独自開発:3,000万〜1億円超

公開契約額は個別案件の参考値です。そのため、初期費用だけでなく、移行や保守、制度改正を含む3〜5年TCOで比べます。クラウドや研修、データ返却も、あわせて考えます。

現行業務と例外処理を洗い出し、同じシナリオで複数社から提案を受けます。導入後は、KPIで改善を続けます。

▼全体ガイドの記事
・自治体向け子育て支援システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

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