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

• 3行要約

- 日本の公的データはJapan Dashboardやe-Statなど良い表層があるけど、形式とスキーマがバラバラで横断利用が面倒なんですよね

- エンジニア視点だと「フェデレーテッド・クエリ層＋スキーマ・マッピングレシピ」で解決できることが多いです

- PDFや表組みExcelを救う抽出/標準化ルートと、運用のためのメタデータカタログが鍵です

結論

国が示す「行政データの機械可読性ルール（案）」やJapan Dashboard、e-Statは重要な基盤です（参照: デジタル庁、内閣官房、e-Stat）。ただ、現場はフォーマットとスキーマのばらつきで実践的な横断分析にコストがかかりすぎる。だからこそ、中央で全部を移植するんじゃなくて「フェデレーション（仮想レイヤ）」を作って、各データ提供側は自分の出力を守りつつ横断クエリを可能にする仕組みが現実的だ、というのが結論です。

本文：技術検証と実践案

今の状況（これ見てくださいよ）

• デジタル庁や内閣官房は機械可読性ルールを提示してます（例：機械可読のレベル1〜の定義、Excel/CSV推奨）[参照: digital.go.jp, cas.go.jp]。
• 一方で現場ではPDFやレイアウト固定のExcel、項目名が非標準、更新頻度が不明瞭というケースがまだ多い。
• e-StatやJapan DashboardはビジュアライズとAPIを提供しているけど、全省庁のスキーマ整合は済んでいない。

要するに、ルールはあるけど運用と横断利用のための『橋渡し層』が足りないということです。

技術的アプローチ（上流から下流まで）

メタデータカタログ（必須）

- DCAT互換のカタログを各自治体・省庁で公開

- カラム説明、更新頻度、ライセンス、プロヴェナンス情報を標準化

- 既成ツール：DataHub / Amundsenなどをカスタム運用

フェデレーテッド・クエリ層（中核）

- TrinoやPrestoのような分散SQLエンジンで仮想テーブルを作る

- 各公開API / 公開CSV / データベースをコネクターで接続

- スキーマ差を吸収する“マッピングレシピ”を配置

スキーマ・マッピングレシピ

- 例：{ "population_total": ["総人口", "人口_合計", "total_pop"] }

- マッピングはJSON-LDやYAMLで管理。これを使ってGraphQLの1つのスキーマへマージ

- 要するに、いろんな名前の列を“同義語辞書”で吸収する仕組みです

PDF / 非構造データ対策

- Tabula/Camelot + Tesseract（OCR）でテーブル抽出→ETLで正規化

- 抽出結果には信頼度メタ（confidence）を付ける。自動抽出だけに頼らず人手レビューのワークフローを用意

品質検査（軽量なガバナンス）

- Great Expectationsでスキーマ準拠テストを定義

- データ更新時に自動でスコアを算出し、カタログに表示

具体的なコード例（イメージ）

• フォーマット判定と簡易スコアリング（Python）

import mimetypes

def format_score(path):
mime, _ = mimetypes.guess_type(path)
if mime in ("text/csv","application/vnd.ms-excel","application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"):
return 1.0
if mime == 'application/pdf':
return 0.3
return 0.1

使い方: score = format_score('https://example.gov/data.csv')

要するに、CSV/Excelなら高め、PDFは低めのスタート。ここに更新頻度やメタデータ有無を掛け合わせれば合成スコアが作れます。

• フェデレーション向けGraphQLスキーマ（抜粋）

type Population {
jurisdiction: String!
year: Int!
population_total: Int
}

リゾルバ側で各省庁APIを叩き、マッピングレシピでフィールドを埋める

運用上のポイント

• マッピングレシピはコミット可能なコード（Git）で管理して、変更履歴を残す
• メタデータ更新とスキーマ適合チェックをセットにして、担当者にフィードバックを返す運用フローを作る
• 初期はパイロット自治体数県で実証し、成功パターンをテンプレ化する

政策との整合と期待される効果

• 内閣官房のデジタル田園都市戦略やデジタル庁の方針は、ローカルの個性を生かしつつ横断連携を求めている（参照: cas.go.jp, digital.go.jp）。このフェデレーション戦略は、地方ごとの公開ルールを侵さずに横断分析を可能にする方法です。
• 期待効果：データの再利用時間短縮、分析コスト削減、政策効果の定量比較がしやすくなる

具体的な短期アクションプラン（6ヶ月スプリント）

• 1ヶ月目：関係省庁・自治体のデータソースをリスト化（Japan Dashboard / e-Stat含む）
• 2〜3ヶ月目：メタデータカタログのPoCを立てる（DCAT + DataHub）
• 4ヶ月目：Trinoで2つのソースをつなぎ、簡単な横断クエリを作成
• 5〜6ヶ月目：PDF抽出パイプラインと品質ルールを追加、運用ドキュメント化

まとめ

• フェデレーテッドな中間層を作るのが現実解。全てを標準化するより早く、かつ現場の負担を抑えつつ横断利用を実現できる
• メタデータ、マッピングレシピ、抽出パイプライン、品質チェックが4本柱
• エンジニア的に言うと、これはまさに“抽象化レイヤ”の導入で、APIやCSVの違いを隠蔽して上流のアプリや政策分析にフォーカスさせるための仕組みです

おかむーから一言

テクノロジーで行政をもっと使いやすくしたい！小さく繋いで大きく動かす、この発想が今の日本に必要だと思ってます。まずは1県のPoCから始めましょうよ〜