どうも〜おかむーです！ Today we're doing a short, slightly nerdy audit of how Japanese government and local bodies publish data — using Nagano, Digital Agency initiatives, and a few public CSVs/PDFs as our test cases.

• Governments often publish numbers, but many are locked in PDF tables or inconsistent CSVs — not great for reuse.
• There's clear momentum (Digital Agency, local DX funds), but APIs, schemas, and machine-readable SLAs are still patchy.
• Practical fixes: require CSV/JSON-first, publish OpenAPI/GeoJSON endpoints, and add CI for data quality — easy wins engineers can push for.

結論

Public-sector data in Japan is getting better (see digital.go.jp and some gov CSVs), but operational maturity is uneven. エンジニア的に言うと、データの発見性・一貫性・機械可読性が不足している部分が多く、政策評価や市民サービス改善のスピードを落としている。要するに、データをAPIと標準スキーマで出すだけで、再現性ある政策検証がぐっと楽になるということです。

レポート本文

現状観察 — これ見てくださいよ

• National/central CSV examples exist (e.g. https://www5.cao.go.jp/j-j/wp/wp-je24/csv/d1-1-4.csv) — good, machine-readable! でも、似たテーマの報告書はPDFも多くて、表は画像やレイアウトに埋められている。
• Digital Agency (https://www.digital.go.jp/) が旗振りしている一方、地方サイト（例: https://www.pref.nagano.lg.jp/）はPRや告知が中心で、オープンデータのカタログが不十分な自治体も多い。
• ローカル事例: Sukagawa city の評価ページ（デジタル田園都市構想の実績評価）には外部有識者による検証があるが、検証用の生データやAPIリンクが目立たない（https://www.city.sukagawa.fukushima.jp/...）。

技術評価ポイント

• Format: CSVs do exist (see gov CSV links and digital assets like xxxxxx_hospital.csv), butフォーマットの統一がない。カラム名称、日時のISO化、自治体コード統一（JIS X 0401/0402）などが欠如しがち。
• Discoverability: no DCAT catalog or machine-readable index in many LG sites.
• API: 公的APIは一部あるが、OpenAPI specやバージョニング、CORS設定といった実運用の配慮が弱い。
• Quality: PDF内にしかない指標があるため、KPI達成状況の自動集計が困難（参考: 総務省のCheck/Action指針文書でKPI評価を要求しているが、データ提供が足りないケースあり）。

簡単なコード例 — CSVをGeoJSONに変換する（Python）

import pandas as pd
import geopandas as gpd
from shapely.geometry import Point

df = pd.read_csv('https://www.digital.go.jp/assets/.../xxxxxx_hospital.csv')
assume lat/lon columns named 緯度, 経度
df = df.dropna(subset=['緯度','経度'])
df['geometry'] = df.apply(lambda r: Point(r['経度'], r['緯度']), axis=1)
gdf = gpd.GeoDataFrame(df, geometry='geometry', crs='EPSG:4326')
gdf.to_file('hospitals.geojson', driver='GeoJSON')

要するに、CSVさえきちんと公開されていれば、こういう変換は数行で済むんですよね。

改善提案（技術的・運用的）

• Policy: すべてのKPI報告は機械可読フォーマット（CSV/JSON）で併記。PDFは解説用に限定。
• API-first: OpenAPI spec を自治体ごとに公開、APIゲートウェイ経由で認証・レート制御・バージョニングを実装。
• Schema & vocab: JIS自治体コード、ISO8601 日時、Schema.org / DCAT metadata を必須に。
• Data CI: GitHub/GitLab でデータリポジトリを管理し、データ質チェック（null検出、型チェック、数値レンジ検証）の自動テストを走らせる。
• UX: デジタル窓口のUI改善（記事参照: UX pieces）を同時並行で。使う人の言葉でAPIレスポンス例やサンプルクエリを公開する。

KPIギャップの見方

• 交付金等の達成状況は「計画値 vs 実績値」を機械的に突き合わせられるかがカギ。CSVに計画/実績を揃え、versioned time series を出せば、外部の再現可能な検証が可能になる。

まとめ

現場の熱意（Digital Agency、地方の評価）はある。ただ、エンジニア目線で見ると「データをどう出すか」が政策検証のボトルネックになっている。PDF頼みをやめて、CSV/JSON・OpenAPI・データCIのセットを標準にするだけで、政策の透明性と市民利用価値は劇的に上がる。正直、ここは改善の余地ありまくりだと思ってます！

おかむーから一言

テクノロジーで社会をアップデートするんだって言うなら、まずデータをちゃんと開けようよ。ノーギアス株式会社とno planでやってきたことを活かして、行政データの作法をアップデートしようぜ！