MatterはなぜIPv6を使う? 家でIPv6を有効にしていなくても使える?
Matter に必要なのはローカルの IPv6 通信で、IPv6 のインターネット接続とは別です。Thread ボーダールーター、検出、権限と五つの確認項目を解説します。
Matter対応のスマートプラグを買い、自宅のスマートホームシステムに接続しようとした。ネットワーク要件を見ると、突然「IPv6が必要」という一行が目に入る。
ルーターの管理画面を開いてみると、回線にはIPv6アドレスがないようだ。家の機器は今も192.168.x.xを使っている。
プラグを使うためだけに、通信事業者へ電話しなければならないのだろうか?
通常、その必要はありません。Matterに必要なのはローカルネットワーク内でIPv6通信ができることであり、通信事業者が提供するIPv6インターネット接続が必須というわけではありません。
ただし、だからといってLAN内のIPv6をすべて無効にしてよいわけでもありません。家の機器同士がIPv6で通信できるかどうかと、IPv6でインターネットにアクセスできるかどうかは、別の問題です。
これは要件を回避するための裏技ではありません。CSAのMatter 1.4.1 Core Specificationは、「ネットワークトポロジー」の節で、通信事業者がIPv6をサポートしない場合や、ネットワークがインターネットから切断されている、あるいはファイアウォールで隔離されている場合の動作を明示的に考慮しています。[1]
では、必ずしもインターネットに接続しなくてよいのなら、MatterはなぜIPv6を使うのでしょうか? 家にはそれほど多くの機器もありません。IPv4では足りないのでしょうか?
冒頭は仮定の場面です。この記事は仕様と公式開発文書に基づいてネットワークの仕組みを説明するもので、ルーターや機器の互換性、オフライン時の性能について実機検証は行っていません。製品によっては、セットアップ、アカウントへのログイン、遠隔操作にインターネットが必要な場合があります。

AI 生成の概念イラストです。ローカルネットワークとインターネットの違いを示し、実際の構成や接続試験の結果は表していません。
一、Matterがまず解決するのは、異なるネットワークの機器に共通の言葉を使わせること
家に、Wi-Fiを使うスマートプラグ、Threadを使う電池駆動のセンサー、有線LANで接続されたコントローラーがあるとします。
消費電力も帯域幅も接続方法も異なるため、すべてを同じ無線技術に統一する必要はありません。それでも制御システムは、機器を見つける、状態を読み取る、コマンドを送る、誰に操作権限があるか確認する、といった共通の処理を行う必要があります。
Matterの役割分担は、まず次のように捉えられます。
| 階層 | 主に答える問い | ここでの例 |
|---|---|---|
| Matterのデバイスモデルとインタラクション | 機器にはどんな機能があり、どう読み取り・操作するか? | スイッチ、明るさ、温度、および関連する属性とコマンド |
| Matterのセキュリティ機構 | 誰が通信し、誰に操作権限があり、メッセージは信頼できるか? | IDを示す認証情報、セキュアセッション、アクセス制御 |
| IPv6ネットワーク | データをどこへ送り、ネットワークを越えてどう届けるか? | ユニキャスト、マルチキャスト、必要なルーティング |
| 下位のネットワーク技術 | データを具体的にどのリンクで運ぶか? | Wi-Fi、イーサネット、Thread |
これは役割を示したもので、完全なプロトコルスタックではありません。
Matterはスマートプラグ専用のアドレス体系やルーティング体系を一から作り直さず、IPネットワーク上に機器間のやり取りを構築しています。
CSA仕様のアーキテクチャの章では、MatterをIPv6ベースのスマートホーム通信プロトコルと位置付け、Wi-Fi、イーサネット、Threadのネットワークを対象とすることを説明しています。[1] Googleの開発者向け入門資料も、IPv6を使う運用時の通信と、機器のネットワーク参加に使用できるBLEを区別しています。[2]
これにより、下位の接続方式と上位の機器機能をそれぞれ進化させられます。センサーは省電力を追求し、コントローラーは有線接続を使い続けても、「温度とは何か」の定義を別のものに変える必要はありません。
二、では、なぜIPv4を使い続けず、IPv6を選んだのか?
「IPv6はアドレスが多いから」とだけ答えるのは間違いではありません。しかし、それでは家に数十台の機器しかないのに、なぜ必要なのかを説明しにくいでしょう。
Matterのアーキテクチャに即した説明には、主に三つの点があります。
第一に、Thread自体がIPv6ベースの低消費電力ネットワークです。
Threadは、まったく異なる機器用ネットワークを作り、各機能をメーカー製ゲートウェイにIPの世界へ変換させる方式ではありません。それ自体が、低消費電力機器向けにIPv6ネットワーク機能を提供します。[3]
Wi-FiとイーサネットもIPv6を運べます。MatterがIPv6を共通して使えば、異なるリンク上にあるネイティブなMatterノードが同じネットワーク層を使え、リンク間で異なるネットワークプロトコルを変換する必要を減らせます。
ただし、これだけでネットワーク間が自動的につながるわけではありません。Threadと家庭内LANの間では、境界ルーティングと、適切なアドレス・ルート設定が引き続き必要です。
第二に、IPv6は個々のアドレスだけでなく、ローカル通信やマルチキャストに必要なネットワーク機構も提供します。
Matterは特定のノードにアクセスするだけでなく、ノードのグループへメッセージを送ることもあります。Googleの開発文書には、MatterがIPv6のユニキャストとマルチキャストを使い、それぞれノードとグループにアクセスすることが明記されています。[4]
IPv6は、到達範囲の異なるアドレスにも対応しています。各センサーにインターネットから到達できる公開アドレスを割り当てなくても、機器はローカル通信に使うアドレスを持てます。
ここで注意したいのは、IPv4にもプライベートアドレスやマルチキャストなどの機能があることです。IPv6の機能を一つ残らず「IPv4にはできないこと」と説明してはいけませんし、IPv6ならグループ制御のメッセージが必ず届くとも言えません。 重要なのは、Matterが共通の通信基盤としてIPv6を選び、その上に独自のインタラクションとセキュリティの規則を定めていることです。
第三に、ネットワーク層の統一は、既存のIP技術やツールの活用に役立ちます。
Thread Groupの技術解説では、Thread、Wi-Fi、イーサネットの機器がIP機器として、より大きな一つのネットワークに接続できる点が強調されています。[5] 開発者はIPの接続性、サービス検出、ルーティングを手がかりに問題を調べられ、下位リンクごとにアプリケーションゲートウェイを定義し直す必要がありません。
これはアーキテクチャ上の利点の説明であり、IPv6が必ずIPv4より速いという意味でも、標準策定者の歴史的な判断をすべて再現したものでもありません。製品の最終的な消費電力、遅延、安定性は、無線環境、実装、処理負荷にも左右されます。
三、「公開IPv6を使っていない」と「LAN内にIPv6がない」は大きく違う
ルーターの画面にある「IPv6」スイッチは、WAN側の接続方式を制御する場合も、LAN側の設定にまで影響する場合もあります。スイッチの名前だけを見て、Matterが使えるかどうかを判断することはできません。
まず、次の三つを分けて考えましょう。
| 確認できた状況 | そこから分かること | それだけでは判断できないこと |
|---|---|---|
| 通信事業者からIPv6アドレスやプレフィックスが割り当てられていない | IPv6でインターネットに接続できない可能性がある | 家の機器同士がローカルでIPv6通信できないとは限らない |
機器に192.168.x.xのアドレスがある |
その機器はIPv4アドレスを持っている | 同時にIPv6を使っていないとは限らない |
| ネットワークインターフェースにIPv6アドレスが見える | 少なくとも一つのIPv6アドレスがある | 対象機器への到達性、サービス検出の正常動作、Matterの認可成功までは分からない |
IPv4とIPv6は同時に使えます。管理画面に見慣れたIPv4アドレスが表示されていても、その機器がIPv4しか使えないとは限りません。
逆に、fe80::で始まるリンクローカルアドレスが見えても、家全体のネットワークがつながっているとは判断できません。この種のアドレスは所属するリンク内でのみ使われ、通常のルーターで別のサブネットへ転送することはできません。Threadなど別のネットワークへ通信するには、ネットワーク間通信に適したアドレスとルートも必要です。[6][7]
Home Assistantの公式Matter文書には、IPv6インターネット接続もDHCPv6サーバーも必要ない一方、ホストのIPv6サポートを有効にし、関連するIPv6通信とマルチキャスト通信を正常に通す必要があると明記されています。[8]
したがって、調査の順序は、まずローカルのIPv6が正常に機能しているかを確認し、その後で障害が本当にインターネットに関係するかを見ることです。
オフラインテストをするなら、切断するのはインターネットへの接続です。ルーター、アクセスポイント、コントローラー、ボーダールーターの電源とローカルネットワークは維持します。ルーターごと電源を抜いてしまうと、「インターネットがない」ことだけを試すテストにはなりません。
四、Threadボーダールーターは、別の種類の「ゲートウェイ」なのか?
商品ページでは、「ゲートウェイ」「中枢」「Hub」といった言葉が混用されがちです。ただし、設計や障害調査では機能ごとに分けて考えたほうがよいでしょう。
Thread対応のMatterスマートプラグを制御する場合、通信経路は次のようになります。
Matterコントローラー → Wi-Fi/イーサネット → Threadボーダールーター → Threadネットワーク → Matterスマートプラグ。
両端が使うのはMatterです。途中のボーダールーターは主にIPデータをネットワークの境界を越えて通し、サービス検出なども支援します。OpenThreadの公式文書には、ThreadとWi-Fi/イーサネット間の双方向IP接続、およびmDNS、SRPに関連するサービス検出機能が明記されています。[7]
リンクがWi-FiからThreadに変わるというだけで、Matterの「点灯」を別のアプリケーションプロトコルの「点灯」に翻訳し直す必要はありません。
一方、Matter非対応のZigbee機器やBluetooth Mesh機器をMatterに接続する場合は事情が異なります。ブリッジは、接続先の機器の機能や状態を、Matterが理解できるデータモデルにも対応付ける必要があります。[1][2]
| 役割 | 主な責務 |
|---|---|
| 一般的な家庭用ルーター/アクセスポイント | 対応するIPネットワーク、ルーティング、Wi-Fi接続を提供する。IPv6に対応しているだけではThreadにも対応していることにはならない |
| Threadボーダールーター | Threadと隣接するIPネットワークを接続し、必要なルーティングとサービス検出を支援する |
| Matterコントローラー | 適切な権限を持つ立場でMatterノードの情報を読み取り、または制御する |
| Matterブリッジ | 他の技術を使う機器の機能をMatterのデータモデルに対応付ける |
一台のスピーカーやゲートウェイ製品が、複数の役割を兼ねることもあります。役割が一つの箱に収まっていても、それぞれの責務が同じになるわけではありません。
もう一つ誤解しやすいのは、ネットワーク上で到達できることと、制御権限があることは別だという点です。MatterのFabricは共通の信頼の起点を基に構成される論理的な範囲であり、Wi-Fiのネットワーク名でも、IPv6のサブネットでもありません。同じ家庭内ネットワークに複数のFabricが存在することもあり、制御権限はMatterの認証情報とアクセス制御によって決まります。[1]
五、Bluetoothでは機器が見つかるのに、なぜ追加に失敗するのか?
「追加する機器を見つける」ことと、「機器が通常の運用状態に入る」ことは、同じ段階ではないからです。
一般的なセットアップ手順の中には、まずBLEで機器を見つけて初期設定用の通信経路を確立し、その後Wi-FiまたはThreadのネットワークを設定するものがあります。さらに、機器を運用ネットワークに接続し、検出、セキュアセッション、最終的な参加確認を完了する必要があります。[1][2]
したがって、スマートフォンが機器をスキャンできても、その段階の検出に成功したことが分かるだけで、その後のIPv6通信まで保証されるわけではありません。
機器がネットワークに参加した後、Matterの運用時の検出にはIPベースのDNS-SDが使われます。一般的なLANではmDNSが関わります。Thread機器のサービス登録や外部からの検出には、ボーダールーター上のSRPと検出プロキシが連携する場合もあります。[4][7][9]
段階を分ければ、障害も説明しやすくなります。
- スキャンはできるが、運用ネットワークに入れない:ネットワークの認証情報、機器が対応する接続方式、Threadへの参加条件を確認する。
- ネットワークには入ったが、コントローラーが見つけられない:サービス検出がコントローラーに届くか、検出結果のIPv6アドレスへ到達できるかを確認する。
- 見つけられ、ネットワーク上でも到達できるが、制御に失敗する:Matterのセキュアセッション、Fabric、アクセス権限、機器の実装を確認する。
これらは調査の方向性であって、症状だけで根本原因を特定できるという意味ではありません。「セットアップ失敗」の一言で、Bluetooth、IPネットワーク、アプリケーションの権限という三つの段階を混同しないようにしましょう。
六、実際に問題が起きたら、まずこの五つを確認する
まず、買ったMatter機器がどの方式かを確認します。 Wi-Fi版とThread版では、必要なネットワーク条件が異なります。一般的なWi-FiルーターがIPv6に対応していても、Threadの無線インターフェースやボーダールーター機能を備えているとは限りません。
次に、コントローラーが実際に動作する環境のIPv6を確認します。 自作ゲートウェイ、仮想マシン、コンテナー環境では特に注意が必要です。ホストにIPv6アドレスがあっても、Matterサービスの実行環境に同じネットワーク接続性があるとは限りません。
機器同士が隔離されていないか確認します。 ゲストネットワーク、APのクライアント分離、VLAN、ファイアウォールのポリシーによって、それぞれの機器はインターネットに接続できても、必要な相互検出や通信ができない場合があります。初回の確認では、信頼でき、構成が単純で、機器間が通信できるローカルネットワークで基準となる動作を確かめ、その後で隔離ポリシーを段階的に加えるとよいでしょう。[8]
「検出」と「通信」を別々に調べます。 DNS-SD/mDNSが担うのは、サービスと接続情報を見つけることです。その後も、正しいIPv6経路で機器にアクセスできなければなりません。VLANをまたぐ場合、mDNSリレーを一つ追加しただけで、アドレス、ルート、マルチキャスト、アクセスルールがすべて整ったことにはなりません。
最後に、ローカル制御とクラウド機能を区別します。 通信事業者のIPv6、メーカーのアカウント、遠隔操作、音声サービス、ファームウェアのダウンロードには、それぞれ異なる依存関係があり得ます。Matterにローカル制御機能があることは、特定の製品が初回セットアップからすべての付加機能まで完全にオフラインで使えることを意味しません。[8]
毎回、「どの段階で失敗したか、両端はどのネットワークにいたか、検出でどんなアドレスが返ったか、実際の接続は成功したか」を記録することを勧めます。「このルーターは非対応」とだけ残すより、調査に役立ちます。
Matterの接続を試すために、ルーターのファイアウォールを丸ごと無効にする必要もありません。まずローカルの通信経路に足りない機能や遮断されている通信を特定し、対象を絞って調整しましょう。
七、IPv6を使うことは、機器がインターネットに直接公開されることではない
最後に、よくある二つの誤解を整理します。
IPv6アドレスは「誰でも遠隔操作できる」ための通行証ではありません。 インターネットから機器に到達できるかどうかは、アドレスの種類、ルーティング、ファイアウォールによって決まります。ネットワーク上で到達できても、Matterには独自の認証、暗号化、アクセス制御があります。[1]
IPv6によって通信が自動的に安全になるわけでもありません。 Matterのセキュリティは、具体的な認証情報、セッション、メッセージの保護、権限の仕組みと、製品の適切な実装・保守によって成り立ちます。「IPv6を使っているから安全」と単純化はできません。
冒頭のスマートプラグに戻りましょう。最初に確認すべきなのは、プラグとコントローラーの間に、サービスを検出でき、IPv6データを運べ、適切な権限も備えたローカルの通信経路があるかどうかです。
MatterがIPv6を選んだことで、接続方式の異なる機器が共通のネットワーク基盤を使えます。まずそのローカルの経路を整えることが、公開IPv6アドレスを申請することよりも、問題に即した対応です。
参考資料と確認範囲
資料の確認日:2026-11-06。この記事では、確認可能な仕様の版としてMatter 1.4.1を引用しており、最新版とは記していません。また、特定メーカーの手順書から、すべてのエコシステムにおける互換性を推定していません。
- CSA:Matter Core Specification 1.4.1、2025-03-17。主に2.1–2.4、2.7–2.8のアーキテクチャ、ネットワークトポロジー、公開IPv6がない場合の動作、Fabric、セキュリティ、参加手順を確認。
- Google Home Developers:What is Matter?。運用時の通信でのIPv6の使用、BLEの機器参加時の用途、ブリッジの概念を確認。自動翻訳による曖昧さを避けるため、英語の本文を使用。
- OpenThread:What is Thread?。Threadが低消費電力機器向けのIPv6ネットワークであることを確認。
- Google Home Developers:Thread and IPv6。ユニキャスト、マルチキャスト、ボーダールーティング、検出プロキシを確認。記載されたスループットや遅延の例は製品の性能指標として引用していない。
- Thread Group:Multiple Thread Networks and The Seamless Interconnectivity of IP、2023-08-24。リンクをまたぐIP接続の利点を理解するために参照。ネットワーク上の到達性とMatterの認可は区別する必要がある。
- OpenThread:IPv6 Addressing。アドレスの到達範囲と、同じ機器が複数のアドレスを持ち得ることを確認。Thread内のアドレスを一律にネットワーク間で到達可能なアドレスとは扱っていない。
- OpenThread:Border Router。ボーダールーティング、mDNS/SRPによるサービス検出、リンクローカルアドレスが境界を越えて転送されないことを確認。
- Home Assistant:Matterの公式統合ドキュメント。主にIntroductionとGeneral recommendationsを参照。ローカル制御とIPv6の設定要件を相互に確認するために使用し、Home Assistant固有のセットアップ手順は他のプラットフォームに当てはめていない。
- Google Home Developers:Commissionable and Operational Discovery。機器参加時の検出と運用時の検出の違い、DNS-SD、Threadのサービス登録プロキシを確認。
コメント・議論
質問や実践の経験をお寄せください。コメントは承認後に表示されます。メールアドレスは公開されません。 コメントのプライバシー
コメントを読み込み中…