コードで語るマニフェスト:政府データはこう直せばいいよ!

IT政策提案
コードで語るマニフェスト:政府データはこう直せばいいよ!

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

  • 政府/自治体データ、CSVは出てるけどフォーマットばらばらで使いにくい!
  • PDFに閉じてる資料を機械可読にするだけで政策評価の幅がぐっと広がる!
  • エンジニア視点でAPI設計・データ品質CI・メタデータを整備する具体案を示すよ

結論

政府・自治体が公開しているデータは「存在するけど使いにくい」ケースが多い。要するに、データを出すだけで満足してるんですよね。エンジニア的に言うと、API一本・標準スキーマ・機械可読メタデータ(DCAT)を整備すれば、政策の検証可能性が劇的に上がる。改善は難しくない、具体的な実装パターンを採用すればOK!

レポート本文

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

検索で見つかる政府系リソースを見ると、CSVファイルを直接置いている例(例:https://notice.go.jp/docs/status_nicter.csv, https://www.jinji.go.jp/content/900024615.csv, https://www.env.go.jp/content/900398071.csv)や、PDF主体の公開、あるいは時々APIが存在するケースが混在している。

  • 長所:CSVでダンプを用意してくれるとすぐ使えて嬉しい!
  • 短所:スキーマが統一されてない、更新頻度やライセンスが明示されていない、エンドポイントやAPI仕様がない

中国ドメイン事情(参考:.gov vs .gov.cn の議論)や、beian.miit.gov.cn が落ちやすい話もある(アクセス性の問題)。要するにドメイン/運用の可用性も無視できないポイントです。

技術的問題点を掘る

  • フォーマットの不一致
  • - 列名が自治体ごとに違う(例:"date" vs "日付" vs "発表日")

    - 日付形式が混在(YYYY-MM-DD / YYYY/MM/DD / Excelシリアル)

    - エンコーディングのばらつき(UTF-8/Shift_JIS)

    要するに、前処理にコストがかかりすぎるということです。

  • 機械可読性の不足(PDF多用)
  • - PDFに政策目標や実績を埋め込みがち。コード書く人ならわかると思うんですけど、PDFはスクレイピングの手間がヤバいです。

  • API不在・API品質の欠如
  • - RESTful設計やOpenAPI仕様がないと、民間アプリや研究者が安全に利用できない

  • メタデータ不足
  • - 更新日、ライセンス、カラム説明、欠損ルールなどが明示されていない

    データと政策のギャップ分析(例示)

    政策には数値目標があるのに、実績データが分断されていて追跡できないケースがある。たとえば、ある自治体の「待機児童ゼロ」目標が発表されても、保育所別の入所数やキャンセル数が機械可読で出ていないと、実績の検証が難しい。

    要するに、目標(policy target)とオープンデータ(observations)の間にAPI・ID・タイムスタンプという“契約”を入れないと、数値の信頼性検証ができないんですよね。

    技術的提案(具体的実装パターン)

    1) 公開APIゲートウェイを立てる

    - 各省庁・自治体はデータAPIを提供し、中央でAPIカタログを整備する(GovTech東京のような共同ダッシュボードの考え方に近い)

    - OpenAPIで仕様を公開、CORS対応、レート制限で運用

    2) 標準スキーマを定義する(例:measurements, entities, timeseries)

    - JSON Schema / CSV Schemaを用意し、必須フィールドを決める

    - DCAT/Schema.orgでデータセットメタを付与

    3) データ品質CIパイプライン

    - GitOpsでデータ更新を管理。PRに対して自動検証(スキーマ検証、重複チェック、日付整合チェック)を走らせる

    - 失敗したらエラー通知と担当者アラート

    4) PDF -> 機械可読のワークフロー

    - 原則としてCSV/JSONでの公開を求めるが、遺留PDFはOCR+Tabular抽出(例えばCamelot/Tabula)で構造化し、差分検出して報告する

    5) サンプルOpenAPI(最小構成)

    openapi: 3.0.0
    

    info:

    title: Municipal Measurements API

    version: 1.0.0

    paths:

    /v1/measurements:

    get:

    summary: 時系列データ取得

    parameters:

    - in: query

    name: entity_id

    required: false

    schema:

    type: string

    - in: query

    name: from

    schema:

    type: string

    format: date

    responses:

    '200':

    description: OK

    6) 簡単なデータ取得コード例(Python + pandas)

    import pandas as pd
    

    url = 'https://notice.go.jp/docs/status_nicter.csv'

    df = pd.read_csv(url, encoding='utf-8')

    スキーマ正規化

    rename_map = {'日付':'date','件数':'count'}

    df = df.rename(columns=rename_map)

    df['date'] = pd.to_datetime(df['date'])

    print(df.head())

    導入時の運用注意点

    • 権限とガバナンス:公開APIに個人情報が混ざらないよう匿名化ルールを明確化
    • 予算と人材:省庁ごとにデータエンジニア1名はほしい(当面は共通プラットフォームで補完)
    • 横断KPI:データ公開率、スキーマ適合率、API稼働率をKPIにする

    まとめ

    • 政府データはすでに宝の山だけど、フォーマットと運用が足を引っ張ってる
    • API化・スキーマ標準化・メタデータ整備・CIによる品質確保を順にやれば活用は劇的に増える
    • 技術的な負債を返す作業は地味だけど、政策の説明責任と市民参画を高める鍵になる

    おかむーから一言

    私は2度起業してフルスタックでプロダクト作ってきた人間です。テクノロジーで行政をアップデートするのは手が届く目標だと思ってますよ。今こそデータとコードでマニフェストを語ろう!