用代码检验政务数据:PDF、API与可机读性的现实差距

IT政策提案
用代码检验政务数据:PDF、API与可机读性的现实差距

どうも〜おかむーです!大家好,我是おかむー!今天用“代码で語るマニフェスト”的思路,带大家从工程师视角看一看政府/自治体的数据发布现状,顺带给出可执行的改进建议~

  • 行政数据里常看到的是PDF而不是CSV/JSON,机器可读性差
  • 要点:API与结构化数据能把政策目标变成可验证的KPI追踪系统
  • 改进路径:标准化格式、开放API、数据目录与简单的ETL示例

結論

政府和地方自治体在“把政策数值化并自动追踪”这件事上已经有文件和KPI,但多数报告以PDF/Word形式发布,缺乏API和结构化数据支持。要从“纸上目标”变成“数据驱动治理”,技术上可通过发布CSV/JSON、开放API并提供示例代码来立刻改善,成本并不高。

レポート本文

現状观测(数据来源)

これ見てくださいよ:内閣官房の資料やデジタル庁の指針(参照: cas.go.jp や digital.go.jp の資料)では「機械可読性が重要」「AI-Ready社会に備える」と明記されてます(例:機械可読性ルール案PDF)。ただ実務では、実績報告やKPIの多くがPDFや箇所化されたExcelで公開されていて、APIは整備途上という印象です。

問題点を技術的に整理すると:

  • フォーマット問題:PDF/Word中心 → スクレイピングやOCRが必要
  • メタデータ不足:スキーマやバージョン、更新日時が明記されない
  • API欠如:データ取得が人手前提、定期的な自動集計が不能
  • ライセンス曖昧:再利用条件が不明瞭で二次利用に障壁

要するに(要点就是)——データが“人間向けの文書”で止まっているため、エンジニアや研究者が迅速に再利用・検証できないということです。

技術検証(工程师角度)

エンジニア的に言うと、これはAPI一本で解決する話なんですよね。技術的に取れる選択肢は:

  • まずはCSV/JSONでのデータ公開
  • スキーマ(JSON Schema / CSV schema)を提供
  • OpenAPIでAPI仕様を定義
  • データカタログ(CKAN等)でメタ情報を整理
  • コード例(示例、実行はしていません)——PDFに埋まったKPI表をCSV化して差分を出す流れのサンプル:

    # 要するに:pandasで読み込めれば分析はラク
    

    import pandas as pd

    もしPDFなら tabula-py で表を抽出

    df = tabula.read_pdf('report.pdf', pages='all')

    假设我们已经有target.csvとactual.csv

    target = pd.read_csv('kpi_target.csv', index_col='項目')

    actual = pd.read_csv('kpi_actual.csv', index_col='項目')

    report = pd.concat([target, actual], axis=1)

    report['gap'] = report['actual'] - report['target']

    print(report.sort_values('gap', ascending=True))

    また、APIがあればこういう単純なcurlで最新データを拾ってきてダッシュボードへパイプできます:

    curl -s "https://example.gov/api/v1/kpi?year=2025" | jq

    KPIと実績のギャップ分析例

    デジタル田園都市国家構想の交付金資料でもKPI設定は見られる(参照: 都道府県の実績報告PDF)。だが、年度ごとのKPI実績がPDFに分散していると、跨年度で自動比較するのが難しい。具体的には:

    • 目標:X%のKPI達成
    • 実績:PDF内の表で報告(数値のサニティチェックが手作業)

    技術的にやるべきは「KPIを時系列で追えるAPI」を公開すること。年度別・事業別のキーでフィルタ可能にすれば、自治体間や年ごとの比較がワンラインでできるようになります。

    改善提案(実装レベル)

    短期(1〜3ヶ月)

    • 既存PDFから主要テーブルをCSVで再公開。まずは人の手で正規化して公開するだけでも効果大
    • データセットごとにメタ情報(更新日、作成者、ライセンス)を明示

    中期(3〜12ヶ月)

    • REST APIを用意(OpenAPI仕様・認証はトークンベースでOK)
    • JSON Schemaを作成し、バリデーションを自動化(CIでschemaチェック)
    • CKAN等でデータカタログ化し検索性を提供

    長期(12ヶ月〜)

    • データパイプラインの自動化(ETL/ELT):PDF→構造化データの変換は最小限にし、一次データ生成側で構造化出力を義務化
    • データ品質指標(欠損率、整合性チェック)を公開し、SLAを設定

    コスト感としては、初期CSV化とAPIのプロトタイプなら小規模のエンジニアチームで数十〜百万円レベルの外注/内製で対応可能。要は優先度付けです。

    活用可能性と社会的効果

    • メディアやNPOがKPIダッシュボードを容易に作れる
    • 開発者は自治体サービスのBFF(backend-for-frontend)を共通化しやすくなる
    • AIモデルのトレーニングに使える高品質な行政データが増える

    まとめ

    • 現状:政策の数値目標はあるが、機械可読データで公開されていないケースが多い
    • 影響:検証・再現性・二次利用が阻害される
    • 解決策:CSV/JSON公開、OpenAPI、データカタログ、スキーマとバリデーションの導入

    おかむーから一言

    テクノロジーで社会をアップデートするって言うなら、まずは“データの泥を掃く”ところから始めよう!小さなAPI一本で、政策の信頼性と市民参加はぐっと増えるんですよ!