コードで語るマニフェスト：自治体オープンデータを技術で検証する

• 이거 3줄로 요약합니다!
• 東京都·埼玉県 등 공공데이터 포털에는 CSV·GeoJSON 등 기계판독 가능한 데이터가ある 반면, PDF에 묻혀 있는 자료도 여전해요
• 정책 성과는 KPI로 적절히 관리될 때만 검증 가능하고, 지금은 데이터 파이프라인·API 표준화가 필요해요
• 엔지니어 관점에서의 개선제안(API, JSON Schema, 자동검증)을 제시합니다

結論

데이터는 이미 있고, 문제는 '열려있는 방식'이에요. PDF·散在メタデータ·비표준フォーマット 때문에 실사용으로 이어지지 않는 경우가多いです。エンジニア的に言うと、APIとスキーマが一本化されれば、自治体データはぐっと使いやすくなりますよね！

レポート本文

何を見たのか（データソース）

これ見てくださいよ：東京都オープンデータカタログ（portal.data.metro.tokyo.lg.jp / catalog.data.metro.tokyo.lg.jp）はCSVやGeoJSONを明示してて、機械可読性は比較的良いです。埼玉県（opendata.pref.saitama.lg.jp）や新潟市（city.niigata.lg.jp）のポータルも同様にCSVを公開してます。

一方で、補助金や事業評価の報告（例：chisou.go.jpや山口県の実績PDF）はPDF主体で、KPIと実績が本文のテキストに埋もれているケースが多いんですよね。

参考：

• 東京都カタログ: https://catalog.data.metro.tokyo.lg.jp/dataset
• 埼玉県オープンデータ: https://opendata.pref.saitama.lg.jp/
• 地方創生データ分析プラットフォーム（RAIDA）: https://raida.go.jp/
• デジタル田園都市国家構想関連ガイド: https://www.chisou.go.jp/

技術的検証ポイント

1) フォーマットと機械可読性

• 良い点：CSV・GeoJSONを直接ダウンロードできるデータセットが存在。地理情報はGeoJSONで提供されれば即マップ化可能。
• 問題点：PDF報告が残っている、あるいはCSVでも列名がバラバラで統一スキーマがない。要するに「同じ意味のカラムに統一IDが振られていない」ことが多いです。

2) APIの有無と使い勝手

• portal.data.metro.tokyo.lg.jpはファイルダウンロード中心で、RESTfulなAPIが限定的な場合がある。RAIDAやデジタル庁の事例集は参照には良いが、生データ取得用の標準APIは自治体ごとに差が大きい。

3) メタデータとライフサイクル管理

• DCATやJSON-LDなど標準メタデータを一貫して使っている自治体は少数。更新日が明示されていてもスキーマバージョン管理がないため、既存のETLが壊れやすいです。

4) KPIと実績の可視化

• デジタル田園都市交付金のKPIはガイドに記載があるが、実績値が機械読取可能な形で公開されている自治体は限られる。PDF化されると数値の集計・検証が手作業になります。

エンジニア的な改善提案（具体案）

• APIファースト：すべての主要データはREST/GraphQL APIで取得できるようにする。GET /datasets/{id}/download.csv のような固定エンドポイントを推奨。

• スキーマ定義：JSON Schema / CSV Schemaを公開して、列名・型・必須フラグを明文化する。例：

{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "population-by-ward",
"type": "object",
"properties": {
"year": {"type": "integer"},
"ward_code": {"type": "string"},
"population": {"type": "integer"}
},
"required": ["year","ward_code","population"]
}

(要するに：構造を示せばデータ利用が圧倒的に楽になるということです)

• CIによるデータ品質チェック：CSVのヘッダ変化、null率、重複チェックを自動化。GitHub ActionsやGitLab CIでパイプラインを回しておくと安心です。

• PDF→構造化化の自動化：既存のPDF報告はOCR＋ルールベース抽出で一旦構造化して、JSON/CSVを生成するETLを用意。将来的には報告テンプレート自体を機械可読形式で提出させるのが理想。

• 事例共有と共通カタログ：RAIDAのような横断プラットフォームに、メタデータとAPI仕様を集約して検索できるようにする。

コード例（データ取得イメージ）

PythonでCSVを読み込む簡単な例です。実際にこれで解析すればすぐにグラフ作れるのがエンジニアの強み！

import pandas as pd
url = 'https://catalog.data.metro.tokyo.lg.jp/dataset/xxx/download/population.csv'
df = pd.read_csv(url)
print(df.head())

要するに、API一本で取れる形にしておけばデータ利活用のコストが劇的に下がります。

KPIと実績ギャップの見方

• ガイド（chisou.go.jp）や交付金報告（例：山口県PDF）を見ると、KPI設定自体は行われているが、実績の“機械可読な公開”が不足しているため外部からの検証が難しい。
• 数字ベースで言うと「目標値Xに対して実績Y」といった時系列テーブルがあれば、トレンド分析や爆発的な外部アプリ連携が可能になるはずです。

活用アイデア

• 洪水リスクや避難所マッチングのように地域横断データを組み合わせるアプリはすぐ作れる。米国の洪水リスクサイトのように、標高データ＋過去被害＋人口動態を結合すれば住民向けサービスの価値は高いです（参照：宙畑の事例まとめ）。

まとめ

• 公共データ自体は増えているが、フォーマットとAPI標準化が追いついていない
• PDF依存とスキーマ不統一が利活用のボトルネック
• 解決策はAPIファースト、JSON Schema、CIベースの品質管理、PDF→構造化ETLの導入
• 技術的コストを下げれば、市民・企業による二次利用が爆発的に増えるはずです！

おかむーから一言

どうも〜 오카무입니다! テクノロジーで行政をもっと早く、もっと透明にしていきたいです。API一本で実証可能な未来、いっしょに作りましょう！