自治体向け福祉業務システム開発の進め方/やり方/流れや方法/手法/工程/手順

自治体向け福祉業務システムの開発は、福祉部門の画面を新しくするだけではなく、制度・住民情報・課税情報・申請・審査・給付・通知・国や都道府県への報告を、将来の制度改正にも耐えられる形でつなぐ取り組みです。成功のポイントは、要件整理から選定、設計開発、テスト、稼働、定着までを一つの流れとして計画し、標準仕様に合わせる業務と自治体独自に残す業務を早い段階で切り分けることです。

本記事では、自治体向け福祉業務システムの進め方を6つのフェーズに分け、各段階で決めること、確認する資料、職員が参加するタイミングを実務目線で解説します。公開契約の事例をもとにした費用レンジ、見積書の読み方、データ移行や個人情報保護のチェックリスト、稼働後に定着させる方法まで整理しています。情報政策課、福祉担当課、調達担当、自治体案件を支援するSIerの方が、RFIやRFPを準備する際にも使える内容です。

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

自治体向け福祉業務システムの全体像

自治体向け福祉業務システムは、住民からの相談を受けてから、資格確認、認定、支給決定、給付、ケース記録、通知、実績管理、統計・報告までを支える行政基幹システムです。民間の介護事業所が利用する請求・記録ソフトとは目的が異なり、自治体が制度を運用し、住民に対して公平にサービスを提供するための仕組みです。導入時は製品の機能数だけでなく、制度横断のデータ連携、監査可能性、制度改正への追随力を見なければなりません。

自治体向けは、住民・世帯・宛名、所得・課税、資格、認定、支給決定、通知、決裁、国や都道府県への報告を正確に処理することが中心です。障害者福祉、介護保険、生活保護、児童福祉、ひとり親・医療費助成、高齢者福祉など、制度ごとの専門性を持ちながら、同じ住民の情報を部門横断で扱う必要があります。一方、民間施設向けのソフトは、サービス提供記録、職員配置、請求、ケアプランなど、事業所の日々の業務を効率化することが主目的です。

この違いを曖昧にしたまま製品比較を始めると、「介護に対応している」という説明だけで、自治体の認定・給付・報告まで対応できると誤認しやすくなります。RFIでは、自治体が保有するどの情報を正とするか、誰がどの業務で参照・更新するか、住民からの申請をどの決裁につなぐかを業務単位で確認することが大切です。

最初に、制度名ではなく業務の流れで棚卸しします。たとえば相談受付、申請、本人確認、資格判定、認定調査、審査会、支給決定、受給者証の発行、給付・償還、変更・更新、ケース記録、訪問、通知、実績集計、監査用出力という単位です。各業務について、入力者、承認者、参照する情報、作成する帳票、外部連携、保存期間、例外処理を一覧にすると、製品のデモで確認すべき画面が明確になります。

最低限の機能として、住民・世帯・宛名情報との連携、所得・課税情報の参照、制度ごとの資格・認定・支給管理、申請と決裁、帳票・通知、事業所や請求情報の管理、統計・報告、権限管理、操作ログ、バックアップが必要です。電子申請、窓口支援、健康管理、国保、税、マイナンバー関連の連携がある場合は、後から追加するのではなく、要件整理の段階でデータ項目と責任分界を決めます。

自治体の基幹業務システムでは、標準化対象事務に適合する標準準拠システムへの移行が大きな前提です。デジタル庁は標準化対象事務を現時点で20事務と説明し、原則として2025年度までの移行を掲げています。2026年以降も移行が具体化した「特定移行支援システム」があり、対象団体は自自治体の移行計画と支援対象の扱いを確認する必要があります（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。

標準化は、全業務を一律に同じ運用へ変えるという意味ではありません。標準仕様に含まれる機能・データ・連携は標準に合わせ、条例や地域事情に関係する業務、相談記録、庁内独自のワークフローは、標準対象外として周辺機能や連携で実現する考え方が現実的です。介護保険では厚生労働省が2025年8月に第5.0版の標準仕様書を公開しているため、提案書には「対応している」という表現だけでなく、仕様書の版、対応予定時期、追加費用の有無まで記載してもらいます（出典: 厚生労働省「介護保険システム標準仕様書」、2025年）。

自治体向け福祉業務システムの進め方

進め方は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けると管理しやすくなります。実務では各フェーズが完全に直列になるわけではなく、要件整理の結果を選定資料に反映し、選定後に詳細設計を詰め、テスト結果を移行計画へ戻す循環が起こります。重要なのは、次のフェーズへ進むための完了条件を決め、未決事項を「保留」のまま契約や本番稼働へ持ち込まないことです。

要件整理では、まず福祉担当課だけでなく、情報政策課、財政・契約担当、窓口担当、関連制度の担当者を含む体制を作ります。現行システムの機能一覧を写すだけでは不十分で、年間スケジュール、繁忙期、制度改正時の作業、紙やExcelで補っている業務、属人化している判断を洗い出します。相談から支給、更新、廃止までの業務フローを制度別に描き、同じ住民情報を複数課で入力していないかを確認します。

成果物は、業務一覧、現行・将来業務フロー、機能要件、データ項目一覧、連携一覧、帳票一覧、非機能要件、移行対象一覧、課題・リスク一覧です。機能要件は「できること」だけでなく、処理件数、同時利用者数、検索応答時間、休日・夜間運用、障害時の代替手順まで記載します。要件整理の完了条件は、必須機能と標準対象外の扱い、移行範囲、概算スケジュール、予算化に必要な費目が合意されていることです。

この段階で使えるチェックリストは、「対象制度と対象課が漏れていないか」「申請・審査・決裁・通知・報告を一連で確認したか」「標準仕様の対象と自治体独自要件を分けたか」「外部連携のデータ責任者を決めたか」「移行しない履歴と保存する履歴を決めたか」「個人番号・障害・介護・生活状況などの機微な情報を扱う範囲を明示したか」です。ここが曖昧なままの見積比較は、価格ではなく前提条件の違いを比較することになります。

候補選定は、RFIで市場・製品の適合状況を知り、RFPで同じ条件の提案と見積を求める順番が基本です。RFIでは、標準仕様の対応版、ガバメントクラウドの構成、自治体規模別の稼働実績、データ移行方式、制度改正時の対応、標準対象外への対応可否を質問します。RFPでは、必須要件、加点要件、将来要件を分け、提案者が「標準機能」「設定」「追加開発」「運用回避」のどれで実現するかを明示する様式にします。

選定評価は、機能適合だけで決めません。標準仕様・データ要件への適合、類似団体の導入実績、移行の品質管理、セキュリティ、制度改正の保守体制、障害時の復旧目標、自治体側に必要な作業、5年間の総保有コストを総合的に評価します。デモでは説明を聞くだけでなく、実際の住民異動、所得変更、認定更新、支給停止、訂正、帳票再発行などのシナリオを操作してもらい、例外処理で現場が困らないかを確認します。

ベンダーの導入実績を確認するときは、自治体名の数だけでなく、同じ制度範囲、人口規模、連携条件、クラウド構成かを尋ねます。可能であれば、稼働後の自治体へのヒアリング、移行リハーサルの実績、制度改正時のリリース手順、問い合わせの一次受付体制まで確認します。契約相手が大手であっても、実際の設計・移行・運用を担う協力会社や地場SIerの役割分担が別になっていることがあるため、体制図と責任者を提案書に含めてもらいます。

設計では、要件を画面、帳票、データ、権限、連携、運用手順に落とし込みます。パッケージ導入の場合も、設定値、コード体系、職員・所属の権限、通知文、自治体固有の帳票、バッチ処理を決める作業が発生します。標準機能で対応する範囲、設定で対応する範囲、追加開発する範囲、業務手順を変更する範囲を設計書に分けて記載し、カスタマイズが将来の標準改定を妨げないかを評価します。

連携設計では、住民情報、宛名、税・課税、国保、健康管理、電子申請、窓口予約、国や都道府県の伝送先など、システムごとにデータの正と更新タイミングを決めます。連携エラー時に誰が検知し、どの時点まで再送し、住民への通知を止めるかも重要です。APIがあるかだけでなく、日次ファイル、オンライン、手動取込などの方式、文字コード、コード変換、重複排除、履歴保持、エラー訂正を確認します。

セキュリティ設計では、担当課・職位・業務・個人情報の種類に応じた最小権限、特権IDの管理、多要素認証、保存時と通信時の暗号化、参照・更新・出力の監査ログ、バックアップ、復旧手順、委託先と再委託先の管理を定義します。行政機関等向けの個人情報保護ガイドラインは、地方公共団体にも適用され、要配慮個人情報や漏えい等の報告に関する考え方を示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」、2025年更新）。要件書には「安全にする」と書くのではなく、ログの保存期間、閲覧できる職員、アラートの通知先、復旧目標を数値または手順で書きます。

テストは、開発会社が行う機能テストだけでは終わりません。単体・結合テストで計算や連携を検証した後、自治体の職員が業務シナリオに沿って受入テストを行います。相談受付から申請、審査、決裁、通知、給付、変更、廃止、年度更新までを一連で試し、正常系だけでなく、住所変更、世帯分離、所得訂正、資格喪失、二重申請、差し戻し、再審査、障害発生などの例外を含めます。

データ移行テストでは、件数が一致するかだけでなく、住民・世帯の紐付け、制度コード、受給資格、認定履歴、給付履歴、未処理案件、添付ファイル、過去帳票を業務上利用できるかを確認します。旧システムのデータをそのまま移せない場合は、変換ルール、移行しない項目、参照用に保管する期間、紙原本の扱い、誤りが見つかったときの訂正責任者を決めます。総件数と制度別・年度別・状態別の内訳を突合し、移行リハーサルを少なくとも複数回行います。

受入テストの完了条件は、重大な未解決不具合がないこと、業務責任者がシナリオを承認したこと、帳票・通知・連携結果が確認できたこと、権限とログが想定どおりであること、移行後の照合結果が基準内であることです。テスト結果を口頭で済ませず、シナリオ、期待結果、実績、証跡、判定、残課題、対応期限を記録します。住民サービスに直結する処理は、稼働判定会議で業務・情報政策・ベンダーが同じ資料を見て判断します。

本番稼働では、一斉切替、段階切替、並行稼働のどれを採用するかを決めます。一斉切替は旧環境との二重管理を短くできますが、問題が起きた際の影響が大きくなります。段階切替は制度や拠点を分けてリスクを抑えられますが、一定期間は連携と運用が複雑になります。選択は、制度の繁忙期、年度更新、給付日、法定期限、職員数、旧システムの保守期限を踏まえて決めます。

切替計画には、データ最終抽出、変換、取込、照合、権限登録、連携停止・再開、帳票確認、利用者への告知、問い合わせ窓口、障害時のエスカレーション、旧システムの参照方法を含めます。稼働初日から数週間は、ベンダーの現地支援または迅速なリモート支援を確保し、朝会で障害・問い合わせ・処理遅延を共有します。万一に備え、旧システムへ戻せる条件や、紙・代替台帳で受け付ける業務を事前に決めておくと、現場が判断しやすくなります。

稼働後は、システムを使える状態ではなく、正しい業務が安定して回る状態を目指します。職員向け研修は、機能説明を一度行うだけでなく、担当業務別のシナリオ研修、異動者向けの短時間教材、操作マニュアル、よくあるエラーへの対応表を用意します。制度ごとのスーパーユーザーを置き、一次問い合わせを集約すると、同じ質問が個別にベンダーへ流れることを減らせます。

定着度は、ログイン人数だけで判断しません。申請から決裁までの処理時間、差し戻し率、二重入力の件数、帳票作成時間、データ照合のエラー件数、問い合わせの解決時間、電子申請の利用率、制度改正リリース後の不具合件数などを、導入前と比較します。業務KPIを月次または四半期で確認し、使われていない機能を減らす一方、現場の負担が残る工程には追加の設定や周辺ツールを検討します。

制度改正対応は、契約時に「保守に含む」とだけ書かれていると、どこまでが無償か分からなくなります。法令・標準仕様の改定、計算式や帳票の変更、連携先の仕様変更、自治体独自の要望、追加研修を分け、通知から影響分析、改修、受入テスト、リリースまでの流れと料金条件を決めます。2026年以降も標準仕様書は更新されるため、最新版の確認者と改定情報を受け取る窓口を自治体側に置き、年度末に慌てない運用にします。

自治体向け福祉業務システムの費用相場とコストの内訳

自治体向け福祉業務システムの費用は、対象制度、人口・利用者数、パッケージの適合度、データ移行、外部連携、帳票、標準化対応、調達・研修の範囲で大きく変わります。公開価格が少ない分、単純な「1制度いくら」では比較できません。以下の金額は、新規導入価格を断定するものではなく、公開契約の実績と一般的な開発規模から企画段階で置くレンジです。正式な予算は、同じ前提条件でRFI・RFPを実施して確認します。

企画初期の目安として、既存パッケージや標準準拠クラウドを1制度・小規模団体へ導入する場合は、初期費用500万円から3,000万円程度、年額の利用・保守は200万円から1,000万円程度のレンジを置くことがあります。データ移行、住民情報や税との連携、帳票、端末、研修を含めると上限を超えることもあります。複数制度の標準化対応と移行をまとめる場合は3,000万円から1億5,000万円程度、大規模自治体の総合福祉基盤や複数システム連携を含む場合は1億円から数億円程度を仮置きするケースがあります。

公開契約は相場の根拠として参考になりますが、契約の一部を示す実績値です。富田林市の公開資料では、2025年度の介護保険システムJip-Base利用契約が年額2,649,900円、生活保護システム利用料が2025年10月から2026年3月まで924,000円、障害福祉システムの制度改正対応が5,445,000円です。唐津市の2025年度税制改正に伴う介護保険システム改修は1,994,300円でした。いずれも新規導入一式ではなく、利用・改修など個別契約の金額です（出典: 富田林市・唐津市の2025年度公開契約資料、2025年）。

見積書は、初期費用、ライセンスまたはクラウド利用料、要件整理、設定・追加開発、連携、データ移行、帳票、テスト、研修、稼働支援、保守、制度改正、バックアップ、通信、端末、廃棄・旧環境撤去に分けてもらいます。特に「移行一式」「連携一式」「標準化対応一式」という表現は、対象件数や作業内容が分からないため、内訳と前提条件を補足してもらいます。作業時間、対象データ、リハーサル回数、受入テストの範囲、現地支援の日数も確認します。

大阪市の公開資料には、2025年度の総合福祉システムの帳票作成等業務7,018,888円や、情報連携機能改修174,096,670円の契約例があります。後者は大規模自治体の一機能に関する契約であり、総合福祉システム全体の新規導入価格ではありません。大きな数字だけを見て自自治体へ当てはめず、人口、制度、連携本数、開発・保守範囲が近い実績を複数確認することが大切です（出典: 大阪市の2025年度契約関連公開資料、2025年）。

初年度が安くても、毎月の利用料、制度改正の都度の改修、追加帳票、データ抽出、クラウドの通信・バックアップ、問い合わせ、職員研修を含めると、長期費用が高くなることがあります。反対に、初期に移行や研修へ費用をかけることで、二重入力や手作業の照合が減り、職員の処理時間を抑えられる場合もあります。初期費用だけでなく、1年目から5年目までの年次費用と、契約終了時のデータ返却・移行費まで並べて比較します。

5年TCOの表には、各年度の固定費、利用者数や処理件数に応じた変動費、制度改正対応の想定、追加開発単価、障害対応、クラウド利用、端末更新、教育費を記載します。価格の上下だけでなく、何が変動要因かを説明できる見積が信頼できます。将来の自治体間共同利用や制度追加を見込む場合は、追加時の単価とデータ分離、権限分離、契約変更の条件も確認します。

見積もりを取る際のポイントとチェックリスト

見積の精度を上げるには、ベンダーに丸投げするのではなく、自治体側で比較条件をそろえます。特に自治体向け福祉業務システムは、同じ製品名でも制度範囲、標準化の版、移行対象、連携方式、帳票、保守契約が違うと金額が大きく変わります。見積書だけでなく、提案書、要件適合表、前提条件一覧、体制図、スケジュール、リスク一覧を一緒に提出してもらいます。

RFI・RFPには、対象制度、人口、職員数、拠点数、年間の申請・認定・給付件数、ピーク時の処理量、既存システム、連携先、帳票数、保存履歴、電子申請の有無、標準化の状況、希望時期を記載します。制度別に必須機能を示し、自治体独自の運用は「残す」「見直す」「周辺機能に切り出す」の候補として提示します。曖昧な要望を減らすため、現行帳票、データ項目、画面、業務フロー、サンプルケースを添付します。

回答様式には、各要件について、標準機能、設定変更、追加開発、外部製品、業務変更の別、対応時期、追加費用、保守費への影響を記載してもらいます。非機能要件は、可用性、性能、バックアップ、復旧目標、ログ、権限、暗号化、脆弱性対応、監視、データ所在、出口戦略を対象にします。候補を選んだ後に要件を追加する場合の変更管理ルールも、契約前に合意します。

移行費は、データ件数だけでなく、形式、欠損、重複、コード体系、履歴、添付、移行先の項目、変換ルール、照合方法で決まります。見積では、対象年度、対象制度、対象項目、移行しない項目、参照用保管の方法、変換プログラム、リハーサル回数、件数照合、業務担当によるサンプル確認、エラー修正の回数を分けます。旧システムから抽出できるデータ形式と、抽出作業の責任者も確認します。

特に注意したいのは、履歴や例外処理です。現在の資格だけを移行しても、過去の認定理由、支給期間、変更履歴、返還、未処理の申請が参照できなければ、問い合わせや監査に対応できません。移行後の照合で不一致が出た場合に、どのデータを正とし、誰が修正し、いつまでに再取込するかを契約上の成果物と受入条件に含めます。

福祉業務では、障害・介護認定、生活状況、所得、医療費、個人番号など、漏えい時の影響が大きい情報を扱います。提案段階で、データの保存場所、管理区域、暗号化、職員・管理者・保守員の権限、特権操作の記録、ログの保存期間、バックアップの暗号化、脆弱性の通知と修正、インシデント時の連絡時間、再委託先を確認します。個人情報保護委員会の行政機関等向けガイドラインだけでなく、自自治体の情報セキュリティポリシーと特定個人情報の運用もRFPへ反映します。

クラウドの場合は、月額費用だけでなく、通信障害時の業務継続、バックアップからの復旧、利用量の増加、データ返却形式、契約終了時の消去証跡を確認します。AIを相談記録の要約や検索に利用する場合は、入力データが学習に使われるか、保存期間、アクセス権、根拠表示、誤回答時の停止手順、人が最終判断する業務範囲を定めます。便利な機能を先に導入するのではなく、住民への判断や給付を自動化してよい範囲を慎重に線引きします。

会社比較では、製品名や導入自治体数だけでなく、課題に合う得意領域を確認します。総合行政基盤と窓口DXまで一体で検討するのか、複数の社会保障制度を横断するのか、相談・ケース管理を先に整えるのか、障害福祉の実務や施設・事業所との連携を重視するのかで、適した候補は変わります。候補企業には、自自治体と似た人口規模・制度数・移行条件の実績と、担当した範囲を示してもらいます。

また、提案時の担当者が稼働後も関わるか、一次問い合わせの受付時間、現地支援の範囲、障害時の連絡経路、制度改正の受入試験を誰が担うかを確認します。保守契約は、通常問い合わせ、障害、法改正、標準仕様改定、追加要望、データ抽出、研修を分類します。導入時の提案力だけでなく、5年後に担当者・技術・製品が継続しているかを判断する材料を集めることが大切です。

よくある質問（FAQ）

最後に、自治体の担当者が導入前によく確認する質問へ回答します。個別の適合性や費用は自治体の制度範囲、人口、既存データ、連携条件で変わるため、ここでは判断の軸を示します。具体的な計画では、回答をそのまま採用せず、自自治体の要件表と契約条件へ落とし込んでください。

不要とは限りません。標準仕様に含まれる基幹機能は標準に合わせることが基本ですが、自治体独自の帳票、条例に基づく運用、庁内ワークフロー、相談記録、電子申請や窓口との連携は別途設計が必要になる場合があります。標準機能・設定・追加開発・周辺システムのどれで実現するかを分け、標準仕様の改定時に追加費用や再改修が発生するかを契約前に確認します。

移行できる範囲は、旧システムから抽出できる項目、データの品質、移行先の項目定義、履歴の扱い、変換ルールで決まります。現在の資格や未処理案件だけでなく、過去の認定・給付・変更履歴、添付、帳票を業務・監査で参照する必要があるかを先に決めます。移行対象外の情報は、参照用データベース、PDF保管、旧環境の限定的な閲覧などの代替策を含め、保存期間とアクセス権を整理します。

必ず安くなるとはいえません。サーバー保有や更新の負担を減らせる可能性がある一方、クラウド利用料、通信、監視、バックアップ、移行、標準化対応、運用体制の費用が発生します。自治体ごとの利用量や共同利用の条件によっても変わるため、初期費用ではなく、5年TCO、障害対応、データ返却、契約終了時の移行費まで比較します。標準準拠とクラウド利用を同じものと考えず、適合状況と費用を別々に確認することが重要です。

要約、検索、入力補助などの周辺業務から検討する余地はありますが、住民への給付や認定などの最終判断をAIだけに任せる設計は避けます。入力情報が学習に利用されるか、どこに保存されるか、権限のない職員が見られないか、出力の根拠を確認できるか、誤りを発見したときに停止できるかを要件化します。まず匿名化したテストデータで精度と誤りの傾向を検証し、職員が原資料へ戻って確認する手順を定着させます。

まとめ

自治体向け福祉業務システムの導入は、製品を選んで終わるプロジェクトではありません。要件整理で現行業務・標準仕様・自治体独自要件・移行範囲を分け、選定で同じ条件の提案を比較し、設計開発で連携・権限・帳票・保守の責任分界を固めます。その後、制度シナリオとデータ照合を含むテストを行い、切替と業務継続を管理し、稼働後は処理時間や二重入力などのKPIで定着を確認します。

着手時は、(1)対象制度と現行業務の範囲、(2)標準仕様の版と特定移行支援システムの該当状況、(3)連携先・移行履歴・帳票の一覧、(4)個人情報・クラウド・障害時の非機能要件、(5)初期費用から5年TCOまでの見積項目を確認します。各項目に担当課と判断期限を置き、未確定のままRFPや契約へ進めないことが、後からの追加費用と現場負担を抑えます。

最初から全制度を完璧に決める必要はありません。福祉担当課と情報政策課で、制度別の業務フロー、帳票、連携、移行対象を持ち寄り、標準機能で早く安定させる領域と、相談支援など段階的に改善する領域を分けます。そのうえで、候補ベンダーへ同じシナリオを提示し、価格・標準適合・移行品質・セキュリティ・保守体制・定着支援を同じ評価軸で比較すれば、自自治体に合った開発・導入計画を作りやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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