Code Speaks: Evaluating Japan's Administrative Data Push from a Tech POV

どうも〜おかむーです！今日はちょっとエンジニアっぽい話をしますよ〜

• Government has published machine-readability rules (PDF→CSV/Excel) but many datasets remain locked in PDFs.
• Local system standardization and cloud migration are policy goals, yet heterogeneity and legacy formats create gaps.
• Technical fixes are straightforward: publish JSON/CSV, provide APIs with OpenAPI, and ship reference implementations.

結論

The policy direction is solid — the Digital Agency and Cabinet Office have pushed machine-readable rules and local-system standardization (see digital.go.jp and cas.go.jp). But エンジニア的に言うと、実務はフォーマットとインターフェースの欠如で止まってます。要するに、文書化された目標はあるけど、データを“コードで使える形”にする実装が追いついていない、ということです。

Report: what's happening and what to fix

What the policy says (short)

• The Digital Agency published rules emphasizing machine-readable formats (CSV/Excel rather than PDF/Word) — see digital.go.jp materials dated 2026/03/31.
• Central bodies (Cabinet Office / Digital Agency / Ministry of Internal Affairs) pursue standardization and migration to a Government Cloud for local governments (materials on digital.go.jp and soumu.go.jp).

これ見てくださいよ：policy docs explicitly call out PDF-as-default as bad practice. So the government knows the problem!

Where the gap shows up

• Formats: Many published reports still live in PDFs. PDFs are great for humans but terrible for pipelines.
• APIs: Few consistent, documented RESTful APIs across municipalities. No ubiquitous OpenAPI specs or centralized catalog like a gov-wide CKAN.
• Data quality & vocabularies: Different field names, encodings, and granularities across LG systems — integration costs skyrocket.
• Operations: Local IT teams maintain custom monoliths; cloud migration plans exist, but runbooks and reference CI/CD are missing.

Technical implications (エンジニア的に言うと)

• If data is in PDF, automated ETL needs OCR and heuristic scraping — brittle and expensive.
• Standard CSV/JSON + OpenAPI = immediate developer uptake. A single JSON schema reduces integration testing time dramatically.

Concrete code-oriented suggestions

• Publish machine-readable datasets alongside PDFs. Use CSV/UTF-8 and ndjson for event streams.
• Provide an OpenAPI spec per major dataset and host it in a public Git repo. Minimal OpenAPI example:

openapi: 3.0.3
info:
title: Municipal Budget API
version: 1.0.0
paths:
/budgets/{year}:
get:
parameters:
- name: year
in: path
required: true
schema:
type: integer
responses:
'200':
description: JSON list of budget items

• Offer ready-to-run reference implementations (containerized Flask/Actix services) that read CSV/Parquet and expose APIs.
• For ad-hoc analyses, provide examples: Python/pandas and jq snippets.

import pandas as pd
df = pd.read_csv('https://example.gov/datasets/budgets.csv')
summary = df.groupby('department')['amount'].sum()
print(summary)

• Use DCAT or schema.org Dataset metadata so catalogs can be harvested centrally (e-Stat style or gov data portals).

Policy target vs reality: short diagnostic

• Target: standardized LG systems and gov-cloud migration (documents from 2025–2026). Reality: each municipality still runs bespoke systems with different DB schemas; procurement cycles are slow; budgets for reengineering are constrained. Result: targets slip and data reuse stalls.

Roadmap & quick wins (practical)

Mandate CSV/JSON exports for all statutory datasets in next 6 months.

Create a central "reference API" GitHub org with CI that validates schema compatibility.

Fund a pooled-service model: shared identity, auth, and dataset hosting on Government Cloud to reduce per-LG costs.

Publish migration playbooks (container images, Terraform, CI templates) so local teams can onboard quickly.

まとめ

Policy is in the right direction — rules and target milestones exist — but the operational layer needs standard interfaces, reference code, and catalogs. 技術的にはCSV/JSON + OpenAPI + reference infraで多くが解決します。要するに、やるべきは『ドキュメントをコードに落とす』ことです。

おかむーから一言

実装フェーズはツラいけど超楽しいんですよ！テクノロジーで役所の針をほんの少し動かすだけで、社会の使い勝手が変わるんです。やりましょう！