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

• 오픈데이터, PDF 지옥에서 CSV·API로 바꾸는 게 핵심이다
• 표준·클라우드·UX가 맞물려야 시민이 실제로 데이터를 쓸 수 있다
• 개선안은 기술 스택·거버넌스·계량지표까지 세트로 제안한다

結論

이 글의 핵심은 단순합니다: 행정이 "데이터를 공개했다"는 사실만으로는 충분하지 않다! PDF에 갇힌 통계, 비표준 포맷, API 부재는 재사용을 막는 진짜 장벽이에요. 엔지니어적으로 말하면 "머신 리더블 + 명세화된 API + 자동화된 데이터 파이프라인"이 없으면 실용적 오픈데이터가 아니다. 총무성(https://www.soumu.go.jp/)과 디지털청(https://www.digital.go.jp/)의 정책방향은 맞는데, 현장 적용에서 파일 포맷·운영요건·UX가 따르지 못하는 경우가多いんですよね〜

레포트 본문

현재상태: 무엇이 문제인가

これ見てくださいよ。総務省のオープンデータ推進資料(https://www.soumu.go.jp/menu_seisaku/ictseisaku/ictriyou/opendata/)やデジタル庁の事例(https://www.digital.go.jp/resources/data_case_study_private)を見れば方針は出てるんですけど、現場の公開はPDF・表組み画像が多い。要するに、機械が読めない形で公開されてるってことです。

具体的に問題点を技術的に整理すると:

• PDFや散在するExcel: 테이블 추출이 불안정해서 데이터 파이프라인을 만들기 어려움
• スキーマ不在: カラム名・単位・更新頻度が明示されない
• API未整備またはドキュメント不十分: 認証方式やレスポンス仕様がバラバラ
• 地理情報の非標準化: GeoJSON/GMLではなく座標をばらばらに持っているケース
• ライセンス曖昧: 二次利用ルールが明確でない

データ品質・ガバナンスのチェックリスト（エンジニア視点）

• 機械可読性: CSV/JSON/GeoJSONがあるか
• API: REST/GraphQLの有無、OpenAPI仕様の提供
• メタデータ: スキーマ、更新日時、担当部署、ライセンス
• ID: 各エンティティに永続IDが振られているか
• テスト: データ検証（型、レンジ、欠損）を自動化しているか

実例コード: PDFテーブル vs CSV

まずはPDFに埋まってるテーブルをスクレイピングしてCSVに変える簡単な例。コード書く人ならわかると思うんですけど、タスクは2段階です: 抽出 → 正規化。

# tabula-pyを使う例（Javaが必要です）
import tabula
import pandas as pd

PDFからテーブルを抽出してDataFrameに
dfs = tabula.read_pdf('municipal_report.pdf', pages='all', multiple_tables=True)
単純にconcatして整形
df = pd.concat(dfs, ignore_index=True)
カラム名・単位を正規化
df.columns = ['facility_id', 'name', 'lat', 'lon', 'count']
CSVに保存
df.to_csv('municipal_facilities.csv', index=False)

でも正直、これは脆弱です。ページレイアウトが変わると壊れます。だから理想は最初からCSV/JSONで公開してもらうことなんですよね〜

APIの理想設計（ミニ提案）

• エンドポイント例: GET /api/v1/facilities?bbox=lngmin,latmin,lngmax,latmax
• レスポンス: JSON+GeoJSONフィーチャーコレクション
• ドキュメント: OpenAPI 3.0 を提供、サンプルクエリを明記
• 認証: 公開データは無認証でOK、アクセス制限が要る場合はAPIキー

curlで呼ぶ例:

curl "https://data.city.example.gov/api/v1/facilities?city=tokyo" -H "Accept: application/json"

データパイプラインとCI

運用面ではこういう仕組みが必要です:

• ETL自動化: GitOpsスタイルでデータパイプラインをコード化（Airflow / Prefect）
• バリデーション: Great Expectationsでスキーマ検証をCIに組み込む
• リリース: CSV/JSONをデータポータル（CKAN等）に自動登録
• モニタ: 更新失敗・異常をSlackやOpsチームに通知

標準化とクラウド移行の意義

地方自治体の基幹業務システム標準化・ガバメントクラウド移行は重要課題です（参考: デジタル庁資料 https://www.digital.go.jp/policies/local_governments）。

要するに、レガシー分散を放置するとデータ設計もバラバラで、API一本統合しても下流の整備が追いつかないんですよね。クラウド移行で得られる利点:

• 共通の運用基盤でCI/CDやログ収集を統一
• 標準ミドルウェアでセキュリティ・バックアップを簡素化
• データレイク/カタログで検索性を向上

ただし移行は技術だけじゃなく、人と契約・SLAの設計が鍵です。

政策目標 vs 実績のギャップ分析（例）

政策として「2025年までに主要データを機械可読で公開」といった目標が出ることがあります（計画値）。でも現場の公開状況をランダムサンプリングしてみると、公開率は目標を下回るケースが多い。原因は:

• 工数の見積り不足（PDF→機械可読化は想像以上に手間）
• 担当者のスキル不足（データモデリング経験がない）
• 法務・権利関係で公開を渋るケース

定量化するには、公開データの「機械可読率」「API提供率」「更新頻度準拠率」をKPI化して月次で公開するのが良いです。

UX와 시민 활용성

データがあるだけじゃダメで、サービスへの繋ぎ込み（位置情報検索、洪水リスク可視化など）が重要。METIやデジタル庁のUI/UXガイドラインを参考に、使いやすい検索UIとAPIサンプルを同梱すると採用率が上がります（参考: https://www.digital.go.jp/policies/servicedesign/government-system-ui）。

実装優先度リスト（短期〜中期）

CSV/JSONでの再公開 + ライセンス明示（短期）

OpenAPI仕様の用意 + サンプルコード提供（短期）

ETL自動化・テスト導入（中期）

データカタログ/CKANとGovCloud統合（中期〜長期）

KPIの公開とPDCA（継続）

まとめ

正直、ここは改善の余地ありまくりだと思ってます！オープンデータは単に公開するだけじゃ意味がない。エンジニア的に言うと、API一本で解決する話なんですよね、でもその前段でスキーマ設計、データ品質、運用自動化が必要。総務省やデジタル庁の方針はあるけど、現場適用のためのツールとスキル、そして計測指標をセットで整備することが最重要です。

おかむーから一言

テクノロジーで行政をアップデートするのは夢じゃないです。小さなCSV一枚が、市民の利便性を劇的に変える。まずは一つ、CSVで公開してくれたらめっちゃ助かりますよ〜！