コードで語るマニフェスト：日本の行政データをエンジニア目線で検証する

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

• 行政データはPDFで頑なに出てくることが多いが、API化・機械可読化が急務
• e-Govや都道府県のオープンデータポータルはあるけど整備のムラとメタデータ欠落が目立つ
• 技術的にはAPI設計・CI・スキーマ管理でかなり改善できる。具体策も示すよ！

結論

日本の行政はデジタル基盤を整備してきたけど、データの機械可読性とAPI品質はまだ「積み上げフェーズ」だと思うんです。要するに、政策目標（KPI）と実績をコードで検証できるようにしないと、チェック&アクションが回らないんですよね。内閣官房やデジタル庁の最新の取り組み（機械可読性ルール等）に沿って、オープンなAPI設計・データパッケージ化・自動品質チェックを導入するのが現実的な改善案です。

レポート本文

1) 現状のランドスケープ — これ見てくださいよ

まずソースを押さえます。デジタル庁（https://www.digital.go.jp/）やe-Govの行政APIポータル（https://www.e-gov.go.jp/digital-government/api）、都のオープンデータAPI（https://portal.data.metro.tokyo.lg.jp/opendata-api/）は公開済み。けど、実務レポートや交付金の実績報告はPDFで配られることが多い（例：山口県の交付金実績PDF）。PDF→CSV変換の工数がかかってしまい、データ利活用のスタートラインに立てていない状況が散見されます。

参考：デジタル田園都市国家構想のKPI評価ガイドラインや実績PDF（国/県レベル）によると、KPI設定はあるが機械可読提出の義務化が弱く、年度ごとの追跡に透明性の欠如があるんですよね（参照: 内閣官房の機械可読性ルール草案や交付金評価PDF）。

2) 技術的な問題点を整理する

• フォーマットの多様性：PDF, Excel（非構造）, HTMLテーブル, 一部JSON／CSV
• メタデータ欠落：カラム説明、更新日、ライセンスが明示されていないケースあり
• API品質：認証・レート制限・レスポンススキーマが統一されていない
• 運用の欠如：CIでのスキーマ検証やデータ整合性チェックがない

要するに、データの信頼性を自動検証できないのでエビデンスに基づく政策評価が難しい、ということです。

3) 実際に触るときのエンジニア的手法

エンジニア的に言うと、まずは"API一本化"と"スキーマのコード化"が鍵。以下は実務で使えるパターンです。コード書く人ならわかると思うんですけど、サンプルを置いておきます。

• e-Gov API（カタログ）を叩いて利用可能API一覧を取得する例（curl）:

curl -s 'https://api-catalog.e-gov.go.jp/info/ja/apicatalog/list' | jq '.items[] | {title: .title, url: .apiUrl}'

• Pythonで都の公共施設APIを叩いてCSV化する簡単な例（requests + pandas）:

import requests
import pandas as pd

r = requests.get('https://portal.data.metro.tokyo.lg.jp/api/3/action/datastore_search?resource_id=PublicFacility')
data = r.json()['result']['records']
df = pd.DataFrame(data)
df.to_csv('public_facilities.csv', index=False)

• PDFレポートを構造化するにはtabula-pyかcamelotでテーブル抽出→スキーマ化

import camelot
tables = camelot.read_pdf('report.pdf', pages='1-end')
for i,t in enumerate(tables):
t.df.to_csv(f'table_{i}.csv', index=False)

注意点：PDF抽出はエラー率が高いので、抽出後にスキーマ検証（pydantic/jsonschema）で品質ゲートを設けるべきです。

4) KPIと実績のギャップをどう検証するか

政策（例：デジタル田園都市交付金）にはKPIがあるけど、実績はPDFやレポートに散在している。これをコードで追跡するには：

• KPIメトリクスをスキーマ化（例：kpi.yamlに目標値と単位を定義）
• 実績データを定期的にAPI/データパッケージで集めるCronジョブ
• 差分を自動算出してダッシュボード（Grafana/Metabase）に流す

簡単なメトリクス例：

• API化されたデータセット数（目標：全重要ドキュメントの90%）
• 機械可読データの更新頻度
• データ欠損率（必須フィールドの欠損%）

5) 改善提案（技術ロードマップ）

機械可読性ルールの徹底運用

- 内閣官房のガイドライン（2026/03/31資料）を基準に、CSV/JSON/OpenAPIを必須化

APIカタログ整備 + OpenAPI公開

- すべての行政APIはOpenAPI仕様書を持ち、APIカタログで検索可能に

データパッケージとCI

- データをGitリポジトリ(またはCKAN)で管理、プルリクで差分レビュー、CIでスキーマ検証

PDFを一次データとして終わらせない

- 入稿時点で構造化フォーマットを要求。レガシーPDFは抽出パイプラインで定期変換

ダッシュボードとモニタ

- KPIの自動集計とアラート（閾値超えたら担当に通知）

技術スタック例：AWS S3 + Lambda（取り込み）→ Glue/EMR（整形）→ PostgreSQL/BigQuery（保存）→ Metabase/Grafana（可視化）。Data CatalogにはCKANやDataHubを推奨。

6) オープンデータの活用可能性

• 民間のスタートアップや市民団体が参照しやすい形にすれば、新サービスが生まれる余地が大きい
• API一本で住民向けアプリ、統計ダッシュボード、予算の可視化ツールが作れる

要するに、技術的にはできることがいっぱいあるんですよ！

まとめ

• 現状：ポータルとAPIはあるが、PDF文化やメタデータ不足で利活用に壁がある
• 解決策：機械可読性ルールの徹底、OpenAPI化、CIによるスキーマ検証、ダッシュボードでのKPI監視
• 期待効果：政策の透明性向上、自治体間の比較可能性、民間イノベーションの促進

おかむーから一言

テクノロジーで社会をアップデートするって、口だけじゃダメなんですよ。コードで検証できる仕組みを作れば、政策はもっと速く、正確に改善できるはず！