実際の仕事で試してください
Voice Type は macOS 用のデバイス上で動く音声入力です。ショートカットを押して話すと、入力中のアプリにテキストが入ります。音声が Mac の外に出ることはありません。7日間無料、その後は 19.99 米ドルの買い切り です（Mac App Store）。サブスクもアカウントも不要です。
無料トライアルを始めるIssue の本文は文章です。何が壊れたか、何を期待していたか、何を見たか。音声入力にぴったりです。ただ、GitHub のコメント欄はプラットフォームのほかの機能とつながっているため、声に出した 2 つの文字が、テキストの外に影響を及ぼします。
GitHub 特有の落とし穴：音声入力した「at」が誰かに通知する
Issue の本文に「@」を入力すると、ユーザーメンションの候補が開きます。メールアドレスやハンドル名、あるいは「at the same time」というフレーズを音声入力するときに「at」と言うと、テキストの上に候補が開きます。さらに悪いことに、続けて音声入力した語がたまたまユーザー名に一致し、Return を押すと、GitHub は本物のメンションを挿入します。そのメンションを投稿すると、見知らぬ人に通知が送られ、その人の受信箱にあなたのバグ報告が届いてしまいます。
- 音声入力を続ける前に、Escape を押して候補を閉じます。
- 送信する前に、プレビューで意図していない青い @ リンクがないか確認します。プレビュータブではメンションがリンクとして表示されるので、見つけやすくなっています。
- 音声入力した「hash」や「number sign」も同様で、Issue とプルリクエストの候補が開き、無関係な Issue にリンクされてしまうことがあります。
2 つ目の落とし穴：Command+Return で送信される
Command+Return でコメントが投稿されます。Command を使った音声入力のホットキーだと、書きかけの Issue が公開リポジトリに送信されてしまうことがあります。音声入力は Command を使わないキーに割り当てるか、スクラッチファイルに下書きして貼り付けましょう。
Issue を音声入力する
- 音声入力を一度オンにします：システム設定 → キーボード → 音声入力。詳しい手順は macOS で音声入力をオンにする をご覧ください。
- 新しい Issue のフォームを開き、本文欄をクリックします。タイトルは別のフィールドで、音声による操作はできません。
- 下の構成に沿って、文章を一度に音声入力します。
- 停止してから、音声が苦手な部分を手で入力します。ファイルパス、識別子、バージョン文字列、コードフェンスに入れるべきものすべてです。
- プレビュータブを開き、送信する前に読み返します。
音声入力しやすい構成
音声入力は、話しながら頭の中に保てる形に向いています。次の構成は、編集の段階まで書式を使いません：
- 何が壊れたかを 1 文で。
- 手順を、順番に話します：まず、次に、それから。
- 期待していたこと、そして実際に起きたこと。2 文で。
- 環境：OS のバージョン、アプリのバージョン、ブラウザ。
- すでに除外したこと。レビュアーが最も重視するのに、手で打つときに省かれがちな部分です。
まったく入力されないとき
- GitHub はブラウザで動くため、マイクの権限はブラウザと音声入力のツールに対して、システム設定 → プライバシーとセキュリティ → マイクで与えられます。
- フォーカスがコメント欄から外れると、GitHub 独自の 1 キーショートカットが有効になり、音声入力された文字がページ移動を引き起こし始めます。
- GitHub だけでなくどこでも音声入力が動かない場合：Mac で音声入力が動かないとき。
エディタでもブラウザでも使える 1 つのホットキー
Voice Type は、キーストロークを流し込むのではなく、キーを離したときに完成したテキストを挿入します。そのため、メンションや Issue の候補が文の途中で開くことはなく、バグを見つけたエディタでも同じホットキーが使えます：Mac の音声入力。