マイナンバー管理システムの発注は、対象業務を洗い出し、要件と責任範囲を明確にすることから始めます。次に発注形態を選び、RFPに要件を文書としてまとめ、契約形態、費用、委託先の順に決めていきます。同じ条件で見積もりを比べておくと、追加費用や責任範囲の迷いを抑えられます。
▼全体ガイドの記事
・マイナンバー管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
マイナンバー管理システムの発注前に知っておく全体像
発注の前に、誰の個人番号をどの事務で使い、どこまでシステムに保持するかを決めておきます。自治体の住民系と企業の人事労務系では、対象データも接続先も異なります。この整理があいまいなままだと、どの見積も前提がそろいません。
自治体向けと企業向けの発注要件の違い
自治体と企業では、番号を使う業務も連携先も違います。そのため、発注対象は用途ごとに分けて整理します。
- 自治体の接続先：住民記録、統合宛名、税、国保、福祉、戸籍
- 自治体の処理：番号などの照合や異動反映、情報照会・提供、帳票のほか、権限、履歴、バックアップ
- 企業の処理：従業員・支払先からの収集、本人確認、給与、年末調整、法定調書、退職後の停止・廃棄
- マイナクラウド：初期無料。最大10人は月額1,000円、最大100人は月額8,000円（税別）
- freee：有料のfreee会計またはfreee人事労務の契約者は、マイナンバー管理を追加料金なしで利用
自治体では、照合の対象に個人番号、住民票コード、宛名番号を含めます。
マイナクラウドは最大30人で月額2,400円、最大60人で4,800円です。初期設定支援と従業員向けセミナーは、それぞれ20万円からです。
マイナクラウドの料金は、2026年8月に確認した企業向けSaaSの価格例です（出典：マイナクラウド「料金・導入方法」、freee「マイナンバー制度とfreeeマイナンバー管理」、2026年確認）。このため、自治体基幹系の開発費とは分けて比較します。
番号管理の安全管理と責任分界
番号を扱うシステムでは、機能を比べる前に、安全管理と責任分界を確かめておく必要があります。どこまでを発注者が管理し、どこからを委託先が負うかは、この段階で線を引いておきます。
- アクセス管理：閲覧・登録・出力の権限、番号の表示制御とマスキング、二要素認証、通信・保存時の暗号化、操作履歴
- 自治体の接続環境：利用事務系、LGWAN接続系、インターネット接続系を分ける三層分離との整合性
- 委託先の管理：従業者教育、再委託先への対応、障害時の連絡、漏えい時の報告の取り決め
- 契約終了時：データの返却と消去の確認
- ガイドライン：発注仕様書と契約書の、現行の指針に沿った照合
「特定個人情報の適正な取扱いに関するガイドライン（事業者編）」は2025年6月に一部改正されました（出典：個人情報保護委員会）。
マイナンバー管理システムの発注形態の選び方
独自業務が少ない企業はSaaS、自治体の標準化対象業務は標準準拠のパッケージやクラウドが候補になります。深い連携が必要な場合は、パッケージに追加開発を重ねる形になります。
SaaSとパッケージ導入の標準機能との適合性
方式を比べるときは、標準機能で対応できる範囲と、個別要件を切り分けて考えます。
- 企業向けSaaS：収集・保管・利用・廃棄が中心なら導入が早く、初期開発費を抑えやすい
- 個別要件：給与・会計連携、複数法人権限、税理士との共有、独自帳票（追加費用の有無）
- サービス条件：API・出力、退会時のデータ返却、ログ保存期間、導入支援、サポート範囲
- 自治体向け：標準準拠、データ・連携要件、標準文字、クラウド接続
自治体向けは、制度や標準仕様が変わると対応も必要になるため、発注時点で見ておきます。さらに、デジタル庁は2026年7月28日に資料を更新し、データ・連携要件の改定予定も公開しました（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年7月28日更新）。そのため、発注時点の仕様だけでなく、契約中の改定にどう追随するかも提案依頼書に記しておきます。
連携改修とスクラッチ開発の独自要件
連携方式と独自開発は、保守の負担と設計条件を比べて整理します。
- 連携方式：番号を各業務システムに複製する方式と、統合宛名や番号連携基盤を参照する方式
- 連携設計：データ項目、キー、更新タイミング、エラー時の再送、手作業による補正方法
- スクラッチ開発の負担：自由度は高い一方、制度・標準仕様・暗号方式・OSの更新対応と、担当者交代後の保守を発注者が長く負うこと
- 独自開発の判断：標準機能で代替できない効果を、長期の保守とあわせて説明できるかどうか
たとえば、住民記録や税、福祉への組み込みには連携改修が必要です。給与や会計への組み込みにも、連携改修が必要です。さらに、番号を複製するか必要なときに参照するかで、セキュリティと移行工数が変わります。
独自開発を選ぶ場合は、将来の利用者数や移行期限、5年から10年の保守体制も、説明材料に含めます。ただし、紙運用を画面にするだけが目的なら、パッケージや業務改革を先に検討します。
RFPと要件整理の進め方
RFPは、解決したい業務課題と提案者に守ってほしい条件を共有する書類です。まずRFIで市場の製品、導入方式、標準化対応を調べ、現行業務の調査を踏まえてRFPに具体化します。こうして段階を踏むと、提案を同じ基準で比べやすくなります。
RFIと現行棚卸しで決める発注対象
発注対象を決めるには、まず現行業務を整理し、業務名や部署、利用者を一覧にします。また、入力項目と番号利用の根拠、保存期間や帳票も押さえます。さらに、連携先や処理件数、繁忙期や障害時の代替手順も、あわせて把握しておきます。
自治体では、住民異動を税や福祉に反映する時期、宛名番号の照合担当、外字や履歴の移行方法を確かめます。また、RFIでは、標準機能で対応できる範囲と、設定や追加開発で対応する範囲、対応不可の範囲を分けて回答してもらいます。
候補先には、類似規模の導入時期や移行件数、制度改正や障害復旧の実績を尋ねます。さらに、再委託先や担当体制、終了時のデータ返却方法も確認します。
RFPの記載区分（機能・データ・非機能・運用）
機能、非機能、データ・移行を分けて書けば、提案内容と見積条件を照合できます。
- 共通機能：収集や本人確認、登録・変更・利用、検索、帳票の処理。停止、廃棄証跡、承認、問い合わせも含みます
- 自治体機能：番号の付番・変更・廃止、カードの交付・更新・失効、情報照会・提供、中間サーバー連携
- 企業機能：入社・扶養変更・退職、年末調整、法定調書、税理士・社労士との権限分離
- 非機能・安全管理：可用性、性能、同時利用者数、バックアップ、RTO・RPO、監視。障害通知、診断、暗号鍵、ログ保存期間、接続元も含みます
- データ移行：対象件数、欠損・重複、文字コード、外字、照合エラーの確認者。リハーサル回数、並行稼働期間
要件は、「安全」「使いやすい」といった表現にとどめず、測定方法や受入条件まで書くと、見積を同じ基準で比べられます。
請負・準委任・保守の使い分け
工程ごとに不確実性の大きさが異なるため、契約も工程ごとに分けて考えます。分ける単位となる工程を、下に挙げます。
- 企画・要件定義
- 設計・開発
- 移行・テスト
- 運用保守
成果物と責任を定義できる工程は、請負にします。
契約は、調査や伴走を準委任に、稼働後の監視や改修を保守契約に分けておくと、責任を整理しやすくなります。
請負と準委任の切り分け
成果物が決まる工程と、調査や伴走が必要な工程では、契約に書く内容が変わります。
- 請負の成果物：合意した成果物を納期・品質条件に沿って完成させる。納品物と検収基準の明記が前提
- 請負の注意点：発注時に業務要件が固まらないまま全工程を請負にすると、変更のたびに追加費用や納期延長が生じるおそれがあります
- 準委任の対象：現状分析、要件定義、RFP作成支援、PMO、移行伴走など、作業時間や専門性を提供する工程に向きます。成果物が不要という意味ではありません
- 準委任の管理：会議体、作業範囲、稼働時間、報告書、課題管理表、意思決定者の取り決め
- 番号を扱う環境へのアクセス：受託者がアクセスする場合の、作業場所、端末、アカウント、有資格者、ログ、持ち出し禁止の定め
納品物には、基本設計書、詳細設計書、プログラムがあります。ほかにも、テスト仕様書や移行計画書が含まれます。これらの納品物と検収基準は、契約書や個別仕様書に明記します。
保守契約と再委託の条件
保守の対応範囲、再委託先、契約終了時の扱いは、契約時に具体的に決めておきます。改定への対応は、「法改正対応」に含む範囲と、追加開発になる規模まで契約で定めておく必要があります。
- 保守水準：問い合わせ受付時間、重大障害の初動時間、復旧目標
- 改定・安全対応：制度改正、標準仕様改定、脆弱性情報への対応、バックアップ確認、ログ監査、定期報告の取り決め
- 再委託：会社名・業務・データアクセスの有無、保管場所、国外移転の有無、監査方法
- 契約終了時：利用可能な形式でのデータ返却、バックアップやログを含む消去証明、移行支援費用
- 責任分界：委託範囲を広げるほど、発注者と受託者の境目を契約に明記する必要があります
マイナンバー管理システムの費用相場と見積の内訳
費用は、対象人数や画面数のほかにも、さまざまな要因で決まります。自治体の場合は、既存の基幹システムとの連携が費用を変える大きな要因になります。
標準仕様、データ移行、閉域網、端末も要因になります。さらに、セキュリティ評価、職員教育、制度改正も費用に関わります。そのため、以下に示す金額は、公開統計の全国平均ではなく、発注前に予算の幅を置くための推定レンジです。
発注方式別の初期費用と期間の目安
企業向けのサービスと、自治体向けの開発とでは、費用と期間の規模が大きく違います。下の5つの方式ごとに、目安を示します。
- 企業向け追加導入：既存人事労務サービスへの追加は初期無料から数十万円、月額数千円から数万円程度のケース
- マイナクラウド月額：最大10人は月額1,000円、最大30人は2,400円、最大60人は4,800円、最大100人は8,000円
- 初期支援：初期設定支援と従業員向けセミナーは、いずれも20万円から
- 自治体パッケージ：3,000万円〜1億円、6〜12か月。連携改修込みは8,000万円〜3億円、12〜24か月
- 自治体独自開発：3億円〜10億円超、18〜36か月程度
マイナクラウドの料金は税別です（出典：マイナクラウド「料金・導入方法」、2026年8月確認）。
自治体向けの金額と期間は、対象業務や人口によって変わる推定です。既存ベンダーや移行の難易度でも差が出ます。公開統計の全国平均や正式な入札価格を示すものではありません。
5年TCOでの比較
見積書では費目を分けたうえで、初期費用だけでなく5年TCOで比べます。
- 導入：要件定義、設計・開発、ライセンス、クラウド利用料
- 環境・移行：端末、カードリーダー、ネットワーク、データクレンジング、移行リハーサル
- 品質・運用：セキュリティ診断、受入テスト、教育、稼働立会い、保守
- 変更対応：制度・標準仕様改定、利用者・容量・帳票の追加、API変更、障害対応の単価
デジタル庁は、標準化対象事務の標準準拠システムへの移行後に、2018年度比で少なくとも3割の運用経費削減を目指す方針です。一方で、ガバメントクラウドに移行すると費用が増える自治体もあります（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年7月更新）。
クラウドだからといって必ず安くなるとは限らないため、初年度費用より、5年または10年の総保有コストと将来のベンダー変更の可能性を比べます。
委託先の選定と見積比較の確認点
知名度や見積総額だけでなく、同じ前提で比べられる評価表を作って委託先を選びます。自治体の場合は、住民情報や番号連携の経験、標準化やガバメントクラウドへの対応を確かめます。
地域の保守体制や入札参加資格、再委託の管理も見ておきます。企業では、給与・会計連携、従業員数の変化、税理士・社労士との権限分離も評価の観点になります。
委託先の実績・体制・標準化対応
類似事例は、対象人数や業務、既存システムまで確かめます。さらに、期間や移行件数、運用体制も見ておきます。
自治体向けの候補には、NEC、富士通Japan、日立システムズがあります。ほかに、NTTデータやTKC、RKKCSなどもあります。
各社には、住民情報や自治体基幹の分野、マイナンバーカード、行政連携に関する公開情報があります。ただし、適合性は事例とあわせて確認する必要があるため、提案書と自治体の調達公告・公開資料を照合します。
候補先の提案は、要件適合から費用・実現性まで同じ観点で採点します。
- 要件・安全：要件適合度30点、セキュリティと個人番号の取扱い20点
- 導入後の体制：移行・連携計画15点、保守体制15点
- 費用・実現性：5年TCO15点、提案の実現性5点
配点は案件に応じて調整し、価格だけで結果が決まらないように設計します。
実装担当者が契約後も配置されるか、営業担当者から引き継がれるかは、事前に確かめておきます。
見積比較の前提条件と除外項目
移行費が一社では含まれ、他社では別料金になっている場合、総額だけで比べると判断を誤ります。そのため、対象ユーザー数やデータ件数、連携先、環境数を共通条件にします。加えて、テスト・教育回数や問い合わせ件数、保守時間、制度改正対応も、前提に含めます。
各社の回答は、必須と推奨、任意と対象外に分けて整理します。また、標準機能と設定の違い、追加開発と運用回避策の違いを表にまとめます。
安い見積でデータ整備や外字、脆弱性診断が抜けていると、後から費用が膨らみます。バックアップや監査ログの保管、研修についても、抜けがないか見ます。高額な案に、不要な独自開発や端末がないかも確かめます。
2026年の動向と要件・保守への反映
2026年は自治体基幹業務の標準化やガバメントクラウド移行が続いています。そのため、標準仕様やデータ連携、文字、非機能要件の改定を前提にしておきます。
デジタル庁は2026年1月23日、iPhoneやAndroidに機能を追加できる「スマートフォンのマイナンバーカード」を案内しました（出典：デジタル庁「スマートフォンのマイナンバーカード」、2026年1月23日更新）。
将来の動向をすべて今すぐ実装する必要はありません。ただし、拡張できない設計は再開発費につながるため、導入時には、後から変えにくい項目を先に決めておきます。
- 本人確認：将来スマホ認証を採用する場合の方式、対応OS、紛失時の停止、ログ、問い合わせ責任者
- 拡張性：APIの有無、認証接続、標準形式、アプリとWebの役割分担、OSのサポート期限
- 契約条件：契約更新時の価格改定条件
- 導入体制：実装時期の第1段階と第2段階、制度・業務・ITの判断体制
マイナンバー管理システムの発注でよくある質問
自治体向けと企業向けで、回答が異なる質問もあります。対象範囲を確認しながら判断してください。
マイナンバー管理システムはどこまで外注できますか？
現状分析、RFP、要件定義は外注の対象です。設計・開発や移行、テストも任せられます。教育と運用保守も、外注の範囲に含まれます。
利用目的や業務ルール、権限承認は、発注者が担います。さらに、受入判定と事故時の最終判断も、発注者が下します。そのうえで、個人番号を扱う範囲と再委託は契約で限定し、外注する作業と発注者が持つ判断を分けておきます。
予算が決まっていなくても開発会社へ相談できますか？
相談できます。予算が未確定なら、詳細開発の見積より先に、現状分析や要件定義を準委任で依頼します。次に、概算費用と選択肢を整理します。
SaaSやパッケージ、連携改修、スクラッチについて、初期費用と運用費、期間を同じ条件で出してもらいます。優先順位をつけて、段階的な導入を検討します。
安い見積を選んでも問題ありませんか？
総額だけで選ぶのは危険です。移行や診断、教育、制度改正の範囲を確かめ、障害対応とデータ返却の有無もあわせて見ます。このため、除外項目を加えた比較総額で判断します。
特に、要件が抜けたまま出された安い見積は、発注後の追加費用を前提としている可能性があります。
まとめ
まず、自治体の住民系か企業の人事労務系かを分け、番号を使う業務と既存の連携を明確にします。次に、SaaSやパッケージ、連携改修、スクラッチを比べ、RFIの後にRFPへ要件を記します。
契約では、請負、準委任、保守を使い分けます。再委託や事故対応、データ返却と消去証明も確かめます。
移行、教育、セキュリティは、5年TCOに含めて比べます。クラウドや保守も同じ5年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を創業。