どうも〜おかむーです！ Today I want to look at municipal and national government data through the lens of an engineer — "code speaks the manifesto" style. I’ll show where things are good, where they get stuck in PDFs, and pragmatic fixes you can ship.

• Government websites often have great intent but ship data as PDFs, not machine-readable formats.
• APIs like e-Gov and Tokyo’s Open Data exist, but coverage and schema hygiene are uneven.
• Practical fixes: OpenAPI specs, CSV/JSON-first publishing, CI for data quality, small UX copy wins.

結論

Public-sector data is close to being useful for real products, but two gaps block it: inconsistent machine-readability (PDFs instead of CSV/JSON) and missing developer-friendly contracts (OpenAPI/schema). エンジニア的に言うと、API + schema + CIで大半は解決しますよね。

Report: what I checked and what it tells us

What I looked at

• e-Gov API catalog (e-gov.go.jp) — an official API hub with promising entries.
• Tokyo Open Data portal (portal.data.metro.tokyo.lg.jp) — exposes endpoints like GET /PublicFacility.
• Digital Agency guidance and machine-readable rules draft (digital.go.jp) — pushes Excel/CSV over PDF.
• Case studies on UX improvements (Zenn, Shibuya examples) and UX pitfalls in municipal digital services.

これ見てくださいよ：Digital Agency’s draft rules explicitly call out CSV/Excel as Level 1 machine-readable formats, and recommend avoiding PDF for tabular stats. 要するに、PDFは人間のため、CSV/JSONは機械のため、ということです。

Technical gaps observed

• PDFs as canonical publications: datasets published only in PDF mean extra ETL work (OCR/manual parsing). That increases friction and breaks automation.
• API surface inconsistency: some APIs exist (e-Gov, Tokyo), but schemas are weakly typed or undocumented. No uniform OpenAPI specs to validate client expectations.
• UX and microcopy: forms and endpoints expose bureaucratic terms; this hurts adoption.

Concrete engineering evidence and reproducible checks

• Try fetching Tokyo’s PublicFacility API (example):

import requests
r = requests.get('https://api-tokyo.example/PublicFacility?limit=10')
print(r.status_code)
data = r.json()
print(data['results'][0].keys())

• If the first step fails or returns HTML/PDF, that’s a hard blocker. 要するに、API should return JSON and a consistent schema.

Policy targets vs reality

Many local governments publish targets in PDFs (e.g., sustainability or accessibility goals) but provide no machine-readable time series. Without numeric CSVs, you can’t programmatically verify progress or join datasets — so the gap between target and verifiable outcome widens.

Practical improvement plan (engineering-first)

Publish a canonical dataset as CSV/JSON alongside PDF: treat PDF as human-friendly, CSV/JSON as canonical.

Ship OpenAPI and JSON Schema for every API endpoint. This enables client generation and contract tests.

CI for datasets: automated checks for nulls, schema drift, and date formats. Example GitHub Action: validate CSV against JSON Schema.

Lightweight ETL patterns: if legacy PDFs remain, run an OCR/parsing pipeline producing canonical CSV and keep provenance metadata.

UX fixes: replace bureaucratic terms with plain language; include example API calls and curl snippets on the portal.

Sample CI check (pseudocode):

# validate CSV schema
python validate_csv.py --schema schema.json --input latest.csv
fail CI if mismatch

Open data — where value is unlocked

• Joinable, timestamped CSVs enable dashboards, machine-learning models, and civic alerts.
• Provide webhook or changefeed for datasets so downstream apps can react to updates.
• Encourage community reuse with sample notebooks and data packages.

まとめ

政府・自治体のデータは道半ばだけど、技術的対処は明快です。PDFを二次出力にして、CSV/JSONを一次ソースにし、OpenAPI/JSON SchemaとCIで品質を守れば、データはぐっと使いやすくなります。UXは言葉とサンプルで改善可能 — 小さい投資で市民と開発者の両方が得しますよね！

おかむーから一言

テクノロジーで行政をアップデートするのは難しくない。小さなAPIと一貫したスキーマを積み上げれば、市民サービスは確実に良くなる。やりましょう！