介護保険システム開発の発注/外注/依頼/委託方法について

介護保険システムの発注・外注は、標準仕様と現行業務を整理し、移行・連携・保守まで含めたRFPで同じ条件の見積もりを比較することが成功の近道です。

介護保険システムは、資格管理、保険料の賦課・収納、要介護認定、給付、通知、統計までを支える自治体の基幹システムです。単に画面を作るだけではなく、住民記録や税・収納、国保連、口座、帳票、認定審査会などとの連携、過去データの移行、制度改正への継続対応をまとめて委託する必要があります。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較、稼働までの進め方を実務の順番に沿って解説します。

▼全体ガイドの記事
・介護保険システム開発の完全ガイド

介護保険システムの発注・外注で最初に知るべき全体像

介護保険システムの発注では、製品の機能数だけで優劣を判断できません。自治体の人口規模、被保険者数、既存ベンダー、データの保有年数、外部インターフェース、独自帳票、標準仕様への適合状況によって、必要な作業と費用が大きく変わるためです。まずは「何を買うか」ではなく、「どの事務を、どのデータと連携させ、いつから、誰が運用するか」を明確にすることが重要です。

介護保険システムは、市区町村が介護保険者として行う事務を一貫して管理する自治体向け基幹業務システムです。被保険者の資格取得・喪失や住所地特例を管理し、所得・世帯情報をもとに保険料を算定します。さらに、要介護認定の申請、訪問調査、主治医意見書、認定審査会、認定結果、更新・変更申請を扱います。

認定後は、受給者、居宅サービス計画作成依頼、施設入退所、負担限度額、減免、償還払い、給付実績を管理し、国保連合会とのデータ交換を行います。窓口照会、通知書、納付書、認定関係資料、統計・国調査、EUCによるデータ抽出も対象になり得ます。したがって、介護保険担当課だけで完結せず、住民記録、税、収納、財政、情報政策、認定審査会など複数部門を巻き込む発注になります。

難しさの中心は、制度に合わせた正確な計算と、自治体ごとに積み重なった個別運用を同時に扱う点にあります。現行システムには、自治体独自のコード、外字、帳票、バッチ、運用例外、手作業の補正が残っていることがあります。これらをそのまま再現しようとするとカスタマイズ費と保守費が増え、すべてを標準機能に寄せると現場の手順変更や教育が増えます。

そのため発注者は、現行機能を一覧化したうえで、標準機能に合わせて廃止する業務、業務手順を変える業務、追加開発する機能、別システムに残す機能を分ける必要があります。厚生労働省は2026年3月に介護保険システム標準仕様書第6.0版を公開しています（出典: 厚生労働省「標準仕様書（介護保険）」、2026年）。RFPには、参照する仕様書の版数と、改版が発生した場合の対応方法まで書いておくことが大切です。

介護保険システムの発注形態はどれを選ぶべきですか？

結論として、介護保険の基幹領域では、標準準拠のパッケージをクラウドまたは共同利用環境で導入し、差分を限定的な追加開発で補う形が比較の出発点になります。ただし、既存基盤、ネットワーク、職員体制、移行期限、独自業務の重要性によって適切な形は変わります。初期費用だけでなく、制度改正、クラウド利用、保守、移行後の運用を含む5年総額で評価します。

標準パッケージ型は、資格、保険料、認定、給付、通知など制度上の共通機能を利用できるため、要件定義から稼働までの見通しを立てやすい方式です。法改正や標準仕様の改版に対応する製品を選べば、自治体が毎回計算ロジックを作り直す負担も抑えられます。業務を標準機能に合わせて見直せる自治体、複数部門の連携を短期間で整えたい自治体に適しています。

クラウド型は、サーバー更改、バックアップ、冗長化、監視の運用負担を抑えやすい点が特徴です。一方で、通信経路、認証、アクセス権限、ログの保管、障害時の責任分界、従量課金、データの返却方法を確認しなければなりません。ガバメントクラウドを前提にする場合は、単に「クラウド対応」と書かれた提案ではなく、対象サービス、構成、可用性、費用の変動条件を明示させます。

オンプレミスや専用環境は、庁内ネットワークや既存の認証基盤を細かく統制したい場合に候補になります。しかし、機器更改、災害対策、バックアップ、運用人材、脆弱性対応を発注者側または委託先が継続して担います。標準化後も長期間利用するなら、次回更改や標準仕様の改版でどの程度の再構築が必要になるかを確認します。

スクラッチ開発は独自の事務や画面を実現しやすい反面、制度解釈、帳票、国保連とのデータ交換、文字要件、移行、法改正への追随を自前で抱えます。独自機能が住民サービスや法令上不可欠なのか、単に従来の慣行で残っているのかをFit & Gapで確認し、スクラッチの採用は最後に判断します。まずパッケージ設定、次に限定的な拡張、その後にどうしても必要な新規開発という順番が安全です。

一括発注は、要件整理、設計、開発、移行、テスト、切替、保守の責任を一つの事業者にまとめやすく、自治体側の調整負担を抑えられます。その一方で、提案内容の妥当性を比較しにくくなり、委託先への依存が強まる可能性があります。RFPでは工程ごとの成果物、費用、受入基準を分けて提示させ、一括価格の中身が見える状態にします。

分離発注は、現状分析やPMO支援、アプリケーション、クラウド基盤、データ移行、第三者検証などを分ける方式です。専門性を活かして相見積もりを取りやすい反面、障害が起きたときに原因と責任の切り分けが複雑になります。分離するなら、統合責任者、連携仕様の管理者、テスト計画の承認者、切替判断者を契約と体制図で決めておく必要があります。

RFPと要件整理はどの順番で進めますか？

RFPは、機能一覧だけを配る資料ではありません。各社が同じ前提で提案と見積もりを作れるよう、現行環境、対象範囲、データ量、連携、非機能、移行、運用、契約条件を一つの前提書にまとめます。作成順序は、現行棚卸し、標準仕様とのFit & Gap、将来業務の決定、RFPの作成、質問回答、提案比較の順番にすると、後から条件が変わりにくくなります。

現行棚卸しでは、資格、保険料、収納、認定、受給者、給付、通知、統計、EUCなどの機能だけでなく、画面、帳票、バッチ、外部ファイル、連携タイミング、権限、ログ、データの保有期間を記録します。担当者へのヒアリングでは、通常業務だけでなく、住所地特例、世帯変更、所得更正、滞納、返戻、認定更新の遅延など、例外処理と繁忙期の作業を確認します。

特に重要なのは、紙や表計算ソフトで補っている作業を見落とさないことです。現行画面に存在しない手作業が新システムの要件になる場合があるため、担当課だけでなく、窓口、収納、認定審査会、委託先、現行ベンダーからも情報を集めます。成果物は、機能一覧、帳票一覧、連携一覧、データ項目一覧、課題一覧、業務フローとして残し、RFPの別紙に流用できる状態にします。

標準仕様との比較では、各機能を「標準で対応」「設定で対応」「追加開発が必要」「業務変更で対応」「対象外または廃止」に分類します。2026年3月18日にデジタル庁が公開した介護保険のデータ要件・連携要件は第8.1版です（出典: デジタル庁「データ要件・連携要件の標準仕様」、2026年）。厚生労働省の機能・帳票要件とデジタル庁のデータ・連携要件は、RFP作成時点の版数を明記して照合します。

RFPの要件章は、機能、データ、連携、非機能、セキュリティ、移行、運用、契約の8章に分けると整理しやすくなります。機能要件には業務フローと帳票を、データ要件には項目、コード、文字、履歴を、連携要件には住民記録、税・収納、国保連、口座、認定関連の入出力と頻度を記載します。非機能要件にはレスポンス、同時利用者、可用性、バックアップ、復旧時間、監視、保守時間を含めます。

データ移行は、契約後に初めて調べる作業ではありません。対象期間、対象項目、履歴の扱い、コード変換、外字・文字化け、欠損値、重複、論理削除、添付資料、移行後の照会方法をRFP段階で決めます。資格、所得、認定、給付、住所地特例、滞納などの代表データをサンプルにし、抽出、変換、取込、件数照合、金額照合、画面照合を試します。

発注者が確認すべき指標は、移行件数だけではありません。資格の有効期間がつながっているか、保険料の年度計算が一致するか、認定の更新履歴を追えるか、給付実績の合計が一致するか、外字が住民向け帳票で正しく表示されるかを確認します。少なくとも本番移行前に複数回のリハーサルを行い、移行時間、差分反映、切戻し方法、担当者の作業手順を記録しておくと、切替日の判断材料になります。

介護保険システムの契約形態と契約前の確認事項

契約形態は、作業の不確実性と成果物の確定度に合わせて選びます。要件が固まり、納品物と受入基準を定義できる工程は請負契約が使いやすく、現行調査やPMO、技術支援のように作業量を確定しにくい工程は準委任契約が適することがあります。導入後のクラウド利用や保守は、利用料・保守サービスの契約として別に管理することも多く、契約を一つにまとめる場合でも内訳を分けておく必要があります。

請負契約では、合意した成果物を完成させ、発注者が検査・受入を行う流れを明確にします。要件定義書、設計書、設定一覧、プログラム、テスト結果、移行結果、操作マニュアルなど、何を納品するのかを成果物一覧にします。受入条件が曖昧だと、動作はしていても帳票の細部、例外処理、性能、移行結果を巡って追加費用や検収遅延が起きやすくなります。

準委任契約では、作業の実施と専門家の支援を対象にするため、発注者側にも意思決定と成果確認の責任が残ります。現状分析、PMO、データクレンジング支援、運用設計など、前提が変わりやすい工程で活用しやすい契約です。作業時間だけを管理するのではなく、会議体、課題管理表、レビュー記録、判断期限などを成果の確認材料にします。

介護保険システムでは、元請けだけでなく、クラウド事業者、帳票印刷会社、移行作業会社、データセンター、保守会社などが関与することがあります。再委託の範囲、事前承認、再委託先の安全管理、事故時の報告、監査への協力、個人情報の取扱いを契約に定めます。再委託先が変わる場合の通知や承認手順も、運用開始後に問題になりやすい項目です。

知的財産については、パッケージの権利を無理に移転させるのではなく、自治体が作成・提供したデータ、設定情報、帳票定義、追加開発部分、マニュアル、テスト成果物をどの範囲で利用できるかを整理します。契約終了時には、標準形式でのデータ返却、返却費用、返却期限、バックアップの消去証明、別ベンダーへの引継ぎ協力を定めます。出口戦略を契約前に確認すると、ベンダーロックインのリスクを見積もりやすくなります。

RFPと契約には、職務別権限、二要素認証、アクセスログ、操作履歴、通信・保存データの暗号化、脆弱性パッチ、マルウェア対策、バックアップ、災害時の復旧、委託先監督を明記します。個人情報保護委員会の医療・介護関係事業者向けガイダンスは、組織的・人的・物理的・技術的な安全管理措置や委託先の監督を示しています（出典: 個人情報保護委員会「医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス」、2025年確認）。自治体の情報セキュリティポリシーとの対応表を提出させると、確認漏れを減らせます。

SLAでは、稼働率、受付時間、障害の重要度、一次回答時間、復旧目標、計画停止の通知、制度改正対応の受付期限、月次報告、違反時の扱いを決めます。特に、計算誤り、帳票出力停止、国保連連携の失敗、個人情報の誤表示、認定審査会の資料閲覧停止など、業務影響の大きい事象を優先度付きで定義します。数字だけのSLAではなく、誰が何をもって復旧と判断するかまで書くことが実務上重要です。

介護保険システムの費用相場と見積もりの内訳

介護保険システムの全国一律の定価や公的な平均額はありません。小規模な制度改正なら数百万円に収まる一方、標準化、データ移行、複数システム連携、クラウド移行を含むと数千万円から数億円に達します。以下の金額は公表された自治体調達額と一般的な工程から組み立てた初期提案段階の推定であり、ベンダーの定価ではありません。

規模の違いを理解するには、自治体が公表した契約額が参考になります。千葉市の介護保険システム標準準拠システムへの移行業務は、履行期間が2025年4月1日から2027年3月31日までで、契約金額は税込6億4,240万円でした（出典: 千葉市「千葉市介護保険システムに係るシステム移行業務委託」、2025年）。この金額は、単純なソフト利用料ではなく、標準化移行に伴う設計、連携、データ、テスト、切替などの範囲を含む案件として読む必要があります。

上越市の福祉系システム標準化・制度台帳移行では、介護保険システムの提案上限額が税込6,999万9,000円で、2026年度4,545万7,000円、2027年度2,454万2,000円に分けられています（出典: 上越市「福祉系システム標準化、各種制度台帳システム移行対応業務委託」、2026年）。一方、唐津市の税制改正に伴う既存システム改修は税込199万4,300円、履行期間は2026年1月5日から3月31日でした（出典: 唐津市「令和7年度税制改正に伴う介護保険システム改修業務」、2026年）。同じ介護保険システムでも、導入・移行と制度改修では金額の意味が異なります。

制度改正、帳票変更、計算ロジックの小規模改修は、既存パッケージを前提に200万〜500万円程度が一つの確認レンジです。小規模自治体の標準機能中心のパッケージ導入・移行は3,000万〜1億円程度、中規模自治体の標準化移行は5,000万〜1.5億円程度が初期検討の目安になります。大規模自治体の標準化・クラウド移行は3億〜8億円程度、スクラッチまたは大幅なカスタマイズは2億〜10億円超になる可能性があります。

これらは人口、被保険者数、データ年数、帳票数、外部インターフェース、拠点数、移行対象、標準仕様との差分で上下します。特に、既存データのクレンジングと移行リハーサル、国保連や住民記録との連携、紙帳票の再現、並行稼働、職員研修を見積もりから抜くと、後から追加費用が発生しやすくなります。安い提案を見つけたときほど、含まれていない作業を確認します。

見積書は、要件定義・Fit & Gap、基本設計、パッケージ設定、追加開発、帳票、外部連携、データ抽出、クレンジング、移行、テスト、研修、切替、運用保守、クラウド利用料の項目に分けてもらいます。移行費を「一式」とせず、対象年度、対象件数、変換ルール、リハーサル回数、差分移行、本番移行、照合方法まで記載させると、複数社で比較しやすくなります。

5年総額では、初期導入費に加えて、月額・年額のクラウド利用料、保守費、制度改正費、標準仕様改版対応、バックアップ、監視、帳票印刷、追加ユーザー、データ返却、次回更改の費用を合計します。移行とデータ品質確認は全体の20〜35%、テスト・切替・研修は10〜20%程度になることがありますが、これは正式な統計ではなく、案件条件を置いた推定です。比率だけで判断せず、各社に同じ作業分解で金額を提示させます。

委託先の選び方と見積比較のポイント

委託先は、知名度や提示価格だけで決めません。同規模自治体の本番稼働・移行実績、標準仕様の適合版、住民記録・税・収納・国保連との連携、データ移行の方法、制度改正への対応、障害時の体制、契約終了時のデータ返却を同じ質問票で確認します。提案書の見栄えよりも、実際の担当者がどの作業をいつ誰が行うかを説明できるかを評価します。

実績を聞くときは、「導入自治体数」だけで終わらせず、人口規模、被保険者数、対象業務、既存ベンダー、データ年数、連携数、稼働時期、移行リハーサル回数、稼働後の障害件数と対応方法を確認します。大規模自治体の実績があっても、自自治体の業務や期限に合うとは限りません。可能であれば、提案担当者だけでなく、実際に移行と運用を担当する責任者に説明してもらいます。

公表資料には、標準化移行と制度改正改修の違いが表れています。千葉市の案件では契約相手が株式会社日立製作所千葉支店で、履行期間は2年間でした。一方、唐津市の改修では、既存の総合行政システムの開発者である株式会社RKKCSにしかできない改修として随意契約が行われています。既存環境を持つ自治体は、現行ベンダーの継続メリットだけでなく、他社への移行可能性とデータ返却条件も比較します。

見積比較では、総額の安い順に並べるのではなく、作業単位をそろえます。要件定義に何人月を含むか、Fit & Gapの対象範囲はどこまでか、追加開発と設定変更をどう区分するか、帳票はいくつか、外部連携は何本か、移行対象は何年度分か、リハーサルは何回か、研修は何回かを確認します。金額が空欄や一式になっている項目は、価格が安いのではなく、条件が未確定な可能性があります。

評価表には、価格だけでなく、機能適合、標準仕様対応、移行計画、連携品質、セキュリティ、プロジェクト管理、保守、5年総額、出口戦略の配点を設けます。たとえば、価格30点、機能・標準仕様20点、移行・テスト20点、体制・実績15点、非機能・セキュリティ10点、契約・保守5点のように、自治体が重視するリスクに合わせて配分します。配点は案件ごとに決め、事前に選定関係者で合意します。

極端に安い提案では、現行調査、データクレンジング、移行リハーサル、帳票調整、連携テスト、職員研修、切替後支援が別費用になっていないかを確認します。また、標準仕様の対象範囲を限定し、追加開発や制度改正を都度見積もる契約になっている場合もあります。見積もりの前提条件、対象外、仮置き、発注者側の作業を一覧にしてもらい、比較表の隣に並べます。

反対に、高額な提案でも、不要な独自機能、過剰な環境、重複する管理費が含まれていることがあります。機能の必要性を「法令・標準仕様上必要」「住民サービス上必要」「業務効率上必要」「従来慣行として残っている」に分け、優先順位を決めます。選定前に代表データを用いたPoCやサンプル移行を行えば、提案書だけでは分からない移行品質と操作性を確認できます。

発注から稼働までの進め方と失敗を防ぐ方法

発注後は、要件定義、設計・設定、追加開発、移行準備、各種テスト、研修・切替、運用開始の工程を分けて管理します。工程ごとに成果物と意思決定を置き、発注者が確認してから次の工程へ進みます。特に、標準仕様の版数、移行対象、帳票、連携、切替日が未確定のまま開発を始めると、後工程で費用と期間が膨らみやすくなります。

体制には、情報政策、介護保険、収納、住民記録、財政、認定審査会、現行ベンダー、委託先の責任者を含めます。週次の進捗会議、月次の意思決定会議、課題・リスク・変更管理の台帳を設け、誰がどの期限で判断するかを明確にします。現場の要望をすべて追加開発に変換するのではなく、標準機能での代替、業務変更、将来対応に振り分ける判断者が必要です。

変更管理では、変更理由、影響する機能、帳票、データ、連携、スケジュール、費用、テスト範囲、承認者を記録します。標準仕様の改版や制度改正が発生した場合も、契約時の変更ルールに沿って扱います。担当者が変わっても判断経緯を追えるように、会議資料だけでなく、課題番号と決定日を残します。

テストは、単体テストや画面確認だけでは不十分です。住民記録からの異動、所得情報の取込、保険料算定、納付・還付、認定結果、給付実績、国保連連携、帳票、通知、権限、バッチ、エラー処理を業務シナリオでつなぎます。通常ケースだけでなく、年度途中の異動、住所地特例、所得更正、認定の変更、滞納、返戻、文字コードの違いなどを含めます。

切替リハーサルでは、データ抽出開始、移行処理、差分反映、件数・金額照合、業務確認、利用開始までの所要時間を測定します。切替に失敗した場合の切戻し条件、旧システムの参照期間、窓口対応、問い合わせ先、休日作業の体制も決めます。並行稼働を省くと短期的には費用を抑えられますが、計算結果や帳票の差異を発見する機会が減るため、業務影響に応じて安全策を選びます。

介護保険システムは、稼働した時点で完成ではありません。制度改正、標準仕様の改版、連携先の変更、帳票変更、セキュリティ更新、職員の異動に対応します。保守契約では、通常保守と有償改修の境界、制度改正への対応時期、緊急パッチ、問い合わせ件数、操作研修、改善要望の受付方法を確認します。

運用開始後は、月次で障害、問い合わせ、処理時間、バックアップ、アクセスログ、未解決課題、制度改正予定を確認します。稼働後3か月や6か月のレビューを契約に含め、現場で増えた手作業や使われていない機能を見直します。これにより、導入時の想定と実際の業務の差を次の改善計画へつなげられます。

よくある質問（FAQ）

ここでは、介護保険システムの発注や外注を検討するときに、特に質問されやすい内容をまとめます。個別の費用や契約条件は自治体の規模と現行環境で変わるため、回答をそのまま発注条件にせず、RFPの前提と照合して確認します。

小規模な制度改正・帳票改修は200万〜500万円程度、標準機能中心の導入・移行は3,000万〜1億円程度、中規模の標準化移行は5,000万〜1.5億円程度が初期検討の推定レンジです。大規模自治体の標準化移行では数億円になる公表事例もありますが、これらは移行、連携、テスト、切替を含むかで意味が変わります。初期費用だけでなく、保守、クラウド、制度改正を含めた5年総額で比較します。

機能だけでなく、人口・被保険者数、データ年数、帳票数、外部インターフェース、独自運用、希望切替日、標準仕様の版数、移行対象、リハーサル回数、研修、保守、セキュリティ、再委託、データ返却、制度改正費を記載します。各社に同じ前提の作業分解表と対象外一覧を提出してもらうことがポイントです。未確定事項は仮置きの条件と、確定後に金額が変わるルールを明示します。

介護保険の基幹業務では、標準パッケージを基本にし、Fit & Gapで必要性が確認できた差分だけを追加開発する方式が比較しやすいです。スクラッチは独自業務を実現しやすい反面、制度改正、標準仕様の改版、帳票、連携、移行、保守を長期に負担します。独自機能が法令・住民サービス・業務継続に不可欠かを確認し、業務変更や設定変更で代替できない場合に限定して検討します。

社数に一律の正解はありませんが、同じRFPを複数社に提示し、少なくとも価格、標準仕様、移行、連携、保守、契約条件を比較できる状態にします。候補は、現行ベンダー、標準パッケージを持つ事業者、クラウド・共同利用に強い事業者、第三者の移行・PMO支援会社など、異なる強みを含めると比較の軸が増えます。候補数を増やしすぎるより、質問回答と提案内容を評価できる体制を整えることが重要です。

まとめ

介護保険システムの発注・外注では、最初に標準仕様、現行業務、データ、連携、期限、運用体制を整理します。そのうえで、パッケージ・クラウド・オンプレミス・スクラッチの違いを5年総額で比較し、RFPには機能だけでなく移行、テスト、セキュリティ、保守、再委託、データ返却まで記載します。

発注前は、標準仕様の版数、Fit & Gapの分類、対象データと移行リハーサル、外部連携の本数、帳票、非機能、権限とログ、障害時の責任分界、制度改正の費用、契約終了時のデータ返却を確認します。見積書は総額ではなく、工程と前提条件をそろえて比較し、安さの裏側にある対象外作業を見落とさないことが大切です。

委託先の選定後も、代表データを使った検証、受入基準の合意、切替リハーサル、稼働後レビューまでを一つの計画として管理します。介護保険システムは制度改正と自治体業務の変化に合わせて運用を続ける基盤です。導入時の価格だけでなく、現場が安全に使い続けられる体制と、将来の移行・返却まで見通せる契約を選ぶことが、長期的な発注成果につながります。

▼全体ガイドの記事
・介護保険システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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