コードで語るマニフェスト：自治体データをエンジニア目線で検証する

どうも〜おかむーです！ 안녕하세요~ 오카무입니다!

• これ見てくださいよ：多くの自治体はPDFで政策資料を公開していて機械利用が難しい！
• 結論：APIと機械可読フォーマットがあれば政策評価の再現性がぐっと上がるんですよね〜
• 提案：データカタログ＋JSON Schema＋CIで「政策＝コード」に近づけよう！

結論

自治体／政府の公開データは「人が読むPDF」中心で、データ活用を阻むボトルネックになっている。エンジニア的に言うと、CSV/JSON APIとスキーマ、メタデータが一本化されれば、政策のKPIと実績のギャップ検証が自動化できる。要するに、政策をコード化してテスト可能にすることが急務なんです！

レポート本文

現状観察：公開サイトとフォーマット

これ見てくださいよ。長野県の公式サイト(pref.nagano.lg.jp)やデジタル庁(digital.go.jp)、GovTech東京の事例紹介では政策・PR資料やダッシュボードの取り組みが公開されている（検索結果参照）。ただ、実務で手を動かしてみると、データはPDFに埋め込まれていたり、画像付きのスライドでしか示されていなかったりして、機械処理が難しいケースが多いんです。

• PDF内表が多い → スクレイピング/手作業が必要
• CSVはあるがメタデータ不足 → カラム意味や更新頻度が不明
• API提供は部分的 → 統一的なデータカタログがない

要するに、人間には読めてもプログラムには使えない、という感じです。

技術的な評価ポイント

機械可読性：CSV/JSON/OpenAPIの有無

スキーマ管理：JSON SchemaやTable Schemaでのバリデーション

メタデータ：DCATやschema.orgによる説明

アクセス：認証、レート制限、CORSの有無

再現性：データ更新履歴とバージョン管理

たとえば「デジタル田園都市国家構想交付金」の評価資料（総務省のガイドラインPDF）ではKPIと実績の照合が必要になるが、実績値がPDFの図表に埋められていると、自動集計できず再現性が下がる（検索結果のガイドライン参照）。

実践的なコード例（サンプル）

エンジニア的に言うと、API一本で解決する話なんですよね。CSVが公開されていればこうやって読みます：

import requests
import pandas as pd
url = 'https://example.prefecture.gov/data/kpi.csv'
r = requests.get(url)
r.raise_for_status()
df = pd.read_csv(pd.compat.StringIO(r.text))
print(df.head())

PDFしかないときはTabula/Camelotで抽出→検証スクリプトで型チェック、というワークフローになります。

政策とデータのギャップ分析（例）

• 政策目標（KPI）: 例えば「住民サービスオンライン化80%」
• 公開実績: PDFレポートに断片的に記載

問題点：KPIが機械的に集計できないため、進捗の時系列分析や外部による再評価が困難。対策として、KPIは時系列CSV/JSONで公開し、各指標に対してOpenAPIエンドポイントを用意するとよい。

改善提案（具体策）

• データカタログ導入（DCAT）でリポジトリ化
• 各データセットにJSON Schema/Table Schema付与
• KPI用のREST APIを用意し、認証はOAuth2・トークンで管理
• CIパイプラインでデータ品質チェック（スキーマ準拠・欠損率・値域チェック）
• PDFは一次公開資源として残し、機械可読版（CSV/JSON）を公式に併記
• オープンソースのダッシュボード＋埋め込みwidgetで可視化

技術スタックの例：e-Stat API（国の統計API）を参考に、自治体側も同様のREST APIを持つと、外部エコシステムでの再利用が一気に進みます。

まとめ

• 現状：PDF中心の出版が依然多く、機械可読性が低い
• 必要：API＋スキーマ＋メタデータで政策をコード化
• 効果：再現性ある評価、自動モニタリング、外部イノベーション促進

おかむーから一言

テクノロジーで政策をテスト可能にしよう。コードで語るマニフェスト、始めれば結果はついてくるんですよ！