「補助金の情報なんて、プログラムで自動収集すればいいのでは？」
太陽光発電の診断ツールを開発すると、必ずこの発想にたどり着きます。全国の自治体サイトをクローラーで巡回し、補助金の金額と期限を自動で吸い上げる——技術的には、確かに可能です。
しかし私たちは、あえてその道を選びませんでした。首都圏を中心に200以上の自治体の補助金を、一件ずつ人力で調べ、公式サイトと照合し、データベースに手入力しています。非効率に見えるこのやり方には、明確な理由があります。
この記事では、太陽光診断SaaS「LUMIQ-ルミック-」（運営：株式会社Leafull／開発支援：PRODUCE WAVES）の開発を通じて分かった、「補助金情報はなぜ自動収集できないのか」という現実と、正確性のために私たちが下した技術的判断を、実例とともに解説します。
この記事で分かること
- 補助金情報のスクレイピングが「技術的には可能」でも「実用にならない」理由
- 自動化すべき部分と、あえて人力に残すべき部分の見極め方
- 200自治体超のデータベースを構築して直面した、補助金制度の”複雑さ”の実例
なぜ補助金情報が”営業の生命線”なのか
太陽光発電の営業では、「初期費用がいくら安くなるか」が契約の決め手になります。その鍵を握るのが補助金です。
ところが補助金は、国・都道府県・市区町村の3階層があり、しかも住んでいる市区町村によって金額も条件も全く異なります。同じ県内でも、A市には手厚い補助があり、隣のB市には一切ない、ということが日常的に起こります。
さらに、業界で広く使われる診断ツールの中には、シミュレーション結果に補助金を反映しても、それをローンの返済計算にまで落とし込まない製品があります。つまり「補助金を引いた後の、本当の月々の負担額」が営業現場で即座に出せない。私たちが開発を支援したLUMIQ-ルミック-は、まさにこの”補助金を含めた実質負担”を住所入力だけで出すことを目指しました。
そのために不可欠だったのが、正確な補助金データベースです。
スクレイピングは可能。でも実用にならない
結論から言えば、Webスクレイピング（サイトから情報を自動取得する技術）そのものは、確立された技術です。私たちも当然、最初に検討しました。しかし調査を進めるほど、「技術的には可能」と「実務で使える」の間に、深い溝があることが分かってきました。
壁①：自治体サイトの構造がバラバラ
全国には1,700以上の自治体があり、それぞれのサイトは構造も情報の載せ方も全く違います。スクレイピングは「このサイトのここに金額がある」という抽出ルールをサイトごとに作る必要があり、1つのプログラムで全国を網羅することはできません。
壁②：PDF地獄
官公庁は、補助金の詳細をPDFで公開することが非常に多い。PDFから金額・要件・期限を正確に読み取るのは、通常のWebページよりも格段に難しく、誤読のリスクが跳ね上がります。
壁③：年度替わりで一斉に壊れる
補助金は年度替わり（3〜4月）に金額が改定され、ページ構造も作り直されます。営業現場が最新情報を最も必要とするこの時期に、自動収集の仕組みは最も壊れやすくなる。皮肉な話です。
壁④：そもそも機械では読めないサイトもある
実際に調査を進める中で、ページの中身をJavaScriptで後から描画するタイプの自治体サイトに何度も遭遇しました。こうしたサイトは、単純な自動取得ではデータを拾えません。
なぜ人力を選んだか：正確性という一点の判断
ここで私たちが立ち返ったのは、「何のための自動化か」という問いです。
補助金データは、間違えれば営業担当者が顧客に誤った金額を提示することになります。「30万円の補助が出ます」と言って契約したのに、実は終了していた——これは信頼を根底から壊します。補助金は、スピードよりも正確性が絶対的に優先される領域なのです。
だから私たちは、こう割り切りました。「データの収集は人力で行い、そのデータを使った計算は徹底的に自動化する」というハイブリッドです。
収集した補助金は、必ず自治体の公式サイトを一次情報として照合します。ポータルサイトの二次情報は使いません（後述しますが、これらは頻繁に間違っています）。そして公式でも確認が取れないものは、憶測で埋めず「不明」として扱います。一方で、集めた正確なデータをもとに「この住所なら、国＋県＋市の補助を合算していくら」という計算は、完全に自動化しています。
どこを自動化し、どこを人の手に残すか。この見極めこそが、私たちが考える”業務理解型エンジニア”の仕事です。技術の派手さではなく、業務の本質から逆算して設計する。それが結果的に、使う人にとって最も価値のあるツールを生みます。
この判断の背景には、開発チームの構成も大きく関わっています。今回の開発陣には、住宅用太陽光発電の訪問販売を5年間経験したメンバーが加わっていました。「営業マンが商談のどの瞬間に、何の数字を求めるか」「どこまでなら現場は数字のブレを許容できて、どこからは絶対に正確でなければ信頼を失うか」——こうした現場感覚は、要件定義書には決して書かれません。実際に住宅を一軒一軒訪ねてきた経験があるからこそ、「補助金だけは絶対に自動化で妥協してはいけない」という判断に、迷いがありませんでした。現場営業マンの視点を開発の最上流から取り込めたことは、このプロジェクトにとって大きな幸運でした。
どう構築したか：プロセスと実例
実際の構築は、地道なプロセスの繰り返しです。
- 対象自治体の補助金を検索で洗い出す
- 必ず自治体の公式サイトにアクセスし、金額・要件・申請期限・件数上限を確認する
- データベースに登録し、重複や整合性をチェックする
- 年度替わりや予算終了を定期的に見直す
このプロセスで痛感したのが、二次情報の当てにならなさです。補助金をまとめたポータルサイトは複数ありますが、私たちが照合した限り、金額が古い・すでに終了している・条件が実際と違う、といった誤りが何件も見つかりました。「便利そうだから」とこれらを鵜呑みにしていたら、そのままユーザーに誤情報を届けていたことになります。
そして、補助金制度そのものの複雑さも、自動化を阻む大きな要因でした。実際に遭遇した例を挙げます（自治体名は伏せます）。
- 上限で頭打ちになる：「1kWあたり◯万円」でも、総額に上限があり、容量を増やしても補助額は比例して増えません。単純な掛け算では過大な金額を出してしまいます。
- 制度間の排他：同じ自治体内に似た補助が複数あり、「どちらか一方しか受けられない」ケース。両方足すと、実際にはあり得ない金額になります。
- 現金取引は対象外：支払方法によって対象から外れる自治体もありました。
- 申請期間・件数の厳しい制限：ある市では、補助が2期制で申請期間がごく短く、しかも年間の受付件数に上限がありました。「制度はあるが、実際にはほぼ枠が埋まっている」という状況まで、機械は判断できません。
こうした一つひとつの”例外”を、人の目で読み解いてデータ化する。地味ですが、これ以外に正確なデータベースを作る方法はありませんでした。
成果：正確なDBが生む差別化
こうして構築した補助金データベースは、現在200件以上。首都圏（東京都・神奈川県・埼玉県）を中心に整備し、対応エリアを順次拡大しています。住所を入力するだけで、その地域で使える国・都道府県・市区町村の補助金を自動で判定し、合算した実質負担額を提示できます。
重要なのは、この補助金をローンの返済計算にまで反映している点です。業界の既存ツールの中には、補助金を表示はしても、月々の返済シミュレーションには織り込まないものがあります。「補助金を引いた後、月々いくら払うのか」——顧客が本当に知りたいこの数字を、住所入力だけで出せることが、LUMIQの差別化になっています。
※LUMIQ-ルミック-の詳細・実際の画面はこちら → 【LUMIQ for Business】
正直な注意点
誠実にお伝えすると、この手作業アプローチには限界もあります。
全国を即座にはカバーできない：一件ずつ人力で確認する以上、全国すべての自治体を一気に網羅することはできません。対応エリアは順次拡大しています。
更新はリアルタイムではない：補助金は予算枠が埋まれば途中で終了することもあります。私たちは各データに登録日を表示し、一定期間が経過したものには「情報が古い可能性があるため、必ずご自身で最新をご確認ください」という注意を出す設計にしています。自動収集で”それらしい最新値”を装うより、正直に「いつ時点の情報か」を示す方が、営業現場では信頼されると考えているからです。
完璧な自動化を装うより、限界を明示したうえで正確な情報を届ける。これも一つの技術的な誠実さだと、私たちは考えています。
技術を「本当に使えるツール」に変えるために
今回ご紹介した補助金データベースのように、優れたツールは「どこを自動化し、どこに人の手を残すか」という業務理解の上に成り立ちます。技術の派手さではなく、業務の本質から逆算する。それがPRODUCE WAVESの一貫した姿勢です。
千葉県柏市を拠点とするPRODUCE WAVESは、単なるシステム開発ではなく、「業務理解」を最優先にした開発支援を行っています。「AIツールやSaaSを”使う”だけでなく、”作れる”会社」として、要件定義から設計・開発・保守までワンストップで対応します。
■ 開発担当者について
本プロジェクト（LUMIQ-ルミック-）のWEB開発を主導されたのは、株式会社Leafullの林様です。太陽光発電の営業現場を知り尽くした事業視点と、高い技術力を兼ね備え、設計から実装まで一貫して手がけられています。またLeafull社の開発チームには、住宅用太陽光発電の訪問販売を5年間経験したエンジニアも在籍しており、現場営業マンの実感に基づいたタスクの洗い出しや、「どこを自動化すべきか」の判断に、その知見が十二分に活かされています。
林様はXでも発信されています。ぜひご覧ください。
▶ @acguard_jp（X）: https://x.com/acguard_jp
■ 関連記事
👉 【SNS BAN・シャドウバン診断ツール「ACCOUNT GUARD」｜技術レビュー・開発支援】
👉 【AI開発が失敗する理由と業務理解型エンジニアの価値】
システム開発・SaaS開発のご相談はこちら → 【お問い合わせ】