コードで語るマニフェスト：日本の行政データをエンジニア視点で検証する

どうも〜おかむーです！오늘은 일본 행정 데이터와 시스템을 엔지니어 관점에서 해부해볼게요〜

• 이 글 한눈 요약: 행정 데이터의 기계 가독성은 정책 결정의 근간이며, PDF에 잠긴 데이터가 많고 표준·API 부족이 문제다
• 기술적 핵심: CSV/JSON, OpenAPI, 데이터 패키지(Frictino less)로 표준화하면 재사용성과 검증 가능성이 확 올라간다
• 제안 요약: 데이터 포맷 표준화, 공개 API, 스키마 배포, 모니터링·品質ゲート 도입

結論

일본 정부·지자체는 데이터 공개 정책(예: 機械可読性に関するルール案、デジタル庁資料)으로 방향성은 잡았지만, 실제 데이터와 시스템 설계 수준은 아직 엔지니어링 관점에서 ‘생산성·再現性·検証 가능성’을 확보하기엔 부족한 상태입니다. 要するに、PDFに埋もれたデータをCSV/JSONとAPI로出して、スキーマとバリデーションを公開すれば多くが解決します。

レポート本文

現状の把握 — これ見てくださいよ

日本ではデジタル庁や総務省が「自治体情報システムの標準化・共通化」や「行政データの機械可読性」ルールを提示していて（例: https://www.digital.go.jp/、https://www.cas.go.jp/、https://www.soumu.go.jp/）、方針自体は前向きです。しかし、現場の公開データを見てみると:

• まだPDFで公開される報告書や一覧が多い（検索でヒットする政策資料のPDF参照）
• CSV/ExcelはあるがShift_JISや日付フォーマットが統一されておらず機械処理が面倒
• APIが提供されているケースはある（e-Statなど）が、地方自治体ごとに仕様がバラバラ

エンジニア的に言うと、データが“可搬性のある構造”で公開されていないと、解析・再現・CI（継続的インテグレーション）に組み込めないんですよね。

参照資料:

• 行政データにおける機械可読性に関するルール（案）: https://www.digital.go.jp/assets/.../20260331_meeting_executive_outline_06.pdf
• デジタル行財政改革会議の決定資料: https://www.cas.go.jp/jp/seisaku/digital_gyozaikaikaku/...
• 自治体情報システム標準化: https://www.soumu.go.jp/menu_seisaku/chiho/jichitaijoho_system/index.html

技術的課題の整理

1) フォーマットの不統一

• PDFやWordでの公開は人間には読めるが機械処理困難。Excelでもエンコーディング（Shift_JIS vs UTF-8）、日付形式、空セル扱いが統一されていない。
• 要するに、同じ項目でも自治体ごとにカラム名や型が違うということです。

2) APIとメタデータの欠如

• APIがない、あってもOpenAPI仕様やスキーマが公開されていない。結果としてクライアント実装が自治体ごとに書き換え必要。

3) データ品質と信頼性の可視化不足

• 更新日時やスキーマバージョンが明示されないケースが多い。データの妥当性チェック・欠損報告が無いと、分析結果の信頼度が下がる。

4) 基幹業務システムのレガシー問題

• 地方の基幹業務システムは標準化・クラウド移行フェーズで、移行コストや運用設計が問題になりがち（https://www.digital.go.jp/policies/local_governments）。

技術的改善提案（具体的）

1) データ公開フォーマットの強制ガイドライン

• 優先順: JSON/NDJSON（API向け） > CSV（バルクロード向け） > 残余はPDFで人間向けに
• すべてUTF-8、ISO 8601の日付、明確なNULL表記を必須にする。要するに、文字コードと日付でハマる時間を無くすということです。

2) スキーマを公開する（JSON Schema / Data Package）

• 各公開データにJSON Schemaとサンプルを添付、CIでスキーマ検証を導入。これでクライアント/解析パイプラインが自動化できます。

3) OpenAPIでAPI仕様を一本化

• APIレスポンスにメタ（updated_at、schema_version、source）を必須にする。
• 例: OpenAPIの一部（簡易）

openapi: 3.0.1
info:
title: municipality-covid-data
version: '1.0'
paths:
/v1/cases:
get:
parameters:
- name: date
in: query
schema:
type: string
format: date
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/CasesResp'
components:
schemas:
CasesResp:
type: object
properties:
source:
type: string
schema_version:
type: string
updated_at:
type: string
format: date-time
data:
type: array

4) データパイプラインのベストプラクティス

• Gitベースのデータリポジトリ（データのPR/レビュー運用）
• CIでスキーマ検証・軽量な品質ゲート（null比率、ユニーク制約、日付の連続性チェック）
• ライフサイクル: raw → cleaned → published (CSV/JSON) → API

5) ローカル自治体向けの共通ミドルウェア

• 共通のオープンソースデータカタログ（CKANやFractalをベースに軽量化）を提供し、自治体が簡単に登録・公開できる仕組み

実装例：簡単な取得と検証スニペット

curlでAPIを叩く例、PythonでJSON Schema検証する例を置いときますよ〜

# API取得（例: e-Statや自治体API）
curl -s 'https://api.example-gov.jp/v1/cases?date=2026-03-31' -H 'Accept: application/json' > cases.json

# Python: jsonschemaで簡易検証
import json, requests
from jsonschema import validate
schema = json.load(open('schema.json'))
resp = requests.get('https://api.example-gov.jp/v1/cases?date=2026-03-31').json()
validate(instance=resp, schema=schema)
print('schema ok')

政策目標と実績ギャップの例（概念的分析）

デジタル庁やデジタル行財政改革会議では「機械可読性ルール」を示しているが、自治体実務では次のギャップが見られる:

• 目標: 機械可読な公開を標準化 → 実績: PDF公開が依然として多い
• 目標: 基幹業務システムの標準化・クラウド移行で運用コスト削減 → 実績: 移行中の自治体では仕様統一が遅延

数値目標がある場合（例えばクラウド移行率やオープンデータ数）は、データで追跡可能にしてダッシュボードで公開すると良いです。要するに、政策自体もデータで評価可能にしようって話です。

まとめ

• 現状: 方針は整いつつあるが現場はまだPDF依存やフォーマットバラつきが残る
• 技術的解決策: UTF-8/ISO8601、JSON Schema、OpenAPI、CIでの品質ゲート、共通カタログ
• 期待効果: 開発コスト低減、再現性のある政策評価、民間利活用の加速

政策ってトップダウンで決めるだけじゃダメで、データ設計と運用の国民的インフラ化が必要です。技術的に言うと、API一本とスキーマ一つで多くの議論がコードで検証可能になりますよ！

おかむーから一言

テクノロジーで社会をアップデートするのがミッションです。PDFの山をCSVに変えて、API一本で民主主義を強くしましょう！