コードで語るマニフェスト:自治体データの現場観察と技術的処方箋

IT政策提案
コードで語るマニフェスト:自治体データの現場観察と技術的処方箋

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

  • 3行要約
- 日本の政府/自治体は可視化やダッシュボード整備を進めているが、多くがPDFや表形式のままで機械可読性に課題がある

- 標準化・クラウド移行の政策は進行中だが、API公開率やCSV化率など定量指標での達成が見える化されていない

- エンジニア視点で言うと、OpenAPI・JSON Schema・CIによるデータ品質ゲートで即効性のある改善が可能

結論

自治体データを“政策チェック可能なコード”にするには、単なるダッシュボードやPDF公開では不十分。要するに「機械可読」「API第一」「スキーマの標準化」を政策設計段階から組み込むことです。エンジニア的に言うと、API一本で説明責任と再利用が劇的に改善します。

レポート本文

現状観察:公開プラットフォームとフォーマット

これ見てくださいよ。国の統計やダッシュボード周りは進化しています。e-Statの統計ダッシュボードやDigital庁のJapan Dashboard、GovTech東京の事例紹介は公式チャネルとして重要な前進です(参照: dashboard.e-stat.go.jp / digital.go.jp / govtechtokyo.or.jp)。

ただし現場はばらつきが大きい。

  • 公開フォーマット: PDFが依然として多い。PDFは人間向けには良いが、エンジニアやデータサイエンティストにとっては扱いづらい。要するに"データが埋め込まれたサンドバッグ"です。
  • APIの有無: e-StatはAPIを提供しているが、地方自治体レベルではAPI未整備、CSVの断片公開、あるいはHTMLテーブルだけのケースが多い。
  • ドメイン・アクセス問題: 中国の事例(知乎の指摘)では特定の司法公開サイトが一部ブラウザで開かない報告が出ている。ドメイン構成やCSP、ユーザーエージェント依存の問題など技術要因が絡む例として参照できます(参照: zxgk.court.gov.cn の議論)。

技術的な問題点の掘り下げ

  • 機械可読性の欠如
  • - PDFやスキャン資料が多く、テーブル抽出しても誤差や欠測が頻発。

    - 要するに、データの二次利用を妨げているということです。

  • メタデータ・スキーマ不在
  • - 異なる自治体で同じ指標名が違う単位・定義で公開されている。統合が面倒。

  • API設計とガバナンス不足
  • - 認証・利用権限・リリースルールが不明確で、安定的な機械読み取りを阻害。

  • モニタリング指標が曖昧
  • - 政策目標(例:基幹系のクラウド移行、標準化)に対して、進捗を測る定量指標が見えない。

    コードで語る—具体的な技術提案

    ここからはエンジニア的な改善案を並べます。実装例やコード例も入れるので、コード書く人ならわかると思うんですけど〜。

    1) APIファースト & OpenAPI

    - 全ての自治体主要データはまずOpenAPI仕様(OpenAPI 3.0)で設計。APIのメジャーバージョンと互換性ルールを明示。

    - メリット: 自動生成ドキュメント、型安全なクライアント生成、CIでの契約テストが可能。

    2) スキーマ管理(JSON Schema / JSON-LD)

    - 指標ごとにJSON Schemaを用意。単位、定義、更新頻度、欠測ポリシーをメタデータに含める。

    3) データ品質ゲート(CI)

    - PR時にスキーマ検証・統計的異常検出・欠損閾値チェックを自動実行。データ変更はコードレビューを経る。

    4) レガシーPDF対策:ETLパイプライン

    - Tabula/ Camelot / pdfplumber を用いた自動抽出 + 人手ラベルのルール学習で精度向上。

    - サンプルPython (概念例):

    # pseudo-code: fetch e-Stat via API
    

    import requests

    API = 'https://api.e-stat.go.jp/rest/3.0/app/json/getSimpleStatsData'

    params = {'appId': 'YOUR_APP_ID', 'statsDataId': '0000020201'}

    r = requests.get(API, params=params)

    data = r.json()

    理想はここでJSON Schema検証

    PDF抽出のヒント:

    # pdfplumberでテーブルを抽出
    

    import pdfplumber

    with pdfplumber.open('report.pdf') as pdf:

    table = pdf.pages[2].extract_table()

    # ここで正規化・スキーマに合わせる

    5) オープンデータ・ポータルの共通基盤

    - Digital庁・総務省の取り組み(自治体情報システムの標準化・共通化)を活かし、共通APIゲートウェイを構築。認証はOAuth2で統一。

    政策目標と実績のギャップ分析(例)

    • 目標: 2025〜2026年にかけて地方基幹系の標準化・ガバメントクラウド移行を推進(digital.go.jp の方針参照)。
    • 実績の確認ポイント(提案するKPI):
    - 移行率: 主要自治体の基幹系システムでクラウド運用が何%か

    - API公開率: 主要業務データのうちAPIで公開されている割合

    - 機械可読率: 公開データのうちCSV/JSONで提供される割合

    - 品質: CI通過率、スキーマ違反率

    要するに、政策目標は立派でもメトリクスがなければ進捗の検証ができないんですよね。だから数値で追えるダッシュボードが必須です。

    オープンデータ利活用の提案

    • 市場創出: APIを標準化すればスタートアップが行政データを使ったサービスを創りやすくなる
    • 市民参加: データポータルにフィードバック機能(データ修正申請)を入れる
    • 透明性: 予算・執行の数値は必ず機械可読で公開し、政策目標と実績を照合可能にする

    まとめ

    • PDFは人間用、API/CSV/JSONは機械用。両者の役割を切り分けて公開フローを設計すること
    • OpenAPI + JSON Schema + CIでデータ品質を担保すれば、政策の説明責任と再利用が同時に強化される
    • 政策は数値で追うこと。移行率やAPI公開率などKPIを定め、公開ダッシュボードで市民に示そう

    おかむーから一言

    オープンデータって結局、"誰でも使えるコード"に変換する話なんです。テクノロジーで行政をアップデートして、役所もスタートアップも市民もハッピーにしようぜ!