自治体システム標準化をコードで設計する:スキーマ・契約・検証の実務案

どうも〜おかむーです!今日はちょっとエンジニアっぽい話をしますよ〜
- 自治体の基幹システム標準化は「仕様書を出す」だけじゃダメで、コード化されたデータ契約が必要
- 現行のガイドラインはPDF中心で機械読み取り性が低く、KPI集計の自動化を阻んでいる
- JSON Schema / OpenAPI / CIで『合意と検証を回す』仕組みを導入すれば運用負荷がぐっと下がる
結論
デジタル庁や総務省が進める自治体システムの標準化(参考: digital.go.jp、総務省の標準化ページ)は良いスタート。ただ、現場で使えるのは“人が読む仕様”だけじゃなく“マシンが検証できる契約”を配備したときです。要するに、スキーマと契約テストを政策実装に組み込むのが最短の改善ルートなんですよね。
レポート本文
背景と問題意識
政府側の資料(digital.go.jp、総務省の自治体情報システム標準化資料)を見てくださいよ。政策目標やスケジュールは示されてるんですけど、実際の仕様はPDFが多くて、プロジェクトごとのKPI報告もPDFや表組みで出されることが多い。要するに、これでは全国での自動集計や品質担保が難しいんです!
エンジニア的に言うと、仕様は“コード化された契約(data contract)”でないと信頼できないんですよね。人間が読むドキュメントから機械が動くアプリケーションまでの橋渡しが足りない。
現状の痛みポイント(まとめ)
- PDF中心の公開:文書はあるけど機械可読性が低い(chisouの交付金評価レポートもPDF)
- スキーマ不在:同じ項目名でも型や単位がバラバラで正規化が必要
- テスト不足:アップデート時に互換性検証が行われていない
- APIの有無が自治体ごとに不均一
技術的提案(具体的)
1) スキーマを規格化する(JSON Schema)
- KPI報告や住民情報のエクスポートに対してJSON Schemaを定義
- 例:交付金KPI報告の最小スキーマ
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "kpi_report",
"type": "object",
"properties": {
"municipality_id": {"type":"string"},
"fiscal_year": {"type":"integer"},
"kpi": {
"type":"array",
"items": {"type":"object","properties":{
"kpi_id":{"type":"string"},
"target":{"type":"number"},
"actual":{"type":"number"}
},"required":["kpi_id","target","actual"]}
}
},
"required":["municipality_id","fiscal_year","kpi"]
}
2) API設計はOpenAPIで公開
- GET /kpi-reports?year=2026 みたいなエンドポイントを標準化
- 認証はトークンベースで、公開用は読み取り専用APIキーを付与
3) CIで契約テストを回す
- ベンダーはスキーマ互換テストを必須にして、リリースパイプラインで自動検証
- 例:AJV(Node.js)でのバリデーションをCIに組み込む
4) PDFは人間向けサマリに限定、データ本体はJSON/CSVで公開
- 要するに、PDFは『見せる用』、データは『動かす用』に棲み分けるべき
実装パターンと運用フロー
- ローカル自治体は現行システムからトランスフォームモジュールを用意して、CSV→JSON Schemaに変換
- 中央でメタレジストリ(gov-data-registry)を運用し、バージョン管理(semver)とリリースログを公開
- 変更は非互換ラベルで通知し、契約テストで影響範囲を可視化
KPIと実績のギャップをどう扱うか
chisouの交付金ガイドラインをみるとKPI設定は徹底する旨があるけど、実績報告がPDF主体だと全国集計が手作業に頼らざるを得ない。だから、まずはKPIスキーマを定義して、年間報告はJSONで必須提出にする。これで「目標と実績の差分」を自動で算出・可視化できるようになるんです。
まとめ
- 政策の『意図』は示されてるけど、それを現場で『動かす』には機械可読なデータ契約が不可欠
- JSON Schema + OpenAPI + CIによる契約テストで、標準化は初めて運用レベルで機能する
- PDFは残してOK。ただしデータ本体は必ず機械可読で出すこと!
おかむーから一言
テクノロジーで社会をアップデートするのって、結局『約束をコードで書く』作業なんです。やってみたら思ったよりシンプルだし、自治体の仕事がめっちゃ楽になりますよ!
情報ソース
- https://www.digital.go.jp/
- https://www.chisou.go.jp/sousei/about/kouhukin/pdf/r6_houkokusho-suishin.pdf
- https://www.chisou.go.jp/sousei/pdf/r5_guideline-checkaction.pdf
- https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB
- https://www.city.moka.lg.jp/material/files/group/47/r6digitaldennennkouhukinnhyouka.pdf
- https://www.zhihu.com/question/2017291694312280331
- https://www.digital.go.jp/policies/local_governments
- https://www.zhihu.com/tardis/bd/art/580345844
- https://www.soumu.go.jp/menu_seisaku/chiho/jichitaijoho_system/index.html
- https://www.zhihu.com/question/43621706
- https://www.zhihu.com/question/290714454
- https://metidx-gov.note.jp/n/n9468573c213b
- https://www.zhihu.com/question/6430289390
- https://ai-government-portal.com/%E5%85%AC%E5%8B%99%E5%93%A1%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E6%8C%91%E6%88%A6%E3%80%8C%E8%A1%8C%E6%94%BFux%E6%94%B9%E5%96%84%E6%A5%AD%E5%8B%99%E5%A7%94%E8%A8%97%E3%80%8D%E5%AE%8C%E5%85%A8%E3%82%AC/
- https://www.zhihu.com/question/38923279
シェアする
関連レポート

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

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

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