「ESP32とArduino UNOは何が違う？」
「初心者ならどちらを選べばいい？」
「Arduino UNOからESP32へ移行するメリットは？」

と迷うことがあります。

どちらもArduino IDEから開発できるため似たようなマイコンボードに見えますが、中身は大きく異なります。

ESP32はWi-FiやBluetoothを内蔵し、高い処理性能と大容量メモリを持っています。

一方、Arduino UNO R3は8bit AVRマイコンを搭載したシンプルな構成で、5V系の電子工作でも扱いやすいボードです。

単純にスペックだけを比較するとESP32が圧倒的に高性能ですが、

高性能だからESP32を選べばよい

とは限りません。

この記事ではESP32とArduino UNO R3について、

CPU性能
メモリ容量
GPIO
3.3Vと5Vの違い
Wi-Fi・Bluetooth
ADCやPWM
開発環境
どちらを選べばよいか

を比較します。

さらに、Arduino UNOからESP32へ移行するときに注意したいポイントも、回路設計とFirmwareの両面から解説します。

この記事ではArduino UNO R3と比較する

最初に比較対象を明確にしておきます。

この記事で「Arduino UNO」と表記する場合、基本的にはArduino UNO R3を指します。

UNO R3はATmega328Pを搭載した、長く使われているArduinoの代表的なボードです。

現在はUNO R4 MinimaやUNO R4 WiFiも販売されていますが、UNO R4ではMCUがRenesas RA4M1へ変更され、32bit ARM Cortex-M4となっています。

そのため、

UNO R3
ATmega328P
8bit AVR
16MHz

に対して、

UNO R4
RA4M1
32bit Cortex-M4
48MHz

と、内部構成は大きく異なります。

Arduino公式によるとUNO R4 MinimaはFlash 256KB、SRAM 32KBを搭載しながら、UNO R3との互換性を意識して5V動作を維持しています。

したがって、

Arduino UNOはすべて8bit・16MHz

というわけではありません。

今回はESP32との違いが分かりやすく、広く使われてきたUNO R3を主な比較対象とします。

ESP32とArduino UNO R3の違いを比較

まず代表的な仕様を比較してみます。

Arduino UNO R3はATmega328Pを搭載し、16MHzで動作します。Flash Memoryは32KB、SRAMは2KB、EEPROMは1KBです。

一方、従来ESP32ではXtensa LX6 Dual Core CPUを搭載し、最大240MHzで動作します。内部SRAMは520KBあり、ESP32-WROOM-32Eでは数MBのSPI Flashを搭載したModuleが用意されています。

数字だけを見ると、かなり大きな差があります。

CPU性能はESP32が圧倒的に高い

Arduino UNO R3のATmega328Pは、8bit AVR CPUを16MHzで動作させます。

一方ESP32は32bit CPUで、従来ESP32では最大240MHzのDual Core構成です。

単純なClockだけでも、

Arduino UNO R3
16MHz

ESP32
最大240MHz

と大きな違いがあります。

もちろんCPU性能はClock周波数だけで決まるものではありません。

CPU Architectureも異なるため、

240 ÷ 16 = 15

だから「ESP32はUNOの15倍速い」と単純に比較することはできません。

それでも、

• 通信処理
• 複数Task
• Display制御
• JSON処理
• Web Server
• 暗号化通信
• Wi-Fi
• Bluetooth

など、多くの処理を同時に行う用途ではESP32の処理能力が有利です。

メモリ容量は大きく違う

個人的には、CPU Clock以上に実際のFirmware開発で差を感じやすいのがRAM容量です。

Arduino UNO R3のSRAMは、

2KB

です。

ESP32は、

520KB SRAM

を搭載しています。

UNO R3では2KBしかないため、大きな配列や文字列Bufferを使用すると、すぐにRAM容量を意識する必要があります。

たとえば、

char buffer[1024];

だけでも1KBです。

UNO R3ではSRAM全体の半分に相当します。

一方ESP32では、より大きなBufferを扱えるため、

HTTP
JSON
Wi-Fi
BLE
Display
File System

などを組み合わせたApplicationを作りやすくなります。

ただし、

ESP32ならRAMを気にしなくてよい

という意味ではありません。

Wi-FiやBluetooth Stackなどもメモリを使用するため、大規模なFirmwareではESP32でもHeapやStackの管理が必要です。

ESP32にはWi-FiとBluetoothがある

ESP32を選ぶ大きな理由の一つが無線通信です。

従来ESP32には、

2.4GHz Wi-Fi
Bluetooth Classic
Bluetooth Low Energy（BLE）

が内蔵されています。

Arduino UNO R3にはWi-FiやBluetooth機能はありません。

そのためUNO R3で無線通信を行う場合は、

Arduino UNO
     │
Wi-Fi Module

など、外部Moduleを追加する必要があります。

ESP32なら、

ESP32
├─ MCU
├─ Wi-Fi
└─ Bluetooth

が一つのSoCに統合されています。

スマートフォン連携やCloud通信、IoT機器などではESP32を選ぶ大きなメリットになります。

ESP32は3.3V、Arduino UNO R3は5V

ここはArduino UNOからESP32へ移行するときに特に注意したいポイントです。

Arduino UNO R3は5V系のボードです。

そのため5Vで動作するSensorやModuleを接続して使った経験がある人も多いでしょう。

一方、ESP32は基本的に3.3V系です。

ESP32-WROOM-32Eの推奨電源条件は3.0～3.6Vです。

したがって、

Arduino UNOで使えた
      ↓
ESP32でも同じように接続

とは考えない方がよいでしょう。

特に外部回路からGPIOへ入力される信号電圧には注意が必要です。

5V信号をESP32 GPIOへそのまま入れない

たとえばUNO R3で、

5V Sensor
   │
   └── Signal → Arduino UNO

としていた回路があるとします。

ESP32へ変更するときに、

5V Sensor
   │
   └── Signal → ESP32

とそのまま置き換えるのは避けます。

外部デバイスが5V Logicを出力する場合は、

抵抗分圧
Level Shifter
適切なInterface IC

などを使用し、ESP32側の入力条件に合わせます。

「Arduino IDEで同じコードが動く」ということと、

Hardwareをそのまま接続できる

ということは別です。

これはUNOからESP32へ移行するときに非常に重要な違いです。

逆にESP32の3.3V出力で5V回路を動かせる？

今度は反対方向です。

ESP32のGPIO HIGHは3.3V系です。

5Vで動作する外部ICへ信号を入力するとき、

ESP32 3.3V HIGH
       ↓
5V IC Input

で正しくHIGHとして認識されるかは、接続先ICの入力電圧仕様によります。

「5V電源で動いているICだから3.3VではHIGHにならない」とも、「3.3Vなら必ずHIGHになる」とも一律には言えません。

確認すべきなのはDatasheetの、

VIH：High-level Input Voltage

です。

ESP32と5V系回路を接続するときは、

電源電圧ではなく、実際の入出力Logic Levelを確認する

ことが重要です。

GPIOの本数だけでは比較できない

Arduino UNO R3にはDigital I/Oが14本あり、そのうち6本をPWM出力として利用できます。またAnalog Inputは6本です。

ESP32にはより多くのGPIOがあります。

ただしESP32では、

GPIO番号が存在する＝すべて自由に同じ用途で使える

とは限りません。

ESP32ではPinによって、

• Input Only
• Boot Strap
• Flashとの接続
• ADC
• Touch Sensor
• RTC GPIO

など、機能や制約が異なります。

そのため単純に、

UNO：14本
ESP32：もっと多い

→ ESP32の方が全部自由に使える

とは考えない方がよいでしょう。

ESP32では、必要なPeripheralと使用可能GPIOを確認してPin Assignmentを決めることが重要です。

ここは既存のESP32ピン関連の記事へ内部リンクできるポイントでもあります。

Arduino UNOにはEEPROMがある

Arduino UNO R3のATmega328Pには1KBのEEPROMがあります。

そのため、

設定値
Calibration値
動作モード

など、電源OFF後も残したいデータをEEPROMへ保存できます。

ESP32にはUNO R3と同じような専用EEPROMはありません。

代わりに、Flash Memory上の**NVS（Non-Volatile Storage）**などを利用して設定値を保存できます。

Arduino-ESP32ではPreferences LibraryからNVSを扱うこともできます。

つまり、

Arduino UNO R3
     ↓
EEPROM

ESP32
     ↓
NVS / Preferences
     ↓
Flash

という違いがあります。

ESP32へ移行するときに、

「EEPROMがないから設定を保存できない」

というわけではありません。

保存方法が変わる、と考えると分かりやすいでしょう。

ここから、前回公開した「ESP32のFlashにデータを保存する方法｜NVS・Preferencesを解説」へ自然に内部リンクできます。

ADCにも違いがある

SensorのAnalog値を読み取る場合も注意が必要です。

Arduino UNO R3には10bit ADCがあり、Analog InputとしてA0～A5を利用できます。

ESP32にもADCがありますが、UNOとまったく同じ感覚で使えるわけではありません。

ESP32ではADC ChannelやAttenuation、入力範囲、ADC特性などを考える必要があります。

またWi-Fi使用時など、使用するESP32やADC Unitによって注意すべき条件があります。

そのため、

analogRead();

という同じようなAPIが使えたとしても、

Hardware内部までArduino UNOと同じ

ではありません。

特にSensorの測定精度が重要な用途では、使用するESP32シリーズのADC仕様を確認する必要があります。

「Arduino IDEが使える」＝Arduino UNOと同じではない

ESP32ではArduino Coreを利用することで、Arduino IDEからFirmwareを開発できます。

そのため、

pinMode();
digitalWrite();
digitalRead();
analogRead();
delay();

など、Arduino経験者には馴染みのあるAPIを使用できます。

これはESP32へ移行しやすい大きなメリットです。

しかし、

Arduino IDEで書けるからArduino UNOと同じマイコン

ではありません。

CPU Architectureも違えば、

Memory
Peripheral
Interrupt
Timer
ADC
GPIO
Wireless

なども異なります。

Arduino APIは違いの一部を隠してくれますが、Hardwareそのものを同じにするものではありません。

ここを理解しておくと、UNOからESP32へ移行したときのトラブルをかなり減らせます。

PWMの仕組みも異なる

Arduino UNO R3では、Digital I/Oのうち6本をPWM出力として利用できます。

Arduinoでは、

analogWrite(pin, value);

を使ったPWM制御に慣れている人も多いでしょう。

ESP32でもPWM出力は可能ですが、内部の仕組みはUNO R3とは異なります。

ESP32にはLEDC（LED Control）Peripheralがあり、PWMの周波数やDutyを設定して使用できます。

そのため、

Arduino UNO R3
    ↓
Timerを利用したPWM

ESP32
    ↓
LEDCなどを利用したPWM

という違いがあります。

ESP32ではPWM周波数や分解能を用途に応じて設定できますが、周波数とDuty Resolutionには関係があります。

「分解能を高くして、周波数もいくらでも高くできる」というわけではありません。

LEDの調光、Motor制御、Buzzerなど、用途に合わせてPWM条件を決める必要があります。

UART・SPI・I2CはESP32の方が柔軟

外部Deviceとの通信では、

UART
SPI
I2C

などをよく使用します。

Arduino UNO R3にもこれらのPeripheralがありますが、ESP32ではより複雑なApplicationを想定した構成になっています。

特にESP32にはGPIO Matrixという仕組みがあります。

Peripheral Signalを特定の固定Pinだけでなく、さまざまなGPIOへRoutingできるため、Pin Assignmentの自由度が高くなっています。

たとえば基板設計で、

UART TX
UART RX
SPI MOSI
SPI MISO
SPI CLK

などを配置するとき、UNOより柔軟にPinを選択できる場合があります。

これは自作基板では非常に便利です。

ただし自由度が高い分、

どのGPIOを使っても同じ

というわけではありません。

Boot Strap PinやInput Only Pin、Flashなどで使用されるPin、Peripheral固有の制約を確認する必要があります。

ESP32の方が消費電力は大きい？

これは使い方によって変わります。

ESP32は高性能CPUに加えてWi-FiやBluetoothを搭載しているため、無線通信中には相応の電流を消費します。

そのため、

単純な処理だけを常時実行するなら、ESP32の方が必ず省電力

とは言えません。

一方、ESP32にはLight SleepやDeep Sleepなどの省電力機能があります。

たとえばBattery駆動Sensorなら、

Deep Sleep
    ↓
TimerでWake-up
    ↓
Sensor測定
    ↓
Wi-Fi接続
    ↓
Data送信
    ↓
再びDeep Sleep

という動作ができます。

つまり消費電力を比較するときは、

MCUの通常動作電流

だけを見るのではなく、

製品が1日を通して
どの状態で何時間動作するか

を見る必要があります。

ESP32のDeep Sleepについては、既存の「ESP32 Deep Sleep完全ガイド」へ内部リンクできます。

リアルタイム制御ならArduino UNOの方がいい？

「ESP32はWi-FiやRTOSが動いているから、Arduino UNOの方がリアルタイム制御に向いている」

という話を見かけることがあります。

これは用途を分けて考える必要があります。

Arduino UNO R3では、基本的に非常にシンプルなFirmware構成になります。

setup()
  ↓
loop()
  ↓
Interrupt

という構成を把握しやすく、

いつ、どの処理が実行されるのか

を比較的追いやすいというメリットがあります。

一方ESP32では、FreeRTOSをベースとしたSoftware環境が使われ、Wi-FiやBluetoothなど複数の処理も動作します。

そのため、厳密なTimingが必要な処理を、

delayMicroseconds();

だけに頼って実装するのではなく、

Hardware Timer
Peripheral
Interrupt
Task Priority

などを適切に使う必要があります。

ただし、

ESP32ではリアルタイム制御ができない

という意味ではありません。

重要なのは、必要なTiming精度に応じてHardware PeripheralやSoftware構成を選ぶことです。

Dual Coreなら処理能力が2倍になる？

従来ESP32はDual Core CPUを搭載しています。

そこで、

「Arduino UNOがSingle Coreなら、ESP32はDual Coreだから単純に2倍？」

と思うかもしれません。

これも単純には比較できません。

Dual Coreだからといって、一つの処理が自動的に2倍の速度で実行されるわけではありません。

ESP32では複数Taskを別Coreで実行する構成も可能ですが、Application側の設計が必要です。

たとえば、

Task A
Sensor処理

Task B
通信処理

のように役割を分けることができます。

一方、ESP32-C3やESP32-C5など、Single CoreのESP32シリーズも存在します。

したがって、

ESP32＝すべてDual Core

と覚えないようにしましょう。

使用するESP32シリーズによってCPU構成は異なります。

ESP32はシリーズによる違いも大きい

ここもArduino UNOとの比較で注意したいところです。

「ESP32」と一言で呼んでいますが、現在は複数のシリーズがあります。

たとえば、

ESP32
ESP32-S2
ESP32-S3
ESP32-C3
ESP32-C5
ESP32-C6
ESP32-H2

などです。

シリーズによって、

CPU Architecture
Core数
Wi-Fi
Bluetooth
USB
GPIO
Memory

などが異なります。

そのため、

「ESP32を使いたい」

と決めた後にも、

どのESP32シリーズを選ぶか

という選定があります。

ESP32を選んだ後に「どのシリーズを選べばよいか」で迷った場合は、「ESP32シリーズの選び方」で用途別に詳しく比較しています。

Arduino UNOからESP32へコードはそのまま移植できる？

簡単なSketchであれば、そのまま動く場合もあります。

たとえば、

pinMode(2, OUTPUT);

digitalWrite(2, HIGH);
delay(1000);

digitalWrite(2, LOW);
delay(1000);

のような基本的なArduino APIを使ったコードなら、Pin番号などを修正するだけで移植できることがあります。

しかしFirmwareが複雑になるほど注意点が増えます。

1．GPIO番号をそのまま使わない

UNOで、

digitalWrite(13, HIGH);

としていたからといって、ESP32でもGPIO13を同じ用途にそのまま割り当てる必要はありません。

使用するESP32 BoardやModuleのPin配置を確認して決めます。

2．5V前提の外部回路を確認する

Firmwareが移植できてもHardwareが対応しているとは限りません。

特に、

Sensor Output
UART
I2C Pull-up
SPI Device

などのLogic Voltageを確認します。

UNO R3の5V環境からESP32の3.3V環境へ変更するときには、ここを最優先で確認した方がよいでしょう。

3．Arduino LibraryがESP32に対応しているか確認する

Arduinoには非常に多くのLibraryがあります。

しかし、

Arduino用LibraryだからESP32でも必ず動く

とは限りません。

Library内部で、

AVR固有Register
Timer
Interrupt
Pin構成

などへ直接アクセスしている場合、ESP32ではそのまま使用できないことがあります。

反対にArduino APIだけで実装されているLibraryなら、比較的移植しやすい場合があります。

使用前にESP32対応状況を確認しましょう。

4．EEPROM処理を見直す

UNO R3で、

EEPROM.read();
EEPROM.write();

などを使用していた場合、ESP32では保存方法を見直します。

ESP32ではNVSを利用でき、Arduino-ESP32ならPreferences Libraryを使用できます。

単にAPIを置き換えるだけでなく、

保存するデータ
書き込み頻度
Factory Reset
Firmware Update後の互換性

まで整理すると、より製品向けの設計になります。

5．TimerやInterrupt処理を確認する

Arduino UNO R3のATmega328PとESP32ではTimerやInterrupt Controllerの構造が異なります。

そのため、AVR固有のRegisterを直接操作しているコードは、そのまま移植できません。

たとえば、

TCCR1A
TCCR1B
OCR1A

などATmega328P固有Registerを操作している場合は、ESP32のPeripheralに合わせて実装し直す必要があります。

Arduino UNO R3を選ぶメリット

ここまで読むと、

「それならESP32を選べばいいのでは？」

と思うかもしれません。

しかしUNO R3にもメリットがあります。

まず構成が非常にシンプルです。

8bit MCU、少ないMemory、基本的なPeripheralという構成なので、マイコンの基本を学ぶには分かりやすいBoardです。

また5V系であるため、5V LogicのDeviceを扱う用途では接続しやすい場合があります。

さらに長年使われてきたため、TutorialやLibrary、作例などの情報量も非常に多くあります。

ESP32を選ぶメリット

ESP32の大きなメリットは、やはり機能の多さです。

Wi-Fi
Bluetooth
高いCPU性能
大容量Memory
豊富なPeripheral
省電力機能

を一つのSoCで利用できます。

特に、

スマートフォン連携
Cloud通信
Web Server
OTA
BLE
Wi-Fi Sensor
IoT Device

などを作るなら、ESP32は非常に有力な選択肢です。

またArduino Frameworkから始めて、必要になればESP-IDFへ移行できることもメリットです。

初心者ならどちらを選ぶ？

「初心者にはArduino UNO」と一律に決める必要はないと思います。

作りたいものによって選ぶ方がよいでしょう。

LEDを点滅させたり、SwitchやSensorを接続したりして、

まずマイコンの基本を学びたい

のであればArduino UNO R3は分かりやすい選択です。

一方、

最初からWi-Fiやスマートフォン連携をやりたい

のであれば、ESP32から始めても問題ありません。

Arduino-ESP32を利用すれば、ESP32でもArduino IDEから、

setup()
loop()

という馴染みやすい形で開発できます。

重要なのは、

初心者だから低性能なマイコンを選ぶ

ことではなく、

作りたいものに必要な機能を持ったマイコンを選ぶ

ことです。

製品開発ならどちらを選ぶ？

製品開発では、さらに判断基準が増えます。

単純な性能だけでなく、

必要なI/O
通信Interface
消費電力
部品コスト
基板面積
供給性
開発環境
Software資産
認証

などを考えます。

Wi-FiやBLEが必要ならESP32は非常に魅力的です。

一方、無線通信が不要で、

Switch入力
Sensor入力
Relay制御
UART通信

程度のシンプルな制御なら、ESP32ほどの性能が必要ない場合もあります。

その場合はArduino UNOそのものを製品へ搭載するという意味ではなく、要求仕様に合った別のMCUを選ぶという判断もあります。

製品設計では、

高性能なMCUを選ぶ

ことより、

必要十分なMCUを選ぶ

ことが重要です。

ESP32とArduino UNO R3、どちらを選ぶ？

用途別に整理すると、次のようになります。

単純な勝ち負けではなく、必要な機能によって選択するのがよいでしょう。

Arduino UNOからESP32へ移行するときのチェックリスト

最後に、UNO R3からESP32へ移行するときに確認したいポイントをまとめます。

特にHardwareでは、5Vと3.3Vの違いを最初に確認しましょう。

SoftwareがBuildできたからといって、Hardwareまで互換とは限りません。

まとめ｜性能ではなく「何を作るか」で選ぶ

ESP32とArduino UNO R3は、どちらもArduino IDEから開発できますが、中身は大きく異なります。

Arduino UNO R3は、

8bit AVR
16MHz
SRAM 2KB
5V系

というシンプルな構成です。

ESP32は、

32bit CPU
高いClock周波数
大容量Memory
Wi-Fi
Bluetooth

など、多くの機能を搭載しています。

性能だけを見ればESP32が大きく上回ります。

しかし、

ESP32の方が高性能だから、常にESP32を選ぶべき

というわけではありません。

シンプルな電子工作や5V系回路の扱いやすさを重視するなら、Arduino UNO R3にもメリットがあります。

一方、

Wi-Fiを使いたい
BLEを使いたい
Web通信をしたい
より複雑なFirmwareを動かしたい

のであれば、ESP32が有力です。

そしてArduino UNOからESP32へ移行するときに最も注意したいのは、

同じArduino APIが使えることと、Hardwareが互換であることは別

という点です。

GPIO電圧、Pin機能、ADC、Timer、EEPROMなど、それぞれの違いを確認して移植する必要があります。

マイコン選定ではスペック表の数字だけを見るのではなく、

自分が何を作りたいのか

から必要な機能を決めることが、最も重要です。

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

「電源を切っても設定値を残したい」
「Wi-Fiの設定を保存したい」
「最後に設定した値を次回起動時にも使いたい」

という場面があります。

通常の変数はRAM上に保存されるため、ESP32の電源をOFFすると内容は失われます。

たとえば、

int temperature = 25;

と変数へ値を保存しても、これは電源OFF後まで保持される設定データにはなりません。

そこでESP32では、Flash Memoryへデータを保存する方法として**NVS（Non-Volatile Storage）**を利用できます。

Arduino-ESP32を使用している場合には、NVSを扱いやすくしたPreferences Libraryも用意されています。EspressifはPreferencesを従来のArduino EEPROM Libraryに代わる方法として案内しています。

この記事では、

NVSとは何か
Preferencesとの違い
実際に値を保存・読み出す方法
Flashの書き換え寿命
NVSへ保存するのに向いているデータ

まで解説します。

なぜ普通の変数ではデータを保存できない？

まずESP32のメモリについて簡単に整理します。

プログラム実行中に使用する変数の多くはRAM上に置かれます。

イメージとしては、

ESP32

RAM
├─ 変数
├─ Stack
└─ Heap

Flash
├─ Firmware
├─ NVS
└─ File Systemなど

という構成です。

RAMは高速に読み書きできますが、電源がなくなると内容が失われる揮発性メモリです。

一方、Flash Memoryは電源を切っても内容を保持できます。

したがって、

電源ON
  ↓
設定値を変更
  ↓
電源OFF
  ↓
次回起動
  ↓
前回の設定値を復元

という動作を実現するには、設定値を不揮発メモリへ保存する必要があります。

ESP32のNVSとは？

NVSはNon-Volatile Storageの略です。

ESP-IDFに用意されている、Flash Memory上へデータを保存するための仕組みです。

NVSではデータを、

Key → Value

というKey-Value形式で管理します。

たとえば、

"volume" → 8
"temp"   → 25
"mode"   → 1

というように、データへ名前を付けて保存できます。

さらにNVSではNamespaceを使ってKeyをグループ分けできます。

Namespace : "settings"

├─ "volume" → 8
├─ "temp"   → 25
└─ "mode"   → 1

別のNamespaceなら、同じKey名を使用しても衝突しません。ESP-IDFのNVS APIでも、nvs_open()でNamespaceを指定し、取得したHandleを使ってnvs_get_*()やnvs_set_*()などを操作する構造になっています。

製品Firmwareでも、

"system"
"network"
"sensor"
"user"

など、用途ごとにデータを整理できます。

NVSにはどんなデータを保存できる？

NVSでは整数だけでなく、複数種類のデータを扱えます。

代表的には、

• 8～64bitの整数
• String
• Blob（Binary Data）

などです。

Arduino-ESP32のPreferencesでは、さらにAPIとして、

putBool()
putInt()
putUInt()
putFloat()
putDouble()
putString()
putBytes()

などが用意されています。

そのため、

温度設定値
音量
動作モード
Calibration値
初期設定完了フラグ
Wi-Fi関連の設定

など、小さな設定値を保存する用途に向いています。

NVSとPreferencesは何が違う？

ここは混同しやすいポイントです。

NVSとPreferencesは別々の保存媒体ではありません。

Arduino-ESP32のPreferences Libraryは、内部でESP32のNVSを利用しています。Espressifの公式Arduino-ESP32 Documentationでも、PreferencesはESP32のNVSを利用してデータを保存すると説明されています。

関係を簡単にすると、

Arduino-ESP32
     │
Preferences
     │
    NVS
     │
Flash Memory

となります。

一方、ESP-IDFを直接使用する場合は、

ESP-IDF
   │
 NVS API
   │
Flash Memory

という使い方ができます。

つまり、

PreferencesはNVSをArduinoから扱いやすくしたAPI

と考えると分かりやすいでしょう。

ArduinoでPreferencesを使って値を保存する

Arduino-ESP32では、Preferences Libraryを使用すると比較的簡単にNVSへ値を保存できます。

まず、

#include <Preferences.h>

Preferences preferences;

とします。

そしてNamespaceを開きます。

preferences.begin("settings", false);

"settings"がNamespace名です。

第2引数のfalseはRead/Write Modeを意味します。trueを指定するとRead Onlyになります。

値を保存する場合は、

preferences.putInt("temp", 25);

とします。

これで、

Namespace : settings
Key       : temp
Value     : 25

として保存できます。

処理が終わったら、

preferences.end();

でNamespaceを閉じます。

保存した値を読み出してみる

次回起動時には、保存した値を読み出せます。

たとえば、

preferences.begin("settings", true);

int temperature = preferences.getInt("temp", 20);

preferences.end();

とします。

ここでは"temp"というKeyから値を取得しています。

第2引数の20は、Keyが存在しなかった場合に返すDefault値です。

つまり初回起動などでまだデータが保存されていなくても、

保存済み
   ↓
保存値を使用

未保存
   ↓
Default値を使用

という処理にできます。

PreferencesではNamespaceをRead Onlyで開いても値の読み出しは可能です。値を書き込む場合にはRead/Write Modeで開く必要があります。

電源OFFしても本当に値は残る？

残ります。

PreferencesはESP32のNVSを利用しているため、保存したデータはRestartや電源断をまたいで保持されます。

たとえば、

初回起動
temp = 20

   ↓

ユーザー操作
temp = 28

   ↓
NVSへ保存

   ↓
電源OFF

   ↓
再び電源ON

   ↓
NVSから読み出す

temp = 28

という動作を作れます。

設定値を保存する機器では非常によく使う処理です。

初回起動かどうかを判定することもできる

製品では、

工場出荷状態

と

一度設定された状態

を区別したいことがあります。

PreferencesではisKey()を使って、特定のKeyが存在するか確認できます。Espressifの公式Tutorialでも、この方法を利用して初回起動時にDefault設定を作成する例が紹介されています。

たとえば、

preferences.begin("settings", false);

if (!preferences.isKey("init")) {
    preferences.putInt("temp", 25);
    preferences.putBool("init", true);
}

preferences.end();

とすれば、"init"が存在しない場合だけ初期値を書き込めます。

これを利用すると、

初回起動
   ↓
Factory Defaultを書き込む
   ↓
init = true

以降の起動
   ↓
保存済み設定を読み出す

という構成にできます。

製品Firmwareでは使いやすい方法です。

NVSは何でも保存する場所ではない

ここからが重要です。

NVSは便利ですが、Flashへ保存できるからといって、あらゆるデータをNVSへ書けばよいわけではありません。

EspressifはNVSについて、主に頻繁には変化しないConfiguration Dataの保存を推奨しています。反対に、頻繁かつ大量に更新するLogging用途などには適さないと説明しています。

たとえば、

○ 向いている

温度設定値
Wi-Fi設定
Calibration値
動作モード
ユーザー設定
初期化済みフラグ

に対して、

△～× 向いていない

高速Sampling Data
毎秒更新するLog
大量の画像Data
大きなFile
連続的な履歴Data

という違いがあります。

Arduino-ESP32のPreferences Documentationでも、多数の小さな値の保存に適しており、大量データならLittleFSなどのFile Systemを検討するよう案内されています。

Flashには書き換え寿命がある

NVSの保存先であるSPI NOR Flashには、無制限にErase/Writeできるわけではありません。

そのため、

void loop()
{
    preferences.putInt("temp", temperature);
}

のように、Loopを回るたびにFlashへ書き込む設計は避けます。

NVSにはFlashの特定領域だけへ書き込みが集中しないよう、内部にWear Levelingの仕組みがあります。EspressifのFAQでも、NVSには独自のErase/Write balancing mechanismが実装されていることが説明されています。

ただし、

Wear Levelingがある＝何回でも書き込んでよい

ではありません。

FlashそのものにはErase Cycleの寿命があります。

したがってFirmware側でも、不要な書き込みを減らす設計が重要です。

「値が変わったときだけ保存する」

基本的な考え方はシンプルです。

たとえば温度設定値なら、

現在値 25℃
   ↓
ユーザーが28℃へ変更
   ↓
RAM上では28℃
   ↓
設定確定
   ↓
NVSへ28℃を保存

とします。

毎Loop、

25 → 保存
25 → 保存
25 → 保存
25 → 保存
25 → 保存

とする必要はありません。

設定値が変化したときや、ユーザーが設定を確定したタイミングなど、意味のあるタイミングだけFlashへ保存する方が合理的です。

NVSは電源断にも配慮されている

製品では、Flashへ書き込んでいる途中で突然電源が切れる可能性もあります。

NVSはこの点も考慮されており、Espressifは突然のPower Lossに対する保護とAtomic UpdateをNVSの特徴として挙げています。

これは設定値を扱ううえで大きなメリットです。

ただし、これも、

「いつ電源を切ってもApplication側では何も考えなくてよい」

という意味ではありません。

製品全体としては、電源断の可能性、保存するタイミング、設定値の整合性などを考える必要があります。

ESP-IDFでNVSへデータを保存する

Arduino-ESP32ではPreferencesを利用しましたが、ESP-IDFではNVS APIを直接使用できます。

基本的な流れは、

NVSを初期化
    ↓
Namespaceを開く
    ↓
値を読み書き
    ↓
Commit
    ↓
Handleを閉じる

です。

まずNVS Flashを初期化します。

#include "nvs_flash.h"
#include "nvs.h"

esp_err_t ret = nvs_flash_init();

if (ret == ESP_ERR_NVS_NO_FREE_PAGES ||
    ret == ESP_ERR_NVS_NEW_VERSION_FOUND) {

    ESP_ERROR_CHECK(nvs_flash_erase());
    ret = nvs_flash_init();
}

ESP_ERROR_CHECK(ret);

NVS Partitionに空きPageがない場合や、現在のNVS Libraryと互換性のない形式が検出された場合などを考慮した、ESP-IDFで一般的に使われる初期化方法です。EspressifのNVS API Documentationでも同様の初期化処理が示されています。

Namespaceを開く

NVSを初期化したら、nvs_open()でNamespaceを開きます。

nvs_handle_t handle;

ESP_ERROR_CHECK(
    nvs_open("settings", NVS_READWRITE, &handle)
);

ここでは、

Namespace = settings
Mode      = Read / Write

として開いています。

読み出しだけでよければ、

NVS_READONLY

を指定できます。

Preferencesの、

preferences.begin("settings", false);

と考え方はよく似ています。

ESP-IDFで整数を保存する

たとえば温度設定値25を保存する場合は、

int32_t temperature = 25;

ESP_ERROR_CHECK(
    nvs_set_i32(handle, "temp", temperature)
);

とします。

ただし、ESP-IDFではここで終わりではありません。

重要なのが、

ESP_ERROR_CHECK(
    nvs_commit(handle)
);

です。

NVS APIでは、nvs_set_*()を実行しただけでは変更内容が必ずしもNon-Volatile Storageへ確定しているとは限りません。nvs_commit()を呼び出して変更を確定します。

最後に、

nvs_close(handle);

でHandleを閉じます。

ESP-IDFで保存値を読み出す

保存した値はnvs_get_*()で取得できます。

int32_t temperature = 20;

esp_err_t err =
    nvs_get_i32(handle, "temp", &temperature);

if (err == ESP_ERR_NVS_NOT_FOUND) {
    temperature = 20;
}

この例では、"temp"が存在しなければDefault値として20を使用しています。

Preferencesの、

preferences.getInt("temp", 20);

ではDefault値まで一つのAPIで指定できましたが、ESP-IDFでは戻り値を確認して処理できます。

少しコード量は増えますが、

Keyが存在しない
データ型が違う
その他のErrorが発生した

といった状態をApplication側で明確に扱えます。

nvs_commit()を忘れない

ESP-IDFでNVSを初めて使うときに注意したいのがnvs_commit()です。

基本的には、

nvs_set_xxx()
     ↓
nvs_set_xxx()
     ↓
nvs_set_xxx()
     ↓
nvs_commit()

という流れで変更内容を確定できます。

たとえば、

ESP_ERROR_CHECK(
nvs_set_i32(handle, “temp”, 25)
);

ESP_ERROR_CHECK(
nvs_set_u8(handle, “mode”, 1)
);

ESP_ERROR_CHECK(
nvs_commit(handle)
);

のように複数項目を更新したあと、Commitすることもできます。

ここでも、

1回値を変更するたびに、何も考えずFlashへ書き込む

のではなく、Applicationとして設定が確定するタイミングを考えることが重要です。

PreferencesとESP-IDF NVS APIはどちらを使う？

どちらを使うかは、使用しているFrameworkによって考えると分かりやすいです。

Arduino Frameworkで小さな設定値を保存するなら、Preferencesは非常に扱いやすい方法です。

一方ESP-IDFでは、NVS APIを直接使うことでError処理やPartitionなどを含めて、より細かく制御できます。

重要なのは、

PreferencesとNVSのどちらが高性能か

という比較ではありません。

Preferences自体がNVSを利用しているため、使用しているFrameworkに適したInterfaceを選ぶと考える方が自然です。

Arduino IDE・PlatformIO・ESP-IDFの違いや、どの開発環境を選べばよいかについては「ESP32の開発環境を比較｜Arduino IDE・PlatformIO・ESP-IDFはどれを選ぶ？」で詳しく解説しています。

NVSとLittleFSはどう使い分ける？

ESP32ではFlashへデータを保存する方法として、NVS以外にLittleFSなどのFile Systemを利用する方法もあります。

大まかな使い分けは、

と考えると分かりやすいでしょう。

NVSはKeyを指定して、

"temp" → 25

のように扱う用途が得意です。

一方、

/config/settings.json

のようにFileそのものとして管理したければ、File Systemの方が扱いやすい場合があります。

EspressifもNVSをConfiguration Dataなどの保存に適した方式として位置付け、大量データについてはFile System等の利用を案内しています。

Factory Resetはどう実装する？

製品では、保存した設定を工場出荷状態へ戻したい場合があります。

Preferencesでは、

preferences.clear();

を使用すると、現在開いているNamespace内のKeyを削除できます。

特定のKeyだけ削除するなら、

preferences.remove("temp");

も利用できます。

ESP-IDFでは、

nvs_erase_key(handle, "temp");

で特定Keyを削除できます。

Namespace内のすべてのKeyを削除する場合は、

nvs_erase_all(handle);
nvs_commit(handle);

とします。

これを利用して、

Factory Reset操作
       ↓
設定Namespaceを消去
       ↓
再起動
       ↓
Keyなしを検出
       ↓
Default設定を生成

という構成にできます。

NVS Partition全体を簡単に消さない

ここは製品Firmwareでは注意したいところです。

Factory Resetだからといって、

nvs_flash_erase();

を安易に呼ぶ設計にはしない方がよいでしょう。

NVS PartitionにはApplicationが想定している以外のデータが存在する可能性があります。

たとえば、

user_settings
network
calibration
production

のように用途をNamespaceで分けておけば、

ユーザー設定だけ初期化する
Calibration値は残す

といった制御ができます。

Factory Resetで「何を消して、何を残すか」は、製品仕様として決めておくことが重要です。

Firmwareを更新してもNVSの値は残る？

通常、Firmwareを書き換えただけでNVS Partitionが自動的に消去されるわけではありません。

そのためOTAなどでFirmwareを更新した後も、NVSに保存された設定値を引き継ぐ設計ができます。

これは便利ですが、別の問題もあります。

たとえばVersion 1のFirmwareで、

temp
mode

を保存していたとします。

Version 2では、

temp
mode
language
sensor_type

へ設定項目が増えるかもしれません。

さらに将来、

mode : uint8_t

だったものを別の形式へ変更する可能性もあります。

すると、

古いFirmwareが保存したデータを、新しいFirmwareがどう解釈するか

を考える必要があります。

設定データにもVersionを持たせる

長期間更新する製品では、設定データにVersion情報を持たせる方法があります。

たとえば、

config_version = 2
temp           = 25
mode           = 1

としておきます。

起動時に、

NVS読出し
   ↓
config_version確認
   ↓
現在Versionと同じ？
   ├─ YES → そのまま使用
   │
   └─ NO
       ↓
   Migration処理

とします。

これによってFirmware Update後に設定項目が変わっても、古い設定を新しい形式へ変換できます。

これはNVS固有の機能というより、Application側で設計するデータ管理方法です。

しかし製品を長期間Updateするなら非常に重要になります。

Calibration値とユーザー設定は分ける

もう一つ実務でおすすめしたいのが、保存データを種類ごとに分けることです。

たとえば、

Namespace : "user"
├─ temp
├─ volume
└─ mode

Namespace : "cal"
├─ offset
└─ gain

Namespace : "system"
├─ config_version
└─ initialized

という構成です。

こうしておけばFactory Resetするときに、

user → 消す
cal  → 残す

といった処理ができます。

工場で書き込んだCalibration値までユーザー操作で消えてしまう設計は避けたいところです。

データの用途と寿命を考えてNamespaceを設計すると、後々のFirmware変更にも対応しやすくなります。

保存直後に電源を切って大丈夫？

NVS自体には突然のPower Lossを考慮した仕組みがありますが、製品としてはもう一段考えます。

たとえばユーザーが設定を変更するたびに、

ボタン操作
 ↓
即Flash Write
 ↓
ボタン操作
 ↓
即Flash Write

とすると、操作回数だけ書き込みが発生します。

そこで、

設定変更
 ↓
RAM上で更新
 ↓
一定時間変更なし
 ↓
設定確定
 ↓
NVSへ保存

という方法も考えられます。

ただし保存を遅らせすぎれば、その間に電源が切れたとき変更内容が失われます。

つまり、

Flash寿命を優先して保存回数を減らす

ことと、

設定変更を確実に残す

ことにはTrade-offがあります。

製品仕様に応じて保存タイミングを決める必要があります。

毎秒保存するとどうなる？

仮に設定値を毎秒Flashへ書き込むとします。

1日では、

60 × 60 × 24
= 86,400回

です。

1年では約3,150万回の保存要求になります。

NVSにはWear Levelingがあるため、「同じFlash Cellを3,150万回直接Eraseする」という単純な話ではありません。

しかし、そもそも設定値を毎秒不揮発化する必要がないのであれば、Firmware側で不要な書き込みを発生させないことが第一です。

たとえば累積稼働時間のような値を保存したい場合にも、毎秒Flashへ保存するのではなく、

RAM上で積算
 ↓
一定間隔
または
正常Shutdown時
 ↓
NVSへ保存

など、要求仕様に応じた方法を検討します。

NVSへ保存する値・しない値を最初に決める

Firmware設計時には、変数ごとに、

電源OFF後も必要？

を考えると整理しやすくなります。

たとえば、

「後で必要になるかもしれないから全部保存する」のではなく、電源断後に復元する必要があるものだけを選ぶのが基本です。

製品FirmwareでのNVS設計チェックリスト

最後に、実際にNVSを使うときの確認項目をまとめます。

APIを呼んで値を保存するだけなら簡単です。

しかし製品では、数年後のFirmware Updateまで考えて保存データを設計することが重要になります。

まとめ｜ESP32の設定保存にはNVSを活用する

ESP32で電源OFF後も設定値を保持したい場合、NVSを利用できます。

Arduino-ESP32ではPreferences Libraryを使うことで、NVSを比較的簡単に扱えます。

ESP-IDFではNVS APIを直接使用し、

nvs_open()
nvs_get_xxx()
nvs_set_xxx()
nvs_commit()
nvs_close()

という流れでデータを管理できます。

重要なのは、

Flashに保存できるから、何でも保存する

という考え方にしないことです。

NVSは、

設定値
Calibration値
動作モード
初期化Flag

など、小さく、頻繁には変更されないデータの保存に適しています。

大量のデータや頻繁なLogには、用途に応じてLittleFSなど別の保存方法を検討します。

また製品Firmwareでは、

書き込み頻度
Factory Reset
設定Version
Firmware Update時のMigration

まで考えておくことで、後からFirmwareを変更したときにも対応しやすくなります。

NVSは単なる「電源を切っても値が残る機能」ではありません。

製品の設定データを長期間どう管理するか

という視点で使うと、より実用的な仕組みになります。

今回の記事からは、既存の**「ESP32の開発環境を比較｜Arduino IDE・PlatformIO・ESP-IDFはどれを選ぶ？」**への内部リンクも自然に設定できます。PreferencesとESP-IDF NVS APIの違いを読んで「そもそもどの開発環境を選ぶ？」となった読者をつなげられます。

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

たとえば、

「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の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の無線機能をより安定して活用できます。

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

ESP32について調べると、

「Arduino IDEが簡単」
「PlatformIOの方が本格的」
「製品開発ならESP-IDFを使うべき」

といった情報が見つかります。

しかし、初めてESP32を使う場合、

「結局どれを選べばいい？」
「Arduino IDEで作ったプログラムは後から移行できる？」
「PlatformIOとESP-IDFは何が違う？」
「ESP-IDFはコマンド操作ができないと使えない？」

と迷うこともあると思います。

結論から言うと、すべての人にとって最適な開発環境が一つあるわけではありません。

試作を素早く動かしたい場合と、長期間保守する製品Firmwareを開発する場合では、求められるものが違います。

この記事では、ESP32でよく使われる

Arduino IDE
PlatformIO + Visual Studio Code
ESP-IDF + Visual Studio Code

の3つを比較し、それぞれどのような開発に向いているのかを解説します。

最初に知っておきたい「IDE」と「Framework」の違い

3つを比較する前に、少し整理しておきたいことがあります。

Arduino IDE、PlatformIO、ESP-IDFは、厳密にはすべて同じ種類のものではありません。

たとえば、

Arduino IDEはプログラムを編集・ビルド・書き込みするための統合開発環境です。

PlatformIOはVS Codeなどと組み合わせて利用できる組み込み開発向けの開発エコシステムで、ESP32ではArduino FrameworkとESP-IDFの両方を扱えます。PlatformIOの公式ドキュメントでも、ESP32向けFrameworkとしてArduinoとEspressif IoT Development Frameworkの両方が用意されています。

そして**ESP-IDF（Espressif IoT Development Framework）**は、Espressifが提供するESP32向けの公式開発Frameworkです。

そのため、

Arduino IDE vs PlatformIO vs ESP-IDF

という比較は、厳密には同じ階層の製品同士を比較しているわけではありません。

しかし実際にESP32を開発するときには、この3つが「どの環境で開発するか」という選択肢として比較されることが多いため、この記事でも実際の使い方を基準に比較します。

まずは3つの違いを比較

大まかな特徴を整理すると、次のようになります。

※ArduinoをESP-IDF Componentとして利用する方法もあります。Espressifも公式にこの構成をサポートしています。

この表だけを見るとESP-IDFが最も高機能に見えますが、高機能＝すべての用途で使いやすい、ではありません。

LEDを点滅させたり、センサーを一つ接続したりするだけなら、Arduino IDEの手軽さは大きなメリットです。

逆に複数人でFirmwareを管理したり、細かなESP32の設定を扱ったりする場合には、ESP-IDFやPlatformIOが便利になります。

Arduino IDE｜まずESP32を動かしたいなら強い

Arduino IDEの最大のメリットは、始めるまでのハードルが低いことです。

ESP32用のArduino Coreを導入すれば、Arduinoと同じような書き方でESP32を開発できます。

代表的なのが、

void setup()
{
    Serial.begin(115200);
}

void loop()
{
}

というおなじみの構造です。

GPIO、UART、I²C、SPI、Wi-FiなどもArduino APIや対応ライブラリを利用して比較的簡単に扱えます。

Arduino IDEのメリット

特に大きいのが情報量とライブラリの多さです。

ESP32で何かを動かそうとして検索すると、Arduino向けのサンプルコードが大量に見つかります。

センサー、LCD、モーター、クラウドサービスなどについても、Arduino対応ライブラリが用意されていることがあります。

そのため、

まずESP32を触ってみたい
短時間で試作品を作りたい
既存ライブラリを利用したい

という場合には非常に便利です。

Arduino IDEのデメリット

一方、プロジェクトが大きくなると管理面で物足りなさを感じる場合があります。

ソースファイルが増えたり、複数のビルド条件を管理したり、ライブラリやFrameworkのバージョンを厳密に固定したりすると、より高度なプロジェクト管理が欲しくなります。

また、ESP32固有の細かな設定を扱う場合には、ESP-IDFの方が直接的です。

Arduino IDEが「簡易版ESP32開発環境」という意味ではありませんが、プロジェクトの規模や要求が大きくなるにつれて別の環境を検討する余地が出てくると考えると分かりやすいでしょう。

PlatformIO + VS Code｜Arduinoから一段進んだ開発環境

Arduino Frameworkを使いたいけれど、プロジェクト管理もしっかり行いたい。

そんな場合に有力なのがPlatformIO + Visual Studio Codeです。

PlatformIOでは、プロジェクトごとにplatformio.iniを持ち、

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino

のように使用するPlatform、Board、Frameworkなどを設定できます。ESP32ではArduino FrameworkだけでなくESP-IDFも選択できます。

PlatformIOのメリット

PlatformIOの大きなメリットは、開発条件をプロジェクトとして管理しやすいことです。

たとえば一つのプロジェクトでも、

• 使用Board
• Framework
• Build Option
• ライブラリ依存関係
• Upload設定
• Debug設定

などを管理できます。

さらに複数のEnvironmentを定義すれば、同じソースコードを異なるBoardや設定でビルドするといった使い方もできます。

Gitでソースコードを管理する場合にも相性がよく、別のPCへ開発環境を移すときにも構成を再現しやすくなります。

PlatformIOにはESP32向けのデバッグやUnit Testingなどの仕組みも用意されています。

PlatformIOのデメリット

Arduino IDEと比較すると、最初に覚えることは増えます。

特に、

platformio.ini
Environment
Build Flags
Library Dependency

など、PlatformIO独自の仕組みを理解する必要があります。

Arduino IDEならメニューからBoardを選択して書き込むだけだったところを、設定ファイルで管理する場面も増えます。

また、PlatformIO自身とFrameworkのバージョン関係を意識する必要が出ることもあります。

そのため、

ESP32を初めて触る人が必ずPlatformIOから始める必要はない

と思います。

Arduino IDEでESP32の基本を理解した後、「プロジェクト管理をもっとしっかりしたい」と感じた時点でPlatformIOへ移るのも十分現実的です。

PlatformIOはArduino専用ではない

ここは意外と誤解されやすい部分です。

PlatformIOは、

ArduinoをVS Codeで使うためだけのツールではありません。

ESP32では、

framework = arduino

だけでなく、

framework = espidf

としてESP-IDFを使用することもできます。PlatformIO公式のEspressif 32 Platformでも両Frameworkがサポートされています。

つまり、

VS Code
   │
PlatformIO
   ├── Arduino Framework
   │
   └── ESP-IDF

という使い方ができます。

この点を理解すると、

Arduino IDE → PlatformIO → ESP-IDF

という一直線の「初心者→上級者」の関係ではないことが分かります。

PlatformIOを使いながらArduino Frameworkで開発することもできますし、ESP-IDFで開発することもできます。

開発環境とFrameworkを分けて考えることが重要です。

ESP-IDF + VS Code｜ESP32を本格的に扱う公式環境

ESP-IDFは、Espressifが提供するESP32シリーズの公式開発Frameworkです。

ESP32の機能をより直接的に扱うことができます。

以前は、

「ESP-IDFはコマンドライン操作が多くて難しい」

というイメージを持っていた人もいるかもしれません。

現在はEspressif公式のVS Code Extensionが用意されており、VS Code上からESP-IDFプロジェクトを扱えます。

Build、Flash、Monitorだけでなく、GDB/OpenOCDを利用したデバッグも公式Extensionから利用できます。

そのため、

ESP-IDF＝ターミナルだけで開発する環境

という理解は現在では正確ではありません。

もちろん内部ではCMakeやESP-IDFのBuild Systemが動いているため、それらの知識が必要になる場面はあります。

しかし普段のBuild・Flash・MonitorなどはVS Code上から操作できます。

ESP-IDFを使うメリット

ESP-IDFを選ぶ大きな理由は、ESP32が持っている機能を公式Frameworkから直接利用できることです。

Arduino FrameworkでもESP32の多くの機能を利用できますが、より細かな設定やESP32固有機能を扱うようになると、ESP-IDFの方が分かりやすい場合があります。

たとえば、

• FreeRTOS
• Wi-Fi / Bluetooth
• Partition Table
• NVS
• OTA
• Power Management
• Watchdog
• Heap管理
• Logging
• JTAG Debug
• Core Dump

などを本格的に扱う場合です。

ESP-IDFでは、これらが公式ドキュメントの中で体系的に整理されています。

特に製品開発では、「とりあえず動いた」だけでなく、

なぜ動いているのか
異常時に何が起きるのか
メモリをどれだけ使用しているのか
どのバージョンでビルドしたのか

といったところまで管理したくなります。

このような開発ではESP-IDFのメリットが大きくなります。

ESP-IDFのデメリット

一方、ESP-IDFはArduino IDEと比較すると学習する内容が多くなります。

たとえばESP-IDFのプロジェクトでは、

project
├── CMakeLists.txt
├── sdkconfig
└── main
    ├── CMakeLists.txt
    └── main.c

のような構成を目にします。

さらに、

• CMake
• Component
• menuconfig
• sdkconfig
• FreeRTOS
• Build System

など、ESP-IDF独自の仕組みを理解する必要があります。

最初は、

「LEDを点滅させたいだけなのに、覚えることが多い」

と感じるかもしれません。

これはESP-IDFが難しいというより、ESP32が持っている機能を細かく扱える分、開発者が理解する範囲も広くなると考えるとよいでしょう。

そのため、ESP32を初めて使う人が必ずESP-IDFから始める必要はありません。

まずArduino IDEでESP32そのものに慣れ、必要になった段階でESP-IDFへ進む方法もあります。

ArduinoとESP-IDFでコードは流用できる？

ここは開発環境を変更するときに気になるポイントです。

結論として、すべてのコードをそのまま移せるとは限りません。

たとえばArduinoでは、

digitalWrite(LED_PIN, HIGH);
delay(1000);
digitalWrite(LED_PIN, LOW);

のように記述できます。

一方、ESP-IDFではGPIO DriverやFreeRTOSのAPIなどを使用して実装できます。

つまり、実現している機能は同じでも、使用するAPIが異なる場合があります。

ただし、

• 自分で作成した計算処理
• 通信Protocolの処理
• データ変換
• 状態遷移
• デバイスに依存しないC/C++コード

などは、設計次第で流用しやすくできます。

これはESP32に限った話ではありません。

Firmwareを作るときに、Hardware依存部分とApplication部分を分離しておくと、FrameworkやMCUを変更するときの移植が楽になります。

ArduinoからESP-IDFへ途中で変更できる？

変更すること自体は可能です。

ただし、

ArduinoプロジェクトをESP-IDFプロジェクトへ変換するボタンを押せば終わり

というものではありません。

Arduino固有APIやArduino向けLibraryを大量に使用している場合は、それらをどう扱うか検討する必要があります。

小規模なプログラムならESP-IDFで書き直すこともできますが、ある程度開発が進んだプロジェクトでは移行工数が大きくなる可能性があります。

そのため、製品開発では開発初期に、

最終的にどこまでESP32の機能を使うのか

をある程度考えておくことをおすすめします。

たとえば、

「Wi-Fiでデータを送るだけ」

という製品と、

「Wi-FiとBLEを同時使用し、OTA、NVS、複数Task、Watchdog、低消費電力制御まで行う」

という製品では、必要になる開発環境も変わってきます。

ArduinoをESP-IDFの中で使う方法もある

ここまで読むと、

ArduinoかESP-IDFのどちらかを選ばなければならない

ように見えるかもしれません。

実際には、その中間的な方法もあります。

Arduino-ESP32は、ESP-IDFのComponentとして利用することができます。 EspressifのArduino-ESP32公式ドキュメントでも、この構成が案内されています。

イメージとしては、

ESP-IDF Project
│
├── ESP-IDF Component
├── 自作Component
│
└── Arduino Component
       └── Arduino API / Library

という構成です。

これによってESP-IDFをベースにしながら、必要な部分でArduinoのAPIやLibraryを利用できます。

ただし、当然ながら構成はArduino IDE単体より複雑になります。

また、ESP-IDFとArduino Coreには対応するバージョンの組み合わせがあるため、好きなバージョン同士を自由に組み合わせられるわけではありません。

単純なプロジェクトで無理に採用する必要はありませんが、

「ESP-IDFへ移行したいが、既存のArduino資産も利用したい」

という場合には選択肢になります。

PlatformIOとESP-IDF + VS Codeはどちらを選ぶ？

この2つも迷いやすいところです。

どちらもVS Codeを使えるため、画面だけを見ると似ています。

しかし、考え方には違いがあります。

PlatformIO + ESP-IDFでは、PlatformIOがプロジェクトやToolchainなどを管理し、そのFrameworkとしてESP-IDFを使用します。

一方、

ESP-IDF + 公式VS Code Extensionでは、Espressif公式のESP-IDF環境をVS Codeから操作します。

そのため、ESP-IDFそのものを深く扱いたいのであれば、私はESP-IDF + 公式VS Code Extensionを選択肢の中心に置くのが分かりやすいと思います。

Espressifの公式Extensionでは、Build・Flash・Monitorだけでなく、Debug、Core Dump、Heap TraceなどESP-IDF向けの機能も提供されています。

一方で、

ArduinoとESP-IDFをプロジェクトごとに使い分けたい
複数のMCU Platformを同じ開発環境で管理したい

という場合にはPlatformIOのメリットがあります。

どちらが優れているというより、何を中心に管理したいかの違いです。

結局どのESP32開発環境を選べばいい？

ここまでの内容を用途別に整理します。

ただし、この表は絶対的なものではありません。

製品開発でもArduino Frameworkを採用することはできますし、個人の電子工作でESP-IDFを使っても問題ありません。

重要なのは、

開発者のレベルではなく、プロジェクトに必要な機能と管理方法で選ぶ

ことです。

「製品開発ならESP-IDF」は本当？

ESP32について調べていると、

「趣味ならArduino、仕事ならESP-IDF」

という説明を見かけることがあります。

これは少し単純化しすぎています。

製品Firmwareで重要なのは、Frameworkの名前そのものではなく、

• 使用バージョンを管理できる
• Build環境を再現できる
• Source Codeを管理できる
• エラー処理が設計されている
• Watchdogなど異常時の動作を考慮している
• Update方法を管理できる
• 長期間保守できる

といった点です。

Arduino Frameworkを使っていても、これらを適切に管理できていれば製品開発は可能です。

逆にESP-IDFを使っただけで、Firmwareの品質が自動的に上がるわけではありません。

ただし、ESP32の機能を深く利用する製品では、ESP-IDFの公式APIやDebug機能、設定機能などが大きなメリットになります。

そのため、要求仕様が複雑になるほどESP-IDFを選ぶ理由が増えていく、と考えるのがよいでしょう。

迷ったらこの順番でもよい

ESP32を初めて使う場合、最初から将来のすべてを予測する必要はありません。

一つの考え方として、

まずESP32を動かしたい
        ↓
    Arduino IDE
        ↓
プロジェクト管理が必要
        ↓
 PlatformIO + Arduino
        ↓
ESP32固有機能を深く扱いたい
        ↓
 ESP-IDF + VS Code

という進み方もできます。

ただし、これは「レベルアップの順番」という意味ではありません。

Arduino IDEで十分なら、そのまま使い続けても問題ありません。

PlatformIOが自分の開発方法に合っていれば、ESP-IDFへ移行する必要もありません。

必要になったときに環境を変える。

これくらいの考え方でよいと思います。

まとめ｜ESP32の開発環境は用途で選ぶ

ESP32では、Arduino IDE、PlatformIO、ESP-IDFなど複数の方法でFirmwareを開発できます。

それぞれに特徴があります。

Arduino IDE
手軽に始められ、Arduinoの豊富なLibraryやサンプルを利用しやすい。

PlatformIO + VS Code
プロジェクトや依存関係、複数のBuild環境を管理しやすく、ArduinoとESP-IDFの両方を扱える。

ESP-IDF + VS Code
Espressif公式Frameworkを使用し、ESP32固有機能やDebug機能を本格的に扱える。

重要なのは、

「どれが一番高機能か」ではなく、「自分の開発に何が必要か」で選ぶこと

です。

ESP32を初めて触るならArduino IDEから始めてもよいでしょう。

Arduinoを使いながら開発環境を整理したくなったらPlatformIO、ESP32の機能をより深く扱いたくなったらESP-IDFという選択肢があります。

そして製品開発では、開発環境の名前以上に、バージョン管理・再現性・デバッグ・保守まで含めて開発環境を選定することが重要です。

ESP32シリーズそのものをまだ決めていない場合は、既存記事の**「ESP32シリーズの選び方」**へつなぎましょう。

また、ESP-IDFをこれから使う読者には、既存の**「ESP-IDF初心者がつまずく5つのポイント」**への内部リンクが非常に自然です。

今回の記事を間に置くことで、

ESP32シリーズを選ぶ → 開発環境を選ぶ → ESP-IDFを実際に使う

という流れができます。

関連記事

ESP32シリーズの選び方

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

一方、ESP32を日本国内で使用するときに気になるのが「技適」です。

「ESP32には技適が付いているから大丈夫」
「技適済みのWROOMモジュールを使えば、自作基板でも問題ない？」
「海外から購入したESP32開発ボードは日本で使える？」
「外付けアンテナへ変更しても技適はそのまま使える？」

ESP32を使っていると、このような疑問が出てきます。

結論から言うと、「ESP32だから技適OK」と一括りに判断することはできません。

確認する必要があるのはESP32というシリーズ名だけではなく、実際に使用する無線モジュールの型番、日本向け認証の有無、使用する周波数帯、アンテナなどの条件です。

この記事では、ESP32を自作基板へ組み込む場合や製品へ採用する場合を想定して、技適を確認するときの基本的な考え方を解説します。

※本記事は回路・基板設計を行う際の確認ポイントを整理したもので、個別製品について法令適合を保証するものではありません。製品化する場合は、使用するモジュールの最新認証資料や関係法令を確認してください。

そもそも「技適」とは？

一般に「技適」と呼ばれているものには、電波法に基づく技術基準適合証明や工事設計認証などがあります。

Wi-FiやBluetoothのように電波を送信する機器は、日本国内で使用するための技術基準を満たしている必要があります。

その適合性を確認する仕組みの一つが技適です。

ESP32の場合、Wi-FiやBluetoothを搭載した無線モジュールが多いため、日本国内で無線機能を使用するのであれば技適について確認する必要があります。

ここで注意したいのが、

ESP32というCPUそのものに一律で「技適あり」「技適なし」が決まっているわけではない

という点です。

実際に確認するのは、採用する無線モジュールや製品です。

「ESP32なら技適取得済み」と考えない

ESP32には非常に多くの製品があります。
ESP32シリーズごとの機能や用途の違いについては、「ESP32シリーズの選び方」で詳しく解説しています。

たとえば、

• ESP32-WROOMシリーズ
• ESP32-S3-WROOMシリーズ
• ESP32-C3-WROOMシリーズ
• ESP32-C5-WROOMシリーズ
• アンテナ内蔵型
• 外部アンテナ接続型

などがあります。

さらに、それらを搭載した各メーカーの開発ボードも存在します。

そのため、

「ESP32-C5は技適を取得している」

という確認だけでは不十分です。

確認するときは、

実際に採用する完全なモジュール型番

まで特定します。

Espressifは各製品について国・地域ごとの認証資料を公開しています。たとえばESP32-C5-WROOM-1についても、日本向けMIC認証として2.4GHz帯、2484MHz、5GHz帯の認証資料が公開されています。

Espressif 認証・コンプライアンス一覧

設計時には、

ESP32だから大丈夫
↓
採用するモジュール型番について、日本向けの認証内容を確認する

という考え方にしておくと安全です。

SoC単体と無線モジュールを区別する

ESP32を使った基板を設計するとき、もう一つ区別しておきたいのがSoC単体と無線モジュールです。

ESP32シリーズのSoCを単体で購入して、自分でRF回路、アンテナ、発振回路などを設計する方法があります。

一方、ESP32-WROOMなどのモジュールには、ESP32 SoCだけでなく、

• Flash
• 水晶発振器
• RF回路
• アンテナまたはアンテナコネクタ
• シールド

などが一体化されています。

そして、モジュール製品について日本向けの認証が取得されているものがあります。

この違いは製品開発では非常に重要です。

認証済みモジュールを採用する方法と、ESP32 SoCからRF回路まで自社設計する方法では、無線部分の設計・評価・認証に対する考え方が大きく変わります。

そのため、少量生産や初めて無線機能を搭載する製品では、認証状況を確認できるモジュールを採用することが現実的な選択肢になります。

技適済みESP32モジュールを自作基板へ載せてもよい？

ここはESP32で自作基板を作るときに、特に気になる部分だと思います。

たとえば、

自作基板
   │
   ├─ 電源回路
   ├─ センサー
   ├─ UART / SPI / I²C
   ├─ その他周辺回路
   │
   └─ ESP32-WROOM
        └─ 認証済み無線モジュール

という構成です。

認証済みモジュールを自作基板へ実装することと、ESP32 SoCからRF回路を自分で設計することは同じではありません。

ただし、

「認証済みモジュールを使ったので、その後は何を変更しても技適上問題ない」

と考えるのも危険です。

認証されている無線設備には、認証を受けた工事設計があります。

したがって、自作基板へ組み込む場合でも、認証されたモジュールをどのような条件で使用するのかを確認する必要があります。

特にRF部分そのものを改造したり、メーカーが想定していないアンテナ構成へ変更したりする場合は注意が必要です。

実際の設計では、

モジュールを改造しない
メーカーのHardware Design Guidelinesを確認する
アンテナ周辺の実装条件を守る
使用するアンテナ条件を確認する
採用型番の認証資料を確認する

といった確認を行います。

基板アンテナ型でもレイアウトは重要

ESP32-WROOMには、モジュール上にPCBアンテナを搭載した製品があります。

このタイプはアンテナまでモジュール内に含まれているため、自作基板では比較的扱いやすい構成です。

しかし、アンテナ内蔵だから基板上のどこへ配置してもよいわけではありません。

EspressifのHardware Design Guidelinesや各モジュールのデータシートには、アンテナ周辺の配置について推奨条件があります。

たとえばアンテナ付近に、

• GND Plane
• 信号配線
• 電源配線
• 金属部品
• コネクタ
• 筐体の金属

などが存在すると、アンテナ性能へ影響する可能性があります。

そのため、基板設計ではモジュールを基板端へ配置したり、指定されたアンテナKeepoutを確保したりします。

これは技適だけの問題ではなく、実際の通信距離や安定性にも直接関係する設計条件です。

認証済みモジュールを採用したとしても、メーカーの推奨レイアウトを無視してよいわけではありません。

海外から購入したESP32開発ボードはどう考える？

ESP32の開発ボードは国内だけでなく、海外通販サイトからも簡単に購入できます。

ここでも、

「ESP32が載っているから技適あり」

とは判断しない方がよいでしょう。

確認したいのは、実際に搭載されているモジュールと、その日本向け認証です。

同じような外観の開発ボードでも、

• 搭載モジュールが異なる
• モジュールのメーカーが異なる
• アンテナ仕様が異なる
• 日本向け認証を確認できない

といった可能性があります。

特にESP32互換ボードやノーブランド品では、写真だけを見て判断するのではなく、実際に搭載されているモジュール型番を確認することが重要です。

「ESP32搭載」という商品説明だけでは、日本国内で無線を使用するときの判断材料として十分ではありません。

外付けアンテナ型ESP32は特に注意する

ESP32-WROOMシリーズには、モジュール上にPCBアンテナを搭載したタイプだけでなく、外部アンテナを接続するタイプがあります。

たとえばESP32-C5では、

ESP32-C5-WROOM-1：PCBアンテナ型
ESP32-C5-WROOM-1U：外部アンテナコネクタ型

という違いがあります。

外部アンテナ型には、

• 筐体外へアンテナを配置できる
• 金属筐体でもアンテナ位置を調整しやすい
• 装置に合わせてアンテナ配置を最適化できる

といったメリットがあります。

一方で、技適を考えるうえでは使用するアンテナについても確認が必要です。

「モジュールが技適取得済みだから、好きなアンテナを接続してよい」と単純に考えることはできません。

アンテナの種類・利得・周波数帯を確認する

外付けアンテナを使用するときは、少なくとも、

• アンテナの種類
• 対応周波数
• アンテナ利得
• インピーダンス
• コネクタ
• ケーブルを含めた接続方法

を確認します。

たとえばESP32-C5-WROOM-1Uのデータシートには、認証試験で使用された外部アンテナや、推奨する外部アンテナの仕様が記載されています。

つまり、

コネクタへ物理的に接続できるアンテナ＝そのまま使用条件を満たすアンテナ

とは限りません。

特に高利得アンテナへ変更すると、無線設備全体としての条件が変わる可能性があります。

外部アンテナ型を製品へ採用するときは、モジュールの認証資料だけでなく、使用予定のアンテナがメーカーの示す条件と整合しているかまで確認することが重要です。

異なるアンテナを使用する場合には、追加評価や認証上の確認が必要になる可能性もあるため、メーカーや認証機関への確認を含めて判断します。

ESP32-C5の5GHz Wi-Fiでは何を確認する？

ESP32-C5の大きな特徴の一つが、2.4GHz帯だけでなく5GHz帯のWi-Fi 6に対応していることです。

従来のESP32で2.4GHz Wi-Fiだけを使っていた場合、

「C5なら5GHzも使える」

という点は魅力的です。

しかし、日本国内で使用する場合は、単にSoCが5GHz対応だから使用できると判断するのではなく、採用するモジュールについて日本向けの認証内容を確認する必要があります。

EspressifはESP32-C5-WROOM-1について、日本向けMIC認証資料を公開しており、5GHz帯についても認証資料を確認できます。

ここでも重要なのは、

ESP32-C5が5GHz対応していることと、採用する製品を日本国内でどの条件でも5GHz運用できることは同じではない

という点です。

5GHz帯には、使用する周波数によって屋内・屋外利用などに条件があります。

そのため製品設計では、

どの周波数帯を使用するのか
日本向け認証がどうなっているのか
製品をどの環境で使用するのか

まで確認しておく必要があります。

特に海外向けと日本向けで共通のFirmwareを使用する製品では、国・地域に応じた無線設定についても確認しておいた方がよいでしょう。

技適済みモジュールなら製品として販売できる？

ここも混同しやすいポイントです。

技適と、完成製品として必要になる法令・安全要求は別に考える必要があります。

技適済み無線モジュールを適切な条件で組み込んでいたとしても、それだけで完成製品に関係するすべての法令への適合が完了するわけではありません。

製品によっては、

• 電気用品安全法
• EMC関連要求
• 使用するACアダプタや電源
• 表示
• 製品安全

など、別の確認が必要になる場合があります。

したがって、

「技適済みESP32を使ったから、この製品はそのまま販売できる」

とは判断しません。

技適は、製品開発で確認する項目の一つとして扱います。

何が必要になるかは製品構成や用途によって異なるため、量産・販売する場合には完成品として適用される法令や規格を別途確認します。

技適マーク・認証番号はどこで確認する？

ESP32モジュールを選定するときは、販売ページだけで判断せず、メーカーの公式資料を確認することをおすすめします。

Espressifでは、各ESP32製品について国・地域別の認証資料を公開しています。

Espressif Certifications & Compliance

ここで、

1. 採用予定の完全なモジュール型番を確認する
2. Japan / MICの認証資料を探す
3. 使用する無線機能・周波数帯を確認する
4. 外付けアンテナ型ならアンテナ条件も確認する

という順番で調べると分かりやすいでしょう。

また、認証状況は新製品の追加などによって変わる可能性があります。

ブログなどに書かれている古い認証番号だけを頼りにするのではなく、実際に設計・購入する時点の公式資料を確認することが重要です。

ESP32自作基板の技適チェックリスト

最後に、ESP32を使った自作基板を設計するときの確認項目をまとめます。

特に、

モジュール型番
日本向け認証
アンテナ

の3項目は、最初の部品選定段階で確認しておくことをおすすめします。

基板設計が終わってから使用予定のアンテナが認証条件と合わないことが分かると、アンテナや筐体まで変更することになりかねません。

ESP32を選定するときは認証も仕様の一部として考える

ESP32を選ぶときは、

• CPU性能
• GPIO数
• Wi-Fi
• Bluetooth
• Flash
• PSRAM
• USB

などの機能を比較することが多いと思います。

しかし、実際の製品開発では認証状況もデバイス仕様の一部として考えた方がよいでしょう。

特に新しいESP32シリーズを採用するときは、

「性能が良いから採用する」

だけでなく、

使用予定の国・地域で必要な認証を確認できるか

まで部品選定時に確認しておくと、後工程での手戻りを減らせます。

これはESP32に限らず、Wi-Fi、Bluetooth、LTEなどの無線モジュールを採用するときにも共通する考え方です。

まとめ｜「ESP32だから技適OK」ではなく型番と使用条件を確認する

ESP32を日本国内で使用するときは、単に「ESP32には技適がある」と判断するのではなく、実際に採用するモジュールについて確認することが重要です。

確認の基本は、

完全なモジュール型番を確認する
↓
日本向け認証を確認する
↓
使用する周波数帯を確認する
↓
アンテナ条件を確認する
↓
実際の基板・製品への組み込み条件を確認する

という流れです。

特に外付けアンテナ型では、モジュールの認証だけを見て終わらず、使用するアンテナの仕様まで確認します。

また、技適済みモジュールを採用することと、完成製品として必要なすべての法令・規格へ適合することは別です。

ESP32を製品へ採用する場合には、**無線認証も回路や部品と同じ「設計条件の一つ」**として扱うことが大切です。

認証や法令は更新される可能性があるため、最終的な製品設計ではメーカーの最新認証資料や公的情報を確認してください。

関連記事

ESP32シリーズの選び方｜用途別におすすめのESP32を解説

ESP32シリーズにピン互換性はある？ESP32・S3・C3・C5の置き換えを徹底解説

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

新しいESP32が登場すると、

「今使っているESP32から載せ替えられないか？」
「同じWROOMシリーズならピン互換なのでは？」
「ESP32-C3からESP32-C5へ変更するだけなら、基板はそのまま使える？」

と考えることもあると思います。

しかし、同じESP32シリーズだからといって、ピン互換があるとは限りません。

外形が似ていても端子配置が異なることがあります。また、同じGPIO番号でも機能や起動時の状態が異なる場合があります。

特に基板設計では、単純に「3.3VとGNDの位置が合っている」「必要なGPIOがある」という確認だけでは不十分です。

モジュールのLand Pattern、電源、EN、Strapping Pin、UARTやSPIなどの周辺機能、Flash・PSRAM構成、アンテナ領域なども確認する必要があります。

この記事では、ESP32・ESP32-S3・ESP32-C3・ESP32-C5を例に、ESP32シリーズを別のデバイスへ置き換えるとき、何を確認すればよいのかを基板設計の視点から解説します。

ESP32シリーズは基本的にピン互換ではない

最初に結論を書くと、ESP32、ESP32-S3、ESP32-C3、ESP32-C5は、基本的にそのまま載せ替えられるピン互換デバイスではありません。

「ESP32」という共通した名前が付いていますが、それぞれCPUアーキテクチャや搭載されている周辺機能、GPIO構成などが異なります。

モジュールについても同様です。

たとえば「WROOM」という名称が付いているからといって、同じLand Patternや端子配列を持っているわけではありません。

そのため、

ESP32-WROOMを使っている基板だから、別のESP32-WROOMへそのまま交換できる

とは考えない方が安全です。

ESP32シリーズを置き換える場合、少なくとも次の3つの互換性を分けて確認する必要があります。

さらに、ハードウェアだけでなくFirmware側の対応確認も必要です。

つまり、

「基板に物理的に載る」＝「ピン互換」ではありません。

ここを最初に理解しておくと、ESP32シリーズを変更するときの設計ミスを減らせます。

ピン互換性で確認するべき5つのポイント

では、ESP32シリーズを変更するとき、具体的に何を確認すればよいのでしょうか。

ここでは特に重要なポイントを5つに分けて説明します。

1．モジュールの外形とLand Pattern

最初に確認するのは、モジュールそのものの物理形状です。

同じESP32シリーズやWROOMという名称であっても、

• モジュールの縦横寸法
• 端子数
• 端子位置
• 端子ピッチ
• GNDパッド
• Land Pattern

などが同じとは限りません。

そのため、データシートの外形寸法だけを比較するのではなく、推奨Land Patternまで確認することが重要です。

基板上に実装できなければ、その時点で単純な載せ替えはできません。

また、モジュールのアンテナ位置にも注意が必要です。

アンテナ部分の下や周辺には、銅箔、配線、部品などを配置しないKeepout Areaが指定されています。

モジュール変更によってアンテナ位置が変われば、基板外形や部品配置まで見直す必要が出てくることがあります。

2．電源・EN・GNDの配置

次に確認するのが電源関係です。

ESP32シリーズの多くは3.3V系で動作しますが、

「どれも3.3Vだから交換できる」

というわけではありません。

3.3V、GND、ENなどの端子位置が違えば、当然そのまま載せ替えることはできません。

また、必要な電源容量についても確認が必要です。

Wi-FiやBluetoothなどの無線通信を行うESP32では、通信時に消費電流が大きく変動します。

既存基板の3.3V電源回路をそのまま流用する場合でも、変更後のESP32に対して十分な電流を供給できるか確認しておく必要があります。

単純なピン配置だけでなく、電源回路そのものが流用できるかまで含めて判断します。

3．GPIO番号だけで判断しない

ESP32はGPIO Matrixによって、多くの周辺機能を比較的自由にGPIOへ割り当てられることが特徴です。

そのため、

「UARTは別のGPIOへ移せばいい」
「SPIも空いているGPIOへ割り当てればいい」

と考えやすいのですが、すべてのGPIOを自由に使えるわけではありません。

シリーズによって、

• 入力専用端子
• 起動時に使用される端子
• FlashやPSRAMで使用される端子
• USBで使用される端子
• 使用を避けた方がよい端子

などが異なります。

特に注意したいのが、FlashやPSRAMを内蔵・搭載するモジュールです。

同じESP32シリーズでも、FlashやPSRAMの構成によって一部GPIOをユーザーが自由に使用できない場合があります。

つまり、

GPIO番号が存在することと、そのGPIOを基板で自由に使えることは別

と考える必要があります。

4．Strapping Pinを必ず確認する

ESP32シリーズを使った基板設計で特に注意したいのが、Strapping Pinです。

Strapping Pinとは、電源投入時やリセット時のGPIO状態によって、ESP32の起動設定などを決定する端子です。

通常動作が始まった後はGPIOとして使用できる場合でも、起動時には特別な役割を持っています。

そのため、外部回路によってStrapping Pinが意図しないHighまたはLowへ固定されると、

• 正常に起動しない
• Download Modeへ入ってしまう
• 書き込みができない
• 起動設定が変わる

といった問題につながる可能性があります。

そして重要なのは、Strapping Pinの割り当てがESP32シリーズごとに異なることです。

既存ESP32で問題なく使えていたGPIOだからといって、別シリーズでも同じように使えるとは限りません。

シリーズ変更時には、データシートのStrapping Pinの項目を必ず確認します。

5．UART・SPI・USBなどの周辺機能を確認する

最後に、実際に基板で使用している周辺機能を確認します。

代表的なものとして、

• UART
• SPI
• I²C
• ADC
• PWM
• USB
• JTAG

などがあります。

ESP32シリーズによって搭載されている周辺機能やチャンネル数、使用可能なGPIOは異なります。

特にUSBはシリーズによる違いが大きい部分です。

従来のESP32と、USB機能を持つESP32-S3やESP32-C3などでは、USBを利用した書き込みやデバッグ方法まで変わる可能性があります。

既存基板でUART、SPI、I²Cなどを複数使用している場合は、使用中の機能を一つずつ新しいESP32へ割り当て直せるか確認するのが確実です。

ESP32・S3・C3・C5は何が違う？

ここまでを見ると、ESP32シリーズの変更では単純なピン番号比較だけでは不十分であることが分かります。

では、ESP32、ESP32-S3、ESP32-C3、ESP32-C5にはどのような違いがあるのでしょうか。

大まかな特徴を比較すると次のようになります。

※従来ESP32自体にESP32-S3のようなネイティブUSB OTG機能があるという意味ではありません。

ここで重要なのは、性能の優劣ではありません。

たとえばESP32-C5は2.4GHz/5GHz Wi-Fi 6に対応するなど、従来シリーズから無線機能が大きく強化されています。

一方で、

「C5の方が新しくて高機能だから、C3をC5へ交換すればよい」

とはなりません。

CPUアーキテクチャが同じRISC-Vであっても、GPIO、周辺機能、Strapping Pin、モジュール端子配置などは別に確認する必要があります。

ESP32からESP32-S3へ置き換えできる？

ESP32-S3は、従来のESP32と同じXtensa系CPUを採用しています。

そのため、一見すると比較的移行しやすそうに見えます。

しかし、ESP32からESP32-S3への変更を単純な載せ替えとして考えることはできません。

ESP32-S3ではCPUコアがXtensa LX7へ変更されているほか、GPIO構成や周辺機能も異なります。

特に大きな違いの一つがUSBです。

ESP32-S3にはUSB OTGやUSB Serial/JTAGが搭載されているため、従来ESP32ではUSB-UART変換ICを使用していた構成でも、S3ではUSBを直接利用する設計が可能です。

これは機能面ではメリットですが、既存基板から変更する場合には、

• USB端子を使用するか
• USB-UART変換ICを残すか
• 書き込み方法をどうするか
• JTAGをどう利用するか

といった基板全体の構成を改めて検討する必要があります。

また、Strapping PinやGPIOの用途も同じではありません。

したがって、

ESP32-S3への変更は「ESP32を高性能版へ交換する」のではなく、新しいMCUを使って基板を再設計する

と考えた方が安全です。

ESP32からESP32-C3へ置き換えできる？

ESP32-C3では、CPUアーキテクチャそのものが変わります。

従来ESP32がXtensa LX6を採用しているのに対して、ESP32-C3はRISC-Vベースです。

さらにCPU構成、GPIO、周辺機能、Bluetooth機能などにも違いがあります。

そのため、ESP32からESP32-C3へ変更する場合も、単純な載せ替えは基本的にできません。

ただし、ESP-IDFやArduinoなどの開発環境では複数のESP32シリーズがサポートされているため、アプリケーションコードの一部を流用できる場合はあります。

ここで注意したいのが、

「ソースコードが流用できる」ことと「基板が流用できる」ことは別

という点です。

たとえばUART通信を行うプログラムそのものは移植できても、実際にUARTへ使用するGPIOが変われば基板配線は変更しなければなりません。

また、特定のESP32向けライブラリや、CPU固有機能へ直接アクセスしているプログラムでは、Firmware側にも修正が必要になる可能性があります。

ESP32-C3への変更では、ハードウェアとFirmwareを別々に確認する必要があります。

ESP32-C3からESP32-C5へ置き換えできる？

ESP32-C3とESP32-C5は、どちらもRISC-VベースのESP32です。

そのため、

「C3からC5なら比較的簡単に変更できるのでは？」

と思うかもしれません。

しかし、C3とC5もピン互換デバイスとして考えるべきではありません。

ESP32-C5では2.4GHzだけでなく5GHz帯にも対応したWi-Fi 6を利用でき、IEEE 802.15.4にも対応するなど、無線機能が大きく拡張されています。

一方で、GPIO構成やStrapping PinなどはC3と同じではありません。

たとえばESP32-C5では、Boot Modeに関係するGPIOやUSB Serial/JTAGで使用されるGPIOなどを確認したうえで回路を設計する必要があります。

さらに、モジュールのメモリ構成にも注意が必要です。

ESP32-C5-WROOM-1では、PSRAM搭載品を選択すると、一部端子がPSRAMとの接続に使用されます。

つまり、

同じESP32-C5-WROOM-1でも、選択するメモリ構成によって自由に使用できるGPIOが変わる場合がある

ということです。

これはシリーズ変更だけでなく、同一シリーズ内でモジュール型番を変更するときにもデータシートを確認する必要があることを意味します。

CPUアーキテクチャが同じだからといって、基板まで互換になるわけではありません。

「同じWROOMなら互換」は間違い

ESP32を選定していると、

• ESP32-WROOM
• ESP32-S3-WROOM
• ESP32-C5-WROOM

のように「WROOM」という名称を目にします。

ここで注意したいのが、

WROOMという名称＝共通のピン配置

ではないことです。

WROOMは、ESP32シリーズのモジュール製品で使用されている名称ですが、シリーズをまたいで共通のLand Patternを保証するものではありません。

そのため、部品表に「ESP32-WROOM」とだけ記載して互換品を選定するような運用は避けた方が安全です。

基板設計では必ず、

完全なモジュール型番 → データシート → 推奨Land Pattern → Pin Definitions

まで確認します。

特に量産製品では、部品供給の都合から別のESP32へ変更したくなる場合があります。

その場合も「同じWROOMだから代替品」と判断するのではなく、設計変更として扱うことをおすすめします。

ESP32を別シリーズへ変更するときの確認手順

では、実際に既存基板のESP32を変更するとき、どのような順番で確認すればよいのでしょうか。

私は次の順番で確認することをおすすめします。

1．モジュール型番を確定する

最初に変更先の完全な型番を決めます。

「ESP32-C5」だけでは不十分です。

Flash容量、PSRAMの有無、アンテナ仕様などによってモジュール型番や使用条件が変わるためです。

2．Land Patternを比較する

既存モジュールと変更先モジュールの推奨Land Patternを比較します。

端子数や端子位置が違えば、基本的に基板変更が必要です。

3．電源仕様を確認する

動作電圧だけでなく、必要な電流や電源投入条件なども確認します。

既存の3.3V電源を流用できるかも、この段階で確認します。

4．使用しているGPIOを一覧化する

既存基板で使用しているGPIOと用途を一覧にします。

たとえば、

のように整理します。

この表を変更先ESP32のGPIOへ一つずつ割り当て直します。

5．Strapping Pinを確認する

割り当てたGPIOがStrapping Pinと衝突していないか確認します。

通常動作だけでなく、電源投入時・リセット時に外部回路がどのような状態になるかまで確認します。

6．Flash・PSRAM関連端子を確認する

モジュール構成によって内部FlashやPSRAMで使用される端子がないか確認します。

データシート上にGPIO番号が存在していても、採用するモジュールでは使用できない場合があります。

7．USB・UART・JTAGを確認する

書き込みやデバッグ方法も確認します。

ESP32シリーズによってUSB Serial/JTAGなどの利用可否が異なるため、MCU変更を機会に書き込み回路を簡略化できる場合もあります。

8．アンテナ領域を確認する

モジュールのアンテナ位置とKeepout Areaを確認します。

ここを見落とすと、基板上には実装できても無線性能へ影響する可能性があります。

9．Firmwareを確認する

最後にFirmware側を確認します。

使用しているESP-IDFやArduino Coreなどが変更先デバイスに対応しているか、使用中のライブラリにデバイス依存部分がないか確認します。

ピン互換にこだわらず基板を再設計した方がよい場合

既存基板をできるだけ変更したくない場合、変換基板やGPIOの割り当て変更によって対応したくなることがあります。

試作や評価用途であれば、それも一つの方法です。

しかし量産基板の場合は、無理に互換性を持たせることで、

• 配線が複雑になる
• 不要な0Ω抵抗やジャンパが増える
• Strapping Pinの制約を受ける
• 本来使いやすいGPIOを使えない
• 新しいESP32の機能を活かせない

といった問題が発生することがあります。

特にESP32からESP32-C5のように世代や機能が大きく異なる場合は、既存回路への適合を優先するよりも、新しいデバイスに合わせて基板を再設計した方が結果的にシンプルになることがあります。

基板変更には工数が必要ですが、製品を長期間使用するのであれば、無理な互換設計を残すより保守もしやすくなります。

ESP32モジュールを変更する場合は、ピン配置や機能だけでなく、日本国内で使用するための認証状況も確認しておきましょう。ESP32の技適については「ESP32に技適は必要？自作基板・製品化で知っておきたい電波法を解説」で詳しく解説しています。

まとめ｜ESP32の型番変更は「載せ替え」ではなく再設計として考える

ESP32、ESP32-S3、ESP32-C3、ESP32-C5は同じESP32ファミリですが、基本的に単純なピン互換デバイスではありません。

ESP32シリーズを変更するときは、

機械的互換性
電気的互換性
機能的互換性

の3つを確認する必要があります。

さらに、実際の製品ではFirmware、Flash・PSRAM構成、アンテナ領域、書き込み・デバッグ方法まで確認します。

特に覚えておきたいのは、

「同じESP32」「同じRISC-V」「同じWROOM」だから互換とは限らない

という点です。

ESP32シリーズを変更するときは、単なる部品置換ではなく、別のMCUへ変更するつもりでデータシートを確認するのが安全です。

その結果、基板変更が必要になったとしても、新しいESP32に合わせて回路を最適化した方がシンプルで扱いやすい設計になることがあります。

ESP32シリーズそのものの選び方で迷っている場合は、既存の**「ESP32シリーズの選び方｜用途別におすすめのESP32を現役エンジニアが解説」**も関連記事としてつなげましょう。逆側の記事から今回の記事への内部リンクも追加すると、かなり相性のよい2記事になります。

技術は、経験から価値になる。

DLROW Design | 現場エンジニア

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

「電源を入れた瞬間だけリレーがONする」

「ResetするとLEDが一瞬光る」

「プログラムではLOWにしているのに、起動時だけ負荷が動く」

といった現象が発生することがあります。

プログラムを見ると、最初にGPIOをLOWへ設定している。

それなのに、なぜ負荷が動くのでしょうか。

原因を調べるときに重要なのが、

ESP32は電源投入直後から自分のプログラムを実行しているわけではない

という点です。

今回はESP32-C5とESP-IDFを例に、起動時のGPIO状態と、外部回路で誤動作を防ぐ考え方を整理します。

app_main()より前にも時間がある

ESP-IDFでプログラムを作成すると、アプリケーションではapp_main()から処理を書き始めます。

そのため、

「app_main()の最初でGPIOをLOWにすれば、起動時からLOWになる」

と思いたくなります。

しかし実際には、

電源投入
↓
Reset
↓
ROM Boot処理
↓
Bootloader
↓
Application起動
↓
app_main()

という流れがあります。

つまり、

電源投入からapp_main()がGPIOを初期化するまでには時間があります。

その期間のGPIO状態を考えずに外部回路を設計すると、起動時だけ負荷が意図しない状態になる可能性があります。

GPIOを設定するまでは出力とは限らない

アプリケーションでGPIOをOutputに設定するまでは、

「必ずLOW」

「必ずHIGH」

とは限りません。

Pinによっては内部Pull-up/Pull-down、Boot時の機能、Strapping用途なども関係します。

そのため、

起動直後の状態をアプリケーションだけで保証しようとしない

ことが重要です。

特に、

• MOSFET Gate
• Transistor Base
• Relay Driver
• Motor Driver Enable
• Heater Enable
• その他、起動時にONしてほしくない信号

では外部回路側でもDefault状態を決めておく方が安全です。

MOSFET Gateが浮くとどうなる？

例えばN-channel MOSFETをLow Side Switchとして使用するとします。

ESP32 GPIO
↓
Gate抵抗
↓
MOSFET Gate

という接続だけにした場合、ESP32がまだGPIOを制御していない期間にGate電圧が不定になる可能性があります。

MOSFETのGateは容量性の入力なので、周囲のノイズや残留電荷などによって電位が決まってしまうことがあります。

その結果、

電源投入時にMOSFETが一瞬ONする

可能性があります。

Pull-down抵抗でOFF状態を作る

N-channel MOSFETを、

GPIO HIGH → ON

として使用するなら、GateとGNDの間にPull-down抵抗を入れる方法があります。

ESP32がまだGPIOを制御していなくても、

Gate
↓
Pull-down抵抗
↓
GND

によってGateをLOW側へ保持できます。

重要なのは、

Softwareが動く前からHardwareで安全状態を作る

という考え方です。

サンプルコード

今回はGPIO10を出力として使用し、起動直後にLOWへ設定したあと、1秒周期でHIGH/LOWを切り替えるサンプルを使用します。

ここで重要なのは、

このコードだけでは電源投入直後からGPIO10がLOWであることを保証できない

という点です。

以下が今回使用するサンプルコード全文です。

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

#include "driver/gpio.h"
#include "esp_log.h"

#define OUTPUT_GPIO GPIO_NUM_10

static const char *TAG = "BOOT_GPIO";

void app_main(void)
{
    gpio_config_t io_conf = {
        .pin_bit_mask = (1ULL << OUTPUT_GPIO),
        .mode = GPIO_MODE_OUTPUT,
        .pull_up_en = GPIO_PULLUP_DISABLE,
        .pull_down_en = GPIO_PULLDOWN_DISABLE,
        .intr_type = GPIO_INTR_DISABLE
    };

    ESP_ERROR_CHECK(gpio_config(&io_conf));

    ESP_ERROR_CHECK(
        gpio_set_level(OUTPUT_GPIO, 0));

    ESP_LOGI(
        TAG,
        "GPIO initialized LOW");

    while (1)
    {
        ESP_ERROR_CHECK(
            gpio_set_level(OUTPUT_GPIO, 1));

        ESP_LOGI(
            TAG,
            "GPIO HIGH");

        vTaskDelay(
            pdMS_TO_TICKS(1000));

        ESP_ERROR_CHECK(
            gpio_set_level(OUTPUT_GPIO, 0));

        ESP_LOGI(
            TAG,
            "GPIO LOW");

        vTaskDelay(
            pdMS_TO_TICKS(1000));
    }
}

このサンプルでは、GPIO10をOutputへ設定した直後にLOWを出力しています。

しかし、ここで確認したいのは、

LOWへ設定したタイミング

です。

LOWにしているのはapp_main()実行後

サンプルコードでは次の部分でGPIOを初期化しています。

gpio_config_t io_conf = {
    .pin_bit_mask = (1ULL << OUTPUT_GPIO),
    .mode = GPIO_MODE_OUTPUT,
    .pull_up_en = GPIO_PULLUP_DISABLE,
    .pull_down_en = GPIO_PULLDOWN_DISABLE,
    .intr_type = GPIO_INTR_DISABLE
};

ESP_ERROR_CHECK(gpio_config(&io_conf));

ESP_ERROR_CHECK(
    gpio_set_level(OUTPUT_GPIO, 0));

確かに、この処理が実行されたあとはGPIO10をLOWへ制御できます。

しかし、

電源投入
↓
ESP32起動処理
↓
このコードを実行

という順番です。

つまり、このコードが実行されるより前の状態については、このgpio_set_level()では制御できません。

ここが起動時誤動作を考えるうえで重要なポイントです。

内部Pull-downを使えば解決する？

ESP32にはGPIOの内部Pull-up/Pull-down機能があります。

例えば今回の設定を、

GPIO_PULLDOWN_ENABLE

へ変更すればよいのではないか、と考えることもできます。

ただし、それだけに依存するのは避けたい場合があります。

内部Pull-up/Pull-downもESP32内部の機能です。

製品として、

Reset中や起動途中を含めて確実に負荷をOFFへしたい

のであれば、外部抵抗でDefault状態を決める方が回路として分かりやすくなります。

特にリレー、モーター、ヒーターなど、安全性や機械動作に関係する出力では重要です。

Softwareより先にHardwareで状態を決める

例えばMOSFET Gateなら、

ESP32 GPIO
↓
Gate抵抗
↓
MOSFET Gate
↓
10kΩ～100kΩ程度
↓
GND

という構成を検討できます。

このPull-down抵抗があれば、ESP32 GPIOがHi-ZでもGateをLOW側へ保持できます。

そしてESP32が起動してGPIOをHIGHにすれば、Pull-down抵抗に逆らってGate電圧が上がり、MOSFETをONできます。

つまり、

HardwareでDefault OFF

Softwareで必要なときだけON

という役割分担です。

Pull-down抵抗は何Ωにする？

よく使用される値としては、10kΩ～100kΩ程度があります。

ただし、

「MOSFET Gateには必ず10kΩ」

という決まりではありません。

抵抗値を小さくするとGateをより強くLOWへ保持できますが、GPIOがHIGHの間はPull-down抵抗へ電流が流れ続けます。

逆に抵抗値を大きくすると消費電流は減りますが、外来ノイズなどに対する保持は弱くなります。

回路条件に合わせて決めます。

Active Lowなら考え方が逆になる

すべての回路が、

HIGH → ON

とは限りません。

例えば、

LOW → Enable

となる外部ICもあります。

この場合、起動時にOFFへしたければ、Pull-downではなくPull-upが必要になる可能性があります。

つまり重要なのは、

Pull-upかPull-downかを先に決めることではありません。

まず、

負荷を安全な状態にする論理レベルはHIGHなのかLOWなのか

を決めます。

その後、その状態へ保持する抵抗を選びます。

Strapping Pinにも注意する

ESP32シリーズには、起動時に特定の状態を参照してBoot動作などを決めるPinがあります。

こうしたPinへ外部Pull-up/Pull-downや負荷を接続すると、意図しないBoot Modeになる可能性があります。

そのためGPIOを割り当てるときは、

「空いているGPIOだから使う」

だけで決めず、そのPinが起動時にどのような役割を持つか確認します。

特に自作基板では、この確認を回路設計段階で行うことが重要です。

起動時だけでなくReset時も考える

もう一つ忘れやすいのがResetです。

製品は電源投入時だけResetするとは限りません。

例えば、

• Watchdog Reset
• Software Reset
• Brownout
• ENによるReset
• Firmware Update後のReset

などがあります。

Resetが発生すれば、再びApplicationがGPIOを初期化するまでの期間が生まれます。

したがって、

「電源投入時に一瞬だけだから問題ない」

ではなく、

運転中にResetしても外部回路が安全状態を維持できるか

まで確認します。

Strapping Pinは回路設計の最初に確認する

ESP32シリーズでは、起動時に特定のGPIO状態を参照してBoot Modeなどを決めるPinがあります。

こうしたPinへ外部回路を接続する場合、

• 強いPull-up
• 強いPull-down
• 外部ICの出力
• MOSFET Gate回路
• LED
• Driver Enable

などが起動条件へ影響する可能性があります。

そのため、

空いているGPIOを見つけてから用途を割り当てる

のではなく、

そのGPIOが起動時に何をするPinなのかを確認してから割り当てる

方が安全です。

特に製品基板では、Boot Modeに関係するPinへ不用意に外部回路を接続すると、

「通常は動くのに、特定条件だけ起動しない」

という分かりにくいトラブルにつながります。

起動時の波形はオシロスコープで確認する

起動時だけ一瞬負荷が動く場合は、GPIO波形を実際に測定すると状況が分かりやすくなります。

確認したいのは、

電源投入直後からApplicationがGPIOを初期化するまで

です。

例えばGPIOをLowにしたい場合でも、波形が、

電源ON
  ↓
Hi-Z
  ↓
一瞬HIGH
  ↓
LOW

のようになっているかもしれません。

目視では分からない短いパルスでも、MOSFETやDriver Enableには十分な場合があります。

そのため、起動時誤動作が疑われる場合は、

• GPIO
• Enable信号
• MOSFET Gate
• 負荷側電圧

をオシロスコープで確認します。

MOSFET GateはHardwareでOFFを作る

N-channel MOSFETをLow Side Switchとして使用し、

HIGHでON

とする場合は、GateへPull-down抵抗を入れるのが基本的な考え方です。

ESP32 GPIO
    │
  Gate抵抗
    │
    ├──── MOSFET Gate
    │
 Pull-down
    │
   GND

ESP32がまだGPIOを出力していない状態でも、GateはGND側へ引かれます。

これにより、

Default OFF

をHardware側で作れます。

一方で、Pull-down抵抗値を小さくしすぎるとGPIO HIGH時に無駄な電流が増えます。

逆に大きすぎるとノイズに弱くなる可能性があります。

そのため回路条件に合わせて選びます。

Relay Driverでも同じ考え方

リレーをトランジスタやMOSFETで駆動する場合も、起動時にDriverが勝手にONしない状態を作る必要があります。

例えばNPNトランジスタを使う場合、

Baseが浮かないようにする

ことが重要です。

MOSFETならGate Pull-down。

NPNならBase-Emitter間の抵抗。

このように、CPUが動いていなくてもDriverがOFFになるようにします。

特にリレーは一瞬ONするだけでも、

• 接点が切り替わる
• 機械が動く
• 電源が投入される

可能性があります。

そのためLEDよりも起動時状態の重要度は高くなります。

Enable信号は安全側へ倒す

Motor Driver、Power IC、外部ModuleなどにはEnable端子があることがあります。

このEnable信号は、

CPU Reset中にどちらの論理へ倒すべきか

を先に決めます。

例えば、

HIGH = Enable

ならPull-down。

LOW = Enable

ならPull-up。

というように、

安全状態をHardwareで固定

します。

ここで重要なのは、

「CPUが起動したら正しく制御できる」

ではなく、

CPUが起動していないときでも安全である

ことです。

Software初期化もできるだけ早く行う

Hardware側でDefault状態を決めたうえで、Software側でもApplication開始後にできるだけ早くGPIOを初期化します。

サンプルコードでは、app_main()の最初でGPIO設定を行っています。

gpio_config_t io_conf = {
    .pin_bit_mask = (1ULL << OUTPUT_GPIO),
    .mode = GPIO_MODE_OUTPUT,
    .pull_up_en = GPIO_PULLUP_DISABLE,
    .pull_down_en = GPIO_PULLDOWN_DISABLE,
    .intr_type = GPIO_INTR_DISABLE
};

ESP_ERROR_CHECK(gpio_config(&io_conf));

ESP_ERROR_CHECK(
    gpio_set_level(OUTPUT_GPIO, 0));

この順番なら、Applicationが開始したあと早い段階でGPIOをLOWへ確定できます。

ただし、繰り返しになりますが、

このコードが動く前の状態はHardware側で担保する

という役割分担が重要です。

GPIO初期値と出力切替順序にも注意する

回路によっては、GPIOをOutputに切り替えた瞬間の状態も気になる場合があります。

例えば、

1. GPIOをOutputへ設定
2. その後LOWへ設定

という順序で、ごく短時間だけ意図しない状態になる可能性がないか確認します。

必要に応じて、使用するESP-IDF APIやGPIOの初期値設定方法を確認し、

Outputとして有効になる瞬間から安全な論理になるようにする

ことも重要です。

特に高速なDriver EnableやPower Controlでは、この短い時間も無視できない場合があります。

Reset中にも同じことが起きる

起動時対策は、電源投入時だけの話ではありません。

ESP32がResetすると、再びApplicationがGPIOを制御するまでの期間が発生します。

例えば、

• Watchdog Reset
• Software Reset
• Brownout
• EN Reset
• Firmware更新後のReset

です。

そのため、

Reset = GPIO制御が一時的に解除される可能性がある

と考えます。

製品が運転中にResetしても、外部回路が勝手にONしないようにしておく必要があります。

Brownout時も安全状態を維持する

Brownoutも注意したいケースです。

電源電圧が低下すると、ESP32が正常に制御できなくなる前後で外部回路の状態が変化する可能性があります。

そのため重要なEnable信号では、

電源が不安定になっても外部回路が安全側へ倒れる

ようにします。

ここでもPull-up/Pull-downやDriver回路のDefault状態が効いてきます。

外部ICの内部Pull-up/Pull-downも確認する

ESP32側だけを見ていると見落としやすいのが、接続先ICの内部抵抗です。

例えばDriver ICのEnable端子に、

内部Pull-up

が入っている場合があります。

ESP32側で何も接続しなければ、自動的にEnableになる可能性があります。

逆に内部Pull-downがある場合もあります。

そのため外部ICのデータシートで、

• Internal Pull-up
• Internal Pull-down
• Input Leakage
• Default State

を確認します。

外付け抵抗と内部抵抗が並列になることも考慮します。

Active High / Active Lowを回路図で明確にする

製品設計では、信号名にもDefault状態を反映すると分かりやすくなります。

例えば、

MOTOR_EN

だけではなく、

MOTOR_EN

がHIGH Activeなのか、

/MOTOR_EN

のようなLOW Activeなのかを明確にします。

回路図上でActive Levelが分かると、

「起動時にPull-upなのかPull-downなのか」

も判断しやすくなります。

安全が必要な負荷はSoftwareだけに任せない

特に、

• ヒーター
• モーター
• ソレノイド
• 電磁弁
• リレー
• 高出力LED
• 電源制御

のような負荷では、

Applicationが正常に起動してからOFFにする

という設計だけでは不十分な場合があります。

Hardware側でDefault OFFを作り、

Softwareはその状態を必要なときだけ変更する。

この構成なら、

CPUがResetしても、

Firmwareが起動しなくても、

Debug中でも、

Default状態を維持しやすくなります。

起動時誤動作の切り分け方法

起動時だけ負荷が動く場合は、次の順序で確認すると整理しやすくなります。

1. GPIOの起動時波形を見る

電源投入からApplication起動までを確認します。

2. 外部回路のDefault状態を見る

Pull-up/Pull-downがあるか確認します。

3. Strapping Pinか確認する

Boot動作に関係するGPIOではないか確認します。

4. 外部ICの内部Pullを確認する

DriverやEnable端子側の仕様を確認します。

5. Reset時にも同じ現象が起きるか確認する

電源投入だけでなくSoftware Resetなどでも確認します。

6. Hardwareで安全状態を作る

必要に応じて外付けPull-up/Pull-downを追加します。

SoftwareとHardwareの役割を分ける

起動時GPIO対策では、SoftwareとHardwareのどちらか一方だけで解決しようとしない方が分かりやすくなります。

Hardware：

CPUが制御していない状態でも安全なDefaultを作る

Software：

起動後に必要な状態へ正しく制御する

という役割分担です。

例えばMotor Enableなら、

電源投入
↓
Hardware Pull-down
↓
Motor OFF
↓
ESP32起動
↓
GPIO初期化
↓
必要な条件が成立
↓
SoftwareでMotor ON

という流れにできます。

これなら起動時にMotorが勝手に回る可能性を減らせます。

設計時チェックリスト

ESP32のGPIOで外部回路を制御するときは、次の項目を確認しておくと安心です。

• そのGPIOはStrapping Pinではないか
• Reset中の状態はどうなるか
• Application起動前の状態を考えたか
• 外部回路の安全状態はHIGHかLOWか
• 外付けPull-up/Pull-downは必要か
• 外部ICに内部Pullがないか
• Reset時にも負荷が安全か
• Brownout時にも安全か
• GPIO波形を実測したか
• Software初期化をできるだけ早く行っているか
• 安全に関係する負荷をSoftwareだけに依存していないか

まとめ

ESP32で、

「起動時だけGPIOが勝手に動く」

ように見える現象は、Applicationだけを見ていると分かりにくいことがあります。

重要なのは、

ESP32がGPIOを制御できない時間も存在する

ということです。

電源投入直後。

Reset中。

Boot処理中。

Application初期化前。

こうした期間でも外部回路を安全な状態へ保つには、Hardware側のDefault設計が重要になります。

MOSFET GateならPull-down。

Active Low EnableならPull-up。

Driver回路ならDefault OFF。

そしてApplicationが起動したあと、Softwareで必要な状態へ切り替えます。

Hardwareで安全状態を作り、Softwareで制御する。

この役割分担を決めておけば、起動時やReset時の意図しない動作を防ぎやすくなります。

技術は、経験から価値になる。

DLROW Design | 現場エンジニア

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

「GPIOから何mAまで流していいのか？」

と迷うことがあります。

例えばLEDなら、GPIOへ抵抗を接続して直接点灯させる回路をよく見かけます。

では、

10mAなら大丈夫なのか。

20mAならどうなのか。

40mAまで流せるのか。

そしてリレーやモーターもGPIOから直接動かしてよいのか。

今回はESP32-C5を例に、GPIOの出力電流と、実際の回路設計でどう考えるべきかを整理します。

「最大何mA？」だけで考えない

ESP32-C5-WROOM-1のデータシートには、GPIO出力について電流と出力電圧の関係が記載されています。

最も強いDrive設定では、High側について、

40mAをSourceした条件で、VOHが2.64V以上

という特性が示されています。

Low側では、

28mAをSinkした条件で、VOLが0.495V

という特性があります。

ここで注意したいのが、

40mAという数字だけを取り出さないこと

です。

GPIOは理想的な3.3V電源ではありません。

流す電流が大きくなれば、High出力の電圧は低下します。

同じようにLow側へ大きな電流を流せば、出力電圧は0Vから上昇します。

つまり、

「GPIOから何mA取り出せるか」と「回路として何mA流す設計にするか」は別の話

です。

Drive Strengthも設定できる

ESP32-C5のGPIOにはDrive Capabilityの設定があります。

ESP-IDFでは、

gpio_set_drive_capability()

を使ってGPIO PadのDrive Capabilityを変更できます。

ただし、Drive Strengthを強く設定したからといって、

外部負荷へ大電流を供給するための電源出力になるわけではありません。

Drive Strengthはデジタル信号を駆動する能力の設定です。

LEDをより明るくするために最大設定へする、リレーを動かすために最大設定へする、といった使い方を基本に考えるものではありません。

LEDなら直接駆動できる場合がある

LED程度の小さな負荷なら、GPIOから直接駆動できる場合があります。

例えば、

3.3V GPIO
↓
電流制限抵抗
↓
LED
↓
GND

という構成です。

重要なのは、必ず電流制限抵抗を入れることです。

LEDの順方向電圧を2.0V、GPIO出力を3.3V、抵抗を330Ωと仮定すると、

(3.3V – 2.0V) / 330Ω

なので、理想的には約4mAです。

実際にはGPIOの出力特性やLEDのVfによって変わりますが、この程度ならインジケータLEDとして十分な場合も多いでしょう。

「GPIOから20mA取れるから20mA流す」

ではなく、

必要な明るさを得られる範囲で電流を小さくする

方が扱いやすい設計です。

サンプルコード

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

#include "driver/gpio.h"
#include "esp_log.h"

#define LED_GPIO GPIO_NUM_10

static const char *TAG = "GPIO_CURRENT";

void app_main(void)
{
    gpio_config_t io_conf = {
        .pin_bit_mask = (1ULL << LED_GPIO),
        .mode = GPIO_MODE_OUTPUT,
        .pull_up_en = GPIO_PULLUP_DISABLE,
        .pull_down_en = GPIO_PULLDOWN_DISABLE,
        .intr_type = GPIO_INTR_DISABLE
    };

    ESP_ERROR_CHECK(gpio_config(&io_conf));

    ESP_LOGI(TAG, "GPIO LED test start");

    while (1)
    {
        gpio_set_level(LED_GPIO, 1);
        ESP_LOGI(TAG, "LED ON");

        vTaskDelay(pdMS_TO_TICKS(500));

        gpio_set_level(LED_GPIO, 0);
        ESP_LOGI(TAG, "LED OFF");

        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

今回はGPIOを出力に設定し、LEDを500ms周期でON/OFFする簡単なコードを使用します。

このコード自体が電流を制限するわけではありません。

LED電流は外付け抵抗で制限します。

例えばGPIO10にLEDと電流制限抵抗を接続した場合を想定します。

以下が今回使用するサンプルコード全文です。

のサンプルではGPIO10をOutputとして使用しています。

ここで、

gpio_set_level()で1を出したから3.3V・何mAという電源が保証される、

という考え方はしません。

接続する負荷によってGPIOの電圧・電流条件は変化します。

GPIOをOutputに設定する

サンプルコードでは、次の部分でGPIO10を出力として設定しています。

gpio_config_t io_conf = {
    .pin_bit_mask = (1ULL << LED_GPIO),
    .mode = GPIO_MODE_OUTPUT,
    .pull_up_en = GPIO_PULLUP_DISABLE,
    .pull_down_en = GPIO_PULLDOWN_DISABLE,
    .intr_type = GPIO_INTR_DISABLE
};

ESP_ERROR_CHECK(gpio_config(&io_conf));

ここではGPIOをOutputとして設定しているだけです。

接続する負荷の電流までESP-IDFが管理してくれるわけではありません。

例えばGPIOに低い抵抗値を接続すれば、GPIOはその負荷を駆動しようとします。

そのため回路側で、

• 負荷に必要な電流
• GPIOの出力特性
• 電流制限抵抗
• 外部ドライバが必要か

を判断します。

GPIOのON/OFFは信号として考える

LEDのON/OFFは次の部分で行っています。

gpio_set_level(LED_GPIO, 1);
ESP_LOGI(TAG, "LED ON");

vTaskDelay(pdMS_TO_TICKS(500));

gpio_set_level(LED_GPIO, 0);
ESP_LOGI(TAG, "LED OFF");

ここで考えておきたいのが、

GPIOは基本的に「電力を供給する端子」ではなく「信号を出力する端子」として扱う

という考え方です。

LEDのように数mA程度で目的を達成できる負荷なら直接駆動できることがあります。

しかし負荷電流が大きくなってくると、

GPIO
↓
トランジスタ / MOSFET
↓
負荷

という構成にします。

GPIOはトランジスタやMOSFETへON/OFFの指示を出し、実際の負荷電流は外部電源から供給します。

リレーをGPIOから直接駆動しない

例えばコイル電流が50mA必要なリレーがあったとします。

「GPIOは40mA程度まで出せるらしいから、少しだけ足りない」

という問題ではありません。

そもそもGPIOへリレーコイルを直接接続する設計を避けます。

一般的には、

ESP32 GPIO
↓
抵抗
↓
トランジスタ / MOSFET
↓
リレーコイル
↓
電源

とします。

さらにリレーコイルのような誘導性負荷では、OFF時に発生する逆起電力への対策も必要です。

GPIOの電流能力だけを見て、

「数字上流せそうだから接続する」

という判断をしないことが重要です。

モーターも直接駆動しない

DCモーターなどはさらに明確です。

起動時には定常運転時より大きな電流が流れることがあります。

またモーターは誘導性負荷であり、ノイズ源にもなります。

そのためESP32のGPIOから直接駆動するのではなく、

• MOSFET
• Motor Driver IC
• H-Bridge

などを使用します。

ESP32の役割は、

モーターへ電力を供給することではなく、Driverへ制御信号を送ること

です。

MOSFETなら何でもよいわけではない

GPIOからMOSFETを駆動する場合も注意が必要です。

ESP32-C5のGPIOは3.3V系です。

そのためMOSFETを選定するときは、

VGS = 3.3V付近で十分にONできるか

を確認します。

MOSFETのデータシートに記載されたThreshold Voltageだけを見て、

「VGS(th)が2Vだから3.3Vで使える」

と判断するのは危険です。

VGS(th)は、一般にMOSFETが大電流を十分低いON抵抗で流せることを保証する値ではありません。

実際に使用するGate VoltageでのRDS(on)などを確認します。

複数GPIOならさらに注意する

もう一つ忘れやすいのが、

GPIOを1本だけ使用する場合と、多数を同時使用する場合は同じではない

ということです。

例えば、

「1pinである程度流せる」

という情報だけを見て、

多数のGPIOすべてへ同じ電流を流してよいとは限りません。

実際の設計ではGPIO単体だけでなく、デバイス全体の電源条件、同時駆動するI/O数、発熱、電圧降下なども考える必要があります。

そのため、

1pinの最大値 × GPIO本数

という計算だけで設計するのは避けます。

SourceとSinkの違い

GPIOから電流を扱うときは、SourceとSinkを分けて考えます。

SourceはGPIOから外部へ電流を流す状態です。

例えば、

ESP32 GPIO → 抵抗 → LED → GND

という回路でGPIOをHIGHにすると、GPIOからLEDへ電流が流れます。

一方、Sinkは外部からGPIOへ電流を流し込む状態です。

例えば、

3.3V → 抵抗 → LED → ESP32 GPIO

としてGPIOをLOWにすると、GPIO側へ電流が流れます。

同じLEDを点灯させる場合でも、GPIOが担う役割は異なります。

SourceとSinkで特性は同じではない

ESP32-C5のデータシートでは、High出力側とLow出力側で別々にDC特性が示されています。

そのため、

「GPIOは何mAまで流せるか」

を一つの数字だけで表現するのは適切ではありません。

High出力時にはVOHがどこまで維持されるか。

Low出力時にはVOLがどこまで上昇するか。

このように、出力電圧と電流の関係で考えます。

回路側が3.3V近いHighを必要としているのに、大きな電流をSourceした結果としてGPIO電圧が大きく低下すれば、論理信号としても問題になる可能性があります。

Drive Capabilityとは？

ESP32-C5ではGPIOのDrive Capabilityを設定できます。

ESP-IDFではgpio_set_drive_capability()を使用します。

Drive Capabilityは、GPIO出力の駆動能力を変更するための設定です。

ただし、

Drive Capabilityを最大にすれば、大電流負荷を直接駆動できる

という意味ではありません。

Drive Strengthを強くすると、配線容量などに対して信号をより強く駆動できます。

一方で、立ち上がり・立ち下がりが速くなることで、基板条件によってはリンギングやEMIなどの影響も考慮する必要があります。

つまり、

必要以上に強く設定することが常に正解ではありません。

LEDを複数同時に点灯する場合

1個のLEDを数mAで点灯する回路なら問題がなくても、LEDを多数同時にGPIOから駆動する場合は話が変わります。

例えば10個のLEDへそれぞれ5mA流すと、

合計では50mAです。

ここで、

「1GPIOあたり5mAだから問題ない」

だけで判断してはいけません。

確認したいのは、

• 同時にONするGPIO数
• デバイス全体の電源条件
• GPIOのSource/Sink状態
• 3.3V電源への負荷
• 発熱
• GPIO電圧の変化

などです。

多数のLEDを点灯する場合は、LED Driver ICやトランジスタアレイを使った方が合理的なこともあります。

GPIOの最大値を合計しない

特に避けたいのが、

1pinの数字 × GPIO本数

という考え方です。

例えば、

40mA × 10pin = 400mA

だからESP32から400mA取り出せる、

という計算にはなりません。

GPIO単体の出力特性と、デバイス全体の電源・内部回路の制約は別に考える必要があります。

多数のGPIOから比較的大きな電流を同時に取る設計は避け、外部ドライバを使う方が安全です。

MOSFETを使う判断

負荷電流がGPIO直接駆動には大きい場合、MOSFETを使う方法があります。

基本構成は、

ESP32 GPIO
↓
Gate抵抗
↓
MOSFET Gate

そして負荷側は、

電源
↓
負荷
↓
MOSFET
↓
GND

です。

この場合、GPIOはMOSFETのGateを制御するだけなので、負荷電流そのものはGPIOへ流れません。

例えば、

• リレー
• ソレノイド
• 小型DCモーター
• LED Strip
• ヒーター制御信号

などでは、このような構成が有効です。

Logic Level MOSFETを選ぶ

ESP32-C5は3.3V GPIOです。

そのためMOSFETを選定するときは、

VGS = 2.5Vや3.3V付近でRDS(on)が規定されているもの

を選ぶと判断しやすくなります。

注意したいのがVGS(th)です。

VGS(th)はMOSFETが十分低いON抵抗になるGate電圧ではありません。

一般に、非常に小さなDrain電流が流れ始める条件として規定されています。

したがって、

VGS(th) = 1.5V

だから、

3.3V GPIOなら完全にONできる、

とは判断しません。

実際に使用するGate電圧でのRDS(on)を確認します。

Gate抵抗は何のため？

MOSFET GateはDC的にはほとんど電流を消費しません。

ただしGateには容量があります。

ON/OFF時にはこの容量を充放電するため、一時的にGPIOから電流が流れます。

そこでGPIOとMOSFET Gateの間に、数十Ω〜数百Ω程度の抵抗を入れることがあります。

目的は、

• Gate充放電電流のピークを抑える
• リンギングを抑える
• GPIOへの負担を軽減する
• スイッチング速度を調整する

などです。

最適値はMOSFET、周波数、負荷条件によって変わります。

Gate Pull-downも検討する

MOSFETをLow Side Switchとして使用する場合、

ESP32がReset中、

起動途中、

GPIOがHi-Zの期間、

などにGateが浮く可能性があります。

そこで、

Gate → GND

へPull-down抵抗を設け、ESP32が制御していない状態ではMOSFETをOFFへ保つ設計がよく使われます。

例えば10kΩ〜100kΩ程度を検討します。

重要なのは抵抗値そのものより、

起動時に負荷が勝手にONしない構成にすること

です。

リレーやモーターでは逆起電力対策も必要

リレーコイルやDCモーターのような誘導性負荷では、電流を急に遮断すると大きな電圧が発生します。

そのため、

• Flyback Diode
• TVS
• Snubber

などを負荷条件に応じて検討します。

MOSFETを使えばGPIOから大電流を切り離せますが、

MOSFETを追加しただけで回路が完成するわけではありません。

負荷の性質も考える必要があります。

トランジスタを使う場合

小型リレーなどでは、NPNトランジスタを使うこともできます。

ESP32 GPIO
↓
Base抵抗
↓
NPN transistor
↓
Relay

という構成です。

この場合はMOSFETとは異なり、Base電流を流す必要があります。

そのため、

• 必要なCollector電流
• トランジスタの増幅率
• Base電流
• GPIOから流す電流
• Base抵抗

を設計します。

負荷電流が大きくなるほど、MOSFETの方が扱いやすい場合も多いです。

「直接駆動するか」の判断基準

実際の設計では、私は次のように考えると整理しやすいと思います。

数mA程度の表示LED

→ GPIO直接駆動を検討できる

外部ICのDigital Input

→ 基本的にGPIOから直接接続できる
ただし電圧レベルや入力条件を確認

トランジスタ/MOSFET Gate

→ GPIOで制御可能
Gate条件・抵抗・起動時状態を確認

数十mA以上必要な負荷

→ 外部Driverを検討

誘導性負荷

→ Driver＋逆起電力対策

モーターや大電力負荷

→ 専用DriverやMOSFET回路を使用

このように、GPIOの限界値から逆算するより、

負荷の種類から駆動方法を決める

方が設計しやすくなります。

GPIOが壊れる前に起こること

GPIOに過大な負荷を接続した場合、

いきなり完全故障するとは限りません。

その前に、

• High電圧が下がる
• Low電圧が上がる
• 通信が不安定になる
• GPIO出力が期待通りにならない
• ESP32全体の電源が不安定になる
• Resetが発生する

といった症状として現れる可能性があります。

つまり、

動いているから安全とは限りません。

長時間運転や温度条件、複数GPIO同時動作なども含めて確認します。

GPIOトラブルの切り分け

GPIOに接続した負荷が正常に動かない場合は、次の順番で確認すると整理しやすくなります。

1. GPIO単体の電圧を確認する

負荷を外した状態でHIGH/LOWが正常か確認します。

2. 負荷接続後の電圧を見る

負荷を接続した瞬間にHigh電圧が大きく下がっていないか確認します。

3. 負荷電流を確認する

必要な電流が想定通りか確認します。

4. 外部Driverを入れて確認する

Driver経由で正常になるなら、GPIO直接駆動が原因候補になります。

5. 電源全体を見る

負荷切替によって3.3V自体が低下していないか確認します。

GPIOを使うときの設計チェック

最後に、実際の回路設計で確認したいポイントをまとめます。

• GPIOは信号出力として使う
• データシートの電流値だけを見ない
• Source/Sinkを区別する
• VOH/VOL条件を見る
• LEDは必要最小限の電流で使う
• 数十mA級の負荷は直接駆動しない
• モーターやリレーは外部Driverを使用する
• MOSFETは3.3VでのRDS(on)を確認する
• 誘導性負荷には逆起電力対策を入れる
• 多数GPIOの同時駆動にも注意する
• 起動時のGPIO状態も確認する

まとめ

ESP32-C5のGPIOには数十mAクラスの出力特性が記載されています。

しかし、それは、

「その電流を積極的に取り出して負荷を駆動するための電源端子」

という意味ではありません。

GPIOは基本的に、

外部回路へHIGH/LOWを伝える信号端子

として考えます。

小電流のLEDなどは直接駆動できる場合がありますが、

• リレー
• モーター
• ソレノイド
• 大電流LED

などはMOSFETやトランジスタ、専用Driverを使用します。

そして重要なのは、

最大何mA流せるかではなく、必要な機能をどれだけ余裕を持って実現できるか

です。

データシートの最大付近を目標にするのではなく、GPIOに必要以上の負担をかけない回路を作る。

その方が、長時間安定して動作する製品へつながります。

技術は、経験から価値になる。

DLROW Design | 現場エンジニア

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

「しばらく動かしていると突然再起動する」

「Wi-Fi通信を始めた瞬間にリセットする」

「処理を追加したら、ときどき最初から起動し直すようになった」

といった現象に遭遇することがあります。

突然再起動すると、つい直前に追加したプログラムを疑いたくなります。

しかしESP32が再起動する原因は、プログラムだけとは限りません。

例えば、

• 電源電圧の低下
• Watchdog
• CPU例外
• Stack関連の異常
• Heap破損
• ソフトウェアからの再起動

などでも再起動します。

そこで重要なのが、

「なぜ再起動したのか」を最初に確認すること

です。

今回はESP32-C5とESP-IDFを例に、リセット理由を取得しながら原因を切り分ける方法を紹介します。

最初にリセット理由を確認する

ESP-IDFには、直前のリセット理由を取得するための

esp_reset_reason()

が用意されています。

突然再起動する現象が発生したら、まずこの情報を確認します。

例えば、

ESP_RST_BROWNOUT

なら電源側を疑う。

ESP_RST_TASK_WDT

ならTask Watchdogを疑う。

ESP_RST_PANIC

なら例外やPanic発生時のログを確認する。

このように、リセット理由が分かるだけでも調査範囲をかなり狭められます。

サンプルコード

今回は起動時に直前のリセット理由を取得し、ログへ表示するサンプルを使用します。

さらに現在のFree Heapと、起動後に記録されたMinimum Free Heapも定期的に表示します。

以下が今回使用するサンプルコード全文です。

#include <stdio.h>

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

#include "esp_system.h"
#include "esp_log.h"

static const char *TAG = "RESET_CHECK";

static const char *reset_reason_to_string(
    esp_reset_reason_t reason)
{
    switch (reason)
    {
        case ESP_RST_POWERON:
            return "POWERON";

        case ESP_RST_SW:
            return "SOFTWARE";

        case ESP_RST_PANIC:
            return "PANIC";

        case ESP_RST_INT_WDT:
            return "INTERRUPT_WDT";

        case ESP_RST_TASK_WDT:
            return "TASK_WDT";

        case ESP_RST_WDT:
            return "OTHER_WDT";

        case ESP_RST_DEEPSLEEP:
            return "DEEPSLEEP";

        case ESP_RST_BROWNOUT:
            return "BROWNOUT";

        case ESP_RST_USB:
            return "USB";

        case ESP_RST_JTAG:
            return "JTAG";

        case ESP_RST_EFUSE:
            return "EFUSE_ERROR";

        case ESP_RST_PWR_GLITCH:
            return "POWER_GLITCH";

        case ESP_RST_CPU_LOCKUP:
            return "CPU_LOCKUP";

        case ESP_RST_UNKNOWN:
        default:
            return "UNKNOWN";
    }
}

static void print_reset_reason(void)
{
    esp_reset_reason_t reason;

    reason = esp_reset_reason();

    ESP_LOGI(
        TAG,
        "Reset reason: %s (%d)",
        reset_reason_to_string(reason),
        (int)reason);
}

static void print_memory_status(void)
{
    ESP_LOGI(
        TAG,
        "Free heap: %lu bytes",
        (unsigned long)esp_get_free_heap_size());

    ESP_LOGI(
        TAG,
        "Minimum free heap: %lu bytes",
        (unsigned long)esp_get_minimum_free_heap_size());
}

void app_main(void)
{
    ESP_LOGI(
        TAG,
        "ESP32 reset check start");

    print_reset_reason();

    while (1)
    {
        print_memory_status();

        vTaskDelay(pdMS_TO_TICKS(5000));
    }
}

このサンプルを実行すると、起動時に直前のリセット理由を表示します。

その後は5秒ごとにHeapの状態を表示します。

esp_reset_reason()で原因候補を絞る

先ほどのサンプルコードでは、print_reset_reason()内でリセット理由を取得しています。

static void print_reset_reason(void)
{
    esp_reset_reason_t reason;

    reason = esp_reset_reason();

    ESP_LOGI(
        TAG,
        "Reset reason: %s (%d)",
        reset_reason_to_string(reason),
        (int)reason);
}

esp_reset_reason()の戻り値はesp_reset_reason_tです。

代表的なリセット理由には、

• ESP_RST_POWERON
• ESP_RST_SW
• ESP_RST_PANIC
• ESP_RST_INT_WDT
• ESP_RST_TASK_WDT
• ESP_RST_WDT
• ESP_RST_BROWNOUT
• ESP_RST_PWR_GLITCH
• ESP_RST_CPU_LOCKUP

などがあります。

ここで大切なのは、

リセット理由そのものが原因箇所を完全に教えてくれるわけではない

という点です。

例えばESP_RST_TASK_WDTなら「Task Watchdogによってリセットされた」ことは分かります。

しかし、どの処理がCPUを長時間占有したのかまでは、別途ログやTaskの処理内容を調べる必要があります。

リセット理由は原因を特定する答えというより、

次にどこを調べるべきかを決める情報

として使います。

Brownoutなら、まず電源を疑う

リセット理由がESP_RST_BROWNOUTだった場合は、プログラムを変更する前に電源を確認します。

ESP32-C5にはBrownout Detectorがあり、電源電圧が安全なレベルを下回るとリセットする仕組みがあります。

例えば、

• Wi-Fi送信開始時
• BLE動作開始時
• 外部回路をONした瞬間
• LEDやリレーなどの負荷を切り替えた瞬間

だけ再起動するのであれば、電源電圧の瞬間的な低下も疑います。

ここで、

「Wi-Fi処理を追加したら再起動した」

という理由だけで、

Wi-Fiプログラムにバグがある

と判断してはいけません。

Wi-Fiを動かした結果、消費電流が変化し、電源側の問題が表面化した可能性もあります。

Brownout発生時は電源波形を見る

Brownoutが疑われる場合は、3.3V電源をテスターだけで確認して終わらせない方がよい場合があります。

テスターで3.30Vと表示されていても、非常に短い時間だけ電圧が低下している可能性があります。

このような瞬間的な電圧変動は、テスターでは確認できない場合があります。

そのためBrownoutが発生しているなら、

オシロスコープでESP32直近の3.3V電源を確認する

のが有効です。

確認したいポイントは、

• 電源ICの供給能力
• 3.3Vラインの電圧低下
• デカップリングコンデンサ
• 電源配線
• GND
• 負荷切替時の電圧変動

などです。

Watchdogによるリセット

リセット理由がESP_RST_TASK_WDTやESP_RST_INT_WDTの場合はWatchdogを疑います。

Watchdogは、プログラムが正常に処理を続けられなくなったときに、システムが永久に停止してしまうことを防ぐための仕組みです。

例えばTask内で長時間処理を続け、他のTaskへ実行権を渡せない状態になると、Task Watchdogが発生する可能性があります。

while(1)そのものが悪いわけではない

ESP32のプログラムではwhile (1)という構造をよく使用します。

重要なのはwhile (1)があることではなく、

ループ内部でどのような処理をしているか

です。

今回のサンプルコードでは次のようになっています。

while (1)
{
    print_memory_status();

    vTaskDelay(pdMS_TO_TICKS(5000));
}

vTaskDelay()によってTaskをBlock状態へ移しているため、CPUを永久に占有するループにはなっていません。

一方、長時間CPUを占有し続ける処理では、Task構成やWatchdog設定によって問題になる可能性があります。

したがってWatchdogが発生した場合は、

「どのTaskが、どれくらい長く処理を続けているのか」

を確認します。

Panicの場合は再起動前のログを見る

リセット理由がESP_RST_PANICだった場合は、再起動後の理由だけを見るのではなく、

再起動する直前に出力されたログ

が非常に重要です。

ESP-IDFではCPU例外などが発生すると、Guru Meditation Errorとともに原因やBacktraceなどが出力される場合があります。

例えば、

• Illegal Instruction
• Load/Store Prohibited
• Load/Store Alignment Error
• Stack Overflow
• Heap Corruption

などです。

この場合、「ESP32が勝手に再起動した」のではなく、

Panic Handlerが異常を検出し、その結果として再起動した

と考えます。

Heapの状態も一緒に確認する

今回のサンプルでは、Free Heapも定期的に表示しています。

static void print_memory_status(void)
{
    ESP_LOGI(
        TAG,
        "Free heap: %lu bytes",
        (unsigned long)esp_get_free_heap_size());

    ESP_LOGI(
        TAG,
        "Minimum free heap: %lu bytes",
        (unsigned long)esp_get_minimum_free_heap_size());
}

esp_get_free_heap_size()では現在利用可能なHeap量を確認できます。

また、esp_get_minimum_free_heap_size()では、起動してから現在までで最も少なかったFree Heap量を確認できます。

例えば長時間運転してFree Heapが継続的に減少しているのであれば、Memory Leakなどを疑う材料になります。

ただし、Free Heapが減っただけでMemory Leakと断定してはいけません。

システムや各Componentが必要に応じてMemoryを確保している場合もあります。

ここでも重要なのは、

時間とともにどのように変化しているかを見ること

です。

再起動したら、まず分類する

突然再起動したときは、最初からすべてを疑うのではなく、まず大きく分類します。

Brownout → 電源を確認

Watchdog → Task・割り込み・長時間処理を確認

Panic → 再起動直前のログとBacktraceを確認

その他 → 発生条件とReset Reasonを確認

BrownoutなのにTask処理を延々と調べても、なかなか原因にはたどり着けません。

逆にTask Watchdogなのに電源回路だけを調べても同じです。

最初に現象を分類する。

これが突然再起動する問題を切り分ける第一歩です。

Task Watchdogが出たら何を見るか

前半では、esp_reset_reason()を使って再起動の原因を大きく分類しました。

ここからは、それぞれのリセット理由が確認できたあと、具体的に何を調べればよいのかを見ていきます。

まずはTask Watchdogです。

ESP_RST_TASK_WDTが確認できた場合、

「Watchdogを無効にすれば直る」

と考えるのはおすすめできません。

Watchdogは問題そのものではなく、プログラムが正常に処理を継続できていないことを知らせている可能性があるからです。

最初に確認したいのは、

• 長時間終了しない処理
• Blockしないループ
• Task優先度
• 他Taskへ実行機会を与えているか
• MutexやSemaphoreの待ち状態
• 処理時間が想定以上に長くなっていないか

などです。

vTaskDelay()の意味を確認する

前半で掲載したサンプルコードでは、メインループを次のようにしています。

while (1)
{
    print_memory_status();

    vTaskDelay(pdMS_TO_TICKS(5000));
}

ここで重要なのは、単に5秒待っていることではありません。

vTaskDelay()を実行すると、そのTaskは指定時間だけBlock状態になります。

その間、Schedulerは他の実行可能なTaskへCPU時間を割り当てられます。

一方、

while (1)の中で重い計算を延々と実行する、

非常に長い処理から戻ってこない、

高優先度TaskがCPUを占有し続ける、

といった構造では、他のTaskやIdle Taskが十分に実行されない可能性があります。

Watchdogが発生した場合は、

Watchdogの時間を長くする前に、CPUを占有している処理がないか確認する

ことを優先します。

Interrupt WatchdogはTask Watchdogと分けて考える

ESP_RST_INT_WDTとESP_RST_TASK_WDTは、同じWatchdogでも調査対象が異なります。

Task WatchdogならTask処理を中心に確認します。

一方、Interrupt Watchdogが発生している場合は、

• Interruptを長時間Disableしていないか
• Critical Sectionが長すぎないか
• ISR内で時間のかかる処理をしていないか

などを確認します。

割り込み処理では、

「ISRの中ですべてを処理する」

のではなく、

「ISRでは必要最低限の処理だけ行い、重い処理はTask側へ渡す」

という構成が基本になります。

PanicではReset Reasonだけで終わらない

次にESP_RST_PANICだった場合です。

この場合、Reset Reasonから分かるのは、

Panicによって再起動した

というところまでです。

本当に欲しい情報は、再起動する直前のログにあります。

ESP-IDFでは異常発生時に、例外の種類やRegister Dump、Backtraceなどが出力される場合があります。

例えば、

LoadProhibited

が表示されていた場合は、不正なMemory AddressへのReadを疑います。

StoreProhibited

なら、不正なMemory AddressへのWriteを疑います。

このように、Panicの種類によって確認すべきコードが変わります。

Backtraceを見る

Panic発生時にはBacktraceが表示されることがあります。

Backtraceから、

「どの関数を通って異常箇所へ到達したのか」

を追える場合があります。

ESP-IDF Monitorを使用している環境では、BacktraceのAddressからソースコード上の関数名や行番号へ変換された情報を確認できる場合があります。

ここで大切なのは、

最後に表示された関数だけを原因と決めつけないこと

です。

例えば不正なPointerを別の関数で生成し、そのPointerを後から使用した場所で例外が発生するケースがあります。

つまり、

異常が発生した場所と、異常を作り込んだ場所が同じとは限りません。

Backtraceを手掛かりに、その少し前の処理まで確認します。

Brownoutなら「発生する瞬間」を探す

Brownoutの場合は、電源電圧だけを見るのではなく、

何をした瞬間にBrownoutが発生するのか

を確認すると原因を絞りやすくなります。

例えば、

• Wi-Fi送信開始
• BLE通信開始
• 外部回路ON
• モーター駆動開始
• リレー切替
• LED点灯
• USB接続状態の変化

などです。

「30分に1回再起動する」

という情報だけより、

「Wi-Fi送信開始直後に再起動する」

という情報の方が、はるかに原因を探しやすくなります。

ESP32直近で3.3Vを測る

電源波形を測定するときは、できるだけESP32の電源端子に近い場所で確認します。

電源ICの出力が正常でも、

配線抵抗、

パターンインピーダンス、

コネクタ、

GND、

負荷変動、

などによってESP32側の電圧が変動する可能性があります。

特に自作基板では、

「電源ICの出力は3.3Vだった」

だけで判断せず、

「ESP32が実際に受け取っている3.3Vはどうなっているか」

を見ることが重要です。

Heapは「現在値」だけでは判断しない

ESP_LOGI(
    TAG,
    "Free heap: %lu bytes",
    (unsigned long)esp_get_free_heap_size());

ESP_LOGI(
    TAG,
    "Minimum free heap: %lu bytes",
    (unsigned long)esp_get_minimum_free_heap_size());

ここで注目したいのは、単純なFree Heapの大きさだけではありません。

例えば起動直後に100kBあり、しばらくして80kBになったとしても、それだけでMemory Leakとは判断できません。

一方、

100kB
95kB
90kB
85kB
80kB
75kB

のように、特定操作を繰り返すたびに戻らず減少しているのであれば、調査する価値があります。

例えば、

接続する
→ Memory確保

切断する
→ Memory解放

という処理を繰り返したとき、確保したMemoryが適切に解放されているか確認します。

「何MB残っているか」ではなく「同じ操作を繰り返したときどう変化するか」

を見るのがポイントです。

HeapとStackを混同しない

ESP32のMemory問題を調査するときに注意したいのが、HeapとTask Stackは同じものではないという点です。

Free Heapに余裕があっても、特定Taskへ割り当てたStackが不足する可能性があります。

逆にTask Stackに余裕があっても、動的Memory確保を繰り返してHeap側で問題が発生することがあります。

そのため、

Free Heapが十分あるからMemory問題ではない

とは断定できません。

Task Stackが疑わしい場合は、FreeRTOSのStack High Water Markなども使って確認します。

ソフトウェアResetも確認する

再起動が発生した場合、ハードウェア異常とは限りません。

前半のサンプルコードではesp_reset_reason()の結果を文字列へ変換しています。

case ESP_RST_SW:
    return "SOFTWARE";

ESP_RST_SWが確認できた場合は、ソフトウェアからResetされた可能性を確認します。

例えばアプリケーション側で異常を検出した際に、意図的に再起動する設計になっている場合があります。

この場合、

「なぜESP32がResetしたのか」

ではなく、

「なぜプログラムがResetを要求したのか」

を追います。

ここでもReset Reasonを最初に確認していれば、電源やWatchdogを必要以上に調査せずに済みます。

再現条件を作る

原因調査で非常に重要なのが、再現条件です。

例えば、

「たまに再起動する」

だけでは調査が難しくなります。

そこで条件を変えてみます。

• Wi-Fiを使用すると発生するか
• Wi-Fiを停止すると発生しないか
• 外部負荷を外すとどうなるか
• 通信周期を変更するとどうなるか
• 特定処理を繰り返すと発生するか
• 数分なのか数時間なのか
• 電源投入直後なのか長時間運転後なのか

こうして、

「何をすると発生し、何をすると発生しないのか」

を探します。

原因そのものがまだ分からなくても、再現条件が分かれば調査はかなり進みます。

一度に複数の条件を変えない

原因調査中に、

電源を変更する。

プログラムも変更する。

通信速度も変更する。

Task構成も変更する。

これを一度に行うと、問題が解消しても、

何が原因だったのか分からなくなります。

基本的には、一度に変更する条件をできるだけ少なくします。

例えばBrownoutが疑わしいなら、

まず電源波形を測定する。

次に電源条件を変更する。

それでも発生するなら次の条件を見る。

というように進めます。

現場では「再起動した」より前の情報が重要

突然再起動するトラブルでは、Reset後のESP32だけを見ても情報が少ないことがあります。

重要なのは、

再起動する直前に何が起きていたのか

です。

そのため開発中は、最低限でも、

• 起動ログ
• Reset Reason
• 主要処理の開始・終了
• Error
• 通信状態
• Memory状態

などをログとして残しておくと、後から原因を追いやすくなります。

特に再現頻度が低い問題では、

問題が起きてからログを追加するのでは遅い

ことがあります。

製品開発では、正常時には邪魔にならず、異常時には調査材料になるログ設計も重要です。

ESP32が突然再起動したときの切り分け手順

ここまでを実際の調査順にすると、次のようになります。

1. Reset Reasonを確認する

まずesp_reset_reason()で大分類します。

2. 再起動直前のログを保存する

PanicやWatchdogの情報が残っていないか確認します。

3. 発生条件を整理する

通信開始時、負荷切替時、長時間運転後など、再現条件を探します。

4. Brownoutなら電源波形を確認する

ESP32直近の3.3Vをオシロスコープで確認します。

5. WatchdogならTask・ISRを確認する

長時間処理、CPU占有、Critical Sectionなどを確認します。

6. PanicならBacktraceを確認する

異常発生箇所だけでなく、そこへ至った処理も追います。

7. Memoryを疑う場合は時間変化を見る

HeapやStackの余裕を継続的に確認します。

8. 一つずつ条件を変更する

変更結果から原因候補を減らします。

この順序なら、

「とりあえずコードを書き換えてみる」

よりも、原因を残しながら調査できます。

まとめ

ESP32が突然再起動すると、ソフトウェアのバグを最初に疑いたくなります。

しかし実際には、

Brownout
Watchdog
Panic
Memory
Software Reset

など、さまざまな原因があります。

そこで最初に行うのが、

Reset Reasonの確認です。

原因を推測して修正するのではなく、

観測する
→ 分類する
→ 再現する
→ 一つずつ切り分ける

という順序で調査します。

特に自作基板では、プログラムだけでなく電源やGND、負荷変動まで含めて考える必要があります。

ESP32が再起動したという結果だけを見るのではなく、

「再起動する直前に何が起きたのか」

を残しておくことが、原因特定への近道です。

技術は、経験から価値になる。

DLROW Design | 現場エンジニア

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.

「低速なら動くのに、クロックを上げると通信エラーになる」

「机の上では動いていたのに、基板にしたら不安定になった」

「同じプログラムなのに、ときどき受信データが化ける」

といった現象に遭遇することがあります。

SPI通信が一応動いているため、プログラムの問題なのか、配線なのか、クロックなのか判断しにくいトラブルです。

特にSPIは通信速度を上げるほど、単純な「HIGHとLOW」だけでは説明できない信号品質の影響が大きくなります。

今回はESP32-C5とESP-IDFを例に、

SPI通信が不安定になるとき、どこから確認すればよいのか

を実際の切り分け方法と合わせて解説します。

SPIクロックを下げて確認する

SPI通信が不安定な場合、最初に試したいのがクロック周波数を下げることです。

例えば現在20MHzで通信しているのであれば、

20MHz
 ↓
10MHz
 ↓
5MHz
 ↓
1MHz

のように下げて確認します。

ここで1MHzなら安定して通信できるのであれば、

• SPI Modeが完全に間違っている
• MOSI/MISOを逆接続している
• CSがまったく動いていない

といった根本的な問題である可能性は低くなります。

一方、1MHzなら安定するが20MHzではエラーになる

のであれば、クロック速度によって顕在化する問題を疑えます。

このように、条件を一つずつ変えて原因候補を減らしていくことが重要です。

今回使用するサンプルコード

今回はSPI Deviceへ8byteを送信し、同時に8byteを受信する簡単なテストコードを使用します。

実際のセンサーなどに依存しないよう、SPI通信部分そのものを確認する構成です。

※実際に受信値を検証する場合は、接続するSPI Deviceの仕様に合わせて送信コマンドを変更してください。

#include <stdio.h>
#include <string.h>

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

#include "driver/spi_master.h"

#include "esp_err.h"
#include "esp_log.h"

#define SPI_HOST        SPI2_HOST

#define PIN_NUM_MOSI    GPIO_NUM_4
#define PIN_NUM_MISO    GPIO_NUM_5
#define PIN_NUM_CLK     GPIO_NUM_6
#define PIN_NUM_CS      GPIO_NUM_7

#define SPI_CLOCK_HZ    (1 * 1000 * 1000)

static const char *TAG = "SPI_TEST";

static spi_device_handle_t spi_handle;

static void spi_test_transfer(void)
{
    uint8_t tx_data[8] = {
        0x10, 0x20, 0x30, 0x40,
        0x50, 0x60, 0x70, 0x80
    };

    uint8_t rx_data[8] = {0};

    spi_transaction_t transaction = {
        .length = sizeof(tx_data) * 8,
        .tx_buffer = tx_data,
        .rx_buffer = rx_data,
    };

    esp_err_t ret = spi_device_transmit(
        spi_handle,
        &transaction);

    if (ret != ESP_OK)
    {
        ESP_LOGE(
            TAG,
            "SPI transmit failed: %s",
            esp_err_to_name(ret));

        return;
    }

    ESP_LOGI(
        TAG,
        "RX: %02X %02X %02X %02X %02X %02X %02X %02X",
        rx_data[0],
        rx_data[1],
        rx_data[2],
        rx_data[3],
        rx_data[4],
        rx_data[5],
        rx_data[6],
        rx_data[7]);
}

void app_main(void)
{
    spi_bus_config_t bus_config = {
        .mosi_io_num = PIN_NUM_MOSI,
        .miso_io_num = PIN_NUM_MISO,
        .sclk_io_num = PIN_NUM_CLK,
        .quadwp_io_num = -1,
        .quadhd_io_num = -1,
    };

    ESP_ERROR_CHECK(
        spi_bus_initialize(
            SPI_HOST,
            &bus_config,
            SPI_DMA_CH_AUTO));

    spi_device_interface_config_t device_config = {
        .clock_speed_hz = SPI_CLOCK_HZ,
        .mode = 0,
        .spics_io_num = PIN_NUM_CS,
        .queue_size = 1,
    };

    ESP_ERROR_CHECK(
        spi_bus_add_device(
            SPI_HOST,
            &device_config,
            &spi_handle));

    ESP_LOGI(
        TAG,
        "SPI initialized: %d Hz",
        SPI_CLOCK_HZ);

    while (1)
    {
        spi_test_transfer();

        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

このコードではSPIクロックを、

#define SPI_CLOCK_HZ    (1 * 1000 * 1000)

としているため、1MHzで通信します。

まずこの状態で安定して通信できることを確認します。

クロック周波数を変更する

先ほどのサンプルコードでは、SPIクロックをマクロで定義しています。

#define SPI_CLOCK_HZ    (1 * 1000 * 1000)

そしてDevice登録時に、その値を使用しています。

抜粋コード

spi_device_interface_config_t device_config = {
.clock_speed_hz = SPI_CLOCK_HZ,
.mode = 0,
.spics_io_num = PIN_NUM_CS,
.queue_size = 1,
};

例えば5MHzで確認する場合は、

#define SPI_CLOCK_HZ    (5 * 1000 * 1000)

へ変更します。

ただし、この5MHzのコードは上記サンプルコードそのものではなく変更例です。

サンプルコードとして掲載している完成版では、最初の動作確認を目的として1MHzにしています。

「最大クロック」と「安定して使えるクロック」は別

SPI Deviceのデータシートを見ると、

Maximum SCLK Frequency：20MHz

などと記載されていることがあります。

ここで注意したいのは、

20MHzまで対応していることと、現在の基板・配線条件で20MHzが安定することは同じではない

ということです。

通信品質には、

• ESP32側の信号
• Device側の入力特性
• PCBパターン
• ジャンパ線
• コネクタ
• 配線長
• 負荷容量
• GND
• 電源品質

なども関係します。

そのため開発初期では、まず低速で通信を成立させ、その後クロックを上げていく方が原因を切り分けやすくなります。

SPI Modeを確認する

クロックを十分下げても通信内容がおかしい場合は、SPI Modeも確認します。

今回のサンプルコードでは、

spi_device_interface_config_t device_config = {
    .clock_speed_hz = SPI_CLOCK_HZ,
    .mode = 0,
    .spics_io_num = PIN_NUM_CS,
    .queue_size = 1,
};

としているため、SPI Mode 0です。

接続するDeviceがMode 3を要求しているのであれば、この設定では正常に通信できません。

SPI Modeは、

• CPOL
• CPHA

によって決まり、Deviceのデータシートに指定されています。

通信速度を下げても改善しない場合には、クロック周波数だけを疑い続けず、Mode設定も再確認します。

エラーと「データ化け」は分けて考える

SPI通信のトラブルでは、

ESP-IDFがエラーを返す場合

と、

APIとしては成功しているのに受信値がおかしい場合

を分けて考える必要があります。

今回のサンプルコードでは、

esp_err_t ret = spi_device_transmit(
    spi_handle,
    &transaction);

if (ret != ESP_OK)
{
    ESP_LOGE(
        TAG,
        "SPI transmit failed: %s",
        esp_err_to_name(ret));

    return;
}

として、spi_device_transmit()の戻り値を確認しています。

ここでESP_OKが返ったからといって、

接続先Deviceから正しいデータが返ってきたことまで保証されるわけではありません。

SPI Master Driverから見ればトランザクション処理が正常に完了していても、

• Deviceがコマンドを正しく認識していない
• SPI Modeが違う
• 信号品質が悪い
• 読み出すレジスタを間違えている

などによって受信値がおかしくなることがあります。

受信値をログで確認する

そこで今回のサンプルでは、受信した8byteをログへ出しています。

ESP_LOGI(
    TAG,
    "RX: %02X %02X %02X %02X %02X %02X %02X %02X",
    rx_data[0],
    rx_data[1],
    rx_data[2],
    rx_data[3],
    rx_data[4],
    rx_data[5],
    rx_data[6],
    rx_data[7]);

例えば、

1MHz  → 毎回同じ正常値
5MHz  → 毎回同じ正常値
10MHz → ときどき異常値
20MHz → 頻繁に異常値

という結果になった場合、

通信速度と異常発生に相関があることが分かります。

この情報が得られれば、ソフトウェアのロジックだけでなく、信号品質やタイミングを確認する段階へ進めます。

ジャンパ線では動作条件が変わる

ブレッドボードやジャンパ線でSPI通信を確認する場合は、特に高速通信へ注意が必要です。

SPIクロックを高速化すると、ジャンパ線も単なる「導線」としてだけでは扱えなくなってきます。

例えば、

ESP32
 │
 │ 長いジャンパ線
 │
 ├──────── SCLK
 ├──────── MOSI
 ├──────── MISO
 └──────── CS
                    │
                 SPI Device

のような構成では、配線長やGNDの取り方によって波形が悪化することがあります。

低速では問題が見えなくても、高速化したときに初めて問題が現れるケースがあります。

確認したい切り分け順序

SPI通信が不安定なとき、私は次のように原因候補を減らしていくのが良いと考えています。

① SPIクロックを下げる
        ↓
② SPI Modeを確認
        ↓
③ CS動作を確認
        ↓
④ MOSI / MISO / SCLKを確認
        ↓
⑤ GND・電源を確認
        ↓
⑥ オシロスコープで波形確認
        ↓
⑦ 信号品質対策を検討

重要なのは、最初からすべてを変更しないことです。

クロック、Mode、配線、抵抗値を同時に変更してしまうと、

何を変更したことで改善したのか分からなくなります。

一つ変更して、一つ結果を見る。

これはSPIに限らず、組み込み開発のデバッグ全般で有効な考え方です。

SCLK波形を確認する

SPI通信が低速では安定しているのに、高速化すると不安定になる場合は、まずSCLK波形を確認したいところです。

デジタル信号は、論理的にはHIGHとLOWの2値ですが、実際の配線上では立ち上がり時間、立ち下がり時間、オーバーシュート、リンギングなどの影響を受けます。

特にSCLKは一定周期で繰り返し変化するため、信号品質の問題が顕在化しやすい信号です。

立ち上がり・立ち下がりが遅い場合

SCLKのエッジが鈍っていると、Device側でしきい値を跨ぐタイミングが曖昧になります。

理想波形

┌─────┐      ┌─────┐
│          │      │          │
│          │      │          │
┘          └───┘          └─────


立ち上がりが遅い波形

   ／─────
 ／
┘

のような違いです。

クロック周波数が低いと多少エッジが遅くても余裕がありますが、高速化するとセットアップ時間やホールド時間に対する余裕が減ります。

その結果、同じ回路でも1MHzでは正常、20MHzでは不安定という現象が起こります。

オーバーシュートとリンギング

高速なデジタル信号では、配線長やドライバの立ち上がり速度によって、波形が一度大きく振れてから振動することがあります。

これがオーバーシュートやリンギングです。

理想

──────┐
            │
            └──────

リンギングあり

─────╮╲╱╲╱────────

この振動が入力しきい値を何度も跨ぐと、Device側が余分なクロックエッジとして認識する可能性があります。

特にSCLKで発生すると、1bit余計に読み込む、ビット位置がずれる、といった問題につながることがあります。

シリーズ抵抗を検討する

リンギングが確認された場合、SCLKやMOSIへシリーズ抵抗を追加すると改善することがあります。

例えば、

ESP32 GPIO ──[22Ω〜47Ω]── SCLK ── SPI Device

のように、信号源の近くへ抵抗を配置します。

シリーズ抵抗は信号の立ち上がりを少し緩やかにし、反射やリンギングを抑える目的で使用します。

ただし、

とりあえず抵抗を入れればよい

というものではありません。

抵抗値が大きすぎると立ち上がり・立ち下がりが遅くなり、高速通信では逆にタイミング余裕を減らす可能性があります。

そのため実際には、オシロスコープで波形を確認しながら調整するのが理想です。

SCLKだけでなくMOSIも確認する

クロックだけ正常でも、MOSI側のデータ波形が崩れていれば通信は不安定になります。

確認したいのは、

• SCLK
• MOSI
• MISO
• CS

の4信号です。

特に、SCLKとMOSIを同時に観測すると、

データがクロックエッジに対して十分早く確定しているか

を確認しやすくなります。

CSのタイミングを確認する

通信開始直前や終了直後のCSタイミングも重要です。

今回のサンプルコードでは、Device登録時にCSをESP-IDFへ任せています。

spi_device_interface_config_t device_config = {
    .clock_speed_hz = SPI_CLOCK_HZ,
    .mode = 0,
    .spics_io_num = PIN_NUM_CS,
    .queue_size = 1,
};

この場合、spi_device_transmit()に合わせてSPI Master DriverがCSを制御します。

esp_err_t ret = spi_device_transmit(
    spi_handle,
    &transaction);

それでも接続するDeviceによっては、

• CSを下げてから最初のクロックまでの待ち時間
• 最後のクロックからCSを上げるまでの待ち時間
• トランザクション間の待ち時間

などに条件がある場合があります。

そのため、DeviceのデータシートにあるCS timingも確認します。

GNDリターンパスを確認する

SPI信号はGPIOからDeviceへ流れて終わりではありません。

電流はGND側を通って戻ります。

つまり、信号線だけでなくリターンパスも重要です。

例えばPCB上でSCLKの直下に連続したGNDプレーンがあれば、比較的きれいなリターンパスを確保できます。

一方、

• GNDプレーンが途中で分断されている
• スリットを跨いでいる
• コネクタ経由で遠回りしている

といった状態では、信号品質が悪化する可能性があります。

高速SPIでは、

信号線だけを見るのではなく、戻り電流がどこを流れるか

まで考える必要があります。

配線の分岐を短くする

複数DeviceへSPIを分岐する場合、前回の記事で紹介したようにSCLK・MOSI・MISOを共有できます。

ただし、ハードウェア的には分岐が増えるほど信号品質は厳しくなります。

例えば、

ESP32
  │
  ├──────────── Device A
  │
  └──────────── Device B

よりも、

ESP32 ──────────┬── Device A
                          └── Device B

のように、長いスタブができる構成では反射の影響が出やすくなります。

特にSCLKは、不要に長い分岐を避けた方が安全です。

ブレッドボードと製品基板は同じではない

開発初期にブレッドボードやジャンパ線で動作確認できたとしても、製品基板で必ず同じ結果になるとは限りません。

逆に、ブレッドボードでは10MHzが不安定でも、PCBでは問題なく20MHzで動作することもあります。

これは、

• 配線長
• 配線インピーダンス
• GND
• コネクタ
• Device配置

などの条件が異なるためです。

そのため、

試作環境で確認できた最大クロック = 製品での最終クロック

とは考えない方がよいです。

ロジックアナライザとオシロスコープの使い分け

SPIデバッグでは、ロジックアナライザとオシロスコープの両方が役立ちます。

ロジックアナライザ

向いている確認項目は、

• MOSIデータ
• MISOデータ
• CS
• SPI Mode
• コマンド内容
• 通信順序

です。

プロトコルデコーダを使えば、送受信データをHEX表示できるため非常に便利です。

オシロスコープ

向いているのは、

• 立ち上がり時間
• 立ち下がり時間
• オーバーシュート
• リンギング
• ノイズ
• 電圧レベル
• クロックとデータのタイミング関係

です。

つまり、

通信内容を見る → ロジックアナライザ
波形品質を見る → オシロスコープ

という使い分けが基本です。

「ロジアナで正常」は信号品質が正常とは限らない

ここは注意したいポイントです。

ロジックアナライザは入力信号をHIGH / LOWとして判定します。

そのため、多少波形が崩れていても、しきい値を正しく跨いでいれば正常に見えることがあります。

一方、実際のSPI Deviceでは入力条件が異なり、同じ波形でも誤動作する可能性があります。

つまり、

ロジックアナライザで正しくデコードできた

だけで、信号品質まで保証されたわけではありません。

不安定現象がある場合は、オシロスコープでも確認する価値があります。

電源品質も確認する

SPI通信が高速化すると、Device側の内部回路も高速に動作します。

そのため、電源が不安定な場合は通信エラーとして現れることがあります。

確認したいのは、

• 3.3V電源
• デカップリングコンデンサ
• GND
• Device直近の電源波形

です。

特にDeviceの近くにデカップリングコンデンサがない場合や、長い配線で電源を供給している場合は注意が必要です。

不安定な通信を切り分ける実践フロー

今回の記事の内容を実際の切り分け順にまとめると、次のようになります。

       SPI通信が不安定
               ↓
       クロックを下げる
               ↓
           安定する？
 ┌──────┴──────┐
YES               NO
 ↓               ↓
信号品質を疑う   Mode・配線・CS確認
 ↓
SCLK/MOSI観測
 ↓
リンギング確認
 ↓
配線・GND確認
 ↓
必要ならシリーズ抵抗
 ↓
徐々にクロックUP

この順番なら、無闇に条件を変更せずに原因を絞り込めます。

実務で大切なのは「最大速度」ではない

SPI通信では高速化に目が向きがちですが、製品設計では必ずしも最大クロックで使う必要はありません。

例えば20MHzまで対応しているDeviceでも、5MHzで必要な処理が十分間に合うなら、あえて5MHzで使う判断もあります。

通信速度を上げれば、

• 信号品質
• EMI
• クロストーク
• タイミング余裕

は厳しくなります。

必要な性能を満たしているなら、

余裕を持った通信速度を選ぶ

ことも立派な設計判断です。

まとめ

ESP32のSPI通信が不安定な場合、プログラムだけを疑うのではなく、クロック・配線・GND・信号品質まで含めて確認する必要があります。

特に、

• 低速では安定する
• 高速化するとエラーが増える

という現象は、重要な手掛かりです。

まずクロックを下げ、

次にSPI ModeやCSを確認し、

それでも高速化時だけ問題が出るのであれば、オシロスコープで信号品質を確認します。

必要に応じて、

• 配線の短縮
• GNDリターンパス改善
• シリーズ抵抗
• クロック周波数の見直し

などを検討します。

SPI通信では、

「最大何MHzまで出せるか」より、「必要な性能を安定して満たせるか」

の方が重要です。

安定した条件を一つずつ確認しながら、必要な性能へ近づけていく。

この進め方が、結果的に最短のデバッグになることがあります。

技術は、経験から価値になる。

DLROW Design｜現場エンジニア

Copyright © 2026 江藤良樹の仕事は物づくり All Rights Reserved.