🐶を監視するツールを作った
我が家には日本スピッツの🐶がいるのですが、まだ幼くて見守りが必要な時期なんですよね。 特に、ケージから出したまま長時間自由にさせると、時々粗相をしてしまったりするんです。
今までは、なるべくそれを防ぐように、家族で共有できるタイマーアプリのようなものを作って管理するように心がけていました。 簡単にいうと、ケージから出したタイミングでタイマーをONにして、一定時間ごとに通知を送ることで長時間自由にさせてしまうことを防ぐみたいなイメージです。
しかし、それだと問題があって、そもそもタイマーをONにするのを忘れてしまい、結局誰も気が付かないまま長時間自由にさせてしまうことがありました。
これは仕組みとして良くないということで、そこを改善するために、今回はより強固な監視を実現するための仕組みを作ったので、それについて簡単に紹介しようと思います。
やったこと
カメラによる定期撮影を行なって🐶の外出状況を監視することで、タイマーONを促す通知を送信する仕組みを構築しました。
タイマーはONにすれば一定時間ごとに通知が送信されるので、タイマーをONにすることさえ忘れなければ、長時間自由にさせてしまうことを防ぐことができます。
アーキテクチャ
全体感としてはこんな感じのアーキテクチャで構築しています。
flowchart LR
CAM["M5Stack CamS3<br/>撮影・画像送信"]
R2["Cloudflare R2"]
Q["Cloudflare Queues<br/>イベント配信"]
PUSH["Web Push"]
subgraph P["画像解析・通知判定"]
W["Cloudflare Workers"]
AI["Workers AI<br/>clef-flash"]
W -->|"画像解析リクエスト"| AI
AI -->|"解析結果"| W
end
CAM --> R2 --> |R2 PutObject Event| Q --> W
W -->|"通知送信"| PUSH
全体感
画像撮影・送信
M5Stack Unit CamS3-5MP を利用することにより、画像の撮影とCloudflare R2への送信を行なっています。
CamS3-5MPは、小型カメラでありながら、WiFi通信を利用してインターネット接続を行うための仕組みを備えています。 すなわち、撮影した画像をインターネットを経由して送信することが可能となっています。
今回は、プログラムを組んで、一定時間ごとに画像を自動的に撮影してCloudflare R2に送信するようにしました。
Cloudflare R2 -> Cloudflare Queues
Cloudflare R2は、オブジェクトが保存された際にイベントを発火させることができます。 そして、Cloudflare Queuesでイベントを受け取り、様々なコンシューマーに配信することができます。
今回は、この仕組みを利用することでWorkersに画像のpushイベントを通知することにしました。
Cloudflare Workers
Cloudflare Workersでは、元々フロントエンドとバックエンドを統合して動かしていました。
今回は、主にそのバックエンド側の処理に手を加えて、送信されてきた画像pushイベントから画像を取得して、🐶の外出状況を判定する処理を追加しました。
判定にはCloudflare Workers AIのclef-flashを利用して、画像解析を行なっています。
clef-flashはJevと類似した意思決定型AIとなっており、画像を利用した判定にも対応していることから、今回の用途にピッタリでした。
画像解析は実質的にAPI通信を行うだけで完結しているので、非常にシンプルに解析処理を実現することができました。
Web Push
元々あったWebアプリケーションのPush通知を利用して、🐶の外出状況を判定した結果に応じて通知処理を行うようにしました。
タイマーの起動状態はCloudflare Durable Objectsに保存しているので、その状態と照らし合わせて、通知を送信するべきか否かを判定しています。
コスト面について
気になるコストについてですが、なんと、今回の仕組みは全てCloudflareの無料枠で実現することができました。
5分に1回撮影して解析という、比較的頻度高く処理を行っている気がするのですが、それでもCloudflareの無料枠で十分に収まっています。
もちろん何も考えずに構築すると課金が発生しますが、いくつかの工夫を行うことでそれを回避しています。
- R2に保存される画像は、保存から3時間経過で自動削除されるようなライフサイクルルールを設定する
- Workers AIは1日10,000 Neuronsまで無料なので、なるべくtokenを絞って超過しないようにする
- tokenを抑えつつ、ある程度の精度を出すためのチューニング作業を行いました
といった感じで、ランニングコスト0を実現できています。
まとめ
こういった仕組みは、今まで考えついたことは幾度となくあったのですが、IoT機器のプログラミングなどに疎くて、どうしてもハードルが高いように感じていました。
しかし、AI Agentの進歩により、その辺りをほとんどAgentに任せられるようになって、詳細を知らなくても形にできるようになりました。 (もちろん、コードのリファクタなどは行なっていますが)
また、こういった小さな仕組みとCloudflareとの相性についても本当に良いなということを再実感しました。
IoTを利用したエンジニアリング、とても面白いので、今後も色々と試していきたいと思いました。