Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드
シェア
Authors

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

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 違い

項目GPT-4oGemini LiveMoshi
価格高い中セルフホスティング
韓国語優秀優秀限定的
カスタム限定的限定的高い (オープン)
モーダル混合音声・テキスト音声・ビデオ・テキスト音声中心
エンタープライズAPI + ロギングGoogle Cloud自前で管理

第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」の時代、限界はもはや作る人の想像力だけだ。

Discuss on Twitter • View on GitHub