機能別連携仕様において、ファイル連携が認められていない連携についても、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年間分のデータを取り込むため、大量データをAPIで連携することに懸念がある。大量データの連携は、基本的にファイル連携を想定しており、一部API連携で大量データを処理する場合は、各自治体とベンダにてタイムアウト時間等を設定いただくことを想定している。現状よりファイル連携の対象を広げる方向で検討している。データ取得件数・容量・タイムアウト値の上限設定」は、同じ課題に起因するため一緒に議論すべきと考える。上限値、データの取得件数制限は自治体ごとに状況が異なるため、外部パラメータで設定いただく想定である。検索条件で市町村コードのみ指定した場合など、エラーとなるようなリクエストパラメータのチェック機能は、ベンダごとに設計するのか。個別パラメータの制御を共通的に規定するべきか、ベンダごとの実装判断にまかせるべきかについては、皆様のご意見を賜りたいと考えている。レスポンスの総件数をチェックすることとし、個別パラメータでの制御を行わないことも選択肢となると考えている。データの取得件数の総数チェックを行う場合は、個別パラメータのチェックは不要と考える。アプリケーションの負荷を考慮すると、まずデータ取得件数をカウントし、取得可能な最大件数を超過していた場合は「超過エラー」とする実装が負荷は少ない。データの取得件数をチェックする機能とあわせて、データ取得可能な上限値を設けることも検討することとしたい。個別パラメータを活用して個人を特定した検索が可能、共通パラメータは個人を特定しない検索が可能という認識でよいか。住民記録システムとの連携にて異動分データを取得する場合データ量が多いため、リクエスト側でデータの取得件数の上限設定は難しい。よって、データの取得件数をチェックし、処理を継続するか、停止するかを選択させる方が望ましいと考える。ご意見を踏まえ検討する。他システムとのデータ連携が各事業者の実装に依存する状態はカスタマイズにつながる。連携テスト時に異動パターンの洗い出しやサンプルデータ作成を行うことになるため、仕様としてサンプルデータを提供いただいた方が開発を齟齬なく効率的に進められると考えている。具体的にサンプルデータが必要な箇所は、機能別連携仕様とあわせて各業務の標準仕様書も確認いただいた上で、不明瞭なところについてご意見いただきたい。事務局としてもサンプルデータの提供を検討する。遡及してデータを修正する場合、履歴番号は変更にならず、操作年月日が更新される認識で合っているか。ご認識の通り、操作年月日が更新される想定である。過去の履歴番号が変更されない場合、履歴番号は固定化した方が良いため、オール9ではなく最新フラグの保持をする形が方がよいと考える。