どうも〜おかむーです！今日は自治体オープンデータの「標準化」って現場でどう実装されているか、エンジニア目線でチェックしてみましたよ〜

• 東京都カタログや自治体CKANの事例を見て、データ形式・API・メタデータの実装差を確認
• 「自治体標準オープンデータセット（デジタル庁推奨）」準拠の度合いを技術的に評価
• 機械可読化、スキーマ管理、運用ワークフローの改善案をコード例付きで提案

結論

標準化の“宣言”は進んでいるけど、実際の現場はフォーマットのばらつき・メタデータ不足・更新自動化の欠如で利活用ハードルが残っている。エンジニア的に言うと、フリクショントラップは「不揃いのスキーマ」「CSVのエンコーディング」「APIの不統一」に集約される。要するに、スキーマ駆動の公開（schema.json / datapackage）とAPI設計、CIでのデータ検証を組めば一気に使いやすくなるということです。

レポート本文

背景と参照ソース

これ見てくださいよ：東京都オープンデータカタログ（https://portal.data.metro.tokyo.lg.jp/ と https://catalog.data.metro.tokyo.lg.jp/dataset）はCSVやGeoJSONを多く公開していて、自治体標準セットに準拠したデータも増えている（検索結果にある通り）。一方、地方CKANや県ポータル（例：大仙市のCKAN、埼玉県のデータカタログ）ではAPIキーやパッケージ構造の違いがある。

参照：東京都カタログ、GovTech東京のデータ利活用ページ（https://www.govtechtokyo.or.jp/services/data-utilization/）、大仙市CKAN、埼玉県データカタログ

技術観点で見る「ズレ」ポイント

• フォーマットのバラつき：CSV / XLSX / PDF / GeoJSONが混在。PDFは論外としても、CSVでも区切り・エンコーディング（Shift_JIS vs UTF-8）でハマることが多い
• スキーマ不在：フィールド名が自治体ごとに違い、年度やIDの規則も統一されていない。これだとデータ連結や横断分析が地味にめんどくさい
• メタデータ不足：更新頻度・ライセンス・取得日時が機械可読でないケースが多い。APIがあってもレスポンスにschema情報がない
• 更新ワークフロー未整備：データ更新が手作業で、差分公開やバージョニングがない（dataset-levelのバージョン管理がない）

エンジニア的チェックリスト（実務でまず見ること）

• dataset の metadata に license, provenance, updated_at があるか
• ファイルが UTF-8 であるか（utf-8-sig 推奨）
• スキーマ定義（JSON Schema / datapackage.json）が付いているか
• API でページネーション・CORS・Content-Type が適切か

実践：CKAN API と pandas/GeoPandasで触るサンプル

エンジニア的に言うと、API一本で解決する話なんですよね。サンプル（Python）を置いときます:

# package_search で dataset メタ取得
import requests
r = requests.get('https://catalog.data.metro.tokyo.lg.jp/api/3/action/package_search', params={'q':'library'})
meta = r.json()

CSV を pandas で読み込み（UTF-8 を期待）
import pandas as pd
csv_url = 'https://example.tokyo/opendata/library.csv'
df = pd.read_csv(csv_url, encoding='utf-8')

GeoJSON は GeoPandas で
import geopandas as gpd
gdf = gpd.read_file('https://example.tokyo/opendata/parks.geojson')

要するに、APIでメタ情報→ファイルURL→形式に応じて読み込む流れが実装できればかなり楽です！ただ、ここでつまづくのがエンコーディングとフィールド命名の不一致なんですよ。

スキーマ駆動での改善提案（具体案）

• 全自治体に対して "自治体標準オープンデータセット" の schema.json を推奨し、catalog に紐づける（例：facility-list/schema.json）
• データパイプラインに CI を導入：新しいCSV/GeoJSONがアップロードされたら自動で JSON Schema チェック、型チェック、欠損率アラートを出す
• データ配信はCKAN + 静的ホスティング（S3/CloudFront）でURL安定化。APIはOpenAPIで定義しておく
• 差分配信：フルダンプだけでなく変更のみのパッチ（ndjsonやparquetの差分）を提供

例：簡単な schema.json（施設一覧）

{
"fields": [
{"name": "facility_id", "type": "integer"},
{"name": "name", "type": "string"},
{"name": "lat", "type": "number"},
{"name": "lon", "type": "number"},
{"name": "updated_at", "type": "datetime"}
]
}

KPIと政策目標のズレをどう見るか

デジタル庁推奨の「自治体標準オープンデータセット」準拠が政策目標ならば、KPIは「準拠率」「機械判定でエラーが出ないデータ割合」「更新の自動化率」に設定すべき。現場データから見えるのは、準拠率が表面的に高くても『実際に使えるか』で落ちることが多い点。要するに、数値目標だけでなく「可用性」「実用性」をKPIに入れるべきです。

まとめ

• 標準化のフレームワークは揃ってきたが、現場実装のばらつきが利活用のボトルネックになっている
• エンジニア的解決はスキーマ公開、CIによる自動検証、API定義、差分配信の四点セット
• 小さく始めて継続的に改善することが重要。まずは主要データセット5件に対してschema.jsonと自動検証を入れるだけで価値が見えるはず！

おかむーから一言

テクノロジーで公共をアップデートするのは泥臭い作業です。でも正しいスキーマと自動化があれば一気に世界が変わる。やっていきましょう、ワンステップずつ！