どうも〜おかむーです！ Today's piece takes a GovTech lens to how Japanese national and municipal sites publish data and build services — we inspect formats, APIs, and UX from a coder's POV.

• Municipal websites often nail visuals but bury data in PDFs or unversioned files
• The Digital Agency and e-Gov offer guidelines and APIs, but machine-readability and monitoring are uneven
• Concrete fixes: adopt CSV/JSON-first, OpenAPI, CI checks, and simple dashboards to track compliance

結論

Public data access must be treated like a software product. If data stays trapped in PDF or ad-hoc Excel, it’s not an API bug — it’s a product design failure. エンジニア的に言うと、データがHTTPで取れないと再利用の速度はゼロに近いんですよね。

Report: What the sources say and what the code sees

What exists today

• Digital Agency UI guidance (digital.go.jp) pushes service design and UI/UX improvements — good attention to user feedback loops.
• e-Gov API catalog (e-gov.go.jp) lists government APIs — a central place but adoption varies across ministries.
• Tokyo Open Data portal (portal.data.metro.tokyo.lg.jp) exposes some endpoints like GET /PublicFacility — a practical example of usable APIs.
• New machine-readable rules (Digital Agency/Cabinet Office docs) push formats like CSV/Excel as Level 1 — this is a concrete win.

These are policy wins, but implementation gaps remain: many local sites still publish PDFs or images as the canonical source (see Zenn and UX articles on municipal site trends).

Technical problems observed

• PDF-first publication: locked semantics, OCR needed, no schema, no diffs.
• Inconsistent formats: mixed Excel layouts, hidden headers, merged cells — pain for parsers.
• Sparse API governance: no uniform OpenAPI specs, inconsistent authentication and pagination.
• Lack of monitoring: no metrics on machine-readability, API uptime, or dataset versioning.

要するに：機械可読性が“ある/ない”で終わっていることが多いんです。運用性がないと使われない。

Concrete code-driven checks (examples)

Fetch an open dataset (pseudocode Python):

import requests
import pandas as pd

r = requests.get('https://portal.data.metro.tokyo.lg.jp/api/3/action/package_show?id=publicfacility')
meta = r.json()
find CSV/Resource URL
csv_url = next(res['url'] for res in meta['result']['resources'] if res['format'].lower()=='csv')
df = pd.read_csv(csv_url)
quick schema check
expected_cols = {'id','name','latitude','longitude'}
print(set(df.columns) & expected_cols)

Schema validation with jsonschema (for JSON APIs) is trivial to add to CI. Use automated ETL to convert Excel/PDF to canonical CSV/JSON, but treat that as a temporary bridge — authoritative sources must publish machine-first.

Policy metrics to track

• % of datasets available as CSV/JSON (target 100%)
• % of public datasets with an OpenAPI/Swagger spec
• API uptime and mean latency
• Time-to-update (days between source change and API update)

UX notes

This is where the Digital Agency work matters: simple language, clear calls to action, and mobile-first structure increase adoption. But good UX and good data must co-exist: a shiny homepage linking to a PDF is still a blocker.

Implementation roadmap

Inventory: catalog datasets across gov sites (use e-Gov catalog + portal APIs)

Prioritize: high-value datasets (population, public facilities, budgets)

Publish canonical CSV/JSON + OpenAPI for APIs

Add CI checks: file format, schema conformance, license metadata

Dashboard: public compliance metrics (percentages above)

まとめ

The policy frameworks are maturing — Digital Agency guidance and e-Gov APIs give a foundation. The next step is productizing data: stable APIs, machine-readable formats, CI, and public KPIs. This turns policy into reusable code and real civic impact!

おかむーから一言

データはインフラですよ！開発者目線で言うと、まずCSV/JSONとOpenAPIを標準にするだけで再利用の速度がグッと上がります。テクノロジーで行政をアップデートしていきましょう！