필사 모드: Voice AI 実践完全ガイド:リアルタイム STT/TTS、音声 LLM、Turn-taking、ディープフェイク防御 (2025)

Season 4 Ep 9 — Ep 8 ではオーディオは複数のモダリティのうちの一つだった。Ep 9 は音声プロダクト一つに集中する。リアルタイム性・自然さ・安全性 — この三つを同時に掴むのがなぜ難しいのか、そしてどう掴むのか。

• Prologue — 「画面のない AI」の年
• 第1章 · 二つのアーキテクチャ
  • 1.1 従来のパイプライン (STT → LLM → TTS)
  • 1.2 音声 LLM (end-to-end)
  • 1.3 2025 年のハイブリッドな現実
• 第2章 · リアルタイムパイプラインの設計
  • 2.1 VAD (Voice Activity Detection)
  • 2.2 ストリーミング STT
  • 2.3 LLM の処理
  • 2.4 ストリーミング TTS
  • 2.5 インターラプション (Barge-in)
• 第3章 · レイテンシバジェットの設計
  • 3.1 目標
  • 3.2 バジェットの例 (従来のパイプライン)
  • 3.3 短縮ポイント
  • 3.4 ジッターと安定性
• 第4章 · 音声 LLM — GPT-4o Realtime、Gemini Live、Moshi
  • 4.1 GPT-4o Realtime
  • 4.2 Gemini Live
  • 4.3 Moshi (Kyutai、オープン)
  • 4.4 違い
• 第5章 · 感情・抑揚・速度 — Expressive Speech
  • 5.1 TTS の制御軸
  • 5.2 SSML (Speech Synthesis Markup Language)
  • 5.3 感情の政治学
• 第6章 · 電話(PSTN)・ブラウザ・モバイル
  • 6.1 電話の統合
  • 6.2 ブラウザ
  • 6.3 モバイルアプリ
  • 6.4 自動車・組み込み
• 第7章 · ディープフェイク・音声クローンの脅威と防御
  • 7.1 脅威
  • 7.2 防御レイヤー
  • 7.3 ウォーターマーキング
  • 7.4 運用ポリシー
• 第8章 · 韓国語音声プロダクトの特殊性
  • 8.1 STT
  • 8.2 TTS
  • 8.3 法・規制
  • 8.4 文化・UX
• 第9章 · コスト・運用
  • 9.1 コストの構成
  • 9.2 スケーリング
  • 9.3 オブザーバビリティ
• 第10章 · 実戦ケース 3 選
  • 10.1 コールセンターの一次対応
  • 10.2 英会話学習アプリ
  • 10.3 シニアケア・ウェルビーイング
• 第11章 · UX 原則 12 か条
• 第12章 · アンチパターン 10 選
  • 12.1 レイテンシを測らずにリリース
  • 12.2 LLM に長すぎるプロンプト
  • 12.3 インターラプション処理がない
  • 12.4 感情・トーンに一貫性がない
  • 12.5 ディープフェイク検出だけを信じる
  • 12.6 法的告知の欠落
  • 12.7 バッチ TTS でリアルタイムを実装
  • 12.8 機微な取引を音声だけで
  • 12.9 方言・高齢者の音声を無視
  • 12.10 ログがない
• 第13章 · チェックリスト — Voice AI ローンチ前の 12 項目
• 第14章 · 次回予告 — Season 4 Ep 10:「LLM セキュリティ」

Prologue — 「画面のない AI」の年

2024 年 5 月の OpenAI による GPT-4o デモは音声 AI の転換点だった。レイテンシ ~300ms、自然な発音、感情表現、インターラプション — 従来の STT→LLM→TTS パイプラインでは到達しづらい品質を、単一の end-to-end モデルが見せた。

2025 年現在:

• コンタクトセンター: 単純な応対の 50%+ を音声 AI が処理する企業が登場
• 教育・コーチング: 英語・外国語の会話アプリの標準 UX
• ヘルス・カウンセリング: 治療的な対話の補助(医療アドバイスは依然として禁止)
• パーソナルアシスタント: 自動車・スマートホーム・ウェアラブル

この記事は「音声 AI を作るときに知っておくべきすべて」を一息で整理する。

第1章 · 二つのアーキテクチャ

1.1 従来のパイプライン (STT → LLM → TTS)

[マイク] → VAD → [ストリーミング STT] → [LLM] → [ストリーミング TTS] → [スピーカー]

• 各段階が独立 → 柔軟でデバッグしやすい
• モデル・ベンダーの選択が自由
• 短所: レイテンシの累積(500ms–1.5s)、感情・抑揚の消失

1.2 音声 LLM (end-to-end)

[マイク] → [音声 LLM: 音声 → 音声] → [スピーカー]

• オーディオトークンを直接入出力
• 感情・笑い・ため息まで再現
• レイテンシ ~300ms
• 短所: モデルサイズが大きい、ベンダーが限られる(OpenAI/Google/Moshi など)、細かい制御が難しい

1.3 2025 年のハイブリッドな現実

• リアルタイム双方向の対話 → 音声 LLM
• 非リアルタイム・バッチ処理 → 従来のパイプライン(コスト・ログの利点)
• エンタープライズ: コンプライアンス・監査の要求が強く、従来のパイプラインが依然として優勢
• コンシューマー: 音声 LLM が急速に普及

第2章 · リアルタイムパイプラインの設計

2.1 VAD (Voice Activity Detection)

• 目的: 話している区間だけを STT に送り、コストとレイテンシを削減
• モデル: Silero VAD(オープン)、WebRTC VAD、PyAnnote
• パラメータ: 閾値・最小発話長・無音による終了判定

2.2 ストリーミング STT

• 部分結果(partial transcript)を 250–500ms 単位で放出
• 最終結果(final transcript)は end-of-utterance 検出時
• Deepgram、AssemblyAI、Whisper(streaming)、Google/Azure/AWS、Clova/Kakao

2.3 LLM の処理

• partial transcript で「考え始める」ことが可能(あらかじめコンテキストを構築)
• final transcript が確定した時点で応答を生成
• Speculative generation: partial に基づいて先に答えを始める → final が確定したら修正

2.4 ストリーミング TTS

• 文の境界で順次再生
• 「考え中」のフィラー(uh/hmm)なしで自然な間合い
• レイテンシ短縮の要

2.5 インターラプション (Barge-in)

• ユーザーが話し始めたら TTS を即座に停止
• 部分的にしか再生されなかった応答は「要約・訂正」として次の発話に反映
• ロボット的ではない人間のように自然な中断の実装が UX の生命線

第3章 · レイテンシバジェットの設計

3.1 目標

研究でも現場でもよく引用される数値: 人の会話の平均的なターン間ギャップは ~200ms。AI が 500ms–1s 以内に応答すれば自然だと感じる。1.5s を超えると不自然になる。

3.2 バジェットの例 (従来のパイプライン)

VAD end-of-utterance 検出: 150ms
STT 最終結果: 150ms
LLM TTFT(最初のトークン): 300ms
TTS 最初のオーディオチャンク: 150ms
ネットワーク・デコード: 100ms
───────────────────
最初の音声再生までの合計: 約 850ms

3.3 短縮ポイント

• small/fast な LLMを first responder に(フィラー・相槌)
• ストリーミング: STT/LLM/TTS のすべてで
• 音声 LLM: アーキテクチャそのものが短い
• ロケーション: ユーザーに近いリージョンへデプロイ

3.4 ジッターと安定性

• 平均レイテンシより p95/p99が重要
• 一つのターンが長いと次のターン以降のリズム全体が崩れる → ユーザー離脱

第4章 · 音声 LLM — GPT-4o Realtime、Gemini Live、Moshi

4.1 GPT-4o Realtime

• 音声・テキストの双方向リアルタイム
• WebSocket/WebRTC ベース
• レイテンシ 300–500ms
• 価格はテキストよりかなり高いが、レイテンシと品質が圧倒的

4.2 Gemini Live

• 1M コンテキスト + リアルタイムマルチモーダル
• 画面共有・カメラ入力の組み合わせが可能
• インターラプションと感情表現に優れる

4.3 Moshi (Kyutai、オープン)

• オープンソースの音声 LLM
• 全二重(full-duplex)、低レイテンシ
• ローカル実行が可能 — プライバシー重視のプロダクトに魅力的

4.4 違い

第5章 · 感情・抑揚・速度 — Expressive Speech

5.1 TTS の制御軸

• トーン/ボイス: 人物像・性別・年齢
• 感情: neutral、happy、sad、angry、excited など
• 速度: 0.8x–1.5x
• 強勢: 特定の単語の強調
• 息づかい・間: <break time="300ms"/> のような SSML

5.2 SSML (Speech Synthesis Markup Language)

<speak>
  こんにちは、<break time="300ms"/>
  今日は <emphasis level="strong">とても大切な</emphasis> お話をしましょう。
</speak>

• Google、Microsoft、Naver Clova、Kakao などほとんどが対応
• ElevenLabs・OpenAI TTS は独自フォーマット(波括弧・自然言語での指示)

5.3 感情の政治学

• 企業のブランドトーン: 過度な感情は排除
• 子ども向けサービス: 温かいトーン、速度は遅めに
• 医療・カウンセリング: 中立的で落ち着いた調子

すべての声に同じトーンを使ってはいけない。サービスの文脈に合わせてプロファイルを分ける。

第6章 · 電話(PSTN)・ブラウザ・モバイル

6.1 電話の統合

• Twilio、Vonage、Plivo、SignalWire: プログラマブル電話
• SIP/PSTN ゲートウェイで音声ストリームを STT/LLM に渡す
• 韓国: LG U+ AI コール、KT AICC、Naver Cloud AiCall などの現地ソリューション

6.2 ブラウザ

• WebRTC で双方向オーディオ
• パーミッション、エコーキャンセリング、ノイズサプレッションが内蔵
• モバイルブラウザの互換性確認は必須

6.3 モバイルアプリ

• iOS: AVAudioEngine、Speech、AVSpeechSynthesizer
• Android: AudioRecord、MediaCodec、TTS API
• ネイティブ VAD を活用できる

6.4 自動車・組み込み

• 騒音・風切り音の補正
• 運転中の安全: 緊急時の短い応答
• オフラインモードは必須(接続が不安定)

第7章 · ディープフェイク・音声クローンの脅威と防御

7.1 脅威

• ボイスフィッシング: 家族の声を複製して緊急の送金を要求
• 経営者のなりすまし: CEO の声で送金を指示
• 身分のなりすまし: コールセンター・金融の本人確認を迂回

7.2 防御レイヤー

1. ライブネス検出: 用意されたセリフか、リアルタイムの応答を要求するか
2. 音声生体認証: 声紋 + 行動ベースの二重化
3. ディープフェイク検出: 合成音声の分類器(精度は 90% 台、完全ではない)
4. コールバック確認: 機微な要求は登録された番号にコールバック
5. AI 表示の義務化: 一部の国・州の法令(AI 音声である場合の告知)

7.3 ウォーターマーキング

• AI 生成音声に知覚できないウォーターマークを挿入(例: Google SynthID for audio)
• 検出器がウォーターマークを確認して AI 由来を識別
• まだ 100% 確実ではない — 防御レイヤーの一つとして扱う

7.4 運用ポリシー

• 機微な取引は「AI 音声での対応禁止」→ 人間に切り替え
• 音声ログの保管・監査(法令の範囲内で)
• 新規コール接続時の AI 案内: 「この通話は AI オペレーターが応対しています」

第8章 · 韓国語音声プロダクトの特殊性

8.1 STT

• 標準語の精度は Clova/Kakao で 95%+
• 方言のカバレッジはまだ不足
• 専門用語(医療・法律)にはカスタム辞書が必須

8.2 TTS

• Naver CLOVA Voice、Kakao i、Supertone: 自然さは最上位
• ElevenLabs の韓国語ボイスも急速に改善
• 韓国語特有の抑揚・敬語の話し方の制御が重要

8.3 法・規制

• 電気通信事業法・電子商取引法: 通話録音の告知は必須
• 個人情報保護法: 音声データも機微情報を含みうる
• 金融: 顧客確認(KYC)で AI 音声だけでは認証できない

8.4 文化・UX

• タメ口/敬語の一貫性
• 呼称(さん・様・お客様)のブランドポリシー
• 応答の冒頭に「はい、〜様」のような一言があると信頼度が上がる

第9章 · コスト・運用

9.1 コストの構成

• STT: 1 分あたり $0.003–0.02
• TTS: 1 文字あたり $0.00001–0.00005 (ボイス・品質による)
• LLM: トークン単位(入力/出力) — テキストと同じ
• 音声 LLM: 従来のパイプラインに比べて 2–5 倍高い傾向(2025 年前半)
• 回線(PSTN): 分単位の追加コスト

9.2 スケーリング

• 同時通話 N 件 → 各ストリームの TCP/WebSocket + LLM スロット
• オーケストレーション(Kubernetes + HPA) + リージョン分散
• Cold start を減らすためのウォームプール

9.3 オブザーバビリティ

• 通話ごとのレイテンシ(p50/p95)、インターラプションの頻度、人間への転送率
• ハルシネーション・不適切発言をリアルタイムに監視
• NPS・解決率のトラッキング

第10章 · 実戦ケース 3 選

10.1 コールセンターの一次対応

• ユースケース: 予約・住所変更・簡単な FAQ
• 複雑な問い合わせは人間のオペレーターへスムーズなハンドオフ(コンテキスト要約を引き継ぐ)
• 録音・コンプライアンス文言の自動チェック

10.2 英会話学習アプリ

• 音声 LLM(GPT-4o realtime)で自然な会話
• 発音評価(従来の STT のほうが正確)
• 適切な難易度調整(ユーザーの実力に合わせる)

10.3 シニアケア・ウェルビーイング

• 話し相手・簡単な通知・服薬リマインド
• 感情トーンは温かく、速度は遅めに
• 緊急事態(転倒・異常な症状)を検知したら保護者に連絡

第11章 · UX 原則 12 か条

1. レイテンシがすべて: 1 秒を超えると不自然
2. インターラプション: ユーザーが遮ったら即座に停止
3. 短く: 1 ターンあたり 3–5 文以内
4. 不確実性のシグナル: わからないときは「よくわかりません」と明示
5. スプーフィング防止: 機微な操作は音声だけでは不可
6. 感情の抑制: ブランドトーン優先、過剰な演出は禁止
7. フィラー: 「うん」「はい」のような短い信号で「聞いています」を伝える
8. 聞き返し: ユーザーが「なんて?」と言ったら速度・発音を調整
9. 終了シグナル: 「ほかにお手伝いできることはありますか?」で自然に締める
10. エラー復旧: STT が間違っていそうなら「私の理解で合っていますか?」と聞き返す
11. 個人情報の遮断: カード番号・住民番号の音声入力は避ける
12. アクセシビリティ: 聴覚障害者・高齢者向けの UX は別に設計

第12章 · アンチパターン 10 選

12.1 レイテンシを測らずにリリース

体感品質の 90% はレイテンシ。基準は p95。

12.2 LLM に長すぎるプロンプト

リアルタイム性が崩れる。システムプロンプトは短く鋭く。

12.3 インターラプション処理がない

話している最中も押し切ってくるロボット。UX を壊す。

12.4 感情・トーンに一貫性がない

ボイスを 3 つ混ぜて使い、ブランドが混乱する。

12.5 ディープフェイク検出だけを信じる

検出器は不完全。ライブネス・コールバック・ポリシーと併用する。

12.6 法的告知の欠落

通話録音・AI 応対の告知は必須。

12.7 バッチ TTS でリアルタイムを実装

チャンク単位のストリーミングに書き直す必要がある。

12.8 機微な取引を音声だけで

金融・医療の本人確認には追加チャネルを。

12.9 方言・高齢者の音声を無視

STT の精度のばらつきが大きい。サンプルの多様化 + カスタム化。

12.10 ログがない

紛争・品質改善の根拠を失う。

第13章 · チェックリスト — Voice AI ローンチ前の 12 項目

• p50/p95 レイテンシの目標と計測
• VAD/STT/LLM/TTS 各段階の障害フォールバック
• インターラプション処理の UX テスト
• 感情・トーンのプロファイル定義
• AI 応対の告知文言の挿入
• 録音・保管・破棄のポリシーが法令に準拠
• ディープフェイク・スプーフィングの防御レイヤー
• 人間へのハンドオフのトリガーとコンテキスト引き継ぎ
• ユーザー満足度(NPS/解決率)の計測
• 機微な取引・データは音声以外のチャネルを推奨
• 韓国語 STT/TTS の品質検証(ベンダー比較)
• アクセシビリティ(聴覚・高齢者)の代替経路

第14章 · 次回予告 — Season 4 Ep 10:「LLM セキュリティ」

音声もテキストも同じで、2025 年の LLM プロダクトにとって最大の脅威はセキュリティ事故だ。

• Prompt injection の 12 の変種
• Jailbreak・ロールプレイによる迂回
• Data exfiltration のベクトル
• Model extraction・パラメータ漏洩
• サービス拒否(DoS)、課金攻撃
• Red team の構築・自動化(PyRIT、Garak)
• ガードレールプロンプト vs 分類器モデル
• プライバシー・PII の漏洩
• サプライチェーン(モデル・MCP サーバー)の脅威
• 標準・規制 (EU AI Act、韓国の個人情報保護)
• インシデント対応プレイブック

「セキュリティは機能ではなくデフォルトだ」。ところが 2024–2025 年、多くの LLM プロダクトはまだ基本すら備えていない。

次の記事で会おう。

まとめ: Voice AI はリアルタイム性・自然さ・安全性の三拍子。従来のパイプラインと音声 LLM のどちらを選ぶかはレイテンシ・制御・コンプライアンスの要求次第であり、p95 レイテンシがユーザー体験の 90% を決める。感情・速度・トーンはブランドポリシーとして管理し、ディープフェイク・スプーフィングには多層防御が必須。韓国語プロダクトは Clova・Kakao・Supertone のような現地資産とグローバルな音声 LLM を組み合わせて品質の境界を最大化する。「画面のない AI」の時代、限界はもはや作る人の想像力だけだ。