自治体向け福祉業務システムの発注は、まず現在の業務と仕様を整理し、発注形態、契約、費用、委託先の順に検討して進めます。
発注形態から委託先までは前の判断を受けて決まるため、この順に見ていきます。全体像は、自治体向け福祉業務システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・自治体向け福祉業務システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自治体向け福祉業務システムの発注・外注の始め方
最初に取りかかるのは、現在の業務と将来の調達範囲を整理することです。
製品や開発会社を探す前に、ここを固めておきます。
業務は制度ごとに並べ、住民・世帯・宛名、所得・課税、資格を洗い出します。認定、給付、相談記録の業務も同じように洗い出します。通知と帳票、統計と外部報告も含めます。
洗い出した業務のうち、基幹システムで管理するものと、周辺システムや窓口サービスで補うものを決めます。
自治体向けと民間施設向けの対象業務の違い
自治体向け福祉業務システムは、市区町村職員が住民の相談を受ける行政システムです。そのため、製品を見るときは次の点に注意します。
- 自治体の業務：資格・認定、支給決定、給付、ケース記録、通知、国や都道府県への報告を扱います。
- 民間施設の業務：介護・障害福祉事業所の請求・記録ソフトとは目的が異なります。
- 製品の確認：住民情報、宛名、課税情報、条例に基づく給付計算に対応しているかを見ます。
民間施設向け製品の機能が優れていても、行政内部の決裁まで満たすとは限りません。
RFIの段階で、利用者と業務範囲を明記しておきます。
標準仕様と自治体固有要件の切り分け
2026年時点で、地方公共団体の基幹業務システムは20の標準化対象事務に沿って移行が進んでいます。また、ガバメントクラウド上の標準準拠システムへの移行は、原則2025年度までを目指すとされています（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年6月更新）。
- 移行時期：2026年度以降に移行する特定移行支援システムも整理されています。
- 仕様と見積：標準仕様の版と移行時期を確認し、標準機能と、条例・地域運用・独自帳票・窓口・電子申請連携の部分を別々に見積もります。
発注形態の選び方
発注形態は、標準準拠パッケージ・クラウドを基本にするか、追加開発をどこまで認めるかで決まります。制度の根幹は既存製品に任せ、自治体固有の相談記録や庁内ワークフローは限定開発や別サービスで補います。
既存製品と限定開発・別サービスを組み合わせる形は、制度改正への追随と保守を両立させる方法として考えられます。
標準準拠パッケージ・クラウドを第一候補とする理由
介護保険や障害者福祉では、制度改正が計算や給付、帳票などに影響するため、標準仕様に対応した製品を使うと、更新を自前で抱える範囲を減らせます。確かめたいのは、標準仕様への対応、クラウドの運用、契約終了時の扱いです。
- 標準仕様：対象業務と対応版、未対応機能を提案書に書いてもらい、今後の改定時期と費用も示してもらいます。
- クラウド運用：月額料金に含む範囲、データの保存場所、バックアップ、障害時の復旧目標を見ておきます。
- 契約終了：データ返却の条件は、導入前に取り決めておきます。
厚生労働省は2026年3月に第6.0版を公表しています（出典：厚生労働省「介護保険システム標準仕様書 第6.0版」、2026年3月）。
限定カスタマイズとスクラッチ開発の使い分け
条例への対応や独自の相談記録、複雑な庁内決裁は、標準仕様にない場合があります。そのため、標準機能で足りない要望は、追加開発で対応するか、設定や業務の見直しで済ませるかを分けて考えます。
- 対応範囲：電子申請や窓口端末との接続は、パッケージへの追加開発で対応できる場合があります。
- 要望の分類：「標準機能」「設定」「追加開発」「業務見直し・廃止」に分けます。
- スクラッチ開発：標準外業務が競争力や住民サービスに直結し、技術者と予算を長期確保できる場合に検討します。
追加開発は画面の変更だけで終わらず、制度改正時のテストや帳票、データ移行、保守費にも影響します。
複数ベンダー方式での責任の切り分け
住民情報・税・国保・福祉・電子申請・窓口支援を別々の事業者に委託すると、一社に任せる方式より競争性を確保しやすくなります。一方で、障害の切り分けや連携の責任が曖昧になりがちです。
- 統括体制：自治体にPMO機能を置くか、プライムベンダーを一社決めます。
- 連携と障害対応：API、ファイル連携、マスタ管理、問い合わせ窓口、障害時のエスカレーションをRFPに明記します。
- 再委託：委託先の範囲、個人情報へのアクセス、監査方法を契約条件に含めます。
RFPと要件整理で決めること
RFPは、自治体が達成したい業務成果を各社に伝える共通資料です。
各社が同じ条件で見積もれるよう、現行業務・対象制度・利用者数・データ量・連携先を示します。さらに、帳票・非機能要件・移行方針・導入時期・運用体制も記載します。そのうえで、必須要件と、提案を期待する要件は分けて整理します。
入力から報告までの現行業務の棚卸し
制度ごとの業務と現場の負担を照らし合わせると、要件や提案を評価する観点が作れます。
- 業務の流れ：申請受付、審査、決裁、資格・認定、支給・請求、通知、返還、ケース記録、統計、国や都道府県への報告を、流れに沿って書き出します。
- 体制と件数：担当課・職員の役割、繁忙期、月間・年間の処理件数を記録します。
- 現行の作業：帳票、Excel、二重入力、手作業のチェックを洗い出します。
- 課題の確認：使いにくさに加えて、処理時間や転記ミスの箇所を聞き取ります。
RFPに入れる機能・移行・連携・運用の条件
RFPには、機能・非機能、移行、連携、運用の条件を具体的に書き込みます。
- 機能要件：住民・世帯・宛名、課税、資格、認定、給付、相談記録、通知、帳票、統計、監査用出力を含めます。
- 非機能要件：可用性、性能、バックアップ、復旧目標、アクセス制御、多要素認証、暗号化、操作・参照・出力ログ、脆弱性対応、障害受付時間を示します。
- 移行条件：旧システムから移す履歴・添付ファイルの年数、コード変換と名寄せの担当を定めます。
- 連携条件：電子申請、窓口、住民情報、税、国保、健康管理との連携方式を明示します。
標準化・セキュリティ・AI利用の評価条件
障害・介護認定、生活状況、個人番号は、本人の権利利益に影響しうる情報です。そのため、評価の条件は、標準化、情報管理、AI利用の三つの面から考えます。
- 標準化：標準仕様の版と、標準データ・連携要件への適合、クラウド構成、特定移行支援の計画を見ます。
- 情報管理：最小権限、委託先・再委託先の管理、ログ監査、バックアップ復旧訓練を評価の対象にします。
- AI利用：入力データの保存・学習利用、誤回答時の停止、根拠表示、職員の最終判断です。
個人情報保護委員会のガイドライン（出典：「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」、2026年確認）によると、地方公共団体は独自の条例や規則にも沿う必要があります。
契約形態の使い分け
契約形態は、成果物や仕様が固まっているか、要件変更が見込まれるかで選びます。あわせて、運用後の責任をどこまで委託するかも判断材料になります。
まず成果物、検収基準、変更手続を明確にし、そのうえで契約書の名称を決めます。さらに、瑕疵や不具合への対応・知的財産・個人情報・再委託・終了時のデータ返却も、契約で定めておきます。
請負契約の完成条件と検収基準
要件・設計・開発・テスト・移行は、成果物と完成条件を定義できるため、請負契約が適します。
- 検収条件：検証データで計算・帳票・外部連携が正しく動き、性能や権限が要件を満たすことを確認します。
- 納品物：設計書、テスト結果、移行手順、運用手順を含めるか決めます。
- 事業者変更：将来に備えて、ソースコードや設定情報の扱いを取り決めます。
準委任契約が向く調査・PMO・運用支援
専門家の作業や支援を委託する業務には、準委任契約が選択肢になります。
- 対象業務：現行調査、要件整理、RFP作成支援、PMO、データ移行の調整、研修、運用改善です。
- 進捗管理：作業時間や体制を基準にする場合も、月次報告、会議体、課題管理を定めます。
- 成果確認：自治体が得る資料や判断材料を明確にし、成果の確認方法を決めます。
導入と運用を分けた複合契約
導入と運用の費用を一括にすると、初期費用と毎年の費用の区別がつきにくくなります。
- 契約の分け方：導入成果物と運用サービスを分け、制度改正や追加帳票は変更管理の単価表にします。
- 随意契約の理由：随意契約や特命随意契約を検討する場合、他社で代替できない理由を調達記録に残します。
費目は、初期導入・データ移行・連携開発・研修・クラウド・保守ごとに分けます。随意契約の理由の例として、既存製品の著作権やデータベース連携が挙げられます。
自治体向け福祉業務システムの費用相場
費用は、人口・制度数・職員数・データ量・連携本数によって変わります。加えて、標準仕様への適合状況や移行の難易度、クラウド構成も費用を左右します。
公開契約の実績値は、新規導入の相場と取り違えないように読み、費目を分けて5年TCOで比べます。
見積もりには、初期導入・移行・連携の費用を含めます。さらに、研修・保守・制度改正・クラウド利用の費用も入れておきます。
公開契約の金額を個別業務の実績値として読む見方
公開契約は対象業務ごとの実績として読み、金額だけで新規導入費を見積もらないようにします。
- 唐津市：令和7年度税制改正に伴う介護保険システム改修は1,994,300円（税込）でした（出典：唐津市「令和8年1月5日随意契約」、2026年）。
- 富田林市：2025年度の介護保険システムのクラウド利用は年額2,649,900円、障害福祉システムの制度改正対応は5,445,000円でした。
- 大阪市：総合福祉システムの情報連携機能改修は174,096,670円となった例があります。
唐津市の契約は既存システムの改修で、要件定義からの新規導入費用ではありません。いずれも制度単位の利用・改修・連携であり、自治体の規模と対象範囲が異なるため、単純な比較はできません。富田林市の金額は、リサーチノートで確かめた2025年度の契約です。
企画段階の費用レンジ
導入する範囲によって金額は大きく変わるため、企画段階では範囲ごとに初期費用と年額費用の推定レンジを置きます。
- 1制度：既存パッケージ・標準準拠クラウドを導入する場合、初期費用500万〜3,000万円、年額200万〜1,000万円程度です。
- 複数制度：標準化対応とデータ移行を含める場合、3,000万〜1.5億円程度を想定します。
- 大規模自治体：総合福祉基盤や窓口・電子申請・住民情報連携まで刷新する場合、1億〜数億円程度を想定することがあります。
- 独自業務や独自帳票を多く残す場合：スクラッチ・大規模カスタマイズは5,000万〜3億円超となる可能性があります。
これらの数字は、リサーチノートに基づく企画段階の推定で、公開契約の単純平均ではありません。そのため、予算要求の確定額にはせず、RFIで条件をそろえて精度を上げます。
5年TCOで見る安さと持続性
初期費用が安いという理由だけで提案を選ぶのは避け、5年TCOで安さと持続性を比べます。
- 導入・基盤：ライセンス、クラウド利用料、ネットワーク、端末、データ移行、連携開発を含めます。
- 運用：研修、問い合わせ、保守、制度改正、追加帳票、バックアップ、監査、脆弱性対応も、費用に入れます。
- 将来費用：利用者数・データ量の増加、更新時の単価改定、終了時の移行費を確認します。
また、デジタル庁は、標準化・ガバメントクラウド移行後に運用費が増える自治体もあると説明しています（出典：デジタル庁「自治体情報システムの標準化・ガバメントクラウド移行後の運用経費に係る総合的な対策」、2025年）。そのため、クラウドや標準準拠であっても、追加費用の有無は決めつけず、項目ごとに金額を確かめます。
委託先選定と見積比較の観点
委託先は、知名度や見積総額とあわせて、自治体での安定稼働の経験を確認します。制度範囲や人口規模、連携条件が自治体に近い実績を比べます。
また、標準仕様の適合表、類似団体の実績、移行リハーサルの方法を資料で確認します。さらに、障害時の連絡体制や、制度改正時のリリース手順も比べます。
実績は自治体の条件との近さ
事例は、自治体の制度範囲や環境に近いかを照らし合わせて評価します。
- 自治体の条件：人口規模、対象制度、職員数、住民情報・税システム、クラウド環境、移行履歴年数を照合します。
- 対応範囲：介護保険の実績があっても、障害福祉や生活保護、相談支援まで扱えるとは限りません。
- 稼働実績：実績件数、稼働年数、制度改正履歴、障害件数と復旧実績、担当者の継続性、自治体評価を確認します。
- ヒアリング：導入前に聞く質問と、導入後に感じた課題を分けて整理します。
見積項目をそろえた条件の比較
相見積もりは、同じRFPと見積フォーマットを使い、費目と評価条件をそろえます。
- 費目：初期導入、要件定義、設計、設定・開発、テスト、移行、連携、研修、保守、クラウド、制度改正、追加作業を分けます。
- 内訳と条件：「一式」には人数、期間、前提、除外事項、再委託費、価格改定条件を確認します。
- 評価：機能を必須・加点・対象外で判定します。価格点だけでなく、品質、移行、セキュリティ、継続性、使いやすさにも配点します。
移行・障害・事業者変更のリスク確認
本番稼働日に旧システムのデータが完全に移らないリスクを想定し、事前に確かめておきます。
- 移行準備：対象データ、欠損・重複、コード変換、名寄せ、添付ファイル、履歴の扱いを決めます。
- 検証：移行後の照合方法を定め、少なくとも複数回のリハーサルを行います。
- 障害対応：一次受付、原因調査、代替運用、復旧、住民説明、再発防止の責任を分けます。
- 事業者変更：標準形式でのデータ返却、設定・仕様書の受領、別事業者への引き継ぎ可否を確認します。
選定の前に出口条件を確かめておくと、長期的なロックインを抑えられます。
自治体向け福祉業務システムの発注でよくある質問
発注前によく寄せられる疑問を、調達の実務で判断しやすい形に整理しています。
制度や自治体の規模、既存システムによって結論が変わるため、自治体の条件に照らして確かめます。
標準仕様に準拠していればカスタマイズは不要ですか？
標準仕様に準拠していても、カスタマイズが必要になることがあります。条例・独自帳票・庁内決裁、既存システムとの連携、移行対象データは、自治体ごとに異なります。
そのため、標準機能で対応できる範囲と追加費用を分けて確認します。また、標準化の対象外となる周辺業務は、基幹部分を大きく変えず、APIや別サービスで連携すると、制度改正に対応しやすくなります。
既存データはどこまで移行できますか？
移行範囲は、旧システムの形式や保存年数、項目定義、コード体系で決まります。
- 現行データ確認：早い段階で一覧、件数、欠損、重複、文字コード、個人を特定するキーを調べます。
- 保管先の分類：移行対象、参照用アーカイブ、紙や別媒体で保管する対象に分けます。
- 移行検証：契約前にサンプルを作り、新旧件数と主要項目を照合します。
- 費用確認：添付ファイルの管理方法と、移行失敗時の再実行費用も見積もりに含めます。
ガバメントクラウドなら費用は必ず安くなりますか？
安くなるとは限らず、移行後も共同化などの対策を含めて費用が増える自治体があると、デジタル庁は説明しています。
そのうえで、インフラ・監視・バックアップ・通信の費用を含めます。アプリ利用料、データ量、運用体制も加えて、5年TCOで比べます。価格に加えて、セキュリティ・災害対策・変更の柔軟性・終了時の出口条件も評価します。
相談記録や障害情報をAIに入力してもよいですか？
サービスの仕様と自治体の規程を確かめないまま入力してはいけません。
- データ管理：要配慮個人情報や個人番号の保存場所、学習利用、第三者提供を確認します。
- 運用管理：アクセス権限、ログ、削除、誤要約への対応を契約・運用規程に定めます。
- 利用時の確認：匿名化、検索範囲の限定、職員の最終確認、AI停止手順を整えます。
AIの出力だけで、支給や支援の判断を完結させてはいけません。
まとめ
自治体向け福祉業務システムの発注では、まず現行業務を制度別に棚卸しします。そのうえで、標準仕様と自治体固有要件を分け、標準準拠製品・限定開発・周辺開発・スクラッチの役割を決めます。さらに、RFIとRFPで、各社が同じ条件で提案できる状態をつくります。
発注前に決めるべきこと
発注前の確認事項をそろえると、費用、契約、委託先を同じ基準で判断できます。
- 費用：初期導入・移行・連携・研修・クラウド・保守・制度改正・追加帳票を分け、5年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を創業。