どうも〜おかむーです！今日は行政データの“出す側”をエンジニア視点で助ける話をしますよ〜

• この3行要約

- 行政が定めた「機械可読性ルール」の現場適用は手動運用だと破綻することが多い

- エンジニア的にはCI（継続検証）パイプラインで公開前バリデーションを回すのが最短解

- 具体的なチェック項目、簡易実装例、行政への運用提案まで提示するので現場で試してほしい！

結論

行政データの機械可読性を守るには“ルールを作る”だけで終わらせずに“公開ワークフローに組み込む”ことが鍵。エンジニア的に言うと、データの公開プロセスをCI化して、エラーを自動検出・可視化・差し戻しできる仕組みを各所に配備すれば再現性と利活用性が劇的に上がるんですよね。

レポート本文

背景と現状（これ見てくださいよ）

内閣官房やデジタル庁の動きで「機械可読性に関するルール」が示されてきてます（参照: デジタル行財政改革会議の資料や説明資料: https://www.cas.go.jp/...、https://www.digital.go.jp/...）

また、実際の公開例として notice.go.jp のお知らせCSV（https://notice.go.jp/docs/status_notice.csv）、環境省や総務省のCSV（https://www.env.go.jp/content/900398071.csv、https://www.soumu.go.jp/main_content/000323625.csv）といった生データが存在します。エンジニア的に見ると、公開方式やHTTPヘッダ、エンコーディング、日付フォーマット、メタデータの欠落が散見され、利用側での前処理負荷が高いんですよね。

要するに：ルールはあるけど“現場で守られているか”が重要ってことです。

現場でよくあるトラップ（技術的観点）

• 文字コードが混在（UTF-8/BOM、Shift_JISなど）→ パーサが落ちる
• Content-Typeやcharsetが未指定／誤指定 → 自動ダウンロード時の扱いがばらつく
• 日付・時刻の表記ゆれ（YYYY/MM/DD、YYYY-MM-DD、和暦）→ 集計ミス
• カラム名の表記ゆれ・順序不揃い → 上流で必要なキーがない
• メタデータ欠落（更新日、ライセンス、カラム説明）→ 再利用にハードル

エンジニア的な対処方針（CIパイプライン設計）

エンジニア的に言うと、これAPI一本で解決する話なんですよ。具体的には次の3フェーズ。

1) 事前チェック（ローカル／PR段階）

- エンコーディング検査（UTF-8であること、BOMの有無）

- HTTPヘッダ検査（Content-Typeにcharsetがあるか）

- CSV構文検査（RFC4180 準拠、カラム数の整合性）

- 必須カラムチェック（公開ルールで定めた必須フィールド）

- 日付正規化チェック（ISO8601でパースできるか）

2) 公開前テスト（CI実行）

- サンプル変換（CSV→NDJSONやJSON-LDへのサンプル変換）で機械可読性を実証

- メタデータ（data.json / DCAT）と実データの一致検証

- スキーマ互換性（前バージョンとの差分警告）

3) 運用モニタ（公開後）

- 定期的なエンドポイント検査（HTTPステータス、更新頻度チェック）

- 差分アラート（行数・主要カラムの異常変化をSLAとして監視）

実装例（軽めのコードでイメージを掴んでください）

エンジニアならわかると思うんですけど、GitHub Actionsを使えばPR時に自動で回せます。以下はチェックを呼ぶワークフローの雛形です。

name: data-lint
on: [pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Install deps
run: pip install pandas chardet python-dateutil
- name: Run data checks
run: python scripts/check_csv.py

check_csv.py（抜粋）のイメージ:

import chardet
import pandas as pd
from dateutil.parser import parse

path = 'data/status_notice.csv'
エンコーディング検査
with open(path, 'rb') as f:
raw = f.read(10000)
enc = chardet.detect(raw)['encoding']
assert enc and enc.lower().startswith('utf-8'), f'非UTF-8: {enc}'

CSV読み込みと日付チェック
df = pd.read_csv(path, dtype=str)
if 'updated_at' in df.columns:
for v in df['updated_at'].dropna().sample(min(10, len(df))):
try:
parse(v)
except Exception:
raise SystemExit(f'日付パース失敗: {v}')

要するに、公開プロセスのどの段階で自動テストを噛ませるかが重要です。ローカルでのミスはPR段階で止めて、公開ブランチへのマージはグリーンのみ許可する。これで現場の負担を減らしつつ品質担保できます。

政策運用の視点：数値目標と現場負荷のギャップ

政策的には「機械可読化を〇年までに全省で達成」といったKPIが掲げられることが多いです。でも要するに、現場のリソースがないと形式だけ揃えても使えないデータになる。CI化は最初の導入コストはかかるけど、長期的には運用コストを下げ、KPI達成を持続可能にする。

行政への現実的な提案

• 最低限の公共スキーマ（必須カラム、推奨型）を省庁横断で定める
• data.json（もしくはDCAT）を必須にしてメタデータを公開する
• 公開リポジトリにCIパイプラインのテンプレを用意して各部署に配布する
• 小さな成功事例（まずは1データセット）でROIを示しロールアウト

まとめ

• 機械可読ルールは「ガイドライン」だけだと守られない。公開ワークフローへ組み込むことが必須。
• GitHub Actions等のCIでエンコーディング、HTTPヘッダ、CSV構文、日付正規化、メタデータ整合性を自動検査すると現場負担が劇的に下がる。
• 政策面ではスキーマとメタデータの標準化、テンプレ化されたCI導入支援が効く。要するに“仕組みで守る”のがポイントです！

おかむーから一言

テクノロジーで行政をアップデートするには、現場の“やる気”を引き出す仕組みが必要なんですよね。CIを回して、エラーを怒られる仕組みじゃなくて直しやすくする仕組みに変えていきましょう！

参考リンク:

• NOTICE（お知らせCSV）: https://notice.go.jp/docs/status_notice.csv
• 環境省例: https://www.env.go.jp/content/900398071.csv
• 総務省全国CSV: https://www.soumu.go.jp/main_content/000323625.csv
• 救護施設CSV（厚労省）: https://www.mhlw.go.jp/content/001682075.csv
• デジタル行財政改革会議 資料: https://www.cas.go.jp/jp/seisaku/digital_gyozaikaikaku/kakusyoDX4/kakusyoDX4.html