はじめに

ESP-IDF v6.1 が 2026年8月27日にリリースされました。

リリースノートの書き出しはこうです。

ESP-IDF v6.1 is a minor update for ESP-IDF v6.0. Release v6.1 is mostly compatible with apps written for ESP-IDF v6.0.

「minor アップデート」で「おおむね互換」。ところが同じリリースノートの Breaking Changes には、17件 が並んでいます。

この記事は、その17件を眺めて終わりにしません。6.0 から上げる人が、実際に踏む順に並べ直します。 最初に当たるのはほぼ確実に MQTT です。そしてリリースノートには載っていないのに、日々の作業をいちばん変える変更が移行ガイド側に2件あります。

🗓️ リリース日は API で機械確認

公開日は GitHub の Releases API で確認しました。

curl -s https://api.github.com/repos/espressif/esp-idf/releases/tags/v6.1

"published_at": "2026-08-27T01:56:12Z" 。本記事の日付はこの値に基づきます。

🧭 1. 前提の整理

1-1. minor リリースの互換性ポリシー — 本来は「コードの変更は不要」

ESP-IDF はセマンティックバージョニングを採用しています。公式ドキュメントは minor リリースをこう定義しています。

Minor Releases like v3.1 add new functionality and fix bugs but will not change or remove documented functionality, or make incompatible changes to public APIs.

（minor リリースは機能追加とバグ修正を行うが、文書化された機能を変更・削除したり、公開 API に非互換な変更を加えたりはしない）

さらに続けて、「your project’s code does not require updating, but you should re-test your project」（プロジェクトのコードを更新する必要はないが、再テストはすべき）と書かれています。

これが v6.1 の Breaking Changes 17件と噛み合っていません。API の改名も、マクロの削除も、ヘッダの非公開化も入っています。

⚠️ どう読むのが実務的か

バージョン番号の桁を見て安心しないことです。minor か major かではなく、Breaking Changes のリストを読むのが唯一の判定方法 になります。

なお Espressif が黙って壊しているわけではありません。リリースノートは「mostly compatible」と留保をつけ、17件を明示的に列挙し、移行ガイドへのリンクも冒頭に置いています。情報は出ている側です。 期待値をバージョン番号から作らず、リストから作ればよい、という話です。

1-2. コンポーネントマネージャとは — 「使う分だけ宣言する」仕組み

ESP-IDF は、機能ごとに切り分けられた コンポーネント を組み合わせてファームウェアを作ります。そのうち 外部から取ってくるもの を扱うのが IDF Component Manager です。配布元が ESP Component Registry（components.espressif.com）で、Espressif 公式の部品置き場にあたります。

使い方はシンプルで、プロジェクトに idf_component.yml（マニフェスト）を置き、依存を書くだけです。コマンドからも足せます。

idf.py add-dependency "espressif/mqtt"
idf.py reconfigure

ビルド時にマネージャがレジストリから取得し、managed_components/ に展開します。バージョンは dependencies.lock に固定されます。

💡 ワード解説：in-tree と レジストリ

in-tree は、ESP-IDF 本体のソースツリーに最初から入っているコンポーネントのことです。何も宣言しなくても REQUIRES に書けば使えます。 レジストリ経由 は、外部から取得するコンポーネントです。idf_component.yml に書かなければ、そもそも存在しません。

この2つの違いが、次の §3 の変更の中身そのものです。

当サイトでは、この仕組みを ESP-IDF 6.0 × ESP32-S3 のレジストリ記事 と 自宅センサー基盤 #2 で実際に手を動かして扱っています。

1-3. 「プレビューサポート」とは — サポート期間の外にある

v6.1 の目玉のひとつが ESP32-S31 のプレビューサポート です。この「プレビュー」には公式の定義があります。

Pre-release versions (betas, previews, -rc and -dev versions, etc) are not covered by any support period. Sometimes a particular feature is marked as “Preview” in a release, which means it is also not covered by the support period.

つまり プレビュー扱いの機能は、そのリリースのサポート期間の対象外 です。バグ修正の保証がある「In Service」の部分とは扱いが違います。試すためのものであって、製品に載せるためのものではない と読むのが正しい距離感です。

📦 2. v6.1 の全体像

リリースノートの各節を数えると、内訳はこうなります。

区分 件数 中身
Major New Features 7件 ESP32-S31 プレビュー、PSRAM 非暗号化領域、Wi-Fi 4件、スリープ保持モジュールの動的着脱
Major Bugfix 1件 JPEG デコーダのセキュリティ修正（後述）
Breaking Changes 17件 周辺ドライバ・セキュリティ・システム
Known Issues 2件 Wi-Fi Aware Pairing と iPhone 17 系、ESP32-C5 と RISC-V ZCMP

自分のプロジェクトに当たるかどうか は、次の順で判定できます。

flowchart TD A["ESP-IDF 6.0 の
既存プロジェクト"] --> B{"MQTT を使っている?"} B -->|使っている| C["espressif/mqtt を
依存に追加（必須）"] B -->|使っていない| D{"LCD・SPI・SPI Flash を
直接叩いている?"} C --> D D -->|叩いている| E["該当 API の変更を
移行ガイドで確認"] D -->|叩いていない| F{"P4・H2・C5 または
Secure Boot を使う?"} E --> F F -->|使う| G["ビルドは通るのに
非互換になる項目あり"] F -->|使わない| H["再ビルドと再テストで
足りる見込み"]

💥 3. 6.0 組が最初に踏むのは MQTT のコンポーネント移管

Breaking Changes の1番目がこれです。

MQTT: The esp-mqtt component was moved to component manager. Add espressif/mqtt to dependencies to use it.

これまで esp-mqtt は in-tree でした。 ESP-IDF を入れれば最初からそこにあり、REQUIRES mqtt と書けば通りました。v6.1 からは レジストリ経由の外部コンポーネント になります。

つまり 宣言しなければ、存在しません。 MQTT を使っているプロジェクトは、v6.1 に上げた時点でビルドが通らなくなります。

3-1. 対処

マニフェストに依存を1行足すだけです。

idf.py add-dependency "espressif/mqtt"
idf.py reconfigure

idf_component.yml を直接書くならこうなります。

dependencies:
  espressif/mqtt: "^1.1.0"

レジストリ上の espressif/mqtt を確認したところ、現在の最新は 1.1.0（2026年7月30日公開）、ライセンスは Apache-2.0 です。依存条件は ESP-IDF v5.3 以降 となっており、6.1 に上げる前の段階でもレジストリ形式へ寄せておける ことになります。

✅ 6.1 へ上げる前にできる準備

espressif/mqtt は ESP-IDF v5.3 以降で使えます。したがって いま 5.x や 6.0 にいるプロジェクトでも、先に依存を明示する形へ移しておけます。 バージョンアップとコンポーネント移管を同時にやると切り分けが難しくなるので、分けて踏むほうが楽です。

なお筆者はこの手順を実機で検証していません。確認は自分の環境で1プロジェクトずつ行ってください。

3-2. 移行ガイドには MQTT の項目が無い

念のため公式の Migration from 6.0 to 6.1 を確認しましたが、この移行ガイドは Peripherals と Tools の2ページだけ で、MQTT の節はありません。

つまり MQTT の変更はリリースノートにしか書かれていません。 移行ガイドだけを読んで上げると、ここで止まります。逆もまた然りで、次の §4 はリリースノートに載っていません。

⚠️ 4. リリースノートに載っていない変更 — 移行ガイド側の2件

移行ガイドにあってリリースノートの Breaking Changes に無い項目が2件あります。片方は毎日の作業に直接効きます。

4-1. idf.py flash の既定が「差分書き込み」になった

これがいちばん体感に来る変更です。移行ガイドの Tools ページより。

ビルドディレクトリに *_flashed.bin（前回の書き込み成功時に作られる）がある場合、idf.py flash は fast reflashing を行うようになりました。変更のあった領域だけを書き込む 挙動です。書き込み後にデバイス上の内容と期待するバイナリを照合し、照合に失敗したときは全体書き込みにフォールバック します。

日常の焼き直しは速くなります。ただし従来どおり全部書きたい場面があります。

idf.py flash -a       # または idf.py flash --all

公式は 新品・空・消去直後のチップを扱うときはこの全体書き込みを推奨 しています。

⚠️ ここは切り分けを間違えやすい

差分書き込みは「速くなる」だけでなく、うまくいかないときの症状が分かりにくくなる 変更でもあります。書き込んだはずの変更が反映されていないように見えたとき、原因の候補に「差分書き込み」が1つ増えます。

照合と自動フォールバックが入っているので通常は救われますが、挙動が変だと思ったらまず idf.py flash -a で全体書き込みを試す のが、いちばん短い切り分けになります。

4-2. UART ウェイクアップ API の刷新

uart_set_wakeup_threshold() と uart_get_wakeup_threshold() が 非推奨 になり、将来のバージョンで削除予定です。これらは RXD エッジ閾値によるウェイクアップ（Mode 0）しか扱えませんでした。

代わりに uart_wakeup_setup() が入り、driver/uart_wakeup.h をインクルードして uart_wakeup_cfg_t で設定する形になりました。対応モードは4つです。

モード 定数 内容
Mode 0 UART_WK_MODE_ACTIVE_THRESH アクティブエッジ閾値（従来 API 相当）
Mode 1 UART_WK_MODE_FIFO_THRESH RX FIFO 閾値
Mode 2 UART_WK_MODE_START_BIT スタートビット検出
Mode 3 UART_WK_MODE_CHAR_SEQ 文字列シーケンス検出

従来 API からの移行は、wakeup_mode に UART_WK_MODE_ACTIVE_THRESH を、rx_edge_threshold に旧 wakeup_threshold と同じ値を入れれば等価です。uart_get_wakeup_threshold() に相当する取得関数は用意されていない ため、設定値が要るなら自分で保持しておく必要があります。

なお、どのモードが使えるかはチップの SOC_UART_WAKEUP_SUPPORT_XXX_MODE に依存します。

🔧 5. 破壊的変更17件 — 自分に当たるかの判定

リリースノートの Breaking Changes を、当たる条件 つきで分類しました。

分類 変更内容 当たる条件
MQTT esp-mqtt がコンポーネントマネージャへ移管 MQTT を使うすべて
周辺ドライバ全般 公開ヘッダから FreeRTOS ヘッダ依存を除去 ドライバのヘッダ経由で FreeRTOS 型を使っていた場合
GPIO gpio_deep_sleep_wakeup_enable/disable → gpio_wakeup_enable/disable_on_hp_periph_powerdown_sleep に改名 ディープスリープ復帰を GPIO で行う場合
GPIO ROM 関数すべてに rom_ 接頭辞を追加 rom/gpio.h を直接叩く場合
GPIO MAX_PAD_GPIO_NUM MAX_GPIO_NUM DIG_IO_HOLD_BIT_SHIFT を削除 これらのマクロを使う場合
LCD RGB / DSI で色変換 API を統一 LCD ドライバを直接使う場合
LCD bits_per_pixel を FourCC ベースの色形式指定へ置換 同上
LCD / DSI use_dma2d フラグを esp_lcd_dpi_panel_enable_dma2d() に置換。2D-DMA 不使用なら バイナリが約10KB 小さくなる MIPI DSI パネルを使う場合
SPI master / slave の初期化で ESP_INTR_FLAG_SHARED を受け付けなくなった 当該フラグを渡している場合
SPI Flash esp_flash_os_functions_t::start に引数 flags を追加 フラッシュドライバを自作・カスタマイズする場合
SPI Flash ヘッダのインクルードパスを可視性に合わせて変更 同上
SPI Flash esp_flash_t と esp_flash_os_functions_t を private ヘッダへ移動。メンバ直接参照ではなく API 経由へ 同上
UART soc/uart_channel.h を削除（→ soc/uart_pins.h） 当該ヘッダを使う場合
MbedTLS PSA の永続ストレージ形式を修正。旧版で保存した PSA 永続 opaque 鍵は再インポートが必要 PSA ECDSA / HMAC の opaque 鍵を永続化している場合
Secure Boot mbedTLS 4.1.0 化に伴い 192bit 曲線のサポートを削除 192bit 曲線を使う場合
Secure Boot ECDSA Secure Boot V2 を ESP32-H2 / C5 / P4 で無効化（量産段階のチップ。ECDSA ベースのフローに脆弱性が見つかったため。詳細は Chip Errata） 該当チップで ECDSA Secure Boot V2 を使う場合
システム ESP32-P4 の既定リビジョンが v3.0 に変更 ESP32-P4 を使うすべて（下記）

5-1. いちばん危険なのは ESP32-P4 の既定リビジョン変更

17件のうち 「ビルドは成功するのに、動かないバイナリができる」 のはこれだけです。

Applications for < 3.0 chips whose sdkconfig has no CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y will build an incompatible binary.

v3.0 より前の ESP32-P4 向けアプリは、sdkconfig に CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y が無いと 非互換なバイナリが出来上がります。 エラーは出ません。

対処は、reconfigure やビルドを走らせる前に sdkconfig へ次を追記することです。

CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y

コンパイルエラーは「気づける失敗」ですが、これは気づけない失敗です。 ESP32-P4 を触っている人は、17件のうちまずここだけ先に確認する価値があります。

🆕 6. 新機能と、ESP32-S31 プレビューの実際

6-1. ESP32-S31 のプレビューサポート

v6.1 の Major New Features の筆頭が ESP32-S31 のプレビューサポート です。Wi-Fi 6 とイーサネットを載せた新しい系列で、当サイトでも 発表時 と Linux BSP の開発者プレビュー で扱いました。

ただし、リリースノートが案内する公式の ESP32-S31 status には、こう書かれています。

Now the master branch contains the latest preview support for ESP32-S31. Until a full support version is released, please update to the HEAD of master branch to develop with ESP32-S31 chips.

v6.1 にプレビューサポートが入った一方で、公式ステータスページは master ブランチの HEAD を使うよう案内しています。 S31 を本気で触るなら、v6.1 タグではなく master を見るほうが実態に近い、と読めます。

⚠️ ここは裏が取り切れていない

このステータスページは 機能ごとの対応表が動的読み込み（ページ取得時点では Loading...）になっており、個別機能の対応状況までは確認できませんでした。 ページの静的部分の日付は2026年3月26日で、v6.1 リリースより前です。

そのため本記事では「v6.1 にプレビューサポートが入った」（リリースノート）と「ステータスページは master を案内している」（公式ページ）の両方を併記するに留めます。 S31 で開発するなら、着手前に同ページの対応表を自分で開いて確認してください。

6-2. PSRAM に暗号化しない領域を切れるようになった

CONFIG_SPIRAM_ENC_EXEMPT が入りました。PSRAM の中に暗号化しない領域を切り出し、新しい MALLOC_CAP_SPIRAM_NO_ENC で確保できます。狙いは 暗号化に伴うアライメント制約を避けること です。

フラッシュ暗号化と PSRAM を併用していて、DMA バッファのアライメントで困った経験がある人には効く追加です。

6-3. Wi-Fi 系4件

機能 内容
OWE-Only（SoftAP） SoftAP モードで OWE-Only に対応。パスワード無しでも暗号化されるオープンネットワーク
DPP マルチ設定（STA） station で複数設定に対応
プライバシー拡張（STA） station 向けのプライバシー拡張機構
Wi-Fi Aware Pairing iOS 互換のペアリングとセキュリティ（実験的）

Wi-Fi Aware Pairing については、リリースノートの Known Issues に 「iPhone 17 系のすべてで失敗する可能性がある」 と明記されています。実験的機能なので、期待値はそこに合わせておくのが安全です。

6-4. JPEG デコーダのセキュリティ修正（CVE-2026-55687）

Major Bugfix の1件は、JPEG デコーダへの厳格なチェック追加です。セキュリティアドバイザリ GHSA-v6r2-f6p2-88cj が公開されており、CVE-2026-55687・CVSS 7.5（High） が割り当てられています。

esp_driver_jpeg（ハードウェア JPEG デコーダ）で、DQT セグメントの量子化テーブル識別子の検証が不足しており、不正な JPEG によって静的配列の外へ書き込みが起きうる、という内容です。影響を受けるのは、信頼できない JPEG を読む経路がある構成 に限られます（ネットワーク経由の画像、外部メディアなど）。

アドバイザリは主たる影響を スタックオーバーフローによるパニック＝サービス拒否 としつつ、スタックカナリアを有効にしていない構成ではコード実行の可能性も否定していません（実証はされていない、とも書かれています）。

💡 影響を受けるバージョン

アドバイザリが挙げる影響バージョンは v6.0.1 / v5.5.4 / v5.4.4 / v5.3.5 、修正は v6.0.2 / v5.5.5 / v5.4.5 / v5.3.6 です。v6.1 にはこの修正が入っています。

「DoS に見える不具合が、条件次第でコード実行に届きうる」という構図そのものは、Citrix NetScaler の CVE-2026-8452 と同じ形です。深刻度の記述だけで優先度を決めない、という点は共通します。

📌 筆者の見方

筆者にとって最初に当たるのは MQTT でした。自宅センサー基盤 #2 で書いたファームウェアは ESP-IDF v5.5.3 で組んであり、JSON 生成と LWT と publish を担当する mqtt_tx コンポーネントが入っています。ここを 6.1 に上げるなら、espressif/mqtt の依存宣言を足す作業が確実に発生します。ただし実機で試したわけではありません。 手順はレジストリの情報から読み取れるところまでで、通ったかどうかは焼いてみないと分かりません。

あの記事の前提節で、筆者は「Wi-Fi も MQTT も NVS も、最初から全部載っている土台ではなく、必要なら依存として宣言する部品です」と書きました。考え方としてはそのとおりでしたが、MQTT に関しては in-tree だったので、実際には宣言しなくても使えていました。 v6.1 は、その例外を消して説明どおりの形に揃えた変更だと受け止めています。書いたときは概念の説明のつもりでしたが、フレームワークのほうが後から文字どおりになった かたちです。

もうひとつ、自分の作業でいちばん引っかかりそうなのは idf.py flash の差分書き込みです。筆者は eim 経由でビルドと書き込みを回していて、焼き直しの回数がとにかく多い。 速くなるのは素直にありがたい一方で、#2 では基板ごとに nvs パーティションだけを書き込むプロビジョニング をしています。全体書き込みと部分書き込みが混ざる運用なので、「変更したのに反映されていない気がする」と感じたとき、疑う対象がひとつ増えた ことになります。公式が新品・消去直後のチップに -a を推奨しているのは、たぶんそういう場面のことです。ここは次に基板を焼くときに、意識して確かめてみるつもりです。

最後に、17件を並べてみて思ったことを。minor リリースの公式定義は「コードの更新は不要」です。その字面と実際の変更リストは噛み合っていません。ただ、筆者はリストが出ているほうがありがたい と感じました。困るのは変更があることではなく、変更が黙って入ることです。ESP32-P4 の既定リビジョンのように ビルドが通ってしまう非互換 が1件混ざっている以上、読むべきは版番号ではなく、毎回このリストのほうだと考えています。

まとめ

  • ESP-IDF v6.1 は 2026年8月27日リリース（GitHub Releases API の published_at で確認）。位置づけは v6.0 の minor アップデート
  • 公式の versioning 方針では minor は「公開 API に非互換な変更を加えない」だが、v6.1 の Breaking Changes は17件。リリースノート自身も「mostly compatible」と留保している。判定はバージョン番号ではなく変更リストで行う
  • 6.0 組が最初に踏むのは MQTT。 esp-mqtt が in-tree からコンポーネントマネージャ管理へ移り、espressif/mqtt を依存に明示しないと使えない。この項目は移行ガイドには無く、リリースノートにしか書かれていない
  • 逆に、リリースノートに無く移行ガイドにしかない変更が2件。 idf.py flash の既定が差分書き込みになったこと（全体書き込みは -a / --all）と、UART ウェイクアップ API の刷新（uart_wakeup_setup()）
  • いちばん危険なのは ESP32-P4 の既定リビジョン変更。 17件で唯一、ビルドは成功するのに非互換なバイナリができる。CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y の追記で回避
  • 新機能は ESP32-S31 プレビュー・PSRAM 非暗号化領域・Wi-Fi 4件・スリープ保持モジュールの動的着脱。プレビューはサポート期間の対象外で、S31 の公式ステータスページは今も master ブランチを案内している
  • Major Bugfix は JPEG デコーダの CVE-2026-55687（CVSS 7.5） 修正

上げる順序としては、MQTT の依存宣言 → 移行ガイド2ページ → 使っているペリフェラルの該当項目、が最短です。 ESP32-P4 を使っているなら、その前に sdkconfig を1行確認してください。

よくある質問（FAQ）

Q. 6.0 から 6.1 に、いま上げるべきですか。

急ぐ理由があるのは、ESP32-S31 を触りたい場合と、JPEG デコーダの脆弱性（CVE-2026-55687）に該当する構成の場合です。それ以外は、Breaking Changes 17件のうち自分に当たるものを確認してからで問題ありません。なお JPEG の件は v6.0.2 など各系列の bugfix リリースでも修正されるとアドバイザリに記載があります。

Q. MQTT を使っていますが、何をすればいいですか。

idf.py add-dependency "espressif/mqtt" を実行して idf.py reconfigure するのが基本形です。espressif/mqtt は ESP-IDF v5.3 以降 に対応しているため、6.1 へ上げる前に、いまのバージョンのまま依存宣言だけ先に済ませておけます。 バージョンアップと同時にやらないほうが切り分けは楽です。

Q. idf.py flash が速くなったのは分かりましたが、危なくないですか。

書き込み後にデバイス上の内容と期待するバイナリを照合し、失敗すれば自動で全体書き込みに切り替わる 設計です。そのうえで公式は、新品・空・消去直後のチップでは idf.py flash -a（全体書き込み）を推奨しています。挙動が怪しいと感じたら -a を試すのが最短の切り分けになります。

Q. 「プレビューサポート」の ESP32-S31 は、製品に使えますか。

公式ドキュメントは、プレビュー扱いの機能を サポート期間の対象外 と明記しています。加えて ESP32-S31 の公式ステータスページは、フルサポート版が出るまで master ブランチの HEAD を使うよう案内しています。評価・試作の段階のものと考えるのが妥当です。

Q. 破壊的変更17件を全部確認する必要がありますか。

ありません。17件のうち大半は「そのペリフェラルを直接叩いている場合」に限定されます。§5 の表の「当たる条件」列で、自分のプロジェクトに関係するものだけを拾えば足ります。ただし MQTT（使っていれば全員）と ESP32-P4 の既定リビジョン（使っていれば全員）の2つは、条件が広いので先に見てください。

Q. 移行ガイドとリリースノートは、どちらを読めばいいですか。

両方です。 今回の v6.1 では、MQTT の移管がリリースノートにしかなく、idf.py flash の挙動変更と UART ウェイクアップ API の刷新が移行ガイドにしかありませんでした。片方だけでは抜けます。

参考

関連記事