GPUなし・オンボロCPUでもAI監視カメラは成立するのか？
AI監視カメラ「Frigate」はGPU前提だと思っていた。
だが、手元のオンボロサーバー（Pentium G4560）でも動くのか試してみた。
結論から言うと、
重い。でも、使える。
ただし——カメラは1台が限界だ。
では実際にどこまで使えるのか。
検証結果をそのまま出す。
Frigate NVRとは何か
Frigate NVRは、RTSPカメラの映像をリアルタイムで解析し、
「人・車・自転車」といった対象を識別して記録するローカルNVRである。
従来の監視カメラが「動き」をトリガーに録画するのに対し、
Frigateは「何が写っているか」を判断してイベントを切り出す。
つまり、
動体検知ではなく、物体検知。
この違いが、そのまま使い勝手の差になる。
さらに重要なのは、クラウドを一切必要としない点だ。
映像はすべてローカルで処理され、外部サービスへの送信は不要。
プライバシー面だけでなく、ランニングコストも発生しない。
そしてもう一つ、見逃せないポイントがある。
Frigateは「サーバーを一から構築するソフト」ではない。
Dockerコンテナとして提供されており、環境さえ整っていればすぐに動く。
特にTrueNAS SCALEでは、Appとして数クリックで起動できる。
従来のNVR構築にありがちな、
- Linuxセットアップ
- ffmpeg設定
- 推論環境の構築
といった面倒な準備を、ほぼすべてスキップできる。
まとめると、Frigateはこういう存在だ。
- RTSP映像を解析するローカルNVR
- 「動き」ではなく「意味」で録画する
- クラウド不要・完全ローカル処理
- TrueNAS Appで即起動できる実用ツール
「AI監視」を最短距離で実現するソフト
今回の検証環境
今回の検証は、あえて厳しい条件で行った。
いわゆる“オンボロサーバーでどこまで通用するか”を確認するためだ。
■ ハードウェア構成
CPU：Pentium G4560（VM割り当て 2Core）
MEM：ホスト16GB（VM割り当て 4GB）
HDD：1GB x 2
GPU：なし
■ ソフトウェア構成
NVR：App版 Frigate v0.17.01（TrueNAS SCALE ver.25.04.2.6）
■ カメラ構成
カメラ：Wansview Q6（RTSP / ONVIF / Firmware 1.0.0）
解像度：2304×1296（H.265）
※RTSPとONVIFが使えるカメラなら、使用できる可能性が高い
ポイントは3つある。
- GPUなし（純CPU処理）
- H.265（デコード負荷が高い）
- フルHD超えの解像度
あえてキツい条件
この状態で、
- AI検知は成立するのか
- 録画は実用になるのか
を検証していく。
導入でハマったポイント
監視カメラを扱うNVRでは、Frigateは「簡単に動く」と言われるが、
実際にはいくつか“勘所”がある。
ここを外すと、普通にハマる。
■ TrueNAS App の初期設定で押さえるポイント
まず、Appの設定で重要なのはこの3つ。
- Image Selector：Normal Image
- Network：Host Network を有効
- Shared Memory：64 → 256MiB に変更
特にShared Memoryは見落としやすいが、
ここを増やしておかないと映像処理が不安定になる。
■ Host Networkは実質必須
Bridgeでも動かせなくはないが、
素直にHost Networkにした方がいい。
- ポート設定で悩まない
- Frigateのデフォルト挙動に乗れる
- トラブルシュートが楽
Bridgeでも動かせなくはないが、
素直にHost Networkにした方がいい。
FrigateのWeb UIはデフォルトPort:5000で以下に立つ：
Host Networkにしておけば、このポートにそのままアクセスできる。
【参考】Frigateのデフォルトポート
WebUI 5000
RTSP 8554
WebRTC 8555
■ カメラ追加はUIではなくyamlが本体
ここが最大のハマりポイント。
FrigateにはUIがあるが、
RTSPカメラの追加は基本的にconfig.yamlで行う。
実際に試したが、
UIだけではカメラはまともに動かない
文法エラーは保存できない親切設計なので、文法違いで動かなくなる心配はない。
「UIは確認用、設定はyamlが本体」
これがFrigate最大のクセ。
今回使用した設定（Frigate v0.17.1）
今回の検証では、
👉 人・自転車・車が出たときだけ録画する構成
とした。
■ config.yaml（抜粋）
mqtt:
enabled: false
cameras:
wansview:
ffmpeg:
inputs:
- path: rtsp://ユーザー:パスワード@192.168.1.159:554/live/ch0
roles:
- detect
- record
detect:
width: 1280
height: 720
fps: 5
objects:
track:
- person
- bicycle
- car
review:
alerts:
enabled: false
detections:
enabled: true
labels:
- person
- bicycle
- car
record:
enabled: true
continuous:
days: 0
motion:
days: 0
detections:
pre_capture: 5
post_capture: 5
retain:
days: 3
mode: motion
snapshots:
enabled: true
retain:
default: 3
設定のポイント
今回のキモはここ。
常時録画を完全に無効化
continuous:
days: 0
これを切らないと“ただの録画機”になる
動体検知だけの録画も無効
motion:
days: 0
「動き」ではなく「意味」に寄せる
検知対象を限定
objects:
track:
- person
- bicycle
- car
ノイズ削減（ここかなり効く）
イベント録画のみ有効化
record:
detections:
AI検知されたものだけ保存
前後5秒を確保
pre_capture: 5
post_capture: 5
これがあるから“ちゃんと使える動画”になる
IP固定は“気になる人だけ”
Wansview Q6 は IPアドレスを固定できない。
ONVIFを有効にしている場合、
Frigate側で自動検出されるため実用上は問題ない。
もし、
気持ち悪いならDHCP予約で固定で対応しよう。
まとめ
Frigateは確かに“簡単に動く”が、
何も知らずに触ると普通にハマる
- App設定
- yaml前提の設計
ここを押さえれば、一気に安定する。
実際に動かした結果
結論から言うと、
普通に動く。ただし軽くはない。
CPU使用率はおおよそ50％前後。
そのうち約40％をFFmpegが占めている。
映像のデコード処理が支配的で、
AI推論そのものよりも負荷が重い印象だ。
「AIが重い」のではなく「映像処理が重い」
ライブビュー
特定カメラのライブ映像は問題なく表示される。
画面上部のボタンで、
- オンデマンド録画
- スナップショット取得
などの操作も可能。
■ タイムライン（履歴）
ライブビューの履歴を押すと、画面の右側に、
直近の映像イベントがタイムライン表示される。
任意の時間にジャンプして再生できるのは便利だが、
正直、この操作はかなり重い。
■ ブラウズ画面（イベント一覧）
検知されたイベントはセグメント単位で一覧表示される。
- 車
- 人
- 自転車
など、カテゴリ別に整理されている。
■ 車イベント一覧（フィルタ）
特定カテゴリだけを抽出することも可能。
通過車両が時系列で並ぶため、 “流れ”が一目でわかる。
カメラの選択、日付の指定、並び替えなどが可能。
■ イベント詳細
個別イベントを開くと、
- スナップショット
- 前後動画（クリップ）
を確認・ダウンロードできる。
追跡オブジェクトの詳細を押すと、対象オブジェクトの認識の軌跡が表示されたりする。
イベント発生前後数秒の動画が自動で切り出される！
これが価値。大きなディスク節約になる。
■ 設定画面
設定やログ、外観の変更も可能。
翻訳に多少クセがあるが、日本語にも対応している。
■ まとめ
- 映像取得：OK
- AI検知：OK（人・車・自転車）
- イベント録画：OK（前後数秒）
- CPU使用率：約50％（うちFFmpeg約40％）
「成立している」が正しい評価
録画の挙動
Frigateは常時録画を前提にしたNVRではない。
今回の構成では、AIが検知したイベント部分だけがクリップとして保存される。
実際に保存されたファイルを見ると、出力はMP4形式で、
1ファイルあたりのサイズはおおむね1MB前後だった。
イベントの長さによっては2〜3MB程度になるものもあるし、
動きの激しさや、昼夜の差も大きい。
春日部の僻地の観測だから、参考までに見て欲しいが、
5時間の運用で生成された総イベント数は約543件。
このペースを24時間換算すると、およそ2600件前後になる。
単純計算では、1日あたりの保存容量は約3GB前後。
条件によって増減はあるが、多くても数GB台に収まる印象だ。
一方、同じカメラを元のRTSPストリームのままフル録画した場合は、
5分で約18MBだった。
これを24時間換算すると、約5.18GB/日になる。
イベント録画： 約3GB/日
フル録画 ： 約5GB/日
差はあるが、劇的ではない
つまり、容量差だけを見れば圧倒的な差ではない。
むしろ、イベントクリップがMP4で保存されることを考えると、
圧縮効率だけで劇的に得をするとは言いにくい。
それでもFrigateの価値は大きい。
保存された映像は、単なる動画ファイルではなく、
- 何が写っていたか
- いつ現れたか
- どのカテゴリだったか
まで含めて整理される。
車だけ、人だけ、自転車だけを一覧でき、
サムネイルから直接目的のイベントへ飛べる。
つまりFrigateは、
単なる「録画ソフト」ではなく、
意味のある映像だけを索引付きで残す仕組み
なのである。
保存ファイルをチェックしてみた
録画ファイルを確認していて、もう一つ気付いた点がある。
当然だが、Frigateは動画だけでなく、スナップショットやサムネイルも同時に生成している。
実際のディレクトリを確認すると、以下のような構成になっていた。
録画データ
動画データは日ごとに複数フォルダに分けて保存されている。
# pwd
/media/frigate/recordings/2026-04-10/02/wansview
# ls -lsh
total 101M
733K -rw-r--r-- 1 root root 723K Apr 10 11:00 00.01.mp4
365K -rw-r--r-- 1 root root 354K Apr 10 11:00 00.10.mp4
617K -rw-r--r-- 1 root root 605K Apr 10 11:00 00.19.mp4
581K -rw-r--r-- 1 root root 568K Apr 10 11:00 00.31.mp4
329K -rw-r--r-- 1 root root 319K Apr 10 11:00 00.40.mp4
589K -rw-r--r-- 1 root root 580K Apr 10 11:01 00.49.mp4
521K -rw-r--r-- 1 root root 497K Apr 10 11:01 01.01.mp4
329K -rw-r--r-- 1 root root 318K Apr 10 11:01 01.10.mp4
521K -rw-r--r-- 1 root root 505K Apr 10 11:01 01.19.mp4
477K -rw-r--r-- 1 root root 466K Apr 10 11:01 01.31.mp4
413K -rw-r--r-- 1 root root 402K Apr 10 11:02 02.01.mp4
553K -rw-r--r-- 1 root root 544K Apr 10 11:02 02.10.mp4
993K -rw-r--r-- 1 root root 984K Apr 10 11:02 02.19.mp4
521K -rw-r--r-- 1 root root 502K Apr 10 11:02 02.31.mp4
357K -rw-r--r-- 1 root root 348K Apr 10 11:02 02.40.mp4
369K -rw-r--r-- 1 root root 358K Apr 10 11:03 03.01.mp4
677K -rw-r--r-- 1 root root 665K Apr 10 11:03 03.10.mp4
1.1M -rw-r--r-- 1 root root 1.1M Apr 10 11:03 03.19.mp4
353K -rw-r--r-- 1 root root 344K Apr 10 11:03 03.31.mp4スナップショットデータ
スナップショットは日ごとにフォルダ分けされていなから、総量は大きく見えている。
# pwd
/media/frigate/clips
total 229M
512 drwxr-xr-x 2 root root 2 Apr 9 12:32 cache
512 drwxr-xr-x 2 root root 2 Apr 9 12:32 export
512 drwxr-xr-x 3 root root 3 Apr 9 12:38 previews
25K drwxr-xr-x 2 root root 439 Apr 10 12:23 review
512 drwxr-xr-x 3 root root 3 Apr 9 13:22 thumbs
129K -rw-r--r-- 1 root root 125K Apr 9 13:22 wansview-1775708548.795054-smg9zc-clean.webp
333K -rw-r--r-- 1 root root 323K Apr 9 13:22 wansview-1775708548.795054-smg9zc.jpg
81K -rw-r--r-- 1 root root 79K Apr 9 13:57 wansview-1775708579.077763-izz5yd-clean.webp
141K -rw-r--r-- 1 root root 130K Apr 9 13:57 wansview-1775708579.077763-izz5yd.jpg
89K -rw-r--r-- 1 root root 87K Apr 9 13:23 wansview-1775708581.465817-4vur26-clean.webp
149K -rw-r--r-- 1 root root 137K Apr 9 13:23 wansview-1775708581.465817-4vur26.jpg
89K -rw-r--r-- 1 root root 86K Apr 9 13:23 wansview-1775708622.424094-14fg1e-clean.webp
145K -rw-r--r-- 1 root root 135K Apr 9 13:23 wansview-1775708622.424094-14fg1e.jpg1イベントあたりの容量は概ね以下の通りだった。
・動画：約600KB
・スナップショット（JPEG＋WebP）：約200KB
合計すると約800KBとなり、
1200イベントで約1GB/dayに達する。
さらに、previewsやthumbsなどのキャッシュも生成されるため、
実際のストレージ消費はこれよりも多くなる。
Frigateはストレージ効率よりも、UIの応答性を優先した設計となっている。
今回は retention を3日としているため問題はないが、
長期間保存する場合は注意が必要だ。
「動画だけなら軽い」と思っていると、
思わぬところでストレージを食われる。
保存期間を30日以下にする運用ならば、目くじらを立てるほどのものではない
実用性の評価
結論から先に言う。
カメラは1台にしておけ
今回の構成（Pentium G4560 / GPUなし）では、
1カメラ運用でCPU使用率はおおよそ50％前後だった。
そのうち約40％はFFmpegによるデコード処理が占めている。
当然、他のサーバーは同時稼働させてはいない。
つまり、
ほぼ「映像処理でCPUが埋まっている」状態
■ 良い点
まず、成立している点。
- オンボロCPUでも動く
- 人・車・自転車の識別は実用レベル
- イベント録画は安定
- 誤検知は想像より少ない
「遊び」ではなく「実用」に入っている
■ 厳しい点
ただし、限界もはっきりしている。
- CPU負荷が重い（常時50％前後）
- H.265は特に厳しい（デコード負荷が高い）
- UI操作もやや重い
- カメラ追加の余力はほぼない
ここが重要。
仮に同じ条件でカメラをもう1台追加した場合、
CPUはほぼ確実に飽和する
つまり、
- 1台 → 成立
- 2台 → 怪しい
- 3台以上 → 現実的ではない
■ よくある勘違い
ここでやりがちなのがこれ。
「カメラ4台くらい余裕でしょ？」
無理。
触れば分かるが、
この構成はすでに“ギリギリ成立ライン”にいる。
ただの録画装置ではないことを忘れてはならない。
■ なぜこうなるのか
原因はシンプル。
AIではなく映像デコードがボトルネック
- H.265デコードが重い
- フル解像度入力
- CPUのみ処理
この3点が揃っている。
■ 向いている使い方
だから、この構成での正しい使い方はこれ。
- 監視対象を1箇所に絞る
- 「見る」ではなく「検知する」用途にする
- 常時監視ではなくイベント中心で使う
“広く見る”ではなく“1点を深く見る”
無論、潤沢なハードウェアリソースを使うつもりなら、この限りではない。
まとめ
前評判通り、Frigateは確かに低スペックでも動いた。
だがそれは、
「制約の中で成立する」
という意味だ。
Pentium G4560では、
- 1カメラ → 実用
- 複数カメラ → 厳しい
それでも、
「意味のある映像だけ残す監視」は確かに成立した
交通量調査には使うな ─ Frigate最大の落とし穴
ここで重要な話をしておく。
Frigateは「万能な監視カメラ」ではない
■ Frigate は交通量調査には向かない
一見すると、
- 車の通過数
- 人の流れ
などのトラッキングに使えそうに見える。
しかし、実際に動かしてみると挙動はこうなる。
Frigateは、対象がフレーム内に入ってから出るまでを
1つのイベントとしてまとめる。
そのため、
- 車が1台通過
- 続けて2台目が進入
- 自転車や歩行者も混在
このような状況でも、
すべて同一イベントに吸収される
■ イベントが“途切れない”
交通量が増えるとどうなるか。
イベントが途切れない
つまり、
- 常に誰かが写っている状態
- 検知が継続し続ける
結果として、
実質的に常時録画と同じ挙動、あるいはそれに限りなく近いものになる
■ 容量効率が逆転する
ここが重要。
Frigateはイベント単位で録画するが、
- イベントが長時間化
- H.264で保存
- 切り出しが効かない
この条件が揃うと、
H.265でフル録画した方が容量効率が良くなる
という逆転現象が起きる。
■ なぜ公式が「家の周り」ばかりなのか
Frigateの公式イメージが、ほぼすべて「住宅周辺」である理由はここにある。
- 出入りが限定される
- イベントが明確に分離される
- 無駄な録画が発生しにくい
■ 正しい使い方
つまり、Frigateはこう使うべきだ。
- 玄関
- 駐車場
- 家の前
- 裏庭
👉 イベントが“区切れる場所”専用
■ まとめ
Frigateは、
「交通量を測るツール」ではない
「意味のある出来事だけを残すツール」
この違いを理解しないと、
- 容量は減らない
- イベントをIndex化した甲斐がない
という状態になる。
最適化の余地
ここまでの結果を見ると、「もう無理では？」と思うかもしれない。
だが、改善の余地はある。
ただし、効果の大きさはそれぞれ違う。
■ detect解像度を下げる
これは一番手軽な調整。
detect:
width: 1280
height: 720
のように下げることで、推論負荷は軽減される。
ただし今回の構成では、
ボトルネックはFFmpeg（デコード）
そのため、
効果は限定的
■ サブストリームを使う（これが本命）
カメラ側にサブストリーム（低解像度）がある場合、
- detect：低解像度ストリーム
- record：高解像度ストリーム
という分離が可能。
これが一番効く
理由はシンプル。
デコード負荷そのものが下がる
今回は試していないが、Wansview Q6にも、640×360 という微妙なサブストリームはあったw
いまどきならせめて、HDくらいのサブストリームが欲しいところ…
■ H.264に変更（できれば）
H.265は圧縮効率が高い反面、
デコードが重い
そのため、
CPU環境ではH.264の方が軽くなる
ただしこれは、カメラ側で変更できる場合のみ
今回のQ6では選択できなかった。
■ Coral TPU導入（効果はあるが…）
Frigate公式が推奨しているのがこれ。
USB接続で使えるエッジTPUで、
AI推論部分をハードウェアオフロードできる。
推論負荷は確実に軽くなる
ただし、今回の構成では注意が必要。
ボトルネックはFFmpeg
つまり、
- 推論 → 軽くなる
- デコード → 変わらない
結果として、
劇的な改善にはならない可能性が高い
※ちなみに、秋月電子通商では売り切れだった..
■ 公式の前提スペック（ざっくり）
Frigateの思想はもともとこうだ。
- GPUまたはTPU前提
- 複数カメラ運用
- 高解像度映像
つまり今回のような構成は、
想定外ギリギリ
■ まとめ
最適化はできる。
だが、
ボトルネックを見誤ると意味がない
今回の構成では、
- 推論 → まだ余地あり
- デコード → ほぼ限界
「軽くしたいなら映像を軽くしろ」
コラム：素人お断り ─ 最安GPUと無限の苦労で叶える最適環境
Frigateを本気で軽くしたいなら、
GPUを使うのが王道だ。
選択肢は3つある。
- Coral TPU（簡単・高価）
- NVIDIA GPU（現実解）
- AMD ROCm（ロマン）
特に中古GPUは魅力的だ。
例えば、Quadro P600のようなカードは
3000円前後で入手できることもある。
これを使えば、
FFmpegのデコード
AI推論
の両方をGPUに逃がせる可能性がある。
ただし、
刺せば終わりではない
- ドライバ
- Docker連携
- hwaccel設定
ここを突破しないと意味がない。
さらにROCmに至っては、
「動けば奇跡」レベル
完全に記事の趣旨からは外れるが、
本気でやるならDockerは捨てた方がいい。
ベアメタルで組み、監視専用機として割り切る覚悟が必要になる。
つまりこれは、
金ではなく時間で殴る最適化
やるかどうかは、あなたの覚悟次第だ..
結論
いまも稼働させ続けているが、安定感は抜群だ。
CPUもファンが唸り出す一歩手前で踏ん張っており、
動作音も普段と変わらない。
これは、仕事に使える道具の匂いがする
おんぼろサーバーでも、AI監視カメラは成立する。
それが今回の結論だ。
そしてもう一つ、強く感じたことがある。
TrueNAS Appに並んでいるアプリたちは、
どれも実戦レベルの精鋭ばかりだということだ。
それを、わずかな手間で使える。
この価値は大きい
もし手元に、
- 使っていないネットワークカメラ
- 遊んでいるサーバー
があるなら、
一度試してみる価値はある。
ただし、
サーバーは電気を食う
今回の構成でも、24時間稼働で月500円程度は見ておいた方がいい。
そして、最後に現実の話。
複数台のカメラを“本気で”運用するなら、
クラウド型の完成品（例：Google Nest Cam）
の方が合理的だ。
それでも、
「動き」ではなく「意味」を記録するカメラ
という体験は、一度味わう価値がある。
後日談
丸1日運用してみたが、動作は非常に安定している。
フリーズや取りこぼしもなく、常用に耐えるレベルに達していると感じた。
検知設定についても見直しを行った。
人と自転車はほぼ同時に検出されるため、自転車のトラッキングは外し、「人」のみとした。
この方がイベントの整理としても分かりやすい。
また、用途によっては「車のみ」に限定するのも有効だと感じた。
人はフレームインからアウトまでの滞在時間が長く、結果として録画時間が伸びやすい。
容量を優先するなら、車検知に寄せる方が合理的だろう。
ゾーン指定もやってみた。
そして最後に余談。
2026年4月から自転車への青切符制度が導入されたが、
このカメラの前を通過する自転車で、一時停止を守る個体は――
ついに1台も観測されなかったw
