公告・通知データを“パイプラインで読む” — 公共通知の機械可読化と横断検索の技術設計

どうも〜おかむーです!今日はちょっと通知・公示データのエンジニア目線での話をしますよ〜
- データ源は notice.go.jp の CSV や各府省の公開資料(PDF/CSV)が混在している
- 機械可読性ルール(内閣府の決定)は出たけど現場はPDF優勢でつながりづらい
- エンジニア的には「正規化→スキーマ化→差分追跡→API公開」で勝負できる!
結論
現行の公告・通知の流通は「人間向けPDFが中心→CSVやAPIが散在」していて、政策の検証や横断検索に弱いです。要するに、まずは横断的な正規化スキーマと差分追跡の仕組みを作れば、公開頻度・更新遅延・政策連関といったKPIを実際に計測できるようになります。具体的には、notice.go.jp の CSV を起点にスキーマを定義し、各府省のPDFを自動抽出して同一モデルに落とすパイプラインを提案します。
レポート本文
背景と現状(データソースの整理)
これ見てくださいよ:
- notice.go.jp/docs/status_notice.csv は行政の通知系の一つの出口になってる(機械で拾えるCSVがある)
- 一方で多くの府省はPDFで公示を出すことが多く、CSVは散在、あるいは存在しない
- 内閣府の「行政データにおける機械可読性に関するルール」(https://www.digital.go.jp/.../20260331_meeting_executive_outline_05.pdf)は良いスタートだけど、現場の運用負荷に触れている
要するに:データはあるけどフォーマットやID体系がまちまちで横断が難しいということです。
問題点を技術的に分解する
- 一意なIDがない:同じ通知が複数ページ・複数形式で出ると突合不可
- スキーマの欠如:フィールド名・日付書式・当事者表記がバラバラ
- 更新トラッキングが手薄:差分(改正・撤回)を自動で拾えない
- 機械可読化の歩留まり:PDF→テキスト抽出で構造が壊れる
技術設計:通知横断パイプライン(概要)
- 起点:notice.go.jpのCSVや府省のCSV/HTML/PDFを取得
- タイムスタンプとソースURIをメタとして保存
- 共通スキーマを定義(例は下に)
- PDFはOCR/レイアウト解析→テンプレ化→フィールド抽出
- ハッシュ(title+date+source)や照合ルールで同一通知を統合
- 各版を保存し、レコード単位でdiffを取る(Who/What/When)
- /notices?from=2026-01-01&keyword=補助金 みたいに横断検索可能に
具体的なスキーマ例(要するにこういう形に落とす)
{
"notice_id": "string", // ソース由来の一意ID + 正規化ハッシュ
"title": "string",
"published_at": "YYYY-MM-DD",
"source": "string", // notice.go.jp 等
"department": "string",
"document_uri": "string",
"document_format": "csv|pdf|html",
"tags": ["補助金","環境"],
"body_text": "string"
}
最低限のコード例(PythonでCSV取得→jsonschemaでバリデート)
import requests
import pandas as pd
from jsonschema import validate
CSV_URL = 'https://notice.go.jp/docs/status_notice.csv'
res = requests.get(CSV_URL)
open('status_notice.csv','wb').write(res.content)
df = pd.read_csv('status_notice.csv')
schema = {"type":"object","properties":{"title":{"type":"string"},"published_at":{"type":"string"}}}
for _, row in df.head(10).iterrows():
record = {"title":row['title'], "published_at":row['date']}
validate(record, schema)
エンジニア的に言うと、これでまずインジェストの成功・失敗を自動判定できるんですよね。
KPIと検証手法(政策評価につなげる)
- 機械可読比率:総通知数に対するCSV/API公開比率
- 公開遅延:初出(府省発表)からnotice.go.jp反映までの日数分布
- 更新追跡率:差分を自動で検知できた通知の割合
これらを定期的に可視化すれば、政策アナリストが「この交付金通知は更新が遅い」とか「この分野はPDF比率が高すぎて解析に時間かかる」といった定量的な指摘ができるようになります。
実装上の注意点とトレードオフ
- OCRの精度に頼りすぎると誤抽出で信頼失う(構造的にCSVがあれば優先)
- 各省のレイヤーで「原本はPDFだからCSVは二次生成」という合意形成が必要
- メタデータ(法令番号、交付金コードなど)は人手での品質保証がまだ要る
まとめ
公告・通知データは政策検証にとても使える資産。だけどフォーマットのバラつきと差分追跡の欠如で実務者の工数が跳ね上がってます。まずは notice.go.jp のCSVを起点に横断スキーマを作って、自動差分追跡と検索APIを用意する。要するに「機械が追える通知の土台」を作れば、政策の実績と目標のギャップも初めてちゃんと数値化できるという話です!
おかむーから一言
テクノロジーで行政の情報流通をスピードアップしたいんだ!まずは小さく正規化して、大きく検証できる基盤を一緒に作ろうぜ!
情報ソース
- https://govtechbridge.com/
- https://www.zhihu.com/question/1940157301433557604
- https://www.zhihu.com/question/40553450
- https://note.govtechtokyo.jp/n/n77785a8254d6
- https://www.zhihu.com/question/372341437/answers/updated
- https://notice.go.jp/docs/status_notice.csv
- https://www5.cao.go.jp/j-j/wp/wp-je24/csv/d1-1-4.csv
- https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/0066e8a8-6734-44ab-a9a9-8e09ba9cb508/xxxxxx_hospital.csv
- https://www.env.go.jp/content/900398071.csv
- https://greenfinanceportal.env.go.jp/csv/issuance_list_gb.csv
- https://www.zhihu.com/question/290714454
- https://www.cas.go.jp/jp/seisaku/digital_gyozaikaikaku/kakusyoDX4/kakusyoDX4.html
- https://www.zhihu.com/question/6430289390
- https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/256dcba6-b936-4031-b88d-3abb27e27f9b/7c809f2f/20260331_meeting_executive_outline_05.pdf
- https://www.zhihu.com/question/2031197523432453026
シェアする
関連レポート

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

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

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