Zigbee・Wi‑Fi・Bluetooth比較と選び方 - TsukuLab | ツクラボ

Zigbee・Wi‑Fi・Bluetoothの違いを先に結論で整理

スペック早見表

先に結論だけ置くと、小さなデータを低消費電力でたくさん集めるなら『Zigbee』、画像や動画、IP機器としてそのままネットにつなぐなら『Wi‑Fi』、スマホと近距離で直接つなぐならBluetooth、その中でも電池駆動のセンサー寄りならBLEです。

CSA Zigbee公式では『Zigbee』を低消費電力のスマートホーム向け規格として位置づけており、Bluetooth Market Update 2025でもBluetoothがスマホ連携や周辺機器の広い土台であることがわかります。
3つは競合というより、得意分野がほぼ分業されています。

理論値と実際の使い勝手がズレやすいので、そこを分けて見ると判断を誤りません。

項目	Zigbee	Wi‑Fi	Bluetooth
主用途	温湿度、開閉、人感、照明、スイッチ	カメラ、画像送信、LAN接続、OTA更新	イヤホン、キーボード、ビーコン、スマホ連携機器
	速度（理論値）	250 kbps	数百Mbps〜Gbps級
	速度（実用の目安）	実測報告の例で約100〜200 kbps程度（解像度・フレームレート・スタックにより変動）	家庭内通信やインターネット接続に十分な帯域を確保しやすい
	屋内距離の目安	10〜30 m（環境依存）	20 m前後（壁材・AP配置で変動）
消費電力	低い	高い	低い。BLEはとくに低い
接続台数	仕様上は最大65,536台を識別可能	台数が増えるほどAP側の設計が効く	小規模〜近距離向き
メッシュ有無	あり	規格の中心はAP配下。メッシュ製品はある	用途によりMeshあり
スマホ直結	基本はハブやゲートウェイ前提	可能	得意。BLE機器はここが強い
ゲートウェイ要否	多くの場合で必要	通常は不要	スマホ直結なら不要
インターネット接続のしやすさ	ハブ経由でつなぐ構成が基本	そのままIP機器として扱いやすい	スマホ経由や専用アプリ連携が中心
導入コスト感	ハブ込みで考える必要あり	単体導入はわかりやすいが、台数が増えると無線設計の負担が出る	小規模構成なら始めやすい

一方で、たとえば『ESP32‑CAM』のように画像を扱う機器は話が別です。
小さなセンサー向けの『Zigbee』ではなく、『Wi‑Fi』でIP直結にしたほうが構成が自然です。
画像、動画、大きめのファーム更新が絡むなら、ここは最初から『Wi‑Fi』前提で考えたほうが迷いません。

Zigbee Home Automation

Instructions on how to integrate your Zigbee Home Automation (ZHA) devices within Home Assistant.

home-assistant.io

用途別ショートアンサー

用途ごとに一言で切るなら、まず電池で1年以上動かしたいなら『Zigbee』かBLEです。
温湿度、開閉、人感のような小さなデータを定期送信する用途では、この2つが本命になります。
『Zigbee』はネットワーク全体として多数センサーを束ねるのが得意で、BLEは単体の低消費電力機器やスマホ連携機器で光ります。

画像、動画、大きなファーム更新を扱うなら『Wi‑Fi』です。
速度の余裕だけでなく、IP機器としてそのままLANに参加できるので、カメラや高頻度ログ送信では設計が素直です。
『ESP32』系でも、センサー用途ならBLEや別系統の無線を検討したくなりますが、映像系では『Wi‑Fi』の優位がはっきり出ます。

スマホ直結で近距離操作したいならBluetooth、とくにBLEが合います。
スマートロック、タグ、ビーコン、初期設定用デバイスではこの強みがそのまま使えます。
筆者宅でもBLEビーコンを玄関まわりのプレゼンス検知に使うと反応は良好でした。
帰宅判定のように玄関周辺だけを見たいなら相性がいいのですが、家全体を一つの受信点でカバーする発想だと届き方に偏りが出るので、受信点の置き方や中継の考え方が必要になります。

家全体にセンサーを多数置くなら『Zigbee』です。
これは単に低消費電力だからではなく、スター、ツリー、メッシュの構成を取れて、照明やスマートプラグのような常時給電機器を経由点に育てられるからです。
Home Assistant ZHAのドキュメントでも、ネットワーク規模が大きくなると構成の組み方が安定性に直結することが読み取れます。
実際、部屋ごとにルータ役の機器が入るだけで、センサーの居場所がぐっと増えます。

3問で決める判断フロー

迷ったときは、質問を3つだけに絞ると決まりやすくなります。

その機器は電池駆動が前提ですか。
Yesなら候補は『Zigbee』かBLEです。センサーやボタン、タグ、ビーコンの多くがここに該当します。Noなら『Wi‑Fi』も有力になります。
スマホと直接つながることが主要要件ですか。
YesならBluetooth、とくにBLEが先頭です。
ペアリング、近距離操作、初期設定の導線まで含めて筋が通ります。
Noなら、家の中のハブやコーディネータ経由で束ねる『Zigbee』、またはLAN直結の『Wi‑Fi』へ進みます。
流すデータは小さいですか。
Yesなら『Zigbee』かBLEです。
温度、湿度、開閉、在室、ボタンイベント程度なら十分収まります。
Noなら『Wi‑Fi』です。
画像、動画、音声、重めの更新データはここで切り分けると早いです。

この3つの条件で整理すると、選択肢は狭まります。
たとえば「電池駆動で、スマホ直結は必須ではなく、送るのは温湿度だけ」なら『Zigbee』が自然です。
「電源は取れて、スマホ直結は不要、でも画像を送る」なら『Wi‑Fi』一択に近づきます。
「ボタン電池で、スマホに近づいたときだけ存在判定したい」ならBLEが収まりどころになります。

TIP

[!NOTE] 家の中にセンサーを増やすほど、速度より「どの規格がどの役割を持つか」の切り分けが効いてきます。
筆者はセンサー群を『Zigbee』、カメラや『ESP32‑CAM』を『Wi‑Fi』、近距離の在室補助をBLEに分けてから、無線まわりのトラブルを追う時間が減りました。

まず押さえたい3規格の基本

Zigbeeの成り立ちと層構造

『Zigbee』は、無線の土台として IEEE 802.15.4 を使う規格です。
ここでいう土台とは、電波の飛ばし方やフレームのやり取りといった物理層 / MAC層の部分です。
その上に、『Zigbee』独自のネットワーク層とアプリケーション層が載っています。
つまり、802.15.4が「無線でどう話すか」を決め、『Zigbee』が「どうつながり、どんな役割で動くか」を決めている構造です。

この分け方を知っておくと、「802.15.4対応」と「Zigbee対応」が同じ意味ではないことも見えてきます。
たとえば802.15.4系の無線チップを使っていても、上位でThreadを動かすのか『Zigbee』を動かすのかで、ネットワークの作り方も相互接続の前提も変わります。
スマートホームで『Zigbee』を語るときは、チップ単体ではなく、上位のネットワーク規格まで含めて見るのがポイントです。

ネットワーク上の役割は、主に3つです。コーディネータはネットワークの親玉で、ネットワーク作成や参加管理の中心になります。
『Home Assistant』で『ZHA』を使う場合、USBドングル型のコーディネータを1台挿して、この役を持たせる構成が定番です。
SONOFF Zigbee 3.0 USB Dongle PlusやConBee IIのような製品名がよく出てくるのはこのためです。ルータは中継役で、常時給電されるスマートプラグや照明機器が担うことが多く、ネットワークの届く範囲を家の中へ広げます。エンドデバイスは温湿度センサーや開閉センサーのような末端機器で、電池動作を優先して必要なときだけ起きる設計が中心です。

トポロジーはスター / ツリー / メッシュに対応します。
初心者目線では、ここで「メッシュ」がいちばん効く言葉です。
コーディネータから直接届かない場所でも、途中にルータを置けば経路を作れます。
筆者宅でも、最初はUSBドングルの近くでは安定していたのに、廊下の先のセンサーだけ通知が抜けることがありました。
そこで常時給電の機器を1つ中継点として入れると、ネットワーク全体の見え方が変わります。
『Zigbee』は単体の到達距離だけで考えるより、家のどこにルータ役を置くかで実運用が決まる規格です。

この構造は、ゲートウェイの位置づけとも直結します。
『Zigbee』機器はスマホがそのまま相手になるというより、ハブやゲートウェイの後ろにまとまる形が基本です。
筆者は『Home Assistant』に『ZHA』を入れ、Zigbeeのセンサー群をそちらへ集約し、別系統で『ESPHome』のWi‑Fi機器とBLE機器を並べています。
構成図にすると、『Home Assistant』が中央にいて、片側に『ZHA』配下のZigbeeネットワーク、もう片側に『ESPHome』配下のIP機器とBLE連携機器が並ぶ形です。
この並びにすると、Zigbeeは「電池センサーの居場所」、Wi‑Fiは「IPで直接しゃべる機器の居場所」と整理できます。
規格の説明だけ読むより、家庭内での置き場所まで含めて見ると理解が進みます。

CSA Zigbee公式CSA Zigbee公式でも、Zigbeeは相互運用を前提にした低消費電力メッシュとして位置づけられています。
新しい動きとしてはZigbee 4.0 / Suzi 発表新しい動きとしてはZigbee 4.0 / Suzi 発表も出てきています。
とはいえ、このセクションではまず、802.15.4の上にZigbeeのネットワークとアプリ層が載る、という基本形を押さえておけば十分です。

Wi‑Fiの役割と認証

『Wi‑Fi』は IEEE 802.11系 を基盤にした無線LANです。
スマートホーム文脈では、センサー網そのものというより、家庭内LANとインターネットに直結するための主力回線として見ると整理しやすくなります。
IPアドレスを持って、TCP/IPでそのまま通信できるので、Web API、MQTT、OTA更新、画像転送のような用途と相性がいいわけです。

周波数帯は主に 2.4GHz / 5GHz / 6GHz を使います。
ここで大切なのは帯域の細かな仕様を全部覚えることではなく、『Wi‑Fi』は速度とIP接続のしやすさを取りにいく規格だという点です。
『ESP32』のようなマイコンでも802.11 b/g/nの2.4GHz帯に乗れるので、センサー値を直接『Home Assistant』へ送ったり、Web UIを持たせたり、ログを投げたりできます。
『ESP32‑CAM』のように画像を扱う機器になると、この「LANにそのまま載る」という性質が効いてきます。
Zigbeeで向くのは状態通知ですが、画像ストリームはWi‑Fiの担当、という切り分けです。

ネットワーク形態は、家庭ではアクセスポイント中心のインフラモードが主流です。
つまり、各機器がルーターやAPへぶら下がり、そこを経由してLANやインターネットへ出ていきます。
メッシュWi‑Fi製品もありますが、規格の中心はあくまで「APを中心にした無線LAN」です。
ここが『Zigbee』のメッシュと発想の違うところで、Wi‑Fi機器を増やすときは、中継ノードの配置よりもAP側の収容力や電波設計が効いてきます。

認証の話も押さえておくと混乱が減ります。
『Wi‑Fi』はIEEE 802.11という標準規格を土台にしていますが、市場で「Wi‑Fi対応」として安心材料になるのは、『Wi‑Fi Alliance』の相互運用認証です。
『Wi‑Fi Alliance』はWi‑Fi CERTIFIEDプログラムを運営していて、他社製品とつながるか、セキュリティ要件を満たすかを検証しています。
つまり、802.11は技術仕様、Wi‑Fi認証は実際に混在環境で動かすための目印と見るとわかりやすいです。

実際の構成でも、『Wi‑Fi』は「単独で完結する」より「既存LANに自然に溶け込む」側面が強いです。
筆者が『Home Assistant』へ『ESPHome』をつないでいるときも、Wi‑Fi機器はZigbeeのように別ハブ配下にまとめるというより、家庭内のIPネットワークへ直接参加させています。
構成図にすると、『Home Assistant』本体、Wi‑Fiルーター、そこへつながる『ESP32』機器群という並びになり、ZigbeeだけがUSBドングル経由の別ネットワークになります。
この差を体で理解すると、Wi‑Fiは「速い無線」ではなく、LANの一員として扱える無線だと見えてきます。

Wi-Fi Alliance

wi-fi.org

Bluetooth ClassicとBLEの違い

Bluetoothは 2.4GHz帯を使う近距離無線で、スマホ、イヤホン、キーボード、マウス、ビーコンなどに広く使われています。
ただし、ひとまとめに「Bluetooth」と言っても、中身は大きく2系統あります。Bluetooth Classic と BLE（Bluetooth Low Energy） です。
ここを分けて考えないと、「Bluetoothなら何でも同じ」と見えてしまいます。

まず押さえたいのは役割の違いです。Bluetooth Classic は、オーディオや継続的なデータ転送のような用途で育ってきた系統です。
ワイヤレスイヤホンやスピーカー、従来型の周辺機器が代表例です。
一方の BLE は、低消費電力を主眼にした設計で、センサー値の通知、ビーコン、タグ、スマホアプリからの設定、ウェアラブル機器の状態取得といった用途に向いています。
スマートホームで「Bluetooth対応」と書かれていたら、実際に見ているのはBLE側であることが多いです。

図にすると、整理は次のようになります。

系統	向く用途	通信の性格	スマートホームでの立ち位置
Bluetooth Classic	オーディオ、従来型周辺機器	継続的な近距離接続	イヤホン、スピーカー、入力機器向け
BLE	センサー、ビーコン、設定連携	小さいデータを低消費電力でやり取り	スマホ連携センサー、タグ、ロック、プレゼンス検知向け

BLEではGATT（Generic Attribute Profile） という考え方が中心になります。
難しく見えますが、要するに「デバイスが持っている情報を、サービスと特性という単位で読み書きする」仕組みです。
温度、電池残量、ボタン状態のような小さな情報を、必要なときに取得するイメージです。
スマホアプリがBLE機器と相性がいいのは、この粒度で状態を扱えるからです。

スマホ直結のしやすさは、この3規格の中でBluetoothがいちばん強いところです。
ペアリングや近距離セットアップの文脈では、BLEは入口として扱いやすく、初期設定だけBLE、常用はWi‑Fiという製品設計も珍しくありません。
筆者も『ESPHome』系の構成で、Wi‑Fi常用の機器とBLEの近距離検知を同居させていますが、BLEは「スマホや受信点の近くで完結する役割」を与えると収まりがいいです。
玄関付近の在室判定や一時的な設定リンクでは素直に動き、家全体の常時監視を丸ごと任せると設計の軸がぶれます。
BLEは万能な家全体ネットワークではなく、近距離で意味のある情報を取る規格として使うと持ち味が出ます。

BluetoothにもBluetooth Meshがあります。
これは照明やビル制御のように、多数ノードを中継しながら動かす仕組みです。
ただ、スマホ直結の気軽さと、メッシュの運用設計は別の話です。
メッシュ化すると経路設計や転送制御の考え方が入ってきて、BLE単体の「近くの機器とつなぐ」感覚とは使い勝手が変わります。
Silicon Labs メッシュ性能比較（https://www.silabs.com/wireless/multiprotocol/mesh-performanceでも、ペイロードやスループットの要求が上がる場面ではZigbee系が有利な整理になっています。
Bluetooth Meshは存在感のある技術ですが、スマートホーム入門でまず覚えるなら、Classicはオーディオ寄り、BLEは低消費電力センサー寄り、そしてメッシュは別レイヤーの設計課題が増える、と切り分けると理解がぶれません）。

Bluetooth Market Update 2025（https://www.bluetooth.com/ja-jp/bluetooth-resources/bluetooth-market-update-2025/でも、BLEはセンサーやロケーション、周辺機器の広い領域を支える前提で見られています。
ここで必要なのは市場規模の数字を覚えることではなく、Bluetoothの中でもClassicとBLEでは守備範囲が違うと把握することです。
スマホと近距離でつながる体験を作るならBLE、音や従来型周辺機器ならClassic、家全体の電池センサーネットワークならZigbeeも候補、という形で頭の中の棚を分けると迷いが減ります）。

ESPHome

Smart Home Made Simple. ESPHome turns ESP32, ESP8266, and RP2040 microcontrollers into fully-featured smart home devices

esphome.io

比較表で見る通信速度・距離・消費電力・接続台数

主要スペック比較表

選定で迷いやすいのは、単純な「速い・遅い」ではなく、どのくらい離れて届くか、電池で回せるか、何台まで増やせるか、スマホやインターネットとどうつながるかです。
そこを同じ軸で並べると、3規格の役割分担が見えます。

項目	Zigbee	Wi‑Fi	Bluetooth
通信速度（理論値）	2.4GHz帯で250 kbps	数百Mbps〜Gbps級	近距離・小容量向け
通信速度（実用の目安）	実測報告の例で約100〜200 kbps程度（環境・実装で大きく変動するため測定推奨）	インターネット接続や画像転送に向く帯域を確保しやすい	BLEはセンサー通知や設定連携向き
通信距離（屋内目安）	10〜20 m程度（遮蔽物や配置で変動。好条件で30 m程度の報告あり）	約20 m前後（環境依存）	約10〜100 m（クラス/実装に依存）
電池駆動のしやすさ	向いている	常時接続では不利	BLEならボタン電池1つで長時間動作する構成がある
接続台数 / 拡張性	仕様上は最大65,536台を識別可能（実運用はコーディネータ性能や配置に依存）	APやルーター中心。台数増加で無線設計の質が効く	小規模・近距離の構成向き
メッシュ有無	あり	規格の中心はAP配下。製品としてのメッシュWi‑Fiはある	用途によりBluetooth Meshあり
スマホ対応	直接つなぐよりハブやゲートウェイ経由が基本	IP機器として扱いやすい	スマホ直結が得意
インターネット接続のしやすさ	ハブ経由でつなぐ構成が基本	そのままネットワークに載せやすい	スマホアプリ経由や専用ゲートウェイ経由が中心
導入コスト感	USBドングルやハブを含めて考える必要あり。価格は流通レンジで変動します（参考価格）	単体導入はが、台数が増えると無線設計の負担が出る	小規模なら入りやすい。スマホを起点に完結する機器が多い
スリープ復帰時間	実装依存。実測報告の目安として数ms〜数十msの幅があり、環境やスタックで変動するため測定推奨	非公表	非公表

具体的な導入イメージとしては、『Home Assistant』に『ZHA』やzigbee2mqttを組み合わせ、SONOFF Zigbee 3.0 USB Dongle PlusやConBee IIをコーディネーターにする構成が定番です。
外部アンテナ付きや出力に余裕のあるドングルは、家の中央付近に置いたときの到達性で差が出やすく、USB延長ケーブルで本体から少し離して設置しただけでリンク品質のばらつきが落ち着く場面がありました。

一方で、Wi‑Fiは速度面の余裕が大きく、『ESP32‑CAM』のような画像を扱う機器では選択肢から外れません。
MJPEGストリーミングのような用途は、ZigbeeやBLEの守備範囲ではありません。
逆に、開閉センサーや温湿度センサーを全部Wi‑Fiに載せると、電池寿命とAP側の管理負荷が先に気になってきます。
Bluetoothはスマホとの距離が近い場面で強く、スマートロックの初期設定、ビーコン、近距離検知、ウェアラブル連携では扱いやすい立場です。

理論値と実用値の読み解き方

通信規格の比較で誤解されやすいのが、理論値の差をそのまま体感差だと思ってしまうことです。
Zigbeeの250 kbps、Wi‑Fiの数百Mbps〜Gbps級、Bluetoothの近距離小容量向けという並びだけを見ると、Zigbeeは極端に遅く見えます。
ただ、センサーの世界では送るデータが小さいので、そこまで単純ではありません。

たとえば温湿度センサーなら、送るのは数値と電池残量、状態フラグのような短い情報です。
ここでは動画用の太い帯域より、短い通信で起きてすぐ寝られることのほうが効きます。
Zigbeeで実用スループットが100〜200 kbps級とされるのも、この文脈で読むと納得できます。
理論値250 kbpsに対して実際のデータ部分は少なく見えますが、センサー用途なら十分な帯域で、むしろ省電力運用との相性が武器になります。
加えて、スリープからの復帰が約15 msという性格は、ボタンやセンサーの反応設計とも噛み合います。

Network Worldが紹介するAP出荷の伸びに関する予測（出典: Network World、予測値）では、2024年が2,630万台、2025年が6,650万台、2026年が1億1,790万台と示されています。
これはあくまで調査機関による予測値であり、地域や集計方法によって変わる点に注意してください。

筆者が自宅でセンサー網を組むときも、理論値だけで選ぶことはほぼありません。
たとえば電池で長く置きたい温湿度センサーや開閉センサーはZigbee寄り、スマホと直接しゃべって設定したい小物はBLE寄り、画像やWeb UIが絡むものはWi‑Fi寄り、という切り分けで考えます。
この見方をすると、数値の大小よりも何をどの頻度で、どれだけの量だけ送るのかが先に決まります。

TIP

[!NOTE] 理論値は「その規格の天井」、実用値は「その用途で困らないか」を見る指標です。
センサーなら復帰時間と消費電力、カメラなら帯域、スマホ連携なら直結性を重視してください。

2.4GHz干渉の注意点

Zigbee、2.4GHz帯のWi‑Fi、Bluetoothは、同じ2.4GHz空間を使います。
つまり、規格が違っても空中では隣り合って混み合うことがあります。
ここを見落とすと、「距離は足りているのに反応が鈍い」「夜だけセンサー通知がもたつく」といった現象が起きます。

家庭内でとくに影響が出やすいのは、Wi‑Fiの2.4GHz帯を太く使っている場所の近くに、ZigbeeコーディネーターやBLE受信点を置いたケースです。
Wi‑Fiの屋内到達距離は約20 m前後がひとつの目安ですが、実際の届き方は壁材、棚や家電の位置、アクセスポイントの設置高さ、チャネル設計で変わります。
高い棚の上にAPを置いたときと、テレビ裏に押し込んだときでは、同じ部屋でも見え方が変わります。

筆者の家でも、夜になると一部のZigbeeセンサーだけ反応が遅れる時期がありました。
日中は気にならないのに、家族が動画視聴や端末の利用を始める時間帯になると、照明トリガーや開閉センサーの反映が鈍くなる、という症状です。
距離の問題だと思って中継機器を足す前に、2.4GHz帯のチャネル配置を洗い直し、Wi‑Fi側のチャネルとZigbee側のチャネルの重なりを避けるように組み直したところ、症状は収まりました。
手順としては、まずWi‑Fiアクセスポイントの2.4GHzチャネルを固定し、そのあとZigbeeコーディネーター側のチャネルを離して再参加を最小限で済む位置に合わせる、という順番が扱いやすかったです。
無線の不調は距離不足と決めつけるより、チャネルの重なりを先に疑うと原因に届きやすくなります。

図解にするなら、次の相関だけ押さえると十分です。

2.4GHz帯の組み合わせ	重なり方の見方	設計上の着眼点
Wi‑Fi 2.4GHz × Zigbee	一部チャネルが近接・重複しやすい	APの固定チャネルとZigbeeチャネルを離す
Wi‑Fi 2.4GHz × Bluetooth / BLE	同帯域を共有する	スマホ周辺機器が多い場所では混雑を意識する
Zigbee × Bluetooth / BLE	同帯域で近接する	コーディネーターや受信点の置き場所を分ける

図に描く場合は、横軸に2.4GHz帯の周波数を置き、上段にWi‑Fiの太いチャネル帯域、下段にZigbeeの細いチャネル、その上をBluetooth/BLEのホッピングが横切るイメージにすると伝わります。
これを一度頭に入れておくと、Wi‑Fi、BLE、Zigbeeを同じ家で併用しても、どこを動かせば改善するのか見えやすくなります。

IoT用途別のおすすめ選定パターン

センサー系

温湿度センサーのように、ボタン電池で長く動かしたい機器を家じゅうに複数台置くなら、筆者はまず『Zigbee』を軸に考えます。
全室設置のような構成では、1台ごとの通信量は小さくても、設置台数が増えるほどネットワーク全体のまとまり方が効いてきます。
CSA Zigbee公式が示す通り、『Zigbee』はスマートホーム向けの相互運用性と低消費電力を前提にした位置づけが明確で、温湿度、人感、開閉のような小さなデータを定期送信する用途に噛み合います。

筆者の自宅でも、温湿度センサーを各部屋へ横展開した段階で『Wi‑Fi』より『Zigbee』のほうが扱いやすいと感じました。
センサー自体は軽い通信しかしないのに、『Wi‑Fi』機器が増えるとアクセスポイント側の管理テーブルや再接続処理の負担がじわじわ効いてきます。
その点、『Zigbee』は常時給電の機器を中継点にしながら家全体へ広げられるので、部屋数が増えても設計の筋道が崩れにくいです。
代替案としては、BLEビーコンを各所に置いてゲートウェイで集約する構成もあります。
スマホ連携や近距離検知と相性がよく、小規模なら成立しますが、全室に同種センサーを並べる発想では『Zigbee』のほうが素直です。

ドア開閉センサーも、選び方の考え方は近いです。
電池駆動で、普段は待機し、開いた瞬間だけイベントを飛ばすタイプなので、『Zigbee』かBLEが候補になります。
ここで差が出るのは、玄関・窓・物置のように家の端へ置いたときの届き方です。
即時性と到達距離のバランスを見ると、『Zigbee』のほうが家庭内の広がりを作りやすく、複数の開閉センサーをまとめて扱う構成に向きます。
逆に、スマホやタブレットの近くにある単体センサーならBLEでも成立します。
読者が迷いやすいのは「1個ならどちらでもよいが、数が増えたときに差が出る」という点で、ここを先に押さえると判断がぶれません。

アクチュエータ系

スマートロックは、センサーよりも「誰が、どこから、どう開けるか」の条件が選定に直結します。
玄関前でスマホと直接つなぎたい、電池を長く持たせたい、近距離で本人だけを判定したい、という要件ならBluetooth LEが第一候補です。
ロック本体がスマホと直結できるので、ハブなしでも成立しやすく、近接操作との相性がよいからです。
筆者宅のBLEロックもこの考え方で組んでいますが、屋内での解錠判定はRSSIのしきい値だけで決めるより、スマホを持つ位置と受信側の設置位置を詰めたほうが安定しました。
玄関ドアの金属面に寄せすぎると判定が揺れ、少しオフセットした位置へ受信点を置くと、意図しない解錠待ちが減りました。
スマホ直結を主役にしつつ、クラウド連携や在宅外からの操作も欲しい場合は、ハブを足した構成のほうが動作が揃いやすいです。

スマート照明は、家に何灯入れるかで答えが変わります。
少数の電球だけを既存アクセスポイントに載せるなら『Wi‑Fi』でも成立しますが、リビング、廊下、寝室、洗面所まで広げるなら『Zigbee』のほうがまとまりやすいです。
照明は常時給電なのでメッシュの中継点になりやすく、壁スイッチや人感センサーと組み合わせたときの応答も揃えやすいからです。
筆者の家でも、最初は『Wi‑Fi』電球を混ぜていましたが、数が増えるにつれて点灯指示の遅れや不達が目につくようになりました。
『Zigbee』照明へ寄せてからは、トリガーから点灯までのばらつきが減り、廊下の自動点灯も狙ったテンポに近づきました。
Wi‑Fi電球そのものが悪いというより、照明のように台数が増えやすい機器をAP配下へ全部ぶら下げると、家庭用ネットワークでは整理しにくくなる場面がある、という理解が実態に合います。

TIP

[!NOTE] センサーは「電池寿命」、アクチュエータは「応答の揃い方」で選ぶと整理できます。
温湿度や開閉は『Zigbee』寄り、スマートロックはBLE寄り、照明は台数が多いほど『Zigbee』寄りです。

高データ量系

カメラだけは、ここまでの話と切り分けて考えたほうが迷いません。
映像を送り、場合によっては音声も扱い、さらにOTA更新も考えるなら、『Wi‑Fi』が現実的です。
『Zigbee』やBLEはセンサー通知には向いていても、カメラのような高ビットレート用途には向きません。
たとえば『ESP32‑CAM』のような小型カメラモジュールでも、実運用ではWi‑Fi前提の構成になります。
OV2640搭載機の例ではUXGA 1600×1200に対応し、実装例でもMJPEG系のストリーミングが中心です。
ここで必要なのは、低消費電力メッシュよりも、LAN機器として安定してつながることと、映像を無理なく流せる帯域です。

このため、見守りカメラ、玄関カメラ、室内監視カメラを『Zigbee』やBLEでどうにかしようと考えるより、カメラは最初から『Wi‑Fi』系に寄せるほうが設計が素直です。
録画、ライブビュー、通知付きスナップショット、ファーム更新まで含めると、IP機器として扱えるメリットがそのまま運用の楽さにつながります。
Wi‑Fi 8の方向性を扱ったNetwork Worldの記事でも、次世代Wi‑Fiは速度競争だけでなく信頼性の改善へ重心が移りつつあると整理されており、カメラのような常時接続機器ではこの流れがそのまま効きます。

ウェアラブル/周辺機器

ウェアラブルはBluetooth LEが基本です。
スマートウォッチ、活動量計、ヘルスケアバンドのような機器では、スマホと近距離で連携しつつ、電池を長く持たせる必要があります。
この用途では、家全体を覆うメッシュより、手元のスマホと確実につながることのほうが優先されます。
Bluetooth Market Update 2025でもBluetooth機器の裾野は広がり続けており、ウェアラブルがその中心的なカテゴリのひとつです。
通知、歩数、心拍、設定同期のようなやり取りは、まさにBLE向けの通信量です。

キーボードやマウスは、同じBluetooth系でも少し性格が違います。
ここで重視されるのは低遅延で、ウェアラブルのような断続通信ではありません。
そのため、選択肢はBluetooth Classicか、メーカー独自の2.4GHzドングルになります。
ノートPCやタブレットと汎用的につなぐならBluetooth、ゲームや高速入力を優先するなら専用ドングル、という分け方が。
IoTという文脈では周辺機器寄りですが、「スマホ直結・近距離・省電力」のBLEと、「継続接続・低遅延」のClassic系は役割が違う、と押さえておくと混同しません。

産業/広域センサー

工場センサーのように、広い空間へ多数のノードを配置し、電池寿命も伸ばしたい用途では、『Zigbee』が依然として有力です。
設備監視、温湿度、接点入力、開閉、簡易な状態通知のような小さなデータを多数集める構成では、低消費電力と多ノード構成の相性がよいからです。
家庭向けと違うのは、到達距離よりも「どの位置に中継点を置き、どこを幹線にするか」という設計が前面に出ることです。
工場や倉庫では金属ラックや機械設備で電波の通り道が分かれやすいので、常時給電のルータ役をきちんと置いた『Zigbee』メッシュのほうが組み立てやすい場面が多いです。

今後の見通しとしては、Sub‑GHz系への流れにも触れておきたいところです。
Connectivity Standards AllianceはZigbee 4.0 / Suzi 発表で、広域・低消費電力の新しい選択肢としてSuziを打ち出しています。
国内適用を現時点で断定する段階ではありませんが、2.4GHzだけでは届かせにくい広域センサー網に対して、将来の候補が増えているという捉え方はできます。
現時点での実務感としては、国内で組むなら『Zigbee』の2.4GHz運用を基本線にしつつ、将来はSub‑GHz系の標準化動向も視野に入る、という整理が無理のないところです。

実装でつまずきやすいポイント

2.4GHz干渉と設置

『Zigbee』『Wi‑Fi』Bluetoothは用途が違っても、家庭では同じ2.4GHz帯を取り合います。
ここで見落とされがちなのが、規格そのものの優劣よりどのチャネルをどこに置いたかで体感差が出ることです。
Wi‑Fiの2.4GHzは一般にチャネル1/6/11を軸に組みますが、Zigbeeのチャネル11〜26とは一部が重なります。
机上では「Zigbeeは低速だから影響が小さい」と見えますが、実際の家ではAPの近くにZigbeeコーディネータを置いただけでリンク品質が崩れることがあります。

筆者の手元でも、Zigbeeコーディネータを金属ラックの脇に置いていた時期は、参加はできるのに応答が不安定な端末が混じりました。
ラックから離し、USB延長で少し持ち上げて設置しただけでリンク品質が目に見えて整いました。
Zigbeeの実用距離は屋内で10〜20m程度、条件がよければ約30mという目安がありますが、この種の数字よりも、まず金属面から離す、高さを確保する、APと近接させすぎないの3点のほうが効きます。

チャネル設計も同じくらい効きます。
2.4GHzの『Wi‑Fi』をチャネル1で使っているなら、『Zigbee』はその近傍を避ける、といった発想で分けると衝突を減らせます。
コーディネータをHome Assistant ZHAで使う場合も、ネットワークを大きくすると起動時や再参加時の混雑に気を配る前提になるので、最初から電波の重なりを減らしておくほうが安定します。
家の中心に近い高めの位置へAP、少し距離を取った位置へZigbeeコーディネータ、という配置は地味ですが効きます。

Wi‑Fiの台数問題と分離設計

『Wi‑Fi』はIP機器として扱えるぶん、つい何でも載せたくなります。
ただ、IoT機器が増えると、帯域そのものより先にルーターやAPの制御面が詰まり始めます。
具体的にはARP、マルチキャスト、定期的なビーコン、スリープ端末の再接続処理が積み上がり、カメラやスマート家電だけでなく小さなセンサー群まで同じSSIDへ集めると、家庭用ルーターでは整理が難しくなります。

とくに照明やプラグのように台数が増えやすい機器を全部『Wi‑Fi』へ寄せると、「通信量は小さいのにネットワーク全体がざわつく」状態になりがちです。
これは回線速度の問題ではなく、APが面倒を見る端末数と管理トラフィックの問題です。
映像系やOTA更新が必要な機器は『Wi‑Fi』に向いていますが、常時小さい状態通知をばらまく機器まで同居させると、構成全体の見通しが悪くなります。

そこで効くのが、IoT用SSIDを分けるか、もう一段進めてIoT VLANを切る設計です。
IEEE 802.1QベースのVLAN分離は業務ネットワークでは定番ですが、家庭のスマートホームでも相性がよく、メインLANとIoT群を分けるだけでブロードキャストの広がり方を制御しやすくなります。
APが複数置けるなら、IoT専用APを1台分ける構成も有効です。
ネットワーク機器の能力を増やすというより、騒がしい機器を別の部屋に移す感覚に近いです。

Zigbeeメッシュの育て方

『Zigbee』は低消費電力センサーと相性がよい一方で、実装ではゲートウェイ前提になりやすい規格です。
スマホに直接つなぐというより、『Home Assistant』にUSBドングルを挿すか、専用ハブを置くところから始まります。
たとえばSONOFF Zigbee 3.0 USB Dongle Plusは『ZHA』とzigbee2mqttの両方で使いやすく、外部アンテナ付きの構成を取りやすい代表例です。ConBee IIもdeCONZ系との親和性が高く、Zigbee 3.0対応ゲートウェイとして定番です。

ここでつまずきやすいのは、コーディネータだけ強いものを置けばネットワーク全体が安定すると思ってしまうことです。
実際には、末端の電池センサー同士は中継しないことが多く、メッシュの骨格になるのはコンセント給電のプラグ、電球、専用リピータのような常時給電ルータです。
筆者の家でも、センサーが増えてから一部の部屋だけ反応が鈍くなりましたが、常時給電ルータを数台追加したところ、そこから先は別物のように安定しました。
メッシュは最初から完成形に見えません。
幹線になる場所へルータを置いて、少しずつ育てる感覚のほうが実態に近いです。

『Zigbee』の最大データレートは2.4GHz帯で250 kbps級なので、大容量通信には向きません。
代わりに、低レイテンシでスリープから復帰しやすいのが強みです。
スリープ復帰時間やネットワーク再構築時間は実装やスタックで変動しますが、実測報告の目安として数ms〜数十ms（例: 約15 ms 程度の報告がある）という範囲で記載されることが多いです。
だからこそ、センサー本体を頑張らせるより、メッシュの通り道を整えるほうが成果につながります。
ソフトウェア相性も見逃せません。
『ZHA』はzigpy互換コーディネータ前提でまとまりがよく、zigbee2mqttは対応デバイスの広さとMQTT連携が魅力です。
ただし、同じUSBドングルでもファームウェアの系統によって相性差が出ます。
ハードより先に、どのスタックで運用するかを決めておくと、後からquirksや再ペアリングで苦しむ場面を減らせます。

TIP

[!WARNING] 『Zigbee』を導入するときは、センサーを一気に増やす前に常時給電のルータを先に置くことを検討してください。
中継点が不足すると、追加したセンサーの安定性が損なわれることがあります。

Bluetoothを家全体で使う工夫

Bluetooth、とくにBLEはスマホ連携の入り口として優秀です。
鍵、タグ、体重計、ウェアラブル、ビーコンのように、まずスマホアプリで触れる機器なら導入のハードルが低く、設定も直感的です。
Bluetooth Market Update 2025でもBluetooth機器は2025年に53億台超と見込まれており、裾野の広さはこの手軽さに支えられています。
スマートロックやプレゼンス検知でBLEがよく選ばれるのも、この「スマホがそのまま管理端末になる」性格によるものです。

一方で、家全体を覆う常設ネットワークとして見ると、BLEは工夫なしでは伸びにくい規格でもあります。
センサーが近くに来たときだけ拾う用途なら問題ありませんが、玄関、廊下、寝室、リビングをまたいで確実に受信したいとなると、受信点の設計が肝になります。
スマホ1台で拾う発想から、スキャナやゲートウェイを複数置く発想へ切り替えないと、取りこぼしが残ります。

筆者はBLEビーコンで在室と帰宅の判定を試したとき、広告間隔を長めにすると電池はよく持つものの、到達率が目に見えて落ちました。
そこで設定だけで解決しようとせず、玄関と廊下に受信点を増やして折衷しました。
BLEは送信側を無理にしゃべらせ続けるより、受信側を賢く増やしたほうが全体が整います。
広めの家でBLEを常設運用するなら、広告間隔とスキャン間隔の両方を見ながら、どこに受信点を置くと生活導線を拾えるかで詰めるほうが現実的です。

電池寿命の設計ポイント

IoT機器の電池寿命は規格だけで決まるものではありません。
送信間隔、送信出力、再送の発生、温度、スリープ復帰の作り方などが寿命に影響します。
IoT機器の電池寿命は、「規格が省電力か」だけでは決まりません。
実際には送信間隔、送信出力、再送の発生、温度、スリープ復帰の作り方で差が出ます。
たとえば同じ温湿度センサーでも、1分ごとに送るのか、変化があったときだけ送るのかで寿命は大きく変わります。
Wi‑Fi系が不利になりやすいのは、接続維持や再接続のコストが重いからで、逆に『Zigbee』やBLEは短い送信を挟んで長く眠る設計に向きます。

『Zigbee』はスリープ復帰が約15msという速さを活かして、必要なときだけ起きる構成を作りやすいです。
人感や開閉のように即時通知が欲しい用途でも、起床が軽いので電池を削りにくいのが利点です。
BLEでは接続型にするか、広告型で流すかで考え方が変わります。
常時接続に寄せるなら接続パラメータを詰め、ビーコン型なら広告間隔を詰める代わりに受信点配置で補う、という整理になります。

設計の視点としては、通信回数を減らす、再送を減らす、起きている時間を短くするの3つが基本です。
ここで再送を減らすには、単に電池を増やすのではなく、前段で触れた2.4GHzの干渉やメッシュ構造を整えることが効きます。
電池寿命は電池の容量だけでなく、ネットワーク品質の結果でもあります。
通信設計と配置設計が噛み合っているネットワークは、同じセンサーでも交換周期が安定しやすく、運用の手間が読みやすくなります。

2025〜2026年の最新動向

Connectivity Standards Allianceは2025年11月にZigbee 4.0とSuziを発表しました。
ここで押さえたいのは、既存のZigbee 3.0を即座に捨てる話ではないという点です。

Connectivity Standards Allianceは2025年11月にZigbee 4.0とSuziを発表しています。
ここで押さえたいのは、これは既存のZigbee 3.0を急いで捨てる話ではないという点です。
CSAの発表ではZigbee 3.0やSmart Energyとの後方互換が示されています。
今ある資産を活かしながら次世代へつなぐ整理になっています。
発表そのものは確定事項として扱えますし、内容も Zigbee 4.0 / Suzi発表で確認できます。

Suziは、そのZigbee 4.0時代の相互運用性を前に進める認証の位置づけです。
認証開始は2026年前半予定とされているので、ここは確定済みの製品流通とは分けて見たほうがよい部分です。
つまり、2025年時点で判断材料になるのは「規格方針が出たこと」であって、「国内で選べる完成品が一気に切り替わること」ではありません。
新規格のニュースだけを見ると大転換に見えますが、実務感覚では移行は段階的です。

注目点のひとつがSub‑GHzの長距離メッシュです。
2.4GHz中心だった従来のZigbeeに対して、到達性の選択肢が広がる可能性があります。
ただし日本でそのまま使えるかは別問題で、国内適用は各国ごとの電波規制と認証に左右されます。
ここは見通しとして語れる範囲に留まり、国内で一般流通する製品が増える時期まではまだ読み切れません。
技適の扱いまで含めると、日本では「規格がある」と「買ってすぐ使える」が同義にならない場面が多いからです。

筆者の見方としては、Zigbee 4.0やSuziは置き換え圧力というより、選択肢の追加です。
家庭用センサーの世界では、今も『Zigbee』が強い立場にありますし、今後もしばらくはその前提で組みます。
筆者自身、当面は家庭用センサーは『Zigbee』、画像系は『Wi‑Fi』、近接操作はBLEという住み分けを続けるつもりです。
新規格が出ても、この切り分けが急に崩れる感じはありません。
むしろ、長距離や認証の面で選べる道が増えた、と捉えるほうが実態に合っています。

Wi‑Fi 7の現実解とWi‑Fi 8の方向性

Wi‑Fi 7は、ニュースよりも出荷台数の伸びで見ると温度感がつかみやすいです。
Network Worldが紹介したAP出荷予測では、2024年に2,630万台、2025年に6,650万台、2026年に1億1,790万台へ伸びる見込みとされています。
つまり、2025〜2026年は「規格として珍しい段階」から「普及品として目に入る段階」へ移る時期です。
ハイエンドのルーターや法人向けAPから始まった流れが、家庭向けにも下りてきます。

一方で、IoT目線ではWi‑Fi 7のインパクトを少し冷静に見たほうが腹落ちします。
広帯域、低遅延、高密度といった恩恵は確かにありますが、温湿度センサーや開閉センサーのような小さな通信を大量にぶら下げる構成では、勝負どころは規格世代よりもSSID設計、AP配置、2.4GHz帯の混雑回避、VLAN分離といった設計側にあります。
大量IoTを抱える家で効くのは、無線LANを新世代に替えることそのものより、「どの機器をWi‑Fiに乗せるのか」を絞る判断です。

この視点で見ると、Wi‑Fi 7は画像系や更新系の安心材料としては強いです。
たとえば『ESP32‑CAM』のような軽量カメラモジュールでも、MJPEGの連続配信やOTAのように帯域と安定性を欲しがる仕事は『Wi‑Fi』向きですし、一般的なネットワークカメラやドアベルでも同じ傾向があります。
逆に、数が増えるセンサー群をまとめてWi‑Fi 7に寄せれば全部解決する、という話にはなりません。

Wi‑Fi 8はさらに象徴的で、速度競争より信頼性と低遅延を前に出す方向が見えています。
業界メディアの Wi‑Fi 8の方向性でも、その軸はスループットの派手さより通信品質です。
これはIoTと相性がよさそうに見えますが、今の選定にそのまま飛びつく必要はありません。
2025年時点で考えるべきことは、将来8が来るから待つのではなく、今つなぐべき機器の性格は何かを見切ることです。

筆者はこの点で、画像・音声・管理UIに関わる機器は『Wi‑Fi』、常時電池駆動の小型センサーは『Zigbee』、スマホが主役の近接操作はBLEという分担を崩していません。
Wi‑Fi 7が普及しても、家庭内のIoT全体を1つの無線規格に寄せるより、役割ごとに分けたほうがネットワークの癖が読みやすく、トラブル時の切り分けも進めやすいからです。
新しい『Wi‑Fi』世代は歓迎しつつも、設計の本質はそこではない、というのが現場寄りの結論です。

TIP

[!NOTE] 2025〜2026年の無線選定では、「新しい規格か」より「その機器は何を運ぶのか」で分けると迷いにくくなります。
映像や更新は『Wi‑Fi』、電池センサーは『Zigbee』、スマホ起点の近接体験はBLEを優先する考え方で十分です。

home

espressif.com

Bluetooth 6系・LE Audio/Auracast/測位の波

Bluetooth Market Update 2025（出典: Bluetooth SIG の Market Update、予測値）では、2025年のBluetoothデバイス出荷は53億台超とされる予測が示されています。
これも市場予測であり確定値ではないことに留意してください。

もうひとつの変化がChannel Soundingです。
これはIoTにとって、近接検知と屋内測位の精度向上につながる流れとして見ておく価値があります。
BLEビーコンはこれまで「近くにいるらしい」判定に留まりやすかったのですが、測距の精度が上がると、スマートロックの誤反応抑制や、部屋単位の在室判定、屋内ナビのような用途が現実味を帯びます。
家の中で言えば、玄関前に立ったときだけ解錠候補にする、廊下を通過しただけでは在室扱いにしない、といった判断の粒度が細かくなるイメージです。

Bluetooth 6系という見出しで語られる将来像も、この延長線上にあります。
ここで確定して見てよいのは、Bluetoothの進化がオーディオ、放送、測位を束ねながら進んでいることです。
普及時期や、国内でどのカテゴリの製品に先に降りてくるかまでは見通しの領域ですが、方向性そのものは明確です。
センサー単体の通信規格として見るより、スマホ・イヤホン・タグ・ロック・ゲートウェイをまたぐ共通基盤として見たほうが、2026年以降の絵が読みやすくなります。

筆者もBLEは今後さらに面白くなると見ていますが、だからといって家中のセンサーをBLEへ寄せるつもりはありません。
筆者の運用では、BLEの持ち味はスマホ直結の近接操作とプレゼンス周辺にあります。
鍵、タグ、初期設定、近くにいる人だけを判定する体験には強い一方、家全体へ常設するセンサーネットワークは『Zigbee』のほうが組みやすいままです。
LE AudioやAuracast、測位の進化は、BLEを置き換え候補ではなく「役割が増えていく規格」として見ると納得しやすいはずです。

よくある質問

Matterとの関係

Matterは「どのメーカーの機器でも、共通の言葉で連携しやすくする」ためのアプリケーション層の相互運用規格です。
ここで混同されやすいのが、Matterが『Zigbee』Bluetooth『Wi‑Fi』を丸ごと置き換える新しい無線規格だ、という理解です。
実際はそうではなく、Matterは『Wi‑Fi』やThreadの上で動く仕組みとして考えると整理しやすくなります。
Thread自体はIEEE 802.15.4ベースの低消費電力メッシュで、通信路の役目を担います。
つまり、役割のレイヤーが違います。

この整理を頭に入れておくと、「Matter対応ならZigbee機器は不要になるのか」という疑問にも答えやすくなります。
現実には、既存のスマートホーム機器には『Zigbee』が広く残っていますし、センサーや照明では今も有力です。CSA Zigbee公式が示す通り、『Zigbee』は独自のエコシステムとして継続しており、Matter登場後もすぐ消える位置づけではありません。
新規製品の相互運用はMatter、既存資産や低消費電力センサー網は『Zigbee』、スマホ直結や近接連携はBLEという形で、しばらく併存すると見たほうが実感に合います。

Threadと『Zigbee』もよく並べて語られますが、同じIEEE 802.15.4系でも中身は別物です。
ThreadはIPベースでMatterと組み合わされることが多く、『Zigbee』は独自スタックで完結した実績あるネットワークです。
家づくりの比喩でいえば、Matterは部屋の中で通じる共通ルール、Threadや『Wi‑Fi』は廊下や配線の通し方、『Zigbee』は別の設計思想でできた既存の建物、くらいに分けると迷いません。

Home Assistantでの始め方

『Home Assistant』で始めるときは、無線方式ごとに入口が違います。
Zigbeeならコーディネータを1本用意して『ZHA』かzigbee2mqttを選び、Wi‑Fi/BLE寄りの自作機器は『ESPHome』との相性が良いです。
ESP32系ボードにセンサーをつないでそのまま『Home Assistant』へ載せる流れは再現しやすい構成です。

『ZHA』とzigbee2mqttは、どちらが上というより性格が違います。
筆者は両方を自宅で回してきましたが、最初の1本として気楽に入れるのは『ZHA』でした。
『Home Assistant』の統合としてまとまっているので、USBドングルをつないでからの導線が短く、構成が散らばりません。
いっぽうで、zigbee2mqttは対応デバイスの幅や細かな露出項目、挙動の追い込みで強さを感じます。
センサーの属性を細かく見たい、対応機器の選択肢を広げたい、という段階になるとこちらが頼もしくなります。

コーディネータ選びでは、最初から定番を選んだほうが遠回りになりません。
SONOFF Zigbee 3.0 USB Dongle Plusは『ZHA』とzigbee2mqttの両方で扱いやすく、出荷時点でコーディネータ用ファームウェアが入っているモデルがあります。ConBee IIも定番ですが、いま新しく入るならSONOFF系のほうが情報量を集めやすい場面が多いです。
どちらを使うにしても、USBポート直挿しより少し離して置いたほうが安定しやすく、家の中心寄りに置くとメッシュの組み立てが素直になります。

『Wi‑Fi』やBLEで始めるなら、『ESPHome』が入口として優秀です。
YAMLでセンサー定義を書いてOTA更新し、『Home Assistant』側でネイティブに見える流れは、インフラ寄りの感覚にも合います。
筆者も温湿度や開閉の周辺では『ESP32』と『ESPHome』をよく使いますが、「まず1台動かして、それを複製して増やす」が通りやすいのが利点です。
Zigbeeネットワークの癖をいきなり覚えなくて済むので、自作IoTの最初の成功体験を作りやすい構成です。

TIP

[!NOTE] 『Home Assistant』の初手は、既製センサー中心なら『ZHA』、自作センサー中心なら『ESPHome』という分け方だと迷いが減ります。
段階的に学ぶと運用の広がりが見えやすくなります。

スマホだけで使える？

スマホだけで完結するかどうかは、無線規格ごとに答えが分かれます。
BLEはここが最も強く、スマホを親機としてそのままつながる前提で作られている機器が多いです。
スマートロック、タグ、設定用デバイス、近接操作系はこの恩恵を受けやすく、専用ハブなしでも成立します。

『Wi‑Fi』も、機器とスマホが同じLANに入っていれば、原則として単体運用できます。
家庭用カメラや家電の初期設定で「アプリを入れて同じSSIDにつなぐ」流れが多いのはこのためです。
IP機器なので、スマホアプリから直接見つけて扱える構造を作りやすいわけです。

いっぽうで『Zigbee』は、スマホだけで完結する前提ではありません。
スマホは通常『Zigbee』無線を直接持たないので、間にハブやゲートウェイ、あるいは『Home Assistant』につながったコーディネータが必要です。
ここがBLE機器とのいちばん大きな差です。
読者が「開閉センサーを1個だけ付けたいのに、なぜUSBドングルやハブが要るのか」と感じるのは自然ですが、それは『Zigbee』の価値が家全体の低消費電力ネットワークにあるからです。
単発の近接機器ならBLE、家全体の常設センサーならZigbee、という分担に落ち着きます。

技適と認証の注意

日本で無線機器を扱うときは、技適の整理を避けて通れません。
自作機器でも完成品でも、国内で無線を出すなら技術基準適合証明の対象になるため、総務省の制度に沿った扱いが前提です。
『ESP32』を使った工作では、技適済みモジュールを前提に組むのがいちばん筋が良い進め方です。
無線部分まで自前で設計して認証を取りにいく話と、認証済みモジュールを条件通り組み込む話では、難易度がまったく違います。

注意したいのはSub‑GHz帯です。
2.4GHz系の『Wi‑Fi』BLE『Zigbee』に比べて、「遠くまで飛びそうだから使いたい」と考えがちですが、日本では周波数、出力、認証の整理が一段増えます。
920MHz帯のような国内制度に乗った機器なのか、海外向けの868MHzや915MHz前提なのかで扱いが変わるため、この帯域は部品選びの時点で設計思想が決まります。

認証も名前が似ていて混ざりやすい。
技適は日本国内で電波を出すための法制度上の適合、『Wi‑Fi Alliance』の認証は相互接続性やセキュリティ要件を示す業界認証で、役割が別です。
MatterやThreadにも相互運用の認証はありますが、それがそのまま日本の電波法の扱いを代替するわけではありません。

『Zigbee』系の今後として、CSAはZigbee 4.0とSuziを打ち出しています。
Zigbee 4.0 / Suzi 発表(https://csa-iot.org/newsroom/the-connectivity-standards-alliance-announces-zigbee-4-0-and-suzi-empowering-the-next-generation-of-secure-interoperable-iot-devices/) の段階では、国内での製品展開や認証の見通しはまだ制度運用と市場投入の話が残っています。
ニュースとしては面白いものの、現時点の選定軸としては「今すぐ国内で広く使える既成事実」ではなく、先の流れを示す材料として捉えるのが自然です。

台数が増えたときの設計

機器が増えたときに詰まりやすい場所は、規格ごとに違います。
『Wi‑Fi』は台数が増えるほどアクセスポイント設計の影響が前面に出ます。
IoT機器を全部ひとつのSSIDに押し込むより、APを分ける、SSIDを分ける、VLANでIoT系を切るといったネットワーク設計の発想が効いてきます。
業務ネットワークほど大げさでなくても、カメラ、家電、センサー、自分のPCやスマホが同じ無線セルに密集すると、障害切り分けが一気につらくなります。
筆者はIoT機器を別セグメントへ逃がした構成のほうが、トラブル時に「無線の問題か、アプリの問題か、LAN設計の問題か」を追いやすく感じています。

『Zigbee』は逆に、台数が増えるほどメッシュの作り方が効きます。
電池センサーばかり増やしても網は強くならず、常時給電のプラグ、リレー、据置機器のようなルータになるデバイスを増やすと安定しやすくなります。
コーディネータ1台で全部背負わせるより、家の中に中継点を置いていく発想です。
筆者もセンサーだけを先に増やした時期は反応が飛ぶ場所が残りましたが、常時給電デバイスを要所に入れると、ネットワーク全体の雰囲気が変わりました。

BLEは単体ではスマホ直結が魅力ですが、台数が増えると「誰が拾うか」が課題になります。
この段階ではスマホ1台に寄せるより、ゲートウェイを複数置く考え方が現実的です。
玄関、廊下、リビングのように受信点を分けると、タグやロック、プレゼンス検知の取りこぼしが減ります。
BLEを家全体の常設インフラとして使うなら、スマホの便利さより、受信点配置の設計が本体になります。

どの規格でも、台数が少ないうちは「つながるかどうか」で十分ですが、増えてくると「どこで混むか」「誰が中継するか」「どのレイヤーで切り分けるか」が主役に変わります。
スマートホームは機器選びの話に見えて、実際には小さなネットワーク設計の積み重ねです。
ここを先に理解しておくと、同じ『Home Assistant』構成でも伸びしろがだいぶ変わります。

次のアクションとまとめ

3つの整理ポイント

ここまで読んだら、次は「どの規格が優れているか」ではなく、「自分の機器に何を求めるか」を3つの軸で切り分けると判断が進みます。
見るべき軸は、電池で長く動かしたいか、スマホと直接つなぎたいか、送るデータが小さいかの3点です。
たとえば、温湿度や開閉のように小さなデータを定期送信するなら低消費電力系が候補に残り、画像や連続ストリームを扱うなら『Wi‑Fi』系に寄ります。

この整理をすると、用途別の最適解も見えます。
高データ量なら『Wi‑Fi』、家全体の電池センサーを増やすなら『Zigbee』、スマホ近距離で完結したいならBLEという骨格です。
記事中で触れた通り、理論値と実用の感覚には差がありますし、スマホ直結できるか、ゲートウェイが前提かでも導入後の運用は変わります。
2025〜2026年の動向も気になりますが、現時点の自作や導入判断では、ニュース性より「今ある機材で素直に組めるか」を優先したほうが失敗が少なくなります。

迷った段階では、安全側に仮決めしてしまうのも有効です。
筆者は、動画や画像やOTA更新が主役なら『Wi‑Fi』、電池駆動の常設センサーを多数置くなら『Zigbee』、スマホを操作の中心にするならBLEという順で当たりを付けます。
ここで決め打ちせず、仮説として置いてから1台だけ試すと、机上の比較より早く答えが出ます。

小規模PoCの進め方

試作は、最初から完成形を目指すより、規格ごとに1台作って比較する形が堅実です。
『Wi‑Fi』なら『ESP32』、BLEならBLE対応MCU、『Zigbee』なら技適済みモジュールと対応ゲートウェイの組み合わせを並べると、配線、初期設定、応答感、運用の手間まで見えてきます。
『ESP32』はEspressifのデータシートで2.3V〜3.6V動作が確認でき、『ESPHome』と『Home Assistant』の組み合わせも取りやすいので、Wi‑Fi側の比較基準として扱いやすい部品です。
スマートホーム前提なら『Home Assistant』の『ESPHome』統合や『ZHA』対応も早めに確認しておくと、試作後の横展開で詰まりません。

『Zigbee』側は、センサー本体だけでなくコーディネータまで含めて比較するのが。
たとえばSONOFF Zigbee 3.0 USB Dongle Plusは『ZHA』やzigbee2mqttとの組み合わせ候補に入りやすく、ConBee IIもPhoscon系の運用基盤があります。
こうしたUSBドングルは、Amazonなどの流通価格ベースでSONOFF Zigbee 3.0 USB Dongle Plusが約¥2,500〜¥6,000、ConBee IIが約¥6,000〜¥12,000のレンジなので、PoC段階では「いきなり家全体を置き換える投資」になりにくいのも利点です。

外部連携まで含めて試すなら、著者プロフィールやカテゴリページは有効な導線になります。
記事末や関連コンテンツ欄に著者ページや smart-home カテゴリーページへの内部リンクを追加することを検討してください。

最終まとめ

規格選びは、スペック表の勝ち負けより、機器の役割を先に決めた人から迷いが消えていきます。
まずは1台だけ作って、1室で動かし、連携先まで含めて確かめる進め方がいちばん堅実です。
自作IoTは、正しい規格を選ぶことより、無理のない範囲で検証を積み上げることが完成への近道になります。