どうも〜おかむーです！今日はちょっとカタログ横断でのオープンデータ発見性について、エンジニア視点でしゃべりますよ〜

• 主要な自治体カタログはCSV公開が多く、API化とメタデータの一貫性にバラつきがある
• カタログ間で同一データが重複・分散し、横断検索や再利用が面倒になっている
• 技術的にはクロール＋正規化パイプラインで現場の負担を減らせる、というのが結論です

結論

カタログは増えたけど“横断発見性”が追いついていない！エンジニア的に言うと、データはあるけどインデックス化と正規化が足りないんですよね。DCAT-AP準拠のメタ化＋軽量ハーベスターを自治体向けに標準化すれば、データの再利用が一気に進みます。

レポート本文

現状観察（実例から見る）

これ見てくださいよ。東京都オープンデータカタログ（https://catalog.data.metro.tokyo.lg.jp/dataset）や函館市のCSV一覧（https://www.harp.lg.jp/opendata/dataset/79.html）、新潟市のCSV作成マニュアル（https://www.city.niigata.lg.jp/.../csv_manual_v1.1.pdf）を眺めると、共通点と差分が見えます。

• フォーマットはCSV主体（CSVマニュアルも公開）で、APIを持つデータと単発ファイルの混在
• メタデータ項目（ライセンス、更新日、APIエンドポイント）がカタログ間で統一されていない
• RAIDAやデジタル田園都市関連のポータル（https://raida.go.jp/, https://www.chisou.go.jp/）は事例集として有用だが、個別カタログまで深掘りしにくい

要するに、データは散らばってるけど "探せる形" になっていないということです。

技術的課題（3つに整理）

発見性：スキーマ名やフィールド名が自治体ごとに異なるため横断検索でノイズが多い

メタデータ欠損：ライセンスや更新頻度が機械可読で欠けているケースが散見される

重複管理：同一データが複数カタログに存在してもIDで紐づいていない

実務的ソリューション（コードで語る）

エンジニア的に言うと、ここは「ハーベスト→正規化→照合→公開」のパイプラインで一気に解決できます。サンプルの小さなパイプラインを示します（Python）：

import requests, pandas as pd
from urllib.parse import urljoin

シンプルなカタログハーベスター
catalog_url = 'https://catalog.data.metro.tokyo.lg.jp/dataset'
r = requests.get(catalog_url)
実際にはHTMLパースかAPI呼び出しでdatasetメタを抽出
ここでは擬似コード化しています

メタ正規化のイメージ
records = [
{'title': '公共施設一覧', 'url': 'https://.../koto.csv', 'format': 'CSV', 'license': 'CC-BY'},
]
df = pd.DataFrame(records)
フィールド名を標準化
df = df.rename(columns={'title': 'dataset_title', 'url': 'access_url'})

要所は「メタデータのスキーママッピング」を作ること。DCAT-AP-JP相当のフィールドで正規化すれば、複数カタログをまとめて検索可能になります。

運用と品質担保

• CI的にメタ検証テストを回す（ライセンス有無、更新日形式、機械可読フォーマット）
• 永続ID（stable URI）とデータフィンガープリント（ハッシュ）で重複検出
• 自治体向けに軽量ライブラリ（harvester + normalizer）を提供して、現場のエンジニア負荷を下げる

まとめ

カタログは増えたけど、横断的に見つけて使うための“接着”が足りない。技術的にはハーベスター＋DCAT準拠の正規化、CIによるメタデータ品質保証で一気に改善できます。RAIDAやデジタル庁の施策（https://digital.go.jp/）と現場カタログをつなぐ“ミドル層”が肝心です。

おかむーから一言

テクノロジーで行政をアップデートするのは地味だけど超重要！まずは小さなハーベスター一つで現場の負担を下げて、使えるデータ基盤を作っていきましょう。僕も手伝いますよ〜