Code-Savvy Manifesto: How Japan's Gov Data Stacks Up (and How to Fix It)

どうも〜おかむーです！ Today we're doing a bit of GovTech autopsy — in a friendly, engineering way. エンジニア的に言うと、この種の政策はデータとAPIで語らせるべきなんですよ〜

• The government publishes useful datasets (e-Gov API, Tokyo Open Data), but machine-readability and consistency are uneven.
• PDFs and ad-hoc CSVs block automated monitoring of policy KPIs; APIs exist but are fragmented.
• Practical fixes: canonical APIs, CSV/JSON-first publication, schema+versioning, and simple code examples to lower the barrier.

結論

Japan has made real progress: there are API catalogs (e-gov.go.jp API catalog) and city-level Open Data APIs (Tokyo’s portal). これ見てくださいよ、APIがあるだけで可能性は大きい！ ただし、現状は“部分的にAPI化されたPDF文化”で、要するに自動化と信頼性が不足しているということです。政策の数値目標をコードで追いかけられるようにすれば、実行力がぐっと上がるんですよね。

Report: technical assessment and recommendations

What exists today

• e-Gov API (https://www.e-gov.go.jp/digital-government/api) — catalog-level entry points for some administrative information.
• Tokyo Open Data API (portal.data.metro.tokyo.lg.jp) — well-scoped endpoints like /PublicFacility returning JSON.
• GovTech Tokyo materials on dashboards and data utilization show institutional momentum.

What's broken (technically)

• PDF-first reporting: budgets, performance reports, and KPI tables often live in PDFs. 要するに、機械が読み取れない。
• Fragmented endpoints: different ministries publish similar data with different schemas and identifiers (no canonical ID for e.g., facilities, projects).
• Lack of stable versioning and metadata (no CSVW/JSON-LD, poor schema docs).

Concrete examples (code)

Fetch Tokyo facility list (simplified):

import requests
r = requests.get('https://portal.data.metro.tokyo.lg.jp/api/3/action/package_show?id=publicfacility')
print(r.json()['result']['title'])

If data is in PDF, use tabula-py or Camelot to extract tables, but that's brittle. Better: ask providers to publish CSV/JSON and attach a schema.

KPI tracking: policy vs reality

Policies often state numeric targets (e.g., service X to be digital by year Y) but reporting is in PDFs updated annually. That creates a visibility gap. Solution: expose time-series endpoints for KPIs (e.g., GET /v1/policies/{id}/metrics?from=2020-01-01&to=2026-01-01) returning machine-readable arrays.

Implementation roadmap (practical)

• Step 1: Inventory — each ministry publishes a small machine-readable catalog (CSV/JSON) listing datasets, PID, update cadence.
• Step 2: Minimal viable API pattern — list, get, search, metrics endpoints with OpenAPI spec and versioning (v1).
• Step 3: Schema-first publishing — use JSON Schema + CSVW for tabular data, include sample queries.
• Step 4: SDKs and examples — provide tiny Python and JS snippets; CI to validate schemas on publish.

まとめ

Progress exists, but we need to move from PDF-as-truth to API-as-truth. 小さな改善（CSV first、schema、versioning、sample code）でデータの再利用性と政策の説明責任が劇的に向上します。エンジニア的に言えば、API一本で解決する話なんですよね！

おかむーから一言

I'm an entrepreneur and engineer — two startups taught me that making things testable and observable changes behavior. Let's make policy measurable by default and ship the APIs that let citizens and developers hold government to account.