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

• 東京都のオープンデータはCSV等で機械可読にされているが、運用面で改善余地が大きい
• リアルタイムデータ（PM2.5の1分値等）はあるが、安定したAPIと仕様管理が足りない
• API設計、GeoJSON対応、メタデータの整備で実用性が飛躍的に向上する

結論

東京都をはじめとした自治体オープンデータは「データ自体は出してる」段階から「データで政策を動かす」段階へ移す必要がある。エンジニア的に言うと、フォーマットの標準化（CSV→CSV/GeoJSON + OpenAPI）、リアルタイム配信の整備、メタデータ／スキーマの厳格化がキー。これがあれば政策評価や市民サービスの自動化がぐっと進むんですよね。

レポート本文

現状の観察（ソース参照）

これ見てくださいよ：東京都オープンデータカタログは避難所データやPM2.5の1分値などを公開していて、ライセンスはCC BY 4.0（出典: https://portal.data.metro.tokyo.lg.jp/ / https://catalog.data.metro.tokyo.lg.jp/）という嬉しい状態。ただし、公開形式はCSVが中心で、メタデータやAPIの仕様がドキュメント化されていない箇所もある印象です。

• PM2.5の1分値がデジタル化されている（速報値）→ リアルタイム性はあるが、安定したAPI仕様やサンプリング情報、欠測ルールの明示が必要（出典: 東京都カタログ）
• 避難所データはCSV提供、位置情報あり→ GeoJSONや標準プロパティ名（name,address,capacity,status等）があるとアプリ側で扱いやすい
• e-Stat / Japan Dashboardなど国レベルのダッシュボードは存在し、APIも利用可能（出典: e-Stat, デジタル庁）

要するに、データはあるけど“データで動かす”ための運用がブレイクしてるということです。

技術的な問題点の整理

• フォーマットのバラつき：CSVが主だが、文字コード（UTF-8 vs Shift_JIS）、日付フォーマット、NULL表現が統一されていない
• メタデータ不足：スキーマ（列の意味、単位、更新頻度、品質指標）が足りない
• API不足または仕様不明：データ取得のプログラム的安定性を担保するREST/GraphQLの明示がない
• リアルタイムデータの取り扱い：速報値の説明（補正・欠測ルール）が不十分
• 地理情報の標準化欠如：GeoJSONやCRS指定があるとGIS連携が楽になる

実践的な検証例（コード）

エンジニア的に言うと、こう取れば一歩目は簡単です。以下はPythonでCSVを拾ってGeoDataFrameに変換し、避難所と最近の大気測定所を重ねる例。

import pandas as pd
import geopandas as gpd
import requests
from io import StringIO

CSVを直接取ってくる（例: 避難所CSVのURL）
csv_url = 'https://catalog.data.metro.tokyo.lg.jp/dataset/.../shelters.csv'
r = requests.get(csv_url)
r.encoding = 'utf-8'
df = pd.read_csv(StringIO(r.text))

緯度経度カラムからGeoDataFrameへ
gdf = gpd.GeoDataFrame(df, geometry=gpd.points_from_xy(df.lon, df.lat), crs='EPSG:4326')

PM2.5の速報値CSVがあれば同様に取得して時系列解析
pm_url = 'https://catalog.data.metro.tokyo.lg.jp/dataset/.../pm25_1min.csv'
pm = pd.read_csv(pm_url, parse_dates=['timestamp'])

例: 1km以内の避難所ごとの平均PM2.5を計算
pm_gdf = gpd.GeoDataFrame(pm, geometry=gpd.points_from_xy(pm.lon, pm.lat), crs='EPSG:4326')
merged = gpd.sjoin(pm_gdf, gdf, how='inner', op='within')
summary = merged.groupby('shelter_id')['pm25'].mean()

要するに、APIがきちんとドキュメントされていればこのフローはもっとシンプルになるんですよね。

政策目標と実績のギャップ（一般論ベースの分析）

自治体が掲げる「迅速な避難情報提供」「リアルタイム環境監視」という目標と、データ公開の実態にはギャップがあることが多い。例えば避難所データは“場所”がわかっても“収容状況のリアルタイム更新”がないと実効性が薄い。ここを埋めるのが技術の出番です。

改善提案（実装レベル）

API化 + OpenAPI仕様書の公開

- 各データセットにOpenAPI/Swaggerを付与して、利用者が型を確認できるようにする

GeoJSON & CRS明記

- 地理データはGeoJSONで提供、EPSG:4326を標準に

メタデータの強化

- スキーマ（列名、単位、欠測ルール、更新頻度、品質指標）を機械可読に

リアルタイムデータの配信

- WebSocketやServer-Sent Eventsで速報値配信。Webhook登録で自治体側からイベント通知

データバリデーションとCI

- データ公開前にスキーマバリデーション（JSON Schema / Great Expectations）を導入

UI/UX改善

- デジタル庁やMETIのガイドラインに沿った公開ポータルの改善（検索性、APIコンソール、サンプルコード）

サンプル: 簡易API（FastAPI）設計スニペット

from fastapi import FastAPI
from pydantic import BaseModel

class Shelter(BaseModel):
id: int
name: str
address: str
capacity: int
lat: float
lon: float

app = FastAPI()

@app.get('/shelters', response_model=List[Shelter])
def list_shelters():
# DBやデータレイクから取得して返す
pass

このようにOpenAPI化すれば利用者は型を信頼してアプリを組めます。

活用アイデア

• 避難所の収容率をリアルタイムで可視化し、自治体とSNSの自動連携で混雑アラートを発行
• PM2.5速報値と人口動態データを掛け合わせて屋外イベントの安全判定を自動化
• 地域経済指標（RESAS等）と連携して復興支援の優先度スコアを算出

まとめ

現状、東京都を含む自治体データは「公開」フェーズにあるが、「運用」「連携」「自動化」までは到達していないケースが多い。エンジニア視点だと、フォーマット標準化、OpenAPI化、GeoJSON対応、リアルタイム配信、メタデータ強化があれば政策の検証とサービス化が一気に進む。具体的な改善は短期（OpenAPI + メタデータ）と中長期（リアルタイム配信、CI導入）で段階的に進めるのが現実的です。

おかむーから一言

テクノロジーは“出すだけ”じゃダメで、“使われる形”にすることが大事なんですよね。ノーギアスの経験で言うと、良いデータ設計はプロダクトのUXを5倍良くする。みんなで作っていきましょう！

---

参照: 東京都オープンデータカタログ（https://catalog.data.metro.tokyo.lg.jp/）、e-Stat（https://dashboard.e-stat.go.jp/）、デジタル庁 Japan Dashboard（https://www.digital.go.jp/resources/japandashboard）、METI UI/UX資料（https://www.meti.go.jp/）