どうも〜おかむーです！ 안녕하세요, 오카무입니다! 오늘은 정부·지방자치단체가 공개하는 데이터와 시스템을 엔지니어링 관점에서 까보고, 개선 제안을 하는 글이에요〜

• 이 글은 정부 데이터 공개에서 "PDF에 갇힌 진실"을 기술적으로 어떻게 풀어낼지 설명합니다
• e-Gov API·오픈데이터 카탈로그 등 실제 공개 인프라를 점검하고, 코드로 검증 가능한 개선안을 제시합니다
• 정책 목표와 실적의 기계적 연결(시계열 데이터, KPI)을 통해 투명성·재현성을 확보하자고 제안합니다

結論

요약하면, 정부·지자체는 이미 API·오픈데이터 인프라를 갖추기 시작했지만 "기계가 바로 쓰기 쉬운 데이터"가 부족해요. PDF나散在하는CSV, 스키마 불일치가 여전합니다. 엔지니어적 관점으로는 표준화된 API(OpenAPI/JSON Schema), 시계열 KPI의 일관된 공개, 데이터 품질 CI 파이프라인 도입이 핵심 해결책입니다!

レポート本文

現状の観察: API는 있지만 범용성이 낮다

まずこれ見てくださいよ。総務省のオープンデータ戦略やe-Govの行政APIカタログ（参考: https://api-catalog.e-gov.go.jp/）は仕組みとして正しく整備されているんです。GovTech東京（https://www.govtechtokyo.or.jp/）の取り組みも、ダッシュボード共有など良い例です。

ただ、実務では次のような問題が頻出します:

• データがPDF報告書に埋め込まれている（機械可読性がない）
• CSVはあるがカラム名やフォーマットが自治体ごとに違う
• APIは存在するがスキーマやメタデータが不十分で再利用が難しい

要するに、データは出しているけど“ちゃんと使える形”で出てないということです。

技術的に見ると何が悪いか

1) フォーマットの非一貫性

• CSV/Excel/PDFが混在。PDFはOCR/レイアウト依存で流用コスト高い。

2) メタデータ不足

• カラム説明、単位、更新頻度、期間が明記されていない。データ連結でエラー発生。

3) API設計の欠如

• OpenAPI仕様が無い、レスポンスがHTML埋め込み／CSVのみでJSONがない。

4) モニタリングと品質管理不在

• データの整合性をチェックする自動CIがなく、後工程で問題が発覚する。

コードで検証する例（手早い確認用）

エンジニア的に言うと、API一本で解決する話なんですよね。たとえばe-Gov APIから法人情報を取得して簡単に検査するPythonスニペット:

import requests
import pandas as pd

url = 'https://api-catalog.e-gov.go.jp/...'  # 仮のエンドポイント
params = {'q': '法人名'}
resp = requests.get(url, params=params)
resp.raise_for_status()

data = resp.json()  # JSONだとそのまますぐ使える
df = pd.json_normalize(data['items'])
print(df.head())

これがPDFだと、まずPDF→テキスト→ラベル付け→正規化という手順が必要で、エラーが増えるんです。

政策目標と実績のギャップをどうコードで可視化するか

政策が「処理時間を30%短縮」とか言っている場合、要するに時系列で公表されるべきなんですよ。理想的には:

• 毎月の中央値・95パーセンタイル処理時間を自治体別に公開
• 目標値と実績を同一スキーマのJSON/CSVで公開

簡単な検証手順:

APIで毎月の処理時間のタイムシリーズを取得

pandasで目標比を計算

異常（急激な悪化）をSlack/Webhookで通知

擬似コード:

# df: columns=['municipality','month','median_processing_time']
goal: 30% reduction from baseline
baseline = df[df.month=='2023-01'].set_index('municipality')['median_processing_time']
current = df[df.month=='2025-02'].set_index('municipality')['median_processing_time']
ratio = current / baseline
alerts = ratio[ratio > 0.7]  # 목표 미달(70% 이하가 되어야 함)

改善提案（実装レベル）

• データフォーマット: CSV/JSONは必須。PDFは二次配布に限定。
• スキーマ定義: OpenAPI + JSON Schemaを全APIで公開。例: /openapi.json
• メタデータ: Data Catalog API（DCAT）互換のメタデータを付与
• 品質CI: GitHub Actionsなどで毎日スキーマ検証・欠損チェック・重複チェックを走らせる
• レート制限・認証: OAuth2やAPIキーで可用性とセキュリティを担保
• サンプルコード: 各データセットにPython/JSのサンプルを付ける

さらに、自治体ごとのCSV方言を吸収する中間レイヤー（ETLサービス）を中央で提供すると良いです。要するに変換器を一度作っておいて各サービスは標準APIを叩くだけにするイメージ。

活用事例案

• 申請処理時間のKPIダッシュボード（自治体別、窓口別、時系列）
• 予算執行のマシンリーダブル公開→市民監査ツール
• 交通データのリアルタイムAPI、二次創作者向けのサンプルアプリ

まとめ

短く言うと、政策の正当性は“数値でつながっていること”で担保されます。PDFで報告して終わり、だと再現性も検証もできないんですよね。既存のe-Gov APIやGovTechの動きは正しい方向ですが、スキーマの標準化、機械可読性、データ品質CIを徹底して初めてエンジニアリングの勝ち筋になります。

おかむーから一言

テクノロジーで社会をアップデートするのが僕の使命なんです。データをちゃんと出して、誰でも検証できる世の中にしようぜ！