非エンジニアが小型ロボットのAIを入れ替えた話（ｽﾀｯｸﾁｬﾝ×Gemini Live API）
※この記事は技術解説ではなく、プログラミング初心者がｽﾀｯｸﾁｬﾝのファームウェア更新に手を出し時間を溶かした反省内容をまとめた記事です。
どうも。2026年も半分が過ぎようとしていることに驚いている私です。
今回はｽﾀｯｸﾁｬﾝをより使いやすくするために、中身のファームウェアを書き換えてみました。ｽﾀｯｸﾁｬﾝのセッティングは以前行ったものの、日本語の回答はいまいちで、改良したいと思っていました。
やったこと
Codexに相談して新生ｽﾀｯｸﾁｬﾝの構成を検討しました。
応答を司るLLMを変えようとすると、大抵は費用がかかります。利用コストを抑えたいので、ローカルLLMかGeminiを候補に挙げて、最終的に、Gemini Live APIを使うことにしました。
※GeminiはAPIを無料で発行できますが、やり取りは学習に使われる可能性があります。
また、GitHubで公開されているAI Stack-chan Exのファームウェアをアレンジしてｽﾀｯｸﾁｬﾝに搭載。話しかけると綺麗な日本語で応答できるようにしました。
手順は以下の通りです。
・ローカルLLMをダウンロードして動かしてみる。
→ PCスペック不足で挫折
・Gemini Live APIを使うために、Google AI StudioでAPIキーを取得
・GitHubのAI Stack-chan Exのファームウェアを取得し、アレンジ
→ 嵌ってしまい時間が溶けました。
・ｽﾀｯｸﾁｬﾝに実装
当初「ローカルLLMが使えたら、ｽﾀｯｸﾁｬﾝに渡せる情報が増えていいよね」と思っていたのですが、私のWindows ノートPCではスペック不足で動かなくなり挫折しました。
それでも、GeminiのAPIキー取得までは比較的スムーズに進みました。
しかし、ファームウェアの設定で苦戦しました。そのまま実装しただけではｽﾀｯｸﾁｬﾝが起動せず、解消にかなり時間がかかってしまいました。
今も日本語応答はできるけど首は曲がらない（サーボが動かない）という後遺症が残っています。
ｽﾀｯｸﾁｬﾝ、交通事故にでも遭った？
ファームウェアの更新方法のコツ
今回、AI Stack-chan Exを最初にそのまま入れたところ、起動しなくなってしまい原因がわからず、あれこれ試すことになりました。
私はファームウェアを書き換えるという経験が数えるほどしかなく、GitHub上にある他の人が作ったものをどういじればいいのか、ファイル構成がどうなっているのかも知らないままスタートしました。 起動しなくなったときに取るべき手順がわかっておらず、闇雲に作業してしまったと感じています。
ファームウェアの修正はどう進めればよかったのか、ChatGPTと一緒に考えてみました。
AIにゴールだけ示して「直しといて」でも動くようになる気はするのですが、詰まった場合に備えてポイントごとにチェックする方法は押さえておくのがいい気がしています。
ファームウェア更新の大前提を知る
基準作り
原因分析①：ハードが壊れていないことを確かめる
原因分析②：機能別の差分を見る
原因分析③：構成マップ
機能ごとの最小テスト
修正計画作り
プログラムの修正
ファームウェア更新の大前提を知る
個人でファームウェアを書き換えるときは修正がつきものだと知りました。
これまで公式が出しているある程度動作保証されたプログラムを使うことがほとんどで、公開されているものを使って動かないこともあるというのを初めて知りました。
インストールしたものが動かないと途方に暮れてしまいますが、「そんなもんだ」と気楽に構えるのが大事だと感じました。
基準作り
基準を作り、動かなくなっても戻れる場所を作ります。
対象フォルダはGit管理しておくのが重要だと思いました。
原因分析①：ハードが壊れていないことを確かめる
可能性として低いものの、マイクやスピーカー、液晶画面などハードウェアが壊れているとソフトウェアをいくら更新しても動きません。
もしハードの故障が疑われるときは、面倒でも一度出荷時のファームウェアに戻して、それぞれが動くか確かめます。
原因分析②：機能別の差分を見る
ハードに問題がなければ、ファームウェアの中身をチェックします。
今回出た症状は以下3点でした。
・LCDが点かない
・マイクが反応しない
・タッチが反応しない
ファームウェアのファイルは数が多いので、機能単位で公式版と変更版で何が違うかを見るのが良いそうです。
原因分析③：構成マップを作る
馴染みのないファームウェアをAIで触る方法としてChatGPTが提案してくれたのが以下のような機能マップです。プログラミングに慣れてない人でも分かりやすそうで、ぜひ次回使ってみたいと思います。
# Firmware Map
## 起動の流れ
main.cpp
-> setup()
-> M5.begin()
-> display init
-> Wi-Fi init
-> LLM client init
-> mic/speaker init
## LCD関連
- 使用ライブラリ:
- 主な初期化関数:
- 表示更新関数:
- 注意点:
## Touch関連
- 使用ライブラリ:
- 読み取り箇所:
- UIイベント処理:
：機能ごとの最小テストをする
今回は原因が分からず、途中でログを出すためにコード変更を繰り返しました。
これを防ぐには原因分析①で挙げた各機能を確認するテスト用プログラムを作るとよいそうです。
修正計画を作る
テスト結果をもとに、コード修正をかける前に修正計画を出してもらいます。
根拠
確認方法
変更が必要なファイル候補
破壊リスク
最小確認ログ
プログラムを修正する
最後にプログラムの修正ですが、内容によって深さが異なります。
外側の浅い方から始め、徐々に内側の深い方に移すのがよいそうです。
浅い：変更しても影響範囲が読みやすい
深い：一見小さい変更でも、別の状態・タイミング・タスクに波及するもの
外側
│
├─ ビルド設定
├─ ボード設定
├─ ライブラリ設定
├─ ピン設定
├─ デバイス初期化
├─ 単体テスト
├─ 機能間の切り替え
├─ 通信・再接続
├─ 状態管理
├─ 並列処理・タスク制御
│
内側これを踏まえると、修正順序は以下のようになります。
第1段階：環境・ボード設定
第2段階：初期化
第3段階：状態遷移
第4段階：LLMやAPI連携
参考：今回変更した箇所の一覧表（API設定以外）
もっとシンプルな修正方法があるかもしれませんが、参考まで。
ファームウェア変更以外の学び
ローカルLLMの使いづらさ
16GBやGPUなしだとローカルLLMでは応答速度が遅くて使いづらいと分かりました。
以応答速度の遅さは以前Gemma4 E2Bでも試した時に実感していました。最近になって、より少ないメモリで動かせる量子化対応トレーニング（QAT）済みのモデルというのが出たので、「ワンチャン使えるか？」と試しにインストールしてみました。
しかし最初に挨拶しようとしただけで、かつてないほどPCが発熱しフリーズし夢は打ち砕かれました。ローカルLLMを使うにはPCに投資しないとだめです。（今更）
Gemini Live APIの応答の速さ
ｽﾀｯｸﾁｬﾝに話しかけると、音声は一度文字に変換され、それがLLMで回答を生成されて、またそれが音声になって返ってきます。（STT・LLM・TTS）音声と文字の変換が2回行われるので、音の細さというのは課題になるだろうと感じていました。
しかし、Gemini Live APIを使うことで、開発者側で STT→LLM→TTS を別々に組み合わせる必要が減り、応答は数秒待つだけに短縮されます。Geminiで決まっている声しか使えないという不自由さはありつつ、使い勝手はいい仕組みだと感じました。
ずんだもんのような人気の声に変えるには、STT・LLM・TTSにしてVOICEVOXで声を設定する必要があります。これはこれで興味があるので、いつかやってみたいです。
感想
うっすら感じていたことではありますが、ハードウェアが絡むと考えることが増えます。
今まで簡単なプログラムを作るのにもエラーが出ては解消する作業を繰り返してきました。そこからさらにハードウェアを動かそうとすると、エラーが出たときに何が原因か判別するのが難しくなると分かりました。
時には「SDカードが古いから処理スピードが遅い」「Wi-Fiがたまたま繋がらなかった」なんてエラーも出ました。「そんなことでエラーになるのか！！」という驚きの連続でした。
しかし、自分であれこれやると理解は深まりますし、手こずったことで理想的な進め方、AIへの指示の出し方を考えることができました。ｽﾀｯｸﾁｬﾝは可愛く手軽に扱えるところが気に入っており、今後も首の治療や機能追加を試してみたいと思います。
【参照サイト】
AI_StackChan_Ex
https://github.com/ronron-gh/AI_StackChan_Ex
ｽﾀｯｸﾁｬﾝの元々の構成を知る
https://note.com/aoya_uta/n/n60a103ebf259
ChatGPTとGemini Liveの応答速度の比較
https://note.com/noiltex_blog/n/n2019d83e5316
