データの「誰のもの？」をコードで問う：基幹系標準化とデータ所有権の実務設計

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

• 行政システムの「標準化」は単なるソフト置き換えじゃない、データの所有権・アクセス設計まで含めて考える必要がある
• PDF→CSVの機械可読性は入り口に過ぎず、データ契約（schema + ACL）がないと再利用は進まない
• エンジニア的に言うと、標準化はAPI設計とデータガバナンスの両輪で進めるべき、でないとコストだけ残る！

結論

政府・自治体の基幹業務システム統一（デジタル庁・総務省の動き参照: https://www.digital.go.jp/policies/local_governments, https://www.soumu.go.jp）は、ただソフトを揃えるだけでは効果が出にくいです。要するに「誰がどのデータをどの条件で使えるか」をコード（API / RBAC / RLS / Schema）で明示し、CIで検証する体制を作れば初めて運用コスト削減と利活用が両立します。

レポート本文

背景と現状（公式ドキュメントから拾う）

デジタル行財政改革や機械可読性ルール（例: デジタル庁の機械可読性に関する資料 https://www.digital.go.jp/assets/.../20260331_meeting_executive_outline_06.pdf）は、フォーマットや公開ルールを前提にしています。でもこれ、"フォーマット標準"だけだと不十分なんですよね。

これ見てくださいよ：公開フォーマットがCSVになっても、

• カラム名が自治体ごとにバラバラ
• アクセス制御がドキュメントにしか書かれていない
• そもそもどの業務システムのどのテーブルから来ているかトレーサビリティがない

これだとデータを信頼して組み合わせることが難しいんです。

問題を技術的に分解する

データ所有権の不明確さ

- 誰がマスターを更新できるか、APIで明示されていない

アクセス制御の欠如

- 管理者ログや行レベル権限制御（RLS）が未整備

スキーマの不統一

- JSON Schema / OpenAPI で契約化されていない

運用で壊れるCI不足

- 取り込む側で毎回ハンドリングコードを書かせるのは非効率

実務的な検証・監査のレシピ（コード例つき）

エンジニア的に言うと、まずは自動監査パイプラインを回すべき。ここに簡単なチェックの例を示します。

• 1) 公開エンドポイントの形式チェック（curl + jq）

# APIがJSONを返すか確認
curl -sS 'https://example-municipality.gov/api/residents' -H 'Accept: application/json' | jq . >/dev/null
if [ $? -eq 0 ]; then echo "JSON OK"; else echo "非JSONレスポンス"; fi

• 2) CSV/PDFの機械可読性判定（Python）

from mimetypes import guess_type
mime, _ = guess_type('report.csv')
print(mime)  # text/csvなら機械可読

• 3) スキーマ検証（pandera / jsonschema）

import pandas as pd
import pandera as pa

schema = pa.DataFrameSchema({
'resident_id': pa.Column(int),
'address': pa.Column(str),
'updated_at': pa.Column(pa.DateTime)
})
df = pd.read_csv('residents.csv')
schema.validate(df)

• 4) 行レベルセキュリティ（Postgresの例）

-- 要するに、部署ごとに見える行を制限するということです
CREATE POLICY dept_policy ON residents FOR SELECT USING (dept_id = current_setting('app.dept_id')::int);
ALTER TABLE residents ENABLE ROW LEVEL SECURITY;

KPIと実績のギャップを測る方法

政策側は「標準化・ガバメントクラウド移行で運用経費削減」を掲げています（資料: https://www.digital.go.jp/policies/local_governments）。じゃあ実際に減っているか？を測るには次の指標が現実的です：

• 標準APIを公開する自治体数 / 総自治体数
• 機械可読データ（CSV/JSON）を持つAPIの割合
• 同一業務データに対するAPI呼び出しレイテンシとエラー率（可観測性）

これらは公開カタログとAPIヘルスチェックで自動収集できます。作り方は上述のcurl/jqを自治体一覧に投げるだけ。要するに自動で"健診"するわけです。

改善提案（コードで落とす）

• データ契約（JSON Schema / OpenAPI）を中央リポジトリで管理し、自治体側はそれをForkして実装するフロー
• CIでの検証：Schema検査、アクセスポリシーテスト（認可のテスト用トークンでのアクセス確認）
• 監査ログとトレーサビリティ：各APIレスポンスにソースID（system_id, table_id, snapshot_id）を付与
• 変更管理：schema changeをPull Requestで扱い、自動的に互換性テストを回す
• 小さな成功体験を増やすために、国がテンプレートAPI（OpenAPI spec + auth + RLS sample）を提供する

まとめ

標準化はフォーマット合わせだけじゃだめで、データの"だれが・どう使うか"をコード化することが本丸です。API＋JSON Schema＋RLS＋CIをセットにして初めて効果が出る。デジタル庁や総務省の資料は良い出発点だけど、実装の約束事（データ契約）を現場レベルで落とし込む仕組みが不可欠です。

おかむーから一言

テクノロジーは約束事を守らせる道具。コードでルールを書いて、ルールで信頼を作る。やってやりましょう、って感じです！

参考資料

• デジタル庁：地方公共団体の基幹業務システムの統一・標準化 https://www.digital.go.jp/policies/local_governments
• デジタル行財政改革会議（機械可読性） https://www.cas.go.jp/jp/seisaku/digital_gyozaikaikaku/kakusyoDX4/kakusyoDX4.html
• 機械可読性に関するルール案（PDF） https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/256dcba6-b936-4031-b88d-3abb27e27f9b/f7af0ca4/20260331_meeting_executive_outline_06.pdf