コードで語るマニフェスト：FAQとルールを構造化して政策の「説明責任」を自動化する

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

• 政策説明（FAQや要件）は人向け文章で終わってないですか？機械が理解できる形にすると再利用性が爆上がりします
• JSON-LDやOpenAPIで政策ルールを型定義すると、検証・可視化・自動申請が現実的になる
• 既存のe-Gov APIや都のオープンデータを使って、段階的に「説明責任のAPI化」を進める設計案を示します

結論

政策の文章（PDFやHTML）はそのままでは検証や自動化に弱いです。エンジニア的に言うと、FAQや給付要件をJSON-LD/JSON Schema/OpenAPIで構造化すれば「住民→自治体→第三者サービス」の相互運用が可能になり、政策の説明責任と実行可能性が高まります！要するに、まずは"説明の仕様化"から始めようということです。

レポート本文

背景：今の問題点

これ見てくださいよ。デジタル庁や都のオープンデータにはAPIが用意されてるけど（例：e-Gov API, 東京都オープンデータAPI）、政策説明はPDFや散在するHTMLに埋もれてることが多いです（参考：Digital庁の利用者視点ガイドや機械可読性ルール案）。要するに、機械に読ませられないから再利用されないんですよね。

• 人向け文書＝ソースオブトゥルースになっている
• 要件や適格性が文章で散在→エラーや解釈差が発生
• 第三者サービス（NPO、民間事業者）が自動連携しにくい

提案：FAQ＋ルールを構造化するアプローチ

エンジニア的に言うと、まずは以下をAPI設計で定義します：

FAQ（頻出質問）をJSON-LDのFAQPageで構造化

給付・申請ルールをJSON Schemaで定義（必須項目、数値レンジ、期間条件など）

OpenAPIでルール検証用のエンドポイントを公開（validateEligibilityなど）

メタデータ（更新日時、法令リンク、担当部署）を付与して信頼性を担保

こうすることで、フロントはJSで即時バリデーション、自治体内のバッチ処理は同じスキーマでETL、外部サービスはAPI一本で利用できるようになるんです。

具体的コード例（イメージ）

// FAQのJSON-LD抜粋
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "補助金の対象は誰ですか？",
"acceptedAnswer": {"@type": "Answer","text": "市内に居住し、要件A〜Cを満たす個人・事業者です。"}
}]
}

# OpenAPIでの検証エンドポイント（抜粋）
paths:
/validateEligibility:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/EligibilityInput'
responses:
'200':
description: Valid or not

これを受けるバックエンドはJSON Schemaで入力を厳密に検証して、理由付きでOK/NGを返す。エンジニアならわかると思うんですけど、これはAPI一本でサービス側のUXが劇的に良くなるパターンです。

実装ステップと現実的な移行計画

• ステップ0：現状リストアップ（PDF/HTML/運用ルール）→ e-Gov APIや都のオープンデータと紐づけ
• ステップ1：FAQをJSON-LDで公開（低コスト、SEOにも効く）
• ステップ2：主要申請フローの属性をJSON Schema化（最優先で1〜2件）
• ステップ3：OpenAPIで検証APIを公開、CIでスキーマ互換性テストを回す
• ステップ4：外部開発者向けドキュメント＋サンプルコードを提供（GitHub + APIカタログ）

この流れは、デジタル庁の機械可読性ルール案にも親和性が高いです（フォーマットはExcel/CSV優先、メタデータ必須など）。

政策の数値目標と実績のギャップを可視化する方法

政策目標（例：高齢者住宅補助、年間1000件）をスキーマのメタデータに「target」フィールドとして入れておきます。APIで実績を定期的にPUTしていけば、ダッシュボードやアラートで差分を自動検出できます。

• 例：/metrics/policy/{policy_id} にmonthly_countをPOST
• これをPrometheus/Grafanaや簡易Lambdaで監視

要するに、目標値をスキーマ化しておけば、実績との比較がコードでできる。人手でExcelを突き合わせる時代は終わりです！

メリットとリスク

メリット

• 再利用性と検証可能性が上がる
• 住民の自己解決が進み窓口負荷が下がる
• 民間事業者の参画がしやすくなる

リスク

• 法的文言と実装の齟齬（解決策：法務と共同でスキーマのバージョニング運用）
• 旧システムとの連携コスト（段階的移行で吸収）

まとめ

文章ベースの政策説明はもう限界。まずはFAQをJSON-LDにして、重要な申請ロジックをJSON Schema/OpenAPIで定義するところから始めよう。これだけで検証・自動化・外部連携の土台ができて、政策の説明責任と実効性がグッと上がります。

おかむーから一言

テクノロジーで社会をアップデートするって言うと大げさだけど、まずは"説明をコードにする"って小さな一歩が強烈に効くんです。僕はこれをやりたいし、一緒に作れる自治体が増えてほしい！

---

参考リンク：e-Gov API（https://www.e-gov.go.jp/digital-government/api）、東京都オープンデータ（https://portal.data.metro.tokyo.lg.jp/opendata-api/）、機械可読性ルール案（digital.go.jp）および各種自治体のUX改善事例を参照。