組織変更に強い公共データ設計──行政の“名前が変わる”現場をコードで守る

どうも〜おかむーです!今日はちょっとエンジニアっぽい話をしますよ〜。
- 行政組織の改編(省庁再編や局の新設)はデータスキーマの地雷です
- PDFで“名前だけ”書き換えられるデータより、バージョン付きIDで繋ぐ設計が必要
- 技術的にはスキーマバージョニング+永続ID+変換パイプラインで実務的に解決できます!
結論
行政組織が法令で変わるたびにデータの意味(semantics)がずれる問題は、ID設計とスキーマバージョニングで技術的にかなり軽減できる。要するに「名前」ではなく「識別子」と「履歴(バージョン)」で政策データを繋げれば、検証や再現性がグッと上がるということです。
なぜ今この話をするか
政府や自治体のデータ公開は機械可読性ルール(例: 内閣官房・デジタル庁の資料)でCSV/Excel推奨が出てきてますが(https://www.digital.go.jp/...)、実務ではまだ「PDFに組織名だけ直す」運用が残ってます。これ見てくださいよ、組織の表記だけ変わっても、データの意味が変わる(担当窓口・予算科目・評価指標)と後工程が混乱します。
問題を技術的に整理すると
- 名称依存: データに「省庁名」や「局名」文字列しか入っていない
- スキーマ非可逆: 組織改編前後の列の意味が曖昧
- 発見性低下: 過去データを横断するときに照合できない
要するに、エンジニア的に言うと「外部キーが文字列で管理されてる」んですよね。これ、DB設計としては論外に近い。
技術的ソリューション(実務寄り)
- 中央/地方それぞれに永続的な識別子を付与(例: 全国地方公共団体コードは自治体に有効)
- 中央省庁向けには法令改正をトレーサブルにする“行政機関ID”をメタデータで管理
- dataset.json に "schema_version" を入れる。変更点はマイナー/メジャーで管理
- 変換ルールをマイグレーションスクリプトとしてコード管理(Git)
- ETLをコード化してCIで回す。PDF→CSVの変換も含む
- 例: Pythonスニペット(概念例)
# org_map.json を読み込んで古い組織名をIDにマップする例
import csv, json
org_map = json.load(open('org_map.json'))
with open('budget_old.csv') as f:
r = csv.DictReader(f)
out = []
for row in r:
org_id = org_map.get(row['org_name'])
row['org_id'] = org_id or 'UNKNOWN'
out.append(row)
保存して downstream の API へ
- 各データセットに発行日、適用期間、関連法令のURIを付与
- JSON-LDで組織の変更履歴を表現すると連携しやすい
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "内閣府",
"identifier": "gov-org:naikakufu",
"validFrom": "2016-12-01",
"validThrough": "2024-03-31"
}
実装上のチェックリスト
- CSV/JSONで機械可読に出しているか(PDFに頼らない)
- dataset に schema_version と validFrom/validThrough を持たせているか
- 組織IDのマッピングテーブルを公開しているか(履歴付き)
- マイグレーションスクリプトをGitで管理してCIでテストしているか
導入のための運用案(短期/中期)
- 短期: 既存CSVに org_id 列を追加し、マッピングテーブルを公開
- 中期: データカタログ(go.jp など)上で組織の履歴APIを提供(内部は Git + DB)
- 長期: 法令変更と連動するトリガーでデータセットのスキーママイグレーションを自動化
参考資料
- 行政データの機械可読性ルール(デジタル庁): https://www.digital.go.jp/...
- 自治体情報システムの標準化(総務省): https://www.soumu.go.jp/...
- 日本の行政機関(概要): https://ja.wikipedia.org/wiki/日本の行政機関
まとめ
組織名の変化は見た目以上にデータの意味を揺らします。名前ではなくIDとバージョン、そして変換パイプラインをコードで運用することで、政策評価や再現可能性のコストが大幅に下がるはず。PDF依存を減らして、メタデータをちゃんと出しましょう!
おかむーから一言
テクノロジーで行政の“履歴”をちゃんと残そう。名前が変わってもデータの価値は変わらない、っていう世界を作りたいんですよ!
情報ソース
- https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E3%81%AE%E8%A1%8C%E6%94%BF%E6%A9%9F%E9%96%A2
- https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/256dcba6-b936-4031-b88d-3abb27e27f9b/f7af0ca4/20260331_meeting_executive_outline_06.pdf
- https://kotobank.jp/word/%E8%A1%8C%E6%94%BF-52748
- https://www.cas.go.jp/jp/seisaku/digital_gyozaikaikaku/kakusyoDX4/kakusyoDX4.html
- https://www.weblio.jp/content/%E8%A1%8C%E6%94%BF
- https://www.zhihu.com/question/2017291694312280331
- https://www.digital.go.jp/policies/local_governments
- https://www.zhihu.com/question/418844521
- https://www.soumu.go.jp/menu_seisaku/chiho/jichitaijoho_system/index.html
- https://www.zhihu.com/question/40525091
- https://kotobank.jp/word/%E5%85%AC%E5%85%B1-494676
- https://www.intec.co.jp/column/smartcity-08.html
- https://www.pref.miyagi.jp/soshiki/jyoho/miyapo.html
- https://www.digital.go.jp/resources/data_case_study_private
- https://miyagi.efftis.jp/04000/PPI/Public/public/common/jsp/OTeaP_main_frame.jsp
シェアする
関連レポート

公共予約システムの“ログインからAPI化”ロードマップ:パスワードレスで運用コストを下げる技術提案
公共施設予約の認証とデータを段階的にAPI化して運用コストを下げる技術ロードマップを紹介します。

政府データを“つなげる”発想:省庁バラバラを超えるフェデレーション戦略
フェデレーション層で省庁データをつなぎ、PDF混在を克服する実践的な技術案を示す。

政策ダッシュボードは“作るだけ”じゃダメ!KPIを自動で監査するパイプライン設計
政策ダッシュボードの数値を自動監査するパイプライン設計案。API・スキーマ・差分管理でKPIの信頼性を上げる技術手法を紹介します。