公金マップ

なぜ作ったか

自分が住む自治体の税金が何に使われているかを知りたいと思っても、予算書や決算書は自治体ごとに様式の違うPDFで、数百頁あることも珍しくありません。契約の結果や補助金の情報も、別々のページに散らばっています。

公金マップは、一般の市民が「このお金はどこから来て、何に使われたのか」を、出典までたどれる形で確かめられるようにすることを目指しています。まずは沖縄県と県内41市町村（合計42自治体）の令和2〜6年度を対象にしています。将来は全国に広げる前提で、名前やデータの構成を特定の地域に固定していません。

主な機能

• 収入と支出：42自治体すべてについて、総務省の決算状況調（普通会計）から、収入・目的別の支出・性質別の支出を、金額と構成比で示します。
• 款・項・目・節の明細：予算書・決算書を公開している自治体は、一般会計・特別会計・公営企業会計ごとに、款・項・目・節まで開いて見られます。各項目から資料の頁にたどれます。
• 具体例としての契約と事業：契約（工事・委託）と、事業ごとの資金の流れを、収入と支出の項目の下の具体例として載せています。共同企業体（JV）は構成企業に振り分けず、別枠で扱います。
• 「ない」と「まだ取り込んでいない」を分ける：見つからないものを「ゼロ」とは表示しません。自治体・年度・資料ごとに、取込済みか未取込かを表示します。
• 出典と誤りの報告：値には出典として、資料名・頁・取得日・ファイルのハッシュ（SHA-256）を付けています。自動で取り込んだデータであることを明記し、各ページから対象データのIDと出典が入った状態で誤りを報告できます。

設計の判断

1. 01検算が合わないデータは公開しない

   課題

   自治体の予算書・決算書はPDFで、様式も自治体や年度ごとに違う。自動で読み取ると、列の取り違えや読み違いが起きる。誤った金額を「税金の使い道」として出すわけにはいかない。

   選んだ方法と理由

   取り込むたびに、款＝項の和、項＝目の和のような合計の検算と、「予算現額＝支出済額＋繰越額＋不用額」のような1行ごとの恒等式、冒頭の総括表との照合を行い、1件でも合わなければ保存しない。原資料そのものの不整合は、頁の記載を確かめたものだけを設定に書き、値は補正せずに画面で注記する。

   結果

   那覇市上下水道局の決算書で、増減の列を予算額と取り違えていたのに合計の検算は一致した、という誤りを見つけた。列の取り違えは全行で同じように起きるため、合計だけでは見つからない。この経験から、恒等式の検算を必須にした。

2. 02画像だけのPDFはAIが読み、検算で確かめる

   課題

   小さな町村の決算書には、スキャンした画像だけのPDFがある。文字として取り出せないため、そのままでは取り込めない。

   検討した選択肢

   • macOS 標準の文字認識（Vision）で読む
   • AI が頁の画像を読んで書き起こし、資料の中の合計と照合する

   選んだ方法と理由

   文字認識は数字の誤りが多かったため採らず、AIが頁の画像を読んで書き起こすことにした。読んだ値は必ず資料の中の合計と照合し、合わない箇所は高い解像度で読み直す。それでも合わなければ「要確認」の印を付け、推測では補わない。確認の記録には、確認者の種類（AI・人）と頁と日付を残す。

   結果

   与那国町の令和6年度決算書（一般会計は画像90頁）では、検算で読み違いを4件見つけ、高い解像度の画像と恒等式で直した。画面には、PDFの文字から読んだのか、AIが画像を読んだのかを表示している。

3. 03データベースを持たず、前処理した静的ファイルで配る

   課題

   運営費は年1万円以内に抑え、定常の運用は月2〜4時間にしたい。一方で、42自治体・5年度分の収入と支出、契約、事業を扱う必要がある。

   検討した選択肢

   • Supabase（Postgres と API）を使う
   • SQLite のファイルを配信する
   • 前処理した JSON を、自治体×年度×区分で分割して配信する

   選んだ方法と理由

   取り込みと集計を事前に済ませ、自治体×年度×区分で分割した JSON を静的ファイルとして配ることにした。画面もビルド工程のない HTML と JavaScript にした。Supabase は、無料枠の休止条件や有料プランの料金が、費用と運用時間の上限と合いにくかった。

   結果

   常時動くサーバーが要らない構成になり、公式情報で確かめた無料枠の範囲では、年間費用の見積もりは0円になった。

技術構成

品質と運用

• 検算：取り込みでは、合計・1行ごとの恒等式・総括表との照合がすべて一致したものだけを保存します。総務省の決算状況調の取り込みでは、10,253件の検算がすべて一致しました。
• データの検査：取り込んだデータは JSON Schema と独自の検査で確かめてから書き出します。予算・契約・交付決定・支払いなど金額の段階を混同しないこと、資金の移転や変更契約を二重に数えないことも、データの構造で区別しています。
• 画面の検査：ヘッドレスブラウザでスマホの画面幅に合わせ、全ページについて必要な文言、JavaScript のエラー、横のはみ出し、地図の表示、報告リンクの事前入力を確かめています。
• 慎重な表示：法人を名前だけで同じとみなしません。高額・集中・随意契約だけを理由に不正と判断するような表示もしません。地図に出すのは、自治体の公式な資料で位置を確認できた場所だけです。
• 原資料の扱い：原資料のPDFなどは再配布せず、金額や相手方などの事実を取り出して、出典へのリンクを付けます。
• AIとの開発：Claude Code と Codex を交互に使っています。会話の履歴に頼らず、判断の記録と作業の引き継ぎをリポジトリに残して、どちらからでも途中から再開できるようにしています。

振り返りとこれから

最初は、契約や補助金の履歴を中心に据える設計でした。作り進めるうちに、「税金が何に使われているか」を知るには、まず自治体の収入と支出の全体が見えなければならないと考え直しました。そこで画面の骨格を収入と支出の項目に組み替え、契約や事業はその下の具体例として位置づけ直しました。

今後は、予算書・決算書を公式サイトに載せていない自治体に提供を依頼し、入手できたところから款・項・目・節の明細に置き換えていきます。公開の条件を整えたうえで、限られたデータから公開を始める予定です。