交付金KPIの“意味合わせ”をコードでやってみたら地方DXが動き出す話

どうも〜おかむーです！今日はデジタル田園都市国家構想交付金まわりのKPIを、エンジニア視点で「意味合わせ（semantic alignment）」してみた話をしますよ〜

• 交付金のKPIは各自治体で表現がバラバラ、比較・集計が難しい
• 要するに「KPIの語彙（ボキャブラリ）」を機械可読にして仲介レイヤーを作れば一気に分析可能になる
• 技術的にはスキーマ＋マッピング＋簡易ツールチェーンで実装できます！

結論

デジタル田園都市国家構想の交付金KPIは、PDF中心の公開とローカルな定義差異で横断分析が死にやすい。エンジニア的に言うと、ここは「語彙の正規化」と「軽量なKPIレジストリAPI」を入れてやれば解決する話なんですよ。要するに、KPIを単なる文字列で扱うんじゃなくて、ID・型・単位・算出式を持つ構造データにしようということです。

レポート本文

背景（これ見てくださいよ）

内閣府や自治体の評価資料（例: https://www.chisou.go.jp/sousei/.../r6_houkokusho-suishin.pdf や各自治体の評価結果PDF）を読むと、ほとんどがPDFでKPIや達成状況が報告されているんです。要するに人間には読めるけど、機械には読みにくい。

エンジニア的に言うと、KPIが「ラベル」だけで渡されると、同じ意味の指標が「利用者数」「利用者数（累計）」「利用者（名）」みたいに複数表現されてしまい、集計や比較ができないんです。

問題点の技術的切り口

• フォーマット: PDF中心、CSVやJSONの公式公開が少ない（PDF埋め込み表が多い）
• 語彙の非一貫性: 指標名に単位や母集団が含まれる、算出式が不明
• バージョン管理欠如: KPI定義が年度で変わっても履歴化されない
• メタ情報不足: データ取得日時、測定方法、信頼区分などが欠落

改善設計: KPI Ontology + レジストリAPI（新しい切り口）

「交付金KPIをSemantic Layerで仲介する」という考え方を提案します。既存のオープンデータ化（CSV化）だけではなく、KPI自体の意味を機械で扱えるようにするのがポイント。

主なコンポーネント:

KPIメタモデル（JSON Schema）

KPIレジストリ（軽量REST API）

マッピング表（自治体側の表現 → レジストリID）

ETLツール（PDF抽出＋マッピング＋バリデーション）

UI（自治体の職員が定義を登録・確認できる簡易画面）

KPIメタモデル（例）

{
"id": "kpi:service_users_monthly",
"label": "月間サービス利用者数",
"description": "サービスを月間で利用した一意の利用者数",
"data_type": "integer",
"unit": "people",
"calculation": "COUNT(DISTINCT user_id) over calendar_month",
"recommended_source": ["service_db.users_events", "survey"],
"version": "2026-01",
"tags": ["digital_inclusion","usage"]
}

要するに、KPIはIDと算出式、型、単位、推奨ソースを持つべきです。これがあれば自治体ごとのラベル差をIDで吸収できます。

レジストリAPI（簡易仕様）

• GET /kpis -> 全KPIの一覧
• GET /kpis/{id} -> 指定KPIのメタ
• POST /mappings -> 自治体表記とKPI IDの紐付け
• GET /mappings?pref=xxx -> ある自治体のマッピング一覧

実装のヒント: PDFからKPIをつなげるワークフロー

エンジニア的に言うと、これは3ステップでかなり自動化できます。

1) PDF抽出: tabula-py / camelot / OCR(Tesseract)

2) 正規化: 正規表現 + 近似文字列マッチング（fuzzywuzzy / RapidFuzz）でラベルをレジストリIDにマップ

3) バリデーション: JSON Schemaで型チェック、単位チェック

短いPythonの疑似コード:

from rapidfuzz import process
registry_labels = [k['label'] for k in registry]
for extracted_label in pdf_labels:
match, score = process.extractOne(extracted_label, registry_labels)
if score > 80:
map_to = registry_by_label[match]['id']
save_mapping(pref, extracted_label, map_to)

政策目標と実績ギャップをどう見せるか

KPIがID化されれば、国と自治体のKPIを縦横に並べて自動集計できます。例えば「導入した事業のKPI達成率」を時間軸でプロットして、目標値との差を可視化。PDFから手で拾ってExcelをつなぐ泥臭い作業を減らせるんです。

運用面の工夫（現場フレンドリー）

• UIで担当者が「この表の列はどのKPI？」とワンクリックで割り当てられるようにする
• KPI定義はバージョン管理（Git-like）で履歴を残す
• レジストリは認可済みKPIと草案KPIを分ける（現場が草案を提案できる）

期待効果

• 横断比較が可能になり、評価の信用度と再利用性が上がる
• 分析工数が大幅に削減され、自治体は評価より改善にリソースを回せる
• 民間や研究者による二次利用・ダッシュボード作成が進む

まとめ

デジタル田園都市交付金のKPIは情報資産だけど、今は語彙がバラバラで使いづらい。解決策は単純で、KPIを機械可読なメタデータにしてレジストリで仲介すること。これだけでPDF漁りの工数が減り、政策の比較と改善がぐっと現実的になります。小さくはじめて、徐々に自治体コミュニティで語彙を育てていけば良いんです！

おかむーから一言

テクノロジーはツールでしかないけど、正しい語彙を揃えると社会の“測れる力”が跳ね上がるんですよ。コードで意味を揃えて、政策をもっと使えるものにしていきましょう！