地方公共団体の基幹業務システムの統一・標準化に関する共通機能等技術要件検討会　宛名管理ワーキングチーム（第1回）兼データ連携ワーキングチーム（第2回）

概要

• 日時：令和4年（2022年）11月15日（火）10時00分から12時00分まで
• 場所：オンライン会議
• 議事次第：
  1. 開会
  2. 構成員の追加
  3. 議題
     • 宛名管理ワーキングチーム
       1. 事前アンケート結果及び宛名管理WTとして取り扱う課題の全体像の説明
       2. 宛名管理に関する議題の対応方針に関する討議
     • データ連携ワーキングチーム
       1. データ連携に関する最適案意見の全体像と今後の進め方
       2. データ連携に関する課題の対応方針の説明
  4. その他
  5. 閉会

資料

• 議事次第（PDF／160KB）
• 資料1 開催要領・構成員等名簿（PDF／392KB）
• 資料2 宛名管理WT_検討概要（PDF／981KB）
• 資料3 宛名管理WT_宛名管理に関する課題（PDF／2,162KB）（2022年11月18日更新）
• 資料4 データ連携WT_検討概要（PDF／862KB）（2022年11月18日更新）
• 資料5 データ連携WT_データ連携に関する課題（PDF／2,850KB）（2022年11月18日更新）
• 議事概要（PDF／471KB）

関連政策

• 地方公共団体の基幹業務システムの統一・標準化

議事概要

日時

令和4年（2022年）11月15日（火）10時00分から12時00分まで

場所

オンライン会議

1.構成員の追加

• 特に議論なし

2.議題

宛名管理ワーキングチーム

1.事前アンケート結果及び宛名管理WTとして取り扱う課題の全体像の説明

• 特に議論なし

2.宛名管理に関する議題の対応方針に関する討議

1. 宛名管理そのものに関する疑義や変更要望

＜1.1.1. 住民を含む宛名番号の付番機能・宛名情報の集約＞

• オブザーバ： 転入が集中する際のレスポンスについては、共通機能の可用性が住民記録システムより高ければ基本的には問題にならないと考えている。また、再転入については、住民記録システムの標準仕様書で定義されている。その中で、住登外者として管理した情報の履歴を確認せずに付番してよいとするのかも踏まえて、宛名の付番機能を一体化するかどうかを判断すべき。
  • 事務局： 再転入時の宛名番号の引き継ぎについては＜2.1.3.住登外者転入時の宛名番号の引き継ぎ＞において議論したい。
• オブザーバ： 現行の宛名管理システムは、これまで業務を運用する中で機能追加を経て今に至っている。結果として、税宛名や様編集、御中編集等の機能が追加され複雑化している。その中で、共通機能の標準仕様書ではどの範囲を規定する想定であるか改めて考え方を確認したい。
  • 事務局： ご指摘の通り、現行の宛名管理システムは各自治体・事業者ごとに機能や管理する内容が異なっていることを踏まえ、標準仕様として定めることは難しいと判断し、横並び調整方針で独自施策システムとして整理した。その上で、現在の住登外者宛名番号管理機能の標準仕様では、住登外者の宛名番号の名寄せのために最低限必要と考える基本4情報のみを保持することを規定している。
  • オブザーバ： 了解した。その前提において、住登外者の管理はどの業務が行う想定か。
  • 事務局： 住民記録以外の20業務が共同で利用、管理する想定である。個人番号利用事務以外の事務では、住登外者宛名番号管理機能の個人番号を利用できないように制御することを規定している。
• オブザーバ： 対応方針内容に記載のある「考慮すべき事項」は、誰がどのように考慮すべきものか。転入時の処理は、いわゆる低レイテンシー・高スループットの処理と考えるが、クラウドのサービスを利用し、負荷やスループットに応じてオートスケーリングする契約で構築していれば特段問題にはならない認識である。
  • 事務局： 同様の認識であるが、実装を想定した場合の懸念等を構成員から伺ったうえで方向性を定めていきたいと考えている。
• オブザーバ： 宛名情報の集約管理は、2025年度までの移行支援期間後の検討課題とすることの説明があったが、すぐに結論が出る内容ではないと考える。一方で、移行支援期間後まで将来像について仕様書に一切記載されないと、どういった方向性となるかシステムを開発する立場ではわかりにくくなってしまうのではないか。今後の仕様書の改定において何らかの将来像に言及することは予定されているか。一定の方向性が示されることで、対応可能なベンダから将来像に向けた作り変えを徐々に進めることも可能と考える。また、現行システムがオールインワンパッケージで提供されており、宛名情報の一体管理をしているところもあるため、それらを活用する実装も含めて仕様書の違反にならないような整理が必要と考えている。
  • 事務局： 承知した。懸念を踏まえて、できる限り記載する方向で検討を継続したい。一方で、一元管理を目指すかどうかも含めて検討がどこまで進められるのかによるところもあるため、今時点で記載することを確約することが難しいこともご理解いただきたい。
• 構成員： 集約について意見を求められている付番機能は、どの範囲をさしているのか確認したい。シーケンシャルな番号を付番する機能のみなのか。＜1.1.5.税宛名との関係の明確化（法人宛名、固定資産税の共有者）＞にて、番号が重複しないルールについて規定されるとの記載があるため、付番する機能だけであれば特段集約は不要ではないかと考える。
  • 事務局： 一義的には、付番する機能のみを想定している。ご指摘の通り、リファレンスとして付番ルールを規定することで、番号の重複は排除できることも踏まえて、集約すべきかについてご意見いただきたい。また、付番機能以外に必要な機能があればご意見をいただきたい。
  • 事務局： 別途、＜2.1.3.住登外者転入時の宛名番号の引き継ぎ＞でも説明を予定しているが、付番機能を集約することで、住登外者の転入時の宛名番号の引き継ぎも当該対応により可能となるものと想定しており、このような側面も踏まえて、ご意見をいただきたい。
  • 構成員： 了解した。一般的に考えた場合、宛名を集約して住民記録システムと分離すると、障害点が増えるため、考慮すべき事項の内容は賛同する。
• 構成員： 住民記録システムを単体で導入している場合には、付番機能の集約はコスト高となることも想定される。この観点も構成員から意見があげられるのが望ましいと考える。

＜1.1.2. 住登外者宛名情報の一元管理＞

• 構成員： 「住登外者宛名番号管理機能で保持する基本4情報の位置づけや他の基幹業務システムとの同期は必ずしも必須ではないことを改めて示す」とあるが、これは基幹業務システムの情報を住登外者宛名番号管理機能に必ずしも反映する必要がないという意味か。逆に、住登外者宛名番号管理機能の情報を基幹業務システムに必ずしも反映する必要がないという意味か。
  • 事務局： 前者を意図したもの。
• 構成員： 本資料で標準化対象外と記載された「連絡先情報／送付先情報」は、税務システムにおいては管理項目としているため、横並び調整方針を含めて整合性を確認いただきたい。
  • 事務局： 承知した。税務システムの規定は認識している。ご意見を踏まえて標準仕様書間の整合性を確保した形で検討する。

＜1.1.3. 団体内統合宛名機能の拡張による住登外者宛名の管理＞

• 構成員： 自治体に対して、団体内統合宛名番号や住登外者宛名番号を一元管理する業務メリットの説明に苦慮している。基本4情報の突合では必ずしも同一人の判断を機械的にやり切ることはできず、確認業務が増えてしまうのが実態である。宛名情報がきれいになる以外のメリットはあるか。
  • 事務局： 現状では住登外者宛名が住民宛名の数倍の数になっている自治体もあるため、これ以上不要な宛名を増やさないというメリットがあるほか、将来的な制度面の整理後に宛名情報の一元管理・相互参照につながる第1段階として捉えていただきたい。
  • 事務局： ご案内のとおり、住登外者の宛名情報の一元管理は、制度的な整理が必要となるため、今回の仕様書では規定しない整理とした。一方で、庁内の基幹業務システム間において必要な整理がつけば情報を相互に照会し情報を参照することは可能である。その際、住登外者宛名番号が一元管理されていれば、それをキー項目とすることができ、庁内データ連携に資する点も大きなメリットであると考えている。
  • オブザーバ： 庁内データ連携において、個人の識別子となる宛名番号の統一は必須であり、議論の余地はないものと考えている。
  • オブザーバ： 番号制度導入の経緯から、大量にあった宛名が名寄せされて現状に至っていると認識している。一方で、業務所管によっては、その必要性を感じられず、おろそかになっているケースが実際には存在している。そういった状況であるため、自治体によっては、システム担当等が定期的なデータクレンジングの一環として名寄せ候補を抽出し、各業務所管に同一人であるかの確認を依頼するような運用が行われている。今回の標準化においても、業務所管によっては、住登外者を一意に特定する宛名番号の付番の必要性を感じられないケースも想定され、その場合、宛名番号は増えていかざるを得ない点は留意が必要。
  • 事務局： ご意見を踏まえて、引き続き検討を行う。
• 構成員： 基本4情報での突合ではなく、個人番号での名寄せを利用できないか。
  • 事務局： 仕様書において団体内統合宛名機能は個人番号で名寄せすることを規定している。住登外者宛名番号管理機能においても、個人番号利用事務では、個人番号での名寄せが可能。
• オブザーバ： 現状、情報提供ネットワークを活用する際、自治体は団体内統合宛名を利用した連携が必須とされていることから、厚生労働省所管の国保、後期、介護における、葬祭料の支払い、死亡された場合の保険料の支払いの事務にかかる公金受取口座の登録において、新たな住登外者の宛名を作成しなければならないという課題が発生している。そういったことも踏まえ、今後は、マイナンバーカードの利用も広がり、広く個人番号を利用した申請が増えていく方向となるのではないか。団体内統合宛名を含む宛名番号の存続を前提とするのではなく、個人番号の利用拡大を検討すべきではないか。
  • 事務局： 個人番号の利用については、検討の必要性を認識しており、今後の議論の参考としたい。一方、現行制度において、庁内のデータ連携に個人番号は利用できないことから、2025年の移行に向けたスコープについては、認められた手段として宛名番号を統一する方向で検討を行うこととしたい。
• オブザーバ： 団体内統合宛名番号を庁内データ連携における共通の宛名番号として利用できない理由は、付番対象が番号利用事務に限られていることだと認識している。一方で、住登外者も含めてかなりの割合で既に団体内統合宛名番号が付番されていることを踏まえると、残りの宛名にも団体内統合宛名の仮番号等を付番する整理とし、共通の宛名番号と位置付けるのが、住登外者宛名番号管理機能を別で構築するより、相対的に費用を抑えられるのではないかと考えている。一方で、2機能の統合をすぐに実施することが難しいのであれば、あくまで機能は分けたうえで、一体的に提供する場合のリファレンスを示す考え方にも賛同できる。前提事項として説明があったデータ項目としても、団体内統合宛名と宛名番号は別項目としつつも、同一の番号を利用することも可能とする整理もできると考える。その際、個人番号を持たない住登外者の宛名の名寄せについては、制度上、基本4情報を利用するほかない点は致し方ないと考える。
  • 事務局： データ項目を統一した場合、既に仕様書で規定した通り、移行に際して住登外者宛名番号の名寄せが必須となる。また、現状で、団体内統合宛名番号は個人に対して一意に付番される整理であるが、名寄せされていない住登外者にも付番するとその整理が崩れることを懸念し、団体内統合宛名番号と宛名番号は別項目として管理することを前提とした。
• 構成員： 一体的に管理するにあたり、住民、住登外者を判別するための項目が必要ではないかと考えている。
  • 事務局： ご意見を踏まえて検討する。

2.宛名管理の仕様の疑義や不足の解消

＜2.1.1. 宛名管理システムを含めた役割分担・運用フローの明確化、連携仕様の規定＞

• オブザーバ： データ連携WTでも議論されている点、基幹業務システムから独自施策システムへのデータを渡すことは可能であるが、基幹業務システムが独自施策システムからデータを受け取ることができないのではないかと考える。その場合、宛名管理システムを独自施策システムと整理することが適切かどうかについて改めて検討が必要ではないか。
  • 事務局： 独自施策システムから基幹業務システムにデータを渡す際においても、すでに機能別連携仕様で規定されているAPIを利用することになる。
  • オブザーバ： その場合同一のAPIを複数のシステムが提供することになり、競合が発生する。
  • 事務局： APIコール名の重複することとなる点はデータ連携WTでもご指摘いただき認識している。独自施策システムが提供する場合の命名規則を定めることで、競合が発生しないようにしたいと考えている。別途、業務的に他のシステムのAPIが利用できるのかといった観点での検討も必要と考えている。
  • オブザーバ： APIコール名を変更するにあたっては、独自施策システムの業務IDは自治体が独自で定めることから、標準準拠システム側がノンカスタマイズでは対応できない点も考慮すべき。
  • 事務局： ご意見を踏まえて検討する。

＜2.1.3. 住登外者転入時の宛名番号の引き継ぎ＞

• オブザーバ： 転入時の宛名番号の引き継ぎよりも、ワンスオンリーや引越しOSSにおける転入予約等の考え方が広がる中での将来的なあり方を念頭に検討すべきである。住登外者として既に管理している情報を、転入時に確認しなくてよいと整理することが正しいか。また、番号法9条に関して、住基事務は個人番号の利用が当然に想定されているため、検討の制約にはならないのではないか。
  • オブザーバ： 引越しOSSでは、転入者に対して自治体がなにを準備するのかという観点から、プレプリント等が必要である点について、デジタル庁とも協議の上で方針を定めた。その際も転入後、住民になった後の事務については住基法記載事項として番号法が適用されるものの、転入予約も含め転入前においては住民ではない以上は、個人番号の利用はできないものとの整理に至った。結果として、利用する識別子も個人番号ではないものとしている。転入前における各基幹業務システムの個人番号の利用については、各法を前提にそれぞれデジタル庁と各府省での個別の協議の上で方針が定められるものと考えている。
• 事務局： 住民記録システムの目線からは、住登外者情報の必要性は薄いため、名寄せが必要な基幹業務システム側での対応するのが望ましいと考えている。再転入に関しても、あくまで住民記録システム内において確認ができればよいとの整理を行った。

＜2.1.5. 排他制御・解除の仕様明確化＞

• オブザーバ： ＜2.1.6.住登外者宛名番号管理機能における履歴管理の仕様規定要否＞も含めて、既存の団体内統合宛名の機能の中に該当するものがあると想定されるため、その要件に合わせた仕様とするのがよいと考える。
  • 事務局： ご意見を踏まえて検討する。

3.住登外者の名寄せ・移行の方針確認

• 特に議論なし

4.その他

• 特に議論なし

データ連携ワーキングチーム

1.データ連携に関する最適案意見の全体像と今後の進め方

• 会議時間の都合で質疑は割愛

2.データ連携に関する課題の対応方針の説明

• 会議時間の都合で質疑は割愛
• オブザーバ： 今回対応方針や取り扱いが未定となっているサブ課題への最適案意見の提示はいつ実施すればよいか。
  • 事務局： 11月29日（火）の次回ワーキングチームにて対応方針を示す予定であるため、その際にご意見をいただきたい。

3.その他

• 特に議論なし

以上