政府API、ただ公開するだけじゃダメだよね?運用・契約テストで信頼を作る技術設計

どうも〜おかむーです!今日は政府・自治体のAPI運用について、ちょっとエンジニア寄りに突っ込みますよ〜
- 行政が公開するAPI、数だけじゃなく「契約(contract)」と運用が大事
- OpenAPI・スキーマ・契約テストをCIに組み込むだけで現場の信頼性が激変する!
- 「公開 → 放置」を防ぐためのメトリクスと改善フローを提案するよ
結論
政府/自治体のAPIは“公開”して終わりにしない仕組み作りが肝心です。APIをプロダクトとして捉え、OpenAPI・バージョニング・契約テスト(consumer-driven contract)・SLO/監視をCI/CDで自動化すれば、データ利活用の導線が劇的に改善します。
レポート本文
現状観察:APIカタログはあるけど運用の粒度が足りない
これ見てくださいよ:e-Govの「行政API」カタログ(https://www.e-gov.go.jp/digital-government/api)や東京都のオープンデータAPI(https://portal.data.metro.tokyo.lg.jp/opendata-api/)が公開されてるんですけど、
- OpenAPI仕様の有無がまちまち
- スキーマ変更の履歴や互換性ポリシーが見えにくい
- 更新頻度・SLA・メンテ窓口が明記されていないケースが多い
要するに、APIは存在しているけど“契約”としての体裁が弱いということです。エンジニア的に言うと、APIはインターフェースの仕様(OpenAPI)+契約テスト+運用指標が揃って初めて使えるプロダクトになります。
技術的チェックリスト(導入の優先順)
- エンドポイント、パラメータ、レスポンス、例示JSONを定義
- 後方互換性の維持方針を明文化
- 利用者が期待するレスポンスをテスト化して、破壊的変更を防ぐ
- PRごとにOpenAPIの差分チェックを走らせる
具体的なコード例
curlで東京都の公開APIを叩く例(簡易):
curl -s "https://portal.data.metro.tokyo.lg.jp/api/PublicFacility" | jq '.[0]'
Pythonでスキーマ検証をする簡単な例(jsonschema使用):
import requests, json, jsonschema
resp = requests.get('https://portal.data.metro.tokyo.lg.jp/api/PublicFacility')
data = resp.json()
schema = {"type":"array","items":{"type":"object","properties":{"id":{"type":"string"},"name":{"type":"string"}}}}
jsonschema.validate(data, schema)
政策目標と実績のギャップ(定性的分析)
デジタル行政推進では「オンライン化・API化を進める」目標が掲げられてますが、現場では「APIは出したけど仕様変更や可用性の説明が無い」ために事業者が採用をためらうケースが散見されます。政策目標(API利活用の促進)と実績(実際の利用・二次利用の増加)のギャップは、可用性と仕様保証の欠如が主因と考えられます。
改善提案(即効性ある手順)
- APIカタログにOpenAPIファイルのURL、バージョン履歴、互換性ポリシー、問い合わせ窓口を必須フィールドにする
- CIに契約テスト(Pact/Dredd)を組み込み、schema-breakingなPRはマージ不可にする
- Prometheus + GrafanaでSLOを可視化、月次でSLOレポートを公開
- CSV/PDFでしか出ていないデータはまずAPIラップしてJSON化し、OpenAPIを発行する(変換レイヤーを用意するだけで活用が倍増します)
まとめ
APIは公開がスタートライン。仕様の明確化(OpenAPI)、契約テスト、バージョニング、監視をセットで運用することが、政策目標と現場活用のギャップを埋めます。これ、エンジニアなら直感的にわかるはずです!
おかむーから一言
テクノロジーで行政をアップデートするのはワクワクします。まずは小さなAPI一本を本気で運用してみてください。信頼はコードで作れるんです!
情報ソース
- https://www.zhihu.com/question/290714454
- https://metidx-gov.note.jp/n/n9468573c213b
- https://www.zhihu.com/question/6430289390
- https://www.trans-plus.jp/blog/column/202210_municipality-dx
- https://www.zhihu.com/question/38923279
- https://www.zhihu.com/question/40553450
- https://www.govtechtokyo.or.jp/services/data-utilization/
- https://www.zhihu.com/question/383506173
- https://note.govtechtokyo.jp/n/n77785a8254d6
- https://www.zhihu.com/question/372341437
- https://www.jichi.ac.jp/
- https://www.e-gov.go.jp/digital-government/api
- https://www.jichi.ac.jp/web_text/
- https://portal.data.metro.tokyo.lg.jp/opendata-api/
- https://www.jichi.ac.jp/library/
シェアする
関連レポート

公共予約システムの“ログインからAPI化”ロードマップ:パスワードレスで運用コストを下げる技術提案
公共施設予約の認証とデータを段階的にAPI化して運用コストを下げる技術ロードマップを紹介します。

政府データを“つなげる”発想:省庁バラバラを超えるフェデレーション戦略
フェデレーション層で省庁データをつなぎ、PDF混在を克服する実践的な技術案を示す。

政策ダッシュボードは“作るだけ”じゃダメ!KPIを自動で監査するパイプライン設計
政策ダッシュボードの数値を自動監査するパイプライン設計案。API・スキーマ・差分管理でKPIの信頼性を上げる技術手法を紹介します。