なぜ音声入力アプリは最初のひと言を食べてしまうのか

ホットキーを押す。話し始める。すると文字起こしは 2 語目から — ときには 3 語目から — 始まっている。「リトライ処理をリファクタリングして」が「処理をリファクタリングして」になる。「あとでマージして」が「マージして」になる。これは、自分の代わりに打ち込まれるには本当に危険な文です。この失敗は、OS 標準の音声入力から専用の音声入力ツールまで、コールドスタートするマイクの経路であればどこでも簡単に再現できます。

人によって言い方は違います — 「頭が切れる」「話す前に一拍おかないといけない」「最初の単語がいつも消える」 — けれども現象はひとつで、一度やられると、誰もが編み出す回避策を自分も編み出すことになります。キーを押して、一拍待って、それから 話す。つまり、道具の埋め合わせのために、小さな迷信じみた儀式を一日に何十回も演じているわけです。本来は逆であるべきなのに、道具の側が人を訓練してしまっている。

私も他のツールで何か月もその儀式をやっていました。Keebye を作るにあたって、これを潰すことは最初のリストに入っていました。というのも、その修正には、ほとんどのアプリが飲まないであろう居心地の悪いトレードオフが必要だと分かったからです — そしてそのトレードオフについても、修正と同じくらい率直に話したいと思います。

なぜ最初のひと言が切れるのか

これは特定のベンダーの雑さではなく、カテゴリ全体の問題であり、物理は単純です。マイクは瞬時ではありません。

音声入力アプリが素朴なやり方で録音を始めるとき — ホットキーを押して、それから マイクを開く — 最初の音声サンプルが取り込まれるまでに、ひと続きの処理が走らなければなりません。OS のオーディオセッションを初期化する。入力デバイスを起こす。ハードウェアによっては、文字どおりのウォームアップ時間が要ります。ストリームのフォーマットが交渉され、バッファが確保され、最初に届くバッファはたいてい捨てられるゴミです。マシンとデバイス次第で、この連鎖には「一拍」から数秒までの幅があります。

その間、すでに考えのまとまっている人間であるあなたは、指がキーに触れた瞬間に話し始めます。実際には、その瞬間より わずかに前 であることが多い。押そうという意図と話そうという意図は脳から一緒に出ていくので、発話の立ち上がりはアプリの準備を日常的に追い抜きます。ストリームが生きる前に言ったことは、アプリにとっては存在しなかったのと同じです。取り込まれなかった音声をモデルが文字起こしすることはできません。だから「処理をリファクタリングして」になるわけです。

では、なぜアプリはマイクを構えたままにせず、必要になってから開くのか。ほとんどは行儀の良さです。マイクを開いたままにすると少し電力を食いますし — もっと大事なことに — OS のマイク使用インジケータが点灯します。ユーザーがそれを「このアプリは私の話を聞いている」と読むのはもっともです。必要なときだけマイクを開けば、インジケータは正直なままで、アプリも礼儀正しく見えます。その代償が、録音の始まりにおけるコールドスタートのリスクです。

修正：キーを押した時点で、すでに聞いているマイク

Keebye はこれを両側から攻めます。ふたつの仕組みは問題の別々の半分を解いているので、分けて説明する価値があります。

温まったマイク。 セッション中の最初の録音のあと、Keebye はオーディオ入力ストリームを開いたままにします。つまり、コールドスタートの連鎖 — セッションの初期化、デバイスの起動、ストリームの交渉 — は、そのストリームが健全であるかぎり、以降の音声入力より前にすでに済んでいます。指が動く前から、ストリームは生きています。

プリロール。 温まったストリームはアプリの遅れを直しますが、あなたの側の早さは直しません — 発話の立ち上がりはキーを押すより先に来ることがある、という話です。そこで Keebye は、直近の音声を 500 ミリ秒ぶんローリングバッファに保持します（16 kHz で 8,000 サンプル、リングバッファです）。ホットキーを押すと、その直前 0.5 秒の音声が発話の先頭に流し込まれます。そのバッファの中で始まった音声は、キーを押す前に捨てられるのではなく、文字起こし側で使えるようになります。

合わせた結果はこうです。2 回目以降の音声入力では、温まったストリームと 500 ミリ秒のプリロールが、キーを押す直前あるいは同時に話し始めるという一般的なケースをカバーします。その境界の内側では、儀式の一拍は要らなくなります。録音開始の 0.5 秒より前に話された言葉を取り戻すことはできませんし、セッションの最初の音声入力には、通常どおりストリーム起動のレイテンシがかかります。

トレードオフを、はっきり言うと

ここは埋もれさせるつもりのない部分です。設計の正直な代価だからです。音声ストリームが音声入力と音声入力の間も開いたままである以上、音声入力していないときも macOS はマイクを使用中として表示します。 オレンジ色のドットは点いています。コントロールセンター（Control Center）を開けば、あなたが何もしていないまさにその瞬間に、Keebye がマイク使用中として並んでいます。

その間に実際に起きていること。音声は 500 ミリ秒のリングバッファに流れ込み、絶えず捨てられています。文字起こしはされません。保存もされません。キーを押すまで、バッファから出ていくものは何もありません — そして 0.5 秒より古いものは、リングに上書きされて永久に消えます。とはいえ、インジケータが嘘をついているふりをするつもりはありません。嘘ではないからです。ストリームは開いていて、「いつでも聞ける状態」というのはこのアーキテクチャの公平な説明です。頼まれるまで、意味のある形では何も聞いていないとしても。

私はこのトレードオフを、目を開けたまま意図的に選びました。理由はこうです。必要なときにマイクを開く方式は、毎回コールドスタートのリスクを持ち込みます。切れた言葉、間違った文、身についてしまった一拍。温めたストリームの設計は、オレンジのドットに対するあなたの心地よさにコストを寄せる代わりに、筋道を追えるアーキテクチャに支えられています。テキストのみのローカル履歴（音声入力がただ消えてしまってはいけないに書きました）、オンデバイスの文字起こし、音声はいっさい保存しない、リングに残るのは 0.5 秒。私はドットを受け入れます。受け入れられないなら — それも真っ当な立場ですし、実際に別のツールの方が正解になることもあります。Keebye vs Superwhisper と Keebye vs Wispr Flow のページは、まさにその判断のために書いています。

ふたつの境界、驚かれないように

セッションの一番最初の音声入力には、通常どおりストリーム起動のレイテンシがかかります。 マイクが温まっているのは、すでに録音が一度あったからです。最初の一回はセットアップの代価を払います。以降の音声入力は、ストリームが開いているかぎり恩恵を受けます。

プリロールは 500 ミリ秒であり、500 ミリ秒は一拍であって一文ではありません。 バッファがカバーするのは自然なケース — キーを押すほんの少し前に始まった言葉です。まるまる一文を言い切って、それから キーを押すことを思い出したなら、先に出た言葉は消えています。設計上そうしています。リングが保持するのは常に 0.5 秒だけで、それは、アイドル中のアプリが意味のある音声を保持しないためです。プリロールを長くすれば、うっかりした話し始めをもっと拾える代わりに、周囲の音声をもっと長くメモリに残すことになります。0.5 秒が、私がその線を引いた場所です。

0.5 秒が、聞こえよりも大事な理由

切れた最初のひと言は、小さなバグに見えます。Keebye が作られた並列レーンのワークフロー — 複数の AI エージェントと複数の人間との会話を同時に動かす制御チャンネルとしての音声、子ども 2 人、スタートアップ 3 社、声はひとつで描いた一日 — では、音声入力は一日に何十回も、まとまった単位で、コンテキストスイッチの合間に起こります。儀式の一拍を要求する道具は、そのすべてに税をかけ、さらに悪いことに、ときどき意味を反転させたうえで送信します。「マージして」が笑えたのは、一度きりでした。

このカテゴリにおける信頼性は、ひとつの大きな機能ではありません。小さな安全策の積み重ねです。話し始めの音声のためのプリロール、文字起こしの背後にある履歴、そして復旧できる挿入経路。この記事は 1 つ目についてで、履歴の記事が 2 つ目を扱っています。

Keebye は macOS 向けに早期アクセス中です。下から無料トライアルを始めて、2 回目以降の音声入力で「あとでマージして」と言い、最初のひと言が生き残るか確かめてください。テストはそれだけです。