政策データをCI/CDで回す：公開データを“デプロイ”する技術設計

どうも〜おかむーです！今日はちょっとエンジニアっぽい話をしますよ〜

• 公的レポートや交付金の成果がPDFで眠ってること、多くないですか？
• それを放置すると再現性ゼロ、検証不能になりがちなんですよね
• だからこそ「データをコード化してCI/CDで運用」する設計を紹介します！

結論

公開データは単なるファイルじゃなくて「ソフトウェアの一部」として扱うのが最短で実用的。Gitベースでスキーマ・テスト・デプロイのパイプラインを作れば、KPIの改訂や実績報告の信頼性がぐっと上がります。要するに、政策の“リリースフロー”をエンジニアリングで担保するということです。

レポート本文

問題の整理：現場でよく見る地雷

これ見てくださいよ。デジタル庁や各自治体（例：digital.go.jp、各都道府県のlg.jp）には素晴らしい意図で資料がアップされてるけど、実態はこんな感じ：

• KPIはPDFの表に埋め込まれている（機械可読性ゼロ）
• CSVがあってもスキーマ不整合、エンコーディング混在
• APIがない or あるがドキュメントが古い
• 更新履歴（誰がいつ変えた）はトレーサビリティ不足

要するに、政策を検証するための「安定したデータ供給」が不足してるんです。

エンジニア的アプローチ：データをコード化するとは？

具体的には次の3点をパッケージ化します。

スキーマをコード化（JSON Schema / CSV Schema）

テストを自動化（値域チェック、外部参照の整合性）

デプロイフロー（Git → CI → 公開ストレージ/API）

こうすると、政策変更が入ったときにも差分で追えるし、回帰テストで過去実績が壊れていないか確認できます。

実装の骨子（例）

• リポジトリ構成

- data/ ← CSV／JSONタイムシリーズ（小容量ならrawデータ）

- schema/ ← JSON Schema や datapackage.json

- tests/ ← Python（pytest）や Goodtablesルール

- .github/workflows/ ← CI定義

コード例：CSVバリデーション（Python + frictionless）

from frictionless import Pipeline, steps

pipeline = Pipeline()
pipeline.add_step(steps.validate(schema='schema/indicator.json', fail_fast=True))

report = pipeline.run('data/indicator_2025.csv')
if report.valid:
print('OK')
else:
print(report.flatten())

CI（GitHub Actions）例：コミットごとにバリデートして、合格ならS3やGCSへデプロイ

name: data-ci
on: [push]

jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v4
with:
python-version: '3.10'
- run: pip install frictionless
- run: python tests/validate_all.py
deploy:
needs: validate
if: success()
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: ./scripts/deploy_to_storage.sh

PDF源の扱い：抽出から正規化まで

PDFしかない資料は多い。ここは現実的にTabula/Camelotでテーブル抽出→検査→正規化のパイプラインを作るべきです。

簡単な流れ：

• PDFをOCR／テーブル抽出
• 初期CSVを作る
• 自動スキーマ推論（frictionless describe）でテンプレ作成
• 手動レビュー→schemaで固定

要するに、最初の労力はかかるけど、その後はCIで自動化できます！

KPIと実績のギャップをコードで見つける

政策ドキュメント（例：交付金のKPI資料）をデータ化すれば、次が可能になります。

• KPI目標と実績を時系列で比較する自動レポート
• SLO／SLA風に更新頻度・遅延をチェック
• アノマリー検出（実績が急落したら自動でSlack通知）

実装ヒント：SQLやPythonで毎日差分を計算して、Grafanaやダッシュボードに流すと現場の議論が変わります。

オープンデータ運用のガバナンス設計

• ライセンスは明示（CC-BY等）→ machine-readableなLICENSEファイル
• バージョン管理（タグ／リリース）で時点復元を担保
• メタデータ（発行日、作成者、原典URL）をカタログに載せる（例：data.gov.jpスタイル）

まとめ

政策データは「出す」だけじゃダメで、「出し続ける」ためのエンジニアリングが必要です。Gitベースでスキーマ・テスト・デプロイを整備すると、検証可能性と運用工数の両方が改善します。PDFばかりの現状でも段階的に自動化パイプラインを導入すれば実利が出ますよ！

おかむーから一言

社会をアップデートするには技術だけじゃなくて、運用の仕組み化が肝心。データをコードとして扱えば、政策の透明性は確実に上がります。やっていきましょう！