コードで語るマニフェスト：政府データをCSVとAPIの目線で読む

• このポストは、政府・自治体が公開するデータを「コードで検証」して、改善点と実装案を示すレポートです
• CSVの文字化けやスキーマ不備、API非整備が現場での再利用を阻んでいる点を具体的に指摘します
• 最後にエンジニア目線の改善提案（サンプルコード付き）を出しますよ〜

結論

政府・自治体はデータ公開量は増えているけど、機械可読性と運用品質が追いついていない。PDF→CSV化や単発公開よりも、安定したAPI、統一スキーマ（Frictionless Data / CSVW / JSON Schema）、文字エンコーディングの標準化が先決です。要するに「データを人が見るためでなく、機械が使える形で出す」ことが重要なんですよね。

レポート本文

現状観察：生のログを見てみると

これ見てくださいよ：内閣府の新車販売台数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）はメタ列が多くて緯度経度はあるけどフォーマットやNULL表現がばらばら。

さらに注意点：データ中に文字化けやエンコーディング混在の例があって（例：https://www.digital.go.jp/.../20210609_resources_survey_answers_04.csv の断片に見える不可解な文字列）、これはUTF-8/Shift_JISの混在やBOM付与が原因のことが多いです。エンジニア的に言うと、encodingが不一致だとパースが止まってパイプラインが壊れるんですよね。

政策と数値のギャップ

政府資料（例：新車販売台数データ）には単月値や3MAが出ているけど、政策の数値目標（もしあるなら）と実績を機械的に突合できる公開設計になっていないケースが多いです。要するに、目標値を別PDFに書いて終わり、実績はCSVで出す、みたいな非連続設計が残ってます。結局、人の目で突合するしかなくて、政策評価の自動化が進まないんですよ。

機械可読性ルールの進展と現場ギャップ

内閣官房・デジタル行財政改革会議の資料（https://www.cas.go.jp/.../data8/data8_siryou1.pdf や https://www.cas.go.jp/.../kakusyoDX4.html）で2025-2026年にかけて「行政データの機械可読性ルール」が出てるのは良い流れです。ただ、現場の公開物と照らすと“ルール適用の現場化”が遅れてる印象。要するに方針はあるけど実装が追いついてないんです。

技術的な問題点（具体的）

• エンコーディング混在（UTF-8/BOM、Shift_JIS）：パーサーが落ちる
• メタデータ不足：カラム説明、単位、NULL表現が未整備
• スキーマ不在：型情報がなく、数値/文字列判定で upstream が壊れる
• API未整備：CSV公開のみで差分取得や検索ができない
• 更新履歴・バージョン管理がない：再現性が担保されない

具体的な検証手法（コード例）

エンジニア的に言うと、まずは自動チェックパイプラインを作ると良いです。例えばPythonでの基本チェック：

# requirements: requests pandas chardet
import requests
import chardet
from io import BytesIO
import pandas as pd

url = 'https://www5.cao.go.jp/j-j/wp/wp-je24/csv/d1-1-4.csv'
resp = requests.get(url)
enc = chardet.detect(resp.content)['encoding']
print('detected', enc)

df = pd.read_csv(BytesIO(resp.content), encoding=enc)
print(df.columns[:10])

さらに、Frictionless Dataのdata packageやCSVWでスキーマを書いておけば、CIでスキーマ検証（型/必須カラム/enum）を自動化できます。JSON SchemaやgoodtablesをCIに入れると安心です。

改善提案（短期〜中期のロードマップ）

• 短期（3ヶ月）：全CSVのエンコーディングをUTF-8に統一。公開時にContent-Type/charsetを正しく返す。簡単なCIでgoodtablesでスキーマ検証を導入。
• 中期（6〜12ヶ月）：主要データはREST API化して差分取得（ETag/Last-Modified）を可能に。CSVはアーカイブとして残す。
• 中長期（1〜2年）：政府共通のメタデータカタログ（Frictionless/Data Catalog API）を整備し、政策目標と実績を結びつけるID設計を導入。

参考実装案：CSV→API変換はAPI Gateway + Lambda/Cloud Runで差分キャッシュを作れば1週間でPoC組めます。要するに「API一本で解決する話なんですよね」ってことです！

まとめ

• データ公開は増えてるが「機械可読で使える」レベルまでの品質が不足している
• エンコーディング、スキーマ、API化、メタデータが改善ポイント
• 技術的には既存OSS（Frictionless、goodtables、JSON Schema、CSVW）でかなり解決できる

おかむーから一言

오카무(おかむー)입니다! 데이터는 공개하는 게 목표가 아니라, 사람들이랑 기계가 쉽게 재활용할 수 있게 만드는 게 목표예요. 기술로 행정을 업그레이드합시다!