住民情報システムの発注は、まず現状の業務とデータを洗い出したうえで、RFIで各社の情報を集め、RFPで条件をそろえるところから始まります。その後、提案を評価して委託先を選び、契約を結びます。
移行と運用まで契約に定めておくことが、安全な切替と継続運用につながります。
▼全体ガイドの記事
・住民情報システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
住民情報システムを発注・外注する前に知っておきたい全体像
住民情報システムは、住民基本台帳と印鑑登録を管理する中核システムです。そのため、発注時には周辺業務との連携も含めた行政情報基盤として考えます。
中核機能と周辺機能に分けた発注範囲の定義
2026年時点では、標準仕様への適合に加えて、既存データを正しく移す計画が成否を左右します。また、帳票や例外処理も安全に引き継ぐ必要があります。
- 中核業務：住民異動、世帯・住所・続柄・在留情報、印鑑登録、証明書交付。
- 管理機能：宛名、住民票コード、個人番号に関する権限の管理。
- 周辺連携：税・保険・年金・介護・福祉・児童手当・就学・戸籍などとの連携。
- 窓口関連：コンビニ交付、電子申請、窓口受付管理などを含めた範囲の確認。
RFPに「住民情報システム一式」と書くと範囲が曖昧になるため、業務やデータなどの単位ごとに範囲を分けて示します。
住民記録・印鑑登録は標準準拠パッケージで、独自の窓口予約やBPR帳票は周辺システムとして整理します。こう分けておくと、価格差と責任分界を比べやすくなります。
2026年の発注における標準化対応と移行プロジェクト
デジタル庁によると、標準化対象事務は現時点で20事務です。原則として2025年度までに標準準拠システムへ移行する方針です。
2026年3月末時点では、移行対象34,366システムのうち10,013システムが対象で、移行対象の29.1％にあたります。これらは、2026年度以降に移行する「特定移行支援システム」に該当します（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年6月更新）。
この数字からは、移行の難所を特定して段階的な計画を組む必要性が分かります。
行政事務標準文字への対応では、2025年度から文字が順次標準化されます。対象は各種証明書や郵送物で、従来の外字と見た目が異なる場合があります（出典：デジタル庁「地方公共団体情報システムにおける文字の標準化」、2026年3月更新）。
- 文字対応：文字の同定・変換、証明書の照合、本人確認時の説明を委託範囲に含める。
- 移行計画：契約期限にとどまらず、難所を特定したうえでの段階的な計画。
文字対応が漏れると、稼働後の窓口で混乱します。
住民情報システムの発注形態の選び方
標準化対象の基幹業務は、パッケージやクラウドを中心にし、標準外の業務改善や周辺連携を追加開発する形が現実的です。
全てをスクラッチ開発するより、制度改正や標準仕様改版への追随負担を抑えられます。また、将来のベンダー変更に向けて、データ移行の条件も整理できます。
既存業務の特殊性が大きい自治体では、パッケージの適合度を業務単位で検証します。
パッケージ・クラウド・スクラッチの違い
方式ごとに、機能の適合度と運用の負担は異なります。標準業務と独自業務を分けて比べると、差が見えてきます。
- 自治体向けパッケージ：住民異動、証明書、印鑑、宛名などを備え、実績や制度改正の知見を活用できます。
- ガバメントクラウド：セキュリティや災害対策の高度化を期待できますが、利用料や運用設計が別途発生する場合があります。
- スクラッチ開発：独自の窓口フローや帳票を実装できますが、定義・改正・テスト・保守の負担が増えます。
デジタル庁は、ガバメントクラウドへの移行で費用が増える自治体もあり得ると説明しています。「クラウドなら必ず安い」とは限りません（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。
標準化対象の中核機能を独自仕様へ戻すと、再移行や連携で不利になりがちです。そのため、スクラッチはポータル、予約、分析、業務改善など標準外の機能に限定するほうが安全です。
一括発注と分離発注の責任の置き方
発注単位は、窓口の一元化と自治体側の管理体制を踏まえて選びます。
- 一括発注：要件定義から保守まで窓口を一本化し、短期間で意思決定できる。
- 分離発注：現状分析、RFP支援、製品導入、移行支援、第三者テストなどを分けて調達。
一括発注で元請けが再委託先を管理する場合、作業会社、障害時の連絡経路、追加費用の算定方法が見えにくいことがあります。
発注側は、契約前に再委託先と担当範囲、成果物、検収基準を確認し、障害時の一次対応者も明らかにします。
分けて発注する場合は、自治体側に全体PMOが必要です。
内部人員が不足するときは、発注者支援を先行委託し、第三者に要件と見積もりを整理してもらったうえで本体契約に進みます。
RFIでの情報収集とRFPでの条件提示
詳細なRFPを急ぐと、現行仕様の漏れや自治体固有の例外処理が後から見つかります。そのため、まずRFIで各社の情報を集めます。
- RFIで確認：標準準拠範囲、導入方式、人口規模別実績、クラウド対応、移行期間、自治体側の体制。
- RFPで提示：業務・データ・連携先・帳票・外字・処理件数・権限と、移行期間・テスト・研修・保守。
- 提案で分類：必須・望ましい要件と、標準機能・追加開発・対応不可の要件。
RFI回答をもとに、現状と目標の差分を整理します。そのうえで、各社へ同じ書式で条件を示せば、含まれる機能の違いによる比較ミスを防げます。
住民情報システムの発注・外注の進め方と順番
発注は、現状調査から運用改善まで順に進めます。期間の目安は、調査・RFP作成が3〜6か月、要件確定・設計が6〜12か月です。
- 現状調査と業務整理を行い、RFI・RFPを作成します。
- 提案を評価して委託先を選び、契約します。
- 設計・設定を行い、データ移行と連携テストを進めます。
- 受入テストと研修を経て切り替え、運用を改善します。
移行・連携・総合テストは6〜12か月、研修と切替は1〜3か月が目安です。
全体では12〜24か月が基本です。
外字や複雑な連携が多い場合は、24〜36か月級も想定します。
業務・データ・連携・帳票の棚卸し
成果物は機能一覧だけでなく、職員が業務で使うデータと引き渡し先を示す業務・データ台帳です。
転入届の受付から住民異動の登録、宛名更新、税・福祉への連携、証明書交付まで、業務フローで表します。
画面にない手作業、Excel、紙台帳、担当者だけが知る補正処理も、移行後に必要なら要件に含めます。
- データ項目：氏名・住所・世帯・続柄、異動履歴・除票、印鑑、個人番号との関係。
- 品質と保存：保存期間、文字コード、欠損、重複、過去データの参照要否。
- 外字対応：標準文字との同定、変換不能文字、証明書表示、旧字形の参照業務。
外字の例外を洗い出しておかないと、移行テストで問題が多発し、納期と費用が膨らみます。
機能・移行・運用・価格に分けた評価表
価格だけで選ばないために、必須条件を先に確認し、品質と費用を段階的に評価します。
- 機能と標準化：機能適合度と標準仕様への適合の採点。
- 移行と連携：移行方法、連携実績、外字対応の確認。
- 運用と継続性：セキュリティ、管理体制、保守、将来のデータ出力性の評価。
価格点を高くしすぎると、要件を削った提案が有利になります。そのため、必須要件を満たさない提案は価格評価の前に除外し、その後に品質と費用を比べる二段階評価が安全です。
デモでは、異動取消、世帯変更、重複、外字表示、証明書再発行、障害時の手作業復旧を実演してもらいます。見るのは画面の完成度だけでなく、エラー時の状況、ログ確認者、業務再開までの流れです。
契約前の移行リハーサルと切戻し条件の決定
データ移行は、複数回の移行と確認を重ねる計画にします。
- 移行リハーサル：変換仕様、サンプル・全件移行、検証、修正、再移行。
- 検証項目：件数、キー、履歴、文字、連携結果、証明書の印字。
- 並行稼働：一定期間並行する場合は、正とするシステム、差分突合、窓口停止時間の明記。
- 切戻し：重大な誤交付、データ欠損、連携停止時の条件の決定。
- 段階検収：「稼働したら検収」と切り分け、受入基準を満たして安定稼働期間を終えた時点での検収も検討。
切戻し期限、復旧対象、判断責任者、住民への案内は総合テストで確認します。
職員の手作業手順とベンダーの応援体制も確かめておきます。
住民情報システムの発注費用相場とコストの内訳
費用は、対象業務と連携、移行データ、標準外機能の有無で変わります。人口やクラウド構成、保守年数によっても変わるため、全国共通の定価はありません。
以下の金額は、2026年時点の公開事例と自治体案件の規模感による目安です。小規模自治体の金額は全国統計ではなく、住民記録・印鑑登録を中心とした推定です。
自治体規模別の初期費用の幅（3,000万円から10億円超まで）
規模と範囲によって検討レンジは変わります。以下は一律の相場ではなく、対象を限定した推定です。
- 小規模自治体：住民記録・印鑑登録の標準準拠導入と最低限の移行・連携で3,000万円〜1億5,000万円程度。
- 中規模自治体：税・福祉・戸籍・窓口・コンビニ交付を含め、1億円〜5億円程度。
- 大都市の公開例：大阪市の構築は4億1,102万6,000円、データ移行は1億1,440万円。
- 周辺機能の公開例：大阪市の除票管理対応は8,446万860円。
大阪市の資料（出典: 大阪市「令和7年度（令和8年2月）公金支出情報」、2026年）には、これら個別契約額が記載されており、構築・移行・周辺機能が別費用になることが分かります。ただし、全国相場とは異なります。
構築費・移行費・連携費・保守費に分けた見積もり
見積内訳を工程別にそろえると、初期費用と稼働後費用の漏れを比べられます。
- 初期費用：調査・要件定義・環境構築・設定、追加開発、帳票、変換、外字対応。
- 移行・導入費：リハーサル、連携、総合テスト、研修、切替支援。
- ランニング費：クラウド・ライセンス・監視・バックアップ、ヘルプデスク、制度改正。
- 保守・環境費：仕様改版、障害・脆弱性対応、帳票、機器・端末・回線、教育。
移行費は件数だけでなく、履歴や除票の参照、欠損の補正、文字の同定、旧システムの抽出仕様によっても変わります。そのため、「1件あたり」の単価に加えて、移行リハーサルと検証の回数も確認します。
大阪市の資料（出典: 大阪市「令和7年度（令和8年2月）公金支出情報」、2026年）には、住民基本台帳等の運用保守費2億1,408万8,523円が記載されており、初期費用と分けて比較する必要があります。
自治体規模が違うため単純比較はできません。ただし、保守費も初期費用とは別の大きな予算項目です。
10年TCOと予備費の別々の試算
初期費用だけでなく継続費用を含む10年累計と、個別リスクに応じた予備費を試算します。
- 累計時点：初年度、2年目以降、5年、10年の費用を並べる。
- 継続費用：クラウド、制度改正、追加連携、帳票、データ出力、問い合わせ対応の比較。
- 提案評価：標準機能が多く改修・移行を抑える案は、初期費用が高くても長期的に有利になる場合があります。
- 予備費：外字、仕様変更、欠損、追加帳票、並行稼働、制度改正の時期を見て、リスク別に置く。
見積前提、除外作業、単価表、変更承認フローを提出してもらうと、追加請求を抑えられます。
住民情報システムの委託先選定と見積比較のポイント
委託先は、知名度や提示価格を判断材料の一つにとどめ、技術力、業務整理、移行体制、障害時の責任、将来のデータ移行性を同じ観点で比べます。
特に、現行ベンダーへの依存が長い自治体では、第三者が比較できる資料に整える工程が重要です。
人口規模と対象業務が近い自治体の実績確認
導入実績は件数よりも中身を見ます。自庁に近い人口規模と業務を持つ自治体の事例を確認し、標準化対応の完了実績も確かめます。
- 対象業務：住民記録・印鑑登録に加え、税・福祉・戸籍・窓口連携の実績。
- 移行・切替：移行回数、外字、停止時間、稼働後の重大障害。
- 継続対応：制度改正への対応、同規模自治体の運用評価。
提案・実装・保守の主体が違う場合は、契約相手と責任者を明らかにします。
可能であれば、同規模自治体の担当者から運用開始後の評価も聞きます。
再委託先が設計・移行・運用を担うなら、会社名と範囲、交代時の引き継ぎ、承認、情報持ち出しを確認します。
個人番号を扱う委託では、再委託先の安全管理と必要な許諾・監督を契約に反映する必要があります。その根拠は、個人情報保護委員会のガイドライン（出典: 個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン（行政機関等編）」、2025年6月改正）です。
作業の不確実性に合わせた契約形態とSLA
要件の確実性に応じて契約を選び、責任と成果物を明確にします。
- 準委任：不確実性が残る現状調査やRFP支援で、作業時間と成果物を定める。
- 請負：要件確定後の設定、開発、移行ツールで、成果物、検収、瑕疵対応を定める。
- 工程別契約：調査・PMO、構築・移行・テスト、月額保守で契約を分ける方法もあります。
SLAでは、受付時間や重大障害の定義、一次応答、復旧目標を決めます。さらに、バックアップやログ保存、制度改正、標準仕様改版、脆弱性対応についても取り決めます。
再委託、データ返却、契約終了時の移行支援も、契約に含めて確認します。
RTOとRPOは数値で定め、障害時に優先して復旧する機能も合意します。
保守契約に含まれない個別調査、帳票修正、データ抽出の単価も決めます。事前に単価を定めておくと、稼働後の予算を管理しやすくなります。
セキュリティとベンダーロックインの同時評価
安全管理とデータ移行性を、契約と運用の両面で確認します。
- 安全管理：最小権限・多要素認証、端末・媒体、暗号化、ログ・監査、バックアップ。
- 継続的な対策：脆弱性管理、インシデント対応、委託先の監督。
- 移行できる設計：項目定義・コード表・変換仕様、APIまたは標準形式、帳票・運用手順。
個人情報保護委員会のガイドライン（出典: 個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン（行政機関等編）」、2025年6月改正）は、適切な安全管理措置を求めています。その目的は、特定個人情報の漏えい、滅失、毀損を防ぐことです。
「クラウドだから安全」で済ませず、誰がログを確認し、委託先をどう監督するかを具体化します。
契約終了時には、全データを使える形式で返却させ、移行の説明と支援、抽出費用も定めます。
委託先が、次回更改の選択肢を残せるかどうかも評価します。
住民情報システムの発注・外注でよくある質問
費用や期間は自治体の規模と範囲で変わります。自庁の現状を洗い出し、個別に確かめてください。
住民情報システムの発注費用はいくらかかりますか？
小規模自治体の標準準拠パッケージは3,000万円〜1億5,000万円程度、中規模で複数業務・連携を含む場合は1億円〜5億円程度が検討レンジです。
公開支出では、大都市の構築が4億円超、移行が1億円超の事例もあります。ただし、全国一律の相場ではありません。
対象業務、移行回数、連携数、保守期間をそろえて見積もりを比較します。
発注から稼働まで何か月かかりますか？
現状調査から切替まで12〜24か月が基本的な目安です。
- 短縮できる場合：パッケージ導入で対象業務が少なければ、6〜12か月に圧縮できる場合があります。
- 長期化する条件：外字、古いコード体系、複数の税・福祉・戸籍連携があると、24〜36か月級になる可能性があります。
- 長期化する場合：並行稼働やデータクレンジングがあると、期間が延びる可能性があります。
- 工程表の確認：移行リハーサル、受入テスト期間、切替停止時間、切戻し条件を入れておく。
現行ベンダーから別会社へ変更できますか？
変更できますが、現行ベンダーのデータ形式、抽出条件、コード表、外字、帳票定義、連携仕様を早めに確認します。
RFP段階では、データ提供と移行協力を整理し、契約終了時の返却、説明、移行支援、抽出費用を明記します。
現行事業者が撤退している場合は、第三者によるデータ解析と移行リハーサルの期間を長めに確保します。
ガバメントクラウドならセキュリティを任せられますか？
ガバメントクラウドの基盤を使えば、セキュリティや災害対策を活用できます。
- 安全管理：基盤を活用しても、自治体と委託先の安全管理は必要です。
- 管理項目：権限、認証、ログ監視、バックアップ、個人番号の取扱いを定めます。
- 委託先の監督：委託先・再委託先の監督と、事故時の報告手順を規程や契約に含めます。
- 稼働後の監査：構築時の評価に加えて、稼働後に誰が何を監査するかも決めておく。
まとめ：住民情報システムの発注は移行と運用まで含めた比較
最初に、住民記録・印鑑登録と、税・福祉・戸籍・窓口・証明書交付などを分けて洗い出します。そのうえで、標準仕様と標準文字、移行、連携の条件をRFPに記し、同じ条件で複数社へ提案を依頼します。帳票や権限、監査ログ、障害対応についても、同じ書式で示します。
発注前の対象範囲と比較条件の統一
比較表と契約では、対象範囲、費用、切替後の品質を同じ基準で確認します。
- 比較項目：標準機能・追加開発・移行・連携、テスト・研修・保守の前提。
- 品質確認：現場職員の受入テストと住民への影響の評価。
- 費用目安：小規模は3,000万円〜1億5,000万円程度、中規模は1億円〜5億円程度。
- 大都市の想定：構築・移行・周辺機能の合算で、10億円を超える可能性があります。
上の金額は、対象範囲と公開事例による目安です。
保守、クラウド、改正、連携を含む10年TCOと切替失敗時の損失も考慮し、成果物、検収、SLA、再委託、データ返却、切戻し条件を契約で具体化します。
契約での移行後の責任分界の合意
契約には、成果物と検収、再委託を記し、障害連絡やデータ返却も含めます。標準仕様改版や制度改正、保守終了時の移行支援も定めておきます。更改やベンダー変更を想定すると、ロックインと予算の不透明さを抑えられます。
- 業務・データの整理：標準化をシステム更改だけで終わらせず、ブラックボックス化した業務とデータを整理します。
- 将来の改善：ベンダー変更やサービス改善につながる基盤への整備。
- 発注者側の体制：業務知識とプロジェクト管理の体制を置く。
- 現場での判断：提案会社の説明をそのまま受け入れず、現場職員が使い続けられるか判断します。
- 住民への影響：住民への誤交付を防げるかという視点も必要です。
▼全体ガイドの記事
・住民情報システム開発の完全ガイド
▼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を創業。