DeepCamera レビュー: SKILL.md でカメラに VLM を足す設計とその代償
Open-Source AI Camera Skills Platform, AI NVR & CCTV Surveillance. Local VLM video analysis with Qwen, DeepSeek, SmolVLM, LLaVA, YOLO26. LLM-powered agentic security camera agent — watches, understands, remembers & guards your home via Telegram, Discord or Slack. Pluggable AI skills. OpenAI, Google, Anthropic or local AI. Runs on Mac Mini & AI PC.
ひと目でわかる
- これは何?
- DeepCamera はカメラ映像の推論をローカルに閉じ込め、能力ごとに SKILL.md を持つプラグインとして切り出す AI カメラ基盤である。JSONL の stdin/stdout プロトコルと env_config.py によるハードウェア自動判定が設計の軸だが、配布の中心は MIT のリポジトリではなくデスクトップアプリ Aegis に移っている。
- 誰に向いている?
- 既に RTSP カメラと自前の推論環境を持ち、YOLO 系の検出スキルを差し替えながら検証したいエンジニアには、skills.json と docs/skill-development.md を読んでスキル単体を動かすところから始める価値がある。逆に、ノーコードで監視を立ち上げたいだけの利用者にとって、このリポジトリは出発点にならない。
- 商用利用できる?
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている?
- されています。最後のコミットは 90 日前です。
- 何の言語で書かれている?
- 主に JavaScript です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
汎用 NVR が苦手とする「映像の中身を言葉にする」処理を差し替え可能にした
従来の NVR は動体検知と録画が中心で、何が映っているかを説明する処理は外側のツールに任されてきた。DeepCamera が解こうとしているのはこの境界で、README は「VLM scene analysis, object detection, person re-identification」をカメラ側のスキルとして列挙し、推論はすべてローカルで完結すると説明している。対象読者は、汎用 NVR では足りないがクラウドの映像解析 API にフレームを送るのは避けたい人である。リポジトリの構成そのものが想定利用者を示しており、skills/detection、skills/analysis、skills/segmentation、skills/annotation、skills/training、skills/automation、skills/integrations というディレクトリ単位で能力が分かれている。カメラを1台持っている個人が最初に触るのは detection 配下の yolo-detection-2026 であり、home-security-benchmark や model-training はむしろ評価や再学習を回したい層に向く。
スキルは JSONL の stdin/stdout で親プロセスと会話する
DeepCamera の中心にあるのは SKILL.md を持つモジュール群と、その間の通信規約である。README の図が示す流れはこうだ。カメラフィードが Frame Governor に入り、そこで 5 FPS に間引かれる。フレームは共有ボリュームに frame.jpg として書き出され、同時に stdin へ frame イベントが流れる。スキル側は stdout に detections を返す。この JSONL プロトコルは detection と segmentation の各スキルで共通なので、Aegis から見れば yolo-detection-2026 と yolo-detection-2026-coral-tpu は入れ替え可能な同一の口になる。面白いのは、映像そのものをパイプで渡さずファイル経由にしている点だ。フレームをディスクに置く以上、共有ボリュームの I/O と容量設計は利用者側の責任になる。5 FPS という数字も README の図に明記された値で、これを上げる設定が用意されているかは提示資料からは確認できない。
env_config.py がハードウェアを見てモデル形式を選ぶ
同じスキルを NVIDIA、AMD、Apple Silicon、Intel、CPU のどれでも動かすため、DeepCamera は skills/lib/env_config.py という共有レイヤを置いている。README のロードマップでは「auto-detect hardware, install matching frameworks, convert models to optimal format」と説明され、図では NVIDIA なら TensorRT、Apple Silicon なら CoreML、Intel なら OpenVINO IR、AMD と CPU なら ONNX に振り分けられるとされている。つまり利用者はモデル形式を自分で選ばない。ただし変換には時間がかかるはずで、初回起動時の待ち時間がどこに表示されるのかは資料に記述がない。Coral 版だけは別系統で、ai-edge-litert と libedgetpu を経由して Edge TPU delegate を使い、TPU が無ければ CPU にフォールバックする。README は Coral 版について約4msという推論時間を挙げているが、これはベンチマーク条件の記載を伴わない一つの数値であり、自分の環境の期待値として使うには根拠が足りない。
導入手順の本体は Aegis に移っており、CLI の記述は薄い
README の冒頭は SharpAI Aegis の紹介に割かれている。Aegis は DeepCamera のデスクトップコンパニオンで、LLM を使って環境構築、カメラスキルの設定、パイプライン管理を自動化するとされ、「no manual Docker or CLI required」と明記されている。配布チャネルも PyPI の sharpai-hub と GitHub Releases が並記される程度で、リポジトリを clone して docker compose up する類のコマンドは提示資料には出てこない。スキルを自分で書く場合の入口は docs/skill-development.md と docs/skill-params.md、そして skills.json によるレジストリ登録である。ここは率直に言って弱点だ。Aegis を使わずにヘッドレスで動かしたい層にとって、この README だけでは起動手順が組み立てられない。エッジ側の Linux に載せたい場合、Aegis の対応プラットフォームがどこまで広いかは資料から判断できない。
プライバシー変換とセグメンテーションは用途がはっきり違う
スキルカタログで目を引くのは depth-estimation である。README はこれを「anonymize camera feeds while preserving activity」と説明し、リアルタイムの深度マップへ映像を変換することで、活動は保ちつつ識別情報を落とす用途を示している。同じ映像を扱う sam2-segmentation は、クリックやボックスプロンプトでピクセル単位のマスクを作り、動画内のトラッキングにも対応するとされる。前者は出力を人に見せないための変換、後者は特定対象を切り出すための変換で、必要な計算資源も求められる精度も別物である。両者を同じ「映像処理スキル」として一括りに評価するのは避けたほうがよい。なお depth-estimation が顔検出に対してどの程度有効かは README に定量的な記述がなく、監視用途で匿名化を前提にするなら自分で確認するしかない。
home-security-benchmark は自前の評価軸を持つが、比較対象は限られる
analysis カテゴリの home-security-benchmark は、LLM と VLM のセキュリティ性能を測るための 143 項目の評価スイートだと README は述べている。ローカル VLM を監視に使う場合、モデル選定の判断材料が不足しがちなので、評価セットをリポジトリ内に持っていること自体は意味がある。ただしこの数値はあくまでこのスイートの設問に対するスコアであり、他社のベンチマークと直接比較できるものではない。Qwen、DeepSeek、SmolVLM、LLaVA といったモデル名が並ぶが、どのモデルをどの解像度で動かした場合の結果なのかは提示資料からは分からない。自宅のカメラ角度や照明条件は評価セットの前提と一致しない可能性が高く、スコアが良くても自分の環境で同じ挙動になるとは限らない。導入前の確認項目としては、このスイートを自分の映像で回せるかどうかのほうが重要である。
Frigate との違いは検出の粒度ではなく、スキルの交換単位にある
同じ領域のオープンソースとして Frigate が挙げられる。Frigate はカメラごとに検出器と録画を設定し、イベントを MQTT で外へ出す構成を取る。DeepCamera も mqtt、webhook、ha-trigger といった automation スキルを計画に置いており、方向性は重なる。違いは交換の単位だ。Frigate では検出器の選択が設定ファイル上の項目になるのに対し、DeepCamera では検出そのものが JSONL プロトコルに従う独立プロセスとして扱われ、skills.json に登録された別スキルと差し替えられる。YOLO を Coral に載せ替える、OpenVINO 版に切り替える、といった変更がアプリ側の再設定なしで済む設計になっている。裏を返せば、スキルプロセスの起動と停止、共有ボリュームの後始末、異常終了時の再起動を誰が担うかを理解しておく必要がある。プラグイン性は運用の複雑さと引き換えである。
MIT だが、配布の重心はリポジトリの外にある
ライセンスは MIT で、リポジトリのコードを fork して自前のスキルを足すことは許される。ただし利用者が実際に触るのは Aegis という別配布のデスクトップアプリであり、そのソースが同じ MIT で提供されているかは提示資料からは確認できない。ここは導入判断で見落とされやすい点だ。スキル側だけを自前のパイプラインに組み込む使い方と、Aegis ごと導入する使い方では、依存する範囲も更新の追い方も変わる。リリースは v3.4.3 が 2022 年、Aegis が 2026 年2月、v2026.3 が 2026 年3月という並びで、2022 年から 2026 年にかけて名称と配布形態が大きく変わっている。古い記事や手順を参照すると現在の構成と食い違う可能性がある。更新コストを見積もるなら、追うべき対象は skills.json と env_config.py、そして Aegis のリリースノートの3つに絞られる。
編集部の結論
既に RTSP カメラと自前の推論環境を持ち、YOLO 系の検出スキルを差し替えながら検証したいエンジニアには、skills.json と docs/skill-development.md を読んでスキル単体を動かすところから始める価値がある。逆に、ノーコードで監視を立ち上げたいだけの利用者にとって、このリポジトリは出発点にならない。最初に確認すべきは、Aegis を使わずにスキルを起動する手順が docs に残っているかどうか、そして depth-estimation の出力が顔検出に対して実際にどこまで有効かの2点である。
コミュニティノート