みなさん、こんにちは。
前回の「M5StickCでパルスオキシメーターを自作した話」の記事では、慣れ親しんだArduino IDE を用いて開発を行いました。
デバイス自体は短時間で完成しましたが、実は開発環境の裏側で少しばかり「格闘」がありました。格闘の結果、Arduino IDEを卒業し、PlatformIOへの移行を決意しました。今回は、格闘の内容と移行の過程で突き当たった壁の乗り越え方についてお話します。
エンジニアの皆さんなら一度は経験があるであろう「開発環境の最適化」という泥臭いけれど避けては通れない話です。
なぜ、今さらPlatformIOなのか
結論から言えば、Arduino IDEの「おせっかいな仕様」に限界を感じたからです。
2026年現在も、Arduino IDEは初心者に優しいツールです。しかし、Ubuntu環境でESP32ボードのアップデートを試みた際、何度も失敗するという事態に見舞われました。調査したところ、Arduino IDEの更新プロセスにはタイムアウトが設定されており、通信環境やパッケージの肥大化によって処理が間に合わないと、問答無用でエラー終了してしまいます。
どうにかして調整できないか格闘したのですが、残念ながら、このタイムアウトから逃れる術はありませんでした。「それならば」と、以前から気になっていたよりプロフェッショナルな環境、PlatformIO（VS Code拡張）への移行を決めたわけです。
「インポートするだけで完了」というネットの記事を鵜呑みにしていたのですが、現実はそう甘くありませんでした。はじめての移行だったため、戸惑うことが多くあったのです。
移行環境
- Target Device: M5StickC
- Sensor: MAX30100心拍センサユニット (Pulse Oximeter)
- OS: Xubuntu 22.04 / Linux
- Transition: Arduino IDE → PlatformIO
インポート後に遭遇した4つの課題と解決策
1. ユニットテストの「お作法」の違い
PlatformIOの大きな魅力の一つは、ユニットテストの統合です。しかし、インポート直後にテストを実行しようとすると、以下のエラーに阻まれました。
Error: Nothing to build. Please put your test suites to the '.../test' folder
原因と対策
Arduino IDEには厳密なユニットテストの概念がありませんが、PlatformIOは「ディレクトリ構造」に厳密です。実機テスト（Embedded）とPC上でのシミュレーション（Native）を分ける必要がありました。
以下のようにディレクトリを整理することで解決しました。
test/
├── test_embedded/
│ └── test_embedded.cpp # M5StickC実機用
└── test_native/
└── test_native.cpp # PC上でのロジック検証用
2. ライブラリ依存関係の明示
Arduino IDEでは「ライブラリマネージャー」でポチポチとインストールすれば魔法のように認識されますが、PlatformIOではplatformio.iniへの記述が絶対です。
当初はヘッダーファイルが見つからない（No such file or directory）というエラーが頻発しました。
解決方法
CLIで必要なライブラリを検索し、そのIDやURLをplatformio.iniに追記します。
; platformio.ini の設定例
[env:m5stick-c]
platform = espressif32
board = m5stick-c
framework = arduino
lib_deps =
oxullo/MAX30100lib@^1.2.1
m5stack/M5StickC@^0.2.5
3. Linux特有の権限問題（Permission denied）
CLIから書き込み（Upload）を行おうとすると、シリアルポートへのアクセス拒否に遭遇しました。
[Errno 13] Permission denied: '/dev/ttyUSB0'
これはArduino IDEがGUI経由でよしなに処理してくれていた権限周りが、CLIベースになったことで表面化した問題です。
解決方法
ユーザーをdialoutグループに追加し、一度ログアウト・再ログインすることで恒久的に解決します。
sudo usermod -a -G dialout $USER
※即座に反映させたい場合は、sg dialout -c "..."コマンドで一時的に実行権限をバイパスできます。
4. テスト環境の「混線」
実機用のコードとネイティブ用のコードが混ざり、コンパイルエラー（Arduino.hが見つかりません等）が発生するケースです。
解決方法
platformio.iniで環境（env）を定義し、それぞれにtest_ignoreを設定して不要なソースをビルド対象から外すのがベストプラクティスです。
[env:native]
platform = native
test_build_src = yes
test_ignore = test_embedded # 実機用テストを無視
Arduino IDE vs PlatformIO – エンジニアの視点
今回の移行を経て感じた違いを、簡単な比較表にまとめました。
| 項目 | Arduino IDE | PlatformIO |
| プロジェクト管理 | フラットでシンプル | src, lib, testに分離されたモダンな構造 |
| ライブラリ | 全プロジェクトで共有（依存関係が不透明） | プロジェクトごとに指定（再現性が高い） |
| テスト | 実装が困難 | Unity統合済み。CI連携も容易 |
| バージョン管理 | .inoファイルのみ | platformio.iniによる完全な環境管理 |
移行して「正解」だったのか？
間違いなく「正解」でした。
最初は設定の多さに戸惑いますが、一度構築してしまえば、GitHub Copilotによるコード補完の質も上がり、CI/CDへの組み込みも容易になります。何より、ライブラリのバージョンを固定できるため、「昨日まで動いていたのに突然ビルドできなくなった」という悲劇を回避できます。
自分の健康を守るデバイスを、より堅牢な環境でメンテナンスしていく。これもまた、エンジニアなりの誠実な向き合い方ではないでしょうか。
もし、Arduino IDEの動作が重い、あるいはプロジェクトの規模が大きくなってきたと感じているなら、PlatformIOへの移行を検討してみてはどうでしょうか。
本日も最後までお読みいただきありがとうございました。
それでは、よいIoTライフを！
参考情報：
