3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

私が「AI音声入力」をやめた理由 ― Claude Codeでの開発で気づいたこと

3
Posted at

少し前、巷で話題の音声入力ツール(AquaVoiceなど)を開発フローに組み込んでみました。文字が画面に流れていくスピードは確かに圧倒的で、最初は「これならキーボードを叩くより速く開発を回せる」と期待していました。

ところが、普段ターミナルでClaudeCodeを使って開発していると、音声入力に切り替えてから「返ってくるコードの質」や「バグ修正の打率」が落ちる感覚がありました。文字の入力スピードは上がったはずなのに、開発全体のテンポはむしろ悪くなる。

この違和感を、人間の認知の仕組みと、AIへの伝わりやすさの両面から考えてみたところ、音声入力には構造的な理由があると分かってきました。音声入力とタイピングの違いは、使ってみると「入力スピード」以外のところに出てきます。確かに、喋るほうが速い。それは間違いないんです。ただ、頭の中を箇条書きや改行で整理しながら出していけるのはタイピングのほうでしたし、打っている途中で「あ、この条件も足したい」と引き返せるのもタイピングでした。エラーログを引用したり、ファイル名を指定したりも、キーボードなら一瞬で済みます。音声だと、その整理も引用も、全部口で説明することになる。

スピードで得したぶんを、別のところで吐き出している。今回は、その「別のところ」を2つに分けて書いていきます。

1. 脳の「出力モード」と音声入力のミスマッチ

音声で喋っているときと、テキストを打っているときで、脳の使われ方が違う ―― これが最初の気づきでした。

コードを書いたりバグの原因を探したりしているとき、私の頭は「ロジカル・構造化モード」になっています。タイピングの良さは、画面という空間を見ながら打ち込んでいる最中に、「やっぱりこの条件も足そう」「この単語は違うな」と、脳内のロジックに合わせてリアルタイムに編集できる点にあります。箇条書きの-を入れたり改行を挟んだりする操作は、構造化モードのまま指先に直結している感覚です。

一方、音声は時間とともに流れる一本の直線です。喋っているときの脳は、情報を整理することよりも「次に何を言うか」という発話のコントロールにリソースを取られます。一度口から出した言葉は、その時点で確定してしまう。後から「いまのは無しで、やっぱり条件を足して」と音声で継ぎ足していくと、指示はどんどん上書きの上書きになり、純度が下がっていきます。

具体的に困ったのは、少し込み入ったリファクタリングを音声で頼もうとしたときです。頭の中では「この関数を3つに割って、バリデーションは前段に寄せて、戻り値は配列じゃなくてオブジェクトに」と、わりと図のような形で見えている。ところが口に出すと、その図を無理やり一列の言葉にほどいて、順番に喋らないといけません。喋っている途中で「あ、戻り値の話を先にすればよかった」と気づいても、前半はもう声になって出てしまっている。タイピングなら、書いたあとで行ごと入れ替えればいいだけの話です。

おもしろいのは、同じ内容でもキーボードに向かうと、勝手に手が箇条書きを作り始めることです。「条件はこれとこれ」と頭で思った瞬間に、指が-を打っている。音声にはこの「打ちながら整理する」回路がなくて、整理は全部、喋り終わってから頭の中だけでやることになる。結局、口で喋った内容を自分でもう一度読み返して直す、という二度手間が起きていました。

結局、頭の中でせっかく組み立てたロジックを、わざわざ話し言葉という流れる形式に翻訳して口から出し、それをClaudeにまた読み解かせている。この二重の翻訳が、地味に認知負荷になっていたのだと思います。タイピングなら、構造化モードのまま、頭の中の形をそのまま画面に置けます。

2. 「箇条書き・改行・引用」ができるだけでタイピングが勝つ

情報の切れ目で改行を入れる。並べたい条件は-や1.を頭につける。コードやエラーログ、それに会話ログの引用には>やコードブロックで囲む。たったこれだけで、どこからどこまでが一つの塊で、どこが参照すべきデータなのかがClaudeに正確に伝わります。

特に「引用して前のやり取りに返す」操作は、タイピングだからこそ自然にできる芸当です。ClaudeCodeで開発していると頻繁にやるのが、エラーログの貼り付け、特定のファイルパスや関数名の指定、そしてClaudeの直前の返答や自分の前の指示を>で引用して返すことです。

たとえば同じ依頼でも、音声で一息に喋るとこうなりがちです。

えーっと、さっきのバグ修正なんですけど、ユーザーが未ログインのときに
早期リターンするようにして、あとログも出してほしくて、で、さっきの
エラーは確か認証まわりのやつで…

これをタイピングで書くと、これくらいで十分伝わります。

以下も追加で

- 未ログイン時は早期リターン
- 処理前にログを出力

出たエラーはこれ。
> AuthError: token expired at AuthService.php:42

同じ意図でも、後者のほうがClaudeは一発で正確に汲み取ってくれます。これを音声でやろうとすると、「バッククォート3つ打って、そこにエラーログを貼って、ファイル名はsrc/…」と、操作そのものを口頭で実況する羽目になり、かえって手間が増えます。

引用がいちばん効くのは、ひとつ前のやり取りに返事をするときです。Claudeが返してきた説明や、自分がさっき出した指示の一部を>で引用して、「ここはこういう意図だった」「この前提だけ変えたい」と返す。会話のどこに対して言っているのかが、引用ひとつではっきりします。これを音声でやろうとすると、「さっきあなたが言った、xxのところなんですけど」と、どの発言を指しているのかの説明から入らないといけません。AIは律儀なので、そのさし示しの説明まで指示の一部として受け取って、話がぶれていきます。

エラーログも同じです。スタックトレースを音声で読み上げるのは現実的ではないので、結局コピペします。だったら最初からキーボードの前にいたほうが早い。音声入力は「喋った言葉をすばやく文字に起こす」ことには強いのに、開発で本当に増やしたい「貼る・囲む・指す」という操作とは、どうにも相性がよくありませんでした。

「文字を入力する速さ」よりも「Claudeに一発で正確なコードを出してもらう速さ」のほうが、開発全体では効いてきます。

結論:音声入力は「プロンプト」ではなく「壁打ち」で使う

ここまで弱点を並べてきましたが、音声入力を全否定したいわけではありません。

仕様がまだ固まっていなくて頭の中がごちゃごちゃしているとき、「いまこういう実装で悩んでいて、こんなエラーが出ている」と一気に吐き出すブレインダンプには、音声入力は最高に向いています。雑多に喋ったものを「この要件を箇条書きで整理して」とClaudeに前処理させる使い方は、十分にアリだと思っています。

ただ、ClaudeCodeを叩いてリアルタイムにコードを生成したり、デバッグを回したりする前線のフェーズでは、キーボードで「改行・箇条書き・引用」を使い、意図を固定して伝えるのが、いまのところ私の最適解です。

流行りの効率化に乗ること自体が目的になると、かえって打率を下げることがあります。AIの特性と自分の脳のモードを理解したうえで、一番打率が高い方法を選ぶ。それが結局いちばん速い、というのが今回の結論でした。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?