• このレポートは実際の政府公開CSVを手元に、機械可読性・フォーマット・APIの有無を技術的にチェックしますよ〜
• PDFに閉じられた情報と、ちゃんとCSVで公開されているデータの差を見せます。エンジニア的にはAPI一本で解決できるんですよ！
• 問題点は「エンコード」「スキーマ不備」「メタデータ不足」。改善案としてJSON Schema、OpenAPI、安定ID、バージョニングを提案します！

結論

実データを触ると分かるんですけど、政府・自治体のデータ公開は「CSVはあるけど使いにくい」がまだまだ多いです。機械可読性ルール（2026年の決定）に期待しつつも、現場ではエンコードの混在、スキーマ不在、メタデータ不足、API未提供がボトルネック。技術的には「UTF-8で統一」「JSON Schemaで型定義」「OpenAPIでAPI提供」「安定したID付与」が即効性が高い改善策です。

レポート本文

何を見たか（データソース）

これ見てくださいよ：実際に公開されているファイルをいくつか拾いました。

• https://notice.go.jp/docs/status_notice.csv — 公的通知系のCSV（存在は確認できる）
• https://www5.cao.go.jp/j-j/wp/wp-je24/csv/d1-1-4.csv — 新車販売台数のCSV（時系列データ）
• https://www.digital.go.jp/.../xxxxxx_hospital.csv — 医療機関リスト（緯度経度や法人番号まで含む）
• https://www.env.go.jp/content/900398071.csv — 環境系のCSV（都道府県別など）

参考として、デジタル行財政改革会議の議事資料（2026/03/31）で「行政データにおける機械可読性ルール」が決定されているので、制度面の追い風はあります（出典：内閣官房／デジタル庁の公開資料）。

技術的に見えてきた課題

エンジニア目線でよく見る問題点を挙げます。

エンコーディングとBOMの混在

- 実務でよくハマるのが文字化けや不正バイト。検索結果の一部CSVにゴミ文字（�や文字化け）やBOM混在の痕跡があります。要するに、UTF-8に統一してくれれば助かるんですよ。

スキーマ不備・カラム定義の不足

- CSVだけ置いて「説明はPDF参照」ってケースがまだ多いです。CSV単独で列名・型・単位・更新頻度が分かると再現性がぐっと上がります。

時系列や単位の曖昧さ

- 例：新車販売台数のCSVは数値単位（万台？台？）があるけど、メタデータに明確に書かれていないと解釈ミスするんです。

安定ID・主キーの欠如

- 医療機関データは法人番号や医療機関コードがあるものの、全データで統一された安定IDがないとレコード突合が難しい。

API非提供または断片的

- データカタログはある（東京都や埼玉県など）が、APIで一本化されているケースはまだ限定的。スクレイピングや定期ダウンロードで運用されがち。

実務でどう処理するか（コード例）

エンジニア的に言うと、まずはフェッチ→検証→正規化のパイプラインを作るのが定石です。Python/pandasでのサンプルを置いときます。

import pandas as pd
import requests
from io import BytesIO

url = 'https://www5.cao.go.jp/j-j/wp/wp-je24/csv/d1-1-4.csv'
res = requests.get(url)
まずエンコーディングを推定してUTF-8に変換
text = res.content.decode('utf-8', errors='replace')
df = pd.read_csv(BytesIO(text.encode('utf-8')))
列名や型をチェック
print(df.dtypes)

データ品質検査の自動化（例）：

• null率チェック
• 数値レンジチェック（異常値検出）
• 単位一貫性の確認

スキーマとAPI設計の提案

要するに、こうすれば二度手間が減るんです：

• データはUTF-8で公開、BOMを含めない
• 各データセットにJSON Schemaを添付（列名、型、単位、例、更新頻度）
• RESTful API + OpenAPI仕様で一覧取得・フィルタ・ページングを提供
• 静的ファイル（CSV）はバージョン付きのURLを付与して履歴を残す
• IDは自治体横断で照合できるよう「連携用安定ID」を付与

簡単なOpenAPI概要（抜粋）:

openapi: 3.0.1
paths:
/datasets/hospitals:
get:
parameters:
- name: prefecture
in: query
schema:
type: string
responses:
'200':
content:
application/json:
schema:
$ref: '#/components/schemas/HospitalList'

政策目標と実績の検証について

ここ大事なんですけど、政策の数値目標（KPI）がPDFや散在するCSVに埋もれていると、実績検証が人的コストに依存してしまいます。例えば「自動車販売の回復目標」があったとしても、CSVの更新頻度・単位不明で比較がブレる。要はデータの“検証可能性”を高める仕組みが必要なんです。

活用シナリオ（オープンデータの可能性）

• 市民向けダッシュボード（時系列可視化・アラート）
• 二次利用アプリ（保険、物流、地域医療マッチング）
• 検証可能な政策評価：公開APIで第三者が再検証可能に

優先度の高い実装タスク（短期3つ）

主要データセットでUTF-8+BOM無しに切替

JSON Schemaを全データセットに付与

最も需要の高い3つのAPI（医療機関、人口、経済指標）をOpenAPIで公開

コスト感とガバナンス

技術的な実装コストは高くないです。既存のCSVを正規化してOpenAPIでラップするだけなら中小のSIer・ベンダーで対応可能。重要なのは運用ガバナンス（誰がスキーマを管理するか）とアクセス権の方針です。

参考：チェックリスト（開発チーム向け）

• [ ] UTF-8で公開
• [ ] JSON Schemaを公開
• [ ] OpenAPIを用意
• [ ] データ辞書（単位・更新頻度・接頭辞）を整備
• [ ] バージョン管理と履歴保持

期待効果

• データ利活用のスピードアップ
• 市民と第三者による政策検証が可能に
• 再現性のある政策評価サイクルの実現

まとめ

現状、良いCSVはあるけど“使いやすくはない”が正直なところです。制度面での機械可読性ルールは前向きな一歩ですが、技術的な細部（エンコーディング、スキーマ、API提供、安定ID付与）が揃って初めて「検証可能な政策」が成立します。エンジニア的にはすぐ直せる課題が多いので、今すぐ着手してほしいですね！

おかむーから一言

テクノロジーで社会をアップデートするのがミッションです。データの基本をちゃんと揃えれば、政策はもっと説明可能になるし、市民の信頼も増えます。まずはCSVをUTF-8にしてJSON Schemaつけるだけで世界変わりますよ、マジで。