戸籍システムの発注は、現行業務とデータを洗い出すことから始めます。RFIとRFPで候補を比べ、移行と受入条件を合意してから本番切替へ進むと、窓口業務を続けやすくなります。
発注形態と契約の選び方、費用相場、委託先の評価も、この記事で扱います。全体像は戸籍システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・戸籍システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
戸籍システムを発注・外注するときの全体像
戸籍システムは、戸籍簿を保存するだけのデータベースではありません。実際には、受付・審査や戸籍・除籍の編製、証明書発行を担い、他システムとの連携も受け持ちます。権限管理、監査ログ、バックアップも扱う、自治体の基幹業務システムです。そのため、発注対象を画面開発だけに絞ると、移行や運用で追加の費用と工数が生じやすくなります。
発注前に決めるべき対象範囲
発注に含める対象は、業務システム、戸籍関連機能、運用範囲に分けて決めます。
- 業務システム：戸籍、附票、住民記録、印鑑登録、コンビニ交付から、対象に含める業務を選びます。
- 戸籍関連機能：情報連携、電子証明書、窓口端末を中心に確かめます。プリンターや帳票も含めます。
- 運用範囲：運用保守の範囲と、各機能の連携方式を決めます。どこまでを誰が受け持つかも、ここで決めておきます。
戸籍と戸籍の附票は、別々の標準仕様です。戸籍は身分関係、附票は住所履歴を扱います。そのため、両者を同じ見積項目にまとめず、連携方法を明記しておきます。
2026年時点の発注で標準仕様が重視される理由
戸籍は、地方公共団体の基幹業務システムの標準化対象20事務に含まれます。デジタル庁は戸籍情報システム標準仕様書第5.0版と、戸籍附票システム標準仕様書第3.1版を公開しています（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。
- 適合状況：適合を確かめないまま個別機能だけを選ぶと、制度改正やデータ連携、ガバメントクラウド対応で再構築になるおそれがあります。
- 発注書の記載：準拠する範囲、適合の確認方法、未対応機能の対応時期を、文書の中で明記してもらいます。
戸籍システムの発注形態の選び方
発注形態は、標準準拠パッケージやクラウド型、既存システムの更改、個別開発に分けられます。候補を比べやすいのは、標準機能を確保し、自治体固有の要件を連携や設定で吸収する形です。一方で、個別開発を選ぶなら、標準機能で満たせない理由を業務ごとに説明できる状態にしておきます。
標準準拠パッケージを導入するケース
標準準拠パッケージは、戸籍法や法務省の仕様に沿った機能を使えるのが強みです。法改正への追随や、複数自治体の運用知見も活かせます。さらに、受付から証明書発行までの機能や、受附帳、監査ログを、一から設計せずに済みます。
一方で、独自帳票や業務手順が標準機能にない場合もあります。そのときは、カスタマイズ費と運用変更の両方を見積もります。
クラウド型サービスを利用するケース
クラウド型は、サーバーやバックアップ設備を自庁で持つ負担を抑えられる形態です。災害対策や複数拠点での利用も、組み立てやすくなります。
クラウドにしたからといって、自動的に安くなるわけではありません。そのため、5年から10年分の総保有コストを比べます。
- 利用・基盤費：利用料、データ転送料、バックアップにかかる費用を、ここに含めて計算します。
- 運用費：監視と障害対応に加え、端末や通信回線の費用も確かめます。
- 終了時費用：契約を終えるときに、データを返却してもらう際の費用も見積もります。
ガバメントクラウドでは、アプリケーション費用とクラウド利用料のどこまでを誰が受け持つかも確認します。
個別開発・スクラッチを選ぶケース
個別開発は、既存パッケージで対応できない業務がある場合や、複数の基幹システムを独自の運用で統合したい場合に検討します。
- 継続費用：法令や標準仕様、文字や証明書、監査要件が変わるため、初期費だけでは維持が難しくなるおそれがあります。
- 保守体制：設計書の更新や適合確認、法改正への対応に加え、障害時の代替要員まで、体制を確かめます。
- 撤退時の引き継ぎ：開発会社が撤退した後でも、発注者が自ら維持できるかを見極めます。
戸籍システムを発注・外注する進め方
戸籍システムの外注は、現状の把握から本番切替まで、次の流れで進みます。要件は発注者側でも整理し、特定の製品に偏らない比較条件を用意しておきます。
- 現行業務、データ、連携先を洗い出します。
- 要件を整理してRFIを行い、市場と発注条件を把握します。
- RFPを作成して、提案を評価し、契約を結びます。
- 設計、移行、受入テストを経て、本番切替に進みます。
発注者は、データ項目と連携先、移行条件、非機能要件を事前に整理しておきます。各社に同じ前提で提案してもらうためです。
現行業務・データ・連携先の洗い出し
窓口で届書を受け付けてから訂正までの業務フローを描きます。審査や入力、決裁の流れを押さえたうえで、証明書発行と保存も含めます。
対象データは、戸籍や除籍、改製原戸籍、附票です。外字や異体字、旧字体、振り仮名も対象に含みます。そのうえで、各項目がどのシステムから出入りするかを記録しておきます。
住民記録や印鑑登録、コンビニ交付との連携も、対象に入れます。また、法務省の戸籍情報連携システムやマイナンバー関連の連携も含めます。
RFIとRFPによる候補会社の情報収集
RFIは、候補ベンダーに情報提供を依頼するものです。標準仕様への適合、クラウド形態、移行方式を尋ねます。さらに、実績や概算費用、保守範囲についても聞きます。
RFIで選択肢と発注条件を把握した後は、RFPで同じ前提の提案と見積を依頼します。RFPには、対象業務や利用者数、戸籍件数、端末数を記載します。加えて、帳票や連携、移行データも書き込みます。
稼働希望時期と研修、保守を明記します。さらに、SLAや成果物、評価基準も示します。
移行リハーサルと受入テストの発注条件
画面が完成していても、移行データに誤りがあれば稼働できません。そのため、サンプル移行と全件移行の両方で確かめます。
- 文字と履歴：外字の同定や文字コードの変換を確かめ、旧字体や戸籍と除籍の履歴が正しく移るかも見ます。
- 件数と帳票：移行後のデータ件数と、証明書の出力結果を照らし合わせます。
- 合否条件：一致件数の基準と未同定外字の扱いを決めます。レイアウトの承認者や切戻しの条件も定めます。
受入条件を発注時に合意しておけば、納品直前の判断を落ち着いて行えます。
研修・切替・安定稼働までの責任分界
本番切替の後も、職員研修や問い合わせ窓口、障害対応が続きます。さらに、バックアップ復元や監査ログの確認、法改正への対応も必要になります。
仕様書には、操作マニュアルだけでなく、役割別研修や稼働立会い、問い合わせの一次受付も含めます。重大障害の連絡時間や復旧目標、再発防止報告の期限も書き込みます。
窓口は止めにくいため、切替当日の要員配置や紙運用などの代替手順も、委託範囲に含めます。
戸籍システムの契約形態と分け方
契約は、要件整理や調達支援から運用保守までをまとめる方法と、工程ごとに分ける方法があります。
- 一括契約：窓口を一本化できる一方で、見積の妥当性や責任範囲が見えにくくなります。
- 工程別契約：工程ごとに見積を比べやすい反面、複数の会社の調整は発注者が受け持つことになります。
戸籍では、移行と運用保守にも、独立した成果物と受入条件を設ける方法が有効です。
請負契約で固定価格にする範囲
請負契約は、要件と完成条件が明確な開発や設定、帳票作成、移行作業に向いています。固定価格にする場合は、成果物と納期を決めるほか、検査方法や瑕疵対応、変更管理も定めます。
移行の成果物には、抽出ファイルや変換結果、件数照合表を含めます。外字同定の結果や証明書サンプル、復元手順も含めると、完成した状態を確かめやすくなります。
準委任契約・保守契約で管理する範囲
要件定義や調達支援、制度改正の調査は、作業量が変わりやすい業務です。運用改善や問い合わせ対応についても、作業量は変わりやすいものです。そのため、準委任や月額保守が適しています。
準委任では、時間単価に加えて、担当者の役割や月次報告を決めます。会議体や成果物、稼働上限、追加承認の条件も定めます。
保守契約では、通常の問い合わせと障害、軽微な改修と制度改正を分けます。営業時間内と時間外も区別し、月額費用に含む作業の範囲もはっきりさせておきます。
データ所有権と契約終了時の条項
戸籍データは、自治体にとって重要な業務データです。開発会社の製品形式に閉じ込められないよう、所有権と利用権を定めておきます。
契約には、標準形式での抽出や外字情報の返却を記載します。設計書や設定書の引き渡し、第三者への再委託、秘密保持を含め、終了時の消去証明も書き込みます。
乗り換えを見据えて、データ抽出の仕様と抽出費用、移行検証への協力義務を、RFPの段階から確認します。
戸籍システムの費用相場とコストの内訳
戸籍システム単体の全国平均価格を示す公的統計はありません。ここでの数字は、公開されている契約額や案件の規模、標準化・移行の作業量を基にした目安です。
この金額は、入札価格や見積金額を保証するものではありません。そのため、初期導入や移行、周辺連携は分けて提示してもらいます。端末・帳票や研修、保守、制度改正対応も、別々に示してもらいます。
初期費用の見込み
小規模から中規模の自治体が標準準拠パッケージを導入し、設定と周辺連携を行う場合、初期費用は3,000万〜8,000万円程度が目安です。
標準化移行や外字同定、データクレンジングを含む場合は、5,000万〜1.5億円程度となることがあります。金額は、移行に加えて、どの周辺作業を含むかで変わります。周辺作業として挙げられるのは、次の4つです。
- 端末設定
- 帳票
- コンビニ交付連携
- 研修
個別要件が多い大規模な刷新やフルスクラッチでは、8,000万円〜3億円超も想定されます。ただし、自治体規模とデータ件数がそろわないままでは、金額を比べられません。
公開契約額から分かる保守・移行費の水準
公開されている契約額は、自治体ごとに対象範囲を確かめてから比べます。
- 京都市の保守：2025年度の契約例を見ることができます。
- 京都市の移行：端末設定変更作業は71,468,485円です（出典: 京都市「随意契約一覧表」、2025年度）。
- 北九州市の保守：2025年度には、23,966,244円の契約例があります（出典: 北九州市「随意契約結果一覧表」、2025年度）。
- 札幌市のライセンス：2026年度の資料には、17,440,500円の例が載っています。
京都市の2025年度の契約例では、サポートセンター業務委託が7,848,720円、運用保守が12,845,250円、パッケージ保守が21,836,650円です（出典: 京都市「随意契約一覧表」、2025年度）。
京都市の契約は全国平均ではありませんが、保守は年800万〜2,500万円程度、移行関連の作業は数千万円規模になり得ます。一方で、札幌市のライセンスは期間と対象範囲が限られるため、年間の総額とはみなせません。
これらの契約額は相場とは言い切れないため、対象範囲をそろえて見積もりを比べます。
見積書で分けるべきランニングコスト
見積書では、継続費用と初年度だけの費用を分けて書きます。月額保守に移行支援や稼働立会いを含めてしまうと、2年目以降の費用が見えなくなります。
- 利用・基盤：ライセンスと利用料、クラウド基盤を、別々の項目にします。
- 運用・保守：監視やバックアップ、ヘルプデスクの費用を含めます。障害や法改正、帳票変更への対応も、この中に入れます。
- 機器・期間費用：端末やプリンターの保守、移行と稼働立会いにかかる費用を、漏れなく確かめます。
5年総額と10年総額を並べて比べます。そのうえで、制度改正の追加費用やデータ返却費、再委託費も確かめます。
RFP作成と見積比較で確認すべきポイント
RFPは、提案を競わせる資料であると同時に、発注者が業務とリスクを整理するための資料でもあります。費用に加え、標準仕様や移行品質、法改正への対応を、同じ書式で回答してもらいます。障害復旧や職員負担についても、各社に答えてもらいます。
評価項目と配点を先に決めておけば、営業資料の印象に左右されにくくなります。
RFPに書くべき要件と質問
RFPでは、要件と確認事項を分けて書くと、各社の回答を比べやすくなります。あわせて、標準仕様や文字対応について質問しておきます。
- 機能：届書受付から戸籍・除籍・改製原戸籍の編製まで、検索や証明書、附票を書きます。受附帳、権限、監査ログも記載します。
- 非機能：稼働時間や同時利用者数、応答性能を示します。バックアップや復旧目標、災害対策も記載します。セキュリティや操作履歴、保守窓口も示します。
- 確認事項：標準仕様の版や適合確認試験について尋ねます。振り仮名対応や外字同定の手順、責任者も聞きます。
見積書を同じ条件で分解した比較
見積書は工程と費目に分けたうえで、数量や単価、期間を同じ条件にそろえて比べます。前提や除外作業もそろえておけば、各社の金額を正しく比べられます。
- 設計・構築：要件定義と設計、設定・開発は、別々の欄で示してもらいます。
- データ・移行：抽出と変換、外字同定の作業は、リハーサルや本番移行と分けて見積もります。
- 周辺・運用：ライセンスとクラウドの費用を確かめます。端末・帳票や連携の費用も見ます。研修や立会い、保守が別の項目として書かれているかも確認します。
A社だけが移行費を別に計上するような比較ミスを防げます。価格が低い会社ほど、除外項目と追加単価を確かめておきます。
委託先を選ぶときの評価軸
会社の知名度よりも、戸籍事務の経験を重く見ます。そのうえで、類似人口や類似件数での移行実績、標準仕様の適合状況を評価します。外字と文字標準化への対応、法改正時の保守体制、障害時の復旧体制も、評価の対象にします。
自治体名を開示できない場合は、同規模の自治体での稼働年数や移行件数を尋ねます。重大障害の対応例や、導入後の担当者数も聞いておきます。
提案責任者と導入責任者が同じ人物かどうか、再委託先がどこかも確かめます。
一者随意契約・ベンダーロックインの回避
現行ベンダーしかデータ形式を知らない場合や、標準化に対応できる開発会社が限られる場合、既存設備との接続仕様が非公開の場合は、一者随意契約につながります。
随意契約が必要な場合でも、RFIで対応できる会社を確かめます。現行ベンダーには、データ項目や抽出・連携の仕様、移行協力費を示してもらいます。
次回の更改に備えて、標準形式での返却や文書化を、現契約に盛り込みます。第三者検証や契約終了時の支援も含めます。
よくある質問（FAQ）
発注では、費用のほかに、標準仕様やデータ移行、契約終了時の引き継ぎについて質問が寄せられます。担当者が確かめたい点を、見出しごとに回答します。
戸籍システムの外注費用は最低いくらかかりますか？
外注費用の最低額は、案件によって変わります。標準準拠パッケージでも、設定や端末、帳票を含めると数千万円規模になり得ます。移行や研修も加わるため、見積の範囲を確かめる必要があります。
初期3,000万〜8,000万円、標準化・移行込み5,000万〜1.5億円の目安があります。その金額は、戸籍件数や外字数、連携数、自治体規模によって変わります。
無料の概算価格を受け取るより、前提条件と除外項目を明記した見積を依頼します。
戸籍システムのRFPには何を書けばよいですか？
対象業務と利用規模、標準仕様の版を記載します。機能・非機能要件やデータ形式、外字を書き込みます。連携先や帳票、移行リハーサルも含めます。
研修や保守、SLAに加え、納品物と契約終了時のデータ返却も含めます。件数や文字の一致、証明書出力を受入条件にします。権限や監査ログ、復元も、受入条件に加えます。
提案書の評価基準と配点も、事前に示しておきます。
現行ベンダーから別会社へ乗り換えられますか？
乗り換えは可能ですが、発注の前に次の条件を確かめておきます。
- データ：抽出仕様と外字、連携仕様を確かめます。契約上の利用権も見ておきます。
- 移行協力：現行ベンダーが協力するかどうかを確かめたうえで、データ移行を試します。
- 候補会社：戸籍分野は主要ベンダーが少ないため、RFIを早めに行います。
デジタル庁は、2026年3月末時点で移行対象34,366システムのうち10,013システムが特定移行支援システムに該当したと公表しています。移行遅延の要因は、個別開発や事業者のリソース不足です（出典: デジタル庁「移行支援期間における特定移行支援システムの数について」、2026年）。
2025年の振り仮名対応は発注時に確認すべきですか？
振り仮名対応は、発注時に確認しておく必要があります。氏名の振り仮名記載は2025年5月26日に始まり、標準仕様書には振り仮名を検索キーとして扱う要件もあります（出典: 法務省「戸籍情報システム標準仕様書」、第5.0版）。
通知や届出、審査の範囲と、記録や検索、証明書の出力範囲を整理します。既存のカナ情報との関係も、あわせて見ておきます。標準仕様に対応する版と改修期限は、提案書で確かめます。
まとめ
戸籍システムの発注では、まず発注形態を比べ、業務とデータを洗い出したうえで、RFIとRFPを進めます。費用は導入だけでなく、移行や連携、機器まで分けて把握します。研修や保守、法改正対応も、見落とさないようにします。
発注先の選定で優先すること
価格よりも、戸籍事務の知識と標準仕様への適合を評価します。類似自治体での移行実績や文字同定、障害復旧、法改正時の保守範囲も、判断材料にします。
同じ項目と前提で見積もりを比べ、除外作業と追加単価を確かめます。契約には、データ返却や文書化、再委託、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を創業。