ターミナルでも生き残る音声入力

音声入力ツールを試す開発者は、しばしば非常に特徴的な形の失敗にぶつかります。デモでは見事に動く。メモアプリでも、Slack でも、ブラウザでも動く。ところがターミナルにフォーカスして一文を音声入力すると、何も現れないか、言ったのとは違う何かが現れるか、半分だけ現れて残り半分がなぜかクリップボードに入っているかのどれかになります。ローカルでは動くのに、SSH で別のマシンに入った瞬間に死ぬこともあります。

このパターンは一貫していて、特定の製品のバグだとは思えません。これは、このカテゴリがテキストを挿入するやり方の帰結です — そして、開発者が住んでいるまさにその場所で失敗します。

これは 2 年前より、今の方が重要です。Claude Code を声で動かすなら — Claude Code を声で動かすで書いたワークフローです — ターミナルは数あるアプリのひとつではありません。それが、そのアプリです。プロンプトが着地する場所であり、エージェントが軌道修正を待っている場所であり、並列レーンという話全体が成立するかしないかが決まる場所です。ターミナルで不安定な音声入力ツールは、バイブコーダーにとって、唯一の仕事において不安定だということです。

なぜペーストは、開発者の住処でこそ壊れるのか

カテゴリレベルの仕組みはこうです。ほとんどの音声入力ツールは同じやり方でテキストを挿入します。文字起こしした文をシステムのクリップボードに置き、フォーカス中のアプリに Cmd+V のキーストロークを合成する。これは妥当なデフォルトです。ペーストは瞬時で、ほぼすべての GUI のテキスト入力欄で動き、アプリごとの作り込みがほとんど要りません。

問題は、その前提が静かに依存しているものすべてです。

まず、フォーカス中のアプリが Cmd+V を「ペースト」として扱うことに依存します。ターミナルはしばしばそうではありません。多くは Cmd+V を別のことに使うか、何にも使っていませんし、tmux や vim にはペーストが何を意味するかについて独自の考えがあり、リモートの SSH セッションは、まとめて流し込まれたテキストを、ローカル側からは予測できない形で解釈することがあります。ブラケットペースト、コピーモード、インサートモードとノーマルモード。ターミナルの世界は、合成されたペーストが誤った場所に着地したり、どこにも着地しなかったりする状態であふれています。

次に、クリップボードが利用可能で、かつ保護されていないことに依存します。クリップボードマネージャは中身を書き換えます。パスワードマネージャは意図的にクリップボードを消したり保護したりします — セキュリティ機能が「音声入力をペーストする」を、静かに「何もペーストしない」に変えるわけです。そしてすべてがうまくいった場合でも、ツールはコピーしてあった内容を上書きしています。ウィンドウ間で持ち歩いていたコミットの SHA は消えて、自分の文に置き換わっています。複数のレーンを回している人間にとって、これはかすり傷ではありません。クリップボードは仕事をしていたのです。

そして — これが一番驚かれるのですが — キーボードレイアウトに依存します。ツールがキーストロークの模倣にフォールバックするとき、素朴なやり方はキー コード を送ることです。物理的なキーの位置です。キーコードは、レイアウトを通して文字に対応づけられます。QWERTY では「V」のコードは V を出します。Dvorak では、同じ物理位置は別の文字です。だから Dvorak、AZERTY、Colemak のレイアウトでスキャンコードを模倣するツールは、換字式暗号を通したように見えるテキストを吐きます。ユーザーは意味不明な文字列を報告し、音声認識が失敗したのだと考えます。違います — 音声は完璧で、挿入がそれをかき混ぜたのです。

これは誰かの悪意でも怠慢でもありません。クリップボードのペーストは 90% のケースにとって正しいデフォルトです。ただ、開発者は残りの 10% で一日を過ごしている、というだけです。

「ペーストせずにタイプする」の中身

Keebye には insert_mode という設定があり、値はふたつ。デフォルトの paste と、type です。

擬似タイピングモードはペーストしません。macOS では CGEventKeyboardSetUnicodeString を使います。これは、合成したキーイベントに実際の Unicode テキストを添付する API です。文字はイベント自体が運び、キーボードレイアウトを通して引かれることはありません。それによって、構造的にレイアウト非依存になります。Dvorak でも AZERTY でも Colemak でも、何で打っていようと、届くテキストは文字起こしされたテキストそのものです。間違えようのあるスキャンコードから文字への変換が、そもそも存在しないからです。

擬似タイピングモードの 2 つ目の性質は、ターミナルユーザーが気にする方です。クリップボードにいっさい触れません。そのコードパスでのクリップボード操作はゼロです。クリップボードの中身は自分のものであり続けます — SHA は生き残り、パスワードマネージャは守る相手がおらず、クリップボードマネージャは記録するものがありません。

そして、ターミナルやリモートセッションは、人間のタイピングより速く届くテキストで詰まることがあるため、擬似タイピングモードは意図的にペースを整えます。テキストは 16 文字のチャンクに分けて送られ、チャンクの間には 4 ミリ秒の間隔が入ります。一文が 1 秒足らずで着地する程度には速く、SSH 越しの tmux ペインが、解釈すべき塊としてではなく追いつけるキーストロークとして受け取れる程度には落ち着いています。

ペーストモードも残っていますし、今もデフォルトです。通常の GUI アプリで大きなテキストの塊を入れるには、実際にこちらの方が速いからです — 3 段落の Slack メッセージは、チャンクの列ではなく 1 回のペーストとして届きます。とはいえ、ペーストモードもレイアウトの教訓は学んでいます。合成する Cmd+V は物理的な V のキーコードを使うので、文字を引き当てる方式のようには、非 QWERTY レイアウトでペースト自体が壊れることはありません。

エージェント相手の作業での実践的なセットアップは単純です。insert_mode を type にして、Claude Code が動いているターミナルにフォーカスし、キーを押しながら軌道修正を言って、離す。プロンプトは、キーストロークが届くのと同じ形で届きます。ターミナルから見れば、実際それがキーストロークだからです。SSH と tmux の具体的な話を含む手順ごとの説明は、macOS のターミナルのための音声入力にあります。

正直な限界

擬似タイピングモードは、長いテキストではペーストより遅くなります。これは欠陥ではなく算数です。間隔を挟んでチャンクに分けたキーストロークは、1 回のペーストイベントより時間がかかりますし、ドキュメントに数段落を音声入力するなら、ペーストモードの方がきびきびと感じるでしょう。だからこそペーストがデフォルトのままで、擬似タイピングモードは設定で自分から選ぶものになっています。正しいモードは、テキストがどこへ向かうかで決まります。

一部のアプリケーションは、たいていセキュリティ上の理由から、合成された入力をレート制限したりフィルタしたりします。どんな挿入戦略も、そこから完全には逃れられません。合成イベントを拒むアプリは、どの音声入力ツールからのものも拒みます。

そして、この記事が主張していること・していないことをはっきりさせておきます。「ターミナルでペーストが壊れる」という苦情は音声入力カテゴリ全体にまたがるパターンであって、特定の競合に固有の欠陥ではありません。他のツールにはそれぞれの答えと強みがあります。Keebye vs Superwhisper と Keebye vs Wispr Flow には、それぞれがあなたにより合うかもしれない場面も含めて、正直な比較を書きました。

挿入は、音声入力の地味な方の半分

注目はすべて音声認識に集まります。モデルの名前、精度の主張、対応言語の数。けれども音声入力ツールには仕事がふたつあります。正しく聞き取ること、そしてそのテキストを、失ったり壊したりせずにカーソルのある場所まで届けること。2 つ目は些細に聞こえますが、このカテゴリが開発者に対して静かに失敗しているのはそこです。2 つ目の仕事は、テキストエディットでは簡単で、Dvorak レイアウトのリモートマシンの tmux ペインでは難しいからです。

プロンプトがターミナルに着地するなら — そしてコーディングエージェントを動かしているなら着地します — 挿入は脚注ではありません。デモするツールと、使うツールの違いです。ちなみに、近い失敗モードには同じ味があります。マイクのコールドスタートで音声入力の最初のひと言が食べられる問題も、機械的な説明のつくカテゴリ全体の苦情で、それについてはなぜ音声入力アプリは最初のひと言を食べてしまうのかに書きました。

Keebye は macOS 向けに早期アクセス中です。口とターミナルの間で音声入力が消えたことがあるなら、下から無料トライアルを始めて、擬似タイピングモードを有効にし、同じプロンプトをもう一度試してください。コピーした SHA はクリップボードに残ったまま、言葉は Unicode のタイプとして届きます。