PlaudっていうAIボイスレコーダー、社内の一部のメンバーが使っているのだけど、私は使ったことがないんですよね。ちょっと羨ましい。ぶっちゃけスマホでええやんって思うんですが、やっぱ専用デバイスでボタンをぽちっとすればすぐに録音が始まるのは便利ですよね。特に録音なんてものは、サッとできてこそ。ということでAIボイスレコーダー（命名 Taroud）を作ったので、その話を書きます。
Ubieテックアドベントカレンダーの24日目のエントリーですが、アドカレというよりもハッカソン的なノリの内容で ネタ枠 です。
構成・全体像
スマホとは別の独立したデバイスを使おうということで、M5StackのAtom EchoというIoTマイコンを使います。Atom Echoの理由は、たまたま持っていたからです（オフィスに常設されている銅鑼が鳴らされたことを検知するために、以前、秋葉原で3,000円くらいで買ったものです）。Atom Echoは、ボタン、LED1個、マイク、スピーカーを持っており、Wifi接続が可能です。
実現したい体験は次のとおり。
シンプルですね。サッと録音を開始して、終了できる。終了したら勝手に要約が生成されるのもいいですね。
その他の登場人物
- Supabase
- Database: 録音のメタデータを保存
- Storage: 録音そのもの（wav）を保存
- Edge Functions: Geminiを叩いてSlackに通知する
- Gemini: 音声ファイルから要約を得る
- Slack: 要約完了の通知と、要約を見るためのインタフェース
最初は画面を作る気満々でしたが、バックグラウンドからの通知を実装するのが面倒だと思ったのでSlackをまるっと使うことにして、画面の作成を省略しました。
実現したい体験を絡めた、各登場人物のインタラクションは次のようになります。
記事を書くに際して、この絵をGeminiに投げて、シーケンス図を表現するMermaidを出力してもらいました（少し手を加えています）。
Atom Echo
2回目のボタン押下、すなわち会話・録音の終了の前に、WAV書き込みを行っています。この図では一度きりに見えますが、頻度高く何度も行います。これはAtom EchoのRAMの小ささからそのようにしています。
RAMやストレージが十分に大きければ、録音をたっぷり溜め込んだあと、一度だけアップロードすればOKです。しかし、実際にはそうはできません。Atom EchoのRAMは520KB、ストレージは4MB（プログラム領域を考慮するとWAVが保存できる領域はもっと少ない）。なので、録音したデータをAtom Echoに長く留めておくわけにはいかないのです。
今回の実装では、RAMに音声（8kHz。昔の固定電話と同じ）を保存しておき、2.9秒ごとにアップロードしています（3秒だと失敗することが多かった）。
最初、この高頻度のアップロードで、その度にconnect（SSLハンドシェイク等）が発生し、そのオーバーヘッドが録音の品質に悪影響を与えていました。とても聴けた音じゃない。ここは大いにハマりました。普段のプログラミングで意識することがありませんからね。1度確立したconnectionを再利用するようにしたら、言葉を識別できるレベルの音声になりました。
Backend
さくっとサーバーレスということでSupabaseを使うことにしました。FirebaseのREST APIを直叩きするのは、Atom Echoの素朴な環境で（あと慣れない言語で）使うにはちょっと大変そうだなと。
Backend as a Serviceをライトに使うだけなので、特筆することはないんですが、やってることを少しだけ説明します。
録音ステータスはDatabaseで管理し、実際の音声データ（細切れのWAV）はStorageに保存します。録音が終わると（2回目のボタン押下）録音ステータスをfinishedに書き換えます。すると、それをトリガーにEdge Functionsが呼び出されます。Edge Functionsでは、細切れのWAVを繋げて、1つのWAVにします。これを音声ファイルのまま（実際にはbase64）Geminiに投げて（今回はgemini-2.5-flashを利用）要約テキストを取得します。これをWebhookを使って、Slackに投稿する、という流れです。
細切れWAVを繋げて、1つのWAVにまとめる操作をバックエンドで行うのであれば、それを前提として、細切れWAVをヘッダー情報を持たないPCMにするということも検討しました。 Atom EchoのRAM節約にもなると思い、少し期待したのですが、一瞬で却下しました。 細切れWAV（一時的に溜めている音声データ）のサイズは46,400bytesなので、そのうちの44bytesを節約しても無視できるほどの効果です。 また、Storageにアップロードされた音声ファイルの品質をチェックするために、SupabaseのWebUI上で再生して確認するには、PCMではなくヘッダー情報を正しく持ったWAVである必要があったからです。
できたもの
Atom Echoはバッテリーを持っていないので、モバイルバッテリーなどと繋いで給電してやる必要があります。いざ、接続！
起動すると、Wifiに接続して、待機中である旨を示すLEDが青色に点灯します。ボタンを押すとLEDが赤色に変わり、録音が始まったことがわかります。5歳の娘とちょっとした雑談をしてボタンを押すと、再び待機中としてLEDが青に戻ります。数秒後、スマホにSlack通知が届き、要約が完成したことを知らせてくれます。
あとがき
実用性はない。
と思ったが、Atom Echoが3,000円で、Supabaseが無料で、Geminiが従量課金で駄菓子程度の費用ということを考えると、Plaudほどスマートな体験にはならないとはいえ、その代替としては検討しうるか。
ガチるならスマホアプリを作った方が断然いいですね。カメラアプリのシャッターを切るbluetoothボタン（電池入り）を使ってみると面白そう。500円くらいで手に入ります。シャッターを切る操作＝音量上げキー押下なのでそれをバックグラウンドにいながらリッスンできたら、物理ボタンから一瞬で録音をスタートできて、やりたかったことに近づけます。
ということでAndroidアプリも作った
ボタンひとつで録音が開始するのが、やはり体験として最高だったので、どうしても実用的なものが欲しくなりました。
Androidであれば、 AccessibilityService を使ってボタン押下をグローバルに取得できます。
本来はその名のとおり、アクセシビリティを目的としたもので、アプリに対して強い権限を与えるので、目的外の使用ということでアプリストアで配布することはできないでしょう。
なので、あくまで自分用。
右手に持っているのが、カメラのシャッターを切るbluetoothボタンです。 これを押すと、どんなアプリが開いていようと、あるいは画面が閉じていようと、自分のアプリがそのイベントをキャッチしてくれます（そうなるように実装したということです）。 結果、録音がスタートします。画面上部に録音のnotificationが出現しているのがわかると思います。
話し終えた後、もう一度ボタンを押せば録音が停止します。 Wifi環境下では、録音を停止したあとに自動的に要約処理が走るようにしました。モバイルネットワークでは"ギガ"を節約するために何もしません（手動でも要約リクエストを投げられるようにしている）。
要約処理が完了すると通知されます。 通知をタップすると、その内容が確認できます。
なお、カメラのシャッターを切るbluetoothボタンは、一定時間（数分くらい？）ボタンが押されないとスマホから切断されます。 接続するにはボタンの長押しが必要です。 そのため、bluetoothボタンでサッと録音するのはあまり現実的ではないかも。 それでも、スマホの音量を上げる物理ボタンを押すこととイベントとしては同義なので、スマホのボタンをポチッとするだけという手軽さはあります。
