PipecatとAmazon Bedrock AgentCore Runtimeで音声エージェントをデプロイする - 第1部

この投稿は、AWS と [Pipecat](https://www.pipecat.ai/?model=aws-nova-sonic) の共同制作です。 自然で人間らしい会話を維持するインテリジェントな音声エージェントをデプロイするには、ユーザーが利用している場所（Web、モバイル、電話チャネルなど）へストリーミング配信を行う必要があります。これは、過大なトラフィックや不安定なネットワーク環境下においても同様です。わずかな遅延でも会話の流れが途切れ、ユーザーにエージェントが反応していない、あるいは信頼できないという印象を与えてしまいます。カスタマーサポート、バーチャルアシスタント、アウトバウンドキャンペーンなどのユースケースでは、自然な流れがユーザーエクスペリエンスにとって極めて重要です。本シリーズの投稿では、[Amazon Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html) 上で [Pipecat](https://github.com/pipecat-ai/pipecat) の音声エージェントを活用し、ストリーミングアーキテクチャがこれらの課題をどのように解決するかについて学びます。 パート1では、WebSocket、WebRTC、および電話回線統合（telephony integration）を含むさまざまなネットワーク転送アプローチを用いて、AgentCore Runtime 上で Pipecat 音声エージェントをデプロイする方法と、実用的なデプロイガイダンス、コードサンプルについて学習します。 ## Voice エージェントにおける AgentCore Runtime の利点 リアルタイム音声エージェントの展開は困難を伴います。低遅延ストリーミング、セキュリティのための厳格な分離、予測不能な会話量への動的スケーリング能力が必要です。適切に設計されたアーキテクチャがない場合、オーディオジッター（音質の揺らぎ）、スケーラビリティの制約、過剰プロビジョニングによるコスト増大、複雑性の増加といった問題が発生する可能性があります。カスケード型 (STT → LLM → TTS) や音声対音声アプローチを含む音声エージェントアーキテクチャの詳細については、以前の投稿 [Amazon Nova Sonic を用いたリアルタイム音声アシスタントの構築とカスケード型アーキテクチャとの比較](https://aws.amazon.com/blogs/machine-learning/building-real-time-voice-assistants-with-amazon-nova-sonic-compared-to-cascading-architectures/) をご参照ください。 [Amazon Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html) は、動的な AI エージェントのスケーリングを可能にする安全でサーバーレスな環境を提供することで、これらの課題に対処します。各会話セッションはセキュリティのために分離されたマイクロ VM (microVMs) で実行されます。トラフィックの急増に対して自動スケーリングし、最大 8 時間にわたる継続的なセッションも処理できるため、長時間にわたる多段階の音声対話に最適です。実際に使用されたリソースのみに対して課金されるため、アイドル状態のインフラに関連するコストを最小限に抑えることができます。 Pipecat は、リアルタイム音声 AI パイプラインを構築するためのエージェントフレームワークであり、最小限の設定で AgentCore Runtime 上で動作します。Pipecat の音声パイプラインをコンテナとしてパッケージ化し、AgentCore Runtime に直接デプロイできます。このランタイムは、リアルタイムオーディオのための双方向ストリーミングと、エージェントの推論やツール呼び出しを追跡するための組み込み観測機能（observability）をサポートしています。 AgentCore Runtime では ARM64 (Graviton) 対応のコンテナが必要となるため、Docker イメージが linux/arm64 システム向けにビルドされていることを確認してください。 ## AgentCore Runtime における音声エージェントのストリーミングアーキテクチャ 本記事では、一般的な音声エージェントのアーキテクチャについてある程度ご存知であることを前提としています。具体的には、音声認識 (STT) と音声合成 (TTS) モデルをパイプラインで接続する [カスケード](https://aws.amazon.com/blogs/machine-learning/building-intelligent-ai-voice-agents-with-pipecat-and-amazon-bedrock-part-1/) モデルのアプローチや、[Amazon Nova Sonic](https://aws.amazon.com/ai/generative-ai/nova/speech/) のような [音声から音声へ](https://aws.amazon.com/blogs/machine-learning/building-intelligent-ai-voice-agents-with-pipecat-and-amazon-bedrock-part-2/) のモデルアプローチです。これらの概念に初めて触れる場合は、先に当社の基礎的な 2 つのアプローチである [カスケード](https://aws.amazon.com/blogs/machine-learning/building-intelligent-ai-voice-agents-with-pipecat-and-amazon-bedrock-part-1/) と [音声から音声へ](https://aws.amazon.com/blogs/machine-learning/building-intelligent-ai-voice-agents-with-pipecat-and-amazon-bedrock-part-2/) に関する以前のブログ記事をお読みください。 音声エージェントを構築する際、レイテンシは極めて重要な考慮事項であり、これが会話の自然さや信頼性を決定づけます。滑らかで人間らしいリズムを維持するためには、エンドツーエンドで通常 1 秒未満のほぼ即時応答が必要です。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/15/voice-ai-streaming-architectures-overview.png) 低遅延を実現するには、複数の経路における双方向ストリーミングを考慮する必要があります。具体的には以下の通りです。 - クライアントからエージェントへ：音声エージェントは、Web ブラウザやモバイルアプリ、エッジハードウェアなど、それぞれ固有のネットワーク環境を持つデバイスやアプリケーション上で動作します。 - エージェントからモデルへ：音声エージェントは、音声モデルとの双方向ストリーミングを介して対話を行います。ほとんどの音声モデルはリアルタイム WebSocket API を公開しており、エージェントランタイムやオーケストレーションフレームワークがこれを利用してオーディオ入力やテキスト・音声出力を取得できます。モデルの選択は、自然な応答性を達成する上で重要な役割を果たします。遅延に最適化され、高速な Time-to-First-Token (TTFT) を提供する Amazon Nova Sonic（またはカスケードパイプラインアプローチでは Amazon Nova Lite）などのモデルを選択してください。 - 電話回線：従来のコンタクトセンターや電話システムを介して処理される着信・発信通話の場合、音声エージェントは電話プロバイダーとも連携する必要があります。これは通常、ハンドオフおよび/またはセッション相互接続プロトコル (SIP) 転送を通じて実現され、生オーディオストリームが電話システムからエージェントランタイムへ転送されて処理されます。 本シリーズの第 1 部では、「クライアントからエージェント」への接続に焦点を当て、エッジデバイスから音声エージェントまでの最初のネットワーク経路における遅延を最小化する手法と、音声エージェントアーキテクチャの他のコンポーネントに関連する追加的な考慮事項について探求します。 これらの概念を説明するために、以下の考慮事項を踏まえて 4 つのネットワーク転送アプローチを探求します: - ユーザーが音声エージェントとどのようにインタフェースするか（Web/モバイルアプリケーションまたは電話通話） - 変動するネットワーク条件下でのパフォーマンスの一貫性と回復力 - 実装の容易さ アプローチ 説明 パフォーマンスの一貫性 実装の容易さ 適した用途 WebSockets Web およびモバイルアプリケーションは、WebSockets を介して音声エージェントに直接接続されます。 良い シンプル プロトタイピングおよび軽量なユースケース。 WebRTC (TURN-assisted) Web およびモバイルアプリケーションは、WebRTC を介して音声エージェントに直接接続されます。 非常に良好 中程度 クライアントが Traversal Using Relays around NAT (TURN) サーバーを介してリレーされるランタイム環境に直接接続することによる遅延を持つ本番環境向けユースケース。 WebRTC (managed) Web およびモバイルアプリケーションは、WebRTC を通じて、高度でグローバルに分散されたインフラストラクチャを介して音声エージェントに接続されます。 非常に良好（グローバル分散） シンプル グローバルに分散したネットワークとメディアリレーを持つ専門プロバイダに遅延最適化をオフロードし、観測可能性や複数参加者通話などの追加機能を提供する本番環境向けユースケース。 電話回線 音声エージェントは、従来の電話通話を通じてアクセスされます。 優秀 中程度 コールセンターおよび電話回線ユースケース。レイテンシは電話プロバイダに依存する可能性があります。 ## 例：WebSockets を用いた双方向ストリーミングアプローチ 最もシンプルなアプローチとして、WebSockets（WebSocket）から始めることができます。これはネイティブでほとんどのクライアントと AgentCore Runtime をサポートしています。永続的で双方向の WebSocket 接続を使用して、クライアントデバイスとエージェントロジック間のオーディオストリーミングを行うことで、Pipecat 音声エージェントを AgentCore Runtime 上でデプロイできます。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/15/voice-ai-streaming-websockets.png) 接続は、以下の単純な 3 ステップのフローに従います。 - クライアントは WebSocket エンドポイントを要求します：クライアントはまず、安全な WebSocket 接続エンドポイントを取得するために、仲介サーバー（/server）に対して POST リクエストを送信します。 - 仲介サーバーが AWS 認証を処理します：Pipecat の事前構築フロントエンド上の仲介サーバーは、AWS SDK を使用して、埋め込まれた資格情報をクエリパラメータとして含む AWS SigV4 署名付き URL（pre-signed URL）を生成します。例：X?-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential= - クライアントが直接接続を確立します：認証された署名付き URL を使用して、クライアントは AgentCore Runtime 上のエージェントに直接接続し、仲介サーバーを経由せずに双方向オーディオをストリーミングし、以降の通信では仲介サーバーをバイパスします。 AgentCore Runtime の要件に従い、Pipecat の [WebSocket トランスポート](https://docs.pipecat.ai/server/services/transport/fastapi-websocket) を使用して /ws パスにエンドポイントを公開します。このアーキテクチャは、クライアントアクセスのセキュリティを確保しつつ AWS 資格情報をブラウザアプリケーションに直接露出させることなく、資格情報の管理とエージェントロジックを分離しています。 詳しくは、WebSocket トランスポートを使用した AgentCore 上の Pipecat の [コードサンプル](https://github.com/pipecat-ai/pipecat-examples/tree/main/deployment/aws-agentcore-websocket) をお試しください。 ## 例のアプローチ：TURN 支援を備えた WebRTC の双方向ストリーミングの使用 WebSocket はシンプルなデプロイメントには適していますが、WebRTC はより優れたパフォーマンスを提供できます。これは遅延を最小限に抑える高速で軽量なネットワーク経路を使用してオーディオを送信するように設計されており、通常は低遅延と滑らかなリアルタイム体験のために UDP を使用します。また、変動するネットワーク条件に対する耐性も向上しています。UDP が利用できない場合、WebRTC は自動的に TCP にフォールバックしますが、これはより信頼性は高いもののわずかな遅延をもたらす可能性があります。音声には理想的ではありませんが、接続が制限されている状況では役立ちます。この信頼性は、NAT やファイアウォールを介して直接のピアツーピア経路を交渉し、直接接続ができない場合に [Traversal Using Relays around NAT (TURN)](https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT) サーバーを介したメディアストリーミングリレーにフォールバックする ICE（Interactive Connectivity Establishment）サーバーによって実現されています。 Pipecat は、AgentCore Runtime 上のクライアントとエージェント間の直接ピアツーピア WebRTC 接続のために [SmallWebRTCTransport](https://docs.pipecat.ai/server/services/transport/small-webrtc) をサポートしています。専用メディアサーバー（Selective Forwarding Units または SFU など）を必要とする包括的な WebRTC アーキテクチャと比較して、この軽量なトランスポートは AgentCore Runtime 内で直接実行可能であり、複雑なメディアサーバー管理の必要性を排除します。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/15/voice-ai-streaming-webrtc-turn.png) このシナリオでは、接続フローは以下の通り動作します。 - シグナリング：クライアントはセッション記述プロトコル（SDP）オファーを仲介サーバーに送信し、これは AgentCore Runtime の /invoke/ エンドポイントへ転送されます。@app.entrypoint ハンドラーがオファーを処理し、メディア機能とネットワーク候補を含む SDP アンスワーを返します。 - 接続確立：直接接続を確立するために、クライアントとエージェントの両方がインタラクティブ・コネクティビティ・エスタブリッシュメント（ICE）プロトコルを使用して最適なネットワーク経路を発見します。AgentCore Runtime は NAT の周囲のリレーを使用したトランザバーサル（TURN）リレー接続をサポートしています。このプロトコルは以下の順序で接続を試みます： 直接接続：ローカルネットワークアドレスを使用してピアツーピアで接続します。このパスは、ランタイム環境にパブリック IP アドレスを割り当てることができないため、AgentCore Runtime ではサポートされていません。 - NAT 用セッショントランザバルユーティリティ（STUN）支援接続：NAT を介してパブリック IP/ポートを発見し、直接接続を試みるために STUN サーバーを使用します。このパスには双方向の UDP トラフィックが必要ですが、AWS NAT ゲートウェイが対称型 NAT を使用しているため、現在はこのパスはサポートされておらず、STUN ベースの直接接続は成功しません。 - NAT の周囲のリレーを使用したトランザバーサル（TURN）リレー接続：メディアを TURN リレーサーバー経由でルーティングします。TURN は管理サービス（Cloudflare や Twilio など）、Amazon Kinesis Video Streams (KVS)、または自己ホスト型ソリューション（VPC 内の coturn など）を使用して構成します。このパスは、VPC で構成された AgentCore Runtime 上で推奨されます（詳細は後述）。 - VPC を介した接続：接続が確立されると、トラフィックはクライアントから VPC を経由してランタイム環境へルーティングされます（詳細は次のセクションで説明）。 さらに詳しく知りたい場合は、Pipecat on AgentCore のコードサンプル [WebRTC トランスポートを使用] (https://github.com/pipecat-ai/pipecat-examples/tree/main/deployment/aws-agentcore-webrtc) をお試しください。 ## VPC 上の AgentCore Runtime の WebRTC 接続用設定 [コードサンプル](https://github.com/pipecat-ai/pipecat-examples/tree/main/deployment/aws-agentcore-webrtc) は、WebRTC を使用したシンプルな音声エージェントを示しています。まず、Pipecat の事前構築フロントエンドの仲介サーバー（/server）とランタイム環境（/agent）の両方で、ICE_SERVER_URLS 環境変数を設定します。これにより、両者間の双方向通信が可能になります。 次に、UDP トランスポートを TURN サーバーへ転送できるようにするために、[VPC ネットワーク構成が設定された AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-vpc.html) にエージェントを展開します。セキュリティのため、ランタイムはプライベート VPC サブネットに公開し、インターネットアクセスをルーティングするための NAT Gateway をパブリックサブネットに配置します。これは以下の図の通りです。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/03/15/voice-ai-streaming-webrtc-vpc-architecture.png) このアプローチにより、STUN と UDP を使用し、TCP フォールバックも備えた完全な WebRTC 接続用の ICE サーバーを設定できます。例えば、Cloudflare が管理する TURN は以下のように設定します。 # agent/.env および server/.env の設定 ICE_SERVER_URLS=stun:stun.cloudflare.com,turn:turn.cloudflare.com:53,turn:turn.cloudflare.com:3478,turn:turn.cloudflare.com:5349 ## Amazon Kinesis Video Streams (KVS) を使用した AWS ネイティブ TURN の活用 管理型 TURN サービスに対する完全な AWS ネイティブの代替手段として、[Amazon Kinesis Video Streams (KVS)](https://docs.aws.amazon.com/kinesisvideostreams/latest/dg/what-is-amazon-kinesis-video-streams.html) は、サードパーティ製の依存関係なしに TURN インフラストラクチャを処理します。これは [GetIceServerConfig](https://docs.aws.amazon.com/kinesisvideostreams/latest/dg/API_signaling_GetIceServerConfig.html) API を介して一時的で自動ローテーションされる TURN 認証情報を提供し、NAT トリバーサル（ネットワークアドレス変換の通過）のためのサードパーティ依存を回避します。フローは以下の通りです。 - 一度きりのセットアップ: KVS シグナリングチャネルを作成します。このチャネルは TURN 認証情報のプロビジョニング専用であり、エージェントはシグナリングとメディアのために引き続き Pipecat の WebRTC トランスポートを使用し続けます。 - 接続時: エージェントは GetSignalingChannelEndpoint を呼び出して HTTPS エンドポイントを取得し、その後 GetIceServerConfig を呼び出して一時的な TURN 認証情報（URI、ユーザー名、パスワード）を取得します。 - ピア接続の設定: 返された認証情報を RTCPeerConnection の ICE サーバーとして渡します。TURN トラフィックは KVS が管理するインフラストラクチャを通じて流れます。 **KVS 管理型 TURN を使用する際の考慮事項** | 要素 | KVS 管理型 TURN | サードパーティ製 TURN | | :--- | :--- | :--- | | AWS ネイティブ | はい — 外部依存なし | いいえ — 外部アカウントが必要 | | 認証情報の管理 | 自動ローテーション | 手動またはプロバイダー管理 | Set up <td style="padding: 10px;border: 1px solid

PipecatとAmazon Bedrock AgentCore Runtimeで音声エージェントをデプロイする - 第1部

背景や根拠まで確認しますか？

調べる

選ぶ

サイト