オープンデータの“解像度スコア”を作って自治体データの実用性を評価する

IT政策の提案
オープンデータの“解像度スコア”を作って自治体データの実用性を評価する

どうも〜おかむーです!今日はちょっとエンジニアっぽい話をしますよ〜

  • 自治体オープンデータ、量はあるけど使い勝手バラバラなんですよね
  • 「解像度(granularity)」という指標でデータの実用度を数値化してみる提案をします
  • API有無・フォーマット・更新頻度・地理参照の4軸でスコア化して技術的改善案を出します!

結論

自治体オープンデータの価値は“公開有無”ではなく“解像度”で決まる。APIと機械可読フォーマット(CSV/JSON)、時間・空間の粒度、そして更新性を組み合わせた「解像度スコア」を運用に組み込めば、データの再利用性が一気に上がる。技術的にはCKAN互換APIの活用、メタデータの標準化、継続的検出用の簡易モニタを推奨するよ!

レポート本文

背景と観測対象

これ見てくださいよ:東京都のオープンデータカタログ(portal.data.metro.tokyo.jp / catalog.data.metro.tokyo.lg.jp)はデータ数が多いけど、1件1件の“使える度合い”はバラつきがあるんです。デジタル庁もUI/UXガイドラインやサービス設計を進めてますが(digital.go.jp)、データそのものの「解像度」はまだ可視化されていない。

エンジニア的に言うと、同じ"公共施設一覧"でも「市区町村レベルの点データ」「住所文字列のみ」「PDFスキャンのテーブル」では再利用コストが全然違うんですよね。要するに、データの細かさ(時間/空間/属性)とアクセス性が鍵。

解像度スコアの構成(提案)

以下4軸でスコアを作ります:

  • API(0〜25点): CKAN/REST APIで直接取りに行けるか。CSVだけどAPI経由で取得できるなら高得点。
  • フォーマット&機械可読性(0〜25点): CSV/JSONは高、PDF/画像は低。文字コード明記・ヘッダ有無も評価。
  • 時間的粒度(0〜25点): 年次・月次・日次・リアルタイムなど。KPI観測には頻度が命。
  • 空間的粒度(0〜25点): 都道府県・市区町村・緯度経度までの有無。地理参照がないと可視化で詰む。

合計100点満点。スコアが低ければ「使えるが改修要」「再公開の優先度高」など運用判断に回せます。

実際にデータカタログを叩く簡易例

多くの自治体カタログはCKANベースなので、package_showでメタ情報が取れるケースが多いです。実例コード(Python、簡易):

import requests

base = 'https://catalog.data.metro.tokyo.lg.jp/api/3/action/package_show'

params = {'id':'dataset-id-example'}

r = requests.get(base, params=params)

meta = r.json()['result']

metaからresources, frequency, spatial, licenseを抜く

要するに、まずはメタデータを機械的に集めてスコアリングの入力にするのが現場で速攻使えるテクニックです。

PDF vs CSVの話(また出た…)

Yamaguchi県の交付金実績資料のように(検索結果にPDFが出ます)、重要なKPIがPDFに埋まってるパターンはまだ多い!PDFは人間に読ませるには良いけど、プログラムで取り出すときはOCRや手作業が発生してコスト高。エンジニア的に言うと、API一本で解決する話なんですよね。

改善提案:

  • KPIは少なくともCSVで定期公開、理想はAPIのtimeseriesエンドポイント
  • PDFは人向けサマリ、データは機械可読で同時公開

自動スコアリングのサンプルロジック(疑似コード)

def score_resource(res):

s = 0

if 'api' in res['url'] or res['format'].lower() in ['csv','json']: s += 25

if res['format'].lower() in ['csv','json']: s += 25

freq_map = {'realtime':25,'daily':20,'monthly':10,'annual':5}

s += freq_map.get(res.get('update_frequency','annual'),0)

if res.get('spatial_coverage') == 'point': s += 25

return min(s,100)

このくらいのシンプルさで運用しつつ、しきい値を決めて「改善通知」を出すのが現実的です。

運用とガバナンスの提案

  • カタログ側で解像度スコアを表示する(住民向けのサマリと開発者向けの詳細両方)
  • データ公開時に必須メタデータ(更新頻度、緯度経度有無、ライセンス、チェックサム)を入力させるフォーム整備
  • パイプライン: CIでメタデータ検証 → 低スコアは自動でissue作成して担当部署へ通知

これ、技術的には既存のCI/CDツール(GitHub Actions等)と組み合わせれば少ない工数で回せますよ。

まとめ

自治体のオープンデータは「出してる感」だけで終わっていることがある。解像度(API可用性・フォーマット・時間/空間粒度)を定量化して運用に埋め込めば、行政のデータ資産が本当に使える資産に変わる。まずはカタログからメタデータを引っ張ってスコア化するプロトタイプを回してみてほしいです!

おかむーから一言

テクノロジーで行政をアップデートするのは夢じゃない。まずは小さなスコアリングから始めて、データがちゃんと“使われる”文化を作ろうぜ!

シェアする