Chapter 01
Matter とは何か — なぜ生まれ、何を解決したのか
この章がなぜ必要なのか——「何のための仕様か」を知らないと、仕様が理不尽に見える.
Matter の仕様は正直に言って複雑である。 「なぜ証明書が 3 種類もあるのか」「なぜ Endpoint と Cluster に分かれているのか」 「なぜコミッショニングがあんなに長いのか」—— どれも、解決しようとした問題を知れば必然だと分かる。
この章では技術の話をほとんどしない。その代わり、 Matter が生まれた背景と設計目標を押さえる。ここが以降のすべての判断基準になる。
1. Matter 以前に何が起きていたか
組み合わせ爆発
スマートホーム機器のメーカーが \(n\) 社、エコシステム（Apple Home / Google Home / Alexa / SmartThings…）が \(m\) 個あるとする。 すべての機器がすべてのエコシステムで使えるようにするには、
メーカーは 4 つのエコシステム向けに 4 通りの実装・認証・保守を抱える。 エコシステム側も、新しいメーカーが出るたびに個別対応が要る。
共通の言語が 1 つあれば \(n + m\) で済む。 Matter が狙ったのはこれである。
具体的に何が困っていたか
| 問題 | 内容 |
|---|---|
| 買う前に調べる必要がある | 「この電球は自分のスマートスピーカーで使えるか」を毎回確認する |
| アプリが機器ごとに増える | メーカー別にアプリをインストールする羽目になる |
| クラウド必須 | 電球を点けるのに、家の中の通信がインターネットを往復する |
| サービス終了で文鎮化 | メーカーがクラウドを止めると機器が動かなくなる |
| プロトコルの断片化 | Zigbee・Z-Wave・独自 RF・Wi-Fi クラウド API が乱立 |
クラウド依存の実害. 実際に、メーカーの事業撤退やサーバ停止により、 正常に動作する機器が一斉に使えなくなる事例が繰り返し起きてきた。 「ネットが切れたら家の照明が点かない」という状態は、 スマートホームの普及を阻む最大の心理的障壁でもあった。
2. Matter の設計目標
CSA が掲げた目標は 5 つである。それぞれが仕様の具体的な部分に直結している。
| 目標 | 仕様への現れ |
|---|---|
| 相互運用性 (interoperability) | 共通のデータモデル（Cluster）と厳格な認証プログラム |
| ローカル制御 | IP 直接通信。クラウドは必須ではない |
| セキュリティ | 全通信を暗号化。デバイス認証を必須化（DAC） |
| 簡単なセットアップ | QR コード 1 枚でどのエコシステムからでも設定できる |
| マルチアドミン | 1 台の機器が複数のエコシステムに同時所属できる |
(a) ローカル制御が意味すること
Matter の通信は家庭内の IP ネットワーク上で完結する。 スマホから電球を点けるとき、パケットはルータを越えない。
| 効果 | 内容 |
|---|---|
| 低レイテンシ | クラウド往復（数百 ms）が不要。数十 ms で応答 |
| インターネット断でも動く | 家の中の操作は影響を受けない |
| プライバシー | 操作ログが外部に出ない（エコシステム側の実装次第だが、原理的に可能） |
| サービス終了に強い | ハブとアプリがあれば動き続ける |
クラウドが不要なのではなく、必須ではない. 外出先からの操作、音声アシスタント、複雑な自動化などはクラウドを使う。 Matter が保証するのは「家の中の基本操作はローカルで完結する」という一線である。
(b) マルチアドミンが意味すること
1 台の電球が、Apple Home と Google Home の両方に同時に登録できる。 家族それぞれが違うエコシステムを使っていても、同じ機器を共有できる。
これは技術的には「1 つの Node が複数の Fabric に所属する」という形で実現されている（02 章・14 章）。 機器側は Fabric ごとに別々の証明書と鍵を持ち、アクセス制御も Fabric ごとに独立する。
これが Matter で最も難易度が高い部分の 1 つである. 「複数の管理者が、互いを信頼せずに、同じ機器を同時に管理する」—— これを安全に成立させるために、14 章で見る Fabric と ACL の仕組みが必要になった。
3. Matter は何であって、何でないか
Matter であるもの
| 領域 | 内容 |
|---|---|
| アプリケーション層 | データモデル（何を表現するか）とインタラクション（どうやりとりするか） |
| セキュリティ層 | 認証・鍵交換・暗号化・アクセス制御 |
| コミッショニング | 機器をネットワークに参加させる手順 |
| 認証プログラム | 相互運用性を担保するテストと認定 |
Matter でないもの
| 誤解 | 実際 |
|---|---|
| 「新しい無線規格」 | 違う。 既存の Wi-Fi / Thread / Ethernet の上に載るアプリケーション層 |
| 「Thread と同じもの」 | 違う。 Thread は下位のネットワーク層。Matter は Thread 上でも Wi-Fi 上でも動く |
| 「Zigbee の後継」 | 半分正しい。データモデルは Zigbee Cluster Library (ZCL) を強く受け継いでいるが、下位層はまったく別 |
| 「クラウドサービス」 | 違う。 ローカルのプロトコル仕様 |
| 「無料で誰でも製品化できる」 | 仕様書は無償だが、製品として名乗るには CSA 会員資格と認証が要る（22 章） |
「Matter は Thread ではない」を最初に腹落ちさせること. この混同は極めて多い。関係を一言で言えば:
- Thread = 低消費電力の IPv6 メッシュネットワーク（何を運ぶかは問わない）
- Matter = その上を流れるアプリケーションの言葉（下がどのネットワークかは問わない）
Wi-Fi と HTTP の関係に近い。HTTP は Wi-Fi でも有線でも動く。Matter も同じである。
4. 歴史
| 時期 | 出来事 |
|---|---|
| 2019/12 | Amazon・Apple・Google・Zigbee Alliance が Project CHIP（Connected Home over IP）を発表 |
| 2021/05 | Zigbee Alliance が Connectivity Standards Alliance (CSA) に改称。CHIP を Matter に改称 |
| 2022/10 | Matter 1.0 公開、認証プログラム開始 |
| 2023/05 | 1.1（安定性・ICD の改善） |
| 2023/10 | 1.2（大型家電 9 種を追加） |
| 2024/05 | 1.3（エネルギー管理・水管理・調理家電） |
| 2024/11 | 1.4（エネルギー機器の拡充、Enhanced Multi-Admin、Thread 認証情報の共有） |
| 以降 | 継続的にリリース。詳細は 24 章 |
オープンソースで開発されている. 仕様策定と並行して、リファレンス実装 connectedhomeip（通称 Matter SDK）が GitHub 上で Apache 2.0 ライセンスで公開されている。 仕様の議論も Issue / PR として可視化されている部分が多い。 「仕様書で分からなければソースを読む」が実際に成立するのは、開発者にとって大きい。
5. 開発者から見た 4 つの立場
このシリーズは以下の 4 つをすべて扱う。自分がどれなのかを意識して読むとよい。
(a) デバイス側（最も分量が多い）
Matter 対応機器そのものを作る。必要になるもの:
- SoC の選定（Wi-Fi か Thread か、メモリとフラッシュの余裕）
- SDK のビルドとポーティング
- クラスタの実装（ZAP → 生成コード → コールバック）
- Factory Data（DAC・鍵・VID/PID）の書き込み
- 省電力設計（電池駆動なら ICD）
- OTA の実装
- CSA 認証の取得
(b) コントローラ／アプリ側
機器を操作する側。スマホアプリ、ハブ、自動化サービスなど。
- デバイス発見とコミッショニング
- 属性の読み書き・コマンド実行
- サブスクリプションによる状態同期
- Fabric 管理（追加・削除・マルチアドミン）
(c) ブリッジ
既存の Zigbee / Z-Wave / 独自プロトコル機器を、Matter の機器として見せる。
- Aggregator エンドポイントと動的エンドポイント
- 既存機器の機能を Matter クラスタにマッピングする設計
- 到達不能時の扱い
(d) 認証・製品化
製品として出荷するまでのプロセス。
- CSA 会員資格と VID の取得
- 証明書（PAA/PAI/DAC）の調達または自社構築
- 量産ラインでの鍵注入
- テストハーネスによる検証と認証取得
6. 何が難しいのか（先回りの警告）
難易度は「広さ」にある. 1 つ 1 つの技術は既知のものである。難しいのは、 ネットワーク・暗号・組み込み・ビルドシステム・認証プロセスのすべてに同時に対処することである。
典型的な詰まりどころ:
場面 よくある症状 最初のビルド 依存関係が巨大で通らない（15 章） コミッショニング 「見つからない」— 原因が IPv6 かも mDNS かも証明書かも分からない（13 章・21 章） マルチアドミン 1 つ目のエコシステムでは動くが 2 つ目で失敗（14 章） 電池駆動 想定の 1/10 しか電池が持たない（17 章） 認証 テストハーネスで大量に落ちる（22 章） これらはすべて事前に知っていれば避けられる。だからこのシリーズは、 各章に「落とし穴」を明示的に置いている。
7. まとめ
- Matter は \(n\times m\) の組み合わせ爆発を \(n+m\) にするための共通言語である。
- アプリケーション層の仕様であって、無線規格ではない。Thread とは別物。
- 設計目標は相互運用性・ローカル制御・セキュリティ・簡単なセットアップ・マルチアドミンの 5 つ。 仕様の複雑さは、ほぼすべてこの 5 つのどれかに由来する。
- 仕様書は無償公開、リファレンス実装もオープンソース。しかし製品化には CSA 認証が要る。
- 難しさは個々の技術ではなく、扱う範囲の広さにある。