Cursor に日本語音声でプロンプトを送る方法

Cursor 音声入力で検索している人は、Cursor の画面に向かって声で長い指示を出し、AI にそのまま実装してほしいと考えているはずです。

現実的には、音声入力ツールで一度プロンプトを作り、Cursor の Chat や Composer に貼る流れが安定します。

Cursor は強力な AI エディタですが、曖昧な長文を渡すと、変更範囲が広がったり、確認してほしい点が抜けたりします。

この記事では、日本語で話した内容を Cursor に渡せる作業指示へ整える手順をまとめます。

Cursor で音声入力はどう使う？

Cursor で音声入力を使うなら、コードを直接声で書くより、AI へ渡すプロンプトを声で作る使い方が向いています。

入力経路は、OS 標準の音声入力、Superwhisper のような音声入力ツール、Gemini API などで作った自作ツールのどれでも構いません。

１．Chat と Composer のどちらへ送るか決める

軽い質問や修正方針の相談なら Chat に送るのが扱いやすいです。

複数ファイルを変更させたいときや、まとまった実装を依頼したいときは Composer の方が向いています。

音声入力の時点で貼り付け先を決めておくと、発話の粒度も変えやすくなります。

Chat へ送るなら「原因を調べて選択肢を出して」、Composer へ送るなら「この条件で変更してテストして」のように、実行度を声で分けます。

２．クリップボード経由にすると横断しやすい

Cursor の入力欄へ直接音声入力するより、いったんクリップボードへ出す方法が安全です。

クリップボード経由なら、Cursor 以外のブラウザ、ターミナル、メモにも同じ入力を使えます。

また、貼る前に文章を見直せるため、ファイル名や関数名の誤変換を止められます。

AI エディタへの音声入力では、速さよりも送信前に止まれることが大切です。

日本語プロンプトの作り方

Cursor に渡す日本語プロンプトは、自然な文章より作業単位として読めることを優先します。

話す順番を固定すると、音声入力でも必要な情報が抜けにくくなります。

１．目的から話す

最初に「何を達成したいか」を話します。

「記事一覧のカードで、スマホ幅のタイトルがボタンに重ならないようにしたい」のように、画面と状態が入っていると Cursor が作業を絞りやすくなります。

反対に「この表示を直して」だけでは、現在の文脈に依存しすぎます。

音声入力では指示が長くなりやすいので、最初の一文だけで作業の芯が伝わるようにします。

２．制約を先に入れる

Cursor は周辺コードを読んで提案してくれるぶん、こちらが望んでいない整理まで進めることがあります。

そのため、「既存のデザイン変数は変えない」「API のレスポンス形式は変えない」「 unrelated なファイルは触らない」のような制約を声に出しておくと安全です。

制約は最後に付け足すより、目的のすぐ後に置いた方がプロンプト全体の方向が安定します。

特に UI 修正、認証、課金、データ移行では、変えてはいけないことを明示してください。

３．検証方法まで話す

Cursor に任せる依頼では、検証方法があるかどうかで完了品質が変わります。

「bun test を実行して」「390px と 1280px で表示確認して」「既存の API テストを通して」のように、終わりの条件を声で入れます。

検証方法がない依頼は、実装がそれらしくても完了判定が曖昧になります。

音声プロンプトでは、最後の10秒を検証条件に使うくらいでちょうどいいです。

貼り付け前の安全確認

Cursor は実際にファイルを書き換える道具なので、音声入力した文章を自動送信する前に確認地点を置くべきです。

特に日本語音声では、否定や範囲指定の誤変換が危険です。

１．危険な動詞を確認する

「削除」「置き換え」「本番」「全体」「リセット」のような語が入っているときは、送信前に止まります。

これらの語は必要な場合もありますが、誤変換や言い直しが混ざると影響範囲が大きくなります。

「全部消して」ではなく、「未使用の一時ファイルだけ削除して、対象を一覧にしてから実行して」のように範囲を具体化します。

声で出た強い言葉ほど、貼り付け前のレビューで整える価値があります。

２．秘密情報を話していないか見る

音声入力では、環境変数、API キー、顧客名、未公開 URL をうっかり話すことがあります。

クラウド型の音声入力を使う場合は、音声やテキストが外部サービスへ送られる可能性も考えます。

Cursor へ貼る前に、秘密情報らしい文字列や固有名詞が含まれていないかを確認してください。

開発中の本番調査ほど、音声入力を短く区切ると事故を減らせます。

うまくいかない発話の直し方

Cursor に音声で送るプロンプトがうまく働かないときは、ツール精度だけでなく発話の形を見直します。

失敗パターンを固定して直すと、毎回の手直しが減ります。

１．「いい感じ」を見える条件へ変える

「いい感じにして」は、Cursor にとって余白、色、構造、文言、コンポーネント分割のどれを変えるべきか分かりません。

見た目なら「ボタンと本文が重ならない」「カードの高さがホバーで変わらない」「タイトルは2行までにする」のように見える条件へ変えます。

実装なら「既存の公開 API は変えない」「型エラーを出さない」「このテストを追加する」のように確認できる条件へ変えます。

声で曖昧に話しても、整形後のプロンプトは観測できる条件に寄せます。

２．長すぎる依頼は分ける

1回の音声入力で、調査、実装、テスト、PR 作成まで全部入れると、どこから始めるべきか曖昧になります。

Cursor には、最初に調査だけ、次に実装、最後に検証というように分けて送る方が安定します。

音声入力は長文が楽だからこそ、作業単位を広げすぎない注意が必要です。

音声コーディングを日本語で始める方法でも、1つの依頼に1つの変更をおすすめしています。

よくある質問

Cursor と音声入力の組み合わせは便利ですが、実装を任せる前提だからこそ安全確認が必要です。

よくある疑問を、作業の始め方に絞って整理します。

Cursor で音声でプロンプトを送れますか？

送れます。

ただし、Cursor 側の専用音声機能に頼るより、音声入力ツールでテキスト化し、Chat や Composer へ貼る方法が現実的です。

貼り付け前に確認できるため、日本語の誤変換や危険な指示を止めやすくなります。

Cursor の長文指示を音声で作るには？

目的、対象、制約、検証の順で話します。

その後、不要な言い直しを削り、ファイル名や技術用語だけを確認してから貼り付けます。

長文を1本にまとめるより、調査、実装、検証で分けると失敗が減ります。

Cursor と VS Code Speech はどちらがよいですか？

VS Code 内で完結するなら VS Code Speech が自然です。

Cursor を中心に複数アプリも使うなら、クリップボードへ出せる音声入力ツールの方が柔軟です。

VS Code の音声入力を AI コーディングで使う方法も合わせて見ると、使い分けがしやすくなります。

Cursor では声を作業指示に変えてから送る

Cursor に日本語音声でプロンプトを送るときは、声をそのまま送るより、作業指示として整えてから貼る方が安定します。

目的、対象、制約、検証の4要素をそろえ、危険な動詞と秘密情報を送信前に確認してください。

音声入力の価値は、雑に自動送信することではなく、長い依頼文の下書きを速く作れることにあります。

おたすけまるの voice-prompt のリポジトリでは、この整形部分を日本語エンジニア向けに検証しています。