政策KPIは“定義が読める”と信頼できる：数式をデータで公開する提案

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

• 3行要約

- 政策のKPI（指標）が「どうやって」算出されているかを機械可読で公開してないケースが多い

- 要するに、数式や入力データの参照がないと政策の再現性・検証ができないということです

- 解決は技術的：KPI定義をJSON-LDやCEL等で公開し、データセットURIとテストベクタを添えるだけで劇的に改善します！

結論

政府・自治体は「KPIの算出式＝データと処理のレシピ」を機械可読で公開すべきです。単なる報告値だけだと市民／研究者が検証できないし、政策の説明責任が果たせません。実装は難しくなく、JSON-LD+式言語（例：CEL）+データセットURI（e-Stat等）＋CIで十分に運用可能です。

レポート本文

問題の所在：数式が“見えない”と何が起きるか

これ見てくださいよ。多くの政府資料や報告書って、数値は載ってるけど「どう計算したか」が曖昧なんですよね。総務省やデジタル庁の機械可読性ガイドライン（例：PDFからCSVへの推奨や統一ルール）では表フォーマットに関する指針が出てます（参照: digital.go.jp, soumu.go.jp）が、KPIそのものの計算式を機械で読み取れる形で公開するルールはまだ広がっていません。

結果として起きる問題：

• 再現性がない → 第三者検証不可
• データソースが変わったときに過去値との比較が意味を失う
• 市民や企業が二次利用しづらい → エコシステムが育たない

要するに「数字はあるけど黒箱」ってことです。

技術的な提案：KPI定義のデータ化仕様

エンジニア的に言うと、これはAPIドキュメントと同じ考え方で解決できます。必要な要素は次の通り。

• id: 指標固有ID（URI）
• name, description: 説明（自然言語）
• formula_language: 使用する式言語（例：CEL, SQL, JMESPath）
• formula: 実行可能な式（例：CEL表記）
• inputs: 入力データのURI（e-Statテーブル、自治体CSV、ガバメントクラウドのAPIエンドポイントなど）
• frequency: 更新頻度（daily/weekly/monthly）
• version, last_updated, change_log: バージョン管理情報
• test_vectors: 入力→期待出力の例（単体テスト用）
• provenance: 出典（省庁名、法的根拠、報告書PDFへのリンク）

これをJSON-LDで公開すれば、検索や発見性も上がるし、Data Catalog（gov catalogs）にも取り込みやすくなります。

具体例（サンプルJSONとSQL/CEL）

コード書く人ならわかると思うんですけど、こういう形で書くと機械的に処理できます。

{
"@context": "https://schema.org/",
"@type": "Dataset",
"id": "https://example.go.jp/kpi/population_density/v1",
"name": "人口密度（市区町村）",
"formula_language": "CEL",
"formula": "inputs.population_total / inputs.area_km2",
"inputs": {
"population_total": "https://www.e-stat.go.jp/api/1.0/data?table=XXXX",
"area_km2": "https://www.soumu.go.jp/....csv"
},
"test_vectors": [
{"inputs": {"population_total": 100000, "area_km2": 50}, "expected": 2000}
],
"frequency": "annual",
"version": "1.0",
"provenance": "e-Stat table XXXX, 総務省公表資料 YYYY"
}

SQLで計算するならこんな感じ（参考）：

SELECT p.municipality_code,
p.population_total / a.area_km2 AS population_density
FROM e_stat_population p
JOIN municipal_area a USING (municipality_code);

要するに、式と入力がセットで公開されていれば、誰でも再現できるし、CIで定期的な再計算と差分検出が組めます。

運用面：テスト・監査・バージョン管理

• CIパイプラインで毎回テストベクタをチェック
• データソース変更時に自動アラート（スキーマ変化検出）
• バージョン間の互換性を保証するためのメタデータ（deprecatedフラグ等）
• 変更ログを機械可読で公開（リリースノートの機械化）

これで政策発表と実際の算出が乖離してたら自動で検出できます。透明性が格段に上がるんですよ！

プライバシーと実務的配慮

個人情報に関わる指標は入力データを直接公開できない場合が多いです。要するに、集計済みの値＋メタデータ＋差分検出でプライバシー保護と再現性を両立できます。必要なら差分プライバシー（DP）やサンプルベースの検証データを併用するのがおすすめ。

実装のロードマップ（現実的ステップ）

まずは省庁の主要KPIトップ10でPoCを作る（JSON-LD公開＋CI）

CSV/PDFに埋もれてる表は機械可読化（総務省・デジタル庁のガイドライン参照）

e-Stat等の公式URIを入力として明記

市民・研究者向けの再現ボタン付きポータルを用意

まとめ

• KPIは単なる数値じゃなく「データと処理のレシピ」だよね
• 数式を機械可読で公開すると再現性・説明責任・利活用が全部よくなる
• 実装はJSON-LD＋式言語＋CIで現場運用に落とせる。まずは主要KPIからPoCやってみよう！

おかむーから一言

テクノロジーで行政をアップデートするのって、魔法じゃなくて工程管理をちゃんとやる話なんです。まずは一つのKPIの式を公開してみてください。動かしてみると世界が変わりますよ！

参照:

• デジタル庁「行政データにおける機械可読性に関するルール(案)」 (digital.go.jp)
• 総務省「統計表における機械判読可能なデータの表記方法の統一ルールの策定」 (soumu.go.jp)
• e-Stat（総務省統計局のオープンデータポータル）