自治体向け福祉業務システム開発の発注/外注/依頼/委託方法について

自治体向け福祉業務システムの発注・外注は、標準仕様と自治体固有の業務を切り分け、移行・連携・保守まで含めた総額と実行体制で委託先を決めることが成功の近道です。

障害者福祉、介護保険、生活保護、児童福祉などを扱うシステムは、一般的な業務アプリよりも制度改正、個人情報、国や都道府県への報告、住民情報との連携を慎重に考える必要があります。本記事では、発注形態の選び方からRFP・要件整理、契約形態、費用相場、委託先選定と見積比較まで、自治体が外注を進める順番に沿って解説します。

▼全体ガイドの記事
・自治体向け福祉業務システム開発の完全ガイド

自治体向け福祉業務システムの発注・外注は何から始めますか？

最初に行うことは、製品名や開発会社を探すことではなく、現在の業務と将来の調達範囲を整理することです。住民・世帯・宛名情報、所得・課税情報、資格、認定、給付、相談記録、通知、帳票、統計、外部報告を制度ごとに並べ、どこを基幹システムで管理し、どこを周辺システムや窓口サービスで補うかを決めます。

自治体向け福祉業務システムは、市区町村の職員が住民からの相談を受け、資格や認定を確認し、支給決定、給付、ケース記録、通知、国や都道府県への報告まで行うための行政システムです。介護事業所や障害福祉事業所が利用する請求・記録ソフトとは目的が異なります。後者の機能が優れていても、住民情報、宛名、課税情報、条例に基づく給付計算や行政内部の決裁まで満たすとは限らないため、RFIの段階で対象利用者と業務範囲を明記することが大切です。

2026年時点では、地方公共団体の基幹業務システムは20の標準化対象事務を軸に、ガバメントクラウド上の標準準拠システムへの移行が進められています。原則2025年度までの移行を目指す一方、2026年度以降の移行となる特定移行支援システムも整理されているため、発注時は「標準準拠済みか」だけでなく、どの版の標準仕様に対応し、いつ何を移行するかを確認します（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年6月更新）。標準化対象の機能、条例や地域運用、独自帳票、窓口・電子申請の連携を同じ箱に入れず、別々の見積項目にすることが重要です。

発注形態はどのように選びますか？

発注形態は、標準準拠パッケージ・クラウドを中心にするか、追加開発をどこまで許容するかで決まります。制度の根幹は既存製品を活用し、自治体固有の相談記録や庁内ワークフローは限定カスタマイズまたは別サービスで補う形が、制度改正への追随と保守の両立を図りやすいです。

介護保険や障害者福祉など、制度改正の影響が大きい領域では、標準仕様に対応したパッケージやクラウドを採用することで、計算、資格、給付、帳票の更新を自前で抱える範囲を減らせます。厚生労働省は2026年3月に介護保険システム標準仕様書の第6.0版を公表しているため、提案書に「標準対応」とだけ書かせず、対象業務、対応版、未対応機能、今後の改定時期と費用を記載してもらいます（出典：厚生労働省「介護保険システム標準仕様書 第6.0版」、2026年3月）。クラウドの場合は、月額利用料に含まれる範囲、データ保存場所、バックアップ、障害時の復旧目標、契約終了後のデータ返却も確認します。

標準仕様にない条例対応、独自の相談記録、複雑な庁内決裁、既存の電子申請や窓口端末との接続は、パッケージへの追加開発で対応できる場合があります。ただし、画面を追加するだけでなく、制度改正時のテスト、権限、ログ、帳票、データ移行、保守費まで影響するため、要望を一件ずつ「標準機能で対応」「設定で対応」「追加開発」「業務を見直して廃止」に分類します。スクラッチ開発は、標準外の業務が競争力や住民サービスに直結し、長期運用の技術者と予算を確保できる場合に限って検討するのが安全です。

住民情報、税、国保、福祉、電子申請、窓口支援を別々の事業者に委託する場合は、特定の一社にすべてを任せる方式より競争性を確保しやすい一方、障害の切り分けとデータ連携の責任が曖昧になりやすいです。自治体側にPMO機能を置くか、プライムベンダーを一社決め、API、ファイル連携、マスタ管理、問い合わせ窓口、障害時のエスカレーションをRFPに明記します。受託側が再委託する場合は、再委託先の範囲、個人情報へのアクセス、監査方法も契約条件に含めます。

RFPと要件整理では何を決めますか？

RFPは、単なる機能一覧ではなく、自治体が達成したい業務成果と、提案各社が同じ条件で見積もるための共通資料です。現行業務、対象制度、利用者数、データ量、連携先、帳票、非機能要件、移行方針、導入時期、運用体制を示し、必須要件と提案を期待する要件を分けます。

制度別に、申請の受付、審査、決裁、資格・認定、支給・請求、通知、返還、ケース記録、統計、国や都道府県への報告を一連の流れで書き出します。担当課や職員の役割、繁忙期、月間・年間の処理件数、現在使っている帳票とExcel、二重入力、手作業のチェックも記録します。現場ヒアリングでは「画面が使いにくい」という感想だけで終わらせず、どの処理に何分かかり、どの転記で誤りが起きるかまで確認すると、提案の評価軸になります。

RFPの機能要件には、住民・世帯・宛名、課税、資格、認定、給付、相談記録、通知、帳票、統計、監査用出力を含めます。非機能要件には、可用性、性能、バックアップ、復旧目標、アクセス制御、多要素認証、暗号化、操作・参照・出力ログ、脆弱性対応、障害受付時間を含めます。さらに、旧システムから何年分の履歴や添付ファイルを移すか、コード変換と名寄せを誰が行うか、電子申請・窓口・住民情報・税・国保・健康管理とどの方式で連携するかを明示します。

標準仕様の版、標準データ要件・連携要件への適合、ガバメントクラウドでの構成、特定移行支援に該当する場合の計画を提案書に求めます。障害・介護認定、生活状況、個人番号などは扱いを誤ると本人の権利利益に影響する情報です。個人情報保護委員会の行政機関等向けガイドラインでは、地方公共団体独自の条例や規則にも沿った対応が必要とされているため、最小権限、委託先・再委託先管理、ログ監査、バックアップ復旧訓練を評価項目にします（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」、2026年確認）。相談記録のAI要約や検索を提案された場合は、入力データの保存、学習利用、誤回答時の停止、根拠表示、職員による最終判断を確認します。

契約形態はどのように使い分けますか？

契約形態は、成果物と仕様が固まっているか、要件変更がどの程度見込まれるか、運用後の責任をどこまで委託するかで選びます。契約書の名称だけで判断せず、成果物、検収基準、変更手続、瑕疵や不具合への対応、知的財産、個人情報、再委託、サービス終了時のデータ返却を明確にすることが必要です。

要件、設計、開発、テスト、移行などの成果物と完成条件を定義できる部分には、請負契約が適しています。RFPに書いた機能を実装しただけでなく、実データに近い検証データで計算・帳票・外部連携が正しく動くこと、性能や権限が非機能要件を満たすことを検収条件に含めます。納品物に設計書、テスト結果、移行手順、運用手順、ソースコードや設定情報を含めるかも、将来の事業者変更を見据えて決めます。

現行調査、要件整理、RFP作成支援、PMO、データ移行の調整、研修、運用改善のように、専門家の作業や支援そのものを委託する部分は、準委任契約が選択肢になります。作業時間や体制を基準にする場合でも、月次の作業報告、会議体、課題管理、成果の確認方法を定めます。単に人月を買う契約にせず、自治体側が得る資料や判断材料を明確にすると、支援の品質を評価しやすくなります。

自治体向け福祉業務システムでは、初期導入、データ移行、連携開発、研修、クラウド利用、保守、制度改正対応を同じ契約書や見積書にまとめると、どこまでが初期費用で、何が毎年発生するのか分かりにくくなります。導入の成果物と運用サービスを分け、制度改正や追加帳票は変更管理の単価表にする方法が実務的です。随意契約や特命随意契約を検討する場合も、既存製品の著作権・データベース連携など、他社では代替できない理由を調達記録に残します。

自治体向け福祉業務システムの費用相場はいくらですか？

費用は、人口、制度数、職員数、データ量、連携本数、標準仕様への適合状況、移行難易度、クラウド構成によって大きく変わります。したがって、公開契約の実績値を新規導入の相場と誤解せず、初期導入・移行・連携・研修・保守・制度改正・クラウド利用を分解し、5年TCOで比較します。

2025年度から2026年に公表された自治体契約を見ると、唐津市の令和7年度税制改正に伴う介護保険システム改修業務は1,994,300円（税込）でした（出典：唐津市「令和8年1月5日随意契約」、2026年）。これは既存システムの改修であり、要件定義から新規導入までを含む金額ではありません。リサーチノートで確認した富田林市の2025年度契約では、介護保険システムのクラウド利用が年額2,649,900円、障害福祉システムの制度改正対応が5,445,000円でした。また、大阪市では総合福祉システムの情報連携機能改修が174,096,670円となった例があります。いずれも制度単位の利用、改修、連携などの契約であり、自治体規模と対象範囲が違うため、単純に横並びにはできません。

企画初期の推定として、既存パッケージや標準準拠クラウドを1制度導入する場合は、初期費用500万〜3,000万円、年額200万〜1,000万円程度を置くことがあります。障害者福祉、介護保険、生活保護など複数制度の標準化対応とデータ移行を含める場合は3,000万〜1.5億円程度、大規模自治体で総合福祉基盤や窓口・電子申請・住民情報連携まで刷新する場合は1億〜数億円程度を想定することがあります。独自業務や独自帳票を多く残すスクラッチ・大規模カスタマイズは5,000万〜3億円超となる可能性があります。これらは公開契約の単純平均ではなく、リサーチノートに基づく企画段階の推定レンジですので、予算要求の確定額として断定せず、RFIで条件を揃えて精度を上げます。

見積比較では、初期費用だけが安い提案を選ばないようにします。5年TCOには、導入ライセンス、クラウド利用料、ネットワーク、端末、データ移行、連携開発、研修、問い合わせ、保守、制度改正、追加帳票、バックアップ、監査や脆弱性対応の費用を含めます。デジタル庁も標準化・ガバメントクラウド移行後の運用経費について、自治体によっては費用増が見込まれると説明しています。クラウドだから安い、標準準拠だから追加費用がないとは決めつけず、利用者数やデータ量の増加、契約更新時の単価改定、終了時の移行費まで確認します（出典：デジタル庁「自治体情報システムの標準化・ガバメントクラウド移行後の運用経費に係る総合的な対策」、2025年）。

委託先選定と見積比較では何を見ますか？

委託先は、製品の知名度や見積総額だけでなく、自治体と同じ制度範囲・人口規模・連携条件で安定稼働させた経験を確認します。提案書の言葉を信じるだけではなく、標準仕様の適合表、類似団体の実績、移行リハーサルの方法、障害時の連絡体制、制度改正時のリリース手順を具体的な資料で比較します。

開発会社には、人口規模、対象制度、職員数、既存の住民情報や税システム、クラウド環境、移行対象の履歴年数が近い事例を提示してもらいます。例えば、介護保険に強い会社でも、障害福祉や生活保護、相談支援まで一体で扱えるとは限りません。実績の件数だけでなく、稼働年数、制度改正の対応履歴、障害件数と復旧実績、担当者の継続性、自治体側の評価を確認します。可能であれば、導入前の自治体が事業者に聞くべき質問と、導入後の自治体が感じた課題を分けてヒアリングします。

相見積もりでは、各社に同じRFPと見積フォーマットを渡し、初期導入、要件定義、設計、設定・開発、テスト、移行、連携、研修、保守、クラウド、制度改正、追加作業の単価を分けて記載してもらいます。「一式」の内訳が多い会社には、人数、期間、前提条件、除外事項、再委託費、価格改定条件を追加で質問します。機能を満たすかは必須・加点・対象外で評価し、価格点だけでなく、品質、移行、セキュリティ、運用継続性、職員の使いやすさにも配点を置きます。

最も見落としやすいのは、本番稼働日に旧システムのデータが完全に移らないリスクです。対象データ、欠損・重複の扱い、コード変換、名寄せ、添付ファイル、履歴、移行後の照合方法を決め、少なくとも複数回の移行リハーサルを行います。障害時は、一次受付、原因調査、代替運用、復旧、住民への説明、再発防止の責任分界を確認します。さらに、契約終了時に標準形式でデータを返却できるか、設定・仕様書を受け取れるか、別事業者が引き継げるかを選定前に質問すると、長期的なロックインを抑えられます。

自治体向け福祉業務システムの発注でよくある質問

発注前に多く寄せられる疑問を、調達実務で判断しやすい形にまとめます。個別の制度、自治体の規模、既存システムによって結論が変わるため、最終的にはRFIやRFPで自自治体の条件に置き換えて確認します。

不要とは限りません。標準仕様の対象業務でも、条例、独自帳票、庁内の決裁、既存システムとの連携、移行対象データなどは自治体ごとに違うため、標準機能で対応できる範囲と追加費用を分けて確認します。標準化対象外の周辺業務は、基幹部分を大きく改変せず、APIや別サービスで連携する方が将来の制度改正に対応しやすいです。

移行できる範囲は、旧システムのデータ形式、保存年数、項目定義、コード体系、添付ファイルの管理方法によって決まります。現行データの一覧、件数、欠損、重複、文字コード、個人を特定するキーを早い段階で確認し、移行対象、参照用アーカイブ、紙や別媒体で保管する対象を分けます。契約前に移行サンプルを作り、新旧件数と主要項目を照合する手順、失敗時の再実行費用まで見積に入れてもらうと安心です。

必ず安くなるとはいえません。デジタル庁は、標準化後の運用経費について、共同化などで対策してもガバメントクラウド移行に伴い費用増となる自治体があると説明しています。インフラ、監視、バックアップ、通信、アプリ利用料、データ量、運用体制を含めた5年TCOで比較し、価格だけでなくセキュリティ、災害対策、柔軟な変更、契約終了時の出口条件を評価します。

サービスの仕様と自治体の規程を確認せずに入力してはいけません。要配慮個人情報や個人番号を扱う可能性がある場合は、入力データの保存場所、学習への利用、第三者提供、アクセス権限、ログ、削除、誤要約への対応を契約と運用規程に落とし込みます。利用する場合も、匿名化や検索対象の限定、職員の最終確認、AI停止手順を整備し、AIの出力だけで支給や支援の判断を完結させないことが重要です。

まとめ

自治体向け福祉業務システムの発注・外注では、まず現行業務を制度別に棚卸しし、標準仕様と自治体固有要件を分けます。そのうえで、標準準拠パッケージ・クラウド、限定カスタマイズ、周辺開発、スクラッチの役割を決め、RFIとRFPで各社が同じ条件で提案できる状態をつくります。

見積は初期導入費だけでなく、データ移行、外部連携、研修、クラウド、保守、制度改正、追加帳票を分け、5年TCOで比較します。契約は請負、準委任、運用サービスを適切に組み合わせ、検収、変更管理、障害対応、再委託、個人情報、データ返却を明記します。価格の低さだけでなく、類似自治体での稼働実績、標準仕様の版、移行リハーサル、復旧体制、事業者変更のしやすさまで評価することが、長く使える福祉業務システムにつながります。

複数社へ声をかける前に、対象制度、処理件数、連携先、移行対象、希望時期、セキュリティ条件、予算の前提を一枚にまとめると、提案の違いが見えやすくなります。自治体職員、情報政策課、福祉担当課、調達担当、現行ベンダーが同じ資料を見ながら優先順位を合意し、段階導入や小規模な検証を挟んで進めることで、住民サービスを止めずに発注・外注を実行しやすくなります。

▼全体ガイドの記事
・自治体向け福祉業務システム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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