どうも〜おかむーです！今日はちょっとエンジニアっぽい話をしますよ〜。地方のデジタル交付金って、発表資料だとキラキラしてるけど、実際の使途や効果をコードで突き合わせるとツッコミどころ満載なんですよね。

• オープンデータ・ポータルの横断で交付金実績をつなげる手法を示す
• CSV/PDFの混在、メタデータ欠乏、識別子不在が監査の障害になっている
• 最低限のデータ設計と自動化レシピで再現性を担保する方法を提案する

結論

交付金の説明責任は「データの連結可能性」と「証跡の機械可読化」で大きく改善できる。都道府県や市のオープンデータ（例：東京都オープンデータカタログ、埼玉県オープンデータ、新潟市のCSV指針）、国のポータル（デジタル庁、デジタル田園都市構想交付金ページ）を“キーで繋ぐ”最小限のスキーマとCI的な照合を組めば、監査可能なパイプラインが作れるんですよね。

レポート本文

現状観測：どこで詰まるか

これ見てくださいよ。地方ページはPDFで事業報告を出してたり、オープンデータはカタログに散らばってたりします（例：東京都カタログ https://catalog.data.metro.tokyo.lg.jp/dataset、埼玉県 https://opendata.pref.saitama.lg.jp/、新潟市のCSV手引き https://www.city.niigata.lg.jp/... ）。

主な問題点:

• 一意の事業IDがない（名称だけで紐付けが困難）
• PDF↔CSV混在で自動集計できない
• メタデータ（更新日時、出典URL、スキーマ説明）が不足
• 地方ごとにカラム名や単位がバラバラ

要するに、データを機械的に結合できないと“再現性のある監査”にならないということです。

技術的にどう繋ぐか（設計レシピ）

エンジニア的に言うと、これは『最小限の正規化とプロヴェナンスの付与』でほぼ解決します。実装レシピを示すと：

共通キー設計

- 採用するキー例：country_code(=JP)/pref_code(JIS)/municipality_code/JFY(会計年度)/grant_program_id(交付金コード)/project_id

- JISコードは地方データの正規化に使える（自治体データと接続するとき便利）

機械可読の事業台帳フォーマット（CSV/JSON）

- 推奨カラム：project_id, program_id, award_amount, disbursed_amount, start_date, end_date, contractor_name, source_url, source_hash, updated_at

- source_urlでPDFや契約書の原典を指し、source_hashで証跡を固定

データ取得・突合コード（簡易例）

import pandas as pd
from urllib.request import urlretrieve

公開CSVを取得
url = 'https://opendata.pref.saitama.lg.jp/datasets/...'  # 例
df = pd.read_csv(url)

別データ（国の交付金台帳）とジョイン
national = pd.read_csv('https://www.chisou.go.jp/sousei/about/kouhukin/index.csv')
merged = pd.merge(df, national, left_on=['project_id','pref_code'], right_on=['project_id','pref_code'], how='outer')

不一致を抽出
mismatches = merged[merged['award_amount_x'].fillna(0) != merged['award_amount_y'].fillna(0)]
print(mismatches.head())

要するに、API一本で解決する話なんですよね。あとはちょっとした正規化とハッシュ確認を入れれば証跡が取れます。

ファジーマッチと正規化

- 事業名だけでつなぐ場合はfuzzywuzzyやLevenshteinでマッチ度を出す

- だが、これに頼ると誤検知が増える。だから事業IDの標準化を自治体間で約束するのがベター

自動化と監視

- GitリポジトリでCSV＋schema.jsonを管理

- 定期ジョブでsource_hashを比較し、差分があればアラート

- 差分が出たら人手レビューのフローを起動

ケーススタディ：須賀川市の評価公開をどう扱うか

須賀川市の実績評価ページ（https://www.city.sukagawa.fukushima.jp/...）は外部有識者の検証が載っていて良い例。ただ、これを機械的にトラックするには評価レポート中の表をCSV化して、交付金台帳と突合するだけで“数値の辻褄”を自動で出せますよね。

改善提案（具体的アクション）

• 交付金：全ての公表にproject_idを付与する（国→都道府県→市町村で伝播）
• 書類：契約書・検収をPDFで出すなら、そのPDFのSHA256をDLページに付記
• ポータル：データセットにschema.json(CSVW)を付ける（カラム説明・型・単位）
• 最低限のAPI：データ更新をGETできるエンドポイントを用意

まとめ

交付金の説明責任はフォーマットの問題が8割。APIやCSVが揃えば、あとはコードで照合して差分を監査フローに落とし込めます。東京都・埼玉・新潟のオープンデータカタログやデジタル庁の交付金ページを繋げれば、地方レベルの実績評価が自動化できるんですよね。改善は小さな変更（ID付与、ハッシュ付記、スキーマ公開）で大きく効きます。

おかむーから一言

テクノロジーで説明責任を当たり前にするのがミッションです。まずはproject_idとsource_hashを1つの自治体で実装してみてください。動くと世界変わりますよ！