Chapter 02
アーキテクチャと用語の地図
この章がなぜ必要なのか——用語を取り違えると、以降がすべて崩れる.
Matter には Fabric・Node・Endpoint・Cluster・Attribute・Device Type と、 似たような階層の言葉が並ぶ。しかもどれも日常語と意味がずれている。
ここで一度、全部の言葉を 1 枚の地図に配置する。 以降の章はこの地図の上を歩くだけになる。迷ったらここに戻ってきてほしい。
1. レイヤ構造
Matter は下から順にこう積まれている。
| 層 | 内容 | 章 |
|---|---|---|
| アプリケーション | 機器のロジック（電球を点ける、温度を測る） | — |
| データモデル | Endpoint / Cluster / Attribute / Command / Event | 07〜08 |
| インタラクションモデル | Read / Write / Invoke / Subscribe | 09〜10 |
| アクション（フレーミング） | 上記をメッセージに変換。TLV でシリアライズ | 17 |
| セキュリティ | セッション鍵で暗号化・認証（AES-CCM） | 11〜14 |
| メッセージング | Matter メッセージ形式、MRP による信頼性 | 06 |
| トランスポート | UDP（主）/ TCP / BTP（BLE 上） | 06 |
| ネットワーク | IPv6（必須） | 03 |
| リンク | Wi-Fi / Ethernet / Thread (802.15.4) / BLE | 04〜05 |
注目すべき境界が 2 つある.
- IPv6 のところで一本化されている. 下が Wi-Fi でも Thread でも、 IPv6 より上はまったく同じコードが動く。これが「ネットワークを問わない」の実体である。
- BLE だけが例外. BLE は IP を持たないので、BTP という専用のトランスポートで Matter メッセージを運ぶ。そしてコミッショニング時にしか使わない（05 章）。
2. 用語の地図
Fabric（管理ドメイン。例: あなたの Apple Home）
└── Node（1 台の機器。Fabric 内で一意な Node ID を持つ）
├── Endpoint 0 ── Root Node（必ず存在。ユーティリティクラスタ）
│ ├── Cluster: Basic Information (0x0028)
│ ├── Cluster: Operational Credentials (0x003E)
│ ├── Cluster: Access Control (0x001F)
│ └── Cluster: Descriptor (0x001D)
└── Endpoint 1 ── Device Type: Dimmable Light (0x0101)
├── Cluster: On/Off (0x0006)
│ ├── Attribute: OnOff (0x0000) = true/false
│ └── Command: On / Off / Toggle
├── Cluster: Level Control (0x0008)
│ ├── Attribute: CurrentLevel (0x0000) = 0..254
│ └── Command: MoveToLevel / Move / Step / Stop
└── Cluster: Identify (0x0003)各用語の定義
| 用語 | 定義 | たとえるなら |
|---|---|---|
| Fabric | 共通の信頼の根（Root CA）を共有する、Node の集合 | 「会社」 |
| Node | ネットワーク上で個別にアドレス可能な 1 つの機器 | 「社員」 |
| Endpoint | Node の中の 1 つの機能単位 | 「その社員が兼任している役職」 |
| Cluster | 関連する Attribute と Command のまとまり | 「役職ごとの職務」 |
| Attribute | 状態を表す値。読み書きできる | 「状態を示す掲示板」 |
| Command | 動作を起こす要求 | 「指示」 |
| Event | 過去に起きた出来事の記録 | 「日誌」 |
| Device Type | Endpoint が満たすべきクラスタの組み合わせの規定 | 「職務記述書」 |
具体例で確認する
電源タップ（3 口、それぞれ独立に ON/OFF）:
| Endpoint | Device Type | 主なクラスタ |
|---|---|---|
| 0 | Root Node (0x0016) | Basic Information, Descriptor, Operational Credentials, … |
| 1 | On/Off Plug-in Unit (0x010A) | Identify, Groups, On/Off |
| 2 | On/Off Plug-in Unit (0x010A) | Identify, Groups, On/Off |
| 3 | On/Off Plug-in Unit (0x010A) | Identify, Groups, On/Off |
1 台の Node に 3 つの独立した口がある——これが Endpoint の存在理由である。 「Node = 機器」「Endpoint = 機器の中の独立した機能」と覚える。
Endpoint 0 は特別である. 必ず存在し、Device Type は Root Node。 ネットワーク設定・証明書・アクセス制御・診断といった、 機器全体に関わるユーティリティクラスタがここに載る。 アプリケーションの機能（電球、センサー）は Endpoint 1 以降に置く。
3. ID の体系
Matter には多くの ID が登場する。整理しておく。
| ID | 型 | 割り当て | 用途 |
|---|---|---|---|
| Vendor ID (VID) | 16 bit | CSA が会員に割り当て | メーカーの識別 |
| Product ID (PID) | 16 bit | メーカーが自由に決める | 製品の識別 |
| Fabric ID | 64 bit | Fabric の管理者が決める | 管理ドメインの識別 |
| Node ID | 64 bit | Fabric 内で一意 | Fabric 内の機器の識別 |
| Group ID | 16 bit | Fabric 内 | 一斉制御のグループ |
| Endpoint ID | 16 bit | 機器が決める | Node 内の機能単位 |
| Cluster ID | 32 bit | 仕様 or メーカー | クラスタの識別 |
| Attribute ID | 32 bit | 仕様 or メーカー | 属性の識別 |
Node ID は Fabric ごとに違う. 同じ電球が Apple Home では Node ID = 0x1234、Google Home では 0x5678 になりうる。 Node ID はグローバルな識別子ではない。機器のグローバルな身元は DAC 証明書（12 章）の VID/PID と、証明書のシリアル番号が担う。
Cluster ID の空間
Cluster ID は 32 bit で、上位 16 bit がベンダー、下位 16 bit がクラスタ番号である。
| 上位 16 bit | 意味 |
|---|---|
0x0000 | 標準クラスタ（仕様で定義） |
| ベンダーの VID | メーカー独自クラスタ |
つまり標準の On/Off クラスタは 32 bit で書けば 0x00000006 である。 独自クラスタを VID 0xFFF1 で作るなら 0xFFF1_0001 のようになる。
独自クラスタは相互運用性を犠牲にする. 他社のエコシステムは独自クラスタを理解できない。 まず標準クラスタで表現できないかを徹底的に検討すること。 どうしても必要なら、標準クラスタで基本機能を提供したうえで、 独自クラスタは付加機能に留めるのが定石である（23 章）。
4. Fabric と信頼の構造
Fabric とは何か
同じ Root CA（RCAC）を信頼する Node の集合。技術的にはこれがすべてである。
| 要素 | 内容 |
|---|---|
| Root CA 証明書 (RCAC) | この Fabric の信頼の根 |
| Fabric ID | 64 bit の識別子 |
| 各 Node の NOC | Root CA から発行された、Node の操作用証明書 |
| IPK | Identity Protection Key。Fabric 内で共有される鍵 |
Node は複数の Fabric に所属できる。所属ごとに:
- 別々の Node ID
- 別々の 操作用鍵ペアと NOC
- 別々の ACL（アクセス制御リスト）
を持つ。Fabric どうしは互いに独立しており、片方の管理者が他方の設定を見ることはできない。
Compressed Fabric ID. DNS-SD のサービス名などで使う短縮識別子。 Root Public Key と Fabric ID から HKDF で導出した 64 bit 値である。 ネットワーク上に Fabric ID そのものを晒さないための工夫でもある（06 章）。
対応 Fabric 数
機器は最低いくつの Fabric を受け入れるべきか。 これは Operational Credentials クラスタの SupportedFabrics 属性で公開される。
仕様の下限は 5 である（
SupportedFabricsの最小値）。 ただし Fabric ごとに証明書・鍵・ACL・グループ鍵を保持するので、 フラッシュと RAM を消費する。設計時に必ず見積もること（17 章）。 実際の製品では 5〜10 程度が多い。
5. ロールの分類
| ロール | 役割 |
|---|---|
| Commissioner | 機器を Fabric に参加させる側（スマホアプリなど） |
| Commissionee | 参加される側（新品の機器） |
| Controller | 機器を操作する側 |
| Administrator | Fabric の管理権限を持つ Node |
| Border Router | Thread ネットワークと IP ネットワークを繋ぐ |
| OTA Provider | ファームウェアを配布する Node |
| Bridge | 非 Matter 機器を Matter として見せる Node |
Client と Server の向きに注意. Matter のクラスタには Server 側と Client 側がある。
- Server: Attribute を保持し、Command を受け取る（例: 電球の On/Off Server）
- Client: Command を送り、Attribute を読む（例: スイッチの On/Off Client）
「サーバ = 大きい機械」ではない。電球が Server で、スイッチが Client である。 Descriptor クラスタの
ServerList/ClientList属性でどちらを持つか公開される。
6. 1 つの操作を最後まで追う
「スマホから電球を点ける」で、全レイヤがどう動くかを見る。
| # | 層 | 起きること |
|---|---|---|
| 1 | アプリ | ユーザーが「点ける」をタップ |
| 2 | データモデル | 対象を特定: Node 0x1234 / Endpoint 1 / Cluster 0x0006 / Command On (0x01) |
| 3 | インタラクション | Invoke Request を構築 |
| 4 | アクション | TLV でエンコード |
| 5 | セキュリティ | CASE セッション鍵で AES-CCM 暗号化・認証 |
| 6 | メッセージング | Matter メッセージヘッダを付与、MRP で ACK を要求 |
| 7 | トランスポート | UDP ポート 5540 へ |
| 8 | ネットワーク | IPv6 パケットとして送出（宛先は DNS-SD で解決済み） |
| 9 | リンク | Wi-Fi か Thread で物理的に飛ぶ |
| — | 機器側では逆順に処理され、電球が点く | |
| 10 | Invoke Response と MRP ACK が返る | |
| 11 | 購読していれば OnOff 属性の変化が Report として通知される（10 章） |
この流れを頭に入れておくと、障害の切り分けが速くなる. 「反応しない」とき、どの層で止まっているのかを問える: IPv6 が届いていないのか（層 8）、セッションが張れていないのか（層 5）、 ACL で拒否されているのか（層 5-6 の間）、コマンドが未実装なのか（層 2）。 21 章のデバッグはこの分解が土台になる。
7. データはどう表現されるか（TLV の予告）
Matter のすべてのペイロードは TLV（Tag-Length-Value）でエンコードされる。 JSON や XML ではなく、独自のバイナリ形式である。
| 理由 | 内容 |
|---|---|
| 小さい | 組み込み機器のメモリと 802.15.4 の小さな MTU に収める |
| スキーマ不要 | タグに型情報が入るので、受信側は構造を知らなくてもパースできる |
| 前方互換 | 知らないタグは読み飛ばせる。仕様の拡張に強い |
詳細と実際のエンコード例は 17 章で扱う（コーデックのデモも用意している）。 ここでは「JSON ではなくバイナリの TLV である」とだけ覚えておけばよい。
8. 仕様書の構成
Matter の仕様は主に 3 冊に分かれている。どれを見るかを間違えないこと。
| 仕様書 | 内容 | よく見る場面 |
|---|---|---|
| Core Specification | アーキテクチャ、ネットワーク、セキュリティ、インタラクションモデル、TLV、コミッショニング | プロトコルの疑問 |
| Application Cluster Specification | 各クラスタの属性・コマンド・イベントの定義 | 「この属性の値域は？」 |
| Device Library Specification | デバイスタイプごとの必須／任意クラスタ | 「この製品は何を実装すべき？」 |
このほか、 Standard Namespace Specification（意味付けのためのタグ）、 Test Plans（認証テストの中身）などがある。
開発中に最も開くのは Application Cluster と Device Library である. Core は最初に通読し、あとは必要なときに引く。 Device Library は「実装漏れがないか」の最終チェックリストになる（22 章）。
9. まとめ
| 階層 | 一言で |
|---|---|
| Fabric | 同じ Root CA を信頼する Node の集合 = 1 つのエコシステムの管理ドメイン |
| Node | 1 台の機器。Fabric ごとに別の Node ID を持つ |
| Endpoint | Node の中の独立した機能単位。0 番は必ず Root Node |
| Cluster | Attribute と Command のまとまり。Server 側と Client 側がある |
| Attribute | 状態（読み書きできる値） |
| Command | 動作の要求 |
| Event | 起きたことの記録 |
| Device Type | 実装すべきクラスタの組み合わせの規定 |
- Matter は IPv6 の上のアプリケーション層。IPv6 より上は下位ネットワークに依存しない。
- BLE だけが例外で、BTP という専用トランスポートを使い、コミッショニング時のみ。
- Node ID はグローバルではない。機器のグローバルな身元は DAC が担う。
- ペイロードは TLV（バイナリ）。JSON ではない。
- 仕様書は 3 冊。Core / Application Cluster / Device Library を使い分ける。