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

• 3行要約

- 自治体サイトのアクセスデータは政策評価の一次情報になるけど、フォーマットや公開ルールがバラバラで活用しづらい

- エンジニア的には「イベントスキーマの標準化」「集約API + CSVエクスポート」「差分プライバシーでの公開」が実装の肝

- 実務ではDigital庁の機械可読性ルールや、自治体の事例（例：須賀川市の評価）を踏まえてスモールスタートのパイプラインを提案する

結論

自治体のウェブアクセスログは単なるトラフィック指標じゃなく、サービス改善や政策の効果検証に使える“公開すべきデータ”です。ただし、個人特定やフォーマットのバラつきが障壁。エンジニア的には「軽量なイベントスキーマ＋集約API＋差分プライバシー適用」を基本設計にすることで、プライバシーを守りつつ再利用可能なオープン指標を実現できます。

レポート本文

背景 — なぜアクセスデータが政策に効くの？

自治体サイトは住民サービスのフロント窓口。案内ページのアクセスやFAQ閲覧は、施策の需要や情報伝達の成功率を示す重要な信号です。これを定量化してオープンにすると、行政と市民・研究者が同じ土俵で議論できるんですよね。

一方で、公開はまだ不十分。Digital庁が示す「行政データにおける機械可読性に関するルール」（参考: https://www.digital.go.jp/）では、CSVやExcel等の機械可読形式が推奨されていますが、現場ではPDFや画像化されたログ要約で終わることが多いです（これ見てくださいよ、PDFに埋まってるレポートは最高に解析しづらい）！

現状の課題（技術的に見ると）

• フォーマット非統一：アクセスログ→イベント名やページIDが自治体ごとに違う
• プライバシー：IP、cookieベースの行動ログは個人特定リスクが高い
• 発見性：カタログ横断でメトリクスを集める仕組みがない
• 検証困難：KPIや数値定義が公開されていないことが多く、比較できない

要するに、データはあるけど“使える形”になっていないってことです。

エンジニア的解決方針（アーキテクチャ）

小さく始めて確実に価値を出すための構成案を提示します：

Client-side and Server-side Event Schema（最小限の標準スキーマ）

- 必須フィールド：timestamp, site_id (自治体ID), page_id, event_type (view, click, download), country, ua_family

- 非必須：session_length, referrer

これ見てくださいよ、サンプルJSONスキーマ：

{
"timestamp": "2026-03-31T12:34:56Z",
"site_id": "sukagawa-city",
"page_id": "/childcare/benefit",
"event_type": "view",
"country": "JP",
"ua_family": "Chrome"
}

集約パイプライン（バッチ or ストリーム）

- Raw logs → ETL（正規化）→ 日次集約（page_idごとのPV, UV推定）→ 差分プライバシー適用 → 公開CSV & API

- 技術スタック候補：Cloud Functions / Lambda（正規化） + BigQuery / ClickHouse（集約） + Airflow（オーケストレーション）

プライバシー処理

- エンジニア的に言うと、個別ログをそのまま出すのはNGなので、集約レベルでノイズを載せるか、閾値（例えばユーザー数が10未満なら非公開）を適用します

- シンプルなラプラスノイズ例（Python）を紹介します：

import numpy as np

def laplace_mechanism(count, epsilon=0.5):
noise = np.random.laplace(loc=0.0, scale=1/epsilon)
return max(0, count + noise)

例: ページのPVが42件のとき
print(laplace_mechanism(42, epsilon=0.5))

要するに、ノイズを入れても傾向は残るので政策評価には使えるんです。

公開インターフェース

- CSVエクスポート（機械可読性ルールに準拠）と、JSON REST API（OpenAPI仕様）を両方提供

- APIは日次集計を返すエンドポイントで十分。例：GET /v1/metrics/site/{site_id}/page/{page_id}?date=2026-03-31

実装上の細かいポイント

• スキーマ管理：バージョニングして互換性を担保（例：schema_registryにJSON Schemaを置く）
• メタデータ：各指標の定義（PV, UVの定義、ノイズ手法、サンプリング率）を必ずデータカタログに明記する。Digital庁の指針と合わせると信頼性高いです（参考: https://www.cas.go.jp/）
• 横断分析：e-Stat等の官民データと結合するために、site_idや行政区コード（JISコード）で標準化する

コードで語る一例：日次集計の簡単なSQL

SELECT
site_id,
page_id,
DATE(timestamp) as day,
COUNT(*) as pv,
APPROX_COUNT_DISTINCT(session_id) as uv_estimate
FROM events_normalized
WHERE DATE(timestamp) BETWEEN '2026-03-01' AND '2026-03-31'
GROUP BY site_id, page_id, day;

政策とKPIの結び付け方（数値目標と実績のギャップ）

政策側は「窓口案内の到達率70%」みたいな目標を置くことがあるけど、これをサイト指標で追うには定義統一が必要。たとえば「到達率 = 対象ページの閲覧UV / 対象世帯数×100」と明文化しておくと、議論が噛み合います。

須賀川市のように外部有識者レビューを公開している自治体の取り組みは参考になります（参考: https://www.city.sukagawa.fukushima.jp/）。要するに、第三者検証があると信頼できるんですよね。

導入ロードマップ（スモールスタート）

まず1自治体でイベントスキーマを導入（3ヶ月）

日次集計とCSV公開を開始、差分プライバシーの導入（次の3ヶ月）

複数自治体でスキーマ適用、データカタログ化（6〜12ヶ月）

まとめ

• 自治体のウェブアクセスは政策評価に超使えるデータだけど、現在はフォーマットとプライバシーの問題で眠っている
• エンジニア的には「標準イベントスキーマ」「集約API/CSV」「差分プライバシー」の組み合わせが現実的で価値が出やすい
• Digital庁の機械可読性ルールや既存の自治体評価事例を踏まえ、スモールスタートでの実装と可視化が鍵

おかむーから一言

テクノロジーで行政サービスをより良くするのって最高にワクワクするんですよね。まずは一つのページの閲覧ログを“ちゃんと使えるデータ”にしてみましょう！