| 年 | 出来事 | 意味 |
|---|---|---|
| 2012年 | Paulus Schoutsen氏がPhilips HueのローカルAPIに触れ、Pythonで照明制御を試し始める | Home Assistantの原点は「クラウドではなく、家の中で直接制御できること」 |
| 2013年9月17日 | Home Assistantの最初のバージョンをGitHubに公開 | オープンソースのスマートホーム基盤として誕生 (Home Assistant) |
| 2015年ごろ | コミュニティが拡大 | 個人プロジェクトから、世界中の利用者・開発者が参加するプロジェクトへ |
| 2017年7月 | Hass.ioを発表 | Raspberry Piなどで、インストール・更新・バックアップ・アドオン管理を簡単にする仕組みが登場 (Home Assistant) |
| 2017年12月 | Home Assistant Cloudを発表 | AlexaやGoogle Assistant連携、リモート接続を、ローカル制御を保ちながら簡単にする方向へ進化 (Home Assistant) |
| 2018年 | Nabu Casa設立 | Home Assistant Cloudの運営と、開発を持続可能にする商業的な支えができる (Nabu Casa) |
| 2021年 | ESPHomeがNabu Casa傘下に | ESP32/ESP8266などを簡単にHome Assistantへ統合する仕組みが、公式エコシステムの重要部分になる (Home Assistant) |
| 2021年 | Home Assistant Yellow発表 | 初心者と上級者の両方を意識した公式スマートホームハブへ展開 (Home Assistant) |
| 2022年12月 | Matter対応の初期版を公開 | Apple、Google、Amazonなどが関わる相互接続規格への対応を開始 (Home Assistant) |
| 2023年 | 「Year of the Voice」 | ローカル・多言語・プライバシー重視の音声アシスタント開発を本格化 (Home Assistant) |
| 2023年9月 | 10周年、Home Assistant Green発表 | 初心者がすぐ始められる公式ハブとして、より一般家庭向けに近づく (Home Assistant) |
| 2023年末 | 音声制御が50以上の言語に対応 | 英語中心ではない、地域・言語に開いた音声スマートホームへ拡大 (Home Assistant) |
| 2024年4月 | Open Home Foundation設立 | Home Assistantを含む多数のオープンソース資産を、プライバシー・選択・持続可能性を掲げる非営利組織の下に置く体制へ (Home Assistant) |
| 2024年12月 | Voice Preview Edition登場 | Home Assistant専用の音声ハードウェアが登場し、ローカル音声操作の実験が進む (Home Assistant) |
| 2025年 | Yellowの生産終了を発表 | Greenなどのより扱いやすい製品へ軸足を移しつつ、Yellowのソフトウェアサポートは継続 (Home Assistant) |
| 2026年4月 | Home Assistant 2026.4で赤外線対応を強化 | テレビ、エアコン、扇風機など、赤外線リモコン機器をHome Assistantに取り込む方向が強まる (Home Assistant) |
AIを含むホームオートメーションの最近の傾向を調査したが、2026年1月に紹介した下記の記事の内容からあまり進展がなかったので、下記の記事で詳しく取り上げなかった「Home Assistant」について現状を調査してみることにした。「Home Assistant」については、2017年頃にユーザーIDを作成し、RaspberryPiをサーバーにしたりしていた記録はあるのだが、大手の企業が扱っているものではなく、ユーザーが自分で調べて構築・更新していかなくてはならない面倒なものとの印象があった。
ただし、「Home Assistant」自体は、専用のCloudを使用しなければ費用はかからないようで、現在は周囲の環境も変わっているはずなので、今回は、使わなくなったIntel Max mini (Late 2014、メモリ8GB)をHome Assistantサーバーとして構築し、現状を調査することにした。CarPlayやAndroid Autoとの関係も確認したいし、できれば小型のローカルLLMも実装してどこまでできるのかを確認したい。
現時点では、下図の通り、Max mini にHome Assistantサーバーし、小型のローカルLLMを組み込んだが、これらの詳細は別記事とし、本記事では、その予備調査の内容について紹介する。
（Appee TVやプリンタの各インクが認識されている）
（音声アシスタント「オラマ」とのチャット画面）
（注）本記事の内容は正確性を保証するものではない。
まず、HOME Assistantについて歴史と最近の動向を調べた。
HOME Assistantの歴史
以降、ChatGPT 5.5 Thinkingとの会話。
Home Assistantの歴史を調べてください
Home Assistantの歴史：要点
Home Assistantは、「ローカルで動く、メーカーに縛られないスマートホーム基盤」として2013年に始まりました。
現在は、単なる自動化ソフトではなく、Home Assistant OS、公式ハードウェア、ESPHome、Matter、音声アシスタント、Open Home Foundationを含む大きなエコシステムに発展しています。
時系列まとめ
歴史の流れを一言でいうと
Home Assistantは、最初はPhilips HueをPythonで制御する個人プロジェクトでした。
そこから、Raspberry Piで動かしやすくするOS、クラウド連携、公式ハードウェア、ESPHome、Matter、音声アシスタントへと広がり、現在は「家の中の機器を、メーカー横断で、できるだけローカルにまとめる基盤」になっています。
重要な転換点
特に大きい転換点は3つです。
1つ目は、2017年のHass.ioです。これにより、Home Assistantは「Pythonが分かる人向けのソフト」から、「Raspberry Piなどに入れてスマートホームサーバーとして使うもの」に近づきました。
2つ目は、2018年のNabu Casa設立です。オープンソースだけでは開発継続が難しくなりやすいところ、Home Assistant Cloudという有料サービスで開発を支える仕組みができました。
3つ目は、2024年のOpen Home Foundation設立です。Home Assistantを企業単独の所有物ではなく、オープンなスマートホーム基盤として守る体制を作った点が重要です。公式発表では、Open Home FoundationはHome Assistantを含む240以上のオープンソースプロジェクト、標準、ドライバー、ライブラリを保護すると説明されています。(Home Assistant)
一般家庭で見ると何が変わったか
初期のHome Assistantは、どちらかというと「詳しい人が自分で設定ファイルを書いて使うもの」でした。現在は、Home Assistant Greenのような公式ハブ、スマホアプリ、UIからの設定、Matter対応、音声操作、ESPHome連携が整ってきたため、一般家庭でも使いやすくなっています。
ただし、Apple Home、Google Home、Amazon Alexaのような「買ってすぐ使える家電アプリ」と比べると、Home Assistantは今でも自由度が高い代わりに、設計・設定・保守の知識が必要です。
家庭内の機器を長く使い、ローカル制御やメーカー横断の自動化を重視する人に向いた方向で発展してきた、と見るのがよいです。
今回の調査で、古いMac miniをHome Assistantサーバーにして、音声アシスタントに、Home Assistantで見えている機器（具体的にはEPSONプリンタ）に関し質問するという実験（別記事予定）を行ったが、ユーザーがyamlファイルに追記するなどの設定を行わなければならなかった。「自分で設定ファイルを書いて使うもの」という状況は変わっておらず、AIの助けがなければ設定が難しい。
HOME Assistantの動向
Home Assistantの最近の動向について教えてください
2026年4月時点では、Home Assistantは「上級者向けの自作スマートホーム基盤」から、「家族も使えるローカル・プライバシー重視のスマートホームOS」へ寄せている印象です。特に最近の動向は、次の7点です。
1. 赤外線リモコン機器の取り込みが本格化
Home Assistant 2026.4では、赤外線が“第一級の機能”として扱われるようになりました。
テレビ、エアコン、扇風機、サウンドバーなど、赤外線リモコンで動く古い家電を、ESPHomeベースの赤外線プロキシ経由でHome Assistantから制御できる方向です。
日本ではエアコンやテレビの赤外線リモコン家電が多いので、かなり実用的な変化です。(Home Assistant)
2. 自動化が「技術用語」から「生活上の意味」へ
最近のHome Assistantは、自動化エディタをより自然な考え方に変えています。
2026.4では、たとえば「ドアが開いた」「温度が変わった」のような意味ベースのトリガーや条件が強化され、接触センサー、カバー、温度センサー、空調、給湯器など、技術的なエンティティ種別を意識しなくても自動化を作りやすくなっています。(Home Assistant)
これは、将来的に「2階の窓が開いたら通知」「誰もいない部屋の照明を消す」のような、部屋・階・ラベル単位の自動化を作りやすくする方向です。
3. AI/音声アシスタントは“ローカル重視”で進化
Home AssistantのAssistは、AlexaやGoogle Assistantの代替というより、自宅内で制御できるプライベートな音声アシスタントを目指しています。
Voice Preview Editionでは、物理ミュートスイッチ、デュアルマイク、音量ダイヤルなどを備えた専用ハードウェアが投入され、オープンでプライベートな音声アシスタントを育てる方針が示されています。(Home Assistant)
さらに2026.3では、Android版Companion Appで実験的にオンデバイスのウェイクワード検出に対応しました。
音声処理は端末内で行われ、クラウドへ音声を送らない設計です。
ただし、常時マイク利用のためバッテリー消費には注意が必要です。(Home Assistant)
4. LLM連携は「何を考えたか見える化」へ
2026.4では、LLMを使ったAssistが処理中にどのようなステップを踏み、どのツールを呼び出したかを表示できるようになりました。
現時点ではデスクトップWeb限定ですが、AIエージェントがなぜその回答や操作に至ったかを確認できるため、自動化やAI制御のデバッグに役立ちます。(Home Assistant)
これは重要で、Home AssistantのAI活用は「AIに全部任せる」より、AIの判断過程を確認しながら、家の操作範囲を管理する方向に進んでいます。
5. Matter/Thread/Zigbee/Z-Waveのハブとして強化
Home Assistantは2025年にMatter認証を取得し、Open Home Foundation Matter Serverも認証されています。
MatterはWi-Fi、Ethernet、Thread経由で複数エコシステムと連携でき、クラウドに依存しないローカル制御を重視するHome Assistantの方針と相性が良いと説明されています。(Home Assistant)
2026.4ではMatter対応スマートロックのユーザー管理とPINコード管理もHome Assistant内で可能になりました。
フルアクセスや1回限りのアクセスコードなどを設定できるため、玄関スマートロック管理の実用性が上がっています。(Home Assistant)
6. ダッシュボードが家族向けに改善
2026.2では、新しいHome Dashboardが新規インストールの標準になりました。
従来より見やすく、デバイスの発見、エリア割り当て、クイック検索などが改善されています。
また「Add-ons」は「Apps」に名称変更され、初心者にも分かりやすい表現に寄せています。(Home Assistant)
2026.4では、ダッシュボードのセクション背景色、カードのお気に入り、ゲージカード再設計、自動高さ調整なども追加され、日常的に見る画面としての完成度が上がっています。(Home Assistant)
7. エネルギー管理・掃除ロボットも実用寄りに
2026.3では、ロボット掃除機をHome Assistantの「エリア」単位で掃除させる機能が追加されました。
Matter、Ecovacs、Roborockで対応が始まり、将来的には「キッチンを掃除して」のような音声操作につながる基盤になると説明されています。(Home Assistant)
また、エネルギーダッシュボードでは、電力、ガス、水道の現在値や水使用量の可視化が改善され、電気・ガス・水の設定も分かりやすく分離されました。
太陽光発電、スマートメーター、蓄電池、空調制御と組み合わせる場合、今後さらに重要になりそうです。(Home Assistant)
8. デバイスデータベース構想が進行中
Home Assistantは、Open Home Foundation Device Databaseという構想を進めています。
これは、利用者が任意で共有する匿名化デバイス情報を集め、「そのスマートプラグはローカル制御できるか」「どのセンサーが実際に安定しているか」「どの統合で使われているか」を判断しやすくするためのデータベースです。
2026.2でLabs機能として導入され、2026年前半に公開Webインターフェースを出す計画も示されています。(Home Assistant)
この流れは、将来的に「あなたの家にはこの自動化がおすすめです」と提案する“集合知ベースのスマートホーム”につながります。
Home Assistantの2025年ロードマップでも、デバイスの文脈を理解し、ダッシュボード・音声・自動化提案へ活用する構想が説明されています。(Home Assistant)
9. バックアップの暗号化も強化
2026.4から、Home AssistantのバックアップはSecureTar v3という新しい暗号化形式を使うようになりました。
Argon2idによる鍵導出、XChaCha20-Poly1305による暗号化・認証、Trail of Bitsによる外部監査が行われています。
既存バックアップは引き続き読めますが、新しいバックアップは自動的に新形式になります。(Home Assistant)
まとめ
| 動向 | 意味 |
|---|---|
| 赤外線対応強化 | 古いエアコン・テレビなどをスマート化しやすい |
| 自動化エディタ改善 | YAMLに頼らず、生活感覚で自動化しやすい |
| Assist/音声強化 | ローカル・プライベートな音声操作へ |
| LLM連携の可視化 | AIが何をしたか確認しやすい |
| Matter/Thread強化 | メーカー混在のスマートホーム基盤になりやすい |
| Device Database | 実利用データに基づく機器選び・自動化提案へ |
| バックアップ暗号化強化 | 長期運用時の安全性が向上 |
日本で今から使うなら、Home Assistant GreenまたはミニPC＋Connect ZBT-2、Matter/Thread/Zigbee機器、赤外線プロキシ、エネルギー監視の組み合わせが現実的です。
AIについては、まずはAssistによる音声操作、LLMによる自動化補助、異常通知の要約から試すのが安全です。
Home Assistantで利用できるLLM
Home Assistantで利用できるLLMについて教えてください
Home Assistantで使えるLLMは、大きく分けると クラウドLLM、ローカルLLM、OpenRouter経由の多数モデル、外部LLMアプリからMCPで使う方式 の4系統です。
2026年4月時点では、単に「会話できる」だけでなく、Assistから家電を操作する、AI Taskで通知文や要約を作る、外部AIにHome Assistantを道具として使わせる方向に広がっています。
まず全体像
Home AssistantのLLM連携は、AIにHome AssistantのAssist APIを渡し、許可されたエンティティだけを参照・操作させる仕組みです。
開発者向けドキュメントでも、LLMはHome Assistantの状態取得や制御に使える一方、管理系タスクは実行できないと説明されています。(Home Assistant開発者ドキュメント)
| 系統 | 主な選択肢 | 特徴 | 向いている用途 |
|---|---|---|---|
| クラウドLLM | OpenAI / Anthropic / Google Gemini | 精度・会話力が高い | 音声操作、複雑な指示、通知要約 |
| ローカルLLM | Ollama | 自宅内処理・プライバシー重視 | ローカル運用、実験、クラウド依存を減らす |
| モデル仲介 | OpenRouter | 多数のモデルを切替可能 | モデル比較、低コスト運用、用途別モデル選択 |
| 外部AI連携 | MCP Server | Claude Desktop / Claude Code / CursorなどからHAを操作 | AI作業環境から家・タスク・センサー情報を使う |
調査した結果、クラウドLLMを使う方法には、①クラウドLLMから自宅のHome AssistantのMCPサーバーに接続する方法と、②音声機能「assist」からクラウドLLMのAPIを呼ぶ方法があることが分かったが、①の方法はVPNなどを使う必要があり、②の方法は、クラウドLLMのAPI料金が発生するので、今回は小型のローカルLLMをMac miniに導入することにした。
Home Assistant Cloudという有料サービスを使う方法もあるようだが、6.5米ドル/月かかるようなので、本件では採用しない。
1. OpenAI
OpenAI統合では、Conversation、AI Task、Speech-to-text、Text-to-speech のサブエントリが用意されています。
つまり、会話エージェントとして家電を操作するだけでなく、AI Taskで文章生成や要約、STT/TTSで音声入出力にも使える構成です。(Home Assistant)
OpenAI系は、Home AssistantのAssistに組み込んで「リビングの照明を少し暗くして」「今日の家の状態を要約して」のような自然文操作に向いています。
モデルにHome Assistant操作を許可する場合でも、操作できるのは exposed entities、つまり公開設定したエンティティに限られます。(Home Assistant)
2. Anthropic / Claude
Anthropic統合では、Claude系モデルを会話エージェントとして利用できます。
公式ドキュメントでは、Claude 3.5 Sonnetなどを例に挙げ、AIにAssist APIへのアクセスを与えることで、デバイス情報の取得や制御ができると説明されています。(Home Assistant)
Claude系は、自然文の理解、長めの説明、条件整理が得意なので、Home Assistantでは「複数センサーの状態をまとめて説明」「自動化案の相談」「通知文の読みやすい要約」に向いています。利用にはAnthropic APIキーと課金設定が必要です。(Home Assistant)
3. Google Gemini
Google Gemini統合は、conversation agent、speech-to-text、text-to-speech をHome Assistantに追加できます。
会話エージェントにはHome Assistant操作を許可でき、許可されたエンティティの情報取得や制御が可能です。(Home Assistant)
Geminiの特徴は、画像やPDFなどを含む生成処理にも使える点です。
たとえば公式例では、ドアベルカメラのスナップショットを短く説明して通知に使う、複数画像から何が起きたかを要約する、といった使い方が示されています。(Home Assistant)
注意点として、GeminiのGoogle Search toolは、Home Assistant制御用のツールと同時に使えないAPI上の制限があります。公式ドキュメントでは、検索専用の2つ目のGemini会話エージェントを作り、スクリプト経由で呼び出す回避策が紹介されています。(Home Assistant)
4. OllamaによるローカルLLM
ローカル運用なら、公式のOllama統合が重要です。
Ollama統合は外部Ollamaサーバーを使い、macOS、Linux、Windows上で動かしたOllamaにHome Assistantから接続します。
設定では、OllamaサーバーのURL、モデル名、コンテキストサイズなどを指定できます。(Home Assistant)
OllamaでもHome Assistant制御は可能ですが、公式ドキュメントでは「experimental」とされています。
特に小型モデルでは、指示理解やツール呼び出しの安定性がクラウドLLMより落ちることがあるため、照明・センサー確認・状態要約などから始め、鍵や防犯系は避けるのが無難です。(Home Assistant)
ローカルLLMは、プライバシー重視の家庭内AIには相性が良いです。
Home Assistant公式ブログでも、クラウドAIだけでなくローカルLLMを選べることを、データとスマートホームを自分で制御するための重要な方向性として説明しています。(Home Assistant)
5. OpenRouter
OpenRouter統合は、Home AssistantからOpenRouter APIを会話エージェントとして使う方式です。
OpenRouter側のモデルを幅広く選べ、課金もOpenRouter側で処理されます。
公式ドキュメントでは、OpenAIなどのサードパーティAPIキーを使うことも可能と説明されています。(Home Assistant)
Home Assistant 2025.8ではOpenRouter統合が追加され、OpenRouter経由で400以上のモデルにアクセスできると説明されています。
用途別に「安いモデルで通知要約」「高性能モデルで複雑な自動化相談」のように分けたい場合に便利です。(Home Assistant)
6. AI Task
AI Taskは、LLMを自動化やスクリプトの中で使うための仕組みです。
たとえば「玄関カメラ画像を短く説明する」「センサー異常を通知文に整える」「一日の家の状態を要約する」など、会話ではなく処理部品としてLLMを使えます。
公式ドキュメントでは、タスクごとに優先AI Taskエンティティを設定でき、用途に応じて異なるモデルを使えると説明されています。(Home Assistant)
これは実用上かなり重要です。
音声アシスタントとしてAIを常用しなくても、通知文生成・画像説明・状態要約・自動化の補助だけLLMに任せる、という使い方ができます。
7. MCP Serverで外部AIからHome Assistantを使う
Home AssistantにはModel Context Protocol Server統合もあります。
これにより、Claude Desktop、Claude Code、Cursor、gemini-cliなどのMCPクライアントから、Home Assistantをツールとして使えます。
たとえばClaude Desktopから照明を操作したり、Google TasksのToDoリストをツールとして公開したりできます。(Home Assistant)
通常のLLM会話エージェントでは「Home AssistantがLLMにツールを渡す」形ですが、MCPでは「外部LLMアプリがHome AssistantのMCPサーバーへ接続する」形になります。
Home AssistantのMCPサーバーは /api/mcp で公開され、認証トークンが必要です。(Home Assistant)
8. 2026.4時点の新しいポイント：LLMの処理過程が見える
Home Assistant 2026.4では、LLM-powered Assistが処理中にどのような思考ステップやツール呼び出しを行ったかを、Assistダイアログ内で確認できるようになりました。
どのツールを呼び、どんな引数を渡し、どんな結果を受け取ったかを確認できるため、AI制御や自動化のデバッグに役立ちます。
ただし、現時点ではデスクトップWebのみで、モバイルアプリでは未対応です。(Home Assistant)
実用上のおすすめ
日本の家庭で現実的に始めるなら、次の順番が安全です。
| 目的 | おすすめ |
|---|---|
| まず試す | OpenAIまたはGoogle GeminiをAssistに接続 |
| プライバシー重視 | Ollamaを別PCやミニPCで動かす |
| モデルを比較したい | OpenRouter |
| Claudeから家の状態を扱いたい | Home Assistant MCP Server |
| 通知・要約だけ使いたい | AI Task |
| 鍵・防犯も扱いたい | exposed entitiesを厳しく制限して慎重に運用 |
個人的には、最初は 「GeminiまたはOpenAI＋AI Task」 で通知要約やカメラ画像説明を試し、次に OllamaローカルLLM を追加するのが堅実です。
家電操作をAIに任せる場合も、照明・エアコン・スマートプラグまでにとどめ、スマートロックや防犯カメラの共有・解錠系は人間確認を挟む設計が安全です。
回答された各LLMとHome Assistantを連携させる場合、どのような費用が発生するかを教えてください
はい。Home Assistant側のLLM連携で発生する費用は、基本的に Home Assistantの費用ではなく、使うLLM API・クラウド・ハードウェアの費用です。
まず結論
| 連携先 | Home Assistant連携自体 | 主な費用 | 月額の考え方 |
|---|---|---|---|
| OpenAI | 無料 | OpenAI API従量課金 | 使ったトークン分 |
| Anthropic / Claude | 無料 | Anthropic API従量課金 | 使ったトークン分 |
| Google Gemini | 無料 | Gemini API従量課金。無料枠あり | 無料枠超過後に課金 |
| Ollama | 無料 | PC・ミニPC・GPU・電気代 | API料金は原則なし |
| OpenRouter | 無料 | OpenRouter経由のモデル料金 | 事前チャージ＋従量課金 |
| AI Task | 無料 | 裏で使うLLMの料金 | OpenAI/Gemini/Ollama等に依存 |
| MCP Server | 無料 | 外部AIアプリ側の料金 | Claude/OpenAI/ローカルLLM等に依存 |
| Home Assistant Cloud | 任意 | 月額6.50ドルまたは年額65ドル | LLM連携には必須ではない |
1. OpenAIと連携する場合
Home AssistantのOpenAI統合はAPIキーが必要で、公式ドキュメントでも「有料サービスなので利用コストを監視し、usage limitを設定する」よう案内されています。ChatGPT Plusなどの月額料金とは別に、OpenAI APIの従量課金が発生します。(Home Assistant)
OpenAI APIの例では、GPT-5.4 miniが入力0.75ドル/100万トークン、出力4.50ドル/100万トークン、GPT-5.4が入力2.50ドル/100万トークン、出力15.00ドル/100万トークン、GPT-5.5が入力5.00ドル/100万トークン、出力30.00ドル/100万トークンです。(OpenAI)
費用感としては、照明操作、家の状態確認、短い通知要約程度なら、月に数十円〜数百円相当で収まる可能性が高いです。ただし、カメラ画像の解析、長い履歴の要約、頻繁な自動実行をさせると増えます。
2. Anthropic / Claudeと連携する場合
ClaudeもHome Assistant側の統合自体は無料ですが、Anthropic APIの利用料が発生します。Anthropicの公式価格では、Claude Sonnet 4.6が入力3ドル/100万トークン、出力15ドル/100万トークン、Claude Haiku 4.5が入力1ドル/100万トークン、出力5ドル/100万トークン、Claude Opus 4.7が入力5ドル/100万トークン、出力25ドル/100万トークンです。(Claude)
Claudeは、状態説明や自動化案の整理には向いていますが、毎回長い家の状態一覧を渡すと入力トークンが増えます。安く使うなら、Haiku系を通知要約・簡単な判断用、Sonnet系を複雑な相談用に分けるのが現実的です。
3. Google Geminiと連携する場合
Gemini APIは無料枠があり、無料枠の範囲では費用が発生しない場合があります。ただし、無料枠には制限があり、商用・安定運用・プライバシー条件を重視する場合は有料枠を前提に考えた方が安全です。
Gemini 2.5 Flashは、有料枠で入力0.30ドル/100万トークン、出力2.50ドル/100万トークンです。Google検索やGoogle Mapsのグラウンディングを使う場合は、一定回数を超えると別料金が発生します。(Google AI for Developers)
さらに安いGemini 2.5 Flash-Liteは、有料枠で入力0.10ドル/100万トークン、出力0.40ドル/100万トークンです。Home Assistantでの軽い通知要約や状態説明なら、かなり低コストです。(Google AI for Developers)
注意点として、Geminiの無料枠では「Used to improve our products」がYes、有料枠ではNoと示されています。家庭内カメラ画像や生活パターンを扱う場合は、無料か有料かだけでなく、データ利用条件も確認した方がよいです。(Google AI for Developers)
4. OllamaでローカルLLMを使う場合
Ollama連携では、OpenAIやGeminiのようなAPI従量課金は基本的に発生しません。Home Assistant公式ドキュメントでは、Ollama統合には外部Ollamaサーバーが必要で、macOS、Linux、Windowsで動かす形だと説明されています。(Home Assistant)
発生する費用は次のようなものです。
| 費用 | 内容 |
|---|---|
| 初期費用 | ミニPC、Mac、Windows PC、GPU搭載PCなど |
| 電気代 | 常時稼働させる場合に発生 |
| メンテナンス | モデル更新、ストレージ、バックアップ |
| 性能面のコスト | 小型モデルでは誤認識や遅延が出やすい |
すでにWindowsマシンやMacを持っていて、そこにOllamaを立てるなら、追加費用はほぼ電気代だけです。ただし、Home Assistantの音声アシスタント用途では、クラウドLLMより応答精度・ツール呼び出しの安定性が落ちる場合があります。
5. OpenRouter経由で使う場合
OpenRouterは、複数のLLMを1つのAPIで使える仲介サービスです。Home AssistantのOpenAI統合は公式OpenAI API専用ですが、Home Assistant側はOpenRouter統合を代替として案内しています。(Home Assistant)
OpenRouterは、無料プランでは無料モデルのみ、Pay-as-you-goでは300以上のモデルを使え、トークン料金はモデルごとに決まります。Pay-as-you-goでは最低利用額なしで、クレジットを購入して使う形です。(OpenRouter)
費用面では、**「OpenAI、Claude、Geminiなどを直接契約する代わりに、OpenRouterにチャージしてまとめて使う」**イメージです。複数モデルを試したい場合は便利ですが、予算上限・APIキーごとの利用制限を必ず設定した方がよいです。
6. AI Taskを使う場合
AI Task自体は、Home Assistantの中でAIを呼び出すための仕組みです。公式ドキュメントでも、AI Taskは単体で追加する統合ではなく、他の統合から提供される building block と説明されています。(Home Assistant)
つまり、AI Taskの費用はこうなります。
| AI Taskの裏で使うもの | 費用 |
|---|---|
| OpenAI | OpenAI API料金 |
| Claude | Anthropic API料金 |
| Gemini | Gemini API料金 |
| Ollama | API料金なし。ローカルPC・電気代 |
| OpenRouter | OpenRouterのモデル料金 |
たとえば、カメラ画像を5分ごとにAI解析するような設定にすると、1日288回、月8,000回以上呼び出す可能性があります。Home Assistant公式ブログでも、AI Taskをカメラ画像解析や自動化・スクリプト内で使える例が示されています。(Home Assistant)
このような使い方では、手動音声操作より費用が増えやすいです。
7. MCP Serverを使う場合
Home AssistantのMCP Server連携自体は無料です。MCP Serverは、Claude Desktopや他のLLMクライアントにHome Assistantの情報や操作機能を渡すための仕組みです。Home Assistant公式ドキュメントでも、Claude Desktopから照明を操作したり、Home Assistantの情報を外部LLMへ提供したりできる例が示されています。(Home Assistant)
ただし費用は、MCPを呼び出す側に依存します。
| MCPを使う側 | 発生する費用 |
|---|---|
| Claude Desktop / Claude API | ClaudeのプランまたはAPI料金 |
| OpenAI APIクライアント | OpenAI API料金 |
| ローカルLLM | PC・GPU・電気代 |
| Cursor / Claude Code等 | そのアプリ側の月額・API料金 |
MCPは「Home Assistantを道具として外部AIに使わせる仕組み」なので、MCPそのものより、どのAIアプリ・どのモデルで呼び出すかが費用を決めます。
8. Home Assistant Cloudは必要か
Home Assistant Cloud、つまりNabu Casaのサブスクは、LLM連携そのものには必須ではありません。料金はInternationalで月額6.50ドル、年額65ドルです。(Nabu Casa)
主な用途は、外出先からの安全なリモートアクセス、AlexaやGoogle Assistantとの簡単連携、Home Assistant開発支援などです。LLM API費用とは別物です。
ざっくり費用シミュレーション
仮に、1回のAI利用を「入力2,000トークン、出力500トークン」とし、月100回使うとします。
| モデル例 | 月100回の概算 |
|---|---|
| Gemini 2.5 Flash-Lite | 約0.04ドル |
| Gemini 2.5 Flash | 約0.19ドル |
| OpenAI GPT-5.4 mini | 約0.38ドル |
| Claude Haiku 4.5 | 約0.45ドル |
| OpenAI GPT-5.4 | 約1.25ドル |
| Claude Sonnet 4.6 | 約1.35ドル |
| OpenAI GPT-5.5 | 約2.50ドル |
| Claude Opus 4.7 | 約2.25ドル |
これはあくまで目安です。実際は、渡すエンティティ数、会話履歴、画像添付、音声入出力、検索・地図グラウンディングの有無で変わります。
おすすめの費用設計
一番堅実なのは、次の構成です。
| 用途 | おすすめ |
|---|---|
| 日常の短い操作 | Gemini Flash-Lite / OpenAI mini / Claude Haiku |
| 状態要約・通知文生成 | Gemini Flash-LiteまたはOpenAI mini |
| 複雑な自動化相談 | Claude SonnetまたはOpenAI上位モデル |
| カメラ画像解析 | Gemini Flash系、ただし実行頻度を制限 |
| プライバシー重視 | Ollama |
| モデル比較 | OpenRouter |
| 外部AIからHAを操作 | MCP Server＋使いたいAI |
結論としては、最初はGemini Flash-Lite、OpenAI mini、Claude Haikuのどれかで小さく始め、usage limitを設定するのが安全です。カメラ解析や定期AI Taskを多用する場合だけ、Ollamaローカル運用やOpenRouterでのモデル切替を検討するとよいです。
Home Assistantを使うメリット
赤外線で制御される機器はBroadlinkのアプリで行うとして、一般家庭でHome Assistantを使うメリットについて調べてください。自宅にローカルLLMをおけばこんなことができるとか、お金をかけずにこんなことができるということを知りたいです。
結論から言うと、赤外線家電の操作をBroadlinkアプリに任せる場合でも、Home Assistantを使うメリットはあります。
ただし、Home Assistantの価値は「赤外線リモコンの代替」ではなく、家全体の情報を集める・自動化する・見える化する・ローカルAIで判断補助するところにあります。
まず注意点
Broadlinkアプリだけで赤外線機器を操作する場合、Home Assistantはその赤外線機器を直接操作できません。
Home Assistantからも赤外線操作したい場合は、Broadlink統合や赤外線コード登録が必要です。
Home Assistant公式のBroadlink統合では、Broadlink Managerなどで赤外線コードを取得してHome Assistant側で使う方法が説明されています。(Home Assistant)
つまり、考え方は次の2通りです。
| 使い方 | Home Assistantの役割 |
|---|---|
| Broadlinkアプリだけで赤外線操作 | Home Assistantは見える化・通知・センサー連携・AI要約が中心 |
| BroadlinkをHome Assistantにも統合 | Home Assistantからエアコン・テレビ等も自動制御できる |
一般家庭で本当に便利になるのは、後者です。
ただし、最初は前者でも十分試す価値があります。
Home Assistantを使う主なメリット
Home Assistantは、公式サイトでも「ローカル制御とプライバシーを重視するオープンソースのホームオートメーション」と説明されており、3500以上の統合を参照できます。(Home Assistant)
Broadlinkアプリ単独だと、基本的には「赤外線家電をスマホで操作するアプリ」です。
Home Assistantを入れると、次のように家全体を1つのシステムとして扱うことができます。
| できること | Broadlinkアプリ単独 | Home Assistant |
|---|---|---|
| エアコン・テレビの赤外線操作 | できる | Broadlink統合すればできる |
| 温湿度・人感・照度・電力の統合 | 弱い | 強い |
| 家全体のダッシュボード | 限定的 | 強い |
| 複数メーカー機器の連携 | 弱い | 強い |
| スマホ位置情報による在宅判定 | 限定的 | できる |
| 自動化の細かい条件設定 | 限定的 | 強い |
| ローカルLLM連携 | 基本なし | できる |
| クラウド依存を減らす | 限定的 | 可能 |
お金をかけずにできること
Home Assistant本体は無料で使えます。
既存のMac、Windows PC、Linuxマシン、ミニPC、Raspberry Piなどに入れれば、追加費用は基本的に電気代だけです。
Home Assistant Greenを買う場合は別途ハード代が必要で、2026年4月時点の公式発表では推奨小売価格が199ドル / 179ユーロに上がっています。
ただし、公式発表でもHome AssistantはGreen以外の手頃なハードでも動かせると説明されています。(Nabu Casa)
また、Home Assistant Cloudは必須ではありません。
外出先アクセスやGoogle/Alexa連携を簡単にしたい場合の有料サービスで、International価格は月額6.50ドル、年額65ドルです。(Nabu Casa)
無料または低コストで始める例
| 構成 | 費用感 |
|---|---|
| 既存PCにHome Assistantを入れる | ほぼ無料、電気代のみ |
| 既存Windows PCにOllamaを入れてローカルLLM化 | API料金なし |
| スマホアプリを入れて在宅判定・通知に使う | 無料 |
| 手持ちのスマートプラグやセンサーを統合 | 追加購入なしなら無料 |
| 外出先アクセスをVPN/Tailscale等で行う | 工夫すれば無料枠で可能 |
ローカルLLMを置くと何ができるか
Home AssistantはOllama統合に対応しており、macOS、Linux、Windows上で動かしたOllamaサーバーをHome Assistantから使えます。
AIにHome AssistantのAssist APIへのアクセスを与え、公開したエンティティだけ情報取得・操作できる仕組みです。(Home Assistant)
ユーザーさんの場合、以前から触れているNVIDIA 5070Ti・VRAM 16GBのWindowsマシンがあるなら、Home Assistant本体は小型PCや別端末、LLMはWindows側のOllama、という構成が現実的です。
できることの例
| ローカルLLM活用 | 具体例 |
|---|---|
| 家の状態を自然文で要約 | 「今の家の状態をまとめて」→ 室温、湿度、照明、電力などを要約 |
| 通知文を分かりやすくする | 「湿度が高い」ではなく「洗面所の湿度が高く、換気した方がよさそうです」 |
| センサー異常の説明 | 電力・温度・人感の変化を見て「いつもと違う」可能性を説明 |
| 自動化案の作成補助 | 「朝7時、寒ければ暖房通知」などのルール案を作る |
| カメラ画像の説明 | 玄関カメラ画像から「人がいる」「荷物らしい」などを要約 |
| 家族向けのやさしい通知 | 技術的なセンサー名を生活文に変換 |
Home Assistant公式ブログでも、LLMはHome Assistantに統合されたクラウドLLMまたはOllamaのようなローカルLLMと会話でき、公開したセンサー情報を要約できると説明されています。(Home Assistant)
AI Taskでできることが実用的
Home Assistantでは、AIを会話だけでなく、自動化やスクリプトの部品として使う「AI Tasks」が重要です。
公式ブログでは、AI Tasksによりテンプレート、スクリプト、自動化の中でAIを呼び出し、画像やファイルを添付して、JSON形式などで結果を返せると説明されています。(Home Assistant)
たとえば、ローカルLLMや画像対応AIを使って、次のようなことができます。
| 例 | 内容 |
|---|---|
| 玄関カメラの通知要約 | 「動体検知」ではなく「玄関前に人影があります」 |
| ペット・家族の見守り | 人感、ドア、温度から状況を文章化 |
| 電力使用量の説明 | 「この時間帯に消費電力が増えています」 |
| 自動化の名前付け | 作成した自動化に分かりやすい名前・説明をAIが提案 |
| 日次レポート | 「今日の室温・湿度・電力・在宅状況」をまとめる |
特に便利なのは、通知を人間が読みやすい文章に変換する用途です。
「センサーAがon」ではなく、「玄関ドアが開いたまま5分経過しています」のようにできます。
音声アシスタントもローカル寄りにできる
Home AssistantのAssistは、ローカル音声アシスタントとして使えます。
公式ドキュメントでは、ローカルで動く音声認識・音声合成の選択肢があり、外部サーバーにデータを送らずに処理できると説明されています。(Home Assistant)
さらに、Voice Preview Editionは「オープン・ローカル・プライベートな音声アシスタント」を目指すハードウェアで、ローカルLLMやGoogle/OpenAI/Anthropicなどにも接続できるとされています。(Home Assistant)
家庭での例
| 音声指示 | できること |
|---|---|
| 「今、家の中で気になることある？」 | センサー状態を要約 |
| 「寒い？」 | 室温と外気温から説明 |
| 「寝る準備をして」 | 照明、通知、空調、戸締まり確認 |
| 「今日の電気の使い方を教えて」 | 電力データを要約 |
| 「玄関の状況を教えて」 | ドア・人感・カメラ情報をまとめる |
BroadlinkをHome Assistantに統合すれば、ここに「エアコンをつける」「テレビを消す」も加えられます。
ダッシュボードが便利
Home Assistantは、スマホやPCで見られるダッシュボードを自由に作れます。
公式ドキュメントでは、ダッシュボードはスマートホーム情報の表示・管理に使え、カード、テーマ、名前やアイコン、カスタムカードなどを使って調整できると説明されています。(Home Assistant)
一般家庭では、次のような画面を作ると便利です。
| ダッシュボード例 | 内容 |
|---|---|
| 家族用トップ画面 | 照明、室温、湿度、天気、戸締まり |
| エネルギー画面 | 電力、太陽光、消費電力、水道、ガス |
| 防犯・見守り画面 | ドア、窓、人感、カメラ、通知履歴 |
| 寝室用画面 | 温湿度、照明、エアコン状態、アラーム |
| ブログ・検証用画面 | センサー値、AI要約、ログ、グラフ |
2026.1では、モバイル向けHome Dashboardが改善され、照明、空調、防犯、メディア、天気、エネルギーなどの要約カードが見やすくなっています。(Home Assistant)
自動化が強い
Home Assistantの自動化は、基本的に「トリガー」「条件」「アクション」で構成されます。
公式ドキュメントでも、「誰かが帰宅し、日没後なら、リビングの照明を点ける」という例で説明されています。(Home Assistant)
一般家庭で使いやすい例は次のようなものです。
| 自動化 | 内容 |
|---|---|
| 帰宅時通知 | 家族のスマホが帰宅したら通知 |
| 外出時チェック | 窓、照明、消費電力を確認 |
| 湿度対策 | 洗面所の湿度が高いと換気通知 |
| 熱中症対策 | 室温が高いと通知 |
| 節電 | 待機電力が大きい機器を検知 |
| 高齢者見守り | 一定時間、人感・ドア反応がない場合に通知 |
| 防犯 | 夜間に玄関ドアが開いたら通知 |
スマホアプリ側では、Androidの位置情報センサーなどをHome Assistantに渡せます。
公式Companion Appドキュメントでは、AndroidのLocation Sensorsは権限と位置情報が有効である必要があり、Background Locationなどが使えると説明されています。(companion.home-assistant.io)
エネルギー管理がかなり実用的
電気代や太陽光発電に関心がある場合、Home Assistantはかなり相性が良いです。
2025.12の更新では、Energy Dashboardでリアルタイム電力監視や水使用量の内訳表示が強化されています。(Home Assistant)
たとえば、次のような使い方ができます。
| 用途 | 例 |
|---|---|
| 電力の見える化 | 今どれくらい電気を使っているか確認 |
| 太陽光発電の確認 | 発電量、売電、買電の把握 |
| エアコン消費の推定 | スマートプラグや電力センサーで確認 |
| 異常検知 | 夜中に消費電力が急増したら通知 |
| 節電レポート | ローカルLLMで「今日の電気使用傾向」を要約 |
これはBroadlinkアプリ単独ではかなり難しい領域です。
Broadlinkアプリ併用での現実的な使い方
最初から全部をHome Assistantに集約しなくても、次のように段階的に進めるのがよいです。
第1段階：Broadlinkアプリはそのまま、Home Assistantは見える化に使う
できること：
| 追加するもの | できること |
|---|---|
| 温湿度センサー | 部屋の快適度を表示 |
| スマートプラグ | 電力使用量を把握 |
| スマホアプリ | 在宅・外出判定 |
| 人感センサー | 見守り・防犯 |
| ローカルLLM | 状況要約・通知文生成 |
この段階では、赤外線家電の操作はBroadlinkアプリで行います。
第2段階：BroadlinkをHome Assistantにも連携
できること：
| 連携後 | 例 |
|---|---|
| 温度に応じてエアコン操作 | 室温28℃以上なら冷房通知またはON |
| 就寝モード | 照明OFF、テレビOFF、エアコン弱運転 |
| 外出時 | テレビOFF、エアコンOFF、照明OFF |
| 帰宅前 | 在宅判定や時刻に応じてエアコンON |
| 音声操作 | 「寒いから暖かくして」など |
ここまで来ると、Home Assistantの価値が一気に上がります。
ローカルLLM込みで「お金をかけずに」できそうな構成
既存のWindows PCを活用するなら、次の構成が安価です。
| 役割 | 機器・ソフト |
|---|---|
| Home Assistant本体 | 既存ミニPC、Raspberry Pi、古いPC、または仮想環境 |
| LLMサーバー | Windows PC + Ollama |
| 音声なしAI | Home Assistantのチャット/Assist |
| センサー | 既存スマートプラグ、温湿度センサー、スマホアプリ |
| 赤外線操作 | 当面はBroadlinkアプリ |
| 外出先アクセス | まずは自宅内限定。必要ならVPNやNabu Casaを検討 |
この構成なら、クラウドLLMのAPI料金をかけずに、まずは以下を試せます。
| 無料で試しやすいこと | 内容 |
|---|---|
| 家の状態をAIに要約させる | 温湿度、電力、在宅状態など |
| 通知文を自然な文章にする | センサー通知を家族向けに変換 |
| 自動化案を相談する | 「このセンサーで何ができる？」 |
| 日次レポートを作る | 1日の室温・電力・在宅状況 |
| センサー異常の説明 | 普段と違う値を説明させる |
逆に、Home Assistantが不要なケース
次のような使い方だけなら、Home Assistantなしでも十分です。
| 状況 | 理由 |
|---|---|
| エアコンとテレビをスマホで操作したいだけ | Broadlinkアプリで足りる |
| 自動化を細かく作る予定がない | HAの設定負担が大きい |
| センサーや電力監視を増やす予定がない | 連携メリットが少ない |
| 家族がアプリを増やしたくない | 運用が面倒になる可能性 |
| ローカルAIや見える化に興味が薄い | HAの強みを活かしにくい |
私ならこう始めます
赤外線制御はBroadlinkアプリに残す前提なら、まずはHome Assistantを家の情報ダッシュボード＋AI要約システムとして使うのが良いです。
おすすめ順は次の通りです。
- 既存PCかミニPCにHome Assistantを入れる
- スマホアプリを入れて在宅判定と通知を試す
- 温湿度センサー、スマートプラグ、電力センサーを追加
- Windows PCにOllamaを入れてローカルLLM連携
- Home Assistantに「今日の家の状態を要約」させる
- 必要を感じたらBroadlinkもHome Assistantに統合する
最初の目的は、赤外線家電を全部Home Assistantに移すことではなく、「家の状態を見える化し、AIで分かりやすく説明させること」にすると失敗しにくいです。
古い Intel Mac miniにHome Assistantを入れることができるか
Intel Mac miniにHome Assistantを入れることはできますか。
2.6GHz デュアルコア Inte Core i5,3MB L3 キャッシュ,8GBの1600MHz LPDDR3,1TBハードドライブの機種です
その仕様なら、Mac mini Late 2014 です。
おそらく以下のモデルです。
| 項目 | 内容 |
|---|---|
| 機種 | Mac mini Late 2014 |
| Model No. | A1347 |
| Model Identifier | Macmini7,1 |
| CPU | 2.6GHz デュアルコア Intel Core i5 |
| メモリ | 8GB 1600MHz LPDDR3 |
| ストレージ | 1TB HDD |
| メモリ増設 | 不可。基板直付け |
| USB | USB 3.0対応 |
| 用途適性 | Home Assistant用としては十分使える |
Home Assistant用途としての評価
結論として、このMac miniは Home Assistant用に十分使えます。
特に、赤外線制御はBroadlinkアプリに任せ、Home Assistantではダッシュボード、通知、センサー連携、在宅判定、AI要約などを行う用途なら問題ありません。
| 用途 | 評価 |
|---|---|
| Home Assistant本体 | 十分使える |
| スマホ通知 | 問題なし |
| 在宅・外出判定 | 問題なし |
| 温湿度・電力センサー管理 | 問題なし |
| Broadlink連携 | 可能 |
| ダッシュボード表示 | 問題なし |
| Matter / Zigbeeアドオン | 構成次第で可能 |
| ローカルLLM | 軽量モデルなら試せるが、快適ではない |
| 画像AI解析 | あまり向かない |
一番の弱点はHDDです
この機種の弱点は、CPUやメモリよりも 1TBハードディスク です。
Home Assistant自体は軽いですが、起動、アップデート、バックアップ、データベース処理でHDDの遅さが出やすいです。
可能なら、次のどちらかをおすすめします。
| 改善策 | 効果 |
|---|---|
| 外付けUSB 3.0 SSDから起動 | 比較的簡単。体感速度が大きく改善 |
| 内蔵HDDをSSDへ交換 | 安定するが分解作業が必要 |
まず試すだけならHDDのままでも構いません。
ただし、長期運用するなら SSD化した方がかなり快適です。
おすすめの入れ方
おすすめ1：macOS上の仮想マシンにHome Assistant OS
最初に試すなら、この方法が一番安全です。
| 項目 | 推奨 |
|---|---|
| 方式 | macOS上でHome Assistant OSをVM起動 |
| 仮想化ソフト | VirtualBoxなど |
| メモリ割り当て | 2GB〜4GB |
| CPU割り当て | 2コア |
| ストレージ | 32GB以上、できれば64GB |
| ネットワーク | ブリッジ接続 |
この方法なら、macOSを消さずにHome Assistantを試せます。
失敗しても仮想マシンを削除すればよいので、最初の検証に向いています。
おすすめ2：Mac miniをHome Assistant専用機にする
Mac miniを完全にHome Assistant専用にするなら、Home Assistant OSを直接入れる方法もあります。
| メリット | デメリット |
|---|---|
| 安定しやすい | macOSを消すことになる |
| 常時稼働向き | 元のMac用途には戻しにくい |
| アドオンが使いやすい | 導入はやや慎重さが必要 |
この方法は、Home Assistantを本格運用すると決めてからでよいです。
8GBメモリで足りるか
Home Assistantだけなら、8GBで十分です。
| 構成 | 目安 |
|---|---|
| Home Assistant OSのみ | 十分 |
| ESPHome、Mosquitto、Matter Serverなどのアドオン | だいたい問題なし |
| データベース長期保存 | ストレージ速度の方が重要 |
| Home Assistant + OllamaローカルLLM | かなり厳しい |
| Home Assistant + 画像AI解析 | 厳しい |
このMac miniではメモリ増設ができないため、8GBの範囲で運用する前提になります。
Home Assistant用途なら問題ありませんが、LLMまで同居させるには余裕が少ないです。
ローカルLLMはどうか
このMac miniでもOllamaなどを入れて小型LLMを試すことはできますが、快適さはあまり期待しない方がよいです。
| LLM用途 | このMac miniでの現実性 |
|---|---|
| 短い通知文の整形 | 軽量モデルなら可能性あり |
| 家の状態の短い要約 | 軽量モデルなら試せる |
| 自然な会話 | 遅い可能性が高い |
| カメラ画像の解析 | 不向き |
| Home Assistantとは別PCのLLMを使う | おすすめ |
ユーザーさんの場合、以前話題に出ていた NVIDIA 5070Ti搭載Windowsマシンがあるなら、
Home AssistantはMac mini、ローカルLLMはWindows PC
という分担がかなり現実的です。
構成例：
| 役割 | 機器 |
|---|---|
| Home Assistant本体 | Mac mini Late 2014 |
| ローカルLLM | Windows PC + Ollama |
| 赤外線操作 | Broadlinkアプリ |
| スマホ操作 | iPhone / AndroidのHome Assistantアプリ |
| 通知・在宅判定 | Home Assistant Companion App |
この機種で最初にやるなら
おすすめの順番はこれです。
- Mac miniのスリープを無効化
- できれば外付けSSDを用意
- macOS上に仮想マシンでHome Assistant OSを入れる
- iPhone/AndroidにHome Assistantアプリを入れる
- 温湿度センサーやスマートプラグを追加
- 通知・在宅判定・ダッシュボードを試す
- 必要になったらBroadlinkもHome Assistantに統合
- ローカルLLMは別PCでOllama運用を検討
判断
このMac miniは、Home Assistant入門機としてかなり使いやすいです。
ただし、長期運用するなら HDDのまま使うより、外付けSSDまたは内蔵SSD化を強くおすすめします。
赤外線操作をBroadlinkアプリに残す前提でも、Home Assistantで
家の状態確認、通知、在宅判定、電力・温湿度の見える化、ローカルLLMによる要約
を試すには十分な性能です。
今回の目的では、追加費用を発生させずに、自宅にHOME Assistantサーバーを構築し、ローカルLLMとのチャットで、自宅の機器の状態監視・制御を行うことであるが、古いIntel Mac miniのOSや内蔵メモリの制限、内蔵HDDの遅さ、ローカルLLMのサイズ制限などにより、LLMは快適には使えないことが予想された。クラウドLLMとの連携は想定していない。
実際、ローカルLLMの音声アシスタントの応答は遅く、回答が始まるまでに約2分かかり、回答が始まっても、文字がゆっくり現れていくような状態だった。快適でない現状を経験したからこそ、将来、それらの制限のない環境にグレードアップすることが楽しみ。
古い Intel Mac miniにどの程度のローカルLLMを入れることができるか
ローカルLLMは、どの程度のものが使え、どのようなことができますか
結論として、その Mac mini Late 2014 / Core i5 / 8GB RAM / 1TB HDD でローカルLLMは使えます。
ただし、「軽量LLMで家の状態を要約する」程度が現実的で、ChatGPTやClaudeのような高性能な会話、画像解析、複雑な推論まで期待するのは厳しいです。
このMac miniで現実的に使えるLLMの規模
目安は次のようになります。
| モデル規模 | このMac miniでの現実性 | 用途 |
|---|---|---|
| 1B〜2B級 | ◎ 現実的 | 短い要約、通知文作成、簡単な質問応答 |
| 3B〜4B級 | ○ 何とか実用 | 家の状態要約、簡単な自動化相談、文章整形 |
| 7B級 | △ 動く可能性はあるが遅い | 実験用。音声応答や日常利用には重い |
| 8B〜9B級以上 | △〜× 厳しい | メモリ圧迫・応答待ちが長い |
| 13B以上 | × 非推奨 | このMac mini単体では現実的ではない |
OllamaのHome Assistant統合は、外部Ollamaサーバーを使う方式で、macOS/Linux/Windows上のOllamaに接続できます。AIにHome AssistantのAssist APIを渡すと、公開したエンティティの情報取得や制御も可能ですが、この制御機能は公式にも「experimental」とされています。(Home Assistant)
試すならこのあたりのモデル
1. Llama 3.2 1B / 3B
このMac miniで最初に試すなら、Llama 3.2 1B または Llama 3.2 3B が無難です。
Ollama公式では、Llama 3.2は1B/3Bのテキストモデルで、3Bは指示追従、要約、プロンプト書き換え、ツール利用に向くと説明されています。(Ollama)
使い方のイメージ：
ollama run llama3.2:1b
ollama run llama3.2向いていること
| 用途 | 評価 |
|---|---|
| センサー状態の短い要約 | ○ |
| 通知文を自然な日本語にする | ○ |
| 「湿度が高い理由」を説明 | ○ |
| 家電操作の意図理解 | △ |
| 複雑な会話 | △ |
| 画像解析 | × |
2. Gemma 3n e2b / e4b
Gemma 3nは、ラップトップ、タブレット、スマホのような日常デバイスで効率的に動くよう設計され、選択的パラメータ活性化により実効2B/4Bサイズとして動くと説明されています。(Ollama)
ollama run gemma3n:e2b
ollama run gemma3n:e4bこのMac miniでは、まず e2b から試すのがよいです。e4bは動く可能性はありますが、Home AssistantをVMで動かしながらだとメモリが苦しくなる可能性があります。
3. Phi-4 mini
Phi-4 miniは、メモリや計算資源が限られる環境、低遅延用途、数学・論理寄りの推論を想定した軽量モデルとして説明されています。(Ollama)
ollama run phi4-mini向いていること
| 用途 | 評価 |
|---|---|
| 条件整理 | ○ |
| 自動化ルール案の作成 | ○ |
| 通知文の整形 | ○ |
| 日本語の自然さ | モデル次第で要確認 |
| 応答速度 | Mac miniではやや重めの可能性 |
4. Mistral 7B
Mistral 7Bは7Bパラメータのモデルで、instruction followingにも対応し、v0.3ではfunction callingにも対応するとされています。(Ollama)
ollama run mistralただし、このMac miniでは実験用と考えた方がよいです。8GBメモリ、HDD、Intel CPUという条件では、応答が遅くなりやすいです。
Home Assistantと組み合わせてできること
Home Assistant公式ブログでは、LLMをクラウドまたはOllamaのようなローカル環境で使い、Assistに公開したスマートホームセンサーの状況を要約できると説明されています。
また、通常のAssistで処理できない自然な依頼をAIへ渡す考え方も示されています。(Home Assistant)
できること1：家の状態を自然文で要約
たとえば、Home Assistantに以下の情報が入っているとします。
| センサー | 例 |
|---|---|
| リビング温度 | 27.8℃ |
| 湿度 | 68% |
| 玄関ドア | 閉 |
| 洗面所湿度 | 75% |
| 消費電力 | 高め |
| 在宅状況 | 在宅 |
ローカルLLMにこう聞けます。
今の家の状態を、家族向けに短く説明して。
出力例：
リビングは少し蒸し暑く、洗面所の湿度が高めです。玄関は閉まっています。換気か除湿をすると快適になりそうです。
これは、軽量LLMでも比較的得意です。
できること2：通知文を分かりやすくする
Home Assistantの普通の通知は、どうしても機械的になりがちです。
通常：
sensor.bathroom_humidity が 75 を超えました。
LLM利用：
洗面所の湿度が75%を超えています。カビ防止のため、換気扇を回すか窓を開けるとよさそうです。
この用途なら、1B〜3B級でも十分試す価値があります。
できること3：自動化の案を作る
たとえば、LLMにこう相談できます。
温湿度センサー、人感センサー、スマートプラグがある場合、どんな自動化が便利？
出力例：
| 提案例 | 内容 |
|---|---|
| 湿度対策 | 洗面所の湿度が70%超で通知 |
| 消し忘れ確認 | 外出時に消費電力が高ければ通知 |
| 熱中症対策 | 室温30℃超でスマホ通知 |
| 見守り | 朝から人感反応がなければ確認通知 |
| 節電 | 深夜に待機電力が高ければ通知 |
ただし、LLMに直接すべてを自動実行させるより、提案だけさせて、人間が自動化を作る方が安全です。
できること4：AI Task的な使い方
Home Assistant 2025.8では、AI Tasksが導入され、AIにタスクを渡して構造化された結果を受け取り、自動化やワークフローに使う基盤が追加されています。
OllamaサーバーやOpenAI APIキーなどを一度設定し、異なるモデルや設定のエージェントを作れる方向も示されています。(Home Assistant)
具体例：
| AI Task | 内容 |
|---|---|
| 朝の家の状態レポート | 室温、湿度、電力、天気を短く要約 |
| 夜の戸締まりレポート | ドア、窓、照明、電力状態を説明 |
| 異常通知の文章化 | 「普段より電力が高い」理由候補を説明 |
| センサー名の翻訳 | binary_sensor.door_1 を「玄関ドア」に言い換え |
| 家族向け説明 | 技術的な状態をやさしい文章に変換 |
Broadlinkアプリを使う場合にできること
赤外線操作をBroadlinkアプリに任せる場合、Home Assistant側のLLMは直接エアコンやテレビを操作しません。
その場合は、以下のような使い方になります。
| 使い方 | 例 |
|---|---|
| 状況判断 | 「室温が高いのでエアコンを入れた方がよさそうです」 |
| 通知 | 「リビングが暑くなっています。Broadlinkで冷房を入れるとよさそうです」 |
| レポート | 「今日は午後から室温が上がりやすい傾向でした」 |
| 自動化案 | 「この条件ならBroadlink連携をHA側にも入れると便利です」 |
もし将来BroadlinkをHome Assistantにも統合すれば、LLMや自動化から「冷房を入れる」「テレビを消す」なども可能になります。ただし、最初は通知・要約止まりにする方が安全です。
このMac miniで苦手なこと
| 苦手なこと | 理由 |
|---|---|
| リアルタイム音声会話 | 応答生成が遅い |
| 画像認識 | CPU・メモリ的に重い |
| 長い会話履歴の保持 | 8GB RAMでは厳しい |
| 7B以上の常用 | 応答待ちが長くなりやすい |
| Home Assistant VMとLLMの同居 | メモリを奪い合う |
| HDD運用 | モデル読み込み・更新が遅い |
Ollama公式ドキュメントでも、モデル保存には追加ストレージが必要で、モデルは数十GB〜数百GBになる場合があると説明されています。(Ollama Documentation)
このMac miniはHDDなので、LLMを試すなら外付けUSB 3.0 SSDにモデルを置く方が快適です。
おすすめ構成
構成A：Mac miniだけで試す
| 役割 | 内容 |
|---|---|
| Home Assistant | macOS上のVM |
| LLM | macOS側のOllama |
| モデル | Llama 3.2 1B / 3B、Gemma 3n e2b |
| 用途 | 通知文生成、家の状態要約、軽い相談 |
この構成は無料で試せるのがメリットです。
ただし、快適さは限定的です。
構成B：Mac miniはHome Assistant専用、LLMは別PC
| 役割 | 内容 |
|---|---|
| Home Assistant | Mac mini |
| LLM | Windows PC + Ollama |
| 接続 | Home AssistantのOllama統合でWindows PCに接続 |
| モデル | 7B〜14B級も現実的 |
| 用途 | より自然な会話、詳しい要約、複雑な自動化相談 |
以前話されていた NVIDIA 5070Ti / VRAM 16GBのWindowsマシンがあるなら、こちらの方がかなり実用的です。
Home AssistantのOllama統合は外部Ollamaサーバーに接続する方式なので、Mac mini上にLLMを置く必要はありません。(Home Assistant)
このMac miniで最初に試すなら
まずは以下の順番がよいです。
- Mac miniにHome Assistantを入れる
- 外付けSSDを使えるなら用意する
- Ollamaを入れる
llama3.2:1bを試す- 問題なければ
llama3.2またはgemma3n:e2bを試す - Home AssistantのOllama統合に接続する
- AIに公開するエンティティを最小限にする
- 「家の状態要約」「通知文生成」から始める
実用度の判断
このMac mini単体では、ローカルLLMは次のような位置付けです。
| 目的 | 実用度 |
|---|---|
| 家の状態を短く要約 | 高い |
| 通知文を自然にする | 高い |
| 自動化案を作る | 中 |
| 音声で柔軟に家電操作 | 低〜中 |
| AIに家電制御まで任せる | 慎重にすべき |
| 画像認識・防犯カメラ解析 | 低い |
| ChatGPT代替 | 低い |
つまり、このMac miniでは「家庭内AI秘書」よりも、「Home Assistantの通知・要約を賢くする補助AI」と考えるのが現実的です。
本格的にローカルLLMを使うなら、Home AssistantはMac mini、LLMはGPU搭載Windows PCに分ける構成が一番おすすめです。
Apple TVのルーター機能
Apple TVは、ThreadボーダールーターおよびMatterハブとして機能するということについて説明してください
はい。Apple TVは、対応機種であれば 「Apple Homeのホームハブ」 として動作し、さらに一部モデルは 「Threadボーダールーター」 としても機能します。
Home Assistantと併用する場合は、Apple TVをThread側の通信インフラとして使い、Home AssistantをMatterコントローラーとして使うという考え方になります。
まず用語の整理
| 用語 | 役割 | Apple TVとの関係 |
|---|---|---|
| Matter | スマートホーム機器を共通操作するための規格 | Apple Home / Home Assistant / Google HomeなどがMatter機器を操作できる |
| Thread | 低消費電力のメッシュ通信規格 | センサー、ロック、電球などがThreadで通信する |
| Threadボーダールーター | Thread機器と家庭内LANをつなぐ橋渡し | 対応Apple TVがこの役割を持てる |
| ホームハブ | Apple Homeの遠隔操作・自動化の中継役 | Apple TVやHomePodが担当 |
| Matterハブ | 厳密には「Matterコントローラー」に近い意味で使われることが多い | Apple TVはApple Home側の中核としてMatter機器管理に関与 |
対応するApple TV
Apple公式では、Thread対応のApple製デバイスとして、Apple TV 4K 第2世代 と Apple TV 4K 第3世代 Wi-Fi + Ethernet が挙げられています。
第3世代でも、Thread対応は Wi-Fi + Ethernetモデル であり、Wi-Fiのみモデルとは区別が必要です。(Appleサポート)
| Apple TV | Threadボーダールーター | Apple Homeハブ |
|---|---|---|
| Apple TV HD | × | ○ |
| Apple TV 4K 第1世代 | × | ○ |
| Apple TV 4K 第2世代 | ○ | ○ |
| Apple TV 4K 第3世代 Wi-Fiモデル | × | ○ |
| Apple TV 4K 第3世代 Wi-Fi + Ethernetモデル | ○ | ○ |
つまり、すべてのApple TVがThreadボーダールーターになるわけではありません。
Threadボーダールーターとしての役割
Thread対応のMatter機器、たとえばドアセンサー、温湿度センサー、スマートロック、電球などは、Wi-FiではなくThreadで通信します。
このときApple TVは、次のような橋渡しをします。
Thread対応機器
↓ Thread
Apple TV 4K
↓ Wi-Fi / 有線LAN
家庭内LAN
↓
iPhone / Apple Home / Home Assistant などApple公式も、Threadベースのアクセサリには、Apple TV 4K、HomePod mini、HomePod 第2世代、または対応する他社製Threadボーダールーターが必要だと説明しています。(Appleサポート)
重要なのは、Apple TVが「家電を直接操作するリモコン」になるというより、Thread機器を家庭内ネットワークへ参加させる通信の橋になるという点です。
Matterハブ／ホームハブとしての役割
Apple TVは、Apple Homeでは ホームハブ として機能します。
ホームハブがあると、外出先からの操作、自動化、通知、Matter機器の管理が安定しやすくなります。
Apple公式でも、HomeアプリにMatterアクセサリを追加するにはホームハブの設定が必要と説明されています。(Appleサポート)
Apple Home側では、Apple TVが次のような役割を持ちます。
| 役割 | 内容 |
|---|---|
| 遠隔操作 | 外出先からApple Home機器を操作 |
| 自動化 | 時刻・在宅・センサー条件で自動化 |
| Matter機器管理 | MatterアクセサリをApple Homeに追加・管理 |
| Thread中継 | 対応モデルではThread機器をLANへ中継 |
| 家族共有 | 家族のHomeアプリ利用を支援 |
Home Assistantと併用する場合
Home Assistantから見ると、Apple TVは主に Threadボーダールーター として役立ちます。
たとえば、Thread対応Matterセンサーを使う場合、次の2パターンがあります。
パターン1：Apple TVをThreadボーダールーターにする
Thread Matter機器
↓
Apple TV 4K
↓
家庭内LAN
↓
Home Assistantこの場合、Home Assistant側にThread用USBドングルを挿さなくても、Apple TVのThreadネットワークを利用できる可能性があります。
パターン2：Home Assistant自身をThreadボーダールーターにする
Thread Matter機器
↓
Home Assistant Connect ZBT-1 / ZBT-2 など
↓
Home AssistantHome Assistant公式では、Connect ZBT-1、Connect ZBT-2、SkyConnectなどの対応ラジオを使い、Home AssistantをThreadボーダールーターにする手順が案内されています。(Home Assistant)
Apple TVを使うメリット
| メリット | 内容 |
|---|---|
| 追加のThreadドングルが不要になる可能性 | Apple TV 4K対応モデルがあればThread機器を使いやすい |
| Apple Homeと併用しやすい | iPhone、HomePod、Apple Watchとの相性が良い |
| 常時電源ON | ボーダールーターとして向いている |
| Matter機器の初期設定がしやすい | iPhoneのHomeアプリから追加しやすい |
| Home Assistant専用機の負担を減らせる | Mac mini側にThread無線を持たせなくてもよい場合がある |
注意点
一番大事なのは、Apple TVをThreadボーダールーターとして使う場合でも、Home AssistantがApple TVを完全に管理できるわけではないという点です。
| 注意点 | 内容 |
|---|---|
| Apple TVのThreadネットワーク管理はApple側中心 | Home Assistant側から細かく制御しにくい場合がある |
| 機種確認が必要 | Apple TV 4K 第3世代でもWi-FiのみモデルはThread非対応 |
| ネットワーク環境が重要 | MatterはIPv6、mDNS、同一LAN構成に影響されやすい |
| Home AssistantでMatter登録するにはスマホ連携が重要 | iPhone/AndroidのHome Assistant Companion Appが関係する |
| 複数のThreadネットワークができることがある | Apple Home側とHome Assistant側で別ネットワークになると面倒 |
Home Assistant公式のMatterドキュメントでも、Matter利用時はiOS/AndroidのCompanion App、Matter統合、Threadボーダールーターなどの組み合わせが重要だと説明されています。(Home Assistant)
Mac mini + Home Assistantとの関係
あなたの構成で考えると、こうなります。
| 役割 | 推奨機器 |
|---|---|
| Home Assistant本体 | Mac mini |
| Matterコントローラー | Home Assistant |
| Threadボーダールーター | Apple TV 4K対応モデル |
| スマホ登録操作 | iPhoneのHome Assistantアプリ / Apple Home |
| ローカルLLM | できれば別PC、または軽量モデル |
この構成なら、Mac miniをHome Assistant専用機にしても、Thread用USBドングルを必ず挿す必要はありません。
対応Apple TVがあれば、Thread通信部分をApple TVに任せられるためです。
まとめ
Apple TVは、対応機種であれば次の2つの役割を持ちます。
- Apple Homeのホームハブ
外出先操作、自動化、Matter機器管理を支える。 - Threadボーダールーター
Thread対応Matter機器を家庭内LANへつなぐ橋になる。
Home Assistantと組み合わせる場合、Apple TVは「Home Assistantの代わり」ではなく、Thread通信の土台を提供する機器と考えると分かりやすいです。
すでにThread対応Apple TV 4Kを持っているなら、Mac miniにHome Assistantを入れる際、まずはApple TVをThreadボーダールーターとして使う構成から試すのが現実的です。
Apple TVは第3世代で、イーサネット接続しています
はい。その場合、Apple TV 4K 第3世代の「Wi-Fi + Ethernetモデル」なので、かなり有利です。
Apple公式仕様では、Apple TV 4K 第3世代のうち Wi-Fi + Ethernetモデルには「Threadネットワークテクノロジー」と「ギガビットEthernet」 が搭載されています。
一方、Wi-FiのみモデルにはThreadの記載がありません。
つまり、Ethernet端子付きの第3世代であれば、Threadボーダールーターとして使えるモデルと考えてよいです。(Appleサポート)
あなたの構成でできること
| 役割 | 担当 |
|---|---|
| Threadボーダールーター | Apple TV 4K 第3世代 Wi-Fi + Ethernet |
| Apple Homeのホームハブ | Apple TV |
| Matter機器のApple Home登録 | iPhone + Apple TV |
| Home Assistant本体 | Mac mini |
| Home Assistant側のMatterコントローラー | Home Assistant |
| Thread用USBドングル | 最初は不要でもよい |
つまり、Mac miniにThread用USBドングルを挿さなくても、まずはApple TVをThreadの土台として使う構成から始められます。
Ethernet接続のままでよいか
基本的には、Apple TVを有線LAN接続しているのは良い構成です。
Apple TVが安定して家庭内LANにつながるため、ホームハブとしては有線接続のメリットがあります。
ただし、Apple公式サポートでは、Threadアクセサリの設定時に「Threadボーダールーターが必要」などの警告が出る場合、Apple TVをEthernet接続しているなら、いったん iPhone/iPadと同じWi-Fiに接続して試す という対処が案内されています。(Appleサポート)
したがって実用上はこう考えるとよいです。
| 状況 | 対応 |
|---|---|
| 普段の運用 | Apple TVはEthernet接続でOK |
| Thread/Matter機器の初期登録がうまくいかない | 一時的にApple TVをWi-Fi接続にして試す |
| 登録後に安定運用したい | Ethernetに戻して様子を見る |
Home Assistantとの組み合わせ
このApple TVがあるなら、Mac miniをHome Assistant専用機にする場合でも、最初からConnect ZBT-2などを買う必要性は下がります。
おすすめは次の順番です。
- Mac miniにHome Assistantを入れる
- iPhoneにHome Assistant Companion Appを入れる
- Apple TVをApple Homeのホームハブとして確認する
- Matter対応機器をApple HomeまたはHome Assistant側で登録してみる
- Thread機器がうまく使えるか確認する
- うまくいかない、またはHome Assistant側でThreadを完全管理したくなったら、Connect ZBT-2等を検討する
注意点
Apple TVはThreadボーダールーターとして使えますが、Home AssistantがApple TVを完全に管理するわけではありません。Apple TVのThreadネットワークはApple Home側の管理になります。
そのため、Home Assistant中心でThreadネットワークを完全にコントロールしたい場合は、将来的に次のような構成も候補です。
| 構成 | 向いている人 |
|---|---|
| Apple TVをThreadボーダールーターにする | まず簡単に始めたい、Apple製品中心 |
| Home Assistant Connect ZBT-2を使う | Home Assistant中心にThread/Zigbeeを管理したい |
| Apple TV + ZBT-2併用 | Matter/Thread機器が増えた後の本格運用 |
結論
あなたのApple TVは、Thread対応のApple TV 4K 第3世代 Wi-Fi + Ethernetモデルです。
そのため、Home AssistantをMac miniに入れる場合でも、まずは Apple TVをThreadボーダールーターとして使う構成で始めるのが合理的です。
最初からMac miniにThreadドングルを追加するより、まずは今あるApple TVを活用して、Matter/Thread機器がHome Assistantでどこまで安定するか試すのがよいです。
最後に、Home Assistantサーバーを構築した場合、どのような環境が構築できるかについての下記の図を作成した。
・大手企業の各プラットホームとの関係を示す図
・Apple TV や iPhoneとの関係を示す図
・SwitchBot製品や赤外線機器との関係を示す図
Home Assistant サーバーのある環境（大手企業の各プラットホームとの関係）
HOME Assistantは、大手企業の各プラットホームとどのような関係にありますか。
図解で説明してください
この図は、Home Assistant が各社のスマートホーム基盤をつなぐ“中心ハブ”として働くことを示しています。
- 中央の Home Assistant が、家庭内の自動化と機器管理の中心です。
- 左右には Apple Home / Siri、Google Home / Google Assistant、Amazon Alexa、Samsung SmartThings があり、Home Assistant と連携できます。
- 下の Matter / Thread は、メーカーをまたいで機器をつなぐ共通規格です。
- 一番下の照明・センサー・スマートプラグ・温度調節器・スマートロック・カメラなどの実際の機器を、Home Assistant 経由でまとめて扱えるイメージです。
- 矢印は、
- 公開：Home Assistant 側の機器を各社プラットフォームから使えるようにする
- 取り込み：各社プラットフォーム側の機器を Home Assistant に統合する
ことを表しています。
要するに、Home Assistant は Apple や Google などを置き換えるというより、それぞれを橋渡しして一元管理・自動化するための中枢です。
大手企業の各プラットホームとの関係を示す図が示すように、多くのプラットホームと何らかの関係を有していることが分かった。その中で、Home Assistantでしかできないことや、各プラットホームを跨いだ連携の可能性なども調べたい。ただし、状態取得・制御される機器及び属性についてHome Assistantで設定する必要がありそうなので、対象機器を絞らないと、それらの手間がかかり、何を設定したのか、後で分からなくなりそうである。
Home Assistant サーバーのある環境（Apple TV や iPhoneとの関係）
Apple TVとiPhoneとMac miniを所有しているので、Apple エコシステムとの関係を調べた。
Apple TV,iPhone,HOME Assistantサーバー（Mac mini）がある環境で、どのような機器が、どこを介してつながるか、図解して下さい
この図は、あなたの環境（Apple TV・iPhone・Mac mini上のHome Assistant）を中心に、「どの機器がどこを経由してつながるか」を示した全体構成です。ポイントごとに整理して説明します。
① 全体の役割（まず1行で）
Wi-Fiルーターを中心に、Apple系（操作）とHome Assistant（制御）が並列に存在し、各デバイスを統合している構成です。
② Apple側（操作・ユーザーインターフェース）
● Apple TV
- HomeKitのホームハブ
- 外出先からの遠隔操作の中継
- ThreadボーダールーターとしてMatterにも関与
👉 役割：操作の中継・HomeKitの司令塔
● iPhone
- HomeアプリやHome Assistantアプリで操作
- 通知の受信（センサー・自動化）
- 外出先からアクセス
👉 役割：ユーザーの操作端末
③ 中心ネットワーク
● Wi-Fiルーター / LAN
- すべての機器の接続ハブ
- Apple TV・iPhone・Mac miniがここでつながる
👉 役割：通信の中心（必須インフラ）
④ 制御の中枢
● Home Assistant（Mac mini）
- スマートホームの本体（頭脳）
- 各機器の統合・自動化
- ローカルで動作（インターネット不要でも制御可能）
👉 役割：実際の制御・自動化ロジックを担当
⑤ スマートホーム機器の接続パターン
図の下段が重要です。機器は種類ごとに接続経路が違います。
1）HomeKit対応機器
- Apple TV経由でHomeKitに接続
- iPhoneから直接操作可能
👉 Apple中心で完結する構成
2）Zigbee機器
- USBドングルなどをMac miniに接続
- Home Assistantが直接制御
👉 Home Assistant主体のローカル制御
3）Matter機器
- Apple TV（Thread） or Home Assistantのどちらにも接続可能
👉 Apple系とHAの“橋渡し的存在”
4）Wi-Fi機器
- ルーター経由でHome Assistantに接続
👉 一番一般的（カメラ・エアコンなど）
5）Bluetooth機器
- Mac miniに直接接続
👉 近距離センサーなど
6）クラウド連携サービス
- インターネット経由でHome Assistantに連携
👉 天気・電力会社・音声AIなど
⑥ インターネットの役割
- 外出先からの操作（iPhone → Apple TV → 家）
- クラウドサービス連携
- ソフトウェア更新
👉 なくても動くが、あると便利
⑦ この構成の本質（重要）
この図の一番重要なポイントはここです👇
✔ Apple系とHome Assistantは「競合ではなく並列」
- Apple：操作・UI・遠隔アクセス
- Home Assistant：制御・自動化・統合
⑧ まとめ（設計思想）
- iPhone → 操作
- Apple TV → 中継・HomeKit・Thread
- Mac mini（Home Assistant）→ 制御の本体
- 各デバイス → プロトコルごとに接続
👉 つまり
「操作はApple、制御はHome Assistant」という分担構成
必要なら、この図をベースに「SwitchBotを追加した場合」や「Matterだけで構成した場合」の比較図も作れます。
大手各社のプラットフォームには接続できず、HOME Assistantにしか接続できない機器はありますか
はい、あります。
ただし正確には、「Home Assistant専用として売られている機器」よりも、「Apple Home / Google Home / Alexa / SmartThingsには直接つながらないが、Home Assistantなら扱える機器」が多いです。
結論
一般家庭でよく出てくるのは、次のような機器です。
| 機器・方式 | Apple / Google / Alexa等へ直接接続 | Home Assistant |
|---|---|---|
| ESPHome自作センサー・リレー | 基本不可 | 得意 |
| MQTT機器 | 基本不可 | 得意 |
| Zigbee汎用機器 | 直接は不可。対応ハブが必要 | ZHA / Zigbee2MQTTで対応しやすい |
| Z-Wave機器 | 多くの大手ハブでは直接不可 | Z-Wave JSで対応 |
| Modbus / KNX / 産業系・設備系機器 | 基本不可 | 対応可能 |
| UPS、NAS、ルーター、プリンタ、太陽光機器 | 基本的にスマートホーム対象外 | 統合できるものが多い |
| 古い家電・赤外線・433MHz RF機器 | 直接は不可 | Broadlink、ESPHome、rtl_433等で扱える場合あり |
Home Assistantは公式統合一覧だけでも非常に幅広く、ESPHome、MQTT、Matter、Google Assistant、Amazon Alexa、HomeKit Bridge、KNX、Z-Waveなどが並んでいます。
つまり、大手プラットフォームが対象にしない機器も、Home Assistantでは「エンティティ」として取り込める場合があります。(Home Assistant)
1. ESPHome機器
代表例は、ESP32やESP8266で作る自作センサーです。
たとえば、次のようなものです。
| ESPHomeで作れるもの | 例 |
|---|---|
| 温湿度センサー | SHT40、BME280など |
| CO2センサー | SCD40、MH-Z19など |
| 赤外線送信機 | エアコン・テレビ用IRプロキシ |
| リレー | 照明、換気扇、低電圧機器のON/OFF |
| 人感・照度センサー | PIR、ミリ波、人感連動 |
| 水漏れセンサー | 洗濯機まわり、キッチン下 |
| BLEプロキシ | BluetoothセンサーをHAへ中継 |
ESPHomeはHome Assistantとの統合が非常に強く、公式ドキュメントでも、ESPHomeデバイスはHome AssistantのネイティブAPIでリアルタイム監視・自動化に使えると説明されています。(Home Assistant)
これはApple HomeやGoogle Homeに直接追加するタイプの機器ではありません。
ただし、Home Assistantに取り込んだあと、必要なものだけをApple HomeやGoogle Assistantへ公開することはできます。
2. MQTT機器
MQTTは、家庭内サーバーやIoT機器でよく使われる通信方式です。
たとえば、次のような機器が該当します。
| MQTT系 | 例 |
|---|---|
| Tasmota化したスマートプラグ | Sonoff、Tuya系などを改造・書き換え |
| OpenBeken系デバイス | 一部Wi-Fiスマート機器 |
| 自作Arduino / ESP32機器 | センサー値をMQTTで送信 |
| Zigbee2MQTT配下のZigbee機器 | センサー、スイッチ、電球など |
| 433MHz受信機 | 温度計、ドアセンサー、リモコン信号など |
Home AssistantのMQTT統合はMQTT Discoveryに対応しており、機器側がDiscoveryメッセージを出せば、Home Assistantに自動登録できます。(Home Assistant)
一方、Apple HomeやGoogle Home、Alexaは、通常ユーザー宅のMQTTブローカーを直接読みに行きません。
そのため、MQTT機器はHome Assistant向きです。
3. Zigbee機器
Zigbee機器も、大手プラットフォームに直接つながるとは限りません。
たとえば、Aqara、Sonoff、IKEA、Tuya系、無名メーカーのZigbeeセンサーなどは、メーカー純正ハブや対応ハブが必要な場合があります。
Home Assistantでは、Zigbee USBドングルを使って ZHA または Zigbee2MQTT で取り込む方法があります。
Zigbee2MQTTは、MQTT Discoveryを使うことでHome AssistantにZigbee機器を自動追加できると説明されています。(Zigbee2MQTT)
つまり、次のような機器はHome Assistantの得意分野です。
| Zigbee機器 | 大手プラットフォームでの扱い | Home Assistantでの扱い |
|---|---|---|
| 安価な温湿度センサー | 直接不可の場合あり | 使えることが多い |
| Zigbeeドアセンサー | 対応ハブ依存 | 使えることが多い |
| Zigbeeボタン | 対応差が大きい | イベントとして使いやすい |
| Tuya系Zigbee機器 | Tuyaハブ依存になりがち | Zigbee2MQTTで使える場合あり |
| Aqara系機器 | Apple Home対応品もあるが差あり | HAで細かく扱える場合あり |
4. Z-Wave機器
Z-Waveは日本ではZigbeeほど一般的ではありませんが、海外のスマートホームでは多く使われています。
Apple TV、Google Nest、Amazon Echoなどは、基本的に汎用Z-Waveコントローラーではありません。
Home Assistantでは、Z-Wave USBアダプターなどを使い、Z-Wave JS統合でZ-Waveネットワークを構築できます。
Home Assistant公式ドキュメントでも、Z-Waveサーバーを設定し、対応Z-Waveアダプターを使ってデバイスをネットワークに追加する流れが説明されています。(Home Assistant)
5. 家電以外の「家庭内IT機器」
ここがHome Assistantの大きなメリットです。
Apple HomeやGoogle Homeでは、通常は「照明、鍵、エアコン、カメラ、センサー」などのスマートホーム機器が中心です。
しかしHome Assistantでは、次のようなものも状態監視の対象にできます。
| 種類 | できること |
|---|---|
| プリンタ | オンライン状態、インク残量、エラー確認 |
| NAS | ディスク容量、稼働状態、温度 |
| UPS | 停電検知、バッテリー残量 |
| ルーター | 接続端末、WAN状態 |
| PC | CPU使用率、メモリ、ディスク、温度 |
| 太陽光・蓄電池 | 発電量、消費量、売電・買電 |
| スマートメーター系 | 電力・ガス・水道使用量 |
| IPカメラ | 映像、動体検知、スナップショット |
たとえば以前話題にされたEPSONプリンタのインク残量のような情報は、大手スマートホームアプリでは中心機能になりにくいですが、Home Assistantではセンサーとして扱える可能性があります。
6. Matter対応でなくてもHome Assistantなら使える機器
Matter対応機器は、Apple、Google、Amazon、SmartThingsなどにまたがって使える可能性があります。
ただし、Matterでもプラットフォームごとに対応デバイス種別や機能差があります。
Matterは共通規格ですが、各社がすべての機能を同じように実装しているわけではありません。(The Verge)
そのため、次のような機器はHome Assistantの方が扱いやすい場合があります。
| 例 | 理由 |
|---|---|
| Matter非対応の古いスマートプラグ | MQTTやメーカーAPIで扱える |
| Matter非対応のZigbeeセンサー | Zigbee2MQTT/ZHAで扱える |
| 自作ESP32センサー | ESPHomeで扱える |
| 赤外線家電 | Broadlink/ESPHome経由で扱える |
| ローカルAPI対応家電 | HA統合があれば扱える |
| メーカーがクラウド連携をやめた機器 | ローカル制御が残っていれば救済できる場合あり |
7. Home Assistant経由で大手プラットフォームに出せる
ここが重要です。
直接Apple HomeやGoogle Homeに対応していない機器でも、Home Assistantに取り込めれば、そこから一部をApple Home、Google Assistant、Alexaへ公開できます。
Home AssistantのHomeKit Bridge統合は、Home Assistant側の機器をApple Home側へブリッジするための統合です。(Home Assistant)
Google Assistant統合でも、Home Assistantの公開済みデバイスをGoogle Homeアプリへ同期できます。(Home Assistant)
また、Home Assistantの音声アシスタント設定では、エンティティごとにAssist、Google Assistant、Alexaなどへ公開する対象を選べる仕組みがあります。(Home Assistant)
つまり、
大手プラットフォーム非対応機器
↓
Home Assistant
↓
Apple Home / Google Home / Alexaという橋渡しが可能です。
具体例
例1：ESP32温湿度センサー
ESP32 + SHT40
↓ ESPHome
Home Assistant
↓ 必要なら公開
Apple Home / Google Home / AlexaこれはApple HomeやGoogle Homeに直接登録する機器ではありません。
しかしHome Assistantでは、室温・湿度センサーとして使えます。
例2：Zigbeeボタン
Zigbeeボタン
↓ Zigbee USBドングル
Zigbee2MQTT / ZHA
↓
Home Assistantこのボタンで、照明、通知、Broadlink操作、ローカルLLMへの問い合わせなどを起動できます。
Apple Homeでは対応が限定されるボタンでも、Home Assistantなら細かいクリックイベントを使えることがあります。
例3：UPS
UPS
↓ USB / ネットワーク
Home Assistant
↓
停電通知 / 自動シャットダウン / スマホ通知UPSは普通のスマートホーム機器ではありませんが、Home Assistantでは家庭内インフラ監視に使えます。
例4：自作赤外線プロキシ
ESP32 + 赤外線LED
↓ ESPHome
Home Assistant
↓
テレビ / エアコン / 扇風機これは大手プラットフォームに直接登録する製品ではありません。
しかしHome Assistantでは、かなり自由に使えます。
逆に、大手プラットフォームだけで十分な機器
次のような場合は、Home Assistantを使わなくてもよいです。
| 機器 | 理由 |
|---|---|
| Matter対応スマートプラグ | Apple/Google/Alexaで十分なことが多い |
| Philips Hue | Hueブリッジだけでも強い |
| SwitchBot中心の環境 | SwitchBotアプリだけで完結しやすい |
| Apple HomeKit認証機器 | Apple Homeだけで使いやすい |
| Google Nest中心 | Google Homeだけで十分な場合あり |
まとめ
はい、大手各社のプラットフォームには直接接続できず、Home Assistantだから活用しやすい機器は多くあります。
特に代表的なのは次の5種類です。
- ESPHomeの自作センサー・リレー
- MQTT機器
- Zigbee2MQTT / ZHAで使うZigbee機器
- Z-Wave機器
- プリンタ、UPS、NAS、太陽光、ルーターなどの家庭内IT・設備機器
Home Assistantの強みは、単にスマート家電を操作することではなく、大手プラットフォームが拾わない機器まで家庭内の情報源としてまとめられることです。
そのため、Matter対応機器だけでそろえる家庭ではHome Assistantの必要性は下がりますが、センサー、自作機器、電力監視、見守り、ローカルLLM連携まで広げるなら、Home Assistantの価値が大きくなります。
Apple/Google/Alexa等には直接出せないが、Home Assistantなら統合できる機器群とHome Assistanttの連携を説明する図を作成してください
EPSONプリンタがHOME Assistantに登録されているのが意外だった。しかも、プリンタ本体だけでなく、５種類のインクも個別に認識され、EPSONプリンタに関連するエンティティは5つとなっていた。
Home Assistant サーバーのある環境（SwitchBot製品や赤外線機器との関係）
自宅に、「SwitchBot スマートリモコン ハブ2」や「ミニハブ」がある場合、SwitchBot製品や、赤外線で制御される機器や、Matter対応製品が、どのように接続されるかを図解にしてください
この図は、Home Assistant が SwitchBot プラットホームを置き換えるものではなく、SwitchBot機器を含むスマートホーム全体をまとめて管理・自動化する“上位の連携先”になる、という関係を示しています。
左側の Home Assistant は、家全体の管理画面・自動化ルール・ダッシュボードを担当します。
右側の SwitchBotプラットホーム は、SwitchBotアプリ、SwitchBotハブ、SwitchBotクラウド、SwitchBotデバイス、赤外線家電を含むSwitchBot側の仕組みです。
両者のつながりは、大きく 3系統 あります。
1. Bluetoothで直接連携
近くにあるSwitchBot機器を、Home Assistantから直接扱う方法です。
たとえば、SwitchBotボット、カーテン、温湿度計などの一部機器は、Home Assistant側のBluetooth環境が整っていれば、SwitchBotハブなしで扱える場合があります。
Home Assistant公式のSwitchBot連携でも、Bluetoothが前提で、SwitchBot Hubは必須ではないと説明されています。(Home Assistant)
特徴は、
ローカル制御・ハブ不要・ただし対応機器に限られる
という点です。
2. SwitchBotハブ／クラウド経由で連携
SwitchBot Hub 2 やハブミニを使い、SwitchBotクラウドやAPI経由でHome Assistantと連携する方法です。
この経路では、SwitchBotハブに登録された機器や、ハブが赤外線で操作しているエアコン・テレビ・照明なども、Home Assistant側にまとめられる可能性があります。
SwitchBot公式ページでも、IR家電やロボット掃除機など、Hub経由の機器はクラウド経由でHome Assistantに統合できると説明されています。(SwitchBot International)
特徴は、
赤外線家電も扱いやすい・ただしインターネットやクラウドに依存しやすい
という点です。
3. Matterで連携
Matter対応のSwitchBot製品を、Home AssistantのMatter連携で扱う方法です。
Home Assistant公式では、SwitchBot Matter機器はローカルで動作し、Home AssistantのMatter連携に統合できると説明されています。
状態更新や操作もローカルで行われるため、クラウド経由より反応が速くなりやすい構成です。(Home Assistant)
特徴は、
ローカル制御・高速・今後の標準連携として期待できる
という点です。
重要なポイント
SwitchBotアプリは、初期設定、機器登録、ファームウェア更新、カーテンのキャリブレーションなどで使う場面が残ります。
Home Assistantはその上で、SwitchBotだけでなく、照明、ドアロック、人感センサー、温湿度センサーなど他社製品も含めて、横断的に自動化できる場所になります。
つまり、関係を一言で言うと、
SwitchBotは機器と専用サービスのプラットホーム、Home Assistantはそれらを他社機器と一緒にまとめる統合管理・自動化プラットホーム
です。