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

概要

• 日時：令和4年12月20日（火）10時00分から12時00分まで

• 場所：オンライン会議

• 議事次第：

1. 開会
2. 議題
   ＜データ連携ワーキングチーム＞
   1.　データ連携に関する最適案意見の全体像
   2.　データ連携に関する課題の対応方針の説明
   ＜申請管理連携ワーキングチーム＞
   1.　申請管理に関する最適案意見の全体像
   2.　申請管理に関する課題の対応方針の説明
   ＜宛名管理連携ワーキングチーム＞
   1.　宛名管理に関する最適案意見の全体像
   2.　宛名管理に関する課題の対応方針の説明
3. その他
4. 閉会

資料

• 議事次第（PDF／80KB）
• 資料1 データ連携WT_検討概要（PDF／770KB）
• 資料2 データ連携WT_データ連携に関する課題 （PDF／1,267KB）
• 資料3 申請管理WT_検討概要 （PDF／461KB）
• 資料4 申請管理WT_申請管理に関する課題（PDF／597KB）
• 資料5 宛名管理WT_検討概要（PDF／488KB）
• 資料6 宛名管理WT_宛名管理に関する課題（PDF／860KB）
• 資料7 データ要件・連携要件の今後の方針について （PDF／226KB）
• 資料8 データ要件の他業務情報グループの考え方について （PDF／227KB）
• 議事概要（PDF／196KB）

関連政策

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

議事概要

日時

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

場所

オンライン会議

1. 議題

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

1. データ連携に関する最適案意見の全体像

特に議論なし

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

<庁内データ連携の全体方針>

• オブザーバ： 今回Can Beをベースにファイル連携を基本とされることに賛同する。一方で、「公共サービスメッシュ等を見据えた」と記載があるが、公共サービスメッシュに関するAPI連携への影響についてスケジュール面を含めて確認したい。

  • 事務局： デジタル庁内の公共サービスメッシュ担当からファイル連携を基本とする方針について問題ない旨の回答を得ており、影響はないと考えている。

• オブザーバ： API連携の対象とする連携は検討中という説明があったが、具体的にどのような連携が対象になるか確認したい。

  • 事務局： 現時点で具体の連携をお示しすることができる段階にないため、追って提示することとしたい。

• オブザーバ： 「ファイル連携は、クラウドサービスを利用した構成とすることを検討」とは、具体的にどのようなものか確認したい。

  • 事務局： マネージドサービスであるオブジェクトストレージサービスを利用することを想定している。

• 構成員： ファイル連携をクラウドサービスの利用を前提に検討されるとの説明があったが、関連する認証認可サーバも一体的に導入・提供することが望ましい点について規定を検討いただきたい。

  • 事務局： ご指摘を踏まえて検討する。

• オブザーバ： 「庁内データ連携の全体方針」に関して、ファイル連携を基本とすることに見直す場合、API連携を基本としている標準化基本方針の見直しが必要となるのではないか。改定の方針があれば共有いただきたい。

  • 事務局： 基本方針についても、見直しの要否を精査する予定である。

• オブザーバ： ファイル連携を基本にすることは大きな方針転換となり、良し悪しはあると考えるが、これまでの検討がAPI連携を前提としていたサブ課題の対応方針の見直しが必要となるのではないか。例えば、独自施策システムとの連携仕様や、適合性確認の対応方針に関して見直しが必要ではないか。独自施策システムとの連携については、標準準拠システムが他の標準準拠システムからデータを受領する機能要件の規定はあるものの、独自施策システムから受領するような機能要件は規定されていない。規定がない当該連携を実装することは、カスタマイズに該当するのではないか。カスタマイズを許容しないという方針を前提として整理する場合、提供側の標準準拠システムに成り代わって独自施策システムがデータを提供する形にしかなりえないと考えている。

  • 事務局： 全体方針を受けた影響箇所の見直しは、ご指摘の通り必要と考えている。独自施策システムとの連携は、ご指摘を踏まえて改めて検討する。

• オブザーバ： 適合性確認については、API連携に対して点検するものであると認識している。ファイル連携になるとテストデータの準備も含めて対応が必要になるのではないか。

  • 事務局： 適合性確認についても、引き続き検討する。

• オブザーバ： API連携のバージョン管理、並行稼働について検討されているが、ファイル連携でも同様の検討が必要ではないか。

  • 事務局： ファイル連携のバージョン管理は、到達確認ファイルにバージョン情報含めることを本検討会にて議論した。並行稼働についても検討する。

• オブザーバ： 今後のAPI連携についてコメントしたい。マイナンバー制度及び国と地方のデジタル基盤抜本改善ワーキンググループ自治体タスクフォースにおいては、公共サービスメッシュを経由した団体間の情報連携が検討されている。国・他の自治体・民間企業に対し、自治体由来のデータが多く連携されることになると考えるが、具体的にどこにどのようなデータを連携してよいかを、制度として整理することが必要と考える。その点がタスクフォースで議論されていないと考えている。誰でもAPIをコールすれば無条件にデータが取得できるようにはならない点は明確にすべきである。

  • 事務局： ご指摘を踏まえ、関係所管省庁も含めて検討する。

＜1.1.5.標準準拠システム以外のシステムとの連携仕様＞

• オブザーバ： #1は理解できるが、#2は標準準拠システムAが標準準拠システムCも独自施策システムもコールはできないのではないか。基幹業務システムの機能要件はホワイトリスト形式の為、機能追加はできない。よって、標準準拠システムCと独自施策システムが並行している状態はあり得ないのではないか。
  • 事務局： 標準準拠システムAの標準仕様書に、独自施策システムから受け取るということが明示的に規定している必要がある。改めてケースを確認して検討していく。

＜1.2.3.API認可サーバの取扱い・設置主体（1つ目）＞

• オブザーバ： ファイル連携を基本とした場合でも、認可サーバの必要性は維持されるのか。
  • 事務局： 現時点では、API連携も残るため認可サーバは必要と考えている。クラウドサービスを利用したファイル連携の認証も含め検討を進めている。

＜1.2.9.異動パターン毎のデータ仕様及びサンプルデータの規定＞

• オブザーバ： サンプルデータの提供にあたっては、住民記録システムの標準仕様書の所管として事前にご相談いただきたい。
  • 事務局： 承知した。

＜1.2.12.仕様書改定時の旧版準拠APIの取扱い＞

• オブザーバ： 並行稼働期間の許容する規定を行うのであれば、法制的には並行稼働期間も同様に規定する必要があると考える。
  • 事務局： ご指摘を踏まえて継続検討する。

＜2.1.2.標準準拠システム以外のシステムとの連携仕様（①独自施策システム）＞

• オブザーバ： データ要件を基に出力するファイルを連携で利用するために差分連携を可能にするため、データ要件・連携要件標準仕様書を見直すことについて、2023年3月までに実施するか確認したい。

  • 事務局： 差分連携の規定は、データ要件・連携要件標準仕様書に規定していないため2023年3月に向けて、規定する想定である。

• 構成員： 独自施策システムとの連携に関して、統合収滞納管理システムとの連携は個別に機能別仕様書に規定される想定か、基本データリストでの連携対象に含まれるか、方針を確認したい。

  • 事務局： 統合収滞納管理システムに関しては、12月23日の第2回検討会にて今後の検討の方向性についてご説明する予定である。

＜3.1.1.移行期間におけるデータ連携のベースライン＞

• 構成員： 移行期間中のデータ連携のベースラインは、前提条件を補記すべきではないか。標準化前システムに標準化後のAPIを実装することは難しく、ファイル連携を対象にする等を想定している。
  • 事務局： リファレンスを規定するにあたり、考え方を補記するようにする。

申請管理ワーキングチーム

1. 申請管理に関する最適案意見の全体像

特に議論なし

2. 申請管理に関する課題の対応方針の説明

＜1.1.2.ぴったりサービスと基幹業務システムの項目対応の整理＞

• オブザーバ： プリセット項目と標準仕様書の管理項目の整合性の確認は年度内にかけて実施する認識か。
  • 事務局： 標準様式の見直し、項目間の対応表の精査は年度内を目途に進めていく予定である。

＜1.2.2.プリセットが規定されていない手続きの取扱い明確化＞

• オブザーバ： 標準仕様書の管理項目にあり、プリセット項目がない状況はあり得るのか。あり得る場合、自治体毎の判断が難しいのではないか。自治体によって、申請者に申請させるのではなく、自治体自ら別の手段で情報を取得する場合も想定される。

  • 事務局： 管理項目のうち、プリセットの規定がないものは今後プリセット化を検討する想定である。

• 構成員： 標準化対象かつプリセットが提供されていない手続きは、申請管理機能に連携する必要がないということか。

  • 事務局： ぴったりサービスからのオンライン申請全体のデータが申請管理機能を経由することと整理している。プリセットのない項目については自治体の判断において管理項目と対応させた上で基幹業務システムへ連携させる必要がある。

• 構成員： 庁内データ連携はファイル連携が基本となったが、申請管理機能と基幹業務システム間の連携がAPI連携を維持した理由を確認したい。

  • 事務局： ぴったりサービスと申請管理システムはAPI連携とされており、一貫性を持たせるため申請管理からの連携はAPI連携を維持することとした。

• オブザーバ： 各標準仕様書で管理項目の規定がある場合、プリセットがなくとも標準準拠システムに取り込み可能という認識でよいか。

  • 事務局： ご認識の通り。

＜2.1.7.総務省仕様準拠のIF利用の方針明確化＞

• オブザーバ： 申請管理機能と住民記録システム間の番号紐づけ情報の連携について、総務省仕様に基づくIFに関しては、申請データ照会APIと同様に、住民記録システム側は標準オプション機能として規定される想定か。
  • 事務局： ご認識の通り。
  • オブザーバ： 住民記録システムの標準仕様書で総務省仕様のIFは標準オプション機能となるとの考え方が共有されたが、既に番号紐づけ情報を申請管理機能に提供する機能を規定していることから、そちらの規定で現行の総務省仕様のIFの継続利用もできるものと解釈する整理でよいか。
  • 事務局： 基本的にはご認識の通り。

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

1. 宛名管理に関する最適案意見の全体像

特に議論なし

2. 宛名管理に関する課題の対応方針の説明

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

• 構成員： 共通機能の一元的な付番機能を実装必須機能とすることによって、開発スケジュールへの影響が見込まれるほか、住民記録システム側の標準オプション機能を含めて、事業者内でどのような方針とするかの検討にも時間を要する。共通機能に住民宛名番号の付番機能は追加せず、住登外宛名番号の付番のみとする案を改めて提案したい。

  • 事務局： 共通機能の標準仕様書はホワイトリスト形式ではないため、基幹業務システムの標準仕様書とは取り扱いが異なり、標準オプション機能を規定していない。共通機能の標準仕様書における規定については、継続検討する。

• 構成員： 同様に、開発スケジュールへの影響があると考える。また、移行にあたっての住登外者宛名番号の重複排除の対応にも時間を要すると考えている。住登外者宛名番号管理機能で付番した番号は、各基幹業務システムで利用することになると理解しているが、日々の業務の中で別の宛名番号を付番せずに同じ宛名番号を利用できるのは実際のところマイナンバーが確認できた場合のみになるのではないか。標準化対象20業務の中で、マイナンバー利用事務以外の業務がどのくらいあり、また、マイナンバー利用事務以外の事務における住登外者宛名番号の一元管理の必要性がどの程度あるのかを踏まえて、改めて共通機能としての利用の必要性を検討すべきではないか。

  • 事務局： ご意見を踏まえて継続検討する。

• 構成員： 2025年の移行期限を見据えると開発だけなく、データ移行等のセットアップ・適用への影響を踏まえた判断が必要。住民を含めることによる検討や、適用におけるリスクも大きくなると考える。

  • 事務局： 一元的な付番機能の必要性は本検討会で示した対応方針であることも踏まえ、ご意見を踏まえて継続検討する。

• オブザーバ： ご発言がなかった事業者についても、開発スケジュールへの影響は会議後も含めて、ご意見いただきたい。2025年度までの移行期限までの移行スケジュールへの影響を懸念しており、移行が間に合わないのであれば議論の意味がなくなってくる。住民については住基法1条、2条で規定されているとおり、住民基本台帳で管理を行うところ、住民記録システムの外で宛名番号の一元付番を行う意義は何なのか、何の為のワンスオンリーなのかを明確にする必要がある。後続のサブ課題も含めて共通機能で持つ機能が膨らむ場合、例えば情報政策課が所管することが基本かもしれないが、自治体内での所管部署についての整理も必要であり、また、費用負担等の問題もある。自治体向けの説明のためにも、一元的な付番の意義は改めて精査をお願いしたい。

  • 事務局： ご意見を踏まえて、メリット・デメリットについて継続検討を行うほかスケジュールへの影響は、会議後改めてご意見をいただくこととする。

• オブザーバ： 一元的な付番のメリットが整理されていないように感じている。番号の付番重複を避けるだけが目的であれば、住民と住登外者で付番ルールを分けるだけで充分であり、付番機能を一体化させる必要まではないのではないか。

  • 事務局： 現行システムでの一元的な付番を実現している事業者が存在していることにも配慮した規定である。
  • オブザーバ： 現行システムと同様のことができるようにするという配慮はあってしかるべきであるが、配慮の問題と全体に実装必須機能として義務的に求めるのは違うのではないか。
  • 事務局： ご意見を踏まえて、検討する。
  • オブザーバ： 一元的な付番機能の議論は、付番の重複を避けるのでなく、住登外者を含めたワンスオンリーの実現のためのものと理解している。住登外者が転入する際に、過去に住登外者として管理していたことを気が付くことができる運用フローがあれば、一元的な付番までは必要ない可能性もある。
  • オブザーバ： どこまでワンスオンリーが求められるのかという観点でも検討が必要である。例えば住登外者の転入時に固定資産税等の情報を自治体が把握しておくことについて、転入者目線で好意的に捉える場合と、そうではない場合もあると想定している。そのあたりの議論が必要ではないか。
  • 事務局： ご意見を踏まえて、運用フローの整備も含め継続検討する。

• 構成員： 共通機能での一元的な付番機能に関して、2025年へ向けた開発対象となるとした場合、今後の方針として機能自体が不要になったり、追加対応が必要となったりする可能性もあるのではないか。不確定要素が残るのであれば、手戻りの可能性もあるため、実装必須機能とはしないことも含めた検討が必要ではないか。

  • 事務局： 将来構想と実装必須機能との整合性は検討する。

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

• 構成員： 「文字コードの取り扱い」について、住民記録システムは文字情報基盤の文字コード、基幹業務システムは縮退マップを用いると標準仕様書上は規定されているが、それ以外の取り扱いへの見直しを検討しているのか。

  • 事務局： 詳細は12月23日の第2回検討会でご説明する。

• オブザーバ： P.11において、居所も含めて登録するような記載となっているが、住民票記載住所を確認できている中で、居所情報で更新してよいのかはもう少し運用も含めて精査が必要ではないか。

  • 事務局： 履歴管理や登録方法について精査していく。

• オブザーバ： 住登外者の過去の住所らしき情報を履歴情報として積み上げて管理するという認識でよいのか。住民が住登外者になった場合には住民であった履歴も含めて管理するのか、あくまで住登外者としての管理のみなのか。一元管理をするとなると新たな所管部署が必要となる。将来的に、宛名情報だけでなく、DV等の支援措置対象者の情報管理も追加することになれば、より厳格な管理が必要となり、追加の運用フローなどが必要となると考える。

  • 事務局： 共通機能での履歴管理の対象は、あくまで住登外のみを想定しており、再転入後については住民記録システムの管理対象となり、共通機能としての管理対象外になると考えている。

• オブザーバ： 住民票記載住所について、住基ネットを利用できるのは住基法別表で規定された事務のみであるため、その他事務でも利用できるような誤解を与える記載は行うべきではない。住登外者の識別子としての基本4情報は確認のレベルが異なっていたり、業務によってすべての情報が得られないケースもあったりすることも想定され、本サブ課題の方針によって、それらの運用を揃えるべきであるとのメッセージに捉えられないような記載にすべきと考える。

  • 事務局： ご意見を踏まえて、誤解のない表現に見直す。

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

• 構成員： 「住民宛名番号の付番も含む一体的な付番用APIに一本化する方向で検討」とは、団体内統合宛名番号と宛名番号の付番APIを一本化する認識でよいか。
  • 事務局： ご認識の通りである。住登外宛名番号管理と団体内統合宛名番号を一体的に構築する場合には、それぞれのAPIを呼びだすなど、現状規定済みのAPIではフローが煩雑になることが想定されるため、APIを一本化する方向で検討している。
  • 構成員： 団体内統合宛名番号の付番は、運用フローでも基幹業務システムから対象者の情報を連携し、単純に付番して基幹業務システムに連携するだけであると認識している。一方で、住登外者宛名番号の付番は、まず候補者の検索を行ってから登録するまでいくつかのやり取りが運用フロー上想定されているため、一体化するイメージが湧きにくく感じた。住登外者宛名番号の付番も団体内統合宛名番号の付番のように運用フローを単純化することも含めて検討いただきたい。
  • 事務局： 候補者を検索する運用フローは一定程度残ると想定しているが、ご意見も踏まえて継続検討を行う。

＜1.1.4.住登外者の支援措置対象者情報の一元管理＞

• オブザーバ： 取り扱いについては、移行支援期間後の対応となると考えるが、支援措置情報は機微な情報にあたるため、関係府省庁踏まえて制度面での検討をお願いしたい。要望や質問が多く、方向性を示さざるを得ない状況は理解できるが、ベースラインとして示すのであれば、それが制度的に問題ないのかという議論が必要と考える。場合によっては個人情報保護委員会との調整も必要となる可能性もあるため、十分な検討が必要と考える。
  • 事務局： ご意見も踏まえて、資料の位置づけを含めた継続検討を行う。

＜1.2.3.住登外者宛名番号管理機能の任意化＞

• オブザーバ： 経過措置として、共通機能の導入前に標準準拠システムを導入する場合には、独自の住登外者の宛名番号の付番機能を保持してよいという理解でよいか。

  • 事務局： 2025年度末の移行支援期間まで住登外者宛名番号管理機能へ移行できれば、それまでに独自の付番機能を個別に保持していたとしても標準化基準へ適合しないという整理にはならないと考えている。
  • オブザーバ： 一定の経過措置を用意していると理解した。法制的にもう少し詰めた方がよい。
  • 事務局： いただいたご意見を踏まえて、継続検討する。

• 構成員： 住登外者の登録において、基幹業務システムから住登外者宛名番号管理機能に照会することが基本であると思うが、宛名管理システムで住登外者宛名情報を検索してもよいか。

  • 事務局： そのような利用ケースもあると想定している。

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

• 構成員： 住所地特例に関する連携についての検討状況を確認したい。
  • 事務局： 検討中につき、別途回答を提示する。

＜2.1.2.宛名番号（住登者・住登外者）の付番方針明確化＞

• 構成員： 住民区分の変更には業務色があるため、パターンごとの運用フローが必要となると考えている。仕様としての規定はいつを目指して実施するのか。
  • 事務局： 年度末の仕様書改定に合わせて規定する想定であるが、共通機能において一元的な付番機能を設けるのかという論点とも合わせ、全体のスケジュールを踏まえ要否について継続検討する。

＜2.1.6.住登外者宛名番号管理機能における履歴管理の仕様規定要否＞

• 構成員： 論理削除が必要かどうかの判断は何をもってするのか。基本データリストにも論理削除フラグを追加するのか。また、作業の流れとしては、各機能要件に論理削除が必要かを追記した上で基本データリストおよび機能別連携仕様書に反映する流れか。すべてのIFに論理削除のフラグを付けることに懸念を示すベンダもいると想定している。
  • 事務局： 基本データリスト及び機能別連携仕様に追加する方針で検討している。

2. その他

データ要件・連携要件の今後の整理について

特に議論なし

データ要件の他業務情報グループの考え方について

特に議論なし

以上