政策ドキュメントに「履歴」と「API」を:バージョン管理で見える化する公共データ戦略

どうも〜おかむーです!今日は政策書類の“いつ変わったか分からない問題”をエンジニア視点で切っていきますよ〜
- 政策文書はPDFで散らばりがち、履歴が追いづらい
- 要するに「版管理」と「機械可読なメタデータ」が足りない
- Git風ワークフロー+抽出パイプラインで政策の時間軸を作ろう
結論
政策文書は単なる公開資料じゃなくて“時系列データ”に変換すべきです。エンジニア的に言うと、PDFはスナップショット、Gitは真のソースコントロール、APIはその差分を取り出すインターフェースです。要するに履歴を機械で扱えるようにすれば、政策評価や検証がぐっと楽になるということです。
レポート本文
問題の現場感覚
これ見てくださいよ:総務省や地方自治体の施策ページ(例:chisho.go.jpの交付金ガイドラインや須賀川市の実績評価ページ)ってPDFでガッと置いてあることが多いですよね(参照: https://www.chisou.go.jp、https://www.city.sukagawa.fukushima.jp)。PDFは人には読めても、コードは読みにくい。さらに「この表はいつ更新されたのか」「前の版と何が違うのか」が明確でない場合が多いんです。
技術的な問題点を整理すると:
- PDFが一次データになっている(CSV/JSONが無い)
- 発行日とバージョンを明示したメタデータが欠落
- 変更履歴を機械で辿れない(差分が見えない)
- APIやe-Stat等の外部DBと紐づけるための永続IDが不在
要するに検証の第一歩がそもそも壊れているんですよね。
どう直すか(具体案)
エンジニア的に言うと、「ソースはテキスト(または構造化データ)で管理して、PDFはビルド出力にする」って発想が有効です。具体的手順は以下。
1) マニフェストリポジトリを用意(例: policy-repo)
- 各施策ごとにディレクトリを作り、原則Markdown/CSV/JSONで保存
- リリースはタグを切る
2) 公開アセットにメタデータを添付
- JSON-LD / DCAT を使い、"version", "issued", "relatedURL" を付与
3) PDFはCIでビルド
- 人向けPDFは自動生成(Markdown→PDF)にして、ソースとビルド物を分離
4) 変更差分をAPIで提供
- /api/policies/{id}/versions や /api/policies/{id}/diff?from=v1&to=v2 で差分を取得
コード例:PDFバージョンのタイムスタンプ化(簡易)
# ダウンロードとコミットを自動化する例
wget -O policy.pdf https://example.go.jp/path/policy.pdf
pdftotext policy.pdf policy.txt
git add policy.pdf policy.txt
git commit -m "import policy $(date -I)"
Pythonで差分行を抜く簡単なスニペット:
from difflib import unified_diff
with open('a.txt') as f1, open('b.txt') as f2:
diff = unified_diff(f1.readlines(), f2.readlines())
print(''.join(diff))
エンジニア的に言うと、これだけで「いつ・何が・誰が変えたか」が取れるんですよ。
データ品質と公開フォーマットの話
- PDFに埋まった表はTabula/Camelotで抽出、可能ならCSV/JSONを同時公開
- e-Statや各省のAPI(digital.go.jpや地方のlg.jpドメイン)と連携するための永続ID設計が重要
- メタデータにS3やCDNのETag、Content-Lengthを入れて差分検出の精度を上げる
運用とガバナンス提案
- 政策公開のSLOを設定(例: 公表後7日以内に機械可読版を公開)
- 年次レビューだけでなく、公開時に自動で差分レポートを作るパイプライン
- 市民が訂正を提案できるIssueトラッカーを公開(プライバシー配慮は必須)
まとめ
政策ドキュメントは単なるPDFの山じゃなく、時系列データとして扱う価値がある!Git的ワークフロー+機械可読メタデータ+差分APIで、検証可能で再現性ある政策運用にできるはずです。要するに、人とコードの両方に優しい公開方法に変えるのが鍵ですよね。
おかむーから一言
政策もプロダクトだと思って、バージョン管理とCIを当てよう!テクノロジーで“いつ変わったか分かる社会”を作りたいんです。
情報ソース
- https://www.zhihu.com/question/290714454
- https://metidx-gov.note.jp/n/n9468573c213b
- https://www.zhihu.com/question/6430289390
- https://www.trans-plus.jp/blog/column/202210_municipality-dx
- https://www.zhihu.com/question/38923279
- https://www.zhihu.com/question/40553450
- https://www.govtechtokyo.or.jp/services/data-utilization/
- https://www.zhihu.com/tardis/zm/art/1924492115896960699
- https://note.govtechtokyo.jp/n/n77785a8254d6
- https://bus.gov.ru/
- https://www.digital.go.jp/
- https://www.chisou.go.jp/sousei/pdf/r5_guideline-checkaction.pdf
- https://column.nippoukun.bpsinc.jp/what-is-digitization/
- https://www.city.sukagawa.fukushima.jp/shisei/gyoseiunei/keikaku/chiho_sosei/1015604/4045.html
- https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB
シェアする
関連レポート

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

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

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