国民健康保険システムの開発は、標準仕様への適合、現行業務の整理、連携・移行・テストの順に進めると、住民サービスを保ちながら更改できます。機能を足す前に業務とデータの流れを捉えることが出発点です。そのうえで、現行調査から稼働後の評価まで、5つの工程を順に進めます。
▼全体ガイドの記事
・国民健康保険システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
国民健康保険システム開発の全体像
住民の異動から通知・給付までを一つの全体像として整理しておくと、各業務のつながりを確かめながら進められます。
国保業務の標準仕様は、資格、賦課、給付などの領域に分かれています。また、収納、滞納、統計・報告の領域も含まれます。周辺システムとの接続も前提として定義されているため、領域の中身とあわせて連携の範囲も把握する必要があります。
資格・賦課・収納・給付の一体的な扱い
資格・賦課・収納・給付の4つの業務は、次のようにつながって動きます。
- 資格管理：加入・脱退、転入・転出、世帯変更、住所・氏名変更の履歴と、資格確認書などの証の発行・回収。
- 賦課管理：所得・資産・世帯人数と軽減・減免条件から保険料または保険税を算定し、年度切替、更正、通知書発行まで扱います。
- 収納・滞納管理：納付書、口座振替、消込、督促、還付、分納、滞納整理の処理。
- 給付管理：療養費、高額療養費、出産育児一時金、葬祭費などの申請を審査し、支給まで行います。
資格異動は賦課に反映され、収納の結果は還付や滞納につながるため、この一貫性を保つことが必要です。
周辺システムとのデータ連携が品質を左右する理由
国保担当課だけで完結する処理は少なく、次のシステムや機関とのデータのやり取りが欠かせません。
- 住民記録・税務：世帯・住所・異動情報と、所得・課税情報の受け取り。
- 収納・金融機関：入金情報の受け取り。
- 国保関係機関：国保連合会、審査支払機関との連携。
- 共通機能：オンライン資格確認、団体内統合宛名、マイナンバー関係機能との連携。
連携を後回しにすると、資格は変わったのに賦課が変わらないといった不整合が生じがちです。さらに、還付対象なのに収納消込が反映されない不整合も起こります。
要件定義の段階で、連携ごとにデータ項目と更新頻度、送受信方式を決めておきます。また、エラー時の再送を誰が行うか、どこまでを誰が受け持つかも決めておきます。
標準パッケージ・クラウド・個別開発の使い分け
採用する方式は、標準機能で担える範囲と、自治体固有の業務をどう残すかで決まります。
- 標準パッケージ・クラウド：第一候補です。開発量を抑えながら、制度改正や仕様改版に合わせて更新できます。
- 標準機能と外付け：固有業務の連携・帳票・申請機能を、標準機能の外側に配置します。
- スクラッチ開発：標準機能で対応できない理由が明確な場合に限り選び、改修費と保守体制も踏まえます。
厚生労働省は、国保標準仕様書の第1.6版を令和8年1月版として公開しています（出典：厚生労働省「標準仕様書（国民健康保険）」、2026年）。資格、賦課、給付などの別紙も公開されています。収納や滞納管理の別紙もあるので、採用方式を比べる際の確認先になります。
国民健康保険システム開発の進め方・やり方・流れ
開発は、次の順に工程を進めます。以降の見出し1〜3は、それぞれ工程1、工程2、工程4と5を扱い、工程3の設計・構築は見出しを立てていません。
- 現行調査とFIT&GAP分析
- 要件定義
- 設計・構築
- データ移行とテスト
- 切替と本稼働後の評価
品質は、年度切替や制度改正、繁忙期の窓口処理を含む業務シナリオで確かめます。機能が並んでいるかだけでなく、実際の業務の流れで動くかを見るためです。
1. 現行業務とデータの洗い出しとFIT&GAPの整理
現行調査では、業務フローとシステム資産を洗い出し、標準仕様とどこまで合っているかを整理します。
- 業務フロー：資格異動から滞納整理までの処理と、帳票、統計報告を記録します。
- 例外処理：年度末の締めや再計算、誤入力の訂正、窓口の手作業を、担当者に聞き取ります。
- 現行資産：画面、帳票、データ項目を一覧にします。連携ファイル、バッチ、権限、ログも含めます。
- 適合区分：標準適合や設定対応、運用変更、外付けの区分で整理します。
- 運用判断：制度上必要なもの、住民への影響が大きいもの、廃止や統合が可能なものに分けます。
自治体独自の運用をすべて残すと、標準化のメリットが失われます。一方で、窓口や給付を支える例外を削ると、職員が表計算や紙へ戻るおそれがあります。そこで、発注側は残す処理の理由を確かめ、廃止する処理の時期を開発会社と合意します。
2. 連携・非機能・移行を含めた要件の定義
機能とデータの要件に加えて、非機能や連携を、移行や調達時の確認事項と一体で定めます。
- 非機能：性能、可用性、バックアップ、災害対策、監視、アクセス制御を定めます。操作ログ、個人情報保護、運用時間、復旧目標も対象です。
- クラウド：利用料やネットワーク、運用監視を決め、アプリと基盤のどこまでを誰が負うかを明文化します。
- RFI：標準への適合方法と対応版、導入自治体の規模、移行件数を尋ねます。連携先、5年・10年の保守費、制度改正の対応範囲も含みます。
- RFP：要件定義書、設計書、テスト・移行計画を納品物にします。操作手順書、研修資料、運用設計書、データ返却手順も納品物です。
- 提案確認：住民異動や賦課更正のデモを見て、実務に合うかを比べます。
デジタル庁も、地方公共団体の基幹業務システムについて、標準に準拠した移行と、データ・連携要件の標準仕様を整えています（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。
3. 移行リハーサルと業務テストを重ねた切替
移行とテストは、データの整合、代表業務と異常系、切替条件の順に確かめます。
- 現行データのコードや表記を変換し、欠損・重複・不整合を修正して取り込みます。
- 移行対象は現年度だけとは限らず、資格・世帯履歴、賦課更正、収納残高を確認します。
- 還付未済や滞納案件、給付状況、監査に必要な操作履歴も確認します。
- 抽出・取込件数、合計額、世帯・被保険者数、未納額、給付額を照合します。
- 転入加入、転出喪失、世帯分離、所得変更による賦課更正、軽減・減免をテストします。
- 年度切替、納付・消込、還付を試します。さらに、高額療養費、出産育児一時金、葬祭費、滞納処分も試します。
- 連携ファイルの欠落・二重送信、処理途中の障害、権限外操作、帳票の再発行を確かめます。
- 複数回リハーサルを行い、切替判定基準、停止時間、応援体制、障害時のロールバックを決めます。
切替判定基準を定めてから本稼働に入り、停止時間と職員の応援体制も確かめます。稼働後は、処理時間やエラー件数を測り、その結果をもとに職員とベンダーで改善を重ねます。
国民健康保険システム開発の費用相場とコストの内訳
費用は、人口に加えて、世帯数や既存データの蓄積量、連携先とインターフェース数によって変わります。
自治体独自の帳票や運用、移行回数、ガバメントクラウドの利用形態も費用を左右します。研修や稼働立会い、保守年数も、見積もりに含めておきます。
公開調達額は定価ではなく、RFP前に予算を仮置きする際の実勢データとして活用します。
公開調達事例から見る費用レンジ
小規模な移行準備だけなら100万円前後から始まる事例もあります。ただし、案件ごとに範囲が違うため、事前準備、データ移行、再構築を分けて見ます。
- 事前準備：伊達市は2026年度移行の事前準備業務を96万円（税別）で決定。本体導入費ではありません。
- データ移行：さいたま市の抽出は3,432万円、唐津市の移行・連携は1億1,594万7,700円です。
- 複数業務の移行：複数業務・複数年度の標準化移行は数億円規模が目安です。大津市は上限4億3,994万1,000円（税込）です。
- 大規模再構築：神戸市は34億8,700万円（税込）で契約しました。
- 予算仮置き：準備・一部移行、中規模の移行・連携、大規模移行、政令市級の4区分で幅があります。
伊達市の準備額は、現行調査や移行準備に相当する範囲の金額です（出典：伊達市「令和7年10月31日 入札結果」、2025年）。公開額の違いは、移行対象と連携範囲の広さにも左右されます（出典：各自治体の公開調達情報、2025〜2026年）。
RFP前の予算は、準備・一部移行なら100万円〜4,000万円、中規模の移行・連携なら3,000万円〜1.2億円を仮置きの目安にします。さらに、本稼働までの大規模な標準化移行は2億〜5億円、政令市級の再構築は10億〜35億円程度です。ただし、この仮置きの金額は、案件範囲を明確にしてから補正します。
神戸市の契約期間は、契約締結日から2028年1月3日までです（出典：神戸市「神戸市国民健康保険システム再構築業務・事業者の決定」、2025年）。
初期構築費の工程別の内訳
初期構築の見積もりは、工程と作業範囲が分かるように、次の5つの項目に分けます。
- 企画・設計：現行調査、FIT&GAP、要件定義、基本・詳細設計。
- 構築：設定、個別・連携開発、帳票、クラウド環境構築。
- 移行：抽出・変換・取込、クレンジング、検証、再抽出、履歴移行、リハーサル。
- 稼働準備：テスト、研修、稼働立会い。
- 連携：送受信、エラー通知・再送、監視、制度改正時の変更。
移行費は、抽出だけを含むのか、どこまでの作業を含むのかで変わります。対象になる作業には、クレンジング、変換、検証、再抽出、履歴移行、リハーサルがあります。
連携費はファイル1本ごとに数えず、送受信、エラー通知と再送、監視、制度改正時の変更まで分けて比べます。
クラウド・保守・制度改正を含むTCOでの判断
初期費用が安くても、運用費が高ければ長期の負担は増えます。一方で、初期費用が高くても、標準機能や共同利用で個別改修と保守を抑えられる場合があります。
- 運用費：月額クラウド利用料、ネットワーク、バックアップ、監視、ヘルプデスク、障害対応。
- 継続費：制度改正・仕様改版、帳票変更、端末更新、職員研修。
- 比較期間：最低5年、できれば10年で初期構築、移行、年額保守を比較します。
- 終了・変動費：追加改修、データ返却、利用量増加時の費用も含めます。
ガバメントクラウドには、サーバーを持たなくてよいという以上の論点があります。利用料やネットワーク、監視は継続して管理し、バックアップと運用設計も含めて責任範囲を明確にします。また、利用料は、データ量やバックアップ世代数の増加も見込んでおきます。
デジタル庁は2025年以降、標準化・ガバメントクラウド移行後の運用経費に関する対策資料を更新しています（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2025〜2026年）。
国民健康保険システムの見積もりを取る際のポイント
見積もりは、同じ前提で比べられるかをまず見ます。金額の小ささは、その後で確かめます。要件が曖昧な一式見積では、移行や連携、制度改正、研修が、契約後に追加費用となることがあります。さらに、追加費用は予算だけでなく、スケジュールも崩すおそれがあります。
そこで、RFPで対象範囲と前提、除外事項をそろえ、成果物と検収条件も明記します。価格と提案内容は、同じ評価表で確認します。
現行資料とRFPの前提のそろえ方
見積もりの前提として現行資料をまとめ、RFPには必要な条件を明記します。
- 規模・業務：人口、世帯・被保険者数、担当課・窓口数、年間資格異動件数、帳票種類、過去データ保管年数。
- 帳票・環境：出力条件、印字項目、宛名、再発行を定めます。封入・発送、端末、ネットワーク、契約終了時期も書き添えます。
- 運用・連携：連携先、バッチ時間、同時利用者数、データ所有者、仕様提供者、障害時の一次窓口。
- 適合・保守：標準仕様の対象版・適合証跡、標準・個別機能の区分、改版時の保守方針。
- 安全・終了：返却形式・期限、移行支援、ログ保存期間を定めます。復旧、権限、委託・再委託、データ・IF説明書も含みます。
複数社の同一シナリオと評価軸による比較
会社の知名度よりも、実績や体制、評価軸を同じ条件で確かめます。
- 適合・実績：標準準拠の確認方法、自治体の規模・人口、住民記録・税務・収納との連携実績。
- 体制・運用：移行担当、クラウド構成、改正保守、障害連絡、導入先の残業・窓口混乱・追加費用。
- 評価表：機能適合性、標準仕様、移行計画、連携・非機能に配点します。運用保守、管理、価格、提案会社の体制も対象です。
- 稼働準備：リハーサル回数、テスト網羅性、研修方法、切替後の応援要員を評価。
- デモ・照会：資格異動、所得変更、賦課更正、納付消込、還付、給付申請を試します。
導入自治体には、制度改正への対応速度を尋ねておきます。デモでの質疑と回答は、議事録に残します。
契約前に確かめる追加費用と役割分担
契約後に予算外の作業が生じないよう、除外条件と役割、期限を確かめます。
- 追加費用：見積もりの除外項目と、別料金となる条件を特定します。
- 作業分担：旧保守会社と新ベンダーで、抽出、変換、検証の担当を分けます。
- 対応・成果：制度改正の提供日数、成果物、節目、検収基準、遅延報告、変更管理。
- 運用・情報：障害重大度と復旧目標、再委託、秘密保持を決めます。監査ログ、個人情報、データ返却も対象です。
- 継続計画：自治体の意思決定遅延とベンダー作業遅延を分けた見直し手順。
例えば、データ不備は移行対象外、仕様変更や帳票追加は別料金、制度改正は保守の対象外、研修は1回のみとなる場合があります。連携エラーの一次切り分けを誰が担当するか、制度改正を何営業日で提供するかも確かめます。住民サービスを止めないため、業務継続計画とロールバック条件も運用設計に反映します。
よくある質問（FAQ）
標準化、費用、期間、パッケージの選び方は、発注の前に確認しておきたい疑問が出やすい項目です。
国保標準仕様に合わせれば、開発は完了しますか？
いいえ。完了には、標準仕様への適合に加えて、住民記録、税務、収納、国保連合会、オンライン資格確認などとの連携も必要です。
現行データの移行や帳票、職員権限、年度切替を整え、業務テストと研修、稼働後の制度改正対応まで終えて、初めて住民サービスで使えるシステムになります。
国民健康保険システム開発にはどのくらいの期間がかかりますか？
小規模な事前準備や一部移行は、数か月で進む場合があります。標準確認から設計、移行、複数回のテスト、研修、本稼働まで含めると、1年半〜3年程度を見込む案件が多くなります。
神戸市の公開調達の契約期間は、契約締結日から2028年1月3日までです。年度切替や制度改正、データ品質、連携先数によって、期間は前後します。
稼働日から逆算して、移行リハーサルと受入テストの期間を先に確保しておきます。
パッケージとスクラッチ開発はどちらが適していますか？
標準仕様への適合、制度改正への追随、移行の確実性、保守体制を重視するなら、標準パッケージやクラウドが適しています。
独自業務がある場合は、標準機能を基本に、必要な箇所だけ外付けします。そうすると、長期費用の抑制につながる場合があります。
スクラッチを選ぶ場合は、標準機能で対応できない理由と、将来の保守担当、標準仕様の改版時に再テストする範囲を文書にして残します。
ガバメントクラウドを使うと費用は必ず下がりますか？
サーバーの保有や更改を抑えられる一方で、クラウド利用料やネットワーク、監視、バックアップ、セキュリティ、運用管理がかかるため、費用が必ず下がるとは限りません。
アプリケーションとの責任分担も決めておく必要があります。さらに、初期費用だけでなく、利用量が増えた場合や5年・10年のTCOも比べます。障害時の復旧方法とデータの保管場所も含めて判断します。
まとめ
成功には、標準仕様への適合に加えて、現行業務とデータを把握しておくことが欠かせません。そのうえで、資格・賦課・収納・給付・滞納のつながりを保つことが求められます。
標準パッケージやクラウドを基本にして、FIT&GAPで自治体独自の運用を整理します。必要な機能は、連携や外付けで補う形になります。
現行調査と移行条件の整理から始める順序
まず、現行の業務フロー、画面、帳票、データを一覧にします。連携や契約、制度改正の予定も書き出します。次に、厚生労働省の国保標準仕様書の対応版を確認します。
標準機能と自治体独自機能を分け、外部連携、移行対象、非機能要件を整理してRFIを実施します。候補会社には、同じ業務シナリオでデモを求めます。
初期構築費だけでなく、移行費やクラウド費、保守費、制度改正費、終了時のデータ返却費まで含む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を創業。