自治体向け福祉業務システムの導入は、6段階で進みます。要件整理から始まり、定着で終わります。制度改正に対応しながら住民サービスを安定して提供するため、各段階で何を決め、何を次の段階へ渡すかを順に確かめていきます。
▼全体ガイドの記事
・自治体向け福祉業務システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
自治体向け福祉業務システムの全体像
自治体向け福祉業務システムは、相談受付から統計・報告までを支える行政基幹システムです。業務には資格確認と認定、支給決定と給付のほか、ケース記録と通知、実績管理もあります。自治体が制度を運用し、住民へ公平にサービスを提供するための仕組みでもあります。
民間の介護事業所向けの請求・記録ソフトとは目的が異なります。そのため、導入時は機能数だけでなく、制度横断のデータ連携、監査可能性、制度改正への追随力を確認します。
自治体向けと民間施設向けの違い
自治体向けと民間施設向けでは、システムが支える業務の範囲が違います。
- 自治体向け：住民情報から資格・認定、支給決定、通知、決裁、行政報告までを扱う
- 民間施設向け：サービス記録や職員配置、請求、ケアプランなど事業所の業務を効率化する
特に自治体向けでは、障害者福祉、介護保険、生活保護、児童福祉、ひとり親・医療費助成、高齢者福祉などを横断して扱います。
「介護に対応」と書かれていても、自治体の認定・給付・報告まで対応しているとは限りません。そのため、RFIでは自治体が保有するどの情報を正とするか、誰がどの業務で参照・更新するかを確かめます。住民の申請をどの決裁につなぐかも、業務単位で確かめておきます。
対象業務と必要な機能の整理方法
対象業務は、制度名ではなく業務の流れに沿って洗い出します。業務単位で並べておくと、製品デモで確認する画面が明確になります。
- 受付・審査：相談、申請、本人確認、資格判定、認定調査、審査会
- 支給・記録：支給決定、受給者証発行、給付・償還、変更・更新、ケース記録、訪問
- 管理・報告：通知、実績集計、監査用出力
各業務の入力者と承認者は、一覧表で分けて書き出します。参照情報や帳票、外部連携に加えて、保存期間と例外処理も同じ表に入れます。
最低限必要な機能の中心は、住民・世帯・宛名との連携と、制度別の資格・認定・支給管理です。所得・課税の参照や、申請・決裁も欠かせません。このほか、帳票・通知や統計・報告の機能が要ります。事業所・請求管理や権限、操作ログ、バックアップも整えます。
電子申請、窓口支援、健康管理、国保、税、マイナンバー関連の連携がある場合は、要件整理の段階でデータ項目と責任分界を決めます。後から連携を足す前提にしないことが大切です。
標準化とガバメントクラウドの捉え方
標準化の対象事務は、標準準拠システムへの移行が前提になります。
デジタル庁は現時点で対象を20事務と説明し、原則として2025年度までの移行を掲げています（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。
- 特定移行支援システム：対象団体が確認する移行計画と支援対象の扱い
- 標準と独自業務：標準仕様の機能・データ・連携は合わせ、条例・地域事情・相談記録・庁内独自業務は周辺機能や連携で実現する
- 仕様書：介護保険の第5.0版が、2025年8月に公開済み
標準化は、すべての業務を一律の運用に変えることを指すものではありません。また、提案書には仕様書の版、対応予定時期、追加費用の有無を記載してもらいます（出典：厚生労働省「介護保険システム標準仕様書」、2025年）。
自治体向け福祉業務システムの進め方
進め方は6段階で、要件整理から始まり、定着で終わります。ただし、段階は一方向に並ぶわけではありません。要件を選定資料に反映したり、設計後にテスト結果を移行計画へ戻したりする循環もあります。
各段階を次へ進めるには、完了条件を決めておく必要があります。未決事項を保留にしたまま契約や本番稼働へ持ち込まないよう、条件を具体的な項目で示します。
フェーズ1：現行業務と目標をそろえる要件整理
要件整理では、関係部署を集めて現行業務と必要な成果物を確かめます。
- 体制：福祉、情報政策、財政・契約、窓口、関連制度の担当者
- 現状把握：繁忙期、制度改正、紙・Excel業務、属人化した判断
- 業務確認：制度別の相談から支給・更新・廃止までの流れ
- 成果物：業務・機能・データ・連携・帳票・非機能・移行・課題・リスク一覧
同じ住民情報を複数の課で入力していないかも、この段階で確かめます。
機能要件には、処理件数や同時利用者数、検索応答時間を書きます。休日・夜間の運用や障害時の代替手順も、併せて記載します。
要件整理の完了時には、必須機能と標準対象外の扱いを合意します。さらに、移行範囲や概算スケジュール、予算化に必要な費目も合意しておきます。
対象の制度と課、申請から報告までの流れは、ここで確定させます。標準仕様と独自要件の線引きや、外部連携の責任者も決めます。移行履歴と機微情報の範囲も、この段階で固めておきます。
要件の確認が曖昧なまま見積もりを比べると、比べているのは価格ではなく、前提条件の違いになります。
フェーズ2：標準適合と実行体制の比較
選定では、RFIで市場を把握したうえで、RFPで同じ条件の提案と見積もりを求めます。RFIとRFPでは確かめる内容が違うため、各社の回答を同じ観点で並べて見ます。
- RFI：標準仕様の版、クラウド構成、実績、移行、制度改正、標準対象外への対応
- RFP：必須・加点・将来要件に分けた提示
- 評価：標準・データ適合、移行品質、セキュリティ、保守、復旧目標、5年コスト
提案者には、各機能をどの方法で実現するかを明示してもらいます。方法は、標準機能、設定、追加開発、運用回避のいずれかです。
評価では、類似団体の導入実績と、自治体側に必要な作業を確かめます。機能の適合だけでなく、記載した評価軸を総合して判断します。
デモでは、住民異動、所得変更、認定更新の操作に加え、支給停止、訂正、帳票再発行などの例外処理を確かめます。
実績を尋ねる際は、自治体数だけでなく、制度範囲や人口規模、連携条件、クラウド構成の近さも聞きます。
可能であれば、稼働後の自治体へのヒアリングや移行リハーサルの内容を確かめます。制度改正時のリリース手順や、問い合わせの一次受付体制も見ておきます。
協力会社や地場SIerが設計・移行・運用を担う場合は、役割分担と責任者を体制図に書いてもらいます。
フェーズ3：設計・開発での変更点と責任分界の確定
設計では、要件を画面や帳票、データに具体化するとともに、権限や連携、運用手順にも落とし込みます。とくに、標準機能で足りる部分と追加開発が要る部分は、設計書で項目ごとに切り分けて記します。
- パッケージ設定：設定値、コード体系、職員・所属の権限、通知文、帳票、バッチ
- 対応範囲：標準機能、設定、追加開発、業務手順変更を設計書で区分
- 連携：データの正、更新時期、エラー検知・再送・通知停止の条件
- 権限・認証：担当課・職位・業務・情報に応じた最小権限、特権ID管理、多要素認証
- 保護策：保存・通信時の暗号化、参照・更新・出力ログ、バックアップ、復旧、委託管理
カスタマイズが将来の標準改定の妨げにならないかも、評価の対象にします。
連携設計の対象には、住民情報や宛名、税・課税が含まれます。さらに、国保、健康管理、電子申請、窓口予約、国や都道府県への伝送先も対象になります。
APIの有無だけでなく、連携方式（日次ファイル、オンライン、手動取込など）、文字コード、コード変換、重複排除、履歴保持、エラー訂正も確かめます。
地方公共団体にも、行政機関等向けの個人情報保護ガイドラインが適用されます。要配慮個人情報や漏えい等の報告について、その考え方が示されています。
出典は、個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（行政機関等編）」です。参照する資料は2025年更新版を使います。
要件書には、ログの保存期間や閲覧できる職員、アラートの通知先、復旧目標を、数値か手順で記します。「安全にする」とだけ書いても、運用条件は伝わりません。
フェーズ4：制度・データ・現場操作の検証
テストでは、機能、業務、移行を検証し、受入条件を記録します。
- 機能・業務：単体・結合テスト後、職員が例外を含む業務シナリオを受入確認
- データ移行：総件数・制度・年度・状態別内訳、紐付け、資格・履歴、未処理案件、添付、帳票を照合
- 完了判定：重大不具合、業務承認、帳票・連携、権限・ログ、照合結果を確認
- 証跡：シナリオ、期待と実績、証跡、判定、残課題、期限の記録
業務シナリオには、相談受付から年度更新までを含めます。また、住所変更や世帯分離、所得訂正、資格喪失、二重申請、差し戻し、再審査、障害発生の場面も試します。
移せないデータは、変換ルールや参照保管期間を決めます。紙原本の扱いと訂正責任者も、あらかじめ定めておきます。
総件数と、制度別・年度別・状態別の内訳を突き合わせ、移行リハーサルを少なくとも複数回行います。
受入テストでは、重大な未解決の不具合がないことを確かめます。そのうえで、業務責任者の承認と、帳票・通知・連携の結果を確認します。
権限とログが想定どおりであること、移行後の照合結果が基準内にあることも、完了条件に含まれます。
住民サービスに直結する処理は、業務、情報政策、ベンダーが同じ資料を見て、稼働の可否を判定します。
フェーズ5：切替方式と業務継続の管理
本番稼働では、一斉切替、段階切替、並行稼働のどれを採用するかを決めます。一斉切替と段階切替では、リスクと運用負荷が異なります。
- 一斉切替：二重管理を短くできる一方、障害時の影響が大きい
- 段階切替：制度・拠点ごとのリスクを抑える一方、連携運用が複雑になる
- 切替計画：最終抽出・取込・照合、権限、連携の停止と再開、告知、問い合わせ
- 継続策：支援体制、旧環境へ戻す条件、紙・代替台帳での業務
方式は、制度の繁忙期や年度更新、給付日を踏まえて選びます。法定期限や職員数、旧システムの保守期限も判断材料になります。
稼働初日から数週間は、現地または迅速なリモート支援を確保しておきます。また、朝会で障害や問い合わせ、処理の遅延を共有します。
切替計画には、障害時のエスカレーションに加えて、旧システムの参照方法も含めます。
フェーズ6：利用状況と制度改正対応の改善
稼働後は、研修や問い合わせ体制、利用状況、制度改正への対応を、継続して見直します。
- 研修：業務別シナリオ、異動者向け教材、操作マニュアル、エラー対応表
- 問い合わせ：制度ごとのスーパーユーザーによる一次受付の集約
- 利用状況：業務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年）。
いずれも新規導入一式の金額ではなく、利用や改修といった個別契約の金額です。
見積金額の費目による分け方
見積書では、導入費と運用費を分けて比べます。費目は、導入、移行・構築、運用・終了の3つに分けると、各社の見積を同じ枠で並べられます。
- 導入：初期費用、ライセンス、要件整理、設定・追加開発
- 移行・構築：連携、データ移行、帳票、テスト、研修、稼働支援
- 運用・終了：クラウド、保守、制度改正、バックアップ、通信、端末、旧環境撤去
「移行一式」「連携一式」「標準化対応一式」といった見積では、対象件数や作業内容が分かりません。そこで、内訳や作業時間、対象データを確かめます。リハーサルの回数、受入テストの範囲、現地支援の日数も確認します。
大阪市の公開資料には、2025年度の契約例として、総合福祉システム帳票作成等業務が7,018,888円、情報連携機能改修が174,096,670円あります。
後者は大規模自治体の一機能に関する契約で、新規導入全体の価格ではありません。そのため、人口や制度、連携本数、開発・保守範囲が近い実績を複数確かめます（出典：大阪市の2025年度契約関連公開資料、2025年）。
5年TCOで比較する理由
運用期間全体の費用を比べるには、初年度の価格だけで判断しないことが要ります。5年TCOでは、継続費、初期投資の効果、比較期間を並べて見ます。
- 継続費：利用料、制度改正、追加帳票、抽出、通信、バックアップ、問い合わせ、研修
- 初期投資の効果：移行・研修で二重入力や手作業照合が減る場合がある
- 比較期間：1〜5年目の年次費用と、終了時のデータ返却・移行費
表には、年度ごとの固定費と、利用者数・処理件数に応じた変動費を分けて書きます。追加開発の単価や障害対応、端末更新、教育費も記載します。
価格の変動要因を説明できる見積もりほど、信頼しやすいといえます。共同利用や制度追加を見込む場合は、追加単価、データと権限の分離、契約変更の条件も確かめます。
見積もりを取る際のポイントとチェックリスト
見積もりの精度を上げるには、自治体側で比較条件をそろえることが欠かせません。同じ製品名であっても、制度範囲や標準化の版、移行対象が違えば、金額は変わります。連携方式や帳票、保守契約の違いも、金額の差になります。
見積書とあわせて、提案書や要件適合表、前提条件の一覧を提出してもらいます。体制図、スケジュール、リスク一覧も求めます。
RFI・RFPに記す条件
自治体の規模や業務範囲をそろえて示すと、各社の提案を同じ条件で比べられます。そのため、RFI・RFPに記す情報を次のとおり整理します。
- 規模：対象制度、人口、職員数、拠点数
- 業務量：年間申請・認定・給付件数、ピーク処理量
- 現行環境：既存システム、連携先、帳票数、保存履歴
- 導入条件：電子申請、標準化状況、希望時期
制度別の必須機能を示します。独自運用は、「残す」「見直す」「周辺機能に切り出す」のどれかを候補として示します。
現行の帳票やデータ項目は、画面や業務フローとあわせて添付します。サンプルケースも付けます。
回答様式では、各機能が標準機能、設定、追加開発、外部製品、業務変更のどれにあたるかを尋ねます。加えて、対応時期や追加費用、保守費への影響も聞きます。
非機能要件には、可用性や性能、バックアップ、復旧目標を含めます。ログや権限、暗号化、脆弱性対応も、要件として書いておきます。さらに、監視やデータ所在、出口戦略も記載します。
候補を決めたあとに要件を追加する場合の変更管理ルールも、契約前に合意しておきます。
データ移行の見積の確認事項
移行の見積もりでは、データ量だけでなく、品質と移行方法も確かめます。
- データ条件：形式、欠損、重複、コード、履歴、添付、移行先項目
- 作業範囲：対象年度・制度・項目、対象外、参照保管、変換プログラム
- 検証：照合方法、リハーサル、件数確認、サンプル確認、エラー修正
旧システムから抽出できる形式と、抽出作業の責任者を明確にしておきます。
現在の資格に加えて、過去の認定理由や支給期間、変更履歴、返還、未処理申請も、参照できる状態にしておきます。これらがなければ、問い合わせや監査への対応が難しくなります。
移行照合で不一致が出た場合に備え、正データ、修正担当、再取込期限を決めます。それらを契約上の成果物と受入条件に含めます。
個人情報・クラウド・保守の確認事項
福祉業務では、障害や介護認定、生活状況、所得、医療費、個人番号など、影響の大きい情報を扱います。そのため、提案の段階で保存場所と管理区域、暗号化を確かめます。権限や特権操作の記録、ログの保存期間も確認します。
- 情報管理：保存場所、管理区域、暗号化、職員・管理者・保守員の権限
- 監視・委託：特権操作、ログ、暗号化バックアップ、脆弱性の通知・修正、事故連絡時間、再委託先
- クラウド：通信障害時の業務継続・復旧、利用量増加、返却形式、終了時の消去証跡
- AI利用：学習利用、保存期間、権限、根拠、停止手順、人の最終判断
個人情報保護委員会のガイドラインに加えて、自治体の情報セキュリティポリシーと特定個人情報の運用も、RFPに反映します。
自治体は、便利な機能を先に導入するのではなく、住民への判断や給付を自動化できる範囲を慎重に線引きします。
開発会社の価格以外の比較軸
自治体の重点課題と導入後の運用を踏まえ、候補となる会社を比べます。
- 得意領域：総合行政基盤・窓口DX、制度横断、相談管理、障害福祉・施設連携
- 導入実績：近い人口規模、制度数、移行条件と担当した範囲
- 稼働後支援：提案担当の継続、受付時間、現地支援、障害連絡、改正テストの担当
- 保守範囲：問い合わせ、障害、法改正、標準改定、追加要望、データ抽出、研修
- 継続性：5年後も担当者、技術、製品が継続するか
よくある質問（FAQ）
個別の適合性や費用は、制度範囲や人口、既存データ、連携条件によって変わります。
各質問では判断の軸を示します。回答は、自治体の要件表と契約条件へ落とし込みます。
標準仕様に準拠していればカスタマイズは不要ですか？
不要とは限りません。基幹機能は、標準仕様に合わせるのが基本です。
一方で、自治体独自の帳票や条例に基づく運用には、別の設計が必要な場合があります。庁内ワークフローや相談記録、電子申請や窓口連携も対象になり得ます。
標準機能、設定、追加開発、周辺システムのどれで実現するかを分けて整理します。標準仕様の改定時にかかる追加費用や再改修も、契約前に確かめます。
既存システムのデータはどこまで移行できますか？
移行範囲は、旧システムから抽出できる項目とデータ品質で決まります。移行先の項目定義や履歴、変換ルールによっても左右されます。
過去の認定・給付・変更履歴や添付、帳票を、業務や監査で参照する必要があるかを先に決めます。
移行しない情報には、参照用データベースやPDF保管、旧環境の限定閲覧などの代替策も含めます。そのうえで、保存期間とアクセス権を整理します。
ガバメントクラウドへ移行すると費用は安くなりますか？
必ず安くなるとは限りません。サーバーの保有や更新の負担は減りますが、クラウドの利用料や通信、監視、バックアップの費用が発生します。移行や標準化対応、運用体制の費用も、あわせて見ておく必要があります。
自治体の利用量や共同利用の条件によっても、費用は変わります。そのため、初期費用だけでなく、5年TCOや障害対応、データ返却、契約終了時の移行費を比べます。
標準準拠とクラウド利用は、それぞれ別に適合状況と費用を確かめます。
福祉の相談記録にAIを利用できますか？
要約や検索、入力補助など、周辺の業務から検討を始められます。住民への給付や認定の最終判断をAIだけに任せる設計は避けます。
入力情報の学習利用と保存場所、アクセス権を要件に定めます。出力の根拠や、誤りを見つけたときの停止方法も盛り込みます。匿名化したテストデータで精度と誤りを検証し、職員が原資料へ戻って確認する手順を定着させます。
まとめ
自治体向け福祉業務システムの導入は、製品選定の後も続く取り組みです。要件整理では現行業務と標準仕様、独自要件、移行範囲を分けます。選定では、同じ条件で各社を比べます。
設計では連携や権限、帳票、保守の責任分界を固め、テストでは制度シナリオとデータ照合を含めて確かめます。稼働では切替と業務継続を管理し、稼働後は処理時間や二重入力などのKPIで定着を確認します。
まず確認する5つの項目
着手時に確認する5項目は、担当課と判断期限とあわせて整理します。
- 対象業務：制度と現行業務の範囲
- 標準化：仕様書の版と特定移行支援の該当状況
- データ：連携先、移行履歴、帳票の一覧
- 非機能要件：個人情報、クラウド、障害時の条件
- 費用：初期費用から5年TCOまでの見積項目
未確定のままRFPや契約へ進まないことが、追加費用と現場の負担を抑えます。
RFI・RFPへ進むための次の一手
RFI・RFPの準備では、関係課が業務と導入方針を整理して共有します。
- 現状を共有：制度別の業務フロー、帳票、連携、移行対象を持ち寄る
- 範囲を分ける：標準機能で安定させる領域と段階改善する領域を整理する
- 同じ軸で比較：価格、標準適合、移行品質、セキュリティ、保守、定着支援
最初から全制度を完璧に決めておく必要はありません。同じシナリオを候補ベンダーへ示すことで、自治体に合う計画を作りやすくなります。
▼全体ガイドの記事
・自治体向け福祉業務システム開発の完全ガイド
▼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を創業。