Chapter 24
バージョンの進化とエコシステムの実情
この章がなぜ必要なのか——Matter は「完成した標準」ではない.
Matter は年 2 回程度のペースでリリースを重ねている。 対応デバイスタイプが増え、既存の仕様も改良されている。
どのバージョンで作るかは、認証・エコシステム対応・製品カテゴリの すべてに影響する重要な判断である。
そして仕様に書かれていても、エコシステムが対応していなければ使えない。 この「仕様と実装のギャップ」を理解しておくことが実務では極めて重要である。
注意: この章の内容は時間とともに古くなる. リリース状況・エコシステムの対応状況は変化するので、 必ず CSA の公式情報と各エコシステムのドキュメントで最新を確認すること。 ここに書くのは「どういう軸で進化しているか」という見取り図である。
この章で使う既出の用語（定義は各リンク先）. Matter（01 章 3 節）、アプリケーション層（01 章 3 節）、コミッショニング（01 章 3 節）、セキュリティ（01 章 2 節）、ネットワーク（01 章 3 節）、相互運用性（01 章 2 節）、認証プログラム（01 章 3 節）、ACL（02 章 4 節）、Cluster（02 章 2 節）、Endpoint（02 章 2 節）、IPv6（02 章 1 節）、MRP（02 章 1 節）、Router（04 章 2 節）、Wi-Fi（04 章 9 節）、BLE（05 章 1 節）、必要（05 章 5 節）、DNS-SD（06 章 1 節）、PASE（06 章 4 節）、AttributeList（07 章 2 節）、FeatureMap（07 章 2 節）、Descriptor（08 章 1 節）、Invoke（09 章 1 節）、Read（09 章 1 節）、Subscribe（09 章 1 節）、Write（09 章 1 節）、Manage（11 章 8 節）、CSA（12 章 3 節）、DAC（12 章 11 節）、ZAP（16 章 1 節）、LIT（17 章 3 節）、不要（19 章 1 節）、Apple（20 章 1 節）、仕様書（21 章 8 節）
1. バージョンの歩み
| 版 | 時期 | 主な内容 |
|---|---|---|
| 1.0 | 2022/10 | 最初の仕様。照明、プラグ、スイッチ、センサー、ドアロック、サーモスタット、ブラインド、メディア、ブリッジ |
| 1.1 | 2023/05 | 主に安定性と明確化。ICD の改善。相互運用性の問題修正 |
| 1.2 | 2023/10 | 大型家電 9 種を追加: 冷蔵庫、ルームエアコン、食洗機、洗濯機、ロボット掃除機、煙/CO 警報器、空気質センサー、空気清浄機、ファン |
| 1.3 | 2024/05 | エネルギー管理（EV 充電器、電力測定）、水管理（漏水検知、バルブ）、調理家電（電子レンジ、オーブン、コンロ、レンジフード、乾燥機）、シーンの改良 |
| 1.4 | 2024/11 | エネルギー機器の拡充（太陽光、蓄電池、ヒートポンプ、給湯器）、Enhanced Multi-Admin、Thread 認証情報の共有、NFC コミッショニング |
| 1.4.x | 2025 | 保守リリース。相互運用性の改善 |
| 1.5 以降 | — | カメラ／映像、開閉制御の拡充など、適用領域の拡大が続いている |
1.0 は「照明とセンサーの標準」だった. そこから家全体の設備（家電 → エネルギー → 水 → 調理）へと 対象領域を広げてきたのが大きな流れである。
エネルギー管理への注力が近年の特徴である。 EV 充電、太陽光、蓄電池、ヒートポンプ—— 電力需給の調整（デマンドレスポンス）に Matter を使う方向性が明確になっている。
2. 進化の 3 つの軸
(a) 対象デバイスの拡大
1.0: 照明・スイッチ・センサー・ロック・サーモスタット
↓
1.2: 大型白物家電
↓
1.3: エネルギー・水・調理
↓
1.4: エネルギー機器の本格対応
↓
以降: 映像、開閉制御など自分の製品カテゴリがどの版で追加されたかを必ず確認すること. ロボット掃除機を 1.0 で認証することはできない（22 章）。
(b) 既存機能の改良
| 領域 | 改良の方向 |
|---|---|
| ICD（間欠動作） | 電池機器の実用性向上。LIT の整備 |
| マルチアドミン | QR の手動読み取りを不要にする方向 |
| Thread 連携 | 認証情報の共有、Border Router の扱い |
| シーン | Scenes Management として整理 |
| 診断 | 障害解析のための情報を拡充 |
(c) コミッショニングの改善
| 手段 | 内容 |
|---|---|
| QR コード | 基本 |
| 手動コード | QR が読めないとき |
| NFC | かざすだけ（1.4 以降） |
| Wi-Fi PAF | Wi-Fi Aware を使った経路 |
| Enhanced Multi-Admin | エコシステム間の直接連携 |
セットアップ体験の改善が継続的なテーマである. 「箱を開けて 30 秒で使える」が理想であり、 そこに向けた改良が毎リリース入っている。
3. 後方互換性
Matter は後方互換性を重視して設計されている.
- 新しい版のコントローラは、古い版の機器を扱える
- 古い版のコントローラは、新しい機器の知っている部分だけを扱える
ClusterRevisionとFeatureMapで差異を吸収する（07 章）- TLV の「知らないタグは読み飛ばす」性質が支えている（17 章）
実際には注意が要る.
- 新しいデバイスタイプは、古いコントローラにはまったく認識されない
- Provisional な機能は変わりうる（08 章）
- エコシステムの実装バグで、想定どおりにいかないこともある
4. 仕様と実装のギャップ
これが実務で最も重要な認識である。
CSA の仕様に定義されている
≠
CSA の認証プログラムでテストされる
≠
各エコシステムが対応している
≠
実際にユーザーの家で動く| 段階 | ギャップの原因 |
|---|---|
| 仕様 → 認証 | Provisional な機能は認証対象外 |
| 認証 → エコシステム | 各社が独自に対応範囲を決めている |
| エコシステム → 実機 | ハブのファームウェア版、地域差、既知の不具合 |
具体例:
- 仕様には定義されているデバイスタイプが、あるエコシステムでは「その他の機器」としか表示されない
- ある属性はエコシステム A では UI に出るが、B では出ない
- 独自クラスタは基本的にどこでも扱われない
- 新しいデバイスタイプは、エコシステムの対応まで数か月〜年単位かかることがある
だから 22 章で「出荷前に各エコシステムで実機確認」を必須としている。
対応状況の確認方法
| 方法 | 内容 |
|---|---|
| 各社の開発者ドキュメント | 対応デバイスタイプ・クラスタの一覧が公開されている |
| 実機で試す | 最も確実。ターゲット全社のハブを用意する |
| コミュニティ | Home Assistant のフォーラムなどに実情報が集まる |
| 各社の開発者プログラム | 早期アクセス、技術サポート |
ターゲットとする全エコシステムのハブを、開発環境に揃えること. Apple TV / HomePod、Nest Hub、Echo、SmartThings Hub。 コストはかかるが、出荷後に発覚するより圧倒的に安い。
5. バージョン選択の判断
| 状況 | 推奨 |
|---|---|
| 照明・センサーなど基本的な機器 | 枯れた版で十分。相互運用性が最優先 |
| 1.2 以降で追加されたカテゴリ | 該当する版以降が必須 |
| エネルギー管理 | 1.3 / 1.4 以降 |
| 新機能を売りにする | 最新版。ただしエコシステム対応を確認 |
| 既存製品の追加対応 | 既存製品と揃える |
判断の軸:
- 自分のデバイスタイプが定義されている最も古い版が下限
- ターゲットエコシステムが対応している版が現実的な上限
- その範囲で、SDK の安定したタグを選ぶ（15 章）
6. 仕様の追随戦略
出荷後、新しい版が出たときにどうするか。
| 戦略 | 内容 | 向くケース |
|---|---|---|
| 追随しない | 出荷時の版のまま | 機能追加の必要がない機器 |
| OTA で追随 | ファームウェア更新で新版に対応 | 長期使用される機器 |
| 再認証 | 新しい版で認証を取り直す | 新機能を追加したい |
「追随しない」も正当な選択である. Matter は後方互換なので、1.0 で認証した電球は 新しいコントローラからも使い続けられる。
追随のコスト
| 項目 | 内容 |
|---|---|
| SDK の更新 | ビルドが通らなくなることがある |
| 再テスト | Test Harness の全項目 |
| 再認証 | 費用と時間（22 章） |
| OTA 配信 | 全出荷済み機器への配布 |
| 互換性 | 古いコントローラとの動作確認 |
安易な追随は避けること. 「新しい版が出たから上げる」ではなく、 具体的な必要性（新機能、脆弱性修正、不具合対応）があるときに上げる。
7. 情報の追い方
| 情報源 | 内容 |
|---|---|
| CSA の公式サイト | 仕様書、リリース情報、認証製品リスト |
| connectedhomeip の GitHub | リリースタグ、Issue、PR。仕様の議論も見える |
| 各エコシステムの開発者ブログ | 対応状況の発表 |
| CSA のメンバー向けリソース | 策定中の情報（会員のみ） |
| コミュニティ | Home Assistant フォーラム、各種 Discord/Slack |
GitHub のリリースノートは実務的に最も有用である. 「何が変わったか」が具体的に書かれている。 SDK を上げる前に必ず読むこと。
8. 今後を見据えた設計
仕様が変わり続けることを前提に設計する.
指針 内容 OTA を必ず実装する 追随の唯一の手段 Flash に余裕を持つ 新機能でコードが増える SDK のバージョンを固定する 意図しない変更を防ぐ 標準クラスタを使う 独自拡張は将来の標準と衝突しうる Provisional を避ける 変わりうる 抽象化しておく プラットフォーム層とアプリ層を分離しておくと移行が楽 最も重要なのは OTA である。 出荷後に何もできない製品は、仕様が動く世界では致命的なリスクを抱える。
9. シリーズ全体のまとめ
24 章を通じて積み上げてきたものを俯瞰する。
| 部 | 中心概念 |
|---|---|
| I（01-03） | Matter は IPv6 上のアプリケーション層。Thread とは別物 |
| II（04-06） | Thread / Wi-Fi / BLE の使い分け。DNS-SD で見つけ、MRP で届ける |
| III（07-10） | Endpoint / Cluster / Attribute。Read/Write/Invoke/Subscribe |
| IV（11-14） | DAC で製品を証明し、PASE で参加し、CASE で話し、ACL で守る |
| V（15-19） | SDK、ZAP、Factory Data、省電力、OTA、ブリッジ |
| VI（20-24） | コントローラ、デバッグ、認証、落とし穴、進化 |
全編を貫く 5 つの糸
- IPv6 がすべての土台 — 下が何であれ、IPv6 の上は同じ。障害切り分けもここから。
- 自己記述性 — Descriptor / FeatureMap / AttributeList。 だから事前知識なしに相互運用できる。宣言と実装を一致させることが実装者の責務。
- 多層防御 — Thread 鍵、Matter セッション鍵、ACL。1 つ破られても全部は破られない。
- 複数 Fabric が前提 — マルチアドミンは Matter の存在理由。 1 Fabric でしか動かない実装は半分捨てている。
- 出荷後も動き続ける — 仕様は更新される。OTA が実装の必須要件になる。
最後に
Matter 開発の難しさは「広さ」にある（01 章で述べたとおり）。
ネットワーク・暗号・組み込み・ビルドシステム・認証プロセス。 どれか 1 つの専門家では作れない。
だが逆に言えば、各分野で既知の技術しか使われていない。 独自の暗号もなく、独自のネットワークもない。 地図さえあれば、順に登れる。
このシリーズがその地図になれば幸いである。 そして繰り返しになるが——最終的な正は仕様書と SDK のソースである。 ここから先は、それらを直接読んでほしい。
10. まとめ
- Matter は年 2 回程度のペースで進化している。1.0 の照明・センサーから、 家電・エネルギー・水・調理・映像へと対象を広げてきた。
- 進化の軸は (a) 対象デバイスの拡大、(b) 既存機能の改良、(c) セットアップの改善。
- 後方互換性は重視されているが、新しいデバイスタイプは古いコントローラには見えない。
- 仕様 ≠ 認証 ≠ エコシステム対応 ≠ 実機動作。 このギャップの認識が実務で最も重要。出荷前に各社の実機で確認する。
- バージョン選択は「デバイスタイプの下限」と「エコシステム対応の上限」で挟む。
- 追随しないのも正当な選択。ただしセキュリティ修正は別。OTA は必須。
- 情報は CSA 公式と GitHub のリリースノートを追う。