GitHubで音声入力： 実際のしくみ

GitHubに音声入力はない。仕事をするのはあなたのホットキー

みんながGoogleに実際に打ち込んでいる質問に答えましょう。いいえ、GitHubに音声入力機能は組み込まれていません。issueエディタにも、PRフォームにも、レビューパネルにも、Discussionsにも、wikiにも、ネイティブのディクテーションはありません。それらは標準的なWebのテキストエリアです。そこに口述するには、音声をどこか別の場所から持ってくる必要があります。OS、ブラウザ、あるいはサードパーティのアプリから。

GitHubがディクテーションをブロックすることは決してありません。ただ、自前のものを何も用意していないだけです。だから選択肢は、ざっくり言って三つ。OSにはディクテーションが組み込まれています――WindowsのWin+Hで使う音声入力か、macOSのDictation。Voice Inのようなブラウザ拡張は、ChromeやEdgeのタブに文字を入力できます。あるいは、Whisperのようなシステム全体で動くデスクトップアプリなら、ブラウザかどうかを問わず、どんなアプリのどんな欄にでも口述できます。

この三つの違いは「届く範囲」です。OSのディクテーションは無料ですが、一度に一つのプラットフォームでしか動かず、品質もまちまち。ブラウザ拡張はタブの中にしかいません――IDEやGitHub CLIまで付いてくることはできず、しかもクラウドで動きます。Whisperのようなデスクトップアプリはタブに縛られません。OSのレベルで動くので、Chrome、Firefox、Safari、Edgeのどれで開いたGitHubにも口述できますし、GitHub Desktopのコミットメッセージにも入力できます。

実際に口述できるもの（そして唯一できないもの）

うっかり越えてほしくない一線がここにあります。Whisperが口述するのは、コードのまわりの文章です。コードそのものは書きません。

正直なところ、それでカバーできるのは開発者がタイピングに費やす一日の大半です。issueの報告。プルリクエストの説明。コードレビューのコメント。Discussionsへの返信。READMEやマークダウンのドキュメント。変更を説明する文章であって、変更そのものではありません。あるマイグレーションがなぜリスキーなのかを話して一段落説明すれば、Whisperはきちんと処理してくれます。でも、そのマイグレーションそのものを口述しようとすると、午後がさんざんなことになります。

理由は単純です。話したコードは、旅の途中で壊れます。関数名、JSON、snake_caseとcamelCaseの違い、kubectlのフラグ、APIのパス――こういうものは、せいぜい英語の当て推量として出てきて、手作業の直しが必要になります。音声モデルは「user underscore I D」と聞いて「user ID」と書く。そうしてあなたは修正に追われます。だから「このPRはauthミドルウェアのnullチェックを直すものです」と言う文を口述して、実際の識別子はタイプしましょう。たいていのissueやPRの本文は、どのみち8割が説明で、2割がコードのスニペットです。8割を口述して、2割をタイプする。

ホットキーを押して、話して、フォーカス中の欄にテキストを得る

やり方は、ほかのどんなアプリでもするのと同じ――そこがまさに肝心なところです。埋めたいGitHubの欄をクリックします。ホットキーを押しっぱなしにします。話します。離します。文字起こしがカーソル位置に現れます。

デフォルトのホットキーは、WindowsではCtrl+Space、macOSではCommand+Optionです。どちらもプッシュ・トゥ・トーク方式で、話している間は押しっぱなしにして、離すと止まります。ほかの何かと衝突するなら、設定で変更できます――ホットキーの衝突と格闘した経験があるなら、その設定がなぜ存在意義を勝ち取ったか分かるはずです（これについては後でもう少し）。

範囲についての正直な細かい話をひとつ。Whisperが貼り付けるのは、フォーカスしている一つの欄だけ、一度に一つです。GitHubのissueフォーム全体を、ひと息で埋めてくれるわけではありません。だから新しいissueを作る流れはこうです。タイトルをクリックして口述、本文をクリックして口述。二つの欄、二回の操作。魔法というより、キーボードに触れない速いタイピストのような感覚です。それが正しいイメージです。

アプリまるごと、その場で動く

これは本物のアプリで、まさにここで動いています――スクリーンショットではありません。あちこち触ってみてください。設定も、ホットキーの選択も、モデルの選択も、ぜんぶ本物です。

クリックしながら知っておくと良いことが、いくつか。GitHub専用のタブも「GitHubモード」もありません。必要ないからです。Whisperから見れば、GitHubのPR説明欄も、ほかと同じテキスト欄のひとつ。issueエディタに口述するのと同じ設定で、メールにもIDEにも口述できます。設定は一度だけ。届く範囲こそが、この機能の本質です。

効いてくる場面：issue、PRの説明、レビュー、ディスカッション

効果が出るのは、地味で繰り返しの多い文章――タイプするのが面倒で、つい後回しにしてしまうものです。

Issue。 良いバグ報告は、ほとんどが語りです。何をしたか、何を期待したか、代わりに何が起きたか。そこはディクテーションのホームグラウンドです。再現手順を、隣の席の同僚に説明するように話して、スタックトレースは手で貼り付けましょう。

プルリクエストの説明。 差分が「それ自体で語る」からと、みんなが書くのを避けるPRの本文（実際には語ってくれません）。「なぜ」を口述しましょう――レビュアーが必要とする文脈を。そして「何を」は差分に語らせればいい。

コードレビュー。 レビューコメントは、トーンが効いてくる場所であり、みんなが説明不足になりがちな場所でもあります。レビューのメモは、タイプするより話したほうが、人間らしく、しかもより完結したものになりがちです。「edge case?」とだけ書く代わりに、「これは動くけれど、リストが空のときに壊れます」と書けるようになります。

ディスカッションとドキュメント。 長めの文章。これこそ音声が得意とするもので、しかも誰もタイプしたがらないものです。READMEの導入、Discussionsへの返信、マイグレーションガイド――まず下書きを口述して、マークダウンは後で整えましょう。同じ理屈は、Jiraのチケット やほかのトラッカーへの口述にも当てはまります。GitHubは、その山のなかのもう一つの欄にすぎません。

口述を自動できれいにする

生の口述にはフィラーが混ざります。「えっと」「そのー」、言いかけてやり直した文。Whisperには、フィラー、句読点、大文字小文字を直すオプションのAI整形パスがあって、issueやPRが、丁寧に書いたかのように読めるようになります。

種類は二つ。無料のローカルプランでは、整形はOllamaを通じてあなたのマシン上で動きます。Proでは、自分のOpenAIキーを持ち込んで整形をクラウドで動かせ、Web検索の回答も利用できます。どちらにせよオプションです――オフにすれば生の文字起こしが得られます。わたしはPRの説明ではオンに、ちょっとしたコメントではオフにしています。手早いコメントは編集が要らず、PRの説明は要るからです。

整形にできないことが一つあります。話したコードを救うことです。整えるのは英語の文章。あなたが「get user by I D」と言ったときにgetUserByIdのつもりだったとは知りません。文章は口述を続け、識別子はタイプし続けましょう。

オフラインでプライベート：ローカルモードでは何もマシンの外に出ない

公開されていないコードについてのissueやPRを口述するなら、音声がどこへ行くかは重要です。Whisperのローカルモードでは、文字起こしはすべてあなたのマシン上で行われます。話した内容がクラウドサービスに送られることは一切ありません。文字起こしの最中にインターネットはまったく必要ありません――オンラインになるのは、モデルを一度だけダウンロードするときだけで、その大きさは選ぶモデルによって約140 MBから3 GBの範囲です。

ここは、わたしが実際に意見を言わせてもらう唯一の場所です。クラウド専用のディクテーションは、文字起こしされるのを待っているプライバシーの惨事です。あるとき、自前のディクテーション試作品が発話のすべてをAPIに送ったせいで、社内のチームが四半期に五桁のクラウド請求を積み上げるのを目にしました――そして悪いのは請求額ではありませんでした。未発表のプロダクトについてのみんなの音声メモが、ベンダーのログに残ってしまったことです。上司の給与スプレッドシート、こっそり起票しているセキュリティの問題、PRで説明している独自のアーキテクチャ――一段落を声でタイプしたかっただけで、そのどれもラップトップの外に出ていいはずがありません。あなたのマシンには、すでにマイクとCPUがあります。一段落のために、ループの中にサーバーは要りません。もしあなたのツールがクラウドでしか動かないなら、わたしならそこを真っ先に直します。

これが向かないもの（コードを書くこと）

あなたは声でコードを書く方法を探してここに来たかもしれません。あるいは「Hey, GitHub!」を覚えていて、どこへ行ったのかと思っているかもしれません。正直な答えが二つあります。

「Hey, GitHub!」とGitHub Copilot Voiceは、GitHub Nextのテクニカルプレビューでした。GitHubは2024年にそのプレビューを終了しました。プロダクトになることはなく、そこで得られた知見はVS Code Speech拡張へと取り込まれました。だから、今日「Hey GitHub」を有効にしようと言うブログ記事があれば、それは何年か古くなっています。

声でコードを扱う道は今も存在します――ただ、それはgithub.comではなく、あなたのエディタとターミナルの中にあります。VS Code Speech拡張（ときに「Hey Code」とも呼ばれます）を使えば、エディタやCopilot Chatに話しかけて、コードやコマンドを扱えます。そしてGitHub Copilot CLIには最近、ターミナルでCopilotエージェントを動かすローカル音声入力が追加されました。どちらもコードとAIエージェントを操るためのものです。どちらも、ブラウザのGitHub issueに文章を口述するわけではありません。それは別の道で、Whisperが担うのはまさにそこです――コードのまわりの文章です。

GitHubのワークフローでWhisperを使わないほうがいいとき

わたしが作ったツールより、あなたにふさわしいツールを使ってほしい。だから、Whisperを使わないほうがいい場面を挙げます。

本当にやりたいのが、声でCopilotやエディタを操ることなら――「この関数を直して」「テストを走らせて」「このブロックを説明して」――それはコード/エージェントの道であって、文章ではありません。代わりに VS Code Speech拡張 か、GitHub Copilot CLIの音声入力を使いましょう。それらは機械に話しかけるもの。Whisperは人間が読む言葉を書きます。

たまに一行のコメントを口述するだけなら、OSがそれをすでに無料でやってくれます。WindowsならWin+Hを押すか、macOSならDictationをオンにすれば、何もインストールせずにGitHubの欄へさっと一文を落とせます。Whisperが元を取り始めるのは、たくさんのアプリにまたがって本物の段落を書くとき、オフラインで動かしたいとき、あるいは一部の欄しかカバーしないOS機能ではなく、どこでも同じホットキーを使いたいときです。そのラインより下なら、組み込みの選択肢で十分ですし、わたしはそうでないふりはしません。

ローカルは無料、クラウドはProで

ローカルのパイプライン――文字起こし、デバイス上でのAI整形、ホットキー、GitHubに口述するのに必要なものすべて――は、サインインしたユーザーには無料で、サインアップ時にカードは要りません。インストールして、サインインして、口述を始めるだけです。

Whisper Proはクラウド面を追加します。OpenAIのクラウド文字起こし、自分のキーを使うクラウドAI整形、そしてWeb検索の回答。このプランには短い試用期間が付きます。issueやPRを口述するだけなら、無料のローカルプランで全部こと足ります。Proの料金は 料金ページ に載っています。段落の途中で数字を並べるつもりはありません。

あのホットキーについて、最後にひとつ

ホットキーがなぜカスタマイズできるのか、ひとこと。これが全体をつなぐ話だからです。Whisperの最初のバージョンは、特定のWindowsマシンで、一回のキー押しにつき録音停止を六回も発火させていました――入力フレームワークからの幻のリリースイベント、クリーンインストールでは動くのに実機では壊れる類のものです。300msのデバウンスと、白状したくないくらいの時間をかけて、ようやく安定させました。Windowsの入力処理について、望んだ以上に多くを学びました。その教訓は残りました。ホットキーは、あなたのマシンに合わせて曲がるべきで、その逆ではない。欄をクリックして、キーを押して、話す。コードは相変わらず自分でタイプする――そして、それがこの取引の正直なところだと思います。