どうも〜おかむーです！ Today I want to do a little engineering audit on how Japan's government and municipalities publish data — think of this as a "code-first" manifesto for public data. エンジニア的に言うと、政策の説明だけじゃなくて、データとAPIが語るべきなんですよね。

• Government publishes APIs but many reports stay trapped in PDFs
• Example: Digital Village grants report published as PDF (Yamaguchi) with KPI mentions but limited machine-readability
• Quick wins: CSV/JSON endpoints, OpenAPI, KPI time-series APIs and schema validation

結論

Public-sector data in Japan is moving in the right direction (e-Gov APIs, Tokyo open data), but too much policy evidence is still PDF-bound and fragmented across catalogs. 要するに、機械可読で継続的に取得できるAPIと明確なスキーマがあれば、KPIの追跡・検証・二次利用が激変します！

Report: what I looked at and why it matters

I surveyed central and local footprints: the e-Gov administrative API portal (https://www.e-gov.go.jp/digital-government/api) and API catalog (https://api-catalog.e-gov.go.jp/info/ja/apicatalog/list), Tokyo's open data portal (https://portal.data.metro.tokyo.lg.jp/opendata-api/) and concrete project reports like Yamaguchi Prefecture's Digital Village grant results (PDF: https://www.pref.yamaguchi.lg.jp/uploaded/attachment/160746.pdf).

What jumps out:

• Machine readability gap

- These resources exist (APIs and catalogs), but many project-level reports (grant KPIs, final reports) are only PDFs. これ見てくださいよ：Yamaguchi's PDF lists adopted projects and actuals (e.g. 実績額：15,289千円) but not as CSV/JSON.

- PDFs block automation and reproducible audit trails.

• API coverage and quality

- e-Gov provides a central API portal, and Tokyo publishes many datasets with CSV/JSON endpoints (catalogs show recent updates). Still, there's no uniform schema for policy KPIs across municipalities.

• KPI vs actuals

- Guidelines (e.g. Digital Village grant guidance) require KPI setting and monitoring, but public disclosure is inconsistent across regions. That makes program-level evaluation by external parties hard.

Technical implications (engineer-eye)

• If KPIs are in PDFs, you need brittle OCR/parsing pipelines. Error-prone and non-repeatable.
• Standardizing on JSON/CSV + JSON Schema + time-series endpoints means simple code can compute deltas, visualizations, and alerts.

Example: minimal pipeline to compare KPI targets vs reported actuals

import requests
import pandas as pd
hypothetic endpoints
kpi_targets = requests.get('https://api.pref.example.jp/digital_village/kpi_targets').json()
kpi_actuals = pd.read_csv('https://portal.data.metro.tokyo.lg.jp/dataset/digital_village_actuals.csv')
join on project_id
df = pd.DataFrame(kpi_targets).merge(kpi_actuals, on='project_id')
df['gap'] = df['actual'] - df['target']
print(df[['project_id','target','actual','gap']])

要するに、API一本で解決する話なんですよ！

Concrete recommendations (practical)

• Expose KPI time-series endpoints: /projects/{id}/kpis?start=2024-01-01&end=2026-03-31 returning JSON timeseries
• Publish machine-readable artifacts alongside PDFs: CSV/JSON + metadata (DCAT), and provide OpenAPI specs for APIs
• Adopt JSON Schema for KPI payloads and use CI to validate uploaded data (reject missing units, ambiguous fields)
• Provide canonical identifiers for projects (UUIDs) so cross-jurisdiction aggregation is easy
• Create a central KPI dashboard (public) that pulls from e-Gov API catalog and municipal endpoints to show target vs actual and trends

Risks and mitigation

• Risk: municipalities lack capacity. Mitigation: provide reference implementations (serverless functions, terraform templates) and small grants to publish CSV+OpenAPI.
• Risk: inconsistent definitions. Mitigation: central registry of KPI types and units.

まとめ

Japan's public data infra has grown — APIs and catalogs exist — but policy accountability is hindered by PDFs and inconsistent schemas. エンジニアとして言うと、データの流通をAPI化してスキーマを決めるだけで、監視・評価・再利用のスピードが段違いに上がります。実務的な手順（CSV/JSON, OpenAPI, JSON Schema, CI）を少し投資するだけで、政策の可視性と再現性が大きく改善します！

おかむーから一言

I've started companies and shipped govtech products — tech reduces friction but standards and tiny implementation help are the rocket fuel. Let's push for API-first public data and stop treating PDFs as the final record!