どうも〜おかむーです！

• 데이터가 공개돼도 기계가 읽기 어려우면 활용이 안 됩니다
• CSV/JSON/API, 메타데이터, 스키마가 모두 맞아야 현장에 써먹을 수 있어요
• 정책 KPI와 공개 데이터의 시간축이 맞지 않으면 검증 자체가 불가능합니다

結論

공공 데이터는 단순 공개가 목표가 아니라 ‘검증 가능성’과 ‘재활용성’이 핵심입니다. PDF에 박힌 표를 이미지로 둔 채 공개하는 건 코드로 검증하려는 사람들한텐 무용지물이에요. 東京都や埼玉県、各市町村のカタログ（catalog.data.metro.tokyo.lg.jp、opendata.pref.saitama.lg.jpなど）を見ても、CSVで出しているところはあるけどスキーマ統一やAPI提供が不十分で、エンジニア目線だと改善ポイントが山盛りです。

レポート本文

現状サーベイ — これ見てくださいよ

• 東京都オープンデータカタログ（https://catalog.data.metro.tokyo.lg.jp/dataset）は大量のデータセットをカタログ化している。だがメタデータやスキーマ記述がまちまちで、ダウンロード後に型チェックや正規化が必要になるケースが多い。
• 埼玉県オープンデータ（https://opendata.pref.saitama.lg.jp/）はポータルが整備されていてダウンロードしやすいが、APIで時系列取得できるかはデータによってバラつきあり。
• 新潟市のCSVマニュアル（https://www.city.niigata.lg.jp/.../csv_manual_v1.1.pdf）は好例で、機械判読に適したCSV作成のガイドラインを提供している。つまり指針がある自治体は強いんです！

要するに、オープンデータの“出し方”の差がそのまま活用可能性の差になるということです。

技術的な問題点の整理

フォーマット混在（PDF、Excel、CSV、CSVでもエンコ・区切りの違い）

- 問題点：自動処理が壊れる。エンジニア的に言うと、パーサーが全パターンに対応しなきゃいけなくて非効率。

スキーマ不在／不統一

- 問題点：列名が自治体ごとに違う（例：population vs 人口 vs 人口数）、型や単位の記載がないデータがある。

時系列の欠落とKPIリンク不足

- 問題点：政策目標（KPI）があるが、KPIの実績時系列が公開されていないと達成度が検証できない。デジタル田園都市構想の交付金評価資料（chisou.go.jp）を見ても、KPIとデータの紐付けが弱い事例がある。

API不足／ドキュメント不足

- 問題点：CSVを落として終わりだと自動更新・パイプライン化が難しい。APIがあればCronで取りに行けるのに！

コードで語る：実務的な検証フロー（例）

以下は典型的なKPI検証パイプラインの例です。PythonでCSVを取ってスキーマ検証→差分チェック→可視化までを示します。

# 예시 코드 (간단화)
import requests
import pandas as pd
from frictionless import Schema, Resource

url = 'https://catalog.data.metro.tokyo.lg.jp/dataset/.../download/data.csv'
df = pd.read_csv(url)

スキーマ定義（例）
schema = Schema.from_descriptor({
'fields':[{'name':'year','type':'integer'},{'name':'population','type':'integer'}]
})
resource = Resource(data=df, schema=schema)
resource.validate()  # エラーが出たら整形/補正を要する

KPIギャップの計算
kpi_target = 1000000
latest = df.sort_values('year').iloc[-1]['population']
gap = kpi_target - latest
print(f'KPI gap: {gap}')

要するに、オープンデータは“パイプラインに載るか”が重要で、そこを踏まえた公開が求められます。

政策の数値目標と実績のギャップをどう見るか

• まずはKPIとデータセットを安定リンクさせる（Dataset metadataにKPI IDを入れる）。
• 時系列データを最低でも年次・四半期で揃える。スナップショットしかないとトレンド分析できない。
• 外部監査やアーカイブ（例：Sukagawa市の実績評価ページ）をデータ化して、第三者が再現可能にする。

SQLでの簡単な達成率算出例：

SELECT year, actual / target AS achievement_rate
FROM kpi_timeseries
WHERE kpi_id = 'digital_infra_1'
ORDER BY year;

改善提案（現場で今すぐできること）

CSVだけでなくJSON/JSON-LDやGeoJSONでの公開を標準化する

OpenAPI / OData でAPIエンドポイントを用意して時系列を取りに行けるようにする

Frictionless Data Package やData Package Schemaでスキーマをバンドルする

CIでデータ検証（型チェック、Null率、突発的増減のアラート）を導入する

KPIとデータセットをメタデータで直結（データセットに kpi_id を付与）

既存PDF資料はOCR→構造化→CSV化の自動パイプラインを作る（ただし精度評価が必要）

これで、政策の“言った・やった”をコードで確認できるようになります！

実運用のハードルと現実解

• 人員と予算の問題：多くの自治体で運用負荷がネック。ここは国のガイドライン（Digital庁）と交付金の設計次第で改善余地あり。
• 既存システムのレガシー：古い基幹系システムからの抽出はつらい。ETL層での定期バッチ整備が現実的です。
• 標準化コスト：共通スキーマを作る初期工数は必要。ただし一度やれば再利用コストが下がるので中長期で得です。

まとめ

• オープンデータは『公開』より『検証可能性』と『再利用性』が重要です。
• フォーマット、スキーマ、APIの3点セットが揃っている自治体のデータは即戦力になります。
• 技術的にはFr ict ionless/JSON-LD/OpenAPI/CICDによる品質担保が有効。政策側はKPIとデータの紐付けを明確に！

おかむーから一言

テックで社会を変えるって言ってるんで、データぐらいAPI一発で出しましょうよ！スタックを整えれば検証と改善がスピードアップします。熱いですよね！