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

• これ見てくださいよ：東京都や各自治体のオープンデータ、時系列データの扱いにムラがある
• エンジニア的に言うと、API設計・チャンク処理・スキーマ進化の設計で政策評価が劇的に変わる
• 提案：時系列公開データを想定した“耐障害パイプライン”と軽量な検証コードを導入しよう

結論

公開されている時系列データ（例：東京都水道局の水源量CSVなど）は、フォーマットやメタデータの不統一で使いづらいことが多いです。エンジニア視点では「ストリーミング取得」「スキーマ定義」「時系列DB格納」「差異検出の自動化」がセットになれば、政策目標と実績を継続的に検証できるようになります。

レポート本文

現状観察：カタログとフォーマットの雑感

最近のオープンデータカタログ（例：東京都オープンデータカタログ、新潟市、埼玉県、横浜市、Daisen市のCKAN）を見ると、次のような実態があるんですよね：

• フォーマットはCSVが多いが、説明（メタデータ）がないデータセットが散見される（横浜市の一部データのように）
• CKANを使っている自治体はAPIを公開している例がある（Daisen市のCKANはAPIを示唆）
• 公共サービス系システムは予約や稼働ログを持っているが、その公開形式は各自治体でバラバラ

要するに、データはあるけど“安定して取り回せる仕組み”が足りないということです。

技術的な問題点を具体的に見る

1) メタデータ不足

• 項目名だけで型や単位が無いと解釈バグが起きる。
• 例えば水源量なら「m3/日」なのか「m3/月」なのか必ず明記してほしい。

2) 大きな時系列ファイルの扱い

• 数十MB〜数百MBのCSVを丸ごと落とす運用は現場も分析者もツラい。
• エンジニア的に言うと、HTTPレンジやストリーミングでのチャンク処理がマスト。

3) スキーマ進化（後方互換）

• カラム追加や名称変更で解析パイプラインが壊れる。Schema Registry的な仕組みが欲しい。

4) APIとバッチの混在

• CKAN APIがある自治体と単純なファイル置き場の自治体が混在すると、汎用パイプラインが作りにくい。

政策検証のためのエンジニア的ワークフロー（提案）

• データ提供側の要件

- 各時系列データにJSON-LD風のメタデータ（項目名、型、単位、更新頻度、最終更新日）を添付

- 大きな日次/時系列はパーティション化（年別/月別ファイル）

- CKANやS3互換ストレージ＋HTTPレンジ対応で部分取得を可能に

• 収集・保管

- ストリーミング取得（requests.stream）でメモリを節約

- TimescaleDBなどの時系列DBにハイパーテーブルで格納

• 品質検証

- Panderaやjsonschemaでスキーマ検証を自動化

- 異常値検知は移動平均や季節性を考慮した閾値で自動アラート

• 可視化と再現

- 小さなダッシュボード（Grafana）でポリシーKPIを見せる

- 生データと加工データを分け、変換コードをリポジトリで管理（Data as Code）

ミニコード例：CSVをストリーミング取得してPanderaで検証（Python）

import requests
import pandas as pd
import pandera as pa
from io import StringIO

schema = pa.DataFrameSchema({
"date": pa.Column(pa.DateTime),
"source_volume_m3": pa.Column(float, nullable=False),
})

url = "https://catalog.data.metro.tokyo.lg.jp/dataset/.../download/sample.csv"
with requests.get(url, stream=True) as r:
r.raise_for_status()
buf = StringIO()
for chunk in r.iter_content(chunk_size=1024*64, decode_unicode=True):
buf.write(chunk)
buf.seek(0)
df = pd.read_csv(buf, parse_dates=["date"])

validated = schema.validate(df)
validatedをTimescaleDBへバルクインサート

要するに、コード書く人ならわかると思うんですけど、丸ごと落として手作業で加工するのは時代遅れなんですよね。

政策目標との合わせ方：目標値と実績をコードで紐付ける

データが時系列で安定して取れるようになれば、政策の数値目標（例：年間平均水確保量）と実績をプログラムで比較できる。具体的には：

• 目標を設定するメタテーブルを用意（goal_id, metric, period, threshold）
• ETLで実績を集計し、ゴールと差分を毎日算出
• 差が閾値を超えたらSlackやメールで担当に通知

疑似コード：

INSERT INTO alerts (metric, period, value, goal)
SELECT 'water_source', '2026-03', sum(source_volume), g.threshold
FROM measurements m JOIN goals g ON g.metric='water_source'
WHERE date_part('month', m.date)=3 AND date_part('year', m.date)=2026
HAVING sum(source_volume) < g.threshold;

活用提案：自治体横断の「時系列ファイルパターンライブラリ」

• よくある時系列（人口・水道・排水・施設利用）それぞれの推奨スキーマテンプレを用意
• CSV＋JSONメタで1つのパターンに従えば、汎用インジェストが可能になる

まとめ

• 公開時系列データは既に財産になりうるが、フォーマットとメタデータの不統一が障壁になっている
• エンジニア視点では「ストリーミング取得」「スキーマ検証」「時系列DB」「Policyゴールのコード化」がキー
• 小さな改善（メタデータ付与、レンジ対応、スキーマ定義）で行政の政策検証力はぐっと上がる

おかむーから一言

テクノロジーで社会をアップデートするのって、本当に地味な改善の積み重ねなんですよね。みんなで少しずつコードを入れていけば、政策はもっと検証できる。やろう！