どうも〜おかむーです！今日はデータと政策をコード目線でつなぐ話をしますよ〜

• 国と自治体のKPI報告、PDFに埋まってばかりで機械的に追えない問題がある
• e-Govや都道府県カタログはあるけどスキーマや更新メタデータがバラバラで自動集約が難しい
• エンジニア視点で“API＋メタデータ＋CI”の設計を提案します！

結論

国（e-Gov API）や都道府県カタログ（東京都・埼玉県など）の存在は心強いんですが、交付金や総合戦略のKPI報告はPDF/HTML混在で、機械で追うにはまだ“接着剤”が必要です。要するに、データの可搬性（フォーマット・メタ情報・更新履歴）を自治体横断で標準化し、軽量な収集パイプラインとCIを回せば、政治判断のための定量観測がぐっと現実的になります。

レポート本文

現状把握：公開ソースと運用の実態

これ見てくださいよ、国の行政APIカタログ（https://www.e-gov.go.jp/digital-government/api）や東京都オープンデータ（https://portal.data.metro.tokyo.lg.jp/）、埼玉県ポータル（https://opendata.pref.saitama.lg.jp/）は健在です。けど、デジタル田園都市国家構想のKPI運用ガイドライン（https://www.chisou.go.jp/.../r5_guideline-checkaction.pdf）や須賀川市の実績評価（https://www.city.sukagawa.fukushima.jp/.../4045.html）はPDFやHTMLレポートに実績が埋まっているケースが多いんですよね。

エンジニア的に言うと、APIで叩けるレコードと、PDFに埋もれる数値が混在してるのは非常に厄介です！要するに自動化が壊れるということです。

技術的課題の切り分け

• フォーマット不統一（CSV/JSON/PDF/HTML）
• メタデータ欠落（last_updated, schema_version, checksum, source_authority）
• 更新履歴がないためロールフォワード検証が難しい
• スキーマ差分で表結合が破綻する（自治体ごとに列名・単位が違う）

実装イメージ：軽量な収集＋正規化パイプライン

エンジニアならわかると思うんですけど、API一本で解決する話なんですよね。サンプル設計：

1) データカタログ層（metadata catalog）

• 必須フィールド：dataset_id, title, description, source_url, format, last_updated, checksum, contact
• これを各自治体のカタログ（東京都、埼玉、Niigataなど）から定期巡回で取得

2) 収集層（harvester）

• CSV/JSONはそのまま取り込み
• PDFはTabula/Apache PDFBoxで抽出、抽出結果は検証ルールでスコア化
• e-Gov APIはSwaggerベースで叩く

3) 正規化層（transform）

• 小さなSQLスキーマにマップ（例：kpi_reports{jurisdiction, kpi_code, value, period, source_url, ingested_at}）

コード例（PythonでCSV/JSON/e-Gov APIを叩くイメージ）：

import requests, csv, json
e-Gov風API呼び出し
r = requests.get('https://www.e-gov.go.jp/api/some_endpoint')
data = r.json()
CSV取り込み
r2 = requests.get('https://portal.data.metro.tokyo.lg.jp/dataset/some.csv')
rows = csv.DictReader(r2.text.splitlines())
単純な正規化マップ
def normalize_row(row):
return {
'jurisdiction':'tokyo',
'kpi_code': row.get('KPI_ID'),
'value': float(row.get('value') or 0),
'period': row.get('period')
}

（要するに）このパイプラインをCI（GitHub Actions）で回し、差分が出たらSlackで通知、差分を監査できるようにすれば運用負荷が激減します。

KPIの数値目標と実績ギャップの扱い

交付金のKPIはガイドラインに記載されてますが、各自治体の評価ページ（須賀川市など）だと報告形式が異なるため、比較可能なタイムシリーズに変換するのが先決です。数値の正規化（単位統一、欠損扱いのルール）を明文化すれば、実績-目標の差を自動算出してダッシュボード化できます。

改善提案（具体的ステップ）

• データカタログの必須メタデータを国側が推奨（last_updated, schema_version, machine_readable=true）
• PDF由来の数値は"extracted_from_pdf"フラグと抽出スコアを付与
• Git-based datasetリポジトリで履歴管理（CSVをコミット）
• CIでフォーマット検証（Great Expectations等）とスキーマテストを実行
• 例：自治体は毎月CSVを/feeds/kpi/YYYY-MM.csvに置く約束をするだけでも世界変わる

まとめ

• いまの資源（e-Gov API、都道府県カタログ）は十分使える！ただし接着剤（メタデータ標準化＋自動収集パイプライン）が必要
• PDF混在は避けられないので、抽出スコアや出典メタデータで“信頼度”を可視化しよう
• 小さな技術投資（メタデータ欄の追加、CI導入、CSV運用ルール化）で政策観測が圧倒的に楽になる

おかむーから一言

テクノロジーで政策を計測可能にするのって、地味だけど超パワフルなんですよ。まずは小さくAPI一本、そこから変えていきましょう！