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

• Government and prefectural portals (Tokyo, Saitama) mostly provide CSV/metadata — good baseline
• Policy reports (e.g. sousei guidance, Sukagawa evaluation) still rely on PDFs; machine-readability gap remains
• Engineering fixes: stable APIs, schema standards, KPI dashboards + example code to validate promises

結論

現状、都道府県レベルのオープンデータはCSVで配られていて再利用性はあるが、政策検証に必要なKPIや事業実績はPDFに埋め込まれているケースが多い。エンジニア的に言うと、API一本とスキーマを整備すれば検証のコストは劇的に下がる！要するに「データがAPIで出てくればコードで語れる」ってことです。

Report: what's available, what's missing, and how to test policy by code

What I checked (sources)

• e-Gov Administrative API catalog — baseline for government system APIs (https://www.e-gov.go.jp/digital-government/api)
• Tokyo Open Data Catalog — many CSV datasets with metadata (https://catalog.data.metro.tokyo.lg.jp/dataset)
• Saitama Open Data portal — similar catalog approach (https://opendata.pref.saitama.lg.jp/)
• Chisou sousei "Check・Action" guideline PDF — KPI reporting framework for Digital Rural City grants (https://www.chisou.go.jp/sousei/pdf/r5_guideline-checkaction.pdf)
• Sukagawa city evaluation page — example of municipality-level evaluation of grants (https://www.city.sukagawa.fukushima.jp/…/4045.html)
• BODIK API — aggregator that targets municipal standard open datasets (https://www.bodik.jp/project/bodik-api/)

Machine-readability: PDFs vs CSV vs API

これ見てくださいよ。政策の根拠やKPIがPDFで配布されていると、スクレイピング→OCR→手作業で整形するはめになります。要するに非効率！一方で、TokyoやSaitamaのカタログはCSVを直接添付していて、エンジニア的に嬉しい。

問題点まとめ:

• KPIや予算対実績の詳細がPDF添付だけで提供されるケースがある（chisou souseiのガイドライン資料に例あり）
• APIの存在はあるが、自治体横断での同一スキーマが足りない（BODIKが補助するが完全ではない）
• メタデータや更新頻度、バージョニング情報が不十分

How to validate a policy claim by code (example)

1) Find the planned KPI in a PDF/guideline (human step)

2) Pull implementation data from open catalogs (CSV) or APIs

3) Compute gap and visualize

Example: fetching a CSV from Tokyo catalog and computing simple KPI gap in Python

import pandas as pd
example CSV URL from a Tokyo dataset (replace with actual URL)
csv_url = 'https://catalog.data.metro.tokyo.lg.jp/dataset/xxxx/resource/yyyy.csv'
df = pd.read_csv(csv_url)
assume df has columns: date, indicator, value
kpi_planned = 1000
actual = df.loc[df['indicator']=='target_project','value'].sum()
gap = kpi_planned - actual
print(f'Planned={kpi_planned}, Actual={actual}, Gap={gap}')

API example (pseudo curl to e-Gov API catalog):

curl -s "https://www.e-gov.go.jp/digital-government/api/catalog" | jq '.datasets[] | {id,name,format}'

要するに、コードでデータを取りに行ければ、政策検証は自動化できるんですよね！

Specific improvement proposals (engineer-first)

• Mandatory machine-readable KPI export: every grant/program page should expose JSON/CSV of planned KPIs and periodic actuals
• Standard schema (e.g., JSON Schema + CSVW) across municipalities so aggregators like BODIK can unify easily
• Stable API endpoints with versioning and metadata for update timestamps
• Small reproducible example datasets and a public spec for the Digital Rural City grants (chisou → publish as machine-readable)
• CI for data quality: automated tests that verify consistency (sum checks, date ranges, null rates)

まとめ

現場レベルではCSVカタログが進んでいるけど、政策文書に埋まったKPIや実績はまだPDFに頼っている。エンジニア的に言うと、API化とスキーマ統一で政策の検証可能性が桁違いに上がる。批判で終わらせず、具体的なAPI設計・データ品質ルールを導入していきましょう！

おかむーから一言

I’ve built APIs and dashboards that made decision-makers actually change course — tech works when it's simple and trusted. Let’s make government data as easy to call as a library API and then we can hold policy promises to code.