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

• 3行要約

- 総務省・デジタル庁の「自治体情報システム標準化」は進行中だが、機械可読性とAPI整備に課題あり

- PDF埋め込みや非正規CSVが多く、AI活用や自動処理には前処理コストがかかる

- 解決はAPI設計（OpenAPI）、CSVW/JSON-LD、データカタログ（DCAT）導入で比較的実装可能

結論

自治体の政策や運用は「データの形」で大きく変わる。要するに、PDFで配る運用のままではAI時代に戦えないんですよね。総務省（自治体情報システムの標準化・共通化: https://www.soumu.go.jp/...）や内閣官房のAI-Ready文書（https://www.cas.go.jp/...pdf）でも機械可読性の重要性を明示しているので、今からでもAPI・機械可読フォーマットへの投資を優先するべきです。

レポート本文

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

• 公式施策文書は揃っている（総務省、デジタル庁の方針ページ: https://www.digital.go.jp/policies/local_governments）が、個別の公開データはPDF埋め込みや人手で作った非正規CSVが多い。
• 内閣官房の資料でも「AI-Readyな行政データ」へ機械可読化の必要性が掲げられている（https://www.cas.go.jp/jp/seisaku/digital_gyozaikaikaku/data8/data8_siryou1.pdf）。
• 統計系は e-Stat / Data StaRt（https://www.stat.go.jp/dstart/）などAPIを提供する例があり、参考になる。

問題点（エンジニア的に言うと）

• データのフォーマット不統一: encoding, delimiter, headerの差でETLが壊れる
• PDF→テーブル抽出が前処理コストを生む: TabulaやCamelotでやっても手動チェック必須
• APIがない、あってもOpenAPI等の仕様が未整備で利用が難しい

技術検証：PDF vs CSV vs API

• PDF: プレゼン用には良いが機械処理には最悪。レガシーシステムが出力することが多い。

- 対処法: 書類はHTML/JSON原本を出力し、印刷用にPDFを生成するワークフローにする

• CSV: 軽量で使いやすいがスキーマが無いと破綻する

- 対処法: CSV-W (CSV on the Web) のメタデータ（JSON）を付与してスキーマとエンコーディングを明示

• API/JSON: 間違いなく最強。OpenAPIで仕様化すれば自動生成・テスト・ドキュメントが楽

コード例（簡単なデータ取得→整形の流れ）

curlでAPI叩き（想定API）:

curl -s "https://example.pref.jp/api/v1/finance?year=2024" -H "Accept: application/json" > budget2024.json

Pythonで読み込んで整形（pandas）:

import pandas as pd
import json

with open('budget2024.json') as f:
data = json.load(f)

df = pd.json_normalize(data['items'])
df.to_csv('budget2024_normalized.csv', index=False)

PDFが公開されている場合の前処理（Tabula）:

tabula -p all -f CSV https://example.pref.jp/docs/report.pdf -o report.csv

要するに、API一本で来ればこの前処理が激減するということです。

政策の数値目標と現場ギャップ

• 例: 総務省の標準化計画は「標準準拠システムへ移行」などを掲げるが、進捗報告はPMOツール経由で自治体からの申告ベース（https://www.digital.go.jp/...）。
• ギャップ分析の提案指標（例）:

- 公開データのうち機械可読率（CSV/JSON/API）: 現状30% → 1年で60%目標

- API提供自治体割合: 現状20% → 2年で70%目標

- データカタログ化率（DCAT準拠）: 現状10% → 2年で80%目標

これらは測ることで初めて改善政策が評価できる。数値目標と実績をダッシュボードで可視化するのが鉄則です。

改善提案（エンジニア目線でやること）

データカタログ導入（DCAT + CKANなど）

- メタデータを一元管理して検索・利用を促進

API設計を標準化（OpenAPI + OAuth2 or APIKey）

- サンプル: /v1/budget, /v1/service-usage

CSVにはCSVWメタデータを付ける

- スキーマ、型、制約、エンコーディングを宣言

データパイプラインの整備

- CIでスキーマチェック（jsonschema/csv-validator）→自動公開

PDFは最終成果物に限定、データの一次ソースは機械可読で保持

サンプルコードとSDKを提供（Python/JS）で市民や企業の障壁を下げる

簡単なOpenAPIスニペット（例）:

openapi: 3.0.1
info:
title: Prefecture Open Data API
version: 1.0.0
paths:
/v1/budget:
get:
summary: 年度別予算データ
parameters:
- in: query
name: year
schema:
type: integer
responses:
'200':
description: OK
content:
application/json: {}

実行計画（短期〜中期）

• 0〜3ヶ月: 最重要データセット10件を選定してCSVWとOpenAPI試験運用
• 3〜12ヶ月: CKAN/DCAT導入、API化をスケールアウト、SDK公開
• 1〜2年: 全自治体向けテンプレート配布と標準PMOツールで進捗管理

コスト見積の例: 小規模自治体で初期導入費用数百万円〜、運用は月額数十万円程度のSaaSでも対応可能。外製ではなくテンプレート化して内製化支援するのが安上がりです。

まとめ

自治体の「データ形」を直すことは、政策評価の精度向上と市民サービス改善につながる。内閣官房や総務省の方針がある今、PDFを配る文化をAPI/CSVへと移すことが一番の近道。技術的な道筋は明確で、OpenAPI、CSVW、DCAT、CIによるスキーマチェックを組み合わせれば現場でも再現可能です。

おかむーから一言

テクノロジーで行政をアップデートするのって、意外と地味で泥臭い作業が多いんですよね。でもその泥を掘り起こすと、政策の精度と市民の利便性は劇的に変わります。エンジニアなら一緒にコードで語りましょう！