クラウドに頼らないスマートホーム：Matter、Home Assistant、サービス終了のリスク

スマートホームの会社がサービスを終了すると、何が起きますか？

何が壊れるかは設計によって決まります。物理スイッチ、キーパッド、サーモスタットのダイヤル、あるいはローカルに保存されたスケジュールを備えた機器なら、基本的な操作は引き続き使えるかもしれません。すべてのコマンドがメーカーのアカウントとクラウドを経由する機器は、サービスが打ち切られると、リモート操作、オートメーション、アプリからのアクセス、さらには初期設定までも失うことがあります。製品が完璧に動いているように見えていても、インターネット障害、アカウントの問題、あるいは会社の決定によってクラウドへの依存が明らかになることがあるのは、このためです。

重要な問いは、製品にアプリがあるかどうかではありません。コマンドとオートメーションがどこで実行されるかです。Googleの説明によると、クラウド連携型の従来の構成では、コマンドが家庭内の機器からプラットフォームのクラウドへ、次にメーカーのクラウドへ送られ、そこから機器に戻ってくることがあります。これに対してMatter対応のローカル制御は、対応するコマンドをホームネットワーク上で送ります。 ^[1] この違いは照明やセンサーをより障害に強くしてくれますが、それは実際にローカルで実装されている機能に限られます。

サービス終了によって、アップデート、遠隔での映像確認、通知、アカウントへのログイン、音声アシスタントとの連携、機器の交換対応も失われることがあります。最も安全な買い物は、必ずしもクラウド機能が最も多い製品ではありません。照明を点ける、サーモスタットを調整する、想定されたローカルな方法で錠を開ける、といった本来の役割が、その家庭にとって重要な障害条件のもとでも機能し続ける製品です。

クラウドの障害と停電を混同しないでください。ローカル制御でも、ルーター、ハブ、そして電気を必要とする機器には電源が必要です。Threadの電池式センサーは電池で動き続けるかもしれませんが、コントローラーに電源がなければオートメーションはやはり失敗します。障害への強さは、電気、ローカルネットワーク、インターネット接続、ベンダーのクラウド、アカウントのうち、正確に何に依存しているのかを見極めることから始まります。

インターネットがないとき、Matterは何をしてくれますか？

Matterは、なじみのある技術の上に構築されたオープンなスマートホームプロトコルです。Connectivity Standards Allianceによると、Matterは初期設定にBluetooth Low Energyを、機器の接続にWi-Fi、Thread、Ethernetを使用します。 ^[2] Googleは、Matter対応機器は、コマンドを1つずつインターネットやメーカーのクラウドに経由させることなく、既存のホームネットワーク上で対応するコマンドをやり取りできると述べています。 ^[1]

これが価値を持つのは、ローカルコマンドのほうが速くなりうるうえ、ローカルネットワークに電源が入っている限り、インターネット回線が途絶えても機能し続けられるからです。 ^[1][7] 相互運用性も向上します。Matter機器は、機器の種類とコントローラーの対応状況に応じて、複数のMatter認証エコシステムから操作できます。 ^[1][4] しかしローカル制御は、宣伝されているすべての機能がインターネットなしで使い続けられるという約束ではありません。

CSAはMatterをローカル接続の技術と呼び、外出先から操作するにはインターネットに接続されたコントローラーが必要だと述べています。また、一部のMatter機器はメーカーのアプリケーションを通じてインターネットに直接接続する場合があるとも指摘しています。 ^[2] リモートアクセス、クラウドバックアップ、ソフトウェアアップデート、アカウントに紐づく機能、音声サービス、ベンダー固有のカメラ機能や分析機能は、基本的なオン・オフのコマンドがローカルであっても、クラウド依存のままになることがあります。

Matterは、包括的な「クラウド不要」のラベルとしてではなく、実際に提供されるローカル機能のために買ってください。製品のサポートページを読み、次のように問いかけましょう。インターネットを切断した状態で、中心となる役割はホームネットワーク上で機能するか。物理的な操作部でも動かせるか。失われるのは何か。履歴か、通知か、リモートアクセスか、ファームウェアアップデートか、それともすべての操作か。返品期間が終わる前に、これを試してください。

Threadとは何ですか。ボーダールーターは必要ですか？

Threadは、IP接続を提供する低消費電力のメッシュネットワーク規格で、一部のMatter機器に使われています。 ^[6] Googleの説明によると、Matter機器はWi-Fi、Ethernet、Threadのいずれでも通信でき、Thread機器とWi-Fi機器が混在する家庭には、Threadボーダールーターとしても機能するハブが必要です。 ^[1] Home Assistantのドキュメントは、Threadボーダールーターを、ThreadのメッシュをEthernetやWi-Fiといった他のIPネットワークに接続するネットワーク機器と説明しています。 ^[6] 電池で動くセンサー、錠、操作機器は、Threadが低消費電力の通信向けに設計されているため、これを採用することがあります。 ^[2][6]

メッシュは機器同士が通信を中継できるため到達範囲を改善できますが、魔法ではありません。ネットワークには、電源につながった対応機器が十分な数だけあり、機能しているボーダールーターが必要です。選んだMatter機器がThreadを使う場合は、選択したコントローラーまたはハブがMatterだけでなくThreadにも対応していることを確認してください。Googleは対応ハブの例を挙げていますが、正しい一覧はプラットフォームと製品の世代によって異なります。 ^[1]

Threadがあるからといって、家庭にルーター、電気、コントローラーが不要になるわけではありません。Threadはローカルの伝送層の1つです。機器を制御するのはコントローラーであり、ボーダールーターはThreadのメッシュをIPネットワークに接続するもので、それ自体が機器を制御するわけではありません。 ^[6] 外出先からの操作について、CSAは、Matterだけの構成では家庭内にインターネットに接続されたコントローラーが必要だと述べています。 ^[2]

初めての導入では、ロゴやバッジだけを頼りに雑多な機器を買い集めるのは避けてください。1つのエコシステムまたはローカルコントローラーを選び、現時点でのMatterとThreadへの対応を確認してから、機器の種類を1つずつ追加していきます。十数台の機器を壁の中や手の届きにくい場所に設置する前に、ローカルコマンドを試してください。

MatterとHome Assistant、クラウドの問題を解決するのはどちらですか？

MatterとHome Assistantは、関連してはいるものの異なる問題を解決します。Matterは、相互運用可能な機器接続とローカル制御のためのプロトコルです。Home Assistantは、家庭内のハードウェア上で動作し、機器とオートメーションを連携させることができるスマートホームプラットフォームです。堅牢な構成では両方を使えます。Matter対応機器を、Matterコントローラーとして機能できるローカルのHome Assistant環境と組み合わせるのです。 ^[7]

Home Assistantによると、Zigbee、Z-Wave、Matter、Thread、ESPHomeなどのローカルプロトコルで通信する機器は、照明、スイッチ、センサー、オートメーションが反応し続けるためにインターネット接続を必要としません。同社はこれを、ベンダーのクラウド専用の機器と対比しています。そうした機器のインテグレーションは、インターネットが止まっていると機器に到達できません。 ^[3] このためHome Assistantは、ローカルコントローラーとそのバックアップを自分で管理する意思のある人にとって、有用な選択肢になります。

Home Assistantは、外部への依存をすべてなくしてくれるわけではありません。同社自身のドキュメントによると、リモートアクセスや、Apple Home、Google Home、Amazon AlexaとのインテグレーションといったHome Assistant Cloudの機能、さらにアップデートとアプリストアへのアクセスには、やはりインターネットが必要です。 ^[3] またローカル制御は、特定のカメラ映像、サブスクリプションサービス、独自機能がいつまでも動くというベンダーの保証の代わりにもなりません。

Matterは、対応するエコシステム間で共通のローカル経路を提供するため、基本的な機器についてはより簡単になりえます。Home Assistantは、より幅広いローカルオートメーションとインテグレーションの選択肢を提供できますが、維持管理すべきコンピューターのようなシステムが1つ増えます。正しい選択は、どこまでの複雑さを求めるかによって決まります。ローカルで制御できる照明が数台あるだけなら、対応するMatterコントローラーだけで足りるかもしれません。既存のローカルプロトコルが混在する家庭なら、専用のローカルプラットフォームを導入する理由があるでしょう。

どちらの選択肢も、セキュリティを弱める理由として扱うべきではありません。コントローラーを最新の状態に保ち、そのローカルアカウントを保護し、バックアップを取り、リモートアクセスは意図をもって見直してください。不用意にインターネットへ公開されたローカルハブは、減らそうとしたクラウド依存とは別の問題を生みかねません。

会社がサービスを終了する前に、スマートホームをどうテストできますか？

設定を終えたら、条件を管理したローカルテストを行ってください。家庭の電気とローカルのルーターは入れたままにして、ルーターのインターネット接続を切断します。そのうえで不可欠な機能を試します。物理スイッチ、アプリからのローカル操作、スケジュールされたオートメーション、センサーをきっかけとする動作です。何が引き続き動き、何が失敗するかを記録してください。このテストによって、インターネットへの依存と電源への依存を区別できます。

次に、機器のアカウントを点検します。ベンダーのアカウントが使えなくなった後も、機器をローカルで操作できますか。初期設定はクラウドへのログインに紐づいていますか。ベンダーに連絡しなくても、リセットして再ペアリングできますか。書き出し可能な設定やローカルバックアップはありますか。これらの問いは、故障したときの影響がより深刻になる錠、暖房、警報装置、アクセシビリティ関連の機器で特に重要です。

プロトコルとコントローラーの詳細を確認してください。Googleによると、Matterのローカル制御は既存のホームネットワークに依存し、Thread機器には対応するThreadボーダールーターが必要です。 ^[1] 一般的なWi-FiルーターがThreadボーダールーターであるとか、Matter対応とうたわれた機器が、望むプロトコルやコントローラー機能をすべて備えているなどと思い込まないでください。

手動での操作方法、機器の設置場所、電源、型番、ローカル動作の復旧方法を、紙またはオフラインの簡単な記録として残しておきましょう。緊急時の手順は、それを必要とする人が見られるところに置いてください。オートメーションが失敗しても、家にいる全員が、想定されたローカルまたは物理的な方法で照明を点け、暖房を調整し、ドアの鍵を開ける方法を知っているべきです。

最後に、購入時の書類を保管し、メーカーがサポート方針や製品終了の方針を公表している場合はそれを確認してください。将来の互換性についての宣伝上の約束よりも、明確な終了計画や移行計画のほうが役に立ちます。

自宅を外部にさらさずにHome Assistantを設定するにはどうすればよいですか？

Home Assistantは、標準ではローカルネットワークからしか到達できないとしています。 ^[5] これは、ローカル優先の家庭にとって理にかなった出発点です。サポートされ保守されているハードウェアにインストールし、強力で使い回しのない認証情報を作成し、リリース情報を確認してからアップデートを適用し、インテグレーションやオートメーションを変更する前にバックアップを作成してください。

リモートアクセスは任意です。Home Assistantは、クラウドによるリモートアクセスサービスとVPNの選択肢を文書化しており、単にルーターのポートを開けるだけでは安全ではないと注意を促しています。そして、環境をインターネットに公開する前に、同社のセキュリティ確保のチェックリストに従うよう推奨しています。 ^[5] リモートアクセスが必要ないなら、ローカルのままにしておくことで、露出の一分野がまるごとなくなります。

家庭の中でも最小権限の原則を使いましょう。家族には必要なアクセス権だけを与え、管理者アカウントの共有を避け、古いインテグレーションやユーザーは削除します。カメラやセキュリティ上重要な機器は、その家庭に適したネットワーク構成に置き、どの外部サービスが機器のデータを見られるのかを見直してください。

クラウドが使えないものとして、オートメーションをテストしてください。Home Assistantのドキュメントによると、ローカルプロトコルの機器とオートメーションはインターネット障害の間も動き続けられますが、ベンダーのクラウド専用の機器には、インターネットがなければそのクラウドインテグレーションから到達できません。 ^[3] 重要な日常の動作は、文書化されたローカル経路を持つ機器を中心に組み立て、安全に関わる操作には手動の代替手段を残しておいてください。

サービス、支払い、通信に関する制限を回避するためにローカルコントローラーを使ってはいけません。その目的は、家庭におけるごく普通の信頼性とプライバシーであり、隠れたアクセスや安全でないインターネットへの公開ではありません。

どの機器をローカル優先にしておくべきですか？

照明、スイッチ、センサー、サーモスタット、基本的なスマートプラグは、中心となる機能が単純で、家の中で動くことが当然に期待されるため、ローカル優先の設計に適した有力な候補です。Matter対応機器は、コントローラーとネットワークが対応していれば、ローカルの制御経路を提供できます。 ^[1][2] オートメーションが使える場合でも、物理的な操作部は引き続き重要です。

錠、警報装置、暖房には、最も厳格な障害対策の計画が求められます。スマート機能は便利かもしれませんが、家には、出入りと温度調整のための文書化された手動の手段が必要です。電池切れ時の挙動、物理的な鍵や認められたローカルでの手動操作、障害の通知、そしてコントローラーが使えないときに誰がその機器を操作できるのかを確認してください。これらの問いに明確な答えが出るまでは、安全に関わる役割に機器を設置してはいけません。

カメラ、ドアベル、クラウド録画サービスは、映像の保存、通知、遠隔での映像確認がベンダーのサービスとアカウントに依存することがあるため、クラウドへの依存が多くなりがちです。別の機能がMatterに対応しているからといって、クラウドカメラのサービスが完全にローカルな映像システムに変わるわけではありません。個々の製品のドキュメントを読み、保存、保持期間、リモートアクセスについて意図をもって決めてください。

本来の役割にローカルや手動の代替手段がなく、あいまいなクラウドの約束しか示さない機器は、買うのを避けてください。これは、クラウド機能がすべて悪いという意味ではありません。その機能が動かなくなったり、有料になったり、提供終了になったりした場合の結果を、買い手が知っておくべきだという意味です。

最良の構成は、たいていの場合、完全にオフラインの家ではありません。不可欠な機能がローカルで動き続け、リモートの便利な機能は意識して選ばれ、どの構成要素がなぜインターネットを必要とするのかを所有者が特定できる家です。

長く使えるスマートホームのために、何を買うべきですか？

まずローカル制御と相互運用性から始め、クラウドの便利な機能は、明確な価値を加える部分にだけ追加してください。Matterは、対応するエコシステム間でIPベースのローカル経路を提供し、Googleはクラウド同士の接続に比べて遅延が小さく信頼性が高いと指摘しています。 ^[4] ロゴだけに頼らず、実際の機器の種類とコントローラーの対応状況を確かめてください。

家庭の複雑さに見合ったローカルコントローラーを選びましょう。Home Assistantは、オートメーションをローカルで実行したいと考え、専用の環境を維持できるユーザーにとっての選択肢の1つです。同社のドキュメントによると、ローカルプロトコルはインターネットなしで動き続けられますが、アップデートとクラウドインテグレーションは別個の依存要素として残ります。 ^[3]

地味な障害に備えて計画してください。インターネットが使えない、電気が来ない、リセット、スマートフォンの紛失、アカウントのパスワード変更、サービスの提供終了、ルーターの交換です。条件を管理した障害テストは、製品ページよりも多くのことを明らかにします。基本的な動作がそのテストを乗り切れないなら、システムを拡張する前に、その便利さが依存に見合うかどうかを判断してください。

スマートホームの信頼性は、設計上の選択です。重要なコマンドはローカルネットワークに置き、物理的な代替手段を残し、コントローラーのバックアップを取り、外部への公開は限定しておきましょう。そうすれば、会社のサービス終了や接続障害は、家のコントロールを失う事態ではなく、不便で済むようになります。