Whisper系STTで「どのアプリにも入力できる」デスクトップ音声入力を考える
日本語で長い文章を書くとき、キーボードより音声入力のほうが速い場面があります。
ただし、実際にデスクトップで使おうとすると、単に「音声を文字起こしする」だけでは足りません。
自分がこのあたりを触っていて一番よく感じたのは、STTそのものよりも「どこに、どう戻すか」のほうで体験が決まるということでした。認識結果が正しくても、毎回コピーして貼るなら日常作業には残りません。
たとえば、次のような問題があります。
- ブラウザでは使えるが、エディタやチャットアプリでは使いにくい
- 文字起こし結果を毎回コピー&ペーストする必要がある
- 日本語の句読点や改行があとから整形しにくい
- STTプロバイダーを固定すると、速度・精度・コストを調整しにくい
- ローカル処理とクラウド処理の使い分けが難しい
この記事では、Whisper系STTを使った「デスクトップ音声入力」の設計を、実装寄りに整理します。
特定サービスの宣伝というより、音声入力アプリを作る/選ぶときのチェックリストとして読める内容を目指します。
文字起こしアプリと音声入力アプリは少し違う
まず分けて考えたいのが、文字起こしと音声入力です。
文字起こしアプリは、録音ファイルや会議音声をあとからテキスト化する用途が中心です。
一方、音声入力アプリは、今開いているアプリにそのまま文章を入れる用途が中心です。
音声入力で重要になるのは、STTの精度だけではありません。
| 観点 | 文字起こし | デスクトップ音声入力 |
|---|---|---|
| 入力元 | 録音ファイル、会議音声 | マイクからの短い発話 |
| 出力先 | テキストファイル、議事録 | 現在フォーカス中のアプリ |
| 操作 | アップロード、変換、編集 | ホットキー、録音、挿入 |
| 品質 | 話者分離、長時間処理 | 低遅延、句読点、自然な文章 |
| 失敗時 | 再変換しやすい | すぐ分かるエラー表示が必要 |
日本語の「音声入力 アプリ」で探している人は、この後者を求めていることが多いです。
最小構成の流れ
デスクトップ音声入力の最小構成は、だいたい次の流れになります。
ホットキー
-> 録音開始
-> 音声バッファ作成
-> STTに送信
-> テキストを受け取る
-> 必要ならLLMで整形
-> 現在のアプリに挿入
ここで面白いのは、STT部分だけを速くしても、最終的な体感はあまり上がらないことです。録音開始のフィードバック、途中状態、失敗時の戻り方、挿入後の文章品質が全部つながって、はじめて「使える」感覚になります。
この流れの中で、体感品質を左右するポイントは3つあります。
- 録音の開始と終了が分かりやすいこと
- STTの失敗が「考え中」のまま隠れないこと
- 出力テキストが、そのまま貼れる品質に近いこと
特に3つ目は日本語で重要です。
音声認識の結果が正しくても、話し言葉のままだとメールやドキュメントには貼りづらいからです。
STTプロバイダーを固定しない理由
Whisper系のローカル処理は、プライバシーやオフライン性の面で魅力があります。
一方で、クラウドSTTのほうがセットアップが簡単で、軽いPCでも使いやすい場合があります。
そのため、実用的な音声入力アプリでは、次のような選択肢を持てると便利です。
- ローカルSTT: 音声を外に出したくない作業向け
- クラウドSTT: セットアップを簡単にしたい場合向け
- BYOK: 自分のAPIキーでコストやプロバイダーを管理したい場合向け
- LLM整形: 句読点、敬体/常体、箇条書き、メール調整などに使う
「どれが一番良いか」よりも、「作業ごとに選べるか」が重要です。
実装時に気をつけたいエラー処理
音声入力で一番困るのは、失敗した理由が分からないことです。
よくある失敗は次の通りです。
- マイク権限がない
- 入力デバイスが違う
- 無音のまま録音された
- STTリクエストがタイムアウトした
- LLM整形が失敗した
- 挿入先アプリにテキストを送れない
このとき、UIがずっと「考え中」のままだとユーザーは詰まります。
録音、STT、LLM、挿入のどこで止まったのかを分けて表示するほうが親切です。
recording
-> transcribing
-> polishing
-> inserting
-> done / error
音声入力は「待てばそのうち終わる」機能ではなく、短い操作を何度も繰り返す機能です。
だからこそ、失敗時の戻り方が体験に直結します。
Ask Anythingのような一回限りの音声質問
通常の音声入力は、テキストを今のアプリに挿入するためのものです。
一方で、最近は「声でAIに一度だけ質問したい」という使い方もあります。
自分の場合、これはコードを書いているときに多いです。エディタに文章を入れたいわけではなく、「このエラーどう見るべき？」とか「この設計の弱点は？」みたいな質問を一回だけ投げたい場面があります。
この場合は、チャット履歴を持つよりも、次のような一回限りの流れが自然です。
録音
-> STT
-> 文字起こしをそのままLLMに送る
-> 結果だけを表示
ポイントは、入力欄をもう一度出さないことです。
音声で質問したのに、最後にテキスト入力欄や送信ボタンが出てくると、音声で始めた意味が薄くなります。
OpenTypelessで試していること
OpenTypelessでは、デスクトップ上のどのアプリにも使える音声入力を目指して、次のような構成を試しています。
- Mac / Windows / Linux向けのデスクトップ音声入力
- STTとLLMのプロバイダー選択
- BYOKによる自分のAPIキー利用
- AIによる文章整形
- Ask Anythingによる一回限りの音声質問
製品ページはこちらです。
まだ改善すべき点はあります。特に日本語では、句読点、敬体/常体、固有名詞、技術用語の扱いで細かい調整が必要です。
それでも、個人的には「音声を文字にする」だけでなく、「今の作業にそのまま入るテキストにする」ことが、日本語のAI音声入力ではかなり重要だと感じています。
まとめ
日本語のデスクトップ音声入力を考えるときは、STT精度だけでなく、次の点を見ると判断しやすいです。
- どのアプリにも入力できるか
- マイク権限や無音時のエラーが分かりやすいか
- ローカル/クラウド/BYOKを選べるか
- 日本語の句読点や話し言葉を整えられるか
- AIへの一回限りの質問にも使えるか
音声入力は、会議の文字起こしとは別のカテゴリとしてもっと発展しそうです。
特に、ChatGPT、Cursor、Notion、メール、ドキュメント作成のような日常作業では、キーボード入力とは違うワークフローが作れます。