CSVだけじゃ足りない!公開データの運用設計をコードで担保する話

IT政策の提案
CSVだけじゃ足りない!公開データの運用設計をコードで担保する話

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

  • 公開されているCSV(例: https://notice.go.jp/docs/status_notice.csv や https://www.env.go.jp/content/900398071.csv)を実際に触って、運用課題を探ってみた
  • データ公開は“出すだけ”で終わっているケースが多く、スキーマと運用の設計が抜けているのが原因
  • エンジニア的には、Schema+CI+バージョン管理で一気に信頼性が上がる!具体策を示す

結論

公開データはフォーマット(CSV)だけでなく「スキーマ」「バージョン」「配信API」「検証パイプライン」をセットで運用しないと現場は使えない。要するに、データをコードで扱う前提に作り変えるべき、ということです。

レポート本文

なぜ今これを言うのか

これ見てくださいよ。総務省が示す機械判読ルール(https://www.soumu.go.jp/menu_news/s-news/01toukatsu01_02000186.html)や、政府の公開CSV群(Noticeや環境省、厚労省のCSVなど)があるんですけど、単にファイルを置いただけで「使える」状態になっているとは限らないんです。

エンジニア的に言うと、ファイル単位の公開は『オブジェクトを手渡す』しかしていない。これだとスキーマの変化に弱いし、自動化も進まないんですよね。

現場でよく見る問題(事例ベース)

  • 文字コードがバラバラ(UTF-8期待なのにShift_JISで来る)
  • ヘッダ名が頻繁に変わる/単語の揺れ(例: "pref" と "prefecture")
  • メタデータ(説明・更新日時・ライセンス)が欠落
  • ファイル置き場にしかないため差分取得が非効率

要するに、機械可読性ルールはあるものの、運用が追いついてないんです。

技術的な改善提案(ステップバイステップ)

  • スキーマ定義を作る(JSON Table Schema / frictionless Data Package)
  • - 例: schema.jsonに各列の型、必須フラグ、許容値を明記

  • CIで差分とバリデーションを回す
  • - 新しいCSVが上がったらGoodtablesやfrictionlessで自動検証

  • バージョン付き配信を行う(/v1/, /v2/)とETag/Last-Modifiedの導入
  • APIゲートウェイでレコード単位の取得を可能にする(OpenAPI準拠)
  • メタデータとカタログ化(DOIやデータカタログ連携)
  • 具体的なコード例(Python: フェッチ→検証→変換)

    import requests
    

    import pandas as pd

    from frictionless import Schema, Table

    url = 'https://notice.go.jp/docs/status_notice.csv'

    r = requests.get(url)

    r.encoding = 'utf-8'

    with open('status_notice.csv','w',encoding='utf-8') as f:

    f.write(r.text)

    df = pd.read_csv('status_notice.csv')

    print(df.head())

    frictionlessでschemaチェック(例)

    schema = Schema.from_descriptor('schema.json')

    Table('status_notice.csv', schema=schema).validate()

    要するに、スキーマをコード化してCIで守るのがポイントです。

    APIがあるかどうかの評価ポイント

    • エンドポイントはあるか(CSVだけかAPIか)
    • 差分取得(incremental)が可能か
    • メタデータ(更新日時・由来・ライセンス)が付いているか

    今の公開状況は「CSV直置き」が多く、APIが無い・差分取得が困る、という問題が頻出。ここを埋めると再利用が格段に増えます。

    政策評価への応用

    政策のKPIや実績は数字だけ出されても追跡辛いです。CSVに以下を付与しましょう: 原データID、集計SQL(またはクエリ)、更新履歴。これで「数値の由来」がコードでトレースできます。

    まとめ

    • 出すだけのCSV公開は限界。スキーマ・バージョン・API・CIをセットにするべき
    • 実務ではfrictionless/JSON Table Schema、Goodtables、OpenAPIあたりを組み合わせるのが現実的
    • 政策の透明性はデータの可検証性で決まる。コードで担保しよう!

    おかむーから一言

    テクノロジーって、ルールをちゃんと作れば人の手間を劇的に減らせるんですよね。データに責任を持たせるために、コードでガバナンスを作っていきましょう!

    シェアする