【AI社員実践記 第13話】毎週金曜、補助金の締切とX投稿案を届ける「締切ウォッチ」を作ってみた

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

第12話では、Jグランツの公開情報を毎朝確認し、新しい補助金が見つかったときだけメールで知らせる「補助金レーダー」を作りました。

補助金情報を毎日人間が見に行く代わりに、機械へ見張らせる仕組みです。

今回作ったのは、その続きです。

補助金には「新しく始まる日」があれば、当然「終わる日」もあります。

そこで今度は、

締切が近づいた補助金を毎週確認し、必要なものだけ知らせる係

を追加しました。

しかも、知らせるだけではありません。

そのメールの中に、

そのままXへ貼れる140字以内の投稿下書き

まで入れることにしました。

社内では、この5人目の係を、

「締切ウォッチ」

と呼んでいます。

思いついてから実際に動くところまで、今回かかった時間は約20分でした。

きっかけは「ここ2日、新しいアイデアが動いていない」

今回の始まりは、かなり単純でした。

AI社員とのチャットで、

「何か新しいアイデアは？ ここ2日ほど動いていないので、何かない？」

と聞いてみました。

すでに、

• サイト監視
• ドメイン期限チェック
• 月次稼働率レポート
• リンク切れチェック
• 補助金新着レーダー

と、いくつかの仕組みが動いています。

そこでAI社員から出てきたのが、

「補助金レーダーで取得しているデータを、締切管理にも使えないか」

という案でした。

言われてみれば、その通りです。

第12話の補助金レーダーは、

新しく始まった補助金を見つける仕組み

です。

でも、補助金を実際に活用する立場からすると、

「新着」だけでなく「もうすぐ終わる」も同じくらい重要

です。

補助金情報には「入口」と「出口」がある

補助金を追いかける仕事を分けて考えると、2つあります。

一つは、

新しい公募が始まったことに気づくこと。

もう一つは、

受付終了が近づいていることに気づくこと。

第12話で作った補助金レーダーは前者です。

毎朝7時にJグランツの公開情報を取得し、前回までになかった新着だけを知らせます。

今回作る締切ウォッチは後者です。

受付中の補助金を確認し、

締切まで残り14日以内

になったものを毎週まとめて知らせる。

これで、

入口は毎朝の新着レーダー。
出口は毎週の締切ウォッチ。

という形になります。

Xの投稿を毎週書くのも、たぶん続かない

今回、締切情報だけをメールで受け取る仕組みにはしませんでした。

もう一つ目的があったからです。

オフィスピコッツでは、補助金情報をWebサイトだけでなくXでも発信しています。

特に、秋に始まる予定の持続化補助金 第20回については、

「様式4まであと○日」

というカウントダウン投稿を続けたいと考えていました。

でも、毎週金曜日になったら、

• 今週締切が近い補助金を確認
• どれをXで紹介するか選ぶ
• 残り日数を書く
• 140字以内にまとめる
• 補助金一覧ページへの導線を付ける

という作業を繰り返すことになります。

1回なら簡単です。

でも、

毎週忘れずに続ける

となると話は別です。

そこで、

締切を見つけるところから、X投稿の下書きを作るところまで機械にやらせる

ことにしました。

人間は金曜の朝に届いた内容を確認し、必要なら少し直して投稿するだけです。

最初はCloudflare側へ追加するつもりだった

第12話の補助金レーダーは、Cloudflare Workersで動いています。

そこで当初は、

「レーダーのWorkerへ締切チェック機能も追加する」

という案でした。

同じ補助金データを扱うのだから、自然な考え方です。

ただ、そこで私からAI社員へ一つ聞きました。

「これ、チャットでやってKAGOYAでいけたりする？」

KAGOYAというのは、第9話から使い続けているVPSです。

元々は遊休状態だったサーバーですが、現在は会社の定期作業をいくつも担当しています。

AI社員の答えは、

「いけます。むしろその方がいいです」

でした。

レーダー本体を触らなくても、公開データを読めばいい

理由はシンプルでした。

第12話で作った補助金レーダーは、取得した補助金情報を機械が読みやすいJSON形式でも公開しています。

つまり締切ウォッチは、

そのJSONを週に1回読みに行けばいい。

Jグランツへもう一度別の仕組みからアクセスする必要もありません。

補助金レーダー本体のコードを変更する必要もありません。

役割としては、

Cloudflare Workers
→ 毎朝、補助金情報を取得して公開する

KAGOYA VPS
→ 毎週、その公開済みデータを読んで締切を確認する

という分担です。

ここで、これまで何となく使い分けていた2つの環境の役割が、かなりはっきりしました。

外から常時アクセスされる公開機能はCloudflare。

週1回・月1回などの社内向け定期処理はVPS。

仕事の種類によって、配属先を変える。

人の仕事分担に少し似ています。

5人目は、すでにあるVPSへ追加する

第9話で最初のサイト監視係を作ったVPSには、現在4つの仕事があります。

1人目はサイト監視係。

2人目はドメイン期限チェック係。

3人目は月次稼働率レポート係。

4人目はリンク切れチェック係。

今回の締切ウォッチは、5人目です。

新しいサーバーは契約しません。

既存のVPSへフォルダを1つ作り、Pythonスクリプトを置きます。

メール通知に必要な設定も、以前作った係のものを流用します。

つまり今回も、

土台はすでにある状態

からのスタートです。

まず、補助金データの中身だけ確認する

AI社員が今回作ったスクリプトには、最初からテスト用の機能を入れてもらいました。

いきなりメールを送るのではありません。

まず、

「実際に取得できるデータの中身だけを表示する」

モードです。

補助金レーダーのJSONについて、

「titleという項目があるはず」

「deadlineはこの形式のはず」

と想像だけでコードを書くと、実際のデータと違ったときに止まります。

そこで最初に実データを取得し、

• area
• deadline
• employees
• first_seen
• id
• max_limit
• title
• url

といった項目が、本当に取得できているかを確認しました。

取得件数は、

126件。

先頭3件のデータも正常に表示されました。

項目名も、AI社員が想定したものと一致しています。

修正なしで、そのまま次へ進めました。

126件の中から、締切が近いものだけを抜き出す

次に、本番と同じ条件でテストします。

対象は、

受付中の補助金のうち、締切まで14日以内のもの。

すると、その日のデータでは、

16件

が該当しました。

期限が近い順に、

• 残り0日
• 残り1日
• 残り4日
• 残り6日
• 残り9日

という形で並びます。

補助金名。

締切日。

対象地域。

Jグランツの詳細ページURL。

これらをまとめたメールを送るようにしました。

実際に届いたメールがこちらです。

件名は、

「【締切ウォッチ】接近16件」

でした。

メールを開けば、

今週、何を優先して確認すればいいか

が一目で分かります。

126件全部を見る必要はありません。

期限が近い16件だけを見る。

「一覧を持っている」ことと、

「今見るべきものが分かる」こと

は、かなり違います。

さらに、X投稿の下書きまで作らせる

今回の締切ウォッチには、メールの最後にもう一つ出力があります。

X投稿の下書きです。

テスト時には、締切が最も近い補助金を一つ選び、

「締切まであと0日」

という形の投稿案が自動生成されました。

たとえば今回のテストでは、

「【締切あと0日】スタートアップ等を活用した農林水産分野の課題解決事業補助金（08/20まで） 受付中の一覧はこちら→ pikoz.net/hojokin-radar/」

という下書きです。

文字数も、

83字

と表示されています。

Xの通常投稿枠に収まることまで確認できます。

私はこれをそのまま自動投稿するつもりはありません。

補助金情報は、内容や対象が毎回違います。

実際にXへ出す前には人が確認します。

ただし、

毎週ゼロから投稿文を書く必要はなくなる。

ここが大きいところです。

「投稿を自動化」ではなく「下書きを自動化」

この仕組みで大切なのは、

Xへの自動投稿まではさせていない

ことです。

毎週金曜、

締切ウォッチが補助金を確認。

投稿候補を選ぶ。

140字以内にまとめる。

下書きをメールで届ける。

ここまでが機械の仕事です。

その後、

本当に今週この補助金を紹介するか

を人が決めます。

そのまま使ってもいい。

少し書き直してもいい。

投稿しなくてもいい。

AIや自動化を使うと、

「全部最後まで自動でやった方がいい」

と考えがちです。

でも、情報発信については、

下書きまで機械、公開判断は人間

くらいが、今のオフィスピコッツにはちょうどいいと思っています。

持続化補助金のカウントダウンにも使う

今回の締切ウォッチでは、もう一つ先の準備も入れています。

持続化補助金 第20回です。

予定している受付期間は11月5日から12月15日。

また、ホームページ制作などで補助金活用を検討する場合に重要になる様式4についても、締切までの日数を意識して案内していきたいと考えています。

そこで、

残り90日を切ったら「様式4まであと○日」という文言をX下書きへ組み込む

設計にしました。

今のうちに仕組みだけ作っておけば、

秋になってから、

「そろそろ投稿を始めないと」

と慌てる必要がありません。

毎週金曜に下書きが届く。

私は確認して投稿する。

続けたい仕事ほど、先に続けられる形にしておく。

今回やりたかったのは、そこです。

今回だけは「該当なし」でもメールを送る

これまで作った監視係には、

問題がなければ黙っている

仕組みが多くあります。

サイト監視は、落ちなければ通知しない。

ドメイン期限チェックも、問題がなければ通知しない。

補助金新着レーダーも、新着がなければ何も送りません。

ところが、今回の締切ウォッチは少し違います。

該当する補助金が0件でも、毎週金曜にメールを送る

ようにしました。

理由は、このメール自体を、

「金曜の補助金発信を考えるきっかけ」

にしたいからです。

16件あれば16件の一覧。

0件なら、

「今週は締切接近なし」

というメール。

毎週決まった朝に届くことで、

締切ウォッチが動いている確認にもなり、その週のX投稿を考える合図にもなる。

同じ自動通知でも、目的によって「正常時は黙る」「正常でも報告する」を使い分けています。

毎週金曜の朝、自動で出勤する

動作確認が終わったら、最後にcronへ登録します。

今回の締切ウォッチは、

毎週金曜日の朝

に自動実行します。

毎週、

VPSへログインする必要はありません。

補助金一覧を開く必要もありません。

残り日数を計算する必要もありません。

投稿文をゼロから考える必要もありません。

金曜の朝になれば、

5人目の係が勝手に補助金レーダーのデータを確認し、

今見るべき締切とX投稿の下書きをメールで届けます。

構築時間は約20分だった

今回の構築にかかった時間は、約20分です。

なぜここまで短くなったのか。

新しく用意したものが、ほとんどないからです。

補助金情報は、第12話のレーダーがすでに取得しています。

VPSは、第9話から使っています。

メール通知の設定もあります。

Pythonを定期実行する方法も、これまで何度も使っています。

つまりAI社員に必要だったのは、

「既存の部品をどう組み合わせるか」

を考えることでした。

1人目の係を作ったときには、環境そのものを準備する必要がありました。

5人目になると、

既存データを読むスクリプトを書いて、cronに1行追加する。

かなり仕事が軽くなっています。

追加費用は0円

今回も、新しい有料サービスは契約していません。

使ったのは、

第9話から稼働しているKAGOYAのVPSと、

第12話で作ったCloudflare側の補助金レーダーです。

締切ウォッチの追加によって、新しい月額料金は増えていません。

追加固定費は0円です。

もちろん、元になるVPSやCloudflare環境そのものには既存の費用があります。

でも、その同じ環境へ仕事を追加しています。

第9話では、月900円弱のサーバーにサイト監視だけを任せていました。

今は5つの係が動いています。

1台のVPSが5係体制になった

現在、このVPSで動いている仕事は次の5つです。

1. サイト監視係
   26サイトを5分間隔で見回り、停止時に通知
2. ドメイン期限チェック係
   管理対象ドメインの期限を週次確認
3. 月次稼働率レポート係
   毎月1日に前月の稼働率を集計
4. リンク切れチェック係
   毎週、サイト内の404などを巡回
5. 締切ウォッチ係
   毎週金曜、補助金の締切とX投稿下書きを送信

最初は、

「使っていないVPSをどうしよう」

というところから始まりました。

今では、

会社の定期業務をまとめて担当する小さな業務サーバー

のようになっています。

CloudflareとVPSの役割分担も見えてきた

今回、もう一つ整理できたのが、

どの仕事をどこで動かすか

です。

補助金レーダー本体はCloudflare Workers。

締切ウォッチはKAGOYA VPS。

どちらでもプログラムは動かせます。

でも、今回の使い分けはかなり分かりやすいものになりました。

常に外からアクセスされる公開ページやAPI。

これはCloudflare。

週1回や月1回、決まった時間に動いて社内へ知らせる仕事。

これはVPS。

すべてを一つの環境へ詰め込むのではなく、

仕事の性質に合わせて働く場所を決める。

AI社員の「配置」を考えるような感覚になってきました。

今回の結論

今回のスタート地点は、

「ここ2日ほど新しいアイデアが動いていない」

という一言でした。

そこから、

既存の補助金レーダーのデータを再利用し、

締切チェックを作り、

X投稿の下書きも作り、

毎週金曜の自動実行まで設定。

約20分で5人目の係が増えました。

今回改めて感じたのは、

AIに毎回答えを聞くより、答えが自動で届く仕組みを一緒に作る方が長く効く

ということです。

「今週締切の補助金を調べて」

と毎週AIへ聞くこともできます。

でも、それなら毎週質問する仕事は人間に残ります。

今回作ったのは、

聞かなくても金曜日になれば届く仕組み

です。

さらに、その情報を使ったX投稿の下書きまで一緒に届きます。

人がやるのは、

確認して、判断して、必要なら投稿すること。

探す。

数える。

毎週同じ形式で書く。

そこは機械へ渡しました。

補助金は「始まった」と「終わる」の両方を見張る

第12話では、新しい補助金が始まった瞬間を見つけるレーダーを作りました。

第13話では、受付終了が近づいている補助金を見つける締切ウォッチを追加しました。

新着という入口。
締切という出口。

両方を見ることで、補助金情報をかなり追いやすくなります。

受付中の補助金は、オフィスピコッツの「京都・滋賀 補助金新着レーダー」で公開しています。

補助金を使ったホームページ制作やリニューアルを検討されている方は、持続化補助金対応ページもご覧ください。

• 補助金新着レーダー：https://pikoz.net/hojokin-radar/
• 持続化補助金対応のホームページ制作：https://pikoz.net/jizokuka-hojokin-hp/
• 補助金サポート：https://pikoz.net/hozyokin-support/
• AI社員実践記：https://pikoz.net/category/ai-jissen/

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