3 台のエアコンが、Nature Remo・SwitchBot・純正アプリの 3 つの経路からバラバラに操作されていて、「エアコンつけて」と言うたびにモードや温度が変わってしまう。そんな状態を、ECHONET Lite の直接制御と Home Assistant + Matter でまとめて解消した記録です。
作業自体は 2026 年 9 月 21〜23 日の 3 日間。やってみて一番おもしろかったのは、構築そのものより「運用し始めてから出てきた変な挙動」のほうでした。
TL;DR
- エアコンは 赤外線をやめて、ECHONET Lite（LAN 内・双方向）で Home Assistant から直接制御するようにした
- 全機器を Home Assistant に集約し、Matter ブリッジで Alexa / Google / Apple Home の 3 つに同じ機器セットを公開した
- 実運用では、「最初の Set が拒否される」「Siri だけ挙動が違う」「純正アプリと取り合いになる」など、複数経路・複数実装ならではの問題に出会った
- 最終的な運用ルールは「エアコンの操作は Home Assistant 経由に一本化、純正アプリは確認専用」
1. もともと何に困っていたか
うちは書斎・寝室・リビングの 3 部屋にエアコンがあり、各部屋に Amazon Echo と Google Nest、Nature Remo が置いてあります。リビングにはさらに SwitchBot Hub Mini。
困っていたのは 2 つです。
① スピーカーごとに使える機能が違う
Echo でできることと Nest でできることが微妙に違っていて、家族が「これはどっちに言えばいいんだっけ」と使い分けきれていませんでした。
② 「エアコンつけて」の結果が、経路次第で変わる
こっちが本題。エアコンへの操作経路が、
- 経路 A：スピーカー → Nature Remo → 赤外線
- 経路 B：スピーカー → SwitchBot → 赤外線
- 経路 C：純正アプリ → メーカークラウド → エアコン
と 3 本ありました。
赤外線リモコンは 一方向通信 です。送るだけで、エアコンが今どういう状態なのかは読めません。なので Nature Remo も SwitchBot も、それぞれ「自分が最後に送った設定」を別々に覚えていて、それを元にリモコン信号を組み立てて送ります。
結果、「エアコンつけて」と言うと、どのスピーカーがどの経路で送ったかによって、冷房だったり除湿だったり、温度が違ったりする。これが地味にストレスでした。
ちなみに前提として、パナソニックはエアコンのスマートスピーカー連携を 2025 年 9 月 16 日に終了しています。純正アプリでの遠隔操作だけは今も使えます。
2. 方針：ECHONET Lite で直接しゃべって、入口を 1 本にする
Home Assistant にたどり着くまで
実は最初から Home Assistant を入れるつもりだったわけではありません。
もともと、SwitchBot と Nature Remo の API を叩いて温湿度を集める自作アプリ（Flask）を動かしていました。なので最初は、「このアプリを改修して、エアコンも API 経由で操作できるようにすればいいか」と考えていました。
その改修方針を Claude に相談していたところ、「問題の根本は、エアコンへの操作経路が複数あること」と指摘されました。たしかに、自作アプリからの API 操作を足しても、経路がもう 1 本増えるだけ。「最後に送った設定」を覚えている場所がまた増えて、むしろ状況は悪くなります。
そこで発想を変えて、「経路を足す」のではなく「経路を 1 本にまとめる」方向で考え直した結果が、今回の構成です。
方針
問題の根っこは「経路が複数あること」と「赤外線が一方向であること」の 2 つ。なので方針もシンプルです。
- エアコンは ECHONET Lite で直接制御する。LAN 内で双方向に通信できるので、状態（電源・モード・設定温度）を読んだうえで操作できる
- 全機器を Home Assistant に集約する
- Matter ブリッジで、Alexa / Google / Apple Home に同じ機器セットを公開する。どのスピーカーに話しかけても、最終的には同じ Home Assistant を通る
ECHONET Lite は、日本の家電・住宅設備向けの通信規格です。対応エアコンなら、LAN 内から UDP で状態を読んだり設定を書いたりできます。
使ったソフトウェア
| 役割 | 使ったもの |
|---|---|
| ホームオートメーション基盤 | Home Assistant（Container 版、host ネットワーク） |
| ECHONET Lite 統合 | HEMS Echonet Lite（sayurin/hems_echonet_lite、HACS 経由） |
| Nature Remo 統合 | hass-nature-remo（hannoeru/hass-nature-remo、HACS 経由） |
| SwitchBot 連携 | SwitchBot Cloud（Home Assistant 標準統合） |
| Matter ブリッジ | Home Assistant Matter Hub（RiDDiX/home-assistant-matter-hub） |
| 導入補助 | HACS（Home Assistant Community Store） |
Matter Hub は、元の t0bst4r/home-assistant-matter-hub が 2026 年 3 月にアーカイブされていて、README でも RiDDiX 版のフォークへの移行が案内されています。これから入れる人はフォーク版を使うのがよさそうです。
エアコンは 3 台ともパナソニックのエオリア（CS-EX367C、CS-220DFX、CS-220DGX）です。
3. 検証編：Set コマンドがなぜか拒否される
いきなり Home Assistant に入れる前に、まず ECHONET Lite で本当に制御できるのかを確認しました。
状態の取得（Get）は 3 台とも問題なし。ところが制御（Set）をやってみると、3 台中 2 台で、運転開始直後の最初の Set コマンドがエアコン側から拒否されました。ECHONET Lite のエラー応答（Set 不可）が返ってくるやつです。
同じコマンドをもう一度送ると、普通に成功します。
原因ははっきりとは分かっていません。今のところの仮説は「エアコン側で別の制御（純正アプリのクラウド連携など）が状態確認をしている最中に、こちらの書き込みがぶつかった」というもの。
家電のプロトコルを直接叩くと、こういう「規格どおりには動くけど、タイミング次第でコケる」場面に出会います。実運用では、1 回拒否されても再送すれば通る、くらいに構えておくのが現実的かなと思っています。
4. 統合編：Home Assistant と Matter ブリッジ
ここは割と素直に進みました。
- Home Assistant（Container 版）を自宅サーバーに立てる。ECHONET Lite はマルチキャストで機器を探すので、host ネットワークで動かしています
- HACS を入れて、ECHONET Lite 統合と Nature Remo 統合を追加
- SwitchBot Cloud は標準統合で追加
- Nature Remo と SwitchBot の エアコン登録は削除。赤外線の経路を残すと、また「経路ごとの記憶」問題が復活するので
- Matter ブリッジ（Home Assistant Matter Hub）を入れて、Alexa / Google Home / Apple Home の 3 つとペアリング
エアコン以外（温湿度計やサーキュレーターなど）は、そのまま SwitchBot Cloud / Nature Remo の統合経由で Home Assistant に集約しています。Remo や SwitchBot 側で組んでいた自動化も、Home Assistant のオートメーションに移しました。
もう一つ、2 章で触れた自作の温湿度収集アプリにも、エアコンの状態を記録させるようにしました。このとき アプリから ECHONET Lite を直接叩かせない のがポイントで、Home Assistant の REST API から読み取るだけにしています。エアコンに話しかける主体を増やすと、後述の「取り合い」問題の種になるので。
5. 実測編：スピーカーによって「つけて」の中身が違う
構成ができたので、「エアコンつけて」を 3 系統（Alexa / Google / Siri）× 3 部屋で試しました。
分かったのは、Matter 経由で届くコマンドが、スピーカーによって違う ということです。
- Alexa・Google：単純な「電源オン」のコマンド。エアコン本体が覚えている前回のモード・温度で起動する
- Siri（Apple Home）：「運転モード」そのものを書き込むコマンドで届く
普段はどちらでも結果は大差ないんですが、これが効いてきたのがこの事件です。
Apple Home 側で、エアコンの部屋の割り当てを間違えていた状態で「エアコンつけて」と言ったら、3 台同時に、しかも室温 25〜26℃ なのに暖房で起動した。
すぐ気づいて手動で止めました。原因は Apple Home 側の部屋の割り当てミスで、直したら再現しなくなりました。
「電源オンだけ」なら、部屋を間違えても前回の設定で動くだけで済みます。でも「モードを書き込む」実装だと、間違ったときの影響がモード選択まで及ぶ。音声アシスタントの実装差が、実際の家電の動きにそのまま出るんだなあ、というのが実感です。Apple Home を使う人は、部屋の割り当てを最初にちゃんと確認しておくのがおすすめです。
6. 運用編：純正アプリと Home Assistant の取り合い
移行後もしばらくは、外出先からの操作に純正アプリを併用していました。そうしたら、こんなことが起きました。
- 外出先からアプリで 26℃ に設定
- 帰宅すると 28℃ になっている
- アプリで直しても、また 28℃ に戻る
- Home Assistant から操作したら、今度はアプリ側に「他の機器で操作中」というエラー
調べてみると、Home Assistant の ECHONET Lite 統合は、バックグラウンドで約 60 秒間隔でエアコンに状態取得（ポーリング）をかけ続けて います。純正アプリのクラウド経由のコマンドとこのポーリングが、エアコン側でタイミング的にぶつかっていた可能性が高い、というのが今の仮説です（3 章の Set 拒否とも、たぶん根っこは同じ）。
結論として、運用ルールを決めました。
- エアコンの操作は Home Assistant 経由に一本化
- 純正アプリは確認専用（操作には使わない）
外出先からの操作は、Alexa / Google Home / Apple Home の各アプリ（クラウド連携）で代わりにできることを確認済みなので、困ることはありません。
「経路をまとめる」ために始めた作業なのに、最後に残った別経路でまたハマる、というオチでした。制御経路は、併用すると本当に怖いです。
7. おまけ：エアコンに「ピッ」と鳴らさせる
赤外線リモコンや純正アプリで操作すると、エアコン本体が「ピッ」と鳴りますよね。ところが ECHONET Lite 経由だと無音。操作が届いたのかどうか分かりにくい。
調べてみると、ECHONET Lite の家庭用エアコンクラス（0x0130）には、「ブザー」のプロパティ（EPC 0xD0）が定義されて いました。しかも HEMS Echonet Lite 統合が、対応している機種に対しては自動で「Buzzer」のボタンエンティティを作ってくれていて、追加の実装は何もいりませんでした。
3 台中 2 台が対応、残りの 1 台（型番が違う個体）は非対応でした。
これを使って、「エアコンを操作するたびに、自動でブザーを鳴らす」オートメーションも作りました。音声で操作したときも「ピッ」と鳴るので、ちゃんと届いたのが分かって安心です。規格のマイナーな仕様が、地味に便利。
8. まとめ
Before / After を並べると、変わったのはこの 2 点です。
| Before | After | |
|---|---|---|
| エアコンへの経路 | Remo・SwitchBot・純正アプリの 3 本 | Home Assistant 経由の 1 本 |
| 通信の向き | 赤外線（一方向・状態は読めない） | ECHONET Lite（双方向・状態を読める） |
やってみて分かったこと：
- 赤外線の「一方向」は、複数経路と組み合わさると本当に厄介。状態を持つのが送信側になるので、経路の数だけ「別の真実」ができる
- ECHONET Lite は便利だけど、機器側の実装にはクセがある。Set の拒否や、他の制御経路との衝突は起こりうる前提で考えたほうがいい
- Matter でエコシステムをまとめても、音声アシスタントごとの実装差は残る。「つけて」がモード書き込みになる実装もある
- 最終的に効くのは運用ルール。技術で経路を 1 本にしても、人が別経路を使えば元に戻る
9. 次にやろうと思っていること
Home Assistant を、ラズパイ + Home Assistant OS に移すか
今は自宅サーバー上で Home Assistant を Container 版 で動かしています。これを、Raspberry Pi に Home Assistant OS を入れて専用機にするかどうかを考え中です。
きっかけは、Container 版では「アプリ」（旧称アドオン）が使えない こと。アプリは Home Assistant の横で動く周辺ソフトで、Home Assistant OS が管理する仕組みになっています。2026.2 で「アドオン」から「アプリ」に名前が変わりました。
Container 版でも、同じソフトを自分でコンテナとして並べれば動かせます（今の Matter Hub がまさにそれ）。ただ、画面からポチッと入れて、アップデートやバックアップも Home Assistant 側で面倒を見てもらえる OS 版のほうが、管理はだいぶ楽そうです。
なお Home Assistant は 2025 年に、公式サポートするインストール方法を Home Assistant OS と Container の 2 つに絞って います。どちらを選んでも「サポート外になる」心配はないので、純粋に「管理の楽さを取るか、今のサーバーに同居させる身軽さを取るか」の判断になりそうです。
ドウシシャのサーキュライトを、Google からも動かしたい
エアコン以外の機器もだいたい Home Assistant に集約できましたが、まだ残っているのが ドウシシャのサーキュライト（照明とサーキュレーターが一体になったやつ）です。これが今のところ Alexa からしか操作できません。
Home Assistant に取り込めれば、Matter ブリッジ経由で Google や Apple Home からも同じように動かせるはず。まずは、Home Assistant から制御する手段（統合があるか、ローカルで制御できるか）があるのかを調べるところから始めるつもりです。
同じように「スマートリモコンが増えすぎてカオス」になっている方の参考になればうれしいです。
注記：この記事は、生成 AI（Claude）を使って執筆しています。作業の記録や検証結果は筆者自身の環境でのものですが、文章の構成・執筆に生成 AI の支援を受けています。内容には注意を払っていますが、誤りがあればご指摘ください。