こども誰でも通園制度は、保護者の就労状況を問わず時間単位で保育を利用できる新しい仕組みです。対象となる市区町村が広がるほど、全国で共通して使える予約・データ・請求の基盤が欠かせなくなり、こども誰でも通園制度総合支援システムは予約管理・データ管理・請求書発行という3つの機能を備えてガバメントクラウド上に構築されています¹。この記事では制度の仕組みそのものよりも、システムを支える技術の側面に焦点を当て、保育の現場経験を持たない技術者がどこに関われるのかを整理します。予約システムや行政データの取り扱いに触れてきたエンジニアにとって、公共分野のリモート案件を考える手がかりになる内容です。

1. なぜいま保育DX・総合支援システムの案件が増えているのか

全国一律の運用を1つの基盤で支える狙い

こども誰でも通園制度は、就労要件を問わずに時間単位で保育を利用できる制度で、実施する市区町村が広がるほど、予約の受け付けや利用実績の管理を担う仕組みの重みが増していきます。市区町村ごとに独自の運用やExcel管理を積み上げると、複数の自治体で保育を提供する事業者ほど、自治体ごとに異なる操作を覚える負担が重くなります。

そこで市区町村ごとに仕組みを積み上げるよりも、全国で共通の基盤を1つ用意するほうが、事業者にとっても利用者にとっても扱いやすくなります。予約管理・データ管理・請求書発行という3つの機能を備えたこども誰でも通園制度総合支援システムは、こうした事情を踏まえてガバメントクラウド上に構築され、令和7年度からの運用開始が予定されています⁵。

制度の対象は保護者の就労状況を問わないため、これまで保育を利用してこなかった家庭からの申し込みも見込まれます。申し込みが集中する時期や、複数の市区町村をまたいで検討する家庭が増えるほど、システム側には安定したアクセス処理と、分かりやすい検索・予約の導線が求められるようになります。

システムづくりに求められる視点

全国の市区町村・事業者・利用者という立場の異なる関係者が、同じ基盤を共通で使う設計は、窓口業務のデジタル化だけにとどまりません。通信経路の分離やアクセス権限の設計、外部システムとの連携まで含めた全体設計が必要になり、公共分野の開発経験を積みたい技術者にとって、規模の大きい設計に関わる機会になります。

こうした全国規模の基盤づくりは、単一の自治体向けシステムの開発とは異なる考え方が必要です。利用が集中する時期のアクセス増加を見込んだ設計や、市区町村ごとに異なる運用ルールを吸収する柔軟な仕組みづくりは、行政システムに限らず大規模なサービスの開発に携わってきた技術者の経験が活きる部分です。

図の作成：Remogu編集部。制度の運用イメージを整理したもので、統計データではありません

2. 3つの機能で捉えるこども誰でも通園制度総合支援システム

予約管理とデータ管理が担う役割

予約管理は、利用者や事業者が全国の空き枠を検索し、予約を受け付ける機能です。市区町村をまたいで保育を利用する場面や、複数の事業者を比較検討する場面でも、共通の画面と共通の操作で完結できるように設計されています。

予約管理では、全国の空き枠をできるだけ最新の状態に保ち続ける必要があります。複数の事業者が同じ時間帯の枠を更新する場面や、申し込みが集中する時間帯でも予約の重複や取りこぼしが起きないようにする設計は、一般的な予約システムの開発で培われる考え方と共通しています。

データ管理は、利用者情報と利用実績を記録・管理する機能です。こどもの氏名や利用日といった情報に加えて、保育の現場では既往歴やアレルギーのような機微な情報も扱う場面があるため、同意にもとづく適切な取り扱いと、必要な範囲に限定したアクセス権限の設計が欠かせません。

データ管理では、利用者情報や利用実績を長期にわたって正確に保つ運用も欠かせません。市区町村の窓口担当者が確認しやすい形で情報を整理し、必要な項目だけを表示する画面設計や、変更履歴を追跡できる仕組みは、行政システムならではの要件として意識しておきたい部分です。

請求書発行が事業者の事務負担を軽くする

請求書発行は、事業者が利用実績にもとづいて請求書を作成し、市区町村へ提出する機能です。自治体ごとに書式や提出方法が異なる状態を避け、共通のフォーマットとデータ連携で処理できるようにすることで、事業者側の事務作業を軽くする狙いがあります。

請求書発行を1つの仕組みに統一することで、市区町村側は自治体ごとに異なる書式を読み解く手間を減らせます。事業者から届く請求データと利用実績データを突き合わせる処理を自動化しやすくなる点も、システム化によって得られる利点です。

3つの機能を一覧で比較する

予約管理・データ管理・請求書発行の3つの機能は、それぞれ利用する立場や扱うデータが異なります。誰が使い、システムが何を処理し、どんな技術領域と接点があるのかを整理すると、リモートで関わる際にどの工程で経験を活かせるかが見えやすくなります。以下の表で3つの機能を比較します。

機能	主に使う立場	システムが担う処理	関わりうる技術領域
予約管理	利用者・事業者	全国の空き枠の検索・予約の受け付け	予約システムの設計・検索処理
データ管理	市区町村	利用者情報・利用実績の記録と管理	データベース設計・個人情報の取り扱い
請求書発行	事業者→市区町村	利用実績にもとづく請求書の作成	請求処理の設計・書類のデータ連携

3つの機能は独立した仕組みではなく、予約の受け付けから利用実績の記録、請求書の作成までが一連の流れとしてつながっている点が特徴です。どこか1つの工程だけを切り出して考えるのではなく、前後の工程とのデータの受け渡しまで意識した設計が求められます。1つの工程で扱ったデータの形式が、次の工程でそのまま活用できるかどうかも、設計段階で確かめておきたい観点です。

図の作成：Remogu編集部。システムが備える機能の流れを整理したもので、統計データではありません

3. 安全に支える基盤

通信経路を利用者・事業者と行政で分ける設計

こども誰でも通園制度総合支援システムは、ガバメントクラウド上に構築され、利用者と事業者はインターネット経由、市区町村・都道府県・こども家庭庁はLGWAN経由でアクセスする設計になっています²。同じシステムでも、接続する経路を立場ごとに分けることで、行政側のネットワークと一般のインターネットを混在させない構成をとっています。

接続経路を分ける設計に加えて、誰がいつどの情報にアクセスしたかを記録する仕組みも、公共システムでは重視されます。操作の履歴を残す設計や、権限に応じて表示できる項目を制御する仕組みは、行政システムに限らず個人情報を扱うプロダクト全般で共通して求められる考え方です。

個人情報を市区町村が管理する設計

利用者に関する個人情報は市区町村が管理し、都道府県やこども家庭庁は個人情報を閲覧できない設計になっています³。こどもに関する情報は、既往歴やアレルギーのように機微な内容を含む場合があり、管理する主体を明確にし、必要のない範囲まで情報が広がらないようにする設計は、個人情報保護の観点で重要な意味を持ちます。

個人情報を市区町村が一元的に管理する設計は、利用者の同意にもとづいて情報を預かるという前提があってこそ成り立ちます。同意の取得状況を記録し、目的外の利用が起きないようにする仕組みづくりも、こうしたシステムを支える重要な要素です。

個人情報の保持期間や、利用者から情報の削除を求められた場合の対応など、運用開始後に発生する実務も設計段階から想定しておく必要があります。長期的な運用を見据えた設計は、行政システムに限らず情報システム全般で重視される観点です。

リモートで開発・運用に関わる技術者にとっても、誰がどの範囲の情報にアクセスできるかを設計段階から意識する姿勢は、行政システムに限らず個人情報を扱うプロダクト全般で求められる視点です。

接続経路と個人情報の扱いを比較する

こども誰でも通園制度総合支援システムは、立場によって接続する経路と、個人情報にアクセスできる範囲が異なります。利用者・事業者と、市区町村・都道府県・こども家庭庁のそれぞれについて、接続経路と個人情報の扱いを表にまとめました。

主体	接続経路	個人情報の扱い
利用者・事業者	インターネット経由	自身に関する情報の入力・閲覧
市区町村	LGWAN経由	管理する立場として登録・閲覧が可能
都道府県	LGWAN経由	個人情報を閲覧できない設計
こども家庭庁	LGWAN経由	個人情報を閲覧できない設計

図の作成：Remogu編集部。通信経路とアクセス権限の設計を整理したもので、統計データではありません

4. 他システムとの連携

ここdeサーチと連携して事業者情報を扱う

こども誰でも通園制度総合支援システムは、事業者情報についてここdeサーチとの連携を予定しています⁴。事業者の情報を複数のシステムでそれぞれ入力し直す状態を避け、既存の情報源と連携することで、事業者側の入力の手間を減らす狙いがあります。

外部の情報源と連携する場合、双方の情報が更新されるタイミングにずれが生じることがあります。どちらの情報を正として扱うか、更新が反映されるまでの間どう表示するかといった整合性の設計は、複数のシステムをまたぐ開発で共通して向き合う論点です。

マイナポータルや窓口から利用申請につなぐ

利用申請は、市区町村の窓口に加えて、マイナポータルのぴったりサービス等を想定しています⁶。オンラインでの申請に慣れている利用者と、窓口での申請を希望する利用者の双方に対応できるよう、複数の申請経路を用意する設計です。

マイナポータルのような本人確認の仕組みと連携する場合、申請者の情報を正しく突き合わせる処理や、途中で入力を中断した申請者への対応など、利用者目線での設計も求められます。窓口とオンラインの両方の実務に触れてきた技術者にとって、実務感覚を活かせる場面です。

外部システムとの連携は、単純にデータをやり取りするだけでなく、更新のタイミングのずれや、片方のシステムにしかない項目の扱いなど、実務で調整する論点が生まれやすい領域です。API設計やデータ連携の経験を持つ技術者にとって、腕の見せどころになる部分といえます。

連携する項目が増えるほど、どの項目をどちらのシステムで正として管理するかを事前に整理しておく必要があります。データの持ち方を早い段階で整理しておく考え方は、後から連携先が増えたときの改修も進めやすくします。

連携先ごとの役割を比較する

こども誰でも通園制度総合支援システムは、複数の外部システムや申請経路とつながることで成り立っています。ここdeサーチ・マイナポータル・市区町村窓口について、それぞれの役割と技術的な接点を表にまとめました。

連携先	役割	技術的な接点
ここdeサーチ	保育事業者の情報を検索・公開する仕組み	事業者情報のデータ連携
マイナポータル（ぴったりサービス）	オンラインでの行政手続きの受け付け	利用申請のオンライン連携
市区町村窓口	従来型の窓口での申請受け付け	窓口システムとのデータ連携

図の作成：Remogu編集部。外部システムとの連携イメージを整理したもので、統計データではありません

5. リモート・フリーランス案件としてどう関わるか

保育の現場経験がなくても関われる技術領域

「保育の現場を知らないと関われないのでは」と感じる技術者は一定数います。しかし、ここまで見てきた予約管理・データ管理・請求書発行・外部システム連携は、いずれも予約システムの設計、データベース設計、請求処理、API連携といった、業種を問わず積み上げられる技術領域です。

保育の現場経験を持たない技術者でも、行政システムや個人情報を扱うプロダクトに携わった経験があれば、その積み上げてきたスキルをそのまま活かせる場面があります。むしろ求められるのは保育の専門知識よりも、複数の立場が使う基盤をどう安全に設計するかという視点です。

実際の案件では、要件定義の一部を担う場合もあれば、既存の基盤に対する機能追加や、データ移行・連携部分の実装を担う場合もあります。関わり方の幅が広いため、これまでの経験を活かせる工程を見つけやすい領域ともいえます。

案件を見極めるときの視点

案件を選ぶときは、募集内容が予約システムの開発なのか、データ設計なのか、それとも請求や外部連携の実装なのかを確認しましょう。工程によって求められる経験は異なり、これまで積み上げてきた分析や設計の経験を、どの工程で活かせるかを照らし合わせることが、参画後のミスマッチを防ぎます。

案件を見極める際は、技術要件だけでなく、クライアントとの打ち合わせの頻度や、資料のやり取りの方法も確認しておくと、参画後の進め方をイメージしやすくなります。行政が関わる案件では、要件の確認に時間をかける場面もあるため、余裕を持ったスケジュール感で臨む姿勢も大切です。

働き方についても、Remoguで扱う案件の90%以上がフルリモート可能です⁷。行政や自治体が関わる案件と聞くと現地常駐を思い浮かべがちですが、設計・実装・テストの多くはリモートで進めやすい領域です。ただし、関係者との調整のタイミングや案件の条件は案件によって異なるため、募集内容をそのつど確認する姿勢が欠かせません。

こうした公共分野のシステムに携わった経験は、行政や自治体が関わる別の案件を検討するときの実績にもなります。1つの案件で得た知見を、次の案件を選ぶときの判断材料として積み上げていく視点も持っておきましょう。

場所に縛られずに公共分野の設計に関わりたい、これまでのスキルを行政システムのような社会性の高い領域で活かしたいと感じているなら、まずは自分の経験に近い案件がどんな形で募集されているかを確認するところから始めてみましょう。

6. まとめ

こども誰でも通園制度総合支援システムは、予約管理・データ管理・請求書発行という3つの機能をガバメントクラウド上でまとめ、利用者・事業者と行政とで接続経路を分け、個人情報は市区町村が管理する設計で、令和7年度からの運用開始が予定されています。ここdeサーチやマイナポータルとの連携も見据えた、公共分野らしい規模の大きいシステムです。

制度の運用が全国に広がるほど、こうした基盤を安定して動かし続けるための開発・運用ニーズも積み重なっていきます。保育の専門知識よりも、予約・データ・請求・連携という技術領域の経験を軸に、この分野への関わり方を考えてみましょう。

保育の現場経験がなくても、予約システムの設計やデータベース設計、請求処理、API連携といったこれまで積み上げてきたスキルは、そのままこの領域で活かせます。まずは自分の経験に近い工程の案件を探し、条件を確認するところから始めてみましょう。

7. よくある質問

保育の専門知識がなくても関われますか

関われます。求められているのは保育の専門知識よりも、予約システムの設計やデータベース設計、個人情報を扱う際のアクセス権限の設計といった技術領域の経験です。保育の現場経験を持たない技術者でも、行政システムや個人情報を扱うプロダクトの経験があれば強みになります。資格や現場経験を問われる場面は少なく、募集内容で示された技術要件を満たしているかどうかが判断の軸になります。

どんなスキルが活きますか

予約システムの設計・実装、データベース設計、請求処理のようなバックエンド開発の経験に加えて、外部システムとの連携経験も活かせます。個人情報を扱う設計に慣れている技術者は、アクセス権限の分離といった観点でも強みになります。加えて、複数の関係者が同じ基盤を使う設計を扱った経験があれば、権限設計や画面設計の面でも強みとして評価されやすくなります。

予約システムやデータ設計の経験は活きますか

活きます。全国の空き枠を検索・予約する仕組みや、利用者情報・利用実績を記録するデータ設計は、他業種の予約システムや会員管理システムで積み上げてきた経験と重なる部分が多い領域です。特に、複数の拠点や店舗をまたぐ予約・在庫管理システムの経験は、全国規模の空き枠管理という点で親和性が高い領域です。

現場に行かずに関われますか

設計・実装・テストといった開発工程の多くはリモートで進めやすい領域です。ただし、関係者との調整のタイミングや案件ごとの条件は異なるため、募集内容を確認したうえで参画を検討しましょう。打ち合わせはオンライン会議やチャットツールで完結する場面が中心で、資料のやり取りもオンラインで進められる案件が一般的です。

案件はフルリモートでもできますか

Remoguで扱う案件の90%以上がフルリモート可能です⁷。保育DXや公共システムに関わる案件でも、この傾向は変わりません。気になる案件を見つけたら、まずは登録して自分の経験に合う条件を確認してみましょう。案件ごとに詳細な条件は異なるため、募集内容を確認したうえで、自分の稼働スタイルに合うかどうかを見極めましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 こども家庭庁「こども誰でも通園制度総合支援システムの概要」（2025年7月）
＊2 こども家庭庁「こども誰でも通園制度総合支援システムの概要」（2025年7月）
＊3 こども家庭庁「こども誰でも通園制度総合支援システムの概要」（2025年7月）
＊4 こども家庭庁「こども誰でも通園制度総合支援システムの概要」（2025年7月）
＊5 こども家庭庁「こども誰でも通園制度総合支援システムの概要」（2025年7月）
＊6 こども家庭庁「こども誰でも通園制度総合支援システムの概要」（2025年7月）
＊7 Remoguサイト公開情報（フルリモート可能案件の割合）