先に、要点をまとめます。
- こども誰でも通園制度が2026年4月から本格実施され、保育所・認定こども園には「就労要件のない一時的な利用者」を受け入れる新しい業務が加わりました
- 現場の負担が増えるのは保育そのものより、予約枠の調整・面談記録・利用実績の登録・請求という事務工程で、既存の在園児の管理と分断されやすい構造になっています
- 事務を仕組み化する場合は、在園児と一時利用児を同じ児童台帳の上で扱えるようにするのが起点で、そこに予約枠管理と記録の共有を積み上げるのが現実的な順序です
保育の現場では、2026年度から「こども誰でも通園制度（乳児等通園支援事業）」が全国の自治体で本格的に始まりました。保護者の就労の有無を問わず、0歳6か月から満3歳未満の未就園児を時間単位で預かる仕組みで、これまで保育所を利用できなかった家庭の受け皿として期待されています（制度の詳細はこども家庭庁「こども誰でも通園制度について」をご確認ください）。
一方で、施設側から聞こえてくるのは「子どもを見るのは慣れているが、そこにぶら下がる事務が読めない」という声です。試行的事業の段階でも、新しい利用者への対応によって保育士の事務作業が増えたという報告が上がっていました。園長・主任の立場からすると、限られた職員体制の中で新しい制度に対応しながら、既存の在園児の保育の質を落とさないことが至上命題になります。
この記事では、こども誰でも通園制度で保育施設に何が増えるのかを事務工程の単位で整理し、どこを仕組み化すれば負担を抑えられるのかを解説します。ひとつだけ、後半で必ず触れる注意点があります。それは「予約システムを入れれば解決する」という発想が、かえって現場の手間を増やしてしまう場合があるということです。この点は記事の中盤以降で詳しく説明します。
こども誰でも通園制度で保育施設の何が増えるのか？
増えるのは保育の時間だけではありません。予約枠の設定、利用前の面談、当日の受け入れ準備、利用実績の登録、給付費請求という一連の事務が、在園児の業務とは別ラインで発生します。
こども誰でも通園制度は、月一定時間を上限として、保護者が必要なときに時間単位で利用できる仕組みです。在園児のように毎日決まった時間に登園するわけではないため、施設側は「いつ・何人まで受け入れられるか」という空き枠を自分たちで設計し、公開する必要があります。
事業者が担う工程を分解すると、おおむね次のようになります。
- 空き枠の設定: 職員配置と在園児の状況を見ながら、受け入れ可能な日時・人数枠を決めて登録する
- 利用申し込みへの対応と面談: 初回利用前に保護者と面談し、子どもの発達状況・アレルギー・かかりつけ医・生活リズムなどを聞き取る
- 利用承認・調整: 申し込みが枠を超えた場合の調整、キャンセルへの対応
- 当日の受け入れ準備: 担当保育士への引き継ぎ、持ち物・食事・アレルギー情報の共有
- 利用実績の登録: 実際に何時から何時まで利用したかを記録し、システムに登録する
- 給付費請求: 登録した実績をもとに請求処理を行う
在園児については、連絡帳や指導計画の作成負担をどう減らすかという論点を保育園の連絡帳・指導計画をAIで時短する方法で整理しています。本記事はその外側にある、一時利用児の受け入れ事務が主題です。
在園児であれば、こうした情報はすでに児童票や連絡帳の中に蓄積されています。しかし一時的な利用児の場合、初回面談で得た情報が「面談シート」という一枚の紙に残るだけで、当日の担当保育士まで確実に届く保証がありません。園長が把握していても、その日にシフトに入っている保育士が知らない、という情報の断絶が起こりやすいのがこの制度の構造的な難しさです。
自園でどこまで受け入れるかを判断する前に、まず「この6工程のうち、いま誰がどうやってやることになるか」を書き出してみると、現実的な受け入れ枠の上限が見えてきます。
なぜ「一時利用児の情報」は現場に届きにくいのか？
在園児の情報は日々の保育の中で自然に更新されますが、一時利用児の情報は面談時の一度きりで、しかも保育の記録と別の場所に置かれるためです。
在園児の場合、アレルギーや発達の状況は、連絡帳・児童票・日々の申し送りを通じて何度も現場を往復します。担当が変わっても、記録を辿れば経緯が分かる状態が保たれています。
一方、こども誰でも通園制度の利用児は、月に数回、あるいは数か月ぶりに来るということも珍しくありません。面談で聞き取った内容は初回の時点では最新でも、次に来たときには離乳食の段階が進んでいたり、新しいアレルギーが判明していたりします。この更新をどこで拾い、どこに反映するかが決まっていないと、保育士は毎回「前回はどうだったか」を紙の束から探すことになります。担当者しか知らない情報が現場に滞留する構造は業種を問わず共通で、医療機関の例はクリニックの患者情報の属人化を解消する仕組みでも整理しています。
さらに厄介なのは、この情報が「事故につながりうる情報」だという点です。アレルギー対応や与薬の可否、体調の変化への注意点は、当日の担当者に確実に伝わっていなければなりません。伝達が口頭と紙に依存していると、シフト交代のタイミングや急な欠員が発生したときに抜け落ちるリスクが高まります。
ここが、こども誰でも通園制度への対応を「予約の問題」ではなく「情報共有の問題」として捉えるべき理由です。自園で一時利用の受け入れを始めるなら、面談で得た情報がその日のシフトに入っている保育士の手元にどう届くのか、そこを先に決めておくと運用が安定します。
こども誰でも通園制度における一時利用児の情報が、面談シートから当日の担当保育士まで届かず分断される流れと、児童台帳を中心に据えて情報を集約した場合の流れを対比したBefore/After図解。Beforeでは面談シート・予約表・保育記録が別々に存在し担当者が探す状態、Afterでは児童IDを軸に面談情報・利用履歴・記録が一元化され当日の担当に自動で共有される状態を示している。
予約システムを入れるだけでは解決しないのはなぜか？
予約システムは「いつ何人来るか」を整えますが、「その子が誰で、何に気をつける必要があるか」を保育の現場に届けるのは別の仕組みだからです。ここが冒頭で触れた注意点です。
こども誰でも通園制度への対応として、まず予約システムの導入を検討する施設は多いと思います。空き枠の公開と申し込み受付を自動化できれば、電話対応の手間は確かに減ります。
ただ、予約システムが持っている情報は基本的に「日時・利用者名・利用時間」です。一方、保育の現場が当日必要とするのは「アレルギーの有無」「食事形態」「発達段階に応じた配慮」「保護者からの申し送り」といった、面談で得た子どもの情報です。この2つが別々のツールに分かれていると、次のような手間が新しく生まれます。
- 予約システムで確定した利用予定を見て、面談シートのファイルから該当児の情報を探して手元に用意する
- 当日の担当保育士に、口頭またはメモで情報を伝える
- 利用後の様子を保育記録に書き、次回のために面談シートを更新する（更新されないことも多い）
つまり、予約が自動化されても、予約情報と子どもの情報を人がつなぎ直す作業が残ります。しかも、この作業は毎回発生し、忙しい日ほど省略されやすい種類の作業です。
この構造を踏まえると、こども誰でも通園制度の事務負担を本当に軽くするには、予約と児童情報と保育記録を同じ基盤の上で扱う設計が必要になります。すでに予約システムを検討している段階なら、「そのシステムに面談情報と保育記録を持たせられるか」を確認しておくと、後から二重管理に陥るのを避けられます。
保育の事務をシステムで仕組み化する場合の費用感とステップは？
業務システムとして構築する場合、児童台帳と一時利用の予約・記録を中心にした構成で300万円前後、AIによる書類作成の補助まで含めると450万円前後が目安です。
保育施設が事務のデジタル化を検討する場合、既製の保育業務支援システムを契約する方法と、自園の運用に合わせて業務システムを構築する方法があります。既製システムは導入が早く、月額利用料も抑えられる一方、こども誰でも通園制度のように制度開始からまだ日が浅い業務では、自治体ごとに異なる運用ルールや自園独自の面談項目まで反映しきれないことがあります。
業務システムとして構築する場合の費用レンジは、機能範囲によって次のように分かれます。
- 児童台帳・一時利用の予約枠管理・利用実績記録を中心にした構成: 300万円前後。在園児と一時利用児を同じ台帳で扱い、予約から実績登録までを1つの流れにする範囲
- AIによる書類作成補助・保護者ポータルまで含めた構成: 450万円前後。指導計画や日誌のドラフト生成、保護者が予約状況や記録を確認できる画面などが加わる
- 園横断のダッシュボードや高度なAI分析まで含めた構成: 750万円前後。複数園を運営する法人で、園ごとの受け入れ状況や職員配置を横断的に見たい場合
保守運用費は月額10万円程度からが目安で、制度改正や自治体の運用変更に追従できる体制を確保しておくと安心です。
導入までの流れは、おおむね次のステップで進みます。
- 要件整理（2〜4週間）: 現在の面談シート・児童票・シフト表の実物を持ち寄り、どの情報がどこで発生し誰が使うかを洗い出す
- 基本設計（2〜4週間）: 児童台帳の項目、予約枠の考え方、記録の様式を設計する
- 開発・テスト（1〜2ヶ月）: 実際の面談情報を使って動作確認しながら調整する
- 運用開始・定着支援: 受け入れ枠の運用実態に合わせて画面や通知を微調整する
要件整理から公開まで最短1.5ヶ月程度で立ち上げることも可能です。一気に全業務をデジタル化しようとせず、まずは一時利用児の受け入れ管理という一点から始め、効果を確認してから在園児の記録に広げていく進め方が、職員の負担も少なく合意も得やすい順序です。
私たちなら保育施設の一時利用受け入れ基盤をこう設計する
ここまでの整理を踏まえ、こども誰でも通園制度への対応を実際にシステムとして形にするなら、という前提で設計の考え方を書き下ろします。
データ設計: 起点は児童台帳です。在園児と一時利用児を別々の名簿で持つのではなく、ひとつの児童マスタに「在園」「一時利用」という区分を持たせ、児童IDを軸に情報を紐づけます。児童IDには、面談で聞き取ったアレルギー情報・食事形態・かかりつけ医・発達段階のメモ・保護者連絡先を持たせ、そこに利用予約（日時・利用時間枠）、当日の保育記録、月ごとの利用実績時間を接続します。給付費請求のもとになる利用実績は、担当保育士が当日入力した登降園時刻からそのまま集計される形にし、事務担当者が月末に紙の出席簿を見ながら転記する工程をなくします。
情報の流れ: 保護者からの申し込みは予約枠に対して行われ、承認されると児童IDに紐づいた予約レコードが立ちます。翌日の受け入れ予定は、シフトに入る保育士の画面に「明日来る一時利用児」として自動で並び、名前をタップすればアレルギー・食事形態・前回の様子・保護者からの申し送りが1画面で確認できる状態にします。園長・主任は、枠の埋まり具合と職員配置を並べて見られるダッシュボードを持ち、受け入れ枠を増やせるか減らすべきかを判断します。職員配置そのものの組み立てについては、介護シフト作成をAIで自動化する方法で扱った考え方が保育の配置基準にも応用できます。利用後は担当保育士がその日の様子を記録し、それが次回の受け入れ時に「前回の様子」として同じ画面に表示されます。ここまでを一本の流れにすることで、面談シートを探して手元に用意する作業がなくなります。
AIの回答設計: 社内AIチャットは、児童台帳と保育記録のデータを根拠に回答します。たとえば主任が「明日の一時利用児で、アレルギー対応が必要な子はいますか」と尋ねると、AIは翌日の予約レコードと紐づく児童台帳のアレルギー項目を参照し、「明日は3名の一時利用予定があり、うち1名に卵アレルギーの記録があります。前回の利用時は代替食で対応しています」と、根拠となる児童台帳と過去の保育記録を示した上で回答します。ここで重要なのは、AIに医学的な判断や与薬の可否を推測させないことです。回答は必ず登録済みのデータの提示に留め、判断は保育士と保護者・かかりつけ医の間で行われるという線を設計段階で引いておきます。
権限・運用ルール: 保育士は自分がシフトに入る日の児童情報を閲覧でき、当日の保育記録を入力できます。アレルギー情報や与薬に関する項目は、面談を担当した主任・園長の権限で登録・更新する運用にし、伝聞での書き換えが起きないようにします。児童台帳の削除や利用実績の修正は管理者権限に限定します。あわせて、面談で得た情報が古くなることを前提に、一定期間ぶりの利用があった場合は受け入れ前に情報の再確認を促す通知を出す運用ルールを組み込みます。
以下は、こうした設計思想をもとに構築した、よりどころべーすの保育施設向けデモ画面（サンプルデータ）です。
よりどころべーすの保育施設向けダッシュボードのデモ画面（サンプルデータ）。当日と翌日の一時利用児の受け入れ予定一覧、児童ごとのアレルギー・食事形態の表示、予約枠の埋まり具合、月ごとの利用実績時間の集計が1画面にまとまっている。
上の画像はサンプルデータによるデモ画面で、実際の施設のデータや導入実績を示すものではありません。受け入れ予定の一覧、児童ごとの配慮事項、予約枠の状況、利用実績の集計が1つの画面にまとまっているイメージを掴んでいただくためのものです。朝の準備の時点でこの画面を開けば、その日に必要な情報がひととおり揃っている、という状態を目指した設計です。
定着の仕掛け: 保育士にとって、子どもを見る以外の入力作業が増えると必ず形骸化します。そこで、当日の記録入力は登降園時刻のタップと、決まった観点（食事・睡眠・機嫌・特記事項）の選択で完了する設計にし、自由記述は任意にします。入力された登降園時刻がそのまま利用実績と請求のもとになるため、「記録を書く」という行為が「事務を減らす」ことに直結する構造を作ります。転記のために別途出席簿をつける作業が消えることで、現場が入力するメリットを実感できる状態にします。
既存環境との連携・移行: すでに保育業務支援システムや連絡帳アプリを使っている園も多いはずです。それらを一斉に置き換えるのではなく、まず一時利用の受け入れ管理という新しい業務を新しい基盤で始め、在園児の記録は既存システムに残す段階移行を想定します。児童台帳の項目を将来的に統合できる形で設計しておけば、運用が安定してから在園児側を寄せることができます。
ここまで書いた設計の多くは、個別のツールを組み合わせても部分的には実現できます。ただ、既製の保育業務支援システムは在園児の日々の保育を前提に作られていることが多く、こども誰でも通園制度のように「月に数回来る、情報が古くなりやすい子ども」を在園児と同じ台帳で扱う設計にはなっていないことがあります。かといって、ゼロからのフル自作は費用も期間もかかりすぎて、多くの施設にとって現実的ではありません。私たちは、保育向けの業種別パッケージを土台にしながら、自園の面談シートの項目や受け入れ枠の考え方に合わせてスクラッチで作り込む形をとることで、この間を埋めます。社内AIチャット・記録・シフト勤怠・ワークフローが同じ基盤に載っているため、「明日の一時利用児のアレルギー」のような、予約情報と児童情報と記録をまたぐ問い合わせにも答えられる設計が組めます。要件整理はエンジニアが直接ヒアリングするので、「主任が面談で実際に何を聞き取っているか」のレベルまで仕様に落とし込めます。
まずは、直近1か月の一時利用の受け入れについて、「面談シートを探した回数」を思い出してみてください。そこに、仕組み化で削れる手間のヒントが見えてくるはずです。ここに書いた設計はあくまで一般化した叩き台であり、実際には自園の面談項目や自治体の運用ルールに合わせて、要件整理の段階から一緒に詰めていくことになります。サービスの全体像は保育園向けの業務システムのページにまとめていますので、あわせてご覧ください。
まとめ：この記事で持ち帰れること
この記事を読み終えた時点で、次のことが判断できる状態になっているはずです。
- こども誰でも通園制度で自園に増える事務が、6つの工程のうちどれで、誰が担うことになるか
- 予約システム単体で足りるのか、児童情報と記録まで含めた基盤が必要なのかの見極め方
- 仕組み化する場合の費用レンジ（300万円前後〜）と、要件整理から運用開始までの期間の目安
こども誰でも通園制度は、保育施設にとって新しい役割であると同時に、地域の子育て家庭との接点が増える機会でもあります。その受け皿を職員の善意と記憶だけで支えると、いずれ受け入れ枠を絞る判断を迫られます。事務の側を先に整えておくことが、結果的に受け入れられる子どもの数を守ることにつながります。
制度への対応や仕組みづくりでお困りのことがあれば、お問い合わせからご相談ください。現状の面談シートやシフト表を拝見しながら、どこから手をつけるべきかを一緒に整理します。
よくある質問
Q. こども誰でも通園制度への対応に、専用のシステムは必須ですか？
A. 必須ではありません。受け入れ枠が月に数件程度であれば、紙の面談シートとExcelの予約表でも運用は可能です。ただし、受け入れ人数が増えるほど「面談情報を当日の担当保育士に確実に届ける」工程が破綻しやすくなるため、受け入れ枠を広げる判断をする前に仕組みを整えておくのが安全です。
Q. すでに保育業務支援システムを使っています。二重投資になりませんか？
A. 一斉に置き換える必要はありません。在園児の記録は既存システムに残したまま、一時利用の受け入れ管理だけを新しい基盤で始める段階移行が現実的です。児童台帳の項目を将来統合できる形で設計しておけば、運用が安定してから寄せることができます。
Q. 保育士の入力負担が増えるのではないですか？
A. 設計次第です。登降園時刻の入力がそのまま利用実績と請求のもとになる構造にすれば、月末に出席簿から転記する作業がなくなり、差し引きでは負担が減ります。逆に、既存の記録とは別にシステム入力を追加するだけの設計にすると、確実に形骸化します。
Q. AIに子どもの情報を扱わせるのは不安があります。
A. AIの役割を「登録済みのデータを探して提示する」ことに限定し、医学的な判断や与薬の可否といった判断はさせない設計にするのが前提です。アレルギー情報の登録・更新権限を面談担当者に限定するなど、権限設計とあわせて考える必要があります。
Q. 導入にはどのくらいの期間がかかりますか？
A. 要件整理から児童台帳の設計、テスト運用を経て本格運用に入るまで、標準的には1.5〜2ヶ月程度です。年度の切り替えや受け入れ枠の拡大タイミングに合わせて逆算すると進めやすくなります。