【AI社員実践記 第18話】補助金の締切がGoogleカレンダーに勝手に並ぶ仕組みを作ってみた

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

第12話で「補助金レーダー」を作ってから、同じ補助金データを何度も使い回しています。

最初は、受付中の補助金をWebページで一覧表示するためのデータでした。

次に、そのデータを第13話の「締切ウォッチ」で使いました。

毎週金曜、締切が近づいた補助金をメールで知らせ、X投稿の下書きまで作る仕組みです。

そして今回は、

同じ補助金データを3度目に使いました。

新しく集めた情報は1件もありません。

追加したのは、

補助金の締切をGoogleカレンダーへ自動で並べる出口

です。

一度設定すれば、補助金の締切が自分のカレンダーへ入り続けます。

今回も追加固定費は0円。

設計から本番確認まで、約30分でした。

「補助金の締切、カレンダーに入ったら便利では？」

きっかけは、AI社員との、

「今ある補助金データ、ほかに使い道はない？」

という話でした。

現在、オフィスピコッツでは「京都・滋賀 補助金新着レーダー」を動かしています。

毎朝、補助金の公開データを確認。

受付中の情報を更新しています。

そのデータには、

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

などがすでに入っています。

AI社員から出てきた案の一つが、

「カレンダー配信にしてはどうですか」

でした。

Googleカレンダーには、

「URLでカレンダーを追加する」

という機能があります。

一度URLを登録すると、そのURLで配信されている予定を定期的に読み込みます。

つまり、

オフィスピコッツ側で補助金締切のカレンダーデータを公開しておけば、利用者側では一度登録するだけ。

その後に追加・更新された締切は、カレンダー側にも反映されていきます。

これは結構便利そうです。

メールとは違う「情報の置き場所」

補助金情報を届ける方法はいくつかあります。

Webページなら、自分から見に来てもらう必要があります。

メールなら、こちらから届けられます。

ただし、受信箱の中へ流れていきます。

カレンダーなら少し違います。

たとえば9月30日締切の補助金なら、

9月30日の予定として、最初からカレンダーの中に置いておける。

仕事の予定。

打ち合わせ。

納期。

その中に、

「【締切】○○補助金」

と並びます。

補助金情報を見るために専用ページを開く必要もありません。

締切の日付そのものが、普段使っているスケジュールの中へ入ります。

今回やりたかったのは、

「新しい補助金を知らせる」だけではなく、「忘れにくい場所へ置く」

ことでした。

使ったのはiCalという標準形式

そこで使ったのが、

iCal（iCalendar／.ics）

というカレンダー用の標準形式です。

Googleカレンダーだけの独自形式ではありません。

OutlookやiPhoneなど、多くのカレンダーが扱える形式です。

中身はテキストデータです。

たとえば、

• カレンダー名
• 予定のタイトル
• 日付
• 説明
• URL

などを、決められた書式で並べます。

今回の場合なら、

SUMMARY：補助金名

DTSTART：締切日

DESCRIPTION：対象地域や詳細情報

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

という形です。

実際に生成されたファイルの中身がこちらです。

一見すると、人間が直接読むには少し分かりにくい文字列です。

でも、Googleカレンダーなどが読めば、

ちゃんと予定として表示されます。

小さな会社が「カレンダー配信システム」を作る必要はなかった

今回、設計として面白かったのはここです。

最初から、

「Googleカレンダーへ予定を直接登録する仕組み」

を作ったわけではありません。

利用者のGoogleアカウントへログインする必要もありません。

Google Calendar APIを使って、1件ずつ予定を登録する必要もありません。

オフィスピコッツ側でやるのは、

正しいiCalデータをURLで公開するだけ。

あとはGoogleカレンダーなどが定期的に読みに来ます。

つまり、

こちらは標準形式で情報を置く。
同期する仕事は、利用者が使っているカレンダー側へ任せる。

という設計です。

独自アプリを作る必要もありません。

専用スマホアプリもありません。

小さな会社でも、標準規格に合わせれば既存サービスの仕組みを活用できます。

これは今回かなり大きな発見でした。

AI社員がコードだけでなく「規格の細かいルール」も担当

仕組みの考え方は単純です。

補助金データを読む。

締切があるものだけ抜き出す。

iCal形式へ変換する。

公開する。

ただし、実際のiCalには細かなルールがあります。

たとえば、

1行を一定の長さで折り返すルール。

カンマやセミコロンなど、特殊文字の扱い。

終日予定の日付表現。

改行コード。

UID。

カレンダー名。

こういう仕様を人間が一から調べながら実装すると、意外と時間がかかります。

今回はAI社員に、

コードと一緒にテストも作る

ところまで任せました。

第17話で、

「東京都」という文字列の中に「京都」が入っているため、地域判定を誤るバグをテストが見つけました。

その経験もあって、今回も、

「作れたら終わりではなく、規格どおりかテストする」

を最初から前提にしました。

またテストが1件止めた

実際、今回もテストが仕事をしました。

最初に生成したカレンダーデータでは、

日本語のカレンダー名を含む行が、iCalの行長ルールを超える

問題が見つかりました。

見た目では分かりません。

ファイル自体も生成されます。

でも仕様としては修正した方がいい状態です。

そこでAI社員が、

規定の長さを超える行を正しく折り返す処理を修正。

再度テスト。

今度は合格しました。

第17話に続いて、

「エラーにならず動いてしまう小さな不備」を、納品前テストが止めた

形です。

最近は、AIにコードを書かせるとき、

「テストも一緒に」

がかなり重要だと感じています。

人間がやった反映作業は約3分

コードとテストができたあと、人間側の作業です。

Cloudflareの管理画面を開く。

既存の補助金レーダーのコードを差し替える。

デプロイ。

基本的にはこれだけです。

実際に私が管理画面で操作していた時間は、約3分でした。

ただし、

第18話の作業全体が3分だった

という意味ではありません。

AI社員との設計。

コード生成。

テスト。

不備の修正。

本番反映。

実データの確認。

そこまで含めると、およそ30分です。

人間側の「手を動かす時間」が3分だった、という感じです。

本番へ出したあとも、AI側で実データを確認

デプロイしたから完成、ではありません。

公開したiCal URLへ実際にアクセス。

生成された内容を確認します。

今回確認したのは、

• カレンダー名が入っているか
• 締切日が終日予定として設定されているか
• 締切のない補助金を入れていないか
• 金額などの情報が崩れていないか
• URLが正しく入っているか
• 実際の補助金データを変換できているか

といった項目です。

100件を超える実データについて、変換結果を確認しました。

今回も、

「作った側が、動作確認まで行う」

という形です。

AIがコードだけ書いて、

「では確認してください」

で終わると、結局人間側の作業が増えます。

設計。

実装。

テスト。

本番確認。

ここまではAI側の仕事。

人間は、

最終的に採用するかを判断し、管理画面のボタンを押す。

最近はこの役割分担がかなり固まってきました。

Googleカレンダーへ登録してみた

最後に、実際の利用者と同じ方法で試します。

Googleカレンダーを開き、

「他のカレンダー」

から、

URLで追加

を選択。

今回作ったカレンダーURLを登録します。

しばらくすると、補助金の締切がカレンダー上へ並びました。

9月のカレンダーを見ると、

「【締切】○○補助金」

という予定が各日に入っています。

同じ日が締切の補助金が複数あれば、同じ日に複数表示されます。

日本の祝日と並んで、補助金締切が見える。

想像していたより分かりやすい画面になりました。

カレンダーを作ったのに、補助金データは1件も増えていない

今回のポイントはここです。

このカレンダーのために、

新しく補助金データを収集する仕組みは作っていません。

元データは、第12話の補助金レーダーで毎朝取得しているものです。

同じデータが、

1つ目の出口

Webサイトの補助金新着レーダー。

2つ目の出口

毎週金曜の締切ウォッチ。

3つ目の出口

今回の補助金締切カレンダー。

になりました。

一つの「仕入れ」に対して、出口が3つあります。

元データを増やすのではなく、

使い方を増やした。

今回の仕組みは、そこが一番面白いところだと思います。

データは「集めるところ」が一番高い

ホームページや業務システムを作っていると、

データをどう表示するかに目が向きがちです。

でも実際には、

正しいデータを継続して集めるところ

が一番大変です。

毎朝Jグランツを確認。

受付中の補助金を整理。

重複を判定。

新着を判断。

地域を整理。

締切を管理。

ここまでが第12話でできています。

だから、そのあとに、

「メールでも使おう」

「記事でも使おう」

「カレンダーでも使おう」

となると、追加コストが急に小さくなります。

第9話から続けてきたVPSの自動化と同じです。

最初の仕組みを作るところが一番大変。

2つ目、3つ目は、前に作ったものを部品として使えます。

「同じデータを何回使えるか」を考えるようになった

以前なら、

「補助金一覧ページを作る」

という依頼なら、一覧ページを完成させて終わっていたと思います。

今は、

「そのデータ、ほかに何へ使える？」

を一度考えるようになりました。

補助金情報なら、

Web一覧。

メール通知。

X投稿案。

記事下書き。

カレンダー。

まだ使い道はあるかもしれません。

一度収集して整えたデータなら、

出口を一つ増やすだけで、新しいサービスに近いものが作れる。

AI社員がいることで、その試作コストがかなり下がりました。

「こんなことできる？」

と聞いて、

30分試して、

使えそうなら残す。

違えばやめる。

小さく試せることが、結果的にアイデアを増やしています。

標準規格は、小さな会社にとってかなり強い

今回もう一つ感じたのが、

標準規格を使う強さ

です。

Googleカレンダー専用機能だけを作れば、Googleユーザーしか使えません。

独自アプリを作れば、そのアプリを使ってもらう必要があります。

でもiCalなら、

Googleカレンダー。

Outlook。

iPhoneなど。

対応するカレンダーへ持っていけます。

オフィスピコッツが利用者ごとに同期システムを持つ必要もありません。

「誰でも読める標準形式で置いておく」

だけです。

大きな会社のような開発予算がなくても、

既にある標準とサービスを組み合わせれば、できることはかなり増えます。

AI社員には、

こういう、

「自前で全部作らず、既存の仕組みに乗る方法はないか」

を考えてもらうのも合っているようです。

今回の追加費用は0円

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

補助金データは既存。

Cloudflare環境も既存。

Googleカレンダー側も、利用者が普段使っているものです。

そのため、

追加固定費は0円。

設計から本番確認まで、約30分でした。

そして完成後は、毎朝の補助金データ更新がそのままカレンダー配信用データにも使われます。

人間が締切予定を一つずつ追加する作業はありません。

今回の結論

第18話で作ったのは、

補助金締切カレンダー

です。

でも今回一番大きかったのは、カレンダーそのものより、

「新しいデータを集めなくても、新しい届け方は作れる」

と実感できたことでした。

第12話で集め始めた補助金データ。

第13話では締切ウォッチへ。

第17話では記事下書きへ。

そして今回はカレンダーへ。

同じ材料を何度も使っています。

新しい情報サービスを考えるとき、

「何を新しく集めるか」

だけではなく、

「すでに持っているデータを、別の場所へ届けられないか」

を見る。

これもAI社員との相談で増えてきた視点です。

補助金締切カレンダーは無料で使えます

今回作ったカレンダーは、どなたでも無料で購読できます。

Googleカレンダーの場合は、

「他のカレンダー」→「URLで追加」

から、次のURLを登録します。

https://subsidy-monitor-worker.pikoz-os.workers.dev/radar.ics

一度登録すると、京都・滋賀の事業者が使える補助金の締切情報がカレンダーへ表示されます。

元データは毎朝更新しています。

一覧で確認したい場合は「京都・滋賀 補助金新着レーダー」をご利用ください。

• 補助金新着レーダー：https://pikoz.net/hojokin-radar/
• 無料AI活用診断：https://pikoz.net/ai-shindan/
• 補助金サポート：https://pikoz.net/hozyokin-support/
• AI社員実践記：https://pikoz.net/category/ai-jissen/

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