前回の記事で書いたとおり、僕がHAをやめて自作CLI群に移った直接のきっかけは、リビング照明のグループ制御がまともに動かなかったことでした。mat はそのMatter担当として作りはじめたCLIです。

ただ、コードを1行も書く前に、決めないといけないことがありました。mat は、HAが持っているMatterの世界にそのまま相乗りするのか、それとも自分だけの世界を新しく持つのか。

これはMatterという規格特有の分岐です。ECHONET Lite（enlが担当）はUDPを一発投げれば終わるコネクションレスな規格なので、この手の悩みはありません。Matterは相手を先に認証（コミッショニング）し、証明書ベースのセッションを維持する必要がある、原理的にステートフルな規格です。この認証の輪のことを「Fabric」と呼びます。同じFabricの証明書を持つコントローラだけが、機器と話せます。

Geminiに壁打ちしながら整理した内容をもとに、この記事では当時考えた3つの選択肢と、実際に選んだ理由、捨てた道、そして数ヶ月経ったいまの答え合わせを書きます。

3つの選択肢

1. HAのFabricに相乗りする

家にはすでにHAの python-matter-server が動いていて、これ自体がひとつのFabricのコントローラです。mat はそこにWebSocketでつなぎ、送られてくるJSONを整形して吐くだけの薄いクライアントにする案です。

実装コストは一番低い。認証もセッション管理もHA側に丸投げできます。

2. 独立したFabricを立てる

mat 自身が新しいRoot CA（証明書の発行元）になり、HAとは別の、自分だけのFabricを作る案です。バックエンドは公式の参照実装 chip-tool をサブプロセスとして呼ぶところから始める前提でした。

3. 段階移行（ストラングラーパターン）

最初はHAのmatter-serverに相乗りしてCLIのインターフェース（コマンド体系や出力JSONの形）だけを先に固め、動作が安定してから裏側を独立Fabricに差し替える、という二段構えの案です。

判断基準にしたこと

3つを比べるとき、次の軸で考えました。

  • 障害の切り分けができるか——HAが重くなったり落ちたりしたとき、mat はそれに巻き込まれずに動けるか
  • Groupcast（複数機器へのマルチキャスト一斉制御）にネイティブに手が届くか——ユニキャストを1台ずつ送るのではなく、1パケットで複数ノードに同時に届けられるか
  • enl / casa の設計思想と整合するか——ステートレスなCLIと、状態を持つ常駐プロセスの役割分担がどう保てるか
  • 実装コスト——どれだけ早く動くものができるか

独立Fabricを選んだ理由

最初に切ったのは、相乗り案（選択肢1）でした。理由は単純で、動機と矛盾するからです。HAをやめたかった一番の理由は、あの重量級スタックに依存しているせいで照明のグループ制御がもたつくことでした。matter-serverにクライアントとして相乗りしても、結局は同じスタックの上で動くことになる。障害の切り分けもできないままです。

段階移行案（選択肢3）も見送りました。最初のフェーズだけとはいえ、HAのAPIに依存する期間が生まれます。当面のあいだ同じ不安定さを引きずるなら、最初から独立させたほうが早いと判断しました。

残ったのが独立Fabric（選択肢2）です。決め手は次の2つでした。

1台のコントローラが自分の証明書で機器を直接コミッショニングし直せば、Matter規格のGroupcast（IPv6マルチキャストによるグループ制御）にネイティブに手が届きます。HAを経由したユニキャストの逐次送信ではなく、1コマンド・1パケットで複数ノードに同時に届けられる。照明のグループ制御がもたついていた、そもそもの不満に一番直接効く選択でした。

もうひとつは、障害点の分離です。HAが再起動中でもアップデートで機嫌が悪くても、mat は自分のFabricから直接デバイスに話しかけられる。

捨てた道がもうひとつあった

検討の途中で、相乗り案の変種も出ました。HA側のデータベースからFabricの秘密鍵を直接抜き出して、mat に読ませるという裏技です。これなら新しいFabricを作らずに済みます。

これは早々に却下しました。HAのストレージ形式が変わった瞬間に mat も道連れで壊れますし、鍵の変換処理を自分でメンテし続けることになる。せっかく切り離すための独立Fabricなのに、依存が形を変えて残るだけでした。

代わりに使ったのが、Matter規格が正式に用意している Multi-admin という仕組みです。1台の物理デバイスは、複数のFabricに同時に所属できます。HA側でペアリングモード（コミッショニングウィンドウ）を数分だけ開き、その間に mat commission を叩けば、同じ照明が「HAの証明書」と「matの証明書」の両方を持つ状態になる。デバイスの再登録という一手間だけで、鍵を奪う裏技を使わずに独立できました。

答え合わせ

この判断から数ヶ月経った現在、mat はどうなっているか。

chip-toolのCPU100%が限界、Matterコントローラ自作へに書いたとおり、mat はいまも独立Fabricのコントローラとして動いています。バックエンドこそ chip-tool のラッパーからRustのフルスクラッチ実装に置き換わりましたが、その移行は既存Fabricの証明書をそのまま引き継ぐ形で行えました。独立Fabricという土台を最初に選んでいたからこそ、あとからバックエンドだけを差し替えるという選択肢が残っていたとも言えます。

狙いだったGroupcastも、実際にリビング照明のグループへ一斉配信できることを実機で確認できています。もたついていたグループ制御という、そもそもの不満はここで解消できました。

一点、想定と違ったこともあります。当時は「セッションキャッシュの管理は casad（家の自動化デーモン）が持つはず」と考えていました。実際に出来上がった構成では、warmなCASEセッションを保持する役目は mat 専用の常駐デーモン matd が担っています。casad はあくまで時刻・イベント起点のルール実行が仕事で、プロトコルごとのセッション管理には踏み込みません。同じ「常駐が要る」という予測は当たっていましたが、その置き場所は一段階、粒度が細かくなりました。

最初の分岐点で「独立する」と決めたことが、いまの構成の土台になっています。