どうも~ 오캄입니다! 오늘은 조금 엔지니어스러운 관점으로 정부·지자체 데이터 시스템을 뜯어보려 합니다~

• 이 글 세 줄 요약

- 도쿄 오픈데이터 포털과 지방 CKAN 사례를 기술적으로 비교 검토함

- PDF·비슷한 포맷 문제, API 부재·메타데이터 미흡 등 기계가 읽기 어려운 점을 지적

- 개선안: 표준 스키마(自治体標準オープンデータセット), JSON Table Schema, CI/CD, API 설계 제안

結論

결론부터 말하면, 정책 목표(데이터 개방·재사용 촉진)는 좋은데 실제 구현에서는 여전히 엔지니어가 바로 쓰기 어려운 장애물이 많습니다. 데이터 포맷·메타데이터 표준화와 배포 파이프라인 자동화가 우선 과제입니다.

레포트 본문

현황 체크: 어디가 잘 되고 어디가 안 되는지

이거 한번 보세요: 도쿄 메트로폴리탄의 포털(https://portal.data.metro.tokyo.lg.jp/)은 많은 데이터셋을 카탈로그화하고 있고, 특정 데이터는 CSV·GeoJSON으로 공개돼요(검색결과[1][2] 참조). 반면 도시·지방별로는 CKAN 기반 레지스트리(예: 大仙市의 CKAN, 검색결과[4])나 각도(県)의 데이터 카탈로그(埼玉県, 검색결과[5])가 섞여 있습니다. 데이터 포맷, 업데이트 주기, API 유무, 메타데이터 수준이 들쭉날쭉한 게 현실이에요.

• PDF에 묶여 배포된 통계·보고서: 사람 눈으로 읽기엔 OK지만 기계처리 불가. 엔지니어적으론 "CSV로 주면 바로 쓰는데 왜 PDF로...!"라는 생각이 듭니다.
• CSV/GeoJSON을 제공하는 경우도 스키마 불일치(컬럼명·타입·日付形式), 문자 인코딩 문제(UTF-8/Shift_JIS 혼재)가 흔함.
• API: 일부는 CKAN API나 포털 내부 API로 접근 가능하지만, 일관된 REST 설계나 버전 관리가 부족함.

기술적 문제점 (좀 더 구체적으로)

메타데이터 부족

- DCAT/JSON-LD 같은 표준 메타데이터가 불충분. 데이터의更新日時やライセンスが曖昧なケースあり

- 要するに、どのデータが最新版か・商用利用OKかが機械的に判断できないということです。

フォーマットの分断

- CSV, XLSX, PDF, GeoPDF 등 섞여 있음. GeoデータはGeoJSON/TopoJSON・ベクタタイルで配ると実務で便利

APIの品質

- CKANのようなAPIはあるが、各自治体でエンドポイントやレスポンスが違う。CORS設定や認証についてのドキュメント不足もある

品質保証パイプラインの欠如

- データ公開が手作業。バリデーション（スキーマ検証・ null チェック・重複検知）が自動化されていない

エンジニア的に言うと: 재현 가능한 데이터パイプライン設計

コード 쓰는 사람이라면 바로 떠올릴 구조가 있습니다. 제안 아키텍처(간단히):

• ソース管理: 데이터 메타와 스키마를 Git 리포지토리로 관리
• CI: GitHub Actions / GitLab CI로 데이터 변환・バリデート（GoodTables, frictionless-data）
• 증분公開: CKAN/Dataverse 또는 자체 API로 자동 업로드
• API: OpenAPI로 명세를 관리하고 버전화

예시 코드(파이썬, CSV를 CKAN에 업로드하는 간단한 흐름):

import requests
from frictionless import describe, validate

1) 스키마 검증
report = validate('data.csv')
if not report.valid:
raise SystemExit('validation failed')

2) CKAN API에 업로드(예시)
CKAN_URL = 'https://example-catalog/api/3/action/resource_create'
headers = {'Authorization':'YOUR_API_KEY'}
files = {'upload': open('data.csv','rb')}
payload = {'package_id':'dataset-id','name':'sample-data'}
requests.post(CKAN_URL, headers=headers, data=payload, files=files)

要するに、データ提供は"人の手でファイルを置く"から"コードでパイプラインを回す"へ移すべきなんです。

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

デジタル庁が推奨する「自治体標準オープンデータセット」(検索結果[3])は、CSV/XLSXでの提供を想定しているはずですが、現場ではPDFでしか出ていない、更新頻度が不明瞭、ライセンス明示がない、といったギャップが目立ちます。目標は「機械可読」でも、実績は「人間可読」止まりになっているケースが多いですね。

改善提案（実務レベルで落とし込む）

• まずはスキーマ標準化: JSON Table Schemaを自治体標準に組み込む
• メタデータ強化: DCAT-AP/J仕様、ライセンスはCC0/ODbL等で明示
• 自動化パイプライン: Git→CI→検証→CKAN(またはAPI)のパイプラインをテンプレ化して配布
• API設計: OpenAPIでエンドポイント標準化。例: /v1/datasets/{id}/resources/{rid}/download
• UX改善: データカタログの検索性（タグ、地理範囲、更新日フィルタ）を強化
• サンプルクエリ提供: BigQuery連携やSQLサンプル、Jupyterノートブックを公式で置く

活用の提案：何ができるか

• スポーツ施設・図書館データを組み合わせて、利用者流動分析やイベント最適配置が可能
• 住宅・人口データ와 공공시설を重ねて、アクセシビリティ指標を作る
• API一本で自治体横断ダッシュボードを作れば政策評価が数値で見える化

まとめ

• 現状: カタログは揃ってきたが、機械可読性・メタデータ・自動化が不足
• 핵심: 스키마 표준화(JSON Table Schema)、CI 기반 검증、OpenAPI 표준화로 재사용성을 높여야 함
• 실천: 소규모 파일럿(예: 하나의 데이터셋을 골라 Git 기반 파이프라인으로 전환)부터 시작하면 빠르게 효과를 볼 수 있음

おかむーから一言

기술로 사회를 바꾸는 건 결국 실행력이라고 믿습니다. 데이터 하나라도 '코드로 말하게' 만들면 정책의 투명성과 재현성이 확 달라집니다. 같이 해보죠!