• How the national push to standardize local government core systems maps to APIs and machine-readable formats
• Where PDFs, vendor lock-in, and Fit & Gap slow things down — and how adapters + canonical schemas help
• Concrete technical roadmap: OpenAPI, JSON canonical model, contract tests, and a simple ETL example

結論

The policy push to require standard-compliant systems for local governments (see Digital Agency and Cabinet materials) is the right direction, but the technical success depends on making data truly machine-readable, providing developer-friendly APIs, and enforcing conformance with automated contract tests. 要するに、政策があるだけではダメで、コードで実効性を担保する仕組みが必要ということです。

Report

Hey — okamu here! Today we dig into the rollout of Japan's effort to unify and standardize local government core systems (Digital Agency: local_governments, Cabinet WG report, and Ministry of Internal Affairs pages). Technically speaking, this is an API-first, data-model problem more than a procurement problem.

What the policy says (quick)

• Digital Agency recommends standardization and apps that consume standardized data formats.
• Ministry and Cabinet documents propose mandating use of standard-compliant systems for ~20 core operations (resident registry, taxation, etc.) and using Fit & Gap processes during migration.

These are great as high-level specs, but this is where the engineering heat starts.

The engineering gaps

These are the practical frictions I see when reading the policy and supporting PDFs:

• PDFs and spec docs: many standards and guidance remain PDF-centric (see Cabinet WG PDFs). PDFs are human-readable but terrible for automation.
• Sparse machine-readable schemas: there's limited reference JSON/JSON Schema/OpenAPI for each core domain.
• API availability & consistency: e-Gov API catalog exists, but adoption across municipalities is uneven (see e-Gov API catalog).
• Vendor lock and legacy systems: many municipalities run different vendors; Fit & Gap is necessary but costly.

要するに、データを機械が扱える形にすることが最優先です。

Technical prescription (practical)

Canonical JSON model per domain

- Publish JSON Schema + example payloads for each of the 20 operations. Link these in a public repo (GitHub/GitLab).

OpenAPI-first APIs

- Mandate an OpenAPI spec for every standard-compliant system. This enables client generation and mock servers.

Contract testing & CI

- Use contract testing (Pact or Schemathesis) to validate vendor implementations during procurement and CI pipelines.

Adapter layer for legacy systems

- Build an API gateway that normalizes diverse vendor outputs into the canonical model (ETL + transformation rules).

Data catalog + dashboard

- Integrate with Japan Dashboard / e-Stat so datasets are discoverable and versioned.

Example: fetch an administrative-code API and transform to CSV

import requests, csv
r = requests.get('https://www.e-gov.go.jp/api/example-endpoint')
data = r.json()
normalize to canonical fields
rows = [(d['id'], d['name'], d.get('pref_code')) for d in data['items']]
with open('admin_codes.csv','w',newline='') as f:
writer = csv.writer(f)
writer.writerow(['id','name','pref_code'])
writer.writerows(rows)

要するに、API一本あれば加工はすぐできるんですよね。

Migration pattern (high-level)

• Step 0: Publish schemas (JSON Schema + OpenAPI)
• Step 1: Build adapter + mock server per vendor
• Step 2: Run Fit & Gap with automated contract tests
• Step 3: Gradual cutover with monitoring and fallback

Benefits and KPIs

• Faster cross-municipal services, lower integration costs
• KPIs: % of municipalities exposing OpenAPI endpoints, mean-time-to-onboard an app, schema compliance rate

まとめ

Japan's policy to standardize core local systems is necessary and promising. The missing piece is treating the policy as software: publish machine-readable schemas, require OpenAPI, run automated contract tests, and provide adapter patterns for legacy vendors. This moves us from paper rules to executable guarantees.

おかむーから一言

I’ve built and shipped GovTech products — this is doable if we treat standards like code: versioned, tested, and open. Let’s make government data as friendly to developers as the web itself!