後期高齢者医療システムの開発は、業務を洗い出し、標準仕様と現行業務を突き合わせ、移行と連携を確かめる順に進めます。この順番を守ると、稼働後も住民サービスを止めずに運用を続けられます。
▼全体ガイドの記事
・後期高齢者医療システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
後期高齢者医療システムの全体像
後期高齢者医療システムは、原則75歳以上の人と、一定の障害認定を受けた65歳から74歳の人の医療保険事務を支えます。都道府県単位の広域連合が財政運営や資格事務を担い、市区町村は窓口、申請受付、保険料徴収などを受け持ちます。
単独の庁内システムだけでは完結しないため、開発の出発点は業務とデータの境界を把握することです。
市区町村と広域連合の役割分担
市区町村では、住民基本台帳や宛名情報との連携、資格の取得・喪失・住所異動の受付を行います。
- 保険料：所得情報をもとにした賦課、普通徴収と特別徴収の収納、還付・滞納の管理。
- 申請と通知：各種の受付、納付書や決定通知書の出力。
- 広域連合との連携：資格、所得、保険料、給付、収納の情報を、定められた形式と時期に送受信します。
要件定義では、データの正本を持つ団体、送信エラーを再処理する担当、訂正や取消の連携単位を一覧にします。たとえば転入時は、住民記録の更新から資格処理、広域連合への送信、証明書や通知の発行までを、一つの業務シナリオで確かめます。
画面の機能一覧だけで進めると、団体の境界で手戻りが起きやすくなります。
主要機能と周辺システム
まず、標準化の対象となる本体機能と、対象外の補完機能を分けて評価します。独自帳票や窓口機能を本体に作るか、別の申請管理システムで持つかによって、費用と移行方法が変わります。
厚生労働省の標準仕様書（出典：厚生労働省「標準仕様書（後期高齢者医療）」、2026年）では、2026年1月版が第1.4版です。そこで、RFIやRFPでは、参照する版と正誤表の扱いを仕様書に明記します。
- 本体機能：宛名・世帯、資格、所得照会、保険料の賦課・軽減・減免を扱います。
- 徴収・給付：普通徴収・特別徴収・併行徴収、給付や高額療養費の申請の管理。
- 情報活用：広域連合とのデータ交換、帳票、統計・照会・監査用出力。
- 周辺機能：自治体によって医療費助成、健康診査、保健事業、電子申請、コールセンター照会も連携します。
後期高齢者医療システム開発の進め方と工程
標準仕様書を読んで製品を選ぶだけでは、開発工程は管理できません。工程を管理するには、現行業務とデータを先に把握しておく必要があります。そのうえで、標準機能へ合わせる範囲、残す独自要件、廃止する業務を決めます。
発注者が管理しやすいよう、7段階の工程を4つのフェーズに分けて示します。
現状把握・体制設計・RFI
まず、市区町村の国保・年金や情報政策、税の各担当と、住民記録、収納の各担当を洗い出します。あわせて、広域連合や現行ベンダーとの関係も一覧にします。
- 業務とデータ：対象業務、データ所有者、日次・月次・年度処理を業務フローに落とし込みます。
- 現場資料：経験に頼らず、帳票の印刷・封入、画面、CSV、台帳を洗い出します。
- 障害対応：停止時の代替手順と担当者。
複数事業者にRFIを行う際は、標準仕様の対応版や適合確認について質問します。あわせて、ガバメントクラウドの提供形態や移行時期を聞き、データ抽出条件、連携仕様、保守の受け持ち範囲も尋ねます。
横浜市は2025年、後期高齢者医療の標準準拠システム導入と医療費助成システム再構築についてRFIを実施しました。また、標準化対象業務と周辺業務を分けて情報収集しています（出典：横浜市「後期高齢者医療の標準準拠システム導入・医療費助成システム再構築に係るRFI」、2025年）。
Fit & Gap・方式選定・基本設計
標準仕様書の業務フロー、機能・帳票要件、帳票レイアウトを現行業務と並べて、Fit & Gap表にまとめます。項目ごとに対応方法を判定する際は、次の3つに分けて考えます。
- 標準機能：そのまま使うか、設定変更で対応する項目。
- 周辺機能：周辺システムで受けるか、業務のほうを見直す項目。
- 個別開発：標準機能で対応できない要件に限って検討します。
資格異動と所得更正、保険料変更は、通常の処理に加えて訂正や取消も確かめます。
還付や滞納、年度更新も対象で、広域連合への再送も含めます。
方式は、標準仕様の改版にどう追随するか、移行の責任をどちらが持つかで比べます。外字や帳票の扱いと、連携先、障害復旧の方法も見ます。契約終了時のデータ返却も、比較の項目に入れます。
標準パッケージを使う場合も、窓口運用をどう変えるかを決めておかないと、追加開発が膨らみます。
基本設計では構成図を作り、画面、権限、バッチ、インターフェースの関係を描きます。帳票やログ、バックアップも、同じ図に載せます。
データ移行・連携設計・変換
現行データの移行は工数を見積もりにくいため、まず宛名や資格、賦課、収納のデータを抽出して、欠損や重複を確かめます。還付や滞納、給付、送受信履歴も対象に含めます。
移行対象を直近年度だけに絞る場合でも、過去の照会に必要な保存期間は、職員と監査担当を交えて決めます。
- 文字とコード：旧字体や外字、コード体系の違い。
- 保存履歴：所得更正や還付照会に必要な履歴の保管。
- 連携仕様：連携の方向、頻度、項目、再送担当、個人番号の有無を定めます。
住民基本台帳や税、国保との連携を中心に、ほかの連携先も一覧にして洗い出します。収納や口座、広域連合との連携も含めます。さらに、帳票印刷と電子申請との連携も、同じ一覧に加えます。
変換の前後で件数と資格・賦課・収納残高を突き合わせ、その結果を証跡として残します。
外字を標準文字へ置き換えると、通知書の表示や窓口での本人確認に影響が出ます。そこで、代表的な氏名を使って先行テストを行います。
テスト・切替・稼働後運用
テストは、単体と連携、総合、受入の段階に分けます。性能やセキュリティ、障害復旧についても、別に確かめます。異常時の処理も、試験対象に含めます。
- 資格異動：75歳到達、転入・転出、死亡の各ケース。
- 保険料処理：所得更正、保険料変更、普通徴収から特別徴収への切替、還付、滞納を一通り確かめます。
- 連携エラー：広域連合からのエラー返却と再処理の流れ。
受入基準には、帳票の内容と件数、金額を数値で定めます。連携結果や処理時間も、数値で置きます。合格の条件には、画面表示のほかに、これらの数値を含めます。
本番前には、移行リハーサルを複数回行い、切替時間や差分データ、職員の作業分担、切戻し方法を決めておきます。
稼働後は、標準仕様書の改版や制度改正、権限の見直しを定例会で確かめます。ログ監視やバックアップ復元、クラウド費用、問い合わせ件数も、あわせて見ていきます。この確認は、制度改正に追随しながら、住民サービスを止めずに運用を続けるためのものです。
後期高齢者医療システムの方式の選び方
方式は、自治体の規模や既存データ、周辺業務を見て選びます。そのうえで、移行期限と職員体制も判断材料にします。
2026年時点では、標準仕様に適合するパッケージやクラウドを中心に据え、独自要件は設定や連携、周辺機能で吸収する構成が比べやすい選択肢です。
比べる際は、初期費用だけでなく、制度改正への対応を含む5年から10年の総保有コストや、契約終了時に移行できるかも見ます。
標準パッケージを導入する場合
標準パッケージは、資格や賦課、徴収、帳票、広域連合との連携などを備えた方式で、制度対応の実績も確かめやすい点が特徴です。ゼロから作る範囲は減らせますが、現行業務を製品に合わせるBPRが必要になります。
- 仕様適合：対応版と適合確認の証跡を見る。
- 接続・移行：広域連合との接続実績とデータ抽出形式。
- 契約継続：価格表、障害時の応答、再委託先、データ返却、移行支援を確かめる。
既存ベンダーを続ける方法は、短期の切替リスクを抑えられる一方で、データや改修のノウハウが一社に集中します。
「今の会社しか対応できない」と言われた場合も、RFIで代替の可能性を調べます。標準機能と個別改修の価格も、分けて確かめます。
ガバメントクラウドを利用する場合
ガバメントクラウドは、自治体が個別に基盤を保有・運用する負担を抑え、標準準拠システムを共通環境で利用しやすくする選択肢です。
デジタル庁は、2025年度までの移行を原則としています。2026年度以降になるシステムは、特定移行支援システムとして把握し、支援しています。2026年6月30日更新の資料では、標準化対象が20事務と整理されています。
運用経費や標準仕様の更新情報も公開されています（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。
- 費用：利用料、通信、監視、バックアップ、ログ保管、移行、障害復旧、制度改正対応を、項目ごとに分けて示してもらう。
- 利用量：平常月、年度更新月、繁忙期の想定を分けたうえで、月額上限や予算管理を決める。
- 安全性と終了時：保存場所、暗号化、管理者権限、復旧目標、事故報告、データ消去・返却。
スクラッチ開発を選ぶ場合
スクラッチ開発は、複雑な独自業務や周辺システムを細かく再現しやすい方式です。一方で、制度改正や標準仕様の改版、個人情報保護に加え、脆弱性や帳票変更も、長く管理し続ける必要があります。
- 差分の必要性：標準機能との差分が制度上必要かどうか。
- 費用範囲：開発費に加えて、改版や保守の費用を見込む。
- 比較対象：標準パッケージに業務を合わせる場合の変更費用。
差分の必要性を判定しないまま作り始めると、開発費だけでなく将来の保守費も大きくなります。費用には、標準仕様への適合確認と広域連合との接続試験、年度更新を含めます。さらに、移行や研修、障害時の代替運用、担当者交代後の引き継ぎも、見込みに入れます。
標準パッケージを基礎にして、設定や連携、周辺アプリケーションだけを拡張するほうが、将来の改版に対応しやすい場合があります。
後期高齢者医療システムの費用相場とコストの内訳
全国共通の開発費相場はありません。金額は、自治体規模や被保険者数、広域連合との接続で変わります。移行データの品質や帳票数、標準化対象業務の組み合わせ、契約期間も、金額を左右します。
公開調達の金額も、単独の開発費ではなく、移行や基盤、運用保守まで含む個別案件として読み解きます。
公開調達から見る実案件の金額
公開調達の金額を比べる際は、まず案件の範囲と契約期間を確かめます。
- 浦安市：2025年12月公表の過渡期連携業務は158万4,000円です。
- 世田谷区：2025年度調達の提案限度額は税込5億9,070万円です。
- 富田林市：2025年度の過渡期連携対応は1,075万8,000円です。
浦安市の委託は、特定移行支援システムと他の標準準拠システムをつなぐデータ要件・連携要件への適合が目的で、全面再構築は含まれていません。また、既存システムを使い、他業務との接続だけを改修する案件では、数百万円規模になる場合があります。
世田谷区の提案限度額には、移行と2027年度から2031年度までの運用・保守が含まれます。2025年度の移行業務分だけでも、税込5,623万2,000円です（出典：世田谷区「後期高齢者医療標準準拠システム移行及び運用・保守業務委託説明書」、2025年）。
富田林市の案件には、税データ連携やIF・文字変換、テスト、入替、本稼働対応が含まれます（出典：富田林市「令和7年度随意契約一覧表」、2025年）。移行費と長期保守は、分けて比べます。
導入パターン別の概算レンジ
公開案件と自治体基幹システムの一般的な規模をもとにした、初期相談で仮置きする概算です。案件範囲から推定した値で、後期高齢者医療単体の定価とは異なります。
- 過渡期連携・制度改修：150万円から1,500万円程度です。
- 標準準拠パッケージへの移行：3,000万円から1億5,000万円程度です。
- 大規模区や複数業務連携を含む移行：1億円から3億円程度です。
- 独自要件の多い大規模再構築：3億円から8億円を超える場合があります。
期間の目安は、過渡期連携・制度改修が3か月から9か月、標準準拠移行が12か月から24か月です。大規模複数業務移行は18か月から30か月、独自要件を含む再構築は24か月から48か月です。
運用保守やクラウド利用料、監視、バックアップ、制度改正対応は、初期費用と別に、年1,000万円から1億円を超えることがあります。金額を見る前に、含まれる工程と期間を確かめます。
見積書で分けるべき費用
初期費用と年次費用を分け、各社を同じ条件で比べられる内訳にします。
- 初期工程：企画・要件定義、設定・開発、テスト、本番切替の各費用。
- 移行・環境：ライセンス・利用料、データ抽出・クレンジング・変換、連携IF、外字、帳票、端末・印刷の各費用。
- 準備作業：移行リハーサルと職員研修。
- 年次費用：クラウド、通信、監視、バックアップ、ヘルプデスク、制度改正、脆弱性、障害復旧の費用。
移行が「別途」、帳票が「現行踏襲は要相談」、制度改正が「都度見積」の場合は、初期費用が安くても、TCOは上がります。
5年分の保守を含む見積は高く見えても、障害対応や改版費用まで含んでいる場合があります。そこで、同じ内訳と5年・10年の総額を、各社から取り寄せます。
後期高齢者医療システムの見積もりを取る際のポイント
見積もりの精度は、ベンダーの営業力よりも、発注者が示す前提条件の精度で決まります。
業務範囲と標準仕様書の版、移行対象は、同じ資料に書きます。連携先や帳票、テスト、研修、運用期間も、その資料にまとめます。
価格と提案内容は分けて評価します。安さを競わせる前に、見積条件をそろえておきます。
要件と仕様書の明確化
仕様書には、対象団体、対象業務・年度、現行製品を書き込みます。利用者数や処理件数、連携先、帳票数も記し、保存期間や稼働時間、繁忙期、移行対象まで書きます。
- 機能要件：資格、賦課、徴収、給付、通知、検索、統計、広域連合連携の各領域。
- 標準仕様：各要件が、仕様書のどの項目に対応するか。
- 非機能要件：最小権限、多要素認証、通信と保存データの暗号化を定める。
- 運用要件：ログ保存、バックアップ世代、復元テスト、復旧時間を定めます。
- 委託管理：脆弱性対応、再委託先、インシデント報告を含めます。
医療・所得・個人番号を扱うため、要件は「安全に対応する」と書くより、復旧時間やログ保管日数など検査できる条件にします。
複数社の同条件での比較
標準仕様への適合に加えて、直接の実績や広域連合との接続を確かめます。住基・税・国保・収納との連携も、あわせて確認します。
移行データの品質や外字・帳票の扱い、クラウド運用、制度改正への対応、障害時の支援体制も、見ておきます。
- 実績：類似自治体の規模、利用年数、移行回数、保守範囲を、提案書に書いてもらう。
- 評価配点：価格に偏らず、業務適合性から運用保守までを評価する。
- 運営体制：プロジェクト管理と職員教育も評価の対象。
デモでは、通常の住民登録に加えて、所得更正や同一世帯の異動、還付を実演してもらいます。エラー再送や外字表示、帳票再発行も、同じデモで見せてもらいます。
実業務に近い質問をすると、提案書では見えない差がわかります。
データ移行・ロックイン・契約終了時の確認
見積の段階で、抽出形式と費用負担、移行元と移行先の突き合わせの責任を確かめます。外字や古いコード、欠損データを除外する場合は、件数と代替手順を明示します。
- 移行リハーサル：実施回数と、切替後の差分確認者を、契約条件にする。
- 継続契約：保守に含む改修と別料金の改修、仕様改版や制度改正の単価を確認します。
- ベンダー変更：ライセンス、データ返却、仕様書、移行支援、並行稼働の扱い。
見積条件には、契約終了時に自治体がデータと業務を取り戻せるかも含めます。初期費用だけで判断すると、この点は見落とされがちです。
よくある質問（FAQ）
標準化の期限、開発方式、費用、既存ベンダーとの関係について、発注前によくある疑問に回答します。
後期高齢者医療システムは市区町村だけで導入できますか？
市区町村だけで完結させるのは難しいため、広域連合とのデータ授受や、どこまでを誰が受け持つかも含めて計画します。窓口・徴収システムを更改する場合も、連携項目と送受信時期を広域連合側と確かめます。
2026年度になっても標準準拠システムへ移行できない場合はどうなりますか？
原則は2025年度までの移行です。ただし、2026年度以降にならざるを得ないことが具体化したシステムは、特定移行支援システムとして扱われるため、個別の完了期限や支援状況を確かめます。
自団体が該当するかどうかは、デジタル庁などの最新資料と、自治体の移行計画、事業者の対応時期を照らし合わせて判断します。過渡期連携が必要な場合は、移行までのデータ連携費用と期間を、別案件として見積もります。
後期高齢者医療システムの開発費用はどのくらいですか？
過渡期連携や既存パッケージ改修は初期相談時に150万円から1,500万円程度、標準準拠システムへの移行は3,000万円から1億5,000万円程度が目安です。
複数業務の連携や大規模な移行を含む場合、さらに長期保守やクラウド利用料、制度改正が加わると、1億円から数億円規模になることがあります。公開調達は範囲が異なるため、本体や移行、連携、保守を分けて比べます。
既存ベンダーから別の開発会社へ移行できますか？
移行できる可能性はあります。ただし、データ抽出形式や契約上の利用条件、外字、帳票を確かめる必要があります。広域連合との接続、履歴、並行稼働の可否も、あわせて確認します。
RFIで複数社の対応可能性を調べ、現行ベンダーにはデータ返却、仕様書、移行支援、抽出費用を質問します。切替の判断は、初期費用だけでなく、5年から10年のTCOと契約終了時の選択肢で行います。
まとめ
開発では、標準仕様への適合だけでなく、市区町村と広域連合の受け持ちの線引きも計画に含めます。そのうえで、住基・税・国保・収納との連携や移行、帳票、外字を計画に組み込み、制度改正や障害時の業務継続も同じ計画で扱います。
工程は、現状把握から始め、Fit & GapやRFI、方式選定、設計へ進みます。そこから移行、テスト、切替を経て、運用改善に入ります。
費用と品質の同時管理
過渡期連携は150万円から1,500万円程度、標準準拠移行は3,000万円から1億5,000万円程度が目安です。移行や連携、長期保守を含む案件は、数億円規模にもなります。
見積書は、初期費用と移行、連携を分けて示してもらいます。帳票や研修、クラウドの費用も、切り分けて書いてもらいます。保守と制度改正の費用は別に扱い、5年から10年のTCOで比べます。
最初に作る資料
RFIの前に、業務と移行の比較条件を、資料にまとめておきます。
- 業務・構成：現行業務フローとシステム構成図。
- 連携・帳票：連携一覧と帳票一覧をそろえます。
- 移行・責任分界：移行対象データと責任分界表。
- 要件：非機能要件と標準仕様書の対応版を明記します。
- 事業者比較：複数社へのRFIで、継続・標準パッケージ・ガバメントクラウドを価格と実現性で比べる。
制度や標準仕様は更新されるため、発注の直前にも最新の情報を確かめます。
▼全体ガイドの記事
・後期高齢者医療システム開発の完全ガイド
▼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を創業。