どうも〜おかむーです！今日は自治体オープンデータのちょっと技術寄りな話をしますよ〜

• 3行要約

- 自治体データは地域固有のフィールド（自治体固有コード・地名の表記ゆれなど）があるため、単純な標準化では潰れてしまうことが多い

- 解決策は「コア＋ローカル拡張」スキーマと、翻訳・正規化レイヤを備えたETLパイプライン

- 実装はJSON-LDで意味づけ、JISコードやCLDRを使ったマッピング、jsonschema/パイプラインで自動検証

結論

自治体データは“全部同じ型にする”と地域性を失う。じゃあどうするかと言うと、コアで共通性を担保しつつ、ローカル拡張を公式に許容するスキーマ設計が最強です。エンジニア的に言うと、schema＝ミニマム必須＋extensionsで、変換／正規化レイヤをCIに組み込めば再利用性が劇的に上がります！

レポート本文

問題意識：地域性 vs 汎用性

これ見てくださいよ。東京都のデータカタログ（https://catalog.data.metro.tokyo.lg.jp/dataset）や埼玉県のオープンデータ（https://opendata.pref.saitama.lg.jp/）を眺めると、CSVや表現は多様で、同じ「児童数」「避難所」でもフィールド名や住所表記がバラバラなんですよね。新潟市はCSV作成ガイド（https://www.city.niigata.lg.jp/shisei/seisaku/it/open-data/index.files/csv_manual_v1.1.pdf）を出していて親切だけど、それでも各自治体の事情でローカル列は残る。

要するに、標準化だけでは足りないということです。

提案：コア＋ローカル拡張スキーマ

設計方針はシンプル。

• core: 全国共通の必須フィールド（例：jis_code, name_ja, geometry, updated_at）
• local_extensions: 自治体固有の列は extensions オブジェクトに格納
• semantics: JSON-LD / schema.org を付与して意味づけ

利点：APIや検索インデックスは core に依拠して高速に横断検索でき、詳細表示や地域固有解析は extensions を参照する。

実践テクニック

地名正規化：JIS X 0401/0402 コードの活用。住所はローマ字表記や別名もCLDRや自前の辞書で補正

多言語対応：survey データ（例：外国人住民向け調査がある東京都のデータ）では name_en/name_ja を用意

機械可読性：CSVを吐く場合も先にJSON-LDを設計し、CSVはその簡易シリアライズと位置づける

バリデーション：jsonschema をCIで回す

簡単な検証コード例（Python + jsonschema）:

# pip install jsonschema pandas
import jsonschema, json
from jsonschema import validate

core_schema = {
"type": "object",
"required": ["jis_code","name_ja","geometry"],
"properties": {
"jis_code": {"type":"string"},
"name_ja": {"type":"string"},
"name_en": {"type":"string"},
"geometry": {"type":"object"},
"extensions": {"type":"object"}
}
}

def validate_record(rec):
validate(instance=rec, schema=core_schema)

サンプル
rec = {"jis_code":"13101","name_ja":"千代田区","geometry":{}}
validate_record(rec)
print('OK')

拡張マッピングの例：自治体固有の避難所コードを core.extensions.disaster.shelter_code に入れる、というルールを決めておけば、横断分析がしやすくなります。

パイプライン設計（実務レベル）

• Ingest: ポータル（Tokyo/Saitama/Hakodate等）から定期取得
• Normalize: 住所→JISコード、表記揺れ→正規化辞書、言語タグ付与
• Validate: jsonschema + データ品質チェック（欠損、重複、型）
• Publish: coreをAPIで公開、extensionsは別エンドポイント/ダウンロード

CI/CD化しておくと、データ更新で破壊的変更が入ったときに検知できるのが便利です。なお、国のデジタル庁（https://www.digital.go.jp/）の方針を参照しつつ、ローカル事情を尊重する運用が現実的です。

活用アイデア

• マッピング：ローカル拡張を使って地域独自の施策（例：観光補助・防災体制）の効果を追跡
• 共通ダッシュボード：coreだけで全国比較、extensionsで自治体の詳細分析
• 多言語オープンデータ：観光・外国人支援に使えるデータ変換パイプライン

まとめ

• 完全標準化は現実離れ。core＋extensions戦略が現場で効く
• JISコードやCLDR、JSON-LDを組み合わせて意味を担保するのがポイント
• jsonschemaをCIに組み込んで「壊れないデータ流通」を作ろう

おかむーから一言

自治体データって泥臭い仕事が勝負ですけど、エンジニア視点の小さな設計が政策の再現性を劇的に変えます。ローカルを尊重して、コードでちゃんと繋ごうぜ！