みなさん、こんにちは。
昨日、私はエンジニアとしての「悪夢」を見ました。丸一日、画面に並ぶ真っ赤なエラーメッセージと格闘し、最終的な成果はゼロ。かつて完璧に動作していたプログラムが、時の流れ（という名のアップデート）によって無惨に破壊されていたのです。
今回は、初代M5Stack（Gray）を最新の開発環境で動かそうとした際に直面した「互換性の地獄」と、そこから得た教訓についてお話しします。
何が起きたのか
以前、初代M5Stack Grayで環境センサー（DHT12 + BMP280）を使い、データをAmbientへ送信するシステムを運用していました。
最近、同様の構成で動かしていたM5StickCの調子が悪くなったため、「予備のM5Stack Grayに入れ替えよう」と思い立ったのが事の始まりです。当時は何の問題もなく動作していたコードです。ただひとつ、当時から現在までに「山のようなアップデート」があったことを除いては。
最新の Arduino IDE 環境（ESP32 ボード 3.3.3 / M5Stack ライブラリ 0.4.6）でコンパイルを試みたところ、次々とエラーの連鎖が発生しました。
終わらないエラーの連鎖
直面したエラーの一部を挙げます。これらはすべて「解決策なし（あるいは絶望的）」という結論に至りました。
1. rom/miniz.h が見つからない
fatal error: rom/miniz.h: No such file or directory
ESP32 コアとM5Stack ライブラリのバージョン互換性が完全に崩れています。
2. M5UnitComponent ライブラリの設計不良
fatal error: M5UnitComponent.hpp: No such file or directory
最新の M5Unit-ENV ライブラリが、存在しないヘッダを参照しています。
3. 依存関係の解決不能
M5Stack 0.3.9 や 0.4.4 をインストールしようとしても、「ESP32CANがない」「MODULE_GRBL13.2がない」といった未解決の依存エラーでインストールすら拒否されます。
4. 致命的な GPIO 未定義エラー
error: ‘GPIO’ was not declared in this scope
M5Stack/src/utility/In_eSPI.h 内で、ESP32コアの内部レジスタを直接叩いている箇所が、現在のコアバージョン（3.3.x）の仕様変更によりコンパイル不能になっています。
M5StickC は動くのに、なぜM5Stack Gray はダメなのか？
不思議なことに、同時期にリリースされた M5StickC なら、今でもほぼコード修正なしで動きます。この差はどこにあるのでしょうか。
- ライブラリの簡潔さ： M5StickCは設計がシンプルで、依存性が少ない。
- メンテナンスの集中： M5Stickシリーズはバリエーションが限られており、メーカー側の保守が届きやすい。
対してM5Stack（Core）シリーズは、BASICからGray、Fire、Core2、CoreS3と次々に新ハードがリリースされます。最新ライブラリは常に「最新機種」をターゲットに最適化されるため、旧機種との互換性は置き去りにされているのが現状です。
結論 – M5Stack Gray を「業務」で使うべきではない
今回の経験から、私は確信しました。ホビーならまだしも、仕事でM5Stackを使い続けるのは非常に危険です。
❌ 使ってはいけない4つの理由
- 互換性がほぼゼロ
Basicは最新のボード定義（ESP32 3.3.x）では確実にビルドが通りません。今後の機種でも同様のことが起こる可能性が高いです。 - アップデートの拒絶
M5Stackは新製品サイクルが非常にはやい機種なので、数年内にセキュリティ修正やバグ修正の恩恵を受けられなくなる可能性が高いです。 - 新しいセンサーとの断絶
新しいUnitを使おうとした場合、古い機種では土台となるライブラリが壊れているため導入できません。 - 開発効率の低下
本来の目的（サービス開発）ではなく、環境構築のトラブルシューティングに数時間を溶かすことになります。
「IoT製品は10年使うこともある」
その視点に立ったとき、この互換性の脆さは致命的です。なぜMicrosoftが（時に揶揄されながらも）業務で支持されるのか、その「後方互換性」への執念の価値を今さらながら痛感しました。MSX規格を提唱した西和彦氏がハードウェアメーカーに問いかけた「互換性の維持」は、今こそ考え直されるべき課題です。
それでもM5Stackを使い続けるユーザーが取るべき「3つの選択肢」
初代M5Stack Basic/Gray をお使いなら、早急に次のいずれかを選択する必要があります。そしてハードを買い替えても2年に1度程度はこの選択肢を再評価する必要があることを忘れてはいけません。
| 選択肢 | 内容 | メリット | デメリット |
| 1. 環境を凍結する | IDE 1.8.19 / ESP32 1.0.x 等で固定 | 確実に動く | 新機能不可 / セキュリティリスク |
| 2. ハードを買い替える | CoreS3 等の最新機種へ移行 | メンテナンスが容易 | コスト増 / コード修正が必要 |
| 3. エコシステムを離れる | 純粋なESP32基板等へ移行 | 互換性の問題が少ない | 開発の手間が増える |
古いものを使い続けるのは「悪」なのか？
M5Stackチームが古いハードのためにリソースを割くことは、おそらくないでしょう。これはテクノロジー業界の宿命かもしれません。
「古いものは動かなくて当たり前。常に最新へアップデートしろ」
それは正論ですが、果たしてそれがすべてでしょうか。良い製品が時代を超えて使い続けられるはずの現実世界において、デジタルデバイスだけが数年でゴミになってしまう。コンピューターの仕事をしていると麻痺してしまいますが、これは本来とても不自然なことです。
古いものを大切に使い続けることが「悪」とされない未来を、もう一度考え直す時期に来ているのかもしれません。
本日も最後までお読みいただきありがとうございました。
それでは、よいIoTライフを！
ピンバック: M5StickCからM5AtomS3へ！環境センシングシステムを最新技術で小型・効率化したお話 - ビューローみかみ