ha-llmvision レビュー: Home Assistant のカメラ映像をマルチモーダル LLM に読ませる統合

カメラ通知の「何か動いた」を文章に変える統合

ha-llmvision が解くのは、監視カメラの通知が持つ情報量の薄さだ。従来のモーション検知は「玄関で動きがあった」までしか言わない。誰が、何を、どの方向へ、という判断は人間が録画を巻き戻して行う。この統合はマルチモーダル LLM に画像や動画を渡し、プロンプトに応じた説明文や質問への回答を生成させる。対象は静止画だけでなく、動画ファイル、ライブカメラのフィード、Frigate のイベントまで含む。README は「Remembers people, pets and objects」とうたっており、人物やペット、物体をまたいだ記憶を持たせる設計が示されている。想定利用者は、Home Assistant を既に運用していて、カメラ台数が数台から十数台、通知のノイズに疲れている層だ。クラウド LLM の API キーを自分で用意できることが前提になる。

プロバイダ抽象化レイヤーとしての実装

アーキテクチャの中心は、プロバイダを差し替え可能にした抽象化だ。README の対応リストは OpenRouter、OpenAI、Anthropic、Google Gemini、AWS Bedrock、Azure、Groq、Ollama、Open WebUI、LocalAI、そして「any provider with OpenAI compatible endpoints」で締められている。つまり OpenAI 互換の API 形状さえ守れば、列挙されていないサービスも設定次第で接続できる。データの流れは、カメラまたは Frigate イベントから取得したフレームを /media 配下にスナップショットとして保存し、それをプロバイダへ送信、返ってきたテキストをセンサーや通知に流し込む、という順序になる。README は「Seamlessly updates sensors based on data extracted from camera streams, images or videos」と説明しており、抽出結果が Home Assistant のセンサー状態に反映される。分析済みイベントはタイムラインとして保持され、任意の Timeline Card でダッシュボードに表示できる。ストレージ、推論、表示が分離されている点は、後から保存先だけ差し替えたい場合に効いてくる。

HACS からの導入と /media マウントという最初の関門

導入は HACS 経由が正規ルートで、README はデフォルトの HACS リポジトリに登録済みだと明記している。手順は、HACS から LLM Vision をインストール、Home Assistant を再起動、設定のデバイスとサービスから LLM Vision を検索、デフォルト設定のまま送信、そして /media フォルダの準備、最後に統合ページへ戻って Add Entry から AI プロバイダを追加、という流れだ。ここで最初のつまずきが /media にある。README は「LLM Vision uses the more secure /media folder for storing snapshots」と述べ、Home Assistant Container で動かしている場合はコンテナ設定でフォルダを /media にマウントする必要があると注意している。スナップショットの保存先を /config ではなく /media に置く判断は、バックアップ対象から映像を外しつつ、ダッシュボードのメディアブラウザから参照できるようにする狙いだと読める。プロバイダの設定は統合ページの Add Entry から行い、認証情報はそこに入力する。

Frigate とブループリント、その役割分担

Frigate を既に使っている家庭では、検知そのものを Frigate に任せ、ha-llmvision はそのイベントを読む係に回る。README は分析対象として「Frigate events」を明示しており、検知ロジックを二重に持たない設計だ。Frigate 側のイベントにはラベルとスナップショットが付くため、LLM へ渡す入力の質が上がる。ブループリントも用意されており、README によれば「camera event notifications intelligently summarized by AI」を得られる。つまり自動化を一から書かなくても、カメライベント通知の要約という定型部分はテンプレートで覆える。ただしブループリントは通知の要約に特化した入口であり、任意のプロンプトでセンサーを更新したい場合は自分で自動化を組むことになる。Frigate を使っていない場合、検知の起点はカメラのモーションや手動トリガーになり、通知の精度は LLM 以前の段階で決まる。

ローカル推論を選べるが、それは無料を意味しない

プライバシーを重視するなら Ollama、Open WebUI、LocalAI を選べば映像は自宅ネットワークの外に出ない。README の対応リストにこの三つが並んでいる点は、クラウド API 前提の類似ツールとの明確な差だ。ただしローカル推論は、マルチモーダルモデルを実用的な速度で動かすハードウェアを要求する。README はモデル名も必要 VRAM も示していないため、自分の環境でどのモデルが現実的に動くかはこの資料からは判断できない。クラウド側を選んだ場合は逆のトレードオフが生じる。カメラ映像という、住居の間取りや生活時間帯を含むデータを外部 API に送ることになる。さらに従量課金のプロバイダでは、カメラ台数とイベント頻度に比例して費用が増える。動き検知のたびに推論を走らせる設定にすると、費用は読みにくい形で膨らむ。この統合は「動いたら常に LLM に聞く」構成を技術的には許すが、経済的には許さない場面が多い。

Frigate 単体、または汎用の画像解析 API との比較

比較対象として最も自然なのは Frigate 単体だ。Frigate は物体検出モデルをローカルで走らせ、person や car といったラベルを付けてイベントを記録する。高速で、外部送信がなく、費用も一定だ。一方で Frigate の出力はラベルと信頼度スコアであり、「宅配業者が荷物を置いて去った」のような文脈は出てこない。ha-llmvision はこの文脈生成の層を足すもので、検知の代替ではない。もう一つの比較軸は、汎用の画像解析 API を自分で Home Assistant の RESTful センサーやスクリプトから叩く構成だ。こちらの方が依存は少ないが、プロバイダごとのリクエスト形式、画像のエンコード、タイムラインの保存、ダッシュボード表示をすべて自作することになる。ha-llmvision はその配線を統合としてまとめ、プロバイダ切り替えを設定画面に寄せている。自作に抵抗がない人にとっては、統合を一つ増やすより REST コマンドを書く方が見通しが良い場合もある。

Apache-2.0 とメンテナンスの見取り図

ライセンスは Apache-2.0 で、特許条項を含む寛容なライセンスだ。Home Assistant のカスタム統合として配布されるため、改変や再配布の自由度は高い。ただし本記事は法的助言ではない。ソースを同梱して再配布する場合の NOTICE の扱いなど、具体的な義務は Apache-2.0 の原文と必要なら専門家の確認に当たるべきだ。メンテナンス面では、リポジトリはアーカイブされておらず、最終プッシュは 2026-09-05、直近のリリースは v1.7.2（2026-09-03）、その前が v1.7.2-beta.1 と v1.7.1 で、いずれもバグ修正と性能改善が中心だ。機能追加よりも安定化のフェーズにあると読める。更新コストは HACS 経由の更新と Home Assistant の再起動で、プロバイダ側の API 仕様変更に追随する必要がある点は他のクラウド連携と変わらない。README はバグ報告時にデバッグログを求め、デバッグは統合の設定ページから有効化できると説明している。

編集部の結論

すでに Home Assistant とカメラ、そして何らかの LLM プロバイダ契約を持ち、Frigate のイベント通知を文章として読みたい人には導入の余地がある。逆に、映像を外部 API に送れない環境や、プロバイダの従量課金を固定できない家庭には向かない。導入前に確認すべきは、/media フォルダがコンテナにマウントされているか、Frigate 連携を使うなら MQTT が既に動いているか、そして選んだプロバイダの料金体系がカメラ台数とイベント頻度に耐えるか。Ollama や LocalAI を選べば送信先は自宅内に閉じるが、その分マルチモーダルモデルを動かすハードウェア要件が自分の環境で満たせるかを先に確かめる必要がある。

公式情報源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. valentinfrlch/ha-llmvision on GitHub