マイナンバー管理システム開発の完全ガイド

マイナンバー管理システムとは、個人番号を単に保存するだけでなく、利用目的を限定し、本人情報との正確な紐付け、アクセス制御、操作履歴、連携、保存期間、廃棄までを管理する業務基盤です。自治体向けでは住民記録や税・福祉などの基幹業務との連携が重要で、企業向けでは従業員や支払先の収集・保管・提出を安全に効率化する役割があります。

本記事では、自治体住民系を主軸に、マイナンバー管理システムの全体像、種類、主な機能、開発の進め方、費用相場、開発会社・サービスの選び方、発注・外注の進め方、セキュリティ、運用、FAQまでを整理します。企業の人事労務系システムを検討している場合にも、どこまで共通し、どこから要件が分かれるのかを判断できるように解説します。

▼関連記事一覧
・マイナンバー管理システム開発の進め方
・マイナンバー管理システム開発でおすすめの開発会社6選と選び方
・マイナンバー管理システム開発の見積相場・費用
・マイナンバー管理システム開発の発注・外注・委託方法

マイナンバー管理システムとは何ですか？

マイナンバー管理システムは、特定個人情報を業務上必要な範囲で利用し、誰が、いつ、何の目的で扱ったかを追跡できるようにする仕組みです。自治体と企業では扱うデータや業務が異なるため、最初に対象を切り分けることが欠かせません。

自治体住民系は、住民記録を中心に、住民票コード、宛名番号、個人番号を正確に関連付け、社会保障、地方税、防災など法令で認められた事務に利用します。住民の異動、出生、死亡、転入、転出、氏名変更などを複数の業務へ反映するため、番号だけを登録する画面では不十分です。誤紐付けを防ぐ照合、職員の職務に応じた権限、窓口業務の継続性まで含めて設計します。

企業人事労務系は、従業員や扶養親族、報酬の支払先から番号を収集し、本人確認、保管、給与・年末調整・法定調書への出力、退職後の保存と廃棄を管理します。従業員数に応じた月額サービスで足りる場合もありますが、給与、人事、会計との連携や複雑な権限管理が必要なら追加開発を検討します。

個人番号は、法令に基づき利用される12桁の番号です。マイナンバーカードは本人確認や電子証明書に使うカードであり、個人番号そのものを自由に読み取ってよいという意味ではありません。住民票コードは住民を識別するための番号、宛名番号は自治体内部の住民管理で使う番号です。これらを同じ項目として扱うと、連携先の誤りや権限の過剰付与につながります。

また、JPKIは公的個人認証サービスによる本人確認、LGWANは行政機関向けの閉域性を持つネットワーク、中間サーバーは情報照会・情報提供を仲介する基盤です。用語の役割を要件定義書に書き分け、どのデータがどの経路を通るかを図にすると、関係者間の認識を合わせやすくなります。

マイナンバー管理システムの主な機能と構成

必要な機能は対象業務によって変わりますが、共通する考え方は「正確に登録する」「必要な人だけが使う」「利用状況を検証できる」「不要になった情報を適切に処分する」の4点です。自治体向けでは連携と可用性、企業向けでは収集と給与・会計連携の比重が大きくなります。

登録機能では、収集した番号の入力、本人確認、重複検知、変更・廃止、保存期間の設定を行います。自治体では住民異動にともなう更新や、住民票コード・宛名番号との照合が中心です。番号の入力値だけを正しくしても、別人の宛名番号へ結び付けば重大な事故になるため、検索条件、候補表示、二者確認、エラー時の差し戻しを業務フローに組み込みます。

連携機能では、住民記録、地方税、国民健康保険、年金、福祉、児童手当、戸籍などの業務システムとデータを受け渡します。連携方式はAPI、ファイル連携、メッセージ連携などから選び、項目定義、文字コード、更新頻度、再送、重複排除、失敗時の通知を決めます。中間サーバーやマイナポータルなど外部基盤と接続する場合は、許可する通信と保持するログも明文化します。

権限は、所属だけでなく担当業務、操作の種類、対象データ、時間帯、端末などを組み合わせて設計します。個人番号を常に画面へ表示するのではなく、通常はマスキングし、許可された操作だけ一時表示する方式が安全です。登録、閲覧、出力、訂正、削除、権限変更のそれぞれに承認を求めることも検討します。

監査ログには、利用者、日時、端末、対象者、操作、結果、承認者を記録し、改ざんを検知できる状態で保管します。ログは保存するだけでなく、異常な大量照会、業務時間外のアクセス、短時間の連続失敗を検知できるようにします。バックアップ、暗号化、鍵の管理、媒体持ち出しの制御、障害時の復旧も、機能一覧ではなく非機能要件として別に記載します。

方式はパッケージ・クラウド・スクラッチのどれが適していますか？

方式の結論は、既存業務との適合度、標準仕様への対応、セキュリティ境界、移行負荷、5年から10年の総額で判断します。自治体の基幹業務を番号管理だけのSaaSへ置き換えることは難しく、標準準拠システムや既存パッケージを核に連携を設計するケースが現実的です。

パッケージは、住民記録や番号連携などの共通機能が整い、制度改正への対応方針や導入手順を確認しやすい点がメリットです。業務を標準機能に合わせられる範囲が広いほど、開発期間と将来の保守負担を抑えやすくなります。一方、現行システムの独自帳票、外字、例外処理をそのまま残したい場合は、追加開発や周辺ツールが増えます。

選定時は、標準仕様のどの版に対応するか、データ要件・連携要件の更新をどう反映するか、制度改正時の費用が保守料に含まれるかを確認します。デジタル庁は2026年にも共通機能やデータ要件・連携要件の標準仕様を更新しているため、契約時点の適合だけでなく、更新への追随方法を評価することが大切です（出典：デジタル庁「共通機能の標準仕様」、2026年）。

クラウドは、冗長化、監視、バックアップ、災害対策をサービスとして利用しやすく、複数業務や共同利用を進める場合に有効です。ただし、マイナンバー利用事務系、LGWAN接続系、インターネット接続系を分ける三層分離、データの所在、管理者権限、ログの閲覧範囲、通信経路、利用料の変動を確認します。クラウドを選ぶだけで安全になるわけではなく、境界と責任分界を設計する必要があります。

スクラッチは、独自の住民サービス、複雑な業務フロー、既存システムでは実現できない連携を作り込めます。一方、制度改正、標準仕様改定、脆弱性対応、担当者交代、保守要員の確保を長期間負担します。独自開発を選ぶなら、独自性が住民サービスや職員業務にどの程度の価値を生むのかを数値化し、標準機能で代替できない部分だけに絞ります。

マイナンバー管理システム開発の進め方

開発は、画面やデータベースを先に作るのではなく、利用目的、対象業務、既存データ、通信境界、運用責任を先に固めます。特に自治体では、現行システムの棚卸しと移行リハーサルが品質を左右します。以下の工程を、要件定義、設計・開発、テスト・移行・運用準備の3段階で進めます。

最初に、個人番号を扱う事務、利用目的、担当者、保存期間、廃棄条件、第三者提供、委託・再委託の範囲を一覧化します。自治体なら住民記録、税、福祉、カード交付などの業務ごとに、番号を使う場面と使わない場面を切り分けます。企業なら入社、扶養変更、年末調整、退職、支払調書というライフサイクルで整理します。

次に、データ項目、コード、外字、履歴、連携頻度、帳票、権限、ログ、障害時の手作業を棚卸しします。住民票コード、宛名番号、個人番号の照合ルールと二重確認を要件に含め、移行前の重複、欠損、表記揺れを検出する計画も作ります。RFPには機能要件と非機能要件を分けて記載し、提案者が同じ条件で比較できる状態にします。

設計では、番号を扱う領域と外部ネットワークの接続を整理し、三層分離の各領域で許可する通信を定義します。画面設計ではマスキング、再認証、出力制御、承認を組み込み、データ連携では項目、形式、送受信時刻、再送、エラー通知を決めます。ログの改ざん防止、暗号鍵の保管、バックアップ世代、復旧目標もこの段階で確定します。

開発中は、現場職員、窓口担当、情報政策担当、監査担当が設計レビューに参加します。システム担当だけで決めると、現場の例外処理や繁忙期の運用が漏れやすいためです。カードリーダー、認証、帳票、連携バッチなど外部要素を含む場合は、早期に小さな連携検証を行い、後工程での手戻りを抑えます。

テストは、機能テストだけでなく、権限テスト、誤入力テスト、連携テスト、負荷テスト、障害復旧テスト、脆弱性診断、ログ監査を行います。特に、権限のない職員が検索・出力できないか、異常な大量照会を検知できるか、通信断から復旧したときに二重登録や欠落が起きないかを確認します。

データ移行は、抽出、変換、クレンジング、件数照合、サンプル照合、承認、切り戻しの手順を作ります。外字や住所表記、過去履歴、廃止データの扱いを先送りすると、稼働後の窓口業務に影響します。移行リハーサルを複数回行い、職員教育、操作マニュアル、問い合わせ窓口、制度改正時の更新手順まで準備してから本稼働します。

▶ 詳細はこちら：マイナンバー管理システム開発の進め方

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

自治体向けのマイナンバー管理機能単体について、全国平均として公表された価格統計は確認できません。そのため、以下は自治体基幹系・番号連携系の類似案件から整理した、企画・見積前の推定レンジです。人口、対象業務数、既存ベンダー、データ品質、標準化対応、ネットワーク、セキュリティ要件によって大きく変わるため、入札価格や正式な相場とは分けて考えます。

企業向けに番号の収集・保管だけを行うクラウドサービスなら、初期費用0円から30万円程度、月額1,000円台から数万円程度で利用できる公開料金の例があります。小規模な事業者では数日から1か月程度で導入できる場合がありますが、給与・会計連携、複雑なワークフロー、既存データ移行を含めると別途費用が発生します（出典：サービス提供元の公開料金ページ、2026年8月確認）。

自治体向けでは、既存パッケージの導入・設定だけなら3,000万円から1億円程度、住民記録・税・福祉との連携改修を含めると8,000万円から3億円程度、独自要件の大規模更改やスクラッチ開発では3億円から10億円超が企画段階の推定レンジです。期間は、パッケージ導入で6か月から12か月、連携改修を含むと12か月から24か月、全体更改では18か月から36か月程度を見込みます。いずれも個別見積が必要です。

費用は、要件定義、設計・開発、ライセンス、データ移行、連携APIや中間サーバー、端末・カードリーダー、ネットワーク、セキュリティ評価、教育、保守、クラウド利用料、制度改正対応、障害対応に分けます。初期費用が低く見えても、移行リハーサル、脆弱性診断、ログ監視、休日対応、データ返却が別料金なら、稼働後に予算が膨らみます。

デジタル庁は、標準化対象事務の運用経費について、標準準拠システムへの移行完了後に2018年度比で少なくとも3割削減を目指す方針を示しています。ただし、これは個別案件の値下げを保証する数字ではありません。自組織の5年または10年TCOを、現行維持、パッケージ、クラウド、独自開発で比較し、職員作業や制度改正対応まで含めて判断します（出典：デジタル庁「地方公共団体の基幹業務システムの統一・標準化」、2026年）。

▶ 詳細はこちら：マイナンバー管理システム開発の見積相場・費用

法令・セキュリティ要件で確認すべきこと

特定個人情報は、通常の個人情報と同じ感覚で扱えません。利用目的、取得、保管、委託、アクセス、提供、廃棄、漏えい時の対応を業務規程とシステムに落とし込み、運用担当者が説明できる状態にします。システムの安全性だけでなく、誤操作や委託先の管理を含む組織的な安全管理措置が必要です。

個人番号を扱う業務ごとに、利用できる担当者、利用目的、照会や出力の条件、保存期間、廃棄方法を定義します。委託する場合は、委託先の安全管理、再委託の可否、アクセス権限、監査権、事故時の連絡期限、契約終了時の返却・消去を契約に含めます。自治体では個人情報保護評価や内部監査の資料と、システムログを突合できる設計にします。

個人情報保護委員会の特定個人情報ガイドラインは、2025年6月に一部改正されています。制度やガイドラインの更新を監視し、改正時に影響範囲、テスト、教育、規程改定を実施する責任者を決めます（出典：個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン」、2025年6月改正）。

技術面では、通信の遮断、認証失敗、権限逸脱、暗号化、バックアップ復元、ログの改ざん検知、脆弱性、マルウェア感染、災害時の切り替えを確認します。業務面では、転入・転出、氏名変更、出生・死亡、扶養変更、退職、再雇用、番号の訂正・廃棄を実データに近い検証データで確認します。

受入条件は「画面が動く」ではなく、正しい担当者が正しい範囲だけを操作でき、異常時に発見・停止・報告・復旧できることです。復旧時間の目標、許容できるデータ損失、代替手順、連絡網、再開判断者を定め、年1回以上の訓練や監査につなげます。

開発会社・サービスの選び方

開発会社やサービスは、知名度や初期見積の安さだけで決めません。自治体向けか企業向けか、標準化や既存連携に対応できるか、特定個人情報を扱う体制があるか、導入後の制度改正や障害対応を任せられるかを同じ評価表で比べます。

「自治体の導入実績がある」という一文だけでは不十分です。人口規模、対象業務、住民記録との連携、カード交付や窓口業務の有無、標準準拠版への移行経験、移行データの件数、稼働後の保守体制を確認します。可能であれば、公開された調達資料や導入先の運用資料と、提案内容が一致しているかを照合します。

企業向けサービスでは、管理人数の上限、本人確認の方法、給与・会計システムとの連携、退職者データの扱い、管理者の分離、データのエクスポート、サポート時間を見ます。無料トライアルの有無だけでなく、契約終了時にデータを安全に返却・消去できるかも重要です。

提案依頼では、標準仕様の対応版、制度改正時の更新方法、データ移行の責任範囲、外字・コード変換の方法、地域の保守要員、障害時のSLA、再委託先、脆弱性対応、監査への協力、5年TCOを質問します。回答は口頭で受けず、提案書、見積明細、体制表、契約書案に残します。

評価項目は、機能適合、セキュリティ、移行、運用、保守、プロジェクト管理、価格の順に重みを設定します。価格だけで順位を決めると、移行や制度改正対応が別料金になりやすいためです。要件の不明点を質問してくれる提案者か、標準機能に合わせる範囲と追加開発の範囲を正直に示す提案者かも見極めます。

▶ 詳細はこちら：マイナンバー管理システム開発でおすすめの開発会社6選と選び方

発注・外注・委託を進める方法

外注では、要件が固まっていない状態で開発会社へ丸投げしないことが重要です。RFIで現状課題や選択肢を把握し、RFPで機能・非機能・移行・セキュリティ・保守・成果物・検収を明記し、複数の提案を同じ条件で比較します。

RFIでは、現在の業務フロー、既存システム、対象業務、データ量、ネットワーク制約、困っていることを簡潔に示し、パッケージ、クラウド、連携改修、段階導入の可能性を尋ねます。RFIの回答をもとに、自組織が標準機能へ合わせられる範囲と、残すべき独自要件を整理します。

RFPでは、必須・加点・対象外を分け、画面一覧、連携一覧、データ移行、三層分離、認証、ログ、バックアップ、監査、教育、SLA、再委託、契約終了時のデータ返却を記載します。見積回答は初期費用、運用費、追加費用、制度改正、作業単価、前提条件に分けてもらい、比較表へ転記します。

契約では、成果物、検収基準、遅延時の扱い、仕様変更、瑕疵対応、保守範囲、制度改正、脆弱性対応、障害報告、再委託、秘密保持、監査、データ返却・消去を確認します。要件定義を別契約にする場合は、次の開発契約へ何を引き継ぐのか、要件が未確定のまま進む場合の追加費用を明確にします。

検収は、機能の動作だけでなく、移行件数の一致、権限マトリクス、ログの取得、復旧訓練、マニュアル、教育、監査資料を対象にします。発注者側にも、意思決定者、業務責任者、セキュリティ責任者、現場の受入担当者を置き、質問への回答やデータ確認を滞らせない体制が必要です。

▶ 詳細はこちら：マイナンバー管理システム開発の発注・外注・委託方法

2026年時点の最新動向と将来の備え

2026年は、自治体基幹業務の標準化、ガバメントクラウド、標準化されたデータ連携、電子証明書やスマートフォンを活用した本人確認が並行して進む時期です。目先の機能を作るだけでなく、標準仕様や認証方式が更新されても交換できる構成にしておくことが、長期の費用とリスクを抑えます。

地方公共団体の基幹業務システムは、標準化対象事務を標準準拠システムへ移行する方向で進められています。2026年4月にもデータ要件・連携要件の標準仕様が更新されているため、開発会社に対して、対応する仕様書の版、適合確認の方法、更新時の影響分析とテストの責任範囲を尋ねます（出典：デジタル庁「データ要件・連携要件の標準仕様」、2026年）。

ガバメントクラウドを採用する場合も、アプリケーション、データ、ネットワーク、認証、監視、バックアップの責任分界を確認します。クラウド上で動くこと自体を目的にせず、標準化で業務をどう見直すか、既存データをどう移すか、障害時に住民窓口をどう継続するかまで設計します。移行期限だけでなく、移行後の運用経費と職員負担も評価します。

外部制度や認証方式の変更に備え、業務データと連携アダプターを分離し、コード変換、認証、通知、ログを共通部品として管理します。番号を直接参照する画面を増やさず、必要な業務だけが安全なサービスを通して利用する構成にすると、仕様変更時の影響範囲を絞れます。

運用面では、制度改正の情報収集、影響分析、リリース、教育、監査、障害訓練を年間計画にします。担当者の異動に備え、業務フロー、権限表、連携仕様、復旧手順、契約・SLA、問い合わせ履歴を一つの管理台帳にまとめます。開発時の担当者しか分からないシステムにしないことが、最も現実的な将来対策です。

マイナンバー管理システムに関するよくある質問

ここでは、自治体と企業の担当者から特に質問されやすい内容をまとめます。対象業務とデータの種類を切り分けると、自組織に必要な機能や相談先が見えやすくなります。

従業員や支払先の番号を収集・保管し、給与や法定調書へ出力するだけなら、公開されているクラウドサービスで足りる場合があります。ただし、本人確認、複数会社の管理、給与・会計連携、独自承認、保存・廃棄ルール、監査ログが必要なら、サービスの標準機能と追加開発の範囲を確認してください。

分けられるかどうかは、利用事務、既存システムの責任分界、標準仕様、連携方式によって異なります。番号だけを切り出すと、住民異動や宛名管理との整合性を別途保つ必要があるため、まず共通基盤に残す機能と周辺へ切り出す機能を業務フローで整理し、連携検証を行ってから判断します。

最初に、対象業務、独自要件、移行データ、連携先、保守範囲を明確にし、標準機能で対応できる部分と追加開発が必要な部分を分けます。初期費用だけでなく、制度改正、監査、バックアップ、障害対応、教育、クラウド利用料を含む5年TCOを比較し、使わない機能を作らないことが有効です。

類似業務の実績、標準仕様への対応、データ移行の経験、セキュリティ体制、再委託、障害時の連絡・復旧、制度改正、契約終了時のデータ返却を確認します。提案書だけでなく、担当者の体制表、見積の前提、検収条件、保守契約案に記載されているかを確認し、複数の候補を同じ評価表で比べます。

まとめ

マイナンバー管理システムは、個人番号を保管するだけの仕組みではありません。自治体では住民記録、宛名管理、番号連携、カード・電子証明書、税・福祉などの業務を正確につなぎ、企業では収集、本人確認、給与・会計連携、保存、廃棄を安全に運用する基盤です。最初に対象を自治体住民系と企業人事労務系に分け、個人番号、住民票コード、宛名番号、カード情報の役割を整理します。

導入時は、現行業務とデータを棚卸しし、利用目的、権限、ログ、三層分離、連携、移行、復旧を要件化します。パッケージ、クラウド、スクラッチは初期費用だけでなく、標準化への適合、制度改正、5年TCO、保守、契約終了時のデータ返却で比較します。RFIとRFPを使って提案条件を揃え、類似実績、移行体制、セキュリティ、再委託、障害対応、検収条件を確認すると、導入後の想定外を減らせます。

▼関連記事一覧
・マイナンバー管理システム開発の進め方
・マイナンバー管理システム開発でおすすめの開発会社6選と選び方
・マイナンバー管理システム開発の見積相場・費用
・マイナンバー管理システム開発の発注・外注・委託方法