マイナンバー管理システム開発の発注/外注/依頼/委託方法について

マイナンバー管理システムの発注では、個人番号を保管する画面だけでなく、利用目的の限定、既存業務との照合、アクセス権限、監査ログ、廃棄までを一体で設計することが重要です。自治体向けでは住民記録・税・福祉などとの情報連携、企業向けでは人事労務・給与との連携があるため、単純な保管サービスと開発案件を同じ基準で比較できません。

本記事では、マイナンバー管理システムを発注・外注・委託するときの進め方を、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の選定、見積比較まで順に解説します。2026年時点の自治体システム標準化やスマートフォンのマイナンバーカードも踏まえ、発注後に追加費用や責任範囲で迷わないための実務的な確認項目をまとめます。

▼全体ガイドの記事
・マイナンバー管理システム開発の完全ガイド

マイナンバー管理システムを発注する前に知っておきたい全体像

発注前に最初に決めるべきことは、「誰の個人番号を」「どの事務で」「どこまでシステムに保持させるか」です。自治体住民系と企業の人事労務系では、対象データ、接続先、運用者、必要な安全管理措置が大きく異なります。

自治体向けのマイナンバー管理は、住民記録システム、統合宛名、税、国民健康保険、福祉、戸籍などの業務と、個人番号・住民票コード・宛名番号を正確に関連付ける基盤として考えます。番号の入力と保管だけを切り出すのではなく、異動情報の反映、情報照会・情報提供、帳票、職員権限、操作履歴、バックアップまでが発注範囲になりやすいです。

企業向けでは、従業員や支払先からの収集、本人確認、給与計算・年末調整・法定調書への出力、退職者の利用停止と廃棄が中心です。たとえばマイナクラウドは、2026年8月に確認した公式料金で、初期費用無料、最大10人で月額1,000円、最大100人で月額8,000円（いずれも税別）を掲げています。一方、freeeは有料のfreee会計またはfreee人事労務の契約者に、マイナンバー管理を追加料金なしで提供しています（出典: マイナクラウド「料金・導入方法」、freee「マイナンバー制度とfreeeマイナンバー管理」、2026年確認）。この価格帯は企業向けSaaSの例であり、自治体基幹系の開発費とは分けて考えます。

個人番号を扱うシステムでは、誰が何を閲覧・登録・出力できるのかを細かく設定し、番号の表示制御やマスキング、二要素認証、通信・保存時の暗号化、操作履歴の保存を要件に含めます。自治体では利用事務系、LGWAN接続系、インターネット接続系を分ける三層分離との整合性も確認が必要です。

委託先を選ぶときは、システムの安全性だけでなく、委託先の従業者教育、再委託先の管理、障害時の連絡、漏えい時の報告、契約終了時のデータ返却・消去まで確認します。個人情報保護委員会の「特定個人情報の適正な取扱いに関するガイドライン（事業者編）」は2025年6月に一部改正されており、発注仕様書と契約書を現行のガイドラインに照らして確認することが大切です（出典: 個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン（事業者編）」、2025年6月改正）。

マイナンバー管理システムの発注形態はどれを選ぶべきですか？

発注形態は、既製SaaSの利用、パッケージ導入、既存システムの連携改修、スクラッチ開発の4つに分けて比較すると判断しやすいです。結論として、独自業務が少ない企業はSaaS、自治体の標準化対象業務は標準準拠パッケージやクラウド、既存業務との深い連携が必要な場合はパッケージを軸にした追加開発が現実的です。

企業が収集・保管・利用・廃棄を効率化したいだけなら、SaaSを導入する方が早く、初期開発費も抑えやすいです。ただし、既存の給与・会計システムへの連携、複数法人の権限分離、税理士への限定共有、独自帳票が必要になると、オプションやAPI、導入支援費が追加されます。料金表だけでなく、データのエクスポート、退会時の返却、ログの保存期間、サポート範囲を確認します。

自治体では、標準準拠システムへの適合、データ要件・連携要件、行政事務標準文字、ガバメントクラウドとの接続性を確認したうえで、パッケージを比較します。デジタル庁は2026年7月28日に標準化関連資料を更新しており、データ要件や連携要件の改定予定も公開しています。発注時点の仕様書だけでなく、契約期間中の改定にどう追随するかを提案依頼書に書きます（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年7月28日更新）。

既存の住民記録、税、福祉、給与、会計などに個人番号管理を組み込む場合は、連携改修が発生します。個人番号そのものを各業務システムへ複製するのか、統合宛名や番号連携基盤で必要時だけ参照するのかによって、セキュリティと移行工数が変わります。データ項目、キー、更新タイミング、エラー時の再送、手作業での補正方法を先に決めます。

スクラッチ開発は、業務に合わせられる自由度が高い反面、制度改正、標準仕様の改定、暗号方式やOSの更新、担当者交代後の保守を発注者が長期に負担します。独自開発を選ぶ場合は、標準機能で代替できない業務上の効果、将来の利用者数、移行期限、5年から10年の保守体制を説明できる状態にします。理由が「既存の紙運用をそのまま画面化したい」だけなら、パッケージや業務改革を先に検討します。

RFPと要件整理はどのように進めますか？

RFPは、作ってほしい機能を並べる書類ではなく、発注者が解決したい業務課題と、提案者に守ってほしい条件を共有する書類です。まずRFIで市場の製品・導入方式・標準化対応を調べ、現行調査の結果をもとにRFPへ具体化すると、提案の比較可能性が高まります。

現行棚卸しでは、業務名、担当部署、利用者、入力項目、個人番号を利用する根拠、保存期間、出力帳票、連携先、処理件数、繁忙期、障害時の代替手順を一覧化します。自治体の場合は、住民異動が住民記録から税・福祉へいつ反映されるか、宛名番号との照合を誰が確認するか、外字や履歴をどう移行するかまで確認します。

RFIでは「対応できますか」だけでなく、標準機能で対応する範囲、設定で対応する範囲、追加開発になる範囲、対応できない範囲を分けて回答してもらいます。候補先には、類似規模の自治体・企業での導入時期、データ移行の件数、制度改正対応、障害復旧実績、再委託先、担当者の体制、契約終了時のデータ返却方法も質問します。

RFPの機能要件には、収集、本人確認、登録、変更、利用、検索、帳票出力、利用停止、廃棄証跡、申請・承認、問い合わせ対応を記載します。自治体なら番号付番・変更・廃止、カード交付・更新・失効、情報照会・情報提供、中間サーバーや既存業務との連携も対象にします。企業なら入社・扶養変更・退職、年末調整、法定調書、税理士や社労士との権限分離を明記します。

非機能要件には、可用性、性能、同時利用者数、バックアップ、RTO・RPO、監視、障害通知、脆弱性診断、侵入テスト、暗号鍵管理、ログ保存期間、アクセス元制御を含めます。データ移行では、対象件数、欠損や重複の扱い、文字コード、外字、照合エラーの確認者、移行リハーサル回数、旧システムとの並行稼働期間を決めます。要件を「安全にする」「使いやすくする」と書くだけでは見積比較できないため、測定方法や受入条件まで書きます。

契約形態は請負・準委任・保守をどう使い分けますか？

マイナンバー管理システムは、企画・要件定義、設計・開発、移行・テスト、運用保守で不確実性が変わります。すべてを一つの契約にまとめるより、成果物と責任を定義できる工程は請負、調査や伴走が必要な工程は準委任、稼働後の監視や改修は保守契約に分ける方が、発注者と受託者の責任を整理しやすいです。

請負契約は、合意した成果物を納期・品質条件に沿って完成させる工程に向いています。基本設計書、詳細設計書、プログラム、テスト仕様書、移行計画書など、納品物と検収基準を契約書や個別仕様書で明確にします。ただし、発注時点で業務要件が固まっていないのに全工程を請負にすると、変更のたびに追加費用や納期延長が発生しやすいです。

準委任契約は、現状分析、要件定義、RFP作成支援、PMO、移行伴走など、作業時間や専門性を提供してもらう工程に向いています。準委任だから成果物が不要という意味ではなく、会議体、作業範囲、稼働時間、報告書、課題管理表、意思決定者を決めておく必要があります。特に個人番号を扱う環境へ受託者がアクセスする場合は、作業場所、端末、アカウント、有資格者、ログ、持ち出し禁止を明記します。

保守契約では、問い合わせ受付時間、重大障害の初動時間、復旧目標、制度改正や標準仕様改定への対応、脆弱性情報への対応、バックアップ確認、ログ監査、定期報告を具体化します。「法改正対応を含む」とだけ書かず、どの範囲を通常保守とし、どの規模から追加開発とするのかを決めます。

再委託がある場合は、再委託先の会社名・業務・データへのアクセス有無・保管場所・国外移転の有無・監査方法を把握します。契約終了時には、発注者がデータを利用可能な形式で返却してもらえること、バックアップやログを含めて消去証明を受け取れること、移行支援の費用がいくらかかることを確認します。委託先に任せるほど、責任分界を細かく書くことが重要です。

マイナンバー管理システムの費用相場と見積の内訳

マイナンバー管理システムの費用は、対象人数と画面数だけでは決まりません。自治体向けでは既存基幹システムとの連携、標準仕様への適合、データ移行、閉域ネットワーク、端末、セキュリティ評価、職員教育、制度改正対応が大きな変動要因になります。以下の金額は公開統計に基づく全国平均ではなく、発注前に予算幅を置くための推定レンジです。

企業が既存の人事労務サービスにマイナンバー管理を追加する場合は、初期費用が無料から数十万円、月額が数千円から数万円程度になるケースがあります。公開料金の一例では、マイナクラウドが最大10人で月額1,000円、最大30人で2,400円、最大60人で4,800円、最大100人で8,000円を提示しています。初期設定支援は20万円から、従業員向けセミナーも20万円からとされており、月額料金以外の導入支援費も存在します（出典: マイナクラウド「料金・導入方法」、2026年8月確認）。

自治体向けの既存パッケージ導入・設定は3,000万円から1億円、住民記録・税・福祉との連携改修を含めると8,000万円から3億円、独自要件の大規模更改やスクラッチ開発では3億円から10億円超を目安に置きます。期間は、パッケージ導入で6か月から12か月、連携改修で12か月から24か月、独自開発で18か月から36か月程度を想定します。これらは対象業務、人口、既存ベンダー、移行難易度による推定であり、正式な入札価格ではありません。

見積書では、要件定義、設計・開発、ライセンス、クラウド利用料、端末・カードリーダー、ネットワーク、データクレンジング、移行リハーサル、セキュリティ診断、受入テスト、教育、稼働立会い、保守を分けて記載してもらいます。さらに、制度改正、標準仕様改定、利用者追加、保存容量増加、帳票追加、API変更、障害対応の単価も確認します。

デジタル庁は、標準化対象事務の標準準拠システムへの移行後、2018年度比で少なくとも3割の運用経費削減を目指す方針を示しています。ただし、ガバメントクラウドへの移行で費用増が見込まれる自治体もあると説明されているため、クラウドなら必ず安くなるとは限りません（出典: デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年7月更新）。発注時は初年度の安さより、5年または10年の総保有コストと、将来のベンダー変更可能性を比較します。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や見積総額だけで選ばず、同じ前提条件で比較できるように評価表を作ります。特に自治体案件では、住民情報や番号連携の経験、標準化・ガバメントクラウドへの対応、地域の保守体制、入札参加資格、再委託管理を確認します。企業案件でも、給与・会計連携、従業員数の増減、税理士や社労士との権限分離が評価軸になります。

提案時には、類似する自治体または企業の導入事例を、対象人数、対象業務、既存システム、導入期間、移行件数、運用体制まで具体的に確認します。自治体向けでは、NEC、富士通Japan、日立システムズ、NTTデータ、TKC、RKKCSなど、住民情報、自治体基幹、マイナンバーカード、行政連携に関する公開情報がある企業を候補にできます。ただし、実在する導入事例があることと、自社・自団体の要件に適合することは別なので、提案書だけでなく自治体の調達公告や公開資料も突き合わせます。

評価表では、要件適合度を30点、セキュリティと個人番号の取扱いを20点、移行・連携計画を15点、保守体制を15点、5年TCOを15点、提案の実現性を5点のように配点します。配点は案件に応じて変更しますが、価格だけで決まらない仕組みにすることが大切です。提案者が実装担当者を契約後も配置するのか、営業担当者から引き継ぐのかも確認します。

見積比較で最も多い失敗は、A社が移行費を含み、B社が別途費用としている状態で総額だけを比べることです。見積依頼書に、対象ユーザー数、データ件数、連携先、環境数、テスト回数、教育回数、稼働後の問い合わせ件数、保守時間、制度改正対応の有無を共通条件として書きます。

各社の回答は、必須・推奨・任意・対象外に分類し、標準機能、設定、追加開発、運用回避策の違いを表にします。初期費用が安い見積でも、データクレンジング、外字対応、脆弱性診断、バックアップ、監査ログの長期保管、職員研修が除外されていれば、後から費用が膨らみます。逆に高額な提案は、必要のない独自開発や過剰な端末を含んでいないかを確認します。

2026年は、自治体基幹業務の標準化・ガバメントクラウド移行が続いており、標準仕様、データ連携、文字、非機能要件の改定を前提にする必要があります。また、デジタル庁は2026年1月23日更新の情報で、マイナンバーカードの機能をiPhoneやAndroid端末へ追加できる「スマートフォンのマイナンバーカード」を案内しています。カードだけでなくスマートフォンによる本人確認を将来採用する可能性がある場合は、認証方式、対応OS、端末紛失時の停止、ログ、問い合わせの責任者を要件に含めます（出典: デジタル庁「スマートフォンのマイナンバーカード」、2026年1月23日更新）。

将来動向をすべて今すぐ実装する必要はありませんが、拡張できない設計にすると再開発費が発生します。APIの有無、認証基盤との接続方式、データの標準形式、アプリとWebの役割分担、OSのサポート期限、契約更新時の価格改定条件を確認し、実装時期を第1段階・第2段階に分けます。発注者側で制度・業務・ITの判断をできる体制を作ることも、委託先に任せきりにしない重要な対策です。

マイナンバー管理システムの発注でよくある質問

ここでは、発注前に特に質問されやすい内容をまとめます。自治体向けと企業向けで回答が変わる質問もあるため、自社・自団体の対象範囲を確認しながら判断してください。

現状分析、RFP作成、要件定義、設計・開発、データ移行、テスト、教育、運用保守まで外注できます。ただし、利用目的の決定、業務ルール、権限承認、受入判定、事故時の最終判断は発注者が担う必要があります。個人番号を扱う範囲と再委託を契約で限定し、外注する作業と発注者が保持する判断を分けてください。

相談できます。予算が未確定の段階では、いきなり詳細開発の見積を依頼せず、現状分析や要件定義を準委任で依頼し、概算費用と選択肢を整理する方法があります。候補先には、SaaS、パッケージ、連携改修、スクラッチの初期費用・運用費・期間を同じ前提で出してもらい、優先順位をつけて段階導入を検討します。

総額だけで安い見積を選ぶのは危険です。移行、セキュリティ診断、教育、制度改正、障害対応、データ返却などが含まれているかを確認し、含まれない項目を加えた比較総額で判断してください。要件の抜けが多い段階では、安い見積が安いのではなく、発注後に追加費用が発生する前提で提示されている可能性があります。

まとめ

マイナンバー管理システムの発注では、最初に自治体住民系か企業人事労務系かを切り分け、個人番号を利用する業務と既存システムとの連携範囲を明確にします。そのうえで、SaaS、パッケージ、連携改修、スクラッチの発注形態を比較し、RFIで市場を把握してからRFPに機能・データ・非機能・移行・保守の条件を書き込みます。

契約は、要件が固まった成果物を請負、調査や伴走を準委任、稼働後の監視や制度改正を保守として整理し、再委託、事故対応、データ返却、消去証明まで確認します。見積は初期費用だけでなく、移行・教育・セキュリティ・クラウド・保守を含む5年TCOで比べることが、発注後の予算超過を防ぐポイントです。

デジタル庁の標準化やスマートフォンのマイナンバーカードなど、発注後も制度と技術は変化します。現時点の要件を満たすだけでなく、標準仕様改定、認証方式の追加、ベンダー変更、契約終了後のデータ移行に対応できる設計と契約を選び、委託先と発注者の責任を最初から明確にしておくことが大切です。

▼全体ガイドの記事
・マイナンバー管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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