ESP32の大きな特徴の一つが、Wi-FiとBluetoothを1つのデバイスで利用できることです。
たとえば、
「BLEでスマートフォンから初期設定を行い、その後Wi-Fiへ接続する」
「BLEでセンサーと通信しながら、取得したデータをWi-Fiでクラウドへ送信する」
「Wi-Fi接続中もBLE Advertisingを続けたい」
といった使い方が考えられます。
ここで気になるのが、
「ESP32はWi-FiとBLEを本当に同時に使えるのか？」
という点です。
結論から言うと、ESP32ではWi-FiとBLEを同時に使用できます。
ただし、「同時使用できる」という言葉には少し注意が必要です。
ESP32ではWi-FiとBluetooth/BLEが2.4GHz帯のRFリソースを共有しています。そのため、Wi-FiとBLEが完全に独立した2つの無線回路を持ち、それぞれが同じ瞬間に送受信しているわけではありません。
Espressifの公式資料では、RFリソースを共有し、TDM（Time Division Multiplexing：時分割多重）と優先度制御によってWi-FiとBluetoothを共存させる仕組みが説明されています。
この記事では、ESP32でWi-FiとBLEを同時使用するときの仕組みと、実際の製品開発で注意したいポイントを解説します。
結論｜ESP32はWi-FiとBLEを同時に使える
最初に結論を整理すると、
Wi-FiとBLEを同時に使用することは可能。ただし、RFを時間的に共有している。
という理解が分かりやすいでしょう。
たとえばESP32をWi-FiのSTAとしてアクセスポイントへ接続しながら、
- BLE Scan
- BLE Advertising
- BLE Connection
を利用する構成は、Espressifの公式Coexistence表でもサポートされています。
したがって、
Wi-Fi接続
＋
BLE接続というシステムを作ること自体は可能です。
ただし、
Wi-Fi専用RF
＋
BLE専用RFという2つの独立した無線回路がESP32内部に存在しているわけではありません。
この違いが、Wi-FiとBLEを同時使用するときの重要なポイントです。
Wi-FiとBLEは同じ2.4GHz RFを共有している
従来ESP32のWi-Fiは2.4GHz帯を使用します。
BLEも同じ2.4GHz帯を使用します。
ESP32には、この2つがそれぞれ独立して使用できる2系統の2.4GHz RFが搭載されているわけではなく、1つの2.4GHz ISM帯RFモジュールをWi-FiとBluetoothで共有します。
そのため、Wi-FiがRFを使用して送受信している瞬間には、Bluetooth側が同じRFを使って送受信することはできません。
そこでESP32では、Wi-FiとBluetoothからのRF使用要求をCoexistence機能が調停します。
イメージとしては、
時間 →
┌──────┬──────┬──────┬──────┐
│Wi-Fi │ BLE │Wi-Fi │ BLE │
└──────┴──────┴──────┴──────┘
1つのRFを共有という考え方です。
実際の制御はこのような単純な固定交互動作ではありませんが、非常に短い時間単位でRFを使い分けることで、ユーザーから見るとWi-FiとBLEが並行して動作しているように見えると考えると分かりやすいでしょう。
TDM（時分割多重）でWi-FiとBLEを共存させる
EspressifのCoexistence機能では、Wi-Fi、Bluetooth、BLEにRFを使用するためのTime Sliceが割り当てられます。
さらに、それぞれからRF使用要求が発生すると、Coexistence機能が優先度を基にRFをどちらへ割り当てるか判断します。
この割り当ては常に一定ではありません。
Wi-Fi側だけでも、
- IDLE
- CONNECTED
- SCAN
- CONNECTING
などの状態があり、それに応じてCoexistence PeriodやTime Sliceが調整されます。
たとえばWi-Fiがアクセスポイントを検索している最中と、アクセスポイントへ接続済みで待機している状態では、必要になるRF時間が違います。
ESP32はその状態に合わせてWi-FiとBluetoothの共存方法を変更します。
つまり、
Wi-Fi 50％、BLE 50％で常に固定されている
わけではありません。
使用状況によってRFの割り当て方が変わります。
Wi-Fi接続＋BLE接続はできる？
できます。
一般的な用途として考えやすいのが、
スマートフォン
│
BLE
│
ESP32
│
Wi-Fi
│
アクセスポイント
│
インターネットという構成です。
たとえばスマートフォンとはBLEで通信しながら、ESP32はWi-Fi経由でサーバーへデータを送信できます。
EspressifのESP32向けCoexistence表でも、Wi-Fi STAについて、
Wi-Fi Scan + BLE
Wi-Fi Connecting + BLE
Wi-Fi Connected + BLE
といった組み合わせがサポートされています。
このため、
BLEを使った初期設定
↓
Wi-Fiへ接続
↓
BLE接続を維持したままWi-Fi通信
という構成も実現できます。
IoT機器では使いやすい構成ですね。
「同時使用できる」＝「性能が変わらない」ではない
ここが今回の記事で特に重要なところです。
Wi-FiとBLEを同時に使用できるからといって、
Wi-Fiだけを使った場合とBLEだけを使った場合の性能を、それぞれ100％同時に得られる
という意味ではありません。
1つのRFを共有しているため、一方がRFを使用している間、もう一方は待つ必要があります。
そのため通信量が増えるほど、
- Wi-FiのThroughput
- BLEの応答時間
- BLE Scan
- Packet Loss
- リアルタイム性
などへ影響する可能性があります。
EspressifもCoexistenceの組み合わせを、単純な「対応／非対応」だけではなく、
Y：Supported and performance is stable
C1：Supported but performance is unstable
X：Not supported
などに分類しています。
つまり公式資料の段階でも、
「動作可能」と「安定した性能を期待できる」は別
として扱われています。
Wi-Fiで大量通信するとBLEへ影響する？
可能性があります。
特にWi-Fiで大量のデータを連続転送すると、Wi-Fi側が必要とするRF時間が増えます。
同時にBLEでも頻繁な通信を要求すれば、限られたRFリソースを両方で取り合うことになります。
EspressifのFAQでも、Wi-FiとBluetoothが大量のデータを同時に扱うと、リアルタイム性の高いBluetoothサービスなどで性能低下が起こり得ることが説明されています。BLE Scanについても、予定されたScan WindowがWi-FiのTime Slotと重なることで中断され、実際のScan時間が設定値より短くなる場合があります。
したがって、
BLEで数バイトの設定値を時々送る
＋
Wi-Fiで定期的にデータ送信これと
BLEで連続通信
＋
Wi-Fiで大量データを連続転送では、同じ「Wi-Fi＋BLE同時使用」でも条件が大きく違います。
製品開発では、単に接続できたことだけでなく、実際の最大通信量で評価することが重要です。
BLE Advertising中にWi-Fiを使える？
BLE AdvertisingとWi-Fiの併用も可能です。
たとえばESP32をWi-Fiへ接続したままBLE Advertisingを行い、スマートフォンなどからESP32を発見できるようにする構成が考えられます。
EspressifのCoexistence表でも、Wi-Fi STAとBLE Advertisingの組み合わせはサポートされています。
これは、
普段はWi-Fiでクラウド通信
設定変更時だけスマートフォンからBLE接続
といった製品に使いやすい構成です。
BLEを常時接続しておく必要がなければ、
通常時
Wi-Fi通信
＋
BLE Advertising
↓
設定時
Wi-Fi通信
＋
BLE Connectionという設計もできます。
通信量を必要以上に増やさないという意味でも、用途に合わせてBLEの動作状態を設計することが重要です。
ESP32が自動で共存制御してくれる？
多くの一般的なCoexistenceケースでは、ESP32側が使用状況に応じて共存状態を切り替えます。
ただしESP-IDFでは、Wi-Fi/Bluetooth Coexistenceに関する設定も用意されています。
現行のESP-IDF Programming Guideでは、ソフトウェアによるCoexistence機能についてCONFIG_ESP_COEX_SW_COEXIST_ENABLEを確認するよう案内されています。
また、Dual CoreのESP32では、より良い通信性能を得るため、Wi-Fi Protocol StackとBluetooth Controller / Host StackのTaskを異なるCPU Coreへ配置する方法も公式資料で案内されています。
つまり、
Wi-FiとBLEのAPIを両方呼べば、それで設計検討は終了
というわけではありません。
通信量が多い製品では、Coexistence設定やTask構成も確認する価値があります。
ESP-IDFを含め、ESP32で使用する開発環境の違いについては「ESP32の開発環境を比較｜Arduino IDE・PlatformIO・ESP-IDFはどれを選ぶ？」で詳しく解説しています。
Wi-Fi＋BLEでメモリ使用量は増える？
Wi-FiとBLEを同時に使用するとき、RFの共存だけでなく注意したいのがメモリ使用量です。
ESP32ではWi-Fi DriverやTCP/IP Stack、Bluetooth Controller、Bluetooth Host Stackなどがそれぞれメモリを使用します。
そのため、
Wi-Fiだけを使用するFirmware
と比べると、
Wi-Fi＋BLEを使用するFirmware
では、一般に必要なメモリ量が増えます。
特にESP32では、無線通信以外にも、
- HTTP / HTTPS
- MQTT
- TLS
- JSON
- OTA
- センサー処理
- Display
- File System
などを同時に使用することがあります。
個々の機能では問題がなくても、機能を追加していくうちにHeapの余裕が少なくなることがあります。
製品開発では、単にBuildが通るかだけでなく、実際にWi-FiとBLEを動作させた状態でHeapの残量を確認することをおすすめします。
NimBLEとBluedroidはどう違う？
ESP-IDFでBLEを使用するときには、Bluetooth Host Stackについても考える必要があります。
代表的なのが、
Bluedroid
NimBLE
です。
BluedroidはBluetooth ClassicとBLEを扱えるHost Stackです。
一方、NimBLEはBLE向けのHost Stackで、EspressifはESP-IDFでNimBLEを利用できるよう移植しています。公式Programming Guideでは、NimBLEはBLEのみを必要とする用途に適した、より軽量な選択肢として説明されています。
そのため、
Bluetooth Classicは不要で、BLEだけ使いたい
という製品では、NimBLEを検討する価値があります。
特にWi-Fi、BLE、TLS、Application処理など多くの機能を一つのESP32へ載せる場合、メモリの余裕は重要です。
ただし、
NimBLEを使えばWi-Fi＋BLEのRF競合がなくなる
わけではありません。
Host StackをNimBLEへ変更しても、Wi-FiとBLEがRFリソースを共有する基本構造は変わりません。
NimBLEを選択する理由は、RFを分離するためではなく、主にBLE Host側の機能やメモリ構成を最適化するためと考えると分かりやすいでしょう。
ESP32-C3やESP32-C5でもWi-Fi＋BLEは使える？
ここではシリーズの違いにも注意が必要です。
従来ESP32はDual Coreですが、ESP32-C3やESP32-C5はSingle Core構成です。
それでも、Wi-FiとBLEの共存機能自体は用意されています。
重要なのは、
Dual CoreだからWi-Fi＋BLEが使えて、Single Coreだから使えない
という関係ではないことです。
Wi-FiとBLEのRF共存と、CPU Core数は別の話です。
ただしSingle Coreでは、Application、Wi-Fi、Bluetoothなどの処理が同じCPUリソース上で動作するため、CPU負荷についても意識する必要があります。
従来ESP32のように、
Core 0 → Wi-Fi
Core 1 → Bluetoothといった形でTaskを別Coreへ配置する考え方を、そのままSingle Coreデバイスへ適用することはできません。
そのためC3やC5では、
RFのCoexistence
だけでなく、
CPU使用率
Task Priority
Stack Size
Heap
なども確認しておくとよいでしょう。
また、シリーズによってサポートされる無線機能やCoexistence条件は異なる可能性があります。
実際の製品では、使用するESP32シリーズに対応したESP-IDFのProgramming Guideで最新条件を確認してください。
ESP32-C5の5GHz Wi-FiならBLEと干渉しない？
ESP32-C5では、従来ESP32との大きな違いとして2.4GHzだけでなく5GHz Wi-Fi 6にも対応しています。
ここで、
「Wi-Fiを5GHzにすれば、2.4GHzのBLEとは完全に別だから共存問題もなくなるのでは？」
と思うかもしれません。
周波数帯という意味では、5GHz Wi-Fiと2.4GHz BLEは異なります。
しかし、それだけを理由にWi-Fi＋BLEの共存制御を考えなくてよいとは判断しない方が安全です。
ESP32-C5は2.4GHz/5GHz Wi-FiとBluetooth LE、IEEE 802.15.4などの無線機能を一つのSoCへ統合しており、EspressifはC5についてもRF Coexistence機能を提供しています。
したがって、C5でも実際に使用するWi-Fi Band、BLEの動作、通信量などを含めて評価することが重要です。
特に製品では、
「周波数が違うから問題ないはず」
という推測だけで設計を完了せず、実機で確認しましょう。
Wi-Fi＋BLEが不安定なときに確認すること
Wi-FiとBLEを同時使用して通信が不安定になった場合、すぐにHardware不良と判断するのではなく、まず通信条件を整理します。
1．Wi-Fiの通信量を確認する
大量のデータを連続送信していないか確認します。
たとえばFirmware Updateや大きなFile Uploadなど、通常時とは大きく異なる通信が発生している場合があります。
2．BLEのConnection Intervalを確認する
BLE接続ではConnection IntervalなどのParameterによって、通信頻度が変わります。
必要以上に短いIntervalを設定すると、それだけ頻繁に無線通信が必要になります。
リアルタイム性が必要ないデータなら、通信頻度を下げられないか検討します。
3．BLE Scanを確認する
BLE Scanを常時行っている場合も注意が必要です。
Wi-FiとBLE Scanが同時に動作すると、RFリソースを共有する必要があります。
前半でも触れたように、EspressifはWi-FiとのCoexistenceによってBLE Scan Windowが中断される場合があることを説明しています。
「BLEデバイスを発見できない」という問題でも、必ずしもBLEそのものが停止しているとは限りません。
4．Wi-Fiの状態を確認する
Wi-Fiが安定して接続されているときと、
Scan中
接続処理中
再接続を繰り返している状態
ではRFの使用状況が異なります。
電波環境が悪くWi-Fiが頻繁に再接続していると、BLE側にも影響が出る可能性があります。
5．HeapとStackを確認する
通信問題に見えても、実際にはメモリ不足が原因の場合があります。
Wi-FiとBLEを同時に使用すると必要なメモリも増えるため、
Free Heap
Minimum Free Heap
各TaskのStack余裕
などを確認します。
6．ESP-IDFのバージョンを確認する
ESP-IDFではWi-FiやBluetooth関連機能も継続的に更新されています。
不具合を調査するときは、
「ESP32でWi-Fi＋BLEを使っている」
だけでなく、
ESP32の型番
ESP-IDFのバージョン
Bluetooth Host Stack
Wi-Fi Mode
BLEの動作状態
まで記録しておくと、原因を切り分けやすくなります。
製品ではWi-FiとBLEの役割を分ける
Wi-FiとBLEを両方搭載できるからといって、常に両方で大量通信する必要はありません。
製品では、それぞれの役割を明確にすると設計しやすくなります。
たとえば、
BLE
└─ 初期設定
└─ スマートフォンとの設定通信
└─ 近距離メンテナンス
Wi-Fi
└─ クラウド通信
└─ データUpload
└─ OTAという分け方です。
この構成なら、通常運転ではWi-Fiを中心に使用し、BLEはAdvertisingや低頻度通信に抑えることができます。
必要なときだけBLE Connectionを確立する設計も可能です。
無線機能を、
搭載されているから常時使う
のではなく、
その通信方式が必要な場面だけ使う
と考えると、通信負荷だけでなく消費電力の面でも設計しやすくなります。
「接続できた」だけで評価を終わらせない
試作段階では、
Wi-Fiにつながった
BLEでもスマートフォンにつながった
ところで動作確認を終えたくなります。
しかし製品では、ここからが重要です。
たとえば、
Wi-Fiで通常通信中
↓
BLE接続開始
↓
Wi-Fi大量送信
↓
BLE設定変更
↓
Wi-Fi切断
↓
Wi-Fi再接続
↓
BLE切断・再接続といった実際に起こり得る状態を試します。
さらに、
- Wi-Fi電波が弱い
- BLE側が遠い
- アクセスポイントが一時的に消える
- スマートフォンがBLE圏外へ出る
- OTA中にBLE操作される
などの条件もあります。
特に無線通信は周囲の環境によって状態が変化します。
そのため、Wi-Fi＋BLE製品では正常系だけでなく通信状態が悪いときの評価も重要です。
Wi-Fi＋BLE同時使用チェックリスト
最後に、ESP32でWi-FiとBLEを同時使用するときの確認項目をまとめます。
| 確認項目 | チェック内容 |
|---|---|
| ESP32シリーズ | 使用デバイスのCoexistence仕様を確認したか |
| Wi-Fi Mode | STA / APなど実際の動作Modeを確認したか |
| BLE動作 | Scan / Advertising / Connectionを整理したか |
| 通信量 | Wi-FiとBLEの最大通信量を確認したか |
| BLE Interval | 必要以上に短くしていないか |
| BLE Scan | 常時Scanが本当に必要か |
| Coexistence | ESP-IDFの設定を確認したか |
| CPU負荷 | Applicationを含め余裕があるか |
| Heap | Wi-Fi＋BLE動作時の残量を確認したか |
| Stack | 各Taskに十分な余裕があるか |
| 異常系 | Wi-Fi再接続中なども評価したか |
| 実機評価 | 最大負荷・悪条件でも確認したか |
この表を設計・評価時のチェックリストとして使うと、単純な接続確認だけで終わることを防げます。
まとめ｜ESP32のWi-FiとBLEは同時使用できる。ただしRFは共有する
ESP32では、Wi-FiとBLEを同時に使用できます。
Wi-Fiへ接続しながらBLE Advertisingを行ったり、BLE Connectionを維持しながらWi-Fiでサーバーへデータを送信したりすることも可能です。
ただし、重要なのは、
Wi-FiとBLEが完全に独立した無線回路で同時通信しているわけではない
という点です。
ESP32ではRFリソースを共有し、TDMと優先度制御によってWi-FiとBluetoothを共存させています。
そのため、
同時使用できる＝それぞれ単独使用時と同じ性能が保証される
という意味ではありません。
Wi-Fiの通信量、BLEのConnection IntervalやScan、CPU負荷、Heapなどによって、実際の通信性能は変化します。
特に製品開発では、
「Wi-FiもBLEも接続できた」
だけで評価を終了せず、最大通信量や再接続、電波環境が悪い状態まで確認することが重要です。
Wi-FiとBLEそれぞれの役割を整理し、必要なタイミングで必要な通信を行う設計にすることで、ESP32の無線機能をより安定して活用できます。