Code-Speaks Manifesto: Inspecting Japan's Public CSVs and What GovTech Should Do Next

どうも〜おかむーです！ Today I'm doing a bit of civic hacking meets policy critique — under the banner "Codeで語るマニフェスト". エンジニア的に言うと、公開データが政策の正否を検証するためのテストケースなんですよね。これ見てくださいよ、今回扱うのは以下の公開CSV群です:

• NOTICE: https://notice.go.jp/docs/status_notice.csv
• Ministry of Environment (Ibaraki): https://www.env.go.jp/content/900398071.csv (463KB)
• Domestic migration list 2011: https://www.inpit.go.jp/content/100869372.csv
• Rescue facilities: https://www.mhlw.go.jp/content/001682075.csv (8KB)
• Cabinet/Local data (national CSV): https://www.soumu.go.jp/main_content/000323625.csv (104KB)

• 3-line summary

- Many ministries publish CSVs — nice! だが、機械可読性とメタデータが足りない。

- API化やスキーマ検証で政策の実績を追跡可能にするべき。

- 実践: encoding detection, schema validation, datapackage化、そしてAPI一本化を提案。

結論

公開CSVは素晴らしい入り口だけど、現状だと政策評価に使うには不十分。要するに、データパイプラインの堅牢化（エンコード/スキーマ/メタデータ）と、API化による安定的なアクセスを最低限やるべき、ということです。

レポート本文

What I inspected

I looked at the CSV links above. Good news: ministries are exporting CSVs instead of PDFs — huge win. Bad news: inconsistencies kill automation.

問題点の例:

• Encoding ambiguity: some files might be Shift_JIS, others UTF-8. エンジニア的に言うと、まずchardetでdetectしないとパイプライン死にます。
• Missing schema: no datapackage.json, no column descriptions, no units. 要するに、どの列がIDでどれが数値か分からない。
• Update frequency unclear: no updated_at metadata, so you can't know staleness.
• No stable API endpoint: direct CSV links break on site reorganizations.

Quick technical checks (code snippets)

Here's a minimal Python pattern to robustly ingest these CSVs:

import requests
import chardet
import pandas as pd

url = 'https://notice.go.jp/docs/status_notice.csv'
r = requests.get(url)
d = chardet.detect(r.content)
text = r.content.decode(d['encoding'] or 'utf-8', errors='replace')
from io import StringIO
df = pd.read_csv(StringIO(text))
print(df.head())

次に、schemaを自動検証する例（panderaを想定）:

import pandera as pa
schema = pa.DataFrameSchema({
'id': pa.Column(pa.Int),
'date': pa.Column(pa.DateTime),
'count': pa.Column(pa.Int, nullable=True),
})
schema.validate(df)

Policy vs data — where the gap is

Many policies declare numeric targets (e.g., disaster shelter capacity, migration balance, administrative notices resolved). CSVs exist, but:

• No mapping from CSV rows to policy KPIs (no policy_id column).
• No historical time series standardized across departments.

結果、政策が目標に対してどう進捗しているかをコードで追えない。

Practical improvements (tech roadmap)

Standardize encodings: publish UTF-8 with BOM avoided, state encoding in HTTP headers and metadata.

Publish a datapackage.json alongside each dataset (Data Package spec) including schema, license, update cadence.

Provide a simple REST API (OpenAPI spec) with pagination and filtering; CSVs as export artifacts, not canonical endpoints.

CI for data quality: use unit tests (pandera/pydantic) in a GitHub Actions pipeline triggered on data updates.

Link datasets to policy manifests: add policy_id, KPI, target_value, period fields so analysts can JOIN.

Example: minimal OpenAPI sketch

openapi: '3.0.0'
paths:
/notices:
get:
parameters:
- in: query
name: date_from
responses:
'200':
content:
application/json:
schema: {...}

まとめ

CSVの公開は前進だけど、engineer目線だとまだ中間テーブルレベル。要するに、データを"信頼できるAPI + スキーマ付きアセット"に昇格させる必要があるんですよね。これができれば、政策の実績と目標のギャップを自動で検出できるし、自治体横断のダッシュボードも作れる。

おかむーから一言

テクノロジーで行政をアップデートするのは手間だけど、やる価値は無限大。まずは小さなデータパッケージから始めよう！