ライセンスが政策を決める?オープンデータの「使えるか」は法とフォーマットで決まる話

どうも〜おかむーです!今日はオープンデータの地味だけど超重要な話をしますよ〜
- 3行要約
- 実例(函館市のCC-BY表記、各都道府県のカタログ)を見て、コードでライセンスを正規化する手法を紹介
- 政策評価には「機械可読ライセンス率」をKPIにして、SPDXやJSON-LDで自動検証するのが現実的
結論
オープンデータの「開放度」は単にCSVやAPIがあるかだけで決まらないんです。ライセンスが機械的に読めて初めて、企業や研究者は安心して投入できるんですよね。要するに、ライセンスがコードで扱えることが重要ということです。
レポート本文
これ見てくださいよ:現状の抜け・ムラ
検索結果を眺めると、東京都のオープンデータカタログ(catalog.data.metro.tokyo.lg.jp)や新潟市のCSVマニュアル(city.niigata.lg.jp)、函館市の「CC-BY」表示(harp.lg.jp)など、各自治体は公開に取り組んでます。けどエンジニア的に言うと、ここで問題になるのは「書かれてるか」ではなく「読み取れるか」です。
PDFで説明されてたり、HTMLに人間用の文言が埋められているケース、またはライセンス表記が曖昧でどの条件で使って良いか分かりにくいケースが混在してます。要するに、APIでポンと取れる形でライセンスが返ってこないと、再利用パイプラインが止まるんですよね。
技術的にやること — ライセンスをコードで扱う手順
エンジニア的に言うと、これAPI一本で解決する話なんです。具体的には:
- カタログ(/dataset や data.json)から license フィールドを抽出
- 自由表記をSPDX識別子に正規化(例:"CC-BY" → "CC-BY-4.0")
- 指定がなければ "NOASSERTION" と扱い、公開ワークフローで差戻し
- 結果をJSON-LDやDCATで出力して二次流通まで追跡可能にする
コード例(Python、簡易):
import requests
from urllib.parse import urljoin
SPDX_MAP = {
'cc-by': 'CC-BY-4.0',
'cc0': 'CC0-1.0',
}
def fetch_catalog(base_url):
r = requests.get(urljoin(base_url, '/dataset'))
return r.json() # CKAN風のJSONを想定
def normalize_license(raw):
key = raw.lower().replace(' ', '').replace('-', '')
return SPDX_MAP.get(key, 'NOASSERTION')
上のコードは概念モデルですけど、実運用はHTMLパースやJSON-LD、RDFのパターンを網羅する必要があります。
政策評価とKPIの提案
政策には目標値が必要ですよね。ここは具体的にやる提案:
- KPI: 「機械可読ライセンス率」= (ライセンスがSPDX等で機械的に解釈可能なデータ数) / (公開データ数)
- 目標: 1年で80%→2年で95%(自治体規模で調整)
- 付帯KPI: 再利用リクエスト数、二次提供サービス数
これをSLOっぽく運用して、CIで新規公開時にライセンス検証を必須にするんです。GitHub ActionsやCIジョブでメタデータを検証して、NGなら公開フローを止める。
実装パターンと運用設計
- 形式: JSON-LD (DCAT) + licenseSPDX フィールドを必須化
- デプロイ: カタログ更新時にライセンスチェックのCIが走る
- ライセンス翻訳テーブルを自治体ごとに管理(ローカルルールを吸収)
- レガシー対応: HTML/PDFから自然言語処理でライセンス文言を抽出し、推定SPDX付与(但し人の確認を残す)
まとめ
ライセンスの“見える化”は地味だけど再利用の肝です。フォーマット(CSV/API)も重要だけど、その上位に「プログラムで解釈できるライセンス」が無いとエコシステムは回りません。SPDXとJSON-LDを軸に、CIでガードする運用が現実解ですよ〜
おかむーから一言
テクノロジーは政策の味付けみたいなもので、ライセンスはそのレシピ。コードで扱える形にしておけば、未来のサービスはもっと自由に生まれます。やっていきましょう!
情報ソース
- https://catalog.data.metro.tokyo.lg.jp/dataset
- https://www.city.niigata.lg.jp/shisei/seisaku/it/open-data/index.files/csv_manual_v1.1.pdf
- https://www.city.niigata.lg.jp/shisei/seisaku/it/open-data/index.html
- https://opendata.pref.saitama.lg.jp/datasets
- https://www.harp.lg.jp/opendata/dataset/79.html
- https://lifeap.co.jp/column/2026/03/18/understanding-public-facilities-definition-types-examples-usage-and-management/
- https://www.intec.co.jp/column/smartcity-08.html
- https://ja.wikipedia.org/wiki/%E5%85%AC%E5%85%B1
- https://www.stat.go.jp/dstart/case/
- https://kotobank.jp/word/%E5%85%AC%E5%85%B1-494676
- https://www.jinji.go.jp/content/900024615.csv
- https://www.env.go.jp/content/900398071.csv
- https://www.inpit.go.jp/content/100869372.csv
- https://www.mhlw.go.jp/content/001429362.csv
- https://www.soumu.go.jp/main_content/000323625.csv
シェアする
関連レポート

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

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

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