• どうも~ 오카무입니다! 오늘은 정부·지자체 데이터의 '機械可読性'와 API 설계 문제를 코드 관점에서 파고들어요.
• 이 글은 e-Gov API(https://www.e-gov.go.jp/digital-government/api)와 Tokyo Open Data(https://portal.data.metro.tokyo.lg.jp/opendata-api/) 등을 실제로 보면서, PDF vs CSV 문제, 스키마 품질, 개선 방안을 제안합니다.
• 결론적으로는 「오픈데이터 ＝ 공개」에서 끝나지 않고, 설계·운영·검証 가능한 API와 파이프라인을 만들어야 정책의 실효성이 담보됩니다.

結論

정부·지자체가 데이터와 시스템을 '공개'하는 건 시작일 뿐입니다. 진짜 엔지니어링 과제는 데이터의 기계 가독성(포맷·스키마), 신뢰성(스키마 검증·バージョン管理), 그리고 API 운영(認証·CORS·レート制限·仕様化)을 확보해, 정책 목표와 실績을 코드로 재현 가능하게 만드는 것입니다.エンジニア的に言うと、API 한 줄로 정책 검증이 가능해야 하죠!

レポート本文

現状観察：公開はあるけど“使える”か？

これ見てくださいよ。国や都道府県のポータル（e-Gov APIやTokyoのオープンデータ）は存在するんですけど、現実はこうです：

• PDFに埋められたレポートが多く、テーブルはOCRや手作業で抽出しないと再利用できない。要するに、機械にとってはゴミ箱扱いなんです。
• APIは一部公開されているが、エンドポイントごとに仕様がバラバラ。OpenAPI/JSON Schemaで仕様が定義されていないケースが多い。
• 更新頻度やバージョン管理が曖昧で、同名のデータが期間ごとに構造変化しても互換性保証がない。

実例：Tokyo Open DataのPublicFacility API（GET /PublicFacility）はJSONで取得できて便利なんですが、メタデータの説明が弱い、日付とタイムゾーンの扱いが統一されていない、IDの永続性が担保されていない、といった課題があります（参考: https://portal.data.metro.tokyo.lg.jp/opendata-api/）。e-GovのAPIカタログは良い出発点（https://www.e-gov.go.jp/digital-government/api）ですが、APIごとの実装例やサンプルコードがもっとあると開発者側の参入障壁が下がります。

技術的課題をもう少し掘る

• フォーマット：PDF > HTML > CSV/JSON/NDJSON/Parquet の順で機械可読性が下がる。

- 要するに、CSV/JSONで出してください、ということです。

• スキーマ：JSON Schema / OpenAPIで型と必須フィールドを明示していないと、取り込みパイプラインが脆弱になる。
• メタデータ不足：更新日時、ライセンス、発行機関、連絡先が明示されてないとデータ利用の法務・運用リスクが増す。
• 運用API：CORS、認証方式（APIキー／OAuth）、レート制限、SLAが未整備だと実運用で詰む。

コードで見せる — 実際にAPIを叩く例

エンジニア的に言うと、API一本で解決する話なんですよね。例えばPythonでTokyoのPublicFacilityを引っ張る簡単な例：

import requests
import pandas as pd

url = "https://portal.data.metro.tokyo.lg.jp/opendata-api/PublicFacility"
res = requests.get(url, params={"format": "json"}, timeout=10)
res.raise_for_status()
data = res.json()

要するに、JSONをDataFrameにしてクレンジングすれば地理可視化も楽
df = pd.json_normalize(data['rows'])
print(df.columns)

このレベルのサンプルが公式にもっとあると助かりますよね。サンプルノートブック（Jupyter/Colab）を公開して、取り込み→正規化→可視化までのパイプラインを示すべきです。

政策の数値目標と実績のギャップ分析

政策は目標値を掲げるが、実績データが「人手で整備されたPDF」だと定期的な評価ができない。例えば「行政サービスの処理時間短縮」や「障害者対応トイレ数の増加」などは、時系列で追えないと改善効果が証明できない。

おすすめの流れ：

• KPIをAPIのエンドポイントで公開（/kpi/service-processing-time?period=2025Q1 みたいに）
• 生データ＋集計値（mean/median/percentiles）を併記
• アンチパターン：年報PDFにだけ載せておしまい、これは評価不能。

改善提案（実装レベル）

ここは改善の余地ありまくりだと思ってます！具体的にやるなら：

OpenAPI + JSON Schemaを必須化

- エンドポイントごとにOpenAPI仕様書（yaml/json）を公開して、型とHTTPステータスを明記する。

機械可読フォーマットを第一公定値に

- PDFは人間向けの別添とし、データ配布はCSV/NDJSON/Parquetを推奨。

データカタログ（CKAN/DataHub等）を整備

- メタデータ（更新頻度、バージョン、ライセンス、連絡先）を必須項目に。

CIでスキーマ検証を回す

- 新しいデータ投入時にスキーマチェック→差分検出→自動通知のワークフロー。

サンプルコードとノートブックの提供

- Python/Rのサンプル、Kaggle/Colabノートを用意してコミュニティが再現可能に。

KPI APIを設計

- 政策ごとにKPIエンドポイントを用意して、数値目標と実績を機械的に比較可能にする。

実運用のための技術スタック案

• データカタログ：CKAN or DataHub
• API仕様管理：OpenAPI + Swagger UI
• パイプライン：Airflow / Prefect
• スキーマ管理：JSON Schema + Confluent Schema Registry（イベント系）
• データフォーマット：日次大量データはParquet、公開APIはNDJSON/CSV

まとめ

• 公開はされているが「使える」形で出てないケースが多い。PDF文化からの脱却が第一歩です。
• OpenAPI/JSON Schema、メタデータの厳格化、CIによるスキーマ検証、サンプルコードの提供で再利用性は劇的に向上します。
• KPIをAPIとして公開すれば、政策の目標と実績をコードで比較できるようになり、説明可能性と信頼性が上がります。

おかむーから一言

テクノロジーは嘘をつかない。データをちゃんと出して、APIで繋いで、検証可能にしよう。社会はもっと早く変わるはずだよ！