コードで語るマニフェスト：地方公共データをエンジニア視点で検証する

どうも〜おかむーです！大家好，我是おかむー！今天来聊聊日本地方公共団体的基幹系統和公開資料，从工程师角度做点实务性的检验和建议～

• 地方公共団体システム有法律框架（「地方公共団体情報システムの標準化に関する法律」），但実装とデータ公開の現場に乖離がある
• API 与ダッシュボード已有雛形（e-Gov API, Japan Dashboard, e-Stat），不过格式不统一，PDF仍然很多
• 改善提案：统一机読性优先的格式（CSV/JSON/NDJSON）、公开OpenAPI/JSON Schema、CI化的数据质量检查

結論

現状は「方針はあるが実装が追いついていない」フェーズ。法律やポータル（例：https://www.digital.go.jp/policies/local_governments、https://laws.e-gov.go.jp/*）で標準化を進めているのは良いんですが、現場の公開データはPDFやフォーマットばらつきが多く、エンジニア的にはAPI一本で解決できることが多いんですよね。要するに、政策の“何を出すか”と“どう出すか”の差が課題です。

レポート本文

背景と現状

まず政策面。デジタル庁のページ（https://www.digital.go.jp/policies/local_governments）や法律（https://laws.e-gov.go.jp/law/503AC0000000040）で「標準化対象事務（現時点で20事務）」が定められているのは大きいです。これ見てくださいよ、方針はあるんです。

でも現場を見ると：

• 中央のAPIカタログ（https://www.e-gov.go.jp/digital-government/api）やJapan Dashboard（https://www.digital.go.jp/resources/japandashboard）は整備中
• 都道府県・市区町村のサイトにはCSV/JSONで公開しているところもあるが、PDFやHTMLスキャン表がまだ多い（例：オープンデータの差は自治体による）

エンジニア的に言うと、API一本で解決する話なんですよね。APIと一貫したスキーマがあれば上流の集計・可視化も簡単になります。

データ形式と機械可読性の問題

これが一番あるある問題。要点は3つ：

PDFが主流の資料がまだ多い（表は画像化されやすい）→ 機械処理が難しい

CSVがあってもスキーマ未整備（列名や型が自治体で違う）→ 結合・横断分析が面倒

APIは存在してもOpenAPIやJSON Schemaで契約が明示されていないケースがある

要するに、データを取りに行くコードを書くたびにハンドリングが変わるんです。正直ここは改善の余地ありまくりだと思ってます！

技術的検証（サンプルと手法）

まずは実務でどう取るか簡単に示します。東京都オープンデータAPIの例（https://portal.data.metro.tokyo.lg.jp/opendata-api/）に対して、Pythonで叩くとこんな感じ：

import requests
import pandas as pd
url = 'https://api.example.tokyo.opendata.gov/xxxx'  # 実際のエンドポイントに置き換え
r = requests.get(url, params={'limit':100})
data = r.json()
df = pd.json_normalize(data['items'])
print(df.head())

PDFからテーブルを抽出する場合はtabula-pyやcamelotを使うのが現実的：

# 一例: tabulaを使ってPDFからCSV化
pip install tabula-py
python -c "import tabula; tabula.convert_into('report.pdf','out.csv',pages='all')"

ただしPDF抽出はエラー率が高いので、可能なら自治体側でCSV/JSONを出してもらう方が建設的。

スキーマと品質チェックの実装例

• 提案：各標準化対象事務に対してJSON Schemaを用意
• CIでの自動チェック：GitHub Actionsでデータ変更時にschema validationと重複キー、欠損率チェックを回す

簡単なJSON Schema例：

{
"$schema":"http://json-schema.org/draft-07/schema#",
"type":"object",
"properties":{
"id":{"type":"string"},
"date":{"type":"string","format":"date"},
"value":{"type":"number"}
},
"required":["id","date","value"]
}

これを使えば、データ提供側と消費側で契約（データ契約）が明確になります。要するに、使う側も出す側もハッピーなんです。

政策目標と実績のギャップ

法律で標準化の方向性は示されているものの、実際の実装・公開状況は自治体によるばらつきが大きい。20事務のうちどれがどの程度API化・機械可読化されているかを定量的にトラックするダッシュボードが必要です。Japan Dashboardやe-Statは方向性を示しているが、地方の細かい実績を横断的に可視化する仕組みはまだ弱いですね。

改善提案（具体的）

中央で「公式のOpenAPI＋JSON Schemaテンプレ」を配布する（自治体はこれをインポートして実装）

データは原則CSV/JSON/NDJSONで公開、PDFは補助資料に限定

CKANやDataverse的なカタログを自治体単位で導入し、中央で横断クエリ可能にする

CI/CDを使ったデータ品質パイプライン（schema validation、欠損率、時系列の連続性チェック）を実装

逆に、APIが難しい小規模自治体には『ホスティング＋変換サービス（PDF→CSV）』を中央で提供

導入コストはあるけど、長期的には保守コストと二次利用の生産性が劇的に下がりますよ〜！

まとめ

• 方針と法律は揃っているが、実装とデータ公開の現場にギャップあり
• エンジニアとしては「API化＋明確なスキーマ＋CIでの品質管理」が最短の改善路線
• 中央と地方の役割分担（テンプレ配布、ホスティング支援、横断ダッシュボード）が鍵

おかむーから一言

テクノロジーで政治や行政をアップデートするのは可能です！まずはAPI一本、JSON Schema一本から始めましょう。僕も一緒に作りたい！