コードで語るマニフェスト：政府データの今と技術的改善案

どうも〜おかむーです！오늘은 정부·지자체 데이터와 시스템을 코드와 엔지니어링 관점에서 한 번 까볼게요〜

• 이 글의 핵심은: 공공데이터가 "열려 있음"과 동시에 "활용 가능"하려면 기계가 읽을 수 있는 형식과 일관된 API가 필수라는 것!
• 현황 요약: Digital庁·総務省는 표준화·대시보드( e-Stat, Japan Dashboard )를 제공 중이지만, 주요 지표는 PDF에 묻혀있거나 CSV 제공이 일관적이지 않음.
• 제안 요약: CSV/JSON 전환, 공통스키마(DCAT/JSON Schema), 데이터 CI·검증 파이프라인, 지방PMO 툴과의 연계로 실적 추적 자동화!

結論

정부와 지자체가 공개한 데이터의 양은 늘고 있지만, エンジニア的に言うと「機械可読性（machine-readability）」と「API化」がまだ主要ボトルネックです。要するに、データを人間が見る用のPDFで出すだけじゃ、エコシステムは育たないということです。

レポート本文

現状サマリ — ソース別に見ると

• Digital庁（https://www.digital.go.jp/）: デジタル社会の司令塔としてダッシュボードや政策資料を公開。Japan Dashboard（https://www.digital.go.jp/resources/japandashboard）で統計可視化を推進しているのは良い動き。
• e-Stat / 統計ダッシュボード（https://dashboard.e-stat.go.jp/）: 主要統計をグラフ化しておりAPIも存在するが、地方の細かいKPIまでのカバレッジは限定的。
• 総務省の自治体システム標準化（https://www.soumu.go.jp/...）: 標準化PMOツールで進捗管理している。一方で、各自治体が出す実績資料はPDFベースが散見される（例: 地方交付金の評価PDFなど、https://www.chisou.go.jp/sousei/pdf/r5_guideline-checkaction.pdf）。
• 事例: 須賀川市のデジタル田園都市評価（https://www.city.sukagawa.fukushima.jp/...）は外部有識者の検証を出しているが、評価表やKPI実績がCSV/JSONで公開されていれば再現性のある検証が容易になる。

これ見てくださいよ、資料自体は多くても形がバラバラだと二次利用が全然進まないんですよ！

技術的検証ポイント

フォーマット（PDF vs CSV/JSON）

- 問題: PDFに重要指標が埋め込まれているケースが多く、テーブル抽出の精度やメタデータ欠落が発生。要するに、データパイプラインに入れるのが面倒なんです。

- 解決: 機械可読なCSV/JSONを公式で付与し、メタデータはDCATやJSON-LDで記述する。これでデータカタログが作りやすくなる。

APIの有無と仕様

- e-StatなどはAPIがあるが、地方独自のKPIはAPI未整備が多い。APIがあってもスキーマがバラバラだと統合が重い。

- 提案: 共通スキーマ（例: kpi_id, municipality_code, fiscal_year, target_value, actual_value, update_timestamp）を定義して、各自治体がこれに準拠してAPIを実装する。要するに、スキーマ統一でクエリ一本化可能にするということです。

データ品質とCI

- エンジニア的に言うと、データはコードと同じくテストが必要！スキーマ検証・欠損チェック・時系列整合性チェックをデプロイ前にCIで回すのが現実的。

政策目標と実績のギャップ分析（技術的に見える化）

• 例: デジタル田園都市構想の交付金KPI（ガイドラインPDF参照）では、各事業毎の達成率や改善アクションが求められている（https://www.chisou.go.jp/sousei/pdf/r5_guideline-checkaction.pdf）。
• 問題点: 多くの自治体レポートは定性的評価やPDFのスキャン画像で提出され、数値の機械集約ができない。結果、国側での自動モニタリングが困難に。
• 技術提案: 交付金案件ごとに標準JSONスキーマを用意し、実績値をAPIにPUT/POSTできるようにすれば、国で集計・KPIダッシュボードに自動反映できる。

具体的な改善提案（技術スタックとワークフロー）

• データ公開

- 必須: CSV/JSONでの正式公開 + メタデータ(DCAT) + 更新頻度の明記

- 推奨: OGP/Schema.orgを使った機械可読メタ情報

• API設計

- REST/GraphQL に共通スキーマを適用

- 認証はOAuth2で柔軟に（トークン発行・レート制御）

• データ品質パイプライン

- CI: GitHub Actions / GitLab CIでスキーマ検証（jsonschema）、欠損チェック、時系列検査

- Monitoring: Prometheus + Grafanaでパイプライン稼働監視

• データカタログと発見性

- Central portal（Japan Dashboard拡張）に自治体メタデータを収集

- DCAT互換のカタログAPIを公開して連携容易に

コード例（最低限の検証スニペット）

• JSON SchemaでKPIを検証するPython例（簡潔版）:

# requirements: jsonschema, requests
from jsonschema import validate, ValidationError
import json

kpi_schema = {
"type": "object",
"properties": {
"kpi_id": {"type": "string"},
"municipality_code": {"type": "string"},
"fiscal_year": {"type": "integer"},
"target_value": {"type": "number"},
"actual_value": {"type": "number"},
"update_timestamp": {"type": "string", "format": "date-time"}
},
"required": ["kpi_id","municipality_code","fiscal_year","actual_value","update_timestamp"]
}

sample = {
"kpi_id": "digital_access_01",
"municipality_code": "07202",
"fiscal_year": 2025,
"target_value": 90.0,
"actual_value": 72.4,
"update_timestamp": "2025-12-01T12:00:00Z"
}

try:
validate(instance=sample, schema=kpi_schema)
print("OK: schema valid")
except ValidationError as e:
print("NG:", e.message)

このコードはサンプルですが、要するに「スキーマで機械的に弾ける」ようにしておくと自治体の提出データを安心して合算できるということです。

オープンデータの活用可能性

• 官民でのアプリケーション連携が進む: 例として地域のデジタル窓口の応答率やオンライン申請の処理時間KPIをAPIで公開すれば、民間サービスがリアルタイムに待ち時間情報や支援ツールを提供できる。
• リサーチ・監査の自動化: 標準化されたKPIを用いれば第三者検証（外部有識者）のプロセスも自動化・再現可能。

まとめ

• 現状: データ量は増加しているが、PDF依存やスキーマ非統一でエコシステム化が停滞。
• 必要なこと: CSV/JSONの機械可読データ提供、共通KPIスキーマ、API標準化、データ品質CIの導入。
• 効果: 政策評価の自動化、民間サービスとの連携強化、透明性と説明責任の向上。

おかむーから一言

テクノロジーは“出し方”で価値が10倍変わるんです。データは宝の山だけど掘り出すツールがないとただの石ころ。僕らエンジニアの手でそれを使いやすくしようぜ！