# Hex 3.0のローカル音声入力：160MB Parakeet GPUストリーミング解説 > Mac、Windows、Linuxで動作するHex 3.0が、160MBのParakeet GPUストリーミングにより100msで音声入力を行う仕組みと、WaylandやIntel GPUの不具合対策、多言語モデルの設定方法を解説します。 - URL: https://freelivecaption.com/ja/posts/hex-local-voice-dictation - Author: 佐藤 美咲 (https://freelivecaption.com/ja/about) - Topic: 音声入力 (https://freelivecaption.com/ja/topics/dictation) ## 要点 - Hex 3.0はオープンソースのローカル音声入力ツールです。 - Parakeet Unified英語GPU処理はAppleシリコンでMetal、Windows x64でVulkan、Windows ARM64でCPUを使用します。 - macOSのマイク表示、Linux Waylandのショートカット、Intel Arc GPUのハング、小音量時のVAD破棄、多言語切り替えの実践的な対策を紹介します。 --- Hexは、コンピュータ上でローカルに音声認識モデルを実行する、Rustベースのオープンソース・デスクトップ音声入力ツール（[anoma.ly/hex](https://anoma.ly/hex)）です。マイクの音声をクラウドサーバに送信する代わりに、グローバルキーボードショートカットを押し続けている間だけ音声を聞き取り、現在フォーカスされているコードエディタ、ブラウザのタブ、ターミナルウィンドウへ文字起こしされたテキストを直接ペーストします。 Hex 3.0のリリースに伴い、デフォルトの英語音声入力パイプラインは、NVIDIAのParakeet Unifiedモデルを活用したストリーミングGPUアーキテクチャへと移行しました。以前のバージョンでは、ローカルの文字起こしモデルをバックグラウンドで常駐させておくために約900MBのRAMを消費し、ショートカットキーを離した後に音声クリップ全体をモデルが処理し終えるまで待つ必要がありました。Hex 3.0では、このメモリ使用量を160MBまで削減し、ホットキーを押している最中にライブストリームで音声を文字起こしします。キーを離す頃には推論がほぼ完了しているため、約100msでアクティブなカーソル位置に最終的なテキストがペーストされます。 現在HexはmacOS、Windows、Linuxに対応し、それぞれ異なるGPUバックエンドを使用しているため、この100msの応答速度を実現できるかどうかはハードウェア、ディスプレイサーバ、およびモデルの選択に大きく左右されます。以下では、各オペレーティングシステムにおけるストリーミングバックエンドの仕組み、オプションのペースト前テキスト整形の設定方法、そして検証中に遭遇したドライバやデスクトップ環境特有の不具合の解決策を解説します。 ## 160MBのParakeetストリーミングパイプラインの仕組み 多くのローカルWhisperラッパーは、ボイスレコーダーとバッチコンバータを組み合わせたような仕組みで動作します。ショートカットを押し、十秒間話し、ショートカットを離してから、GPUがオーディオバッファを最初から最後までエンコードする間、二、三秒ほど読み込みアイコンを見つめることになります。長文のメモであればその程度の遅延でも問題ありませんが、ちょっとしたターミナルコマンドやSlackの返信、ドキュメントへの短い一文を音声入力する際には作業のリズムが崩れてしまいます。 Hex 3.0では、ショートカットキーを押し続けている間にオーディオチャンクをParakeet Unified英語モデルへ継続的に送り込むことで、この待ち時間を解消しています。話したフレーズから順次GPUが処理していくため、キーを離した時点では最後の音節をフラッシュしてシステムクリップボードに文字列を流し込むだけで済みます。Appleシリコン搭載のMacや十分な性能を持つVulkan対応GPUを搭載したWindows PCでは、キーから指を離したほぼその瞬間にテキストが入力欄へ反映されます。 使い始めに少し戸惑いやすい点として、Hexは話している最中にアプリケーションへ単語を一つずつ入力していくわけではありません。デフォルトでは、小さなフローティングHUDピルに録音状態と短い文字起こし状態が表示されるのみで、テキスト自体はホットキーを離してセグメント全体が一括ペーストされるまで保持されます。長めの文章を音声入力する際に、最初の文にある専門用語が誤認識されていないか最後まで分からないのが不便な場合は、コマンドラインから実験的なライブプレビュー機能を有効にできます。 ```bash hex experiments enable live-text ``` このコマンドを実行した後、Hexのバックグラウンドサービスを再起動してください（Linuxでは、`systemd`ユニットが起動時にのみ実験機能の設定ファイルを読み込みます）。有効にすると、HUDピルのすぐ下にクリックスルー可能な一行のテキストが描画され、話している内容に合わせてリアルタイムで更新されます。このプレビューは音声入力の履歴には保存されず、キーを離すまでカーソル位置にも影響しません。Parakeet Unifiedストリーミングでの検証では、短い文であれば正確にライブ表示されましたが、最終的な句読点や大文字・小文字の整形が行われる前の生のストリーミング出力が表示されます。また、キーを離さずに長い段落を話し続けると、一行表示のプレビューがオーバーレイの表示領域を超えて広がり、整形済みの最終テキストがアプリにペーストされるまでの間、最新の単語が画面端で見切れることがあります。 ## Mac、Windows、LinuxにおけるGPUおよびCPUバックエンド Hex 3.0は、すべてのマシンで同じ推論パスを使用するわけではありません。オペレーティングシステムとプロセッサアーキテクチャに応じて、異なるハードウェアバックエンドへモデルをルーティングします。 - **macOS（Appleシリコンのみ）**：macOS 15以降を実行しているMシリーズMac上で、`transcribe.cpp`を介した厳密なMetal GPUアクセラレーションを使用します。 - **Windows x64**：ディスクリートGPUおよび内蔵グラフィックスカード上で、Vulkan GPUアクセラレーションを使用してParakeet Unified英語ストリーミングを実行します。 - **Windows ARM64**：Vulkan GPUパスをバイパスし、CPU上で文字起こしを実行します。 - **Linux x64**：デフォルトでVulkan GPUアクセラレーションを使用し、非対応のグラフィックスドライバやヘッドレス環境向けにはCPUフォールバックパスを備えています。 ### Intel Macがブロックされる理由とmacOSのオレンジ色のマイク表示を消す方法 ディスクリートのRadeon Pro GPUを搭載した2018年モデルや2019年モデルのMacBook Proであっても、IntelベースのMacでHexをダウンロードしようとすると、インストーラは実行を拒否し、WebサイトにはAppleシリコン必須という条件がグレーアウト表示されます。公式のmacOS向けDMG、ZIP、およびHomebrew Caskのビルドは、`macos-arm64`専用にコンパイルされています。内部的には、macOS版のHexはモデルを使用可能と判定する前に厳密なMetal上でロードすることを必須としており、`x86_64-apple-darwin`向けのビルド済みCPUフォールバックバイナリは用意されていません。GitHubリポジトリをフォークして自らIntelターゲット向けにコンパイルし、さらに厳密なMetalの代わりにCPUバックエンドを受け入れるようモデルローダにパッチを当てない限り、Hexの利用にはMシリーズMacが必要です。 Hexがネイティブ動作するAppleシリコン搭載Macでは、アプリを起動して最初に気づく点として、音声入力を行っていないアイドル状態であってもメニューバーにあるmacOSのオレンジ色のマイクインジケータが常時点灯したままになります。これはHexが密かに室内の音声を録音しているわけではありません。ホットキーを押した際、CoreAudioがデバイスを初期化するのを待たずに最初の音節から確実に捉えられるよう、オーディオ入力のデフォルト設定がマイクストリームを常時オープンに保つ仕様になっているためです。 メニューバーのオレンジ色のプライバシードットを一日中点灯させておきたくない場合は、Hexを開いて**Settings → General → Dictation → Advanced → Microphone mode**へ進み、設定を「**Keep ready (fast)**」から「**Release when idle**」に変更してください。**Release when idle**に切り替えると、ショートカットキーを押していない間はオレンジ色のインジケータが消えるようになります。トレードオフとして、ホットキーを押した際にわずかな初期化の待ち時間が発生するため、最初の単語が途切れないようキーを押してからほんの一瞬待って話し始める必要があります。 ## Linux Wayland、Intel GPUのハング、Windows 11のHUD問題の解決策 Windows 11およびLinuxでは、HexはRune UIオーバーレイの描画とGPUによるモデル推論の両方にVulkanを使用し、テキストの流し込みにはデスクトップポータルやクリップボードユーティリティを利用します。標準的な環境であればそのまま問題なく動作しますが、ハードウェアやデスクトップ環境の組み合わせによっては手動での調整が必要になります。 ### Linux VulkanにおけるIntel内蔵GPUのハング Intel Arc内蔵グラフィックス（`i915`カーネルドライバとMesa `vulkan-intel`を使用するCore Ultraプロセッサなど）を搭載したノートPCでLinuxを実行し、Parakeetから`qwen3_asr06_b`や`whisper_large_v3_turbo`といったより重いモデルに切り替えると、Vulkanの推論処理によってGPUがロックアップすることがあります。この現象が発生すると、カーネルログに`i915`のGPUハング（`context reset due to GPU hang`）が出力され、Hex側では`LocalTranscriber::load`がGPU上に文字起こしモデルをロードできなかったという警告を記録したのち、8スレッドの`ggml` CPUセッションへとフォールバックします。CPUによる文字起こしが始まる前にGPUコンテキストのハングとリセットを待たなければならないため、六秒間の音声クリップの処理完了までに90秒以上かかるようになり、純粋なCPU推論と比べてGPUパスが約20倍も遅くなってしまいます。 `VK_ICD_FILENAMES`にダミーのファイルパスを設定してVulkanを完全に無効化しようとすると、CPUでの文字起こしは五秒未満に短縮されますが、Rune UIツールキット自体の描画にGPUサーフェスが必要となるため、HexのウィンドウやHUDオーバーレイが起動しなくなります。HUDを正常に動作させつつ文字起こし処理をCPUに強制割り当てするには、二つの方法があります。UIレンダリングと音声エンジンが分離された新しいビルドを使用している場合は、**Settings → General → Advanced → Dictation → Speech engine**へ進んで**cpu**を選択するか、次のコマンドを実行します。 ```bash hex settings set transcription_device cpu ``` この設定項目がまだ公開されていないビルドを使用している場合は、`vulkan-swrast`（Mesaのソフトウェアラスタライザである`lavapipe`）をインストールし、Hexのユーザーサービスに`Environment="VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.json"`を追加してください。これにより、モデルの推論処理をハングの原因となるIntel i915ドライバから切り離しつつ、HUDの描画に必要なサーフェスを確保できるため、六秒間のクリップの処理時間を五秒前後まで戻すことができます。 ### Linux Waylandのショートカット、ペースト、およびGNOMEのオレンジ色のインジケータ Wayland環境のLinuxでHexを実行する場合、文字起こしされたテキストをウィンドウにペーストするために`wl-clipboard`（`wl-copy`）が必要です。Hexは起動時に`wl-clipboard`の有無をチェックしないため、未インストールの状態では一見正常に動作しているように見え、最初の音声入力を行って初めてペーストに失敗します。まずはパッケージマネージャから`wl-clipboard`をインストールしてください。 また、GNOME 46が動作するUbuntu 24.04では、Hexのメインウィンドウに`Hold Ctrl+Space to dictate`と表示されているにもかかわらず、デフォルトの`Ctrl+Space`ホットキーを押し続けても何も起きない現象に遭遇します。起動ログを確認すると、`No such interface "org.freedesktop.portal.GlobalShortcuts"`というメッセージが出力されています。`xdg-desktop-portal-gnome` 46にはGlobalShortcutsポータルが実装されていないため、Hexはコンポジタから直接キー入力を取得できません。GNOME 46でHexを使用するには、システムの**設定 → キーボード → キーボードショートカット → 独自のショートカット**を開き、次のコマンドを実行するショートカットを割り当ててください。 ```bash hex dictation toggle ``` なお、GNOMEの独自ショートカットはキーを押した瞬間と離した瞬間を追跡するのではなく、キー押下時にのみ発火する仕組みです。そのため、ホットキーの動作は「押している間だけ話す（ホールド・トゥ・トーク）」ではなく、「一度押して開始、もう一度押して停止」というトグル方式になります。新しいビルドでは、**Settings → Desktop shortcuts**の下にこのルールを自動作成する**add gnome keyboard shortcuts**ヘルパーボタンも用意されています。 GlobalShortcutsが機能する新しいGNOMEデスクトップ（ArchやNixOS上のGNOME 50や51など）を使用している場合は、ポータルに関して他に二つの挙動が見られることがあります。一つ目は、Hex内でショートカットキーを変更した際に新しいキーが反応しなくなる現象です。この場合は**設定 → アプリ → Hex → グローバルショートカット**へ進んで**すべてのショートカットを削除**をクリックし、その後Hex内でショートカットを一度オフにしてから再度オンに切り替えることで、GNOME側から新しいキー割り当ての承認プロンプトが表示されます。二つ目は、Wayland上で音声入力とテキストのペーストを行った後、GNOMEのトップバーにあるオレンジ色のリモート操作／画面共有インジケータが点灯したままになる現象です。Hexはペーストのキーストロークを送信するために`WaylandKeys::Portal`のRemoteDesktopセッションを使用しますが、デスクトップポータルが有効な復元トークンを返さない場合、音声入力のたびに権限許可ダイアログが表示されるのを防ぐため、Hexは意図的にバックグラウンドでセッションを開いたまま維持します。 ### マイク音量不足による無音破棄とHUDピルが表示されない問題 LinuxでPipeWireとUSBマイクを組み合わせて使用した際に遭遇したもう一つの問題として、五秒から十秒ほど話してキーを離しても、UI上に何のエラーメッセージも出ないまま何もペーストされないケースがあります。ターミナルで`hex dictation stop --print`を実行した際、`discarded dictation without detected speech`というログメッセージとともに終了コード4で終了する場合は、マイクの入力ゲインが低すぎることが原因です。 マイクの入力音量が35%から40%程度（`-47 dBFS`から`-50 dBFS`前後）にとどまっていると、Hexの音声区間検出（VAD）が「無音のままだった」と判定し、文字起こしモデルに渡す前にオーディオバッファを破棄してしまいます。デフォルトのオーディオソース音量を75%まで引き上げれば、この問題は即座に解消します。PipeWire／WirePlumber環境では、次のコマンドを実行してください。 ```bash wpctl set-volume @DEFAULT_AUDIO_SOURCE@ 0.75 ``` また、Bluetoothヘッドセットを使用していて突然文字起こしされなくなる場合は、PulseAudio／PipeWireレベルで入力ソースがミュートになっていないかも確認してください（`pactl set-source-mute @DEFAULT_SOURCE@ 0`で解除できます）。ミュート状態になっていると、Hexは`-120 dBFS`の無音を録音してクリップを破棄してしまいます。 最後に、Windows 11やHyprlandのようなミニマルなWaylandコンポジタ環境において、ショートカットを押した際に開始・終了のチャイム音は鳴るものの画面上にフローティングHUDピルが一切表示されない場合でも、音声入力のループ処理自体はバックグラウンドで正常に動作しています。`layer-shell`非対応かつXWaylandを無効化した純粋なWaylandコンポジタ上では、Runeオーバーレイがウィンドウサーフェスを作成できませんが、キーを離せばテキストは通常どおりペーストされます。また、NVIDIA GPUと内蔵グラフィックスのハイブリッド構成を採用したWindows 11ノートPCでは、初期の3.xビルドにおいてクリックスルーオーバーレイに必要なレイヤードウィンドウ属性の設定処理に不具合があり、最新リリースへアップデートするまでHUDが非表示になる現象が確認されています。 ## OpenCodeによるオプションのペースト前テキスト整形 Parakeet Unifiedの出力をアクティブなウィンドウへ直接ストリーミングする方法は最速のレスポンスを誇りますが、生の音声文字起こしは話し言葉をそのまま反映します。考えながら途中で言葉に詰まったり、同じ単語を繰り返したり、ラフな箇条書きを口述したりすると、生の文字起こしではそうした言い淀みまで一字一句そのままペーストされてしまいます。 音声をクラウドへ送信することなくこの問題に対処するため、Hex 3.0にはアプリケーションへペーストする直前に文字起こしテキストをブラッシュアップするOpenCodeとのオプション連携機能が用意されています。このステップを有効にすると、音声をテキストに変換する処理自体は引き続きローカルの音響モデルで実行されますが、キーを離した直後にクリップボードからペーストする代わりに、文字起こし結果をOpenCodeへルーティングし、文法の修正やフィラー（言い淀み）の除去、入力先に合わせたフォーマット整形を行います。 ショートカットを離してから出力をペーストするまでの間にLLMによるクリーンアップ処理を挟むと、Parakeetストリーミングの100msという処理時間にさらなる遅延が加わるため、状況に応じて使い分けるのが最適です。ターミナルコマンドや変数名、一行程度のチャットメッセージを入力する際は、テキストが即座に表示されるようペースト前整形をオフにしておきます。一方、複数文にわたるメールの下書きやプルリクエストの説明文など、後から手作業で句読点を直すのに十五秒ほどかかりそうな場面では、OpenCodeのパスをオンにした方が結果的に時間を節約できます。 ## Hex 3.0とOS標準の音声入力およびMacWhisperとの比較 Hex 3.0、OS標準の音声入力、そして[MacWhisper](/en/posts/macwhisper-guide)のような専用デスクトップ文字起こしスイートのどれを選ぶかは、「プッシュ・トゥ・トークによるカーソル位置への即時入力」「単語ごとのリアルタイムな視覚的フィードバック」「多言語への柔軟な対応」のうち、どれを最も重視するかによって決まります。 macOS標準の「音声入力」やWindows 11の「音声入力」（`Win + H`）には、Hexのデフォルト表示と比べて明確な利点が一つあります。それは、話している最中にドキュメントへ直接単語が一つずつ挿入されるため、テキストエディタ内で文章が組み立てられていく様子を目で確認できる点です。しかし、Windowsの「音声入力」はMicrosoftのAzure Speechサーバへの常時インターネット接続が必要であり、また両OSの標準ツールともに、考え事をして数秒間話すのを止めると自動的にマイクがオフになってしまいます。Hexは100%オフラインで動作し、ホットキーに指を置いている限りタイムアウトすることがなく、クラウドの遅延なしで完成したテキストブロックを100msでペーストします。 MacWhisperと比較した場合、両者はローカル文字起こしワークフローにおける異なる領域を担っています。MacWhisperは、録音済みオーディオファイルのドラッグ＆ドロップ、システム音声や会議音声のキャプチャ、検索可能な文字起こしアーカイブの閲覧といった用途に優れています（macOSで会議やデスクトップ音声をキャプチャする他の方法を探している場合は、[Mac向けライブキャプションアプリの比較](/en/posts/live-caption-apps-mac)もあわせて参照してください）。MacWhisperにもmacOS向けのグローバル音声入力モードが搭載されていますが、Hexは軽量なクロスプラットフォームのプッシュ・トゥ・トーク専用ユーティリティとして設計されています。Parakeet Unifiedストリーミング使用時のRAM消費量は160MBに抑えられているため、巨大なWhisperモデルを一日中メモリに常駐させるとスワップ圧迫を引き起こしかねない8GBや16GBのノートPCでも、他の作業を妨げずに常駐させることができます。 Hex 3.0で注意が必要なのは、多言語での音声入力を行う場合です。160MBの超高速ストリーミング構成は、英語専用のParakeet Unifiedを前提に構築されています。ドイツ語、ポーランド語、ベトナム語、スペイン語、その他の言語で音声入力を行うには、**Settings → General → Speech model**を開き、カタログから多言語モデルをダウンロードする必要があります。カタログには、Parakeet v3、Whisper Large v3 Turbo、Qwen3-ASR、Cohere、および[NVIDIA Nemotron 3.5 ASR](/en/posts/nemotron-3-5-transcribe)などが用意されています。 複数の言語を併用する場合、現在のHexには実用上の制限が三つあります。一つ目は、Hex内の言語ドロップダウンメニューがスクロールバーを描画しないカスタムUIコンポーネントを使用している点です。約40言語をサポートするWhisper Large v3 Turboを選択した際、ドイツ語（`de`）のようにリストの下方にある言語は、開いたドロップダウンの上にカーソルを置いてマウスホイールやトラックパッドで下にスクロールしない限り、まるで非対応であるかのように見えてしまいます。二つ目は、Parakeet v3が手動の言語ピッカーを完全に無視し、音声からの自動言語検出に依存している点です。長めの文章であれば問題なく機能しますが、英語とポーランド語のように複数言語を行き来している場合、二単語程度の短いフレーズでは誤った言語と判定されることがあります。 三つ目は、Hexが一回のホットキー押下を単一のオーディオクリップとして処理するため、文の途中で言語を切り替えられない点です。設定画面で手動で言語を変更するとモデルの再読み込みが発生するため、Mac上で二つの言語を頻繁に切り替えて使う場合は、**Labs → switch model with keyboard language**を有効にするワークフローが最適です。これにより、macOSの各キーボード入力ソースと、ダウンロード済みの特定のモデルおよび言語のペアが紐付けられます。macOSのショートカットを押してキーボードレイアウトを切り替えるたびに、Hexはバックグラウンドで約300msのうちにアクティブな音声モデルを自動的に入れ替えます。 ## 出典と確認 - [anoma.ly/hex]() — 確認日 2026-11-02