政府データの「鮮度SLO」を作ろう！更新遅延を技術でガチ管理する話

どうも〜おかむーです！今日はデータの鮮度、いわゆる"Freshness"の話をちょっとエンジニア寄りに掘りますよ〜

• 政府・自治体データは“出る頻度”がバラバラで使いにくい問題が残ってます
• 重要なのは可視化だけでなく「どれくらい新しいか」をSLOで担保することです
• 実際のサービス（keiba、NICTER、e-Stat等）を例に、実装と監視の設計を提案します

結論

公開データには「いつ更新されたか」を機械的に保証する仕組み（鮮度SLO＋イベント配信）が必要です。エンジニア的に言うと、API/ヘッダでのバージョン管理、プッシュ通知（WebSub/SSE/webhook）、およびPrometheusでの鮮度監視を組み合わせれば実用的に改善できます！

現状観察：データの“鮮度”はバラバラ

これ見てくださいよ。地方競馬情報サイト（keiba.go.jp）はライブ中継や「発走時刻30分以内は黄色表示」といったUIで時間を伝えてますが、APIの存在は明示されていないページもあります（https://www.keiba.go.jp/）。

一方でNICTERの注意喚起はCSVを公開していて（https://notice.go.jp/docs/status_nicter.csv）、頻繁に更新されるデータの典型です。国の統計はe-Statダッシュボード（https://dashboard.e-stat.go.jp/）で可視化してますが、更新頻度と機械可読性はデータセットごとに違います。

要するに、データが新しいか古いかをプログラムから自動判断する手段が統一されていないことが多いんですよね。

技術的に測る／担保する「鮮度SLO」設計

エンジニア的に言うと、まずはSLOを定義して監視パイプラインを作ります。重要な指標は以下:

• Freshness latency: データソース側での最終更新時刻と利用側で取得した時刻の差
• Staleness rate: SLO（例：5分以内）を超えたリクエストの割合
• Update frequency declared vs actual: メタデータに書かれた頻度と実際の更新間隔の差

実装要素:

• HTTPヘッダ: Last-Modified / ETag を全API/ファイル配信で使う
• メタデータ: dataset.json に last_updated, expected_frequency, change_type を含める（https://project-open-data.cio.gov/ の考え方に近い）
• プッシュ: WebSub / Server-Sent Events / Webhook で変更を通知
• モニタリング: Prometheus にカスタムメトリクスを流す（freshness_latency_seconds, stale_fraction）

簡単なコード例（条件付き取得+鮮度計算）

import requests
from datetime import datetime

url = 'https://notice.go.jp/docs/status_nicter.csv'
resp = requests.get(url, headers={'If-Modified-Since': 'Tue, 01 Jan 2025 00:00:00 GMT'})
if resp.status_code == 304:
print('Not modified')
else:
lm = resp.headers.get('Last-Modified')
if lm:
last_mod = datetime.strptime(lm, '%a, %d %b %Y %H:%M:%S GMT')
latency = datetime.utcnow() - last_mod
print('Freshness latency:', latency.total_seconds(), 'sec')
else:
print('Last-Modified header missing')

要するに、HTTPキャッシュヘッダを怠らないだけで鮮度の一次指標が取れるということです。

実運用での課題と具体的改善案

問題点:

• CSVやPDFのみで更新時刻が埋もれているケースがある（検索結果のCSV一覧参照）
• そもそもAPIがない、または速達性のためのプッシュ手段がない
• メタデータが非標準で、監査や差分検出が難しい

改善案（優先度順）:

1) 全データに machine-readable metadata を付与（dataset.json）: last_updated, change_type, contact

2) HTTPヘッダの運用徹底：ETag/Last-Modified と Cache-Control

3) 重要データはプッシュ配信：WebSub/Webhookで購読可能に

4) 差分配信API：フルダンプだけでなく delta-endpoint を実装して帯域と処理時間を削減

5) 鮮度SLOの策定とモニタリング：SLO(例: 95% requests < 5min)を公開しPrometheus+Grafanaで可視化

導入イメージ：流れをコードで説明

• データ公開側: 更新時にS3に新ファイルを置く→PUTイベントでLambdaがdataset.jsonとSSE通知を発行
• 利用者側: SSEで通知を受け取り、差分APIを叩いてインクリメンタルに取り込む

このパターンだと「いつ更新されたか」が確実に伝搬して、取り込む側は古いデータ処理を避けられます。

ガバナンスとSLAの話

政策データは単なるファイルじゃないです。選挙、災害、経済指標など重要性が異なるので、データカテゴリごとに鮮度要件を定義してSLA化しましょう。デジタル庁や総務省の標準化計画（例: 地方公共団体の基幹業務システムの統一・標準化）と合わせて運用するのが現実的です（https://www.digital.go.jp/policies/local_governments、https://www.soumu.go.jp/）。

まとめ

• 単にデータを公開するだけでなく「機械が鮮度を検証できる」仕組みが必要です
• HTTPヘッダ、機械可読メタデータ、プッシュ配信、SLO監視の組み合わせが現実解です
• 小さく始めるなら: まずLast-Modifiedとdataset.jsonを全部の公開物に追加してください！

おかむーから一言

テクノロジーで市民の信頼を作るのは地味だけど超大事な仕事です！まずは小さなSLOから入って、改善の連鎖を起こしましょう〜