皆様の家には、いったいいくつの「専用アプリ」と「専用ハブ」が転がっているのでしょうか。 照明をつけるためのアプリ、鍵を開けるためのアプリ、エアコンを操作するためのアプリ。各メーカーが己の覇権を信じて独自の規格を作り続けた結果、皆様の家は互いに会話の通じないデバイス群がひしめき合う、カオスな電子の孤島と化しました。
この果てしない分断を終わらせる「夢の統一規格」として鳴り物入りで登場したのが、MatterとThreadです。しかし、プロトコルが統一されれば全てが丸く収まるほど、この世界は単純ではありません。
絶え間なく膨張する「統一規格」という地層#
Matterは単一の規格でありながら、内部はバージョンごとに絶え間なく変化しています。Matter 1.5.1ではカメラの複数ストリーム配信などが追加されましたが、より根深いのはMatter 1.4.2で導入されたVID（ベンダーID）検証、Access Restriction Lists（アクセス制限リスト）、CRL（証明書失効リスト）、Quieter Reportingといったセキュリティ要件、そして「1台のThread Border Routerが少なくとも150台のデバイスを支える」「Wi-Fi APが100台の同時接続を支える」といったスケーラビリティ要件です。
「Matter対応」と銘打たれた製品を導入しても、ハブ側が特定の要件をサポートしていなければ、想定通りの動作は約束されません。もはやMatterは単なる「共通語」ではなく、ベンダーごとの実装差分やバージョン差異という新たな地層を積み上げる土台となっているのが現実です。
Thread 1.4とネットワーク分断への処方箋#
Matterを支える主要な低消費電力通信プロトコル「Thread」もまた、進化の過程にあります。Thread 1.4のホワイトペーパーを読むと、この規格が直面していた課題が見えてきます。
これまで、異なるメーカーのThreadボーダールーターを導入すると、家の中に別々のネットワークが乱立してしまう問題がありました。Thread 1.4では「Credentials Sharing（資格情報の共有）」機能が導入されました。対応ボーダールーターが周囲に機能を知らせ、ユーザーの操作と一時的な安全接続を経て資格情報を渡すことで、既存ネットワークへの参加を容易にします。これにより不要な別Threadネットワークの作成を避けやすくなりますが、実際の運用には1.4対応の機器が適切に導入されているという前提が必要です。
主権の奪還とOSSハブを用いた「主従の設計」#
ここで面白いのが、巨大テック企業のクラウドに依存しない「ローカル制御」を志向するオープンソースコミュニティの動きです。
Home Assistantはオープンソースプロジェクトとして初めてMatter認証を取得しました。Matterサーバーとユーザーインターフェース（UI）を分離して認証を取得したことで、アップデートごとに再認証を受ける手間を省きつつ、制御経路をローカルな環境へ置くことに成功しています。
openHABのMatterバインディングも同様に、クライアントとしての機能だけでなく、openHAB自身を「Matterデバイス（ブリッジ）」としてApple HomeやGoogle Homeに公開する機能を備えています。
これらを踏まえ、わたくしは一つの強烈な設計論を提案します。それは「OSSのハブを『家の権限の門番』として据え置き、各社の高度なAIアシスタントを単なる『便利な音声UI』として部分的に従属させる」という主権の分割です。
図の矢印が示すように、下回りのデバイス制御とローカルに閉じる自動化（Local Control & Automation）はすべてOSSハブが握り込み、外部のAIには限定的なコマンドの受け入れ（AI Commands & Insights）だけを許可するよう構成します。Matterが機器の共通語になり、GoogleのGemini for HomeやAmazonのLLM化されたAlexaが生活パターンの支配層として機能する現在、AIに見せる履歴と見せない操作をハブ側で選別する意味は極めて大きいです。
ローカルネットワークとIPv6ルーティングの罠#
しかし、この洗練された運用を構築するための道は決して平坦ではありません。Home AssistantやopenHABのドキュメントを読み解くと、そこには「IPv6ルーティング」という巨大な罠が待ち構えていることがわかります。
Matterは基盤プロトコルとしてIPv6を強く要求します。Dockerコンテナでスマートホームハブを運用していたり、セキュリティのためにVLANやサブネットを分離していたりすると、mDNSによるローカルネットワーク上のデバイス発見や相互到達性が途端に壊れます。Linuxホスト側のRouter Advertisements（RA）やRoute Information Options（RIO）のカーネル設定まで要求されるなど、自前で構築しようとした途端に、高度なIPv6マルチキャストルーティングの知識を要求してくるのです。
複数規格を使い分ける「分割統治」の設計論#
MatterとThreadが未来の主役だとしても、家を一つの規格で統一してしまう必要はありません。むしろ、適材適所で規格を使い分けるハイブリッド運用こそが、強靭なスマートホームの設計論です。
例えばZigbee2MQTTを使えば、絶えず追加される膨大な種類の安価なZigbeeデバイスを照明などの主軸に据えることができます。さらにESPHome 2026.5.0ではESP32-H2/C6を用いた自作デバイスを直接Zigbeeルーターやエンドデバイスとしてネットワークへ参加させる機能が強化され、用途に応じた専用センサーを組み込むことが容易になりました。
また、Z-Waveは長距離通信（Long Range）という独自の強みを持っています。Threadの2.4GHz帯域では電波が届きにくい屋外や離れには、最大4,000ノードをスター型トポロジで収容できるZ-Wave LRを配置し、屋内はMatter/ThreadとZigbeeでカバーするといった「分割統治」によって、各規格の弱点を補い合うことができます。
命令権限を分割して設計せよ#
MatterとThreadの登場により、デバイス間の基本的な会話は確かに成立するようになりました。しかし、それは「どのデバイスを選ぶか」という悩みが消えたわけではありません。
私たちは、Apple、Google、Amazonといった巨大企業に家のすべてを預けるという短絡的な選択に陥る必要はありません。かといって、クラウドの利便性を完全に捨てる必要もないのです。真に問われているのは「自分のものであるはずの空間とデバイスの命令権限を、どのように切り分けて設計するか」です。
統一規格に丸投げして思考を止めるのではなく、システムの境界線を自ら引き直し、便利なAIとローカルの主権を天秤にかける。その果てしない作業こそが、現代のスマートホーム構築における最も優雅な愉しみだと思いませんか？