地方公共団体の基幹業務システムの統一・標準化に関する共通機能等技術要件検討会 宛名管理ワーキングチーム（第2回）
概要
- 日時：令和4年（2022年）12月13日（火）10時00分から12時00分まで
- 場所：オンライン会議
- 議事次第：
- 開会
- 議題
- 宛名管理に関する最適案意見の全体像と今後の進め方
- 宛名管理に関する課題の対応方針の説明
- その他
- 閉会
資料
関連政策
議事概要
日時
令和4年（2022年）12月13日（火）10時00分から12時00分まで
場所
オンライン会議
1.議題
宛名管理ワーキングチーム
1.宛名管理に関する最適案意見の全体像と今後の進め方
- 事務局： 本日の検討会の内容に関して意見があれば、12月15日（木）午前中までに提出いただきたい。
2.宛名管理に関する課題の対応方針の説明
＜1.1.1.住民を含む宛名番号の付番機能・宛名情報の集約＞
- オブザーバ： 共通機能で住民宛名番号と住登外宛名番号の両方付番できる機能が実装されることとなると理解した。住民記録システム側で標準オプション機能とするのは、共通機能における付番機能の利用部分だけか、住民記録システムにある付番機能も対象となるか。
- 事務局： 今後、総務省と協議をする予定であるが、共通機能における付番機能の利用部分のみの想定。住民記録システムにて既に実装必須機能として定義されている住民宛名番号の付番機能の扱いは変更しない方針。
- オブザーバ： 住民記録システムが標準オプション機能を選択しなかった場合の共通機能はどのような動きとなるか。住民記録システム側で住民宛名番号を付番した場合、共通機能側でも付番して重複することにならないか。
- 事務局： これまでの仕様規定と変わらず、住民記録システムにて住民宛名番号を付番し、住登外者宛名番号については共通機能にて付番する。住民記録システムにて住民宛名番号付番をする場合は、共通機能で付番されることがないように規定する想定である。
- 構成員： 住民宛名番号を付番する機能は、共通機能としては実装必須機能とされているが、利用するか否かは住民記録システム側の標準オプション機能の提供状況を踏まえた判断という理解でよいか。
- 事務局： ご認識のとおり。
- 構成員： 住登外者宛名管理機能で住民宛名番号を付番する機能を実装必須とする理由は何か教えていただきたい。
- 事務局： 住民記録システム側で標準オプション機能を実装した際に、共通機能に付番機能がなければ一体的に付番ができない状況になるため、共通機能側は可変とはせず、常に機能を提供する形がよいと考えたためである。
- オブザーバ： 宛名情報の一元管理についての議論は、令和7年度後に引き継がれるか、令和5年度から7年度に掛け継続して議論を進めるのか、スケジュール感及び対応方法について確認したい。
- 事務局： 本検討会で検討している内容のうち、共通機能での住民宛名番号の付番機能の追加など仕様書に規定すると整理しているものについては、今年度末の改定に含めて対応する想定である。
- オブザーバ： 令和5年度から7年度で対応するものは今年度反映し、令和7年度以降対応となるものは継続検討という理解でよいか。
- 事務局： ご認識のとおり。
- 構成員： 共通機能で住民宛名番号と住登外者宛名番号を一元的に付番する際、番号体系は分かれるか、連番となるか。
- 事務局： 特段規定しない方針で考えている。詳細は「 2.1.2.宛名番号（住登者・住登外者）の付番方針明確化」で説明するが、一元的に付番する際は、番号が一意となるように付番するという要件を設けるに留め、実装方法はベンダー側で検討いただく整理としている。なお、一元的に付番しない場合には、先頭1桁で付番時の区別をしていただく実装方法をリファレンスとして規定する想定である。
- 構成員： 承知した。
- オブザーバ： 宛名番号を一元的に付番する機能について、一定のニーズはあると理解しているが、住民宛名番号の付番機能まで共通機能の実装必須機能とする必要があるか。実装必須機能とするか、標準オプション機能とするかという点について議論が必要だと考える。また、自治体において、どの部局が、共通機能の付番機能を所管するかに関しては、事務負担を考慮した整理が必要である。さらに、共通機能が一元的に付番機能を持つ場合、それに対応する住民記録システム側の標準オプション機能の是非に関する検討が必要となる。この取り扱いに関しては、住民記録システム標準仕様書の所管である総務省の標準化検討会での判断としたい。
- 事務局： 共通機能の付番機能を標準オプション機能とするかに関しては、前述のとおり、自治体が一元的な管理を選択した場合に対応可能とするため、両方の機能が可変であると整合が取れなくなる可能性を考慮した取り扱いである。また、共通機能はホワイトリスト形式でないため、標準オプション機能を規定していないという事情もある。自治体内での共通機能の所管については、なんらか手当てが必要という点は同様の認識であり、共通機能における新機能の所管は自治体内で整理が必要である旨を現時点の標準仕様書に記載している。住民記録システム側の機能の取扱いは、総務省の標準化検討会で議論いただくことに異論はなく、引き続き協議、調整させていただきたい。
- オブザーバ： 現行システムで一元的に宛名番号を付番している場合があり、当該対応を維持するための検討が行われた結果と理解した。
- 事務局： ご認識の通り。
＜1.1.2.住登外者宛名情報の一元管理＞
- 構成員： 「住登外者の住所情報は、横並び調整方針でアドレス・ベース・レジストリを参照することとしているため、入力の揺れは発生しない」とあるが、方書や氏名は手入力による入力の揺れが発生すると考えるため、再考いただきたい。
- 事務局： ご意見を踏まえて、検討を行う。
- オブザーバ： 住登外者の基本4情報は、複数の業務が集めたものでそれぞれ更新されることが想定されており、また免許証に性別がないなど基本4情報のすべてを確認できない場合も想定され、情報の信頼度が十分ではないのではないか。各業務の本人確認手法を含めて情報の更新や突合方法については詳細を検討する必要があると考える。
- 事務局： 基本的には各業務で聞き取った情報で登録いただくことになると考えている。また、運用について整理ができることが望ましいと考えるが、各機能に跨ることも踏まえて規定は難しいものと考えている。
- オブザーバ： 基本4情報における住所は、住民票の住所か、避難先の住所かどちらか。
- 事務局： 各業務の性質によるため、現時点では明確に規定していないが、その他のご指摘も踏まえて、改めて検討を行う。
＜1.1.4.住登外者の支援措置対象者情報の一元管理＞
- オブザーバ： 支援措置対象者の管理について、住民の情報については各市区町村の住民基本台帳を管理している部署が行うが、住登外者の情報を他市区町村で利用する場合、どのようにデータ連携をする想定か。
- 事務局： 支援措置情報の一元管理は、自治体内でのデータ管理を対象としており、他自治体と連携する想定はしていない。なお、住登外者における支援措置情報については、宛名管理システムで管理とした場合の連携の想定を別のサブ課題で検討している状況である。
- オブザーバ： 住登外者の支援措置情報を別の市区町村に通知する対応は現状では検討されていないと理解したが、他市区町村に経由で情報が加害者等に伝わってしまうようなユースケースも想定されるため、市区町村間の連携についても是非ご検討いただきたい。
- 事務局： ご意見いただいたユースケースがある点については認識しており、今後の検討事項としたい。
- 構成員： 支援措置対象者情報は、各基幹業務システムで管理することになっているはずだが、「各基幹業務システムにて保持できる情報ではないため、宛名管理システムで管理する場合は、直接入力する等の利用となる想定」とはどういう意味であるか。
- 事務局： 記載誤りであるため修正する。支援措置対象者情報ではなく、申出書情報の記載誤りである。基幹業務システム側で、支援措置対象者情報を住民記録システムから連携可能であることは認識しているが、申出書情報は住民記録システムから連携されないと認識している。当該記載は同様の項目を宛名管理システムで保有する場合を想定したものであったが、誤解の可能性があるため修正する。
- 構成員： 承知した。
- オブザーバ： 本サブ課題の対応方針によって、これまで女性や子供など支援が必要な住登外者の支援情報は各基幹業務システムで管理していたが、一元的に宛名管理システムで管理する方針になるということなのか。その場合、様々な制度を踏まえて整合がとれているか。
- 事務局： 一元管理が必須というわけではなく、これまで通り各基幹業務システムでの管理が原則であるが、自治体が一元管理をする判断をした場合において、宛名管理システムで持つ場合の整理を示すものである。
- オブザーバ： まず、制度論として住登外者の支援措置対象者の情報をどのように管理するべきかという観点で検討した上で、システム上でどのように管理すべきかの観点で検討するのがよいと考える。宛名管理システムで管理するとした場合、自治体の中で支援措置対象者情報を管理する部署が発生し、管理部署には責任が生じることになるため、各省庁を含め、検討が必要である。
- 事務局： 制度面からも検討が必要という点について、承知した。令和4年度末の仕様書改定に向けて検討が可能か、移行支援期間後の検討事項とするか検討する。
- オブザーバ： 宛名番号を一元的に付番するということは、庁内で個人情報を連携することになると考えるが、業務間で連携すべきではない情報と連携できる情報があり、分けて議論すべきであると考える。本サブ課題では後者を対象とし、前者については別途検討するのがよいと考える。
- 事務局： ご意見いただいたとおり、連携可能な情報を対象としている。
＜1.2.3.住登外者宛名番号管理機能の任意化＞
- 構成員： 住登外者宛名番号管理機能とは、独立した新システムという理解でよいか。また、標準準拠システムで住登外者を登録する場合、本システムの導入が必要であるということか。その場合、住登外者宛名番号管理機能は各業務システムを標準化するにあたっては必須となると整理されるが、その仕様書が令和4年度末に改定される予定ということであれば、自治体側でハレーションが起きる可能性がある。この点も含めて調整、検討いただきたい。
- 事務局： ご認識のとおり、各自治体で構築していただく必要があり、標準準拠システムにおいて住登外者を登録する際には住登外者宛名番号管理機能を利用する必要がある。指摘事項を踏まえて検討する。
＜2.1.1.宛名管理システムを含めた役割分担・運用フローの明確化、連携仕様の規定＞
- 構成員： 国保、介護等の資格管理系システムの資格情報を、基幹業務システムが庁内連携で取得するにあたって、住所地特例などの住登外者の資格情報の連携が想定される。そのため、事前に住所地特例などの住登外者の宛名情報を基幹業務システムに連携しておく必要があるが、標準化後においてはどのように対応することになる想定か。
- 事務局： 機能別連携仕様にて、該当の連携を確認して回答する。
- 構成員： 現状では、規定されていない認識であるため、一律に住登外者宛名番号管理機能の宛名情報を基幹業務システムに持ってくることも含め、検討いただきたい。
- 事務局： 承知した。
＜2.1.2.宛名番号（住登者・住登外者）の付番方針明確化＞
- 構成員： 「宛名番号の先頭1桁目で区別」とあるが、基幹業務システムは20業務あるため、その区別に先頭2桁が必要であると考える。また、「住民区分（仮）」はどこに追加される想定か。
- 事務局： 業務の区別は不要であり、住民、住登外の区別ができればよいため、先頭1桁で十分であると考えている。また「住民区分（仮）」は、住登外者宛名番号管理機能の項目定義書に追加する想定である。
- 構成員： 承知した。
＜2.1.5.排他制御・解除の仕様明確化＞
- 構成員： 「排他制御の強制解除後に、排他制御を取得していた基幹業務システムは更新処理を継続できないようにする」という仕様について、実装イメージが湧かないため、標準仕様書に反映する際には、シーケンスなど補足情報を追加いただきたい。
- 事務局： 承知した。
＜2.1.6.住登外者宛名番号管理機能における履歴管理の仕様規定要否＞
- オブザーバ： 居所情報も含め、身元確認情報として基本4情報の履歴管理を行うことは賛成。しかし、住記住所を居所情報で上書きしてしまう可能性もあり、基本4情報のマスタを都度更新する対応には問題はないか。
- 事務局： 突合の妨げとなる可能性があり、整理が必要であるが、当面は履歴を残すことで管理する。
- 事務局： 住所情報に関し、居所情報、住所地の情報以外の他の情報があればいただきたい。
- オブザーバ： 居所の定義は曖昧である。名寄せの際に、居所情報を捨てる必要はないと考える。
- 事務局： 検索時に履歴で保持している住所情報も対象とするなどの対応も含め検討する。
＜2.2.8.外国人氏名の入力方法の確認＞
- 構成員： 現時点で規定されている入力ルールでは、入力揺らぎを抑制するには至らないと考えるため、検討頂きたい。
- 事務局： 意見を踏まえ精査する。
＜全体＞
- 構成員： 資料2 P1にある「3．住登外者の名寄せ・移行の方針確認」、「4．その他」の課題に関しては、反対意見が少なかったため取り上げていないという認識でよいか。
- 事務局： ご認識の通り。
2.その他
- 特に議論なし
以上