AI と一緒に考えるための音声: なぜキーボードは間違った道具なのか

私はかつて、音声はアクセシビリティインターフェースか利便性機能だと考えていました。AI ツールを毎日使うようになって考えを変えました。キーボードは精度には優れていますが、AI と一緒に考えるための道具としては貧弱です。なぜならアイデアがまだ準備できていないうちに、狭いチャネルを通すことを強いるからです。

キーボードのボトルネック

速いタイピストは毎分 70 語あたりでピークに達します。会話の話し言葉は毎分 150 語に近く、内的思考はどちらよりも速く動けます。正確な数字よりも形が重要です。キーボードは、アイデアが準備できる前に思考を磨かれた断片へと直列化させます。

それがキーボードのボトルネックです。タイピングが絶対的に遅いということではありません。タイピングはあなたに思考を形作りながら編集することを促します。AI と一緒に作業するとき、その早期の圧縮は有用な曖昧さ — 注意点、代替案、確信はないがモデルに考慮してほしいこと — を取り除いてしまうことが多いのです。

疲れているときに最も顕著に気づきます。1 日の終わりに、タイプしたプロンプトは短くなり、モデルもそれに応じて有用性が落ちます。同じ晩、同じツールに同じ意図をディクテーションすると、より良い答えが得られます。話したバージョンには、私が手で編集して取り除いてしまうコンテキストがまだ含まれているからです。キーボードは私を遅くするだけでなく、ある時刻以降、モデルとの協働者として私を悪くします。

AI はプロンプトの形を変える

LLM と仕事することは、コマンドを発するよりも協力者にブリーフィングすることに近いです。良いプロンプトには多くの場合、コンテキスト、動機、制約、例、不確実性が含まれます。問題がまだ曖昧なとき、AI ツールへの音声プロンプトはより良く機能します。なぜなら、優美にすることに立ち止まらずに周囲のコンテキストを話せるからです。

これが考えるための音声が重要な理由です。「バグはキャッシュキーにあると思うけど、ユーザーロケールがその一部かは確信がない、まずその経路を調べて、間違ってたら教えて」と言えます。タイプすると、これはしばしば「キャッシュバグを確認」になります。短いプロンプトは思考を失います。

プロンプトの形は、もはやその前置きではなく、仕事の一部です。プロンプトをあなたが生み出す成果物として扱えば、音声は自然な著作ツールになります。あなたが実際に問題をどう理解しているかの構造 — 確信のない部分を含む — を保持するからです。半成形の形を受け取ったモデルは、自信ありげだが部分的なコマンドを受け取ったモデルよりも、しばしば良い答えを返します。

考えを変えた三つの瞬間

一つ目はデバッグセッションでした。リグレッションを調査するようエージェントに短いプロンプトをタイプしました。間違った方向へ進みました。次に乱雑なバージョンをディクテーションしました。何が変わったか、何を疑っているか、何を疑っているか、何が私の仮説を反証するか。エージェントは問題をより速く見つけました。なぜなら、私はようやく自分の不確実性の形を与えたからです。

二つ目はライティングでした。私たちのモデルスタックについて簡潔な段落をタイプしましたが、正しく聞こえるけれども死んでいるように感じました。同じアイデアをアーキテクチャに至った苛立ちを含めて歩きながら話しました。ディクテーションしたバージョンには本物の議論がありました。それでも編集はしましたが、無菌な outline からではなく、生きたドラフトから編集しました。

三つ目は長くて気まずい顧客返信でした。顧客はきれいな答えのない質問をしてきていました。正直な応答にはトレードオフと小さな謝罪が含まれていました。タイプすると、返信は 6 回の編集を経てもまだぎこちなく感じました。ディクテーションすると、最初のテイクの方が暖かく、直接的で、一語の修正だけが必要でした。私はそのバージョンを送信し、会話は前進しました。どんなトーンも必要なメッセージにはもうタイプした返信を信用しません。

今の自分の音声の使い方

音声は最終精度ではなく、ファーストパスの思考に使います。乱雑な要約を Claude Code、Cursor、Obsidian、または素の Markdown ファイルにディクテーションします。次にキーボードに切り替えて正確な編集をします。その分業は各ツールをそれぞれのレーンに保ちます。音声はコンテキスト用、キーボードは手術用。

• コーディングの前: 変更、リスク、テスト経路をディクテーションします。話したバージョンは、タイプしていたらスキップしていたであろうリスクを表面化させることが多い。
• ライティングの前: outline する前に議論を声に出して話します。2 分で議論を言えなければ、自分が何を考えているかまだ分かっていない。
• 会議の前: 通話から必要な決定をディクテーションします。決定を名指して会議に入ると、会話が変わります。
• 失敗の後: 記憶が消える前に驚いたことをディクテーションします。翌朝までに、捕まえていなければ教訓は消えています。

話す速度とディクテーションパターンに関する外部コンテキストとしては、Nielsen Norman Group の音声認識に関する記事と 毎分単語数のリファレンスが出発点として有用です。

繰り返し聞く反論

「共有スペースで仕事してます。」公平な反論で、実在する制約です。私の答えは、難しいプロンプトをディクテーションするのに 1 日 10 分だけ静かに使えるとしても、タイプした 1 日分よりも有用だということです。音声がワークフローを支配する必要はありません。それを変えるだけで十分です。

「タイプしながら考えられます。」本当にそうできる人もいます。テストはタイプでテキストを生成できるかどうかではありません。タイプして生成するテキストが、話していたら持っていたであろう思考と同じ形をしているかどうかです。私を含む大半の人にとって、タイプしたバージョンは一貫して不完全です。

「ディクテーションすると話がまとまらない感じがします。」最初の 1 週間はぎこちないものです。2 週目ははるかに良くなります。学ばれているスキルは話すことではありません。話された思考を、読者(あるいはモデル)が使える形に整える能力です。誰もが会話で以前使ったことがあるので、思ったより速く戻ってきます。

Loqua がはまる場所

私たちが Loqua を作ったのは、生の書き起こしクリーンアップを受け入れずに考えるための音声を欲しかったからです。フォルススタートを取り除き、技術名を保持し、自分がいるアプリ用に出力をフォーマットします。ソフトなピッチはこうです。アイデアが大きすぎる、または脆すぎてキーボードを通せないときに Loqua を使ってください。

この議論の実践版については、私たちのボイスファースト勤務日を参照してください。その記事は、音声がいつ機能し、いつ失敗し、いつまだキーボードに手を伸ばすかを示します。この記事のポイントは「なぜ」、あちらは「どうやって」です。