カスタマーサポート向けAI音声エージェントは、電話に自力で応答します。相手の発言を文字起こし（音声認識）し、LLMでナレッジやシステムをもとに推論し、音声で返答（音声合成）する流れを、約1秒で行います。難しいのはAIではなく、リアルタイム処理の基盤です。相手は800msを超える遅延に気づくため、往復全体がストップウォッチで測られます。
費用面では、音声は分単位で課金されます。すぐ使えるプラットフォームでは、サポート通話の多くが電話回線を除いて1分あたり0.07〜0.16ドルの範囲に収まり、5分の通話なら電話料金を除いて約0.35〜0.80ドルです。
導入のたびに肝に銘じたいこと：音声AIは人間につなぐときにうまくいき、人間を置き換えようとすると失敗します。私は長年、ライブのサポートキューにAIを投入してきましたが、最大の教訓は「網羅性より確信度」です。自信のあるものはエージェントに任せ、残りは引き継ぎましょう。この教訓はチャネルを問わないため、電話回線を足す前に、チャットやチケットを解決するAIヘルプデスクエージェントの方式を正しく整える価値があります。
AI音声エージェントとは実際に何か
宣伝文句を取り除けば、AI音声エージェントとは、電話を取り、自然な言葉で相手を理解し、仕事をこなし、音声で返答するシステムで、通話の大半で人間は回線に出ません。主流の設計は、3つの専門モデルをつなげます。音声認識（STT）、思考を担う大規模言語モデル（LLM）、音声合成（TTS）で、これらが実際の通話をつなぐ電話回線層の上に載ります。Twilioはこれをカスケード型音声エージェントアーキテクチャと呼び、そこでは"the user's speech is transcribed, the transcript is processed by an LLM, then the resulting tokens are synthesized into audio."とされています。
新しい方式では、この連鎖を1つのモデルにまとめます。OpenAIのRealtime APIは音声から音声へ直接処理し、"reduces latency, preserves nuance in speech, and produces more natural, expressive responses."とされています。
2つの比較で理解できます。
- 昔の電話ガイダンスとは違います。「請求のご用件は1を押してください」（IVR）は、プッシュ音や決まった数語しか理解できず、全員を同じ固いメニューに通します。音声エージェントは、相手に自分の言葉で問題を説明させ、そこから振り分けるか解決します。
- テキストのチャットボットの音声版ですが、はるかに難しい媒体です。チャットはターン制で、1〜2秒の遅れは許されます。音声は同期的でリアルタイムであり、この違いが技術的課題のすべてです。AIエージェントとルールベースのチャットボットの違いを読んだことがあれば、これは同じ飛躍に、リアルタイム音声の問題が上乗せされたものです。
AI音声エージェントの仕組みを順に解説
サポート通話が着信から返答まで通る全経路は次のとおりです。
電話回線（テレフォニー）。 通話は電話網（PSTN）またはSIP接続で届きます。Twilioはこれを<ConversationRelay>要素として提供し、これは"handles the complexities of live, synchronous voice calls,"とされ、OpenAIも最近、Realtime APIにSIPによる電話通話を追加しました。
音声認識。 相手の音声はリアルタイムで文字起こしされます。ここで本当に難しいのは認識そのものではなく、エンドポインティング、つまり相手が本当に話し終えたかを見極めることです。文の途中の短い間は"can sound identical to an end-of-turn pause."だからです。優れたシステムは、暫定の推測と確定した記録という2つの文字起こしバッファを持ち、早めに考え始めて後から修正できるようにします。
LLMとナレッジ検索。 文字起こしはLLMに渡され、LLMが相手の用件を判断し、推測せずにナレッジベースから根拠のある回答を引き出します。AWSの参照構成は、Amazon Connect、Lex、Bedrock Knowledge Basesを組み合わせ、エージェントが検索した自社コンテンツから回答するようにしています。この検索の工程は、優れたテキストエージェントが一言も発する前にナレッジベースで学習しておく必要がある理由と同じです。
業務システムでの実行。 本番のエージェントは話すだけでなく、ツールを呼び出します。注文の照会、CRMレコードの確認、チケットの起票などです。OpenAIのgpt-realtimeはリモートMCPサーバーへの対応を追加してセッションをツール群に接続できるようにし、長い通話を非同期にして"the model can continue a fluid conversation while waiting on results."を実現しました。
音声合成。 モデルの言葉は合成音声としてストリーミングで返されます。DeepgramのFlux TTSはテキストと音声の生成を交互に行い、返答の長さが最初の音声までの遅延を増やさず、最初の音声は"as low as 80ms."です。
この最後の数字が、本当の話を示唆しています。これらの各段階は時間との競争であり、それが次のセクションのテーマです。
なぜ音声はチャットボットよりずっと難しいのか
テキストのエージェントを作ったことがあれば、音声は「同じものを声にしただけ」と思うかもしれません。そうではありません。音声には、チャットにはないリアルタイムの制約が加わります。
最大の問題は時間です。Twilioは2025年後半に独自のローンチ目標を公表し、遅延を"mouth-to-ear turn gap"と定義して、エンドツーエンドの目標を1,115ms、上限を1,400msとしました。この時間配分は1か所で使われるわけではありません。おおよそSTT 350ms、LLM 375ms、TTS 100msに、ネットワークとバッファリングが加わり、これらの数字は積み上がるため、"acceptable numbers at each stage can still sum to a broken conversation."となります。Deepgramは知覚の閾値をさらに厳しく見ており、相手は"start noticing lag near 800ms of total round-trip time."としています。
さらに、電話の相手がするのにチャットのユーザーがしないことがあります。割り込みです。この「バージイン」に対処するには、相手が話に割り込んだ瞬間に、進行中の返答を取り消さなければなりません。そのためDeepgramのエージェントAPIは組み込みのバージイン検出と発話ターンの予測を備えています。また、相手は騒がしい場所から、訛りのある話し方で、頼れる画面もなく電話をかけてくるため、音声が不明瞭でも「下のボタンをクリックしてください」という逃げ道がありません。
音声ループをゼロから作り直したある開発者は、難しさの所在を的確に言い当てました。
"The hard part isn't STT, LLMs, or TTS in isolation, but turn-taking: detecting when the user starts and stops speaking, cancelling in-flight generation instantly, and pipelining everything to minimize time-to-first-audio... By colocating Twilio, Deepgram, ElevenLabs, and the orchestration layer, I reached ~790ms end-to-end latency."
公平に言えば、モデルは本当に良くなりました。gpt-realtimeはBig Bench Audio推論評価で82.8%を記録し、OpenAIの2024年後半のモデルの65.6%から向上しています。笑いなどの非言語的な手がかりを捉え、文の途中で言語を切り替えることもできます。音声デモが破綻する原因は、たいてい知能ではなく、その周りの基盤です。
AI音声エージェントの実際の費用
多くのベンダーページが隠している部分です。音声AIは通話の分単位で課金され、見出しの分単価が請求額のすべてになることはほぼありません。ベンダーによっては、電話回線（テレフォニー）、STT、LLM、TTSが加わり、まとめて含まれる場合も、「原価」で転嫁される場合も、自分で組み合わせる別々の項目として請求される場合もあります。
価格体系は大きく3つです。
- 分単価に全部込み（Bland、Retell、ElevenLabs Agents）：STT、LLM、TTSをすでに含む1つの混合料金。シンプルで、表示価格はやや高めになりがちです。
- プラットフォーム料金＋実費転嫁（Vapi）：分単位の薄いオーケストレーション料金に加え、STT、LLM、TTSを原価で支払います。下限は最安ですが、構成要素が最も多くなります。
- コンポーネントまたはインフラ（Twilio、Deepgram、OpenAI、Amazon Connect）：1つの層を購入し、残りは自分で組み込みます。
| ベンダー | プラン / ティア | 公表料金 | 含まれるもの | 転嫁または別料金 |
|---|---|---|---|---|
| Bland AI | Start (dev) | $0.14 / min | LLM、STT、TTSをすべて含む、"no model pass-throughs" | 着信番号は月額約15ドル、転送は1分あたり0.05ドル |
| Retell AI | Pay-as-you-go | $0.07-$0.31 / min (~$0.115 midpoint) | 音声基盤＋LLM＋TTSの混合 | 10ドルの無料クレジット。自社回線持ち込みなら電話料金は約0ドル |
| Ringly | 会話ごとの課金 | 月額99ドルで50会話込み、以降は1会話あたり1.99ドル | Shopify連携のAI電話サポート | Sethが引き継ぎ前に対応した通話は課金対象。月1,000通話以上は個別料金 |
| Vapi | Build (usage) | $0.05 / min プラットフォーム料金 | Vapiのオーケストレーションのみ | STT/LLM/TTSは原価。10回線を超えると回線あたり月額10ドル |
| Deepgram | Voice Agent API (Standard) | $0.075 / min | DeepgramのSTT＋LLM＋TTSバンドル | 自前LLMなら1分あたり0.065ドル、Advancedは0.163ドル |
| ElevenLabs Agents | 超過料金 | $0.08 / min (burst $0.16) | TTS＋オーケストレーション＋プランの分数 | LLMは別請求、電話回線も別 |
| Twilio | ConversationRelay | $0.07 / min | AI音声のオーケストレーションのみ | ＋PSTN $0.0085-$0.014/min＋自前のSTT/LLM/TTS |
| Amazon Connect | 音声 (usage) | $0.038 / 音声分 | コンタクトセンターの電話回線＋プラットフォーム | 電話回線＋Amazon Q / Contact Lensのアドオン |
| OpenAI Realtime | gpt-realtime-2.1 | $32 / 100万音声入力トークン、$64 / 100万音声出力トークン | モデルのみ | 実際には1分あたり約0.06〜0.24ドル。電話回線なし |
Ringlyは種類の違う購入です。分単位で課金される音声基盤ではなく、会話ごとに課金されるShopify特化のサービスです。以下の例は分単位課金のプラットフォームに当てはまります。
具体例で積み重なりを見てみましょう。月に2,000件のサポート通話があり、平均4分だとします。全部込みのプラットフォームで1分あたり約0.12ドルなら、8,000分で、プラットフォーム費用は約960ドルです。Twilioのような電話回線を1分あたり約0.01ドルで加えると約1,040ドルになり、さらに番号のレンタル料と、ウォーム転送の分数が加わります。1通話あたりは安くても、件数に応じて増え、長くて込み入った通話（例外的なケースが生む通話）が高くつきます。
契約前に織り込むべき注意点がいくつかあります。
- 電話回線はほぼ常に別料金で、「全部込み」のベンダーでも同様です。分単位の実費に加えて1番号あたり1〜2ドルがかかり、国際料金はずっと高くなります。
- 「原価」での転嫁は無料ではありません。Vapiの1分あたり0.05ドルの下限は現実の費用で、さらにSTT、LLM、TTSを原価で足すと簡単に0.05〜0.10ドル加わり、全部込みのベンダーと同じ価格帯になります。
- コンプライアンスはアドオンです。HIPAAやZero Data Retentionは一部のプラットフォームでは有料ティアで、BAAはEnterpriseに限られることが多いです。
この表を見て、分単位の課金は予測しにくいと感じたなら、それが率直な読み方です。eeselが通話の分数ではなく、チケットまたはカスタマーチャット1件につき1クレジットの月額クレジットプランを使うテキストチャネルのほうが、予測しやすいことが多い理由の1つです。AIエージェントと人間のエージェントのコストの詳しい内訳で計算を確認できます。
カスタマーサポート向けに比較したいAI音声プラットフォーム3つ
以下の選択肢は、導入ニーズの異なるケースをカバーしています。選ぶ前に、それぞれを自社の通話、連携システム、引き継ぎ要件で試してください。
1. Bland AI：まとめて提供される音声スタック
Bland AIは、言語モデル、音声認識、音声生成を自社の音声プラットフォームに統合しています。これらのコンポーネントを1社でそろえたいチームの選択肢です。プラットフォーム料金に加えて、電話番号と転送の料金も確認してください。
2. Retell AI：従量課金の音声基盤
Retell AIは、従量課金の音声基盤を提供しています。最安の表示料金をすべての通話のコストとみなさず、モデル、音声、電話回線を含む、必要な構成全体で比較してください。
3. Ringly：Shopifyストア向けのAI電話サポート
RinglyのSethは、Shopifyストア向けに作られたAI電話応対システムです。着信に応答し、注文や商品を照会し、返品に関する定型の質問に対応し、必要に応じて通話者をチームに転送します。独自の音声と電話回線のスタックを組み立てずに、ストアのデータとつながった音声エージェントがほしいEC事業者向けです。
上記の分単位のインフラ型の選択肢と違い、Ringlyは会話ごとに課金します。公表価格は最初の50会話が月額99ドル、以降は課金対象の会話1件につき1.99ドルです。Sethが引き継ぎ前に対応した通話もカウントされ、スパム、切断、間違い電話、すぐに人間を求める要求はカウントされません。請求額を見積もる前に、これらのルールが自社の通話構成にどう当てはまるかを確認してください。Shopifyに特化しているため、他の業種や発信業務にはあまり向きません。
AIに電話することについて、人々が実際に言っていること
デモはいつも同じです。相手が「営業時間は？」と聞き、AIがなめらかに答えます。現実はもっと入り混じっており、導入前に理解すべき最も有用なことは、その2つの間のギャップです。
うまくいくときは、本当にうまくいきます。ベンダーではなく、営業時間外のサポート通話を語る実際の利用者の声です。
"It was after hours, and a dreaded robot voice answered my call. I was fully prepared to spend the next 10 minutes rewording my issue... Surprisingly, this robot understood every single sentence I said... That's the most pleasant customer service call I have ever experienced. I don't mind talking to AI. In fact, instead of a live agent, I actually prefer to talk to your LLM, so my issue can be quickly triaged to the right human who actually understand my situation."
この通話を良いものにした点に注目してください。適切な人間に振り分けられたことです。これがパターンです。次は、自動応答の行き止まりにぶつかった人の、失敗の例です。
"One (recently) even told me, after wandering through the menu options, that they were going to text me a link to their app - and then hung up on me. I already tried the app, their system was broken - that's why I was trying to call and talk to a human!"
そして、2回読む価値のある、核心の緊張関係を最も鋭く言い表した一文です。
"The problem with the call center A.I. is that almost every time I need to call somewhere that uses them, I have some kind of edge case. They always give examples of how the automated agent can handle simple queries like 'what's my balance'... but I never need to call with something straightforward like that."
この1つのコメントがすべてを物語っています。人々は単純なことで電話をかけるのではなく、例外的なケースで電話をかけます。そして「これは人間向けです」とはっきり認められないエージェントは、サポートチャネルを壁に変えてしまいます。
誰もが間違えること：網羅性より確信度
チームが何度も犯す間違いは、音声エージェントがどれだけ答えられるかを最適化し、いつ答えるべきでないかをどれだけ見極められるかを最適化しないことです。ライブ通話では、自信満々の誤答は素早い引き継ぎより悪く、相手がそれに基づいて行動し、後になって判明します。
これは音声に限った考え方ではなく、あらゆるチャネルのライブのサポートキューでAIを何年も運用してきた教訓です。当社の顧客のひとり、DTCサプリメントブランドのCXリーダーは、どんな営業資料よりもうまく言い表しました。
"The AI will never be able to answer 100% of the questions. I need an AI who is only handling the tickets that it's confident to handle, and all the other ones, leave them alone."
これが設計原則です。実際には、チャネルが音声でもテキストでも、3つのことを意味します。
- すべての回答を実際のナレッジに基づかせ、エージェントが即興で答えず、ヘルプセンターや過去の解決事例から検索するようにします。これにより、サポートの質問でのハルシネーションを防げます。
- 確信度で制限し、自信のあるものだけを解決し、残りは完全な文脈を添えて人間に引き継ぎます。上の良い通話がたどったパターンそのものです。
- 本番前に、ベンダーのデモシナリオではなく、自社の履歴でテストします。台本どおりの「営業時間は？」ではなく、直近の実際の通話やチケット1,000件をどう処理したかを知りたいはずです。
この最後の点は、チームが省略して後悔するものです。期待と確信の違いであり、顧客に1人も触れる前に過去のチケットでシミュレーションすることが、サポートのテキスト面で必須条件になった理由です。
AI音声がサポートスタックのどこに合うか
では、電話回線にAIエージェントを置くべきでしょうか。率直な意見です。音声は1つのチャネルであり、ほとんどのサポートチームにとって最大のチャネルではありません。チャット、メール、チケットのほうが量が多いことが通常で、テキストのエージェントは下書きし、レビューを待ち、電話の相手をリアルタイムで待たせずに引き継げるため、先に自動化するほうがリスクが低くなります。
ほとんどのチームに適した順序は次のとおりです。
- 同じナレッジと同じ確信度による制限が、はるかに穏やかな失敗の形で通用するテキストチャネルを先に自動化します。ここでAIカスタマーサービスツールが最も早く成果を出します。
- 解決率やその他の指標を指針に、エージェントが実際に何に確信を持てるかを、実データから学びます。
- ルーティングを信頼できるようになったら、テキストで検証済みの同じナレッジベースと引き継ぎロジックを再利用して、音声に広げます。
再利用できるのは、ナレッジと確信度のロジックです。音声特有の基盤（電話回線、遅延、バージイン）は上に加える追加の層で、チェックボックスではなく本格的なプロジェクトです。まずテキストの土台を正しく作ることが、後から音声の層を加える価値を生みます。
サポートのテキスト面でeeselを試す
eeselは、すでに使っているヘルプデスクの中で、チケット、ライブチャット、メールという、実際に量の大半があるチャネルを担当するAIヘルプデスクのチームメイトです。電話や音声のエージェントではありません。大げさに言うより、はっきりそう伝えたいと思います。得意なのは、この記事全体が最初に作るべきだと主張している土台です。過去のチケットとヘルプセンターで学習し、確信度で返信を制限して自信のあることだけに答え、ライブの会話に触れる前に実際のチケット履歴でシミュレーションできるので、導入を決める前に解決率を確認できます。
Zendesk、Freshdesk、Gorgias、Front、Help Scout、Slackと連携し、分単位の課金ではなく月額クレジットプランを採用しており、料金ページで確認できます。まずテキストチャネルでしっかり解決できるようにすれば、音声の層はすでに信頼しているものの延長になり、賭けのような飛躍ではなくなります。eeselを無料で試すことができ、クレジットカードも営業電話も不要です。