特集
ミニPCとローカルAIで「監視カメラシステム」を自作、サブスク不要でスマホ通知も可
2026年9月11日 09:42
近頃は高機能なネットワークカメラがリーズナブルに入手でき、AIで人やクルマなどを検知するような機能も標準的に備えている。購入して設置したら、それだけでもうAIカメラ監視システムの完成だ。
映像の変化を捉えたのを契機にスマホなどに通知するように設定でき、異常を検知したら対処したり、宅配物が届いたときにそれに気付いたりと、24時間自動で監視、警戒できる。
ただ、そのようなネットワークカメラのAI機能を利用するにはサブスク登録が必要で、継続的に料金がかかることが多い。また、映像をクラウドに送信して分析する仕組みだとプライバシー上の懸念は払拭できない。
これを解決するには、ローカルで完結するAIカメラ監視システムを自分で作ればいい。幸いなことに今はAIコーディングを駆使すれば、大きな手間をかけることなく実用的なローカル監視システムを構築できる。
欲しい機能を追加するのも自由自在で、超高性能なGPUは必須ではないし、ミニPCでも実現可能だ。早速チャレンジしてみよう！
必要なハードウェアとソフトウェア
今回のコンセプトは、「スペックの高すぎないミニPCで、ローカルAIを使って一般のネットワークカメラをローカルAI監視カメラにしよう」というもの。
目標としては「人物などを検知」し、「そこで何が起きているのかを文章で説明してもらう」ような監視カメラにすることだ。何かあったらいつでも確認できるように、スマホにプッシュ通知する機能も実装する。
まずはそのために必要なものを整理していきたい。今回は下記のハードウェアとソフトウェアを用意したが、やり方は1つではないので、ほかの方法だと変わってくるところもある。あくまでも一例として見てほしい。
ハードウェア
・ミニPC(GMKtec NucBox K15、Intel Core Ultra 5 125U、メモリ32GB)
・ネットワークカメラ(TP-Link Tapo C325WB V2.0)
・eGPU(NVIDIA GeForce RTX 4070 Ti)
・スマートフォン
・宅内LAN環境
ソフトウェア
- Windows 11 Pro
- ClaudeまたはChatGPT(Codex): コーディング用
- Docker Desktop: サーバー用仮想環境
- Frigate: ネットワークカメラ制御用ソフト
- Mosquitto: システム連携用
- Home Assistant: オートメーション用、スマホアプリ
- Ollama: AI処理基盤
今回ミニPCを選んだ理由の1つは、省電力であること。サーバーの役割を持たせて常時稼働させることになるので、できる限り電力消費は少ない方が良い。
性能面では不利なところもありそうだが、CPU内蔵とはいえGPUはあるし、NPUも使えるので、うまく活用すればローカルAIを実用レベルで動作させる余地があると踏んだ。が、やはり試してみないことには分からないので、OCuLinkで接続するeGPU環境(MINISFORUM「DEG1」とGeForce RTX 4070 Ti)も用意した。
ネットワークカメラは「どれでもいい」わけではないので注意しよう。ネットワーク内の別のシステムからカメラにアクセスして映像などを取得できるように、「RTSP」というプロトコルに対応した製品であることが必須だ。
加えてカメラも常時監視になるので、バッテリ駆動よりコンセントから電源を取れる製品の方が都合が良い。あとは予算に合わせて昼夜ともに画質の良い製品を選びたいところ(映像解析の精度に影響することがあるため)。
ソフトウェアについては、こういった自作監視カメラのベストプラクティスがすでにネット上に存在している。「Frigate」というネットワークカメラを制御するソフトウェアを軸に、スマートホームデバイスなどのオートメーションを実現する「Home Assistant」、それらシステム間をつなぐ「Mosquitto」、AI処理基盤となる「Ollama」を組み合わせる形だ。
Frigateには物体検知の仕組みも内包されているため、「カメラ映像の監視」と「人の検知」はほぼ設定作業だけで済む。スマホ通知もHome Assistantの設定(とスマホアプリ側での設定)で実現可能だ。
コーディング作業が発生するのは主にLLMを制御する部分。カメラ映像内に動きがあったとき、何が起きているのかの説明文章を生成するのにLLMを稼働させるので、その部分の作り込みが必要となる。
LLMを動作させるのがOllamaで、AIモデルには「Qwen3-VL 4B Instruct」を使用した。画像や映像を読み取れる、いわゆるVLM(視覚言語モデル)としてはサイズが小さく、メモリ容量がさほど多くないPCでも扱いやすいのがメリットだ。
ただし、FrigateはLinux向けのソフトウェアのため、そのままではWindowsで動作させられない。そこで必要になるのが(Linuxベースの)仮想環境を作成できる「Docker Desktop」だ。そこで1つ仮想環境を作り、Frigate、Ollama、Home Assistantなどをまとめて動かすことになる。
AIツールで設計書を作成し、ミニPC上で実装へ
AI監視カメラシステムを構築するにあたっては、AnthropicのClaudeと、OpenAIのCodexを利用した。ちなみにClaudeとCodexという組み合わせにしたのには大きな理由はない。サブスクプランのトークン残量の都合上、それを有効活用したかった筆者の都合だ。本来ならClaudeのみ、またはChatGPT+Codexの組み合わせの方が無難だろう。
それはともかく、手順としては最初にチャット(ClaudeやChatGPT)でやり取りしながら最適な機器・ソフトウェア構成を模索する。確定したら具体的な連携方法や段階的な実装計画を立てて、それを設計書として出力してもらう。通常はMarkdownファイルになるが、それだと人間が読みにくいので、HTMLファイルにしてもらった。
次に、コーディングAI(今回はCodexで「GPT-6 Astra 中」を選択)に移動して設計書に従って実装を開始するよう指示。といっても、どちらかというとプログラムのコーディングよりも各種ソフトウェアのダウンロードとセットアップ、カスタマイズ作業が中心となる。
Docker Desktopなど、WindowsアプリのセットアップはAIに任せても失敗することがあるので、人の手でダウンロード&インストールした方が早いだろう。一方、Frigateを含む仮想環境(Dockerコンテナ)の導入、Home Assistantの追加など、Linux系OS周りの操作はAIでも成功率が高い。
また、実装を進めていく途中でFrigateやHome Assistantの設定手順が説明される場合もあるが、ここもユーザーが手を動かす必要はない。Codexの内蔵ブラウザからアクセスできるそれらのツールについては、Codexに直接操作してもらうこともできるからだ(Claudeも同様)。
そんな風にあらゆる部分をAIにやってもらうと、ユーザー自身に知識として身に付かないという弊害はある。次に似たような設定が必要になったときに、どんな簡単な操作でも「何をどうやるんだっけ？」となって途方に暮れてしまうかもしれない……。
どれくらい快適に動くのか、最も実用的なハードウェア構成は何か、検証
そんなこんなで、大体1日かけて設計、実装、調整と進め、ひと通りの機能が完成した。人を検知し、それをスマホに通知して、さらに「そこで何が起きているか」も文章で教えてもらう、という一連の流れをちゃんと実現できた。
では、それがどれくらいの快適さで動いてくれるのか。説明文の生成はハードウェア(CPU/内蔵GPU/NPU/eGPU)を切り替えることができるので比較してみることにした。結果が下記のグラフだ。なお、各処理の最適化はまだ図っていない段階だったため、おおよその傾向として見ていただきたい。
人の検知については一律CPU処理となっているため時間にはほとんど差がない。ただし、これは「映像を見て、人であると確定してからプッシュ通知するまでの時間」という意味。パラメータ調整の仕方によって、その前段階の「人であると確定するまでの時間」が変わってくるので、体感的には数秒の時間が追加でかかっている。
ハードウェアの差が最も効いてくるのが、先ほど書いた通り説明文を生成するところだ。CPUでは43秒近くかかっており、実際に届くのは1分以上後になってしまう。これだとさすがに実用にならないが、内蔵GPUやeGPUにすればトータル30秒以内で届くので一気に実用圏内になる。
こうしてグラフにしてみると改善箇所も明らかだ。「説明処理開始までの待ち時間」が気になる部分だろう。この計測時点では、人を検知してからの一連の処理が完了してから次の処理に進む、というような流れになっていたこともあり、説明文の生成処理の開始自体が遅れていたようだ。
待機時間を短縮できれば説明文が通知されるまでの時間を大幅に早められるはず。ということで、この後に最適化の作業を進めていったことで待機時間はほとんどゼロになり、内蔵GPUでは人を検知した通知から10秒余りで、eGPUでは人の検知とほとんど同時に、説明文も通知されるようになった。
以上の結果から、処理時間としては「eGPU＞＞内蔵GPU＞＞NPU＞CPU」となり、eGPUを使えば間違いなく快適であることが分かった。ただ、常時稼働させるシステムであることを考えると消費電力は無視できない。なので、参考までにアイドル時と処理中のシステム全体の消費電力をワットチェッカーで計測してみた。
予想通りではあるが、処理中の消費電力はeGPU利用時が圧倒的に大きい。短時間で処理できる分、消費電力“量”は少なくなるとしても、アイドル時にほかより約3倍大きいとなればコストパフォーマンスの面からは選びにくいだろう。
また、CPU/内蔵GPU/NPUはほぼ横並びではあるものの、先ほどの処理時間もあわせて考えると、CPUはかなり非効率。最もバランスが良いのは内蔵GPUということになる。ミニPC単体で内蔵GPUを使うのが監視システムとしては一番理にかなっている、といえそうだ。
ネットワークカメラを自分好みの理想的な監視システムに
AIコーディングで一番重要と思われるのは、最初の設計書を作るところだ。その内容をしっかり固めておけば、以降の実装時に発生する修正などの負担が少なく、スムーズに進みやすい。
もちろん設計時には想定していないこともいろいろと発生する。今回でいえばHome Assistant上のライブ映像が乱れてしまうので映像の変換処理が必要になったり、人の検知や通知のタイミングを早めるためにいくつかのパラメータを繰り返し調整したり、実装を変えたり、といった作業をしなければならなかった。
監視カメラで人を検知するシステムである性質上、人間がカメラの前に立って検証するという物理的な作業は欠かせない。ここはいくらソフトウェア開発をAIが代行してくれたとしても省けない部分だ。しかし言い方を変えれば、ユーザー自身の環境に最適な動作を納得いくまで突き詰められる、という自前システムならではの利点がある、ということでもある。
ネットワークカメラが標準で備える機能は、あらゆるユーザー環境で汎用的に使えるよう設計されており、ユーザー固有の環境(設置場所や監視エリアの地形など)によっては調整するのにも限度がある。でも自前のシステムなら、より柔軟にカスタマイズして、汎用品にはない独自機能を追加することも可能だ。
クラウドを使わずプライバシーを守りやすい、クラウド料金を払い続けることもない、といった利点もあるが、自分好みのシステムを作り上げて進化し続けられる、というのも自作AIカメラ監視システムの便利で楽しいところ。みなさんも有効活用できていないPCがあるようならぜひ試してみてほしい。
