本文へ移動

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

概要

  • 日時：令和4年（2022年）10月21日（金）14時00分から16時00分まで
  • 場所：オンライン会議
  • 議事次第：
    1. 開会
    2. 議題
      1. 検討概要
      2. API連携に関する課題
      3. ファイル連携に関する課題
      4. 移行期間におけるデータ連携に関する課題
    3. その他
    4. 閉会

資料

参考資料

関連政策

議事概要

日時

令和4年（2022年）10月21日（金）14時00分から16時00分まで

場所

オンライン会議

議事概要

1.検討概要

  • 特に議論なし

2.API連携に関する課題

＜1.1.3.PUSH型データ提供の追加＞

  • 構成員： 機能別連携仕様において、ファイル連携が認められていない連携についても、PUSH型APIが必要なものがあると考えている。更新の都度PULL型で取得するのが現実的ではないと想定している。
    • 事務局： すべての連携でファイル連携を規定するわけではないものの、現状よりファイル連携の対象を広げる方向で検討している。ファイル連携が規定されれば、PUSH型APIの必要性がなくなるという理解でよいか。
    • 構成員： ご認識の通り。
  • 構成員： ぴったりサービスから連携されるデータは基幹業務システムがPULL型でデータを取得することとなっていることもあり、基本的にPULL型APIで統一されていると理解しているが、PUSH型も今後検討対象とするのか。
    • 事務局： PULL型APIを原則として、各標準準拠システムが周期的に照会する形でのデータ連携を想定しているが、本検討会の中でPUSH型データ提供の必要性について議論し、ご意見を踏まえて検討対象とするかを考えたい。
  • 構成員： 移行期間に関する取り扱いとも関連するが、標準化前システムと標準化後システムの中間に配置する統合DB（連携基盤）に対してデータを連携する際はPUSH型APIでデータ連携を行うのか。
    • 事務局： 機能別連携仕様で規定している連携方式以外の連携は認められていないため、API連携の場合は、標準準拠システムが提供しているAPIを統合DB（連携基盤）がPULLする、ファイル連携の場合は、標準準拠システムが出力したデータを統合DB（連携基盤）が取り込む仕様となる。よって、統合DB（連携基盤）に対する連携をPUSH型APIで実現することは考えていない。
    • 構成員： 承知した。その場合、PUSH型APIは不要と考える。ファイルの取り込みバッチを実行中にPUSH型で更新データが届くと処理が難しいと考える。

＜1.1.8.レスポンス側システムのサーバ停止、バックアップ時の運用設計＞

  • 特に議論なし

＜1.1.9.API連携のDB負荷を考慮したリクエストパラメータの制御＞

  • 構成員： 税の年次処理では基幹業務システムが1年間分のデータを取り込むため、大量データをAPIで連携することに懸念がある。
    • 事務局： 大量データの連携は、基本的にファイル連携を想定しており、一部API連携で大量データを処理する場合は、各自治体とベンダにてタイムアウト時間等を設定いただくことを想定している。また、現状よりファイル連携の対象を広げる方向で検討している。
  • 構成員： 1.1.9.と「1.1.2. データ取得件数・容量・タイムアウト値の上限設定」は、同じ課題に起因するため一緒に議論すべきと考える。
    • 事務局： 上限値、データの取得件数制限は自治体ごとに状況が異なるため、外部パラメータで設定いただく想定である。
    • 構成員： 例えば検索条件で市町村コードのみ指定した場合など、エラーとなるようなリクエストパラメータのチェック機能は、ベンダごとに設計するのか。
    • 事務局： 個別パラメータの制御を共通的に規定するべきか、ベンダごとの実装判断にまかせるべきかについては、皆様のご意見を賜りたいと考えている。レスポンスの総件数をチェックすることとし、個別パラメータでの制御を行わないことも選択肢となると考えている。
    • 構成員： データの取得件数の総数チェックを行う場合は、個別パラメータのチェックは不要と考える。アプリケーションの負荷を考慮すると、まずデータ取得件数をカウントし、取得可能な最大件数を超過していた場合は「超過エラー」とする実装が負荷は少ない。
    • 事務局： 承知した。データの取得件数をチェックする機能とあわせて、データ取得可能な上限値を設けることも検討することとしたい。
  • 構成員： 個別パラメータを活用して個人を特定した検索が可能、共通パラメータは個人を特定しない検索が可能という認識でよいか。
    • 事務局： ご認識の通り。
    • 構成員： 住民記録システムとの連携にて異動分データを取得する場合データ量が多いため、リクエスト側でデータの取得件数の上限設定は難しい。よって、データの取得件数をチェックし、処理を継続するか、停止するかを選択させる方が望ましいと考える。
    • 事務局： ご意見を踏まえ検討する。

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

  • 構成員： 他システムとのデータ連携が各事業者の実装に依存する状態はカスタマイズにつながる。連携テスト時に異動パターンの洗い出しやサンプルデータ作成を行うことになるため、仕様としてサンプルデータを提供いただいた方が開発を齟齬なく効率的に進められると考えている。
    • 事務局： 具体的にサンプルデータが必要な箇所は、機能別連携仕様とあわせて各業務の標準仕様書も確認いただいた上で、不明瞭なところについてご意見いただきたい。事務局としてもサンプルデータの提供を検討する。

＜1.2.10.遡及修正時の連携仕様＞

  • 構成員： 遡及してデータを修正する場合、履歴番号は変更にならず、操作年月日が更新される認識で合っているか。
    • 事務局： ご認識の通り、操作年月日が更新される想定である。
    • 構成員： 過去の履歴番号が変更されない場合、履歴番号は固定化した方が良いため、オール9ではなく最新フラグの保持をする形が方がよいと考える。
    • 事務局： 承知した。

＜1.2.2.リクエストパラメータの追加＞

  • 構成員： 「異動分を取得するためのパラメータがあります」という記載は、操作年月日、操作時刻のことを指すか。データ連携された業務側が操作年月日、操作時刻を保持し、異動分を取得する際は、保持している操作年月日、操作時刻以降のデータを取得する必要があるのか。
    • 事務局： ご認識の通り。
    • 構成員： 以下3つの理由により、異動分データの取得が漏れる可能があるため、操作日時ではなく、シーケンシャルな番号での管理が望ましいのではないかと考える。
      • 操作年月日、操作時刻は秒単位での管理のため、ミリ秒単位でのデータの取得が欠落する可能性がある
      • 時間はサーバから取得するが、サーバ毎の設定時間がずれている場合がある
      • 操作年月日、操作時刻の記録の考え方がアプリケーションごとに異なることが想定され、またアプリケーション内で処理後、DBに書き込むまでにもタイムラグが生じる
    • 構成員： 操作年月日、操作時刻は、「職員が操作した時間」、「DBに格納した時間」のどちらを指しているか。認識齟齬が発生する可能性があるため、仕様書等に規定した方がよい。
    • 事務局： 仕様書等で規定する方向で検討する。
  • 構成員： 国保・後期・介護の場合は主キーに宛名番号がなく、他業務からのデータ取得が困難になるため、宛名番号を共通パラメータに追加した方がよい。
    • 事務局： 被保険者番号等がない場合に必要となると理解した。検討する。

＜1.2.3.API認可サーバの取扱い・設置主体＞

  • 構成員： 認証・認可において、認可サーバは誰が構築する想定か。
    • 事務局： ファイルサーバ同様に認可サーバの構築主体を規定していない。ファイルサーバのように認可サーバの構築主体におけるベースラインが必要な場合、ご意見を賜りたい。
    • 構成員： 自治体ごとに認可サーバを構築するのは非効率であるため、早めに方針を出していただきたい。国からID管理機能を提供するのであれば、早めに周知いただきたい。
    • 事務局： 国において公的機関統一ID基盤の構築等の取り組みがあることは記載しているが、提供時期は標準化の対応後となる見込みである。よって、標準化の対応においては、統一ID基盤の提供をされることは前提とせずベンダ・自治体の単位で認可サーバを構築していく必要があり、どのような単位で構築が望ましいか年内の検討会においてお示ししていきたい。

3.ファイル連携に関する課題

＜2.1.1.ファイルサーバの構築主体・配置の規定＞

  • 構成員： ベースラインを定めることは良いと考えるが、自治体として調達する目線で考えると、どのように調達するのかは悩ましい。ファイルサーバの提供は住民記録システムと一体ではなく、共通機能として提供するべきではないか。
    • 事務局： ご意見を踏まえて検討とする。
  • 構成員： 標準化するシステムの順序が自治体ごとに異なるため、最初に導入するシステムとセットでファイルサーバを構築するという考え方もあるのではないか。住民記録システムが多いと想定するが、その他の場合もあると考えている。
    • 事務局： ファイルサーバの構築を最初に導入するシステムとセットとする場合、どのシステム・どのベンダもファイルサーバを構築する可能性がある。
    • 構成員： マルチベンダになった場合は、初めに導入するシステムが連携を開始するため、初めに導入するシステムと共通機能をセットとして調達することも選択肢となると考える。

＜2.1.4.データ出力タイミング（日次／月次／年次）の規定＞

  • 構成員： 業務側の標準仕様書に、データ連携のタイミングが記されているため、仕様の見直し・追加等は不要と考える。
    • 事務局： 承知した。

＜2.2.2.ファイル連携における版数判断仕様の規定＞

  • 構成員： 構成員の意見は、仕様の版数の識別をする仕組みが必要ということではないか。回答にあるタイムスタンプでは連携仕様書の版数判断ができないと考える。
    • 事務局： 完了通知ファイルに記載する方針にて検討する。

＜2.2.4.権限付与の主体の見直し＞

  • 構成員： 考え方に記載されている、システム共通機能を担うベンダがいないケースというのは、自治体がファイルサーバを構築する場合を指すか。

    • 事務局： ご認識の通り。
    • 構成員： 一般的には、ファイルサーバの構築主体が権限付与を行った方がよいと考える。
    • 事務局： 各基幹業務システム側に権限付与機能をそれぞれ構築することが、非効率であるという考えに基づくご意見であるか。
    • 構成員： ご認識の通り。

  • 構成員： ファイルサーバの権限付与について、権限付与作業を行う提供側システムに対して、自治体内のどの部署が必要な権限を付与する想定か。その権限付与を行うのであれば、ファイルサーバにて集中的に権限付与を行った方がよいと考える。

    • 事務局： 自治体におけるファイルサーバの所管の話と、システム機能として、どのような仕組み・分担で権限付与を行うのかは分けて検討する必要がある。

4.移行期間におけるデータ連携に関する課題

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

  • 構成員： 「恒常的に設ける形も可能」と記載した意図はなにか。
    • 事務局： 統合DBは移行期間に限らず、移行期間終了後も引き続き利用する可能性も考えられるため、「恒常的に」と記載した。
    • 構成員： 承知した。
  • 構成員： 標準化後のシステムと標準化前のシステムが連携する場合、標準化前のシステムは、標準化後のAPI連携に未対応となると考えるが、具体的にはどのような対応をするべきなのか。
    • 事務局： 例外的に、標準化後のシステムに既存IF（標準化前のIF）を設け、標準化前のシステムと連携することが可能。
    • 構成員： 標準化後に新たに開始する連携はどのように考えればよいか。
    • 事務局： 標準化後に開始する新たな連携は、双方のシステムが標準化後に標準化後IFにて連携する整理である。
    • 事務局： 原則としては、標準準拠システムには標準化後のIFのみを設けることとなるため、標準化前のシステムに標準化後IFを設けることが基本的な対応となることを補足したい。一方で、自治体ごとの移行方法の事情を踏まえてその対応が難しい場合の対応として、既存IFを標準準拠システムに設けることも可能とするという整理である。
  • オブザーバ： 直接IFをもつ方式の場合、「標準準拠システム側に一時的にIF差異を吸収する変換機能が必要」とあるが、各業務の標準仕様書に機能要件を規定させる想定か。各業務の標準仕様書に規定させない場合、これはカスタマイズに該当すると認識している。カスタマイズを避けるための外付けシステムとして、変換機能を仲介する方式が良いのではないか。
    • 事務局： 標準化法第8条2項の必要最小限度の改変にあたるという整理ができないか等を検討しているところであり、標準仕様書に規定がなくても実装が可能となるように整理したい。

＜その他＞

  • 構成員： 今後開発を進めるにあたり、疑問点が発生すると予想されるため、ベンダからの質問に対しての回答窓口を設置いただきたい。
    • 事務局： これまでもAPPLIC構成員の事業者とは、GitHubでのコミュニケーションを行ってきているため、そこで継続的に回答することも考えられる。そういった対応も含めて、質疑対応の方法は検討したい。

5.その他

  • 事務局： 次回の申請管理ワーキングチームは11月1日（火）14時から16時を想定していたが、同日程でJ-LISフェアが開催されることを踏まえ日時を調整のうえ、改めて連絡する。

以上