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

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

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

  • 自治体の基幹システム標準化は「仕様書を出す」だけじゃダメで、コード化されたデータ契約が必要
  • 現行のガイドラインは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。ただしデータ本体は必ず機械可読で出すこと!

おかむーから一言

テクノロジーで社会をアップデートするのって、結局『約束をコードで書く』作業なんです。やってみたら思ったよりシンプルだし、自治体の仕事がめっちゃ楽になりますよ!

シェアする