コードで語るマニフェスト：政策指標の出自（プロヴェナンス）をエンジニア視点で可視化する

どうも〜おかむーです！今日はちょっとエンジニアっぽい話をしますよ〜

• これ見てくださいよ：政府のダッシュボード（Japan Dashboard、e-Stat、RESAS）は便利だけど、指標の“出自”が見えにくいことが多い
• エンジニア的に言うと、政策KPIにもソフトウェアの「観測性（observability）」が必要なんですよね
• 要するに：データの系譜（provenance）を標準化して、APIとメタデータで繋ぐと政策の信頼度が上がるという話です

結論

政府・自治体のダッシュボードは見た目の可視化は進んでるけど、データ出自（どのCSV/API/報告書から取ってきたか）、集計ロジック、更新履歴が散逸している。エンジニア的にはW3C PROVやJSON-LDでスキーマ化し、データ契約（data contract）と自動検証パイプラインを導入するのが現実的な第一歩です。

レポート本文

現状把握（参照元）

政府が提供する代表例として、Digital庁のJapan Dashboard、総務省のe-Statダッシュボード、RESAS（地域経済分析システム）がある（参照：digital.go.jp、e-stat.go.jp、stat.go.jp）。これらは可視化レイヤーとして有用だけど、以下の技術的課題が見えるんです。

技術的な課題点

• 出所の明示不足：ダッシュボード上のグラフがどのCSV/API/統計表に由来するか不明瞭
• スキーマ不一致：CSVの列名・型がバラバラでパイプライン化が面倒
• メタデータ欠落：更新タイムスタンプ、ライセンス、生成クエリが見えない
• 機械可読の不足：PDF報告書や散在するCSVが混在していて自動化困難

エンジニア的解像度で見ると

エンジニアならわかると思うんですけど、政策指標もソフトウェア資産です。要するに「どのソース→どの変換→どの集計」がコードやメタデータで追えることが重要。ここで使える概念と実装案を挙げます。

• プロヴェナンス記録（W3C PROV）でデータラインを記述
• JSON-LD / schema.org Dataset で機械可読メタデータを付与
• データ契約（期待スキーマ）を jsonschema で定義しCIで検証
• チェックサム／行数／Null率などの品質メトリクスを毎日収集

実装イメージ（コード例）

curlでe-Stat APIを叩く例（具体的なAPIキーは環境変数で管理）:

curl -s "https://api.e-stat.go.jp/rest/3.0/app/json/getStatsData?appId=$E_STAT_KEY&statsDataId=0000020201" | jq .

Pythonで簡易的な鮮度チェックとchecksumを取る例:

import requests, hashlib, pandas as pd
r = requests.get(csv_url)
data = r.content
sha = hashlib.sha256(data).hexdigest()
df = pd.read_csv(io.BytesIO(data))
print('rows', len(df), 'sha', sha)

JSON-LDでデータセットのメタを付ける例:

{
"@context": "https://schema.org/",
"@type": "Dataset",
"name": "地方創生指標 - 失業率",
"distribution": [{"@type": "DataDownload","contentUrl": "https://.../unemployment.csv"}],
"variableMeasured": "unemployment_rate",
"sameAs": "https://www.e-stat.go.jp/..."
}

政策目標と実績のギャップをコードで追う

目標表（policy_targets）と観測表（observations）を結合して差分を出すのはSQL一本でできる話です。例:

SELECT p.indicator, p.target_value, o.date, o.value, o.value - p.target_value AS gap
FROM policy_targets p
JOIN observations o ON p.indicator = o.indicator
WHERE o.date BETWEEN p.start_date AND p.end_date;

要するにダッシュボードは終点じゃなくてパイプライン全体の可視化が必要なんです！

提案：導入優先度の高い施策（実務寄り）

• 全ての公開指標にDataset JSON-LDを必須化（contentUrl, provenance, updateFrequency）
• CSV/JSONのスキーマをjsonschemaで定義、リリース時にスキーマタグ（version）を付与
• 小さなCIジョブ：毎朝CSVを取得してchecksum・行数・Null率をSlackへ通知
• W3C PROV形式で集計ジョブのログを出力してトレーサビリティを担保

まとめ

見た目のダッシュボードだけじゃ政策の信頼性は担保できない。エンジニア的には「データの出自」「スキーマ契約」「自動検証」「メタデータ公開」がセットで必要です。Japan Dashboardやe-Stat、RESASの資産を活かすなら、まずはメタデータと小さなCIから始めましょう。

おかむーから一言

テクノロジーで政策をアップデートするのは地味な作業の積み重ねですけど、これが一番効く。まずは一つの指標にプロヴェナンスを付けて、そこから仕組みを横展開しましょう！