どうも〜おかむーです！今日は行政データを技術でつなぐ話をしますよ〜

• 交付金や事業レポートがPDFに散らばっている問題、公共IDで解決できる
• エンジニア視点で「識別子」「スキーマ」「公開フォーマット」を揃える具体案
• 実装例（UUIDv5でのID生成、JSON-LDメタデータ、OpenAPIでの公開）と運用提案

結論

自治体や国の政策データは「識別子の欠如」でつながらないことが最大のボトルネック。政策・交付金・KPI・施設・成果を横断して結びつけるために、まずは軽量で一意な『公共ID』設計とメタデータの標準化（JSON-LD / DCAT）を導入すべきです。エンジニア的に言うと、「ID」と「スキーマ」と「API」の3点セットを先に決めるだけで、データの再利用性が劇的に上がります！

レポート本文

背景：データの現状と課題

これ見てくださいよ。デジタル庁や総務省は自治体情報システムの標準化を進めているんですが（https://www.digital.go.jp/、https://www.soumu.go.jp/）、現場を見ると交付金の報告がPDFフォーマットで自治体サイトに散らばっていたり、KPIがPDF内に埋め込まれていたりします（山口県の交付金実績PDFなど：https://www.pref.yamaguchi.lg.jp/uploaded/attachment/160746.pdf）。

要するに、機械が拾える形でIDが振られていないから紐付けができないということです。

なぜ『公共ID』が効くのか

• 一意の識別子があれば、事業→交付金→KPI→施設→報告書を結合できる
• PDFに含まれる値もIDで指し示せれば、OCRや手作業で拾ったデータの信頼性が上がる
• APIやカタログ（DCAT）でIDを参照すれば連携が自動化可能

エンジニア的に言うと、IDはAPIのリソースURIの一部であり、JSON-LDの@idとして振るだけでノードグラフが作れます。

公共IDの設計方針（実務案）

名前空間を定義する（例: https://data.pref.example.jp/）

リソース種別をプレフィックスで表す（grant, project, kpi, facility）

不変な一意IDをUUIDv5（名前ベース）で生成する

メタデータはJSON-LDで公開、DCATでカタログ化する

メリット：ヒューマンリーダブルなURI、衝突しにくいID、リンクトデータとの親和性

コード例：UUIDv5でIDを作る（Python）

import uuid
namespace = uuid.UUID('12345678-1234-5678-1234-567812345678')
name = 'yamaguchi:grant:2024:12345'  # 都道府県:種別:年度:事業ID
public_id = str(uuid.uuid5(namespace, name))
print(public_id)
=> 'e4b7...'

このIDをリソースの@idにして、JSON-LDで公開します。

JSON-LDメタデータの例

{
"@context": "https://schema.org/",
"@id": "https://data.pref.yamaguchi.jp/grant/e4b7...",
"@type": "Dataset",
"name": "デジタル田園都市交付金・事業12345",
"description": "交付金情報とKPIを紐づけたメタデータ",
"license": "https://creativecommons.org/publicdomain/zero/1.0/"
}

API公開と互換性

• OpenAPIでエンドポイントを定義（/grants/{id}, /kpis/{id}, /facilities/{id}）
• バージョニングはURLベース（/v1/）よりヘッダで管理する方針を推奨
• レガシー自治体システムはFacade APIで包む（SOAPやオンプレDBの前にAPI層を置く）

エンジニア的に言うと、Facadeパターンでレガシーとモダンをつなぎ、徐々に内部を置換すれば運用負荷が減ります。

KPIと実績のギャップをIDで測る

山口県の実績PDFにはKPIが設定されている事が確認できますが、これを機械判読可能にするには各KPIにも公共IDを振ることが有効です。IDがあれば年度ごとの実績を時系列で追い、APIで自動集計できます。CSVやJSONでKPI実績があれば、簡単にダッシュボードやCIで監視可能です。

運用提案（現場で取れるステップ）

まず試験的に一自治体と交付金の事業だけでIDを振るPoCをやる

JSON-LDでカタログを出し、DCATエントリを総務省／地域カタログに登録する

既存のPDFレポートにID注記を入れる（PDFのメタデータ／HTMLのリンク）

オープンソースのFacadeテンプレ（Dockerで動く）を配布して展開を加速する

技術的注意点

• 個人情報はID化に向かないので、公共IDは非PIIリソース（事業・施設・KPI）に限定
• ライフサイクル（廃止・統合）のポリシーを決めること。IDは不変だがエイリアスを追加する必要あり
• 互換性のためにJSON SchemaとOpenAPIのスキーマを同時に公開する

まとめ

公共IDを導入すれば、バラバラのPDFや自治体ごとのフォーマットによるデータの断絶が解消されます。要するに、まずは小さくIDを振ってAPIで公開する実証をやれば、政策評価やダッシュボード、自動集計の世界が一気に近づきます！

おかむーから一言

テクノロジーで行政をもっとつなげたいんです。まずはIDを1つ振って、データをつなげてみましょう。小さな勝ちを積み重ねれば、社会はちゃんと変わるんですよ！