LiveKitエージェント・フレームワーク: Oracle Cloud Infrastructure上のリアルタイム・アウトバウンド音声AI (2026/09/26)

https://blogs.oracle.com/ai-and-datascience/livekit-agents-real-time-voice-ai-on-oci

_{概要、発信コールフロー、LiveKitの役割、およびOCIの全体像}

はじめに

現代の企業には、電話、ブラウザ、モバイルなど、ユーザーが既に利用している場所で対話できるAIが必要です。多くの業務フローにおいて、音声は依然として、配送確認、見込み客の選定、アポイントメントのスケジュール設定、構造化面接の実施などを行うための最速の手段です。

課題はチャットボットを作成することではない。真の課題は、脆弱な一時的統合を構築することなく、ライブ音声、電話ネットワーク、AIモデル、企業データ、セキュリティ、および可観測性を調整することである。

LiveKitのオープンソースのエージェントフレームワークは、Apache-2.0ライセンスの下で自己ホスト型で商用ワークロードに使用できます。Oracle Cloud InfrastructureのAIサービスおよびOCIインフラストラクチャと組み合わせることで、チームは所有、監視、拡張可能なリアルタイム音声エージェントを構築および運用するための実用的な方法を得ることができます。この最初のセクションでは、基本事項から始めます。発信AI電話通話中に何が起こるのか、LiveKitがどのように各要素を接続するのか、そして同じフレームワークをOCI内にどのように組み込むことができるのかについて説明します。

発信型AI電話の仕組み

発信型AI電話は、2つの世界をつなぐ架け橋です。一方では、顧客は通常の電話を受けます。他方では、AIエージェントがリアルタイムのLiveKitルームに参加し、発信者の会話を聞き、会話内容を推論し、同じ通話を通して応答します。
これらの用語は最初は難しく聞こえるかもしれませんが、基本的な考え方はシンプルです。LiveKitは、AIエージェントと電話の発信者を同じライブオーディオセッションに維持します。

学期	平易な意味
WebRTC	ブラウザやアプリで使用される、リアルタイムの音声および動画伝送方式。
SIP	電話システムが通話の開始、管理、終了を行うために使用する通話制御プロトコル。
SIPトランク	システムが電話プロバイダ経由で通話を発信できるように設定されたルートまたはアカウント。
PSTN	携帯電話番号と固定電話番号の背後にある公衆電話網。
TwilioまたはSIPプロバイダー	クラウドアプリケーションを公衆電話網に接続する通信事業者プラットフォーム。Twilioはその代表的な例の一つです。
SIP bridge	LiveKitの電話レイヤーは、LiveKitのルームオーディオと通話の電話ネットワーク側を接続します。

発信通話の流れ：ステップバイステップ

1. LLMが最初のメッセージを準備します。LLMはシステムプロンプトを読み取り、エージェントの役割、目標、およびトーンを把握します。たとえば、配達確認エージェントは顧客に挨拶し、荷物が届いたかどうかを尋ね、通話を短くする必要があります。これに基づいて、LLMはエージェントが話す最初のメッセージを作成します。

2. テキスト読み上げによってエージェントの音声が生成される： LLMの応答は依然としてテキストであるため、テキスト読み上げエンジンがそれを自然な音声に変換します。最新のエンジンは、ほんの一瞬で音声のストリーミングを開始できるため、エージェントは文全体が終わるのを待たずに話し始めることができます。

3. LiveKit Roomはライブ音声を伝送します。LiveKit Roomは、通話用のプライベートなオンライン音声ルームと考えてください。AIエージェントはこのルームに参加者として参加し、マイクに向かって話す人のように、自分の声をルームに発信します。LiveKitは、その音声を通話フローの次の部分にルーティングします。

4. SIPブリッジはインターネット音声と電話音声を接続します。LiveKitはインターネット経由で音声を処理し、通常の電話ネットワークはSIPを使用します。SIPブリッジはこれら2つの世界の間でリアルタイムに翻訳を行うため、LiveKitルームからのエージェントの声が顧客の通常の電話通話に届きます。

5. 電話ネットワークが顧客に電話をかける：翻訳された音声はTwilioなどの電話キャリアに渡され、電話キャリアは公衆電話ネットワークに接続して顧客の番号にダイヤルします。顧客から見ると、アプリや特別なハードウェアは必要なく、通常の着信として表示されます。

6. 顧客が応答し、通話が開始される：顧客が電話に出ると、双方向の音声リンクが確立されます。オペレーターの声は手順2、3、4、5を経て顧客に届き、顧客の声も同じ経路で逆方向に伝わります。これで通話が正式に開始されました。

7. 顧客の音声がLiveKitルームに戻る：顧客が話すと、その音声は電話キャリアとSIPブリッジを経由して同じLiveKitルームに戻ります。エージェントはそこでリアルタイムで音声を聞いており、すぐに次のステップに音声を渡すことができます。

8. 音声認識で顧客の発言をテキスト化：顧客の音声は音声認識エンジンにストリーミングされ、話された言葉がテキストに変換されます。これは顧客が話している最中にも行われるため、オペレーターは返答を理解し、次の応答を迅速に準備することができます。

9. LLMの理由と応答：文字起こしされた言葉は、これまでの会話履歴とともにLLMに渡されます。LLMは次に何をするかを決定します。単に言葉で応答する場合もあれば、注文を検索したり、結果を保存したり、通話を転送したりするためにツールを呼び出す場合もあります。どのような決定を下しても、回答はステップ2に直接反映され、ループが続きます。

ステップ2～9を繰り返すループ：ステップ2～9は会話の各ターンごとに繰り返され、LLMは実行中のコンテキストを保持します。ループは、LLMが通話が完了したと判断し、顧客が電話を切った時点で終了します。

音声パイプラインの順序：VADからSTT、LLM、TTSへ

電話がつながると、AIエージェントはシンプルながら強力な音声処理パイプラインに従って動作します。各段階には明確な役割が一つずつ割り当てられています。

オーディオ入力 → VAD → STT → LLM → TTS → オーディオ出力

1. 音声活動検出

音声活動検出（VAD）は、オペレーターが顧客の発言を把握するのに役立ちます。実際の音声と無音、背景雑音、短い間を区別します。

顧客が話し始めたことを検知すると、音声は次の段階に渡されます。

短い沈黙は、顧客が話し終えたのではなく、考えていることを意味する可能性があり、それによって、よりリアルな会話のための慎重な調整が可能になります。

2. 音声認識

顧客の音声は音声認識（STT）エンジンにストリーミングされ、そこで文字起こしが行われます。最新のSTTエンジンは、顧客が話している最中でも単語やフレーズの一部を送信できます。これにより、オペレーターは応答の準備を始める前に文全体を待つ必要がないため、遅延を軽減できます。

3. 大規模言語モデル

顧客の発言内容、システムプロンプト、会話履歴、および利用可能なツールを受け取ります。これらの情報に基づいて、次に何をすべきかを判断します。直接回答したり、追加の質問をしたり、注文を検索したり、通話結果を保存したり、通話を転送したりする場合があります。

4. テキスト読み上げ

LLMは応答を生成し、TTSエンジンはその文を自然な音声に変換します。TTSは応答が完全に完了するのを待つのではなく、できるだけ早く音声をストリーミングする必要があります。

5. オーディオ伝送

ブラウザやモバイル端末での通話の場合、通常はWebRTCを介して行われます。電話通話の場合は、音声はSIPと電話網を介して伝送されます。

LiveKitがコンポーネントをいかにして結合させるか

音声エージェントは多くの構成要素から成り立っています。あるコンポーネントは顧客の音声を聞き取り、別のコンポーネントは音声をテキストに変換します。LLM（音声認識モジュール）は次に何を言うべきかを判断し、テキスト読み上げ機能がその回答を音声に変換します。電話ネットワークは音声データを顧客との間で送受信します。

調整層がなければ、これはすぐに脆弱な独立したサービスの連鎖になってしまう可能性がある。

LiveKitは、その連携レイヤーを提供してくれる。

LiveKitは、これらの様々な要素を一つのリアルタイムな会話へと統合します。各コンポーネントを個別に独立して実行されるステップとして扱うのではなく、LiveKitは顧客、AIエージェント、そして電話が一体となる共有のリアルタイム空間を提供します。

発信通話の場合、LiveKitは発信SIPトランクを使用して顧客に電話をかけ、通話をLiveKitルームに接続します。顧客が応答すると、AIエージェントと顧客は同じライブセッションで接続されます。顧客は通常の電話通話で話し、エージェントはLiveKitを通じてそれを聞き、応答します。

ここでLiveKit Agentsの真価が発揮されます。AgentSessionは、音声パイプラインを単一の動作フローに統合します。具体的には、着信音声、音声アクティビティ検出、音声認識、LLM推論、テキスト音声変換、割り込み、ツール呼び出し、セッションイベントなどが含まれます。各サービスごとに個別のグルーコードを記述する代わりに、アプリケーションは単一のセッションレイヤーから会話を管理できます。

OCI の現状: OCI 上の LiveKit フレームワーク

OCIのデプロイメントパターンはシンプルです。パブリックエッジを小さく保ち、エージェントランタイムをプライベートに保ちます。LiveKitのメディアエントリポイントと必要なロードバランサーはパブリックサブネットに配置されます。エージェントワーカー、ツールサーバー、データベース、シークレット、およびAIサービス呼び出しは、プライベートサブネットまたはマネージドOCIサービスに配置されます。

この構成では、パブリックサブネットは、WebRTCメディア、SIP接続、OCIロードバランサー経由のTLSエントリなど、外部からアクセス可能な接続のみを処理します。プライベートサブネットは、LiveKitエージェントワーカー、MCPツールサーバー、キューまたはキャッシュサービス、およびインターネットに直接公開すべきでないアプリケーションロジックを実行します。

エージェントワーカーは、推論のためにOCI Generative AI、必要に応じて音声サービスのためにOCI Speech、文字起こしと結果のためにAutonomous Database、録音と成果物のためにObject Storage、そしてシークレットのためにOCI Vaultを呼び出します。監視、ログ記録、監査、IAM、ネットワークセキュリティグループ、プライベートエンドポイント、およびBastionアクセスにより、本番環境への展開に必要な運用およびセキュリティ制御が提供されます。

このアプローチにより、LiveKitフレームワークはOCI AIおよびエンタープライズデータに近接した状態を維持しつつ、特定のユースケースで必要とされる場合には、電話プロバイダーやオプションの外部AIサービスとの制御された統合も可能になります。

次のブログで詳細をご覧ください：
https://blogs.oracle.com/ai-and-datascience/livekit-powered-cargo-company-ai-delivery-confirmation-agent↗