どうも〜おかむーです！今天来聊点既技术又政策的东西，用代码和数据把宣言（マニフェスト）掰开看看里面有没有料〜

• 这篇文章用东京、函馆、新潟、数字庁等公开数据例子，从机器可读性、API 支持、数据质量到政策目标兑现做技术检查
• 重点在「PDF vs CSV」「编解码与规范」「API/スキーマの有無」，并给出具体的代码样例与改进建议
• 最后给出可实现的工程化改进路线，方便自治体把开数据从展示变成可持续的治理基础

結論

政府/自治体的数据基础设施已经有了分水岭：有些机关把数据当作「資料」，只求公開；有的开始当作「API 资产」，可以直接驱动服务与计量。要するに、これは技術与治理的联合问题：统一的格式、明确的 API、以及持续的品質监测，才是把宣言变成可检视政策的关键。

レポート本文

何を見たか（データソース）

• 東京都オープンデータカタログ（catalog.data.metro.tokyo.lg.jp）——CKAN 風のカタログで CSV やメタデータが多数（例：公共施設一覧、地域別人口など）
• 北海道函館市の CSV 一覧（harp.lg.jp/opendata）——自治体単位で CSV を整備する例
• 新潟市の CSV マニュアル（city.niigata.lg.jp の PDF）——CSV の作り方を明文化している点は良い
• デジタル庁の医療機関 CSV（digital.go.jp）など、中央の実例

これらはいずれも「公開」はしているが、扱いやすさは様々だというのが第一印象。你看、同じ CSV でも文字コード、列名、日付フォーマットがバラバラだと自動化が壊れるんですよね。

技術観点の問題点と具体例

1) PDF に埋まったデータ vs CSV

• 多くの政策資料は PDF 併記で、機械可読データが付随していないケースがまだある（予算資料や報告書）。PDF は人間に優しいけど機械には厳しい。要するに、二次利用を促したければ CSV/JSON/API を優先公開すべき。

2) 文字コードとエンコーディング地雷

• 日本の自治体データは Shift_JIS / UTF-8 / BOM の混在が散見される。読み込みでエラーになるのは日常茶飯事。

3) スキーマ不在・列名の非標準化

• 「緯度／経度」が lat/lon、緯度,経度、LATITUDE,LONGITUDE と散らばるとパイプライン作成が面倒。スキーマ宣言（JSON Schema / Frictionless Data）で統一すべき。

4) API の有無・メタデータ不足

• 東京都のカタログは API を提供しているが、自治体によっては単なるファイル置き場になっている。更新日やバージョン履歴が無いと「いつの数字？」がわからない。

5) 政策目標と実績の可測化の欠如

• 予算や公共投資の CSV（例：内閣府の公共投資テーブル）からは検証可能だが、目標（宣言）と紐づくデータセットが整備されていないことが多い。目標->中間指標->実績を結ぶデータモデルが必要。

エンジニア的に言うと（コード例）

これ見てくださいよ。以下は自治体の CSV を拾って、文字コード問題を吸収しつつ標準化する Python/pandas の簡単な例です：

import requests
import io
import chardet
import pandas as pd

url = 'https://catalog.data.metro.tokyo.lg.jp/dataset/xxxx.csv'
res = requests.get(url)
enc = chardet.detect(res.content)['encoding']
明示的に shift_jis か utf-8 を当てるのが現実的
df = pd.read_csv(io.BytesIO(res.content), encoding=enc)

カラム標準化の一例
col_map = {c: c.strip().lower() for c in df.columns}
df.rename(columns=col_map, inplace=True)

緯度経度を統一して GeoJSON に
if '緯度' in df.columns and '経度' in df.columns:
df = df.dropna(subset=['緯度','経度'])
df['geometry'] = df.apply(lambda r: {'type':'Point','coordinates':[float(r['経度']),float(r['緯度'])]}, axis=1)

出力
print(df.head())

要するに、この手順を自治体側で自動化しておけば、外部開発者は API を叩くだけで済むんです。

政策の数値目標と実績のギャップをどう検証するか

• ステップ1：宣言文書（マニフェスト、閣議決定、方針）から KPI を抽出して機械可読化（例：CSV/JSON）
• ステップ2：関連データセット（予算、支出、事業進捗、利用統計）と結合して時系列で比較
• ステップ3：自動アラート（CI）で目標から乖離している場合はレポート作成

簡単な SQL 例（予算 vs 実績）：

SELECT
p.year,
p.budget_amount,
coalesce(a.actual_amount,0) AS actual_amount,
(coalesce(a.actual_amount,0) / p.budget_amount) AS spend_ratio
FROM policy_targets p
LEFT JOIN actuals a ON p.project_id = a.project_id AND p.year = a.year;

この比率を自治体公開ダッシュボードに載せれば、市民もチェックしやすい。

改善提案（実務的ロードマップ）

• 短期（3ヶ月）: CSV マニュアル整備（新潟市の例を参照）、全データのエンコードを UTF-8 に統一
• 中期（6-12ヶ月）: JSON Schema / Frictionless Data を導入してスキーマ定義、CKAN 等で API を標準化
• 長期（1年〜）: データパイプラインの CI 化（エンコーディングチェック、カラムチェック、品質ゲート）、オープンデータの SLA を明文化

技術スタックの提案：GitHub Actions + Great Expectations（品質検証）+ S3/CloudFront（配信）+ CKAN/OpenAPI（カタログ & API）。

活用可能性の提案

• 公共施設一覧 × モビリティデータ = 高齢者向け移動支援の最適配置
• 予算・実績データの公開→市民ダッシュボード→市民参画のサイクル化
• 医療機関 CSV を使った地域医療アラート（感染症時の対応力向上）

まとめ

自治体のオープンデータは「既に資源」になり得る一方で、形式やメタデータの不揃いが利活用の大きな阻害要因になっているんです。要するに、ただ公開するだけじゃダメで、エンジニアがすぐ使えるような“API級の品質”で出していくことが肝心。PDFを残すのはOKだけど、それとは別に機械可読な CSV/JSON/API を作るべきだと強く思います！

おかむーから一言

テクノロジーで社会をアップデートするって言うと大げさに聞こえるかもだけど、データの小さな改善が政策の透明性をぐっと上げるんですよ。エンジニアとして、そして起業家として、そこにコミットしていきたい！