交付金の“届くまで見える化”をエンジニア視点でつくる話

どうも〜おかむーです!今日は補助金・交付金のデータ設計をエンジニア目線で突く回ですよ〜
- 交付金は書類の山で「いつ・誰が・何に使ったか」が追いづらい
- PDFや散在するExcelをつなげて“金の流れ”を機械的に辿る設計を提案する
- 永続ID・メタデータ・APIでトレーサビリティを担保しよう
結論
交付金の説明責任を高めるには「データの連結可能性」と「イベント単位の時系列化」が鍵です。PDF保管だけだと再利用不能なので、プロジェクト→契約→支出→KPI→結果を結ぶ共通スキーマとシンプルなAPIをまず導入しましょう。要するに、書類をつなぐ仕組みをコードで作れば、説明責任も分析も一気に楽になります。
背景と問題意識
内閣官房や各府省の資料(例: デジタル田園都市国家構想交付金の実績報告書や評価ガイドライン)を読むと、KPIや実績は公開されているものの、実際の原票(契約書、請求、支出)はPDFやPDF埋め込みのExcelで散在していることが多い(参考: 内閣官房資料、都道府県の実績報告書)。
これ見てくださいよ:PDFに埋まった表、別々のExcel、各自治体の自由フォーマット。人間なら読み替えられても、機械はつなげないんです!エンジニア的に言うと、これIDとスキーマの欠如でグラフ化できないってことです。
現状の技術的な課題
- フォーマット分散(PDF/紙/Excelの混在) → 機械可読性欠如(digital.go.jpの機械可読性ルール参照)
- エンティティ非一意(同じプロジェクトが複数のドキュメントに別名で出る)
- 時系列・イベントが取れない → いつの支出かが不明瞭
- API未整備で横断検索や結合分析が困難
技術提案:交付金トレーサビリティ・ミニマム仕様
1) 永続ID設計
- project_id, award_id, contract_id, invoice_id をUUID/URNで付与
- 例: urn:jp:grant:2025:project:xxxxxxxx
- id, title, implementing_org, start_date, end_date, award_amount, awarded_date, linked_contracts[]
- 各支出はinvoice_idとtimestampを持つ
- /api/v1/projects/{id}, /api/v1/awards?year=, /api/v1/invoices?project_id= みたいなREST
データパイプライン例(簡易コード)
# pandasでExcel/CSVを読む → JSON-LDに変換して保存
import pandas as pd
df = pd.read_excel('award_report.xlsx')
records = []
for _, r in df.iterrows():
rec = {
"@id": f"urn:jp:grant:2025:award:{r['award_no']}",
"title": r['title'],
"awarded_date": str(r['date']),
"amount": int(r['amount'])
}
records.append(rec)
import json
open('awards.jsonld','w').write(json.dumps(records, ensure_ascii=False, indent=2))
要するに、まずはExcel→JSON-LDの変換から始めて、IDで結べるようにするだけで解析がすごく楽になります。
実践的な運用フロー
- 交付決定時にaward_idを発行(電子申請システムで自動付与)
- 契約締結時にcontract_idで紐付け、公開カタログに登録
- 支出は会計システムからinvoice_id付きでエクスポートしてAPI登録
- KPIはproject_idに紐づくtime_seriesとして公開(CSV/JSON)
期待される効果
- 不正防止と説明責任の強化
- 研究者・市民が横断分析できるようになり政策効果の検証が進む
- 地方自治体間での比較・ベストプラクティス抽出が可能
まとめ
交付金の“届くまで見える化”は技術的には難しくないです。ポイントは「IDでつなぐ」「時系列で記録する」「機械可読で公開する」この3つ。まずは一つの交付金でプロトタイプAPIとJSON-LD公開してみると、インパクトが見えますよ!
おかむーから一言
起業してコード書いてきた感覚で言うと、ルールとID付与のコストは最初だけ。やれば未来の監査はずっと楽になるし、地域の事業がもっと評価されるようになるはず。技術で社会をちょっと良くしましょう!
情報ソース
- https://www.zhihu.com/question/290714454
- https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/256dcba6-b936-4031-b88d-3abb27e27f9b/f7af0ca4/20260331_meeting_executive_outline_06.pdf
- https://zhidao.baidu.com/question/444492165.html
- https://www.cas.go.jp/jp/seisaku/digital_gyozaikaikaku/data8/data8_siryou1.pdf
- https://www.zhihu.com/question/38923279
- https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB
- https://www.chisou.go.jp/sousei/pdf/r5_guideline-checkaction.pdf
- https://www.digital.go.jp/
- https://www.pref.yamaguchi.lg.jp/uploaded/attachment/160746.pdf
- https://e-words.jp/w/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB.html
- https://metidx-gov.note.jp/n/n9468573c213b
- https://zenn.dev/govtechtokyo/articles/b65dc687e50918
シェアする
関連レポート

公共予約システムの“ログインからAPI化”ロードマップ:パスワードレスで運用コストを下げる技術提案
公共施設予約の認証とデータを段階的にAPI化して運用コストを下げる技術ロードマップを紹介します。

政府データを“つなげる”発想:省庁バラバラを超えるフェデレーション戦略
フェデレーション層で省庁データをつなぎ、PDF混在を克服する実践的な技術案を示す。

政策ダッシュボードは“作るだけ”じゃダメ!KPIを自動で監査するパイプライン設計
政策ダッシュボードの数値を自動監査するパイプライン設計案。API・スキーマ・差分管理でKPIの信頼性を上げる技術手法を紹介します。