コードで語るマニフェスト：自治体基幹システム標準化をデータとコードで検証する

どうも〜おかむーです！

• 지방자치단체의基幹業務システム 표준화가 법제화되고 있지만, 실제 데이터의 기계가독성·API 제공에는 갭이 있다요
• PDF에 묻힌 정책수치와 분산된 API를 통합하면 정책 평가·서비스개발이 훨씬 쉬워진다요
• 해결책은 OpenAPI·JSON Schema·中央カタログ·バージョニング을 조합한エンジニアリングだよ〜

結論

정부와 지방자치단체의『基幹業務システムの統一・標準化』정책(デジタル庁·総務省·内閣府の資料参照)은 좋은 방향이지만, 실무 관점에서는 "データを機械可読かつAPI化して初めて効力を発揮する"という点が決定的に不足しているんです。要するに、標準規格をコード（スキーマ・API・スキーム）で定義し、公開・検証・運用するワークフローを強化する必要があります。

レポート本文

背景と現状（これ見てくださいよ）

国の資料（Digital庁の地方公共団体の基幹業務システムの統一・標準化、総務省の自治体情報システム標準化ページ、内閣府のWG資料PDF）を見ると、目的は明確で「標準準拠システムの利用義務化」「業務別の標準化」「進捗管理」ですね。ただ、出力フォーマットや公開方法を見るとPDF資料や人手でのFit&Gap表がまだ多く、機械可読性が低いんです。

政府のAPIカタログ（e-Govの行政API）や東京都のオープンデータAPIは存在しますが、地方ごとのデータ品質やスキーマ統一はまちまち。e-StatやJapan Dashboardのような統計ダッシュボードは便利だけど、基幹業務のトランザクションデータと結びつけて政策評価に使える形ではまだ限定的です。

要するに：政策目標や進捗の数値がPDFや散在APIにある→データを結合・再現するのに工数がかかる、ということです。

技術的評価ポイント

• フォーマット：PDF中心 → CSV/JSON/JSON-statへ移行すべき

- PDFは人間には読めるけど、コードで取り扱うときはOCR/スクレイピングに頼るしかなくてエラーが出やすいです。要するに、機械可読フォーマットでの公開が必須。

• API：存在するが統一規約が弱い

- e-GovのAPIはあるけど、自治体レベルでの標準OpenAPI仕様や共通ID（例：自治体コードや住民基本台帳の匿名化スキーマ）の統一が不十分。

• メタデータとカタログ：中央のデータカタログ（Japan Dashboard等）への登録自動化が弱い

- 各自治体が公開するデータセットのメタデータ（更新頻度、ライセンス、スキーマ）を中央で検証・可視化する仕組みが必要。

• ガバナンス：バージョン管理、変更通知、認証・認可の仕組みが不十分

- APIのバージョン、Schemaの互換性、移行計画が明文化されていない場合が多い。

コードで語る——具体的技術提案（エンジニア的に言うと）

1) スキーマをまず定義する（JSON Schema / OpenAPI）

• 要するに、業務ごとに標準のJSON Schemaを作って共有することです。例えば住民記録APIのスキーマ例：

{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "ResidentRecord",
"type": "object",
"properties": {
"resident_id": { "type": "string" },
"name": { "type": "string" },
"dob": { "type": "string", "format": "date" },
"address_code": { "type": "string" }
},
"required": ["resident_id", "name"]
}

2) OpenAPIでエンドポイントを標準化

• OpenAPIを自治体共通の形で公開すれば、SwaggerやPostman等で自動テスト・SDK生成が可能。これで自治体間の相互運用性が飛躍的に上がります。

3) 中央カタログ＋CIパイプライン

• 各自治体がスキーマをGitで管理→PRベースでDigital庁の中央リポジトリに登録→CIでスキーマ互換性・サンプルデータ検証→自動的にJapan Dashboardやe-Statにメタデータを更新。こうすると公開漏れやフォーマット不一致が減ります。

4) データ品質チェックとサニタイズ

• 毎日/週次でJSON Schemaバリデーション、ユニットテスト、サンプル統計（行数・欠損・重複）を実行。Pythonでの簡単なチェック例：

import requests, json, jsonschema
schema = json.load(open('res_schema.json'))
data = requests.get('https://city.example.gov/api/residents').json()
jsonschema.validate(instance=data[0], schema=schema)

5) 公開フォーマットの推奨

• 統計はJSON-statやCSV（UTF-8, BOM無）
• 時系列や地理参照はGeoJSONやTopoJSON
• メタデータはDCAT-AP/Japanの拡張で統一

政策数値目標と実績のギャップ分析（具体例）

政府資料には「標準準拠システムの利用義務化」「段階的導入」の目標がありますが、進捗管理は自治体ごとの報告に依存しています。これ、要するに"申告ベースの自己報告"になりがちで、現地データ（稼働ログ・API応答の可用性・スキーマ準拠率）を自動収集して可視化してこそ実績が定量的に評価できます。

例えば：ある都道府県で「基幹システム標準化率70%」と報告しても、実際のAPI応答が標準スキーマに沿っているか、更新頻度は守られているかは別問題。ここをCIで定量化してダッシュボード化するのが技術的解です。

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

• ベースライン：自治体が標準スキーマでデータを出せば、民間のスタートアップや研究者が政策効果を検証しやすくなる
• 例：住民移動データ（匿名化）＋住民記録の標準化で、地域施策の効果を定量評価可能
• API＋SDKを提供すれば、自治体横断アプリや自治体間ベンチマークが生まれてエコシステムが拡大する

実装上の注意点

• 個人情報保護：スキーマは匿名化・集約化を前提にし、X-Request-IDやログは出さない設計が必要
• ロールアウト戦略：まずRead APIを公開してエコシステムを育成→次にWrite/行政側B2B APIを段階導入
• レガシー対応：ETL jobsで既存DBからジョブを切り出し、Schema Registryへ変換

まとめ

• 法制度は揃ってきたけど、機械可読データとAPIの標準化・公開が追いついてないです
• エンジニアリング視点では「JSON Schema + OpenAPI + 中央カタログ + CI」で解決可能
• 実績の定量評価には、自己報告ではない“自動収集された運用メトリクス”が必須
• 最終的に、データが使いやすければ民間活用・透明性・効率化が同時に実現します！

おかむーから一言

テクノロジーで社会をアップデートするのは本気で可能です。小さく始めてスキーマ一つから動かしてみましょう。自分もコード書いて一緒に検証しますよ〜