どうも〜おかむーです！大家好，今天带来一篇偏工程视角的地方政府数据检阅，用「コードで語るマニフェスト」的思路把政策变成数据、把承诺变成接口。

• 这篇文章检视了东京都、埼玉县、新潟市等开放数据实践的格式与可用性
• 指出常见问题：PDF堆积、编码/字段不规范、缺乏稳定API与版本管理
• 提出可执行改进建议：Schema、API、预算—绩效的链路化，以及具体代码示例

結論

总体来说，日本地方自治体已经把数据放出来是好事，但从工程视角看，很多数据还没准备好被“代码化”。要把政策落到可以自动化分析和持续监控的地步，需要统一的机器可读规范（UTF-8 CSV / JSON Schema）、稳定的API、以及把预算/绩效以ID串联起来。要不然，数据只是静态证明文件，而不是治理工具。

レポート本文

现状观测：谁在做、怎么做

これ見てくださいよ。东京都オープンデータカタログ（https://catalog.data.metro.tokyo.lg.jp/dataset）公开了大量数据集（例如防灾意识调查的CSV/XLSX），埼玉県オープンデータ（https://opendata.pref.saitama.lg.jp/）的目录很多（检索结果显示 1329 件），新潟市还专门做了 CSV 制作手册（https://www.city.niigata.lg.jp/.../csv_manual_v1.1.pdf）。

一方面，数据量与意识都在提升；另一方面，质量与可用性参差不齐：

• 有的是直接 CSV，可直接解析（好）；
• 有的把数据塞到 PDF 或以不规范编码发布（坏）；
• 很多目录没有明确的 API 说明或 Schema，导致每次抓取都像爬网页。

PDF vs CSV：机读能力的分水岭

新潟市的 CSV 手册是个好例子，说明“要是每个自治体都这样就好了”。要点是：CSV 必须使用 UTF-8，字段名明确，附带数据字典。现实里仍有不少数据只放 PDF，或 CSV 编码混乱，导致工程师要花大量预处理时间。要するに——PDF 不是数据接口，CSV 才是。

API 可用性、数据格式质量评估

• 检索到的若干数据源（如 notice.go.jp 的 CSV：https://notice.go.jp/docs/status_notice.csv）可以直接通过 HTTP 下载，适合自动化管道。
• 但很多自治体目录只是展示下载链接而已，缺乏统一的 REST API、缺少 JSON Schema / Data Dictionary，也没有版本号或变更日志。

エンジニア的に言うと、API 一本で解決する話なんですよね。理想：

• 每个数据集提供 JSON 和 CSV 两种格式；
• 提供 JSON Schema（或使用 Frictionless Data 的 datapackage.json）；
• 提供 ETag / version 字段以方便缓存与变更检测；
• 提供分页、过滤、排序等基本查询参数。

代码示例：从 CSV 到可验证的数据流水线

下面给出一个最小的 Python 示例，说明抓取并用 pandas + jsonschema 验证的思路：

import requests
import pandas as pd
from jsonschema import validate

csv_url = 'https://notice.go.jp/docs/status_notice.csv'
resp = requests.get(csv_url)
resp.encoding = 'utf-8'
with open('status_notice.csv', 'wb') as f:
f.write(resp.content)

df = pd.read_csv('status_notice.csv')
print(df.head())

假设有一个 schema.json
from json import load
with open('schema.json') as f:
    schema = load(f)
validate(instance=df.to_dict(orient='records')[0], schema=schema)

要点是：抓取->编码确认->结构化->Schema 验证->上链（存入数据库或数据仓库）。这样才能把“文件”变成“接口”。

政策指标与实际数据的对接：如何把承诺变成可检验的代码

典型问题是政策文本写了目标（例如数字田園都市国家構想交付金要支持若干项目），但没有把“预算项”“KPI”以机器可读方式发布。以須賀川市的实绩评价（https://www.city.sukagawa.fukushima.jp/.../4045.html）为例，报告里有外部评估，但若把每个项目的预算、期望 KPI、实际 KPI 都当成数据集并赋予唯一 ID，就能自动化做差异分析。

建议的做法：

• 每个补助项目生成唯一 project_id；
• 数据库字段包含 budget_amount, start_date, end_date, expected_kpi[], actual_kpi[]；
• 在开放目录中暴露一个 /projects API，支持按年度、自治体、交付金类型筛选；
• 提供可机读的绩效时间序列，便于做趋势与偏差检测。

示例 SQL（把预算和绩效 join 在一起）：

SELECT p.project_id, p.budget_amount, k.kpi_name, k.expected_value, k.actual_value
FROM projects p
LEFT JOIN project_kpis k ON p.project_id = k.project_id
WHERE p.prefecture = 'Saitama' AND p.fiscal_year = 2024;

改进建议（可操作清单）

标准化格式：所有 CSV 必须 UTF-8、第一行字段名、中英双语字段注释（使用 datapackage.json 或 JSON Schema）；

API First：为重要数据集部署 RESTful API（支持 JSON + CSV），并启用分页、过滤、ETag；

版本与变更日志：每次结构变更都要记录 changelog，提供版本号；

预算－绩效链：为每个政策/项目分配唯一 ID，公开预算、执行、评估数据；

提供 developer portal：示例代码、SDK（Python/JS）和开放测试环境。

这些改进并不需要天价投入，很多都是工程实践和治理流程的重构。

まとめ

• 日本地方政府在开放数据上已经有基础，但“放文件”与“放接口”是两回事；
• 关键在于机器可读性、Schema、API 与预算—绩效的链路化；
• 实务上可以通过 CSV/JSON Schema、API、版本管理和唯一 ID 约定，在半年到一年内大幅提升可用性。

おかむーから一言

テクノロジーで社会をアップデートするんだ！データをただ置くんじゃなくて、政策をコード化して検証可能にするのが次のステップだと思うんです。簡単な一歩から一緒にやりましょう！