AIの返事を43秒から10秒にした工夫

MuseとM5Stack StopWatchで、「持ち運べるずんだもん」を作りました。
最初は声が返るまで43秒。今は長めの返事でも約10秒です。

この記事で持ち帰ってほしいのは次の3つです。

1. 待ち時間を区間に分けて測ると、縮める場所が分かる
2. 返事を文ごとに分けて声にするときは、1つ目の長さで「早さ」と「途切れなさ」を選ぶ
3. 速くなったかを測るときは、キャッシュと前回のファイルに気をつける

同じようなものを作っている方から、Xで応答を速くするために何をしたのかと質問をいただきました。
その答えを詳細に書いた記録です。
測った数字はすべて実機とVMのログから出しています。

1. 質問をいただいたデバイス

ボタンを押して話しかけると、Museの返事がずんだもんの声で返ってくる、手のひらサイズの時計型ガジェットです。
(以降、本記事では時計と呼びます)

Museは、Metaが2026年9月に出した個人向けのAIエージェントです。
自分専用の仮想マシン（VM）を持ち、そこで作業します（Mercado）。

2026年10月には、Muse用の機器を自作できるSDKが公開されました（TechCrunch、muse-gadget-sdk）。
M5StackのStopWatch（丸い画面とマイク、スピーカーを持つESP32-S3のボード）にも対応しています。

公式のSDKは、返事が文字で届きます。
なので、MuseのVM上で作った声を、時計が読みに行く形で実装しています。

時計のファームウェアはClaude（Claude Code）が、VMのブリッジはMuse本人が作りました。
人間は実機確認です。
※ClaudeとMuseは、GitHubのIssueに書き込んでお互い相談して進めてもらいました。この記事の数字も、2人がお互いにログを突き合わせながら算出しています。

2. まず43秒を区間に分けた

速くする前に、待ち時間がどこで使われているかを測りました。
時計のログ、Museの会話の記録やログの時刻を並べています。

最初に声が出た10月30日の1往復は、こうでした。

区間	時間	持ち場
声を送って、サーバーが受け取る	約1〜2秒	時計とサーバー
考える（声のメモが記録に入る → 返事が記録に入る）	23.4秒	Muse
声を作る（返事が記録に入る → 声ができる）	約18秒	VMのブリッジ
合計（ボタンを離してから最初の声まで）	43秒

待ちの大半は、Museが考える時間と、VMが声を作る時間の2つでした。
なので、工夫もこの2つに絞りました。
加えて、UXの観点から、待っている間の表現も少し入れています。

いちばん新しい11月3日の回では、513バイト（171字）の返事で9.95秒でした。10月30日の返事は357バイト（127字）だったので、返事は4割ほど長くなっています。

縮んだ33秒の内訳は、考える時間が18.0秒、声を作る時間が約14秒、残りが約1秒です。工夫の数は声を作る側のほうが多いのですが、縮んだ秒数では考える側が上回りました。

ただし、これは別の日の別の質問を1回ずつ比べた数字です。考える時間は質問と文脈で大きく変わるので、18秒がすべて工夫の効果とは言えません（日ごとの中央値は4節）。

3. 声を作る側でやったこと

返事を文ごとに分けてできた順にしゃべる

いちばん効いたのは、返事をまとめて声にせず、文の部品ごとに作って、できた順に時計がしゃべる形にしたことです。
最初の声が出るまでの時間が、返事全体の長さに左右されなくなりました。

ほかの音声エージェントでも、同じやり方が定番です。話し終えてから最初の音までをTTFA（time to first audio）と呼び、ここを縮めます（ElevenLabs）。

同じ質問で比べると、差はこうなりました（11月5日、5問の中央値）。

形	文字が揃ってから最初の声まで	部品の間の無音
① 全文の形（10月30日の形）	7.1秒	なし（1つの音声）
② 昔の文ごとの形（1つ目15〜20字）	3.2秒	5回中2回（0.4秒、1.5秒）
③ 今の文ごとの形（1つ目24〜28字）	4.3秒	5回中1回（0.7秒）

1つ目の部品は短ければよいわけではなかった

一般には、1つ目の部品を短くすると最初の音が早く届くと言われます（ElevenLabs）。私たちも最初は1つ目を15〜20字にしました。

ところが実機では、1つ目を話し終えても2つ目が間に合わず、2.6秒と1.7秒の無音が空きました。
当時、VMで声を作る速さは約7字/秒で、ずんだもんが話す速さ（約5字/秒）とあまり変わらなかったからです。

Museは、新しい文章12本で同じ無音を再現してから、分け方を変えました。

• 1つ目を24〜28字にする
• 次の部品は、前の部品の1.45倍までにする
• 最後以外で16字未満の部品は、次の部品とつなげる

同じ質問で比べると、③の今の形は、②より最初の声が約1秒遅く、無音は減りました。早さと途切れなさのどちらを取るかは、声を作る速さと話す速さの差で決まります。

決まった返事は先に声にしておく

挨拶、相槌、確認などのよく使われる決まった19文は、消えないキャッシュに入れました。
Museも同じ文言で返すので、声はキャッシュから出すだけ（約0.01秒）です。時計で測ると、挨拶は返事の文字が届いてから1.1〜1.3秒で声が出ました。

同じ日に同じ質問をし直したときも、作った部品を使い回せます。天気を聞き直したときは、13.2秒が3.3秒になりました（VMでの計測）。

細かい待ちを1つずつ削った

やったこと	変わったこと
返事を見つけたら、すぐ声を作り始める	0.5秒ごとの見回りをやめた。平均0.5秒、最大1秒の待ちが消えた
時計の最初の問い合わせを早める	返事の文字が届いてから1.5秒後だったのを0.8秒後に
MP3にする処理を、別のプロセスからブリッジの中へ	1部品あたり約0.06〜0.15秒
長さを測るffprobeをやめ、WAVの頭から計算する	この段の中央値が313ミリ秒から167ミリ秒に
起動時と、30分使わなかったときに1本作っておく	起動直後の遅い初回（35秒の例）を、だれも待たない

4. 考える側でやったこと

声を作る時間をいくら縮めても、Museが考える時間のブレは残ります。
11月1日には、Muse側の要約処理と重なった1往復に149秒かかり、時計が待ちきれずに時間切れになりました。

考える側は、速く考えることより、考え方と流れを変えることで縮めました。Museと決めたのは次の4つです。

• 時計への返事は、結論の1行を先に出す。続きは文ごとの声が追いかける
• 決まった質問には、考えずに即答する。3節の19文は、声のキャッシュであると同時に、考えを省く近道でもある
• 重い調べものは時計との会話ではしない

Museが会話の記録から出した、日ごとの考える時間（声のメモの行から最初の返事の行まで）はこうです。

日	往復	中央値	最大
10月30日	37	10.3秒	88.7秒
10月31日	32	8.4秒	55.7秒
11月1日	24	5.4秒	149.3秒（要約と重なった回）
11月2日	3	7.4秒	7.6秒
11月3日	9	2.9秒	17.5秒

中央値は10.3秒から2.9秒に下がりました。
ただし、この数字には返事の長さや質問の中身の違いも入っていて、件数も少ないです。どの工夫がどれだけ効いたかまでは分けられません。

5. 待っている間の見せ方

待ちの体感は、長さよりも「音がない」「何が起きているか分からない」で決まります。

始まる前の待ちは、始まったあとの待ちより長く感じます（Maister 1985）。待ち行列の心理を8つの原則にまとめた文章です。

人の会話の「間」は短く、これを調べた研究では、日本語の返答までの間は平均7ミリ秒でした（Stiversほか）。

会話の間に比べると、数秒の待ち時間でも、ガジェットが黙っていれば、それはかなり長く感じます。

そこで時計には、待っている間も「聞いている」と伝える動きを入れました。

• ボタンを押すと振動し、離すと画面の縁を回るリングと上を見る目に変わる
• 5秒たったら「えーっと」系の相槌を鳴らす。12秒でもう1つ、25秒からは長い待ち用を鳴らす
• ※サイレントモードを入れ、画面が見えないとき（伏せている、画面が消えている）に返事が来たら、振動して知らせる

相槌は、最初は3秒で鳴らしていましたが、試すと体感で早すぎると感じたので、5秒に延ばしています。

6. 速くなったかを測るときの落とし穴

測り方で転んだ話です。
測ったつもりで、測れていなかったことが3回ありました。

同じ文章で測るとキャッシュで速く見える

ある合成の方法を試していたとき、同じ文を繰り返し測っていると、2.10秒が0.13秒になりました。
喜んで採用したところ、その後の会話では部品の間の無音が約3.6秒に増えました。
これは、エンジン側のキャッシュが効いて速く見えていただけで、試した方法による改善ではありませんでした。

試したい機能がそもそも動いていなかった

合成を止める機能を見つけて試すと、会話の打ち切り処理が最初は速くなったように見えました。
でも調べていくと、その機能は実は無効で、404が返っていました。
速くなったのではなく、エラーで落ちていただけでした。

キャッシュを切っても前回のファイルを読んでいた

3節の同じ質問での比べ直しは、1回目に失敗しています。
検証用にブリッジのキャッシュは切っていたのですが、②と③の回で、①で作ったファイルを時計が読んでしまい再計測となりました。

時計は、返事の本文から計算したファイル名をつけ、その名前でファイルを読んでいます。今回検証用に同じ質問をしました。そのため、3つの形で返事の本文が同じで、同じ名前のファイル名になりした。
このファイル名部分は切れていなかったのです。

Museがブリッジを直し、測るときだけ、声を作る前に同じ名前のファイルを消すようにしました。そのうえで、3つの形を改めて測り直しています。

ほかにも、全文の形の文字から声までが、11月3日は11.6秒、11月5日は7.1秒でした。
別日に改めて測り直す間にエンジンを更新したので、そのおかげに見えました。

Museが記録を調べると、差は返事の長さ（中央値115字と62字）から来ていて、1字あたりの時間は変わっていませんでした。
※天気の話だってので、別日で回答が変わりました。

この3回から、測るときは次の3つを確かめることにしています。

• 新しい文章で測る。繰り返したときの速さは別に記録する
• 対象の機能が本当に動いているか（200が返るか）を先に確かめる
• 前回の結果のファイルやキャッシュを消してから測る

測って採らなかった手（5つ）

手	結果
VOICEVOXのcoreを直接呼ぶ	HTTP経由より、どの長さでも遅い
ストリーミング合成（/streaming_synthesis）	最初の音は0.4秒早いだけで、全部できるまでは73%遅い
合成の並列化	VMでは速くならず、直列のまま
同じ文に強い合成の方法を標準にする	初めての文が遅く、本番で無音が増えた。戻した
ユーザー辞書261語	測っても、決まって遅くなる傾向はなかった

7. 質問への答え

工夫について質問をいただいたのは、この投稿に対してでした。

私からの答えは4つです。

1. まず、ボタンを離してから声までを区間に分けて測った
2. 声を作る側は、文ごとに分けてできた順にしゃべり、決まった返事は先に声にしておいた
3. 考える側は、結論を先に、決まった質問は即答、重い調べものはアプリへ、と考え方と流れを変えた
4. 待っている間は、振動、目の動き、相槌で「聞いている」と伝えた

43秒が約10秒になったのは、1つの工夫ではなく、この組み合わせの結果です。

8. 最後に、自分のデバイスで試すなら

ぜひ、下記を試してみてください。

1. 次に1往復試すときは、ログに時刻を出し、離してから最初の声までを区間に分ける
2. 返事を文ごとに分けるときは、声を作る速さと話す速さを一度比べてから、1つ目の長さを決める
3. 速くなったかを測るときは、新しい文章で、前回のファイルを消してから測る

以上、皆さんの参考になりましたら幸いです。

付録

主な参考文献

• muse-gadget-sdk（Meta、Apache-2.0）
• Meta wants you to build your own Muse gadget（TechCrunch、2026-10-02）
• Meta presentó Muse（Mercado、2026-09-10）
• M5Stack StopWatch
• VOICEVOX Engine
• Voice agent latency optimization（ElevenLabs）
• Maister, D. (1985). The Psychology of Waiting Lines
• Stivers, T. et al. (2009). Universals and cultural variation in turn-taking in conversation. PNAS 106(26).

調査限界

• 数字は、私の時計1台とMuseのVM1台で測ったものです。VMの性能や混み方、Museの版で変わります。
• 43秒と9.95秒は、別の日の別の質問を1回ずつ比べたものです。同じ質問での比較（3節）は、1つの形につき5回だけなので、1秒より小さい差はたまたまかもしれません。
• 声の受け渡しは、Museの会話の記録を読むしくみに頼っています。公開された仕様ではないので、Museの更新で動かなくなる可能性があります。
• この記事は個人の工作の記録です。

AIの利用について

時計のファームウェアと、この記事の調査と下書きはClaude（Anthropic）が作りました。VMのブリッジはMuseが作りました。数字はすべて実機とVMのログに戻って確かめています。

クレジット

音声：VOICEVOX:ずんだもん