政策は本番前にリハーサルできるか？：モックデータで政策実行性を検証する技術手法

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

• 政策や交付金のKPIは“公開後の検証”だけじゃ遅い。モックとシミュレーションで事前検証しよう！
• PDFに埋まった実績レポートや各省の標準化ルールをベースに、API契約と合成データで『リハーサル環境』を作る手順を示すよ〜
• 要するに、コードで政策を一度動かしてみれば、運用コストやデータ欠損の地雷を早めに見つけられる、ってことです！

結論

政策はリリース前に“モックデータ＋契約テスト＋CI”でリハーサルするべき。とくに地方公共団体の基幹業務標準化が進む今、標準APIと合成データのテストベッドを整備すると、運用トラブルやKPI測定の齟齬を大幅に減らせます。

レポート本文

背景：なぜ“事前リハーサル”が必要なのか

デジタル庁の動きや「地方公共団体情報システムの標準化に関する法律」（e-gov）で、自治体システムに標準準拠が求められているよね（参照: digital.go.jp、laws.e-gov.go.jp）。要するにAPIやデータスキーマでの合意が増えるんだけど、実際のデプロイでデータの欠落・形式違反・運用ルールの齟齬が原因でKPIが測れなくなるケースが多いんです。

これ見てくださいよ：交付金や事業報告の実績はPDFで公開されることが依然多くて（自治体PDFレポート例: pref.yamaguchi.lg.jp）、機械可読性が低い。実データで動かす前に、APIの想定やKPI算出ロジックをコードで検証しておけば、発見できる不整合が圧倒的に増えるんです。

技術的アプローチ：モックAPI＋合成データの設計

以下は実務で使える流れ。エンジニア的に言うと、合同テスト（contract testing）と合成データ生成の組合せで“政策の振る舞い”をCIに入れる、って感じです。

スキーマ設計

- 既存の省・自治体の標準仕様書（digital.go.jpや厚労省の標準仕様など）をベースにOpenAPI / JSON Schemaを作る。要するにAPIの型定義を最初に書いておく。

合成データ生成

- FakerやSDV、差分プライバシー付きの合成ツールで住民や事業者データを作る。実データを直接使わず、運用パターンを再現する。

モックサーバ＋契約テスト

- Pactやwiremockでプロバイダ／コンシューマの契約テストを用意。APIの契約が変わったらテストが落ちる。

KPIシミュレーション

- 合成データを流してKPI算出ロジック（例: 交付金消化率、利用件数の時系列）を実行、期待値とズレがないかを検証。

CI組込み

- すべてをGitHub Actions/GitLab CIに流して、仕様変更時に自動でリハーサルが走るようにする。

具体的コード例（合成データ生成）

# simple_synthetic.py — Fakerで自治体向けサンプルを作る例
from faker import Faker
import json
fake = Faker('ja_JP')
rows = []
for i in range(1000):
rows.append({
'resident_id': f"R{i:06}",
'age': fake.random_int(min=0, max=100),
'address_block': fake.address(),
'applied_grant': fake.random_element(elements=('A','B','C')),
'applied_date': fake.date_between(start_date='-2y', end_date='today').isoformat()
})
print(json.dumps(rows, ensure_ascii=False))

この合成データをモックAPIに流して、KPI算出ロジックを回すと「どの申請日パターンで処理遅延が起きるか」「CSV→DB変換で日付フォーマットが壊れるケース」などを事前に見つけられます。

モックを作るときによくある落とし穴と対策

• 本物っぽいが偏る合成データ

- 対策: 実レポートの統計（年齢分布、申請種別比率）を読み取り、サンプリングで近似する

• プライバシー問題

- 対策: 実データは使わない。差分プライバシー手法や合成の検証を取り入れる

• PDFソースの取り扱い

- 対策: PDFは一時的な仕様書扱いにして、必ずスキーマ化（CSV/JSON）して保存する

実運用でのUX/ガバナンス連携

デジタル庁のUI改善施策（digital.go.jp のUIガイドライン）と組み合わせると、リハーサル環境でユーザーテレメトリ（クリック、離脱）を模擬してUI変更の効果も測れる。要するに“技術的なリハーサル”が、UX改善と運用安定につながるんです。

期待される効果（定量的に測る）

• 本番バグ件数の削減率（目標: 50%減）
• KPI測定ずれの検出率向上（目標: 90%の事前検出）
• ロールバック回数の減少

これらはCIでのベンチマークとして自動計測できるよ。

まとめ

政策はコードで動かしてリハーサルできる！標準APIの設計、合成データ、契約テスト、CIを組み合わせれば、PDFやバラバラ仕様に泣かされることがぐっと減る。自治体の標準化政策（laws.e-gov、digital.go.jp）を技術的に支える現場のワークフローとして、モック＋合成データのテストベッドを作るのが現実的で効果的なんです。

おかむーから一言

現場でコードを書いてると、政策の“想定外”って本当に多いんですよね。だからこそ、リハーサル文化を行政にもってきましょう！小さく試して、大きく学ぶのが一番早いんです。