Claude Codeの音声入力をつかってみた

はじめに

Claude Code には音声入力機能が備わっています。キーボードの代わりに音声で指示できれば入力の手間を省けると考え、macOS 環境で検証を行いました。

実際に試したところ、入力自体は快適になったものの、話し言葉特有の曖昧さがそのまま送信されて意図しないコード修正が始まってしまう問題に直面しました。そこで、発話内容をいったん整理させるスキルを導入し、さらに応答の音声読み上げまで組み合わせた作業環境を構築しました。その構成と運用の実際を説明します。

声で話しかけてみる

音声入力は /voice コマンドで有効にします。指定できるモードは 2 種類あります。

• hold：Space キーを押している間だけ録音する
• tap：Space キーを押すと録音を開始し、もう一度押すと送信する

/voice hold
Voice mode enabled (hold). Hold space to record.

両方のモードを試した結果、運用には hold を採用しました。tap モードは入力欄が空の状態でしか録音を開始できない制約があり、コマンド名を入力したあとに続けて音声を入力する操作ができません。あらかじめコマンド（後述する /duck など）を打ち込んでから Space キーを押して発話できる hold のほうが、スキルの呼び出しと併用する目的に合致します。

この機能の利用には claude.ai アカウントでのログインとマイクの接続が必要です。録音キーの割り当ては keybindings.json で変更できます。詳細な設定手順は公式ドキュメントに記載されています。

少し使ってみた所感としては、誤変換も少なく録音停止からプロンプトに反映されるまでの速度も速いため快適でした。

• Voice dictation
• Keybindings

話すと、プロンプトが散らかる

実際に使い始めると、テキスト入力との違いがすぐに表面化しました。テキストを書くときは頭の中で構造を整理してから入力しますが、音声では思考の過程をそのまま口に出してしまいがちです。言い淀みや直前の発言の訂正が、そのままプロンプトの文字列として送信されます。

Claude Code は曖昧な入力からも意図を汲み取ろうとし、具体的な方針が決まる前に自律的なツール実行（ファイルの編集やテストコマンドの実行）へ進んでしまいます。その結果、人間の側の思考がまとまる前に、意図しないファイル変更が始まってしまう場面が生じました。

この問題を避けるため、話した内容をまず整理させ、作業はまださせないスキルを作成することにしました。

整理係のスキルを作る

Claude Code のスキルは、skills/<名前>/SKILL.md というファイルを配置することで、/名前 のコマンドとして呼び出せます。ファイルの中身は定型の指示文であり、コマンドの引数として渡した発話内容が $ARGUMENTS の位置に展開されます。

今回作成した 2 つのスキルには、いずれもフロントマターに disable-model-invocation: true を指定しました。開発者が明示的にスラッシュコマンドを入力したときだけ呼び出され、会話の流れから Claude Code 側が自律的に実行することはありません。

/duck：うまくいかないときの整理係

ラバーダック・デバッグ（アヒルのおもちゃに話しかけながら考える手法）に着想を得て作成しました。不具合の調査中に考えている事柄を発話すると、次の 4 項目に分類して整理します。

1. 何が起きているか（観察した事実）
2. 疑っていること（仮説。確度の高い順に）
3. 前提にしていて未確認のこと
4. 次に試すべきこと（最小の手順）

---
name: duck
description: 考えながら喋った（音声入力した）整理されていない内容を、事実・仮説・未確認の前提・次の手順に整理する
disable-model-invocation: true
argument-hint: <喋った内容>
---
以下は私が考えながら喋った内容で、話は整理されていません。
口調や言い淀みは無視して、次の形にまとめてください。

1. 何が起きているか（観察した事実）
2. 私が疑っていること（仮説。確度の高い順に）
3. 前提にしていて未確認のこと
4. 次に試すべきこと（最小の手順）

まだコードは変更しないでください。必要なら確認のためにファイルを読むのはOKです。

$ARGUMENTS

末尾に置いた「まだコードは変更しないでください」という一文により、Claude Code がコード修正へ先走るのを防ぎ、思考の整理だけに役割を限定できます。

/think：迷ったときの相談係

/duck を運用するなかで、新たな課題が見つかりました。この 4 項目の分類は不具合調査には適していますが、設計方針や進め方の相談には適合しません。

そこで、相談に特化したスキルとして /think を作成しました。出力フォーマットを次の 4 項目に変更しています。

1. やりたいこと
2. 迷っていること（選択肢と、それぞれの利点や懸念点）
3. 決める必要があること（発注者や開発者自身が決めるべき論点を、質問の形式で提示）
4. おすすめと次の一手

この記事の構成案も、実際に /think へ相談して決定しました。「手順の解説を中心にするか、試行錯誤の結果得られた知見を中心にするか」を音声で投げかけたところ、次のような回答が得られました。

おすすめ：B を軸にして、手順は短く添える形 手順は公式ドキュメントへのリンクで済ませられる。この記事ならではの価値は、使ってみてわかったこと（話し言葉は散らかる、だから整理させる）にある。

この提案を採用し、本記事は設定手順そのものよりも、運用の過程で得られた知見を軸に組み立てています。

なお、ここで紹介した /duck や /think の定義は検証段階のものです。項目の分け方や言い回しは、開発対象の特性や業務の要件に合わせて適宜変更できます。

ついでに、返事も声にしてみた

入力を音声で行えるようになると、応答の確認も音声で行いたくなります。Claude Code のフック機能を利用すると、応答の生成が完了したとき（Stop）や、ユーザーの許可を待つ通知が出たとき（Notification）をトリガーにして、任意のコマンドを実行できます。

say と VOICEVOX で試してみた

読み上げには、環境変数で切り替えられる 2 つの手法を検証しました。

• say：macOS 標準の読み上げ機能です。追加の環境構築なしで動作するため、疎通確認に適しています。
• voicevox：音声合成ソフトウェア VOICEVOX のローカル HTTP API です。好みの音声モデルを指定して読み上げられます。ローカル環境で VOICEVOX アプリケーションを起動しておくと、http://127.0.0.1:50021 経由で API を利用できます。

フックから say や VOICEVOX を呼ぶしくみ

フックとして登録した Python スクリプトで、イベント情報から応答テキストを抽出し、指定したバックエンドへ渡しています。処理の流れは次の 3 段階です。

1. 標準入力から渡されるイベントデータから応答テキストを取り出し、Markdown 記法や URL を除去して読み上げ用の文に整形する
2. Claude Code 側の処理を待たせないよう、読み上げ処理をバックグラウンドプロセスとして切り離す
3. バックグラウンド側で、環境変数の指定に応じて macOS の say コマンドまたは VOICEVOX の API を呼び出して音声を再生する（VOICEVOX との通信に失敗した場合は say へ切り替える）

この仕組みにより、ターミナルから目を離してドキュメントや仕様を確認している最中でも、応答の完了とその概要を耳で把握できます。

やってみてわかったこと

• 音声による指示は入力の手間を減らせる一方で、発話内容が断片化しやすい性質があります。直接コード変更を行わせず、スキルの定義によって思考を整理するステップを挟むことで、意図しない変更を防げます。
• 整理の枠組みは、用途に応じて切り分ける運用が合理的です。不具合の原因調査には事実と仮説を分ける /duck、進め方の検討には論点と選択肢を整理する /think が機能します。
• 思考の整理を指示することで、音声認識の誤変換や論理の飛躍を発見しやすくなります。
• 応答の読み上げは、日常的な開発作業で常用するかと言われると微妙なところです。ただ、リモートワーク環境で一人で作業を続ける際の気分転換や、耳からのフィードバックによって思考のテンポを変えたい場面では適した手段になりそうです。