住民 ID の統合｜既存の利用者データを移すときに決める 10 のこと

本記事は、2026年10月30日時点で公開されている資料をもとにした一般的な観点の整理です。法令やガイドラインの解釈、個別の統合計画の判断は、各自治体の個人情報保護と情報セキュリティの所管部門、システムを提供する事業者、必要に応じて専門家に確認してください。ガイドラインや解説書は改訂が続くため、実際の作業の時点で最新の版を確認してください。

住民 ID の統合とは｜アカウントをまとめることと、データを移すこと

「統合」という言葉には、性質の違う作業が混ざっています。まず、自治体が何をしようとしているのかを分けておくと、決めることが見えやすくなります。

• ログインの共通化 — 各サービスの利用者番号は残したまま、共通のログインでサービスに入れるようにします。仕組みは「自治体の OpenID Connect による SSO 入門」で整理しています
• アカウントの統合 — 同じ住民が複数のサービスに持つアカウントを、1 つの住民 ID に結び付けます。本記事の中心です
• データの移行 — 旧サービスにある利用履歴や登録情報を、新しい基盤へ移します。アカウントの統合と同時に行うことも、別に行うこともあります

SSO の導入にともなう紐付けについて、同記事の「既存の ID をどうつなぐか｜紐付けと移行」では、sub を鍵にする、初回ログイン時に本人であることを確かめる、利用者番号を残す、手順と期間を仕様書に書く、の 4 点を挙げています。本記事は、その先にある「何を寄せ、誰を寄せ、どう確かめ、どう戻すか」を掘り下げます。

決めることの全体像は、次のとおりです。

表は横にスクロールできます

個人情報保護の観点｜移す前に所管部門と確認すること

統合は、個人情報の集め方・使い方を変える作業でもあります。個人情報保護委員会の資料（行政機関等向け）で、移行に関わる点を確認します。なお、これらは自治体の機関にも適用される規律ですが、個別の判断は所管部門の仕事です。

1. 利用目的の範囲に収まるか — ガイドライン（行政機関等編）は、利用目的をできるだけ具体的かつ個別的に特定すること、特定した利用目的の達成に必要な範囲を超えて保有しないことを求めています。利用目的を変更する場合は、変更前と相当の関連性を有すると合理的に認められる範囲を超えてはならない、とされています。Q&A（行政機関等編）は、利用目的以外の利用・提供は臨時的に行う場合の例外で、恒常的に行う場合は、あらかじめ利用目的として特定するか、利用目的を変更する必要がある、としています。旧サービスで集めた情報を、共通の ID に恒常的にまとめて使うのであれば、この整理の対象になると考えられます（本記事の整理）
2. 「機関」が分かれていないか — ガイドラインは、地方公共団体の機関に、市区町村長のほか教育委員会などが含まれるとしています。Q&A は、同じ地方公共団体の異なる機関の間で、法令に基づかず利用目的以外の目的のために保有個人情報を提供する場合は、本人や第三者の権利利益を不当に侵害するおそれがなく、かつ法第 69 条第 2 項第 3 号の要件を満たす必要がある、としています。サービスを所管する機関が分かれている場合は、データを寄せる前に確認します
3. 委託先の範囲と管理 — 移行作業を事業者に委託する場合、ガイドラインは、委託先の選定基準と、契約への必要な条項（委託先での情報管理、再委託先の選定、監査など）、定期的な監査などによる必要かつ適切な監督を挙げています。事務対応ガイドの別添指針（4-8-9）には、契約書に明記する事項として、複製等の制限や、委託終了時の個人情報の消去・媒体の返却などがあります。委託する個人情報の範囲は、委託する業務に照らして必要最小限とすること、提供や委託の際には必要に応じて特定の個人を識別できる記載を削除または置き換えることも書かれています。移行用に作る抽出ファイルや試験用のデータも、この対象に含めて考えます（本記事の整理）
4. 個人情報ファイル簿の見直し — 行政機関の長等は、保有する個人情報ファイルについてファイル簿を作成・公表します。Q&A によれば、本人の数が 1,000 人未満のファイルは作成・公表義務の対象外ですが、作成・公表することは妨げられません。事務が廃止されても、ファイルを保有している限りは対象で、保有をやめたときは、公表中のファイル簿から遅滞なく削除する必要があります。旧システムのデータをどの時点まで保有するかは、ファイル簿の更新時期にも関わります
5. 移行の検証と、移行後の抹消 — 総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」（令和8年3月版）は、システムの更新・統合時に、リスク管理体制の構築、移行基準の明確化、更新・統合後の業務運営体制の検証を行うこと（第 2 編・第 3 編、システム開発、導入、保守等の項）を求めています。また、データを移行する際は、移行完了後に移行元のデータを抹消する必要がある、としています

この ID 統合に特化した手順を定めた公的資料は、確認できた範囲ではありませんでした。上の資料は、統合に当てはめて読める一般的な規律です。

統合で決める 10 のこと

決めること 1　統合の対象

最初に、どのアカウントを統合するかを決めます。サービスが増えるほど、対象の線引きが曖昧になります。次の 3 つの軸で整理すると、後の判断が楽になります（本記事の整理）。

• サービス — 図書館、施設予約、イベント、子育てなど、どのサービスを今回の対象にするか。所管する部署や機関が違う場合は、上の「個人情報保護の観点」で触れた確認を先に行います
• 利用者の範囲 — 住民だけか、在勤・在学の人や、他の自治体の住民も含むか。新しい住民 ID を持てない利用者の扱いも決めておきます
• アカウントの状態 — 有効、長く使われていない、退会済み、重複している、のうちどれを対象にするか。扱いは「休眠アカウントと退会」で決めます

決めること 2　名寄せのルールと誤統合

名寄せとは、複数のサービスにある同じ人のデータを、1 人にまとめることです。DS-511 は、身元確認の脅威として「重複登録」（同一の申請者による重複申請を検知できない）と「別人との誤紐づけ」（申請者と別の人物を区別できず、誤った人物の情報と紐づけてしまう）を挙げています。そして、属性情報を正確に収集できないと、重複登録や別人との誤紐づけの原因になるため、誤記や表記揺れのほか、改姓や改名、住所変更、通称、外国語の表記法、文字コード、異体字や外字の取扱いなどを考慮するよう述べています。

名寄せの鍵になりうる項目には、それぞれ弱点があります。次の表は、DS-511 の考え方を踏まえた本記事による整理です。

表は横にスクロールできます

個人番号（マイナンバー）の利用は、法令で利用できる事務が定められているため、本記事では名寄せの鍵として扱いません。使えるかどうかは、所管部門に確認してください。

そのうえで、判定の結果を 3 つに分け、扱いを変える設計が考えられます。「一致が確実」は、複数の項目が正規化後に一致し、同じ人でないと説明がつかない場合です。「候補」は、一部だけが一致する場合です。「一致しない」は、寄せません。誤統合は、他人の利用履歴や家族の情報が見えてしまう事故につながり、後から切り分けるのが難しいため、迷う場合は寄せない側に倒すことを原則にします（本記事の整理）。

誤統合が起きた場合の対応も、あらかじめ決めておきます。他人の情報が表示された場合は、個人情報の漏えい等として対応が必要になりうるため、発生時の連絡と報告の手順を、移行の前に所管部門と確認します。解除の手順は「戻し方」で扱います。

決めること 3　紐付け時の再確認

旧アカウントを新しい住民 ID に結び付けるとき、本人確認をやり直すかどうかを決めます。旧アカウントは、メールアドレスとパスワードだけで登録されていることがあります。新しい住民 ID が、公的個人認証などで確かめられた本人に紐づくなら、「旧アカウントのパスワードを知っている人」を、新しい ID の本人と結び付けてよいのかが論点になります。

DS-511 は、本人確認の水準を、手続ごとに、なりすまされたときの影響度から決めるとしています。紐付けでも同じ発想を使えます。紐付けると、旧アカウントに入っている情報が、新しい ID から見えるようになるためです。たとえば、次のように考えます（本記事の想定）。

表は横にスクロールできます

注意したいのは、旧アカウントのパスワード再設定の仕組みです。DS-511 は、アカウントの回復手段を攻撃の起点とされないよう、採用している当人認証と同等以上の強度の手法を選ぶこととしています。旧システムの再設定が弱いままだと、そこから旧アカウントを乗っ取られ、新しい ID に結び付けられるおそれがあります。紐付けの受付期間中は、旧システム側の回復手段も点検します（本記事の整理）。本人確認の水準の決め方は、「行政手続きの本人確認の水準」で整理しています。

決めること 4　本人確認が弱いアカウント

旧アカウントの多くは、登録時に本人確認書類を確認していません。氏名や生年月日は、利用者の自己申告のままです。こうした属性を新しい基盤へそのまま移すと、確認済みの属性と、未確認の属性が区別できなくなります。扱いの選択肢は、おおむね次の 3 つです（本記事の整理）。

• 属性は引き継がず、利用履歴と連絡先だけを移す — 氏名・生年月日・住所は、新しい ID で確認したものを正とします。食い違いの扱いが単純になります
• 引き継ぐが、「未確認」の印を付ける — 属性ごとに、確認済みか自己申告かを持たせます。新しい ID で確認できた時点で、印を外します
• 移さず、新規に登録してもらう — 旧アカウントの内容が、利用の継続に必要でない場合に選べます

どの方法でも、移行したアカウントが、確認済みの ID と同じ水準の手続に使えるようになってはいけません。高い水準が求められる手続には、新しい ID の本人確認の水準で判断し、旧アカウントから引き継いだ属性だけを根拠にしないようにします。また、新しい ID の確認済みの属性と、旧アカウントの属性が食い違う場合に、どちらを正とするか、住民へどう知らせるかも、あらかじめ決めておきます。

決めること 5　住民への通知と同意

統合は、住民が気づかないまま進めてよい作業ではありません。通知する内容は、少なくとも次の点を含めます（本記事の整理）。

• 統合の目的と、統合されるサービス
• いつ、何が変わるか（旧ログインが使えなくなる日、新しい ID でのログイン方法）
• 旧サービスの情報が、どう引き継がれるか。引き継がれないものは何か
• 統合を望まない場合や、退会したい場合の手続
• 問い合わせ先

通知の手段は、1 つに頼りません。メールは、登録アドレスが古い住民には届きません。広報や掲示、窓口での案内を組み合わせ、届かなかった人への対応も決めておきます。

同意については、整理が必要です。個人情報保護委員会の Q&A（行政機関等編）は、民間事業者の規律では第三者提供に原則として本人の同意が求められるのに対し、行政機関等が利用目的のために保有個人情報を利用・提供する場合は、本人の同意を得ることは求められていない、としています（令和7年12月追加の記載）。つまり、統合のために同意を取るかどうかは、法律上の要否と、住民への説明や信頼の観点から、分けて考える必要があります。利用目的を変更する場合の周知の要否と方法は、所管部門に確認してください。同意と再同意の設計は、「自治体の住民向けサービスの同意管理」で整理しています。

決めること 6　切り替えの日程と並行期間

切り替えの進め方には、いくつかの型があります。次の表は、本記事による整理です。

表は横にスクロールできます

どの型でも、決めておくことは共通です。旧ログインの受付を終える日、その日までの通知の回数と時期、並行期間中に旧システムへ入った変更（住所の更新や退会）を新しい基盤へ反映する方法、窓口での対応（旧システムの利用者番号で問い合わせを受けたときの照会）です。窓口の照会に備え、旧システムの利用者番号は新しい基盤にも残しておくと便利です。総務省のガイドライン（令和8年3月版）は、導入に際して、移行の際に情報システムに記録されている情報資産の保存を確実に行い、移行に伴う停止などの影響が最小限になるよう配慮すること、運用環境への移行の前に、業務に精通した利用部門の協力を得て擬似環境でテストを行うことを挙げています。

決めること 7　休眠アカウントと退会

旧サービスには、長く使われていないアカウント、退会済みの利用者のデータ、亡くなった方のアカウントが残っていることがあります。これらを新しい基盤へ持ち込むかどうかは、利用目的と保有の必要性の問題です。ガイドラインは、特定した利用目的の達成に必要な範囲を超えて個人情報を保有してはならないとしています。持ち込む場合は、その必要性を説明できるようにしておきます（本記事の整理）。

表は横にスクロールできます

DS-511 は、プライバシーの観点で、収集する情報の最小化と、必要のなくなったデータの破棄を、対策の例に挙げています。統合を機に、持たなくてよい情報を持ち越さないことが、結果として安全管理の負担を減らします。

決めること 8　データの整備

名寄せの前に、データを整えます。整える内容の例を挙げます（本記事の整理）。

• 文字の揺れ — 全角と半角、空白、旧字体と新字体、異体字、外字。DS-511 は、文字コードや異体字・外字の取扱いを、一意な識別を妨げる要素として挙げています
• 書式の揺れ — 電話番号のハイフン、郵便番号、住所の丁目・番地の表記、メールアドレスの大文字と小文字
• 誤りと欠け — 入力ミス、必須項目の空欄、生年月日の誤り
• 重複 — 同じサービスの中で、同じ人が複数のアカウントを持っている場合

整備の方針として、元の値は残し、整えた値を別に持つことをお勧めします。整える処理が誤っていた場合に、元に戻せるためです。また、ガイドラインは、行政機関の長等が、利用目的の達成に必要な範囲内で、保有個人情報が過去又は現在の事実と合致するよう努めなければならない、としています。どこまで正確にするかは、利用目的によって、過去の一定時点の事実で足りるか、現在の事実が必要かが変わります。

データを最新にするために、他の部署や他のサービスの情報で補いたくなることがありますが、それは「機関が分かれていないか」で触れたとおり、提供や目的外利用の問題になりうるため、整備の作業に含めるときは、先に所管部門と確認します。

決めること 9　戻し方

戻し方には、2 つの水準があります。1 つは、誤統合した個別のアカウントを元に戻すこと。もう 1 つは、移行全体がうまくいかなかったときに、旧システムへ戻すことです。

総務省のガイドライン（令和8年3月版）の解説は、システムを更新・統合するときに検証しておく事項として、想定外の事象に対応する体制、システムやデータの移行が失敗した場合や、移行直後に障害が生じた場合に旧システムへ戻す計画とその手順、更新・統合で影響を受ける業務運営体制、移行の検証チェックポイントや移行の妥当性基準の明確化、を例に挙げています。

• 個別の解除 — 誤統合が分かったとき、紐付けを解除し、元の旧アカウントの状態に戻せるようにします。そのためには、統合の前の状態と、統合で何を書き換えたかを記録しておく必要があります
• 全体の切り戻し — どの状態になったら戻すかの基準（たとえば、誤統合の疑いの件数、ログインできない住民の割合）を、移行の前に決めます。数値は、規模に応じて自治体が決めます
• 旧データを残す期間 — 戻せるようにするには、旧データを一定期間、読み取り専用などの形で残す必要があります。一方、同じガイドラインは、移行完了後に移行元のデータを抹消する必要があるとしています。「戻せる期間」と「抹消の時期」を、あらかじめ両立する形で決めます。旧データをいつまで保有するかは、ファイル簿の更新にも関わります

決めること 10　記録と監査

統合の作業は、後から検証できるようにしておきます。記録する内容の例です（本記事の整理）。

• 旧アカウントと新しい ID の対応表 — どの旧アカウントが、どの ID に結び付いたか
• 結び付けた根拠 — どのルールで一致と判定したか（自動か、職員の確認か、本人の操作か）、いつ、誰が
• 例外の処理 — 候補として保留した件、寄せなかった件、住民から訂正の申し出があった件
• データを整えた履歴 — 元の値と、整えた値
• 委託先の作業記録 — 作業の範囲、複製したデータの管理、終了時の消去の確認

対応表そのものも個人情報ですから、閲覧できる職員と事業者を最小限にし、保存期間を決めます。DS-511 は、各プロセスの検討結果を文書化して管理するよう求めています。また、事務対応ガイドの別添指針では、委託先の作業管理体制や個人情報の管理の状況を、少なくとも年 1 回以上、原則として実地検査で確認することが示されています。統合後は、対応表を使った抜き取りの確認や、住民からの苦情の傾向の確認を行い、ルールの見直しにつなげます。

RinX の場合

当社の自治体向け統合 ID 基盤 RinX（リンクス）が、サービスページで公開している内容のうち、本記事の観点に関わるものは次のとおりです。

• 既存の利用者データの取り込み — 職員向けの管理画面の機能として「既存の利用者データの一括取り込み」があり、これまでの利用者情報を引き継げます
• 導入の流れ — 導入の流れの中に「試験・データ移行」の段階があり、職員による受入試験、本番環境での動作確認、既存利用者データの移行を行います
• 利用者の管理 — 管理画面で、利用者の照会・訂正・CSV 出力ができます
• 本人確認の手段 — マイナンバーカードによる本人確認（公的個人認証）、LINE、メールアドレスのログインに対応しています。利用する手段は、自治体ごとにご相談のうえ決定します
• 同意・家族・ID 連携 — 同意文書の管理（改定時の再同意の取得）、お子さまのアカウントの紐付け、OpenID Connect によるシングルサインオンに対応しています
• 住民の利用環境 — マイページは Web ブラウザで利用でき、RinX 専用のアプリは不要です

名寄せの判定方法や取り込むデータの形式など、移行の個別の要件は、本記事の 10 の観点に沿って、お問い合わせの際にご相談ください。RinX に関する記事は、RinX の記事一覧にまとめています。

まとめ

1. 住民 ID の統合は、ログインの共通化、アカウントの統合、データの移行が混ざった作業。何をするのかを分けて考える
2. 名寄せは、鍵の弱点を踏まえ、「一致が確実」「候補」「一致しない」に分けて扱う。誤統合は戻しにくいため、迷うときは寄せない
3. 旧アカウントを結び付けるときは、旧アカウントにある情報の重さに応じて、本人確認をやり直すかを決める。確認が弱い属性は、確認済みの属性と区別する
4. 利用目的、機関ごとの提供、委託、ファイル簿は、移す前に所管部門と確認する。同意の要否と、住民への説明は分けて考える
5. 切り替えの日程、休眠・退会の扱い、データの整備、戻し方、記録は、移行の前に決めておく。戻せる期間と、旧データの抹消時期は、両立する形で決める

RinX の機能・導入の流れ・費用の考え方は、サービスページで確認できます。

サービスを見る

よくある質問

Q1. 住民 ID の統合とは何ですか？

サービスごとに別々の利用者番号やアカウントを持っている状態から、住民 1 人につき 1 つの共通の ID に切り替え、既存の利用者データを新しい基盤へ移す取り組みです（本記事での定義）。ログインの共通化だけを指す場合と、データの移行まで含む場合があるため、計画の段階で、何をするのかを分けて確認します。

Q2. 名寄せは、自動処理だけで行ってよいですか？

どこまでを自動にするかは、自治体が決めることです。DS-511 は、重複登録と別人との誤紐づけを脅威として挙げ、表記ゆれや改姓、住所変更などを考慮するよう求めています。複数の項目が一致して同一人物と説明できるものだけを機械的に処理し、一部だけ一致する候補は、職員または本人の確認を挟む設計が考えられます。

Q3. 統合に、住民の同意は必要ですか？

個人情報保護委員会の Q&A（行政機関等編）は、行政機関等が利用目的のために保有個人情報を利用・提供する場合は、本人の同意を得ることは求められていない、としています。一方、利用目的以外の目的での利用・提供を恒常的に行う場合は、利用目的として特定するか、利用目的を変更する必要があるとされています。統合が利用目的の範囲に収まるか、周知をどうするかは、所管部門に確認してください。同意を取るかどうかは、法律上の要否とは別に、住民への説明の観点でも検討します。

Q4. 旧アカウントの ID やパスワードを忘れた住民は、どうなりますか？

新しい住民 ID を先に作り、旧アカウントとの紐付けは後から行えるようにする方法があります。ただし、窓口やメールで旧アカウントを回復する手段が弱いと、そこが攻撃の起点になります。DS-511 は、アカウントの回復手段を、採用している当人認証と同等以上の強度にするよう求めています。紐付けの受付方法とあわせて、回復の方法も決めておきます。

Q5. 休眠アカウントは、削除してよいですか？

何年使われていなければ休眠とするかを定めた公的な基準は、確認できた範囲ではありませんでした。自治体で基準を決め、対象者への通知の方法とあわせて整理します。ガイドラインは、利用目的の達成に必要な範囲を超えて保有しないことを求めていますが、法令や文書管理の規程で保存期間が決まっているデータは、別に確認する必要があります。

Q6. 誤統合が分かったときは、どうすればよいですか？

紐付けを解除し、元の旧アカウントの状態に戻します。そのために、統合前の状態と、書き換えた内容の記録が必要です。他人の情報が表示されていた場合は、個人情報の漏えい等として対応が必要になりうるため、連絡と報告の手順を、移行の前に所管部門と確認しておきます。

Q7. RinX では、既存の利用者データを取り込めますか？

はい。職員向けの管理画面の機能として「既存の利用者データの一括取り込み」があり、導入の流れの「試験・データ移行」の段階で、既存利用者データの移行を行います。名寄せの判定方法や取り込むデータの形式などは、お問い合わせの際にご相談ください。

出典・参考資料

いずれも2026年10月30日に内容を確認しています。

1. 個人情報保護委員会『個人情報の保護に関する法律についてのガイドライン（行政機関等編）』（令和4年1月、令和8年10月一部改正）ppc.go.jp
2. 個人情報保護委員会事務局『個人情報の保護に関する法律についての事務対応ガイド（行政機関等向け）』（令和4年2月、令和8年10月一部改正）ppc.go.jp
3. 個人情報保護委員会事務局『個人情報の保護に関する法律についてのＱ＆Ａ（行政機関等編）』（令和4年2月、令和8年4月更新）ppc.go.jp
4. 個人情報保護委員会『法令･ガイドライン等』（上記 3 資料の掲載ページ）ppc.go.jp
5. 総務省『地方公共団体における情報セキュリティポリシーに関するガイドライン』（令和8年3月版、令和8年3月27日改定）soumu.go.jp
6. 総務省『自治体のサイバーセキュリティ対策』（上記ガイドラインの掲載ページ）soumu.go.jp
7. デジタル社会推進標準ガイドライン DS-511『行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン』（2025年9月30日、デジタル社会推進会議幹事会決定）digital.go.jp
8. デジタル社会推進実践ガイドブック DS-512『行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン 解説書』（2026年2月24日、デジタル庁）digital.go.jp

関連記事

自治体 · 本人確認 · 保証レベル行政手続きの本人確認の水準｜デジタル庁のガイドラインで決める「保証レベル」の 6 つの手順2026年10月30日自治体 · 同意管理 · 利用規約自治体の住民向けサービスの同意管理｜規約の同意・再同意・記録で決める 7 つのこと2026年10月30日自治体 · ID連携 · OpenID Connect自治体の OpenID Connect による SSO 入門｜住民向けの ID 連携で確認する 8 つの観点2026年10月29日関連サービスRinX（リンクス）｜マイナンバーカードで本人確認できる自治体向け統合 ID 基盤サービスを見る →

関連サービス

RinX（リンクス）

本人確認・マイページ・外部連携をひとつの基盤で提供する、自治体向けの統合 ID 基盤です。

サービスを見る