後期高齢者医療システム開発の発注/外注/依頼/委託方法について

後期高齢者医療システムの発注・外注は、広域連合とのデータ連携、標準仕様への適合、住民情報・税・収納との接続までを含めて範囲を定めることが成功のポイントです。

本記事では、後期高齢者医療システムを委託する際の発注形態の選び方、RFI・RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、移行・テストの確認項目を順番に解説します。2026年時点で公表されている標準仕様書、自治体の調達事例、RFIの内容を踏まえ、発注担当者が候補企業との打ち合わせにそのまま使える考え方をまとめます。

▼全体ガイドの記事
・後期高齢者医療システム開発の完全ガイド

後期高齢者医療システムを外注する前に知っておきたい全体像

後期高齢者医療システムは、原則75歳以上の人と一定の障害認定を受けた65歳から74歳の人に関する資格、賦課、収納、給付、通知、照会などを扱う業務システムです。制度の財政運営や資格管理を担う後期高齢者医療広域連合と、窓口や保険料徴収を担う市区町村が関係するため、自治体単独のシステムとして閉じない点に特徴があります。

発注前に、資格取得・喪失・住所異動、被保険者情報、所得を使った保険料の賦課、軽減・減免、普通徴収・特別徴収、還付・滞納、給付申請、高額療養費、通知書・納付書の作成を棚卸しします。そのうえで、住民基本台帳、税、国民健康保険、収納、番号連携、電子申請、広域連合とのデータ授受を別の構成要素として整理します。

市区町村側の窓口・徴収機能だけを更改するのか、周辺の医療費助成や保健事業までまとめるのかで、見積もりは大きく変わります。広域連合へ送る資格・所得・収納データの項目、送信周期、エラー時の再送、文字コードや外字の扱いを責任分界表に書き、システム本体と連携作業を同じ費目に埋め込まないことが重要です。

厚生労働省の「標準仕様書（後期高齢者医療）」は、2026年1月に第1.4版が掲載され、同年2月にも正誤表が更新されています（出典: 厚生労働省「標準仕様書（後期高齢者医療）」、2026年）。RFPには参照する版、機能・帳票要件、帳票レイアウト、改版に追随する方法を明記し、候補企業には適合状況を一覧で提出してもらいます。

標準化対象の基幹20業務は原則として2025年度末までの標準準拠システム移行が目標でしたが、2026年度以降の移行が避けられないことが具体化した場合は、特定移行支援システムとして個別の完了期限や支援対象を確認します。デジタル庁は2026年6月30日に特定移行支援システムの把握状況を更新しているため、過渡期の連携を発注する自治体は、現在の対象区分と移行計画を最新資料で確認する必要があります（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。

後期高齢者医療システムの発注形態はどれを選ぶべきですか？

発注形態は、現行ベンダーを継続する方式、標準準拠パッケージへ移行する方式、ガバメントクラウド上のサービスを利用する方式、独自要件を含めてスクラッチ開発する方式に分けて比較します。結論としては、制度・帳票・自治体間連携の標準部分はパッケージや標準準拠サービスで揃え、自治体固有の差分だけを設定や周辺開発で補う方法が現実的です。

現行ベンダーを継続する方式は、既存データの構造、業務運用、帳票、広域連合との接続を把握している点が強みです。短期の過渡期連携や制度改修では、現行資産を活用することで切替リスクを抑えられる場合があります。ただし、現行ベンダーしかデータを抽出できない、移行仕様が開示されない、契約終了後の支援条件が不明確という状態は、将来のロックインにつながります。

継続発注を検討する場合は、随意契約の理由だけでなく、他社が移行できない技術的事情、データ抽出の可否、抽出費用、標準仕様への適合予定、契約終了時のデータ返却と移行支援を確認します。現行ベンダーに依頼する場合でも、RFIで市場の対応可能性と費用水準を調べておくと、提案内容の妥当性を評価しやすくなります。

標準準拠パッケージは、資格管理、賦課、収納、通知、検索、広域連合連携などの業務知識を製品に持つため、ゼロから作るより制度対応を進めやすい方式です。ガバメントクラウドを利用する構成では、基盤の共通化や災害対策を検討しやすくなりますが、クラウド利用料、通信、監視、バックアップ、運用者の権限管理を含めた総保有コストで比較する必要があります。

提案書では「標準対応済み」という説明だけでなく、厚生労働省の標準仕様書のどの版に、どの機能・帳票・連携が適合しているかを一覧にしてもらいます。標準外の機能がある場合は、追加開発で実現するのか、業務を見直すのか、経過措置を使うのかを分けます。将来の改版で追加費用が発生する条件も、見積書と保守契約に記載してもらいます。

スクラッチ開発は、既存パッケージでは対応できない独自の住民サービス、複数制度をまたぐ業務、特殊な連携や分析を組み込みたい場合に候補となります。一方で、制度改正、標準仕様書の改版、脆弱性対応、帳票の変更、広域連合との接続試験、担当者交代後の保守を長期に担う必要があります。「自団体の業務に合わせられる」ことだけでなく、10年程度の運用体制と費用を比較します。

独自開発を選ぶ場合でも、資格・賦課・徴収など制度の共通部分をすべて作り直すのではなく、標準パッケージを中核にして、窓口受付、帳票、データ分析、周辺サービスをAPIで拡張するハイブリッド構成を検討します。独自機能の廃止候補を先に洗い出すと、開発費だけでなく改版時の保守負担も抑えられます。

RFPと要件整理はどのように進めますか？

RFPは「後期高齢者医療システムを作ってください」と依頼する文書ではなく、候補企業が同じ条件で提案・見積できるように、業務範囲、入力、出力、連携、品質、納期、運用条件を整理する文書です。最初から細部を固定しすぎるのではなく、標準機能で対応する部分と、提案を受けたい部分を分けて記載します。

RFIでは、現在のシステム構成、利用部門、被保険者数、データ件数、連携先、帳票数、外字、バッチ時間、繁忙期、移行希望時期、現行契約の終了時期を概要として示します。候補企業には、標準準拠製品の名称と対応版、特定移行支援システムへの対応経験、広域連合との接続実績、データ移行の方法、必要な発注者作業、概算費用、標準的な期間を回答してもらいます。

横浜市は2025年に、後期高齢者医療の標準準拠システム導入と医療費助成システム再構築を対象にRFIを公開しました（出典: 横浜市「後期高齢者医療の標準準拠システム導入・医療費助成システム再構築に係る情報提供依頼」、2025年）。このように、標準準拠システム本体だけでなく周辺制度との関係も早い段階で情報収集すると、後のRFPで範囲を見落としにくくなります。

現行業務を、標準機能で対応できるもの、設定変更で対応できるもの、追加開発が必要なもの、業務を変えることで廃止できるものに分類します。例えば、独自の一覧帳票がある場合は、制度上必須なのか、職員が慣れているだけなのか、標準の検索・出力で代替できるのかを確認します。独自要件をそのままRFPへ転記すると、標準化の効果が失われ、見積比較も難しくなります。

Fit & Gap表には、業務担当者、現行ベンダー、広域連合との連携担当、情報政策担当の確認欄を設けます。資格異動、所得更正、保険料変更、死亡、転出、還付、滞納整理などの例外業務も記載し、担当者の頭の中にある手作業や月次・年度更新の判断を可視化します。

データ移行は、宛名、資格、賦課、収納、還付、滞納、給付、履歴を項目単位で定義し、抽出、クレンジング、変換、突合、エラー処理、移行後の検証までを作業範囲に含めます。外字や旧字体がある場合は、変換表、変換できない文字の扱い、通知書での表示、広域連合との送受信結果を確認します。移行回数を一回とせず、テスト移行、本番前リハーサル、切替後の照合を計画します。

非機能要件には、稼働時間、同時利用者数、バッチの完了時刻、障害時の復旧目標、バックアップ世代、復元テスト、職員の権限、操作ログ、通信・保存データの暗号化、脆弱性対応、再委託先の管理を含めます。住民情報や所得情報を扱うため、機能要件だけで評価せず、個人情報保護、監査、災害時の業務継続を提案書の評価項目に入れます。

後期高齢者医療システムの契約形態はどのように組み合わせますか？

契約形態は、作業の不確実性、成果物の明確さ、発注者側の関与、稼働後の継続性を見ながら分けます。現状調査や要件整理を準委任、仕様と検収条件が定まった開発・移行を請負、稼働後の問い合わせや制度改正対応を保守契約とする組み合わせが基本です。自治体の調達ルールや会計年度、契約手続きとの整合は、法務・契約担当と確認します。

現行システムの解析、業務ヒアリング、Fit & Gap、RFI支援、移行方針、RFP作成は、開始時点で全作業量を確定しにくい業務です。準委任で進める場合は、単に月額と人月だけを合意せず、月ごとの作業計画、会議体、課題一覧、成果物、レビュー期限、投入する専門職の役割を決めます。成果物として、業務フロー、機能一覧、連携一覧、データ移行方針、非機能要件、概算見積の前提を残します。

準委任は仕様変更の自由度がある一方、発注者側の判断が遅れると期間と費用が膨らみます。週次で未決事項を確認し、業務担当者が決めること、情報政策担当が決めること、受託者が提案することを分けます。要件定義の完了条件を「資料を納品した」ではなく、「範囲、優先度、検収方法、残課題の扱いを承認した」と定義することが大切です。

開発やデータ移行を請負で依頼する場合は、成果物、納期、検収条件、瑕疵や不具合への対応、遅延時の扱いを明記します。画面が表示されることだけではなく、資格異動、所得更正、年度更新、還付、広域連合との送受信、帳票印刷、権限とログを含む受入試験に合格することを検収条件にします。

開発途中に標準仕様書の改版や制度変更が発生したとき、契約金額に含まれる範囲と追加費用になる範囲を決めておきます。仕様変更の申請書には、変更理由、影響する機能・帳票・連携、費用、納期、テスト方法、承認者を記録します。固定価格に見せるためにリスクを隠すと、後から追加請求や品質低下につながるため、前提条件を見積書に残します。

運用保守は、問い合わせ、障害一次対応、監視、バックアップ、復元、脆弱性対応、帳票改版、制度改正、標準仕様書改版、クラウド利用料、ライセンスを分けて記載します。年額保守に何が含まれるかが曖昧だと、制度改正のたびに個別見積となり、年度予算の見通しが立ちません。重大度ごとの応答時間、復旧目標、報告期限、再委託先への連絡方法もSLAとして確認します。

契約終了時には、データを発注者が利用できる形式で返却すること、データ辞書や変換仕様を引き渡すこと、次の事業者への移行支援を行うこと、バックアップを含めて不要な複製を消去することを定めます。システムを導入できても、次の更改で移行できなければ、初期費用の安さが長期的な負担に変わります。

後期高齢者医療システムの費用相場と内訳は？

後期高齢者医療システムに全国一律の開発価格はありません。自治体の規模、被保険者数、広域連合との接続数、標準化の状況、現行データの品質、帳票・外字、税や住基など周辺システムの更改時期、契約期間で金額が変わるためです。以下の金額は公開調達をもとにした参考値であり、単独の新規スクラッチ開発の定価ではありません。

小規模な過渡期連携の例では、浦安市の2025年度「後期高齢者システム標準化過渡期連携業務委託」が税込158万4,000円でした。富田林市の2025年度の過渡期連携対応は税込1,075万8,000円で、税データ連携、IF変換、文字変換、連携テスト、入替、本稼働対応などを含む案件です（出典: 浦安市「一社随意契約の公表」、2026年公開、富田林市「令和7年度随意契約一覧表」、2025年度）。同じ「連携」でも対象業務と作業範囲が違うため、単価だけを比べてはいけません。

大規模な移行では、世田谷区の2025年度調達において、標準準拠システムへの移行、プロジェクト管理、2027年度から2031年度までの運用・保守を含む提案限度額が税込5億9,070万円、2025年度移行業務の上限が税込5,623万2,000円でした（出典: 世田谷区「後期高齢者医療標準準拠システム移行及び運用・保守業務委託説明書」、2025年）。移行費と5年分の保守費を分けるだけでも、候補企業の見積比較はしやすくなります。

初期相談の段階では、既存パッケージの過渡期連携・制度改修なら150万〜1,500万円、標準準拠パッケージへの移行なら3,000万〜1億5,000万円、大規模区や複数業務連携を含む移行なら1億〜3億円程度、独自要件の多いスクラッチや大規模再構築なら3億〜8億円超を仮置きの目安にします。これは個別案件の成約価格ではなく、公開調達と自治体基幹システムの作業範囲から推定した予算レンジです。

運用保守・クラウド・制度改正対応は、年1,000万〜1億円超となる場合があります。被保険者数だけでなく、標準仕様書への追随、広域連合との接続、データ移行の回数、帳票の種類、監視時間、職員向けサポート、災害復旧、再委託管理の有無で変わります。予算化では、初期構築費、移行費、接続・テスト費、教育費、保守費、クラウド従量費、制度改正費、5年から10年のTCOを分けます。

見積依頼では、企画・現状調査、要件定義、パッケージライセンス、設定・追加開発、インフラ、クラウド、連携インターフェース、データ抽出・変換・クレンジング、帳票・外字対応、テスト、移行リハーサル、教育、切替、本番後保守を分けます。人月だけでなく、作業単位、数量、単価、前提、除外事項、発注者が担当する作業を記載してもらいます。

特に抜けやすいのは、データの不備を直す作業、広域連合との接続試験、印刷・封入の確認、繁忙期の並行稼働、制度改正での再テスト、障害時の現地対応です。見積書の一式表記は、安く見えても比較できません。候補企業には同じ内訳表を渡し、標準機能、オプション、追加開発、将来費用を分類して回答してもらいます。

委託先選定と見積比較では何を確認しますか？

委託先は、会社規模や知名度だけでなく、後期高齢者医療の業務知識、自治体標準化の経験、広域連合・住基・税・収納との連携力、データ移行の体制、導入後の保守要員を確認して選びます。候補企業の提案を同じ評価表に載せ、価格、標準仕様への適合、移行、品質、セキュリティ、体制、将来の移行可能性を分けて評価します。

実績確認では、「自治体システムの経験があります」という説明で終わらせず、後期高齢者医療のどの業務を、どの規模で、どの製品・クラウド・連携方式で導入したかを聞きます。資格、賦課、収納、給付、通知、広域連合接続、データ移行、外字、年度更新の担当範囲を確認し、今回のプロジェクトに配置される責任者が実績を説明できるかを見ます。

確認できる公開情報として、富士通JapanのMCWEL後期高齢者システムに関する過渡期連携、日立製作所の市区町村向け後期高齢者医療事務支援パッケージ、日本電子計算の自治体向け後期高齢者医療システムの構築・運用などがあります。公開情報は現行製品の提供条件まで保証するものではないため、RFIでは対象自治体規模、標準仕様書の対応版、現在の受注・保守体制を個別に確認します。

見積比較表には、初期費用、移行費用、ライセンス、クラウド、連携、帳票、教育、保守、制度改正、追加開発の単価を並べます。さらに、被保険者数の上限、同時接続数、データ保持年数、移行回数、対応する標準仕様書の版、含まれない作業、発注者側の人員、再委託の有無を同じ列に記載します。金額が安い提案でも、前提が厳しければ実際の費用は増えます。

5年TCOでは、初期費用に毎年の保守・クラウド・通信・監視・ライセンス・制度改正対応を加え、契約終了時の移行費も仮置きします。障害時に現地対応が必要か、夜間・休日の受付が含まれるか、標準仕様書改版の追随が定額か、データ返却に費用がかかるかで、長期の負担は変わります。提案プレゼンでは、通常時よりも「データ移行で不一致が出た場合」「広域連合の再送が必要な場合」「制度改正が短納期で発生した場合」の対応を質問します。

評価項目には、最小権限、多要素認証、職員と管理者の権限分離、操作ログの保全、暗号化、バックアップ、復元試験、脆弱性対応、インシデント報告、災害時のRTO・RPOを入れます。クラウドを利用する場合は、保存場所、ネットワーク分離、サービス停止時の代替運用、クラウド事業者と受託者と自治体の責任分界を説明してもらいます。

再委託がある場合は、再委託先の会社名・担当範囲・アクセス権・監査方法・事故時の責任を確認します。契約終了時に、データ、データ辞書、帳票定義、連携仕様、テストケース、運用手順、ログをどの形式で返却できるかも評価します。ベンダーを選ぶ段階で出口条件まで確認すると、将来の更改で選択肢を残せます。

発注から稼働までの進め方はどうなりますか？

発注は、候補企業へ連絡して見積を取る前に、庁内の目的、対象範囲、責任者、期限をそろえることから始めます。その後、RFI、現状分析、RFP、提案評価、契約、要件定義、設計・設定、移行、テスト、研修、切替、稼働後の安定化という順番で進めます。各工程の完了条件を決め、次工程へ未解決の課題を持ち越す場合は、期限と判断者を記録します。

体制には、業務主管課、情報政策課、調達・契約担当、情報セキュリティ担当、現行ベンダー、広域連合との連携担当を含めます。市区町村だけで決められないデータ項目や送受信タイミングがあるため、広域連合への確認事項を課題管理表に登録します。受託者にはプロジェクト責任者、移行責任者、連携責任者、保守責任者を置いてもらい、担当者の交代時も引き継げる文書を求めます。

会議体は、日々の作業を確認する実務会議、週次の課題・進捗会議、月次の意思決定会議に分けます。課題には発生日、影響、暫定対応、恒久対応、期限、担当、判断者を記録します。特に、標準仕様書の版変更、連携先の仕様変更、移行データの不一致、帳票の印字ずれ、年度更新の遅延は、後半で発見すると切替日へ影響するため、早い段階で管理します。

テストは、単体、連携、総合、受入、性能、セキュリティ、障害復旧に分けます。通常の資格登録だけでなく、75歳到達、転入・転出、所得更正、保険料の変更、死亡、還付、滞納、広域連合からのエラー返却、再送、年度更新をシナリオにします。データ移行では旧システムの件数と新システムの件数を比較し、資格・賦課・収納・還付・宛名の残高や履歴を業務担当者が確認します。

切替前には、本番相当のデータで少なくとも複数回のリハーサルを行い、作業時間、停止時間、照合結果、エラーの修正時間を計測します。切替当日の判断者、切戻しの条件、住民窓口が使う代替手順、広域連合との連絡方法、問い合わせの一次受付を決めます。稼働後は一定期間、旧システムとの照合と問い合わせ件数を確認し、安定化の完了条件を合意します。

標準準拠システムへの移行が完了しても、標準仕様書の改版、制度改正、税・住基側の変更、クラウド基盤の更新、職員の異動が続きます。月次で障害・問い合わせ・処理時間・バックアップ結果を確認し、年度更新前には権限棚卸し、復元テスト、帳票確認、広域連合との接続確認を行います。保守会社任せにせず、発注者が運用状況を判断できる指標を持つことが必要です。

利用部門から出た改善要望は、法令・標準仕様に必要なもの、業務効率化のもの、個別の好みのものに分類します。標準仕様への追随を優先し、独自機能を増やす前に業務手順の見直しや帳票の削減を検討します。標準化の目的はシステムを置き換えることだけではなく、移行後の運用負担を減らし、住民への説明と窓口対応を安定させることです。

よくある質問（FAQ）

後期高齢者医療システムの発注では、費用だけでなく、標準仕様書、広域連合との連携、データ移行、契約終了時の出口条件まで確認する必要があります。ここでは、発注担当者から特に質問されやすい内容を、結論から回答します。

過渡期連携・制度改修なら150万〜1,500万円、標準準拠パッケージへの移行なら3,000万〜1億5,000万円、大規模移行なら1億〜3億円程度が初期予算の仮置きです。公開事例では158万4,000円の過渡期連携から、移行と長期運用保守を含む5億9,070万円の提案限度額まで幅があります。対象範囲と契約年数をそろえて見積を比較してください。

既存ベンダーは現行データや業務を理解しているため、短期の過渡期連携や切替では有力な候補です。ただし、他社の移行可能性、データ抽出条件、標準仕様書への適合、契約終了後の返却・移行支援をRFIや契約書で確認し、継続発注の技術的理由と費用の妥当性を説明できる状態にしてください。

標準仕様書に対応する機能・帳票、現行業務、連携先、データ件数、移行範囲、非機能要件、納期、検収条件、発注者側の作業まで、候補企業が同じ前提で見積できる粒度にします。実装方法まで一方的に固定する必要はありませんが、標準機能、追加開発、提案を受けたい範囲を分け、外字・帳票・例外処理・災害復旧などの抜けやすい条件を明記してください。

現状調査、RFI、要件整理、PoCなど作業量が変わりやすい工程は準委任、仕様・成果物・検収条件が確定した開発や移行は請負が適しやすいです。実際には、要件定義を準委任、開発・移行を請負、運用保守を月額または年額契約に分けます。制度改正や標準仕様書改版の追加費用条件を契約書で確認してください。

まとめ

後期高齢者医療システムの発注・外注では、最初に市区町村と広域連合の役割、資格・賦課・収納・給付・通知・連携の範囲を整理します。次に、標準仕様書の版と移行状況を確認し、現行ベンダー継続、標準準拠パッケージ、クラウド、スクラッチの選択肢を、機能適合だけでなく移行性とTCOで比較します。

RFI・RFPには、Fit & Gap、広域連合との接続、データ移行、外字、帳票、年度更新、受入基準、障害復旧、セキュリティ、再委託、契約終了時のデータ返却を含めます。見積は初期開発費だけでなく、移行、テスト、教育、クラウド、保守、制度改正、5年から10年のTCOまで同じ条件で比較します。候補企業の過去実績は、現行製品と標準仕様書の版を個別に確認してください。

後期高齢者医療システムは、制度業務、自治体調達、データ移行、周辺システム連携を横断して計画する必要があります。発注条件が固まりきっていない段階でも、現状整理やRFIの回答比較から始め、標準化後の運用まで見通した提案を受けることで、開発費だけでは見えないリスクを早期に把握できます。

▼全体ガイドの記事
・後期高齢者医療システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。