【AI社員実践記 第12話】毎朝7時、補助金の新着だけを知らせる「補助金レーダー」をAIと作ってみた

こんにちは、オフィスピコッツの小笹です。

今朝7時、1通のメールが届きました。

差出人は、

「補助金情報自動監視」

件名は、

「【補助金情報】新着公募1件のお知らせ」

でした。

本文には、新しく公募が始まった補助金の名称、対象地域、上限額、締切、公式ページへのリンクが並んでいます。

今回検知したのは、全国を対象とした補助金。

上限額は1,500万円、締切は2026年10月7日です。

私自身は、その朝に補助金サイトを検索していません。

誰かが新着情報を調べてメールを書いたわけでもありません。

毎朝7時に機械が補助金情報を確認し、「昨日までになかったもの」だけを知らせてくる。

今回は、この仕組みをAIと一緒に作った話です。

社内では、分かりやすく、

「補助金レーダー」

と呼ぶことにしました。

第9〜11話はVPS。今回はCloudflare側に仕事を作った

ここ数回のAI社員実践記では、1台のVPSへ少しずつ仕事を増やしてきました。

第9話ではサイト監視。

第10話ではドメイン期限チェックと月次レポート。

第11話ではリンク切れ巡回。

機械に任せられる定期確認を、一つずつ人間の仕事から外してきました。

今回も考え方は同じです。

ただし、今回の仕事場はVPSではありません。

Cloudflare Workersを使って、補助金情報を毎朝確認する係を作ります。

なぜこの仕事を自動化したかったのか。

理由は単純です。

補助金情報の「見張り」は、人間が毎日やる仕事としてはかなり相性が悪いからです。

補助金は「必要になってから探す」と遅いことがある

オフィスピコッツでは、京都・滋賀の中小企業さま向けに、ホームページ制作だけでなく補助金活用のご相談も受けています。

その中で地味に難しいのが、

新しい補助金が始まったことに、早く気づくこと

です。

補助金には国の制度もあれば、都道府県の制度もあります。

対象業種が限定されるものもあります。

いつ新しい募集が始まるかも一定ではありません。

毎朝、

「今日は何か始まっていないかな」

と複数サイトを見に行く。

できなくはありません。

でも、これを365日続けるのは現実的ではありません。

しかも、ほとんどの日は何も変わっていません。

人間が毎日同じページを見て、

「今日も変化なし」

を確認し続ける。

これは、これまでの監視シリーズと同じく、

機械の方が向いている仕事

です。

やりたいことをPIKOZ OSへそのまま伝えた

今回も、最初はPIKOZ OSから始めました。

新しい会話を作り、Kimi K2.7 Codeを選択。

欲しい仕組みをまとめて伝えます。

主な条件は、

• Jグランツの公開情報から補助金情報を取得
• 毎朝7時に自動実行
• 全国・京都府・滋賀県を対象
• 前回までになかった新着だけを判定
• 新着があったときだけメール通知
• 受付中の補助金を一覧表示
• 地域で絞り込み
• 最終取得日時と件数を表示

といったものです。

デザインについては、

「白ベース、装飾は最小限、スマホでも読みやすく」

とだけ伝えました。

ここまでなら、これまでのPIKOZ OSで作ってきた案件管理アプリなどと似ています。

ところが今回は、すぐに一つ問題が出ました。

PIKOZ OSのGadgetからは、外部APIを直接取りに行けなかった

AI社員が要件を整理し始めると、

「GadgetからJグランツのAPIへ直接アクセスすることはできない」

という話になりました。

PIKOZ OSのGadgetは、サンドボックス化された環境で動いています。

画面やデータ保存の仕組みは作れますが、その中から自由にインターネット上のAPIへアクセスできるわけではありません。

つまり、

画面は作れる。
でも、補助金情報を取りに行く仕事は別の場所で動かす必要がある。

ということです。

AI社員はそこで、

• Gadgetは表示とデータ管理
• Jグランツからの取得はCloudflare Workers
• 新着判定もWorkers
• メール通知もWorkers
• 毎朝の実行もWorkersのCron Trigger

という役割分担を提案しました。

最初から思い描いていた構成とは少し変わりました。

でも、無理にGadgetだけで全部やろうとはしません。

できない制約が見つかったら、仕事を別の場所へ分ける。

実際のシステムづくりでは、こういう判断の方が大切なのかもしれません。

一度はPIKOZ OS内でつなごうとしたが、そこも行き止まりだった

PIKOZ OSは、補助金一覧の画面とWorkers側のコードまで作ってくれました。

ところが、次に必要になったのが、

Gadgetと外部Workerをつなぐための公開RPC情報

です。

ここでも制約に当たりました。

今回のWorkspaceからは、Gadgetを外から呼び出すための公開RPC URLや認証情報を発行できません。

つまり、

コードはできた。
画面もできた。
でも、この2つを想定した方法ではつなげない。

という状態です。

AI社員との実践では、こういうことが割とあります。

AIがコードを書けたからといって、サービス側の仕様まで消えるわけではありません。

そこで、Gadgetとの直接連携にこだわるのをやめました。

今回の目的は、

「毎朝、新しい補助金を見つけること」

です。

まず、その中核だけをCloudflare Workersで完成させることにしました。

ローカルから作業しようとしたら、今度はNode.jsがなかった

次に、Cloudflare Workersをローカル環境から設定しようとしました。

ところがPowerShellで確認すると、

node -v

が通りません。

Node.jsが入っていませんでした。

ここで、

「ではNode.jsをインストールして……」

と進めてもいいのですが、今回やりたいことのためだけにPCへ新しい開発環境を増やす必要があるのか。

AI社員と相談して、

Cloudflareの管理画面だけで進める

方法へ切り替えました。

遠回りしているようにも見えます。

でも、

目的を達成するのに不要なものは増やさない。

この判断も、今のところうまくいっています。

「昨日までに知っていた補助金」を覚える場所が必要だった

今回の仕組みで一番重要なのは、

新着かどうかをどう判断するか

です。

今日126件あった。

明日127件になった。

その1件が新着です。

でも、昨日の126件を覚えていなければ、比較できません。

そこで使ったのがCloudflare Workers KVです。

KVは簡単に言えば、

Workerが前回の状態を覚えておく場所

です。

Cloudflareの管理画面からKVを作成。

続いてWorkerを作ります。

AI社員が生成したコードを貼り付け、デプロイしました。

その後、

• WorkerとKVを接続
• メール送信用の設定
• 必要な変数・Secretを登録

と、一つずつ設定していきます。

今回も操作自体は私が行っています。

AI社員は、

「次にどの画面を開くか」
「ここには何を入れるか」
「設定後に何を確認するか」

を一手ずつ案内する役です。

第8話のメール移行と同じで、

隣で管理画面を見ながら進める担当者

に近い使い方です。

毎朝7時に自動実行する

Workerが動く状態になったら、次は自動実行です。

Cloudflare WorkersにはCron Triggerがあります。

今回設定したのは、

0 22 * * *

です。

Cloudflareの画面ではUTCで設定するため、22時UTC。

日本時間では翌朝7時になります。

これで、

毎朝7時になると、自動的に補助金情報を取りに行く

ようになりました。

人間がパソコンを開いている必要はありません。

VPSを起動しておく必要もありません。

毎朝決まった時間にWorkerが動きます。

初回だけは、126件全部を「新着」にしない

ここでも一つ考える必要がありました。

仕組みを初めて動かした時点で、受付中の補助金が126件ありました。

システムから見れば、

全部初めて見る補助金

です。

何も考えずに作れば、

「新着126件！」

というメールが初日に届きます。

でも、それでは意味がありません。

欲しいのは、

今日から新しく増えたもの

です。

そこで初回実行だけは、

• 現在の補助金一覧を取得
• 126件のIDをKVへ保存
• メールは送らない

という動きにしました。

最初の実行結果では、

total: 126

workersNewCount: 126

emailSent: false

reason: first_run

となっています。

つまり、

126件を覚えただけで、通知はしなかった。

設計どおりです。

そして、すぐに2回目を実行しました。

今度は、

total: 126

workersNewCount: 0

emailSent: false

です。

同じ126件をもう一度見ても、新着とは判定しない。

差分判定が正しく動いていることを確認できました。

「毎朝メールを送る」のはやめた

今回、最初から決めていたことがあります。

新着がない日は、何も送らない。

毎朝7時に、

「今日の補助金情報です」

というメールを送る仕組みにすることもできます。

でも、変化がなければ内容はほぼ同じです。

これを毎日受け取ると、たぶん数週間後には読みません。

第10話のドメイン期限チェックでも同じ考え方を使いました。

正常なら黙っている。

異常や変化があったときだけ話しかける。

補助金レーダーも、

新しい公募が出た朝だけ鳴る

仕組みにしました。

メールを減らすこと自体が、通知を読んでもらうための設計でもあります。

取得した情報は、メールだけではもったいない

ここまでで、社内向けの新着通知は完成しました。

でも、毎朝せっかく補助金データを取得しています。

メールを1通送って終わりではもったいありません。

そこで同じデータを使って、

「京都・滋賀 補助金新着レーダー」

という公開ページも作りました。

受付中の補助金を締切順に並べ、

• 全国
• 京都府
• 滋賀県

で絞り込めるようにしました。

新しく追加されたものには「新着」を表示します。

人間がWordPressへ毎朝記事を追加する必要はありません。

毎朝の自動取得結果を、そのまま公開ページにも反映する。

同じレーダーは「京都・滋賀プレスリリース」にも設置しました。

一つ取得する仕組みを作ったことで、

社内通知と公開情報の両方に同じデータを使える

ようになりました。

WordPressに設置したら、別のところでまた詰まった

公開ページを作る途中にも、一つ問題がありました。

一覧を表示するプログラムをWordPressのページへ直接貼り付けると、

エディタがコード中の記号を変換してしまい、正常に動かない

という現象が起きました。

しかも、別の2つのテーマで同じ症状が出ました。

そこで最終的には、

プログラム本体を外部ファイルとして置き、WordPress側から1行で読み込む

方式へ変更しました。

これで正常に動作しました。

今後、同じようなウィジェットをWordPressへ置く場合も、この方式を標準にするつもりです。

ここでも、

「最初に書いたコードをそのまま使い切る」

のではなく、

実際の環境に合わせて形を変える

必要がありました。

4日間、何も来なかった

仕組みを本番稼働させました。

初日に126件を記録。

翌朝7時。

メールは来ません。

次の日も来ません。

その次の日も来ません。

4日間、補助金レーダーは沈黙したままでした。

一瞬、

「本当に動いているのかな」

という気持ちにもなります。

でも、テストでは差分判定まで確認済みです。

新着がないなら、何も言わない。

それが今回の仕様です。

つまり、

メールが来ないこと自体が正常動作

です。

監視系の仕組みでは、この「何も起きない時間」を信じられるところまでテストしておくことが大切だと感じます。

5日目の朝7時、本物の新着が来た

そして5日目。

朝7時に、冒頭のメールが届きました。

「【補助金情報】新着公募1件のお知らせ」

テストメールではありません。

実際に新しく公募された情報です。

メールには、

• 補助金名
• 対象地域
• 上限額
• 締切
• 公式ページURL

が自動で入っています。

この日の新着は、上限額1,500万円。

締切は2026年10月7日。

対象地域は全国です。

同じタイミングで、公開中の補助金レーダーにも新着情報が反映されました。

つまり、

取得
→ 前回との差分判定
→ 新着メール
→ 公開ページへ反映

まで、誰も操作していません。

初めて、仕組みの端から端まで本物のデータで通りました。

この瞬間は、かなりうれしいものでした。

今回かかった追加費用

今回の補助金レーダーでは、Cloudflare Workersを既存環境の範囲で利用しています。

そのため、この係を追加するための新しい月額サービスは契約していません。

追加の固定費は実質0円です。

AIとのやり取りには利用料が発生していますが、今回の設計・コード生成・修正までを含めても数十円程度でした。

そして人間側が毎朝補助金サイトを確認する時間は、今後ほぼ不要になります。

もちろん、

「この補助金はお客様に使えそうか」

という判断は機械には任せません。

自動化したのは、あくまで見つけるところです。

「見張り」は機械に。「使うかどうか」は人間に

第9話から、自動化する仕事を少しずつ増やしてきました。

サイトが落ちていないか。

ドメイン期限が近くないか。

リンク切れがないか。

そして今回は、

新しい補助金が始まっていないか。

共通しているのは、

毎日・毎週、同じ確認を繰り返す仕事

です。

ここは機械に向いています。

一方、

• この補助金は自社に合っているのか
• 申請する価値があるのか
• 条件を満たしているのか
• 補助金を使って何をするのか

という部分は、人が考えます。

全部AIに任せたいわけではありません。

人間が考える前に必要な「見張り」を、自動化したい。

今回の補助金レーダーは、その一つになりました。

AI社員が「調べる人」から「仕組みを作る人」になってきた

今回、私はAIへ、

「今日使える補助金を調べて」

と頼んだわけではありません。

それなら、その日の答えが1回返ってきて終わりです。

今回頼んだのは、

「明日から毎日、自分で見に行く仕組みを作ってほしい」

という仕事です。

一度仕組みが完成すれば、明日も、来週も、来月も動きます。

AIに毎日同じ質問をする必要もありません。

この違いは大きいと思います。

AIを「質問すると答えてくれる人」として使うだけでなく、

人間がやっている定型作業を見つけ、それを継続して動く仕組みに変える。

最近のAI社員実践記は、だんだんそこへ進んできました。

補助金情報は、どなたでも見られるようにしました

今回作った補助金レーダーは、社内だけで使う仕組みにはしていません。

受付中の補助金情報は、

「京都・滋賀 補助金新着レーダー」

で公開しています。

全国・京都・滋賀で絞り込みながら確認できます。

また、

「うちの会社なら、どんな補助金が候補になる？」

という場合は、「補助金3分診断」も用意しています。

補助金は、

見つけること

と、

実際に使うべきか判断すること

が別の仕事です。

見つける部分は機械へ。

使い方を考えるところは人間へ。

そんな分担で運用していきます。

• 補助金新着レーダー：https://pikoz.net/hojokin-radar/
• 補助金3分診断：https://pikoz.net/hojokin-shindan/
• 補助金サポート：https://pikoz.net/hozyokin-support/

AI社員実践記は、まだ続きます。