Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — ハブの心臓を入れ替えたアップデート
背景 — Matterサーバーは正確には何をしているのか
タイムライン — 寄贈から片道GAまで
良くなった点 — 再起動、OTA、コミッショニングのセキュリティ
支払うもの — RAM2倍、片道切符、若いコードベース
仕様の速度 — Matter 1.5.1、1.6、そして4週間
急がないほうがいい場合
おわりに
参考資料

はじめに — ハブの心臓を入れ替えたアップデート

自宅でHome Assistantを動かしている人にとって、去る6月23日は静かながら大きな日でした。Open Home Foundationの発表とともにMatter Serverアプリ(旧アドオン)が9.0に上がりましたが、これはバージョン番号ひとつの話ではなく、実装そのものの入れ替えでした。Pythonで書かれ公式C++ Matter SDKをラップしていたサーバーが、TypeScriptで最初から書き直されたmatter.jsベースのサーバーに置き換わったのです。

これが他人事でない理由は規模にあります。発表文が引用するオプトイン統計によれば、Matter統合はHome Assistantインスタンスの38%で動いており、全統合の中で利用率12位です。その38%の家庭で、Matterデバイスと会話するプロセスが丸ごと別のコードベースに置き換わったことになります。そしてこのマイグレーションは片道です — 公式FAQの表現をそのまま借りれば、「旧サーバーに戻れるか」という問いへの答えは「No」です。

スマートホームエコシステム全体の見取り図は昨年書いた「スマートホーム & Matter 2026」徹底ガイドで扱ったので、本稿は今回の移行一件に絞ります。なぜ変えたのか、実際に何が良くなるのか、そして請求書に何が書かれているのか。

背景 — Matterサーバーは正確には何をしているのか

Home AssistantのMatterサポートはコアの中には入っていません。Matter統合(コア)はWebSocket経由で別プロセスであるMatterサーバーに接続し、実際のMatterコントローラーの役割 — コミッショニング、セッション暗号化、サブスクリプション、OTA — はすべてそのサーバーが担います。月次のコアリリースとサーバーリリースは分離されている構造なので、今回の入れ替えも2026.7コアリリース(7月1日)とは別に、アプリのアップデート一回だけで配信されました。ちなみに2026.7リリースノートでMatter関連の項目は、土壌水分センサー対応の追加くらいしかありません — 本当に大きな変化はコアの外で起きたのです。

構造を図にするとこうなります。

[以前]  Home Assistant (Matter統合)
          │  WebSocket
          ▼
        python-matter-server  ── Pythonラッパー
          │
          ▼
        公式 Matter SDK (C++ · project-chip/connectedhomeip)

[以後]  Home Assistant (Matter統合)   ← コード変更なし
          │  WebSocket (同一API)
          ▼
        matterjs-server + matter.js (TypeScript単一スタック · Node.jsランタイム)

以前のサーバーであるpython-matter-serverは公式C++ SDKの上にPythonを乗せた構造で、2025年3月にはHome AssistantとともにCSA認証まで受けました — オープンソースプロジェクトとしては初めてでした。ところが発表文はこの構造について「堅実な出発点ではあったが、私たちのオープンソースの野心の速度についてこられなかった」と書いています。認証まで受けたスタックを15か月で手放した理由が、この一文に詰まっています。

matter.jsはMatter標準をTypeScriptで完全に再実装したプロジェクトです。リポジトリはMatterの正式リリース直後にあたる2022年11月から存在し、発表文によればHomebridgeとopenHABのMatterサポートもこのライブラリの上で動いています。作者のIngo Fischerは2025年後半にOpen Home Foundationにフルタイムで加わりながらmatter.jsを財団に寄贈し、財団は2025年11月26日のニュースレターでMatterサーバーをmatter.jsの上に作り直す計画を正式発表しました。

タイムライン — 寄贈から片道GAまで

移行は不意打ちではなく、半年がかりの公開移行でした。日付はすべてGitHubのコミット・リリース履歴で確認したものです。

日付	出来事
2025-11-26	OHF、matter.js寄贈とサーバー再構築計画を発表
2026-01-22	アドオン8.2.0 — ベータフラグを有効にするとmatter.jsサーバーへ切り替え(双方向に切り替え可能)
2026-06-09	matterjs-server 1.0.0
2026-06-17	CSA、Matter 1.6仕様を公開
2026-06-23	アプリ9.0.0 GA — matter.jsサーバーがデフォルトに、マイグレーションは片道。同日、python-matter-serverリポジトリをアーカイブ化
2026-07-01	HAコア2026.7リリース。matter.jsにMatter 1.6.0サポートPRがマージ
2026-07-15	アプリ9.1.0 — Matter 1.6.0サポートを搭載

ベータ期間中はデータが自動でマイグレーションされつつもPythonサーバーへ戻すことができましたが、9.0.0 GA以降はそれができません。そのため告知とFAQはアップデート前のバックアップを繰り返し推奨しています — ロールバック手段がバックアップしかないためです。ノード数が多い場合、初回起動(ストレージマイグレーション+全数インタビュー)はかなり時間がかかるため、途中で再起動をかけてしまうHAウォッチドッグを一時的に無効化しておくよう、マイグレーションFAQにも明記されています。

良くなった点 — 再起動、OTA、コミッショニングのセキュリティ

マーケティング文句を取り除き、FAQとチェンジログに書かれた具体的な変化だけを拾うとこうなります。

再起動と再接続。 旧サーバーは起動のたびにデバイスを最初から探し直し、全数インタビューを回していました。新サーバーはデバイスの最終アドレスを記憶して直接つながり、再接続時には変わったデータだけを取得する部分インタビューを使います。Threadデバイスが多い環境では、Threadネットワークの帯域幅の限界を尊重しながら接続するという項目もFAQに別途書かれています — 低電力メッシュネットワークに再起動の嵐を浴びせないという意味です。

OTAアップデート。 旧サーバーはデバイスファームウェアのOTAのためにMatterネットワークへ一時的なノードを別途立てており、FAQ自身が「しばしば問題を引き起こした」と認めています。新サーバーはOTAロジックをコントローラーの中に統合しました。

コミッショニングのセキュリティ既定値。 旧サーバーは開発・テスト証明書しか持たない未認証デバイスもデフォルトでコミッショニングしていました。DIYデバイスを接続するには便利ですが、悪意あるデバイスが静かにファブリックへ入り込む通り道でもありました。新サーバーはこれを逆転させ、テスト証明書デバイスを接続するにはTest-Net DCLオプションを明示的に有効化する必要があります。コミッショニング時の証明書失効(revocation)リスト確認も追加されました。

オフラインコミッショニング。 証明書検証に必要なDCLデータをリリース時点のスナップショットとしてサーバーに同梱し、インターネットなしでもその時点まで登録済みのデバイスはコミッショニングできます。インターネットに接続されればバックグラウンドで更新します。ただしREADMEが明かす通り、同梱データは古くなり得るため、その間に出たデバイスはオフライン状態でコミッショニングに失敗することがあります — 制御はローカルでも、コミッショニング時点の信頼確認は依然としてインターネットを必要とするという、local-firstの観点で覚えておくべき点です。

ネットワーク可視化。 サーバーのWeb UIにThread/Wi-Fiトポロジービューが加わりました。ノードごとに役割(リーダー、ルーター、スリーピーエンドデバイス)が表示され、リンクの色で接続品質を示します。デバイスとボーダールーターの間にホップが複数生じるThreadメッシュで特に有用です。正直な注記も添えられています — スリーピーなバッテリーデバイスはネットワーク情報を頻繁に更新しないため、可視化に表示される「Unknown devices」や「External routers」は古いデータの可能性があるとFAQがあらかじめ釘を刺しています。

このほか、コミッショニングをHome AssistantのBluetoothスタック(ESPHome BLEプロキシを含む)経由にする実験的機能ble_proxy、9.1.0で追加されたデバイス時刻同期(time_sync)とICD(間欠接続デバイス)管理の実験的サポートなどがチェンジログに積み上がっています。

支払うもの — RAM2倍、片道切符、若いコードベース

次は請求書の番です。

メモリ。 公式の数値です。新サーバーは旧サーバーの約2倍のRAMと、やや多めのCPUを使います(マイグレーションFAQに基づく、ベンダー自身の記述であり測定条件は公開されていません)。アドオンコンテナにNode.jsランタイムが丸ごと入る構造なので、驚くことではありません。リリースノートもアップデート前にホストの余裕リソースを確認するよう案内しています — Raspberry Piクラスのボードでアドオンを複数動かす一般的な構成では特にそうです。

片道マイグレーション。 改めて強調しますが、GA以降はPythonサーバーへ戻る公式な経路はありません。バックアップだけが唯一の脱出口です。

生まれたてのコードベース。 GAが滑らかだったわけでもありません。9.0.0リリース後10日以内にアドオンのパッチが4回(9.0.1〜9.0.4)出て、9.0.4のチェンジログはサーバーを1.1.2から1.1.7へ上げつつ「報告された問題の解決とRAM/CPU使用量の大幅な最適化」を理由に挙げています。matterjs-serverのチェンジログを数えると、GA以降7月16日までの3週間あまりでサーバーリリースが14回です。素早い対応と読むこともできれば、まだ揺れている最中と読むこともできる数字です — おそらく両方とも事実でしょう。FAQのトラブルシューティングセクションには、マイグレーション失敗でストレージが壊れた場合にデータディレクトリを直接削除する手順や、初回起動後にデバイスがオフラインのまま残る場合(mDNSアドバタイズの欠落)は電源を入れ直せという案内が、すでに掲載されています。

再認証はまだ。 2025年のCSA認証はPythonベースのサーバーが取得したものです。matterjs-serverのREADMEは、現行の実装が「まだCSA再認証を受けておらず、今後受ける予定である」と明記しています。認証状態が重要な環境であれば、今のサーバーはその空白の中にあります。

仕様の速度 — Matter 1.5.1、1.6、そして4週間

今回の移行の本当の意味は、今年のCSAのリリースカレンダーと重ねて初めて見えてきます。

3月31日、CSAはMatter 1.5.1を出しました。1.5が導入したカメラ・ドアベル対応の上に、マルチストリーム転送(録画用の高解像度+モバイル用の低解像度+分析用ストリームを一つのセッションに)、HEICスナップショット、CMAFベースのHLS/DASHアップロード、PTZ動作の改善を加えた増分リリースです。6月17日にはMatter 1.6が登場しました。新しいデバイスカテゴリはなく、代わりにNFCだけでコミッショニングの全工程を終えるNFCベースコミッショニング(1.4.1のNFCタグはセットアップ情報だけを保持しBLEが必要でした — 天井照明を取り付ける前にスマホをかざして登録するというシナリオが、いまや仕様の中にあります)、複数のエコシステムが一つのファブリックを共同管理するJoint Fabric、サーモスタットに直接コマンドを送る代わりに期限付きの提案を送るThermostat Suggestionsが中核です。

ここで新スタックの速度が現れます。仕様公開が6月17日、matter.jsのMatter 1.6.0サポートPRのマージが7月1日、それを搭載したサーバー1.2.0が7月9日、Home Assistantユーザーに配信されたアプリ9.1.0が7月15日。仕様から安定チャンネルまで正確に4週間です。発表文が6月に「1.6はまもなく」と書いたとき、その「まもなく」は3週間でした。公式C++ SDKのリリースサイクルに縛られていた時代には構造的に出しにくい速度であり、「公式SDKが私たちの速度についてこられない」というあの一文の実証でもあります。

標準エコシステムの観点でも意味があります。仕様が事実上単一の実装に従属してしまうと、実装のバグがそのまま標準の挙動になってしまいます。TLSやHTTPがそうだったように、大規模に稼働する独立実装がもう一つ増えることは標準の健全性にとって良いことです — いまやMatterには、商用エコシステム全体が使うC++実装と、最大のオープンソースホームプラットフォームに実配備されたTypeScript実装が並び立っています。

急がないほうがいい場合

まとめると、次のような場合はアップデートボタンをすぐには押さないのが合理的です。

ホストのメモリに余裕がないとき。 RAM約2倍は公式の数値です。2GBクラスのボードでアドオンをすでに複数目一杯動かしているなら、まず計算から始めてください。
Matterノードが多く、中断が痛いとき。 初回起動はマイグレーション+全数インタビューで時間がかかり、ロールバックはバックアップの復元だけです。平日の夜に気軽にやることではありません。
開発・テスト証明書のDIYデバイスを使っているとき。 自作したMatterファームウェア(ESP32など)を接続してきたなら、これからはTest-Net DCLオプションを有効にしないとコミッショニングできません。知らずに詰まると、デバイス故障のように見えます。
認証状態が要件になっているとき。 CSA再認証前という事実が問題になる環境なら、それは待つ理由になります。
あと数週間様子を見たいとき。 3週間で14リリースというパッチの速さは活発さの証拠であると同時に、あなたの構成でまだ踏むかもしれない小石が残っている可能性の合図でもあります。イシュートラッカーを一通り見てから決めても遅くはありません。

逆に、Threadデバイスが数十台つながった家で、サーバー再起動のたびに数分間デバイスが死んだままになるのが持病だったなら — 部分インタビューとアドレスキャッシュだけでも、今回のアップグレードは十分に元が取れます。

おわりに

世界最大のオープンソーススマートホームプラットフォームが、認証まで取得していた公式SDKベースのスタックを15か月で手放し、TypeScript再実装へ乗り換えました。大義は抽象的な性能ではなく速度の主導権であり、GAからわずか4週間で最新仕様(1.6)を安定チャンネルに載せることで、その大義を自ら証明してみせました。代償は明示的です — RAM2倍、片道マイグレーション、再認証の空白、そして若いコードベースが経験する初期のパッチラッシュ。

あなたのHome Assistantが数個のMatterデバイスを静かに動かしているだけなら、この移行にはおそらく気づかないまま通り過ぎるでしょう — ドロップイン互換が目標であり、おおむねその通りに動作しているからです。ただし、アップデート前のバックアップだけは必ず取っておいてください。今回のチケットは片道です。