【ITニュース解説】Fixing the ElevenLabs Call Transfer Bug with Twilio
2025年10月02日に「Dev.to」が公開したITニュース「Fixing the ElevenLabs Call Transfer Bug with Twilio」について初心者にもわかりやすく解説しています。
ITニュース概要
ElevenLabsとTwilio連携の音声エージェントで、通話転送・終了時に音声が途切れるバグが発生。ElevenLabsのタイミング処理不足が原因だ。これをTwilio APIで回避し、通話転送や終了を数秒遅らせて手動実行する。これにより、エージェントが話し終えてから処理が完了し、通話体験を向上させる。
ITニュース解説
現代のIT技術では、音声AIがまるで人間のように会話をしてくれるサービスがどんどん増えている。たとえば、問い合わせ対応のコールセンターでAIオペレーターが応答したり、予約の電話をAIが代行したりするケースなどがその一例である。このような音声AIサービスを構築する際によく利用されるのが、「ElevenLabs(イレブンラボ)」のような高機能な音声合成・AI会話サービスと、「Twilio(トゥイリオ)」のような電話回線や通話機能をプログラムで制御できるサービスである。ElevenLabsで自然な声のAIを作り、TwilioでそのAIと実際の電話をつなぎ、通話機能を提供するという連携は、非常に一般的である。
しかし、この強力な連携には、現在、一つの困った問題が発生している。それは、音声AIエージェントが「通話を転送します」と言っている最中や、「お電話ありがとうございました」と話し終える前に、突然電話が切れてしまうというバグである。利用者がAIエージェントと話していて、「少々お待ちください、担当者におつなぎします…」とAIが言いかけた途端にプツンと電話が切れてしまったらどうだろう。あるいは、丁寧にお礼を言っている途中で突然回線が切れたら、利用者は非常に不自然だと感じ、場合によっては不満を抱くかもしれない。これは、せっかくスムーズな会話を目指して作られたAIエージェントの努力を台無しにしてしまう、ユーザー体験を著しく損なう重大な問題である。
なぜこのような問題が起こるのだろうか。原因は、ElevenLabsの内部処理にある。本来、AIエージェントが「通話を転送する」とか「通話を終了する」という指示を受け取った場合、まずはAIがその意図を伝えるメッセージを最後まで話し終えてから、実際の転送や終了処理に移るのが理想的である。しかし、現状のElevenLabsでは、こうした通話制御のタイミングをうまく扱えていない。具体的には、転送や終了の指示が出たと同時に、AIの音声ストリーム(声のデータが流れる経路)をすぐに切断してしまうのだ。そのため、AIがまだ話している途中であっても、強制的に通話が途切れてしまう事態が発生する。この問題は、TwilioとElevenLabsを直接連携させている場合だけでなく、SIPトランクと呼ばれる、インターネット経由で電話回線をつなぐ方式を使っている場合でも同様に発生することが確認されている。
この不具合に対する解決策は、ElevenLabsが提供する通話転送や終了の機能を直接使うのをやめ、自分たちでこれらの処理を制御するという「ワークアラウンド」である。ワークアラウンドとは、一時的な回避策や対処法を意味し、根本的なバグ修正がされるまでの間、システムを正常に動かすために用いられることが多い。ただし、この解決策には重要な制約がある。それは、Twilioの「プログラム可能な音声(Programmable Voice)」という機能で登録された電話番号にのみ有効である点だ。もし電話番号がSIPトランク経由で接続されている場合、TwilioのAPI(プログラムから外部サービスを操作するための窓口)を使って通話の状態を更新したり、転送したりすることができないため、今回の方法は適用できない点に注意が必要である。
具体的な解決の仕組みを見てみよう。まず、ElevenLabsが持つネイティブな通話転送・終了機能を無効にする。そして、自分たちのバックエンド(サービスを動かすサーバー側のシステム)に、独自の「transfer_call(通話転送)」と「end_call(通話終了)」という機能、つまり「カスタムツール」を作成する。AIエージェントが通話を転送したい、あるいは終了したいと判断し、これらのカスタムツールを呼び出したとする。このとき、私たちのバックエンドは、すぐに「200 OK」というHTTPステータスコードをElevenLabsに返す。これは、ウェブサーバーが「要求を正常に受け付けました」と伝えるメッセージであり、ElevenLabs側には、通話転送や終了の指示が成功し、AIの音声ストリームがまだ生きている、つまりAIが話し続けていると錯覚させる効果がある。
「200 OK」を返した裏で、私たちのバックエンドは、実際の通話制御処理をすぐに実行するのではなく、数秒間(たとえば2〜5秒)の短い遅延を持たせた「バックグラウンドジョブ」をキュー(処理待ちの列)に入れる。バックグラウンドジョブとは、ユーザーが直接待つ必要のない、裏側で実行されるタスクのことである。この遅延は、AIエージェントが「転送します」というメッセージや「ありがとうございました」というお礼の言葉を最後まで話し終えるのに十分な時間を与えるためのものである。遅延時間が経過した後、このバックグラウンドジョブが実行され、Twilioの「REST API」を呼び出して、実際の通話制御を行う。REST APIとは、インターネット経由でサービス同士がデータをやり取りするための標準的な方法である。
通話転送の場合、バックグラウンドジョブはTwilioのAPIを使って、現在進行中の通話に「新しいTwiML(トゥイムル)」を適用するよう指示する。TwiMLとは「Twilio Markup Language」の略で、Twilioに通話をどう扱うかを指示するためのXML形式の特別な命令文である。新しいTwiMLには、<Dial>という命令が含まれており、「この電話を指定された番号にダイヤルして転送しなさい」という具体的な指示が書かれている。これにより、AIが話し終えた後に、スムーズに別の担当者や部署へと通話が転送されるのだ。通話終了の場合も同様に、バックグラウンドジョブはTwilioのAPIを呼び出し、通話の「ステータス」を「completed(完了)」に更新するよう指示する。これにより、通話が自然な形で終了する。
例えば、Ruby on Railsというウェブ開発フレームワークを使った実装例では、特定のバックグラウンドジョブがTwilioのAPIを使って通話を更新する役割を担う。通話を更新する際には、新しいTwiMLを生成するウェブページのURLをTwilioに伝える。そのウェブページは、受け取った転送先の情報をもとに、Twilioに通話転送を指示する<Dial>命令を含むTwiMLを生成してTwilioに返す。通話終了の場合も、別のバックグラウンドジョブがTwilioのAPIを使い、通話のステータスを「completed」に変更することで、通話を終了させる。このようにすることで、ElevenLabsが「ありがとうございました」と話し、そのメッセージを受け取ったバックエンドがすぐに200 OKを返した後、数秒経ってから通話終了の処理が実行されるため、AIの声が途切れることなく、自然な通話終了が実現するのである。
このアプローチの最大の利点は、AIエージェントがメッセージを最後まで話し終えるまで、通話が途切れないことである。また、遅延時間を自分たちで正確に制御できるため、2秒、5秒など、状況に応じて最適な時間を設定できる柔軟性も得られる。これにより、通話転送と通話終了の両方で、利用者に非常にスムーズで自然な体験を提供できるようになる。
まとめると、ElevenLabsとTwilioを連携させて音声AIエージェントを構築する際、通話転送や通話終了時に音声が途切れてしまうという既知のバグがある。この問題を解決するためには、ElevenLabsのネイティブ機能を使わず、自分たちのバックエンドで独自の通話制御ツールを実装する必要がある。そして、ElevenLabsからの指示を受けたらすぐに正常応答を返しつつ、裏で数秒の遅延を持たせたバックグラウンドジョブを動かし、TwilioのAPIを使って実際の通話転送や終了処理を行う。この方法を用いることで、AIエージェントはメッセージを最後まで話し終えることができ、利用者は途切れることのない、はるかに快適な通話体験を得られるのである。これは、システムの品質を大きく向上させる重要な対処法となる。