住民記録システムの発注は、まず発注範囲を決めることから始まります。そのうえで標準準拠の方式を選び、要件と移行の責任を固めてから見積を比べます。この順で進めると、窓口業務を止めにくい切替につながります。
▼全体ガイドの記事
・住民記録システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
発注前に押さえたい住民記録システムの全体像
住民記録システムは、住民基本台帳を中心に、住民異動、証明書発行、印鑑登録、住基ネット連携、統計処理などを支える自治体の基幹システムです。発注の際は、住民票の保管にとどまらず、戸籍附票、コンビニ交付、マイナンバー利用事務との接続も、業務基盤の一部として含めて見ます。加えて、次の接続も業務基盤の一部として捉えます。
- 税・福祉・選挙との接続
- オンライン申請との接続
住民異動から周辺業務までの発注範囲
見積の前に、発注側が対象業務と周辺システムへ渡すデータを一覧にしておきます。範囲が曖昧なままだと、連携改修や帳票の追加が後から出てきて、予算と納期が崩れやすくなります。
- 異動処理：転入・転居・転出・世帯変更・出生・死亡への対応
- 証明と登録：住民票・除票・転出証明書の発行と印鑑登録
- 連携と管理：住基ネット、戸籍附票、コンビニ交付、宛名番号、統計、操作ログ
- 周辺業務：国保、年金、税、福祉、選挙、健康管理、申請管理へ渡すデータ
2026年の発注で見据える標準化後の運用
標準化の対象事務は現時点で20業務あり、住民基本台帳、戸籍の附票、印鑑登録などが含まれます。
- 移行目標：原則として2025年度までの標準準拠システム移行が目標でした。
- 仕様更新：標準仕様書の更新への対応も、発注時の検討事項です。
- 契約確認：仕様改定への追随方法、法改正対応の費用、移行後の保守体制
また、2026年度も標準仕様書やデータ要件・連携要件の更新が続いています（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年7月28日更新）。
住民記録システムの発注形態の選び方
発注側は、住民記録の中核に標準仕様対応のパッケージか共同利用型クラウドを優先します。そのうえで、自治体固有の差分は周辺機能や運用で吸収するのが現実的です。
個別開発も選択肢に入ります。ただし、標準対象の業務をフルスクラッチで作ると、法改正や仕様改定のたびに追加費用と検証工数が膨らみやすくなります。
標準パッケージと共同利用型クラウドの比べ方
発注側は、標準パッケージと共同利用型クラウドを、機能と運用条件を並べて比べます。
- 標準パッケージ：住民異動、証明書、印鑑、帳票と自治体向け制度対応を導入しやすい方式です。
- 共同利用型クラウド：同じバージョンを複数の自治体で使い、個別保守や更新の負担を抑えます。
- 業務の調整：独自帳票や承認順序を再現できない場合があるので、Fit & Gapで残す業務、変える業務、廃止する業務を決めます。
- 自団体との適合：人口規模、既存ベンダー、移行対象データを同じ条件で見比べます。
移行事例として、TKCは2026年2月、TASKクラウドの全利用団体で、標準仕様対応版への切替とガバメントクラウド移行が完了したと発表しました。同社は共同利用方式とアプリケーション分離を採用し、照会発行サーバーと縮退運用システムで最小限の窓口業務を続ける仕組みも説明しています（出典: 株式会社TKC「自治体の標準仕様対応システム、全団体の移行完了」、2026年2月9日）。
専用クラウドとフルスクラッチの見極め方
専用クラウドとフルスクラッチは、適用範囲と継続運用の条件を見極めて選びます。
- 専用クラウド：他団体と共有せず、クラウドの可用性やバックアップを使いたい場合に候補になります。
- 適する自治体：業務量が大きい、周辺連携が複雑、既存資産を段階的に移行したい場合に利点が出る可能性があります。
- 費用と責任分界：利用料、回線、監視、バックアップ、障害対応の分担を定めます。曖昧なままでは、オンプレミスより安いとは限りません。
- スクラッチの範囲：標準パッケージで扱えない特殊な周辺業務や独自サービスに限ります。
- 選定理由：RFPで、標準製品では代えられない業務効果と維持費の見通しを示します。
中核を独自開発する場合は、標準仕様の改定、制度改正、文字コード、住基ネットの連携仕様を継続して追える組織が必要です。
RFPと要件整理の進め方
RFPは、対象業務、データ、連携を、提案各社の共通の前提にそろえるための文書です。非機能、移行、運用、評価方法も前提の一部として書き込みます。製品名や画面要望の一覧ではありません。
まず現行業務を洗い出し、RFIで市場の方式や移行可能時期を調べます。そのうえで要件を絞ってからRFPを出すと、提案と見積を比べやすくなります。
最初に行う現行業務・データ・例外運用の洗い出し
担当課ごとに業務フローを作り、受付から統計までの処理を確かめます。標準手順から外れる例外や、紙で補う確認、担当者の経験に頼る判断も、あわせて記録します。
- 業務の流れ：受付から照会まで、審査と決裁、入力、証明書発行、訂正・取消を含めて整理します。
- 定期処理：月次・年次の統計まで確かめます。
- データ状態：住民・世帯・住所・異動履歴・除票・印鑑・外字・ログの件数、保存期間、欠損、重複を把握します。
発注者側では、業務一覧、現行業務フロー、データ項目一覧を作ります。連携、帳票、権限、課題についても、それぞれ一覧にしておきます。
調査をベンダーへ委託しても、成果を承認するのは自治体の業務責任者です。承認がないまま進むと、受入試験で認識違いが起きるおそれがあります。
情報政策担当に加えて、住民窓口や戸籍の担当者を早期に巻き込みます。税、福祉、選挙、情報セキュリティの担当者にも、早めに加わってもらいます。
RFPの機能要件・移行要件・非機能要件の書き分け
要件は機能、移行、非機能の3つに分けます。移行範囲や障害時の条件を具体的に書くと、提案各社の見積前提をそろえられます。
- 機能要件：異動・証明書・印鑑・検索・帳票・統計・権限・監査ログと、住基ネット・コンビニ交付の連携を記載します。
- 移行要件：抽出対象、履歴・除票、項目対応、外字同定、データ整備、全件照合、リハーサル回数、本番後の再移行を記載します。
- 非機能要件：性能、稼働、継続、監視、セキュリティの条件を記載します。
過去何年分を移行するか、旧システムを参照用に残すかは、費用と作業量に直結します。
非機能要件では、同時利用者数、繁忙期の応答性能、稼働時間を定めます。バックアップと復旧目標も決めておきます。
加えて、災害時の継続や監視、脆弱性対応も含めます。ログ保管、端末制御、通信と保存データの暗号化についても、条件を書きます。
障害時に住民票の交付や異動の受付をどこまで続けるかは、具体的な業務シナリオに沿ってRFPに書きます。「高可用性」「十分な性能」のような抽象的な言葉のままでは、各社がそれぞれ別の前提で見積もってしまいます。
請負・準委任・サービス利用の使い分け
完成させて引き渡すものと責任範囲をどこまで明確にできるかで、契約形態を選びます。工程やサービスごとに合う契約を整理します。
- 請負契約：要件定義、設計、移行、試験など、完成物を検収する工程に向きます。
- 準委任契約：現状調査やPMO支援など、業務の進行を支援してもらう工程が候補です。
- サービス利用契約：利用料と保守を含め、パッケージやクラウドの利用範囲、SLA、データ返却条件を定めます。
請負契約での成果物・検収・変更管理の具体化
請負では、何を納めるかと検収条件を明確にしておく必要があります。要件を凍結したあとの変更手順も、あらかじめ決めておきます。
- 納品物：要件定義書、基本・詳細設計書、移行計画書を工程ごとに定めます。テスト計画書、試験成績書、操作マニュアル、運用手順書も含みます。
- 検収条件：「動くこと」だけでなく、異動、複雑な世帯変更、証明書、訂正・取消、連携エラー、帳票、権限、監査ログの場面で判定します。
- 追加要望：すべてを無償の変更と考えると、受託者のリスク上乗せや品質低下を招くおそれがあります。
- 変更管理：凍結後の影響範囲、追加費用、納期、試験範囲を記録して承認します。標準仕様改定や法令対応の負担者は、通常変更と分けて契約に書きます。
サービス利用・保守契約のSLAと出口条件
サービス利用と保守では、契約の前に、費用、SLA、終了時のデータ引き継ぎ条件をそろえておきます。
- 利用・運用費：初期費とは別に、月額・年額のソフト利用料、基盤・データベース・バックアップ、回線、監視、ヘルプデスク、法改正対応費が発生します。
- SLAと運用条件：稼働率、計画停止、障害の重大度別の受付時間と復旧目標、問い合わせ上限、事故報告、データ保存場所を決めます。
- データ返却：自治体が読める形式、項目定義、コード表、ログ・帳票の保持期間、返却後の安全な消去を定めます。
- 乗換条件：外字や独自コードのベンダー依存を避けるため、標準形式と変換ルールの所有者を明確にします。
住民記録システムの費用相場と見積内訳
費用は、人口規模や対象業務、データ品質によって変わります。連携数、移行期限、クラウド構成も影響します。全国一律の価格表はありません。
ここで示すのは、自治体基幹システムの公開契約や類似案件をもとにした発注時の目安です。新規開発費と、使用料・標準化対応・移行・保守を含む契約額は、分けて読みます。
方式別の初期費用の幅
方式によって初期費用の水準は大きく異なり、移行や連携をどこまで含めるかで幅がさらに広がります。下の4つは、その違いを方式や規模ごとに示したものです。
- SaaS・共同利用型：既存サービスの初期設定は数十万円から300万円程度です。
- 標準パッケージ：移行、外字、連携、試験、研修を含む場合は1,000万〜3,000万円前後です。
- 中規模案件：標準化対応とガバメントクラウド移行を含め、3,000万〜1億円程度です。
- 大規模な個別開発：複数業務を含む場合、8,000万円〜1億円超になる可能性があります。
墨田区の令和7年8月随意契約一覧には、住民記録管理システム（ガバメントクラウド版）の契約額が掲載されています。内訳は、使用が1億3,077万9,000円、運用保守業務委託が3,570万6,000円です。
この金額は、新規開発費だけでなく、標準化対応やサービス利用・保守を含む契約額です。そのため、相場とは断定できません（出典: 墨田区「令和7年8月 随意契約一覧」、2025年）。ただし、使用料と保守費を分けて見積もる方法の参考にはなります。
5〜10年で比べる初期費用・移行費用・運用費
見積の抜けや職員の負担を見つけるために、作業ごとに金額と期間を分けます。
- 構築：要件定義・Fit & Gapと、アプリ設定・開発・API連携を分けて書きます。
- 移行と導入：抽出・データ整備・外字同定・リハーサル・試験・研修・切替支援を含めます。
- 運用：保守、クラウド利用料、回線、監視、法改正対応を見ます。
初期費用が安く見えても、移行を職員が担う前提や、連携改修・本番後支援の別料金が隠れている場合があります。
比較表には、初期費用、年間の固定費、従量費を並べます。加えて、制度改正時の改修費、5年と10年の総額、自治体側の作業人数と期間も入れます。
また、クラウド料金の変動条件や、データ量・利用者数の課金単位、バックアップ世代数も含めます。休日・夜間対応、端末更新、旧システムの並行稼働期間も加えます。
標準化後に運用経費が必ず下がるとは限りません。割引や補助を前提にせず、通常時のTCO（総所有コスト）で比べます。
委託先の選定と見積比較で見るべき点
知名度や提示価格だけで決めないために、各社に同じ質問をします。また、実際に作業するプロジェクト責任者と移行リーダーが誰になるかも、確かめます。
- 移行実績：同規模自治体での標準化、外字・除票・履歴、周辺連携への対応を確かめます。
- 導入支援：データ移行責任者、職員研修、障害時の窓口継続
- 運用と契約：仕様改定への追随と、契約終了時のデータ返却
自治体規模と移行条件をそろえたベンダー実績の確認
「導入実績100団体」という数字から、自団体に合う委託先かを判断するには、条件をそろえて類似案件を見ます。
- 規模と業務：人口、窓口数、対象業務、データ件数をそろえます。
- 移行条件：外字数、連携先、共同利用か専用環境か、旧ベンダーからの乗換かを確かめます。
- 導入結果：停止時間、リハーサル回数、本稼働後の障害件数、自治体側の人数、仕様改定への対応について質問します。
候補として名前が挙がるのは、NEC、MICJET系を展開する富士通Japan、ADWORLDを提供する日立システムズ、TASKクラウドのTKCです。住民総合システムの富士フイルムシステムサービスや、自治体向け住民記録管理システムの開発・運用実績を持つGCCなども候補です。
候補の名前は比較の入口です。そのうえで、標準準拠の範囲、移行作業、5年と10年のTCO、SLAを、同じ様式で各社に提出してもらいます。
見積比較で確かめる作業範囲と自治体側の負担
同じ機能でも、見積の価格だけでなく作業の境界を見ます。委託先と自治体のどちらが作業を担うかが、見積額を左右します。
- データ作業：抽出担当、外字同定が何文字まで含まれるか、除票や異動履歴を全件移行するかを確かめます。
- 連携試験：連携先ごとのテストデータを誰が作るかを決めます。
- 研修：資料提供だけか、操作演習・管理者研修・本番立会いを含むかを見ます。
評価点は、価格に加えて、機能適合、標準仕様、移行計画、セキュリティに分けます。業務継続、体制、保守、将来のデータ可搬性も、評価の観点に入れます。
価格の配点が高すぎると、移行や障害対応を自治体へ戻す提案が有利になることがあります。質疑回答は全社に公開します。前提をそろえてから、最終の提案と見積を出してもらいます。
契約前に詰めておく移行・外字・業務継続のリスク
移行は、サンプル数件の確認で終わらせず、全件の件数照合と業務シナリオによる帳票照合を行います。転入や世帯主変更、住所異動、除票、印鑑登録のデータは、問題が出やすいものです。外字を含む氏名や他業務との連携も、あらかじめテストケースにしておきます。
外字は、行政事務標準文字への同定結果、見た目が変わる場合の確認、未同定文字の扱い、証明書や郵送物の出力を、受入条件に含めます。
デジタル庁は行政事務標準文字を約7万字として整備し、外字標準化によるデータ連携や行政事務の効率化を目指しています（出典: デジタル庁「地方公共団体情報システムにおける文字の標準化」、2026年3月24日更新）。外字はベンダーロックインや連携障害の原因にもなるため、フォント設定に限らず、住民データの変換と本人確認を含む移行課題として扱います。
切替時期は、繁忙期や年度更新、選挙、法改正の時期を避けて決めます。試験から本番切替、初期安定化まで、順に進めます。
- 要件確認
- 各種試験
- 新旧並行運用と切替リハーサルを経た本番切替
- 本番後の初期安定化
障害時の紙運用や縮退環境への切替手順、判断者、住民案内、復旧後の再入力方法を訓練しておけば、システムの停止が窓口サービス全体の停止に直結しにくくなります。
よくある質問
発注・外注・委託では、費用に加えて、標準化、移行、契約終了後の運用を確かめておく必要があります。
住民記録システムをフルスクラッチで開発しても問題ありませんか？
技術的には可能ですが、標準仕様の対象業務までフルスクラッチにする場合は、慎重に検討します。標準パッケージで代えられない特殊な周辺業務に限り、中核は標準準拠システムとするほうが、制度改正・連携・保守の負担を抑えやすくなります。
ガバメントクラウドに移行すれば費用は必ず安くなりますか？
必ず安くなるとは限りません。比べる項目には、クラウド利用料、回線、バックアップ、監視、二重運用を含めます。さらに、移行支援、保守、法改正対応も入れます。
5〜10年のTCOで比べ、共同利用や標準化による効率化が、自団体の条件でどの程度見込めるかを確かめます。
旧ベンダーから別の委託先へ乗り換えることはできますか？
乗り換えは可能ですが、判断の前に、データ形式や外字、履歴、除票を確かめます。連携仕様、契約上の権利、移行支援の範囲も、あわせて確認します。
RFPには、データの全件提供、項目定義、コード表を明記します。また、変換支援と旧システムの参照期間も書き込みます。複数回の移行リハーサルと受入試験も行います。
システム障害が起きたときも窓口業務を続けられますか？
続けられる業務の範囲は、契約するサービス構成と自治体の縮退運用で決まります。
照会・証明書発行の代替環境や紙受付を、RFPとSLAに記載します。加えて、復旧後の再入力、連絡体制、目標復旧時間も記載します。実際に動くかどうかは、切替訓練と障害訓練で確かめます。
まとめ
発注では、住民異動や証明書だけでなく、印鑑や戸籍附票も含めて範囲を定めます。住基ネットやコンビニ交付、税・福祉との連携範囲も定義します。
標準パッケージ、共同利用型クラウド、専用クラウド、個別開発を比べ、標準化後の運用に合う方式を選びます。
発注前に決めておく事項
対象業務と移行範囲、外字・除票・履歴、連携先を決めます。障害時の窓口継続と、自治体側の担当者も決めておきます。
範囲が明確であれば、RFIやRFPで各社に同じ条件を示せます。そのため、価格だけに引きずられない比較につながります。
選定時に優先する判断の基準
RFPには、現行業務、移行、外字、除票・履歴、連携を盛り込みます。非機能、SLA、窓口継続、研修、データ返却も含めます。
初期費用だけでなく、クラウド、保守、法改正、職員負担を含む5〜10年のTCOで比べます。同じ条件での実績と、移行責任者も確かめます。
▼全体ガイドの記事
・住民記録システム開発の完全ガイド
▼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を創業。