本文へ移動

地方公共団体の基幹業務システムの統一・標準化に関する共通機能等技術要件検討会（第3回）

概要

  • 日時：令和5年2月1日（水）16時00分から18時00分まで

  • 場所：オンライン会議

  • 議事次第：

  1. 開会
  2. 議題
    • 継続検討課題の検討
  3. その他
  4. 閉会

資料

関連政策

議事概要

日時

令和5年2月1日（水）16時00分から17時50分まで

場所

オンライン開催

議事概要

1. 議題

1. 継続検討課題の検討

【継続検討課題に関する検討状況】
＜仕様書改定時にかかる並行稼動期間の規定方法（リファレンスでよいか）＞

  • オブザーバ： P4の「並行稼働の考え方」について、API連携は並行稼働期間が発生するため経過措置があると理解しているが、ファイル連携は並行稼働期間を想定していないため経過措置は不要ではないか。
    • 事務局： ファイル連携において並行稼働は想定していないという点はご認識のとおりであるが、新版数に基づくシステムの提供のタイミングは自治体毎に異なることが想定される。API連携のように1つの自治体内での新旧の連携の並行稼働ではなく、自治体全体をとらえた場合に、並行稼働を想定したものである。
    • オブザーバ： 承知した。

＜申請管理機能-基幹業務システム間の連携方式（申請データ照会APIを維持するかファイル連携に転換するか）＞

  • 構成員： P5の「申請管理機能と基幹業務システムの申請データの連携」について、申請管理についても、ファイル連携で実施する方針とした理由について説明いただきたい。

    • 事務局： 理由としては2つある。１点目は、庁内データ連携の全体方針として、リクエスト側のデータの提供を起点として、それに対するレスポンス結果を用いてのオンライン処理が必要となる連携等に該当する場合等においてのみAPI連携とする点と整合させたという点。もう1点は、当該連携においては添付ファイルも連携対象となるため、データ容量の観点でファイル連携の方が好ましいと考えられるという点である。
    • 構成員： 承知した。

  • 構成員： 申請データの添付ファイルについては、ファイル連携となったとしてもディレクトリが指定されて連携されるという理解でよいか。

    • 事務局： 現時点では、申請管理機能から基幹業務システムに連携する際、ぴったりサービスから取得した申請ZIPのまま連携するような形を想定している。格納先については、ファイル連携に関する詳細技術仕様書に記載のフォルダ構成や命名規則に沿っていただく想定である。
    • 構成員： 承知した。

＜共通機能における住民宛名番号を含めた宛名番号付番機能の規定方針（共通機能の実装類型、住民区分の更新仕様等）＞

  • オブザーバ： P7の「住民区分」について、「2：転出者」のまま残り、「X：住登外者」にならない場合もあると考えてよいか。

    • 事務局： 住民記録システム以外の基幹業務システムにおいて、住登外者として管理する場合に、「X：住登外者」に変更として更新する。

  • オブザーバ： P18の「住民区分の遷移図」において、「X：住登外者」に移った者が再転入した場合は、再転入者の候補者抽出は共通機能のデータで実施するという理解でよいか。

    • 事務局： 共通機能で住民宛名番号を付番する場合において、ご認識の通り。P18もその前提で記載している。一方で、住民記録システムの中で住民宛名番号を付番する場合には、住民記録システムのデータで候補者抽出を実施する。

  • オブザーバ： 戸籍や戸籍附票にのみ管理している方を住登外者として管理することは想定しておらず、従来通り、各基幹業務システムで管理が必要となったタイミングで住登外者として管理が開始されるということは変わらないという認識でよいか。

    • 事務局： ご認識の通り。現行の住登外者の定義を拡大することを意図したものではない。

  • オブザーバ： P18の「住民区分」について、「1：住民」と「X：住登外者」は排他関係にあると認識している。そのうえで、「X：住登外者」に変更となったもののなかに、「2：転出者」であった住登外者や、「3：死亡者」であった住登外者が混在することになり区別がつかなくなるが、区別は必要ないのか。住民記録システムの「住民状態」はそのまま保持しつつ、住登外者として管理されていることを別項目で管理する方がよいのではないか。

    • 事務局： 共通機能としては、住登外者であるかを管理できればよいと考えているほか、住民記録システムの「住民状態」との連続性をある程度確保する意図で、このような住民仕様の更新仕様（案）としている。
    • オブザーバ： 承知した。

  • 構成員： P7の「住民区分」について、転出者には、未来の日付を指定した転出予定も含まれると認識している。そのうえで転出予定状態であれば、厳密にはまだ住登者の扱いとなると考えている。転出予定の場合は、予定日の到来をもって転出者に変更することが正確ではあるが、システムのつくりとしては作りこみが必要となる。一方、住民記録システムからの異動情報にあわせて転出者に変更するだけであればつくりはシンプルになる。この点について、共通機能としてはどのように取り扱うのかは明示いただきたい。

    • 事務局： ご意見を踏まえて検討する。住民記録システムからの異動情報と整合させることとなると考えている。

＜住登外者の住所情報を履歴管理する上での更新の取り扱い及び運用フロー＞

  • オブザーバ： P8の「住登外者の本人確認レベル・方法の共通化に関する規定」に記載のとおり、本人確認レベルは業務毎の制度に関するものであるため、システムの標準仕様書に記載する内容ではないと考える。

    • 事務局： 標準仕様書に記載する内容ではない点は、同様の認識である。取り上げた経緯としては、住登外者の住所情報には、住基ネットで取得した情報や一時的な居所情報などが想定され、様々な本人確認レベルでの住所情報の登録が考えられることから、本人確認レベルに応じた運用を規定すべきではないかとの議論があったためである。
    • オブザーバ： 承知した。本人確認のレベルの共通化を意図したものではなく、住登外者の住所情報の精度の差異に着目した検討であると理解した。
    • 事務局： ご認識のとおり。

  • オブザーバ： P8の「本人確認」について、これまでの検討会において指摘した意図は、身元確認レベルに差異があることを想定して、機能整理いただきたいということである。現状の規定では２点の課題があると考える。1点目は、住基ネットで取得した住所の基本4情報が、信頼度が低いものも含めた最新情報に上書きされるという情報の精度に疑義がある点である。2点目は、1点目を前提に同一人の判断の精度にも差異が生じ、宛名番号自体の信頼性が揺らぐ懸念があるという点である。身元確認レベルを揃える、身元確認レベルに差異があることを前提に機能として対処を講じるということも考えられる。自治体向けには、身元確認レベルが異なる住所情報が登録され、それを前提に業務運用で対処する必要があることを、何らかの形での注意喚起を行うべきである。

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

  • オブザーバ： P8には、「住基ネットから受領した本人確認情報については（中略）慎重な対応が必要」という記載があるが、共通機能で、住基ネットで取得した本人確認情報を保持するのは、住基法別表に規定された事務以外が利用可能となるため、実態として登録は難しいと考えている。

＜住登外者の支援措置情報を管理する場合の制度面の整理及び運用フロー等＞

  • オブザーバ： P10の「個人情報保護法」について、支援措置情報の管理については、所管省庁にて解釈を示す必要があると考えているが、どのような想定か教えていただきたい。令和5年度から自治体においても個人情報保護の定義が統一され、自治体毎の取り扱いの差異は基本的になくなると考える。その前提において、所管省庁としての解釈は自治体に示す必要があると考える。
    • 事務局： 各省庁が解釈を示していただくことは妨げないが、全体の方針として各省庁から解釈をお示しすることについては、今後の整理とさせていただきたい。

【横並び調整方針に関する検討状況】
特に議論なし

【その他検討事項の検討状況】
＜基幹業務システムから独自施策システムのAPIを呼び出す連携方法の精査＞

  • オブザーバ： P12の④に「成り代わってデータを提供すること（統合DBを含む）が想定されることから」と記載があるが、記載の方法以外は採りえないと考えており、表現が正確ではないと考える。また、独自施策システムとの連携以外にも、標準化対象外事務、標準化対象外機能等は、標準準拠システムに対して疎結合で構築する必要があるため、それらもすべて含めて、現状の連携仕様の規定で十分なのか、整理・検討が必要であると考える。

    • 事務局： 表現が正確でない点はご指摘の通り。ご意見を踏まえて検討する。

  • オブザーバ： 独自施策システムが標準準拠システムにデータを提供する場合に、基本データリストの差分連携を利用することに懸念がないか、別途構成員に意見照会を行うべきではないか。

    • 事務局： 前回の意見照会において独自施策システムが提供する場合に明示的に絞った確認はできていない。改めて過去の意見内容を確認するほか、今後の仕様書改定のスケジュール等も踏まえ、再度構成員への意見照会を行うのか見極めることとしたい。

＜連携項目としての「削除フラグ」の要否＞

  • オブザーバ： P14の「削除フラグ」について、「連携済データ」はどのように識別するのか。連携データに何らかの識別番号の付与が必要ではないか。
    • 事務局： 対象のデータに削除フラグを立てて連携することを想定しているが、特定するための情報が不足する場合には、追加での規定を検討する。
    • オブザーバ： 承知した。

＜他業務連携のグループの基本データリストへの規定方針＞

  • 構成員： P14の②について他業務連携のグループを削除という記載があるが、EUC機能には、基本データリストにある項目を連携することとされており、他業務連携のグループが基本データリストから削除されるとEUCに連携できなくなるのではないか。
    • 事務局： ご懸念の点は認識しており、横並び調整方針を更新することを予定している。その際、他業務連携のグループに属する項目は基本データリストに規定がない場合もEUC機能に連携できる旨を追加する予定である。
    • 構成員： 承知した。

＜ファイル連携のクラウドサービスを利用したアーキテクチャ検討（オブジェクトストレージサービスを利用）＞

  • 構成員： P13の「ファイル連携の方式」について、基本的に提供元システムにオブジェクトストレージとして作成する旨が記載されている。これまで共通機能として、ファイルサーバを1つに設ける想定から方針変更になったという理解でよいか。

    • 事務局： ご理解のとおり。

  • 構成員： P13の「ファイル連携の方式」について、4CSPとの連携が実装必須機能となるのか。

    • 事務局： 4つのCSPとの連携を実装必須機能とするかについては継続して検討する。各CSPのオブジェクトストレージにアクセスする際のサンプルコードは提供する想定である。
    • 構成員： 承知した。

  • 構成員： P13の「ファイル連携の方式」について、双方がオンプレの場合にオブジェクトストレージの利用ができない場合があることを考慮すべきではないか。

    • 事務局： ご意見を踏まえて検討する。何らか対応方針についてご意見があれば伺いたい。
    • 構成員： これまでFTPやSFTPサーバー等を使った認証を想定していた。それらを使えばセキュアかつCSPへの依存もない形でファイル連携を実装可能と考えていたが、今後のクラウド利用の推進を見据えてオブジェクトストレージを利用するということであれば方向性について理解できる。双方がオンプレの場合の取扱いを含め、今後検討結果を共有していただきたい。
    • 事務局： 承知した。

  • 構成員： P14の「ファイル連携の方式について」の[ガバメントクラウドの場合実装必須]には、AWSの場合はIAMを利用するとの記載がある。自治体向けのガバメントクラウドの利用に関する説明資料では、IAMユーザーの払い出し権限はガバメントクラウド運用管理補助者が持つこととされていたと認識しており、その点と整合させた整理が必要であると考える。

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

＜標準仕様書で規定する管理項目とぴったりサービスのプリセットの対応関係の規定方針の見直し＞

  • オブザーバ： P15の②について、ぴったりサービスのプリセット項目に対応した標準準拠システムの管理項目の追加規定を行わない場合、どのデータ項目でも取り込めることになるため、自治体・ベンダ双方で苦慮する可能性がある。今年度中の対応が難しいとしても、いつまでに実施するかについては期限設定を行う必要と考える。
    • 事務局： ご指摘の通り、ぴったりサービスのプリセット項目と対応する管理項目が標準仕様書にすべて規定されたうえで、それらの対応表を提示することが望ましいと考えている。一方で、今年度中の仕様書改定のスケジュールにおいて、各制度所管府省に管理項目のすべてを見直しいただくのは現実的に難しい状況であるためご理解いただきたい。次年度以降の対応について、各制度所管府省と連携をとり、進めていく。

＜団体内統合宛名に関する仕様の取扱い明確化＞

  • 構成員： P16の①に「団体内統合宛名に関する仕様、中間サーバーとの接続仕様が不明確と考えられる点」について、J-LISと協議と記載があるが、協議結果を踏まえて、3月の仕様書改定に何か反映されると考えてよいか。
    • 事務局： ご認識の通り。基本的に共通機能仕様書内で完結する内容であり、中間サーバーの仕様書に影響を与えるものではないため、協議において方向性が変わることはないと想定している。

＜その他全体を通じて＞

  • オブザーバ： 共通機能仕様書の改定に関し、都道府県への適用をどうするかが重要な論点であると考える。一定の都道府県では団体内統合宛名機能を保持しているケースがあると認識している。
    • 事務局： ご指摘の点について検討を進めており、年度内の改定において方針を反映する予定である。ご意見があった団体内統合宛名などが利用されていることは把握しており、構築する場合は本仕様書に従っていただく方針で検討しているところ。ただし、都道府県の導入状況を把握しきれておらず、追加で調査を行う予定である。
  • 構成員： 文字要件については、いつ頃示されるのか教えていただきたい。
    • 事務局： 庁内で詳細検討中であり、年度内に方向性をお示しする予定である。別途情報提供させていただく。

2. その他

  • 事務局： 共通機能としての統合収滞納管理の要件について、昨年末の第2回検討会において、1月末時点で検討状況を構成員の皆様にお示しする予定をお伝えしていたが、現状では準備が整っていない状況にある。2月10日時点の状況を事前に共有させていただきたい。また、全国意見照会においては、機能要件、項目定義書、機能別連携仕様等の資料一式が揃った状態でご確認いただくことを予定しているためご理解いただきたい。