Code as Manifesto: A Technical Check of Japan’s Municipal Data and Systems

どうも〜おかむーです! Today I’ll take a tech-first look at how Japanese national and local governments publish and operate public data and systems — think of this as a "code-based manifesto" that checks promises against actual APIs, file formats, and implementation.
- PDFs still dominate in places where machines should read data
- National push for system standardization is real, but local legacy + vendor lock-in slow it down
- Practical roadmap: APIs, OpenAPI, JSON Schema, CI for datasets — engineers can implement this fast
結論
The policy direction is right: e-Gov APIs, Digital Agency case studies, and ministry-led standardization (Soumu) create a foundation. But on the ground, data lives in PDFs, ad-hoc CSVs, or behind inconsistent endpoints. 要するに — policy + standards exist, but technical implementation and operational pipelines must catch up. Engineers can fix most gaps with an API-first, schema-driven approach and simple tooling.
Technical report
This comes from reading the e-Gov API catalog, Digital Agency materials on local system standardization, and examples like the SHA-1 deprecation note on a municipal portal (that one bit me: legacy certs break client support). These signals point to three practical problems:
1) Machine-readability: many datasets are only available as PDFs or embedded in webpages. That kills reuse.
2) Fragmented schemas and IDs: each municipality often names the same field differently (e.g. "addr" vs "address1").
3) Operational maturity: no consistent CI/CD for data, little schema validation, and vendor-tied legacy systems.
This is not fantasy — projects like BODIK API show we can aggregate municipal datasets, and the Digital Agency’s case studies show private reuse is feasible.
Technical evidence & examples
- API availability: e-Gov publishes an API catalog — nice! From an engineer's point of view, the next step is consistent OpenAPI specs per dataset so clients can auto-generate clients.
- PDF vs CSV: This data, look at this — PDFs are everywhere. If you have to extract tables, use tools like tabula-py or Camelot; but that’s brittle. Better to publish CSV/JSON with a JSON Schema.
Sample Python snippet to call an e-Gov JSON API and coerce to a canonical DataFrame:
import requests
import pandas as pd
r = requests.get('https://www.e-gov.go.jp/api/example')
r.raise_for_status()
data = r.json()
df = pd.json_normalize(data['items'])
map local fields to standard schema
mapping = {'addr':'address','zip':'postal_code'}
df = df.rename(columns=mapping)
Data engineering checklist (practical):
- Publish OpenAPI + JSON Schema for each dataset
- Provide canonical CSV/JSON downloads and a streaming endpoint for updates (RDF/JSON-LD optional)
- CI pipeline: validate schema, check sample rows, auto-deploy dataset with version tag
- Catalog + search: e-Gov already has an API catalog, extend it with dataset health metrics (last updated, format, schema)
- Auth & rate limits: provide API keys with reasonable free tiers for civic tech reuse
Policy vs implementation gap
The central push to standardize municipal core systems (Soumu, Digital Agency) aims to make vendors supply standard-compliant systems. But real constraints: budget cycles, staff capacity, and vendor lock-in. Practically, require transitional adapters:
- API Facade: an adapter layer that overlays a standard API on top of legacy DBs
- Schema translation rules maintained in Git alongside tests
- Migration windows and audit logs to measure functional parity
Improvement proposals (concrete)
- Mandate OpenAPI + JSON Schema for any dataset referenced in policy reports
- Fund a shared middleware (API gateway + validation) municipalities can opt into
- Provide a reference implementation (Docker image) that exposes a standard REST API and S3-backed dataset store
- Publish a minimal data contract (IDs, datetimes in ISO8601, UTF-8, geocoordinates in WGS84)
まとめ
Policy momentum is strong and usable assets (API catalog, case studies, aggregator projects) exist. The remaining work is engineering: consistent schemas, machine-readable formats, and automated validation. 要するに、政策のコード化 — manifest in OpenAPI + JSON Schema + CI — があれば、自治体データはぐっと使いやすくなりますよ!
おかむーから一言
I’ve built products that turned messy data into live services — and I’m convinced: standardize the API, automate validation, and civic tech will sprint. Let’s ship the toolkit and make public data actually public!
Sources
- https://kotobank.jp/word/%E5%85%AC%E5%85%B1-494676
- https://www.intec.co.jp/column/smartcity-08.html
- https://www2.wagmap.jp/takatsuki/Portal
- https://www.digital.go.jp/resources/data_case_study_private
- https://ja.wikipedia.org/wiki/%E5%85%AC%E5%85%B1
- https://www.jichi.ac.jp/
- https://www.e-gov.go.jp/digital-government/api
- https://www.jichi.ac.jp/web_text/
- https://www.bodik.jp/project/bodik-api/
- https://www.jichi.ac.jp/library/
- https://www.digital.go.jp/policies/local_governments
- https://www.soumu.go.jp/menu_seisaku/chiho/jichitaijoho_system/index.html
- https://www.allied-telesis.co.jp/netrend/govdx-sys-standard/
- https://business.ntt-east.co.jp/column/bizdrive/municipality_systemstandardization.html
- https://www5.cao.go.jp/keizai-shimon/kaigi/special/reform/wg6/2025/shiryou3-2.pdf
Share
Related Reports

Code-driven Manifesto: Auditing Local Gov Data and Systems (Kagawa case study)
Local gov systems run but hide data behind UIs; expose CSV/JSON, APIs, and common schemas to unlock value.

Code-driven Check: Japan’s Open Data and the Machine-Readable Gap
Digital Japan has dashboards and rules, but PDFs and messy formats still block automated policy verification; mandate CSV/JSON, APIs, and dataset linting.

Code Speaks: Testing Japan's Gov Data and Dashboards
Japan has great dashboards but inconsistent machine-readability. This report inspects e-Stat, Japan Dashboard, Kantei PDFs, and proposes API-first fixes and practical code examples.