Bluetooth Mesh はどう選ぶ？照明の受け入れチェックリストで設計を検証する

これまでの4回では、各方式の関係、独自ブロードキャストからマルチホップへ進む設計、SIG Mesh のプロビジョニングとモデルバインド、SIG Mesh 対応だけでは Mi Home に接続できない理由を説明しました。

実際の選定では「結局どれを使うのか」に戻りがちです。まず、こう問い直すことを勧めます。納入する空間で、利用者が必要とする操作を、この実装は安定して実行できるでしょうか。

壁スイッチだけ必要な案件、Mi Home が必須の案件、自作ゲートウェイから Matter へブリッジする案件を、一般的なプロトコル比較表だけでは決められません。

ここでは会議室と隣の廊下の照明を仮の例にします。部屋、機器、故障は設計上の例で、実測済みの現場ではありません。チェックリストはエンジニアリング上の提案であり、認証試験でも性能保証でもありません。

Bluetooth Mesh：検証してから約束する

1. プロトコル名より先に利用者の操作を書く

「1回押すとグループ全体が反応する」「インターネットが切れても基本照明が使える」「スマートフォン表示が実際の照明と食い違ったままにならない」を、さらに具体化します。

オフラインとはインターネット切断か、ルーターやゲートウェイの電源断も含むのか。
最終的に全部点灯すればよいのか、最初と最後の時間差にも制限があるのか。
正しい状態とはファームウェアの受理か、ドライバーやセンサーによる実出力の確認か。
操作アプリは Mi Home 必須か、専用アプリでもよいのか。

Mi Home が納入条件なら、対応カテゴリ、接続手順、対象ゲートウェイは無線部分の開発前に確認する制約です。自作ゲートウェイなら、機器プロトコル、鍵管理、ローカルインターフェースへのアクセスを早期に確保します。

まずエコシステムで絞り、その後で性能を検証します。 逆にすると、開発ボードでの成功を製品の納入保証と取り違えます。

2. 優劣ではなく責任範囲で選ぶ

独自 Mesh、SIG Mesh、Xiaomi Mesh は、同列の3規格ではありません。独自方式は設計判断の集合、SIG Mesh はネットワークとモデルの標準機構、小米の接続には製品識別や機能定義、プラットフォーム手順も含まれます。

主な目的	評価する経路	早期に必要な証拠
両端を自社で保守し、機能を限定する	独自方式も候補にする	メッセージ、安全性、配網、互換性、保守担当が明確で、検証を再現できる
自作ゲートウェイで複数機種を扱い、標準モデルを活用する	特定チップと SDK の SIG Mesh 実装	要素、モデル、任意機能、配網、鍵管理が整合する。規格名だけでは不足
Mi Home と対象ゲートウェイで使う製品を作る	小米が現在対応する接続方式	カテゴリ、製品識別、テンプレート、ファームウェア、対象ゲートウェイとの適合

併用はできますが、すべての長所を自動的に継承するわけではありません。標準採用は異なるメーカー間の相互運用試験の完了を意味せず、プラットフォーム採用も全機能のオフライン動作を保証しません。

Bluetooth SIG の入門資料が扱うのはモデル、発行・購読、多段通信の基礎です。小米の資料にはゲートウェイ変換、クラウド経路、製品テンプレートが加わります。ある層の対応は別の層の保証にはなりません。

3. 「オフライン対応」を3つの試験に分ける

操作ごとに経路を描きます。スイッチが直接 Mesh メッセージを送る場合と、ホストへ通知して転送させる場合では、ゲートウェイ停止の影響が異なります。

インターネットだけ切り、ローカル機器は動かす。 壁スイッチ、スマートフォン、設定済み自動化を分けて試し、クラウド依存を記録します。
他の設備を維持し、ゲートウェイを停止する。 機器間だけで動く操作を確認します。これを単なるインターネット切断として扱いません。
中継ノードを1台停止する。 中継に依存する経路がある構成で、遠方の照明の到達性と復電後の挙動を確認します。

SIG Mesh の機構は、すべての業務操作をクラウド経由にすることなくモデル間通信を可能にします。ただし製品での実現はモデル、設定、アプリケーション次第です。

小米の現在の BLE Mesh 基礎資料は、ゲートウェイ通信、スマートフォン直結、中継を区別し、説明対象の非低消費電力機器は中継できても相互制御はできないとしています。パケットの中継と、スイッチから照明への操作を独立して実行することは別です。

報告には「インターネット切断後、この機種のスイッチでこのグループを操作できた」と書き、単に「オフライン対応」としません。

4. 単灯の成功はグループ全体の成功ではない

近距離の1灯が動いても、単純な経路が確認できただけです。グループには中継、再送、状態通知、無線環境が加わります。

Silicon Labs は、中継過多、高頻度の発行、不適切な再送が通信量を増やし性能に影響すると説明しています。中継や再送を増やせば信頼性が上がるとは限りません。

1回のグループ操作では、少なくとも次を観測します。

合意した観測時間内に対象の各照明が目標状態へ達したか。
最初の照明と最後の照明の到達時間差。
制御側が十分な状態情報を得た時点と、無応答ノードを誤って成功扱いしていないか。

1件の応答だけで全体成功とは判定できません。確認応答なしのメッセージも、実観測や後続の状態確認で結果を判断し、エラーなしを完了と見なしません。

通常配置で基準を取り、機器と背景通信を増やし、その後に中継配置を変えます。可能なら一度に変える要因は1つ。ファームウェア、設定、電源、距離、壁、干渉条件を記録して比較可能にします。

5. 命令への応答、機器状態、実負荷を分ける

第4回でも述べたとおり、小米のサーバー・ゲートウェイ・機器間通信は非同期です。ゲートウェイの即時応答は実行済みの証拠ではなく、属性にはキャッシュや通知フィルターもあります。

自作システムでも、シリアル書き込み成功、SDK の成功、モデルの状態報告、実際の発光は異なる証拠です。

試作機の検収では、操作開始、ホスト送信、機器報告のログと、固定カメラの映像を対応させます。光センサーがあれば測定を加えられます。ファームウェア状態しか得られないなら「プロトコル上の状態」と明記し、実負荷の確認と呼びません。

同期していない2台の時刻を引いてエンドツーエンド遅延としてはいけません。同じ収集時計を使うか、同期方法を先に確立して説明します。

6. 復旧と交換で保守コストが見える

配網成功は保守の始まりです。次も確認します。

ホストと無線モジュールを別々に再起動しても、アドレス、鍵、モデル設定が整合するか。
設定中の停電後に、継続、再確認、再実行のどれが行われ、結果を理解できるか。
古い識別情報をどう削除し、交換機を既存の業務グループに入れるか。
バックアップに何が入り、復元は何に依存し、機密情報をどう保護するか。

復元試験は隔離環境で行い、シーケンス番号、リプレイ保護、永続化要件をチップと SDK の文書で確認します。記憶領域全体を別機器へ安易に複製しません。プラットフォーム識別情報や証明書は供給元の手順に従い、全消去を万能の復旧方法にしません。

共有記録には匿名化した機器識別子を使い、NetKey、AppKey、DevKey、機器の秘密鍵を載せません。

7. 最終成果は条件付きの結論

次の表で試作機の試験を整理できます。しきい値は試験前に合意し、結果を見てから合格線を変えません。 Bluetooth 認証に合格したという根拠にはなりません。

試験	先に決めること	最低限の記録
単灯・グループ制御	対象、観測時間、成功条件	試行数、各照明の結果、タイムアウト、再試行
操作体験	計時方法、期限、許容時間差	典型・遅い例、最大値、失敗。十分な標本で分位点も確認
切断・故障	切断箇所、維持すべき機能	機能変化、障害表示、復旧過程
状態整合性	プロトコル状態か実負荷か	命令、報告、観測、不一致の継続時間
拡張・復旧	台数、負荷、設定版、再起動順序	変更前後の差、設定の保存と復元

100回操作しただけでは信頼性を証明できません。1回が単灯かグループか、失敗を命令単位で数えるか対象ごとに数えるかを示します。タイムアウトを黙って除外して成功例の平均だけを見せてはいけません。

有用な結論は、機器、ファームウェア、設定、配置、負荷を列挙し、満たせた操作と未達の操作、次に変える点を説明します。

「速い、省電力、安定」と断言するより狭い結論ですが、調達、開発、導入に使えます。プロトコルは機構を、製品は能力を提供し、検証が約束できる範囲を決めます。

参考資料

Bluetooth SIG: The Bluetooth Mesh Networking Primer。標準機構とモデル間通信。
Silicon Labs: Bluetooth Mesh Networking Principles。中継、TTL、再送、発行頻度、リプレイ保護。閲覧時は 11.0.2。実際の SDK 版を確認してください。
小米 IoT：BLE Mesh 基礎知識。非同期応答、キャッシュ、接続テンプレート。ページ更新日は 2026-08-04 で、2026-08-06 以降の変更を説明しています。

資料確認日：2026-11-05。試験構成、観測、検収表は技術的提案であり、本稿で実機試験は行っていません。