音声変換手段には、Web Speech、STT、Local LLM、Speech-to-Speechなどある（後者ほど高性能）。昨今は、Gemma4などのLocal LLMでもSpeech-to-Speech が可能。
主要な音声入力方式
| 方式 | 代表例 | 音声認識する場所 | 精度 | リアルタイム性 | 実装 | コスト | ブラウザ依存 | 向いている用途 |
|---|---|---|---|---|---|---|---|---|
| ① Web Speech API | SpeechRecognition | ブラウザが管理する認識サービス | ○ | ◎ | 非常に簡単 | ほぼ無料 | 大 | Webチャット、簡易音声入力 |
| ② 専用クラウドSTT | Azure Speech / Google STT / AWS Transcribe | クラウド | ◎ | ◎ | △ | 有料 | 小 | 業務システム、会議、字幕 |
| ③ 生成AI系STT API | OpenAI gpt-transcribe / Realtime transcription | AIクラウド | ◎〜◎+ | ◎ | ○ | 有料 | 小 | AIチャット、エージェント |
| ④ ローカルSTT | Whisper / large-v3-turbo等 | PC/GPU/サーバー | ○〜◎ | △〜◎ | △〜× | API費用なし | なし | 機密情報、オフライン |
| ⑤ Speech-to-Speech | OpenAI Realtime | AIモデルが直接音声理解 | ◎ | ◎◎ | △ | 有料 | 小 | 本格的な音声AI秘書 |
現在のLocal LLMの実力
| モデル | 規模 | ローカル適性 | OnoPiano用途 | コメント |
|---|---|---|---|---|
| OpenAI gpt-oss-20b | 21B / active 3.6B | ◎ | ◎ | 16GB以上のVRAM/Unified Memoryが目安。Ollama対応 |
| Gemma 4 12B | 12B | ◎◎ | ◎◎ | Q4で約6.7GB。音声入力もネイティブ対応 |
| Gemma 4 26B A4B | 26B / active 4B | ◎ | ◎◎ | Q4約14.4GB。性能/速度のバランスが非常に良い |
| Gemma 4 31B | 31B | ◎ | ◎ | Q4約17.5GB。より高品質 |
| Qwen3 30B-A3B | 30B / active 3B | ◎ | ◎ | 日本語・推論・ツール利用の候補 |
| Llama 4 Scout | 109B / active 17B | △ | ○ | 重い。個人PCよりGPUサーバー向け |
| Mistral Small 4 | 119B / active 6B | ×〜△ | ○ | 名前はSmallだが実際はかなり巨大 |
Gemma 4 と OpenAI Realtime の違い
| Gemma 4 12B Unified | OpenAI Realtime | |
|---|---|---|
| 音声入力 | ○ | ○ |
| Transcript | ○ | ◎ |
| 音声理解 | ○ | ◎ |
| 音声出力 | × 単体では不可 | ○ |
| Speech-to-Speech | × | ◎ |
| ストリーミング会話 | △ 実装必要 | ◎ |
| ローカル実行 | ◎ | × |
| オフライン | ◎ | × |
| API料金 | 不要 | 必要 |
| データを外部送信しない | 可能 | 不可 |
| 実装容易性 | △ | ◎ |
- Web Speech、STT、Local LLM、Speech-to-Speechをどう使い分けるか
- 1. まず押さえておきたいSTTとTTS
- 2. 方法1：ブラウザのWeb Speech API
- 3. 方法2：クラウドSTT
- 4. 方法3：WhisperなどによるLocal STT
- 5. 方法4：Local LLM自身に音声を理解させる
- 6. Gemma 4はSpeech-to-Speechなのか？
- 7. 方法5：Speech-to-Speech
- 8. TranscriptだけならSpeech-to-Speechは必須ではない
- 9. 主要方式を比較する
- 10. Local LLMの意味は今後さらに大きくなる
- 11. 今後は「STT」という独立した層が薄くなる
- 12. それでも専用STTはなくならない
Web Speech、STT、Local LLM、Speech-to-Speechをどう使い分けるか
生成AIアプリケーションに音声インターフェースを組み込む方法は、ここ数年で大きく変化している。
従来は、
音声 → 文字 → AI処理 → 文字
という構成が一般的だったが、現在では、
音声 → AI → 音声
までを一つのモデルで処理する Speech-to-Speech や、Local LLMが音声を直接理解する方式も登場している。
本記事では、2026年時点の主要な音声処理技術を整理し、それぞれの特徴と今後の方向性を考える。
1. まず押さえておきたいSTTとTTS
音声AIで頻繁に登場するのが STT と TTS である。
STT（Speech-to-Text）
音声
↓
STT
↓
文字
人間の発話を文字列へ変換する技術であり、「文字起こし」「音声認識」「ASR（Automatic Speech Recognition）」などとも呼ばれる。
一方、
TTS（Text-to-Speech）
文字
↓
TTS
↓
音声
は、AIが生成した文章などを音声として読み上げる技術である。
従来型の音声AIは、このSTTとTTSをLLMの前後に配置する構成が基本だった。
🎤
↓
STT
↓
Text
↓
LLM
↓
Text
↓
TTS
↓
🔊
現在も非常に重要なアーキテクチャである。
2. 方法1：ブラウザのWeb Speech API
最も手軽な方法の一つが Web Speech API である。
JavaScriptから、
SpeechRecognition
などを利用し、ブラウザに音声認識を行わせる。
Web Speech APIは、Webページから音声認識と音声合成を利用するために設計されたAPIで、仕様上はサーバー型認識・端末内認識の両方を許容している。
典型的な構成は、
🎤
↓
Browser
↓
Web Speech API
↓
Text
↓
Web Server
↓
LLM
となる。
メリット
- 実装が非常に簡単
- STT専用サーバーを構築する必要がない
- アプリサーバーには文字列だけを送ればよい
- 小規模Webアプリに適する
一方で、ブラウザやOSによる対応状況の差がある。SpeechRecognitionは現在もすべての主要ブラウザで同一条件で利用できる機能ではない。
したがって、簡易音声入力には非常に便利だが、重要な業務用文字起こし基盤を完全に依存させる場合には注意が必要である。
3. 方法2：クラウドSTT
本格的な音声認識では、専用クラウドSTTを使う方法が一般的である。
代表例として、
- Microsoft Azure Speech
- Google Cloud Speech-to-Text
- Amazon Transcribe
- OpenAI Realtime Transcription
などがある。
例えば、
Browser / App
↓ Audio
Cloud STT
↓ Text
Application
↓
LLM
という構成になる。
Azure Speechはリアルタイムおよびバッチ文字起こしに対応している。
Google Cloud Speech-to-Textもストリーミング音声を送りながら途中結果を受け取ることができる。
Amazon Transcribeもストリーミングをサポートし、SDK、HTTP/2、WebSocketなどから利用できる。
クラウドSTTの強み
- 高い認識品質
- リアルタイム処理
- ブラウザ依存を減らせる
- 長時間音声への対応
- 話者分離や専門用語対応などの機能
- サーバー側で品質を統一しやすい
その代わり、API利用料金とインターネット接続が必要になる。
4. 方法3：WhisperなどによるLocal STT
音声を外部サービスに送らず、自分のPCやGPUサーバーで文字起こしすることもできる。
代表的なのが Whisper である。
WhisperはOpenAIが公開している汎用音声認識モデルで、多言語音声認識、音声翻訳、言語識別などを実行できる。
構成は、
🎤
↓
Local Server
↓
Whisper
↓
Text
↓
LLM
となる。
Local STTのメリット
最大のメリットはプライバシーである。
音声データを外部クラウドへ送信せず、
マイク
↓
自社PC / 自宅PC / 社内GPU
↓
文字
まで処理できる。
また、APIを使用しないため、大量の音声を処理する場合にはランニングコストを抑えられる可能性がある。
一方、
- GPUやCPU性能が必要
- モデルの管理が必要
- リアルタイム化には追加実装が必要
- 同時接続数が増えると計算資源が必要
といった課題も存在する。
5. 方法4：Local LLM自身に音声を理解させる
2026年に特に興味深い変化が、
STT専用モデルとLLMの境界が曖昧になってきたこと
である。
例えばGoogleのGemma 4では、一部モデルが音声入力に対応している。
Gemma 4のE2B、E4B、12BモデルはAudio入力を処理でき、音声認識、翻訳、音声内容の理解などを行える。出力はテキストである。
つまり、
従来
Audio
↓
Whisper
↓
Text
↓
LLM
↓
Answer
だったものを、
Audio
↓
Multimodal LLM
↓
Transcript / Answer
とすることが可能になりつつある。
GoogleもGemma 4向けに、音声データから直接文字起こしを行うASR用プロンプトを公開している。
これはかなり大きな変化である。
例えば会議音声を入力して、
「この音声を文字起こしして」
だけでなく、
「この会議の決定事項だけ抽出して」
「発言内容から技術的な課題を5つ挙げて」
といった処理まで、一つのモデルで実行できる可能性がある。
6. Gemma 4はSpeech-to-Speechなのか？
ここは区別が必要である。
Gemma 4はAudio入力を扱えるが、基本的には、
Audio
↓
Gemma 4
↓
Text
である。
つまり、
Audio-to-Text / Audio Understanding
であり、モデル単体で、
Audio
↓
AI
↓
Audio
を実現するSpeech-to-Speechモデルではない。Gemma 4の公式モデルカードでも、マルチモーダル入力からテキストを生成するモデルとして説明されている。
音声で回答させたいなら、
Audio
↓
Gemma 4
↓
Text
↓
TTS
↓
Audio
とする必要がある。
7. 方法5：Speech-to-Speech
現在最も先進的な方式の一つが Speech-to-Speech である。
従来型は、
Audio
↓
STT
↓
Text
↓
LLM
↓
Text
↓
TTS
↓
Audio
だった。
Speech-to-Speechではアプリケーションから見ると、
🎤
↓
Voice AI
↓
🔊
となる。
OpenAI Realtime APIはこのタイプのアーキテクチャを提供している。
OpenAIは現在、音声エージェントの構成として、
- Speech-to-Speech
- STT → LLM → TTSというChained Architecture
の2方式を明確に区別している。Speech-to-Speechは自然で低遅延な会話に向き、Chained方式は文字起こしや処理内容をアプリ側で明確に制御したい場合に向く。
Realtime APIでは、音声入力・音声出力を直接扱うことができ、ブラウザからの接続にはWebRTCを使用できる。
8. TranscriptだけならSpeech-to-Speechは必須ではない
ここは重要である。
目的が単純な文字起こしなら、
Speech-to-Speech
まで使う必要はない。
OpenAIにもRealtime Transcription専用モードがあり、
Streaming Audio
↓
Realtime Transcription
↓
Transcript Delta
↓
Final Transcript
という処理が可能である。発話の途中から文字列の差分を受け取れるため、リアルタイム字幕などにも利用できる。
したがって「音声AI」と一言で言っても、
文字起こしが欲しいのか、AIと会話したいのか
によって最適な技術は異なる。
9. 主要方式を比較する
| 方式 | 音声→文字 | リアルタイム | ローカル | API費用 | 実装難度 | 主な用途 |
|---|---|---|---|---|---|---|
| Web Speech API | ○ | ◎ | △ | ほぼ不要 | 低 | Web音声入力 |
| Azure / Google / AWS STT | ◎ | ◎ | × | 必要 | 中 | 業務文字起こし |
| OpenAI Realtime Transcription | ◎ | ◎ | × | 必要 | 中 | AIアプリ・ライブ字幕 |
| Whisper Local | ◎ | ○ | ◎ | 不要 | 中 | 機密情報・大量処理 |
| Audio対応Local LLM | ○〜◎ | △〜○ | ◎ | 不要 | 中〜高 | STT＋内容理解 |
| Speech-to-Speech | ○ | ◎◎ | 基本クラウド中心 | 必要 | 中 | 音声AIエージェント |
重要なのは、「どれが最高か」ではなく、用途によって最適解が違うことである。
10. Local LLMの意味は今後さらに大きくなる
現在、Local LLMは単なるテキスト生成モデルではなくなりつつある。
Text
Image
Audio
Video
といった複数の情報を一つのモデルで扱うマルチモーダル化が進んでいる。
Gemma 4のようにAudio入力と推論を組み合わせられるLocalモデルが登場したことで、
STT
+
LLM
を一つのモデルに統合できるケースが増えてくる。
これは特に、
- 社内会議
- 技術会議
- 医療・研究
- オフライン端末
- 機密情報
- 大量の録音データ解析
などで大きな意味を持つ。
11. 今後は「STT」という独立した層が薄くなる
今後数年間の大きな方向性は、おそらく次のようになる。
第1世代
Audio
↓
STT
↓
LLM
第2世代
Audio
↓
Multimodal LLM
↓
Text / Analysis
第3世代
Audio
↓
Multimodal Voice AI
↓
Audio
そしてLocalモデルでも、
🎤
↓
Local AI
↓
🔊
が一般的になる可能性が高い。
これは単に部品が一つ減るという話ではない。
従来のSTTは基本的に、
「何と言ったか」
を認識する技術だった。
Audio-nativeな生成AIは、
「何を言ったか」
「どういう意味か」
「どう答えるべきか」
まで同じモデルで扱える。
この違いは非常に大きい。
12. それでも専用STTはなくならない
一方、専用STTがすぐになくなるとは考えにくい。
例えば議事録では、
- 正確な逐語録
- タイムスタンプ
- 話者分離
- 認識信頼度
- 再現性
などが重要になる。
このような用途では、
STT
↓
確定Transcript
↓
LLM解析
と分離した方がシステムとして扱いやすい。
一方でAIアシスタントなら、
Audio
↓
AI
↓
Audio
の方が自然である。
つまり今後は、
STTが消滅するというより、用途によって「専用STT」と「音声ネイティブAI」が使い分けられる
と考えるべきだろう。
まとめ
生成AI時代の音声処理は、大きく5つの方式に整理できる。
- Web Speech API
最も簡単なWeb音声入力。 - Cloud STT
Azure、Google、AWSなどを利用する本格的な音声認識。 - Local STT
Whisperなどを自分のマシンで実行する方式。 - Audio対応Local LLM
Gemma 4などに音声を直接入力し、文字起こしと理解を統合する方式。 - Speech-to-Speech
音声を直接理解し、音声で返答する次世代Voice AI。
現在はまだ、
STT → LLM → TTS
が制御性と実用性の高い構成である。
しかし技術の流れを見ると、
Audio → Multimodal AI → Audio
へ向かっていることはかなり明確である。
さらにLocal LLMの高速化、小型化、マルチモーダル化が進めば、
Cloud Voice AI
だけでなく、
Local Voice AI
も一般的になるだろう。
その段階では「音声認識モデルを何にするか」という現在の議論そのものが変わり、
「音声を含めて世界を理解するAIを、Cloudで動かすかLocalで動かすか」
という設計判断へ移っていく可能性が高い。
コメント