政府ダッシュボードの“更新信頼度”をコードで監視する話

どうも〜おかむーです！今日は政府や自治体のダッシュボード／公開データの更新タイミングと信頼性をエンジニア的に検証する話をしますよ〜

• ダッシュボードは見える化されているけど、更新の“信頼度”が見えないことが多い
• APIやCSVに対して差分検出・更新遅延検知の自動監視を回すと、政策の実効性検証に直結する
• 技術的にはETag/Last-Modified、スキーマ検証、タイムスタンプ署名、差分アラートでかなり改善できる

結論

政府の公開ダッシュボード（たとえばJapan Dashboard / Digital庁やe-Statなど）は可視化の入口として有用だけど、実務的な検証・再現をするためには「更新の確度」を機械で追跡できる仕組みが必須です。エンジニア的にはAPIのメタデータ（ETag, Last-Modified）、明示的なデータタイムスタンプ、スキーマ宣言、差分配信（webhookやChangeLog）があれば8割は解決しますよ〜

レポート本文

なぜ更新信頼度が重要か

公開ダッシュボード（参照: Japan Dashboard: https://www.digital.go.jp/resources/japandashboard, e-Stat: https://dashboard.e-stat.go.jp/）は政策の状況を端的に示してくれます。けれど「このグラフ、いつ更新されたデータで作ってるの？」が明確でないと、政策評価や第三者検証で使いにくいんです。

これ見てくださいよ：ダッシュボードAは“毎日更新”と書いているけど、データソースがPDF添付だけで更新日時がない。要するに“見た目は最新”でも“データ再現性ゼロ”ということです。

現状の技術的課題（よくあるパターン）

• データがPDFに埋め込まれている（機械可読性ゼロ）
• CSVはあるがLast-Modified/ETagが未設定で差分検出できない
• APIはあるがスキーマ定義（OpenAPI/JSON Schema）がないためスキーマドリフトが起きる
• タイムゾーンや日付フォーマット不一致で時系列解析が壊れる
• ダッシュボードウィジェットがデータの加工ロジックを公開していない（どのフィルタ・補正が入ったか不明）

技術的検証手法（現場で使える）

1) メタデータ追跡

- HTTPヘッダのETagとLast-Modifiedを利用して差分検出

- JSON/CSV に "data_published_at" のようなタイムスタンプを入れてもらう

2) 差分・スキーマ監視パイプライン

- 定期的に取得してハッシュ（SHA256）を比較

- JSONなら jsonschema でバリデーション、CSVはヘッダ一致と型サンプリングで検査

3) 変化検出の自動通知

- 変更があればSlack/メール/Webhookへ通知

- 期待より更新が遅延していたらアラート（SLA監視のように）

サンプル: Pythonで簡単に差分監視する（例）

import requests, hashlib, sqlite3, time
DB='meta.db'
conn=sqlite3.connect(DB)
conn.execute('CREATE TABLE IF NOT EXISTS resources(url TEXT PRIMARY KEY, etag TEXT, last_hash TEXT)')
url='https://example.gov/data.csv'
resp=requests.get(url)
etag=resp.headers.get('ETag')
body=resp.content
h=hashlib.sha256(body).hexdigest()
row=conn.execute('SELECT etag,last_hash FROM resources WHERE url=?',(url,)).fetchone()
if not row:
conn.execute('INSERT INTO resources(url,etag,last_hash) VALUES(?,?,?)',(url,etag,h))
print('initial pull')
else:
old_etag, old_hash = row
if etag and old_etag!=etag:
print('ETag changed -> update')
elif old_hash!=h:
print('content changed (hash mismatch) -> update')
else:
print('no change')
conn.commit()

要するに、ETagが無い場合でもハッシュで比較すれば更新は検出できます。ただしPDFだとバイナリ差分が細かくてノイズが出るので、可能ならCSV/APIでの公開をお願いしたいんです！

スキーマドリフト対策

• OpenAPI / JSON Schema を公開してもらう
• CIでschema vs sampleを自動チェック（GitHub ActionsやGitLab CI）
• 破壊的変更はセマンティックバージョニングで管理

政策評価への応用（数値目標と実績ギャップの検出）

政策は「目標値」と「実績」を比較して評価します。けれどダッシュボードの実績値がいつのデータに基づくか曖昧だと、ギャップが過小評価されるリスクがあります。

実務例：ある自治体が業務効率化で「処理時間を20%短縮する」と掲げたとします。可視化はあるが、実績の原データが週次更新で2週間ラグがあったらどうなるか。エンジニア的には“ラグ補正”を加えないと誤った結論になるんですよね。

そこで、上で説明した自動監視を回しておけば「この指標は最新データで算出されたか」「データ更新に○日ラグがある」などを定量的に示せます。要するに、政策のKPI検証が定量的かつ再現可能になるということです。

改善提案（実装指針）

• API/CSV提供側で必須メタデータを定義する（data_published_at, version, source_url）
• HTTPでETag/Last-Modifiedを正しく返す
• ダッシュボード側は表示データに“基データのハッシュ/バージョン”を載せる
• 公開APIにOpenAPI・JSON Schemaを添付する
• 変更検出用Webhookを用意し、外部監視サービスが購読可能にする
• CIでスキーマ検証とサンプルデータの自動テストを回す

技術的には、これらを組み合わせると「誰でもコードで検証できる」形になるので、政策の透明性がぐっと上がります！

まとめ

• 見た目のダッシュボードだけでは政策評価に不十分。更新の『信頼度(誰がいつどのデータで作ったか)』を機械可読にするのがポイント
• ETag/Last-Modified、データタイムスタンプ、スキーマ、差分配信を組み合わせれば再現性は高まる
• エンジニア的には監視パイプライン（ハッシュ比較、jsonschema、アラート）を早めに作ると現場の手間が激減します

おかむーから一言

テクノロジーで社会をアップデートするって口で言うのは簡単だけど、実際はこういう“更新の信頼度”みたいな地味なところをちゃんと直すことが近道なんですよね！一緒にコードで検証していきましょう〜