HOME Assistantサーバーと組み合わせるローカルLLMの最適構成

下記の記事で、古いIntel Mac mini（late 2014、1TB HDD）をHOME Assistantサーバーとして構成し小型のローカルLLMを組み込んだ例を紹介した。古いMac miniでどこまでできるかを確認する目的で構成したが、その構成では、LLMからチャットの応答が帰ってくるまでに約2分かかることが分かったので、あらためて、HOME Assistantサーバーに最適な機器や、そのサーバーと連携させるのに最適なLLMを調査し、機器をどの程度アップグレードすれば、HOME assistantを快適に使えるかを調べた。

（注）本記事の内容は正確性を保証するものではない。

---

Home Assistantサーバー候補（ローカルLLMと同居させる場合）

以下、ChatGPT 5.5 Thinkingとの会話。

Home Assistant機器＋ローカルLLM同居 比較表

機器・方式	Home Assistantの入れ方	常時稼働向き	Home Assistant用途の評価	ローカルLLM同居	同居時に使えるLLMサイズの目安	メリット	注意点	おすすめ度
Home Assistant Green	Home Assistant OS搭載済み	◎	非常に向く	△	0.5B〜1B程度	最も簡単。専用機として安定	4GB RAMなのでLLM同居には不向き	◎
Raspberry Pi 4 8GB	Home Assistant OS	◎	向く	○	1B〜3B程度	既に持っているなら有力。低消費電力	7B級はかなり遅い。SSD化推奨	◎
Raspberry Pi 5 8GB / 16GB	Home Assistant OS	◎	向く	○	8GBなら1B〜3B、16GBなら7Bも視野	Pi 4より処理に余裕	冷却・電源・SSD構成が重要	◎
Intel NUC / 省電力ミニPC	Home Assistant OS / VM / Container	◎	とても向く	◎	16GBで7B、32GBで13B級	Home AssistantとLLMを同居させやすい	PiやGreenより消費電力は高め	◎
Mac mini（Intel系・旧型）	macOS上のVMでHome Assistant OS	○	使える	○	8GBなら1B〜3B程度。7Bは厳しめ	既存Macを活用できる	古いIntel MacではLLM推論速度は控えめ	○
Mac mini（M系 / Apple Silicon）	macOS上のVMでHome Assistant OS、またはContainer	◎	向く	◎	16GBなら7B級、24〜32GBなら13B級、48〜64GBなら30B級以上も候補	低消費電力・高性能。Ollama等のローカルLLMと相性がよい	Home AssistantをVMで動かす場合、VM管理が必要。メモリは後から増設不可	◎
NAS	Home Assistant Container中心	◎	条件付きで使える	△〜○	x86 NASで8GB以上なら1B〜3B程度	NASを常時稼働しているなら追加機器不要	Container方式ではアドオンが使えない	○
Proxmoxサーバー	VMでHome Assistant OS	◎	とても向く	◎	16GBで7B、32GB以上で13B級、GPUありならさらに上	HA用VMとLLM用VM/Containerを分離できる	サーバー管理の知識が必要	○〜◎
Windows高性能PC	VM / Docker / WSL等	△	試用向き	◎	GPU搭載なら7B〜13B以上も可能	LLM性能は高い	常時稼働には不向き	△
Jetson Nano 4GB	Home Assistant Container中心	△	非主流	△	0.5B〜1B程度	AI実験機としては面白い	4GB RAMではHA＋LLM同居は厳しい	△
Jetson Orin Nano	Home Assistant Container中心	○	非主流だが可能	○〜◎	3B〜7B程度	画像認識・音声処理・AI補助機に向く	HA専用機には過剰。Docker/Linux管理が必要	△〜○
Arduino UNO Q	Containerなら可能性あり	△	実験向き	△	0.5B〜1B程度	センサー・制御・実験用途に向く	HA本体＋LLMサーバーには余裕が少ない	△

Home Assistant公式では、macOS上では Home Assistant OSを仮想マシンで動かす方式が案内されています。
Apple Silicon Macの場合はARM 64-bit系の仮想マシンとして扱う形になります。(Home Assistant)

現行のMac miniはApple M4 / M4 Pro構成で、M4モデルは10コアCPU・10コアGPU・16コアNeural Engine、M4 Proモデルは14コアCPU・20コアGPU・16コアNeural Engine、メモリは構成により24GB、32GB、48GB、64GBなどが選べます。(Apple)

LLMサイズの目安として、Ollamaのモデル説明では一般に 7Bは8GB以上、13Bは16GB以上、70Bは64GB以上のRAM が必要とされています。
Home Assistantを同居させる場合は、OS・VM・Home Assistant分のメモリを差し引いて考える必要があります。(Ollama)

Mac mini M系を入れた場合の結論

Home Assistant本体＋軽〜中量級ローカルLLMを1台で動かすなら、Mac mini M系はかなり有力です。

特におすすめは次のような考え方です。

用途	おすすめ構成
Home Assistant中心、LLMは軽く試す	Mac mini M系 16GB
Home Assistant＋7B LLMを実用的に使う	Mac mini M系 16GB〜24GB
Home Assistant＋13B LLMも試したい	Mac mini M系 24GB〜32GB
Home Assistant＋より大きなローカルLLMも視野	Mac mini M4 Pro 48GB〜64GB

あなたの用途では、Raspberry Pi 4 8GBをHome Assistant専用機にして、Mac mini M系をローカルLLM用にする構成が最も安定です。
ただし、1台にまとめたい場合は、Mac mini M系 24GB以上を選ぶと余裕があります。

---

Home Assistantサーバーと同居させないローカルLLM専用機候補

---

はい。Home Assistant本体とは別に、ローカルLLM専用機を用意する前提なら、候補はかなり変わります。
この場合、Home Assistant側は Raspberry Pi 4 8GB / Home Assistant Green / 省電力ミニPC などに任せ、LLM側は Mac mini M系・Windows GPU PC・Mac Studio・Jetson Orin Nano などから選ぶ形になります。

以下は、主に Ollama / llama.cpp / LM Studio などで、Q4量子化モデルを動かす前提の目安です。

ローカルLLM用機器の比較表

ローカルLLM用機器	常時稼働向き	使えるLLMサイズの目安	推論速度の目安	メリット	注意点	おすすめ度
Mac mini M系 16GB	◎	3B〜7B級	○	低消費電力、静音、Ollamaとの相性がよい	13B級はメモリに余裕が少ない	◎
Mac mini M系 24GB / 32GB	◎	7B〜13B級	○〜◎	Home Assistantとは別のLLMサーバーとして非常に扱いやすい	メモリは後から増設できない	◎
Mac mini M系 48GB / 64GB	◎	13B〜30B級	◎	省電力で中〜大きめのモデルを扱える	価格が上がる	◎
Mac Studio M4 Max	◎	30B〜70B級も候補	◎	大きめのLLMをローカルで使いたい場合に強い	Home Assistant連携だけなら過剰性能	○〜◎
Mac Studio M3 Ultra	○〜◎	70B級以上も候補	◎	大規模モデルをローカルで試す用途に強い	高価。家庭用HA連携にはかなり過剰	○
Windows GPU PC / RTX 5070 Ti 16GB級	△	7B〜13B級が快適、条件次第で30B級も候補	◎	GPU推論が速い。既存PCを活用できる	消費電力・発熱・騒音が大きい。常時稼働には不向き	○
Windows / Linux PC + RTX 4060 Ti 16GB級	○	7B〜13B級	○〜◎	16GB VRAM搭載GPUとして比較的現実的	GPU以外に本体の消費電力も考える必要あり	○
Intel / AMD 省電力ミニPC 32GB RAM	◎	7B〜13B級	△〜○	サーバーとして常時稼働しやすい。Linux運用に向く	GPUなしCPU推論だと遅め	○
Intel / AMD 省電力ミニPC 64GB RAM	◎	13B〜30B級	△〜○	大きめモデルをメモリ上に置ける	速度はGPU搭載機やM系Macに劣りやすい	○
Jetson Orin Nano 8GB	○	3B〜7B級	○	画像認識・音声処理・エッジAIとの併用に向く	8GB RAMなので大きなLLMは厳しい。構成調整が必要	△〜○
Jetson Nano 4GB	△	0.5B〜1B級	△	実験用途なら面白い	LLMサーバーとしてはかなり非力	△
Raspberry Pi 5 16GB	◎	3B〜7B級	△	省電力で常時稼働しやすい	CPU推論中心なので遅い。会話用途は軽量モデル向き	△〜○
Raspberry Pi 4 8GB	◎	1B〜3B級	△	省電力。既存機器を活用できる	7B級はかなり遅い	△
Arduino UNO Q 4GB	△	0.5B〜1B級	△	センサー・制御との組み合わせは面白い	ローカルLLMサーバー本体には不向き	△

Ollamaのモデル説明では、一般的な目安として 7Bモデルは8GB以上、13Bモデルは16GB以上、70Bモデルは64GB以上のRAM が必要とされています。
ただし、実際にはOS、バックグラウンド処理、コンテキスト長、量子化方式によって必要メモリは増減します。(Ollama)

Apple Siliconでは、OllamaがApple GPUのMetalアクセラレーションに対応しており、Apple Silicon版ではMetalが組み込まれています。
さらに、Ollamaは2026年3月にApple Silicon向けMLX対応のプレビューも発表しており、M系MacはローカルLLM用途との相性が良いです。(Ollama)

Mac miniは、M4 / M4 Pro構成で、M4 Proでは最大64GBのユニファイドメモリを選べます。
LLM用としては、16GBなら軽〜中量級、24GB〜32GBなら7B〜13B級、48GB〜64GBならさらに大きめという見方になります。(Apple)

Mac Studioは、M4 Maxで最大128GB、M3 Ultraで最大256GBのユニファイドメモリ構成があり、家庭用ローカルLLM機としてはかなり強力です。
Apple公式仕様でもM4 Maxは最大40コアGPU、M3 Ultraは最大80コアGPU構成です。(Apple)

NVIDIA GPUを使うWindows / Linux機は、OllamaがCompute Capability 5.0以上のNVIDIA GPUに対応しているため、CUDA対応GPUを活用できます。
たとえばRTX 5070 Ti 16GB級なら、7B〜13B級のローカルLLMはかなり実用的な候補になります。(Ollama)

Jetson Orin Nano Super Developer Kitは、8GB LPDDR5、1024 CUDAコア、32 Tensorコア、7W〜25Wの電力枠を持つエッジAI向け機器です。
LLM単体というより、カメラ認識・音声処理・Home Assistant連携AIノードとして使うと魅力があります。(nvidia.com)

用途別のおすすめ

用途	おすすめ機器
低消費電力で常時稼働するLLMサーバー	Mac mini M系 24GB / 32GB
7Bモデルを安定して使いたい	Mac mini M系 16GB以上、またはRTX 16GB搭載PC
13Bモデルも使いたい	Mac mini M系 24GB〜32GB、RTX 16GB搭載PC、省電力ミニPC 32GB
30B以上を試したい	Mac mini M系 48GB / 64GB、Mac Studio、64GB以上のPC
画像認識・音声処理もHome Assistantと連携したい	Jetson Orin Nano
既存Windows GPU PCを時々使う	RTX搭載Windows PC
電気代重視で軽量AIだけ使う	Raspberry Pi 5 16GB、Mac mini M系

結論

Home Assistantと分離するなら、ローカルLLM用の第一候補は Mac mini M系 24GB以上だと思います。
低消費電力・静音・導入の簡単さ・Ollama対応のバランスがよく、Home Assistant側とはAPI経由で連携しやすいです。

すでに RTX 5070 Ti 16GB搭載Windows PC があるなら、性能面では有力ですが、消費電力が気になる場合は、常時稼働ではなく「必要な時だけLLMサーバーとして起動」する使い方が現実的です。
（この方法は本記事で別途検討した　→　ローカルLLMをWindows PCに実装する場合のWindows PCの運用要領 ）

常時稼働させるサーバーとしてはMac mini（M系）が優秀。ただし、メモリの増設はできないため、ローカルLLMのグレードアップは制限を受ける。

Windows PCは消費電力が大きいので、ローカルLLMを組み込む機器としては不向きと考えていたが、通常はWindows PCをスリープ状態にしておき、ローカルLLMに高度な相談をするときは、HOME AssistantサーバーからWindows PCを起動し、その後、自動的にWindows PCをスリープ状態に戻すことができそうなので、その方法も検討すべき構成であることが分かった。

---

Home Assistantアドオンとは

Home Assistantアドオンとは、Home Assistant本体の周辺機能を追加するための「追加アプリ」のことです。
現在の公式ドキュメントでは、以前の “Add-ons” は Apps と呼ばれています。
公式説明では、AppsはHome Assistantの周辺機能を拡張する追加アプリで、たとえばMQTTブローカーを動かしたり、Sambaで設定ファイルを他PCから編集できるようにしたりするものです。(Home Assistant)

ざっくり言うと

Home Assistant本体が「スマートホームの中心」だとすると、アドオンはその横で動く補助ソフトです。

Home Assistant本体
  ├─ 照明・センサー・エアコンなどを管理
  ├─ 自動化を実行
  └─ ダッシュボードを表示

Home Assistantアドオン / Apps
  ├─ File editor
  ├─ Terminal & SSH
  ├─ Samba share
  ├─ Mosquitto broker
  ├─ Node-RED
  ├─ Zigbee2MQTT
  ├─ ESPHome
  └─ Matter / Thread関連ツールなど

代表的なアドオンの例

アドオン	何をするものか
File editor	configuration.yaml などをブラウザ上で編集する
Terminal & SSH	Home Assistant内でコマンド操作する
Samba share	MacやWindowsからHome Assistantの設定フォルダを開けるようにする
Mosquitto broker	MQTT通信の中継サーバー
Node-RED	視覚的に自動化フローを作る
ESPHome	ESP32/ESP8266系デバイスを管理・書き込みする
Zigbee2MQTT	Zigbee機器をMQTT経由でHome Assistantに接続する

つまり、アドオンは Home Assistantの中に入れる拡張機能というより、Home Assistant OS/Supervisorが管理してくれる別アプリ群 と考えると分かりやすいです。

「統合」と「アドオン」の違い

ここが少し分かりにくいです。

種類	役割	例
統合 / Integration	Home Assistant本体が機器・サービスとつながるための機能	SwitchBot、EPSONプリンタ、Apple TV、Matter、Ollama
アドオン / Apps	Home Assistantの横で動く追加アプリ	File editor、Samba、Mosquitto、Node-RED、ESPHome

たとえば Mosquitto broker はアドオンとして動くMQTTサーバーです。
一方で、Home AssistantがそのMQTTサーバーを使って機器とやり取りするためには、別途 MQTT統合 を使います。

なぜNASのContainer方式では使えないのか

Home Assistant公式では、Apps / Add-ons は Home Assistant OS方式でインストールした場合のみ利用可能 と説明されています。
Container方式など、他の方法でHome Assistantを入れた場合はAppsを使えません。(Home Assistant)

理由を簡単に言うと、Home Assistant OSには Supervisor という管理役がいて、アドオンのインストール・起動・更新・ログ管理などをまとめて面倒見てくれます。

Home Assistant OS
  ├─ Home Assistant本体
  ├─ Supervisor
  └─ アドオン / Apps

一方、NASのContainer方式では、Home Assistant本体だけをDockerコンテナとして動かします。

NAS / Docker
  └─ Home Assistant Container

この場合、Supervisorがないので、Home Assistantの画面から「アドオンストア」を使って追加アプリを入れることができません。

ではNASでは使えない機能が多いのか

完全に使えないわけではありません。
多くのアドオン相当機能は、NAS側で別のDockerコンテナとして手動で動かすことができます。

Home Assistant OSなら	NAS Container方式なら
アドオンストアからMosquittoを入れる	NASのDockerでMosquittoコンテナを別途作る
アドオンストアからNode-REDを入れる	Node-REDコンテナを別途作る
アドオンストアからESPHomeを入れる	ESPHomeコンテナを別途作る
File editorをアドオンで入れる	NASのファイル共有やエディタで編集する
Samba shareをアドオンで入れる	NAS本体の共有機能を使う

Home Assistant公式ブログでも、Container方式を使う場合、多くのアドオンはHome Assistantの横で別コンテナとして動かせると説明されています。(Home Assistant)

どちらがよいか

方式	向いている人
Home Assistant OS	画面から簡単に管理したい。 アドオンを使いたい。 初心者〜中級者向き
NASのContainer方式	DockerやNAS管理に慣れている。 アドオン相当機能を自分で別コンテナ管理できる
NAS上の仮想マシンでHome Assistant OS	NASを使いつつ、アドオンも使いたい

NASを使う場合でも、NASに仮想マシン機能があれば、NAS上にHome Assistant OSを仮想マシンとして入れることでアドオンを使える可能性があります。

あなたの用途で重要そうなアドオン

Home Assistantをこれから本格的に使う場合、特に重要になりやすいのは次のあたりです。

目的	便利なアドオン
configuration.yaml を編集したい	File editor / Studio Code Server
MacやWindowsから設定フォルダを開きたい	Samba share
コマンド操作したい	Terminal & SSH
MQTT機器を使いたい	Mosquitto broker
複雑な自動化を作りたい	Node-RED
ESP32系センサーを作りたい	ESPHome
Zigbee機器を増やしたい	Zigbee2MQTT

結論として、アドオンはHome Assistantを便利にする追加アプリ群です。
NASのContainer方式でも代替はできますが、Home Assistantの画面から簡単に入れて管理できる便利さは失われる、という意味で「Container方式ではアドオンが使えない」と説明しました。

configuration.yaml に「template:」という項目を追加するのに「Studio Code Server」を使った。設定ファイル編集用のエディタとして使え、自分で設定ファイルの保存場所を調べたり、別途、エディタを用意する必要がないので便利。
それだけ、configuration.yaml 編集は日常の作業か。

ESPHomeのほか、Node-REDまで連携できることが分かった。Node-REDとの連携も楽しみ。たしかに、多様な機器と連携できることはHOME Assistantの大きな強み。

---

各サイズのLLM性能とHOME Assistantに最適なローカルLLM候補

結論から言うと、Home Assistantと組み合わせるローカルLLMは「7B〜8B級」が最もバランスがよいです。
1B〜3B級は力不足、13B〜14B級は余裕あり、30B級以上はHome Assistant制御だけなら過剰気味です。

ただし、これは Q4量子化モデル、かつ Home Assistant側で公開するエンティティを絞る前提です。
Home Assistant公式のOllama統合では、ローカルLLMでHome Assistantを制御する場合、公開エンティティは25個未満を推奨し、小さいモデルほどミスが増えると説明されています。
また、Home Assistantを制御できるのは「Tools」に対応したモデルに限られます。(Home Assistant)

まず、Home Assistant側でLLMにできること

Home AssistantのAssistだけでも、照明のオン・オフ、明るさや色の変更、カーテンやガレージドア、シーン・スクリプト、メディアプレイヤー、掃除機、買い物リスト、日時確認、タイマーなどは扱えます。
Assistで操作するには対象エンティティをAssistに公開し、名前やエリア名を適切に設定する必要があります。(Home Assistant)

LLMを組み合わせると、単なる定型文コマンドではなく、たとえば「キッチンが暗いから何とかして」のような曖昧な表現を解釈したり、公開済みセンサーの状況を要約したり、会話の文脈を引き継いだりできます。
Home Assistant公式も、通常のAssistは定型的なホーム制御に強く、AIはより自由な質問や曖昧な依頼に向くと説明しています。(Home Assistant)

ただし、LLMにできることは無制限ではありません。
Home AssistantのLLM APIはAssist APIをLLMに公開する仕組みで、公開されたエンティティとAssistで可能な操作が中心です。
公式開発者ドキュメントでは、LLM APIはHome Assistantを取得・制御できる一方、管理作業はできないとされています。(developers.home-assistant.io)

LLMサイズ別：Home Assistant用途で何ができるか

LLMサイズ	代表的な目安	Home Assistantでできること	バランス評価	向く機器例
0.5B〜1B級	超軽量モデル	雑談、簡単な言い換え、単純な分類程度。Home Assistant制御は不安定になりやすい	力不足	Raspberry Pi、Arduino UNO Q、Jetson Nanoの実験用途
1.5B〜3B級	小型モデル	「照明をつけて」程度の単純な意図理解、少数エンティティの状態確認、簡単な要約	やや力不足	Raspberry Pi 4/5、低消費電力ミニPC
4B級	軽量実用モデル	少数の部屋・機器なら自然文制御、センサー要約、短い会話が可能	最低限実用	Jetson Orin Nano、Mac mini M系、軽量GPU PC
7B〜8B級	標準的な小型実用モデル	照明・エアコン・センサー確認・スクリプト実行・買い物リスト・曖昧な依頼の解釈	最もバランスがよい	Mac mini M系 16GB以上、 RTX 8GB以上、 ミニPC 16GB以上
13B〜14B級	中型モデル	複数部屋・複数条件の解釈、スクリプト選択、状況説明、簡単な自動化案の作成	余裕あり	Mac mini M系 24GB以上、 RTX 16GB、 ミニPC 32GB
20B〜32B級	大きめ中型モデル	多数エンティティの把握、複雑な状態要約、MCP連携、より自然な対話、設定相談	高性能。家庭用HA制御だけならやや過剰	Mac mini M系 48GB以上、 Mac Studio、 RTX 24GB級
70B級以上	大型モデル	高度な推論、複雑な自動化設計、トラブルシュート、複数情報源を使う相談	Home Assistant制御だけなら過剰	Mac Studio大容量、 RTX 4090/5090級複数GPU、 高性能サーバー

Ollamaのモデル説明では、一般的な目安として 7Bは8GB以上、13Bは16GB以上、70Bは64GB以上のRAM が必要とされています。
実際には、量子化方式、コンテキスト長、OSの使用メモリ、同時実行数によって余裕を見ておく必要があります。(Ollama)

Home Assistant機能ごとの「必要なLLMサイズ」

Home Assistantでやりたいこと	必要なLLMサイズ	判断
決まった音声コマンドで照明・スイッチ・エアコンを操作	LLM不要〜1B	Assistだけで十分な場合が多い
「リビングを少し明るくして」など曖昧な自然文制御	4B〜8B	7B〜8Bが安定しやすい
センサー状態の要約：「家の様子を教えて」	4B〜8B	公開エンティティが少なければ4Bでも可
複数条件の判断：「暑くて暗いならエアコンと照明を調整」	7B〜14B	7B以上が現実的
スクリプトの選択：「出かける準備をして」	7B〜14B	スクリプト化してLLMに選ばせるのが安全
自動化の名前・説明・カテゴリ提案	7B〜14B	AI Tasks用途。13B級だと余裕
カメラ画像を見て状況判断	Vision対応モデルが必要	サイズだけでなく画像対応が必須
複雑な自動化YAMLの作成・修正相談	13B〜32B以上	30B級以上はかなり余裕
Home Assistant全体の設計相談・MCP連携・外部情報も含む相談	13B〜70B	目的次第。制御だけなら過剰

Home Assistantでは、LLMにスクリプトを公開して能力を拡張できます。
たとえば「少し外出する」という曖昧な依頼を、あらかじめ定義した「外出用スクリプト」に結びつける運用ができます。
これは、LLMに勝手な判断をさせるより安全です。(Home Assistant)

さらに、Home AssistantのAI Tasksでは、テンプレート、スクリプト、自動化からAIを呼び出し、画像などの添付ファイルを渡したり、JSONのような構造化出力を求めたりできます。
公式ブログでは、カメラ画像から鳥の数を数えてセンサー値にする例が紹介されています。(Home Assistant)

実測・ベンチマークから見たサイズ感

Home Assistant公式ブログでは、Home LLM Leaderboardに言及し、最近のローカルモデルは 8GB以上のVRAMを使うモデルならクラウドモデルに近づいていると説明しています。(Home Assistant)

Leaderboard上では、Home AssistantのAssist用途で、たとえば qwen3-1.7bは35.9%、qwen3-4b-instructは71.7%、qwen3-8bは82.8%、qwen3-14bは79.3%、gpt-oss-20bは87.6%、qwen3-30b-a3b-instructは83.9% といった結果が示されています。
小型モデルでは急に性能が落ち、7B〜20B級で実用域に入りやすいことが分かります。
ただし、このLeaderboardはサンプル数や未評価モデルがあるため、結果は絶対評価ではなく目安として見るべきです。(GitHub)

サイズ別の具体的な評価

0.5B〜1B級：Home Assistant制御には基本的に力不足

このクラスは、軽量な雑談、単純な分類、短文の言い換えには使えます。
しかし、Home Assistantの制御では、エンティティ名、部屋名、操作対象、意図、制約を正しく解釈する必要があります。

向く使い方

用途	評価
「このセンサー値を短く説明して」	△
「今日の状態を一言で要約」	△
照明・エアコン操作	×〜△
スクリプト実行	△
自動化作成支援	×

判断：力不足です。
Home Assistant本体と直接組み合わせるより、実験用・学習用と考えた方がよいです。

---

1.5B〜3B級：軽い会話と少数機器なら可能

このクラスになると、簡単な自然文理解はできます。
ただし、Home Assistantの制御では、対象が増えるほど間違いやすくなります。

向く使い方

用途	評価
少数の照明・スイッチ操作	△〜○
センサー1〜数個の状態説明	○
「寒い？」などの簡単な判断	△
買い物リストやタイマーとの会話	△
複数部屋・複数条件の制御	×〜△

判断：やや力不足です。
公開エンティティを10個前後に絞り、「リビング」「寝室」など対象を限定すれば使えますが、安定運用には不安があります。

4B級：最低限のローカルAI Assistとして使える

4B級は、Home Assistantと組み合わせる場合の「軽量実用ライン」です。
ただし、モデルの種類による差が大きく、Tools対応や日本語性能が重要です。

向く使い方

用途	評価
照明・スイッチの自然文制御	○
センサーの簡単な要約	○
「暗いから明るくして」程度の解釈	○
スクリプトの選択	△〜○
自動化案の作成	△
多数エンティティの把握	×〜△

判断：最低限実用です。
Jetson Orin NanoやMac mini M系で軽く動かすなら候補になります。
ただし、Home Assistant用として安心して使うなら、次の7B〜8B級の方が無難です。

7B〜8B級：Home Assistantとのバランスが最もよい

このクラスが、家庭用Home AssistantとローカルLLMを組み合わせる場合の本命です。

できること

用途	評価
照明、スイッチ、カーテン、エアコンの自然文制御	○〜◎
センサー状態の要約	◎
複数の部屋・機器を含む依頼	○
スクリプト実行の判断	○〜◎
買い物リスト、タイマー、会話の文脈引き継ぎ	○
自動化の説明・名前付け	○
自動化YAMLの本格作成	△〜○

判断：最もバランスがよいです。
Home Assistant側の機能は、そもそも「公開エンティティを制御する」「スクリプトを実行する」「状態を要約する」という性格が強いため、7B〜8B級でかなりの範囲をカバーできます。
Home Assistant公式の2024.8リリースでも、ローカルLLM実験ではLlama 3.1 8Bと公開エンティティ25個未満が推奨されていました。(Home Assistant)

13B〜14B級：中規模のスマートホームなら余裕あり

13B〜14B級になると、曖昧な依頼や複数条件の解釈が安定しやすくなります。
特に日本語で自然に話したい場合、7B級より余裕が出やすいです。

できること

用途	評価
複数部屋の状態把握	◎
センサーをまたいだ状況説明	◎
「寒いけど電気代を抑えて」などの柔らかい依頼	○〜◎
スクリプトやシーンの適切な選択	◎
簡単な自動化提案	○〜◎
YAML作成・修正相談	○
カメラ画像解析	Vision対応モデルなら○

判断：余裕があります。
Mac mini M系 24GB以上、RTX 16GB級、32GB RAMのミニPCなら、Home Assistant用のローカルAIとしてかなり使いやすいです。
単純な照明操作だけなら過剰ですが、センサー要約や自動化支援まで使うなら良い選択です。

20B〜32B級：高度な相談・自動化支援まで視野

このクラスは、Home Assistantの「操作」よりも、「設計」「相談」「整理」に強くなります。

できること

用途	評価
多数エンティティの要約	◎
複雑な条件の解釈	◎
自動化の設計相談	◎
YAMLやテンプレートの作成支援	○〜◎
MCP経由で外部ツールも含めた相談	◎
日常的な照明・家電操作	◎だが過剰

判断：高性能ですが、Home Assistant制御だけならやや過剰です。
ただし、あなたのようにHome Assistant、MCP、ローカルLLM、センサー、ブログ整理などをまとめて試す用途なら、30B級は十分意味があります。

Home AssistantのMCP Server統合では、外部のLLMクライアントがHome Assistantの情報にアクセスしたり、公開エンティティを制御したりできます。
公式ドキュメントでは、MCP経由でも制御できるのは公開されたエンティティに限られると説明されています。(Home Assistant)

70B級以上：Home Assistant制御には基本的に過剰

70B級以上は、Home Assistantの照明・センサー・スクリプト制御だけなら明らかに過剰です。
ただし、次のような用途では意味があります。

用途	評価
Home Assistant構成全体の設計相談	◎
大量のエンティティ・自動化の整理	◎
複雑なYAML、テンプレート、MCP連携設計	◎
カメラ・ログ・センサーを組み合わせた高度分析	◎
日常の家電操作	過剰

判断：Home Assistant用ではなく、家庭内AIサーバー用です。
家の制御だけなら7B〜14Bで十分です。
70B級は「Home Assistantも扱える高性能ローカルAI」と考える方が自然です。

あなたの用途に合わせた現実的な選び方

目的	推奨LLMサイズ	理由
Home Assistantの音声操作を少し賢くしたい	7B〜8B	最もバランスがよい
日本語で自然に会話しながら家電制御したい	8B〜14B	誤解が減りやすい
センサー状態の要約や外出・在宅判断をさせたい	8B〜14B	文脈処理に余裕がある
自動化の作成・修正も相談したい	13B〜32B	設計支援に強い
画像認識・カメラ解析もしたい	Vision対応の7B〜32B	サイズより画像対応が重要
Home Assistant以外の家庭内AIサーバーにもしたい	30B以上	汎用AIとして使いやすい
電気代重視で最低限だけ試したい	3B〜4B	ただし安定性は妥協

最終結論

Home Assistantと組み合わせるなら、次のように考えるのが現実的です。

LLMサイズ	Home Assistantとの相性
1B以下	力不足
3B級	実験用
4B級	最低限実用
7B〜8B級	最もバランスがよい
13B〜14B級	余裕があり安心
20B〜32B級	高度な相談・自動化支援向き
70B級以上	Home Assistant制御だけなら過剰

あなたの構成候補で言えば、Home Assistant本体はRaspberry Pi 4 8GBやHome Assistant Greenに任せ、ローカルLLMはMac mini M系 24GB以上で7B〜14B級を動かすのが、安定性・消費電力・実用性のバランスが最もよいと思います。

手元にRTX 5070 Ti 16GB搭載Windows PCがあるので、13B〜14B級を狙いたいところ。使う時だけ、Windows PCをスリープから起こして使うことができるようなので、現時点では、この構成がアップグレードの選択肢の1つ。また、通常の制御などはローカルLLMで行い、高度な相談のときだけ、クラウドLLMの安いモデルを使うということもできるようなので、この構成がもう1つの選択肢である。

---

Vision対応のLLM

はい。Home Assistantと組み合わせる前提なら、Vision対応LLMは大きく クラウド型 と ローカル型 に分けて考えるのが分かりやすいです。

Home Assistantでは、AI TaskやOpenAI Conversationがカメラ画像・ファイル添付に対応しており、AI Taskでは画像を渡してJSONなどの構造化出力を得る使い方もできます。
つまり、ドアホン画像、監視カメラ画像、ゴミ箱・郵便物・照明状態の確認などにVision LLMを使えます。(Home Assistant)

Vision対応LLM比較表：クラウドモデル

モデル	種別	画像 入力	Home Assistantでの主な用途	料金感	評価
Gemini 3.1 Flash-Lite Preview	クラウド	○	カメラ画像の簡易判定、宅配物・ゴミ箱・人影の有無、低コスト大量処理	入力 $0.25 / 100万トークン、出力 $1.50 / 100万トークン	費用重視なら第一候補
Gemini 3.1 Flash	クラウド	○	画像説明、複数条件の判定、通知文生成	入力 $0.50 / 100万トークン、出力 $3.00 / 100万トークン	性能と価格のバランスがよい
Gemini 3.1 Pro	クラウド	○	複雑な画像理解、設定相談、画像＋長文の高度分析	入力 $2.00 / 100万トークン、出力 $12.00 / 100万トークン	HA画像判定だけならやや高性能
GPT-5.4 mini	クラウド	○	画像＋Home Assistant設定相談、カメラ画像の説明、YAML相談	入力 $0.75 / 100万トークン、出力 $4.50 / 100万トークン	OpenAI系の低〜中価格候補
GPT-5.4	クラウド	○	複雑な自動化設計、画像＋設定ファイルの相談	入力 $2.50 / 100万トークン級	HAの画像判定だけならやや過剰
GPT-5.5	クラウド	○	高度な画像理解、複雑なトラブルシュート、設計相談	入力 $5.00 / 100万トークン級	高度相談用。 常用には高め
Claude Haiku 4.5	クラウド	○	画像説明、長めの説明文、簡単な状況判断	入力 $1 / 100万トークン、出力 $5 / 100万トークン	相談文・説明文に向く
Claude Sonnet 4.6	クラウド	○	複雑な画像分析、設計相談、エラー原因分析	入力 $3 / 100万トークン、出力 $15 / 100万トークン	高性能だが常用は高め

OpenAIの最新モデル群は、テキストと画像入力に対応し、テキスト出力を行うVision対応モデルとして案内されています。GPT-5.4 miniも入力にテキスト・画像、出力にテキストをサポートします。(OpenAI開発者)

Gemini 3.1 Flash-Liteは「高ボリュームのエージェントタスク、翻訳、単純なデータ処理向けの低コストモデル」とされ、テキスト・画像・動画入力の料金も低めです。
Gemini 3.1 Flashはその上位のバランス型、Gemini 3.1 Proは高度分析向けと考えるとよいです。(Google AI for Developers)

Claudeは現在のモデルがテキスト・画像入力、テキスト出力、Visionに対応していると公式に説明されています。
Claude Haiku 4.5は安価寄り、Sonnet 4.6は高性能寄りです。(Claude)

Vision対応LLM比較表：ローカルモデル

モデル	種別	サイズ	必要機器の目安	Home Assistantでの主な用途	評価
Gemma 3 4B	ローカル	4B	Mac mini M系、軽量GPU PC、Jetson Orin Nano級	簡単な画像説明、明暗確認、物体の有無判定	軽量ローカルVisionの入口
Gemma 3 12B	ローカル	12B	Mac mini M系 24GB以上、GPU 12GB〜16GB級	画像説明、通知文生成、簡単な状況判断	ローカルで使いやすい中間候補
Gemma 3 27B	ローカル	27B	Mac mini 48GB以上、GPU 24GB級以上	複雑な画像理解、説明文生成	HA用途だけならやや過剰
Qwen2.5-VL 3B	ローカル	3B	Jetson Orin Nano、Mac mini M系、軽量PC	エッジAI、簡単なカメラ画像判定	軽量だが精度は妥協
Qwen2.5-VL 7B	ローカル	7B	Mac mini M系 16GB以上、GPU 8GB〜12GB級	カメラ画像の説明、物体確認、簡単なOCR、ゴミ箱・宅配物判定	Home Assistant用ローカルVisionの本命
Qwen2.5-VL 32B	ローカル	32B	Mac mini 64GB以上、GPU 24GB以上	図表・文字・複雑な画像理解	高性能。家庭用画像判定だけなら過剰気味
Llama 3.2 Vision 11B	ローカル	11B	8GB VRAM以上	画像説明、OCR、一般的な画像質問	実用候補。ただしやや重い
Llama 3.2 Vision 90B	ローカル	90B	64GB VRAM級	高度な画像理解	家庭用HA用途ではほぼ過剰

OllamaではVisionモデルが画像とテキストを同時に受け取り、画像の説明・分類・質問応答ができると説明されています。(Ollamaのドキュメント)

Gemma 3はテキストと画像を処理できるマルチモーダルモデルで、270M、1B、4B、12B、27Bなどのサイズが用意されています。(Ollama)

Qwen2.5-VLは、物体認識だけでなく、画像内のテキスト、図表、アイコン、レイアウトの分析、JSONなどの構造化出力にも強みがあると説明されています。
Home Assistantで「カメラ画像から状態を判定してセンサー値化する」用途には相性がよいです。(Ollama)

Llama 3.2 Visionは11Bと90Bがあり、Ollamaでは11Bに少なくとも8GB VRAM、90Bに少なくとも64GB VRAMが必要とされています。(Ollama)

Home Assistant用途別のおすすめ

用途	おすすめモデル	理由
ドアホン画像から「人・荷物・動物」を判定	Gemini 3.1 Flash-Lite / Qwen2.5-VL 7B	低コスト・実用性のバランスがよい
ゴミ箱が出ているか、郵便物があるか判定	Qwen2.5-VL 7B / Gemini 3.1 Flash	画像中の物体判定に向く
カメラ画像を見て通知文を自然文で作成	Gemini 3.1 Flash / GPT-5.4 mini / Claude Haiku 4.5	文章生成も含めるならクラウドが安定
日本語を含む画像・掲示物・機器表示の読み取り	Qwen2.5-VL 7B以上 / GPT-5.4 mini / Gemini Flash	OCR的な理解が必要
Home Assistantの画面キャプチャを見て設定相談	GPT-5.4 mini / Claude Haiku 4.5 / Claude Sonnet 4.6	画像＋設定説明の相談に向く
複雑な自動化設計と画像判定条件の整理	Claude Sonnet 4.6 / GPT-5.4 / Gemini Pro	推論力が必要
外部送信せず自宅内だけで画像判定	Qwen2.5-VL 7B / Gemma 3 12B	プライバシー重視ならローカル

実用上のおすすめ構成

役割	推奨
通常の家電操作	ローカル7B〜8BテキストLLM
カメラ画像の軽い判定	Qwen2.5-VL 7B または Gemma 3 12B
低コストなクラウド画像判定	Gemini 3.1 Flash-Lite
画像＋説明文生成	Gemini 3.1 Flash または GPT-5.4 mini
画像＋高度な設定相談	Claude Haiku 4.5、難しい場合は Claude Sonnet 4.6
最終確認・複雑な設計	GPT-5.4 / GPT-5.5 / Claude Sonnet 4.6

私ならこう選びます

Home Assistantと組み合わせるなら、最初は次の3段構成がよいです。

優先度	モデル	使い方
1	Qwen2.5-VL 7B	ローカル画像判定の本命
2	Gemini 3.1 Flash-Lite	安いクラウドVisionの予備・大量処理用
3	GPT-5.4 mini または Claude Haiku 4.5	画像を見ながら設定相談・説明文作成

最終的な結論は、プライバシー重視なら Qwen2.5-VL 7B、費用重視のクラウドなら Gemini 3.1 Flash-Lite、相談の質まで重視するなら GPT-5.4 mini / Claude Haiku 4.5です。
Home Assistantのカメラ画像解析だけなら、GPT-5.5やClaude Sonnet級は普段使いには高性能すぎることが多いです。

---

ローカルLLMとクラウドLLMの使い分け

はい、できます。しかも、Home Assistantの現在のAI機能なら、かなり現実的です。

結論としては、次の構成がよいです。

用途	使うLLM	接続先
日常の家電操作・状態確認	ローカル7B〜8B級	Ollamaなど
「家の様子を教えて」程度の要約	ローカル7B〜8B級	Ollamaなど
自動化の名前・説明・整理	クラウドLLM または高性能ローカル	OpenAI / Claude / Gemini / OpenRouter
複雑な自動化設計・YAML相談	クラウドLLM	OpenAI / Claude / Gemini等
Web情報を含む相談	クラウドLLM	Gemini / OpenAI等

Home Assistantでは、OpenAI、Anthropic、Google Gemini、Ollama、OpenRouterなどをAI連携として使えます。
OpenAI統合はConversationとAI Taskのサブエントリを持ち、モデルやHome Assistant制御可否を設定できます。(Home Assistant)
Anthropic統合もconversationとai_taskエンティティを提供します。(Home Assistant)
Google Gemini統合も会話エージェントとして使え、Home Assistant制御を許可するかどうかを選べます。(Home Assistant)

切り替えは簡単か

手動切り替えは比較的簡単です。
完全自動切り替えは工夫が必要です。

切り替え方法	簡単さ	内容
Voice Assistantを分ける	◎	「通常用：ローカル」「相談用：クラウド」の2つのアシスタントを作る
AI Taskのentity_idを指定する	◎	自動化・スクリプトごとに、ローカルLLMかクラウドLLMかを指定する
デフォルトAI Taskを切り替える	○	Suggest with AIなどで使うAIをまとめて変えられる
キーワードで自動振り分け	△	スクリプトやカスタム構成で実現可能だが、標準UIだけでは少し工夫が必要
完全にAIが判断して切り替える	△〜×	可能ではあるが、誤振り分け対策が必要

Home AssistantのAI Taskでは、タスクごとに使うAI Taskエンティティを指定できます。
entity_idを省略した場合は、設定済みの優先AI Taskエンティティが使われます。(Home Assistant)
さらに、デフォルトAI Taskエンティティを設定しておくと、AI Tasksを使う自動化を後から別モデルへ移行しやすくなります。(Home Assistant)

おすすめ構成

一番分かりやすいのは、2種類のAIを明確に分ける方法です。

名前の例	中身	用途	Home Assistant制御
Assist Local	Ollama 7B〜8B	照明、エアコン、センサー確認、日常操作	許可する
Assist Cloud Consultant	OpenAI / Claude / Gemini	自動化設計、整理、相談、YAML案作成	原則オフ、または限定的に許可
AI Task Local	Ollama 7B〜8B	短い要約、通知文、軽い分類	必要に応じて
AI Task Cloud	OpenAI / Claude / Gemini	自動化の説明、名前付け、複雑な判断	原則オフ

Home AssistantのOllama統合では、同じモデルでも「Home Assistant制御なし」と「制御あり」の複数設定を作れると説明されています。
また、ローカルLLMで制御を試す場合は、公開エンティティを25個未満にすることが推奨されています。(Home Assistant)

「高度な相談・自動化支援」だけクラウドにする方法

方法1：相談用の別Assistantを作る

通常の操作はローカルLLMに任せ、クラウドLLMは別の会話エージェントとして用意します。

例：

操作	使うもの
「リビングの電気をつけて」	ローカル7B〜8B
「今日の家の状態を教えて」	ローカル7B〜8B
「この自動化をもっと安全に整理して」	クラウドLLM
「外出時の自動化案を作って」	クラウドLLM

Home Assistantでは、LLMプロバイダを追加したあと、Settings > Voice Assistants > Add Assistant で会話エージェントを選ぶ形で、複数のAssistantを作れます。(Home Assistant)

方法2：AI Taskを用途別に分ける

自動化やスクリプト内で、軽い処理はローカル、重い処理はクラウドにできます。

タスク	推奨
通知文を短く整える	ローカル7B〜8B
センサー値を短く要約	ローカル7B〜8B
自動化の名前・説明・カテゴリ提案	クラウドLLM
カメラ画像の高度な説明	クラウドLLMまたはVision対応ローカル
YAMLやテンプレートの改善案	クラウドLLM

Home Assistant 2025.8では、AI Taskを自動化・スクリプト・テンプレートエンティティに組み込めるようになり、画像やカメラを添付してAIに解析させる例も紹介されています。(Home Assistant)

方法3：Suggest with AIだけクラウドにする

「自動化の名前・説明・カテゴリ・ラベルを提案してもらう」用途なら、Suggest with AIをクラウドLLMに割り当てる方法があります。

Home AssistantのSuggest with AIは、保存する自動化やスクリプトの内容、既存の自動化名やラベルをLLMに送り、名前・説明・カテゴリ・ラベルを提案します。(Home Assistant)
ただし、この処理では自動化やスクリプトの内容がLLMに送信されるため、プライバシー重視ならローカルLLMを使う選択もあります。(Home Assistant)

注意点：クラウドLLMに何を任せるべきか

クラウドLLMに向いているのは、操作そのものではなく、次のような「相談・設計・整理」です。

クラウドLLMに任せる	理由
自動化の設計相談	推論力が必要
YAMLの改善案	文脈理解が必要
複数条件の整理	7B級より安定しやすい
Web情報を含む相談	ローカルLLM単体では難しい
エラー原因の切り分け	長文理解に強い

一方、実際の家電操作はローカルLLMまたはAssistに寄せるのが安全です。

ローカルに任せる	理由
照明・スイッチ操作	速く、外部送信不要
センサー状態確認	プライバシー面で有利
シーン・スクリプト実行	定型操作に向く
日常の音声操作	遅延が少ない

Home AssistantのLLM APIは、LLMがHome Assistantの情報取得や制御をできるようにする仕組みですが、標準のAssist APIでできる範囲に限られ、管理作業はできません。(Home Assistant)
つまり、クラウドLLMに「自動化を考えてもらう」ことはできますが、標準機能だけで何でも自由に管理・変更させるものではありません。

私ならこう構成します

あなたの用途なら、次の構成がバランスよいです。

役割	推奨
Home Assistant本体	Raspberry Pi 4 8GB / Home Assistant Green
日常操作用LLM	Mac mini M系上のOllama 7B〜8B
高度相談用LLM	OpenAI / Claude / Gemini
Web情報を含む相談	GeminiまたはOpenAI
HA内のAI Task	通常はローカル、複雑なものだけクラウド
Suggest with AI	最初はクラウド、慣れたらローカルも比較

最終判断

できます。切り替えも、用途を分ければ簡単です。

ただし、理想形は「1つのAIが自動的に全部を振り分ける」ではなく、まずは次のように分けることです。

通常	高度相談
ローカル7B〜8B	クラウドLLM
家電操作・状態確認	自動化設計・整理・YAML相談
低遅延・プライバシー重視	高推論力・長文処理重視
Home Assistant制御あり	原則、制御なし

この分け方にすると、日常操作はローカルで安全・高速に動かし、難しい相談だけクラウドに出すという運用ができます。

---

クラウドLLMを併用する場合に最適なLLMモデル

はい、モデル指定はできます。
Home Assistantでは、OpenAI / Anthropic / Google Gemini などの統合で「Recommended settings」を外すと、使用モデルを指定できます。
OpenAI統合では Model 欄があり、デフォルトは gpt-4o-mini と説明されています。
Anthropic統合やGoogle Gemini統合でもモデル指定欄があります。(Home Assistant)

また、Home Assistantの AI Task はタスクごとに使うAI Taskエンティティを指定できるため、「通常はローカル7B〜8B」「高度相談だけクラウド低価格モデル」「失敗時だけ高性能モデル」という分け方ができます。(Home Assistant)

結論

Home Assistantの高度相談用なら、最初から最高性能モデルを使う必要はありません。

おすすめは次の順です。

優先	モデル候補	用途	判断
1	Gemini 2.5 Flash-Lite	自動化案、説明文、整理、簡単なYAML相談	安価。まず試す候補
2	Gemini 3 / 3.1 Flash系	少し複雑な設計相談、画像・検索も絡む相談	低価格と性能のバランスがよい
3	GPT-5.4 mini	YAML、テンプレート、手順整理、やや複雑な設計	価格は上がるが安定候補
4	Claude Haiku 4.5	長文説明、設計方針、自然な相談	Sonnetより安価で相談向き
5	Claude Sonnet 4.6 / GPT-5.4	低価格モデルで失敗した時だけ	高性能だが常用は割高

GoogleのGemini 2.5 Flash-Liteは「最小かつ最も費用効率の高いモデル」と説明され、料金は入力 $0.10 / 100万トークン、出力 $0.40 / 100万トークンです。
Gemini 3.1 Flash-Lite Previewも高ボリュームのエージェントタスクや単純なデータ処理向けの低コストモデルとして案内されています。(Google AI for Developers)

OpenAIでは、GPT-5.4 mini が入力 $0.75 / 100万トークン、出力 $4.50 / 100万トークンです。
通常の GPT-5.4 は入力 $2.50、出力 $15.00 なので、Home Assistant相談用にはまず mini から試すのが合理的です。(OpenAI)

Anthropicでは、Claude Haiku 4.5 が入力 $1 / 100万トークン、出力 $5 / 100万トークン、Claude Sonnet 4.6 が入力 $3、出力 $15 です。
高度相談でも、最初は Haiku 4.5、詰まった時だけ Sonnet 4.6 でよいと思います。(Claude)

Home Assistant用途別のおすすめモデル

やりたいこと	推奨モデル	理由
自動化の名前・説明・カテゴリ整理	Gemini 2.5 Flash-Lite	安価で十分なことが多い
「この条件ならどういう自動化がよいか」程度の相談	Gemini 3 / 3.1 Flash系	低価格で推論力も比較的ある
configuration.yaml やテンプレートの相談	GPT-5.4 mini	構文・手順整理に向く
長めの設計相談、複数案の比較	Claude Haiku 4.5	説明・整理が得意
失敗原因の切り分け、複雑なYAML修正	Claude Sonnet 4.6 / GPT-5.4	必要時だけ使う上位モデル

料金感の目安

たとえば、1回の高度相談で 入力1万トークン、出力2千トークン 使った場合の概算です。

モデル	概算コスト
Gemini 2.5 Flash-Lite	約 $0.0018
Gemini 3 Flash系	約 $0.005〜$0.01台
GPT-5.4 mini	約 $0.0165
Claude Haiku 4.5	約 $0.02
Claude Sonnet 4.6	約 $0.06
GPT-5.4	約 $0.055

つまり、高度相談でも、毎回Sonnet級やGPT-5.4級を使う必要はありません。
まず Gemini Flash-Lite / Flash系、GPT mini、Claude Haiku で試し、回答が不十分な時だけ上位モデルに投げ直す運用がよいです。

Home Assistantでの実用構成

役割	モデル	Home Assistant制御
日常操作	ローカル7B〜8B	有効
軽い相談・説明	ローカル7B〜8B または Gemini Flash-Lite	原則オフ
高度相談の通常枠	Gemini Flash系 / GPT-5.4 mini / Claude Haiku 4.5	原則オフ
難問・最終確認	Claude Sonnet 4.6 / GPT-5.4	原則オフ

クラウドLLMを「相談用」として使う場合は、Control Home Assistant は原則オフにするのがおすすめです。
Home Assistant統合では、制御を許可した場合でも、公開されたエンティティだけを扱える仕組みですが、相談用途なら実機操作まで許可しない方が安全です。(Home Assistant)

私のおすすめ

最初の構成はこれでよいと思います。

用途	モデル
通常の家電操作	ローカル7B〜8B
自動化の整理・名前付け	Gemini 2.5 Flash-Lite
Home Assistant設定相談	GPT-5.4 mini
長文の設計相談	Claude Haiku 4.5
どうしても解けない時	Claude Sonnet 4.6 または GPT-5.4

特に費用重視なら、まず Gemini 2.5 Flash-Lite → GPT-5.4 mini → Claude Sonnet 4.6 の順で段階的に上げるのがよいです。

---

クラウドLLMを併用する場合、クラウドLLMの実機操作を制限

はい、可能です。切り替えなしで「役割ごとに固定」できます。

つまり、次のように同時に設定できます。

役割	使うAI	Home Assistant操作権限	運用
日常操作用	ローカルLLM / Ollama 7B〜8B	有効。ただし公開エンティティだけ	通常のAssistに割り当てる
相談・設計用	クラウドLLM	無効	AI Task、 相談用Assistant、 スクリプトで使う

Home AssistantのOllama統合には Control Home Assistant という設定があり、有効にしても操作・参照できるのは exposed entities、つまりAssistに公開したエンティティだけです。
公式ドキュメントでも、モデルがHome Assistantとやり取りできるかを設定でき、許可した場合でも公開済みエンティティだけを制御・情報取得できると説明されています。(Home Assistant)

クラウド側も同じ考え方です。
OpenAI統合にも Control Home Assistant 設定があり、これをオフにすればクラウドLLMを相談・文章生成・AI Task用途に使い、実機操作はさせない構成にできます。
OpenAI統合ではConversationとAI Taskのサブエントリを持ち、Control Home Assistantの可否やモデル設定を行えます。(Home Assistant)

「切り替えなし」の意味での現実的な構成

おすすめは、日常操作の入口と相談の入口を最初から分けておく方法です。

入口	割り当て	例
通常のVoice Assistant / Assist	ローカルLLM、操作権限あり	「リビングの電気をつけて」
AI Taskの既定エンティティ	クラウドLLM、操作権限なし	自動化の説明、名前付け、整理
相談用Assistant	クラウドLLM、操作権限なし	「この自動化の条件を見直して」

この構成なら、ローカルLLMは常に公開エンティティだけを操作可能、クラウドLLMは常に操作不可という状態にできます。毎回、設定画面で切り替える必要はありません。

Home AssistantのAI Tasksは、自動化・スクリプト・テンプレートからAIを呼び出せる仕組みで、ファイル添付や構造化出力にも対応しています。
また、既定のAI Taskエンティティを設定できるため、UI上のSuggest with AIやAI Task利用先を特定のAIに固定できます。(Home Assistant)

ただし注意点

「完全に同じ話しかけ口で、内容に応じて自動的にローカル/クラウドへ振り分ける」場合は、少し工夫が必要です。
標準的には、会話エージェントやAI Taskエンティティを用途ごとに指定します。
Home Assistantのコミュニティでも、conversation.process の agent_id を指定して特定の会話エージェントを呼ぶ方法が紹介されています。(Home Assistant Community)

つまり、整理すると次の通りです。

やりたいこと	可能か
ローカルLLMだけに操作権限を与える	可能
ローカルLLMに公開エンティティだけを扱わせる	可能
クラウドLLMを操作権限なしにする	可能
設定を毎回切り替えず、役割固定で使う	可能
1つの入口で完全自動振り分け	可能だがスクリプト等の工夫が必要

おすすめ設定

項目	設定
Ollama / ローカルLLM	Control Home Assistant：オン
公開エンティティ	照明、エアコン、センサー、スクリプトなど必要最小限
OpenAI / Claude / Gemini	Control Home Assistant：オフ
クラウドLLM用途	AI Task、Suggest with AI、相談用Assistant
安全面	実機操作はローカル側に限定

この構成なら、日常の家電操作はローカルで安全に処理し、クラウドには高度相談だけを任せるという運用ができます。

---

クラウドLLMへ振り分けるための具体的指示

はい。自動振り分けを作るなら、「クラウドへ回す合図」を言葉の中に入れるのが一番確実です。

Home Assistantでは、会話処理の conversation.process に agent_id を指定できるため、ローカル用エージェントとクラウド用エージェントを別々に呼び出せます。
また、AI Taskではタスクごとに entity_id を指定できるので、用途別にAIモデルを固定できます。
条件分岐にはスクリプトの choose が使えます。(Home Assistant)

一番おすすめの指示パターン

クラウドへ回したいときは、冒頭に次のような言葉を付ける方式が安全です。

クラウドへ振り分ける合図	例
「設計相談」	「設計相談、外出時の自動化を見直して」
「自動化相談」	「自動化相談、夜間に人感センサーで照明をつける条件を考えて」
「YAML相談」	「YAML相談、このテンプレートセンサーの書き方を確認して」
「原因分析」	「原因分析、プリンタのインク残量が正しく読めない理由を考えて」
「整理して」	「Home Assistantのエンティティを部屋別に整理する方針を考えて」
「改善案」	「今の外出モード自動化の改善案を出して」
「クラウド相談」	「クラウド相談、在宅・外出・就寝モードの設計を比較して」

この方式なら、通常の操作文はローカルLLM、相談・設計系だけクラウドLLMに分けやすいです。

クラウドへ振り分ける具体的な指示例

1. 自動化の設計相談

次のような依頼はクラウド向きです。

設計相談、夜10時以降に廊下の人感センサーが反応したら、まぶしくない明るさで照明をつける自動化を考えて。

自動化相談、外出時にエアコン、照明、プリンタ、空気清浄機をどう扱うべきか整理して。

設計相談、在宅モード、外出モード、就寝モードをどう分けると安全で分かりやすいか提案して。

これは実機操作ではなく、ルール設計・条件整理なのでクラウドLLMに向いています。

2. YAMLやテンプレートの相談

YAML相談、次のtemplate sensorの書き方に問題がないか確認して。

YAML相談、configuration.yamlに追加したtemplateブロックを安全に整理する方法を教えて。

YAML相談、インク残量の複数センサーを1つのまとめセンサーにする例を作って。

この場合、クラウドLLMには操作権限を与えず、設定案だけ出させるのが安全です。

3. 原因分析・トラブルシュート

原因分析、EPSONプリンタのエンティティを公開しているのに、AIがオンライン状態を答えられない理由を整理して。

原因分析、Home Assistantでtemplateを追加したあと反映されない場合の確認手順を教えて。

原因分析、SwitchBotの状態がHome Assistantに遅れて反映される原因を考えて。

これは状態確認だけでなく、仕組み・設定・原因の切り分けが必要なのでクラウド向きです。

4. 既存構成の整理

整理して、Home Assistantに公開するエンティティを、ローカルLLMに扱わせるものと扱わせないものに分けたい。

整理して、照明、エアコン、センサー、プリンタ、SwitchBotを部屋別に分類する方針を作って。

整理して、Assistに公開するエンティティを25個以内に絞る候補を考えて。

「整理して」は便利ですが、日常操作にも聞こえる場合があります。
確実にクラウドへ回したいなら、「設計相談、整理して」のように言うのがよいです。

5. 比較・方針決め

設計相談、Home Assistant GreenとRaspberry Pi 4で運用する場合の違いを比較して。

設計相談、ローカルLLMをMac mini M系に置く場合とWindows GPU PCに置く場合を比較して。

改善案、ローカルLLMとクラウドLLMの役割分担を見直して。

比較・方針決めは、7B〜8Bでも可能ですが、長文整理や複数条件の比較はクラウドLLMの方が安定しやすいです。

ローカルLLMへ残すべき指示例

逆に、次のような指示はクラウドに出さず、ローカルLLMでよいです。

指示例	理由
「リビングの電気をつけて」	実機操作なのでローカル向き
「寝室の照明を少し暗くして」	公開エンティティ操作で十分
「プリンタのインク残量を教えて」	状態確認なのでローカル向き
「今、家の中は寒い？」	センサー確認なのでローカル向き
「外出モードを実行して」	既存スクリプト実行なのでローカル向き

つまり、動かす・確認する・実行するはローカル、考える・設計する・直す・比較する・整理するはクラウド、という分け方です。

振り分けルールの例

自動振り分けの判定ルールは、最初は単純でよいです。

入力文に含まれる言葉	振り分け先
設計相談	クラウド
自動化相談	クラウド
YAML相談	クラウド
原因分析	クラウド
改善案	クラウド
比較して	クラウド
整理して	原則クラウド
つけて / 消して / 実行して / 教えて	原則ローカル

より安全にするなら、「整理して」だけではクラウドにせず、「設計相談」や「クラウド相談」が付いたときだけクラウドにするのがおすすめです。

ルーター用の指示文例

自動振り分け用に、ルーター役のLLMやスクリプトに次のような指示を与えると分かりやすいです。

あなたはHome Assistant用の振り分け係です。
ユーザーの依頼を LOCAL または CLOUD に分類してください。

LOCAL:
- 照明、エアコン、スイッチ、センサー、シーン、スクリプトの操作
- 現在の状態確認
- 公開エンティティだけで処理できる短い依頼

CLOUD:
- 自動化の設計相談
- YAML、template、configuration.yamlの相談
- 原因分析、トラブルシュート
- 複数案の比較
- エンティティ整理、運用方針の検討
- 「設計相談」「自動化相談」「YAML相談」「原因分析」「クラウド相談」が含まれる依頼

返答は LOCAL または CLOUD のどちらか一語だけにしてください。

私ならこうします

最初は、誤振り分けを避けるために、明示キーワード方式にします。

クラウドへ送るときは、必ず冒頭に次のどれかを付けます。

設計相談、
自動化相談、
YAML相談、
原因分析、
クラウド相談、

通常の家電操作では何も付けません。

この運用なら、たとえば次のように自然に使えます。

リビングの電気をつけて

→ ローカルLLM

設計相談、リビングの照明を夜だけ自動で暗めにする条件を考えて

→ クラウドLLM

プリンタのインク残量を教えて

→ ローカルLLM

原因分析、プリンタのインク残量をAIが正しく説明できない理由を整理して

→ クラウドLLM

この分け方が、安全性・料金・分かりやすさのバランスが一番よいと思います。

---

HOME Assistantの音声関連の機能

はい。Home Assistantの音声関連機能は、中心に Assist という音声アシスタント機能があり、その周辺に 音声入力、音声出力、ウェイクワード、音声サテライト、LLM連携、AI Task が組み合わさる構造です。

全体像

人の声
  ↓
マイク / スマホ / Voice Preview Edition / 音声サテライト
  ↓
ウェイクワード検出
  ↓
Speech-to-Text：音声を文字に変換
  ↓
Conversation Agent：命令を解釈
  ↓
Home Assistantのエンティティ操作・状態確認
  ↓
Text-to-Speech：返答を音声化
  ↓
スピーカーから返答

Home Assistant公式では、Assistは自然言語でHome Assistantを操作する音声アシスタントで、ローカル処理にもLLM連携にも対応できると説明されています。
スマホ、タブレット、専用音声端末、自作音声デバイスなどから利用できます。(Home Assistant)

主な音声関連機能の一覧

機能	役割	ローカル対応	クラウド対応	概要
Assist	Home Assistantの音声アシスタント本体	○	○	音声やテキストで家電操作・状態確認を行う
Assist Pipeline	音声処理の流れを定義	○	○	STT、会話エージェント、TTSを組み合わせる
Speech-to-Text	音声を文字に変換	○	○	Whisper、Speech-to-Phrase、Home Assistant Cloudなど
Text-to-Speech	返答を音声に変換	○	○	Piper、Home Assistant Cloud、各種TTS統合
Wake Word	「Hey Jarvis」等で起動	○	一部○	openWakeWord / microWakeWord系
Voice Satellite	各部屋のマイク・スピーカー端末	○	○	Voice PE、Raspberry Pi、自作端末など
LLM連携	曖昧な指示や会話を処理	○	○	Ollama、OpenAI、Gemini、Claudeなど
AI Task	自動化や画像解析にAIを使う	○	○	通知文生成、画像解析、構造化出力など
Broadcast / Announcement	音声端末へ一斉通知	○	○	「夕食の時間」と各部屋へ放送する用途

1. Assist：Home Assistantの音声アシスタント本体

Assistは、Home Assistantを自然な言葉で操作するための機能です。

たとえば次のようなことができます。

音声指示の例	動作
「リビングの照明をつけて」	照明をオン
「寝室の照明を暗くして」	明るさ調整
「エアコンをつけて」	climateエンティティを操作
「外出モードを実行して」	スクリプトやシーンを実行
「プリンタのインク残量を教えて」	センサー状態を返答
「家の状態を教えて」	LLM利用時は状態要約も可能

Home AssistantのAssistは、公開されたエンティティを対象に動作します。
公式のベストプラクティスでは、Assistに公開するエンティティは必要最小限にすること、名前やエリア名、別名を整えることが推奨されています。
公開エンティティが多すぎると処理が遅くなり、LLM利用時はリクエストごとの文脈量や費用も増えます。(Home Assistant)

2. Assist Pipeline：音声処理の組み合わせ

Assist Pipelineは、音声アシスタントの処理経路です。

構成要素は主に3つです。

パイプライン要素	内容	例
Speech-to-Text	音声を文字にする	Whisper、Speech-to-Phrase、Home Assistant Cloud
Conversation Agent	文字化された命令を解釈する	Home Assistant標準、Ollama、OpenAI、Gemini、Claude
Text-to-Speech	返答を音声にする	Piper、Home Assistant Cloud、Google TTS等

ローカル構成では、Speech-to-TextにWhisperまたはSpeech-to-Phrase、Text-to-SpeechにPiperを使う流れが公式手順として案内されています。
設定画面では、Settings > Voice assistants からAssistantを追加し、言語、会話エージェント、STT、TTSを選びます。(Home Assistant)

一方、Home Assistant Cloudを使う場合は、音声認識と音声合成をCloud側の音声サービスに任せる構成になり、低性能な本体でも高速に使いやすいのが利点です。(Home Assistant)

3. ローカル音声処理とクラウド音声処理

Home Assistantの音声機能は、ローカル重視とクラウド活用の両方を選べます。

構成	STT	TTS	特徴	向く用途
Cloud構成	Home Assistant Cloud	Home Assistant Cloud	簡単・高速・低性能機でも使いやすい	まず試す、安定重視
Focused Local	Speech-to-Phrase	Piper	定型コマンドに強い、軽め	家電操作中心
Full Local	Whisper	Piper	汎用的な音声認識、ただし重い	プライバシー重視、ローカル完結
LLM併用	上記いずれか	上記いずれか	曖昧な指示・会話に強い	「何とかして」系の指示

Home Assistantは2025年の音声関連アップデートで、音声処理の組み合わせを Cloud / Focused Local / Full Local のように整理しています。
Focused LocalはSpeech-to-PhraseとPiper、Full LocalはWhisperとPiperを使う考え方です。(Home Assistant)

4. Wake Word：呼びかけで起動する機能

Home Assistantでは、「Okay Nabu」「Hey Jarvis」「Hey Mycroft」などのウェイクワードでAssistを起動できます。

ウェイクワードの仕組みには、主に次のものがあります。

方式	概要
openWakeWord	Home Assistantが採用しているオープンなウェイクワード技術
microWakeWord	Voice Preview EditionやAndroid実験機能で使われる軽量ウェイクワード技術
端末側ウェイクワード	Androidスマホなど端末内で起動語を検出

Home AssistantはopenWakeWordを使っており、実用速度・精度・単純なモデル構造・少ない学習データでのウェイクワード作成を目標とした仕組みだと説明されています。(Home Assistant)

2026.3では、Android版Companion Appに実験的なオンデバイス・ウェイクワード検出が追加されました。
処理はAndroid端末上で行われ、音声はクラウドに送られません。
ただし常時マイクとCPUを使うため、バッテリー消費に注意が必要です。(Home Assistant)

5. Voice Satellite：各部屋に置く音声端末

Voice Satelliteは、Home Assistant本体とは別に、各部屋に置くマイク・スピーカー端末です。

候補は次のようなものです。

音声端末	特徴
Home Assistant Voice Preview Edition	公式推奨の音声ハードウェア
Androidスマホ / タブレット	Companion AppでAssistを使える
Wear OS	腕時計からAssistを使える
Raspberry Pi + マイク/スピーカー	Wyoming Satelliteとして自作可能
ESPHome系音声端末	小型・自作向き
古い電話機連携	電話を使った会話・通知の実験的用途

Home Assistant公式は、Assistを試す最も簡単な方法としてCompanion Appを挙げ、専用ハードウェアとしてHome Assistant Voice Preview Editionを推奨しています。(Home Assistant)

Voice SatelliteはWyoming ProtocolでHome Assistantに接続できます。
Wyoming Protocolでは、Raspberry Piなどで動くリモート音声サテライトがZeroconfで自動検出されることもあります。(Home Assistant)

6. 音声でできること

Home Assistantの音声操作でできることは、大きく分けて次の通りです。

分類	できること
家電操作	照明、スイッチ、エアコン、カーテン、ロック、掃除機など
状態確認	温度、湿度、電力、プリンタ状態、センサー状態など
シーン・スクリプト実行	外出モード、就寝モード、帰宅モードなど
タイマー・リスト	タイマー、買い物リストなど
通知・放送	音声サテライトへのアナウンス
LLM会話	曖昧な依頼、状態要約、設計相談
画像・AI処理	カメラ画像解析、通知文生成など

Home Assistantは標準の会話エージェントだけでなく、LLMを組み合わせることで、より自由な会話や高度な相談に拡張できます。
公式は、Assistがローカルでも最新LLMを活用する形でも動作できると説明しています。(Home Assistant)

7. 音声通知・アナウンス機能

Home Assistantでは、Text-to-Speechを使ってスピーカーや音声サテライトにしゃべらせることができます。

例：

用途	例
家族への通知	「夕食の時間です」
洗濯通知	「洗濯が終わりました」
防犯通知	「玄関が開いたままです」
車庫通知	「ガレージドアが30分開いたままです」
災害・気象通知	「明朝、道路凍結の可能性があります」

TTSはHome Assistantが音声で返答したり、自動化で発話したりするための基盤機能です。
公式ドキュメントでは、TTSはHome Assistantに「話させる」ための機能であり、Assistの返答にも使われると説明されています。(Home Assistant)

また、Home Assistant 2025.3ではWyomingサテライトへのアナウンス対応が追加される流れが紹介され、音声サテライトを家の中の放送端末として使う方向が強化されています。(Home Assistant)

8. LLMと音声の組み合わせ

Home Assistantの音声機能は、Conversation Agentを差し替えることでLLMと組み合わせられます。

会話エージェント	向く用途
Home Assistant標準	照明・スイッチなどの定型操作
Ollama / ローカルLLM	曖昧な指示、簡単な要約、プライバシー重視
OpenAI / Gemini / Claude	高度な相談、自動化設計、設定整理
MCP連携	外部情報や外部ツールを含む会話

あなたの用途なら、次のような分担が自然です。

用途	推奨
日常の音声操作	ローカルLLMまたは標準Assist
照明・エアコン・状態確認	ローカル
自動化設計相談	クラウドLLM
Home Assistant設定相談	クラウドLLM
カメラ画像解析	Vision対応LLMまたはAI Task

Home AssistantのAI Taskでは、用途ごとにAI Taskエンティティを指定できます。
これにより、軽い処理はローカルモデル、複雑な処理はクラウドモデルという分け方が可能です。(Home Assistant)

9. AI Taskとの関係

AI Taskは、音声アシスタントそのものというより、Home Assistantの自動化やテンプレートからAIを呼び出す機能です。

できることの例：

AI Taskの用途	内容
通知文生成	センサー状態から自然な通知文を作る
カメラ画像解析	動体検知時のスナップショットをAIに見せる
構造化出力	JSON形式で「人がいる / いない」などを返す
自動化補助	名前・説明・カテゴリ案を作る
状態要約	複数センサーの状況を文章化する

Home Assistant公式は、AI Taskでカメラ画像を解析するブループリント例にも触れており、デフォルトのAI Taskエンティティを設定できるため、あとから利用モデルをまとめて切り替えやすいと説明しています。(Home Assistant)

10. 音声サテライトの状態を自動化に使う

Home Assistant 2026.2では、Assist satelliteの状態条件が追加されています。
これにより、音声サテライトが idle / listening / processing / responding のどの状態かを自動化条件として使えるようになりました。(Home Assistant)

たとえば次のような使い方が考えられます。

条件	自動化例
音声サテライトが応答中	他の通知音を鳴らさない
リスニング中	テレビ音量を一時的に下げる
アイドル中	通知を読み上げる
処理中	LEDを点滅させる

11. 最近強化された音声機能

時期	機能	内容
2024年12月	Voice Preview Edition	公式音声ハードウェアが登場
2025年2月	Speech-to-Phrase / Broadcast強化	定型音声認識と放送機能が強化
2025年6月	Voice Chapter 10	Cloud / Focused Local / Full Localの整理
2025年8月	Streaming TTS / AI Task	音声応答の高速化、AI Task連携
2025年10月	非言語確認	同じ部屋の操作では短いビープ音で確認
2026年2月	Assist satellite条件	音声端末の状態を自動化条件に利用可能
2026年3月	Androidウェイクワード	Android端末が実験的に音声サテライト化

Home Assistant 2025.10では、同じ部屋内で完結した音声操作の場合、長い音声返答ではなく短いビープ音で確認する機能が追加されています。
これにより、照明操作などのたびに長い返答を聞かなくてよくなります。(Home Assistant)

あなたの環境でのおすすめ構成

これまでの話を踏まえると、次の構成が現実的です。

役割	推奨構成
Home Assistant本体	Raspberry Pi 4 8GB、Home Assistant Green、またはMac mini
日常音声操作	Assist標準またはOllama 7B〜8B
音声入力	まずはHome Assistant Cloud、慣れたらローカルSTT
音声出力	Home Assistant CloudまたはPiper
音声端末	Voice Preview Edition、Androidスマホ、Raspberry Piサテライト
高度相談	クラウドLLM
カメラ画像解析	AI Task + Vision対応LLM

最初に試すなら、Home Assistant Cloudの音声処理 + Assist + 必要最小限の公開エンティティが一番簡単です。
その後、プライバシーやローカル完結を重視するなら、Whisper / Speech-to-Phrase + Piper + ローカルLLMへ移行する流れがよいです。

まとめ

Home Assistantの音声関連機能は、単なる「音声リモコン」ではなく、次のような階層構造になっています。

層	内容
入口	スマホ、Voice PE、Raspberry Pi、Android、Wear OS
起動	ウェイクワード、ボタン、アプリ内Assist
認識	Cloud STT、Whisper、Speech-to-Phrase
理解	標準Assist、ローカルLLM、クラウドLLM
操作	公開エンティティ、シーン、スクリプト、自動化
返答	Piper、Cloud TTS、各種TTS
拡張	AI Task、Vision、MCP、音声サテライト

あなたの場合は、まず 日常操作はローカルまたは標準Assist、高度相談はクラウドLLM、音声認識は最初Cloudで安定運用という分け方が扱いやすいと思います。

---

はい。安価に始めるなら、候補はあります。
ただし、音声サテライトは「安さ」だけで選ぶと、マイク感度・ウェイクワード・スピーカー音量・設定難易度で苦労しやすいです。
（追記）下記の価格は参考。

・M5Stack ATOM Echo Smart Speaker Dev Kit（最安級の実験用　￥3,480）
・ATOM Voice スマートスピーカー開発キット（ESP32音声実験 ￥2,572）
・Raspberry Pi Zero 2 W（Pi衛星の本体 ￥3,454)
・Raspberry Pi Zero 2 WH（ピン付きPi Zero ￥3,520）
・ReSpeaker 2-Mics Pi HAT（Pi用マイクHAT ￥2,343）
・Seeed Studio XIAO ESP32S3 Sense（小型ESP32-S3 ￥2,660）
・Seeed Studio XIAO ESP32S3（拡張前提ボード ￥1,245）
・Raspberry Pi向けサウンド/オーディオHATキット（Pi音声入出力 ￥4,300）

結論：安価なおすすめ順

順位	機器	目安	おすすめ度	向く人
1	使っていないAndroidスマホ / タブレット	追加費用ほぼ0円	◎	まず試したい人
2	M5Stack ATOM Echo	数千円	○	とにかく安くESPHome音声を試したい人
3	Home Assistant Voice Preview Edition	約59ドル	◎	失敗を減らして実用寄りにしたい人
4	Raspberry Pi Zero 2 W + ReSpeaker 2-Mics HAT	数千円〜1万円台	○	自作・調整が好きな人
5	ESP32-S3系ボード + マイク/スピーカー	数千円〜	△〜○	電子工作に慣れている人

Home Assistant公式では、ESPHomeを使えばESP32系マイコンで安価な音声サテライトを作れると説明しており、チュートリアルでは13ドル程度から作れる例にも触れています。(Home Assistant)

一方で、公式の専用音声端末である Home Assistant Voice Preview Edition は、Seeed Studioで59ドル、在庫ありとして販売されており、Home Assistantと簡単に連携できる専用音声ハードウェアです。(seeedstudio.com)

1. まず試すなら：余っているAndroidスマホ

一番安いのは、古いAndroidスマホやタブレットを音声サテライト化する方法です。

Home Assistant 2026.3では、Android版Companion Appに実験的なオンデバイス・ウェイクワード検出が追加され、ロック中でもAssistを開けるようになったと説明されています。(Home Assistant)

項目	評価
追加費用	◎ ほぼ0円
設定の簡単さ	○
マイク・スピーカー	○ スマホ次第
常設性	△ 充電・バッテリー管理が必要
実用性	○ 実験用としてかなり良い

おすすめ用途
まずHome Assistantの音声操作を試す、机の上や寝室で使う、設定の流れを理解する用途に向きます。

注意点は、Androidの常時ウェイクワード検出はまだ実験的機能なので、安定性は専用機に劣る可能性があることです。

2. 最安級の実験用：M5Stack ATOM Echo

M5Stack ATOM Echo は、安価なESP32系の小型スマートスピーカー開発キットです。
価格が安く、Home AssistantのESPHome音声サテライト実験でよく候補になります。

Home Assistant公式の音声ページでも、ESPHomeを使って安価なESP32マイコンを音声アシスタント衛星として使えると説明されています。(Home Assistant)

項目	評価
価格	◎ 安い
サイズ	◎ 非常に小さい
設定難易度	△ やや高い
音質	△ 小型なので期待しすぎない
実用性	△〜○ 近距離用

おすすめ用途
机の上、作業部屋、近距離で「リビングの電気をつけて」程度を試す用途。

注意点
小型なので、遠くからの音声認識や大きな音での返答には向きません。
ESPHomeのVoice Assistant機能は、マイク付きESPHomeデバイスが音声をHome AssistantへストリーミングしてAssistで処理する仕組みですが、音声機能はデバイス側のRAM/CPUをかなり使うという注意もあります。(ESPHome – Smart Home Made Simple)

3. 安さと実用性のバランス：Home Assistant Voice Preview Edition

安さだけならATOM Echoですが、実用性まで考えるとVoice Preview Editionが一番無難です。

項目	評価
価格	○ 約59ドル
設定の簡単さ	◎
マイク性能	○〜◎
見た目	◎
実用性	◎
自作の手間	◎ ほぼ不要

Voice Preview Editionは、Home Assistant向けに作られた初の専用音声ハードウェアで、USB-C電源に接続してウィザードに従うだけでセットアップできると説明されています。ハードウェアミュートスイッチも備えています。(Apollo Automation)

おすすめ用途
リビング、寝室、キッチンなど、日常的に使う場所。

判断
「安く失敗なく使いたい」なら、最初の1台はこれが最有力です。

Voice Preview Editionは販売されているが、開発途上ゆえの商品で、中級者以上のギークや開発者に向けた、実験的かつ革新的なデバイスとの情報もある。

4. 自作派向け：Raspberry Pi Zero 2 W + ReSpeaker 2-Mics HAT

Raspberry Pi系は、Wyoming SatelliteとしてHome Assistantに接続する構成が使えます。
Home Assistant公式のWyoming統合では、リモート音声サテライトは通常Raspberry Piで動き、Zeroconfで自動検出される場合があると説明されています。(Home Assistant)

項目	評価
価格	○ 部品を選べば安い
拡張性	◎
設定難易度	△〜×
マイク性能	HAT次第
実用性	○ 調整できれば良い

おすすめ用途
電子工作、自作ケース、部屋ごとのサテライト作成。

注意点
Pi Zero 2 W本体だけでは音声サテライトになりません。
マイクHAT、スピーカー、ケース、電源などが必要です。
結果的にVoice Preview Editionに近い費用になることもあります。

5. ESP32-S3系ボード

ESP32-S3系は音声処理向けの候補ですが、初心者向けというより開発・実験向けです。

項目	評価
価格	◎〜○
小型化	◎
設定難易度	△〜×
実用性	構成次第
向く用途	自作・組み込み

Seeed Studio XIAO ESP32S3 Senseなどは小型で魅力がありますが、音声サテライトとして使うには、マイク、スピーカー、アンプ、ケース、ESPHome設定などを自分で整える必要があります。

用途別おすすめ

目的	おすすめ
追加費用なしで試す	余っているAndroidスマホ
とにかく安く実験	M5Stack ATOM Echo
日常的に使う1台目	Home Assistant Voice Preview Edition
自作を楽しむ	Raspberry Pi Zero 2 W + ReSpeaker HAT
超小型に組み込みたい	ESP32-S3系ボード

私ならこう選びます

あなたの用途なら、次の順番がよいと思います。

段階	機器	理由
まず試す	Androidスマホ	追加費用が少ない
実験用に買う	M5Stack ATOM Echo	安価でHome Assistant音声サテライトを試せる
実用運用する	Home Assistant Voice Preview Edition	設定が簡単で専用機として安定しやすい
部屋ごとに増設	Voice PE または ATOM Echo	用途に応じて混在可能

結論として、安価に試すならAndroidスマホかM5Stack ATOM Echo、実用性まで考えるならHome Assistant Voice Preview Editionがおすすめです。

---

はい。AndroidでHome Assistantの常時ウェイクワード検出を使うには、事前設定がいくつか必要です。
特に重要なのは、Home Assistant Companion Appを新しくすること、Assistを既定のデジタルアシスタントにすること、Assistパイプラインを用意することです。

必要な事前設定

項目	必要度	内容
Home Assistant Companion App	必須	Android版アプリ 2026.2.3以降 が必要
Assistパイプライン	必須	Home Assistant Cloud、またはローカルAssistパイプラインを設定
既定のアシスタント設定	必須	Android側でHome Assistant Assistを既定のデジタルアシスタントにする
ウェイクワード検出	必須	Companion App内で有効化
マイク権限	必須	Home Assistantアプリにマイク使用を許可
バッテリー最適化	推奨	常設端末なら省電力制限を緩める
電源接続	推奨	常時検出はバッテリー消費が大きい
自宅Wi-Fi接続	推奨	Home Assistantに安定接続するため

Home Assistant公式ドキュメントでは、Androidのウェイクワード検出には Home Assistant Companion App 2026.2.3以降、Assistを既定アシスタントに設定、Home Assistant Cloudまたは手動設定済みローカルAssistパイプライン が必要とされています。
ウェイクワード検出は実験的機能です。(Home Assistant)

設定手順

1. Home Assistantアプリを更新する

AndroidのHome Assistant Companion Appを最新版にします。
公式条件では 2026.2.3以降 が必要です。(Home Assistant)

2. Assistパイプラインを用意する

Home Assistant側で、音声入力を処理できるAssistantを用意します。

選択肢は大きく2つです。

方式	内容
Home Assistant Cloud	設定が簡単で速度も出やすい
ローカルAssistパイプライン	Whisper / Speech-to-Phrase、Piperなどを使う

まず試すなら、Home Assistant CloudのAssistが簡単です。
ローカル完結を目指す場合は、STT・会話エージェント・TTSを組み合わせたローカルパイプラインを作ります。

3. Home Assistant Assistを既定のアシスタントにする

Androidスマホ側で、Home Assistantを既定のデジタルアシスタントにします。

Home Assistantアプリでの流れは次の通りです。

Home Assistantアプリ
  → 設定
  → Companion app
  → Assist for Android
  → Set as default
  → Androidの「既定のデジタルアシスタント」画面で Home Assistant を選択

公式手順でも、Home Assistantアプリの Settings > Companion app > Assist for Android > Set as default から、Androidの既定デジタルアシスタントアプリとしてHome Assistantを選ぶ流れが案内されています。(Home Assistant)

4. ウェイクワード検出を有効化する

同じくHome Assistantアプリ内で設定します。

Home Assistantアプリ
  → 設定
  → Companion app
  → Assist for Android
  → Wake word detection を有効化

選べるウェイクワードは、公式では次の3つです。(Home Assistant)

ウェイクワード
Hey Nabu
Hey Jarvis
Hey Mycroft

有効化すると、Android端末がロック中でも、またアプリがバックグラウンドでもウェイクワード検出が動作します。(Home Assistant)

追加で確認した方がよい設定

マイク権限

Home Assistantアプリにマイク権限を許可します。

Androidの設定
  → アプリ
  → Home Assistant
  → 権限
  → マイク
  → 許可

常時ウェイクワード検出では、Android端末上でmicroWakeWordが音声を監視します。
処理は端末内で行われ、ウェイクワード検出前の音声はHome Assistantやクラウドには送られません。(Home Assistant)

バッテリー最適化

常設の音声サテライトとして使うなら、Home Assistantアプリがバックグラウンドで止められないようにします。

Androidの設定
  → アプリ
  → Home Assistant
  → バッテリー
  → 制限なし / 最適化しない

機種によって表示名は違います。
Pixelなら「バッテリー使用量」、GalaxyやXiaomiなら「バックグラウンド制限」「自動起動」「省電力対象外」なども確認が必要です。

公式でも、ウェイクワード検出は継続的にマイクとCPUを使うため、バッテリー消費が大きいと説明されています。
必要な時だけ有効にする自動化も推奨されています。(Home Assistant)

電源接続

常時サテライト化するなら、基本的には充電器につないだ状態が現実的です。

運用	評価
常時電源接続	◎
バッテリー運用	△
必要な時だけウェイクワードON	○

注意点

Androidの常時ウェイクワード検出は、公式にもexperimental / 実験的とされています。(Home Assistant)

特に注意する点は次の通りです。

注意点	内容
バッテリー消費	Google Assistantより不利。 専用低電力チップを使えないため
機種差	AndroidのメーカーやOSバージョンで挙動が変わる
安定性	実験的機能なので、アプリ更新で改善中の段階
複数端末	複数端末が反応した場合、最初に検出した端末だけがAssistを開く
常設端末	画面オフ・省電力設定で停止しないよう調整が必要

Google Assistantは一部端末で専用の低電力ハードウェアを使えますが、Home Assistantなど第三者アプリはそのAPIを利用できないため、標準的な音声処理でCPUを使い続ける必要があり、電池消費が増えると説明されています。(Home Assistant)

Home AssistantからON/OFF制御も可能

便利なのは、Home Assistant側からAndroid端末のウェイクワード検出をオン・オフできる点です。

公式ドキュメントでは、Companion Appへの通知コマンドとして command_wake_word_detection を使い、turn_on / turn_off で制御できると説明されています。(Home Assistant)

たとえば次のような運用ができます。

条件	動作
自宅Wi-Fiに接続したら	ウェイクワードON
外出したら	ウェイクワードOFF
就寝時間だけ	寝室端末だけON
バッテリー残量が少ない	ウェイクワードOFF

まとめ

AndroidをHome Assistantの音声サテライトにするには、最低限これを設定します。

1. Home Assistant Androidアプリを最新版にする
2. Home Assistant側でAssistパイプラインを用意する
3. AndroidでHome Assistantを既定のデジタルアシスタントにする
4. Assist for AndroidでWake word detectionを有効化する
5. Hey Nabu / Hey Jarvis / Hey Mycroft から選ぶ
6. マイク権限とバッテリー制限を確認する

まず試すなら、Androidスマホを自宅Wi-Fi接続・電源接続状態にして、Home Assistant CloudのAssistで動作確認するのが一番スムーズです。

---

ローカルLLMをWindows PCに実装する場合のWindows PCの運用要領

はい、可能です。
ただし、通常の流れは「Home AssistantがいきなりOllama等へ問い合わせる」のではなく、先に Wake on LANでWindows PCを起こす → 起動完了を確認する → LLMに問い合わせる → 一定時間後にWindows側が自動スリープ という構成にします。

結論

項目	可能か	補足
Windows PCを通常はスリープにしておく	○	消費電力を抑えられる
Home Assistantから起こす	○	Wake on LANを使う
起動後にローカルLLMを使う	○	OllamaなどをWindows側で起動しておく
使用後に自動で再スリープ	○	Windowsの電源設定、またはHAからスリープ命令
完全にシームレスに即応答	△	起動待ち・モデル読み込み待ちがある

Home Assistantには wake_on_lan.send_magic_packet アクションがあり、Wake on LAN対応機器へマジックパケットを送って起動できます。
Windows側では、ネットワークアダプターがマジックパケットを受けて低電力状態から起動する仕組みです。(Home Assistant)

通信の流れ

ユーザー
  ↓
Home Assistant
  ↓ ① Wake on LAN
スリープ中のWindows PCを起動
  ↓ ② ping / API疎通確認
Windows PC起動完了を確認
  ↓ ③ Ollama APIへ問い合わせ
http://Windows_PC_IP:11434
  ↓
ローカルLLMが応答
  ↓
Home Assistantが結果を利用
  ↓
一定時間使わなければWindows PCが自動スリープ

Ollamaは標準では 127.0.0.1:11434 にバインドされます。
Home Assistantから別機器のWindows PC上のOllamaへ接続する場合は、OllamaをLANから見えるように OLLAMA_HOST を設定する必要があります。(Ollama Documentation)

実用上のおすすめ構成

設定項目	推奨
Windows PC接続	有線LAN推奨
IPアドレス	DHCP予約で固定
起動方法	Home AssistantのWake on LAN
起動確認	pingセンサー、またはOllama API疎通確認
LLMサーバー	OllamaをWindows起動時に自動起動
再スリープ	Windowsの電源設定で「操作なし○分後にスリープ」
予備案	HAからWindowsへスリープ命令を送る

Windows側では、ネットワークアダプターの電源管理で「このデバイスでコンピューターのスタンバイ状態を解除できるようにする」「マジックパケットでのみ解除する」系の設定を有効にします。
Microsoftの説明でも、WOL対応アダプターではこれらの設定を使うことが案内されています。(Microsoft Learn)

注意点

一番大きな注意点は、Home AssistantのOllama統合が普通にLLMへ問い合わせた瞬間、Windows PCが寝ていると失敗することです。

そのため、次のどちらかの運用が現実的です。

方式	内容	おすすめ度
事前起動方式	「AI相談を開始」ボタンや音声指示で先にWindows PCを起こす	◎
自動起動スクリプト方式	LLM利用前にWOL→起動確認→LLM呼び出しを行うスクリプトを作る	○
常時待機方式	Windows PCはスリープさせず、Ollamaを常時待機	△
完全自動即応答方式	眠っていても通常の会話と同じ速度で応答	×に近い

つまり、「必要な時だけ起こす」ことは可能ですが、起動待ちの数十秒〜数分は発生します。
さらに、LLMモデルを初回ロードする時間も加わる場合があります。

Windowsを再びスリープさせる方法

方法1：Windowsの電源設定に任せる

これが一番簡単です。

例：

設定	内容
画面オフ	5分
スリープ	10〜30分
GPU負荷終了後	自動でアイドル判定
Home Assistant側	特にスリープ命令を出さない

この方法なら、LLM使用後に操作がなくなれば、Windowsが通常の電源設定でスリープに戻ります。

方法2：Home Assistantからスリープ命令を送る

より積極的に制御したい場合は、Windows側にSSH、PowerShell Remoting、小さなHTTPサーバー、MQTTなどを用意し、Home Assistantからスリープ命令を送ります。

Windowsにはシステムをスリープまたは休止状態へ移行させる SetSuspendState APIがあります。
Microsoftのドキュメントでは、この関数はシステムをサスペンドし、引数によってスリープまたは休止状態に入ると説明されています。(Microsoft Learn)

ただし、最初は方法1の Windows電源設定に任せる で十分だと思います。

Home Assistant側の構成イメージ

alias: LLM用Windows PCを起動
sequence:
  - action: wake_on_lan.send_magic_packet
    data:
      mac: "AA:BB:CC:DD:EE:FF"

  - wait_template: "{{ is_state('binary_sensor.llm_pc_ping', 'on') }}"
    timeout: "00:03:00"

  - delay: "00:00:30"

  - action: notify.mobile_app_iphone
    data:
      message: "LLM用Windows PCが起動しました。AI相談を開始できます。"

Home AssistantのPing統合では、ICMP echo requestで対象ホストがオンラインか確認できます。標準のポーリング間隔は30秒です。(Home Assistant)

実際の使い方の例

例1：音声で事前起動

ローカルAIを起動して

Home AssistantがWindows PCへWake on LANを送信。

数十秒後：

ローカルAIが使えるようになりました

その後：

設計相談、外出モードの自動化を見直して

例2：ボタンで起動

Home Assistantのダッシュボードに、

LLM用PCを起動

というボタンを作る。

押すと、

1. Wake on LAN送信
2. pingで起動確認
3. Ollama疎通確認
4. 「利用可能」と表示

という流れにします。

この運用が向いている用途

用途	向き不向き
Home Assistantの高度相談	◎
自動化設計・YAML相談	◎
画像解析をたまに使う	○
毎日の短い音声操作	△
照明・エアコン操作	×、ローカル常時稼働LLMまたは標準Assist向き
即時応答が必要な防犯・通知	×

Windows GPU PCは高性能ですが、起動待ちがあります。
したがって、日常操作はRaspberry PiやMac mini上の軽量LLM、重い相談だけWindows PCを起こすという分担が現実的です。

おすすめ判断

あなたのRTX 5070 Ti搭載Windows PCを使うなら、構成は次のようにするのがよいです。

役割	機器
Home Assistant本体	Raspberry Pi 4 8GB / Home Assistant Green / Mac mini
日常操作用AI	ローカル7B〜8B、または標準Assist
高度相談・画像解析・重いLLM	RTX 5070 Ti搭載Windows PC
Windows PCの起動	Wake on LAN
Windows PCの停止	Windows電源設定で自動スリープ

結論として、可能です。
ただし「呼ばれたら即答」ではなく、呼ばれたら起動して、起動完了後にLLMを使うという運用になります。消費電力を抑えながら高性能GPUを活用する方法としては、かなり現実的です。

---

Windows PCのメインメモリがローカルLLMに与える影響

はい、メインメモリも関係あります。
ただし、RTX 5070 Ti 16GBのようにGPUでローカルLLMを動かす場合、優先順位は次の通りです。

重要度	要素	影響
1	GPUメモリ、VRAM 16GB	モデルをGPU上に載せられるかを決める。速度に最も影響
2	メインメモリ、RAM	VRAMに載り切らない分の受け皿、WindowsやOllamaの動作余裕
3	CPU	CPU推論・一部レイヤー処理・モデル読み込みに影響
4	SSD	モデル読み込み速度に影響

結論

VRAM 16GBが最重要ですが、メインメモリは不要ではありません。

特にWindows PCで使うなら、私なら次のように考えます。

メインメモリ	判断
16GB	7B〜8B級中心なら一応可。ただし余裕は少ない
32GB	RTX 5070 Ti 16GBとのバランスがよい。おすすめ最低ライン
64GB	13B〜20B級、Visionモデル、長い文脈、複数モデル利用に安心
128GB以上	30B〜70B級をRAM併用で試すなら意味あり。ただし速度は期待しすぎない

VRAMとメインメモリの役割の違い

VRAMにモデルが全部載る場合

この場合は高速です。

LLMモデル
  ↓
GPUメモリ 16GB内に収まる
  ↓
GPUで高速推論

この状態では、メインメモリは主に Windows、Ollama、モデル管理、入出力処理 のために使われます。
Ollamaでは ollama ps で、モデルがGPUにどの程度載っているかを確認できます。
PROCESSOR 欄に 100% GPU のように表示されます。(Ollama Documentation)

VRAMに載り切らない場合

この場合、足りない部分がCPU側・メインメモリ側に回ります。

LLMモデル
  ↓
一部はGPUメモリ
一部はメインメモリ
  ↓
GPU + CPUの混在処理
  ↓
遅くなる

このとき、メインメモリ容量が足りないと、さらにSSDへのスワップが発生し、かなり遅くなります。
llama.cpp系でも、モデルをRAMに保持する mlock やメモリマップ mmap の設定があり、十分なRAMがないと安定性・速度に影響します。(GitHub)

RTX 5070 Ti 16GBでの現実的なモデルサイズ

目安としては次のようになります。

モデルサイズ	RTX 5070 Ti 16GBでの扱いやすさ	メインメモリの目安	評価
7B〜8B Q4/Q5	◎	16GB〜32GB	快適。Home Assistant用途に十分
13B〜14B Q4	○〜◎	32GB推奨	実用的。高度相談にも使いやすい
20B〜22B Q4	△〜○	32GB〜64GB	入る場合もあるが、長文・Visionでは厳しくなりやすい
30B〜32B Q4	△	64GB推奨	VRAM 16GBには載り切りにくい。RAM併用で遅くなりやすい
70B Q4	×〜△	128GB級	動かせても実用速度は期待しにくい

Ollamaやllama.cpp系では、モデルサイズ・量子化方式・コンテキスト長によって必要VRAM/RAMが変わります。
一般的には、7B〜8Bは16GB VRAMでは余裕、13B〜14BもQ4なら現実的、30B級以上は16GB VRAMでは厳しくなります。(ローカルAIマスター)

Home Assistant用途で考えると

Home Assistantの高度相談用なら、RTX 5070 Ti 16GBでは次が現実的です。

用途	おすすめモデルサイズ	メインメモリ
日常操作の補助	7B〜8B	16GBでも可、32GB推奨
自動化設計相談	8B〜14B	32GB推奨
YAML相談・エラー原因分析	13B〜14B	32GB推奨
Vision対応モデルで画像解析	7B〜12B級	32GB〜64GB推奨
かなり複雑な設計相談	20B級	64GB推奨

重要な注意点

メインメモリを増やしても、VRAM 16GBが32GBになるわけではありません。

つまり、

VRAM 16GB + RAM 64GB

にしても、GPU上で高速に扱える量は基本的に VRAM 16GBの範囲です。
RAMに逃がした部分はCPU側処理やPCIe越しのやり取りが増えるため、速度は落ちます。

ただし、RAMを増やす意味はあります。

RAMを増やす効果	内容
VRAMに載らないモデルを一応動かせる	ただし遅くなる
Windows全体が安定する	ブラウザ、Ollama、監視ツールを同時起動しやすい
長いコンテキストに強くなる	KVキャッシュや補助処理の余裕が増える
Visionモデルで余裕が出る	画像処理・マルチモーダルはメモリを使いやすい
複数モデルを切り替えやすい	モデルロード時の余裕が増える

あなたのPCでのおすすめ

RTX 5070 Ti 16GB搭載Windows PCを、Home Assistant用の高度相談・Vision解析用LLMサーバーとして使うなら、

メインメモリは32GB以上がおすすめです。

より安心にするなら、

64GBにするとかなり扱いやすいです。

構成	おすすめ度
RTX 5070 Ti 16GB + RAM 16GB	△：軽めなら可
RTX 5070 Ti 16GB + RAM 32GB	◎：バランス良好
RTX 5070 Ti 16GB + RAM 64GB	◎：Vision・長文・20B級まで試しやすい
RTX 5070 Ti 16GB + RAM 128GB	○：大型モデル実験向け。普段使いには過剰気味

結論としては、ローカルLLMの速度を決める主役はGPUメモリ16GBですが、安定性と扱える幅を決めるのはメインメモリです。
Home Assistant連携用なら、32GBで実用的、64GBなら余裕ありと考えるのがよいです。

RTX 5070 Ti 16GB搭載Windows PCは、主にゲーム、たまにアマチュア無線のFT-8通信、3Dプリンタのデータ作り程度にしか使っていなかったので活用したい。ただし、RAMの増設が必要のようだ。