これが AI ビルダーに誰も教えない真実だ。音声エージェントに必要なのは、最高のモデルではない。必要なのはたったこれだけだ。
TLDR; 読むのが退屈だったり、注意力が散っているなら、私が作ったスキルファイルを使って記事全体をエージェントに貼り付けられる ➡️https://github.com/codejunkie99/voice-agent-builder
構築に必要なのは、たったこれだけ：
- リアルタイムパイプラインと実際のレイテンシ予算
- 正しい順序で配線された 5 つのコンポーネント
- モデルを正直に保つための十分なグラウンディング
- 毎週のレビューループで積み上げる
OpenAI は 2026 年 5 月 7 日に GPT-Realtime-2 をリリースした。Salesforce AI Research は 3 月 1 日に VoiceAgentRAG 論文を発表し、同じ週に Deepgram Flux はベータ版から GA に移行した。部品自体は問題ではなくなった。
問題であり続けたのは、それらの配線方法と、エージェントに何を言わせるかだ。
私はこの 3 ヶ月、実際に電話に出る音声エージェントの構築に費やしてきた。そのプロセスが決してきれいだったとは言わない。
- 最初のビルドはキオスクみたいな声だった。2 日で捨てた。
- 2 番目のビルドは、最初の 1 時間で 4 件の幻の予約を「入れた」ことに気づくまで放置した。
- 3 番目のビルドは、バックグラウンド抽出機能が新しい情報を書き込んだ後にコンテキストキャッシュを無効化するのを忘れてメモリリークした。
- 何かが動くようになった時には、システムは 4 回目の書き直しだった。
今なら守れるバージョンには、いくつかの特性がある。それをこれから 6,000 字かけて説明する。
- パイプラインは 1 つの予算内で 1 つの仕事をする。5 つのコンポーネント、エンドツーエンドで 700ms 未満、例外なし。
- ナレッジはドキュメントに存在し、デュアルエージェントキャッシュで取得される。モデルの頭の中から引き出されるわけではない。
- 会話デザインは、耳に向けて書く技術であって、目に向けて書くものではない。ほとんどのチームはこれを表面的なものと見なすが、そうではない。
- 毎ターン、構造化ログを書き込む。それを 90 日後に現在の設定に対して再生できる。
この記事は、その 90 日間が実際に教えてくれたことと、もし今日最初からやり直すなら最初に賭けるであろう 2、3 の選択だ。🔽🔽
音声エージェントとは実際何か
音声エージェントは、マイクをくっつけたチャットボットではない。テキスト API の TTS ラッパーでもない。
それはリアルタイムの音声システムだ。レイテンシに制約がある。5 つのコンポーネントが 300 ミリ秒から 800 ミリ秒のウィンドウ内で連携する。
イベントが実際に発生する順序のパイプライン：
- ユーザーが話す
- 音声がキャプチャされる
- ストリーミング STT が、相手がまだ話している間に、単語ごとに文字起こしする
- エージェントが文字起こしを読み、ドキュメントから関連知識を取得する
- LLM が応答を生成する
- TTS が応答を音声で読み上げる
- ユーザーがそれを聞く
これらの矢印の 1 つ 1 つが、選択、調整、交換可能なコンポーネントだ。
私は最初にチャットボット方式で構築しようとした。STT が完了し、LLM に送信し、完全な応答を待ち、TTS に送信し、完全な音声を待ち、再生する。
ひどかった。キオスクと話しているようだった。2 日で削除した。
ひどく感じた理由は、レイテンシの数値が悪かったからではない。紙の上では問題なかった。理由は、人間は順番に会話するわけではないからだ。人間は重なるストリームで会話する。
- エージェントは、ユーザーがまだ文を終えていないうちに応答を練り始めなければならない。
- TTS は、LLM が書き終える前に話し始めなければならない。
- STT は、エージェントが話している間も聞き続け、いつ黙るべきかを知らなければならない。
中断できない音声エージェントは、音声エージェントではない。それはボイスメールだ。
3 つのアーキテクチャ
3 つしかない。何を制御したいかで選べ。
チェーンパイプライン
- 個別の STT、LLM、TTS サービスを配線
- それぞれのジョブに特化した 3 つの独立したモデル
- テキストがそれらの間を流れる
- 適切に調整されたマネージドプラットフォームで、レイテンシは約 600 ～ 700ms
- 最も制御可能、最もデバッグしやすい、1 層ずつアップグレードしやすい
ハーフカスケード
- 音声が直接マルチモーダルモデルに入力される。デコードされたテキストではなく、音声そのものを聞く
- 声のフラストレーション、語尾の上がり調子で示唆される質問、文中での言語切り替えを捉える
- 出力は、音声制御のために専用の TTS を経由する
- レイテンシは 300 ～ 500ms に低下する
ネイティブ音声間（スピーチトゥスピーチ）
- 1 つのモデル、音声入力、音声出力
- 文字起こし層なし、テキストの受け渡しなし
- 2026 年までに主要な研究所はすべてネイティブ音声モデルをリリースした
- レイテンシは 200 ～ 300ms に低下し、発信者が AI と話していることに気づかなくなる閾値を下回る
どれから始めるか
- チェーンパイプラインから始めよ。これに対する最高のツールが存在する。パイプライン上で製品を証明し、段階的なレイテンシ改善を望むなら、音声間モデルに移行せよ。
- 私はすべてを最初から音声間モデルで試した。予約フローには優れていた。
- しかし、12 ステップの問診票で崩壊した。なぜなら、単一モデルはターン 9 までにコンテキストが肥大化し、状態機械を頭の中に保持できなかったからだ。
- そのモデルを、実際の状態機械層を持つチェーンパイプラインに移行したところ、完了率は 3 日間で 61% から 89% に跳ね上がった。
- 状態ごとのツールスコーピングがすべての修正だった。
配線しなければならない 5 つのコンポーネント
すべてのチェーンパイプラインには、同じ 5 つのコンポーネントがある。エージェントが最初の電話を受ける前に埋めなければならない 5 つのジョブだ。
耳（ストリーミング STT）
STT モデルは、入力音声をリアルタイムで、単語ごとに、相手がまだ話している間にテキストに変換する。これはスタックの中で最も影響力の大きいコンポーネントだ。ここでの文字起こしエラーは、以下のすべてに波及する。
2026 年に注目すべき点：
- ストリーミング精度。相手が話している最中でも正確であること。話し終えた後だけでなく。
- ワードエラー率。実際のプロダクション音声で 6 ～ 8% が良好。12% を超えると、3 回に 1 回の割合でユーザーをイライラさせる。
- 組み込みのターン終了検出。2026 年の最大の UX アップグレードと言える。
ターン終了検出が重要な理由：
- 汎用 STT は文字起こしを返す。話し手がいつ終わったかは教えてくれない。
- それがなければ、エージェントは文中で割り込むか、気まずい 2 秒の間を置くかのどちらかになる。
- 2026 年のストリーミング STT モデルの波は、文字起こしを生成する同じネットワーク内にターン終了検出を搭載して出荷されている。
- モデルは、話し手が終えたと判断した時点で、ターン完了シグナルを発する。
- このシグナルは、単なる音響的な無音ではなく、意味的なコンテキストを使用する。語尾が消えていくのを捉え、呼吸の間を無視する。
- プロバイダーがこれを出荷しているなら、切り替えよ。エージェントが話し始める前の間が、毎ターン 200 ～ 400ms 短縮される。
脳（LLM）
LLM は、文字起こし、会話履歴、取得されたナレッジを読み、何を言うかを決定する。また、単なる言葉だけでなく、行動も決定する。
音声固有のルール：
- 小型で高速なモデルを使え。フラッグシップは使うな。フロンティア推論モデルは、最初の単語を生成するのに 1500ms かかる。それは無音だ。同じファミリーの小型モデルは、ほとんどの場合、音声ターンで勝つ。
- 実際の計画が必要な特定の複雑なツール呼び出しに対してのみ、大型モデルにエスカレーションせよ。
- システムプロンプトは 800 トークンに制限せよ。毎ターン再読み込みされる。4000 トークンのプロンプトは、すべてのメッセージにレイテンシを追加する。
関数呼び出し、平たく言えば：
- 各関数を、何をするか、どんな情報が必要かの説明と共に定義する。
- LLM は説明を読み、会話の状態に基づいて、いつそれを呼び出すかを決定する。
- 条件分岐のロジックツリーは不要。LLM は自然言語から意図を関数にマッチングする。
関数呼び出しにおける最も一般的なプロダクション障害は、予想外のものだ：
- LLM は関数を呼び出せない場合でもエラーを投げない。代わりにアクションを説明する。
- 「予約を確認しました。」何も呼び出されていない。ユーザーは予約されたと思う。されていない。
- 修正方法は、ツールを現在の状態にスコープすることだ。「名前を収集する」状態では、book_appointment を公開してはならない。「詳細を確認する」状態では、check_availability を公開してはならない。
- 状態機械が安全レールであり、システムプロンプトではない。
ナレッジ（RAG）
RAG は、モデルの学習データではなく、ドキュメントからエージェントが回答できるようにするメカニズムだ。
これをスキップできない理由：
- LLM は、ある基準日までの公開インターネットで学習されている。
- 世界については多くのことを知っているが、あなたの製品、価格、ポリシー、顧客については何も知らない。
- RAG がなければ、「エンタープライズプランには何が含まれていますか？」と聞かれたエージェントは、自信満々に幻覚を見るだろう。
- RAG があれば、応答する前に実際の回答をドキュメントから取得する。
基本的な仕組み：
- ユーザーが質問する。
- システムがクエリを埋め込む。
- ベクトルデータベースが、関連する上位のドキュメントチャンクを返す。
- チャンクが LLM のコンテキストに注入される。
- LLM は、そのコンテキストからのみ答えるように指示される。
音声固有の課題：
- 典型的なベクトルデータベースクエリは、パイプラインに 50 ～ 300ms を追加する。
- STT、LLM、TTS と組み合わさると、レイテンシ予算を超過する。
- 修正方法は、デュアルエージェントキャッシュパターンだ。これについては以下のセクション全体で説明する。
口（TTS）
TTS はテキストを音声に変換する。単純そうに聞こえるが、実際には知覚品質における主要な差別化要因だ。
重要な点：
- 最初の音声までの時間。話し始めるのに 200ms かかる TTS は、出力層だけでレイテンシ予算の 3 分の 1 を消費する。
- 音声品質。人間は合成音声に非常に敏感だ。微妙なアーティファクト、不自然なテンポ、誤った強調はすべて、システム全体に対する評価として受け取られる。
- 意図的に声を選べ。ユーザーが一文を聞く前の信頼シグナルとなる。
手（関数と統合）
関数は、LLM が会話中に実行できるアクションだ：
- 予約を入れる
- 注文状況を確認する
- 確認 SMS を送信する
- 人間に転送する
- CRM のレコードを更新する
これが、最新の音声エージェントを、1 番を押して請求部門につなぐような従来のシステムよりも劇的に有能にするアーキテクチャ上のシフトだ。
収まらなければならないレイテンシ予算
音声エージェントに関する最も重要でわかりにくい点：処理時間の 1 ミリ秒 1 ミリ秒が、発信者が座して待つ無音の時間になる。
計算：
- 人間は、文を終えてから 500 ～ 700ms 以内の会話的な返答を期待する
- 1 秒を超えると、システムが苦戦しているように感じる
- 2 秒を超えると、発信者はエージェントの話に割り込み始める
この 700ms があなたの全予算であり、すべてのコンポーネントに分割される。
コンポーネントごとの予算、高速レーン vs 低速レーン：
- 転送。ピアツーピアで 20 ～ 50ms。リレー経由で 50 ～ 100ms。
- STT 最初の中間結果。キャッシュヒット時 100 ～ 150ms。ミス時 150 ～ 250ms。
- ターン終了検出。モデル統合型、約 50ms。無音閾値型、300 ～ 600ms。
- RAG 検索。キャッシュヒット時 1ms 未満。ローカル BM25 + リランク時 80 ～ 150ms。
- LLM の最初のトークンまでの時間。小型モデルで 150 ～ 250ms。フロンティアモデルで 400 ～ 600ms。
- TTS の最初の音声までの時間。高速ティアで 60 ～ 100ms。品質ティアで 150 ～ 250ms。
- ネットワークオーバーヘッド。同一リージョン内で合計 40 ～ 80ms。リージョン間で合計 100 ～ 160ms。
- エンドツーエンド。高速レーンで約 440ms。低速レーンで約 700 ～ 900ms。
2026 年の 2 つの最大のブレイクスルー：
- モデル統合型ターン終了検出。毎ターン 200 ～ 400ms を削減。今年できる最大の単一アップグレード。
- デュアルエージェントキャッシュによる投機的プリフェッチ。約 40% のターンで、検索を「ベクトル検索によるミス」から「キャッシュルックアップによるヒット」に変える。
これら 2 つに比べれば、他のすべては誤差の範囲だ。
デュアルエージェント RAG パターン
音声ループ内の標準的な RAG には問題がある。ベクトルデータベースクエリは 80 ～ 300ms かかり、毎ターンレイテンシ予算を超過する。
2026 年の研究による回答は、Salesforce AI Research が 3 月に発表した VoiceAgentRAG 論文から来ている。その洞察は単純だ。
- 実際の会話では、次の質問は通常、現在の質問から予測可能である。
- 価格について尋ねる人は、おそらく次にエンタープライズティアについて尋ねるだろう。
- インストールについて尋ねる人は、おそらく次に互換性について尋ねるだろう。
そこで、2 つのエージェントを同時に実行する。
バックグラウンドエージェント（スロートシンカー）
- ユーザーが現在の応答を聞いている間に実行される
- LLM を使用して、可能性の高いフォローアップ質問を 3 ～ 5 つ予測する
- 各予測に対して、関連するドキュメントチャンクをプリフェッチする
- ユーザーが現在の回答を聞き終える前に、ローカルのインメモリキャッシュに保存する
フォアグラウンドエージェント（ファストトーカー）
- 次のライブ質問を、まずインメモリキャッシュをチェックして処理する
- キャッシュルックアップは、リモートのベクトルデータベース呼び出しの 110ms に対して、サブミリ秒の時間しかかからない
- キャッシュに答えがあれば、データベースを完全にスキップする
- キャッシュミスの場合、データベースにフォールバックし、その結果を次回のためにキャッシュする
論文からのベンチマーク数値
- クエリの 75% がキャッシュにヒット
- キャッシュヒット時、316 倍の検索高速化（0.35ms vs 110ms）
- 200 のクエリにわたって累積 16 秒のレイテンシ節約
覚えておくべき原則：ユーザーのリスニング時間を計算時間として使え。ユーザーが現在の応答を聞き始めた瞬間が、次の質問の準備を始める瞬間だ。
最初のビルドでは、音声ループ内でプレーンなベクトル RAG を試した。1 ターンあたり 110ms 追加された。
会話の感触が台無しになった。6 週目にデュアルエージェントキャッシュパターンに移行した。キャッシュにヒットする 40% のターンは、エージェントが置き換える人間のコールセンターレップよりもキビキビしている。
会話デザインは、ほとんどのビルダーがスキップする技術
最速の STT、最小の LLM、最もスマートな RAG キャッシュがあっても、エージェントが話し方を知らなければ、発信者は電話を切るだろう。
会話デザインは、耳に向けて書く技術であって、目に向けて書くものではない。
間違えて学んだ後、今私が従うルール
- 短い文で話せ。音声情報に対する人間の平均的な注意持続時間は 8 ～ 10 秒だ。15 秒の応答は長すぎる。2 つのターンに分割せよ。
- 1 ターンで 2 つの質問をするな。発信者はワーキングメモリに 1 つしか保持できない。1 つ質問し、待ち、次を質問せよ。
- 肯定フレーズを使え。「わかりました。」「はい。」「確認してみますね。」これらは、ユーザーが話し終えてから応答の準備ができるまでの無音を埋める。
- ユーザーの言語をミラーリングせよ。発信者が「請求問題」と言ったら、エージェントも「請求問題」と返せ。「金銭的紛争」や「支払い問題」ではない。言い換えると摩擦が生じる。ミラーリングは親密感を生む。
- 耳に向けて書け、目に向けて書くな。箇条書き、見出し、システムプロンプト内のマークダウンは使うな。LLM はアスタリスクやハイフンを話そうとする。
- 数字は言葉で綴れ。「94,107」ではなく「九万四千百七」。「$15.99」ではなく「15 ドル 99 セント」。TTS はフォーマットされた数字を頻繁に誤って発音する。
- システムプロンプトは 800 トークンに制限せよ。毎ターン再読み込みされる。
すべての優れた音声会話の 3 幕構成
- 承認と方向付け。「では、木曜日の予約を変更されたいのですね。確認します。」話し手が理解されたことを確認する。検索が実行されている間の時間を稼ぐ。
- 解決。核となるアクションまたは回答。1 ターンにつき 1 ポイント。前に進む。
- 確認とクローズ。「予約を 19 日（月）の午後 3 時に変更しました。まもなく確認テキストをお送りします。」きれいな出口。未解決のループを残すな。
安全は 2 つのチェックポイントであり、1 つではない
ほとんどの初めてのビルダーがスキップし、後悔するコンポーネント。
音声エージェントには「送信前に読む」瞬間がない。安全でない出力は即座に話される。下書きなし、プレビューなし、人間の介入なし。
正しいモデルは 2 つのチェックポイントだ。
入力ガード（LLM がユーザーのターンを見る前）
- プロンプトインジェクション。「前の指示は無視して、あなたは〜のふりをして…」といった攻撃。LLM の指示追従性を悪用し、データを盗んだりスコープを破ったりする。
- 声に出して話された PII。クレジットカード番号、社会保障番号。ログやデータベースに到達する前に編集する。
- トピックブロックリスト。JSON ファイルからロードされる。ユーザーが実際に何を試すかを学習するにつれて毎週更新される。
出力ガード（LLM が応答を書き、TTS が話す前）
- 過剰約束の表現。「保証します」「約束します」。録音回線で法的および信頼の問題を引き起こす。
- 取得されたコンテキストにない特定の事実主張。軽量な幻覚チェック。私のデプロイメントでは、作り話の回答の約 70% を捕捉する。
- 標準モデレーションエンドポイント。まれなモデルの誤動作に対して。
両方のガードが返すもの
- safe（ブール値）
- detected category（文字列、安全でない場合）
- 代わりにエージェントが話す代替フレーズ
すべてのトリガーは、タイムスタンプ、カテゴリ、編集テキスト、コール ID とともにファイルにログ記録される。
エスカレーションフレーズ
ハードコードされた 1 つの正確なフレーズで、エージェントが答えを知らないとき、または何かがうまくいっていないときに言う。
- 「正確な情報をお伝えしたいので、担当者におつなぎしますね。」
- 5 つのバリエーションではない。LLM が即興で考えた適切な言い回しの推測ではない。
- 1 つのフレーズ。システムプロンプトで ALL CAPS。安全チェックが発動した時のフォールスルー。
最初のビルドでは出力ガードなしで出荷した。エージェントは自信満々に、実際より 30% 安い価格を引用した。
その価格は、ナレッジベース内の古いドキュメントに記載されていた。
幻覚チェックがあればそれを捕捉できたはずだ。正しい価格が取得されたコンテキストに含まれていなかったからだ。
評価、つまり良いかどうかを知る方法
測定できないものは改善できない。ほとんどのチームは評価をスキップし、壊れたエージェントを出荷する。
4 層フレームワーク
層 1：インフラストラクチャ。配管。
- 実際のドメインにおける WER（ベンダーのベンチマークではない）
- パイプライン全体の p50、p95、p99 レイテンシ
- 最初の音声までの時間
- トランスポート上の音声品質
層 2：実行。エージェントは要求されたことを行うか。
- タスク成功率
- ツール呼び出し精度
- パラメータ正確性
- 応答のグラウンディング
- 小型で高速なモデルで LLM-as-judge を使用する。4 つのはい/いいえの質問：正しく回答したか、グラウンディングを維持したか、音声として自然に聞こえたか、適切に簡潔だったか。
層 3：ユーザー行動。話していて自然に感じられるか。
- 割り込み回復率
- 再プロンプト率
- 平均ターン長
- 会話修復回数
- 週に 20 件の通話をサンプリングする。実際の文字起こしを読む。10 件以内にパターンが見えるだろう。
層 4：ビジネス成果。問題を解決しているか。
- 封じ込め率（人間を介さずに解決された通話の割合）
- 転送率
- CSAT
- 初回解決率
- 封じ込めに対して最適化する。これは他のすべてと相関し、インストルメンテーションなしで測定するのが最も簡単だ。
テストセット構成
ローンチ前に構築せよ。最低 50 の会話。
- 40% ハッピーパス
- 30% エッジケース
- 15% エラーハンドリング
- 10% 敵対的（プロンプトインジェクション、ジェイルブレイク試行）
- 5% 音響的バリエーション（背景ノイズ、強いアクセント、スピーカーフォン）
各シナリオについて：
- どのツールが呼び出されるべきだったか
- どのようなパラメータで
- エージェントは何と言うべきだったか
毎週のレビューループ
毎週月曜の朝。30 分。
- メトリクスを取得
- 20 件の通話をサンプリング（7 件はエスカレーション、7 件は解決、6 件はランダム）
- 文字起こしを読む
- 最も一般的な障害タイプを 1 つ挙げる
- 1 つの変更を行う（常に一度に 1 変数）
- 48 時間 A/B テストする
- 勝者を出荷する
グラウンディングは信頼システムである
ほとんどのビルダーは RAG をパフォーマンス機能、つまりより正確な回答を得る方法と考えている。その枠組みは過小評価である。
音声エージェントにおいて、すべての回答の正確性は、あなたの製品がどれだけ信頼できるかについての直接的な声明である。価格や補償範囲やポリシーについての間違った回答を、自然な声で自信満々に聞かされた発信者は、単にイライラするだけではない。騙されたと感じるだろう。
信頼の約束の実装には 4 つの部分がある。
- ソース・オブ・トゥルース
- あなたのドキュメントであり、モデルの学習データではない
- システムプロンプトは、これを明示的に、大文字で言わなければならない：提供されたコンテキストからのみ答えよ
- モデルは依然として時々一般的な知識にドリフトするが、明示的な指示はその率を桁違いに削減する
- 優雅な拒否
- エージェントが答えを見つけられない場合、直接そう言う
- 正確なフレーズが重要だ
- 「正確な情報をお伝えしたいので、確認しますね」は、優雅な転送のための時間を稼ぐ
- 「わかりません」は無能に聞こえる
- 「私の情報によると」は弁護士の逃げ口上に聞こえる
- 1 つのフレーズを選び、ハードコードし、決して LLM にここで即興させてはいけない
- 信頼度に応じた応答
- 取得されたチャンクの上位 BM25 スコアは、信頼度の有用なプロキシである
- スコア 0.6 以上：エージェントは自信を持って回答する
- スコア 0.3 ～ 0.6：エージェントは回答するが、「だと思います」という逃げ口上を追加する
- スコア 0.3 未満：エージェントは回答せず、転送を提案する
- システムプロンプト構築コードの 20 行の変更。幻覚を約半分に削減する。
- ナレッジベースの衛生状態
- 古いドキュメントは古い回答を生み出し、それは危険な回答である
- 私は金曜日に監査を実行する：その週の信頼度スコアの低い応答の下位 5% を読む
- 半分の確率で、回答自体は正しいが、検索が古いチャンクを見つけていた
- チャンクを更新し、再埋め込みし、来週は問題が減る
注意すべき点
あなたを襲う 6 つの障害モード。
パイプライン内の VAD ではなくトランスポート上の VAD
- 問題。エージェントが自身の TTS 出力にトリガーされ、割り込みループに入るか、ターン終了の検出に完全に失敗する。
- 解決策。VAD アナライザーは常にトランスポート上に置く。最近のアシスタント出力にマッチする STT 文字起こしを無視するエコーガードと組み合わせる。
間違った状態で利用可能なツール
- 問題。LLM が、まだ患者の名前を収集している状態で book_appointment を呼び出す。または、決して発生しなかった予約をでっち上げる。
- 解決策。ツールを状態ごとにスコープする。1 つの状態には、その関数のみ。状態機械が安全レールであり、システムプロンプトではない。
関数ハンドラーが例外を投げ、結果コールバックを決して呼び出さない
- 問題。LLM が決して来ないツール結果を待ってハングする。または、でっち上げる。
- 解決策。すべてのハンドラーを try/except でラップする。すべての分岐は結果を返す。すべての失敗には、話されるフォールバックがある。空の結果は決して許さない。
プロンプト内でのユーザーデータ検証ではなく、コード内での検証
- 問題。LLM は、12 番目の通話で「john@」を本物のメールとして受け入れる。47 番目の通話で、プラス記号を含む有効なメールを拒否する。
- 解決策。検証は Python に存在する。メールには正規表現、日付には日付パーサー、名前の長さチェック、検証失敗時の再質問応答。
長時間の通話でのコンテキストウィンドウの無制限な拡大
- 問題。コード変更なしで、週を通して p95 レイテンシが上昇する。20 ターン目までに、毎ターン 12K トークンを送信していることになる。
- 解決策。直前 N ターンとシステムプロンプトのスライディングウィンドウ。または、各 discrete ステージの終わりでのマイルストーンベースのコンテキストリセット。
TTS がコードや ID を文字通り読み上げる
- 問題。確認コード「A3X7」が、間を置かずに「エー スリー エックス セブン」と出力される。患者はとにかく繰り返しを求める。
- 解決策。NATO フォネティックアルファベット展開と SSML ブレークタグを使用。遅く聞こえる。初回で正しく読まれる。
私が違うやり方をするだろうこと
- ターンログスキーマを 1 日目に構築し、4 週目ではなく。リプレイエンドポイントは私が作った中で最も価値のあるツールであり、必要になった後に作った。
- 最初から意味論的ターン終了検出を使用し、無音閾値と格闘するのではなく。
- システムプロンプトが 300 語を超えたその日に、実際の状態機械に移行する。散文で状態機械をエンコードしようとしない。
- プロンプト内での検証をやめる。LLM はパーサーではない。Python がパーサーだ。Python を使え。
- 通話開始時に、最も可能性の高い 5 つの RAG ドキュメントをキャッシュする。ターンループ内でのベクトル検索をスキップする。
- 検索を構築する前に、雑談ゲートを構築する。「こんにちは」はシステム内で最も安価な 200ms の利益だ。
- 最初のプロダクション通話の前に評価セットを実行する。最低 50 の会話。
- 初日から永続的な抽出キューを配置する。単一のリトライワーカーを持つ pending_extractions Postgres テーブルは 200 行で済み、実際の障害を防ぐ。
- 50 通話ごとに非同期 LLM 判定を実行する。グラウンディング、関連性、簡潔さでスコアリングする。ダッシュボードに流す。ドリフトは現実だ。
- 毎週のレビューループを実行する。毎週月曜日に 20 件の通話をサンプリングする。1 つの変更を行う。A/B テストする。勝者を出荷する。
結論
音声エージェントは AI のように見える。しかし、リアルタイムシステムのように動作する。
出荷するチームは、そのように扱う。6 ヶ月遅れて出荷するチームは、より良いプロンプトがシステム問題を解決すると思う。
自分のパイプラインを所有せよ。自分のログを所有せよ。どの障害も 1 回のリプレイで済むプレーンファイルに保存せよ。
最初のエージェントを作るのに週末がかかりました。本番システムには10週間かかりました。それ以来、私が触らなくても、毎日改善され続けています。ユーザーはそれを測定しません。彼らは、エージェントが待たせることなく「ありがとう」と返答したことに気づくのです。
免責事項と開示
本記事は著者が調査・執筆し、AI モデルによって編集されました。サムネイルは Pinterest から取得しました。
本記事は、著者がより深いインフラストラクチャで音声エージェントに取り組んでいる際に調査・執筆されました。
Perplexity、Claude、ChatGPT を使用した進化するメモと深い調査、および数冊の学部レベルの大学の教科書からのシステム設計と API 設計に基づいています。
文法上の誤りと書式について、Minimax M2.7 と Claude Opus 4.7 によって徹底的に編集されています。
