Chapter 05
Wi-Fi・Ethernet・BLE — どれを選び、どう使うか
この章がなぜ必要なのか——ネットワークの選択は、あとから変えられない.
Thread か Wi-Fi かは、SoC の選定・電源設計・BOM コスト・ 「ユーザーにハブを買わせるか」という商品企画にまで波及する。 基板を起こしてからでは戻れない判断である。
そして BLE。Matter で BLE はコミッショニング専用という特殊な使われ方をする。 ここを誤解すると「BLE で常時通信できるはず」という前提で設計してしまう。
この章で使う既出の用語（定義は各リンク先）. Matter（01 章 3 節）、コミッショニング（01 章 3 節）、セキュリティ（01 章 2 節）、ネットワーク（01 章 3 節）、IPv6（02 章 1 節）、データモデル（02 章 1 節）、トランスポート（02 章 1 節）、リンク（02 章 1 節）、mDNS（03 章 4 節）、マルチキャスト（03 章 3 節）、Router（04 章 2 節）
1. Matter がサポートするリンク層
| リンク | 運用通信 | コミッショニング | 主な用途 |
|---|---|---|---|
| Wi-Fi | ○ | ○（同一ネットワークにいれば） | 常時給電・高スループット機器 |
| Ethernet | ○ | ○ | ハブ・ブリッジ・据置機器 |
| Thread | ○ | ○（既に参加済みなら） | 電池機器・多数配置 |
| BLE | × | ○（主役） | 初期セットアップの経路 |
BLE は運用通信に使えない. Matter の仕様上、BLE はコミッショニング時のトランスポートとしてのみ定義されている。 「Matter 機器と BLE で日常的に喋る」ということはない。 設定が終われば BLE は切断され、以降は Wi-Fi か Thread を使う。
2. Wi-Fi
要件
| 項目 | 内容 |
|---|---|
| IPv6 必須 | ルータが IPv6 を有効にしている必要がある（03 章） |
| mDNS | マルチキャストが通ること |
| 帯域 | 2.4 GHz が一般的。5 GHz 対応機器もある |
| 規格 | 802.11 b/g/n が多い。Wi-Fi 6 (ax) 対応 SoC も増加 |
消費電力の現実
| 状態 | 目安 |
|---|---|
| 送受信中 | 100〜300 mA |
| アイドル（接続維持） | 数 mA〜数十 mA |
| DTIM ビーコン受信 | 周期的に起きる必要がある |
| ディープスリープ | 数 µA（ただし切断される） |
Wi-Fi で電池駆動は原則として無理である. 接続を維持するだけで DTIM ごとに起きる必要があり、平均消費電流は どうしても mA オーダーになる。単三電池 2 本（約 2000 mAh）で 数百時間——つまり数週間が限界に近い。
「Wi-Fi + 電池」を成立させるには、普段は完全に切断し、 イベント時だけ接続する設計にするしかない（接続に数秒かかり、 その間の消費も大きい）。ドアベルやカメラの一部がこの方式を採る。
常時応答が必要な電池機器なら Thread 一択である。
Wi-Fi での落とし穴
| 落とし穴 | 内容 |
|---|---|
| IPv6 が無効なルータ | 機器が動かない。ユーザー側の設定に依存する |
| クライアント分離 | ゲスト Wi-Fi では端末間通信が禁止されている |
| 2.4/5 GHz の分離 | スマホが 5 GHz、機器が 2.4 GHz で別サブネットだと mDNS が届かない |
| メッシュ Wi-Fi | 中継機を跨ぐとマルチキャストが落ちることがある |
| 省電力モードでのマルチキャスト取りこぼし | 機器が mDNS クエリを見逃す |
| DTIM 設定 | 大きいと応答が遅れる |
「うちのルータでは動かない」というサポート問い合わせは必ず来る. 上記のどれかであることがほとんどである。 トラブルシューティング手順をドキュメント化しておくことが実務上きわめて重要になる。
3. Ethernet
最も素直に動く。Border Router、ハブ、ブリッジ、据置型の機器に向く。
| 利点 | 欠点 |
|---|---|
| 安定・高速 | 配線が必要 |
| マルチキャストの問題が起きにくい | 設置場所が制約される |
| 電源が確保されている前提が置ける | 一般家庭では敷設されていないことが多い |
開発初期は Ethernet で作るのが賢い. ネットワークの不確定要素を排除して、Matter のロジックだけに集中できる。 Linux 上の
all-clusters-appを Ethernet で動かし、 データモデルとインタラクションを固めてから、無線に移す——という順序が効率的である。
4. BLE — コミッショニングの入口
なぜ BLE が必要なのか
新品の機器は、まだ Wi-Fi のパスワードも Thread の Dataset も知らない。 ネットワークに入れないので、IP で通信できない。
そこで、まだネットワークに入っていない機器と話す経路が要る。それが BLE である。
1. 機器が BLE でアドバタイズ（「私はコミッショニング待ちです」）
2. スマホが BLE で接続
3. BLE 上で PASE セッションを確立（[13 章](13_コミッショニング.md#pase-spake2+-によるセッション確立)）
4. BLE 経由で Wi-Fi 認証情報 or Thread Dataset を渡す
5. 機器がネットワークに参加
6. 以降は IP（Wi-Fi / Thread）で通信。BLE は切断BTP（Bluetooth Transport Protocol）
BLE は MTU が小さい（デフォルト 23 bytes、拡張しても 244 bytes 程度）ので、 Matter のメッセージをそのまま載せられない。
BTP が、Matter メッセージを BLE の GATT 上でフラグメント／再構成する。
| 要素 | 内容 |
|---|---|
| サービス UUID | Matter 用に割り当てられた 16 bit UUID |
| Characteristic C1 | クライアント → サーバ（Write） |
| Characteristic C2 | サーバ → クライアント（Indicate） |
| Characteristic C3 | 追加データ（任意） |
| ハンドシェイク | ウィンドウサイズと MTU の折衝 |
| フラグメント | セグメント化と再構成、フロー制御 |
BLE アドバタイズの中身
コミッショニング待ちの機器は、以下を含むアドバタイズを出す。
| 項目 | 内容 |
|---|---|
| Discriminator | 12 bit。どの機器かを絞り込む |
| Vendor ID / Product ID | 機器の種類（任意） |
| Commissioning Mode | コミッショニング可能な状態か |
スマホは QR コードから読み取った Discriminator と突き合わせて、目的の機器を特定する。
Discriminator は「同時に複数台をセットアップする」ための識別子である. 家電量販店の店頭や、同じ機種を何台も設置する現場では、 周囲に同じ製品が複数コミッショニング待ちになっている。 Discriminator（12 bit = 4096 通り）で絞り込むことで、目的の 1 台を選べる。
完全にユニークではないので、製造時にランダムに割り当てるのが望ましい。 全個体で同じ Discriminator にすると、隣の機器を設定してしまう事故が起きる。
5. ネットワークの選び方
判断フロー
電池駆動か？
├─ はい → 常時の即応性が必要か？
│ ├─ はい → Thread（SED、ポーリング間隔を短めに）
│ └─ いいえ → Thread（SED、ポーリング間隔を長く）※電池寿命最優先
└─ いいえ（常時給電）
├─ 大きなデータを流す（映像・音声）か？ → Wi-Fi
├─ 有線を引ける据置機器か？ → Ethernet
├─ ユーザーにハブを要求できるか？
│ ├─ できる → Thread（多数配置なら特に有利）
│ └─ できない → Wi-Fi
└─ 既存 Wi-Fi 製品の Matter 対応 → Wi-Fi（ハード変更なしの可能性）比較表
| 観点 | Wi-Fi | Thread | Ethernet |
|---|---|---|---|
| 電池駆動 | ほぼ不可 | ○ | 不可 |
| スループット | 高い | 250 kbps | 高い |
| 到達範囲 | ルータ次第 | メッシュで拡張 | ケーブル次第 |
| ハブ（Border Router） | 不要 | 必要 | 不要 |
| SoC コスト | やや高 | やや低 | — |
| 設置の手軽さ | ○ | ○ | × |
| ネットワークトラブル | 起きやすい | Border Router 依存 | 少ない |
多くのメーカーが両方を出している. 同じ製品ラインで Wi-Fi 版と Thread 版を用意し、 ユーザーの環境に合わせて選ばせる。SDK は共通なので、 プラットフォーム抽象化さえきちんとしておけば、アプリ層は使い回せる。
6. 同時対応（マルチトランスポート）
1 台の機器が Wi-Fi と Thread の両方を持つ構成もありうる。
| メリット | デメリット |
|---|---|
| ユーザー環境を選ばない | BOM コストが上がる |
| Border Router が無くても動く | 2 つのラジオの共存設計が必要 |
| — | 認証も両方必要になる可能性 |
仕様上、Matter の運用トランスポートは基本的に 1 つを選ぶ. 「Wi-Fi と Thread を同時に運用する」構成は複雑さの割に得るものが少ない。 実際には、両対応 SoC を載せて、コミッショニング時にどちらかを選ぶ設計が現実的である。
7. 開発時の構成例
最速で動かす（Ethernet / Linux）
# Linux 上でサンプルを直接実行。ネットワークの不確定要素がゼロ
./out/linux-x64-all-clusters/chip-all-clusters-app
# 別端末から
./out/linux-x64-chip-tool/chip-tool pairing onnetwork 1 20202021
./out/linux-x64-chip-tool/chip-tool onoff toggle 1 1Wi-Fi 機器の開発（ESP32 の例）
# esp-matter 環境で
idf.py set-target esp32
idf.py build flash monitor
# BLE 経由でコミッショニング（Wi-Fi 認証情報を渡す）
chip-tool pairing ble-wifi 1 <SSID> <PASSWORD> 20202021 3840Thread 機器の開発
# Border Router の Dataset を取得
ot-ctl dataset active -x
# BLE 経由でコミッショニング（Thread Dataset を渡す）
chip-tool pairing ble-thread 1 hex:<dataset> 20202021 3840
20202021と3840は SDK のサンプルのデフォルト値である （テスト用の passcode と discriminator）。 製品では必ず個体ごとに変えること（13 章・22 章）。 全製品が同じ passcode だと、誰でもコミッショニングできてしまう。
8. 落とし穴
| 落とし穴 | 対処 |
|---|---|
| BLE を運用通信に使おうとする | 仕様上できない。設計を見直す |
| Wi-Fi + 電池を想定する | 消費電力を実測して現実性を確認する |
| Discriminator が全個体同じ | 製造時にランダム割り当て |
| BLE アドバタイズを止め忘れる | コミッショニング完了後は停止する（電力・セキュリティ両面） |
| 5 GHz 前提の設計 | 多くの Matter SoC は 2.4 GHz のみ |
| ルータの IPv6 が無効 | ユーザー向けドキュメントで案内が必要 |
| BLE と Wi-Fi/Thread の共存 | 同じ 2.4 GHz。コエグジスタンス設定を確認する |
BLE アドバタイズの停止は忘れられがちである. コミッショニングが完了したら、BLE は不要になる。 出し続けると電力を消費し、また 「コミッショニング待ちに見える」状態が残ってセキュリティ上も望ましくない。 ただし再コミッショニング用に、条件付きで再開できる必要はある（14 章）。
9. まとめ
- Matter の運用トランスポートは Wi-Fi / Ethernet / Thread。BLE はコミッショニング専用。
- BLE では BTP が Matter メッセージをフラグメントして GATT で運ぶ。
- BLE アドバタイズには Discriminator が入り、複数台の中から目的の 1 台を特定する。 個体ごとにランダムであるべき。
- Wi-Fi + 電池は原則として成立しない。電池機器は Thread。
- Thread は Border Router（ハブ）が必要——これは商品企画上の判断でもある。
- 開発初期は Ethernet / Linux で動かすと、ネットワーク要因を排除できて速い。