1 は第一選択肢であり、これで独自施策システム等の需要が賄える場合は問題ない。 一方で、1 の連携項目範囲は限定されるため、多様な独自施策システム等の需要を満たせるか の懸念が残る。 2 は範囲が広く、独自施策システム等の需要を満たせ可能性は高い。 一方で、基本データリストは本来システム移行用のフォーマットであり、読み込みの仕組みもシス テム移行時のデータセットアップツールとして構築されている。たとえ差分データになったとしても、 通常業務として業務 DB の更新に利用可能であるか懸念がある。 さらに、業務 DB の更新には職員の判断が必要な場合も多く、バッチ処理で単純に更新できる とは限らない。申請管理機能からの申請データ連携と同様に、登録画面に転記して職員が確認の 後、更新するといったフローも十分想定される。 現状においては、実現性は低いと評価せざるを得ない。 4 経過措置 独自施策システム等との連携は原則、外出し疎結合である。しかし、独自機能を除いては経過措 置規定が設けられている。よって、当面のあいだ一体的なシステムにおいては、独自施策システム等 と標準準拠システムが DB 共有その他、既存の方式での連携を維持することができる。 上記整理の通り、特に受信パターンでは多様な独自施策システム等の要求に応えられる連携方 式の提供が現段階では難しい。ここは、「一体的」の解釈を広めにとり、当面は経過措置を採用し て、連携方法を含めて独自対応を維持する必要があるのではないか。 その場合、独自機能だけに経過措置が適用されない状況は不都合である。これを改め、独自機 能においても一体的な提供と経過措置の適用を認めるように方針変更すべきではないか。 以上