Skip to Content
Docs03. 実装音声エージェントの実装
上級voice-agentsstreamingmultimodal更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

音声エージェントの実装

この記事の目的

音声で対話しツールで行動するエージェントを実装するときの設計判断を扱います。パイプライン型、単一の音声モデル、音声対話とバックエンドを分ける構成の選択、レイテンシ設計、ターンテイキングと割り込みの制御、ツール呼び出しとの統合、音声特有の評価を、自分の要件に合わせて組み立てられるようになります。

対象読者

  • 電話・アプリの音声対話でタスクを遂行するエージェントを設計・実装するエンジニア
  • テキストの Agent は動いているが、音声化でレイテンシ・会話制御の壁に当たっているエンジニア

前提知識

本文

概要: テキストとの差分は「沈黙」「ターン」「中間テキスト」

音声エージェントの実装は、テキストの Agent に 3 つの新しい問題が加わったものです。

  1. 沈黙が失敗に見える: テキストなら数秒の待ちは許容されますが、音声の沈黙は「壊れた」と感じられます。レイテンシ管理が体験の中心になります
  2. ターンテイキング: 「誰が話す番か」をシステムが判定する必要があります。ユーザーが話し終えた検出と、話し始めたときの割り込み処理という、テキストにない制御問題です
  3. 中間テキストの有無: 構成によっては「文字起こし → テキスト推論」という中間テキストが存在せず、ガードレールモデルの判断の外側でコードとして強制される制御。入力・出力・アクションの 3 層に配置し、プロンプトでの指示(お願い)と区別される。・監査・デバッグの制御点が変わります
音声エージェントの実装: 概要: テキストとの差分は「沈黙」「ターン」「中間テキスト」の図音声エージェントの実装: 概要: テキストとの差分は「沈黙」「ターン」「中間テキスト」の図
音声エージェントの実装: 概要: テキストとの差分は「沈黙」「ターン」「中間テキスト」の図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

音声エージェントの実装: 概要: テキストとの差分は「沈黙」「ターン」「中間テキスト」の図音声エージェントの実装: 概要: テキストとの差分は「沈黙」「ターン」「中間テキスト」の図

アーキテクチャと制御の位置

観点パイプライン型(STT → LLM → TTS)speech-to-speech 型(realtime)
レイテンシ3 段の遅延が積み上がる(ストリーミングLLM の応答を生成と同時に逐次受信・表示する方式。Agent の体感品質を左右する基本技術。で緩和)段間の往復がなく、最初の音声までが速い
制御性各段のテキストが取れる。ポリシーチェック・承認ゲート・決定的な分岐を挟みやすい中間テキストの制御点が減る(監査はトランスクリプト取得で補う)
既存資産テキスト Agent のプロンプト・評価・ガードレールを再利用できる音声モデル向けに調整し直す部分が出る
会話の自然さターン検出・割り込みを自前(またはミドルウェア)で組む割り込み・ターンテイキングが API 標準機能
部品の差し替えSTT・LLM・TTS を個別に選定・交換できるモデルとベンダーに一体で依存する

選択の目安です。電話応対のような自然な会話体験が主目的で、割り込みへの即応が要るなら speech-to-speech 型が有利です。各段の可視性が必須(発話前のポリシーチェック、承認ゲート、確定的な会話ログ)な業務や、既存のテキスト Agent を音声化する場合はパイプライン型が堅実です。2026-08 時点では、speech-to-speech の API は主要ベンダーの一部が一般提供・一部がプレビュー段階で、パイプライン型を公式の想定構成とするベンダーもあります。提供状況は変化が速いため、選定時に各社公式ドキュメントで確認してください(調査記録: research/professional/voice-agents.md)。

なお両者は排他ではありません。「検証はパイプライン型で始めて資産(プロンプト・評価)を作り、体験要件が確認できたら speech-to-speech に載せ替える」という段階的な進め方も現実的です。

部分再確認(2026-10-02): OpenAI の公式ガイドは、GPT-Live の全二重(full duplex)構成も区分しています。音声側は聞く・話すを同時に行い、推論・ツール処理は別のバックエンドへ委譲するため、処理中も会話を続けられます。既存のテキスト処理を接続するクライアント側委譲(client delegation)と、OpenAI がホストする Responses モデルへの委譲(Responses delegation)があり、いずれもアプリが権限と業務記録を制御します。単一モデルで音声・推論・ツールを担う Realtime API や、各段を検査するパイプラインとは制御点が異なります。会話の継続を業務処理の完了や承認に読み替えません。他社の提供条件・終了予定は2026-09-10の確認範囲のままです。

レイテンシ設計

音声の主要指標は first-audio latency(ユーザーが話し終えてから、最初の音声が返るまで) です。合計処理時間より「最初の音が出るまで」が体感を決めます。

  • パイプライン型は「全段ストリーミング」が定石: STT の逐次確定 → LLM のストリーミング出力を文単位で区切る → 文ごとに TTS へ流す、という構成で、全文完成を待たずに話し始められます。体感レイテンシを 3 割前後下げた公式実測例もあります(ストリーミングと Agent の UX 実装パターンの音声版です)
  • 段ごとに計測する: STT 確定まで・LLM の最初のトークンまで・TTS の最初の音声チャンクまで、を分けて計測し、どこがボトルネックかを特定します。平均でなく分布(p95)で管理します
  • 接続方式: ブラウザ・モバイルなどクライアント直結は WebRTC、サーバー間は WebSocket、という使い分けが公式に案内されています。電話は SIP 接続や電話基盤(CPaaS)経由の統合が提供されており、自前で音声搬送を作る必要はほぼありません(2026-08 時点)
  • 沈黙を埋める: 処理が長引く場面では、つなぎの発話(「確認しますね」)で沈黙を埋めます。次節のツール実行と組み合わせて設計します

会話制御: ターン検出と割り込み

  • ターン検出(ユーザーが話し終えたか): 音声活動検出(VAD: voice activity detection)が基本で、無音の長さで区切る方式と、発話内容から「言い終えた」確率を推定する方式(セマンティック VAD)があります。感度は 「早すぎる割り込み」と「応答の遅さ」のトレードオフで、無音しきい値・感度のパラメータをユースケースに合わせて調整します(考えながら話すユーザーが多い業務では長めに、テンポ重視の案内では短めに)
  • 割り込み(barge-in): モデルの発話中にユーザーが話し始めたら、進行中の生成・再生をキャンセルします。speech-to-speech API は標準機能として提供します。注意点は履歴のずれです — モデルが「話したつもり」の内容とユーザーに実際に届いた内容(割り込みで途中まで)が食い違うため、未再生分を切り詰めて履歴を実際に届いた範囲に揃える処理が要ります
  • 手動ターン制御: 騒音環境や確実性重視の業務では、自動検出をやめて明示的な操作(押して話す)にする選択肢もあります

ツール使用との統合

音声エージェントも行動はツール呼び出しです。音声固有の設計点は次のとおりです。

  • 音声セッション中の function calling: 主要な speech-to-speech API はリアルタイムセッション中のツール呼び出しに対応しています(2026-08 時点)。パイプライン型では LLM 段で通常どおりツールを使います
  • ツール実行中の沈黙: 数秒かかるツールの間、無言だと体験が壊れます。対策は (1) 実行前にひとこと発話(「調べますね」)、(2) ツール実行中も会話を継続できる非同期ツール実行(対応 API がある)、(3) 長い処理は「調べて折り返します」で会話を閉じ、完了後に通知する(非同期・長時間タスクの設計(耐久実行)への接続)
  • 高リスク操作の承認を音声だけにしない: 「はい」の一言を不可逆操作(送金・解約)の承認にすると、聞き間違い・言い間違い・本人性の問題を抱えます。金額や対象の復唱確認を最低限とし、リスクが高い操作は別チャネル(アプリ・SMS)での確認を挟みます(Human-in-the-Loop 設計)

音声特有の評価

テキストの評価(Agent 評価の基礎)に、音声ならではの軸が加わります。

評価軸見るもの測り方
タスク成功用件が解決したかテキストと同じ(トランスクリプトと最終状態で判定)
認識・了解性STT の誤認識、応答の聞き取りやすさ誤認識率の計測、人手サンプリング
応答速度first-audio latency分布(p95)で監視
会話制御の品質誤割り込み(考え中に被せる)、応答の待たせすぎ誤割り込み率・ターン間隔の計測 + 人手確認

実装上の要点は、speech-to-speech でも必ずトランスクリプト(文字起こし)を記録することです。トランスクリプトがあれば、既存の評価資産(LLM-as-a-Judgeコードでは採点できない開放的な出力を、基準を与えた別の LLM に判定させる評価手法。judge 自体の検証(人手ラベルとの一致率測定)を前提とする。・回帰テストプロンプト・ツール・モデルの変更で既存の品質が壊れていないかを、評価データセットの再実行と前回比較で検知するテスト。)と監査・デバッグの多くをテキストと同じ道具で回せます(可観測性とトレーシング)。評価セットには、静かな環境のきれいな発話だけでなく、実環境の入力(騒音・言い直し・方言・電話品質)を含めます。

音声認識と対話モデルの更新を別に追う

2026-09-10 確認の OpenAI 退役表は、whisper-1 / gpt-4o-transcribe / gpt-4o-mini-transcribe / gpt-4o-transcribe-diarize の終了日を 2027-02-26、代替候補を gpt-live-transcribe / gpt-transcribe と案内しています(告知 2026-08-26)。2027-01-20 の旧 realtime 系の終了日とは別です。話者分離・時刻情報・ストリーミング・音声入力形式を個別に照合します。

Google の 2026-08-26 リリースノートには Gemini 3.5 Transcribe と Transcribe Live の GA が掲載されています。専用の文字起こしモデルの GA を、Gemini Developer API の音声対話用 Live 全体の GA と読み替えません。

2026-10-03 の AWS 表にも旧 amazon.nova-sonic-v1:0 の EOL 期日 2026-09-14 が残っています。期日は経過していますが実停止・延期は確認不能です(ap-northeast-1 / eu-north-1 / us-east-1)。Nova 2 Sonic は別モデルです。期限の近い旧版を新規採用するのでなく、対象地域の後継で会話品質・割込み・ツール連携を評価します。

実務での注意点

アンチパターン

  • テキスト Agent の応答をそのまま読み上げる → 箇条書き・長文・URL の読み上げは音声では聞くに堪えない → 「短く・一度に 1 つ・確認を挟む」音声向けの応答スタイルをプロンプトで指定する
  • レイテンシを合計時間の平均で管理する → 体感を決める first-audio latency の悪化を見逃す → first-audio latency を段ごと・分布(p95)で計測する
  • VAD・ターン検出を既定値のまま運用する → ユーザー層に合わず、考え中に被せる・待たせすぎるが多発する → 誤割り込み率と応答遅延を測りながら感度を調整する
  • ツール実行中に無言で待たせる → 沈黙が故障と受け取られ、切られる・言い直される → つなぎ発話・非同期ツール・折り返し設計で沈黙を埋める
  • 音声の「はい」だけで不可逆操作を実行する → 聞き間違い・本人性の問題で事故になる → 復唱確認と、高リスク操作の別チャネル承認を設計する
  • トランスクリプトを残さない → デバッグ・評価・監査がすべて不可能になる → speech-to-speech でも文字起こしを記録し、テキストの評価資産に接続する

チェックリスト

  • アーキテクチャ(パイプライン / 単一の音声モデル / 音声対話と別バックエンド)の選択理由を制御点・レイテンシ・既存資産の観点で説明できる
  • first-audio latency を段ごと・分布で計測している
  • パイプライン型なら全段ストリーミング(文単位の TTS 送り)になっている
  • ターン検出の感度をユースケースに合わせて調整し、誤割り込み率を測っている
  • 割り込み時に未再生分を切り詰め、履歴を実際に届いた内容と揃えている
  • ツール実行中の沈黙対策(つなぎ発話・非同期・折り返し)がある
  • 不可逆操作に復唱確認・別チャネル承認がある
  • トランスクリプトを記録し、評価・監査に使える形にしている
  • 評価セットに実環境の入力(騒音・言い直し・電話品質)が含まれている

関連トピック

参考資料

TODO・未確認事項

ブラウザ・コンピュータ操作の実装ファインチューニングと蒸留