EIM（ESP-IDF Installation Manager）の使い方｜複数バージョン共存で変わる ESP32 開発環境

🧭 はじめに：ESP-IDF は「入れ方」が長年の泣きどころだった

ESP-IDF そのものは強力な開発環境です。ただ、環境構築でつまずいた経験のある人はかなり多いはずです。私自身も何度もやり直してきました。

理由ははっきりしていて、これまで「入れ方」が複数あり、それぞれが独立していたからです。Windows 用のインストーラ exe、リポジトリ同梱の install.bat／install.sh、VS Code 拡張のセットアップウィザード——どれを選ぶかで環境の場所も管理方法も変わり、一度作った環境のバージョンを上げるとなると「壊して入れ直し」が基本でした。プロジェクトごとに必要な ESP-IDF バージョンが違う、という組み込み開発にありがちな状況とは、正直相性がよくありませんでした。

この状況を一新するのが、ESP-IDF 6.0 と同時に登場した公式ツール EIM（ESP-IDF Installation Manager） です。この記事では、EIM とは何かという基本から、本命である複数バージョン共存管理、導入手順、実運用パターン、既知の罠までを、実際に運用している環境の実測ベースでまとめます。

なお、ESP-IDF での開発そのものが初めての場合は、先に VS Codeで始めるESP-IDF環境構築ガイド で「ESP-IDF で開発するとはどういうことか」の全体像をつかんでおくと読みやすくなります。

💡 EIM とは：公式が用意した「環境構築の一本化された入り口」

EIM（ESP-IDF Installation Manager） は、Espressif が公式に提供するクロスプラットフォームのインストールマネージャです。公式は「ESP-IDF と好みの IDE のセットアップ全体を単純化する、統一されたクロスプラットフォームのツール」と説明しています。GUI 版と CLI があり、公式ドキュメントは両者を同等の機能として位置づけています。

従来の方法と何が違うのか、対比で見るのが早いでしょう。

🔁 本命：複数バージョンの共存管理——「環境を壊さず隣に足す」

EIM のいちばんの価値はここです。実際に運用している環境で eim list を実行すると、こうなります。

> eim list
Installed versions:
- v6.0.2 [C:\esp\v6.0.2\esp-idf]
- v5.5.2 [C:\esp\v5.5.2\esp-idf]
- v5.5.3 (selected) [C:\esp\v5.5.3\esp-idf]

3つのバージョンが同居しています。(selected) が付いているのが既定のバージョンで、それぞれ独立したディレクトリと Python 仮想環境を持つため、互いに干渉しません。

使い分けの操作は2つだけです。

# ① コマンド単位でバージョン指定（末尾に付ける）——既定は変わらない
eim run "idf.py -C <プロジェクト> build" v6.0.2

# ② 既定そのものを切り替える——以後の eim run はすべて 6.0.2 に
eim select v6.0.2

従来の「バージョンアップ＝賭け」がなくなる

従来の一番の恐怖は、バージョンを上げた結果、動いていたプロジェクトがビルドできなくなり、しかも簡単には戻れないことでした。メジャーバージョン移行ではこれが特に重く、「上げたいけど、いま動いているものを壊したくない」というジレンマが常にありました。

EIM ではこの構図が変わります。ESP-IDF 6.0 への移行 を例にすると、やることは実質これだけです。

1. eim install --idf-versions v6.0.2——5.5 系はそのまま、隣に 6.0.2 が入る
2. 試したいプロジェクトだけ eim run "idf.py build" v6.0.2 でビルド——既定は安定版のまま
3. 6.0 で問題ないと確信できたら eim select v6.0.2——それでも旧環境は消えておらず、eim select v5.5.3 で即座に戻せる

「メジャーバージョン移行」という重い響きの作業が、リスクのない足し算になっています。試して、ダメなら戻す。この気軽さは、一度体験すると戻れません。

📥 導入手順

Windows（実測）

winget で一発です。導入されるのは GUI 版ですが、GUI 版は CLI 機能を完全に内蔵しているため、そのまま eim コマンドが使えます（CLI 専用版を別途入れる必要はありませんでした）。

winget install Espressif.EIM
eim install          # 非対話モードで必須機能のみインストール
eim list             # 入ったバージョンを確認

eim install は引数なしだと自動的に非対話モードになり、「必須機能だけ」を選んで進みます。バージョンや追加機能を指定したい場合は明示します。

eim install --idf-versions v6.0.2 --idf-features mcp --non-interactive true

macOS／Linux（公式の提供チャネル）

公式ドキュメントによると、macOS は Homebrew（推奨）または直接ダウンロード、Linux は Homebrew・APT（Debian/Ubuntu）・DNF（Fedora/RHEL）・pacman（Arch）が用意されています。パッケージマネージャに乗っているので、導入も更新も OS の流儀のままで済みます。

コマンド一覧（eim 0.17.1 実測）

eim --help で確認できる主なコマンドです。「インストールマネージャ」の名のとおり、入れた後の管理コマンドが充実しているのが分かります。

なお discover（利用可能バージョンの探索）はヘルプに「not implemented yet」と正直に書かれています。開発途上のツールらしい表記ですが、裏を返せばこの規模の機能がすでに実装済みということでもあります。

🛠️ 実運用パターン集

実際に2週間あまり運用して定着した使い方です。

パターン1：既定は安定版、新版はコマンド単位で試す

# ふだんの開発（既定 = 安定版）
eim run "idf.py -C D:\proj\product-a build"

# 新バージョンの試験だけ末尾指定
eim run "idf.py -C D:\proj\experiment build" v6.0.2

既定を安定版に固定しておけば、うっかり新環境でビルドして壊す事故が構造的に起きません。新版の検証はコマンド単位で明示的に。この「明示したときだけ新しい方」という非対称性が安全側に効きます。

パターン2：プロジェクトとバージョンの対応を固定する

プロジェクトごとに使うバージョンが決まっているなら、ビルドスクリプトや AI コーディングエージェントへの指示書にバージョン引数ごと書いておくのが確実です。この環境では Claude Code のスキルに eim run の作法を書いてあり、「ビルドして」と頼むだけで正しいバージョン・正しい作法で実行されます（仕組みは Claude Code スキルで ESP32 開発を自動化 を参照）。

パターン3：メジャー移行は「隣に足して、試して、select」

前章の 6.0 移行がまさにこれです。install（追加）→ run で試験 → select（昇格）→ 問題があれば select で降格。どの段階でも旧環境が無傷で残っているのがポイントです。

パターン4：CI・自動化

公式ドキュメントはヘッドレス（非対話）動作・設定の TOML エクスポート/インポート・CI/CD と Docker への統合を明記しています。手元で eim install --non-interactive true に各種フラグを足した1行を作っておけば、それがそのまま CI の環境構築スクリプトになります。「手元の環境構築」と「CI の環境構築」が同じコマンドで再現できるのは、従来ばらばらだった入り口が一本化されたおかげです。

パターン5：壊れたら fix、やり直すなら purge

ツールの欠損などで環境が不調になったら、入れ直しの前に eim fix を試します。ツールと依存関係を再インストールして修復するコマンドです。まっさらからやり直したいときは eim purge で全バージョンを一括削除できます。「困ったら消して全部入れ直し」しか無かった時代との違いがここにも出ています。

⚠️ 既知の罠（詳細は各記事へ）

EIM 経由の運用でこれまでに実際に踏んだ罠は、それぞれ既存記事に実測付きでまとめてあります。ここでは見出しだけ。

• 素の PowerShell/CMD に idf.py は存在しない — EIM の環境はシェルに常駐しません。eim run "idf.py <args>" の形で呼ぶのが基本です（→ スキル記事）
• eim run は内側のコマンドが失敗しても終了コード 0 を返すことがある — 成否は exit code ではなく出力の文字列（Hash of data verified などの成功ログ／エラー行）で判定します（→ スキル記事に失敗検知の実例）
• 引数なし eim install は追加機能をスキップする — 前述。--idf-features を明示（→ MCP サーバ記事）
• 別プロセスからの利用は環境変数を引き継がない前提で — AI クライアント等が起動するプロセスにはシェルの環境変数が渡らないため、対象プロジェクトは -C <パス> で明示するのが確実です（→ MCP サーバ記事）
• COM ポートの占有 — ターミナルソフトがポートを掴んだままだと書き込みに失敗します（→ スキル記事に実例）

✅ まとめ

• EIM は ESP-IDF 公式のインストールマネージャ。OS ごと・方法ごとにばらばらだった環境構築の入り口が1つになりました
• 本命は複数バージョンの共存管理。eim list（一覧）・eim select（既定切替）・eim run 〜 <version>（コマンド単位指定）の3つを覚えれば、既存環境を壊さず新バージョンを隣に足せます
• メジャーバージョン移行が「賭け」から「リスクのない足し算」に変わったのが最大の恩恵。製品メンテ用の旧環境と新規開発用の新環境の並行運用も1台で済みます
• fix・purge・import など「入れた後」のコマンドが揃っており、非対話動作と設定エクスポートで CI への展開も一本道です
• 実際に 5.5.2／5.5.3／6.0.2 の3バージョンを共存させて2週間あまり運用していますが、環境の取り違えによる事故は起きていません。ESP-IDF の環境構築は、確実に楽な時代に入りました

❓ よくある質問（FAQ）

Q. 既存の環境（VS Code 拡張や install.bat で構築したもの）はどうなりますか？

A. そのまま共存できます。EIM には既存の ESP-IDF 環境を管理下へ取り込む eim import コマンドも用意されています。新しいバージョンから EIM 管理に移行し、古い環境は役目を終えたら畳む、という段階移行が現実的です。

Q. 複数バージョンはどこにインストールされますか？

A. この環境（Windows）では ESP-IDF 本体がバージョンごとに C:\esp\<バージョン>\esp-idf、ツール類と Python 仮想環境が C:\Espressif\tools 配下に置かれています。バージョンごとに独立しているため互いに干渉しません。

Q. GUI 版と CLI 版、どちらを入れるべきですか？

A. Windows で winget から入れた GUI 版は CLI 機能を完全に内蔵しており、eim コマンドがそのまま使えました。公式も GUI と CLI を同等機能と位置づけているので、GUI 版を入れて必要に応じてコマンドを使う、で困りません。

Q. ディスク容量はどれくらい必要ですか？

A. バージョンごとに ESP-IDF 本体＋ツールチェーン＋Python 仮想環境を持つため、共存させるぶんだけ容量は増えます。使わなくなったバージョンは eim remove で個別に削除できるので、「試したら畳む」を習慣にすると膨らみません。

関連記事

• ESP-IDF 6.0 移行ガイド｜レガシードライバ全廃と破壊的変更の要点：EIM の共存管理を使って実際に 6.0 へ移行した実録つき。何が壊れてどう直すかはこちら
• ESP-IDF 6.0×ESP32-S3でWi-Fi接続とHTTP POST｜cJSONをidf_component.ymlで取得するレジストリ時代の依存管理：本記事の環境（v6.0.2）で実際にプロジェクトを作り、実機で動かした実践編
• Claude Code × ESP32｜ESP-IDF 6.0 の MCP サーバ活用ガイド：eim install の機能選択の罠と MCP サーバの実機検証
• Claude Code スキルで ESP32 開発を自動化｜idf.py を直接叩く：eim run の作法をスキル化して自然言語でビルド・書き込みする方法
• VS Codeで始めるESP-IDF環境構築ガイド｜最小構成でHello Worldまで：ESP-IDF 開発の全体像。拡張機能の使い方は EIM 併用でも役立ちます

参考

• ESP-IDF Installation Manager 公式ドキュメント（Espressif）
• espressif/idf-im-ui（GitHub・EIM 本体リポジトリ）
• Announcing ESP-IDF v6.0（Espressif Developer Portal・2026年3月）