どうも〜おかむーです！今日はちょっとエンジニアっぽい話をしますよ〜

• オープンデータに「永続的な識別子（ID）」がないと、異なる府省・自治体のデータをつなげられない
• ID設計は政策評価やKPI追跡の精度に直結する。機械可読化だけじゃ足りないんですよね
• 実務では「自然キーの衝突」「スキーマ変化」「バージョン管理不足」が主な障害になる

結論

行政データの利活用を進めるには、単にCSVやAPIで公開するだけでなく「恒久的かつ連結可能なID設計」が不可欠。要するに、データ同士をつなぐための設計ルール（命名規則・バージョン・リゾルバ）がないと、政策の実績と目標を正しく紐付けられないということです。

レポート本文

なぜIDが重要か？

これ見てくださいよ：NICTERのCSV（notice.go.jp）や環境省のCSV（env.go.jp）って公開はされてるんですけど、各行に入ってる識別子が局所的だったり省ごとにフォーマットが違ったりするんです。エンジニア的に言うと、キーが一意に保証されていないとJOINができない。要するに“つなげられないデータ”になります。

また、デジタル庁や内閣官房の資料（digital.go.jp、cas.go.jp）ではAI-Readyや機械可読性が謳われてますが、実務ではIDの永続性や後方互換が抜け落ちるケースが多い。これがKPIの追跡ミスや重複集計の原因になるんですよね。

よくある設計欠陥

• 自然キー依存（名称や住所をキーにする）→表記ゆれで衝突
• 省独自の連番のみ（別府省で同じIDが再利用される）→重複
• バージョンレス（更新のたびに上書き）→変更履歴が追えない

政策目標とIDのギャップ例

デジタル田園都市交付金のKPI報告（chisou.go.jp / 都道府県レポート）を追う場面を想像してください。補助事業の実績（pref.yamaguchi.lg.jp等PDF）と国側の交付金データを突き合わせるには、事業IDが必要。だけどPDFには事業名だけで一意なIDがなく、人手で突合せすると誤差が出ます。要するに、自動化が効かないんです。

技術的改善案（現場で使えるチェックリスト）

グローバルに一意なIDスキーマを定める（例: jp.gov.{agency}.{dataset}.{local-id}）

IDは不変にする（変更が必要なら新バージョンとして別IDを発行）

各公開データにcanonical_id列を必須化する

レジストリ（小さなRDF/JSON-LDカタログ）でIDのメタ情報を公開する

APIはIDで検索・参照でき、Content-Location/ETagでバージョンを示す

実務で使えるコード例

例えばCSVに固有IDがないとき、公開データを取り込んで一時的にハッシュで振り直すサンプル（Python/pandas）:

import pandas as pd
import hashlib

df = pd.read_csv('https://www.env.go.jp/content/900398071.csv')
結合可能なキーが無ければ、ソースと行の重要フィールドでハッシュ作成
def make_canonical(row):
s = f"env:{row['project_name']}:{row['address']}"
return hashlib.sha256(s.encode('utf-8')).hexdigest()

df['canonical_id'] = df.apply(make_canonical, axis=1)

要するに、最初は暫定ハッシュでつなげることができるんですけど、恒久的には公式IDを発行すべきです。

実装の注意点

• IDの公開は政策的合意が必要（どのレベルで一意化するか）
• 過去データとの互換性を保つために変換マップを公開する
• プライバシー配慮で、個人を特定するIDは設計しない

まとめ

• 永続的なID設計はオープンデータの“つながり”を作るインフラで、政策評価の精度を上げる
• 技術的にはグローバル命名、バージョン管理、レジストリ公開、APIでのID参照が鍵
• 今すぐできることはCSV/APIsにcanonical_id列を足すこと。これ、現場コストほとんどかからないんですよ！

おかむーから一言

政府データの価値は“つながる”ことで倍増します。ID設計は地味だけど超重要。エンジニアと政策担当が一緒に作るべき基盤ですね！