腕時計ローカルAIｽﾀｯｸﾁｬﾝを作ったら組み込み開発の罠にハマった話

2026.6.28 ローカルAIと向き合う展⽰会 Vol.2 のLTで発表した内容です。
発表時の台詞に合わせて当日のスライドから若干修正しています。

Transcript

1. Slide 1 / 13 改めまして、ほーきーと申します。LTのト ップバッターということで若干緊張してお りますが、普段はXのほうでいろいろつぶ やいております。1日数十ポストぐらい、 平均でつぶやいておりまして、いわゆるツ イ廃と呼ばれる部類です。AI関連の資格を いくつか持っています、という「ちゃんと 仕事しています」アピールをしておこうと 思って、ここにバッジを載せております。
2. Slide 2 / 13 今回は「ローカルAIと向き合う展示会」と いうことですが、ローカルAIそのものから は若干外れた、番外編のようなテーマです 。ローカルAIに家の外からアクセスしよう としたらどうなるか・ということで、「腕 時計ローカルAIｽﾀｯｸﾁｬﾝを作ったら組み込 み開発の罠にはまった話」という題材を選 んでいます。
3. Slide 3 / 13 腕時計ローカルAIｽﾀｯｸﾁｬﾝとは何ぞや、と いう話ですが──前提として、AIｽﾀｯｸﾁｬﾝ というものがありまして。右側にあるよう な、こういう顔があって……それがｽﾀｯｸﾁｬ ﾝというキャラクターです。M5Stackとい うメーカーが出している、マイコンにディ スプレイとセンサーがまとまって付いたデ バイスに、こういう顔を表示するのが「ｽﾀ ｯｸﾁｬﾝ」で、元々はメーカー発ではなくコ ミュニティ発のものです。
4. Slide 4 / 13 そのｽﾀｯｸﾁｬﾝに、AIを使ってしゃべらせる というのが『AIｽﾀｯｸﾁｬﾝ』です。今回はそ れをさらに、AIをクラウドではなくローカ ル完結でやることと、腕時計としてｽﾀｯｸﾁｬ ﾝを身に着けて持ち運ぶことを実現しよう と取り組みました。 構成としては、自宅のローカルマシンでAI を動かしたうえで、家にいるときは、この ｽﾀｯｸﾁｬﾝが動いているCore2というデバイ スからWi‒Fiで直接通信します。外出したと きはWi‒Fiで直接入れません。ちなみに、サ ーバー側をそのままグローバルに晒すのも 怖すぎるので、VPNを張ったうえで、その VPNに参加しているAndroidスマートフォ ンを使います。スマホは普段持ち歩くので 、スマホとこのｽﾀｯｸﾁｬﾝのパーツをセット にして持ち運び、外出時はこれをUSBでつ ないで、ローカルのAIにアクセスする構成 にしています。
5. Slide 5 / 13 で、さきほどの構成図を見て疑問に思われ たかもしれません。 そうですね、Core2をVPNに参加させれば 、もっとシンプルな構成にできます。
6. Slide 6 / 13 私も最初は、Androidスマホをわざわざ経 由せずに、Core2をVPNに参加させればい いのではないかと考えました。そうすると 、全部Wi‒Fi経由で、しかもスマホのアクセ スポイントにWi‒Fiでつなげば、家の中でも 外でも同じ環境でできるので、シンプルな 構成になります。
7. Slide 7 / 13 しかし、このM5StackのCore2というデバ イスは、WindowsでもMacでもLinuxでも Androidでもありません。OSが動いている わけではなく、ファームウェアで動作を制 御する代物です。 私が使っているTailscaleというサービスも Core2には対応しておらず、VPNクライア ントも当然ダウンロードできません。
8. Slide 8 / 13 そこで「どうする…？」と考えました。 さすがにTailscaleのクライアントをスクラ ッチ実装するのはやりすぎかなということ で、さきほどの構成にすると決めました。 ただ、Androidにアプリを載せてCore2と 通信しようとすると、アプリを自作するだ けではなく、通信プロトコルも自作しなけ ればならない──という大きなハードルが ありました。とはいえ他にやりようがない ので、この構成でやってみました。自作ア プリと自作プロトコルで実装です。
9. Slide 9 / 13 このAIｽﾀｯｸﾁｬﾝは、音声で話しかけるとｽﾀｯ ｸﾁｬﾝがしゃべるというものです。実装はだ いたいAIに丸投げしていて、コーディング が終わりました。ファームウェアも書き込 みました。そこで、いざ試してみました。
10. Slide 10 / 13 短い文で試してみようと思って「元気です か？」と話しかけると、ｽﾀｯｸﾁｬﾝは、何を 言っているかわからない音声を返してきま した。 音声が再生できていないことだけはわかる 、という状態です。これが昨日か一昨日の 夜中くらいの状態でした。 Wi‒Fiのときはちゃんとしゃべれていたので 油断していたのですが、自作プロトコルに したらうまく音声が再生できないというこ とになり、「なぜなのか」ということをア プリ側にデバッグログを追加しながら、い ろいろ調べていました。
11. Slide 11 / 13 Wi‒Fiでは再生できていたのに有線通信にす ると再生できないのはなぜなのか── 音声が送られる経路の概略図は、この通り です。 ローカルAIサーバーマシン側で動いている Text‒to‒Speechで合成されたオーディオ が、Androidスマートフォンに送られてき て、それがデバイスに送られる、という経 路です。 ただ、スマートフォンのリレーアプリがオ ーディオファイルをCore2に送るとき、フ ァイルを1回の通信では送れません。オー ディオファイルのサイズがそれなりに大き いため、1024バイト単位のチャンク(送信 しやすいサイズに小分けした塊)で、アプリ からデバイスにオーディオが送信されます 。
12. Slide 12 / 13 今回は、Core2側がそのチャンクをうまく受け取れて いませんでした。Androidアプリ側からデバイスに送 ろうとしている速度に対して、デバイス側が受け取る 速度が遅く、受け取りきれないパケットがたくさん発 生してしまいました。その結果、音が途切れ途切れに なったり、そもそもデコードできないというエラーが 出たりする状態になっていて……それを今朝から会場 でデバッグしていました。 【後記】 その後の調査で、Core2が受信できる帯域を超えたサ ンプリングレートのファイルが送信されており、そも そも原理的に受信するのが不可能であったと判明しま した。 ハードウェア制約により、通常のUSBでの有線通信で はなく、マイコン用のシリアル通信を利用しており通 信速度が遅いため、高品質なオーディオデータを受信 できませんでした。 そこで、TTSが生成するオーディオの品質を落とし、 シリアル通信でCore2が受信可能なレートまで抑える ことで、無事に音声が再生できるようになりました。 （このあたりの数字を含めた話は、別途時間があると きに記事にします）
13. Slide 13 / 13 感想としては、やはりハードウェアが絡む と制約条件が増えてくるので…… ソフトウェアと同じノリで「こういうこと はできるだろう」とカジュアルに考えても 、事前によく調査しないと、こういう落と し穴にはまります。 事前の下調べをじっくり行い、過去に問題 を乗り越えてきた先人たちの苦労と資産(ア セット)と涙をありがたく恩恵として受け取 りながら、Vibesだけで取り組むのではな く、きちんと設計をして開発に取り組むこ とが改めて重要だとわかりました。 皆様もこういう点にご注意ください。以上 でLT終了とさせていただきます。ありがと うございました。