ドメインとインフラで語るオープンデータ流通論 — コードで見つける再利用のボトルネック

どうも〜おかむーです！今日はちょっとインフラ寄りのGovTechネタを持ってきましたよ〜エンジニア的に言うと、データが公開されてても“どこにあるか・どう取りに行けばいいか”が微妙だと再利用は始まらないんです。

• ドメイン・TLS・sitemapなどインフラ設計はデータ流通性に直結する
• ローカル自治体のドメイン多様性が機械利用の壁を作っている
• 数行のチェックコードで可視化→簡単な運用ルールで改善可能

結論

ドメイン命名規則、TLS運用、sitemap/robots、MIME・CORSといった“インフラ周辺”が整えば、オープンデータの再利用率はぐっと上がる。要するに政策はデータを出すだけじゃなく「取りに行きやすく」する運用をセットで設計することが肝心です。

現状観察：ドメイン多様性と機械可読性のミスマッチ

これ見てくださいよ、都市や府県で使われるドメインは go.jp / lg.jp / city.*.lg.jp など様々です（例: 都のオープンデータは catalog.data.metro.tokyo.lg.jp にまとまってます）。一方でコンテンツがPDFに埋め込まれていたり、CSVが散在していたり、sitemapが無いサイトも多いんですよね。

要するに、ドメインやサブドメインの設計がバラバラだとクローラーや自動化スクリプトで拾いにくくなる、ということです。

具体的に困る点

• サブドメインごとに証明書の運用がバラバラでHTTPSの品質が不均一
• robots.txtやsitemap.xmlが無い、あるいは誤設定でクロール除外される
• MIMEヘッダが適切でない（CSVが text/html で返るなど）
• CORSが無くブラウザ経由のAPI利用が面倒

エンジニア的チェック（実践コード）

ここはコード書く人ならわかると思うんですけど、まずは自動で状況を拾うスクリプトを用意しましょう。例を2つ。

1) TLS情報を取る（shell / openssl）

openssl s_client -connect catalog.data.metro.tokyo.lg.jp:443 -servername catalog.data.metro.tokyo.lg.jp < /dev/null | openssl x509 -noout -dates -issuer -subject

2) sitemapからCSVリンクを見つける（Python）

import requests
from bs4 import BeautifulSoup
r = requests.get('https://catalog.data.metro.tokyo.lg.jp/sitemap.xml')
soup = BeautifulSoup(r.content, 'lxml-xml')
urls = [u.text for u in soup.find_all('loc')]
csvs = [u for u in urls if u.endswith('.csv')]
print('CSV count', len(csvs))

さらに、コンテンツタイプチェック：

curl -I https://example.city.lg.jp/path/to/data.csv

Content-Type: text/csv; charset=UTF-8 ← これが欲しい

政策目標と実績の“測り方” — ギャップ分析の技術

政策側で「オープンデータ化率○%」という目標があるなら、まずは機械で検証できるメトリクスを定義します。例：

• データ形式比率（CSV/JSON/Excel/PDF）
• APIエンドポイント保有率（OpenAPI/spec.jsonの有無）
• TLS健全度（証明書期限・チェーン・TLSバージョン）
• 発見性指標（sitemap有無、robots有無）
• ライセンス明示率（SPDX/機械可読ライセンス）

上のPythonスニペットをカタログのエンドポイントに走らせれば、CSV比率やAPI保有率は数分で出せます。実績が目標に届かない部分は技術的負債と見做して対応計画を立てる、という流れがいいですね。

改善提案：実装可能なTech Roadmap

具体的で簡単に始められる施策を並べます。

ドメイン設計ルール

• データ専用サブドメインを定義（例: data.pref.tokyo.lg.jp）
• ワイルドカード証明書とACME自動更新を採用

機械可読な公開ポイント

• sitemap.xml + robots.txt の整備
• /.well-known/openapi.json または /datasets.json（DCAT/JSON-LD）を配置
• HTTPヘッダに Link: ; rel="license"

運用ヘルスチェック

• 定期的に上記スクリプトをCIで実行してステータス公開
• TLS・DNSのモニタリング（DNSSEC / CAA の設定）

配信品質

• 正しい Content-Type 設定（text/csv, application/json）
• CORSを適切に許可してフロント/CLIからの利用を容易に

サーバ設定例（Nginxでの基本ヘッダ付与）:

``nginx

add_header Link "; rel=license";

add_header Access-Control-Allow-Origin "*";

`

実務上の落とし穴と回避策

• PDF文化はすぐには無くならない → PDFは必ず機械版（CSV/JSON）を付ける運用にする
• サイト運営が分散している自治体では中央リポジトリを用意して仲介する（GovTech的な集約）

まとめ

ドメインやTLS、sitemapといった“インフラの細部”がデータ利活用の成否を決める。コードで自動チェックして可視化し、簡単な運用ルール（サブドメイン規約、証明書自動更新、JSON-LD/Linkヘッダ）を回すだけで再利用性は大きく向上するんです！

おかむーから一言

テクノロジーは細部で差が出る。ドメインとインフラに少し手を入れれば、データはもっと活きる。さぁ、まずは一行のスクリプトを走らせよう！