コードで語るマニフェスト:オープンデータの「ライセンス可読性」を技術で解く

どうも〜おかむーです!今日はオープンデータのちょっと地味だけど超重要な話をしますよ〜
- 3行要約
- PDFに権利表記だけ載せる自治体がまだ多いので、JSON-LDやDCATで明示する仕組みを提案
- CI/カタログ・API側でライセンス互換性チェックを自動化すれば流通が劇的に改善する
結論
オープンデータは“出す”だけじゃダメで、“プログラムが読める形で権利情報を出す”ことが必須。エンジニア的に言うと、ライセンスはメタデータの一フィールドでしかないんですけど、その値が曖昧だとデータ連携や商用利用にブレーキがかかる。要するに、ライセンスをJSON-LD / DCAT / SPDXで機械的に表現して、APIやカタログの検証パイプラインに組み込むべきです。
レポート本文
何が問題か?これ見てくださいよ
総務省やデジタル庁(例: e-GovのAPIカタログや総務省のオープンデータ戦略)ではデータ公開が進んでますが、現場を見ると「ライセンスはPDFの注記にのみ」とか「HTMLページに自由文で記載」なんてケースが多いんですよね(要するに機械は読めない)。
問題点を技術的にまとめると:
- ライセンス表記が自然文でばらつく → 正規化できない
- カタログとデータセットで不一致がある → 自動収集器が信頼できない
- ライセンスの粒度が低い(カタログ単位のみ) → ファイル単位で異なるケースに対応できない
なぜ機械可読が重要か(エンジニア的視点)
- 自動パイプラインが利用可否を判定できる(商用利用可/不可の振り分け)
- データマッシュアップ時に互換性検査が可能(CC BYとCC BY-NCの違いを機械的に把握)
- カタログ横断で権利情報を集めて分析できる(ガバメントデータのエコシステム化)
具体的対策(コード例つき)
1) メタデータフォーマットを決める
- DCAT (dcat:license), schema.org (dataset.license) を推奨
- 追加で SPDX識別子を付与してライセンス互換性判定を容易にする
例: datasetのJSON-LD(最小)
{
"@context": "https://schema.org/",
"@type": "Dataset",
"name": "河川水位データ",
"url": "https://example-lg.jp/datasets/river-level",
"license": "https://creativecommons.org/licenses/by/4.0/",
"spdxIdentifier": "CC-BY-4.0"
}
2) API側でライセンスの正規化とチェックを実装する
- 取得したlicenseフィールドを正規化して既知のURI/SPDXにマップする
- 互換性ルール(商用可否、派生物可否)をルックアップしてフラグを返す
簡単なPython例(疑似コード):
import requests
KNOWN = {"https://creativecommons.org/licenses/by/4.0/":"CC-BY-4.0"}
r = requests.get('https://example-lg.jp/datasets/river-level.json')
meta = r.json()
spdx = KNOWN.get(meta.get('license'))
if not spdx:
raise ValueError('Unknown license, manual review needed')
print('SPDX:', spdx)
3) CIに組み込む(GitHub Actionsなど)
- メタデータ差分を検知 → ライセンス未定義や変更を検査 → デプロイ停止
- 既存カタログを定期クロールしてライセンス統計を出す
4) カタログ/ポータルのUI改善
- データ詳細ページに機械可読ライセンスのリンクと一目でわかる利用可否バッジを表示
期待される効果
- データ流通がスムーズになり、民間事業者の利活用が加速する(Digital Agencyの事例のように)
- 行政内部でもデータ再利用の判断コストが下がる(調達や二次利用申請が減る)
実装上の注意点
- 既存PDFに書かれた権利表記は人間向けの説明として残すべきで、置き換えではない
- ライセンス変更の履歴管理を行い、変更が互換性破壊を伴う場合はユーザー通知を必須にする
まとめ
ライセンスは面倒に見えて、実はデータ流通のガードレール。JSON-LD/DCAT/SPDXで機械可読にして、APIとCIで検査・運用するだけで利活用が格段に向上します。PDFだけに頼るのはもったいない!
おかむーから一言
テクノロジーで社会を変えるには、小さな運用改善の積み重ねが効くんですよ。ライセンスを“読む”仕組みを作って、データが自由に動く社会を一緒に作りましょう!
情報ソース
- https://ja.wikipedia.org/wiki/%E5%85%AC%E5%85%B1
- https://www.intec.co.jp/column/smartcity-08.html
- https://kotobank.jp/word/%E5%85%AC%E5%85%B1-494676
- https://www.digital.go.jp/resources/data_case_study_private
- https://www.takeda.tv/saga/blog/post-230907/
- https://www.e-gov.go.jp/digital-government/api
- https://www.soumu.go.jp/menu_seisaku/ictseisaku/ictriyou/opendata/opendata03.html
- https://japan-opendata.github.io/awesome-japan-opendata/
- https://www.jichi.ac.jp/
- https://api-catalog.e-gov.go.jp/info/ja/apicatalog/list
- https://www.keiba.go.jp/
- https://www.digital.go.jp/policies/local_governments
- https://www.keiba.go.jp/KeibaWeb/TodayRaceInfo/TodayRaceInfoTop
- https://www.soumu.go.jp/menu_seisaku/chiho/jichitaijoho_system/index.html
- https://www.keiba.go.jp/live/
シェアする
関連レポート

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

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

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