TwilioとDeepgramを活用したアウトバウンド音声オペレーターの構築

TwilioとDeepgramを活用したアウトバウンド音声オペレーターの構築

Twilioでアウトバウンド音声オペレーターを構築する場合、インバウンド音声オペレーターにはない課題を解決する必要があります。まず、こちらから電話を発信しなければなりません。また、応答したのが人間なのかボイスメールなのかを判定し、オペレーターが「誰と」「どのような目的で」話しているのかを認識できるようにコンテキストを提供する必要があります。さらに、通話終了後には、その結果を記録システムに反映させます。

これを受けて、Deepgramのチームは、Twilio上でこれらすべての処理を一括して実行できるアウトバウンド音声オペレーターのリファレンス実装をリリースしました。システムがREST APIを通じて発信を開始すると、AIオペレーターが受信者とシナリオに沿った会話を展開し、構造化された通話結果がCRMに記録されます。相手がボイスメールの場合は、代わりにパーソナライズされたメッセージを残します。

以下では、そのアーキテクチャと、より単純な実装ではスキップされる処理について説明します。

アウトバウンド音声オペレーターアーキテクチャの仕組み

関連するインバウンド音声オペレーターに関する記事を読んだ方であればお気づきの通り、コアとなる音声ブリッジの仕組みは同じです。具体的には、Starlette上に構築されたPythonアプリケーションと、VoiceAgentSessionクラスが処理を担います。このクラスは2つのWebSocket接続（TwilioとDeepgramのVoice Agent API）を保持し、両者間で音声をやり取りします。DeepgramのVoice Agent APIは、音声認識、LLMによる推論、音声合成処理を1つのリアルタイムなループに統合しています。サービスを個々に組み合わせる必要はなく、音声データを送信するだけで即座に生成された音声データを受け取ることができます。

また、音声オペレーター向けに最適化されたDeepgramのSTTモデル「Flux」は、会話のターン（発言権の交代）をネイティブに判定するため、AIオペレーターは発信者がどのタイミングで話し始めたかを正確に把握できます。ユーザーによる会話の割り込みは、Twilioのclearイベントに連携されているため、ユーザーはいつでもオペレーターを遮って発言できます。

インバウンドとの決定的な違いは、この音声ブリッジが開く前段階の処理の複雑さにあります。

住宅所有者向け保険のリード（見込み客）に対するフォローアップの電話を事例として紹介します。見込み客がWebサイトのフォームから見積り依頼を送信します。依頼を受けると、システムは自動でアウトバウンド発信をトリガーし、顧客情報の確認を行うとともに、追加データ（屋根の築年数や最近の保険金請求履歴など）を聞き取りして、最適な担当者との相談の予約を行います。通話がボイスメールへ転送された場合は、AIオペレーターが代理でパーソナライズされたメッセージを残します。

この発信操作を開始するには、外部システム（CRM、CLIスクリプト、Webhookなど）から対象者の電話番号とリード情報（コンテキスト）を添えて、自社サーバーのPOST/make-callエンドポイントへリクエストを送信します。

そこから先はサーバーが処理を引き継ぎます。サーバーは、自身のWebSocketを指す<Connect><Stream>を含んだインラインTwiMLを指定して、Twilio REST APIを呼び出します。これにより、Twilioが受信者へダイヤルし、通話が接続されたタイミングでVoiceAgentSessionブリッジへと処理が引き継がれます。これは、Twilioの利用者がよく構築しているパターンです。CRMをトリガーとして、アウトバウンド音声通話を発信し、結果などの構造化データを記録システムへ返します。

留守番電話検知、CRM連携、およびリポジトリが対応しているその他のアウトバウンド関連の課題

Twilioの非同期APIを使用した留守番電話検知（AMD）。通話が接続された段階では、サーバーは応答したのが人間なのかボイスメールなのかを識別できません。Twilioの非同期AMD（留守番電話検知）が実行されている間（約2〜4秒）、受信音声をバッファリングします。検出結果が/amd-resultにPOSTされると、セッションが分岐します。

• 人間の応答を検出: Deepgram Voice Agent APIに接続してバッファリングされた音声をクリアし、会話を開始します。
• ボイスメールの応答を検出: Deepgramの音声合成モデル「Aura-2」を用いてパーソナライズメッセージを再生し、通話を終了します。

リポジトリは、遅延検出にも対応しています。オペレーターが人間と判定して会話を開始した後にAMDがボイスメールを検出した場合、システムは通話中にDeepgramとの接続を切断し、メッセージ吹き込み処理へと切り替えます。このような稀なケースは大量発信時に発生することがありますが、すでに解決済みです。

音声オペレーターのプロンプトに、見込み客のコンテキスト情報を挿入します。オペレーターのシステムプロンプトは、POST /make-callリクエストに含まれるリードデータに基づいて動的に生成されます。オペレーターは会話の開始段階で、顧客名、物件の詳細情報、および顧客のニーズを把握しています。つまり、冒頭で「こんにちは、こちらは自動音声ガイダンスです」といった定型句ではなく、「エバーグリーンテラス742番地の住宅保険の見積りの件でお電話いたしました」のように自然に語りかけることができます。

構造化された通話結果をCRMに反映させます。これこそが、音声オペレーターを単なる「デモ」から「実用的なワークフロー」へと進化させるコア要素です。Deepgram Voice Agent APIは関数呼び出しに対応しているため、会話の裏側で動くLLMが対話中に特定のアクション（空き状況の確認や予約枠の確保など）を自律的に実行できます。さらに通話の最後には、update_lead関数が実行され、対応ステータスや確認済み情報、新たに収集したデータ、そして自然言語による通話要約を構造化されたJSONデータとして出力します。このリファレンス実装では、データはコンソールにログ出力されます。本番環境では、CRM、Webhookエンドポイント、またはデータベースへPOST（送信）されます。LLMは、通話がいつ行われ、何を報告すべきかを判断し、サーバーはそれをバックエンドにルーティングします。

DeepgramのInjectAgentMessageによるサイレンスモニタリング サイレンスモニターは、通話の相手が応答しているかを監視します。無音状態が一定時間続くと、DeepgramのInjectAgentMessage APIを使用して、オペレーターが発信者へ「聞こえていらっしゃいますか？」と問いかけます。これはサーバー側からの割り込みコマンドで、LLMに自ら応答を生成させるのではなく、指定した固定のセリフを音声オペレーターに直接発話させる仕組みです。応答がない状態が続くと、サーバーは最終的に通話を終了します。些細なことのように見えますが、大量の発信を行う場合、無音時間の通話料を削減する上で非常に重要なポイントとなります。

アウトバウンド音声オペレーターの使用を開始する

リポジトリには、Twilioの設定とFly.io（ユーザーに近いアプリサーバーを実行するプラットフォーム）へのデプロイを行うセットアップウィザードが含まれています。事前準備として、Python 3.12以降、Twilioアカウント、およびDeepgram APIキー（無料、200ドル分のクレジット付き、クレジットカード不要）が必要です。

ウィザードに従って操作するだけで、Twilio番号の選択、/make-callエンドポイント用のエンドポイントシークレットの生成、Fly.ioへのデプロイまでをスムーズに行えます。デプロイが完了したら、テスト発信を実行します。

指定した電話に着信します。音声オペレーターが、保険の見込み客へのフォローアップ会話を進めます。サーバーログから、完全な文字起こしデータと構造化された通話結果（JSON）を確認します。

このコードをフォークして、保険関連のシナリオを削除し、独自のプロンプト、関数、CRM連携機能を組み込んでください。MITライセンスです。

発信者からの着信に対してAI受付担当者が自動応答するインバウンド機能の構築については、「Building an Inbound Voice Agent with Twilio and Deepgram」（TwilioとDeepgramを使用したインバウンド音声オペレーターの構築）で解説しています。