用代码说话的宣言：从API、CSV到UX看自治体数据与系统的技术改造

どうも〜おかむーです！今天来点工程师口味的政务数据聊聊〜

• 这篇文章用技术视角检视自治体/政府的数据发布与系统设计问题
• 我会从API、机器可读性、PDF vs CSV、以及UX连动提出可实作的改进方案
• 给出具体代码示例和数据治理建议，方便你立刻上手验证与落地

結論

要让政府数据真正被用起来，光做好前端 UX 不够，后台的数据接口、格式规范、版本管理和自治体间的语义一致性全都要上链路。エンジニア的视角是：API 一个、Schema 一个、用例一个，能立刻把“看得到”变成“能用”。

レポート本文

現状観察：UX 热情高、数据可用性参差

これ見てくださいよ：近年自治体やデジタル庁、東京都のオープンデータカタログ（参考：e-Gov API カタログ、東京都オープンデータAPI）で公開の動きはあるんですけど、実際に開発者がすぐ使える状態になっているかというと微妙なんですよね。

• フロント側のUX改善（Zennや渋谷区事例）は進んでいるが、裏のデータはPDFやバラバラのExcelのまま
• デジタル庁や総務省は「機械判読可能性ルール」を提示しているが、自治体の現場への浸透はまだ道半ば（参考：機械可読性に関するルール案）

要するに、UI とデータ API が乖離しているということです。

問題点を技術的に分解する

フォーマットの不統一

- PDFやスキャン画像で公開される統計表が多い。これだとスクレイピングやOCRが必要でコスト高。

- 解決イメージ：CSV/JSONでの一次公開。Excelでもセル位置に依存しないテーブル形式。

API設計の欠如・非互換

- e-Gov や東京都の API はあるが、エンドポイントやレスポンススキーマが自治体ごとに異なる。クライアント側で大量のハンドリングコードが必要。

- 解決イメージ：OpenAPI 仕様で公開、共通スキーマ（JSON Schema）を策定。

メタデータ不足

- 投稿日／更新日／ライセンス／スキーマ説明などが欠けている場合が多い。品質評価ができない。

- 解決イメージ：DCAT/Schema.org を使ったメタデータ公開。

数値目標と実績の追跡が難しい

- 政策のKPIがPDF報告のみで、機械集計できないケース。施策評価が手作業になっている。

- 解決イメージ：KPIは時系列データとしてAPIで公開、差分・前期比較が自動化できる形に。

具体的な改善提案（技術手順）

1) データ公開パイプラインの整備

• ソース（自治体DB） → ETL（正規化・型付け）→ 出力（CSV/JSON/Parquet）→ API + オープンデータカタログ
• ここで重要なのは「ソースのスキーマ定義」をコードで管理すること。例えば JSON Schema / Avro を使えば型が明示される。

2) API の標準化

• OpenAPI で仕様を書き、一つの共通ライブラリでクライアント生成を行う。
• 例えば「公共施設」API は東京都の GET /PublicFacility を参考に、共通フィールド（id, name, lat, lon, accessibility）を定義する。

3) 機械可読性のルール運用

• 総務省／デジタル庁のガイドラインに沿って、公開データは「レベル1: CSV/Excel」「レベル2: 構造化JSON」「レベル3: API+Schema」という分類を行い、各ファイルにレベルタグを付与する。

4) 実務で使えるコード例

• Tokyo Open Data の PublicFacility を叩いて GeoJSON に変換する Python スニペット（概念例）:

import requests
import geojson

r = requests.get('https://portal.data.metro.tokyo.lg.jp/api/PublicFacility')
items = r.json()['results']
features = []
for it in items:
feat = geojson.Feature(
geometry=geojson.Point((float(it['lon']), float(it['lat']))),
properties={k: it[k] for k in ('name','type','accessibility') if k in it}
)
features.append(feat)

fc = geojson.FeatureCollection(features)
open('public_facilities.geojson','w').write(geojson.dumps(fc))

• PDF 統計表を CSV に落とす（Tabula を使う例）:

# Java と tabula-py が必要
python -m tabula --pages all input.pdf -o output.csv

要するに、まずは「誰でも再現できる小さなパイプライン」を作るのが現実的です。

政策KPIの検証手法

• 政策が例えば「待機児童を3年で半減」のような数値目標を持つとする。これを追うためには、年／月単位で保育所利用者数や供給数を機械可読で公開する必要があります。
• 手法：KPIごとに時間軸データをAPIで定義し、CIでデータの差分警告（異常なドロップや欠測があればSlack通知）を設定する。

反対で終わらない具体的な施策

• 小さく始める：まず1つの行政サービス（例：公共施設・保育所・窓口予約）を選び、API+UIのエンドツーエンドをつくる
• テンプレート提供：OpenAPI テンプレート＋ETLサンプルを自治体向けに配布
• 開発者ポータル：API コンソール、サンプルデータ、SDK をまとめたポータルを運営
• 自治体間で共通の JSON Schema を協議会で決める

まとめ

• UX改善だけで満足しないでください！エンジニア的にはデータの可用性（API・CSV・スキーマ）が最優先です
• PDF→CSV変換、OpenAPI化、JSON Schemaでの型定義、メタデータ公開が実務的に効く
• 小さなサービスでの成功事例をテンプレ化して自治体横展開するのが現実解

おかむーから一言

テクノロジーって泥臭いんですよ、でも泥臭さを減らすのがエンジニアの仕事！まずはAPI一本、CSV一枚から始めて、社会を使えるデータで埋めようぜ！