国民健康保険システム開発の発注/外注/依頼/委託方法について

国民健康保険システムの発注は、標準仕様への適合だけでなく、既存データの移行、住民記録・税務との連携、制度改正後の保守までを含めて委託範囲と費用を決めることが成功の条件です。

本記事では、国民健康保険システムを外注・委託する自治体担当者に向けて、発注形態の選び方、RFI・RFPと要件整理、契約形態、2026年時点で確認できる費用相場、委託先選定と見積比較のポイントを順番に解説します。窓口業務を止めない移行や、資格・賦課・収納・給付のデータ整合性まで見据えて、発注前に確認すべき項目を整理します。

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

国民健康保険システムの発注・外注は何から始めますか？

結論から言うと、最初に作るべきものは製品名のリストではなく、現行業務と移行条件を整理した発注方針です。国民健康保険システムは、資格管理、賦課管理、収納管理、滞納管理、給付管理が相互に連動し、住民記録や税務などの外部システムともデータを交換します。そのため、機能だけを比較すると、移行後の責任分界や連携費用が見えにくくなります。

発注前には、加入・脱退、転入・転出、世帯変更、保険料の算定・更正・減免、納付書発行、還付、高額療養費、出産育児一時金、葬祭費、滞納整理などの業務を一覧にします。各業務について、担当課、入力元、処理頻度、締め日、帳票、承認者、外部連携先、例外処理を確認すると、ベンダーへ伝えるべき要件が具体的になります。

同時に、世帯・被保険者の履歴、所得・課税情報、収納消込、給付実績、宛名、行政区分などのデータ項目を確認します。コード体系や文字、欠損、重複、過去年度の保持期間も移行費を左右します。現行資料が不足している場合は、システムの画面一覧だけでなく、職員へのヒアリングと実データを匿名化したサンプルの確認を組み合わせることが有効です。

国民健康保険システムの標準仕様書は、資格、賦課、給付、収納、滞納などの領域ごとに機能要件や帳票を整理しています。厚生労働省の公開ページでは、2026年1月の第1.6版と、各領域の別紙が公開されています（出典: 厚生労働省「標準仕様書（国民健康保険）」、2026年）。RFPには、どの版を基準とするか、改版時にどこまで追随するかを明記します。

現行自治体の独自帳票や独自の承認手順をすべて残す前提にすると、標準化の効果が薄れ、個別改修とテストの費用が膨らみやすくなります。一方で、条例・要綱・住民サービスに直結する差分まで無理に廃止すると、現場が運用できません。標準機能、パラメータ設定、外付け機能、業務運用の変更、個別開発の五つに分けて、差分ごとに採否を決めることが大切です。

発注形態の選び方｜パッケージ・クラウド・共同利用・個別開発

発注形態は、パッケージを導入するか、クラウドで利用するか、複数自治体の共同利用に参加するか、個別開発を行うかで、初期費用・納期・自由度・将来保守が変わります。国民健康保険システムでは、標準仕様に合わせられる範囲が大きいほど、個別開発を減らし、制度改正への追随を委託先に集約しやすくなります。

標準準拠パッケージは、資格・賦課・給付・収納・滞納の基本機能を既製の業務モデルで導入し、自治体ごとの差分を設定や周辺機能で補う発注形態です。初期開発を抑えやすく、複数団体で使われた業務知見や制度改正対応を活用できる点が強みです。ただし、製品が標準仕様のどの版に対応しているか、適合確認の証跡、未対応機能の代替方法を確認する必要があります。

クラウドを選ぶ場合は、アプリケーションの利用料だけで判断しません。ガバメントクラウドの利用料、ネットワーク、バックアップ、監視、障害時の連絡、データ保全、運用管理補助者の支援まで含めた月額・年額を比較します。デジタル庁は標準準拠システムをガバメントクラウド上へ移行する方針を示し、可用性、性能・拡張性、移行性、セキュリティなどの非機能要件も標準化しています（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年確認）。

共同利用は、同じ製品・運用基盤を複数自治体で使い、導入費や制度改正対応費を分担する方法です。単独で大規模な開発体制を持ちにくい自治体でも、運用監視や問い合わせ窓口を整備しやすくなります。発注時には、自治体ごとの設定権限、データの保管場所、障害時の優先順位、共同体から離脱するときのデータ返却条件を確認します。

共同利用で注意したいのは、他自治体の運用に合わせるため、自団体の例外処理が残ることです。参加前に、世帯異動、賦課更正、減免、還付、給付審査、年度切替の代表ケースを持ち寄り、設定で対応できる範囲をデモで確認します。費用が安く見えても、独自帳票や外部連携がオプションになる場合は、5年分の総額で比較することが重要です。

スクラッチや大幅な個別改修は、自治体独自の業務や帳票を再現しやすい一方、要件定義、テスト、制度改正、担当者交代後の保守を長期にわたって負担します。国保の中核業務を個別開発する前に、標準機能、設定、外付けサービス、業務手順の変更で代替できないかを検討します。

個別開発を残す場合は、標準仕様から外れる理由、対象業務、改修費、受入テスト、改版時の影響調査、保守担当、終了時の移行方法をRFPに記載します。標準機能と個別機能を同じ契約・同じ見積項目に混ぜると、将来の費用が把握できません。機能単位で責任と価格を分けることが、発注者を守る設計になります。

RFP・要件整理の進め方｜発注仕様書に何を書くべきですか？

RFPには、機能一覧だけでなく、標準仕様の版、データ移行、外部インターフェース、帳票、非機能、研修、保守、制度改正、障害対応、契約終了時のデータ返却までを一つの条件として書きます。候補企業が同じ前提で提案できるように、自治体側の前提条件と、提案者に回答してほしい項目を分離して記載します。

まだ現行資産や予算の幅が見えない段階では、RFIで情報提供を依頼します。RFIでは、標準仕様への適合状況、製品の提供形態、想定する導入期間、移行方式、必要な自治体側の体制、概算費用、制度改正時の対応を質問します。回答をそのまま採用せず、各社に同じ質問を送り、比較可能な形式で回収します。

RFPでは、候補を絞ったうえで、対象業務・利用者・連携先・データ量・稼働時期・予算上限・評価方法を明示します。要求水準が曖昧なまま価格だけを求めると、各社が異なる前提で見積もるため、安い提案が本当に安いのか判断できません。質問回答書や追加資料を正式な調達資料として扱い、後から条件が変わらない運用も必要です。

機能要件には、加入・脱退、異動、資格確認書等の発行、所得連携、保険料の算定・更正・減免、収納消込、督促・還付、滞納整理、療養費・高額療養費などの業務ケースを記載します。単に「資格管理に対応」と書かず、年度切替や訂正、再処理、職員の承認、履歴照会までをシナリオにします。これにより、提案段階のデモと受入テストをつなげられます。

移行要件では、抽出、変換、クレンジング、取込、件数照合、金額照合、エラー修正、再取込、リハーサル、本番切替、切戻しを分けます。非機能要件では、稼働時間、同時利用者数、応答時間、バックアップ、復旧目標、監査ログ、権限、脆弱性対応、災害対策、運用監視を指定します。データを移した後に正しく賦課できることまでを、移行の完了条件に含めることが重要です。

住民記録、個人住民税、固定資産税、収納、口座、国保連合会、オンライン資格確認、マイナンバー系の共通機能など、国民健康保険システムの周辺には複数の連携先があります。RFPには、連携方向、頻度、形式、件数、エラー時の再送、照合方法、連携停止時の業務継続策を記載します。

特に、住民記録の異動が国保の資格へ反映されるタイミング、所得情報の確定後に賦課を再計算する責任、収納消込の不一致を誰が調査するかを明文化します。複数ベンダーが関わる場合は、アプリ、クラウド基盤、ネットワーク、連携ミドルウェア、帳票印刷、端末、ヘルプデスクごとに責任者を決めます。障害が起きたときに「相手のシステムが原因」と言い合う状態を防ぐための要件です。

契約形態と委託範囲の決め方｜一括請負と準委任はどう使い分けますか？

契約形態は、成果物と完成条件を固定できる範囲は請負、調査・支援・運用のように作業内容を柔軟に調整したい範囲は準委任とする考え方が基本です。国民健康保険システムでは、要件定義から本稼働までを一つの契約にまとめるより、工程ごとに成果と責任を定義したほうが、変更管理と検収がしやすくなります。

請負契約に向くのは、要件定義書、基本設計書、移行計画、テスト計画、操作マニュアル、設定済みのシステムなど、成果物と完成条件を明確にできる業務です。契約書や仕様書には、検収単位、検収期間、未達時の再作業、重大障害の定義、保証期間、損害賠償の範囲、再委託の条件を記載します。

一括請負に見えても、制度改正や標準仕様の改版で要求が変わる可能性があります。変更要求を無償対応と追加契約に分ける基準、見積の算定方法、承認者、納期への影響をあらかじめ決めます。特に年度切替、賦課更正、給付支給、帳票の法定様式に関わる変更は、費用とテストの扱いを曖昧にしないことが大切です。

準委任契約は、現行調査、RFI・RFP作成支援、FIT&GAP、プロジェクト管理、移行リハーサル支援、職員研修、稼働後の伴走など、専門家の作業や助言を得たい場面に向きます。成果物だけでは品質を測りにくい場合でも、月次報告、会議体、課題管理表、レビュー記録、稼働時間、担当者のスキルを契約条件に含めると、委託の透明性を高められます。

準委任では、受託者が自治体の指揮命令下で作業するような関係にならないよう、業務分担と連絡系統を整理します。職員の判断を代替するのではなく、選択肢の整理、課題の可視化、テスト支援を委託する形にすると、発注者の意思決定を保ちやすくなります。請負と準委任を工程別に組み合わせる場合は、同じ担当者がどの契約で何を担うかも確認します。

本稼働後の運用保守は、障害対応だけでなく、制度改正に伴う仕様変更、標準仕様の改版、セキュリティパッチ、バックアップ確認、問い合わせ、帳票変更、年度切替の支援まで含めて考えます。初期導入費が低くても、法改正のたびに個別見積が発生する契約では、長期の予算が立ちません。

契約書では、通常保守と追加開発の境界、受付時間、一次切り分け、復旧目標、重大度別の対応時間、計画停止、月次報告、改版の提供時期を定義します。国保業務は年度切替や保険料通知など繁忙期が明確なため、繁忙期の体制と、切替直後の増員・立会いを価格に含めるか確認します。

国民健康保険システムの費用相場と見積項目

国民健康保険システムの費用は、人口だけで一律に決まりません。世帯数・被保険者数、過去データの保持量、外部連携の数、帳票、自治体独自運用、クラウド基盤、移行の難易度、職員研修、保守年数によって大きく変わります。公開調達事例は定価ではありませんが、RFP前の予算仮置きに使える実勢の手がかりになります。

狭い範囲の移行準備では、福島県伊達市が2025年10月に公表した「国民健康保険標準準拠システム移行準備業務委託」が参考になります。2026年度の移行に向けた事前準備を対象に、決定金額は税別96万円でした。これは本体導入費ではなく、現行資料の整理や移行前の準備に近い金額です（出典: 伊達市「令和7年10月31日 入札結果」、2025年）。

一方、神戸市の国民健康保険システム再構築業務は、標準準拠システムへの移行を含む大規模案件で、契約金額は税込34億8,700万円、契約締結から2028年1月3日までの契約期間です（出典: 神戸市「神戸市国民健康保険システム再構築業務」、2025年）。この二つを同じ「国保システムの相場」として平均することには意味がありません。準備、データ抽出、連携、全体再構築を分けて見る必要があります。

RFPの初期目安としては、事前調査・一部準備が100万円前後から、データ抽出・移行や連携を含む案件が数千万円から1億円超、本稼働までの標準化移行が数億円、大規模自治体の再構築が10億円から35億円程度まで広がると整理できます。これは公開事例からの推定レンジであり、製品価格を保証するものではありません。提案依頼では、各社に同じ前提で金額を出してもらうことが重要です。

見積書では、現行調査、要件定義、標準機能の設定、個別開発、データ抽出・変換・取込、外部インターフェース、帳票、クラウド移行、環境構築、テスト、研修、切替・立会いを項目ごとに分けます。さらに、システム利用料、ガバメントクラウド利用料、ネットワーク、運用保守、制度改正、追加サポートを年額で示してもらいます。

2026年3月公表の大津市の標準化移行対応業務では、価格見積書を「標準化対応費用」「システム利用料及び運用保守料（年額）」「ガバメントクラウド利用料（年額）」に分けることが求められていました（出典: 大津市「国民健康保険システム標準化移行対応業務 公募型プロポーザル実施要領」、2026年）。このように費用を分解すると、導入時の安さだけでなく、5年・10年のTCOを比較できます。

5年TCOは、初期費用に5年分の利用料、クラウド、保守、制度改正、バックアップ、端末やネットワーク、職員研修、追加改修を加えて算出します。保守料に含まれる問い合わせの範囲、標準仕様の改版対応、法定帳票の変更、障害時の現地対応をそろえないと、金額だけの比較になります。

見積の前提には、人口・世帯数・被保険者数だけでなく、担当課数、利用者数、ピーク時の処理量、連携先数、帳票数、データ保存年数、移行回数、想定稼働日を記載します。候補企業の見積に前提条件、除外項目、オプション、単価、追加時の算定方法が揃っていれば、提案内容が変わったときにも予算影響を追跡できます。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や見積総額だけで決めません。国保の業務理解、標準仕様への対応、データ移行、外部連携、クラウド、保守、自治体規模の近さを評価し、実際に担当するチームの経験と体制を確認します。提案書の文章だけでなく、代表的な業務シナリオを使ったデモと、質問への回答の具体性を見ます。

実績を聞くときは、「自治体向けの実績があります」という説明で終わらせません。国民健康保険の資格・賦課・収納・滞納・給付のどこを担当したか、標準仕様のどの版に対応したか、人口・世帯規模、移行データ量、外部連携、契約期間、稼働後の保守体制を確認します。可能であれば、同規模の自治体における切替時の課題と、解決方法を匿名化して説明してもらいます。

標準準拠の根拠として、適合確認の状況、機能要件・帳票要件への対応表、未対応項目、代替策、今後の改版予定を提示してもらいます。制度改正対応を自社開発するのか、製品共通版で提供するのかによって、自治体側の検証負担が変わります。担当予定者が提案会だけでなく、要件定義や移行リハーサルにも参加するかも重要な確認項目です。

デモでは、資格異動から資格確認書の発行、所得情報を使った賦課、減免や更正、納付・収納消込、還付、高額療養費の申請・支給、年度切替までを一連のシナリオで見せてもらいます。標準機能でできるのか、設定が必要なのか、個別開発なのか、運用を変えるのかを、その場で回答してもらいます。

デモの評価は画面の見栄えではなく、処理の正確性、履歴の追跡、エラー検知、再処理、帳票、権限、監査ログ、外部連携の状態で行います。職員が普段使う言葉で質問し、例外ケースをあえて含めると、提案書だけでは見えない製品差が分かります。デモで約束された機能は、提案書や議事録に残し、契約後の成果物・検収条件に結び付けます。

評価表では、業務・機能、標準仕様適合、移行計画、連携、非機能、セキュリティ、運用保守、体制、実績、費用、将来性を分けて点数化します。価格の配点を高くしすぎると、移行や保守が弱い提案が有利になります。費用は初期価格だけでなく、5年TCO、追加改修の単価、クラウド利用料の変動条件を評価します。

また、最高点の提案をそのまま採用するのではなく、重大な未達条件がないかを確認します。移行リハーサルの回数、障害時の切戻し、バックアップの復元テスト、繁忙期の応援体制、契約終了時のデータ返却、再委託先の管理は、価格と別に最低条件を設定します。提案評価と契約交渉の記録を残すことが、後の説明責任にもつながります。

よくある質問（FAQ）

国民健康保険システムの発注では、費用だけでなく標準仕様、移行、制度改正、保守を一体で確認する必要があります。ここでは、発注前によくある質問に直接回答します。

事前準備は100万円前後から、大規模な標準化移行・再構築は数億円から35億円程度まで、対象範囲によって大きく異なります。伊達市の移行準備業務は税別96万円、神戸市の再構築業務は税込34億8,700万円でした。どちらも全国共通の定価ではないため、現行調査、移行、連携、保守を分けた見積を取ることが必要です。

標準仕様の版と適合範囲、対象業務、現行資産、データ移行、外部連携、帳票、非機能、セキュリティ、研修、切替、運用保守、制度改正、SLA、データ返却、再委託条件を入れます。あわせて、人口・世帯数、被保険者数、連携先数、帳票数、稼働希望日などの前提条件と、提案者に回答を求める形式をそろえることが大切です。

原則として、標準仕様に適合したパッケージやクラウドを第一候補にし、標準機能・設定・外付けで対応できない明確な理由がある部分だけ個別開発を検討します。スクラッチは独自運用を再現しやすい一方、制度改正、テスト、保守、担当者交代後の引き継ぎの負担が増えやすいため、5年・10年のTCOと継続体制で判断します。

安さだけで選ぶと、移行・連携・制度改正・クラウド利用料・繁忙期支援が別費用になり、契約後に総額が増える可能性があります。前提条件、除外項目、5年TCO、標準仕様への適合、移行リハーサル、障害時の体制をそろえて比較し、最低限の品質条件を満たす提案の中から費用を評価します。

まとめ｜国民健康保険システムの発注を成功させる進め方

まとめとして、国民健康保険システムの発注で特に重要な要点を、発注方針、費用・契約、稼働後の三つに分けて整理します。

最初に現行業務・データ・連携・帳票を棚卸しし、標準仕様に合わせる部分と自治体独自で残す部分を分けます。そのうえで、パッケージ、クラウド、共同利用、個別開発の発注形態を比較し、RFIで候補の違いを把握してから、RFPで条件と評価方法を固定します。

見積は、初期構築だけでなく、移行、外部連携、研修、切替、クラウド、運用保守、制度改正を分け、5年・10年の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を創業。