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

• 3行要約

- 政府・自治体のCSVやPDFはドメインをまたいで散らばっていて、メタデータ不足で使いにくいです

- エンジニア視点だと「自動収集→正規化→バリデーション→カタログ化」のパイプラインでほぼ解決できます

- フリクショレス(Data Package)、JSON Schema、データカタログ(DCAT/CKAN)を組み合わせるのがおすすめです

結論

公開データの本質的な課題はフォーマットよりも「発見性」と「機械判別できるメタデータ」の欠如なんですよね。エンジニア的に言うと、API一本で解決できる話もあるんですが、現実はCSVやPDFが散らばっている。だからまずはフェデレーテッドなハーベスター＋Data Packageによる正規化を導入して、CIで品質ゲートを通す運用を作るのが最短です！

レポート本文

現状観察：これ見てくださいよ

検索で見つかる実例を見てみると、公開データはこんな感じです。

• notice.go.jp の NOTICE注意喚起: https://notice.go.jp/docs/status_notice.csv
• 環境省のCSV（例）: https://www.env.go.jp/content/900398071.csv
• 総務省の全国CSV: https://www.soumu.go.jp/main_content/000323625.csv
• 内閣官房の資料(PDF)で「機械可読性が重要」と明記: https://www.cas.go.jp/jp/seisaku/digital_gyozaikaikaku/data8/data8_siryou1.pdf
• デジタル庁の取り組み紹介: https://digital-gov.note.jp/n/neb45f4883f23

これ見てくださいよ。ファイルはあるけど「ライセンス」「スキーマ」「更新履歴」が人間向けしかないケースが多いです。要するに、機械に読ませようとすると問題が山積みということです。

主な課題

• 発見性が低い：同じ内容でもドメインやディレクトリがバラバラ
• メタデータ欠如：ライセンスやカラム定義が埋め込まれてない
• フォーマットのばらつき：一部がShift_JIS、日付フォーマットが混在
• バージョン管理がない：差分や改訂履歴が追いにくい

技術的な処方箋（アーキテクチャ）

エンジニア的に言うと、解決はパイプライン化すれば楽です。提案アーキテクチャ：

ハーベスター（Crawler）

- 各省庁ドメインとCSV/PDFエンドポイントを定期クロール

- sitemap、robots、HTMLメタから候補を抽出

正規化（Normalizer）

- frictionless-pyでCSVをData Packageに変換

- 文字コードUTF-8へ正規化、日付はISO8601へ

バリデーション

- JSON Schema + profile checks（数値範囲、必須カラム）

- 灰色リスト（例：欠損が多すぎる場合はアラート）

ストレージ

- Parquetで長期保存、S3互換ストレージ推奨

- メタデータはDCAT互換のカタログに格納

API & カタログ

- CKANやData Catalog APIで検索可能に

- OpenAPIでデータAPIを表現

運用

- Git-based data registry（データの差分はDVCやLakeFS）

- CI（GitHub Actions等）でバリデーション自動化

具体的コード例（簡易ハーベスト→検証→Data Package生成）

import requests
from frictionless import Table, Package, Resource

url = 'https://notice.go.jp/docs/status_notice.csv'
r = requests.get(url)
r.encoding = 'utf-8'
open('status_notice.csv','w',encoding='utf-8').write(r.text)

frictionlessで検証
table = Table('status_notice.csv')
print('headers:', table.header)

Data Package作成
resource = Resource(path='status_notice.csv', name='notice_status')
package = Package(resources=[resource])
package.to_descriptor('datapackage.json')

要するに、このくらいのコードで初動は回せます。フリクショレスはカラムの型推定や検証にも使えるので便利です。

チェックリスト（実務で入れるべき自動テスト）

• 文字コード utf-8 であること
• ライセンスがSPDXタグで明記されていること
• カラムごとの JSON Schema があること
• 更新時に必ず revision+timestamp を残すこと
• KPI系はフォーマット（%か整数か）を統一すること

具体的改善案：メタデータと公開フロー

• 公式カタログはDCAT形式でエクスポート（省庁横断で検索可能に）
• 各CSVは必ず datapackage.json を同一ディレクトリに置く運用を必須化
• データの変更は Pull Request ベースで行い、CIでテストを強制
• ライセンスは単一のSPDXコードで明示（例: CC-BY-4.0）

まとめ

• 現場はデータはあるけど機械に使わせる体裁が整ってないケースが多いです
• 対応は技術的に難しくない：クロール→正規化→バリデーション→カタログ化で劇的に改善します
• frictionless/Data Package、JSON Schema、DCAT、CIを組み合わせる運用が現実的で効果大です

おかむーから一言

テクノロジーで社会をアップデートするって言うけど、まずはデータをちゃんと見つけて、機械が読める形にすることが最短です！エンジニアならこのワークフロー作るだけで社会に価値出せますよ〜