Shelly ThreadLinkがThreadをIPネットワークに変えるわけではありません。Threadは当初からIPv6上に構築されています。変わるのは、Shellyがそのネットワークをどのように利用するかです。Threadを主にMatter用に確保し、ベンダーAPI、クラウド接続、高度な機能をWi-Fi上に残すのではなく、ThreadLinkはそれらの複数の経路を同じ低消費電力メッシュ上で運ぶよう設計されています。
そのため、ThreadLinkは単なるMatter互換性の発表よりも興味深いものです。このアプローチが約束どおりに機能すれば、Threadはスマートホームの低消費電力IPエッジになり得ます。リレー、スイッチ、センサー、コントロール機器がThread上で通信し、Home Assistant、サーバー、Wi-Fiデバイス、Ethernetシステムはより広いローカルネットワークの一部として引き続き機能します。ただし、ファームウェアはまだ利用できません。Shellyは現在、9月3日の発表からおよそ3か月後にオプトイン方式のアップデートを提供する予定です。
Shelly ThreadLinkとは?
ThreadLinkは、対象となるShelly Gen4デバイス向けの新しい代替ファームウェアです。Thread対応無線を主に1つのアプリケーション経路に限定せず、より幅広いIP接続として利用します。
Shellyは公式のThreadLink発表で、ファームウェアがThread上でIPv6ネットワークを実行しながら、TCPおよびRPC/UDP通信をサポートすると説明しています。同じ低消費電力無線が、次の通信を担うことを想定しています。
- Matter接続、
- Shelly Cloudのトラフィック、
- Shelly RPCおよびAPI通信、
- デバイス間の直接制御、
- 設定と診断、
- そして、より深いHome Assistant連携。
主なアーキテクチャ上の変更は次のようになります。
一般的な現在のモデル
Matter
|
Thread
Shellyデバイス ───── Wi-Fi ───── Shelly API
|
└─────────── Wi-Fi ───── クラウド
THREADLINKの方向性
Matter
|
Shelly API ─────── Thread ───── クラウド経路
|
ローカルP2P
ベンダー固有のデバイス側通信にWi-Fiを必要とし、ThreadがMatterを運ぶ構成ではなく、ShellyはThread自体に複数のアプリケーションのIPトランスポートを同時に担わせようとしています。
この区別は重要です。MatterとThreadは、ネットワーク上の同じ階層ではありません。
Shelly ThreadLinkは現在利用できますか?
いいえ。ThreadLinkは発表されていますが、製品版ファームウェアはまだ一般提供されていません。
Shellyによると、2026年9月3日の発表から約3か月後に、対象となるGen4デバイス向けの無料のオプトイン方式ファームウェアとして別途提供される予定です。
ユーザーは、デバイスごとに標準のWi-Fi指向ファームウェアを実行するか、ThreadLinkを実行するかを選択します。
| ThreadLinkのステータス | 現在の状況 |
|---|---|
| 発表済み | はい — 2026年9月3日 |
| 一般提供済み | まだ |
| 対象ハードウェア | 対象となるShelly Gen4デバイス |
| ファームウェアの種類 | 別途オプトイン方式のアップデート |
| 予定時期 | 発表から約3か月後 |
| 価格 | 無料アップデートとして提供予定 |
これは、現時点ではThreadLinkを、すべてのGen4所有者が今すぐ有効化できる機能ではなく、発表されたアーキテクチャとして扱うべきだという意味です。
また、すべてのGen4モデルがファームウェアを受け取ると主張するのは時期尚早だということでもあります。Shellyは具体的に対象となるGen4デバイスと述べているため、最終的な互換性リストが重要になります。
ThreadはすでにIPネットワークではなかったのですか?
はい。これは、解消しておくべき最も重要な誤解です。
Threadは、IEEE 802.15.4無線上で6LoWPANを使用する、IPv6ベースのメッシュネットワークとして設計されました。ThreadのIPv6基盤に関するThread Groupの説明によると、この設計原則はMatterが存在する何年も前にさかのぼります。
ネットワークスタックは次のように簡略化できます。
アプリケーション
Matter
ベンダープロトコル
その他のIPサービス
|
v
トランスポート
UDP / TCP
|
v
ネットワーク
IPv6
|
v
アダプテーション
6LoWPAN
|
v
無線
IEEE 802.15.4
したがってThreadは、多くの人が気軽に説明するような意味でのMatter専用無線プロトコルではありません。
Threadは、その上位でアプリケーションプロトコルを運べる低消費電力のIPネットワークです。
現在、MatterはThreadにおける最も目立つコンシューマースマートホーム用途ですが、Thread自体はアプリケーション層に依存しないよう設計されています。
ThreadLinkはThreadをIPネットワークにするわけではありません。すでにIPネットワークであるThreadを、よりその本来の姿に近い形で利用します。
ThreadLinkで実際に新しいことは何か?
新しいのはIPv6そのものではありません。1台のコンシューマーIoTデバイスで、現在もWi-Fiに依存することが多い複数のアプリケーション経路にThreadを利用できるようにしたという判断です。
MATTERパイプとしてのTHREAD
Matter
|
Thread
↓
ネットワークとしてのTHREAD
Matter ─────────┐
|
Shelly RPC ─────┤
|
ローカルAPI ──────┼── IPv6 / Thread
|
P2Pロジック ──────┤
|
クラウド経路 ─────┘
これにより、無線通信の役割が変わります。
Threadは、別のエコシステムからMatter経由でリレーを操作できるという理由だけで役立つものではありません。Shelly独自のアプリケーション通信、ローカルロジック、設定、診断、さらにはソフトウェア更新も運ぶことができます。
Shellyは、ThreadLinkが応答性の高いローカル通信向けのUDPと、設定データや診断情報など、より大容量または信頼性が重視される転送向けの完全なTCPサポートを提供すると説明しています。
これは、Threadに接続されたコンシューマーデバイスで可能なことを、はるかに広く捉えた解釈です。
MatterがShellyのすべての機能を公開しない理由
相互運用性とベンダーによる差別化は、異なる問題を解決するものだからです。
Matterは、メーカーやスマートホームプラットフォームに標準化されたデバイスモデルを提供します。Matter対応リレーは、Apple Home、Google Home、Amazon Alexa、SmartThings、Home Assistantなどが理解できる既知の機能を公開できるため、各プラットフォームでまったく異なる独自プロトコルを実装する必要がありません。
この標準化には大きな価値があります。
ただし、ベンダーは標準化されたMatterモデルを超える機能を公開する場合もあります。たとえば:
- より詳細なエネルギー測定、
- 診断情報、
- 特殊なリレー動作、
- デバイス固有の設定、
- スクリプトまたはオートメーション機能、
- 高度なステータス情報、
- およびベンダー管理機能。
現在、多くの場合、次の2つの並行した経路が存在します。
デバイス
|
+-- Matter
| |
| v
| 標準機能
| Apple/Google/HA
|
+-- ベンダーAPI
|
v
高度な機能
診断
設定
ThreadLinkは、2つの異なるネットワークトランスポートを必要とせずに、これら2つの経路を維持しようとしています。
Matter
\
\
Thread
/
/
Shelly RPC
Shellyによると、専用のHome Assistantモジュールによって、Matterのデータモデルが提供する範囲を超えた、より幅広いShellyの機能セットを利用できるようになります。
そのためThreadLinkが重要になります。MatterはThread上で1つのアプリケーションとして動作し続けながら、Thread上で唯一のアプリケーションになる必要はありません。
Shellyデバイス同士はWi-Fiなしで制御できますか?
ShellyのThreadLink設計によれば、答えは「はい」です。
Shellyによると、ThreadLinkデバイスはAPIを介してThreadメッシュ上で直接通信できるため、シーン、インターロック、オートメーションをピアツーピアで実行できます。
重要なのは、障害発生時の経路です。
Shellyによると、次のような場合でもデバイス間の関係は継続できます。
- インターネット接続に障害が発生した場合、
- Shelly Cloudに到達できない場合、
- または、家庭のWi-Fiネットワークが停止した場合。
そのため、単純な関係は次のようになります。
壁スイッチ
|
Thread
|
v
リレー
常に次の構成を必要とするのではなく、
壁スイッチ
|
v
Wi-Fi/ルーター
|
v
ホームサーバー
|
v
Wi-Fi/ルーター
|
v
リレー
これによって、サーバー経由の構成が間違いになるわけではありません。
すべてのローカル操作でHome Assistantを使う必要はない、という意味です。
ローカル制御にHome Assistantはまだ必要ですか?
単純なデバイス間の関係であれば、必ずしもそうとは限りません。より広範なオーケストレーションでは、Home Assistantには依然としてまったく異なる役割があります。
ローカルの壁スイッチで1つのリレーをオンにすることは、複数のシステムを組み合わせるオートメーションとは根本的に異なります。
デバイスレベルのロジックで処理できるのは次のようなものです。
- 単純なスイッチとリレーの関係、
- インターロック、
- 基本的なシーン、
- 即時のフォールバック動作。
ホームオートメーションサーバーは、次のようなロジックに適しています。
IF
太陽光の売電電力 > 3000 W
AND
バッテリーのSOC > 80%
AND
部屋に人がいる
AND
電気料金が安い
THEN
HVAC/家電の負荷を有効化
このワークフローは、エネルギー、在室状況、価格、スケジュール、さらに複数のプロトコルにまたがる可能性があります。
これは、より上位のオーケストレーション層に属します。Home Assistantのローカル処理が広がる動きも同じ原則に従っています。適切な判断は家庭内の近くで行い、本当に必要な処理に限ってクラウドへの依存を残します。
デバイスレベルのローカル制御
スイッチ
|
Thread P2P
|
リレー
サーバーレベルのローカル制御
太陽光 ───────┐
エネルギーメーター ┤
在宅状況 ────┼── Home Assistant ── HVAC
スケジュール ────┤
その他のIoT ───┘
ローカルファーストは、必ずしもサーバーファーストを意味しません。
堅牢なスマートホームでは、単純な操作にはローカルのデバイス間連携を使用し、ホームサーバーはシステム間のロジック、履歴、ポリシー、ダッシュボード、状態の管理に集中させることができます。
ThreadLinkはWi-Fiなしでどのようにクラウドへ接続できるのか?
ThreadLinkのより珍しい特徴の一つは、エンドポイントがThreadデバイスのままでありながら、Shelly Cloudにアクセスできることです。
この経路では、デバイス自体にWi-Fi認証情報は必要ありません。
Shellyはこのアーキテクチャを次のように説明しています。
Shelly ThreadLinkデバイス
|
v
IPv6/Thread
|
v
Threadボーダールーター
|
v
NAT64
|
v
IPv4インターネットサービス
|
v
Shelly Cloud
この考え方は、Threadの幅広い開発方針にも合致します。Thread 1.4では、Threadネットワークからインターネットサービスへ向かう標準経路に関する追加作業が正式化されており、ネットワークエッジでのIPv6からIPv4への接続も含まれます。
重要な概念上の変化は次のとおりです。
クラウド接続は、エンドポイントでWi-Fi接続を必要とするとは限りません。
低消費電力デバイスはローカルではThreadを使用し、ネットワーク上位のIPルーティングによって外部サービスへのアクセスを処理できます。
だからといって、ThreadLinkがローカル専用になるわけではありません。
これはその逆を示しています。ローカルデバイス通信と任意のクラウド接続は、同じIPアーキテクチャを共有できます。
Threadボーダールーターは実際に何をするのか?
Threadボーダールーターは、Threadメッシュをより広いIPネットワークに接続します。本質的にはルーターであり、すべてのスマートホームコマンドを変換するプロトコル変換器ではありません。
Thread GroupによるThreadボーダールーターの役割についての説明では、この違いが明確に示されています。
従来のスマートホームアーキテクチャは、一般的に次のようになります。
Zigbeeデバイス
|
v
Zigbeeネットワーク
|
v
ベンダーハブ
|
プロトコル変換
|
v
IPネットワーク
一方、Threadはデバイスネットワーク自体でIPを使用します。
Threadデバイス
|
IPv6/Thread
|
v
ボーダールーター
|
IPルーティング
|
v
ホームLAN
ボーダールーターは、物理ネットワークセグメント間でパケットを転送します。
Threadから独自のLANプロトコルへ、すべてのアプリケーションコマンドを変換する必要はありません。
つまり、Home Assistantはローカルネットワーク上の別の場所に配置できます。
Threadデバイス
|
Threadメッシュ
|
ボーダールーター
|
イーサネット/Wi-Fi LAN
|
+-- Home Assistant
+-- ホームサーバー
+-- その他のIPサービス
したがって、MatterコントローラーとThreadボーダールーターは異なる役割を担います。ボーダールーターはネットワークへの到達性を提供し、Matterはそのネットワーク上でアプリケーションとコントローラーの関係を提供します。複数のプラットフォームが同じMatterデバイスを個別に制御する場合、複数のMatterコントローラーによって、Threadのルーティングだけでは解決できない、独立した信頼と所有権のレイヤーが導入されます。
トラフィックがThreadメッシュを離れた後も、通常のIPルールは適用されます。Home Assistantのネットワーク到達性は、引き続き、コントローラーとエンドポイント間で使用可能なアドレス指定、ルーティング、ポリシー、および機能する戻り経路に依存します。
ThreadLinkはThreadがWi-Fiに取って代わることを意味するのか?
いいえ。ThreadとWi-Fiは、異なる種類のトラフィックに合わせて最適化されています。
Home Assistantの現在のThreadドキュメントでは、Threadは低消費電力かつ低帯域幅であり、比較的少量のデータをやり取りするデバイスに特に適していると説明されています。
| ワークロード | 自然なネットワーク |
|---|---|
| モーションセンサー | Thread |
| 壁スイッチ | Thread |
| リレー | Thread |
| ドアロック | Thread |
| 低データレートの環境センサー | Thread |
| セキュリティカメラ | Wi-Fi / Ethernet |
| ビデオディスプレイ | Wi-Fi / Ethernet |
| ノートパソコン | Wi-Fi / Ethernet |
| NAS | Ethernet |
低消費電力のリレーにWi-Fiの帯域幅は必要ありません。
4Kセキュリティカメラを、ThreadがIPベースだからという理由だけでThreadに接続すべきではありません。
Threadは新しいWi-Fiになるわけではありません。同じホームネットワークにおける、低消費電力のIPエッジになる可能性があります。
ThreadはホームLANの低消費電力エッジになりつつあるのか?
ここで、個々のShellyファームウェア発表よりもThreadLinkのほうが興味深い存在になります。
将来のローカルネットワークは、複数の孤立したスマートホームエコシステムというより、複数の物理伝送媒体に広がる1つのIPアーキテクチャに近い形になる可能性があります。
ホームサーバー
|
|
ホームIPネットワーク
|
+-----------------+----------------+
| | |
Ethernet Wi-Fi Thread
| | |
NAS カメラ リレー
サーバー スマートフォン センサー
ワークステーション テレビ スイッチ
ロック
エンドポイントでは、すべてのデバイスが同じ無線方式を使用する必要はありません。
適切な場合に、上位層が標準ルーティングを通じて通信できることのほうが重要です。
これは、Thread、Wi-Fi、Ethernetを1つの勝者にするために競わせることとは根本的に異なります。
未来のスマートホームには、1つの無線ネットワークしか存在しないとは限りません。複数の物理ネットワークにまたがる、1つのIPアーキテクチャになる可能性があります。
ThreadLinkはHome Assistantにどのような変化をもたらすのか?
ThreadLinkにより、Home Assistantは同じ物理Shellyデバイスへ、便利な2つの経路で接続できる可能性があります。
1つ目は標準Matterです。
Shellyデバイス
|
Thread上のMatter
|
Threadボーダールーター
|
Home Assistant Matterコントローラー
|
標準Matter機能
2つ目は、Shellyが計画しているベンダー固有の経路です。
Shellyデバイス
|
Thread上のShelly RPC
|
Threadボーダールーター
|
Home Assistant
|
Shelly固有の機能
公式のHome AssistantのMatterアーキテクチャは、ネットワークとアプリケーションの違いをすでに明確にしています。Matterはアプリケーションレベルの制御プロトコルであり、デバイスに応じてWi-Fi、Ethernet、またはThreadを介して通信できます。
ThreadLinkは、このレイヤー化された設計を基盤にしています。
Matterはエコシステム間の相互運用性を実現しつつ、Shelly統合はデバイス固有のより高度な機能を維持できます。
これは、相互運用性とベンダーの高度な機能のどちらかをユーザーに選ばせるよりも、優れたアーキテクチャです。
現在、本当に1つのThreadネットワークを実現できるのでしょうか?
必ずしもそうとは限りません。現在のThread導入環境は、理想的なアーキテクチャが示すよりも分断されている可能性があります。
Home Assistantは現在、Thread統合を開発中の機能として説明しており、家庭内に存在する異なるThreadネットワークを明示的に追跡しています。
家庭内では、次のような構成が見つかる場合があります。
AppleのThreadネットワーク
|
異なる認証情報
GoogleのThreadネットワーク
|
異なる認証情報
Home AssistantのThreadネットワーク
|
different credentials
別々のThreadネットワーク上にあるデバイスは、すべてがThreadを使用しているというだけで、自動的に1つの大規模なメッシュになるわけではありません。
Home Assistantは、ユーザーが既存のネットワークを確認したり、対応している場合にはHome Assistantボーダールーターを希望する既存ネットワークに参加させたりするのに役立ちます。しかし、一般消費者向けエコシステムは、すべての家庭で完全に統合された1つのThreadメッシュと同等になっているわけではありません。
これはThreadLinkにとって重要な現実確認です。
技術的に洗練されたIPアーキテクチャであっても、ボーダールーターの互換性、共有認証情報、ネットワークトポロジー、そして実際の実装サポートに依存します。
Thread 1.4で何が変わるのでしょうか?
Thread 1.4によって、エコシステムは統合ネットワークという考え方に一歩近づきます。
Thread Groupは、主要な改善点の1つを1つのメッシュネットワークをより簡単に実現することと説明しています。
異なるエコシステムの更新済みデバイスやボーダールーターが、不要に別のメッシュを作成するのではなく、既存のThreadネットワークを認識して参加できるようにすることが目標です。
Thread 1.4では、次の点も追加または改善されています。
- クラウド接続への標準化された道筋、
- インフラストラクチャ上のThread、
- ネットワーク診断とトラブルシューティングの可視化、
- エコシステムをまたぐネットワークの統合、
- そしてコミッショニングの改善。
これにより、ThreadLinkをより広い文脈で捉えられます。
初期のTHREAD
低消費電力IPv6メッシュ
|
Matterが主流になる
コンシューマー向けアプリケーション
THREAD 1.4
より優れたネットワーク収束
より優れたボーダールーターインフラ
クラウド経路
診断
|
v
THREADLINKの構想
Matter
ベンダーAPI
クラウド
P2P
|
同じ低消費電力IP転送
したがって、ThreadLinkはすべてのベンダーが同じアプローチを採用する証拠ではありません。
しかし、これはThreadのネットワークアーキテクチャが常に可能にしてきた、アプリケーションの多様性の具体例です。
スマートホームのすべての自動化をホームサーバー経由にすべきか?
いいえ。レジリエントなシステムでは、アクションの複雑さと重要性に応じてロジックを分散できます。
| 層 | 適切な責任 |
|---|---|
| デバイス | 即時のローカル動作とフォールバック |
| Threadメッシュ | 低消費電力のローカルIP転送とピア通信 |
| ボーダールーター | Threadとより広いLAN間のルーティング |
| Home Assistant | デバイス間およびプロトコル間のオーケストレーション |
| ホームサーバー | 永続サービス、自動化、履歴、ポリシー |
| NAS | バックアップと永続データ |
| クラウド | オプションのリモートサービスとベンダー機能 |
単純なインターロックでは、必ずしもサーバーを往復する必要はありません。
家全体のエネルギー自動化なら、おそらく必要です。
この分離により、1つの層の障害がすべてのローカル機能を自動的に失わせることがなくなるため、ネットワークのレジリエンスが向上します。また、実際のHome Assistantの性能経路には、Home Assistantを実行するCPUだけでなく、無線、ネットワーク、ブローカー、対象デバイス、ストレージが含まれる理由も説明できます。
ThreadLinkによってホームサーバーの重要性は下がるのか?
これにより、ホームサーバーはプロトコルゲートウェイとしての重要性が下がる一方、オーケストレーション層としての役割がより明確になる可能性があります。
従来のスマートホームでは、多くのデバイスネットワークが家庭内のIPネットワークに直接参加できなかったため、ブリッジが増えていきました。
旧モデル
Zigbeeデバイス ── ベンダーハブ ──┐
|
その他のデバイス ─── ゲートウェイ ─────┼── ホームサーバー
|
Wi-Fiデバイス ─────────────────┘
よりIP指向のアーキテクチャは、次のように異なる構成になります。
デバイス層
Threadデバイス
Wi-Fiデバイス
Ethernetデバイス
|
v
IPネットワーク層
|
v
制御層
Home Assistant
|
+-- 自動化
+-- 状態
+-- 履歴
+-- ポリシー
+-- ダッシュボード
+-- プロトコル横断のロジック
|
v
データ層
バックアップ
NAS
永続ストレージ
サーバーは、存在意義を示すためにすべてのパケットを経由させる必要がなくなりました。
その価値は、より大きな全体像を維持することからますます生まれます。
- どのデバイスが存在するか、
- それらがどの状態にあるか、
- 無関係なシステムがどのように連携するか、
- 昨日何が起きたか、
- どの自動化を実行するか、
- サービスが失敗したときにどうするか、
- そして構成と履歴がどのように保護されるか。
これらの役割には、それぞれ異なるストレージ要件と復旧要件があります。このアーキテクチャでは、Home Assistantの永続データを一時的なランタイム状態から分離することで、データ層の保護がはるかに容易になります。
Threadによってプロトコル変換の必要性は減りますが、ホームオートメーションソフトウェアが不要になるわけではありません。
また、Home Assistantに突然高性能なハードウェアが必要になるという意味でもありません。現在のHome Assistantサーバーのハードウェア要件は、通常の自動化であれば依然として控えめです。より大きなサーバー負荷を生むのは、通常、カメラ、長期履歴、ローカル音声、データベース、追加サービスです。
これらのサービスのいくつかを同時に稼働させる予定なら、スマートホームサーバーの容量はThreadデバイスの台数ではなく、サービス全体の構成に基づいて決めるべきです。
Shelly Gen4の所有者はWi-FiからThreadLinkに切り替えるべきか?
その推奨をするにはまだ早すぎます。
ファームウェアはまだ一般提供に至っておらず、最終的な対象デバイス一覧が重要です。また、既存のThreadネットワークやボーダールーターとの実際の相互運用性についても、デモ以外の環境で検証する必要があります。
ThreadLinkが利用可能になったら、Gen4の所有者は次の点を評価すべきです:
- 使用しているShellyデバイスの正確なモデルが対象になっているかどうか、
- 適切なThreadボーダールーターがすでにあるかどうか、
- 自宅のThreadネットワークが統合されているか、分断されているか、
- 必要なShelly機能が新しいHome Assistantモジュール経由で動作するかどうか、
- クラウドアクセスが必要かどうか、
- デバイス間の直接的なロジックが役立つかどうか、
- また、既存のWi-Fi環境がすでに安定して動作しているかどうか。
| 状況 | ThreadLinkの見通し |
|---|---|
| Wi-Fi対応のShellyデバイスはすでに問題なく動作している | 急いで切り替える理由はない |
| リレーを高密度に設置している | 興味深い可能性があります |
| Matterに加えて、より高度なShelly機能が必要 | 注目すべき有力なユースケース |
| Wi-Fi停止時もローカルP2Pを利用したい | 大きなアーキテクチャ上の利点 |
| Threadボーダールーターがない | LAN/クラウドアクセスには追加のインフラが必要 |
| 複数の分断されたThreadネットワーク | まずトポロジーを理解する必要があります |
| Gen4の非対応モデル | ThreadLinkは利用できない可能性があります |
したがって、2026年時点での正しい判断は、発表だけを根拠に稼働中の環境を移行するのではなく、実装の進展を見守ることです。
ThreadはスマートホームのローカルIPネットワークになりつつあるのか?
Threadがスマートホーム内の唯一のローカルネットワークになる可能性は低いでしょう。むしろ、そのネットワークの低消費電力IPエッジになる可能性のほうが高いと考えられます。
Ethernetは、サーバー、NASデバイス、固定設置の大容量帯域システムにとって、今後も自然な伝送手段であり続けます。
Wi-Fiは、スマートフォン、ノートパソコン、カメラ、ディスプレイなど、大幅に高い帯域幅を必要とする機器にとって、今後も自然な無線ネットワークであり続けます。
Threadは低消費電力のエッジに適しています。
- センサー、
- リレー、
- スイッチ、
- ロック、
- 制御、
- 比較的少量のデータをやり取りするその他のデバイス
Shelly ThreadLinkが興味深いのは、そのエッジを単一アプリケーション専用のサイロとして扱わなくなる点です。
Matterは、標準化されたエコシステム制御を提供できます。
Shelly RPCは、より高度なベンダー機能を提供できます。
ピア通信によって、単純な操作をローカルに保てます。
ボーダールーターはメッシュをより広いLANに接続できます。
Home Assistantはプロトコルをまたいでオーケストレーションできます。
また、エンドポイント自体をWi-Fiに接続しなくても、クラウド接続を任意にできます。
このオーケストレーション層を専用のローカルシステム上で運用したいユーザーにとって、ZimaBoard 2スマートホームは一例です。拡張可能な常時稼働サーバー上にコントローラーを置き、Threadボーダールーターとエンドポイント無線をネットワークの別々の構成要素として維持できます。
したがって、スマートホームの未来は、Thread、Wi-Fi、Ethernetのどれを選ぶかというよりも、同じIPアーキテクチャ内でそれぞれに役割を与えることになるかもしれません。
それがThreadLinkのより大きな構想です。
ThreadはこれまでもIPネットワークでした。
Shellyは、単にそれをそのように使い始めるだけです。
FAQ:Shelly ThreadLinkとThreadスマートホームネットワーク
Shelly ThreadLinkとは何ですか?
ThreadLinkは、対象となるShelly Gen4デバイス向けに発表されたオプトイン方式のファームウェアです。Shellyによると、デバイスのThread無線を使い、同じ低消費電力のIPメッシュ上でMatter、Shelly RPC/APIトラフィック、クラウド接続、デバイス間の直接通信を伝送します。
Shelly ThreadLinkは現在利用できますか?
いいえ。Shellyは2026年9月3日にThreadLinkを発表し、対象となるGen4デバイス向けに、無料でオプトインできるファームウェアを約3か月後にリリースする予定です。
すべてのShelly Gen4デバイスがThreadLinkに対応しますか?
Shellyがアップデートを約束しているのは、対象となるGen4デバイスのみです。完全な最終互換性リストは、ファームウェアが利用可能になった時点で確認してください。
ThreadLinkによって、ThreadはIPネットワークになりますか?
いいえ。ThreadはこれまでもIPv6、6LoWPAN、IEEE 802.15.4を基盤としてきました。ThreadLinkは、既存のIPネットワーク上でMatter以外も動作させることで、Shellyがそのネットワークをどのように利用するかを変えるものです。
MatterはThreadと同じものですか?
いいえ。Matterはアプリケーションレベルのスマートホーム制御規格です。Threadは、Matterやその他の互換性のあるアプリケーションプロトコルを運べる、低消費電力のIPv6メッシュネットワークです。
MatterなしでThreadを利用できますか?
はい。Threadはアプリケーション層に依存しません。現在、一般消費者向けのThread製品はMatterと強く結び付いていますが、Thread自体は他のIPベースのアプリケーションプロトコルにも対応できます。
ThreadLinkデバイスはWi-Fiなしで動作しますか?
Shellyによると、ThreadLinkデバイスは、エンドポイント自体がWi-Fiに接続しなくても、ThreadをMatter、ローカルAPI通信、ピアツーピア自動化に利用でき、Threadボーダールーターを介してクラウドにも接続できます。
ThreadLinkはインターネットなしで動作しますか?
Shellyによると、インターネット接続やWi-Fiネットワークが停止しても、デバイス間の直接的なシーン、インターロック、自動化はThreadメッシュ内でローカルに動作できます。
ThreadLinkにはThreadボーダールーターが必要ですか?
ThreadLinkデバイスが家庭内の広域LAN、アプリ、Home Assistant、クラウドサービスと通信するには、ボーダールーターが必要です。Shellyによると、デバイス間のシーンはThreadメッシュ内だけで動作できます。
ThreadLinkはHome Assistantに取って代わりますか?
いいえ。単純なデバイス間の関係では、直接的なピアツーピア処理によってサーバーが不要になる一方、Home Assistantは、異なるプロトコル間の自動化、履歴、ダッシュボード、ポリシー、スケジュール、家全体のオーケストレーションに引き続き役立ちます。
ThreadはWi-Fiに取って代わりますか?
おそらく置き換わりません。Threadは、低消費電力で比較的低帯域幅のIoTデバイス向けに設計されています。カメラ、ディスプレイ、スマートフォン、コンピューターなど、より高帯域幅を必要とする製品には、依然としてWi-Fiの方が適しています。
Threadボーダールーターとスマートホームハブの違いは何ですか?
Threadボーダールーターは主に、Threadメッシュと、より広範なIPネットワークの間でIPv6トラフィックをルーティングします。従来のハブやブリッジは、非IPデバイスネットワークとIPベースのLANまたはアプリケーションの間で変換を行うことが一般的です。
家庭内に複数のThreadネットワークを構築できますか?
はい。現在の家庭には、異なる認証情報を持つApple、Google、Home Assistantなどの個別のThreadネットワークが存在する場合があります。Thread 1.4は、既存の1つのメッシュへの統合を容易にすることを目的としていますが、実際の実装はデバイスやエコシステムの対応状況に左右されます。
Thread 1.4で何が変わりますか?
Thread 1.4では、エコシステム間のネットワーク参加、ボーダールーターのインフラストラクチャ、クラウド接続、診断、コミッショニング、信頼性、そしてより大規模で統合されたThreadメッシュの維持機能が向上しています。
ThreadLinkはホームサーバーにとってなぜ重要ですか?
ホームサーバーは、独自デバイスネットワークのプロトコル変換に注力するよりも、オーケストレーション、状態、履歴、ポリシー、システム間の自動化、永続的なデータの管理に集中でき、基盤となるIPトランスポートはThread、Wi-Fi、Ethernetが担うということです。
サポートとヒント
もっと読む

Home AssistantはWi-Fiでは動作するが、イーサネットまたはVPNでは接続できない
各ネットワーク経路を個別にテストし、インターフェースとルーティングの状態を確認して、直接IP接続と検出による接続を区別したうえで、失敗したレイヤーだけを修復します。

保護されていないデータを残さずにHome Assistantを廃止する方法
交換またはアーカイブを証明し、すべての信頼パスを無効化し、データを保持する各デバイスをサニタイズして、文書化された保護済みのリカバリコピーのみを保持する。

ホームサーバー上のHome Assistantで自動更新を利用すべきですか?
家庭への影響、互換性リスク、観察期間、復旧準備の状況を考慮して、手動更新、通知のみ、または段階的な自動更新を選択してください。

