Matter プロトコル入門

Matter はスマートホーム向け相互接続プロトコル。データモデル、MIoT SPECとの比較、配網フロー、バージョン1.5のカメラサポートを解説。

2024年3月16日テクノロジー , コンピュータネットワーク 4 分で読めます

Matter は CSA（Connectivity Standards Alliance） が策定したスマートホーム相互接続プロトコルです。IP ベースのアプリケーション層プロトコルであり、異なるブランドやエコシステムのデバイスが互いに通信できないという、スマートホーム分野に長年存在する断片化問題の解決を目的としています。

Matter の前身は Project CHIP（Connected Home over IP） であり、Apple、Google、Amazon、Samsung などの大手企業が 2019 年に共同で立ち上げました。2022 年 10 月に Matter 1.0 が正式にリリースされました。

特性	説明
相互運用性（Interoperability）	1 つのデバイスを Apple Home、Google Home、Alexa など複数のエコシステムから同時に制御可能
ローカル制御（Local）	デバイス通信は LAN 内で完結し、クラウドに依存しないため遅延とプライバシーリスクを低減
セキュリティ（Security）	証明書ベースのデバイス認証、すべての通信を暗号化
簡単セットアップ（Easy Setup）	QR コードスキャンまたは NFC で Commissioning（配網）を完了
マルチ管理者（Multi-Admin）	同一デバイスを複数の制御エコシステムで同時に管理可能

Matter は IP ネットワーク上で動作し、下位転送層として以下をサポートします：

Wi-Fi：高帯域幅デバイス（カメラ、ディスプレイ）に適する
Thread：低消費電力メッシュネットワーク、センサーやスマートロックなどのバッテリー駆動デバイスに適する
Ethernet：有線接続、ブリッジや Hub などに適する
BLE（Bluetooth Low Energy）：デバイスの配網フェーズのみに使用

┌─────────────────────────────────────────┐
│            Application Layer            │
│               (Matter)                  │
├─────────────────────────────────────────┤
│           Transport (TCP/UDP)           │
├─────────────────────────────────────────┤
│              Network (IPv6)             │
├──────────┬──────────┬───────────────────┤
│  Wi-Fi   │  Thread  │    Ethernet       │
│ (802.11) │(802.15.4)│                   │
└──────────┴──────────┴───────────────────┘
         BLE は Commissioning のみに使用

Matter は階層化データモデルを採用してデバイス能力を記述します。これはプロトコル全体を理解する上で鍵となります。

Node → Endpoint → Cluster → Attribute / Command / Event

概念	説明
Node（ノード）	ネットワーク内のアドレス可能なエンティティで、1 つの物理デバイスに対応し、固有の Node ID を持つ
Endpoint（エンドポイント）	ノード内の機能単位。Endpoint 0 はルートエンドポイント（Root Node）として固定、Endpoint 1 以降はアプリケーション機能
Cluster（クラスタ）	機能の最小モジュール単位で、属性、コマンド、イベントを含む。Server（データ提供）と Client（データ消費）に分かれる
Attribute（属性）	Cluster 内の状態データ。Read / Write / Subscribe をサポート
Command（コマンド）	Cluster 内で呼び出し可能なアクション（On、Off、Toggle など）
Event（イベント）	デバイスが能動的に報告する状態変化の通知

Device Type（デバイスタイプ） は、エンドポイントが実装すべき最小限の Cluster セットを定義します。例えば “Dimmable Light” デバイスタイプは OnOff Cluster と LevelControl Cluster の実装を要求します。

Physical Device (Node ID: 0x0001)
├── Endpoint 0 (Root Node)
│   ├── Basic Information Cluster
│   │   └── Attributes: VendorName, ProductName, SoftwareVersion...
│   ├── Network Commissioning Cluster
│   └── Descriptor Cluster
│
└── Endpoint 1 (Dimmable Light)
    ├── OnOff Cluster (server)
    │   ├── Attributes: OnOff (bool)
    │   └── Commands: On, Off, Toggle
    ├── Level Control Cluster (server)
    │   ├── Attributes: CurrentLevel (uint8)
    │   └── Commands: MoveToLevel, Step
    └── Descriptor Cluster
        └── Attributes: DeviceTypeList, ServerList, ClientList

小米（Xiaomi）の MIoT SPEC は、米家（Mi Home）エコシステムにおけるデバイス記述プロトコルであり、iot.mi.com で定義されています。両者には類似した設計思想がありますが、位置づけと開放性の度合いが大きく異なります。

次元	Matter	米家 MIoT SPEC V3
階層構造	Node → Endpoint → Cluster → Attribute/Command/Event	Device → Module → Service → Property/Action/Event
デバイス識別	Device Type ID（数値）	URN：`urn:miot-spec-v2:device:<type>:<vendor>:<version>`
グループ層	Endpoint（多機能デバイスの機能区分）	Module（ハードウェアモジュール区分）
機能単位	Cluster（OnOff、LevelControl など）	Service（light、fan など）
状態量	Attribute（Read/Write/Subscribe 対応）	Property（Read/Write/Notify 対応）
操作	Command	Action
通知	Event（タイムスタンプ付きログ型）	Event（報告型）

MIoT SPEC V2 プロトコルの階層は Device → Service → Property/Action/Event であり、Module 層が存在しない。現在、米家エコシステムの大部分のデバイスはまだ V2 プロトコルを使用している。

Matter                          MIoT SPEC V3
─────────────────────────────────────────────
Node                    ←→      Device
Endpoint                ←→      Module
Cluster                 ←→      Service
Attribute               ←→      Property
Command                 ←→      Action
Event                   ←→      Event
Device Type             ←→      Device URN Type

次元	Matter	米家 MIoT SPEC
策定主体	CSA（Apple、Google、Amazon など共同）	小米（Xiaomi）
開放性	オープンスタンダード、どのメーカーでも実装可能	閉鎖的エコシステム、小米プラットフォームへの接続が必要
クロスエコシステム	ネイティブで複数エコシステム制御をサポート	米家/HomeKit のみ（一部デバイス）
通信方式	LAN IP 通信（Wi-Fi/Thread）	Bluetooth mesh / Wi-Fi / ZigBee、ゲートウェイに依存
クラウド依存	ローカル優先、クラウド非依存	多くの機能が小米クラウドに依存
認証体系	CSA 統一認証	小米独自認証
デバイス規模	2025 年時点で約 3000+ の認証製品	米家エコチェーンに数千製品

シーリングファンライトは典型的な多機能デバイスで、ファンとライトの両方の機能を備えており、グループ層（Endpoint / Module）の役割を示すのに最適です。

Matter（Fan Light）：

1 つの物理デバイスが 2 つの Endpoint を通じてライトとファンの能力をそれぞれ公開します：

Fan Light Node
├── Endpoint 0 (Root Node)
│   └── Basic Information, Descriptor...
│
├── Endpoint 1 (Dimmable Light)
│   ├── Device Type: Dimmable Light (0x0101)
│   ├── OnOff Cluster
│   │   ├── Attribute: OnOff (bool)
│   │   └── Commands: On, Off, Toggle
│   └── LevelControl Cluster
│       ├── Attribute: CurrentLevel (0-254)
│       └── Commands: MoveToLevel
│
└── Endpoint 2 (Fan)
    ├── Device Type: Fan (0x002B)
    ├── FanControl Cluster
    │   ├── Attribute: FanMode (Off/Low/Medium/High/Auto)
    │   ├── Attribute: PercentCurrent (0-100)
    │   └── Commands: Step
    └── OnOff Cluster
        └── Commands: On, Off, Toggle

MIoT SPEC V3（シーリングファンライト）：

V3 は 2 つの Module でライトモジュールとファンモジュールをそれぞれ記述します：

{
  "type": "urn:miot-spec-v2:device:fan-light:0000A012:yeelink-fancl1:1",
  "modules": [
    {
      "iid": 1,
      "type": "urn:miot-spec-v2:module:light-module",
      "services": [
        {
          "type": "urn:miot-spec-v2:service:light",
          "properties": [
            {"type": "urn:miot-spec-v2:property:on", "format": "bool", "access": ["read","write","notify"]},
            {"type": "urn:miot-spec-v2:property:brightness", "format": "uint8", "value-range": [1,100,1]}
          ]
        }
      ]
    },
    {
      "iid": 2,
      "type": "urn:miot-spec-v2:module:fan-module",
      "services": [
        {
          "type": "urn:miot-spec-v2:service:fan",
          "properties": [
            {"type": "urn:miot-spec-v2:property:on", "format": "bool", "access": ["read","write","notify"]},
            {"type": "urn:miot-spec-v2:property:fan-level", "format": "uint8", "value-range": [1,5,1]},
            {"type": "urn:miot-spec-v2:property:mode", "format": "uint8", "value-list": [
              {"value": 0, "description": "Normal"},
              {"value": 1, "description": "Natural Wind"}
            ]}
          ]
        }
      ]
    }
  ]
}

この例から明らかなように、Matter の Endpoint と MIoT SPEC V3 の Module は同じ問題を解決しています — 多機能な物理デバイスの異なる能力を独立した名前空間に分割し、制御側がそれぞれを個別にアドレス指定して操作できるようにするというものです。

両者の設計思想は非常に似ており、いずれも「機能グループ化 + 属性/コマンド」のパターンです。V3 で新たに追加された Module 層は Matter の Endpoint と異曲同工であり、いずれもデバイスと機能単位の間にグループ化の抽象化層を追加し、多機能デバイスの内部構造（エアコンの「圧縮機モジュール」と「表示モジュール」など）を記述するためのものです。

主な違いは、Matter がクロスエコシステムのオープンスタンダードであるのに対し、MIoT SPEC は小米の閉鎖的エコシステムにサービスを提供している点です。

バージョン	リリース日	主な追加機能
1.0	2022.10	基本デバイスタイプ：電球、スイッチ、コンセント、スマートロック、サーモスタット、カーテンなど
1.1	2023.05	ICD（間欠接続デバイス）サポート、シーン管理
1.2	2023.10	冷蔵庫、洗濯機、ロボット掃除機などの家電デバイスタイプ
1.3	2024.05	エネルギー管理、EV 充電スタンド、電子レンジ、オーブンなど
1.4	2024.11	拡張デバイスコンポジション、拡張 ICD
1.5	2025.11	カメラ、開閉系デバイス（Closures）、強化されたエネルギー管理

カメラは Matter で最も待望されていたデバイスタイプの 1 つです。Matter 1.5（2025 年 11 月リリース）でようやくカメラの完全なサポートが導入されました。これは複雑なデバイスタイプです — 電球やスイッチのような単純な状態制御とは異なり、カメラはリアルタイムの音声・映像ストリーム転送、コーデックネゴシエーション、プライバシー制御など多岐にわたる能力を必要とします。

Matter 1.5 ではカメラ向けに 3 つのコア Cluster が新たに追加されました：

この Cluster はカメラの音声・映像能力の記述とストリームリソースの管理を担当し、カメラデバイスタイプの中核です。

主要 Attributes：

Attribute	説明
`MaxConcurrentVideoEncoders`	デバイスが同時に実行できる最大ビデオエンコーダ数
`MaxEncodedPixelRate`	最大エンコードピクセルレート（解像度×フレームレートの上限を制約）
`VideoSensorParams`	イメージセンサーパラメータ（物理解像度、最大フレームレートなど）
`NightVisionCapable`	ナイトビジョン対応の有無
`SupportedSnapshotParams`	サポートされるスナップショットパラメータ（解像度、エンコード形式）
`HDRModeEnabled`	HDR モードが有効かどうか
`RateDistortionTradeOffPoints`	レート歪みトレードオフポイント。制御側が適切なエンコードパラメータを選択するのに役立つ
`MicrophoneCapabilities`	マイク能力（サンプルレート、チャンネル数、エンコード形式）
`SpeakerCapabilities`	スピーカー能力（双方向通話用）
`TwoWayTalkSupport`	双方向通話サポートタイプ（半二重/全二重）
`AllocatedVideoStreams`	現在割り当てられているビデオストリームのリスト
`AllocatedAudioStreams`	現在割り当てられているオーディオストリームのリスト
`AllocatedSnapshotStreams`	現在割り当てられているスナップショットストリームのリスト

主要 Commands：

Command	説明
`VideoStreamAllocate`	ビデオストリームを 1 つ割り当てる。エンコード形式、解像度、フレームレート、ビットレートなどを指定
`VideoStreamDeallocate`	ビデオストリームを解放
`AudioStreamAllocate`	オーディオストリームを 1 つ割り当てる
`AudioStreamDeallocate`	オーディオストリームを解放
`SnapshotStreamAllocate`	スナップショットストリームを割り当てる（画像キャプチャ用）
`SnapshotStreamDeallocate`	スナップショットストリームを解放
`CaptureSnapshot`	スナップショットキャプチャを 1 回トリガー
`SetStreamPriorities`	複数ストリームの優先度を設定（リソース不足時に低優先度ストリームが低下）

この設計は「能力記述 + リソース管理」の考え方を示しています。デバイスはまず Attributes を通じて自身の能力範囲を制御側に伝え、制御側はその情報に基づいて Commands で具体的なストリームリソースを要求します。

この Cluster は WebRTC セッションのシグナリング交換を担当し、リアルタイムビデオ転送のチャネル確立層です。

設計思想：Matter プロトコル自体をシグナリングチャネルとして使用し、WebRTC の SDP Offer/Answer と ICE Candidate 交換を運搬します。これにより、追加のシグナリングサーバが不要になります。実際の音声・映像データは WebRTC のメディアチャネルを介してピアツーピアで転送され、Matter メッセージ層を経由しません。

Attributes：

Attribute	説明
`CurrentSessions`	現在アクティブな WebRTC セッションのリスト
`MaxSessions`	最大同時セッション数

Commands：

Command	説明
`SolicitOffer`	制御側がカメラに SDP Offer の送信を要求（カメラ主導でネゴシエーション）
`ProvideOffer`	制御側がカメラに SDP Offer を送信（制御側主導でネゴシエーション）
`ProvideAnswer`	SDP Answer を返信し、メディアネゴシエーションを完了
`ProvideICECandidate`	ICE 候補アドレスを交換し、NAT 越えと接続確立に使用
`EndSession`	WebRTC セッションを終了

WebRTC セッション確立フロー：

┌──────────┐                              ┌──────────┐
│ 制御側    │                              │  カメラ   │
│(手机/Hub) │                              │          │
└─────┬────┘                              └─────┬────┘
      │                                         │
      │  1. ProvideOffer (SDP Offer)            │
      │────────────────────────────────────────►│
      │                                         │
      │  2. ProvideAnswer (SDP Answer)          │
      │◄────────────────────────────────────────│
      │                                         │
      │  3. ProvideICECandidate (双方向交換)     │
      │◄───────────────────────────────────────►│
      │                                         │
      │  4. ICE 接続性檢查 & DTLS 握手           │
      │◄═══════════════════════════════════════►│
      │                                         │
      │  5. SRTP 音声・映像ストリーム (P2P 直接)  │
      │◄═══════════════════════════════════════►│
      │                                         │

ステップ 1〜3 は Matter メッセージ層を介して転送（シグナリング）、ステップ 4〜5 は WebRTC メディア層の直接通信です。

この Cluster はカメラが能動的にビデオストリームを指定された受信側にプッシュすることをサポートし、以下のシナリオに適しています：

継続録画：ビデオストリームを NVR（ネットワークビデオレコーダー）やクラウドストレージにプッシュ
イベントトリガー：動体検知や音声検出後、能動的に Hub やスマートフォンにビデオをプッシュ
複数受信側：同一カメラのビデオストリームを複数の宛先に同時プッシュ

Commands：

Command	説明
`AllocatePushTransport`	プッシュ先を登録し、転送プロトコルと宛先アドレスを指定
`DeallocatePushTransport`	プッシュ先を削除
`FindTransport`	登録済みのプッシュ転送を検索
`SetTransportStatus`	プッシュを有効化/一時停止

WebRTC Transport Provider との違い：WebRTC は「プル」モード（制御側が必要に応じて表示を要求）、Push AV Stream は「プッシュ」モード（カメラが能動的に送信）です。両者は補完関係にあり、カメラの典型的な使用シナリオをカバーします。

Matter が RTSP や独自プロトコルではなく WebRTC をビデオ転送技術として選択した理由は、以下の考察に基づきます：

比較観点	WebRTC	RTSP	独自プロトコル
遅延	極めて低い（<500ms、通常 <200ms）	中程度（1〜3s）	実装による
NAT 越え	ネイティブ対応（ICE/STUN/TURN）	追加処理が必要	追加処理が必要
暗号化	必須（DTLS + SRTP）	オプション（RTSPS）	不確定
エコシステムの成熟度	ブラウザ/モバイルでネイティブ対応	専用プレイヤーが必要	専用 SDK が必要
双方向通信	ネイティブ対応	主に単方向	実装による
コーデックの柔軟性	H.264/H.265/VP8/VP9/AV1	主に H.264/H.265	実装による

コアとなるメリットのまとめ：

追加インフラが不要：シグナリングは Matter チャネルを再利用、メディアは P2P 直接接続のため STUN/TURN サーバの導入が不要（LAN 環境）
エンドツーエンドのセキュリティ：強制暗号化が Matter のセキュリティ設計思想と一致
広範な互換性：制御側（スマートフォン、スマートスピーカー）に追加 SDK が不要で接続可能

Camera Node
├── Endpoint 0 (Root Node)
│   ├── Basic Information Cluster
│   ├── Network Commissioning Cluster
│   └── Descriptor Cluster
│
└── Endpoint 1 (Camera)
    ├── Camera AV Stream Management Cluster
    │   ├── Attributes:
    │   │   ├── MaxConcurrentVideoEncoders (uint8)
    │   │   ├── MaxEncodedPixelRate (uint32)
    │   │   ├── VideoSensorParams (struct)
    │   │   ├── NightVisionCapable (bool)
    │   │   ├── HDRModeEnabled (bool)
    │   │   ├── SupportedSnapshotParams (list)
    │   │   ├── MicrophoneCapabilities (struct)
    │   │   ├── SpeakerCapabilities (struct)
    │   │   ├── TwoWayTalkSupport (enum: None/HalfDuplex/FullDuplex)
    │   │   ├── AllocatedVideoStreams (list)
    │   │   ├── AllocatedAudioStreams (list)
    │   │   └── AllocatedSnapshotStreams (list)
    │   └── Commands:
    │       ├── VideoStreamAllocate / Deallocate
    │       ├── AudioStreamAllocate / Deallocate
    │       ├── SnapshotStreamAllocate / Deallocate
    │       ├── CaptureSnapshot
    │       └── SetStreamPriorities
    │
    ├── WebRTC Transport Provider Cluster
    │   ├── Attributes:
    │   │   ├── CurrentSessions (list)
    │   │   └── MaxSessions (uint8)
    │   └── Commands:
    │       ├── SolicitOffer
    │       ├── ProvideOffer / ProvideAnswer
    │       ├── ProvideICECandidate
    │       └── EndSession
    │
    └── Push AV Stream Transport Cluster
        └── Commands:
            ├── AllocatePushTransport
            ├── DeallocatePushTransport
            ├── FindTransport
            └── SetTransportStatus

カメラ以外にも、Matter 1.5 では以下が導入されました：

Closures（開閉系デバイス）：ガレージドア、ブラインドなど、精密な位置制御と安全状態フィードバックが必要なデバイス
強化されたエネルギー管理：より詳細な電力監視、スマートスケジューリング、デマンドレスポンス機能

デバイスが Matter ネットワークに参加するプロセスを Commissioning と呼び、典型的なフローは以下の通りです：

┌──────────┐         BLE/SoftAP         ┌──────────────┐
│          │ ◄─────────────────────────► │              │
│  新規デバイス│   1. 発見 & PASE 安全通道   │  Commissioner │
│          │                            │  (手机 App)   │
└──────────┘                            └──────────────┘
     │                                         │
     │  2. デバイス認証 (DAC 証明書チェーン検証)  │
     │◄────────────────────────────────────────│
     │                                         │
     │  3. ネットワーク設定 (Wi-Fi/Thread 資格情報の送信)│
     │◄────────────────────────────────────────│
     │                                         │
     │  4. CASE 安全セッションの確立             │
     │◄────────────────────────────────────────│
     │                                         │
     │  5. 完了、デバイスが Fabric に参加         │
     │◄────────────────────────────────────────│

主要なセキュリティメカニズム：

PASE（Passcode-Authenticated Session Establishment）：デバイスの配網コードに基づいて初期安全チャネルを確立
CASE（Certificate-Authenticated Session Establishment）：証明書に基づいて実行時安全チャネルを確立
DAC（Device Attestation Certificate）：デバイス認証証明書。デバイスが正規メーカーのものであることを保証
Fabric：Matter ネットワークにおける信頼ドメイン。同一 Fabric 内のデバイスは相互に信頼する

Matter プロトコルは、スマートホームに真の「共通言語」を確立しようと試みています。そのデータモデル（Cluster/Attribute/Command）は、米家 MIoT SPEC（Service/Property/Action）と設計思想においては同じ目標に収斂していますが、Matter の開放性とマルチエコシステムサポートにより、業界標準となる可能性を秘めています。

Matter 1.5 で導入されたカメラサポートは WebRTC 技術スタックを採用しており、低遅延、セキュリティ、相互運用性を兼ね備えており、プロトコルの成熟度における重要なマイルストーンです。より多くのデバイスタイプの追加とエコシステムの充実に伴い、Matter は「どのブランドのデバイスを買っても、どのプラットフォームでも制御できる」というビジョンを真に実現することが期待されています。

参考資料