本文へ移動

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

概要

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

  • 場所：オンライン会議

  • 議事次第：

  1. 開会
  2. 構成員の追加
  3. 議題
    ＜申請管理ワーキングチーム＞
    1.　申請管理に関する最適案意見の全体像と今後の進め方
    2.　申請管理に関する課題の対応方針に関する討議
    ＜データ連携ワーキングチーム＞
    1.　データ連携に関する最適案意見の全体像と今後の進め方
    2.　データ連携に関する課題の対応方針の説明
  4. その他
  5. 閉会

資料

関連政策

議事概要

日時

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

場所

オンライン会議

1.構成員の追加

  • 特に議論なし

2.議題

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

1.申請管理に関する最適案意見の全体像と今後の進め方
  • 特に議論なし
2.申請管理に関する課題の対応方針に関する討議

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

  • オブザーバ： エンドポイントとなるAPIは1つとし、ぴったりサービスの申請項目と基幹業務システムの管理項目の関係を整理すること自体には賛成する。その際、基幹業務システムは標準仕様書にて、保持できる管理項目が決められていることから、ぴったりサービスのプリセット項目か否かは整理に影響がないのではないか。逆に基幹業務システムの管理項目にあって、ぴったりサービスの申請項目にないものがあれば、ぴったりサービス側に追加する必要がある。そうすることで任意設定項目はなくなっていくのではないか。

    • 事務局： 基幹業務システムの管理項目として規定されている項目に関しては、取り込める必要があり、ぴったりサービスのプリセット項目はそれとの対応付けを行う。プリセットのない項目はこれから精査し取り扱いは検討、プリセットに追加することも含め対応付ける方向で検討を行う予定である。任意設定項目は、プリセット以外の項目は自治体が任意で追加可能であるため、一定程度存在する前提で取り扱いについて検討する。
    • オブザーバ： 任意項目の考え方が今後変わることを自治体にも周知する必要があるのではないか。任意項目をぴったりサービスで設定することは自由であり、申請管理機能における審査に利用することはできるが、基幹業務システムに取り組めないということとなる。基幹業務システムに取り組むデータは標準化されたので、自治体の裁量で追加はできず、追加して業務を行う必要がある場合は、独自施策システムにする必要があるということを合わせて整理が必要。
    • 事務局： ご意見を踏まえて、検討する。

  • 構成員： 現在、ぴったりサービスから申請ZIPを取得すると項目マッピングCSVがダウンロードされる。その中では画面入力項目名、様式独自項目名、APPLIC標準項目名、3つの項目間のマッピングされている。APPLIC標準項目名は、現状の地域情報プラットフォームの項目と認識しているが、今後基本データリストの項目名に置き換える予定か。申請データ照会APIの仕様書にもAPPLIC標準項目名も残っているが、実態としては基本データリスト項目名にあたると考えており、そこも今後検討してほしい。

    • 事務局： 承知した。APPLIC標準項目名は、現在のぴったりサービスの仕様通りに記載しているが、基本データリストの項目名への置き換えがあるべき状態と考えており、今後の検討に加える。

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

  • オブザーバ： 対応方針（案）の内容に「プリセット以外の項目と、基本データリストの管理項目として取り込むことを可能とする。」とある。「1.1.2.ぴったりサービスと基幹業務システムの項目対応の整理」と同様のコメントになるが、基幹業務システムの機能要件として規定された項目以外は取り込めない。ぴったりサービスの申請項目に追加してもよいが、申請管理機能の目視確認に利用するにとどめるか、独自施策システムへ取り込む必要がある点を明確にする必要がある。
    • 事務局： ご意見を踏まえて、検討する。

<2.1.3.オンライン申請全体の役割分担・流れの整理>

  • 構成員： 本サブ課題における整理において、形式チェック、形式審査、実質審査等が規定されているが、基幹業務システム側で実質審査を行うこととなっている。一方で、住民記録の標準仕様書では、引越しOSSの審査で却下や差戻しを行う機能は規定しておらず、内容を別の担当が確認する程度の規定となっている。今後、基幹業務システム側でも、却下や差戻しが必要となる場合、どのくらいのスケジュール感で規定されるか。

    • 事務局： 基幹業務システム側で審査した結果を機能的に申請管理に差戻しする機能は、役割分担（案）の図に記載している申請処理状況登録APIに該当すると認識しており、2025年度までの移行支援期間後の検討課題となる。移行支援期間の対応としては、現状横並び調整方針にて示しているとおり、基幹業務システムでの申請処理状況を、画面表示、または出力できればよく、その内容をもとに申請管理機能にて登録することを想定している。
    • 構成員： 了解した。

  • オブザーバ： ぴったりサービスでのオンライン化の重点対象は、市町村向けで26手続き、都道府県分も含めて31手続きあるが、オンラインでワンストップ申請になっていない手続きがいくつかあると認識している。介護保険の申請や妊娠届出などは対面手続きが厚生労働省で義務付けられており、結局窓口に行かないといけない。システムとしても、対面で申請書類を持参する場合等、同一手続きでもオンライン申請以外からの流入経路を想定する必要があるのではないか。また、オンラインでワンストップ申請できるように各府省庁へ働きかけていただきたい。

    • 事務局： 引き続き、制度所管府省庁と連携して対応する。

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

  • オブザーバ： 資料中の「申請データ照会APIを構築するまで実装猶予」とは、申請管理機能が申請データ照会APIを構築するまで、基幹業務システムの機能構築が猶予されるという理解でよいか。

    • 事務局： ご認識の通り。
    • オブザーバ： 2026年度以降は共通機能が標準化されるため、申請管理機能も実装必須になっていると思うが、猶予期間は2025年度中となるのか。2026年度以降も認めるとなると、申請管理機能の標準仕様を満たしていない申請管理システムを許す期間が存在することになる。
    • 事務局： 先ほど、API構築の猶予を申請管理機能がAPI提供するまでと説明したが、過渡期の期間をどういった範囲で定めるかは引き続き検討する。

  • オブザーバ： 「方式3、4を標準オプション機能にする」と記載があるが、すでに方式3、4として基幹業務システムに実装した機能を利用できるように、基幹業務システムの標準オプション機能とするという認識でよいか。

    • 事務局： ご認識の通り。標準オプション機能として、基幹業務システムに実装可能とすることを横並び調整方針にて規定する予定。
    • オブザーバ： 方式3、4を標準オプション機能とすると、「申請データ照会APIを構築するまでは実装を猶予」は不要ではないか。それとも、猶予ということで、方式3、4を利用する場合も最終的には申請データ取得APIも必要ということか。
    • 事務局： 後者の認識である。標準オプション機能とすることは過渡的な対応であるため、最終的には申請データ照会APIへの統一が必要であり、ご懸念の点が解消されるよう、横並び調整方針の記載は継続して検討する。
    • オブザーバ： 了解した。

  • 構成員： 基幹業務システムでの対応を改めて確認したい。基幹業務システムとしては申請データ照会APIの実装は必須であるが、過渡期は実装しなくてよい、ということか。その場合、申請管理機能は、方式1から4のいずれかを採用するが、基幹業務システムは申請データ照会APIを利用するなど、共通機能の連携方式と基幹業務システム側の連携方式が嚙み合わない場合があるのではないか。

    • 事務局： 過渡期的に方式1から4を利用する場合は、現在の総務省仕様に基づいて作られた申請管理システムであると想定しており、連携方式が嚙み合わないことは想定していないが、ご意見を踏まえ、整理がわかりにくい点は補いつつ、不整合のないように規定していく。
    • 構成員： 了解した。

＜2.1.5.差分データ取得仕様（「取得年月日」「取得対象時間」の明確化）＞

  • 構成員： 形式審査・年月日・時間をリクエスト項目として追加する点は、システムの改修が増えるため最低限に絞っていただきたい。次に、形式審査の年月日や取得年月日など日付関連の項目でリクエストした場合は、リクエストの期間がずれた場合に、取得できないデータが残る可能性があると考えている。また、申請管理機能からぴったりサービスにデータを取りに行くように未取得のデータがあれば取得するようなフラグをリクエスト項目にAPIに追加し、それを基幹業務システム側から指定した場合には、未取得のものを全部連携するとした方が、取得漏れが起きずよいのではないかと考えている。
    • 事務局： ご意見も踏まえて、検討する。未取得のフラグはあった方が望ましいと考えているが、情報提供依頼に記載したとおり、どのタイミングでフラグを立てるのか、という点はご意見いただきたい。何らかのエラーなど発生した時に、基幹業務システムに届いていないのにもかかわらず、申請管理機能側で取得済みフラグを立ててしまうという懸念がある。基幹業務システムで受領したことを申請管理機能へ通知して、取得済フラグを立てるなどもあるが、処理が煩雑になってしまう懸念もある。ぴったりサービスの方でも同様の機能があるため、その点も踏まえて最終的な方針を定める。

＜2.1.6.大量データの取扱い明確化＞

  • 構成員： 申請データの取得はAPIで実装するという方針が提示されているが、データ連携ワーキングチームでは全体的にファイル連携の対象が拡張される方向で検討されていると認識している。申請データ取得APIのみが残って、このAPIのためだけに認証機能などを準備するのが非常に難しいのではないかと考えている。他のデータ連携の方針ともあわせて検討いただきたい。
    • 事務局： 承知した。全体的なファイル連携、API連携の対象数も踏まえて引き続き検討する。

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

1. データ連携に関する最適案意見の全体像と今後の進め方
  • 特に議論なし
2. データ連携に関する課題の対応方針の説明

＜1.1.1.API仕様書の公開＞

  • 構成員： 個別のAPI仕様書は作成しないということになると思うが、API規定事項一覧には現在リクエスト項目名が日本語名だけは書いてある。パラメータ名や型や文字数など規定されたうえで提供していただけると考えてよいか。
    • 事務局： 「API規定事項一覧」には連携毎に可変となる事項（コール名やパラメータ）を記載している。「API連携に関する詳細技術仕様」には、共通的に規定するパラメータやデータ型や必須/任意などを規定しているので、当仕様にて必要事項に不足はないと認識している。
    • 事務局： 項目の日本語名以外の定義は「基本データリスト」にて規定しており、「API規定事項一覧」と併せて参照いただきたい。

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

  • オブザーバ： APIはPULL型となる場合、独自施策システムが受け取る#1は理解できるが、独自施策システムが渡す#2は業務的なユースケースが想像できない。また、基幹業務システムとして、コールする対象システムは機能要件、連携要件で規定されていることから、規定がない独自施策システムのAPIとして呼び出す機能の取扱いは別途整理が必要ではないか。仮に、#2があるとした場合、基幹業務システムに成り代わって、データを渡すことになると想定され、図示するとすれば、標準準拠システムの間に独自施策システムが入るのではないか。

    • 事務局： 現時点では、「独自施策システムが渡す」場合の具体的なユースケースを想定しているわけではなく、論理的に想定されることをもって対応方針を示している状態である。具体的なユースケースは精査する。
    • オブザーバ： 了解した。

  • 構成員： 横並び調整方針では、宛名管理システムを独自施策システムとして規定されているが、本サブ課題の整理が適用されるか。

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

  • オブザーバ： 後期高齢者医療制度の広域連合は、現状、市町村から宛名番号を含む住民記録情報等を受け取っている。その際、現行の住民記録システムはデータが統一されていないため、標準データに変換した上で連携している。今後、住民記録システムは標準化されるため、当該変換機能は不要になると想定されたものの、宛名管理システムが独自施策システムとして存続する場合には、引き続き変換機能が必要となると考える。

    • 事務局： 承知した。

  • オブザーバ： 教育関係の校務支援システムなど、現状では住民記録システムと学齢簿等のシステムのデータを統合して利用している場合について、標準化においてデータを統合してから渡すような新しいAPIを検討する想定はあるか。

    • 事務局： 想定はない。それぞれの基幹業務システムからデータを受け取り、宛名番号をキーに利用側のシステムにおいてデータを統合して利用いただくことを想定している。

＜1.2.2.リクエストパラメータの追加（1つ目）＞

  • 構成員： 庁内データ連携の全体方針の見直しを踏まえて、リスエスト項目の追加の必要性を改めて検討するとなっているが、スケジュールを教えてほしい。本年度末の改定に間に合う想定か。
    • 事務局： 庁内データ連携の大半をファイル連携とした場合、懸念が寄せられたIFについては、リクエスト項目を追加せずとも各基幹業務システム内の検索項目としていただくことで解消できると考えている。なお、APIとして残る場合には、業務固有のリクエスト項目の追加は年度末の仕様書改定に含める予定である。
    • 構成員： 了解した。

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

  • 構成員： 本サブ課題の対応方針（案）のすべてが強制力はないリファレンスであるとの認識でよいか。特に、 並行稼働を許容する版数は2世代とあるが、これも強制力がない認識でよいか。
    • 事務局： 基本的にはご認識の通り。一方で、ご意見のあった版数については、リファレンスとした場合、全体の整合性がとれないことも想定されるため、今後不整合にならないように規定を検討する。

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

  • 構成員： 「1基本データリスト利用する方式（※条件あり）」の条件とは何か。また、標準準拠システムと独自施策システムで連携する基本データリストは、制限なく連携が可能となるか。

    • 事務局： 個人番号利用事務でない場合、特定個人情報は連携できない。また、個人番号利用事務間のやり取りも含め、独自施策システムの事務の特性に応じて、基本データリストのどこまでの情報を利用できるかは、業務側の制度に照らして各自治体にて判断いただく必要があると考えている。

  • オブザーバ： 現状、基本データリストの出力ファイルは連携要件ではなく、移行用のデータ要件として規定したもの。日次で独自施策システムに連携するために全件を出力する点や、独自施策システム側がデータを取り込む際に全て更新する点など、各社が対応可能か懸念している。

    • 事務局： ご意見の通り、基本データリストは現時点ではデータ要件としての規定しかないため、連携要件として更新分となる差分連携が可能となるように規定する。その他必要な事項はご意見を踏まえて検討する。

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

  • 構成員： 複数パターンがリファレンスとして規定されると、連携の双方で認識齟齬が発生する可能性があり、結果として複数のIFを作らないといけなくなることが懸念される。原則は基本どうするのかを明記することはできないか。
    • 事務局： 現行システムで利用している既存IFを継続する場合（資料中#2）として規定しているため、ご意見を踏まえて、原則の対応方針を示す等検討とする。

3.その他

  • 特に議論なし

以上