大家好，我是おかむー！今天來點工程師口味的公民科技聊聊，主題是「代碼で語るマニフェスト」，也就是用資料和工程的眼光檢驗政府與自治體的承諾～

• 政府在推動數位化與UX改善，但資料仍大量散落在 PDF / 網頁中，機器可讀性不足
• e-Gov 與都道府縣的 OpenData 有 API，但品質與格式不一，需要標準化與自動化流程
• 提案：以 CSV/JSON 為基礎、同步 API 與資料目錄、並用 CI/CD 把資料品質納入部署流程

結論

政府的政策與宣示已經朝向「開放與用戶優先」走，但工程實作還沒跟上：PDF、混亂的 Excel、非標準 API 與缺乏機制的資料更新，讓政策承諾在實際應用上變弱。要把「宣言」變成可被程式、研究者、創業者實際消費的數據，需要從資料格式、API 設計、資料品質檢測與部署自動化三個層面著手。

報告本文

現況快照：有哪些資源可以用？

• e-Gov 的行政 API 目錄（https://www.e-gov.go.jp/digital-government/api）已提供部分政府系統的 API，這是基礎設施的一環。
• 東京都的 Open Data API（https://portal.data.metro.tokyo.lg.jp/opendata-api/）提供公共設施等資料，示範了地方政府可以做的事。
• 同時，數位廳與內閣官房在推動 UI/UX 與機械可讀性規則（例如：機械可読性に関するルール案與決定文件，見 2026 年的資料），顯示政策層面已有方向，但落實仍需技術工作。
• 社群與業界的 UX 改善報告（如 Zenn、設計事例）指出自治體介面與內容架構常不友善，進而阻礙資料被實際利用。

要するに（簡而言之）：政策有方向、平台有雛形，但資料狀態與工程實作仍是瓶頸。

技術問題詳解

1) PDF 與非機器可讀格式仍然太多

これ見てくださいよ：官方報告或統計常常以 PDF 或印刷用 Excel 發布（出典：數位廳機械可讀性草案/決定文件）。對工程師來說，PDF 是最難自動化處理的來源。

• 問題：OCR/解析成本高、結構不穩、錯誤率高
• 解法：原生提供 CSV/JSON/Excel (xlsx) 的結構化檔案，並把 PDF 當作人類閱讀的副本

2) API 可用但不一致

• e-Gov 與地方 API 存在，但規格、認證方式、資料更新頻率差異大
• 工程師角度說：若每個機關都有自己的非標準 schema，整合成本會爆炸

3) 資料品質與文件不足

• 缺少 schema、欄位說明、單位與更新時間，導致使用者要花大量時間清理
• 要求：提供 JSON Schema / OpenAPI 規格與測試端點

4) 政策目標 vs 實績的可驗證性

• 政府常有數值目標（例如某服務採用率、回應時間等），但若沒有機器可讀化的監測端點，第三方無法驗證
• 建議：把 KPI 換成可量測的 API 指標並公開時間序列資料

實作範例與工具建議

1) 資料上鏈路線（從 PDF 到 API）：

• 儘量直接匯出 CSV/JSON；若不得已用 PDF，採用定期的 ETL：

# 範例：自動抓取公開 CSV（pandas + requests）
import requests
import pandas as pd
url = "https://portal.data.metro.tokyo.lg.jp/example.csv"
r = requests.get(url)
open('data.csv','wb').write(r.content)
df = pd.read_csv('data.csv')
基本清理
df.columns = df.columns.str.strip()
df['date'] = pd.to_datetime(df['date'])

• PDF 轉 CSV：使用 tabula-py / camelot，自動化放入 CI (注意表格邊界與文字編碼)

2) API 設計建議

• 提供 RESTful JSON endpoints，並同時提供 CSV 存取
• 發佈 OpenAPI 規格檔與 JSON Schema
• 支援分頁、篩選、資料版本（v1/v2）以及 CORS
• 用 rate limit + API key 做基礎保護，但對公開資料應採匿名讀取優先

3) 資料品質持續整合（Data CI）

• 在資料發佈流程加入自動驗證：schema check、空值率警報、時間戳一致性
• 把資料集當成程式碼管理（Git + PR），資料改動走審查流程

政策可驗證性的衡量方法

• 把政策 KPI 換成可量測指標並提供 API：例如「窓口デジタル化率 80%」=> 提供 /services/digitalization_status 時間序列
• 建立公開 dashboard，底層拉取原始 API，讓第三方可以 replay

範例工作流程（部署一個自治體資料 API）

從現有系統導出結構化資料（CSV/JSON）

定義 JSON Schema / OpenAPI

建立 ETL pipeline（Airflow / GitHub Actions）自動抓取 + 驗證

部署 API（軽量的 FastAPI / Flask）並加上監控

提供文件（GitHub Pages / Swagger UI）與樣本資料

改善優先順位（短中長期）

• 短期（3ヶ月）：把關鍵報表從 PDF 改為 CSV，提供簡單 API
• 中期（6-12ヶ月）：全市級資料目錄化、OpenAPI 化、資料 CI
• 長期（1-2年）：整合 KPI 時序資料、公開治理 dashboard 與機械可讀性合規化

參考與出典

• e-Gov 行政 API 目錄: https://www.e-gov.go.jp/digital-government/api
• 東京都オープンデータAPI: https://portal.data.metro.tokyo.lg.jp/opendata-api/
• デジタル庁：政府情報システムのUI改善: https://www.digital.go.jp/policies/servicedesign/government-system-ui
• 内閣官房・行財政改革会議（機械可読性に関する決定資料）

まとめ

自治體與中央政府在政策與平台上已經在走對的方向，但要讓承諾真正被利用、被驗證，需要技術上的標準化與工程化：把資料從人看的格式轉成程式能讀的格式、把 API 視為第一次階段性產出並持續維護、並把資料品質納入 CI/CD。要是把這些基礎建好了，開放資料就能真正在創新與監督上產生價值！

おかむーから一言

我兩次創業、跑過 GovTech 前線，老實說：技術能讓政府承諾變成可破解、可重複、可驗證的東西。別讓宣言只停在白皮書，把資料當作基礎設施來維護吧！