はじめに（導入）
ある日、14時間ほど机に座ってキーボードを叩き続けた日がありました。
夜、布団に入っても肩甲骨のあたりがずっと痛い。
そのまま眠ると、夢の中でも仕事をしていました。
夢の中で仕事をしている時点でかなりつらいのですが、問題はその中身です。
夢の中の私は、見たこともない机の前に座っていて、
「この机すごい！！ 肩の負担が全然違う！！」
と、心の底から感動していました。
キーボードの高さがちょうどよくて、肘の角度が自然で、肩甲骨がふわっと軽くなる。あの机をどこで買えるんだろう、と夢の中で真剣に考えていました。
目が覚めて、そんな机は存在しないと分かったとき、正直に思いました。
これは深刻だ。
身体が「机とキーボードを何とかしろ」と夢で訴えてくるレベルまで来ている。
そう思って、起きてからは分割キーボードやエルゴノミクス系のキーボード、昇降デスクを真剣に調べ始めました。
このときの私は、
「入力が辛いなら、入力装置を良くすればいい」
と思い込んでいました。
それも一理あります。姿勢や道具を見直せば、1 回の打鍵は確実に楽になります。
ただ、自分の 1 日を振り返ってみると、それだけでは足りないことに気付きました。
私が一番多く文字を打ち込んでいる相手は、エディタでもターミナルでもなく、Claude（AI コーディングエージェント） だったのです。
- 「この API の仕様をコードから追って、要件をまとめて」
- 「このテストが落ちる原因を根本から調べて」
- 「さっきの変更を台帳に記録して、コミットして」
こういう 日本語の指示文 を、一日中打っていたわけです。
日本語の指示文であれば、キーボードで打つ必要はありません。喋ればいい。
この記事は、
- キーボードの打ちすぎで身体が悲鳴を上げている
- AI エージェント（Claude Code など）に日本語で長い指示を出す機会が多い
- WSL2 で開発している
そんな プロンプトエンジニア初心者 に向けて、
- 実際に使ってみて感じた利点
- マイクは何を使うべきか（PC 内蔵・イヤホン・ピンマイクを試した結論）
- 逆に、EC2 上で Claude Code を動かす Remote-SSH 構成とは相性が悪いという話
- 付録として、WSL2 での導入手順と引っかかった技術的な話（
soxとlibsox-fmt-pulse）
導入手順を先に見たい方は 付録 へ飛んでください。
をまとめたものです。
「キーボードを良くする」のではなく、「キーボードを使わない」
最初に、なぜ「いいキーボード探し」をやめたのかを整理しておきます。
キーボードで身体を痛める負担は、ざっくり 「1 回の打鍵の重さ × 打鍵の回数」 で決まります。
分割キーボードやエルゴノミクス系のキーボードを探していたときの私は、このうち 「1 回の重さ」を軽くする ことばかり考えていました。
確かに効果はあるのですが、1 日に何万回と叩いている限り、掛け算の答えはそこまで小さくなりません。
一方で、入力先の大半が AI への日本語指示だと気付いたときに見えたのは、もう片方の 「回数」そのものを減らせる という選択肢でした。
日本語の指示文は、キーボードを経由しなくても AI に渡せる。ここを声に置き換えれば、掛け算の片側がほぼゼロになります。
コードそのものを書く場面では、今もキーボードを使っています（後述しますが、識別子やコード片の音声入力は向いていません）。
ただ、以下のような入力は、すべて声に置き換えられました。
| 入力の種類 | 以前 | 今 |
|---|---|---|
| 調査・実装の依頼文 | キーボード | 声 |
| 修正内容のレビューコメント返し | キーボード | 声 |
| 「ここはこうしたい」という方針の相談 | キーボード | 声 |
| コード片・ファイルパス・識別子 | キーボード | キーボード |
体感では、1 日の打鍵量の大部分が声に置き換わった と感じています。肩甲骨の痛みは、この切り替えの数日後にはかなり軽くなりました。
使い方自体はシンプルで、Claude Code で /voice を有効にして、スペースキーを押しながら喋る だけです。WSL2 で動かすまでの手順と、そこで引っかかった話は 付録 にまとめました。
使ってみて分かった、音声入力の利点
ここからは、実際に数日使ってみて「これは戻れないな」と感じたことです。
1. 身体への負担が、文字通り消える
これが一番の目的だったので最初に書きます。
肩甲骨の痛みは、キーボードに手を伸ばし続ける姿勢が原因でした。
音声入力にしてからは、指示を出している間は 背もたれに体を預けたまま で済みます。
コードを書く場面だけキーボードに戻るので、打鍵量が激減しました。
2. 日本語の長文は、打つより喋る方が圧倒的に速い
AI への指示は、短いコマンドではなく、背景と意図を含んだ長めの文になりがちです。
「このテストが 3 回連続で落ちてるんだけど、たぶんモックの戻り値がテスト間で残ってるのが原因だと思う。beforeEach で clearAllMocks してるはずなんだけど、mockReturnValue で設定した実装は消えないっていう話があったから、そこを疑って根本原因から調べてほしい」
これをキーボードで打つと 1 分近くかかりますが、喋れば 15 秒程度です。
しかも、キーボードで打つときは無意識に 「打つのが面倒だから」と説明を省いてしまう のですが、声だと省かずに済みます。結果として、AI に渡る情報量が増えて、やり直しが減りました。
3. 「話し言葉のまま」で通じる相手だから、誤変換を気にしなくていい
音声入力が今まで定着しなかった理由の一つは、誤認識を直す手間 だと思います。
メールやドキュメントに音声入力すると、変換ミスや言い直しの残骸を一つひとつ直さないと相手に失礼になります。
ところが、入力先が AI エージェントだとこの前提が変わります。
- 「えーっと、あの、さっきのファイル、じゃなくてその前のファイル」のような 言い直し も、文脈で解釈してくれる
- 固有名詞が微妙に違う表記になっても、コードベースを見て 正しい対象を推測 してくれる
- 句読点や改行がなくても意味は伝わる
つまり、「人間に見せる文章」ではなく「意図を伝えるための発話」 でよくなるので、音声入力の最大の弱点である修正コストがほぼ消えます。
これは、音声入力そのものが進化したのではなく、受け手が変わった ことによる変化だと感じています。
4. 喋ることで、自分の考えが整理される
副次的な効果ですが、これも大きかったです。
キーボードで指示を書いていると、書きながら「あれ、そもそも何をしたいんだっけ」と手が止まることがあります。
声に出して説明しようとすると、説明できない部分＝自分が理解していない部分 がはっきりします。
「ここはこうしたい。理由は……あ、理由がないな」と気付いて、指示を出す前に一度考え直す、ということが増えました。
マイクは何を使うべきか
音声入力を始めると、次に気になるのがマイクです。
先に結論を言うと、在宅で一人なら、正直マイクは何でもいい と思います。周りを気にせず普通の声量で喋れるなら、PC 内蔵マイクでも十分に認識されます。
問題は オフィス です。隣に人がいる中で、AI に向かって普通の声量で指示を出すのはかなり気が引けます。結果として、口元でぼそぼそ喋ることになる。
この 「ぼそぼそ声でも聞き取ってくれる」 という条件を満たすために、私は 3 種類のマイクを試して、最終的にピンマイクに落ち着きました。
PC 内蔵マイク: 打鍵音と距離が敵
まずはノート PC の内蔵マイクで試しました。在宅で普通に喋るなら問題ないのですが、オフィスで声を落とすと途端に厳しくなります。
- 口からマイクまでの距離が遠く、ぼそぼそ声だとほとんど拾えない
- 途中でキーボードに手を伸ばすと、打鍵音がそのまま乗る
- 姿勢を変えると音量が変わり、認識の精度がぶれる
という問題がありました。特に「楽な姿勢で背もたれに預ける」とマイクから遠くなるので、目的と相性が悪いです。
イヤホンのマイク: 音質が落ちて、まともに聞き取ってくれない
次に、普段使っているワイヤレスイヤホンのマイクを試しました。手軽ではあるのですが、問題が 2 つありました。
1 つ目は音質です。
多くの Bluetooth イヤホンは、マイクを使い始めると 音楽再生用のプロファイルから通話用のプロファイルに切り替わる ため、マイクの音は電話越しのようなこもった音になります。
人間同士の通話なら「ちょっと音が悪いな」で済むレベルですが、音声認識にとっては致命的で、まともに聞き取ってくれません。言い直す回数が多すぎて、打った方が早い状態でした。
2 つ目は、そもそも認識されているのかどうかが分からないことです。
Bluetooth イヤホンは Windows のサウンド設定上、再生用と通話用で別のデバイスとして見えることがあり、どちらが今マイクとして使われているのか、設定画面を見てもよく分かりません。
喋っても文字が出てこないとき、「音質が悪くて拾えていないのか」「そもそもマイクとして選ばれていないのか」の切り分けができず、ここで時間を取られました。
ピンマイク（約 2,000 円）: これで十分だった
最終的に落ち着いたのが、Amazon で 2,000 円ほどで買った ワイヤレスのピンマイク です。
「ワイヤレス」と聞くと、さっきの Bluetooth イヤホンと同じ問題が起きそうに見えますが、仕組みが違います。
このマイクは Bluetooth を使わず、付属の小さなレシーバーを PC の USB 端子に挿す方式 です。マイク本体とレシーバーの間は専用の無線でつながり、PC からは ただの USB マイク として見えます。
なので、Bluetooth イヤホンで起きた「通話用プロファイルに切り替わって音がこもる」問題がそもそも起きません。ペアリング操作も不要で、レシーバーを挿してマイクの電源を入れれば繋がります。
高価なものではありませんが、音声入力の用途には十分でした。理由は音質そのものより、位置が安定すること です。
- マグネットクリップで胸元に固定 するので、口からの距離が常に一定
- 姿勢を変えても、背もたれに預けても、距離が変わらない
- キーボードから離れているので打鍵音が乗りにくい
- 全指向性なので、少し顔の向きが変わっても拾い方が変わらない
音声認識は「良い音」より「一定の音」に強いと感じます。
会議室の集音マイクより、講演者の胸元のピンマイクの方が聞き取りやすいのと同じ理屈です。
それに加えて、この価格帯なのに ノイズキャンセリング、ワンタッチのミュート が付いているのが実用的でした。
ミュートは特に便利で、隣の人に話しかけられたときや咳をするときに、マイク側のボタンを押すだけで音声入力に混ざらなくなります。
端子を切り替えられるので、PC でもスマホでも同じマイクが使える
もう一つ、このマイクを選んだ理由が 端子の柔軟さ です。
レシーバー自体は USB-C ですが、USB-C → USB-A と USB-C → Lightning のアダプタが付属しています。
つまり、
| 挿す先 | 使う端子 |
|---|---|
| ノート PC（USB-C） | レシーバーをそのまま |
| デスクトップ PC・古めのノート PC（USB-A） | USB-A アダプタを付ける |
| iPhone（Lightning） | Lightning アダプタを付ける |
| Android・iPad（USB-C） | レシーバーをそのまま |
と、マイクを買い足さずに挿す先だけ切り替えられます。
普段は PC に挿して Claude Code への音声入力に使っていますが、アダプタを付け替えればそのままスマホの音声メモや動画撮影にも回せます。有線のピンマイクだと端子ごとに買い分けることになりがちなので、ここは想定以上に便利でした。
Windows 側では、レシーバーを挿すと USB マイクとして認識されるので、「サウンド設定」で既定の入力デバイスに選ぶだけです。WSL 側の設定変更は不要でした。
音声入力が向かない場面と、気を付けていること
良いことばかり書いてきましたが、キーボードに戻る場面もあります。
- コード片・ファイルパス・識別子: 「アンダースコア」「キャメルケース」を口で言うのは非効率です。ここは今でもキーボードか、コピー＆ペーストです
- カフェなど公共の場: ピンマイクがあってもさすがに喋れません。オフィスは小声＋ピンマイクで何とかなりますが、静まり返った会議中などは無理です
- 送信前に一度読む: 誤認識自体は AI が吸収してくれますが、「削除して」が「作成して」に化けると事故になります。文字起こし結果を一読してから送信する癖は付けています
マイクは手元、Claude Code は遠く。この構成だと音声入力は成立しない
ここまで書いてきた音声入力は、Windows の WSL2 上で Claude Code を動かして使っています（手順は 付録）。ところが、私の普段の業務開発の本流は WSL2 ではなく、別の構成です。
Windows PC から VS Code の Remote-SSH で EC2（Amazon Linux 2023）に接続し、EC2 上で Claude Code を動かす
リポジトリも Gradle も DB クライアントも EC2 側に揃えてあり、手元の Windows は「画面とキーボード」の役割だけ、というやり方です。
「WSL2 で動いたなら、本流の EC2 でも同じ手順で動くだろう」と思って試したところ、ここで壁に当たりました。
この構成で /voice を試すと、sox を入れても次のメッセージが出て使えません。
Voice mode requires a microphone, but SoX could not open an audio capture device.
最初は「WSL と同じで、PulseAudio 系のパッケージが足りないんだろう」と思いました。これも違いました。
足りないのはパッケージではなく、マイクそのもの
WSL2 の場合は、Windows のマイクの音が WSLg 経由で WSL 内に「届いていた」ので、PulseAudio バックエンド（libsox-fmt-pulse）を足せば録音できました（詳細は付録）。
一方、EC2 はデータセンターの中にあるサーバーです。そこには オーディオデバイスがそもそも存在しない し、手元の Windows のマイクの音を EC2 まで届ける経路もありません。
公式ドキュメントにも、要件としてはっきり書かれています。
A local microphone: voice dictation does not work in remote environments such as Claude Code on the web or SSH sessions.
VS Code 拡張版についても同様です。
It is not available in VS Code Remote sessions, including SSH, Dev Containers, and Codespaces, because the microphone is on your local machine and the extension runs on the remote host.
つまり、マイクがあるマシン上で Claude Code 本体が動いている ことが前提であり、SSH や VS Code Remote では公式に非対応です。パッケージを足しても解消しません。
なぜ相性が悪いのか: Claude Code は「動いているマシン」を操作する
もう一段掘ると、問題の本質は「マイクがない」ことではなく、マイクと作業対象が別のマシンにある ことです。
Claude Code は、自分が動いているマシンのファイルを読み書きし、そのマシンでコマンドを実行します。
| 構成 | Claude Code の場所 | マイクの場所 | 作業対象（リポジトリ・ビルド・DB） |
|---|---|---|---|
| WSL2 | Windows 内の WSL | Windows（WSLg 経由で届く） | WSL 内。すべて同じ PC |
| Remote-SSH + EC2 | EC2 | Windows | EC2。マイクだけ別マシン |
「じゃあ Windows 側にも Claude Code を入れればいい」と思うかもしれませんが、それだと Claude Code は Windows のファイルしか直接触れません。EC2 上のリポジトリや Gradle、DB クライアントを操作するには ssh を挟んだ間接操作になり、ファイルを読むたびに一手間増えて、かえって非効率になります。
音声入力と作業対象を 同時に 満たすには、Claude Code・マイク・作業対象が同じマシンに揃っている必要がある。これが、EC2 構成と音声入力の相性が悪い理由です。
おすすめ: 開発環境を Windows ローカルに寄せる
私がおすすめするのは、開発環境そのものを Windows ローカル（WSL2 含む）に構築し、Claude Code もローカルで動かす 構成への切り替えです。
/voice がそのまま使えるようになるだけでなく、Remote-SSH 由来の地味なストレスも一緒に消えます。
- ターミナル操作のラグがなくなる
- SSH が切れても作業が飛ばないように
tmuxで守る、という運用が不要になる - ファイルの保存・検索がローカル速度になる
移行にあたって Windows 側に用意が必要になるものは、だいたい以下です。
| 用途 | 用意するもの |
|---|---|
| ソース管理 | Git、リモートリポジトリ（CodeCommit）用の AWS 認証情報 |
| Backend ビルド | JDK 17 |
| BFF ビルド | Node.js、pnpm |
| DB 接続 | Oracle クライアント（SQLPlus）と、DB へ到達できるネットワーク経路 |
一番の壁になりそうなのは DB への接続経路です。EC2 なら同じ VPC 内から素直に届いていたものが、ローカルからだと VPN や踏み台の話になります。ここだけは事前にインフラ側と相談しておく必要があります。
暫定策: Windows 標準の音声入力（Win + H）をターミナルに向ける
すぐには移行できない、という場合の逃げ道もあります。
Windows には標準で音声入力機能があり、Win + H で起動します。これは「今フォーカスしているテキスト入力欄」に文字を流し込むだけなので、VS Code の Remote-SSH ターミナルにフォーカスした状態で使えば、EC2 上の Claude Code のプロンプトにも音声で入力できます。
Claude Code の /voice と比べると、
- コード用語（
regex、OAuth、JSONなど）やプロジェクト名・ブランチ名を認識ヒントにしてくれる補正がない - スペース長押しのようなプッシュ・トゥ・トークではなく、別のショートカットで起動・停止する
といった違いはありますが、「日本語の指示文を打鍵せずに入れる」という目的は達成できます。
肩甲骨が限界の人は、移行の前にまずこちらで急場をしのぐのも手です。
まとめ
-
14 時間の打鍵で肩甲骨が限界になり、最初は「いいキーボード」を探していた
-
振り返ると、自分の入力先の大半は AI エージェントへの日本語指示 だった。それなら打つ必要はなく、喋ればいい
-
Claude Code の音声入力は
/voiceで有効になり、スペース長押しで喋るだけ -
WSL2 では
soxだけでなくlibsox-fmt-pulseをセットで入れる 必要がある。sox単体では ALSA バックエンドしか入らず、WSLg が用意する PulseAudio に届かない（付録）sudo apt install sox libsox-fmt-pulse -
利点は、身体への負担がなくなること、長文指示が速くなること、そして 受け手が AI なので誤認識の修正コストがほぼ消える こと
-
Remote-SSH で EC2 上の Claude Code を動かす構成では音声入力は成立しない。マイク（手元）と作業対象（EC2）が別マシンにあるのが本質で、パッケージ追加では解消しない。開発環境をローカルに寄せるのがおすすめで、暫定策は Windows 標準の
Win + H -
在宅ならマイクは何でもいい。オフィスでぼそぼそ喋るなら、約 2,000 円のワイヤレスピンマイクで十分。音質より「口からの距離が一定であること」が効く。Bluetooth ではなく USB レシーバー方式を選ぶこと、端子を切り替えられるものを選ぶと PC とスマホで使い回せる
「1 回の打鍵を軽くする」という発想から、「打鍵の回数そのものを減らす」という発想に切り替わったのが、この体験の一番の収穫でした。
同じように肩や手首の痛みに悩んでいる方は、まず /voice を試してみてください。
WSL2 で SoX のエラーが出たら、libsox-fmt-pulse のことを思い出してもらえれば幸いです。
付録 音声入力の導入手順（WSL2）
本文で触れた導入方法と、WSL2 で引っかかった技術的な話をまとめておきます。環境は Windows + WSL2（Ubuntu 24.04） で、Claude Code は WSL 側で動かしています。
/voice で有効にする。けれど WSL2 ではひと手間いる
Claude Code には音声入力（voice mode）が用意されていて、セッション中に
/voice
と打つと有効になります。有効になると、入力欄の下に
hold space to speak
と表示され、スペースキーを押している間だけ録音され、離すと文字起こしされて入力欄に入る、いわゆるプッシュ・トゥ・トーク（push-to-talk）方式で使えます。
面白いのは、文字起こしを 手元の PC ではやっていない ことです。録音した音声はそのまま Anthropic のサーバーにストリーミングされ、サーバー側で文字に変換されて返ってきます。
ローカルに音声認識エンジンを入れる必要がない代わりに、Claude.ai アカウントでのログインが必須です。ちなみに、この文字起こしは Claude のメッセージ数やトークンを消費しません。
この環境で初めて /voice を実行したときは、こんなメッセージが出て使えませんでした。
Voice mode requires SoX for audio recording. Install it with:
Ubuntu/Debian: sudo apt-get install sox
さらに、WSL 向けにはこういう補足も表示されます。
WSL2 with WSLg provides audio via PulseAudio — install SoX with its PulseAudio backend
(sudo apt install sox libsox-fmt-pulse) so Claude Code can record through it.
ここで私は「sox を入れればいいんだな」と思って、まず sox だけを入れました。これが間違いでした。
sox だけでは足りない。libsox-fmt-pulse が必要な理由
結論としては、WSL2 では以下の 2 つを セットで 入れる必要があります。
sudo apt install sox libsox-fmt-pulse
理由は単純で、sox は録音の道具、libsox-fmt-pulse はその道具を WSL2 の音の入口につなぐ部品 だからです。
WSL2 の中には物理的なマイクもサウンドカードもありません。Windows 側のマイクの音は、WSLg という仕組みが PulseAudio というサーバー経由で WSL 内に届けています。
ところが sox を単体で入れると、物理サウンドカード（/dev/snd）に直接触る ALSA 用の部品しか付いてこない。WSL2 には /dev/snd が無いので、これでは録音できません。
PulseAudio につなぐ部品が libsox-fmt-pulse です。公式ドキュメントにもそのまま書かれています。
Installing
soxalone pulls in the ALSA backend, which cannot record on WSL because there is no/dev/snddevice.
入っているかどうかは、sox のヘルプに pulseaudio が出るかで確認できます。
$ sox -h | grep -A1 "AUDIO DEVICE DRIVERS"
AUDIO DEVICE DRIVERS: pulseaudio
心配なら、sox 付属の rec コマンドで 2 秒だけ試し録りしておくと確実です。
$ rec -q test.wav trim 0 2
$ soxi test.wav
Duration : 00:00:02.00 = 96000 samples ~ 150 CDDA sectors
ここまで通れば、Claude Code 側で /voice を実行しても SoX のエラーは出なくなります。あとはスペースキーを押しながら喋るだけです。
ちなみに、Windows 側の設定は何もしていない
WSLg は Windows 11 の WSL2 に標準で入っている仕組みなので、Windows 側で特別なマイク共有設定は必要ありませんでした。
Windows の「サウンド設定」で既定のマイクを選んでおけば、それがそのまま WSL 内の PulseAudio の入力になります。
（後述するピンマイクのレシーバーを挿したときも、Windows 側で既定デバイスを切り替えるだけで、WSL 側は何もいじっていません）
もう一つの落とし穴: 文字起こしの言語は英語がデフォルト
動くようになった直後、日本語で喋ったのに英語っぽい謎の文字列が入ってきて戸惑いました。
音声入力の言語は Claude Code の language 設定に従い、未設定だと英語 で文字起こしされます。/config から日本語に変えるか、ユーザー設定ファイルに次のように書けば直ります。
{
"language": "japanese"
}