自治体システムにおけるAPI連携 その２
モグです。お疲れ様です。
自治体システム標準化における「連携要件を考える」シリーズです。いよいよ触れたくない、でも触れないわけにもいかない領域に差し掛かってきました。まともな結論、というより課題提起になるかどうかさえわからないのですが、現場感覚から情報発信することに意味があると信じたいという気持ちは変わりません。
シリーズの軽い振り返り
前回までの考察で、以下のようなことを述べてきました。
現在の標準仕様では、本来の目的である相互運用性は達成できない。
達成できるのは、インタフェース形式の統一までであり、相互接続性については、事業者間調整により確保することとなった。
連携要件を整備するにあたっての当初方針の中には達成できていないものがいくつかあり、その中の一つにAPI連携がある。
標準仕様の中に僅かに残存しているAPI連携について、その記載レベルは、一般的なガイドライン等を踏まえても十分である。
API連携における要件（使われるシーンや制約事項等）が十分に詰まっているとは言えない。
議論の中では特に踏み込んでいませんが、技術的な観点からは、世の中にWebAPIが広く普及していることを踏まえると、API連携を連携要件の主たる方式とすることについて、致命的な課題はないのではないかと考えています。この領域特有の事情や歴史的経緯による、APアーキテクチャ面からの制約があったり、ガバメントクラウドを利用することによるなんらかの課題（特にマルチCSP環境における課題については、多くの方がご指摘されているとおりです）があったりするのかもしれませんが、そういったことはそこまでクリティカルな問題ではなく、時が解決するようなところもあるのではないかと思っています。もちろん、いわゆる移行期限までにそのような状態になるわけではなく、次のステップでしっかりと検討し、標準仕様を定め、課題を解決したうえで、実装していくものだと考えています。
データ連携のユースケースと連携方式
データ連携は、どんなときに必要なのか？
では、さっそくAPI連携を念頭に置きつつ、データ連携ってそもそも何のために必要になるのか、ユースケースを考えてみましょう。
ここでは、Ａ業務からＢ業務にデータ連携が必要な理由となり得るものを、できるだけ抽象化して考えてみましょう。以下の３ケースに収斂するのではないでしょうか。
１．Ｂ業務として管理すべき項目があるが、当該項目の発生源はＡ業務である（Ａ業務にて住民からの届出を受け付ける項目、Ａ業務での業務ルールにより生成される項目等）
２．Ｂ業務の業務ルール上、参照すべき項目がＡ業務にて管理されている（資格要件の判断、Ｂ業務における演算時に必要な数値、資格重複の確認等）
３．Ｂ業務の業務運用上、参照することが望ましい項目がＡ業務にて管理されている（窓口での相談時の参照等）
どれも似ていますが、１はＢ業務としてその項目を管理しなければいけない状態を指します。もう少し具体的に書くと、Ｂ業務でその項目を管理すべき法的根拠がある状態をイメージしています。一方で、２はＢ業務としてその項目を管理すべき法的根拠はないものの、業務の運用上、当該項目を参照する必要がある状態をイメージしています。
ただし、本来の意味では２であっても、すなわちＢ業務でその項目を管理すべき法的根拠がなかったとしても、たとえばほとんどその都度当該項目を参照しないことには業務が運用できない等、実装上の理由で１のような扱いとなっている項目もあるのではないかと想像しており、ここではあるべき姿として１として取り扱った方がよいのかなと思います。
さらに、３はＢ業務のシステムでその項目を参照できなくてもよい状態（極端な話、Ａ業務とＢ業務の画面を両方見ればよい状態）をイメージしました。
pushか、pullか
まず、pushかpullかという話をします。
端的に言うと、１のケースは、push型の連携が必要になると思います。Ａ業務でデータが更新されたとしたら、なんらかのタイミングでＢ業務でもその情報を管理できるようにしないといけないからです。もちろん、実装上は、Ｂ業務側からのトリガ（たとえば毎日夜間とか）により、Ａ業務からpushという形でもよいです。
なお、現在の標準仕様で定めているファイル連携は、push&pull(連携元側は庁内データ連携の標準仕様にて定められたフォルダに格納し、連携先側がそれを取りに来る)ですが、ここではpushとして分類しています。
２のケースは、pull型の連携がよさそうですね。必要な時に必要な情報が取得できればよいのです。行政の事務には、締め日的な概念（確定賦課、本算定など）があるので、pullはpullでも全件が対象になるようなケースはありそうです。
３のケースは、乱暴ですがこの議論では無視しましょうか。関連業務システムとして両方の情報を表示する画面を作るもよし、マルチウィンドウで運用するもよし、というところです。
余談みたいな話になりますが、１のケースの派生形として、トリガ情報だけをpushして、pullで情報の中身を取得するという考え方もありますね。若かりし頃、汎用機でシステムを提供していたこともありますが、その時（なんの要件だったか忘れました。税の異動累積ファイルをもとに福祉側の何かの要件を満たすような感じだったかと）は先輩方にそういう考え方で設計すべしと教えていただいた記憶があります。要は、情報提供側システムで、何かしらの異動が発生した場合、キー情報＋αをpushで連携先に連携し、連携先は必要なタイミングで、そのキー情報を元に最新の情報を情報提供側システムに取りに行く（pull）というやり方です。これは、恐らくですが、情報提供側システムで異動情報をファイルで連携するにあたって、そのサイクルが長い（月次とか）場合を考慮していたのではないかと考えています。月次で異動情報が連携されても、そこに含まれる対象者が、さらに何らかの異動をしていた場合は、最新の情報を取得した方が、業務運用的によりよいということなのかと思います。業務データの更新と違って異動累積に含まれている更新情報はアテにならない（バグがあってもあまり気づかない）から、トリガとして使うのはよいが、更新情報の中身は信じてはいけない、という裏事情もあったかもしれません。
あと、この方式は、ファイルの容量を減らせる（連携先が必要ない項目は連携しない。）という点にメリットがある気はしますね。
API連携か、ファイル連携か
次に、API連携か、ファイル連携か、という話です。どちらの連携方式でも、理論上はpushもpullも可能ですね。
が、世間一般的にいうとAPI連携は、pull型で設計するのではないでしょうか。標準仕様でも、元々はpull型データ提供のみを対象としていました。この件は、共通機能等課題検討会におけるWTでも以下のような意見がありましたが、push型の必要性については別の回で触れたいと思います。
https://www.digital.go.jp/councils/local-governments-common-features-datalinkage-wt
送信先システムがシステム障害やメンテナンス中の場合にデータ連携できないことを理由に、PULL型データ提供のみをAPI連携 の方式として規定していますが、構成員からは業務特性を応じてPUSH型（データ配信）の必要性について意見が寄せられました
ファイル連携の方は、push型の方が一般的ではないでしょうか。ファイルなので、ある時点断面における条件に合致した対象レコード、もしくはある時点からある時点までの期間にタンキングされた対象レコードが含まれることになります。標準化対象業務の要件的には、どちらかというと、後者の方が多いのではないでしょうか。実際、標準仕様書には「ファイル連携の場合は、原則、差分連携とする」と記載されており、時点断面における対象レコードではなく、時点間の対象レコードを対象として連携するべしと書かれています。そうした場合、pull型で連携するのは感覚的にも危険な気がしますね。pullだと、たとえばデータを提供する側のシステムに、遡及異動が発生していた場合、範囲を指定して正しく必要なレコードを抽出するのは難しい場合がありそうです。それよりも、データ提供側のシステムに、責任をもって出すべき範囲のレコードを抽出して、ファイルとして提供してもらった方が安心ですね。そして、そのファイルの中で、レコードの順序性等を担保するために「履歴番号」「最新フラグ」「削除フラグ」という項目を管理するようにしようという議論になったのですね。
まとめると、pull型のAPI連携と、push型のファイル連携で構成するのがよさそうに思います。あと、敢えて前述の余談で書いた話を活かしますが、pushで「異動が発生したことのトリガファイル」のみを連携して、あとは必要な側がpull型のAPIで取得するという方式を組み合わせてもよいかもしれません。
全件か、差分か
まず、API連携については、差分という概念はないと思います。２のケースが発生した際に、pull型で対象とする全件を連携（参照）することになります。対象は1件かもしれませんし、文字通り全件かもしれません。
ファイル連携については、前節に記載したように、基本的には差分の方が多いと思います。ただし、業務的に意味のあるタイミングにおいて、敢えて全件取得するような要件はあると思います。選挙における定時登録、選挙時登録など、継続的な差分更新により要件が満たせないことはないと思いますが、このタイミングで住民基本台帳のデータをもとに、全件の選挙人名簿を作成する意味はあるように思います（制度的な背景もあるのかもしれません）。また、発行抑止情報のように、過去の履歴などよりも、とにかくその時点の最新情報に意味があるものについても、定期的に全件を連携することには、一定の合理性があるように思います。
結局どうするのがよいのか
個人的には、API連携を基本とするAPIドリブンな世界観には賛同しますし、エンジニアとしても興味があります。
しかしながら、現時点の標準化対象業務においては、前述のとおり、その要件に応じて、pull型のAPI連携と、push型のファイル連携を使い分けるのが得策なのではないでしょうか。どちらをどう使うかは、冒頭の方でユースケースを抽象化しながら、考え方を整理しました。それぞれ業務要件としてどうなのかを明らかにしたうえで、適切に決めていけばよいことだと思います。
そして、ファイル連携を使う場合は、連携要件だけを精緻化するのではなく、連携元先業務の要件を精緻化する必要があることは、以前のNoteでも触れたとおりです。各業務での履歴の考え方、遡及の考え方などを整理せずして、ファイル連携を前提とした相互運用性の確保はできません。「各事業者の実装に依存する領域だから規定しない」というのは、短期間で仕様を整備するためにはやむを得ない判断だと理解していますが、中長期的に見れば規定するしかないと私は考えています。データと業務ルールはしっかり統一して、ワークフローやUIが、事業者の競争領域でもあり、各団体としての特徴を出す領域でもある（事業者と団体の共創領域かもしれない）という世界を目指すべきではないでしょうか。
もし、「いやいやファイル連携など過去の遺物であり、とにかくAPIドリブンな世界観にしていくのだ！」ということであれば、制度的な拘束力を持つ締め日のような概念をなくすことも一つにはある気がしますが、それよりもまずは１のようなユースケースをなくしていくことが必要だと思います。これは、各制度における管理項目の最適化、正規化そのものですね。
考えてみれば、そうなってくると、同じ項目なのにシステム間で意味が違うとか、面倒なデータ連携の調整ごともなくなるわけです。管理元の業務で管理されている項目（項目の意味も、曖昧にするのではなく、きっちり定義すべきであることは言うまでもありません）を、必要な時にAPIで参照して、それをそのまま使うだけの話なので。そして、そういう形で整理できるのであれば、「Rule as Codeで誰一人取り残さない社会を！」というキーフレーズも現実味を帯びてくると思うのです。
そういう世界を作るまでは現役でいたいものです。
今回は、いきなり将来形の話まで持っていってしまったので、次回は共通機能等課題検討会にて議論されたデータ連携に関する各種の課題について、振り返り（思い出し）を含めて掘り下げてみたいと思います。