どうも〜おかむーです！今日は行政の申請フォームや公開データの“入口”に注目して、エンジニア視点で政策データの品質を検証しますよ〜

• 申請フォームの設計不備が、政策KPIの測定をゆがめている
• フロントでのバリデーション／フォーマット不一致がCSVやAPIに伝播する具体例
• 実装で防げる改善案（JSON Schema・IDempotency・監査ログ・ETL監視）を提示

結論

フォーム設計と入力パイプラインがまずければ、どれだけ良いダッシュボードを作っても“嘘の数字”になりがちです。要するに、UI/UXとデータ工学をつなぐ実務的な契約（schema-first）を自治体レベルで標準化するのが最もコスパ良い改善策です。

レポート本文

何が問題か？これ見てくださいよ

地方自治体の公開データ（例えば東京都オープンデータやe-GovのAPIカタログ）は存在します（参考: https://portal.data.metro.tokyo.lg.jp/ 、https://www.e-gov.go.jp/digital-government/api）。ただ、実務では「申請フォームは別システム」「公開用CSVは手作業で作成」「元はPDFで受け取る」といったフローが多いんですよね。要するにデータの型・正規化・エンコーディングが壊れたまま公開される。

影響例:

• 日付フォーマット混在（YYYY/MM/DD と YYYY-MM-DD と 和暦）→ 集計がバグる
• 同一の概念に対する複数コード（free-textで「女性」「女性（妊婦）」など）→ 自動分類が壊れる
• 途中のPDF化・手入力で欠損が発生 → KPIの分母が小さく見える

技術的にどう検証するか

エンジニア的に言うと、まずは「入力契約（Input Contract）」を明文化して自動テスト化するべきです。

JSON Schemaでフォームの契約を定義

フロントで同一Schemaを使ったバリデーション（ライブラリ共有）

サーバー側でも同Schemaで再検証（信頼境界）

ETLで型チェックと監査ログを残す

コード例（JSON Schemaの抜粋）:

{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "ChildcareWaitingRegistration",
"type": "object",
"properties": {
"applicant_id": {"type": "string"},
"birth_date": {"type": "string", "format": "date"},
"desired_start": {"type": "string", "format": "date"},
"care_level_code": {"type": "string", "enum": ["0","1","2","3"]}
},
"required": ["applicant_id","birth_date"]
}

データ受け渡しのcurl例（e-GovのAPIに似せた想定）:

curl -X POST https://api.metro.tokyo.lg.jp/childcare/waiting \
-H 'Content-Type: application/json' \
-d @registration.json

ETL側のチェック（pandasで型強制）:

import pandas as pd
df = pd.read_csv('waiting_raw.csv')
日付を統一
df['birth_date'] = pd.to_datetime(df['birth_date'], errors='coerce')
欠損率の監視
missing = df.isnull().mean()
print(missing[missing>0])

PDF vs CSV の問題もちゃんと見る

PDFで受け取ったり公開したりする運用はまだ多いです。PDFは人間には良いけど機械的には最悪。要するにPDFはロスの温床です。可能なら入力段階から機械可読（JSON/CSV/JSONL）を採用し、PDFは最終的なレポート出力に限定すべきです。

KPIとデータのギャップをコードで見つける

例えば「保育所待機児童ゼロ」を目標にするなら、申請ベースと実績ベースで異なる定義がないかをコードで照合します。具体的には：

• 申請DBのステータス定義と公開統計のステータスマッピングを明文化
• 週次で差分レポートを自動生成（SQL + CIで検出）

SQL差分例:

SELECT date, count(*) as raw_applications FROM applications
WHERE status IN ('applied','pending')
GROUP BY date;

比較用に公開CSVを読み込んで差分アラートを出すパイプラインを組めば、運用ミスを早期に検出できます。

政策運用への提案（実装ロードマップ）

フォーム設計をschema-firstで共通化（JSON Schema/OpenAPI）

ライブラリ共有（フロント+バックで同一validation）

入力イベントに一意IDとidempotencyを付与して重複/欠損を防止

ETLにデータ品質チェック（completeness, uniqueness, format）を組み込む

品質メトリクスをダッシュボード化（エラー率・欠損率・変換失敗率）

まとめ

フォームは単なるUIじゃなくて、政策データの第一線です。ここをちゃんと設計すれば、政策評価の信頼性が格段に上がります。要するに「見た目良ければOK」ではなくて「見た目＋データ契約」が必要って話です。

おかむーから一言

スタートアップやってきて感じるのは、仕様書をちゃんとコードにするチームが強いってこと。行政でも同じで、仕様（schema）をコードに落とし込めばムダが減るし、市民にも優しいサービスになりますよ！