コードで語るマニフェスト:日本政府データの現場から見る技術検証

IT 정책 제안
コードで語るマニフェスト:日本政府データの現場から見る技術検証

안녕하세요~ 오카무입니다! 오늘은 정부·지자체 데이터와 시스템을 코드 관점에서 훑어보는 브리핑을 가져왔어요. 엔지니어적 관점에서 정책의『데이터』과『エンジニア링』으로 검증해봅시다~

  • 중앙 정부는 Japan Dashboard와 e-Stat 등으로 시각화하고 있지만, 실제 기계가 읽을 수 있는 형태(콘텐츠의 CSV/JSON/API)는 아직 부족
  • 최근 "行政データにおける機械可読性に関するルール"(決定、2026/03/31)로 개선 신호는 있으나 시행과 데이터 연계가 과제
  • PDF에 묻힌 KPI·交付金実績은 자동화로 추출·검증 가능하지만, API·스키마·ID가 부족해 신뢰성 확보가 어려움

結論

정부는 디지털 전환의 인프라(デジタル庁、Japan Dashboard、e-Stat)를 갖춰가고 있지만, 실질적인 오픈데이터 품질은 아직 '중간' 수준입니다. 핵심은 데이터의 기계 가독성(파일 포맷·스키마·ID 체계)과 API-first 접근으로 정책의実績を継続的に検証 가능한 구조로 바꾸는 것! 엔지ニア視点では、CSV/JSON/REST API + スキーマ/仕様書 + バージョニングが最低条件입니다。

レポート本文

現状のスナップショット

  • 公式:digital.go.jp、cas.go.jp(デジタル田園都市)や内閣官房の資料にはKPIやロードマップが記載(例:https://www.digital.go.jp/、https://www.cas.go.jp/jp/seisaku/digitaldenen/sougousenryaku/)
  • 可視化:Japan Dashboardやe-Statの統計ダッシュボードは良い起点(https://www.digital.go.jp/resources/japandashboard、https://dashboard.e-stat.go.jp/)
  • 問題点:多くの行政資料はPDFや報告書に埋まっており、CSV/JSONでの配信が一貫していない(機械可読性ルールの決定は2026/03/31付)

これ見てくださいよ:交付金のKPIと実績はchisou.go.jpのガイドラインPDFに書いてあるけど、表をそのままPDFで出されると自動集計が面倒なんですよね!要するに、データを人間向けのレイアウトで出すだけだと再利用性ゼロってことです。

技術的な評価ポイント

  • フォーマット:PDF vs Excel/CSV/JSON。PDFはレイアウト重視で機械解析が必要、Excel/CSVは直接パース可能
  • ID体系:都道府県・市区町村はJISコードで統一してるか?(統一されていれば結合が楽)
  • API:e-StatはAPIを公開しているが、交付金や補助金の実績はAPIで直結されていないケースが多い
  • スキーマとメタデータ:DCATやData Packageでメタデータ化しているか
  • バージョニングとリンケージ:時系列データや改定履歴が明示されているか

実際に手を動かす——コード例

エンジニア的に言うと、API一本で解決する話なんですよね。例えばe-Stat API呼ぶ場合(appIdは取得してね):

import requests

params = {

'appId': 'YOUR_APP_ID',

'statsDataId': '0003xxxx',

'metaGetFlg': 'N'

}

r = requests.get('https://api.e-stat.go.jp/rest/2.1/app/json/getStatsData', params=params)

data = r.json()

要するにJSONで取れれば時系列比較も楽

PDFに埋もれた表を自動化するならtabulaやpdfplumberで抜くのが現実的:

import tabula

dfs = tabula.read_pdf('kpi_report.pdf', pages='all', multiple_tables=True)

あとはpandasで正規化して、JISコードでマージ

SQLでKPIと実績のギャップを確認する例:

SELECT region_id, kpi_target, SUM(actual) as actual

FROM kpi_table JOIN disbursement_table USING(region_id, year)

GROUP BY region_id, kpi_target

HAVING actual < kpi_target;

改善提案(具体的)

  • 全てのKPI/交付金実績をCSV/JSONの定常配信にする(最低でも毎月更新)
  • OpenAPI仕様でAPIを定義し、認証はAPIキーで柔軟に管理
  • スキーマ定義(例:Data Package/JSON Schema)とサンプルデータを同梱
  • JIS行政区画コードでIDを標準化し、他データ(人口・産業)と結合可能に
  • データのバージョン管理と変更ログを公開(誰がいつ何を変えたか)
  • PDFは最終報告向けに残してもいいが、機械読取用の一次データは必ず機械可読フォーマットで公開
  • これらは技術的にはさほど難しくないです。API設計、CIでCSV-JSON生成、Schemaテストを入れるだけで品質が劇的に上がるんですよ!

    まとめ

    • デジタル庁やJapan Dashboardは良い基盤だけど、実態のデータ配信はまだ改善余地あり
    • 決定(2026/03/31)のような機械可読性ルールは前進だが、実務での運用とスキーマ設計が勝負
    • エンジニア的には『CSV/JSON + API + スキーマ + ID統一 + バージョン』のセットがあれば、政策の実績検証は自動化できる

    おかむーから一言

    테크로 행정을 업그레이드하는 건 결국 작은 자동화들이 쌓이는 일입니다. 코드로 약속을 검증할 수 있는 사회, 같이 만들어봅시다!

    공유하기