STM32をVS Codeで開発する｜STM32CubeIDE for VS Code拡張の導入・ビルド・デバッグ【2026年最新】

STM32のファームウェア開発をEclipseベースのSTM32CubeIDEではなく、使い慣れたVisual Studio Code（VS Code）で完結させたい——そのための公式手段が、STマイクロエレクトロニクスが提供する「STM32CubeIDE for Visual Studio Code」拡張です。かつて「STM32 VS Code Extension」「STM32Cube for Visual Studio Code」と呼ばれていたものと同じ拡張で、2026年5月時点の最新はv3.9.0。単なるエディタ支援ではなく、CubeMXでの設定、CMake/Ninjaでのビルド、OpenOCD＋ST-LinkでのデバッグまでをVS Code上でつなぎます。この記事では、導入から実際のビルド・デバッグ、さらにVS Code経路ならではのAIコーディング活用までを実例で解説します。

まとめ：STM32×VS Code開発の要点

• 拡張の正式名称は「STM32CubeIDE for Visual Studio Code」（旧・STM32 VS Code Extension）。Marketplaceの発行元はSTMicroelectronics、現行はv3.9.0（2026年5月）。
• 2026年の大きな変更はBundle Manager化。従来オールインワンだったSTM32CubeCLT（ARM GCC・CMake・Ninja・OpenOCD等）を、拡張がCLIツールを自動取得・バージョン管理する方式へ置き換えた。CubeCLTは将来的に非推奨となる。
• プロジェクトはCubeMX2から直接生成でき、既存のSTM32CubeIDE（Eclipse）プロジェクトもCMakeへ変換して取り込める（dual-core／TrustZone等のマルチコンテキストとpre/post-buildは未対応）。
• ビルドはCMake＋Ninja。デバッグは拡張が自動生成するST純正構成（stlinkgdbtarget／jlinkgdbtarget）が標準で、ST-LinkとJ-Linkをネイティブ対応。従来型のcortex-debug＋OpenOCDも代替として使える。
• 開発の場がVS Codeに移ることで、Claude CodeやGitHub CopilotといったAI支援をSTM32のソースに直接使える点はEclipse版にない実利。ただしレジスタ操作やHALコードは必ずリファレンスマニュアルで検証する。

以下、それぞれを手順とコード付きで見ていきます。

STM32 VS Code Extension（現STM32CubeIDE for VS Code）とは：2026年時点の位置づけ

「STM32 VS Code Extension」は、STマイクロが公式に配布するVS Code向けのSTM32開発拡張です。検索では「stm32cube vscode」「stm32 開発環境 vscode」「stm32cubeide vscode」など複数の呼び方で探されますが、指す対象は同じ一つの拡張です。VS CodeのソースエディタとGit連携をそのまま活かしながら、STM32のプロジェクト設定・ビルド・書き込み・デバッグを一つのウィンドウで扱えるようにします。

「STM32CubeIDE for Visual Studio Code」への改称と現行バージョン

この拡張は開発の過程で名称が変わっています。初期は「STM32 VS Code Extension」、その後「STM32Cube for Visual Studio Code」、そして正式版で「STM32CubeIDE for Visual Studio Code」に統一されました。Marketplaceでの識別子はstmicroelectronics.stm32-vscode-extensionで一貫しているため、名称が違っても同じ拡張を指します。バージョンはv3.4.11・v3.6.2を経て、STM32C5シリーズ対応のv3.8.0（2026年3月）、そしてv3.9.0（2026年5月11日）が現行です。旧称のまま解説している古い記事も多いので、インストール時はこの識別子で確認すると確実です。

Eclipse版STM32CubeIDEとの違いと使い分け

混同しやすいのが、従来からあるEclipseベースの単体IDE「STM32CubeIDE」との違いです。両者は別物で、選ぶ基準は明確です。Eclipse版はグラフィカルなデバッグやマルチコア・TrustZoneといった高度な機能が成熟している一方、エディタの操作性や拡張エコシステムはVS Codeに劣ります。VS Code版はエディタ体験・Git・AI支援に強く、CMakeベースで再現性が高い反面、一部の高度なデバッグ機能はまだ移植途上です。

結論として、dual-coreやTrustZoneを多用する製品開発ではEclipse版が無難、単一コアでエディタ体験とAI活用を重視するならVS Code版、という住み分けになります。両方を併用し、設定はCubeMX、コーディングとビルドはVS Code、難しいデバッグ局面だけEclipse版に戻す運用も現実的です。

導入手順：拡張機能パックとツールチェーンの準備

導入は「VS Code本体→拡張機能パック→CLIツール（Bundle Manager）→CubeMX」の順で進めます。2025年までのv2系はSTM32CubeCLTの手動インストールが前提でしたが、現行版では手順が大きく簡略化されています。

拡張機能パックのインストール

VS Codeの拡張ビュー（Ctrl+Shift+X）で「STM32CubeIDE for Visual Studio Code」を検索し、発行元がSTMicroelectronicsであることを確認してインストールします。現行版は単一拡張ではなく拡張機能パック（extension pack）として提供され、C/C++解析用のclangd、MicrosoftのCMake Tools、周辺レジスタ表示用のPeripheral Viewerなど必要な依存がまとめて入ります。コマンドラインから入れる場合は次の通りです。

code --install-extension stmicroelectronics.stm32-vscode-extension

Bundle Managerによるツール取得（旧STM32CubeCLTからの変更）

ここが2026年最大の変更点です。ARM GCC（arm-none-eabi）、CMake、Ninja、OpenOCD、ST-Link関連ツールといったビルド・書き込みに必要なCLI群を、以前は「STM32CubeCLT」というオールインワンパッケージ（v2.0.0はCLT 1.15.0が必須で、CMakeとNinjaもこれで入った）で一括導入していました。現行版はこれをBundle Managerが置き換え、拡張がVS Code内から必要なツールを自動でダウンロード・インストール・更新します。ARM GCCやCMakeを個別に入れる必要はありません。Bundle ManagerはアクティビティバーのSTM32ビュー、またはコマンドパレット（Ctrl+Shift+P）で「STM32」と入力して出るコマンドから開けます。

Bundle Managerではツールを複数バージョン併存させ、プロジェクト単位でバージョンを固定（ロック）できます。チーム内やCIで同じツール構成を再現でき、「自分の環境では通るがビルドサーバーで落ちる」といった差異を避けられます。なお従来のSTM32CubeCLTは将来的に非推奨となる方針が示されているため、新規導入ではBundle Managerに寄せるのが安全です。

CubeMXの準備と動作確認

ペリフェラルやクロックの設定にはSTM32CubeMXを使います。現行の拡張はCubeMX2をVS Codeから直接起動できるため、設定画面のためだけに別ウィンドウを探す手間が減ります。導入後は簡単なプロジェクトを一つ作り、ビルドと書き込みが最後まで通ることを確認してから本開発に入ってください。ここでつまずく典型はツール未取得（Bundle Managerでの取得漏れ）とST-Linkドライバ未認識の2つです。

プロジェクトの作成とCubeMX連携

プロジェクトの起点は2通りあります。新規はCubeMX2からCMakeプロジェクトを生成する方法、既存資産があるならEclipse版プロジェクトをCMakeへ変換して取り込む方法です。

CubeMX2から新規CMakeプロジェクトを生成

CubeMX2でMCUまたはボードを選び、ペリフェラル・クロック・ピン配置を設定したら、Project Managerのツールチェーン選択でCMakeを指定してコードを生成します。出力にはCMakeLists.txtとツールチェーン設定（arm-none-eabi向け）、HAL/LL初期化コードが含まれ、そのままVS Codeで開けます。CubeMXが生成・管理する領域（USERコメント外）を手で書き換えると再生成時に上書きされるため、追記は必ずUSER CODE BEGIN／USER CODE ENDの間に書きます。

既存STM32CubeIDEプロジェクトのCMake変換import

すでにEclipse版のSTM32CubeIDEで作った資産がある場合、拡張の変換ツールでネイティブプロジェクトをCMake形式へ変換して取り込めます。ただし制約があり、dual-coreやTrustZoneといったマルチコンテキスト構成、およびpre/post-buildステップは現時点で未対応です。これらを使うプロジェクトは変換で情報が欠けるため、単一コア構成に限って移行するか、該当プロジェクトはEclipse版に残す判断が要ります。安易に全プロジェクトをVS Codeへ移すのではなく、構成を確認してから移行対象を絞るのが安全です。

ビルドとデバッグの実行（CMake・Ninja・ST-Link/J-Link）

ビルドはCMakeのconfigure→buildの2段階です。デバッグは、現行版がST純正のGDBサーバー（ST-Link GDB Server）を立て、拡張が生成したデバッグ構成でVS Code側から接続する流れが標準になります。

CMake configure→buildの流れ（Ninja）

拡張のUIボタンからも実行できますが、中身を理解しておくとエラー切り分けが速くなります。ジェネレータにNinjaを指定し、CubeMXが出力したツールチェーンファイルを渡してconfigureし、続けてbuildします。VS Code内のターミナルで実行する場合は次の通りです。

cmake -S . -B build -G Ninja \
      -DCMAKE_TOOLCHAIN_FILE=cmake/gcc-arm-none-eabi.cmake
cmake --build build

Ninjaは差分ビルドが速く、GNU Makeより並列化の効率が良いため、STM32のような多ファイル構成で体感差が出ます。ビルドエラーが出たら、まずターミナルの最初のエラー行（後続はその波及であることが多い）と、ツールチェーンファイルのパスが正しいかを確認します。外部ライブラリを取り込む場合はCMakeのFetchContentが定番で、依存の取得からビルドまでをCMakeLists.txtにまとめられます。書き方はFetchContentを用いたCMakeでの外部ライブラリ管理の全体像で詳しく解説しています。

launch.jsonとST-Link/J-Linkでのデバッグ（ST純正）

現行版はST独自のデバッグ実装を持ち、デバッグ対象を選ぶとlaunch.jsonをその場で自動生成してデバッグを開始します（この一時構成はセッション終了後に保存されない仕様のため、恒久化したい場合は自分で.vscode/launch.jsonに書き出します）。設定のtypeにはST純正のstlinkgdbtarget（ST-Link）やjlinkgdbtarget（J-Link）を使い、cortex-debugのようにOpenOCDの.cfgを手で指定する必要はありません。ST-Link向けの構成は次の形です。

{
  "type": "stlinkgdbtarget",
  "request": "launch",
  "name": "STM32Cube: STM32 Launch ST-Link GDB Server",
  "cwd": "${workspaceFolder}",
  "preBuild": "${command:st-stm32-ide-debug-launch.build}",
  "runEntry": "main",
  "imagesAndSymbols": [
    { "imageFileName": "build/my_project.elf" }
  ]
}

typeをjlinkgdbtargetに替えればJ-Linkプローブをそのまま使えます。ブレークポイント、変数ウォッチ、ステップ実行はVS Codeの標準デバッグUIから操作でき、preBuildでデバッグ開始前のビルドを自動化できます。周辺レジスタの内容はPeripheral Viewerで確認できます。なお、マルチコアのステップ制御などEclipse版にある一部の高度なデバッグ機能はVS Code版で未実装の段階です。

cortex-debug＋OpenOCDでの代替設定

旧バージョンから移ってきた場合や、OpenOCDでの細かな制御を続けたい場合は、Marus25のcortex-debug拡張を別途入れて使えます（ST純正が推奨ですが、cortex-debugも引き続き動作します）。この場合はtypeをcortex-debug、servertypeをstlinkまたはopenocdにし、OpenOCD経由ならボード用のconfigFiles（interface/stlink.cfgとMCUシリーズ用のtarget/stm32f4x.cfg）を指定します。プローブを替えたのに接続できないときは、まず古いST-Linkファームウェアの更新と.cfg指定の一致を疑うのが定石です。

Claude Code・CopilotをSTM32開発で使うという選択肢

開発の場がEclipseからVS Codeに移ることの実利は、ビルドの再現性だけではありません。VS CodeのAIコーディング支援を、そのままSTM32のファームウェア開発に使える点が大きい。「claude code stm32」「stm32 claude code」といった検索が見られるのも、この組み合わせを試す開発者が現れているからでしょう。Eclipseベースの単体IDEでは選べない道です。

具体的には、HAL/LL APIの呼び出しコード、GPIOやタイマのレジスタ設定の下書き、CMakeLists.txtやデバッグ設定の生成、エラーログの解読といった作業でAIが効きます。VS Code拡張として提供されるAnthropicが「Claude Code for VS Code」を一般提供開始、AIコーディング支援拡張機能が正式リリースや、VS CodeでGitHub Copilotを使うには？導入から使い方までわかりやすく解説【2026年版】で導入方法を確認できます。どちらもSTM32拡張と同じVS Code上で同時に動かせます。

ただし過信は禁物です。AIは接続中のMCUの実際のクロック構成やペリフェラルの状態を知りません。生成されたレジスタ操作やビット設定は、必ず対象MCUのリファレンスマニュアルとデータシートで裏取りしてください。とくにCubeMXが自動生成する初期化コードをAIに書き換えさせると、次回の再生成で消える・整合が崩れるという事故が起きます。AIにはUSER CODEブロック内のアプリケーションロジックや周辺のグルーコードを任せ、CubeMX管理領域とハードウェア直結の設定は人が検証する——この線引きを守るのが、組み込みでAIを安全に使う条件です。

よくある質問

STM32CubeMXとSTM32CubeIDEの違いは何ですか？

CubeMXはペリフェラルやクロックを設定して初期化コードを生成する設定ツール、CubeIDEはEclipseベースの統合開発環境（エディタ＋ビルド＋デバッグ）です。VS Code開発では、設定をCubeMX2で行い、ビルドとデバッグをVS Code側の拡張が担う分業になります。

Eclipse版のSTM32CubeIDEはVS Codeで使えますか？

Eclipse版そのものはVS Code上では動きません。ただし拡張の変換ツールで既存のCubeIDEプロジェクトをCMake形式へ変換すれば、VS Codeで開いて開発を続けられます。dual-core／TrustZoneやpre/post-buildを使う構成は未対応なので、その場合はEclipse版に残してください。

ARM GCCやCMakeは個別にインストールが必要ですか？

現行版では不要です。拡張のBundle Managerが、ARM GCC・CMake・Ninja・OpenOCD等を自動で取得・管理します。以前のSTM32CubeCLTを手動で入れる方式は将来的に非推奨となる方向のため、新規導入ではBundle Managerを使ってください。

拡張機能がインストール・起動できないときは？

VS Codeのバージョンが拡張の要件を満たしているか、発行元がSTMicroelectronicsの正規拡張か（stmicroelectronics.stm32-vscode-extension）をまず確認します。拡張機能パックの依存が入りきっていないケースもあるため、一度アンインストールして再インストールし、Bundle Managerでツール取得をやり直すと解消することが多いです。

ST-LinkやOpenOCDでボードに接続できないときは？

まずST-Linkのファームウェアを最新に更新します。ST純正構成でつながらない場合はプローブ選択とデバイス指定を、cortex-debug＋OpenOCDの代替構成を使っている場合はconfigFilesがボードのインターフェースとMCUシリーズに合っているかを確認します。USBケーブルが給電専用でデータ線が無いケースや、ドライバ未認識も典型的な原因です。

関連記事

• FetchContentを用いたCMakeでの外部ライブラリ管理の全体像
• Anthropicが「Claude Code for VS Code」を一般提供開始、AIコーディング支援拡張機能が正式リリース
• VS CodeでGitHub Copilotを使うには？導入から使い方までわかりやすく解説【2026年版】