안녕하세요~ 오카무입니다! 오늘은 공공데이터를 코드 관점에서 뜯어보는 시간이에요. 정부·지자체가 공개한 CSV들을 직접 훑어보면서 "정책이 코드로 말할 때" 어떤 문제가 보이는지, 개선은 어떻게 할지 기술적으로 정리해봅니다.

• 이 기사 3줄 요약

- 여러 기관에서 CSV로 공개하고 있어 기계가 읽기 쉬운 점은 좋음! 하지만 스키마 불일치·메타데이터 부재가 반복됨

- 엔지니어 관점의 핵심 결론: API 표준화, 스키마 선언(JSON Schema/DCAT), 버전 관리가 우선

- 개선 제안: 자동화된 검증 파이프라인 + 정책 목표와 실적을 기계적으로 비교하는 KPI 데이터 모델 제안

結論

정부·지자체가 CSV를 공개하는 건 매우 좋은 출발이다! 하지만 엔지니어적으론 "파일 던져놓기" 수준에 머물러 있는 경우가多い。要するに、データは機械可読でも、意味的に使える形になっていないことが問題です。API設計・スキーマ宣言・バージョン管理・ライセンス明記をセットで運用するのが最短で効果出ます。

レポート本文

現状観察 — 参照したソース

これ見てくださいよ！検索結果に並んだCSV群を観察すると:

• notice.go.jp の status_notice.csv（公開CSV）
• env.go.jp の地域データ（例: 900398071.csv、約463KB）
• inpit.go.jp の移行データ一覧表2011（CSV）
• mhlw.go.jp の救護施設リスト（8KBのCSV）
• soumu.go.jp の全国データ（104KB CSV）

CSVで出してくれてるのは嬉しいんですけど、ここでよくある技術的な問題を挙げます。

よく見る問題パターン（エンジニア的に言うと）

• 文字コード不明・混在（UTF-8推奨だがShift_JISやEUCが混ざる）
• カラム名の不統一（都道府県名カラムが "pref" や "都道府県" など複数形で存在）
• メタデータ欠如（列の意味、単位、更新頻度、ライセンスがファイル内にない）
• スキーマ未宣言（JSON SchemaやCSV Schemaが無く、型推論を自前でやる必要がある）
• ID・主キーの欠如（時間での追跡や差分同期が困難）
• バージョン管理が無い（更新で上書きされると差分追跡不可）

データ品質チェックの例 — 手早いコード（Python/pandas）

import requests, chardet, io
import pandas as pd
url = 'https://example.go.jp/data.csv'
r = requests.get(url)
enc = chardet.detect(r.content)['encoding']
df = pd.read_csv(io.BytesIO(r.content), encoding=enc)
基本チェック
print(df.columns)
print(df.isnull().sum())
日付カラム変換
for c in df.columns:
if 'date' in c.lower() or '日付' in c:
df[c] = pd.to_datetime(df[c], errors='coerce')

要するに、まず文字コードと日付を確実に正規化するのが第一歩です。

政策の数値目標と実績のギャップを機械的に検出する方法

政策目標を構造化しておけば、CSVデータと突き合わせて自動でギャップレポート出せます。データモデル例:

• policy_targets.csv: policy_id, metric, target_value, target_date, source
• actuals.csv: region, metric, value, observed_date

簡単な比較ロジック（擬似コード）:

# targetsとactualsをマージして差分を計算
merged = pd.merge(targets, latest_actuals, on=['metric', 'region'], how='left')
merged['gap'] = merged['value'] - merged['target_value']

こうすると政策ごとに遅れている地域を自動で抽出できる。コード書く人ならわかると思うんですけど、これがあると説明責任（accountability）がぐっと上がりますよね！

APIの有無と改善案

現状: 多くは静的CSVファイルを公開するのみで、RESTfulなAPIが無い場合が多い。

改善案:

• 小さくてもいいのでJSON APIを一本用意する（例: GET /v1/evacuation-centers?pref=Ibaraki）
• OpenAPI/Swaggerで仕様を公開
• レスポンスはJSON-LD/Schema.org/DCATでメタデータつきにする

例: OpenAPIでのエンドポイント定義（概念）

paths:
/v1/shelters:
get:
parameters:
- name: pref
in: query
schema: {type: string}
responses:
'200':
content:
application/json:
schema:
$ref: '#/components/schemas/ShelterList'

運用面のベストプラクティス（すぐ導入できる）

• CSVだけでなく: Schema宣言(JSON Schema/CSVW)、例データ、ライセンス(Creative Commons)を同梱
• CIでスキーマ検証を回す（GitHub ActionsやAzure Pipelinesで自動化）
• 公開はCKANやdata.go.jpのようなカタログ経由で
• 差分取得のためにETagや日次差分CSVを用意

活用パターンの提案

• ローカル防災アプリが避難所CSVを定期取得してオフライン地図に差し込む
• KPIダッシュボード：政策目標と実績の時系列グラフを自動更新
• 民間事業者に向けたWebhook（更新通知）でエコシステム形成

まとめ

• CSV公開は素晴らしいスタート！ただし機械的な使いやすさはスキーマ・メタデータ・APIで決まる
• エンジニア的に言うと: まずはエンコード・日付・カラム名を正規化して、JSON Schemaを宣言してほしい
• 政策の数値目標は構造化して公開し、実績と自動で突き合わせる仕組みを作ると説明責任が担保される

おかむーから一言

테크로 사회를 바꿉시다! 데이터는 공개하는 것보다, "쓰게 만드는" 설계가 중요합니다. 작은 API 하나가 시민의 불편을 확 줄일 수 있어요!