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

• 3行要約

- 自治体オープンデータで本当に重要なのは「機械が発見して取り出せること」。PDFが多いと使われない！

- エンジニア観点で測る「フリクション・メトリクス」を提案。探索性・メタデータ品質・API完成度を定量化する

- 政策目標（推進や標準化）はあるが、現場のメタデータ品質で実績と乖離する。コードで差を可視化しよう

結論

自治体オープンデータは単に公開すればOKじゃないです。エンジニア的に言うと“発見性（discoverability）と契約（contract）”が命。APIやCSVにしても、メタデータやCORS・サンプルがないと実務で使えないんですよね。だから「フリクション・メトリクス」で現状を数値化して、運用改善につなげるべきです。

レポート本文

背景（政策リファレンス）

総務省やデジタル庁はオープンデータ推進と自治体システム標準化を掲げています（参照: https://www.soumu.go.jp/menu_seisaku/ictseisaku/ictriyou/opendata/ 、https://www.digital.go.jp/resources/data_case_study_private）。要するに国は「開けよ」と言ってるんですけど、現場はフォーマットやメタデータ運用で手こずってるんですよね。

問題の現場感（これ見てくださいよ）

• データがPDFで置かれている（機械可読性ゼロ）
• メタデータ（更新日・ライセンス・スキーマ）が欠けている
• APIがあってもページネーションやCORS、認証ルールがバラバラ

エンジニア的に言うと、API一本で済む話でも、メタデータがなければ組み合わせや自動化が死にます。

フリクション・メトリクス（提案）

各自治体のデータカタログに対して自動で算出する指標群を作るといいです。具体的には：

• Discovery Score（発見スコア）: カタログの機械可読性（catalog.jsonの有無、sitemap、robotsの存在）
• Format Score（形式スコア）: CSV/JSON比率（PDFの割合が高いほど減点）
• Metadata Score（メタデータスコア）: ライセンス、更新日、スキーマの記載率
• API Readiness（API準備度）: エンドポイントの有無、CORS許可、サンプル、ページネーション
• Freshness（鮮度）: 最終更新日の中央値／平均

それぞれ0〜100点で算出して合算すると、総合フリクション値が出ます。

実際にチェックするサンプルコード

小さいコード例で、カタログにあるファイルの拡張子を数えるだけのPythonスニペット：

import requests
from urllib.parse import urlparse

def count_formats(catalog_url):
r = requests.get(catalog_url, timeout=10)
catalog = r.json()  # ここはCKANやDCATに合わせてパース
counts = {}
for ds in catalog.get('results', []):
for res in ds.get('resources', []):
url = res.get('url','')
ext = urlparse(url).path.split('.')[-1].lower()
counts[ext] = counts.get(ext,0)+1
return counts

例: count_formats('https://{your-catalog}/api/3/action/package_search')

curlでCORSを確認する簡単な例：

curl -I https://example.gov/data.csv | grep -i access-control-allow-origin

要するに、こういう自動チェックをCI的に回せば「公開したけど使われない」悲劇は減るんです。

政策の数値目標と実績のギャップ（評価フレーム）

総務省/デジタル庁の目標は「自治体のオープンデータ推進・標準化」で、成果指標としては“公開件数”や“カタログ導入率”がよく出てきます（参考: 上記govサイト）。要するに目標は量ベースになりがちなんですよね。

ここで重要なのは「質」—公開件数が多くてもPDFだらけなら実務での価値は限定的。だからギャップを数値化するには、以下のようなKPIが必要です：

• 公開件数（政策目標） vs 機械可読件数（実績）
• カタログ導入率（政策目標） vs カタログ内のメタデータ完全率（実績）

例えば「公開100件」を目指した自治体で、CSV/JSONが30件しかないとすれば機械可読率は30%で、政策目標とのギャップは明確になります（この種の比較はe-Statや各自治体のカタログAPIから自動抽出可能）。

改善提案（技術レイヤーでできること）

• カタログはDCAT-APやCKAN形式で公開し、catalog.jsonをルートに置く
• 公開ルールに"最低限のメタデータテンプレ"（ライセンス、更新日、フィールドスキーマ）を義務化
• PDFは二次配布用とし、データはCSV/JSONで別途公開
• CIパイプラインでフリクション・メトリクスを毎週計算してダッシュボード化
• サンプルコードやOpenAPI/Swaggerを添付して開発者のオンランプを作る

まとめ

オープンデータは出すだけじゃ意味がない！エンジニア目線で「発見できる」「契約が明確」「使いやすい」を数値化するフリクション・メトリクスが現場を動かすカギです。総務省やデジタル庁の方針（https://www.soumu.go.jp/、https://www.digital.go.jp/）は良い出発点だけど、現場運用でのメタデータ品質が追いついていないのが実情。コードで測って、そこから改善を回すのが近道ですよ！

おかむーから一言

テクノロジーで社会をアップデートするって言うけど、まずはデータを『見つけられる』ようにしよう！小さなCIパイプライン一つで世界が変わりますよ〜