ChillaHome スマートホーム構成紹介 - 5.Matter / Thread / Zigbee / BLE の住み分け -

この章は Bluetooth / Zigbee / Thread / Matter を「体感（反応速度・安定性・遅延・途切れ）」の原因まで含めて整理する回です。

スマートホーム機器は、アプリ上ではどれも同じように見えます。

• ボタンを押す
• センサーが反応する
• ライトが点く
• ロックが開く
• 自動化が動く

しかし実際には、その裏側で使っている通信方式がかなり違います。

ChillaHomeでも、体感として以下のような差があります。

• Hueはほぼ1秒以内に点くことが多い
• SwitchBotロックは1〜2秒かかる時がある
• 玄関のような遮蔽が強い場所では、SwitchBotロックが遅い / 不安定に感じることがある
• AqaraのMatter over Wi-Fi製品とZigbee製品で、体感差がそこまで大きくない場面もある
• では将来的にはThreadに寄っていくのか？ それともBluetooth / Zigbeeも残るのか？

このあたりを、今回は TCP/IPモデルっぽい見方 に寄せながら分解していきます。

厳密には、ZigbeeやBLEをTCP/IPモデルにそのまま綺麗に当てはめることはできません。
ただ、「どの層の差が体感差につながるのか」を整理するには、この見方がかなり便利です。

0. 先に結論

先に、今回の結論をざっくり書くとこうです。

• Matterは“スマートホーム操作の共通言語”

  • データモデル、操作方法、認証、権限、コミッショニングなどを標準化する
  • どちらかというとアプリケーション層寄りの話

• Threadは“IPv6ベースの低消費電力メッシュ網”

  • 802.15.4上でIPv6を運ぶ
  • Matterを運ぶ土台として使われやすい

• Zigbeeは“IPではないが、実績のあるメッシュ網”

  • 照明・センサー系で強い
  • Hueのようにブリッジ経由でスマートホーム基盤へ統合される

• Bluetooth / BLEは“近距離・低消費電力の通信”

  • 基本的には点対点 / スター型寄りの使われ方が多い
  • BLE Meshという仕様は存在するが、一般的なスマートホーム製品すべてがそれを前提にしているわけではない
  • 玄関ドアのような遮蔽の強い場所では、体感差が出やすい

• Wi-Fiは“家庭内LANに直接乗る便利な方式”

  • 帯域は広い
  • ただし、台数・干渉・AP設計・クラウド依存の影響を受けやすい

つまり、

• Matter = 何をどう操作するか
• Thread / Zigbee / BLE / Wi-Fi = それをどう運ぶか

という見方をすると分かりやすいです。

1. 全体像：スマートホーム通信を層で見る

まず、ざっくり比較するとこうなります。

Matterは「通信規格」というより、スマートホーム機器同士が共通の言葉で会話するための標準です。
一方で、Thread / Zigbee / BLE / Wi-Fiは、実際に電波やネットワークでデータを運ぶ側の話です。

そのため、同じMatter対応製品でも、

• Matter over Wi-Fi
• Matter over Thread
• Zigbee製品をMatter Bridge経由で見せる
• BLE製品をHub経由で持ち上げる

のように、裏側の経路はかなり違います。

2. Application層：Matterが標準化している範囲

2-1. Matterは「スマートホーム操作の共通言語」

Matterが標準化しているのは、ざっくり言うと以下です。

• デバイスの種類
• 機能
• 属性
• イベント
• コマンド
• 読み取り / 書き込み / サブスクライブ
• 認証
• 暗号化
• 権限
• コミッショニング

たとえば照明であれば、

• オン / オフ
• 明るさ
• 色温度
• 色
• 状態通知

といったものを、メーカーごとの独自仕様ではなく、共通のデータモデルとして扱えるようにするのがMatterの大きな役割です。

これにより、理想的には

• Apple Home
• Google Home
• Alexa
• SmartThings
• Home Assistant

などの複数エコシステムから、同じ機器を同じような考え方で扱いやすくなります。

ただし、ここで注意したいのは、Matterが標準化するのは主に「操作の意味」や「やり取りの方法」であって、電波そのものを飛ばす方式ではないという点です。

そのため、Matter対応と書かれていても、実際には

• Wi-FiでつながるMatter製品
• ThreadでつながるMatter製品
• Zigbee製品をブリッジしてMatterとして見せる製品

が混在します。

2-2. ZigbeeにもZCLという“アプリ層の世界”がある

Zigbeeも、単なる無線方式ではありません。

Zigbeeには、ZCL（Zigbee Cluster Library）のように、照明・センサー・スイッチなどを扱うためのアプリケーション層の考え方があります。

Philips Hueが照明で強いのは、単にZigbeeを使っているからだけではなく、

• 照明向けの実装が成熟している
• Hue Bridgeを中心にエコシステムが整理されている
• 電球・センサー・スイッチが一体で動く
• Google Homeなどにブリッジ経由で統合しやすい

という積み重ねがあるからです。

ただし、Zigbeeは基本的にIPネットワークそのものではありません。
そのため、家庭内LANやスマートホームアプリとつなぐには、Hue Bridgeのようなブリッジが重要になります。

3. Transport層：MatterはUDP + MRPが基本、TCPも使う

3-1. MatterはIPベースで動く

MatterはIPベースのプロトコルです。

ここが、Zigbeeや一般的なBLE機器との大きな違いです。

Matterの通常運用では、IPv6上で通信します。
下位のネットワークとしては、主にWi-Fi / Ethernet / Threadが使われます。

ざっくり言うと、

• Matter over Wi-Fi
• Matter over Ethernet
• Matter over Thread

のような形です。

3-2. MatterはUDP + MRPで信頼性を確保する

Matterの通信では、UDPが基本的に使われます。

ただし、

UDPだから信頼性がない

という単純な話ではありません。

Matterには MRP（Message Reliability Protocol） という仕組みがあり、UDPの上でメッセージの再送や確認を行う設計になっています。

つまり、Matterは

• 軽量なUDPを使う
• 必要な信頼性はMatter側で補う
• IoT機器に向いた低オーバーヘッドな通信にする

という方向です。

一方で、TCPもまったく使わないわけではありません。
大きなペイロードや特定の用途ではTCPが使われる場面もあります。

そのため、表現としては

MatterはIPv6上でUDPを主に使い、MRPで信頼性を担保する。用途によってTCPも使われる。

くらいが一番安全です。

3-3. コミッショニング時にはBLEが使われることがある

Matterでは、初期セットアップ、つまりコミッショニング時にBLEが使われることがあります。

ここは少しややこしいポイントです。

Matter対応製品であっても、

• 初期セットアップ時：BLEを使う
• 通常運用時：Wi-Fi / Thread / Ethernetで通信する

というパターンがあります。

つまり、

Matter製品だから通常運用もBLEで動く

という意味ではありません。

BLEは、スマホと近距離で安全に初期設定するための経路として使われることがあります。

4. Network層：ThreadはIPv6メッシュ、Zigbee/BLEとは思想が違う

4-1. ThreadはIPv6ベースの低消費電力メッシュ

Threadは、スマートホーム向けの低消費電力メッシュネットワークです。

下位の無線としてはIEEE 802.15.4を使い、その上でIPv6を運びます。
低消費電力な無線の上でIPv6を扱うために、6LoWPANなどの仕組みも関係します。

ここがZigbeeとの大きな思想差です。

Zigbeeも802.15.4を使いますが、基本的にはIPネットワークそのものではありません。
一方でThreadは、最初からIPv6ネットワークとして扱えるように設計されています。

このため、Threadは

• スマートホーム機器向け
• 低消費電力
• メッシュ
• IPv6ベース
• Matterを運ぶ土台になりやすい

という特徴を持ちます。

4-2. Thread Border Routerが必要になる

Thread機器を家庭内LANやスマートホームアプリとつなぐには、Thread Border Routerが必要です。

Thread Border Routerは、ざっくり言うと

Threadメッシュ網と、家庭内LAN（Wi-Fi / Ethernet）をつなぐ出入口

です。

Wi-FiルータがWi-Fi機器と有線LANをつなぐように、Thread Border RouterはThread機器を家庭内ネットワーク側へ橋渡しします。

ここで重要なのは、Thread Border Routerは「Matterコントローラ」と同じ意味ではないことです。

• Matter Controller：Matter機器を管理・操作する側
• Thread Border Router：Threadネットワークを家庭内LANへ接続する側

実際の製品では、この2つを兼ねるものもあります。
しかし、概念としては分けて考えた方が分かりやすいです。

4-3. ChillaHomeではAqara Hub M3がThreadの入口になる

ChillaHome視点では、Aqara Hub M3が重要です。

Aqara Hub M3は、Matter Controller / Matter Bridge / Thread Border Routerとしての役割を持つため、Threadを試す入口になります。

これにより、ChillaHomeでは

• Hue：Zigbeeの世界
• SwitchBot：BLE + Hubの世界
• Aqara Hub M3：Thread / Matterの入口

を同居させられます。

4-4. Google Nest MiniはThread Border Routerではない

ここは誤解しやすいポイントです。

Google Nest MiniはGoogle Home連携では便利ですが、Thread Border Routerではありません。
少なくとも、GoogleがThread Border Routerとして挙げている代表的なGoogleデバイスには、Nest Hub系やNest WiFi系が含まれますが、Nest Miniは含まれません。

そのため、

家にGoogle Nest MiniがあるからThread機器もそのまま使える

とは考えない方が安全です。

Matter over Wi-Fiの機器を操作する世界と、Matter over Threadの機器をThreadメッシュへ参加させる世界は分けて考える必要があります。

5. Link層：最後は2.4GHzの現実が効く

ここまでMatter / Thread / Zigbee / BLEを層で見てきましたが、体感差に一番効くのは、最終的にはリンク層の現実です。

つまり、

• 電波が届くか
• 遮蔽物があるか
• 干渉していないか
• 中継できるか
• 常時給電ノードがあるか
• APやHubの位置が適切か

という話です。

5-1. Zigbee / Threadはメッシュ前提で設計しやすい

ZigbeeやThreadの強みは、メッシュを前提に設計しやすいことです。

特に常時給電されている機器は、中継ノードとして機能しやすくなります。

Hueで電球が大量にある構成は、この恩恵を受けやすいです。

• 電球は常時給電
• 台数が多い
• 家の中に分散している
• 照明同士でメッシュを作りやすい
• 人感センサーから照明までの到達性が上がりやすい

このため、Hueは「生活導線の照明」としてかなり安定しやすい構成になります。

5-2. BLEは玄関・金属・遮蔽の影響を受けやすい

BLEは低消費電力で扱いやすい一方、玄関のような環境では弱点が出やすいです。

ChillaHomeの玄関は、

• 金属っぽい扉
• 家の外に出るとWi-Fiすら届きにくい
• ロックとパッドが扉をまたいで通信する
• 設置位置の自由度が低い

という条件があります。

この場合、BLEリンクは

• 距離
• 金属
• 遮蔽
• 電池残量
• 設置角度
• Hubとの位置関係

の影響を強く受けます。

そのため、BLE自体が悪いというより、

BLEの得意な条件から外れると、体感差として出やすい

と捉えるのが良いです。

5-3. BLE Meshは存在するが、ここでは別物として扱う

補足すると、BluetoothにはBLE Meshという仕様も存在します。

そのため、

Bluetoothにはメッシュが存在しない

と書くと不正確です。

ただし、一般的なスマートホーム機器、特にSwitchBotのロックやパッドの話をする場合、Zigbee / Threadのようなメッシュ前提の設計と同列に扱うと誤解しやすいです。

この記事では、BLE Meshという仕様の存在は認めた上で、

SwitchBotロック周辺の体感問題は、基本的にはBLEの近距離リンク品質やHub / Repeater配置の話として考える

という整理にします。

6. 体感差を生む要素

ここまでを踏まえると、スマートホーム機器の体感差は、単純に「規格名」だけでは決まりません。

体感差を生む要素は、主に以下です。

6-1. ローカル完結か、クラウド往復か

同じ「スマホでON/OFF」でも、内部経路が違うと体感は大きく変わります。

• ローカル完結

  • LAN内で完結する
  • 遅延が少ない
  • インターネット障害の影響を受けにくい

• クラウド往復

  • インターネット経由で操作する
  • 遅延が増えやすい
  • クラウド側や回線品質の影響を受ける

SwitchBotや各社IoT機器は、機能によってローカル経路とクラウド経路が混ざることがあります。
そのため、「この製品は必ず速い / 遅い」と単純には言えません。

6-2. メッシュで中継できるか

メッシュが効く構成では、「直接届かない」を中継で救える可能性があります。

たとえばHueのように、常時給電の電球が家中にある構成では、メッシュ網を作りやすくなります。

一方で、BLE中心の構成では、HubやRepeaterの配置が重要になります。

6-3. 常時給電ノードがあるか

メッシュネットワークでは、常時給電ノードが重要です。

バッテリー機器は省電力のため、基本的に常時中継役には向きません。
一方、電球・コンセント・壁スイッチ・有線給電のハブなどは、中継や安定化に貢献しやすいです。

6-4. 設置場所が電波的に厳しくないか

玄関、トイレ、洗面所、浴室付近、金属扉、分電盤付近、電子レンジ付近などは、電波的に厳しいことがあります。

ChillaHomeの玄関は、まさにこのパターンです。

規格としては問題なくても、設置場所が厳しいと、体感は悪化します。

7. ChillaHome視点の製品別考察

ここからは、ChillaHomeの実運用に寄せて整理します。

7-1. SwitchBot：BLE + Hubで持ち上げる構成

7-1-1. SwitchBotの役割

ChillaHomeにおけるSwitchBotは、主に以下の役割です。

• スマートロック
• 顔認証 / 指紋 / キーパッド系
• Bluetoothセンサー類
• Hub Mini / Hub 2 / シーリングライトProなどによる赤外線操作
• クラウド連携
• スマートスピーカー連携

SwitchBotの強みは、既存の生活機器に後付けしやすいことです。

特にロックや赤外線リモコンのように、家の設備を大きく変えずにスマート化できる点は大きいです。

一方で、BLE機器をHubで持ち上げる構成では、Hubと機器の位置関係がかなり重要になります。

7-1-2. 玄関で遅くなりやすい理由

ChillaHomeの玄関では、以下の条件があります。

• ドアが金属っぽい
• 外に出るとWi-Fiも届きにくい
• ロック・パッド・Hubの位置関係が制約される
• 人が待つ場所なので、1秒〜2秒の遅延でも気になりやすい

この条件では、BLEリンクが不安定になりやすくなります。

具体的には、

• 一度で通信できず再送が増える
• 認証後の解錠指示に時間がかかる
• 反応したりしなかったりする
• 体感として「ワンテンポ遅い」と感じる

といった現象が起きやすいです。

7-1-3. 「顔認証パッド → ロックUltra」が遅い場合の切り分け

ここは、記事として一番実用的なポイントです。

SwitchBotロック周辺の遅延は、ざっくり2系統に分けて考えると分かりやすいです。

A. パッド → ロック本体の直結リンクが遅い

顔認証パッドやキーパッドとロック本体の間の通信が遅い場合、主な原因はリンク層です。

つまり、

• 距離
• 金属ドア
• 遮蔽
• 設置位置
• 電池
• ファームウェア
• ロック本体とパッドの向き

といった物理寄りの問題です。

この場合、Hubを増設しても、パッドとロック本体の直結リンクそのものが改善するとは限りません。

対策としては、

• パッドとロック本体の位置関係を見直す
• 電池残量を確認する
• ファームウェアを更新する
• 通信を速くする設定があれば有効化する
• どうしても不安定なら、解錠方法や運用で割り切る

という方向になります。

B. スマホ / クラウド → Hub → ロックの経路が遅い

一方、スマホアプリやスマートスピーカー経由での操作が遅い場合は、別の要素が効きます。

この場合は、

• Hubとロックの距離
• Hubの設置場所
• Hub側のWi-Fi品質
• 2.4GHzの干渉
• クラウド往復
• インターネット回線品質

が支配的になります。

対策としては、

• Hubをロックに近づける
• Hubを玄関に近い部屋へ移動する
• 2.4GHz Wi-FiのRSSIや干渉を確認する
• Hubを増設する
• Bluetooth Repeater対応デバイスを検討する

という方向になります。

7-1-4. Bluetooth Repeaterという救済策

SwitchBotには、Bluetooth Repeaterとして機能する製品があります。

たとえばRelay Switch 1 / 1PM系は、Bluetooth Repeater機能を持ち、SwitchBot Bluetooth機器の到達範囲を広げる用途で使えるとされています。

ただし、ここで大事なのは、公称値をそのまま鵜呑みにしないことです。

見通し最大80m級のような表記があっても、実際の家では

• 壁
• 金属ドア
• 家具
• 設置高
• 電波干渉
• 2.4GHz混雑

の影響を受けます。

そのため、ChillaHome玄関のような遮蔽環境では、

Repeaterを入れれば絶対に解決する

ではなく、

HubやRepeaterを、ロックに近い安定した位置へ置けるかが重要

と考える方が現実的です。

7-1-5. ChillaHomeでの改善優先順位

ChillaHomeでSwitchBotロック周辺を改善するなら、優先順位はこうです。

1. ロック / パッド / Hubの位置関係を確認する
2. ロックとHubのBluetoothリンクを改善する
3. 玄関付近の2.4GHz Wi-Fi品質を確認する
4. 電池残量・ファームウェア・設定を確認する
5. Bluetooth Repeater対応機器を検討する
6. それでも厳しい場合は、玄関はBLEに厳しい場所として運用を割り切る

特に重要なのは、原因が

• パッド → ロック本体
• Hub → ロック本体
• スマホ / クラウド → Hub

のどこにあるかを分けて見ることです。

ここを混ぜると、Hubを増やしても改善しない問題に時間を使ってしまう可能性があります。

7-2. Philips Hue：Zigbeeメッシュ + 照明台数が強い

7-2-1. Hueが生活導線に向く理由

ChillaHomeのHue構成は、生活導線にかなり向いています。

たとえば、

• E17電球
• E26電球
• Lightstrip
• 人感センサー
• 廊下
• キッチン
• 洗面所
• トイレ

のように、「すぐ反応してほしい場所」に集中しています。

Hueがここで強い理由は、Zigbeeメッシュと照明の性質が噛み合っているからです。

照明は基本的に常時給電です。
常時給電のZigbee機器は、メッシュの中継役として機能しやすくなります。

そのため、照明が多い家では、Zigbeeメッシュの密度が上がりやすくなります。

7-2-2. 「ほぼ1秒以内」の体感につながりやすい理由

Hueが速く感じやすい理由は、単にZigbeeだからではありません。

• Hue Bridgeがローカルにある
• 照明機器が常時給電
• メッシュを作りやすい
• 人感センサーと照明の用途が絞られている
• 照明操作は短いコマンドで済む
• クラウド往復に依存しない経路を作りやすい

この組み合わせが効いています。

つまり、Hueの強さは、

Zigbee + Bridge + 常時給電照明 + 用途特化

の合わせ技です。

7-2-3. Hueの注意点

一方で、Hueにも注意点があります。

代表的なのは、

物理スイッチを切られるとスマート照明として死ぬ

という問題です。

スマート電球は常時給電されている前提で動きます。
壁スイッチで電源を切られると、ネットワーク上からも消えます。

そのため、ChillaHomeのようにスイッチカバーを付けて、物理スイッチを不用意に切られないようにする運用はかなり合理的です。

7-3. Aqara：Zigbee / Matter over Wi-Fi / Thread入口が混在する

7-3-1. Aqaraは混在環境を作りやすい

Aqaraは少し特殊で、複数の世界をまたぎやすいメーカーです。

ChillaHomeでは、Aqaraは以下のような位置づけです。

• Hub M3
• Zigbee機器
• Matter対応機器
• Wi-Fi系デバイス
• Thread検証の入口
• FP2のようなミリ波センサー系

Aqara Hub M3は、Thread Border Routerとしても使えるため、ChillaHomeでThreadを試す入口になります。

7-3-2. Matter製品とZigbee製品で体感差が小さい理由

ChillaHomeでは、AqaraのMatter over Wi-Fi製品とZigbee製品で、体感差がそこまで大きくない場面があります。

これは自然です。

なぜなら、家庭内のスマートホーム操作は、多くの場合

• 短いコマンド
• 小さな状態変化
• ローカルネットワーク内の通信
• 数百ミリ秒〜数秒以内の体感

の世界だからです。

この場合、規格名そのものよりも、

• ローカルで完結しているか
• 電波が安定しているか
• Hub / APの位置が良いか
• クラウド往復していないか
• 製品実装が安定しているか

の方が体感に効くことがあります。

つまり、

Matterだから必ず速い
Zigbeeだから必ず遅い
Threadだから必ず快適

という単純な話ではありません。

7-3-3. FP2のような製品は“規格差”とは別の難しさがある

Aqara FP2のようなミリ波センサーは、通信方式だけで評価しにくい製品です。

FP2で気になるのは、通信遅延よりも、

• ゴースト
• 検知エリア設定
• 人の滞在判定
• 部屋の形状
• 反射
• 設置位置

のようなセンサー特性です。

つまり、スマートホーム機器の体感は、

• 通信方式の問題
• センサーの問題
• 自動化ロジックの問題
• 設置場所の問題

が混ざって出てきます。

このあたりを分けて考えないと、原因を見誤りやすいです。

8. 将来：Threadに寄っていくのか、Zigbee/BLEは残るのか

8-1. 長期的にはMatter + Threadは強い

長期的には、Matter + Threadの組み合わせはかなり強いと思っています。

理由は、

• Matterがアプリ層の共通言語になる
• ThreadがIPv6ベースの低消費電力メッシュになる
• IPネットワークとして統合しやすい
• 複数メーカー・複数エコシステムをまたぎやすい
• ローカル制御との相性が良い

からです。

スマートホームが「メーカーごとの閉じた世界」から、「IPベースで相互運用する世界」に寄っていくなら、Matter + Threadはかなり自然な方向です。

8-2. それでもZigbeeは残る

ただし、Zigbeeがすぐ消えるとは思いません。

理由はシンプルです。

• 既存製品が多い
• 照明・センサーで実績がある
• Hueのような強いエコシステムがある
• ブリッジ経由でMatter側に見せられる
• 製品ラインナップが豊富
• E17のような現実的な製品選択でZigbeeが強い場合がある

ChillaHomeでも、Hueを使っている理由は「理想の規格」だけではなく、E17電球や生活導線に合う製品が存在するからです。

スマートホームでは、規格の美しさよりも、

実際に買える製品があるか
家の設備に合うか
安定して動くか
家族が困らないか

の方が重要です。

その意味で、Zigbeeはまだまだ残ると思います。

8-3. BLEも残る

BLEも残ります。

特に、

• 初期セットアップ
• スマホとの近距離通信
• ロック
• タグ
• 小型センサー
• 後付け機器
• 低消費電力機器

では、BLEは便利です。

ただし、ChillaHome玄関のように遮蔽が強い場所では、BLE単体の弱点が出やすくなります。

そのため、BLEを使う場合は、

• Hubを近づける
• Repeaterを使う
• 金属ドアをまたぐ通信を過信しない
• 電池残量を軽視しない
• 遠隔操作経路と直結経路を分けて考える

という設計が重要になります。

8-4. Wi-Fiも当然残る

Wi-Fiも残ります。

特に、

• カメラ
• スピーカー
• 家電
• 赤外線リモコン
• 大きめの電力を使える機器
• ファームウェア更新が多い機器

ではWi-Fiが便利です。

ただし、Wi-Fiは便利な反面、

• 台数が増える
• 2.4GHzが混む
• AP設計が悪いと不安定になる
• IoT機器が大量にぶら下がる
• クラウド依存が混ざりやすい

という問題もあります。

結局、スマートホームでは「全部Thread」でも「全部Wi-Fi」でもなく、用途に応じた混在が現実解になると思います。

9. ChillaHomeに落とす設計メモ

最後に、ChillaHome視点で整理します。

9-1. 生活導線の照明はHue / Zigbeeが強い

廊下、洗面所、トイレ、キッチンなど、毎日使う場所では反応速度が重要です。

ここはHue / Zigbeeがかなり強いです。

理由は、

• 電球が常時給電
• メッシュを作りやすい
• Hue Bridgeでローカル制御しやすい
• 照明用途に特化している
• 家族が体感しやすい場所で安定する

からです。

9-2. 玄関はBLEの弱点が出やすい

玄関は、スマートホームの中でもかなり難しい場所です。

• 金属ドア
• 屋外 / 屋内の境界
• 電波遮蔽
• 設置位置の制約
• 電池駆動
• 反応待ちのストレス

が重なります。

SwitchBotロックの体感差は、製品の良し悪しだけではなく、玄関という場所の難しさも大きいです。

9-3. ThreadはAqara Hub M3を入口に検証する

Threadを試すなら、Aqara Hub M3を入口にするのが自然です。

ただし、Threadはまだ「入れれば全部解決」という段階ではなく、

• Border Routerの互換性
• 複数エコシステムのThreadネットワーク
• Matter Controllerとの関係
• 既存Zigbee機器との住み分け

を見ながら検証する必要があります。

9-4. ChillaHomeの現実解

現時点のChillaHomeでは、以下の住み分けが現実的です。

• 照明・人感：Hue / Zigbee
• 玄関ロック：SwitchBot / BLE + Hub / Repeater検討
• 赤外線家電：SwitchBot Hub系
• センサー実験：Aqara
• Thread検証：Aqara Hub M3
• 高帯域機器：Wi-Fi
• 統合・自動化：Google Home / Home Assistant / 各社アプリを用途別に併用

10. まとめ

今回のポイントをまとめます。

• Matterは、スマートホーム操作の共通言語
• Threadは、IPv6ベースの低消費電力メッシュ
• Zigbeeは、IPではないが実績のあるメッシュ
• BLEは、近距離・低消費電力に強いが、遮蔽の強い場所では体感差が出やすい
• Wi-Fiは便利だが、AP設計・混雑・クラウド依存の影響を受ける
• Hueが速く感じるのは、Zigbeeメッシュ + 常時給電照明 + Bridge + 用途特化の組み合わせが強いから
• SwitchBotロックが玄関で遅く感じる場合は、パッド↔ロック、Hub↔ロック、クラウド↔Hubの経路を分けて考えるべき
• Aqara Hub M3は、ChillaHomeでThread / Matterを検証する入口になる
• 将来的にMatter / Threadは伸びるが、Zigbee / BLE / Wi-Fiがすぐ消えるわけではない

スマートホームは、規格名だけで良し悪しが決まる世界ではありません。

実際には、

• どこに置くか
• 何を操作するか
• 電源があるか
• 中継できるか
• ローカルで完結するか
• 家族がストレスなく使えるか

の方が重要です。

ChillaHomeでは、今後も「理想の規格」だけでなく、「実際に生活で安定して使えるか」を基準に、Hue / SwitchBot / Aqara / Matter / Threadを使い分けていく方針です。

付録A：規格・技術情報の参考URL

Matter

• Matter公式 / Connectivity Standards Alliance
  • https://csa-iot.org/all-solutions/matter/
• Matter仕様ダウンロード
  • https://csa-iot.org/developer-resource/specifications-download-request/
• Matter SDK / Project CHIP Documentation
  • https://project-chip.github.io/connectedhomeip-doc/

Thread

• Thread Group
  • https://www.threadgroup.org/
• OpenThread
  • https://openthread.io/
• Google Home Developers - Thread
  • https://developers.home.google.com/matter/thread

Zigbee

• Connectivity Standards Alliance - Zigbee
  • https://csa-iot.org/all-solutions/zigbee/

Bluetooth

• Bluetooth SIG Specifications
  • https://www.bluetooth.com/specifications/specs/
• Bluetooth Mesh
  • https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/mesh/

付録B：ベンダー情報の参考URL

Philips Hue

• Hue Developer Program
  • https://developers.meethue.com/develop/hue/

Aqara

• Aqara Hub M3 FAQ
  • https://www.aqara.com/jp/product/hub-m3-faq/
• Aqara Hub M3
  • https://www.aqara.com/en/product/hub-m3/

SwitchBot

• SwitchBot公式
  • https://www.switchbot.jp/
• SwitchBot Relay Switch 1PM
  • https://www.switch-bot.com/products/switchbot-relay-switch-1pm
• SwitchBot API
  • https://github.com/OpenWonderLabs/SwitchBotAPI