国民健康保険システム開発の進め方/やり方/流れや方法/手法/工程/手順

国民健康保険システム開発は、標準仕様への適合を起点に、現行業務の棚卸し、外部連携、データ移行、業務テスト、並行稼働までを順番に進める方法が基本です。

国民健康保険システムは、保険料を計算するだけのソフトではありません。資格の取得・喪失、世帯異動、賦課と減免、収納と滞納整理、療養費や高額療養費などの給付、住民記録・税務・国保連合会・オンライン資格確認との連携を支える自治体の基幹システムです。本記事では、自治体の情報政策担当者や国保担当者が、国民健康保険システムをどのような順番で開発・更改すべきか、2026年時点の標準化動向、費用相場、見積もりの確認ポイントまで実務に沿って解説します。

▼全体ガイドの記事
・国民健康保険システム開発の完全ガイド

国民健康保険システム開発の全体像

国民健康保険システムの開発では、機能を追加する前に、住民の異動から通知・給付までの業務とデータの流れを一つの全体像として捉えることが重要です。国保業務の標準仕様は、資格管理、賦課管理、給付管理、収納管理、滞納管理、統計・報告などの領域に分かれ、周辺システムとの接続も前提に定義されます。

資格管理では、加入・脱退、転入・転出、世帯変更、住所や氏名の変更、資格確認書などの証発行と回収を履歴付きで管理します。賦課管理では、所得、資産、世帯人数、軽減・減免の条件から保険料または保険税を算定し、年度切替や更正、通知書発行につなげます。収納・滞納管理では、納付書、口座振替、消込、督促、還付、分納、滞納整理を処理し、給付管理では療養費、高額療養費、出産育児一時金、葬祭費などの申請・審査・支給を扱います。どれか一つの計算精度だけでなく、資格異動が賦課へ反映され、収納結果が還付や滞納へつながる一貫性が求められます。

国保担当課だけで完結する処理は少なく、住民記録から世帯・住所・異動情報を受け取り、税務システムから所得や課税情報を受け取り、収納システムや金融機関から入金情報を受け取ります。さらに、国保連合会や審査支払機関、オンライン資格確認システム、団体内統合宛名、マイナンバー関係の共通機能との連携が必要です。連携要件を後回しにすると、資格は変わったのに賦課が変わらない、還付対象なのに収納消込が反映されないといった不整合が起こりやすくなります。要件定義の段階で、データの項目、更新頻度、送受信方式、エラー時の再送、責任分界を確認します。

第一候補は、国保標準仕様に対応したパッケージやクラウドサービスです。標準機能を活用できれば開発量を抑えやすく、制度改正や標準仕様の改版に追随しやすいからです。2026年時点で厚生労働省は、国保標準仕様書の第1.6版を令和8年1月版として公開し、資格管理、賦課管理、給付管理、収納管理、滞納管理などの別紙も公開しています（出典: 厚生労働省「標準仕様書（国民健康保険）」、2026年）。一方、自治体固有の業務を残す場合は、標準機能の外側に連携・帳票・申請機能を配置する設計が現実的です。スクラッチ開発は、標準機能では対応できない明確な理由がある場合に限り、将来の改修費と保守体制まで含めて選択します。

国民健康保険システム開発の進め方・やり方・流れ

国民健康保険システムの進め方は、現行調査、標準仕様とのFIT&GAP分析、要件定義、設計・構築、移行、テスト、切替、本稼働後の評価という流れです。特に重要なのは、機能一覧だけでなく、年度切替や制度改正、繁忙期の窓口処理を含む業務シナリオで品質を確かめることです。

最初に、資格異動、賦課計算、減免、納付、還付、給付、滞納整理、帳票、統計報告を業務フローに落とし込みます。担当者へのヒアリングでは、標準的な手順だけでなく、例外処理、年度末の締め、再計算、誤入力の訂正、窓口での手作業も記録します。次に、現行画面・帳票・データ項目・連携ファイル・バッチ処理・権限・ログを一覧化し、標準仕様にそのまま適合する機能、パラメータ設定で対応できる機能、業務運用を変える必要がある機能、外付けに分けます。

この段階で自治体独自の運用をすべて残そうとすると、標準化のメリットが失われます。反対に、窓口や給付を支える例外を機械的に削ると、稼働後に職員が表計算や紙へ戻るおそれがあります。制度上必要な処理、住民への影響が大きい処理、廃止・統合できる処理を分け、残す理由と廃止する時期を合意します。

要件定義では、機能要件だけでなく、データ要件、連携要件、性能、可用性、バックアップ、災害対策、監視、アクセス制御、操作ログ、個人情報保護、運用時間、障害時の復旧目標を決めます。ガバメントクラウドを利用する場合は、クラウド利用料、ネットワーク、運用監視、アプリケーションと基盤の責任分界を明文化します。デジタル庁は、地方公共団体の基幹業務システムについて、標準準拠システムへの移行と、データ要件・連携要件の標準仕様を整備しています（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。

RFIでは、標準仕様への適合確認方法、対応版、導入自治体の規模、移行データの件数、連携先、5年・10年の保守費、制度改正の対応範囲を尋ねます。RFPでは、納品物を要件定義書、設計書、テスト計画、移行計画、操作手順書、研修資料、運用設計書、データ返却手順まで細分化します。提案書だけでなく、代表的な住民異動や賦課更正を使ったデモを依頼すると、画面の見栄えでは分からない実務適合性を比較できます。

データ移行では、現行データを抽出し、コードや表記を変換し、欠損・重複・不整合を修正して新システムへ取り込みます。移行対象は現年度だけとは限らず、資格や世帯の履歴、賦課更正、収納残高、還付未済、滞納案件、給付の処理状況、監査に必要な操作履歴まで確認します。抽出件数と取込件数を照合し、合計額、世帯数、被保険者数、未納額、給付額を現行と新システムで突き合わせる検証を行います。

業務テストでは、転入による加入、転出による喪失、世帯分離、所得変更による賦課更正、軽減・減免、年度切替、納付・消込、還付、高額療養費、出産育児一時金、葬祭費、滞納処分を代表ケースにします。さらに、連携ファイルの欠落、同じデータの二重送信、処理途中の障害、権限外操作、帳票の再発行を異常系として試します。リハーサルを少なくとも複数回行い、切替判定基準、停止時間、職員の応援体制、障害時のロールバック方法を決めてから本稼働に入ります。

国民健康保険システム開発の費用相場とコストの内訳

国民健康保険システムの費用は、人口だけでは決まりません。世帯数、既存データの蓄積量、連携先とインターフェース数、自治体独自の帳票・運用、移行回数、ガバメントクラウドの利用形態、研修と稼働立会い、保守年数によって大きく変わります。公開調達額は案件の範囲が異なるため定価ではありませんが、RFP前の予算仮置きには有効な実勢データになります。

小規模な移行準備だけであれば、100万円前後から始まる事例があります。福島県伊達市は、2026年度に標準準拠システムへ移行する国民健康保険システムの事前準備業務を、96万円（税別）で決定しています（出典: 伊達市「令和7年10月31日 入札結果」、2025年）。これは本体の導入費ではなく、現行調査や移行準備に相当する狭い範囲です。さいたま市の標準準拠国保システム向けデータ抽出は3,432万円、唐津市のデータ移行・連携は1億1,594万7,700円という規模で公表されており、移行対象と連携の広さだけでも金額が大きく変わります（出典: 各自治体の公開調達情報、2025〜2026年）。

複数業務・複数年度をまたぐ標準化移行では、数億円規模が現実的な目安になります。大津市の国民健康保険システム標準化移行対応業務は上限4億3,994万1,000円（税込）で、神戸市は標準準拠システムへの再構築業務を34億8,700万円（税込）で契約しています。神戸市の契約期間は契約締結日から2028年1月3日までです（出典: 神戸市「神戸市国民健康保険システム再構築業務・事業者の決定」、2025年）。したがって、準備・一部移行は100万円〜4,000万円、中規模の移行・連携は3,000万円〜1.2億円、本稼働までの大規模な標準化移行は2億〜5億円、政令市級の再構築は10億〜35億円程度を仮置きし、範囲を明確にして補正します。

見積書では、現行調査・企画、FIT&GAP、要件定義、基本設計、詳細設計、パラメータ設定、個別開発、連携開発、帳票、クラウド環境構築、データ抽出・変換・取込、テスト、研修、稼働立会いを分けてもらいます。特にデータ移行は、抽出だけなのか、クレンジング、変換、検証、再抽出、履歴移行、移行リハーサルまで含むのかで費用が大きく変わります。連携費も、1本のファイル連携を単純に数えるのではなく、送信側・受信側・エラー通知・再送・監視・制度改正時の変更まで分解して比較します。

初期費用が安くても、月額のクラウド利用料、ネットワーク、バックアップ、監視、ヘルプデスク、障害対応、制度改正、標準仕様の改版対応、帳票変更、端末更新、職員研修が高ければ、長期の負担は増えます。反対に、初期費用が高くても、標準機能の活用や共同利用によって個別改修と保守を抑えられる場合があります。最低5年、できれば10年のTCOを、初期構築費、移行費、年額保守、クラウド費、制度改正費、追加改修費、終了時のデータ返却費に分けて比較します。

ガバメントクラウドは、サーバーを持たなくてよいという単純な話ではありません。利用料やネットワーク、監視、バックアップ、運用設計を継続的に管理し、アプリケーション側とクラウド側の責任範囲を明確にする必要があります。デジタル庁も2025年以降、標準化・ガバメントクラウド移行後の運用経費に関する対策資料を更新しています（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2025〜2026年）。見積では、利用料の単価だけでなく、データ量やバックアップ世代数が増えた場合の変動も確認します。

国民健康保険システムの見積もりを取る際のポイント

見積もりの比較で重要なのは、金額の小ささではなく、同じ前提で価格が並んでいることです。要件が曖昧なまま一式見積を依頼すると、契約後に移行・連携・制度改正・研修が追加費用になり、予算とスケジュールの両方が崩れます。RFPの段階で対象範囲、前提、除外事項、成果物、検収条件をそろえ、価格と提案内容を同じ評価表で確認します。

発注前に、対象人口・世帯数・被保険者数、担当課と窓口数、年間の資格異動件数、通知書と帳票の種類、過去データの保管年数、連携先、バッチの実行時間、同時利用者数、既存端末、ネットワーク、現行契約の終了時期をまとめます。帳票は名称だけでなく、出力条件、印字項目、宛名、再発行、封入・発送の方法まで整理します。住民記録・税務・収納の各システムが別ベンダーの場合は、データの所有者、連携仕様の提供者、障害時の一次窓口も書き分けます。

RFPには、国保標準仕様書の対象版、適合確認の証跡、標準機能と個別機能の区分、標準仕様の改版に対する保守方針を明記します。さらに、データ返却の形式と期限、契約終了時の移行支援、ログの保存期間、バックアップからの復旧手順、個人情報へのアクセス権限、委託先・再委託先の管理も要求します。将来のベンダーロックインを避けるため、データ項目とインターフェースの説明書を納品物に含めることが大切です。

候補会社は、知名度や営業資料だけで決めません。標準準拠の確認方法、自治体の規模と人口、住民記録・税務との連携実績、データ移行の担当体制、ガバメントクラウドの構成、制度改正時の保守、障害発生時の連絡体制を確認します。国保だけでなく、住民情報や税、収納を含めた実績があるかも重要です。導入自治体へ、移行時の残業、窓口の混乱、制度改正時の対応速度、追加費用の発生状況を確認できれば、提案書に現れないリスクを把握できます。

評価表は、機能適合性、標準仕様への対応、移行計画、連携・非機能、運用保守、プロジェクト管理、価格、提案会社の体制に配点します。価格だけでなく、移行リハーサルの回数、テストケースの網羅性、職員研修の方法、切替後の応援要員を評価対象にします。候補が絞れたら、資格異動、所得変更、賦課更正、納付消込、還付、給付申請を使ったデモと質疑を行い、回答を議事録に残します。

見積もりの除外項目には特に注意します。例えば、現行データの不備は移行対象外、連携先の仕様変更は別途、制度改正は保守契約外、帳票の追加は個別見積、職員研修は1回のみという条件が隠れている場合があります。現行システムの保守会社と新ベンダーのどちらが抽出・変換・検証を担当するのか、連携エラーの一次切り分けを誰が行うのか、稼働後の制度改正を何営業日で提供するのかを確認します。

契約では、成果物、マイルストーン、検収基準、遅延時の報告、変更管理、障害の重大度、復旧目標、再委託、秘密保持、監査ログ、個人情報の取扱い、データ返却を定義します。自治体側の意思決定が遅れた場合と、ベンダー側の作業遅延が起きた場合を分けて、スケジュールを見直す手順を合意します。住民サービスを止めないためには、価格交渉だけでなく、切替時の業務継続計画とロールバック条件を契約・運用設計へ反映することが必要です。

よくある質問（FAQ）

国民健康保険システムの開発では、標準化、費用、期間、パッケージの選び方について多くの質問があります。ここでは、発注前に特に確認しておきたい疑問へ直接回答します。

いいえ、標準仕様への適合だけでは完了しません。住民記録、税務、収納、国保連合会、オンライン資格確認などとのデータ連携、現行データの移行、帳票、職員権限、年度切替、業務テスト、研修、稼働後の制度改正対応まで整えて初めて、住民サービスで使えるシステムになります。

小規模な事前準備や一部移行は数か月で進むことがありますが、標準仕様の確認から設計、移行、複数回のテスト、研修、本稼働まで含めると、1年半〜3年程度を見込む案件が多くなります。例えば神戸市の公開調達は契約締結日から2028年1月3日までの契約期間です。年度切替や制度改正の時期、データ品質、連携先の数で前後するため、稼働日から逆算して移行リハーサルと受入テストの期間を先に確保します。

標準仕様への適合、制度改正への追随、移行の確実性、保守体制を重視する場合は、標準パッケージやクラウドが適しています。独自制度や特殊な業務を維持する場合でも、まず標準機能を使い、必要な部分だけを外付けする方が長期費用を抑えやすいです。スクラッチを選ぶ場合は、なぜ標準機能では対応できないのか、個別開発を将来誰が保守するのか、標準仕様の改版時にどの範囲を再テストするのかを文書化します。

必ず下がるとは限りません。サーバーの保有や更改を抑えられる可能性がある一方、クラウド利用料、ネットワーク、監視、バックアップ、セキュリティ、運用管理、アプリケーションとの責任分界が新たに発生します。初期費用だけで判断せず、利用量が増えた場合と5年・10年のTCO、障害時の復旧方法、データの保管場所を含めて比較します。

まとめ

国民健康保険システム開発を成功させるポイントは、標準仕様に合わせることだけではなく、現行業務とデータを把握し、資格・賦課・収納・給付・滞納のつながりを切らないことです。標準パッケージやクラウドを基本にしながら、自治体独自の運用をFIT&GAPで整理し、必要な機能だけを連携や外付けで補います。

最初に、現行の業務フロー、画面、帳票、データ、連携、契約、制度改正の予定を棚卸しします。次に、厚生労働省の国保標準仕様書の対応版を確認し、標準機能、自治体独自機能、外部連携、移行対象、非機能要件を整理してRFIを実施します。候補会社には同じ業務シナリオでデモを求め、初期構築費だけでなく、移行費、クラウド費、保守費、制度改正費、終了時のデータ返却費を含む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を創業。