コードで語るマニフェスト：政策実行の「観測設計」をつくる話

どうも〜おかむーです！今日はちょっとエンジニア寄りの話をしますよ〜。政策って作るまでが注目されがちだけど、実際に動かしているかどうかを継続観測する仕組みがめっちゃ重要なんです。

• 施策はAPIで拾えるデータだけじゃない。PDFや報告書に埋もれた数値が意外と多い
• エンジニア的に言うと、「観測設計（telemetry）」を最初に決めれば再現性・監査性がぐっと上がる
• 実装は既存のe-Stat/Japan Dashboardや交付金報告を活かして、イベント駆動＋バージョニングを入れるだけで一気に改善できる

結論

政策の「実行」を信頼できる形で可視化するには、データフォーマットの機械可読化（CSV/JSON/API）、観測イベント定義（発生時刻・主体・KPI値・ソースURI）、そしてデータの可検証性（バージョニングと署名）がセットで必要です。要するに、コードでトレースできる状態にしよう、ということです。

レポート本文

背景と現状

これ見てくださいよ：デジタル庁のJapan Dashboard（https://www.digital.go.jp/resources/japandashboard）やe-Stat（https://dashboard.e-stat.go.jp/）は統計可視化を推進してます。一方で、地方交付金の実績資料はPDFで配られることが多く（例：山口県の交付金実績PDF https://www.pref.yamaguchi.lg.jp/uploaded/attachment/160746.pdf）、CSVやAPIで一貫して取れないケースがまだあります。要するに、データが"断片化"してるんです。

技術的課題

• フォーマットの非整合（PDF vs CSV vs HTML）: 自動化パイプラインが止まる原因
• スキーマ不在: 同じ"交付金額"でも定義がバラバラで集約できない
• 更新頻度・バージョン管理不足: いつ数値が変わったか追えない
• 発生観測の欠如: 施策のライフサイクル（申請→決定→支出→評価）をイベント化してない

設計提案（エンジニア的に言うと）

1) 観測イベントスキーマを定義する

• event_id: UUID
• timestamp: ISO8601
• actor: {type, id}
• action: enum [申請, 承認, 支出, 測定, 報告]
• amount: number (通貨単位明示)
• kpi: {name, value, unit}
• source_uri: URL
• version: semver

要するに、施策を"ログ"として残すイメージです。

2) データ経路をイベント駆動にする

• ローカル自治体システム → メッセージブローカー（Kafka/RabbitMQ）→ データレイク（Parquet）→ ETL → 公開API + ダッシュボード
• 既存のe-Stat/Japan Dashboardは出力先として活用。最初に標準Eventを入れておけば横断集計が楽になります。

3) 機械可読化のレシピ

• CSV/JSON優先で公開。やむを得ずPDFなら、表抽出ツール（tabula-py / Camelot）でCSVに落として差分検証を自動化
• APIはOpenAPI仕様で公開して、CORSと認証を整備

サンプルJSON Schema（抜粋）:

{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"event_id": {"type": "string"},
"timestamp": {"type": "string", "format": "date-time"},
"action": {"type": "string"},
"amount": {"type": "number"},
"source_uri": {"type": "string", "format": "uri"}
},
"required": ["event_id","timestamp","action","source_uri"]
}

運用上の観点

• SLOを決める: 例）交付金報告の機械可読化率を90%にする
• モニタリング: 取り込み失敗率、スキーマ違反数、データ遅延時間を指標化
• 監査ログ: 変更履歴は必ずバージョン管理（GitやDelta Lake）し、公開差分を追えるように

実例で見る問題点

山口県の交付金実績PDF（https://www.pref.yamaguchi.lg.jp/uploaded/attachment/160746.pdf）を見ると「採択事業：2事業、実績額：15,289千円」といった要約はあるんですが、年次別・事業別のCSVがないと検証が面倒なんですよね。APIで1行ずつイベント化していれば、誰でも再現可能な検証ができます。

改善のインパクト

• 市民・研究者が再現可能な検証をできるようになる
• 不正防止や説明責任が強化される（証跡がコードで辿れる）
• 自治体間での集約・比較が容易になり政策設計の質が上がる

まとめ

政策の成果を"見せる"だけでなく、ソフトウェア設計として"観測可能な形"にすることが最重要です。APIと標準Eventスキーマ、バージョニング、そして自動化パイプラインを組めば、今あるダッシュボードや交付金レポートの価値が何倍にもなります！

おかむーから一言

テクノロジーで政策の信頼性を上げたいなら、まず観測設計をコード化しよう。データは嘘をつかないんで、コードで証明できる状態を作るのが勝ち筋です！