自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

一般財団法人全国地域情報化推進協会

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

目 次

本書の位置づけ ................................................................................................................................................................................ 1
1「団体内統合宛名システム」の概要 .................................................................................................................................. 2
1.1「団体内統合宛名システム」整備の目的 .................................................................................................... 2

1.2「団体内統合宛名システム」と「団体内統合利用番号連携サーバー」 ..................................................... 2

1.3「団体内統合宛名システム」に係る用語 .................................................................................................... 2

2

地域情報プラットフォームにおける「団体内統合宛名システム」の定義 ............................................................... 4
2.1「団体内統合宛名システム」の要件の整理 ................................................................................................ 4

2.1.1「団体内統合宛名システム」の機能 .......................................................................................... 4

2.1.2「団体内統合宛名システム」が保有する情報 ............................................................................ 7

2.1.3「団体内統合宛名番号」と「識別番号」 ...................................................................................... 7

2.1.4

業務ユニット以外の業務システムにおける団体内統合宛名番号 ............................................... 8

2.1.5

地方公共団体内の異なる機関への対応 .................................................................................. 8
団体内統合宛名システム」の整備に向けた考え方 ............................................................................... 8

2.2
2.2.1

機能の重複と新たに構築する範囲 ........................................................................................... 82.2.2

システムの構築方法 ................................................................................................................ 9

2.3「団体内統合宛名機能」の定義 ................................................................................................................ 10

2.4

実現方法 ................................................................................................................................................ 12

2.4.1

統合 DB 機能を活用して構築する方式 ................................................................................... 12

2.4.2

専用の統合宛名機能を構築する方式 .................................................................................... 13

2.4.3

中間サーバーとのインタフェース ............................................................................................ 13

3「団体内統合宛名機能」と外部環境の情報連携 ........................................................................................................ 14
3.1

本書における検討範囲 ......................................................................................................................... 143.2

住民基本台帳ユニットおよび住登外管理ユニットとの連携 ................................................................ 18

3.2.1

構築パターンによる違いと本書で検討する範囲 ...................................................................... 18

3.2.2

データ項目 （構築パターンの全ての場合） ............................................................................. 18

3.2.3

通信仕様 （別途構築（全部機能）型の場合） .......................................................................... 20

3.3

業務ユニットとの連携 ............................................................................................................................ 20

3.3.1

構築パターンによる違いと本書で検討する範囲 ...................................................................... 20

3.3.2

データ項目 （追加構築（全部機能）型および別途構築（全部機能）型の場合） ......................... 23

3.3.3

通信仕様 （追加構築（全部機能）型および別途構築（全部機能）型の場合） ............................ 23＜参考資料＞ 番号制度団体内統合宛名システム導入方針 V1.0 ............................................................................. 25
本書の位置づけ ................................................................................................................................................................................ 1
１．団体内統合宛名システム ......................................................................................................................................................... 2
２．「団体内統合宛名システム」の導入に対する地域情報プラットフォーム活用方針................................................. 5
２．１．地域情報プラットフォーム標準仕様の活用点 .......................................................................................... 5
２．２．実現方法例 ................................................................................................................................................ 8

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン
２．３．自治体内における現状の宛名管理の類型化 ........................................................................................ 10
２．４．類型化パターンに対する活用方針の適用 ............................................................................................. 17
２．５．団体内統合利用番号連携サーバーの活用 ........................................................................................... 20
３．【参考】 今後の中間サーバーインタフェース等への展開 ........................................................................................... 21

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

本書の位置づけ

社会保障・税に関わる番号制度（以下「番号制度」という）については、平成 25 年 5 月 24 日に「行政手続きにおける特定の個人を識別するための番号の利用等に関する法律」および関係法律が成立したところである。
番号制度では地方公共団体等の行政機関間の団体間データ連携を「情報提供ネットワークシステ
ム」を介して実施する。この実現に際して、地方公共団体の各種業務システムは情報提供ネットワー
クシステムに直接接続するのではなく、「中間サーバー」を設け、これを介して接続することとされている。また、この「中間サーバー」のソフトウェアは国による一括開発が行われている。
中間サーバーとの接続にあたっては、平成２５年８月に公開された「地方公共団体における番号制
度の導入ガイドライン」（総務省）等にて、「団体内統合宛名システム」を整備し、地方公共団体内に保有する個人データを一意に識別する「団体内統合宛名番号」を用いて行うことが示されている。
具体的には、各種業務システムと中間サーバーとの連携のキーとして、また、符号取得要求時に中間サーバーに対して提供する情報の一つとして利用される。
地域情報プラットフォーム標準仕様では、26 の業務ユニットが定義されているが、「団体内統合宛名システム」に相当するものは現状定義されておらず、番号制度における情報連携を確実に行う仕組みとするためには、地域情報プラットフォームにおける「団体内統合宛名システム」の定義、関連する業務ユニットとの接続について示す必要がある。
本書では、これまでの地域情報プラットフォームの方針と「地方公共団体における番号制度の導入
ガイドライン」での「団体内統合宛名システム」の考え方、機能等を検討・整理し、「団体内統合宛名機能」を定義した。「団体内統合宛名システム」の整備にあたって、本書に示した要件を充たすことにより、地域情報プラットフォームとして、番号制度における情報連携を確実に行う仕組みとすることができる。
検討にあたっては、以下の資料を参照した。
・「地方公共団体における番号制度の導入ガイドライン」（平成 25 年 8 月）
以下、「番号制度導入ガイドライン」とする。
・「「地方公共団体における情報連携プラットフォームに係る中間サーバー・ソフトウェアの設計・開発作業の請負」 システム方式設計書第 1.1 版」（平成 26 年 11 月）
以下、「中間サーバー・システム方式設計書」とする。
・「「地方公共団体における情報連携プラットフォームに係る中間サーバー・ソフトウェアの設計・開発作業の請負」 外部インターフェイス仕様書第 0.6 版」（平成 26 年 12 月）
以下、「中間サーバー・外部インターフェイス仕様書」とする。

－ 1 －自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

1「団体内統合宛名システム」の概要
本章では、「団体内統合宛名システム」の概要について示す。

1.1「団体内統合宛名システム」整備の目的「番号制度導入ガイドライン」に記載されているとおり、地方公共団体において宛名情報（個人に紐づく宛名や住所、所在地等）を適切に管理することは、行政事務の実施や住民サービスの提供の上で重要である。しかし、地方公共団体における宛名情報管理は、全業務横断的に統一管理されているケース、一部業務横断的に統一管理されているケース、各業務システムにおいて個別に管理されているケースなど、様々である。
「番号制度導入ガイドライン」ではこの状況を整理し、「団体内統合宛名システム」および「団体内統合宛名番号等」を用いた仕組みの整備を求めている。
「団体内統合宛名システム」とは、各地方公共団体における複数の業務システムを統合した形で宛名を管理するためのシステムの呼称である。システムにおける宛名管理に係る結合状況については、
前述の通り、各地方公共団体により様々である。
番号制度の導入後、情報連携を行うため、中間サーバーにおいて、各地方公共団体の保有する個人情報と、「符号」（情報提供ネットワークシステムにおける情報連携において、個人の特定のために用いられる「見えない番号」）を紐付けて管理することになる。この符号について、該当する個人を特定することが必要となるが、中間サーバーでは個人番号は保有しない。このため、中間サーバーでは、
各地方公共団体において特定の個人を一意に識別する番号、すなわち団体内統合宛名番号等と符号を紐付けて管理することとしており、各種事務において情報連携を行うためには、別途個人番号と団体内統合宛名番号等の紐付けを管理するシステムが必要になり、各地方公共団体は「団体内統合宛名システム」の整備を求められているところである。

1.2「団体内統合宛名システム」と「団体内統合利用番号連携サーバー」

番号制度における情報連携においては、基本的に団体内統合宛名番号等と個人番号の紐付け管理ができれば、中間サーバーを介した情報提供ネットワークシステムとの連携は可能である。そのため、少なくとも団体内統合宛名番号等（団体内統合利用番号）と個人番号の紐付け管理を行う「団体内統合利用番号連携サーバー」の整備が必要であるが、「番号制度導入ガイドライン」では、宛名情報の統一的管理による情報システム改革・業務改革推進、住民サービス向上のために、「団体内統合宛名システム」の整備が推奨されている。
したがって、番号制度対応に向けた「団体内統合宛名システム」等の整備においては、宛名管理に係る結合状況、システムの実態、団体におけるニーズ、費用対効果等を踏まえながら整備方針を決定する必要があるが、将来的には「団体内統合宛名システム」を実現することが望ましい。

1.3「団体内統合宛名システム」に係る用語表 1-1 に、「団体内統合宛名システム」の整備を検討にするにあたって前提となる用語を整理する。

－ 2 －自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

表１－１ 「団体内統合宛名システム」に係る用語
用語

説明

番号制度

「社会保障・税に関わる番号制度」の略称。

番号法

行政手続における特定の個人を識別するための番号の利用等に関する法
律（平成 25 年法律第 27 号）をいう。
※本書で、特に明示しない条文番号は、本用語定義の出典元と同じく、番号法の条文番号とする

団体内統合宛名シス

地方公共団体で業務横断的に宛名、住所、所在地等の情報の保持・管理テムを行う宛名管理システムを指す。

団体内統合宛名番

地方公共団体において、「団体内統合宛名システム」で、個人又は法人（事号業所等）を識別するために付番されている番号を指す。「団体内統合宛名番
号」は地方公共団体に閉じて用いられる固有の番号である。

宛名管理システム

地方公共団体で業務上必要となる宛名、住所、所在地等の情報の保持・管理を行うシステムを指す。

個人番号

番号法に基づき個人に付番される「個人番号」を指す（第 2 条第 5 項）。

符号

情報提供ネットワークシステム等及び情報保有機関において情報提供で用いる個人の識別子を指す。

情報提供ネットワー

特定個人情報の提供について管理するための電子情報処理組織で総務大クシステム

臣が設置、管理するものを指す（第 2 条第 14 項）。

特定個人情報個人番号をその内容に含む個人情報を指す（第 2 条第 8 項）。

－ 3 －自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

2

地域情報プラットフォームにおける「団体内統合宛名システム」の定義
本章では、「団体内統合宛名システム」の要件、整備に向けた考え方を整理し、地域情報プラットフ
ォームにおける「団体内統合宛名システム」を定義する。

2.1「団体内統合宛名システム」の要件の整理

地域情報プラットフォームにおける「団体内統合宛名システム」を定義するにあたり、「団体内統合
宛名システム」の要件について整理する。
なお、整理にあたっては、「番号制度導入ガイドライン」「中間サーバー・システム方式設計書」「中間サーバー・外部インターフェイス仕様書」を参照した。

2.1.1 「団体内統合宛名システム」の機能「団体内統合宛名システム」の機能としては、大きく４つに分類されると考えられる。
① 団体内統合宛名管理に関する機能
団体内統合宛名番号の付番、個人番号、基本４情報等宛名情報との紐付けおよび管理② 符号取得に関する機能
中間サーバーに対する、団体内統合宛名番号と個人番号の通知③ 中間サーバーとの連携に関する機能
中間サーバーへの団体内統合宛名番号の通知、登録済み団体内統合宛名番号に対する変更・削除、個人番号および基本４情報の提供④ 既存システムとの連携に関する機能
既存システムに対する宛名情報等の通知
上記の分類を踏まえ、「団体内統合宛名システム」が実装する機能を表 2-1 に示す。
また、機能の関係（概念図）を図 2-1 に示す。
なお、番号法別表第二に関連する業務ユニットと中間サーバーの情報連携（特定個人情報の登録・照会）については、本書では、各業務ユニットが直接中間サーバーと連携するものとする。

－ 4 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

表 2-1 「団体内統合宛名システム」の機能
機能分類

機能名

機能説明
「団体内統合宛名番号」が未登録の個人につい団体内統合宛名番号付①

団体内統合宛名管番機能て、新規に「団体内統合宛名番号」を付番する機能。既存業務システムからの「団体内統合宛名
番号」の要求に対し、「団体内統合宛名番号」を付番する機能。

理に関する機能「団体内統合宛名システム」において基本４情報
宛名情報等管理機能

を「団体内統合宛名番号」、個人番号と紐付けて保存し、管理する機能。

②

符号取得に関する機能

団体内統合宛名番号、個人番号を中間サーバー

符号取得要求機能に通知し、符号取得要求を行う機能。

符号取得状態確認機能③④

連携に関する機能

既存システムとの連携に関する機能する機能。

団体内統合宛名番号通

中間サーバーに対して、団体内統合宛名番号を知機能通知する機能。

団体内統合宛名情報提中間サーバーとの中間サーバーから符号取得状態を取得し、確認供機能

中間サーバーからの要求に基づき、「団体内統合宛名番号」に紐づく個人番号・基本４情報を通知する機能。※１

団体内統合宛名番号変

中間サーバーに登録済みの団体内統合宛名番

更機能号について、変更要求を行う機能。

団体内統合宛名番号削

中間サーバーに登録済みの団体内統合宛名番

除機能号について、削除要求を行う機能。
既存業務システムからの要求に基づき、個人番

既存システム連携機能

号又は「団体内統合宛名番号」に紐づく宛名情報を通知する機能。

※１：「中間サーバー・システム方式設計書」の業務フローでは、中間サーバー接続端末を用いた基本４情報の確認は「地方公共団体の任意運用」とされているが、中間サーバー側は「団体内統合宛名情報取得機能」を有しているため、本ガイドラインでは必須の機能とする。

－ 5 －自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

中間サーバー

団体内統合宛名システム
機能分類②「符号取得に関する機能」

機能分類③「中間サーバーとの連携に関する機能」

機能分類①「団体内統合宛名管理に関する機能」

機能分類④「既存システムとの連携に関する機能」

既存業務システム

図 2-1 「団体内統合宛名システム」の機能の関係 概念図－ 6 －

既存業務システム

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

2.1.2 「団体内統合宛名システム」が保有する情報「団体内統合宛名システム」が保有する情報を表 2-2 に示す。
なお、表 2-2 に任意と示された項目（連絡先情報、送付先情報など）については、地方公共団体がそれぞれ運用しやすいように工夫して設計しており、独自の要素が大きい。そこで、本書では、表 2-2のうち、「必須」とされた情報を対象として、以降の説明をする。
表 2-2 「団体内統合宛名システム」が保有する情報
項番

情報名

主な内容

1

団体内統合宛名番号

地方公共団体において、「団体内統合宛名

必須・任意の区分
必須システム」で、個人又は法人（事業所等）を識別するために付番されている番号を指す。「団体内統合宛名番号」は地方公共団
体に閉じて用いられる固有の番号である。
2

個人番号

番号法に基づき個人に付番される「個人番必須号」を指す（第 2 条第 5 項）。
3

基本４情報

氏名、住所、生年月日、性別

必須

4

連絡先情報

個人の電話番号等の連絡先情報

任意

5

送付先情報

個人への郵送物の届け先情報

任意

6

口座情報

還付口座や納付口座情報

任意

7

特記事項

個人に対する特記事項、注意事項など

任意

8

法人情報

任意

2.1.3 「団体内統合宛名番号」と「識別番号」
地域情報プラットフォーム標準仕様を活用した「団体内統合宛名システム」を検討する場合、団体内にて個人を一意に識別する「団体内統合宛名番号」は、自治体業務アプリケーションユニット標準
仕様に定義される「識別番号」を活用することが考えられる。
これについては、平成２５年度に APPLIC にて取りまとめた「番号制度団体内統合宛名システム導入方針 V1.0」（以下、「導入方針」とする）にて、現状の宛名番号や識別番号の整備状況を類型化し、識別番号の活用可能性について整理したところであるが、地域情報プラットフォーム標準仕様の思想としては、できるだけ広い範囲の業務で識別番号を採用し、業務間の円滑な連携を図ることであり、庁内で広く採用された識別番号を団体内統合宛名番号として採用することが望ましい。
また、「導入方針」では地域情報プラットフォーム活用の留意点として、団体内統合宛名番号の桁数が未定であることを挙げているが、現在は「中間サーバー・外部インターフェイス仕様書」にて団体
内統合宛名番号は「文字列 15 桁」とされており、識別番号の桁数（文字列 15 桁）とも一致する。
上記を踏まえ、団体内統合宛名番号に識別番号を活用することを前提とする。
なお、今後、「中間サーバー・外部インターフェイス仕様書」の改版等により、団体内統合宛名番号の桁数に変更があった場合には、識別番号の活用について再度検討する。

－ 7 －自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

2.1.4 業務ユニット以外の業務システムにおける団体内統合宛名番号「2.1.3 「団体内統合宛名番号」と「識別番号」」にて述べたように、「識別番号」を「団体内統合宛名番号」として活用することを前提とする一方、業務ユニット以外の業務システムについては、個人を一意に特定するキーとなる情報の定義が、「識別番号」と必ずしも一致しない可能性がある。
「番号制度導入ガイドライン」では、「番号制度の趣旨及び地方公共団体の業務改革の重要性に鑑みると、制度導入に当たって、宛名情報の統一的な管理の推進が望ましい」とされており、団体内統合宛名番号による統一管理を、地域情報プラットフォームの考え方を導入して実現するには、業務ユニット以外の業務システムについても、「識別番号」と同様に定義されたキーに統一されることが望ましいと考えられる。
しかしながら、業務ユニット以外の業務システムへの影響を鑑みると、システム更改時などのタイミ
ングで「識別番号」へのキーの統一化を検討するなど段階的に進めるとともに、コスト面や業務運用への影響などを考慮しながら、慎重に検討する必要がある。
当面の対応としては、例えば、「番号制度導入ガイドライン」にて示された「団体内統合利用番号連
携サーバー」相当の機能を別途構築し、「識別番号」と、各業務システム固有の番号との紐付けを行い、業務ユニットやそれ以外の業務システムが保有する宛名情報の統一的管理を行う方法など、いく
つかの方法が考えられる。

2.1.5 地方公共団体内の異なる機関への対応
番号法別表第二に定められる情報照会者・情報提供者が情報保有機関とされるため、地方公共団体では、首長部局と教育委員会は別の情報保有機関となる。
「団体内統合宛名システム」は符号取得要求等に中間サーバーとのデータ連携を行うが、符号は情報保有機関単位で取得することから、それぞれの機関への対応が求められる。機関ごとに「団体内統合宛名システム」を整備する方法が考えられるが、両機関の対応を一つの「団体内統合宛名システム」で行うことも可能とされている。
本書では、これを踏まえた「団体内統合宛名システム」整備を行う場合にも対応できるように、一つの「団体内統合宛名システム」によって両機関の対応を行うことを想定とする。具体的には、表 2-1 に示した機能分類②「符号取得に関する機能」は、機関別に符号取得要求および取得状況管理を行う
ことが求められる。

2.2

団体内統合宛名システム」の整備に向けた考え方「団体内統合宛名システム」の整備方法は、地方公共団体のシステム整備状況に応じて様々な方法が想定される。本節では、地域情報プラットフォームにおける「団体内統合宛名システム」の整備に向けた考え方について示す。

2.2.1 機能の重複と新たに構築する範囲
地域情報プラットフォーム標準仕様では、住民基本台帳ユニットおよび住登外管理ユニットが人の基本的な情報の管理を担い、両業務ユニットは個人番号や基本４情報を管理する。また、識別番号を付番する。
そのため、本書「2.1.3 「団体内統合宛名番号」と「識別番号」」にて述べたように団体内統合宛名－ 8 －自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

番号に識別番号を活用する場合、表 2-1 に示した機能分類①「団体内統合宛名管理に関する機能」
については、番号付番および宛名情報等管理において、現行の住民基本台帳ユニットおよび住登外
管理ユニットとの機能の重複が生じることになる。
また、機能分類④「既存システムとの連携に関する機能」については、番号制度に関連する業務ユニットは「住基情報」「住登外情報」として個人番号を保有しており、基本４情報は住民基本台帳ユニ
ットもしくは住登外管理ユニットとの連携を有していることから、当該機能についても重複が生じることになる。

団体内統合宛名システム

住民基本台帳
ユニット

住登外管理
ユニット

機能が重複
図 2-2 機能の重複 概念図
上記を踏まえ、「団体内統合宛名システム」の整備方法を考えると、次の三つの案が考えられる。
A スクラップ＆ビルド
B 現行の業務ユニットの機能を活用し、不足する機能のみを構築する
C 現行の業務ユニットとは別に、全ての機能を構築する「A スクラップ＆ビルド」方法は、現行の業務ユニットの構成を見直し、新たに一つの業務ユニットとして構築する方法を指す。この場合、現行の業務ユニットの構成に変更が生じるため、既に地域情報
プラットフォーム標準仕様に準拠したシステムを導入している地方公共団体への影響が非常に大きいと考える。そこで、本書では、「A スクラップ＆ビルド」以外の方法を対象とする。
「B 現行の業務ユニットの機能を活用し、不足する機能のみを構築する」方法は、機能分類①と④は住民基本台帳ユニットおよび住登外管理ユニットが担い、機能分類②と③のみを新たに構築する方法を指す。この場合、住民基本台帳ユニットおよび住登外管理ユニットと組み合せることで「団体内統合宛名システム」を構成するため、両業務ユニットとの結び付きが強くなる。
「C 現行の業務ユニットとは別に、全ての機能を構築する」方法は、現行の業務ユニットの構成はそのままに、「団体内統合宛名システム」の全ての機能（機能分類①②③④）を新たに構築する方法を指す。この場合、「B 現行の業務ユニットの機能を活用し、不足する機能のみを構築する」方法に比べて住民基本台帳ユニットおよび住登外管理ユニットとの結び付きは弱いが、個人番号や基本４情報を管理する両業務ユニットから個人番号と基本４情報を取得する必要がある。

2.2.2 システムの構築方法
本書「2.2.1 機能の重複と新たに構築する範囲」を踏まえ、システムの構築方法について考える。
「B 現行の業務ユニットの機能を活用し、不足する機能のみを構築する」方法は、機能分類①と④を担う住民基本台帳ユニットおよび住登外管理ユニットとの結び付きが強いため、「不足する機能の－ 9 －自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

みを住民基本台帳ユニット・住登外管理ユニットの両方もしくは何れかを拡張して構築する」方法が考えられる。この場合、両業務ユニットの影響を強く受ける。
「C 現行の業務ユニットとは別に、全ての機能を構築する」方法は、現行の業務ユニットの構成はそのままにするため、「住民基本台帳ユニットおよび住登外管理ユニットとは別に独立して構築する」
方法が考えられる。この場合、システムの独立性が高く理想的な構築方法であるが、「住民基本台帳
ユニット・住登外管理ユニットの両方もしくは何れかを拡張して構築する」方法に比べてシステムの構成が大掛かりになることが懸念される。
また、システムの構築方法の観点から考えると、両者の中間的な方法、「全ての機能を構築するが、住民基本台帳ユニット・住登外管理ユニットの両方もしくは何れかを拡張して構築する」方法も考えら
れる。

2.3

「団体内統合宛名機能」の定義

本書「2.2 団体内統合宛名システム」の整備に向けた考え方」を踏まえ、地域情報プラットフォーム
における「団体内統合宛名システム」を定義する。
まず、本書「2.2 団体内統合宛名システム」の整備に向けた考え方」にて述べた、新たに構築する部分を「団体内統合宛名機能」と定義する。
なお、新たに構築する部分は地域情報プラットフォーム標準仕様で定める「業務ユニット」の要件を満たさないため、「機能」の位置付けとする。
次に、「団体内統合宛名機能」の形態として、次の三つの構築パターンを定義する。
・ 追加構築（一部機能）型
・ 追加構築（全部機能）型
・ 別途構築（全部機能）型
団体内統合宛名機能の構築パターンの特徴を表 2-3 に示す。
また、団体内統合宛名機能の構築パターンの概念図を図 2-3 に示す。

－ 10 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

表 2-3 団体内統合宛名機能の構築パターンと特徴
団体内統合宛名機能の構築パターン

追加構築（一部機能）型

追加構築（全部機能）型

別途構築（全部機能）型

機能分類① ： 団体内統合宛名管理に関する機能

備えない

備える

機能分類② ： 符号取得に関する機能

備える

備える

機能分類③ ： 中間サーバーとの連携に関する機能

備える

備える

機能分類④ ： 既存システムとの連携に関する機能

備えない

備える

備える機能
特徴

システムの構築方法

住民基本台帳ユニット・住登外管理ユニットの両方もしくは何れかを拡張して構築する

追加構築（一部機能）型：

追加構築（全部機能）型：

住民基本台帳ユニットおよび住登外管理ユニットとは別に独立して構築する

別途構築（全部機能）型：

団体内統合宛名システム

団体内統合宛名システム

団体内統合宛名システム

団体内統合宛名機能（ 機能分類②③）

団体内統合宛名機能（ 機能分類①②③④）

団体内統合宛名機能（ 機能分類①②③④）

住民基本台帳
ユニット

住登外管理
ユニット

住民基本台帳
ユニット

住登外管理
ユニット

図 2-3 団体内統合宛名機能の構築パターン 概念図－ 11 －

住民基本台帳
ユニット

住登外管理
ユニット

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

2.4

実現方法

「導入方針」では、地域情報プラットフォーム標準仕様のアーキテクチャ下では「団体内統合宛名システム」を実現するに際して住民・住登外者の情報を一元的に提供する機能を提供する必要があることから、次の二つの方式を提示した。
① 統合 DB 機能を活用して構築する方式② 専用の統合宛名機能を構築する方式
以下に、両方式について説明する。

2.4.1 統合 DB 機能を活用して構築する方式
統合 DB 機能を活用して団体内統合宛名システムの既存システム連携機能相当のインタフェースを実現する。この方式を「統合 DB 方式」と呼ぶこととする。
現状、統合 DB に住民基本台帳ユニット、住登外管理ユニットが対応している場合、「個人情報メッ
セージ」、「住登外情報メッセージ」に対応するインタフェースが実装されている。
統合 DB 方式では中間サーバーとの連携のためのインタフェースを機能強化し、追加対応することとなる。この際、「個人情報メッセージ」、「住登外情報メッセージ」に対応する機能部分を活用して効率的に実装することが考えられる。公開用 DB 方式の場合の例を下図に示す。

住民基本台帳

住登外管理

ユニット

ユニット

登録

住登外
管理表
専用表
住民基本
台帳表
統合 DB

中間サーバー連携機
能対応部分を強化

図 2-4 統合 DB 方式－ 12 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

2.4.2 専用の統合宛名機能を構築する方式
統合 DB 機能では統合 DB に登録される情報の原本はあくまで業務ユニットが保持することが原則である。そこで、上述の統合 DB 方式では「個人番号」は住民基本台帳ユニット、住登外管理ユニットにも保持されることとなる。
一方で、「個人番号」を「団体内統合宛名システム」に集約し、多くの業務で分散管理することのな
いようにすることも考えられる。
そこで、住登外管理ユニットに「個人番号」を保持せず、団体内統合宛名システムにのみ保持する方法が考えられる。この場合、構造は統合 DB 方式と同様になるが、業務ユニット側に情報を持たないことから従来の地域情報プラットフォーム標準仕様では統合 DB 機能とは言えない。そこで、この方式を統合 DB 方式と明示的に区別するため「統合宛名機能方式」と呼ぶこととする。

住民基本台帳

住登外管理

ユニット

ユニット

登録

登録

統合宛名
機能

統合宛名表
中間サーバーへ

図 2-5 統合宛名機能方式

なお、「統合宛名機能方式」の実装方法としては、表 2-3 の別途構築（全部機能）型のように住民基
本台帳ユニットおよび住登外管理ユニットとは別に独立して団体内統合宛名機能を構築する方法と、
住民基本台帳ユニット、住登外管理ユニット自体に団体内統合宛名機能を追加しアプリケーションとして一体化する方法の二つが想定されるが、後者は、住民基本台帳ユニットおよび住登外管理ユニ
ットのそれぞれに機能を実装する場合もある。

2.4.3 中間サーバーとのインタフェース「中間サーバー・システム方式設計書」によれば、中間サーバーとの通信は、地域情報プラットフォーム標準仕様に基づき、SOAP にて行うこととされている。したがって、「統合 DB 方式」「統合宛名機
能方式」のいずれの場合においても、中間サーバーとの接続にあたり、SOAP インタフェースの実装が求められる。また、「中間サーバー・システム方式設計書」にて、中間サーバーと「団体内統合宛名システム」との連携として、団体内統合宛名番号の登録・変更・削除・確認、符号取得要求、宛名情報（基本４情報）提供が示されているが、これらの電文仕様については中間サーバーが要求する仕様に従うものとする。
－ 13 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

3「団体内統合宛名機能」と外部環境の情報連携
本章では、「団体内統合宛名機能」と外部環境の情報連携について示す。

3.1

本書における検討範囲
番号制度における情報連携概要図を図 3-1～3-3 に示す。
本書におけるここまでの整理を踏まえ、本書における検討範囲は、図 3-1～3-3 の B-1、B-2 の部分とする。
なお、団体内統合宛名機能と中間サーバー間の連携（図 3-1～3-3 の A-1、A-8、B-2）については、「中間サーバー・システム方式設計書」「中間サーバー・外部インターフェイス仕様書」等で示されているため、中間サーバー側が要求する仕様に準じるものとする。

－ 14 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

住基ネット
全国サーバー

情報提供ネットワークシステム
A-6
A-7

C-4

A-2

C-3

C-2
中間サーバー

中間サーバー
A-3

B-2

符号情報

C-5

団体内統合宛名情報

団体内統合宛名システム

A-1

A-8
団体内統合宛名機能（ 機能分類②③）

A-5

B-1

住基ネット
ＣＳ

A-4

団体内統合宛名用
住基情報

B-1

団体内統合宛名用
住登外情報

住登外管理
ユニット

住民基本台帳ユニット
住基情報

特定個人情報C-1

業務ユニット（情報照会側）特定個人情報業務ユニット（情報提供側）住登外情報

地方公共団体Ａ

地方公共団体Ｂ

Ａ．符号取得の流れ

Ｂ．宛名情報提供の流れ

Ｃ．特定個人情報の登録・照会の流れ［凡例］： 番号制度における情報の流れ： 定義する範囲

機能分類① ： 団体内統合宛名管理に関する機能
機能分類② ： 符号取得に関する機能
機能分類③ ： 中間サーバーとの連携に関する機能
機能分類④ ： 既存システムとの連携に関する機能

図 3-1 情報連携概要図（追加構築（一部機能）型の場合）－ 15 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

住基ネット
全国サーバー

情報提供ネットワークシステム
A-6
A-7

C-4

A-2

C-3

C-2
中間サーバー

中間サーバー
A-3

B-2

符号情報

C-5

団体内統合宛名情報

団体内統合宛名システム

A-1

A-8

団体内統合
宛名情報

団体内統合宛名機能（ 機能分類①②③④）

A-5

B-1

住基ネット
ＣＳ

A-4

団体内統合宛名用
住基情報

B-3

B-1

団体内統合宛名用
住登外情報

住登外管理
ユニット

住民基本台帳
ユニット
住基情報

C-1

特定個人情報業務ユニット（情報照会側）特定個人情報業務ユニット（情報提供側）住登外情報

地方公共団体Ａ

地方公共団体Ｂ

Ａ．符号取得の流れ

Ｂ．宛名情報提供の流れ［凡例］： 番号制度における情報の流れ： 定義する範囲

機能分類① ： 団体内統合宛名管理に関する機能
機能分類② ： 符号取得に関する機能
機能分類③ ： 中間サーバーとの連携に関する機能
機能分類④ ： 既存システムとの連携に関する機能

図 3-2 情報連携概要図（追加構築（全部機能）型の場合）－ 16 －

Ｃ．特定個人情報の登録・照会の流れ自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

住基ネット
全国サーバー

情報提供ネットワークシステム
A-6
A-7

C-4

A-2

C-3

C-2
中間サーバー

中間サーバー
A-3

B-2

符号情報

C-5

団体内統合宛名情報

団体内統合宛名システム

A-1

A-8

団体内統合
宛名情報

団体内統合宛名機能（ 機能分類①②③④）

A-5

B-1

住基ネット
ＣＳ

A-4

団体内統合宛名用
住基情報

B-3

B-1

団体内統合宛名用
住登外情報

住登外管理
ユニット

住民基本台帳ユニット
住基情報

特定個人情報C-1

業務ユニット（情報照会側）特定個人情報業務ユニット（情報提供側）住登外情報

地方公共団体Ａ

地方公共団体Ｂ

Ａ．符号取得の流れ

Ｂ．宛名情報提供の流れ

Ｃ．特定個人情報の登録・照会の流れ［凡例］： 番号制度における情報の流れ： 定義する範囲

機能分類① ： 団体内統合宛名管理に関する機能
機能分類② ： 符号取得に関する機能
機能分類③ ： 中間サーバーとの連携に関する機能
機能分類④ ： 既存システムとの連携に関する機能

図 3-3 情報連携概要図（別途構築（全部機能）型の場合）－ 17 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

3.2

住民基本台帳ユニットおよび住登外管理ユニットとの連携

本節では、図 3-1～3-3 に示した B-1（住民基本台帳ユニットから団体内統合宛名機能への団体内
統合宛名用住基情報の連携および住登外管理ユニットから団体内統合宛名機能への団体内統合宛
名用住登外情報の連携）について示す。

3.2.1 構築パターンによる違いと本書で検討する範囲
団体内統合宛名機能の構築パターンにより住民基本台帳ユニットおよび住登外管理ユニットとの関係が異なるため、両業務ユニットとの連携に違いがある。
追加構築（一部機能）型および追加構築（全部機能）型の場合、団体内統合宛名機能は住民基本台帳ユニット・住登外管理ユニットの両方もしくは何れかを拡張して構築するため、両業務ユニットとの連携はいわゆるシステム間の連携ではなく、連携の方法は SOAP による通信や電子ファイルの交換などではないと考える。
そこで、本書では、追加構築（一部機能）型および追加構築（全部機能）型については、通信仕様は対象外とし、連携するデータ項目のみを対象とする。
別途構築（全部機能）型の場合、団体内統合宛名機能は住民基本台帳ユニットおよび住登外管理ユニットとは別に独立して構築するため、両業務ユニットとの連携はいわゆるシステム間の連携となる。
なお、地方公共団体のシステム整備状況に応じて様々な連携の方法が想定されるが、本書では、SOAP による通信を前提とする。

3.2.2 データ項目 （構築パターンの全ての場合）
住民基本台帳ユニットおよび住登外管理ユニットと団体内統合宛名機能との連携にあたり、必要となるデータ項目は次の通りである。表 3-1、3-2 に示すデータ項目は、「自治体業務アプリケーション
ユニット標準仕様」にて定義されており、これらを活用するものとする。
なお、識別番号を除く他項目については、中間サーバー側の外部インタフェース仕様と自治体業務
アプリケーションユニット標準仕様でデータ型、桁数、コードが一致していないため、中間サーバーとの連携に際して、団体内統合宛名機能においてデータ変換が必要となる。

－ 18 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

表 3-1 住民基本台帳ユニットから団体内統合宛名機能に連携するデータ項目（住民基本台帳ユニット インタフェース仕様より抜粋）
コード

No

情報名
CD

データ型

桁数

項目説明

コード名

団体内統合宛名用
住基情報
1

識別番号

X

15

自治体内で人を統一的に管理する番号。

2

個人番号

X

12

番号法に基づき個人に付番される「個人番号」
住民票の氏名（外国人住民の場合は氏名欄の記

3

氏名

氏名情報

載に準じた書式） ※資料「業務 1-1 標準仕様の読み方」を参照

4

性別

○

性別

X

1

住民票の性別5

生年月日

生年月日情報住民票の生年月日

6

現住所

住所情報

住民票の現住所

表 3-2 住登外管理ユニットから団体内統合宛名機能に連携するデータ項目（住登外管理ユニット インタフェース仕様より抜粋）
コード

No

情報名
CD

データ型

桁数

項目説明

コード名

団体内統合宛名用
住登外情報
1

識別番号

X

15

自治体内で人を統一的に管理する番号。

2

個人番号

X

12

番号法に基づき個人に付番される「個人番号」

3

氏名

4

性別

5

生年月日

生年月日情報住登外者の生年月日

6

現住所

住所情報

住登外者の現住所

氏名情報
○

性別

X

住登外者の氏名1－ 19 －

住登外者の性別自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

3.2.3 通信仕様 （別途構築（全部機能）型の場合）「中間サーバー・システム方式設計書」では、図 3-4 の通り、通信仕様が定められているが、これらは「地域情報プラットフォーム標準仕様 プラットフォーム通信標準仕様」（以下、ＰＦ通信標準仕様）にて定義されている通信プロトコルとほぼ一致する。中間サーバーと接続する団体内統合宛名機能
は中間サーバーの通信仕様に準じた通信プロトコルを実装する必要があるが、前述の通り、PF 通信
標準仕様に対応することとほぼ同義である。
したがって、団体内統合宛名機能と、住民基本台帳ユニットおよび住登外管理ユニットとの通信仕様は、ＰＦ通信標準仕様に準じるものとする。
通信仕様
メッセージ交換パターン
添付付きメッセージ（メッセージへの添付（SwA）型）
基本メッセージ（SOAP 1.1 and Basic Profile 1.0）
転送プロトコル（HTTP1.1）
通信セキュリティ（TLS1.1/1.2）
インターネットプロトコル（IPv4 or IPv6）※「中間サーバー・システム方式設計書」に基づき作成

図 3-4 中間サーバー・団体内統合宛名システム間の通信仕様
なお、別途構築（一部機能）型および別途構築（全部機能）型の場合は、この限りではない。
また、統合 DB 機能を用いて団体内統合宛名機能と業務ユニット間のデータ連携を行う場合は、
SQL の採用が考えられる。この場合、別途構築（一部機能）型および別途構築（全部機能）型と同様に扱うものとするが、「地域情報プラットフォームガイドライン」に示される通り、差し替え性を考慮すると、その連携は、ODBC、JDBC などの標準化されたものを採用し、SQL も DBMS に依存しない範囲で使用するべきである。

3.3

業務ユニットとの連携

本節では、図 3-2～3-3 に示した B-3（団体内統合宛名機能から業務ユニットへの団体内統合宛名
情報の連携）について示す。

3.3.1 構築パターンによる違いと本書で検討する範囲
団体内統合宛名機能の構築パターンにより団体内統合宛名機能が備える機能が異なるため、業
務ユニットとの連携が異なる。
追加構築（一部機能）型の場合、表 2-1 に示した機能分類④「既存システムとの連携に関する機能」
は住民基本台帳ユニットおよび住登外管理ユニットが担い、団体内統合宛名機能は業務ユニットと連携しない。
追加構築（全部機能）型および別途構築（全部機能）型の場合、機能分類④は団体内統合宛名機能が担い、団体内統合宛名機能は業務ユニットと連携する。
－ 20 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

そこで、本書では、追加構築（全部機能）型および別途構築（全部機能）型の場合を対象とする。
なお、追加構築（全部機能）型および別途構築（全部機能）型の場合、業務ユニットは団体内統合
宛名機能との連携と住民基本台帳ユニットおよび住登外管理ユニットとの連携の二つの連携を有するため、用途により使い分けることが考えられる。

－ 21 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

団体内統合宛名情報

識別番号
個人番号
基本４情報

団体内統合宛名機能

団体内統合宛名用
住基情報
識別番号
個人番号
基本４情報

住民基本台帳ユニット

団体内統合宛名用
住登外情報
識別番号
個人番号
基本４情報

住登外管理ユニット

業務ユニットＡ

住登外情報

識別番号
個人番号
基本４情報
住民種別
住民状態

住基情報

…

識別番号
個人番号
基本４情報
住民種別
住民状態

…

図 3-5 別途構築（全部機能）型における業務ユニットの連携－ 22 －

業務ユニットＢ

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

3.3.2 データ項目 （追加構築（全部機能）型および別途構築（全部機能）型の場合）
団体内統合宛名機能から業務ユニットに連携するデータ項目を表 3-3 に示す。
なお、連携するデータ項目は、団体内統合宛名機能が保有する宛名情報である。本書「2.2 「団体内統合宛名システム」の整備に向けた考え方」にて述べたように、本書では、「番号制度導入ガイドラ
イン」にて「必須」と示された項目とする。
また、個人番号については、利用範囲は制限されるため、データ毎に個人番号の利用が認められた業務ユニットに対してのみ連携する。
なお、追加構築（一部機能）型の場合、この限りではない。
表 3-3 団体内統合宛名機能から業務ユニットに連携するデータ項目
コード

No

情報名
CD

データ型

桁数

X

15

項目説明

コード名

団体内統合宛名情報1

識別番号

自治体内で人を統一的に管理する番号。
番号法に基づき個人に付番される「個人番号」。

2

個人番号

X

12

データ毎に個人番号の利用が認められた業務ユニットに対してのみ連携する。

3

氏名

氏名情報

4

性別

5

生年月日

生年月日情報対象者の生年月日

6

現住所

住所情報

対象者の現住所○

性別

X

対象者の氏名1

対象者の性別3.3.3 通信仕様 （追加構築（全部機能）型および別途構築（全部機能）型の場合）
次の二つの連携方法が考えられる。
A 通知型（プッシュ型）
B 問合せ応答型（プル型）： 定期的にデータの全件あるいは差分を連携する： 任意のタイミングで最新のデータを連携する「A 通知型（プッシュ型）」については、電子ファイルの交換による連携であるため、本書では、通信仕様については対象外とし、連携するデータ項目のみを対象とする。
「B 問合せ応答型（プル型）」については、本書「3.3.2 データ項目」にて述べたように、本書では、連携するデータ項目は識別番号と基本４情報であるが、これらの情報は頻繁には更新されないため、－ 23 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン

最新のデータの連携は必ずしも必要ではないと考えられる。そこで、本書では、通信仕様については対象外とし、連携するデータ項目のみを対象とする。

－ 24 －

自治体業務アプリケーションユニット標準仕様 別冊
地域情報プラットフォームにおける「団体内統合宛名機能」ガイドライン＜参考資料＞ 番号制度団体内統合宛名システム導入方針

V1.0

次ページより、平成２５年度標準仕様 WG 自治体業務標準化ＴＦにて作成した「番号制度団体内統合宛名システム導入方針 V1.0」を掲載する。
「番号制度団体内統合宛名システム導入方針 V1.0」は平成２５年度時点の情報等に基づき検討・作成されたものであり、参考資料として活用いただきたい。

番号制度団体内統合宛名システム導入方針 V1.0

参考資料

【番号制度団体内統合宛名システム導入方針】

V1.0

一般財団法人全国地域情報化推進協会

番号制度団体内統合宛名システム導入方針 V1.0

目 次

本書の位置づけ ................................................................................................................................................................................ 1
１．団体内統合宛名システム ......................................................................................................................................................... 2
２．「団体内統合宛名システム」の導入に対する地域情報プラットフォーム活用方針................................................. 5
２．１．地域情報プラットフォーム標準仕様の活用点 .......................................................................................... 5
２．２．実現方法例 ................................................................................................................................................ 8
２．３．現状の類型化 .......................................................................................................................................... 10
２．４．類型化パターンに対する活用方針の適用 ............................................................................................. 17
２．５．団体内統合利用番号連携サーバーの活用 ........................................................................................... 20
３．【参考】 今後の中間サーバーインタフェース等への展開 ........................................................................................... 21番号制度団体内統合宛名システム導入方針 V1.0

本書の位置づけ

社会保障・税に関わる番号制度（以下「番号制度」という）については、平成 25 年 5 月 24 日に「行政手続きにおける特定の個人を識別するための番号の利用等に関する法律」および関係法律が成立したところである。
番号制度では地方公共団体等の行政機関間の団体間データ連携を「情報提供ネットワークシステ
ム」を介して実施する。この実現に際して、地方公共団体の各種業務システムは情報提供ネットワー
クシステムに直接接続するのではなく、「中間サーバー」といわれる仕組みを設置し、これを介して接続することとされている。また、この「中間サーバー」は国によって一元的に開発される計画である。
さらに、番号制度に関して公開されている下記の資料では、中間サーバーの導入に伴って「団体内統合宛名システム」と称して団体内の宛名管理統一化が求められている。
・「地方公共団体における番号制度の導入ガイドライン 平成２５年 ８月 総務省」
（以降、「導入ガイドライン」と表記）
・「地方公共団体における情報連携プラットフォームに係る中間サーバ・ソフトウェアの設計・開発作
業の調達仕様書 平成２５年 ９月 総務省」
（以降、「中間サーバー調達仕様書」と表記）
この「団体内統合宛名システム」は、個別業務システムのサブシステムとして業務ごと個別に整備される「宛名管理システム」とは異なる概念として、各業務システムの宛名管理システムを統合して統一的に宛名を管理するシステムと整理されている。
ただし、現状の地方公共団体内における「個人を一意に特定するための業務範囲の区切り方や仕組み」は団体毎に様々であり、「個人に紐づく住所や所在地等の宛名情報」が必ずしも、一元的もしくは統一的に管理されているわけではない。したがって、前述した「導入ガイドライン」や「中間サーバ
ー調達仕様書」においても、「団体内統合宛名システム」について、「各地方公共団体における業務上の必要性や宛名管理の統合の状況を総合的に勘案して整備をしていくこと」と説明されている。

APPLIC においては、平成 26 年度に策定を予定している地域情報プラットフォーム標準仕様 V3.0
において情報提供ネットワークを利用した情報連携に対応した仕様改訂を予定している。「団体内統合宛名システム」に対する仕様も同改訂で議論する計画である。
本書は地域情報プラットフォーム標準仕様書の改訂に先立ち、番号制度への対応、特に「団体内統合宛名システム」の実現方法検討における地域情報プラットフォーム標準仕様の考え方や同標準仕様の活用方針について整理したものである。

－ 1 －番号制度団体内統合宛名システム導入方針 V1.0

１．団体内統合宛名システム「導入ガイドライン」に記載されているとおり、地方公共団体において宛名情報（個人に紐づく宛名
や住所、所在地等）を適切に管理することは、行政事務の実施や住民サービスの提供の上で重要である。しかし、地方公共団体によっては宛名情報が各業務システムにおいて個別に管理されている
場合があり、必ずしも統一的に管理されていない。
一方で、宛名管理を団体内で分野横断に統一管理していたり、部分的に分野を横断した統一が図られたりしている地方公共団体も存在する。
番号制度ではこの状況を整理し、全庁的に業務横断に宛名管理を統一しているシステムを「団体内統合宛名管理システム」とよび、そこで個人を指定するのに用いられている識別子を「団体内統合
宛名番号」と定義して業務ごとの宛名管理システムと区別している。
中間サーバーを介して情報連携するに際して、情報連携に用いる「符号」と団体内の業務システム
で管理されている個人を一意に識別して紐づける必要がある。宛名管理が統合的に整備されている
場合は、団体内統合宛名システムで管理されている団体内統合宛名番号を用いて紐づけることが可能となる。そこで、「導入ガイドライン」では団体内統合宛名管理システムの導入を推奨している。
本書では、地域情報プラットフォーム標準仕様を利用し、この「団体内統合宛名システム」を整備す
る方法や考え方を示すこととし、本章で前提となる「団体内統合宛名システム」に関連する各種用語
定義や基本要件を整理する。
なお、統合的に整備されていない場合には業務ごとの宛名管理システムが持つ宛名番号を統合して個人を一意に指定する「団体内統合利用番号」を導入し、その紐付を行うための仕組みである「団体内統合利用番号連携サーバー」を整備する方法も「導入ガイドライン」には示されており、それらにも配慮した検討とする。
（１）「団体内統合宛名システム」の導入方法を検討するにあたって前提とする用語定義（出典元：「中間サーバー調達仕様書」）
表１－１ 用語の定義
用語

説明

番号制度

「社会保障・税に関わる番号制度」の略称。

番号法

行政手続における特定の個人を識別するための番号の利用等に関する法
律（平成 25 年法律第 27 号）をいう。
※本書で、特に明示しない条文番号は、本用語定義の出典元と同じく、番号法の条文番号とする

団体内統合宛名シス

地方公共団体で業務横断的に宛名、住所、所在地等の情報の保持・管理テムを行う宛名管理システムを指す。

団体内統合宛名番

地方公共団体において、団体内統合宛名システムで、個人又は法人（事業号所等）を識別するために付番されている番号を指す。団体内統合宛名番号
は地方公共団体に閉じて用いられる固有の番号である。

宛名管理システム

地方公共団体で業務上必要となる宛名、住所、所在地等の情報の保持・管理を行うシステムを指す。

個人番号

番号法に基づき個人に付番される「個人番号」を指す（第 2 条第 5 項）。

符号

情報提供ネットワークシステム等及び情報保有期間において情報提供で用いる個人の識別子を指す。

情報提供ネットワー

特定個人情報の提供について管理するための電子情報処理組織で総務大クシステム

臣が設置、管理するものを指す（第 2 条第 14 項）。

特定個人情報個人番号をその内容に含む個人情報を指す（第 2 条第 8 項）。
－ 2 －番号制度団体内統合宛名システム導入方針 V1.0

（２）基本要件① 「団体内統合宛名システム」に求められる機能 （出典元：「導入ガイドライン」）
表１－２ 団体内統合宛名システムの機能
機能名

機能説明

宛名番号付番機能

団体内統合宛名番号が未登録の個人について、新規に団体内統合
宛名番号を付番する機能。既存業務システムからの団体内統合宛名
番号要求に対し、団体内統合宛名番号を付番し、既存業務システム
及び中間サーバーに対し返却する。

宛名情報等管理機能

団体内統合宛名システムにおいて宛名情報を団体内統合宛名番号、
個人番号と紐付けて保存し、管理する機能。

中間サーバー連携機能

中間サーバーまたは中間サーバー端末からの要求に基づき、団体内
統合宛名番号に紐づく宛名情報等を通知する機能。

既存システム連携機能

既存業務システムからの要求に基づき、個人番号又は団体内統合宛
名番号に紐づく宛名情報を通知する機能。

中間サーバー連携機能については中間サーバー側の仕様、要件として定義されると考えられるため、本書では具体的な定義は行わない。
（３）基本要件② 「団体内統合宛名システム」が対象とする事務の範囲 （出典元：「導入ガイドライン」）
番号法において情報連携が義務付けられている別表第二に列挙されている事務および独自に条例を制定し番号制度の対象とした事務が最低限対象となる。
（４）基本要件③ 「団体内統合宛名システム」が保有する情報の範囲 （出典元：「導入ガイドライン」）
表１－３ 団体内統合宛名システムの持つ情報
項番

情報名

主な内容

1

団体内統合宛名番号

地方公共団体において、団体内統合宛名

必須・任意の区分必須システムで、個人又は法人（事業所等）を識別するために付番されている番号を指す。団体内統合宛名番号は地方公共団体に閉じて用いられる固有の番号である。
2

個人番号

番号法に基づき個人に付番される「個人番必須号」を指す（第 2 条第 5 項）。
3

基本４情報

氏名、住所、生年月日、性別

必須

4

連絡先情報

個人の電話番号等の連絡先情報

任意

5

送付先情報

個人への郵送物の届け先情報

任意

6

口座情報

還付口座や納付口座情報

任意

7

特記事項

個人に対する特記事項、注意事項など

任意

8

法人情報

任意

本書では必須部分の団体内統合宛名番号、個人番号、基本四情報を対象に議論することとする。

－ 3 －番号制度団体内統合宛名システム導入方針 V1.0
（５）基本要件④ その他の留意事項 （出典元：「導入ガイドライン」）
i. 履歴管理の考え方

前述した「団体内統合宛名システム」が保有すべき情報のうち、「項番 2． 個人番号」「項番 3． 基
本 4 情報」について、適切な履歴管理を行い、過去時点における宛名情報も返すことができるようにすることが重要となる。
ii. 機能範囲の考え方
本書の「１．（２）基本要件 ①」に抽出した「団体内統合宛名システム」に求められる機能は、最低限必要なものとして「導入ガイドライン」に示されている。したがって、各地方公共団体の業務やシステムの状況等を勘案し、これより多くの機能を実装すること事態、特段、問題はないと考えられる。
iii. 保有すべき情報範囲の考え方
本書の「１．（４）基本要件 ③」に抽出した「団体内統合宛名システム」が保有すべき情報の範囲は、最低限検討が必要なものとして「導入ガイドライン」に示されている。したがって、各地方公共団体の業
務やシステムの状況等や制度上の制約を勘案したうえで、これより多くの情報を管理すること事態、特段、問題はないと考えられる。

－ 4 －番号制度団体内統合宛名システム導入方針 V1.0

２．「団体内統合宛名システム」の導入に対する地域情報プラットフォーム活用方針
前章で整理した「団体内統合宛名システム」の基本要件を踏まえ、本章では地域情報プラットフォー
ム標準仕様に示しているシステム構築の考え方や同標準仕様に準拠した製品を利活用した「団体内統合宛名システム」の導入・実現方法案を提示する。
導入・実現方式案の検討に際して、「表１－２ 団体内統合宛名システムの機能」に示した各機能の実現に地域情報プラットフォーム標準仕様がどのように活用可能であるかをまず整理することとする。
これらの整理は次年度以降、更に方式案の充実を図るとともに、各案の具体性を高め自治体の実導入に活用可能な資料として整備する。

２．１．地域情報プラットフォーム標準仕様の活用点
以下に、「団体内統合宛名システム」の導入・実現に際して活用可能と考える地域情報プラットフォーム標準仕様の要素と活用の際の留意点をまとめる。
（１）地域情報プラットフォーム標準仕様における「識別番号」の活用
地域情報プラットフォーム標準仕様体系内の自治体業務アプリケーションユニット標準仕様（以降、「自治体業務 APU 標準仕様」と省略表記）に定義されている「識別番号」を団体内統合宛名システムの「宛名番号付番機能」の導入に活用することが考えられる。
地域情報プラットフォーム標準仕様体系内の自治体業務 APU 標準仕様に含まれる「業務 1-1 標準
仕様の読み方（補足事項）」では以下のような考え方を前提としている。
自治体内で人（外国人住民・住登外者・団体・法人を含む）を共通的に管理するための番号を「識別番号」と称している。識別番号は以下のような番号である。
①識別番号は、人が自治体の中で最初に登録された業務ユニットで、自治体内で重複が無いように付番される。
識別番号を付番する業務ユニットと対象は次のとおり。
・住民基本台帳ユニット： 住民 （日本人住民、外国人住民）
・住登外管理ユニット： 住登外 法人 他
②人が、ある業務ユニットから他の業務ユニットに管理が移っても、一度付番された識別番号は基本的に変わらず、同じ番号で管理することとする。

前章の「表１－２」に整理した「宛名番号付番機能」の導入に際しては、団体内統合宛名番号をいかに付番するかの検討が重要である。
団体内統合宛名番号の付番方法として、既存の宛名番号などを団体内統合宛名番号として採用する方法と、あらたに団体内統合宛名番号を付番する方法が考えられる。導入ガイドラインでは基礎
自治体はすでに一定の宛名管理がなされている場合が多いことから前者を推奨している。
地域情報プラットフォーム準拠の業務ユニットが既に導入されており、識別番号が付番済みの場合、団体内統合宛名番号として識別番号を活用する方法が考えられる。ただし、識別番号を団体内統合
宛名番号とする場合には、以下の 3 点について注意が必要である。
1.

「識別番号」は番号法対象外の業務に対しても付番される
地域情報プラットフォーム標準仕様においては住登外者は全て「住登外管理ユニット」において管理されており、どの業務で住登外者として登録されたかに関わらず、平等に識別番号を付－ 5 －番号制度団体内統合宛名システム導入方針 V1.0

番している。
業務によっては番号制度対象外のものも含まれる可能性があり、その場合、番号制度の「団体内統合宛名番号」の観点では付番不要な個人にも「識別番号」がつけられることとなる。
これには実害はないが、団体内統合宛名システムに期待される「個人番号、団体内統合宛名
番号」の一対一の対応という観点では、「個人番号、識別番号」の対応とすると必ずしも対応がつかないものが生じることとなる。
2.

「識別番号」は再転入の際などの再利用を求めていない「識別番号」はある時点で団体内の個人が一意に指定できることを求めているが、同一個人が例えば転出し、再転入した際などに以前の識別番号に紐づけることは明確には求めてない。
一方で、「団体内統合宛名番号」は転出入に依存しない「個人番号」と一対一に紐づく性質から、同一個人については同じ番号が再利用されることが求められる。
《注意が必要なケース》
・転出した人が再転入する場合、以前の番号を使用する。
・住登外者に登録されていた人が転入する場合、以前の番号を使用する。
・住民が転出した後、引き続き、住登外者として管理する場合、番号を引き継ぐ。

3.

団体内統合宛名番号の桁数等は現状未定「中間サーバー」の仕様が未確定であるため、団体内統合宛名番号の桁数などデータ形式も未確定であり、識別番号がそのまま採用可能であるか現時点では不明である。

地域情報プラットフォーム標準仕様の思想としては、できるだけ広い範囲の業務で識別番号を採用
し、業務間の円滑な連携を図ることであり、庁内で広く採用された識別番号を団体内統合宛名番号として採用することが望ましい。
しかし、各団体の地域情報プラットフォームへの準拠状況は多様であり、識別番号が導入されていると一言で言っても、識別番号で統一的に個人が管理されている業務範囲は様々である。また、従来からの宛名番号と混在している場合も考えられる。
そのような状況では単純に識別番号を団体内統合宛名番号として、必要なインタフェースなどにセットすると定義するだけでは地域情報プラットフォーム標準仕様の活用方針の説明として不親切といえる。
そこで、まず現状の宛名番号や識別番号の整備状況をある程度類型化し、識別番号の活用可能性について整理するものとする。詳細は 2.3 章で述べる。

（２）地域情報プラットフォーム標準仕様における「業務ユニット IF」の活用
団体内統合宛名システムの「既存システム連携機能」や「中間サーバー連携機能」を地域情報プラットフォーム標準の業務ユニット IF を活用して構築する方法が考えられる。
しかし、番号制度において「中間サーバー」は「団体内統合宛名管理システム」から一元的に情報が提供されることを要求しており、住民の種別（住民・住登外者の違い）に応じてインタフェースを使い分ける方式では要件を満たさない。ところが、地域情報プラットフォーム標準仕様では住登者であるか否かに従って、「個人情報メッセージ」と「住登外情報メッセージ」に分かれている。そこで、既存システム連携機能や中間サーバー連携機能の構築に業務ユニット IF を活用するには二つのインタフェー
スを統合し、一元的に提供する機能を追加しなければならない。
この様な機能は地域情報プラットフォーム標準仕様のアーキテクチャでは業務ユニットに当てはまらないため、アーキテクチャ標準仕様「4.2 地域情報 PF の全体アーキテクチャ」に示されている「サー－ 6 －番号制度団体内統合宛名システム導入方針 V1.0

ビス基盤」に属する“機能”として定義することとが必要となる。
住民・住登外者の情報を一元的に提供する“機能”の実現方法としては、様々な方式を検討することが可能である。次年度において具体的な実現方式を検討するにあたり、本書では以下の検討例を提示するものとする。
1.
2.

統合 DB 機能を活用して構築する
専用の統合宛名機能を構築する

なお、住民基本台帳システムあるいは住登外管理システム等の既存システムを拡張して構築する
方法も考えられるが、宛名統合のために既存業務システムを改修することは現状環境への影響が大きく団体の負担も大きいと考えられるため、標準的な対応方法としては上記の方式を採用する。各方式の詳細は次章で定義する。

－ 7 －番号制度団体内統合宛名システム導入方針 V1.0

２．２．実現方法例

上述の通り、地域情報プラットフォーム標準仕様のアーキテクチャ下では団体内統合宛名システムを実現するに際して住民・住登外者の情報を一元的に提供する機能を提供する必要がある。実現方式は来年具体的に検討するが、例として
1.
2.

統合 DB 機能を活用して構築する
専用の統合宛名機能を構築するの方法が考えられる。以下でそれぞれの方式例を提示する。
例１： 統合 DB を活用する方式
統合 DB 機能を活用して団体内統合宛名システムの既存システム連携機能相当のインタフェースを実現する。この方式を「統合 DB 方式」と呼ぶこととする。
現状、統合 DB で住民基本台帳ユニット、住登外ユニットを対応している場合、「個人情報メッセー
ジ」、「住登外情報メッセージ」に対応するインタフェースが実装されているはずである。
統合 DB 方式では中間サーバー連携機能のためのインタフェースを機能強化し、追加対応することとなる。この際、「個人情報メッセージ」、「住登外情報メッセージ」に対応する機能部分を活用して効率的に実装することが考えられる。公開用 DB 方式の場合の例を下図に示す。

住民基本台帳

住登外管理

ユニット

ユニット

登録

検討中

住登外
管理表
専用表
住民基本
台帳表
統合 DB

中間サーバー連携機
能対応部分を強化

図 2-1 統合 DB 方式
なお、中間サーバー連携機能のためのインタフェースは中間サーバーの仕様として定義されることを想定しており、それに従うものとする。
－ 8 －

番号制度団体内統合宛名システム導入方針 V1.0

例２： 専用の統合宛名機能を導入する方式
統合 DB 機能では統合 DB に登録される情報の原本はあくまで業務ユニットが保持することが原則である。そこで、上述の統合 DB 方式では「個人番号」は住民基本台帳ユニット、住登外管理ユニットの双方にも保持されることとなる。
一方で、「個人番号」を保持することで特定個人情報保護評価対象となるため、できるだけ「個人番号」を持たない考え方もある。団体内統合宛名システムにおいても、「個人番号」を同システムに集約し、多くの業務で分散管理することのないようにすることも意図の一つとされている。
そこで、住登外管理ユニットに「個人番号」を保持せず、団体内統合宛名システムにのみ保持する方法が考えられる。この場合、構造は統合 DB 方式と同様になるが、業務ユニット側に情報を持たないことから従来の地域情報プラットフォーム標準仕様では統合 DB 機能とは言えない。そこで、この方式を統合 DB 方式と明示的に区別するため「統合宛名機能方式」と呼ぶこととする。

住民基本台帳

住登外管理

ユニット

ユニット

登録

検討中

登録

統合宛名
機能

統合宛名表
中間サーバーへ

図 2-2 統合宛名機能方式－ 9 －番号制度団体内統合宛名システム導入方針 V1.0

２．３．自治体内における現状の宛名管理の類型化（１）前提となる考え方の整理
前章で整理したように、団体内統合宛名システムの「宛名番号付番機能」、「既存システム連携機能」、「中間サーバー連携機能」の実現に地域情報プラットフォーム標準仕様を活用することが考えられる。
地域情報プラットフォーム標準仕様の活用を考えるに当たって、特に識別番号の活用に際しては、
現状どこまで庁内の宛名管理が統一されており、識別番号が利用されているかによって、活用可能性が大きく変化する。
そこで、まず宛名の統合に対する自治体の現状を類型化する。そして、類型化されたそれぞれのパターンに対して活用方針をどのように適用するかを整理する。活用方針を実際にどの様に適用す
るか次年度に具体化する。
「導入ガイドライン」では各地方公共団体の宛名管理の現状を、番号法で情報連携が義務付けられている全ての業務システムに対して、
 別表第二対象の全業務システムで宛名管理が統一されている場合
 全部ではないが、一部の業務システムで宛名管理が統一されている場合
 宛名管理が全く統一されておらず、全ての業務システムが個別に宛名情報を管理している場合に類型化して整理している。
本稿においては、課題を整理するうえで上記の「宛名管理が統一されているか否かの状態」を次のような２つの観点【Ａ】・【Ｂ】を用いて定義し、現状の類型化を行うにあたっての前提とする。

観点【Ａ】
観点【Ｂ】

同じ宛名番号が複数の個人に付与されることはない状態（＝ 一つの宛名番号は唯一無二の個人に付与されている状態）
複数の異なる宛名番号が同一個人に付与されることはない状態（＝ 唯一無二の宛名番号が一人の個人に付与されている状態）
図 2-3 「宛名管理が統一」される理想的な状態の定義－ 10 －

番号制度団体内統合宛名システム導入方針 V1.0

まず、下記の「表２－１」に示した「パターン【あ】」のとおり、【Ａ】の状態も【Ｂ】の状態も「○＝成り立っている」場合を、「宛名管理が統一されている理想的な状態」と定義する。その他、【Ａ】の状態もしくは【B】の状態の一方が「×＝成り立っていない」場合、および【A】と【B】の双方が「×＝成り立っていない」場合は、「宛名管理が統一されていない状態」と定義する。
表２－１ 本稿で「宛名管理が統一されているか否か」を判断する組み合わせ
パターン【あ】パターン【い】パターン【う】

パターン【え】

観点【Ａ】

○

○

×

×

観点【Ｂ】

○

×

○

×

宛名管理が統一

宛名管理が統一

宛名管理が統一

宛名管理が統一されている理想

されていないされていないされていない内容

的な状態
前述したような「宛名管理の統一」状態の定義を踏まえ、システム的な２つの手段の適用方法を軸に、自治体の現状を類型化する。
自治体が取りうる２つのシステム的な手段として、まず、システムで運用する際の「付番体系の適用」と「付番機能の適用」という汎用的な方法を踏まえた考え方の整理を行う。
手段１： 付番体系の適用方法
手段２： 付番機能の適用方法【手段１： 付番体系の適用方法】
付番体系の適用方法として、後述する付番機能が複数になっても各付番機能が一貫した番号体系
ルールのもとで宛名番号を発行する方法と、そうした複数の付番機能間で相互調整された番号体系
ルールを適用せずに運用する場合がある。前者のように、全ての付番機能で付与する番号の順序性や独立性を保つ付番ルールがあり適用されている場合は、それぞれの付番機能が同じ宛名番号を重複して発行することはない。一方、複数の付番機能間で相互調整された番号体系ルールの適用が無い場合には、異なる付番機能で同じ宛名番号が重複して発行される可能性がある。
【手段２： 付番機能の適用方法】
付番機能の適用方法として、「識別番号」や「宛名番号」といったシステム処理用の識別子を付番する機能が別々の業務システムを横断的に一か所で提供されている場合、新たな宛名番号を必要とする個別の業務システムは、この集約された付番機能に発番を依頼する。一方で、付番機能が複数箇所に分散して提供される場合もあり（例えば、複数の業務システムが個別に付番機能を保有している事例も含む）、こうした場合は、複数の業務システムが個別に付番機能を保有して独自に発番することが可能となる。

－ 11 －

番号制度団体内統合宛名システム導入方針 V1.0

ここで、このような「２つのシステム的な手段の適用方法」と、「宛名管理が統一されているか否かの状態」との関係性について考察を加える。
自治体内における付番体系で番号の順序性や独立性を保つ統一的なルールがあれば、付番機能が複数個所の場合でも同じ宛名番号が複数の個人に付番されることはない。つまり、図 2-3 の観点【A】が「○＝成り立つ」ことが保証される。
一方、付番機能が複数箇所に分散している場合、これらの複数の付番機能間で相互調整された番号の付番体系ルールがない場合、同一個人に独立した付番機能毎に異なる宛名番号を付与される可能性はある。つまり、独立した付番機能としては、一人の個人に対して一つの宛名番号のみを発行していたとしても、他の付番機能でもこの同一個人に異なる宛名番号を発行しているため、結果として複数の宛名番号や重複した宛名番号が同一個人に付与される可能性がある。また、いわゆる再転入の際など、以前利用していた宛名番号を再利用するといった処理が番号の付番体系のルールとして適用されていない場合には、同一個人に以前利用していた宛名番号と異なる番号が追加で付番される可能性もある。
このような事態を避けるためには、同一個人に対する自治体内における付番履歴を管理し、過去に一度でもいずれかの付番機能が発行した宛名番号を持った個人にはその宛名番号を利用し、全く新規の場合にのみ新しい宛名番号を発行する、というような付番体系のルールが適用される必要がある。付番機能が一か所に集約されている場合、このような付番のルールは単一の付番機能内に適用してあればよいが、付番機能が複数個所に分散している場合、複数の付番機能間で当該ルールを共有し履歴情報や更新情報を相互連携する機能が必要となる。
（２）宛名管理の類型化
前述した考え方の整理を踏まえ、自治体内における宛名管理の状態をそれぞれの区分として次表のパターン①～⑦に分類する。
表２－２ 現状の宛名管理に対する整理
類型

付番体系

類型①

統一されている

付番機能
一か所

類型②

個人との対応
一対一対応
時系列に 1 対 N

類型③

複数個所

一対一対応

類型④

（相互連携機能あり）

時系列に 1 対 N

類型⑤

複数個所

付番機能内で 1 対１類型⑥（相互連携機能なし）

１対 N

複数個所

－

類型⑦

統一されていない

類型①は付番体系の統一ルールが適用され、さらに、一か所の付番機能から付番履歴を管理し再転入処理などの処理を施しているため、本稿「表２－１」の「パターン【あ】」が保証され、宛名管理が統一された理想的な状態にあると位置づけられる。

－ 12 －

番号制度団体内統合宛名システム導入方針 V1.0

付番
機能

住基

住登外

履歴

図 2-4 類型①のイメージ
類型②は付番体系が統一されているため本稿「図２-３」の観点【A】に示した「同じ宛名番号が複数の個人に付与されることはない状態」は保証されるが、再転入処理などが行われておらず、時系列には同一個人に複数の宛名番号が付与される可能性がある。従って、本稿「表２－１」の「パターン【い】」に含まれ、宛名管理が統一されていない状態といえる。

付番
機能

住基

住登外

図 2-5 類型②のイメージ
類型③は複数個所から付番されるが付番体系が統一されており、同じ宛名番号が各付番機能で多重に付番されることはない。また各付番機能を相互連携する機能が実装されており、同一人には同じ宛名番号が付番されるようになっている。さらに、各付番機能は再転入などの処理を実装しており時系列にも同じ番号が保証される。つまり、本稿「表２－１」の「パターン【あ】」が保証され、宛名管理が統一された理想的な状態が実現できていると整理できる。

付番
機能

付番
機能

住基

履歴

履歴

図 2-6 類型③のイメージ－ 13 －

住登外

番号制度団体内統合宛名システム導入方針 V1.0

類型④は付番機能ごとに同じ宛名番号が多重に付番されることはなく、相互連携されて同一人には同じ宛名番号となるが、再転入処理などがなされておらず時系列では同一人に異なる番号となる
ため、本稿「表２－１」の「パターン【い】」に含まれ、宛名管理が統一されていない状態といえる。

付番
機能

付番
機能

住基

住登外

図 2-7 類型④のイメージ
類型⑤は複数個所で独立して付番されている。番号体系が統一されているので同じ宛名番号が多重に付番されることはないが、同一個人に対しては複数の宛名番号が付番される場合がある。一つの付番機能内では再転入処理などが行われており時系列での無二性が保証されているが、全体としては、本稿「表２－１」の「パターン【い】」に含まれ、宛名管理が統一されていない状態といえる。

..
..
..

付番
機能

付番
機能

住基

..
..
..

住登外

履歴

履歴

図 2-8 類型⑤のイメージ
類型⑥では再転入処理が行われていないため、一つの付番機能内においても同一個人に複数の異なる宛名番号が付与される可能性がある。従って、全体としては本稿「表２－１」の「パターン【う】」に含まれ、宛名管理が統一されていない状態といえる。

付番
機能

..
..
..

付番
機能

住基

図 2-9 類型⑥のイメージ－ 14 －

..
..
..

住登外

番号制度団体内統合宛名システム導入方針 V1.0

類型⑦では複数の付番機能が統一されない個別の付番体系で宛名番号を付番しており、同じ宛
名番号が多重に付番される場合もある。そのため、類型⑦は本稿「表２－１」の「パターン【え】」に含
まれ、宛名管理が統一されていない状態といえる。
なお、付番機能が部分的に統一されているが、全ての付番機能は統一されていない場合も統一されていないとして類型⑦に分類する。

付番
機能

付番
機能

住基

住登外

図 2-10 類型⑦のイメージ

表２－３ 宛名管理の類型と宛名管理の統一度合い（表２－１）の関係性
類型

宛名管理が統一されている（○）か否（×）

類型①

○

類型②

×

類型③

○

類型④

×

類型⑤

×

類型⑥

×

類型⑦

×

（３）宛名管理の類型と地域情報プラットフォーム標準仕様との関係についての考察
地域情報プラットフォーム標準仕様における「識別子」の性質は付番体系が統一されていること、付番機能をまたがって同一個人に同じ番号が付番されることを求めており、付番機能の統一や再転入など時系列での同一性については明確な規定はない。よって、類型①から④が識別子の性質を備えていると言える。一方で、団体内統合宛名番号は加えて時系列で同一番号であることを求めており
類型①、③がその性質を備えていることとなる。
ただし、地域情報プラットフォーム標準仕様における識別子の統一範囲は地域情報プラットフォー
ム標準仕様が対象とする業務ユニットの範囲であり、一方で団体内統合宛名番号が対象とするのは別表第二の範囲である。双方の範囲は異なるので単純に比較はできない。
しかし、「導入ガイドライン」における分類整理は別表第二の対象業務に関するものではあるが、番号制度の目的である行政事務の正確性、効率性向上の観点からは別表第二に含まれない業務に対しても付番管理が整備され、庁内全体として宛名管理が統一されている状態であることが望ましい。
－ 15 －

番号制度団体内統合宛名システム導入方針 V1.0

また、地域情報プラットフォームも庁内の情報連携を促進するものであり、対象業務ユニット以上の識別番号活用を妨げるものではない。
つまり、対象範囲の違いをことさらに意識する必要のない場合も多いと考えられる。一方で、情報連携ネットワークはもちろん、庁内の他システムとも連携がなく、全く独立したシステムも存在する可能性があり、そこまでを全体とし統一対象とすると自治体現状の多くのが類型⑦に極端に偏ってしまう可能性がある。
そこで、以下の議論では特に断らない限り分類対象とする全体を最低限、別表第二の範囲とする。
ただし、それ以上の範囲についてもできるだけ広範囲に統一について検討することを推奨する。

－ 16 －

番号制度団体内統合宛名システム導入方針 V1.0

２．４．類型化パターンに対する活用方針の適用

前章で作成した各類型に対して活用方針の適用について方向性を整理する。具体的な適用方法
や、その中で標準仕様として規定すべき部分の整理については次年度に継続して実施するものとする。
まず、類型⑦については地域情報プラットフォーム標準仕様の識別番号としての性質も、番号制度の団体内統合宛名番号としての性質も備えていないため、そのまま既存の宛名番号を活用して団体
内統合宛名番号対応することは推奨できない。類型⑦についてはまず同じ宛名番号が別人に付番される可能性を排除することが先決となる。
対処方法として例えば、対象の各業務システムにおいて宛名番号を登録するデータベース項目の桁数など宛名番号の桁数定義に余裕がある場合、それぞれの付番機能が付番した宛名番号の先頭に付番機能ごとの固有番号を付加すれば付番機能ごとに独立した番号とすることができる。これによって同じ宛名番号が異なる付番機能において別人に付番される可能性を排除し類型⑥の状態へ移行することができる。（表 2-2 の I）
番号制度では当面の対応としてバラバラの宛名番号を紐づける対応表を外付けで実装する「団体内統合利用番号連携サーバー」方式も利用可能としている。
類型⑦ではこの「団体内統合利用番号連携サーバー」による対応も可能である。ただし、この当面の対応方法は「団体内統合宛名システム」とは異なるものと定義されている。そこで以下の活用方法の議論からは外すこととする。団体内統合利用番号連携サーバーについては次章で改めて整理する。
住基

Aさん1回目宛名番号

住登外

Aさん1回目宛名番号

住基

Aさん2回目宛名番号

住登外

Aさん2回目宛名番号

住基

Aさん3回目宛名番号

住登外

Aさん3回目宛名番号

住登外

Bさん1回目宛名番号

住登外

Bさん2回目宛名番号

住登外

Bさん3回目宛名番号

Aさん統合利用番号

宛名

業務を横断した
対応表を作る

Bさん統合利用番号

住基

宛名

住登外

宛名機能ごと、時系列に一人に複数ある宛名番号を紐づける対応表を外付けに準備し、必ず一人に一つの統合利用番号が付番されるように管理する。
図 2-11 団体内統合利用番号連携サーバー方式での対応
次に類型⑤、⑥の状態では同一人に異なる宛名番号が付番されおり、既存の宛名番号を団体内
統合宛名番号として利用するにはまずこれへ対応する必要がある。
－ 17 －

番号制度団体内統合宛名システム導入方針 V1.0

対処方法としては、宛名番号付番方式の抜本的な見直を行い、すべての宛名番号が一つの付番
機能から付番される形態（①、②）へ移行する方法あるいは、各付番機能の改修（機能追加）により付番機能が相互連携する形態（③、④）へ変更する方法のいずれかが必要になる。（表 2-2 の II）
表２－４ 付番に対する改善
類型

付番体系

類型①

統一されている

付番機能

個人との対応

一か所

一対一対応

類型②

時系列に 1 対 N

類型③

複数個所

一対一対応

類型④

（横断的調整機能あり）

時系列に 1 対 N

類型⑤

複数個所

付番機能内で 1 対１

類型⑥
類型⑦

統一されていない

複数個所

II 抜本 的な見直しを行うか、相互連携する機能を強化する

１対 N

I 付番機能ごとの固－有番号を付ける

以下ではこれらの対応を行い類型⑤～⑦は一旦、類型①から④の状態に改善した後に番号制度対応することを前提として類型①～④についての対応方法を整理する。
（１）類型①に対する活用方法
類型①は識別番号としての理想的な導入形態であり、既存の宛名番号が団体内統合宛名番号としての性質も備えている。この場合、宛名番号をそのまま識別番号かつ団体内統合宛名番号として活用することができる。既に住登者、住登外者ともに宛名番号を用いて特定し、アクセスすることが可能な状態と見ることができる。
この場合、住民・住登外者の情報を一元的に提供する機能の実現方式としては統合 DB 方式、統合宛名機能方式双方とも問題なく利用することができるので、現状の導入状況、例えば統合 DB が既に導入済みなどといった状況に合わせて方式を選択する。
ただし、識別番号と団体内統合宛名番号を同値とする場合、
「識別番号」は番号法対象外の業務にも付番されている



団体内統合宛名番号の桁数などの要件が未定については引き続き課題であるので、注意が必要である。
特に後者に関して、桁数などの問題がなく識別番号と団体内統合宛名番号を同じ値にできたとしても、ある業務は識別番号を持つが番号制度の連携対象外で団体内統合宛名番号を持たない場合もある。同じ値であっても運用上は両者を意識的に区別すべき場合もあり、対応を検討する必要がある。これについては次年度継続検討とする。
（２）類型②に対する活用方法
類型②は識別番号としての性質を備えるため、類型①と同様に宛名番号を識別番号として利用することができる。しかし、再転入処理などがなされていないため、団体内統合宛名番号としては利用できない。

－ 18 －

番号制度団体内統合宛名システム導入方針 V1.0

対応策としては、


発番済みの宛名番号を管理して再転入に備える履歴管理機能を強化し、類型①に改善する
方法



団体内統合宛名番号を新規に付番し、時系列で異なる同一個人対する宛名番号をまとめてそれに紐づける対応表を外付けで管理する方法が考えられる。その他の方法含め詳細な対応方針については次年度継続検討とする。
情報を一元的に提供する機能の実装については類型①と同様になる。
（３）類型③に対する活用方法
類型③は付番機能が分散しているものの、類型①と同様に識別番号としての性質も団体内統合
宛名番号としての性質も備えている。よって、宛名番号をそのまま識別番号、団体内統合宛名番号として利用することができ、類型①と同様の状況となる。
（４）類型④に対する活用方法
類型④は類型②と同様に識別番号としての性質は備えるが、団体内統合宛名番号としての性質は持たない。よって類型②と同様の対応を検討する必要上がる。
ただし、付番機能が分散しているため、一か所の機能強化で対応できる類型②に比べて対応工数が大きくなる可能性がある。まずは付番機能の統一を図り、類型②の状態に改善してから対応を進める段階的な方法も考えられる。
段階的な移行や適用の方針について次年度継続検討とする。

－ 19 －

番号制度団体内統合宛名システム導入方針 V1.0

２．５．団体内統合利用番号連携サーバーの活用

類型⑦のように現状宛名番号が統一されていない環境に対して「導入ガイドライン」では当面の対応策として「団体内統合利用番号連携サーバー」を導入する方式も認めている。
「団体内統合利用番号連携サーバー」では既存の宛名番号（番号制度では利用番号とも呼ばれる）の運用はそのままで、別途外付けで同一人物に関する宛名番号を一つの統合利用番号に紐づける
対応表を団体内統合利用番号連携サーバーに保持し、データ連携時に相互変換を行う方式である。
あくまで当面の対応として「団体内統合宛名システム」とは別方式と定義されているため、団体内
統合宛名システムの導入方法を議論する本書の対象スコープではない。しかし、実情として現段階で宛名の統合がされておらず団体内統合利用番号連携サーバー方式を採用する団体も相当数あることが想定される。
そこで、一旦団体内統合利用番号連携サーバー方式を導入した後、団体内統合宛名システムへ移行する方法が考えられる。
団体内統合利用番号連携サーバーは複数の付番機能を横断的に管理する機能がある点で類型③、④に近い状態となる。
しかし、各付番機能間を横断的に団体内統合利用番号連携サーバーが紐づけているとはいえ、同一人に同じ利用番号になるように調整しているのではなく、あくまで紐付を管理しているだけなので、③、④と完全には対応しない。この場合、各業務が保持している利用番号はそのままでは識別番号
としても団体内統合宛名番号としても利用することはできない。
各業務で利用番号と合わせて団体内統合利用番号も統合利用番号連携サーバーから取得し保持することで①に近い状態にすることが可能である。最終的に元の利用番号を廃止し、団体内利用番号に移行すれば①と同等の状態となる。
この場合、団体内利用番号は識別子としての性質も団体内統合宛名番号としての性質も持たせることが可能となる。
これ以外にも移行方法は複数検討可能であり、具体的な移行手順や方針については次年度継続検討とする。

－ 20 －

番号制度団体内統合宛名システム導入方針 V1.0

３．【参考】 今後の中間サーバーインタフェース等への展開
本書は団体内統合宛名システムの導入方法について検討するものであり、各業務ユニットと中間サーバーとのインタフェースについての議論は範疇ではない。
しかし、来年度以降に中間サーバーとのインタフェースについて議論する際、団体内統合宛名番
号と識別番号との関係について注意すべき点があるので参考として考え方を整理する。
既存の地域情報プラットフォーム標準仕様における庁内のユニット間インタフェースにおいては、個人を指し示す値は「識別番号」であり今後もこの点について変更はないものと考えられる。
一方で、中間サーバーとの連携に用いられるインタフェースについては、中間サーバー側の仕様として決定される想定であるが、個人を指し示す値は「団体内統合宛名番号」となると考えられる。
具体的な定義は来年度の議論であるが、一つの考え方として、庁内の連携インタフェースのメッセージ定義においては「識別番号」をメッセージの項目として利用し、中間サーバーとのインタフェース
では「団体内統合宛名番号」をメッセージ項目として利用する対応が考えられる。
ここまでで見たように、例えば類型①や③の場合、識別番号を団体内統合宛名番号として活用することが可能であり、その場合は実際の値としては両メッセージに同じものがセットされることとなる。

税システム

連携I/F（地域情報PF)

他システム

識別番号 宛名情報

宛名DB

001

識別番号 宛名情報 個人情報①個人情報②

識別番号 宛名情報
001
002

個人A
個人B

所得DB
識別番号 個人情報①
001

¥¥¥¥A

002

¥¥¥¥B

○○DB

個人A

識別番号 個人情報①
001

¥¥¥¥A

001

個人A

¥¥¥¥A

$$$$A

002

個人B

¥¥¥¥B

$$$$B

識別番号＝団体内統合宛名番号であるため、識別番号を団体内
統合宛名番号にそのままセットして中間サーバーに連携可能

中間サーバー

同一個人に対して複数の識別番号が振られていない【補足】
団体内の情報連携はこれまでどおり識別番号により行うため、連携I/F（地域情報PF)を変更する必要がない。

図 3-1 識別番号と団体内統合宛名番号が同じ値となるパターン－ 21 －

番号制度団体内統合宛名システム導入方針 V1.0

一方で、例えば類型②や④の場合、既に述べたとおり時系列で一人に異なる宛名番号が付番されてしまっている場合の対策として


団体内統合宛名番号を新規に付番し、時系列で異なる同一個人対する宛名番号をまとめてそれに紐づける対応表を外付けで管理する方法とした場合には識別番号と団体内統合宛名番号を異なる値とする実装も考えられる。
この様な場合には中間サーバーに連携する際には識別番号から団体内統合宛名番号を取得し、その値をメッセージにセットする必要がある。
この様な変換を行うしくみは「団体内統合利用番号連携サーバー」を用いて実現することができる
が、具体的な対応については次年度に検討するものとする。

連携I/F（地域情報PF)

税システム

他システム

識別番号 宛名情報

宛名DB

001

○○DB

個人A

識別番号 宛名情報 個人情報①個人情報②

識別番号 宛名情報
個人A

001

識別番号 個人情報①
001

個人A

002

¥¥¥¥A1

団体内

001

個人A

¥¥¥¥A1$$$$A1002

個人A¥¥¥¥A2$$$$A2901

識別番号＝団体内統合宛名番号でないため、識別番号キーにして団体内統合
利用番号連携サーバーから団体内統合
宛名番号を取得して中間サーバーに連
携する

所得DB
識別番号 個人情報①
001¥¥¥¥A1

002¥¥¥¥A2

団体内
901

中間サーバー

団体内統合利用番号連携サーバー（当面の対応策）

宛名DB
識別番号

団体内

001

901

002

901

【補足】
当面の対応策となっている団体
内統合利用番号連携サーバーを利用するシステムのみが個別対応すれば全体に影響しない。

図 3-2 識別番号と団体内統合宛名番号が異なる値となるパターン－ 22 －