【ITニュース解説】Parsing Public Data: What Happens When Municipal APIs Break

公共のデータ、例えば交通機関の運行情報や地方議会の投票記録、公共支出のデータベースなどは、私たちの生活を支える多くのサービスやアプリケーションの基盤となっている。住宅情報を追跡するアプリから大気の質を監視するシステムまで、その用途は多岐にわたる。しかし、これらの公共データは、一般的な商業サービスが提供するAPIとは異なり、非常に不安定で扱いにくいという現実がある。システムエンジニアを目指す上で、このような現実を理解し、それに対応できる設計と実装のスキルを身につけることは極めて重要だ。

公共データのAPI、つまり外部のシステムがデータを利用するための窓口は、往々にして予期せぬ問題を引き起こす。例えば、ある朝午前4時に突然、交通機関のAPIから地図の座標情報を示すフィールドが消えてしまうといった事態が起こりうる。このような変更があった場合、データを取り込むためのスクリプト（プログラム）が設計が不十分だと、システム全体が停止し、重要な通知サービスまで機能しなくなる可能性がある。商業目的のAPIに対しては、我々は何週間もかけて堅牢なデータストリーミングの仕組みを構築するが、政府機関が提供するデータフィードは、まるで一度作成されたら変わらない静的なCSVファイルのように扱われがちだ。しかし、その背後にあるインフラは非常に脆いということを認識しなければならない。

市議会の投票記録や支出データベースといった公共のデータを扱う際には、具体的な困難がいくつも伴う。データの構造を示す「スキーマ」は頻繁に変更されることがある。これは、例えば古いバックエンドシステムで誰かがフィールドの名前を一つ変えただけで起こりうる。また、APIの利用回数を制限する「レート制限」が予告なく導入されることもある。これは、そのAPIを動かしているサーバーが、古いハードウェアのままオフィスの片隅に置かれているような状況で突然発生する。さらに厄介なのは、システムが定期的な再起動中に、本来ならデータの塊であるJSON形式ではなく、HTML形式のエラーページを返してしまうといったケースだ。もしデータパイプラインが常に一貫性のあるデータが提供されると仮定して設計されている場合、このような予期せぬ状況に直面すると、簡単に機能不全に陥ってしまう。

このような問題を解決し、堅牢なデータパイプラインを構築するためには、「すべてのデータは信頼できない入力として扱う」という考え方が基本となる。外部からやってくるデータは、常に壊れている可能性があると想定するのだ。データがシステムに入る「境界」で、厳格なスキーマ検証を行う。つまり、データが期待する形式や構造に合致しているかを厳しくチェックする。もし形式が正しくない「不正なデータ」が見つかった場合は、それをシステムの下流にある重要なデータモデルに悪影響を与える前に、「デッドレターキュー」と呼ばれる特別な場所に隔離する。これにより、不正なデータが後続の処理を汚染するのを防ぎつつ、後でその原因を調査したり、手動で修正したりする機会を残すことができる。

また、データを取り込むスクリプトは「冪等（べきとう）であること」が求められる。これは、例えば遅延した税評価バッチのデータを取得するスクリプトを誤って二度実行してしまっても、データベースに重複したエントリーが作成されないようにする設計のことだ。同じ操作を何度行っても、システムの状態は一度実行した場合と同じ結果になるという特性である。このような「防御的なプログラミング」は、公共データを扱う上での基本的な要件となる。

具体的なコードで考えてみよう。Python言語を使ったデータ取得と解析のルーチンは、予期せぬデータの変更があってもプログラムがクラッシュしないように設計できる。まず、requestsライブラリを使って指定されたURLからデータを取得しようとする。この際、ネットワーク接続の問題やサーバーからの応答がない場合に備えて、try-exceptブロックを使いrequests.exceptions.RequestExceptionというエラーを捕捉する。これにより、ネットワークが一時的に切断されたり、サーバーがダウンしていたりしても、プログラムが突然終了するのを防ぐことができる。

次に、サーバーからのHTTP応答ステータスコードを確認するresponse.raise_for_status()を呼び出す。これは、例えば「404 Not Found」や「500 Internal Server Error」といったエラー応答を受け取った場合に、例外を発生させてその状況を知らせるためのものだ。これにより、正常なデータが返されなかったことを早期に検知できる。

さらに、Content-Typeヘッダーをチェックし、応答がapplication/json形式であることを確認する。これは非常に重要だ。前述したように、APIがエラーページをHTML形式で返すような場合、JSONとしてパースしようとするとエラーが発生し、プログラムが停止するからだ。もしJSON形式でなければ、エラーとしてログに記録し、そのデータを処理しない。最後に、response.json()を使って受け取ったデータをJSONとして解析する。ここでも、データが破損しているなどでJSONとして解析できない場合に備えてjson.JSONDecodeErrorを捕捉し、不正なJSONデータが原因でプログラムがクラッシュするのを防ぐ。

これらのチェックは、予期せぬメンテナンス画面が表示されたり、サーバーが一時的に誤ったデータを返したりしても、データパイプライン全体が停止するのを防ぐのに役立つ。コードの背後にある私たちの仕事は、単にプログラムを書くだけではない。公共データのパイプラインが壊れると、開かれた政府に対する市民の信頼が損なわれるという、より大きな意味を持つ。そのため、商業システムのコアな監視と同じ厳格さで、これらのデータ取り込みジョブを監視する必要がある。そして、データが古くなったり、欠落したりする事態を、ユーザーが気づく前に私たち自身が検知し、対処する体制を整えることが求められる。

より良いシビックテック（市民のためのテクノロジー）を構築することは、地方自治体のインフラが抱える「ごちゃごちゃした」現実を受け入れ、古いシステムと現代の利用者の期待との間に橋を架けるようなコードを書くことを意味する。これは挑戦的な仕事だが、技術の力で社会をより良くしていくという大きなやりがいのある仕事である。