Arduino Wi‑Fi接続はESP32で｜最短手順とボード選び - TsukuLab | ツクラボ

arduinoでwifi接続したいならなぜesp32が有力なのか">ArduinoでWi‑Fi接続したいなら、なぜESP32が有力なのか

Arduino UNOとESP32の基本スペック比較

Arduinoという言葉は、ボード単体というより、開発環境まで含めたエコシステム全体を指すことが多いです。
その中でArduino UNOは「マイコン入門の基準点」として長く使われてきました。
一方、ESP32は「無線につながる工作を最短で形にするための入口」として選ばれることが増えています。
両者は競合製品というより、得意分野が違うボードだと捉えると整理しやすくなります。

まず押さえたいのは、Arduino UNOはATmega328P系の16 MHz動作ボードとして広く知られ、デジタルI/O 14本、アナログ入力 6本という構成が基本だという点です。
センサーを読んでLEDを光らせる、サーボを動かす、タイマー制御を学ぶといった教材では、今でも定番です。
対してESP32はEspressifのSoCファミリーで、Wi‑FiとBluetoothを内蔵し、classic系では最大240 MHz級のCPUが使われます。
無線通信を前提にした設計なので、同じ「マイコンボード」でも役割の置き方が違います。

項目	Arduino UNO	ESP32-WROOM-32系	ESP32-S3/C3/C6系
主な位置づけ	電子工作の基礎学習、I/O制御の入門	Wi‑Fi機器、IoT試作の定番	用途別に選ぶESP32の発展系
CPUの目安	ATmega328P系、16 MHz	最大240 MHz級	C3は160 MHz、用途別に機能が分かれる
Wi‑Fi	標準では非搭載	標準搭載	標準搭載
Bluetooth	標準では非搭載	搭載	系列により対応内容が異なる
I/Oの基準情報	デジタルI/O 14本、アナログ入力 6本	ボードごとに異なる	ボードごとに異なる
向いている用途	Lチカ、センサー、モーター制御の基礎	Web表示、MQTT、OTAを使うIoT	USB活用、低コスト化、スマートホーム系など
無線工作の始めやすさ	外付けモジュール前提になりやすい	ボード単体で始められる	機能選定まで含めて考える必要がある

この表から見えてくるのは、UNOが劣っているという話ではなく、Wi‑Fi接続をテーマにした瞬間に前提条件が変わるということです。
UNOで無線LANにつなぐには、外付けのWi‑Fiモジュールやシールドを組み合わせる流れになりやすく、電源、通信方式、配線の整合まで考える場面が増えます。
筆者の経験では、ここで最初のつまずきが起きやすいです。
ブレッドボード上でジャンパ線が1本抜けただけでも通信できず、原因の切り分けが「コード」ではなく「配線」から始まります。

それに対してESP32 Dev Module系のボードは、Wi‑Fi機能が最初から載っています。
センサーを1つつないで、あとはWiFi.hで接続し、IPアドレスを確認するところまで一気に進めます。
筆者がワークショップで見てきた範囲でも、UNOに外付けWi‑Fiモジュールを足すより、ESP32をそのまま使った方が初回の成功率は明らかに高いです。
理由は単純で、無線部分の配線がほぼ消えるからです。
初心者にとって、配線本数が減ることは快適さの話ではなく、失敗箇所が減るという意味を持ちます。

IoT向きと言われる理由も、この延長で理解すると腑に落ちます。
無線内蔵なので筐体内の配線が減り、CPUやメモリに余裕があるので、センサ値を送るだけでなく、小さなWebサーバーを立てたり、『MQTT』でブローカーと通信したり、OTAで後から書き換えたりという運用まで視野に入ります。
UNOでも工夫次第で近いことはできますが、最初からその土俵に立てるのがESP32の強みです。

EMQX: The Unified MQTT Platform for AI and IoT Data Streaming

Leverage EMQX

emqx.io

Arduino IDEからESP32を使える理由

ESP32が入門向けとして強いのは、ハードウェアだけでなく、普段のArduino IDEの流れをほぼそのまま使えるからです。
初心者が最初に触れる開発環境は、今でもArduino IDE 2.xであることが多いです。
ここで別のSDKやコマンドライン中心の環境に飛ばずに済むのは、学習の連続性という意味で大きな差になります。

具体的には、Arduino IDEのBoards ManagerにESP32 by Espressif Systemsを追加すれば、ESP32向けのボード定義やライブラリをインストールできます。
導入手順は、環境設定で追加のボードマネージャURLに package_esp32_index.json を登録し、ボードマネージャで「esp32」を検索してインストールする流れです。
Random Nerd TutorialsのESP32 Getting StartedRandom Nerd TutorialsのESP32 Getting Startedでも、この手順から始める構成になっていて、現場でもこの入口がもっとも理解されやすいです）。

ここがポイントです。
Arduino IDEからESP32を扱えるということは、スケッチを書く感覚がUNOと大きく離れないということです。setup() と loop() の基本構造はそのままですし、Wi‑Fi接続も WiFi.begin()、接続確認も WiFi.status()、IPアドレス取得も WiFi.localIP() と、Arduino文脈の延長で読めるコードに収まります。
初心者が「新しいボードを学ぶ」のではなく、「Arduinoの守備範囲が広がる」と感じられるのは、この一貫性のおかげです。

さらに、ESP32は次の段階へ進みやすい土台があります。
たとえばWi‑Fi初期設定ではSoftAPやBLEを使ったプロビジョニングが選べますし、運用フェーズではOTA更新も現実的です。
Last Minute EngineersのESP32 OTA Updates（https://lastminuteengineers.com/esp32-ota-updates-arduino-ide/で紹介されている通り、Arduino IDEの流れのまま無線経由の更新まで持っていけます。
UNO系ボードで同じ体験を目指すと、追加部品と構成設計の比重が一気に上がります）。

もちろん、ESP32はファミリーが広いので、classicのESP32-WROOM-32、USB周りでも人気のESP32-S3、低コスト寄りのESP32-C3、スマートホーム文脈で注目されるESP32-C6と、選ぶ段階で迷うことはあります。
ただ、初心者が最初に使う1枚としては、ESP32 Dev Moduleとして認識される定番ボードを選べば、Arduino IDEでの書き込み、Wi‑Fi接続、シリアルモニタ確認まで素直に進められます。
UNOの知識がそのまま生きるという点で、ESP32は「別世界のマイコン」ではありません。

NOTE

Arduino IDEでESP32を使う価値は、無線機能そのものよりも、学習コストを増やさずに無線機能を足せるところにあります。
IDE、スケッチ構造、ライブラリ管理の流れが続くので、初心者が迷う場所が増えません。

Getting Started with the ESP32 Development Board ｜ Random Nerd Tutorials

This is a getting started guide for the ESP32 Development board. The ESP32 is the ESP8266 sucessor. Loaded with new feat

randomnerdtutorials.com

価格・入手性と“最初の1枚”の現実解

対して、公式ストア掲載の例ではArduino UNO R4 WiFiが27.60米ドル、Arduino UNO Q 4GBが61.04米ドルです。
どちらもArduinoブランドの安心感があり、UNO系の流れを保ったまま進みたい人には魅力があります。
特にUNO R4 WiFiは「Arduinoの延長でWi‑Fiも使いたい」という要望に真正面から応える存在です。
ただ、価格差をそのまま教材や試作の自由度に置き換えると、ESP32の方がボード追加や失敗を含めた試行回数を確保しやすい、という現実があります。

この「試行回数を確保しやすい」というのは、初心者にとって小さくない要素です。
IoTの学習は、Lチカの次にすぐ成功するとは限りません。
Wi‑Fi接続、ルーター側の設定、シリアルポート認識、場合によっては書き込み時のBOOT操作まで、何段階か乗り越える必要があります。
そのとき、1枚のボード価格が抑えられていると、壊したらどうしようという心理的な重さが減ります。
筆者が講座でESP32を選ぶ場面が多いのも、スペックだけでなくこの気軽さがあるからです。

さらに、ESP32は情報量が多いです。
Arduino IDEでの導入記事、Wi‑Fi接続例、Webサーバー、MQTT、OTA、BLEプロビジョニングまで、実装例が豊富に見つかります。
『EMQX』のESP32 MQTT Beginner Guide（https://www.emqx.com/en/blog/esp32-connects-to-the-free-public-mqtt-brokerのように、MQTTに進むための足場も整っています。
学び始めたあとに「次は何を作ればいいか」が続いていることは、最初の1枚としての価値に直結します）。

もちろん、UNO系の資産をそのまま使いたい、公式ブランドで揃えたい、授業や既存教材との整合を優先したいならArduino UNO R4 WiFiは有力です。
ただ、無線LANにつながる工作をゼロから始める文脈では、無線内蔵、Arduino IDE対応、価格帯、情報量、拡張の広さがそろったESP32の方が、入門ボードとしての収まりがいいです。
筆者なら「最初の1枚」に挙げるのは、今でもESP32 Dev Module系の定番ボードです。
Wi‑Fiセンサー、簡単なWeb表示、MQTT送信、OTA更新まで1枚でつながるので、Arduinoの延長線上でIoTを体験するにはちょうどいい立ち位置です。

ESP32で始める前に知っておきたい基礎知識

用語の整理：SoC / モジュール / 開発ボード

ESP32で最初につまずきやすいのは、性能より先に「名前が指している実体」が広いことです。
ワークショップでも、ESP32-WROOM-32と書かれた銀色の部品を見て「これがボードですか？」と止まる場面がよくあります。
逆にESP32 Dev ModuleというArduino IDEの項目名を見て、製品名だと思って探し始める人もいます。
ここがほどけると、型番の見え方が一気に変わります。

まずSoC（System on Chip）は、マイコン、無線機能、周辺回路の一部を1つのチップにまとめた中核部品です。
Espressifの『ESP32 Product Overview』で見えてくるESP32ESP32-S3ESP32-C3などは、この“頭脳”の系列名だと考えると整理できます。
電子工作の文脈では「ESP32のチップそのもの」と言い換えても大きくは外れません。

次の層がモジュールです。
たとえばESP32-WROOM-32は、SoCに加えてフラッシュメモリやアンテナまわりを実装し、基板に載せやすい形にまとめた部品です。
よく見る金属シールド付きの四角いパーツがこれに当たります。
SoC単体より扱いやすく、メーカー製品や自作基板にも組み込みやすいのが役割です。

その外側にあるのが開発ボードです。
ESP32-DevKitCや各社のESP32-S3 DevKitのように、モジュールへUSB端子、電源回路、書き込み回路、ピンヘッダを足して、すぐ試せる形にしたものです。
USBケーブルでPCにつなぎ、ブレッドボードへ差して、Arduino IDEから書き込む――初心者が手に取るのはたいていこの層です。

イメージで並べると、SoC＝頭脳のチップ、モジュール＝頭脳を載せた無線付き部品、開発ボード＝そのまま実験できる完成度の高い基板です。
さらに「マイコンボード」という言い方は少し広く、Arduino UNOのような開発ボードも、ESP32-DevKitCのような開発ボードも含む総称として使われます。
つまり、マイコンボードという大きな箱の中に、ESP32系の開発ボードが入っている、と捉えると混乱しません。

ここでひとつ補足すると、Arduino IDEのボード選択に出てくるESP32 Dev Moduleは、特定の1製品名というより汎用的な設定名として使われることがあります。
実物の基板にESP32-WROOM-32と印字されていても、IDE上ではESP32 Dev Moduleを選ぶ、といった対応になるわけです。
初学者はこの「型番」と「IDE上の名前」のずれで止まりやすいんですよね。

ESP32 Wi-Fi & Bluetooth SoC

espressif.com

Wi‑Fiは2.4GHz中心という大前提

Wi‑Fiは一般には無線LANの通称として使われる言葉です。
ケーブルなしでネットワークにつなぐ仕組み、と考えればこの段階では十分です。
ESP32が便利なのは、その無線LAN機能をボード側に最初から持っている点にあります。
Arduinoの入門記事でよく見る「別売りのWi‑Fiシールドを足す」流れを省いて、1枚でネットにつながる構成を組めます。

ただし、ここには初心者が先に知っておいたほうがいい前提があります。
ESP32系の入門ボードは、2.4GHz帯のWi‑Fiを中心に使うものだという点です。
家庭用ルーターが5GHzと2.4GHzの両方を出していると、ついスマホと同じ感覚で「どちらでも入る」と思いがちですが、ESP32の定番系は2.4GHz側を使う前提で組むほうが話が早いです。
SSIDが2つ分かれているルーターなら、2.4GHz側へつなぐ場面が多くなります。

この点は、実際にセットアップすると差がはっきり出ます。
PCやスマホは5GHzに入っていても、ESP32だけ接続できず、コードを疑って何度も書き直すことがあります。
ところがWi‑Fi設定を見直すと、原因は「5GHzのSSIDを入れていた」だけ、ということが少なくありません。
最初の疎通確認では、2.4GHzのSSIDとパスワードを明確に分けて扱うだけで切り分けが進みます。

ESP32 by Espressif SystemsをArduino IDEに追加して使う流れは、定番の解説記事でも整理されています。
そこで紹介されるWi‑Fi接続例も、基本は2.4GHz帯の無線LANへ接続する前提です。
入門段階では「ESP32はネットにつながる」より一歩踏み込んで、「2.4GHzのWi‑Fi子機として扱う」と覚えておくと、接続トラブルの半分くらいは先回りできます。

なお、WiFi.hでの接続自体はシンプルで、WiFi.begin() でSSIDとパスワードを渡し、WiFi.status() が WL_CONNECTED になるまで待つ、という流れが基本です。
手順は単純でも、接続先の周波数帯を取り違えると結果が返ってこないので、ここはコードより前に押さえておきたいポイントです。

ESP32ファミリーのざっくり比較

ひと口にESP32と言っても、中身は1種類ではありません。
入門向けでよく出てくるのはESP32-WROOM-32系、ESP32-S3系、ESP32-C3系、ESP32-C6系です。
さらにESP32-H2のように、名前は近くてもWi‑Fiを積まない系列もあります。
ここをまとめて理解しようとして細部で迷うより、まずは「何に向いた系列か」で掴むのが近道です。

ESP32-WROOM-32は、いわゆる定番です。
作例が多く、検索して出てくる情報量も厚めです。
Webサーバー、MQTT、センサー送信、GPIO制御といった王道のIoT題材では、この系統を基準にした説明がまだ多く残っています。
入門者にとっての利点は、困ったときに同じ画面や同じボード形状の解説を見つけやすいことです。
「最初の1枚」の軸に置かれやすい理由はここにあります。

ESP32-S3は、近年の新規設計で目にする機会が増えた系列です。
USBまわりの扱いや拡張性の面で注目されることが多く、ディスプレイ付きボードやAI寄りの作例、GUI寄りのデモでも見かけます。
入門用途でも選びやすいのですが、同じS3でも搭載メモリや端子構成がボードごとに見えやすく変わるので、購入ページの写真だけで判断すると混乱しがちです。
実際、筆者も講座でS3の名前だけを見て話すと、「それはUSB端子が2つあるボードですか、液晶付きのやつですか」と質問が分かれます。
型番だけでなく、どの開発ボードなのかまで一緒に見る必要があります。

ESP32-C3は、より軽量な方向の選択肢です。
160 MHz動作の系列として整理されることが多く、価格を抑えたい場面や、そこまで多機能を積まなくてよいセンサー用途で候補に上がります。
最初の学習対象としても成立しますが、定番のWROOM-32系と比べると、記事によって前提にしているボードや機能差を読み分ける必要が出てきます。
情報量だけで押し切るなら定番系、絞った用途で組むならC3、という見方がわかりやすいです。

ESP32-C6は、Wi‑Fi 6やThreadZigbeeまで見据えた系列として整理されています。
スマートホーム寄りの将来性に惹かれるシリーズですが、入門の主戦場はまだWROOM-32やS3のほうです。
C6は「今後の規格まで視野に入れた選択肢」と捉えると位置づけが自然です。

ESP32-H2は名前こそ近いものの、Wi‑FiではなくThreadZigbee向けの系列です。
ここは初心者が誤解しやすい部分で、ESP32と付いているからWi‑Fiにつながると思って選ぶと、用途がずれてしまいます。
この記事の主題が「ArduinoでWi‑Fi接続したい」なら、H2は主役ではありません。

2024年以降はH21など新しい名前も話題に上がっていますが、入門の中心線として見るなら、流通量が多く資料も豊富なESP32-WROOM-32系とESP32-S3系が土台です。
その上で、低価格寄りならC3、スマートホーム規格まで視野に入れるならC6、Wi‑Fi不要でThreadZigbee専用ならH2、という順に切り分けると迷いが減ります。

入門ボード選びのチェックリスト

入門ボードは、CPU名だけで選ぶより、手元で困りにくい構成かを見るほうが実用的です。
見た目が似ていても、USBまわりやピン配置で扱いが変わるためです。
ここはスペック表より、作業机の上で何が起きるかを想像すると判断しやすくなります。

まず見たいのはUSB-シリアル変換です。
『CP210x』系やCH340系がよく使われます。
前のセクションでも触れた通り、PCにポートが出ない場面ではこの部分が原因になることがあります。
入門では、ボード説明欄にUSBシリアルの型番が書かれている製品のほうが切り分けが進めやすくなります。
書き込み時に毎回BOOTボタン操作が要るボードより、自動書き込み回路が素直に動くボードのほうが学習が前へ進みます。

次にピン数です。
LEDやセンサーを数個つなぐだけなら小型ボードでも足りますが、ブレッドボードで配線を広げて学ぶ段階では、両側にある程度まとまったピンが並んだDevKitC系の形が扱いやすいです。
極端に小さいボードは省スペースですが、ジャンパワイヤが密集してGPIO表記を追いにくくなります。
手を動かして覚える初期ほど、ピン名が基板上に印字されている価値は大きいです。

電源まわりも見逃せません。
USB給電でそのまま動かせること、3.3V系のセンサーと相性がよいこと、リセット用のENボタンが独立していること、このあたりが揃うとデバッグが楽になります。
ブレッドボードで配線していると、リセットだけ何度も試したい場面が出ます。
USBを抜き差しせずENを押せるだけで、作業の流れが止まりません。

アンテナ形状にも意味があります。
基板端にアンテナ部分が逃がしてある定番ボードは、机の上に置いても無線部を意識しやすい構造です。
金属ケースへ入れる、周囲を配線で囲う、といった段階ではアンテナ位置が効いてきますが、入門ではまず「アンテナが基板のどこにあるか見てわかる」ことが助けになります。

サイズとブレッドボード適性も実用面では効きます。
幅が広すぎるボードは、ブレッドボード中央へ挿すと左右の穴列を大きくふさいでしまいます。
逆に細すぎると、USBケーブルの重みで傾きやすくなることがあります。
筆者の感覚では、定番のESP32-DevKitC系の寸法感は、ジャンパワイヤを足しても取り回しの見通しが保ちやすい位置にあります。

整理すると、入門ボードを見る視点は次の4点にまとまります。

USBまわりが明確か: 『CP210x』またはCH340の記載があり、PC接続時の切り分け先が見える
ピン配置が追えるか: GPIO表記が基板上にあり、ブレッドボードで配線を広げられる
電源と操作系が揃っているか: USB給電、3.3V運用、ENやBOOTの位置がわかる
物理サイズが実験向きか: ブレッドボードをふさぎすぎず、アンテナ位置も把握しやすい

入門の文脈では、ESP32-WROOM-32搭載のDevKitC系か、ESP32-S3の素直な開発ボードがこの条件に当てはまりやすいです。
名前の新しさより、USBでつないで書き込み、GPIOを数本引き出し、Wi‑Fiへ接続するまでを滞りなく進められることが、最初の1枚では効いてきます。

{{ogp:https://jp.silabs.com/interface/usb-bridges/usbxpress/device.cp2102n-gqfn20|{ {term_sku:1} } USBXpress USB ブリッジ - Silicon Labs|CP2102N-GQFN20 デバイスは、USBXpress ファミリの一部です。
QFN20 パッケージ（3x3）を採用した CP2102N-GQFN20 には、デジタル I/O ピンが 4 本含まれています。
このデバイスには、USB 2.|https://www.silabs.com/content/dam/siliconlabs/images/social-thumbnails/homepage-thumbnail.png}}

最短でWi‑Fi接続を試す準備

必要なものチェックリスト

Wi‑Fi接続の確認までを最短で進めるなら、まず道具を絞るのが近道です。
ここで余計な寄り道を減らすと、最初の目標を「ESP32が自宅や職場の無線LANへつながること」に固定できます。
Espressifの製品概要でもESP32はWi‑Fi搭載SoCとして案内されており、Arduino文脈では開発ボードをUSBでつないで試す流れが入口になります（Espressif ESP32 Product OverviewEspressif ESP32 Product Overview。

必要なものは次の4点です。

ESP32開発ボード（ESP32-WROOM-32系、またはESP32-S3系）
USBケーブル（データ通信対応）
PC（Arduino IDE 2.xを入れたWindows、macOS、Linux）
2.4GHz帯のWi‑Fi

この中で、初心者が最初につまずきやすいのはUSBケーブルです。
スマートフォン充電用として付属していたケーブルの中には、給電だけでデータ線が入っていないものがあります。
その場合、ボードのLEDは点いてもPCにポートが現れず、書き込みまで進みません。
筆者の講座でも、ボード不良だと思っていたらケーブル交換だけで通った例が何度もあります。
ここがポイントで、USBケーブルは「挿さるか」ではなく「データ通信できるか」で見ます。

Wi‑Fi側は2.4GHz帯を前提にすると話が早いです。
ESP32の入門例やWiFi.hのサンプルもこの前提で進むことが多く、まず接続確認だけを狙う段階では、2.4GHzのSSIDとパスワードを手元に置いておくと作業が止まりません。

Arduino IDEでESP32ボードを追加する

準備ができたら、Arduino IDE 2.xへESP32用のボード定義を入れます。
ここで入れるのはボードそのものではなく、ArduinoからESP32へ書き込むための開発環境です。
Arduino IDE 2.xにはBoards Managerがあり、ESP32のようなサードパーティ製ボードは追加のURLを登録してから導入する流れになります。

手順は次の順です。

Arduino IDE 2.xを開く
環境設定で「追加のボードマネージャのURL」にESP32用のJSONを追加する
Boards Managerで esp32 と検索する
esp32 by Espressif Systemsをインストールする

また、公式のホスティング例としては https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json のほか、https://espressif.github.io/arduino-esp32/package_esp32_index.json も広く使われています。
どちらかの URL を「追加のボードマネージャのURL」に登録してから Boards Manager で 'esp32' を検索してインストールしてください。
この作業が終わると、WiFi.hを含むESP32向けの基本ライブラリも使える状態になります。
つまり、この段階でArduino側の「ESP32へWi‑Fi接続スケッチを書き込む土台」が整います。

ボード・ポートの選択と書き込み時の注意

ボード追加の次は、実機に合わせてツールメニューを整えます。
定番のESP32-WROOM-32搭載ボードやDevKitC系なら、まずESP32 Dev Moduleを選ぶ流れで通ることが多いです。
ESP32-S3系では、そのボード名に合った項目を選びます。
ここを別物にすると、書き込みは通っても挙動が合わないことがあります。

続いて見るのがポートです。
USB接続後にCOMや /dev/tty 系のポートが現れていれば、PC側はボードを認識しています。
ポートが何も出ないときは、まずケーブル、その次にUSB‑シリアル変換チップのドライバを疑うと切り分けが進みます。
『CP210x』系なら『Silicon Labs』のVCPドライバ、CH340系ならCH340用ドライバが関係する場面があります。
ボード上のチップ刻印が読めると、ここで迷いません。

シリアルモニタのボーレートは、入門用スケッチでは115200を起点にすると揃えやすいです。
Wi‑Fi接続の成否やIPアドレス表示も、この設定で読める例が多く、書き込み直後の確認がスムーズです。

書き込みで止まりやすいのは、ドライバ以外では電源不足、USBケーブル不良、USBハブ経由の不安定さです。
PC本体のUSB端子へ直結すると改善する場面があります。
もうひとつ見逃せないのがBOOTとENの扱いです。
ESP32はリセット時のGPIO0状態でブートモードが決まり、GPIO0をLOWにした状態で起動するとシリアル書き込みモードへ入ります。
自動書き込み回路が素直に動くボードなら意識しなくて済みますが、初回だけ入りにくい個体はあります。

筆者がメイカースペースの教室で受講者のボードを並べて見ていると、同じ手順でも1台だけ書き込みに入らないことがあります。
そんなときは、USB接続のあとBOOTを押したまま書き込み開始を待ち、転送が走り出したところで離すと通る場面がありました。
押しても反応がないときはENで一度リセットを入れてから再度試すと、ブートローダへ切り替わることがあります。
現場ではこの操作で詰まりが解けることがあり、特に最初の1回で成功率が上がります。

TIP

書き込み失敗が続くときは、ボード設定を何度も変える前に、ポート認識、データ対応USBケーブル、USB‑シリアルドライバ、BOOTとENの順で見直すと原因が絞れます。

ここまで整うと、次はWi‑Fi接続用のスケッチを書いて、SSIDとパスワードを入れて試せる状態です。

ESP32をWi‑Fiに接続する手順

Step 1：スケッチ作成と資格情報の入力

ここでは、まずWiFi.hを使って、SSIDとパスワードでESP32を無線LANへ参加させる最小構成のスケッチを作ります。
単に WiFi.begin() を呼ぶだけでも接続は試せますが、入門段階ほどどこで止まったか見える形にしておくと、原因の切り分けが一気に進みます。
筆者の経験では、シリアルへ接続進捗を細かく出すだけで、現場で「認証前で止まっているのか」「接続待ちが長いのか」「タイムアウトなのか」をすぐ拾えるようになります。

以下のコードは、接続リトライ、タイムアウト、失敗時の状態表示まで入れた基本形です。ボードは前の手順で選んだESP32系のまま使えます。

#include <WiFi.h>

const char* WIFI_SSID = "あなたのSSID";
const char* WIFI_PASS = "あなたのパスワード";

const unsigned long WIFI_TIMEOUT_MS = 20000;
const unsigned long RETRY_WAIT_MS = 3000;
const int MAX_RETRY = 3;

const char* wifiStatusToString(wl_status_t status) {
  switch (status) {
    case WL_IDLE_STATUS:       return "WL_IDLE_STATUS";
    case WL_NO_SSID_AVAIL:     return "WL_NO_SSID_AVAIL";
    case WL_CONNECTION_LOST:   return "WL_CONNECTION_LOST";
    case WL_DISCONNECTED:      return "WL_DISCONNECTED";
    default:                   return "UNKNOWN_STATUS";
  }

bool connectWiFi() {
  WiFi.mode(WIFI_STA);
  // デバッグ用途で省電力を一時的に切ると改善する場合がある（環境依存）。
  WiFi.setSleep(false);

  for (int attempt = 1; attempt <= MAX_RETRY; attempt++) {
    Serial.println();
    Serial.print("Wi‑Fi接続開始 SSID: ");
    Serial.println(WIFI_SSID);
    Serial.print("試行回数: ");
    Serial.print(attempt);
    Serial.print(" / ");
    Serial.println(MAX_RETRY);

    WiFi.disconnect(true, true);
    delay(500);

    WiFi.begin(WIFI_SSID, WIFI_PASS);

    unsigned long startTime = millis();
    wl_status_t lastStatus = WiFi.status();

    Serial.print("接続待機中");

    while (millis() - startTime < WIFI_TIMEOUT_MS) {
      wl_status_t currentStatus = WiFi.status();

      if (currentStatus != lastStatus) {
        Serial.println();
        Serial.print("状態変化: ");
        Serial.println(wifiStatusToString(currentStatus));
        lastStatus = currentStatus;
      }

      if (currentStatus == WL_CONNECTED) {
        Serial.println();
        Serial.println("Wi‑Fi接続成功");
        return true;
      }

      Serial.print(".");
      delay(500);
    }

    Serial.println();
    Serial.println("タイムアウト: 指定時間内に接続できませんでした");
    Serial.print("最終状態: ");
    Serial.println(wifiStatusToString(WiFi.status()));

    if (attempt < MAX_RETRY) {
      Serial.print("再試行まで待機 ");
      Serial.print(RETRY_WAIT_MS);
      Serial.println(" ms");
      delay(RETRY_WAIT_MS);
    }

  return false;
}

void setup() {
  Serial.begin(115200);
  delay(1000);

  Serial.println();
  Serial.println("ESP32 Wi‑Fi接続テスト開始");

  bool connected = connectWiFi();

  if (!connected) {
    Serial.println("Wi‑Fi接続失敗");
    Serial.println("原因候補: SSID/パスワード誤り、2.4GHz以外のAP、電波不足、AP設定");
  }

void loop() {
  if (WiFi.status() != WL_CONNECTED) {
    Serial.println("接続が切れました。再接続を試みます");
    connectWiFi();
  }

  delay(5000);
}

書き込みが終わったら、Arduino IDEのシリアルモニタを開き、ボーレートをスケッチと同じ 115200 に合わせます。
ここで見るべきなのは、単に「つながったかどうか」だけではなく、WiFi.status() がどの状態を返しているかです。
WiFi.hでは WL_CONNECTED が接続完了を示し、接続できないときは別の状態値が返ります。

このスケッチでは、接続処理の流れを次の順で追えるようにしてあります。

ステーションモードへ切り替える
前回の接続情報をいったん切る
WiFi.begin(SSID, PASS) で接続開始
一定時間 WiFi.status() を監視する
接続成功なら終了、失敗なら待機して再試行する

単発の接続コードだと、失敗したときに「何も起きない」ように見えることがあります。
現場では、シリアルにドットを出すだけでも生きている処理かどうかが分かりますし、状態変化を併記すると認証段階なのかアクセスポイント探索段階なのかが見えます。
筆者はワークショップでもこの形をよく使いますが、受講者のボードを順番に見て回るとき、ログが細かい個体ほど対処が早くなります。
止まる場所が分かるだけで、見るべき項目が一気に絞れるからです。

もし接続後にアプリケーション側の処理を追加するなら、loop() の中でも WiFi.status() を監視し、切断時に再接続する形が基本になります。
センサーデータ送信や簡易Webサーバー化へ進む前に、まずこの再接続の骨格を入れておくと、途中で無線が切れたときの挙動が読みやすくなります。

TIP

接続テストの段階では、センサー読取りやHTTP通信を一緒に詰め込まず、まず WiFi.begin と WiFi.status の確認だけに絞ると、無線設定の問題とアプリ側の問題が混ざりません。

Step 3：IPアドレスの表示とネットワーク確認

Wi‑Fi接続が通ったら、次に見るのはESP32へ割り当てられたIPアドレスです。WiFi.localIP() を表示すると、同じネットワーク内の端末からそのESP32を見つけやすくなります。
セットアップ完了時に次のような表示を追加しておくと、接続確認の精度が上がります。

if (WiFi.status() == WL_CONNECTED) { Serial.print("接続状態: "); Serial.println(wifiStatusToString(WiFi.status())); Serial.print("IPアドレス: "); Serial.println(WiFi.localIP()); } シリアルモニタで WL_CONNECTED と IP アドレスが表示されたら、ESP32 はルータからアドレスを受け取っています。
PC からの確認は、同一ネットワーク内の端末で ping を打つか、簡易的にESP32側で HTTP サーバーを立ててブラウザからアクセスして応答を確認するのが基本です。
HTTP サーバーの実装は次のステップで扱います。

なお、IPアドレスが表示されたのにPCから見えない場合は、ESP32本体のWi‑Fi接続より、ルータ側のネットワーク設定を疑う場面が増えます。
後のチェックリストで触れるAP分離設定などがここで効いてきます。

接続できないときの切り分けチェックリスト

接続に失敗したときは、コードを書き換える前に、止まっている場所に応じて項目を分けて見ます。ESP32の無線接続で詰まりやすい点は、だいたい決まっています。

ESP32は2.4GHz帯のアクセスポイントで使う
ESP32の基本的な接続先は2.4GHzです。
家庭用ルータで同じSSID名を2.4GHzと5GHzで共用していると、スマホやPCはつながっていてもESP32だけ参加できない場面があります。
接続テストでは2.4GHz側のSSIDを明示して使うと、ここで迷いません。
SSIDとパスワードの文字列をそのまま見直す
接続失敗の原因として最も多いのは入力ミスです。
コピーしたつもりでも、前後に空白が入っていたり、記号が別文字になっていたりします。
シリアルログで WL_CONNECT_FAILED が続くなら、まずここを疑うと流れが早いです。
MACフィルタやステルスSSIDの有無を確認する
ルータ側で接続端末を制限していると、正しい資格情報でも参加できません。
SSIDを非表示にしている構成では、通常の接続確認より切り分けの手数が増えます。
まずは制限の少ない通常SSIDで接続可否を確かめたほうが、問題点が絞れます。
ルータのAP分離設定を疑う
ESP32にIPが出ているのに、PCやスマホから ping やHTTPで届かないときは、AP分離設定が効いていることがあります。
これが有効だと、同じ無線LANに見えても端末同士が直接通信できません。
簡易Webアクセスの確認でここが表面化します。
チャネル幅やアクセスポイント設定を見直す
無線LANの設定が強めに最適化されている環境では、初回接続テストだけ不安定になることがあります。
ESP32単体の問題というより、アクセスポイント側の設定と噛み合っていないケースです。
接続ログが進むのに安定しないときは、この層を見ます。
電波強度と距離を詰める
書き込み机の上では動くのに、設置場所へ持っていくと切れやすいことがあります。
ESP32の小型ボードは置き方の影響を受けやすく、ルータから距離がある場所や遮蔽物の多い場所では、接続と切断を繰り返すことがあります。
省電力モードの影響を切り分ける
接続は通るのにその後しばらくすると不安定になる場合は、テストとして WiFi.setSleep(false); を試す価値があります。
効果はモジュールやアクセスポイント、コアバージョンに依存するため、改善が確認できたら省電力を再検討してください（公式ドキュメントや使用しているコアのIssueも参照すると安心です）。
アンテナの向きや金属筐体との干渉を見る
ケースへ入れた途端に通信が不安定になることがあります。
金属ケースの内側や、アンテナ部分の近くに金属板が来る配置では、机上テストと結果が変わります。
基板の端にあるアンテナパターン周辺を覆っていないかは、実機で差が出るところです。

この段階でのコツは、一度に複数の条件を変えないことです。
SSIDを変え、ルータも変え、コードも変えると、どれで直ったのか分からなくなります。
シリアルログに進捗を出しておけば、「見つからない」「認証で落ちる」「つながったのに見えない」を分けて追えるので、切り分けが短時間で済みます。
次のステップでは、この接続済みの状態を土台にして、HTTPやMQTTなどの通信処理を積み上げていけます。

IoTらしい使い方へ進む3つの道

Webサーバー：LAN内の可視化・操作

Wi‑Fi接続まで通ったら、次に手を伸ばしやすいのがWebサーバーです。
ESP32側でHTTPサーバーを動かして、同じLANにいるPCやスマホのブラウザから状態を見る形です。
たとえば温度センサーの値をページに表示したり、ボタンを置いてLEDを点灯・消灯したりできます。
前のセクションで触れたIPアドレス確認の延長線上にあるので、「つながった先で何ができるか」を最短で実感できます。

この方式が向くのは、少数のデバイスを手元のネットワークで扱う場面です。
机の上の試作機をブラウザで開いて、GPIOの出力を切り替える、センサー値を更新表示する、といった“見える化”にはちょうどよい構成です。
Arduino IDEで書いたスケッチの結果が、そのままブラウザ画面に出るので、ワークショップでも反応が伝わりやすく、受講者が「通信できている」を腹落ちしやすい段階でもあります。

筆者の経験では、最初の1台か2台ならWebサーバーから入る流れがいちばん自然です。
ブラウザを開けば動作が見えるので、センサーの値とLEDの反応を一画面で確認できます。
台数が少ないうちは、どの端末がどのIPかも追えますし、デバッグ中に「今この基板は生きているか」を確かめる用途にも向きます。
IoTの入口としては、ネットワーク越しの入出力を目で見て理解できる点が大きいです。

一方で、台数が増えると管理の負担が前に出てきます。
各デバイスに個別のWeb画面があり、それぞれのIPへアクセスする運用になるからです。
5台、10台と増えると、見る先が分散し、複数デバイスの値を一括で集める仕組みも別途ほしくなります。
筆者は小規模な試作ではWebサーバーから始めて、センサーが増え始めた段階で『MQTT』へ移ることが多いのですが、この切り替えは運用の流れとして無理がありません。
まずは見える形で1台を動かし、その後で集約へ進むと理解がつながります。

MQTT：スケーラブルなPub/Sub

複数のESP32をまとめて扱いたくなったら、『MQTT』が本命になります。
『MQTT』はブローカーを中心にしたPub/Sub方式で、送信側はトピックへ発行し、受信側はそのトピックを購読します。
センサー側は「どの画面に表示されるか」を知らなくてもデータを送れますし、表示側や制御側も「どの端末から来たか」を細かく意識せず購読できます。
1対1ではなく、1対多・多対多へ広げやすいのが強みです。

たとえば、温湿度センサーを各部屋に置いて home/living/temperature や home/bedroom/humidity のようなトピックへ送ると、ダッシュボード、記録システム、自動制御の3者が同じデータを受け取れます。
スマートホーム連携ではHome Assistantと相性がよく、個別のHTTP画面を増やすより構成が整理されます。
『EMQX』のTLSドキュメントでは、MQTT over TLSを前提にした設定例や、TLS 1.2 / 1.3のサポートが示されており、LAN外へまたぐ構成や認証を伴う運用では、平文のまま置かない設計へ進みやすくなっています。

ESP32側のArduino系ライブラリではPubSubClientが定番ですが、ここは初心者が一度つまずきやすいところでもあります。
GitHubのPubSubClientではデフォルトの最大メッセージサイズが256バイトです。
小さな数値を送るだけなら十分でも、JSONを欲張って詰め込むとすぐ上限に当たります。
筆者も最初のころ、状態をまとめて1つのJSONで送ろうとして、想像より早く窮屈さを感じました。
IoTでは「小さく刻んで流す」ほうが扱いやすいことが多く、トピック設計を分ける発想に切り替えると構成が整います。

TLSにも少し目を向けたいところです。
ESP32のWiFiClientSecureはmbedTLSを土台にしていますが、PC向けのクライアントと同じ感覚で証明書まわりを全部任せると、実装の前提がずれます。
実運用では、LAN内の試作は平文MQTTで先に流れを作り、外部ネットワークへ出す段階でMQTT over TLSへ切り替えると整理しやすくなります。
暗号化そのものより、証明書の置き方、更新、検証方法まで含めて設計が必要になるためです。

Webサーバーと『MQTT』の境目は、「誰が見に行くか」と「何台あるか」で考えると判断しやすくなります。
1台のESP32にブラウザでアクセスして、その場でON/OFFしたいならWebサーバーが素直です。
複数センサーの値を集めたい、別のシステムにも配りたい、あとから監視画面を足したいなら『MQTT』のほうが伸びます。
最初の試作はWebサーバー、2台目以降で「まとめて見たい」が出てきたら『MQTT』へ進むと、段階ごとの理解が崩れません。

OTA：現地での無停止更新

設置後の運用まで考え始めると、OTAが効いてきます。
OTAはOver The Airの略で、USBケーブルをつながずにWi‑Fi経由でスケッチを書き換える方法です。
天井近く、棚の裏、ケースの中など、物理的に触りにくい場所へ置いたESP32では、この差がそのまま保守の手間になります。
試作中はUSB書き込みでも進みますが、常設に近づくほどOTAのありがたみが出ます。

ESP32のOTAでは、一般に2つのアプリ領域を使う構成がよく使われます。
いわゆる app0 と app1 に相当するスロットを用意し、現在動いていない側へ新しいファームウェアを書き込み、再起動後に切り替える流れです。
現場感覚で言うと、「今動いているものを残したまま次を準備できる」ため、更新時の安心感が大きく違います。

注意点もあります。
まず、フラッシュのパーティション構成をOTA前提で選んでおかないと、アプリ領域が足りず更新できません。
次に、更新中に電源が不安定だと失敗の原因になります。
さらに、LAN内の試作段階では便利でも、外部から更新できる構成へ広げるなら認証と通信経路の保護が欠かせません。
ここが。
OTAは「書き込みが楽になる機能」ではありますが、同時に「遠隔から書き換えられる入口」でもあります。
更新機能を有効にしたまま認証を弱く置くと、運用面での負担が別の形で増えます。

Webサーバー『MQTT』OTAのどれを次に選ぶか迷ったら、次の4点で振り分けると筋道が見えます。

まず1台を見える形で動かしたい
ブラウザで状態表示やLED制御を行うWebサーバーが合います。LAN内で完結し、通信の流れを目で追えます。
複数台のデータを集めたい
ブローカー経由で集約できる『MQTT』が合います。Home Assistant連携や、複数画面への配信まで視野に入ります。
設置後も更新が続く
USBを抜き差しせずに改修を重ねられるOTAが合います。棚の上やケース内など、触りにくい場所で差が出ます。
LAN外や共有ネットワークも視野に入る
MQTT over TLSや、認証つきのOTAを優先して考える段階です。通信経路の暗号化だけでなく、証明書や更新権限まで設計対象になります。

この3つは排他的ではなく、順番に積み上げるものです。
最初はWebサーバーで1台を見える化し、増えてきたら『MQTT』で集約し、置き場所が固定されてきたらOTAで保守を軽くする。
この流れが、ESP32を「Wi‑Fiにつながるマイコン」から「IoTの部品」へ進めるときの、いちばん無理のない進み方です。

Wi‑Fi情報を埋め込まない設定方法

なぜハードコードを避けるべきか

ESP32を最初に触るときは、WiFi.begin("SSID", "PASSWORD") の形でスケッチに直接書く方法がいちばん早く動きます。
ただ、常設や配布を考え始めると、この書き方がすぐに足を引っ張ります。
設置先ごとにSSIDが違う、ルーター交換でパスワードが変わる、2.4GHz側のネットワーク名だけ変えた、といった場面で、毎回PCを出して書き換え、再書き込みする流れになるからです。
1台なら我慢できますが、台数が増えるほど「ネットワーク変更のたびにファーム更新」という設計そのものが重荷になります。

ここで考えたいのは、Wi‑Fi接続をコードの一部ではなく、運用時に差し替える設定値として扱うことです。
SSIDとパスワードを本体の設定領域に保存し、初回だけ入力、変更時だけ再設定という形にしておけば、現地の事情に合わせて動かせます。
筆者がワークショップや小規模な設置案件で見てきた範囲でも、つまずきの多くはプログラムそのものより「置く場所のネットワーク事情」にありました。
家庭ではルーターの買い替え、現場ではアクセスポイントの更新が起きるので、Wi‑Fi情報を埋め込まないだけで保守の流れが整います。

もうひとつ見落としにくいのが、スケッチの配布や共有です。
サンプルコードをそのまま渡したい場面では、認証情報がコードに入っていると扱いづらくなります。
Arduino IDE 2.x ではBoards Manager経由でESP32 by Espressif Systemsを追加でき、サンプルの試行も進めやすいのですが、試作段階の書き方をそのまま運用へ持ち込むと、設定変更のたびに開発者向けの作業が残ります。
Arduino IDE 2.xの導入手順やBoards Managerの流れはArduino系のチュートリアルでも整理されていますが、設定値を外へ出す発想まで持っておくと、その先の運用で差が出ます。

BLEプロビジョニング

BLEプロビジョニングは、スマートフォンとESP32をBluetooth Low Energyでつなぎ、アプリ側からSSIDとパスワードを渡す方式です。
家庭向けのIoT機器でよく採られる流れで、ユーザーはスマホアプリで機器を見つけ、表示されたWi‑Fi一覧から自宅のネットワークを選んで設定します。
ブラウザに手動でIPアドレスを入れる必要がなく、接続先の切り替えもアプリの画面にまとめやすいので、導入時の迷いが少なくなります。

ESP32はBluetooth機能を持つため、この方式をArduino環境でも組み込みやすい部類です。
BLEプロビジョニングの考え方やArduinoでの実装例は、Random Nerd TutorialsのESP32 BLE Wi‑Fi Provisioningが全体像をつかむ入口になります。
実装では、受け取った認証情報を不揮発領域へ保存します。
次回起動時は自動接続し、失敗時だけ再プロビジョニングへ戻す構成にすると流れが安定します。

この方式の良さは、現場で「設定用の専用画面に確実に入れる」点です。
SoftAP方式だと、スマホが元のWi‑Fiやモバイル通信へ戻ってしまい、設定ページを開く前に通信先が切り替わることがあります。
BLEなら設定通信そのものがWi‑Fiとは別経路なので、利用者が今どのネットワークにつながっているかを意識しなくて済みます。
筆者の経験でも、家庭内の初期設定はSoftAPで数分のうちに終わるケースが多い一方、設置場所が広かったり、利用者の端末設定を細かく案内しにくかったりする現場では、BLEのほうが段取りを崩しませんでした。

一方で、BLEはアプリ側の用意まで含めると開発項目が増えます。
自作アプリで作り込む道もありますし、ESP32向けの公式系サンプルやコミュニティ実装を土台にする方法もありますが、Web画面だけで済む方式より構成はひとつ増えます。
家庭向け製品のように「箱から出して迷わずつながる」体験を優先するなら相性がよく、配布台数が増えるほど、その価値が見えてきます。

SoftAPプロビジョニング

SoftAPプロビジョニングは、ESP32自身を一時的なアクセスポイントとして起動し、スマホやPCをそこへ接続してブラウザで設定ページを開く方式です。
専用アプリが不要で、最初の導入コストが低いのが魅力です。
Arduinoで始めるなら、まずこの方式から入るのが現実的です。
WiFi.hだけでも構成できますし、Web設定画面までまとめて使いたいならWiFiManager系のライブラリが定番です。
tzapu/WiFiManagerはもともとESP向けの代表的なプロビジョニングライブラリで、ESP32でも使われています。

SoftAP方式の流れは素直です。
初回起動または接続失敗時にESP32が設定用SSIDを出し、ユーザーがそこへ接続し、ブラウザでSSIDとパスワードを入力します。
保存後は本来の家庭内Wi‑Fiへ接続し直すだけです。
導入説明も短く済みやすく、スマホ1台で完結しやすいので、試作から小規模運用まで一気に持っていけます。
自宅で使う温湿度計や通知機器のような用途なら、この方式で初期設定が短時間で終わる場面が多く、配布用の試作でも説明書きを増やさず進められました。

TIP

SoftAPは「まず動かす」段階と相性がよく、BLEは「設定体験を整える」段階で効いてきます。
試作の1台目はSoftAP、複数配布や現場設置で案内コストが目立ってきたらBLE、という順番だと設計の無駄が出にくくなります。

実装の入口としては、Arduino IDEのFile > Examples内にあるWi‑Fi系サンプルと、ESP32 by Espressif Systemsのコアを入れた環境が基本になります。
ボード追加はpackage_esp32_index.jsonを使ってBoards Managerから導入する流れが一般的で、パッケージの公開先として raw.githubusercontent.com 上のpackage_esp32_index.jsonが広く使われています。
そこからESP32 Dev Moduleを選び、最初はシンプルなアクセスポイント＋Webフォームの構成で試すと、全体像がつかみやすくなります。

BLEとSoftAPの比較表

どちらを選ぶかは、実装の難しさだけでなく、現場で誰が設定するのかまで含めて決まります。比較の軸をそろえると、判断がぶれません。

項目	BLEプロビジョニング	SoftAPプロビジョニング
初期体験	スマホアプリ内で完結させやすく、設定導線を一画面に集約しやすい	ブラウザで設定でき、アプリ不要で始められる
セキュリティ	Wi‑Fi資格情報をBLE経由で渡す構成を組める	設定用APとWeb画面の設計次第で保護内容が決まる
実装難度	本体側に加えてアプリまたは相当する操作導線が必要	ArduinoのWebサンプルやWiFiManager系から入りやすい
再設定手順	アプリから再設定画面へ戻しやすい	本体を設定モードに戻してAPへ接続し直す流れが基本
現場要件	案内の統一や確実な再設定が求められる場面に向く	家庭内の初回設定や少人数での導入に向く

実際のロードマップとしては、最初の試作ではSoftAPが扱いやすい選択です。
アプリを作らずに済み、失敗しても原因を追いやすいからです。
そこから台数が増えたり、利用者に設定手順をなるべく意識させたくなくなったりした段階で、BLEへ広げると設計が自然につながります。
ESP32 Product OverviewとしてまとまっているEspressifの情報でも、ESP32ファミリーがWi‑FiとBluetoothを併せ持つ点は、この手の構成を取りやすい理由のひとつです。
Arduinoでの入口はSoftAP、配布や運用の密度が上がったらBLEという順番が、実務でも無理の少ない進め方です。

セキュリティと運用で最低限やっておきたいこと

TLSとMQTT over TLS

ESP32で外に向けて通信するなら、まず整えたいのはTLSです。
HTTPならHTTPS、MQTTならMQTT over TLSを前提にすると、同じネットワーク上で通信内容をのぞかれたり、平文の認証情報を拾われたりする事故を減らせます。
『EMQX』のドキュメントではTLS接続を前提にしたMQTT設定が整理されており、ブローカー側でもTLS 1.2やTLS 1.3を使う構成が一般的です。
IoT機器は一度置いたあと長く動かすことが多いので、最初の試作段階から平文通信を常態化させないほうが、後で公開環境へ持っていくときの修正範囲が小さく収まります。

Arduino系の作例では、まずPubSubClientでMQTT接続を通し、そのあとTLS化する流れを見かけます。
ただ、筆者の経験ではここを後回しにすると、接続先URL、証明書、時刻同期、再接続処理までまとめて触ることになり、試作の勢いがいったん止まりました。
最初から全部の機能を盛るより、TLSとOTAを先に通しておくほうが、運用段階での手戻りが少なく済みます。
センサー追加やUI改善はあとからでも積みやすい一方、通信路の保護は土台なので、後付けにすると影響範囲が広がるからです。

証明書の扱いは、最初は「何を信頼するか」を絞るところから始めると整理できます。
基本線は、デバイス側に信頼するCA証明書を持たせ、接続先サーバ証明書を検証する方法です。
自己署名証明書を試験用に使うこともありますが、本番と同じ癖で運用したいなら、配布する証明書を固定し、更新時の入れ替え方法まで考えておくほうが後で困りません。
ESP-IDF Get StartedにつながるEspressifの公式資料群でも、ESP32のTLS基盤はmbedTLSで構成されており、証明書検証を前提に組み込める土台があります。

ここで気をつけたいのは、「TLSを使った」ことと「十分に検証できている」ことは同じではない点です。
ESP32のWiFiClientSecureは便利ですが、PC向けのブラウザのように何でも自動で厳密に面倒を見てくれるわけではありません。
証明書チェーンや失効確認まで重くすると、組み込み機では負担が増えます。
初心者の段階では、接続先を限定し、信頼するCAまたはサーバ証明書を明示してMQTT over TLSを成立させるところまでを最初の到達点に据えると、設計の軸がぶれません。

OTAの安全な運用

OTAは便利ですが、更新できるということは、更新経路を悪用される余地も生まれるということです。
そのため「無線で書き換えられるようにした」で終わらせず、署名付きバイナリと失敗時に戻せる構成をセットで考える必要があります。
OTAの基本構成はESP32 OTA UpdatesやESP32 OTAの基本を徹底解説のような解説でも整理されていますが、実務で効くのは app0 / app1 のように2つのアプリ領域を持たせる発想です。
いま動いている領域とは別のスロットへ新しいファームウェアを書き込み、起動確認が取れたら切り替える形なら、更新途中の電断や破損で本体が起動不能になる場面を減らせます。

この二重化で見落としやすいのが、更新失敗時のロールバック条件です。
単に「新しいほうを起動する」だけだと、起動直後に異常が起きた場合に戻れません。
一定時間内に正常起動のフラグを立てる、サーバ到達や主要機能の初期化完了を確認してから更新完了扱いにする、といった運用ルールを持たせると、現場での復旧負荷が下がります。
筆者はこの部分を後回しにした試作で、通信処理だけ通っても本番相当の再起動試験で詰まったことがありました。
OTAは書き込み成功だけでなく、起動成功まで含めて更新です。

安全面では、配信元をTLSで守るだけでなく、受け取ったバイナリが正しいものかを署名確認で判断する流れが基本です。
通信経路が暗号化されていても、更新ファイルそのものの正当性を確認しない構成では、配信経路や保管場所の事故に弱くなります。
公開しても困りにくい設計に寄せるなら、OTAファイルは署名付きにし、デバイス側で検証してから切り替える流れを早めに入れておくほうが堅実です。

WARNING

OTAは「更新できるか」より「失敗しても元に戻れるか」で評価すると設計の優先順位が見えます。
app0 / app1 の二重化と署名確認が入るだけで、試作機のまま運用へ流れ込む事故を減らせます。

Secure Boot / Flash Encryptionの要点

デバイス側の保護として名前がよく挙がるのがSecure BootとFlash Encryptionです。
どちらもESP32で使える代表的な保護機能ですが、役割は別です。
Secure Bootは、起動しようとしているファームウェアが正規のものかを検証し、改ざんされたアプリを起動しないための仕組みです。
Flash Encryptionは、フラッシュ上の内容を暗号化して保存し、外部から読み出されてもそのままでは意味が取れない状態にする仕組みです。

初心者がまず押さえたいのは、これらが「泥棒対策の鍵」のようなものだという点です。
たとえばWi‑FiのSSIDやパスワード、MQTTの認証情報、APIキーをフラッシュへ平文で保存していると、基板に触れられた時点で守りが薄くなります。
設定情報を保存する必要があるとしても、平文のまま置かない設計へ寄せるほうが安全です。
Secure Bootは不正なファームウェアの起動防止、Flash Encryptionは保存データの秘匿化と覚えると、役割が混ざりません。

導入難易度は、TLSやOTAより一段上がります。
理由は、鍵の管理や書き込み手順、量産時のフローまで絡むからです。
いったん有効化すると開発中の書き換え手順も変わるため、Lチカ直後の段階で無理に全部入れるより、通信保護と安全なOTAを先に固め、その次の段階でSecure BootとFlash Encryptionへ進むほうが流れとして自然です。
ただし、公開用途や配布用途を見据えるなら、この2つを「高度なオプション」と片付けないほうがよく、少なくとも概念だけは早い段階で把握しておく価値があります。

初心者向け：優先順位チェックリスト

全部を一度に入れようとすると、学習コストより設定ミスが先に増えます。
そこで初心者向けには、運用で効く順に段階導入する考え方が向いています。
筆者がワークショップや試作で崩れにくかった順番は、次の4段階です。

パスワードをソースコードにハードコードしない
まず外したいのは、SSID、Wi‑Fiパスワード、MQTTユーザー名、APIキーをスケッチへ直接書き込む運用です。
配布時の差し替え漏れ、Gitへの誤コミット、再設定時の再ビルドが重なると、管理のほうが先に破綻します。
前述のプロビジョニング方式や外部設定保存を使い、資格情報をコードから切り離すだけでも事故の入口が減ります。
パスワード管理は少なくとも環境分離する
開発用と本番用で同じ認証情報を使い回さない、テスト用ブローカーと公開用ブローカーを分ける、といった環境分離を入れます。
これだけでも、試験機の設定がそのまま本番へ残る事態を避けやすくなります。
小規模な試作でも、この線引きがあるだけで後の整理が楽になります。
MQTT over TLSを導入する
MQTTを使うなら、平文接続のまま広げないことが次の壁です。
最初は接続先を1つに絞り、証明書を明示してTLSでつなぐ構成にすると、あとで台数が増えても設計が散らかりません。
通信の暗号化は派手な機能ではありませんが、公開環境で困る要因を静かに減らしてくれます。
OTAで署名確認を入れる
OTAが通るようになった段階で満足しがちですが、運用ではここが分かれ目です。
更新ファイルの署名を確認してから切り替える流れを追加すると、「更新できるけれど誰の更新でも通る」状態から抜け出せます。
app0 / app1 の二重化と組み合わせると、失敗時の戻し先も確保できます。

この順番の狙いは、最初に土台を固めることです。
センサーを増やしたり、表示を整えたり、通知先を増やしたりする作業は後から積み上げられます。
一方で、TLSとOTAが未整備のまま運用へ進むと、あとで全部の通信経路と更新経路を洗い直すことになります。
筆者の現場感としても、最初の1台でそこを整えておくほうが、台数が増えたときの修正量が明らかに小さくなります。

ここまで進めば、Arduino IDEでESP32を認識させて、自宅Wi‑Fiへつなぎ、IPアドレスが見えるところまで到達できています。
まず確認したいのは、通信できる1台を確実に作れたかどうかです。
筆者の経験では、最初の1台を安定させてから2台目以降で『MQTT』やOTAの型に乗せる流れのほうが、設定漏れと切り分けの手戻りが減ります。
次は、通知や連携を優先するなら『MQTT』、更新作業を軽くしたいならOTAを選ぶ段階です。
常設まで見据えるなら、プロビジョニングとTLSもこの延長線上で考えると迷いません。

NOTE