AWS、レストラン向け電話AIホストを公開

日本の飲食店では、店舗あたり月平均約150件の電話が置き去りにされています。そのうち約6割は注文やテーブル予約を目的とした顧客からのものです。こうした電話の集中は、まさにディナータイムの最盛期に起こります。ホストが客を案内し、スタッフが席替えを行っている最中に、電話対応がおろそかになりがちです。

現場から誰かを呼び出して対応させるのは解決策になりません。むしろ、顧客体験とスタッフの業務効率の両方を悪化させるだけです。アプリやWebサイトの導入はオンライン注文を好む顧客には役立ちますが、「ただ電話をかけたい」という顧客にとっては何の解決にもなりません。

本稿では、電話番号に着信し、挨拶から注文確認まで一貫して対応する音声注文システムの構築方法をご紹介します。このシステムは、エージェントのホストと実行に Amazon Bedrock AgentCore を、リアルタイム音声処理には Amazon Nova 2 Sonic を使用します。また、飲食店のバックエンドシステムとの連携には Model Context Protocol (MCP) を採用しています。

解説では、AWS Cloud Development Kit (AWS CDK) を用いたフルスタックのデプロイ手順と、Amazon Elastic Container Service (Amazon ECS) や AWS Fargate 上の SIP ゲートウェイを介して電話回線をエージェントに接続する方法を詳しく説明します。さらに、通話開始前にエージェントセッションをウォームアップさせる仕組みも実装しており、通話者が待ち時間（デッドエア）を感じることはありません。

ソリューションの概要

本システムは、3 つのレイヤーで構成されています。まず「電話回線層」が通話特有の課題を処理します。ここでは音声データがブラウザ経由ではなく電話網を通じて届き、ユーザー認証もログイン情報ではなく電話番号によって行われます。この音声は、署名付き WebSocket 接続を介して「エージェント層」へストリーミングされます。ここで Amazon Nova 2 Sonic を実行するエージェントが会話を行います。

さらに、エージェントは MCP ツールを通じて「バックエンド層」にアクセスします。バックエンドにはメニュー情報、カート、注文履歴、店舗場所などのデータが保持されています。これらのレイヤーを分離することで、注文ロジックと通信チャネルを独立させることが可能です。例えば、モバイルアプリやキオスクといった新しいチャネルを追加する場合でも、バックエンドを書き換えることなく既存のエージェントに接続できます。また、MCP はエージェントと外部ツールを接続するためのオープン標準であるため、バックエンドを変更してもエージェント側への影響はありません。

このエージェントは、入力・出力ともにテキストと音声の両方に対応しており、文字起こし、ターン制の制御、会話中の割り込み処理などを、単一の双方向ストリーム上で一括して処理します。

本ソリューションでは、以下の構成要素を展開します：

電話回線側では、Amazon Chime SDK Voice Connector が SIP トランクとフリーダイヤル番号を提供し、着信通話を受け付けます。SIP ゲートウェイは AWS Fargate 上で動作する Amazon ECS で実行され、その背後には Network Load Balancer が配置されています。

エージェント層では、AgentCore Runtime が会話ロジックをホストし、各通話は分離のために個別のマイクロ VM 内で実行されます。音声対話（Speech-to-Speech）は Amazon Nova 2 Sonic が担当します。また、AgentCore Gateway はバックエンド API を MCP ツールとして公開しており、エージェントは名前を指定してこれらを検索・呼び出すことができます。

バックエンド層では、Amazon API Gateway が REST エンドポイントの前面に立ち、AWS Identity and Access Management (IAM) によるセキュリティで守られています。メニュー、カート、注文、店舗検索などのビジネスロジックは AWS Lambda で実行されます。データ保存には Amazon DynamoDB を使用し、住所変換（ジオコーディング）や経路計算は Amazon Location Service が担当します。

エージェントのコンテナイメージは、Amazon Elastic Container Registry (Amazon ECR) で管理され、AWS CodeBuild でビルドされ、Amazon Simple Storage Service (Amazon S3) に保存されます。

構成図

以下の図は、4 つのセクションに整理された本ソリューションを示しています。

レストランのバックエンド基盤は、まずセクション A で構築されます。顧客情報、注文データ、メニュー、カート、店舗住所などは Amazon DynamoDB に保存され、住所検索や経路探索には Amazon Location Service を活用します。ビジネスロジックは AWS Lambda が実行し、外部からのアクセスには IAM 認証を付与した上で Amazon API Gateway が公開します。リソースのデプロイ順序も依存関係に合わせて設定されています。

セクション B では AgentCore Gateway の作成と IAM 権限の設定を行い、バックエンドのエンドポイントをエージェントが利用可能な MCP ツールとして公開する構成を行います。これはエージェントとバックエンドを分離するための重要なレイヤーです。この仕組みがなければ、ツールの追加や変更のたびにエージェント自体を再デプロイする必要が生じます。

セクション C ではエージェントのプロビジョニングを行います。まず Amazon ECR リポジトリを作成し、Amazon S3 と AWS CodeBuild を活用してコンテナイメージのビルドとプッシュを実行します。その後、AgentCore Runtime をデプロイします。さらに、通話ごとにパーソナライズされた対応を実現するための支援リソースも整えます。具体的には、プロンプトをレンダリングする Lambda 関数や、AWS Systems Manager Parameter Store に保存したプロンプトテンプレート、通話者の特定に使用するシークレット情報などが含まれます。

D セクションでは、電話回線の経路を構築します。具体的には、Amazon Chime SDK Voice Connector とフリーダイヤル番号のセットアップ、着信通話の処理内容を決定する SIP Media Application Lambda、共有の Amazon Virtual Private Cloud (VPC)、そしてネットワークロードバランサー背後で AWS Fargate 上で動作する Amazon ECS 上の SIP ゲートウェイ（drachtio-server）を構成します。このゲートウェイは、Chime SDK Voice Connector と AgentCore Runtime の間を中継して通話を繋ぎます。

上記の図にある番号付き注釈は、本ソリューションがエンドツーエンドでどのように動作するかを追跡しています。

顧客から、あるいは別の回線からの転送により、Amazon Chime SDK でプロビジョニングされた電話番号宛てに通話が発生します。

Amazon Chime SDK が入力された通話を応答し、AWS Lambda を呼び出してブリッジのセットアップを行います。Lambda はセッション識別子を生成し、AgentCore Runtime への接続を開いてマイクロ VM をウォームアップさせます。これにより、メディアストリーミング開始時のコールドスタートを回避できます。

Lambda からの応答が成功すると、Amazon Chime SDK は TCP ポート 5060 を介して SIP インバイテを送信し、ネットワークロードバランサに対してブリッジアクションを開始します。

AWS Fargate で稼働している SIP サービスがこのインバイテを受け取り、同じコンテナ内のリアルタイムトランスポートプロトコル（RTP）サービスで空きポートを確保します。これにより、割り当てられたパブリック IP アドレス上でメディアの受信が可能になります。

RTP サービスは Voice Connector から UDP ポートを通じてメディアを受信し、SIP メディアアプリケーションハンドラが作成した同じセッション識別子を使用して、AgentCore Runtime の WebSocket に接続します。これでメディアの変換処理が始まります。

AgentCore Runtime は、セッション識別子と顧客の Amazon DynamoDB レコードに基づき、AWS Systems Manager Parameter Store に保存されたシステムプロンプトを構築するために AWS Lambda 関数を呼び出します。

その後、AgentCore Runtime は Amazon Nova 2 Sonic とセッションを作成し、確立された接続を通じてシステムプロンプトの指示に従って顧客に挨拶を行います。

さらに AgentCore Runtime は、MCP プロトコルを使用して AgentCore Gateway から利用可能なツールの一覧を取得し、呼び出します。

AWS CDK がソリューションを Amazon S3 にデプロイすると、AWS CodeBuild がトリガーされてコンテナイメージがビルドされ、Amazon ECR に保存されます。AgentCore Runtime と AWS Fargate はこれらのイメージを使用して、エージェントおよび SIP サーバー、RTP サーバーを展開します。

Amazon CloudWatch により、すべてのサービスにわたる集中型の監視、ログ収集、アラート管理が行われます。また、保存されているすべてのデータは、AWS Key Management Service (AWS KMS) を用いて暗号化されています。

コールアウト 1〜9 は単一の通話中に発生するプロセスを説明しており、コールアウト 10 では SIP サーバーと AgentCore Runtime のデプロイ方法について、コールアウト 11 では監視とセキュリティの仕組みについて解説しています。次のセクションでは、デプロイや運用に関する記述は一旦脇に置き、通話そのものに焦点を当てていきます。

着信フロー

このセクションでは、通話者が最初に電話をかけた瞬間から応答までの一連の流れを追跡します。これは、前節のアーキテクチャ図で示した「1〜9 の発信コール」と同じ実行パスです。以下の図はイベントの順序をより明確に把握できるよう、シーケンス形式で描かれています。

上記の図にある番号付きステップは、通話の各段階に対応しています。

• 通話者がフリーダイヤルへ発信し、Amazon Chime SDK Voice Connector が応答します。
• Voice Connector は SIP Media Application Lambda を呼び出し、通話用のセッション ID を計算します。
• Lambda は AgentCore Runtime に対してウォームアップリクエストを送信します。これにより、電話が鳴っている間にエージェント側でセッションの準備が進みます。
• Lambda は Voice Connector に、AWS Fargate 上で動作する ECS の SIP ゲートウェイへ通話をブリッジするよう指示し、セッション ID を引き渡します。
• SIP ゲートウェイは、そのセッション ID を使用して AgentCore Runtime に対して SigV4 で署名された WebSocket を開きます。通話はウォームアップ済みのセッションに接続され、通話者の音声はエージェントへ、エージェントの応答音は通話者へと流れます。
• エージェントは Amazon Nova 2 Sonic と会話を進めながら、メニュー、カート、注文情報、店舗位置などのデータが必要な際は AgentCore Gateway を介してバックエンドツールを呼び出します。

必要な環境と前提条件

AWS アカウントを用意してください。また、デプロイ先の AWS リージョンにおいて Amazon Nova 2 Sonic のモデルアクセス権限を Amazon Bedrock コンソールの「モデルアクセス」ページから申請しておく必要があります。

さらに、Amazon Chime SDK の PSTN（公衆交換電話網）オーディオ機能を利用するには、同コンソールで電話番号のクォータ増額をリクエストしてください。過去にこのアカウントで電話番号を発注したことがない場合は特に必要です。

開発環境としては、Node.js 24.x 以降と、認証情報を設定済みの AWS CLI 2.x を用意します。また、Git でリポジトリをクローンできる状態にしておきましょう。

最後に、対象の AWS アカウントとリージョンで AWS CDK のブートストラップ（npx cdk bootstrap aws:///）を実行してください。

なお、エージェントコンテナは Python で構築されていますが、ビルド処理は AWS CodeBuild 上で実行されるため、ローカルマシンに Python をインストールする必要はありません。デプロイ先には、Amazon Nova 2 Sonic、Amazon Chime SDK の PSTN オーディオ機能、そして AgentCore Runtime がすべて利用可能なリージョンを選んでください。まずは US East (N. Virginia) リージョン（us-east-1）から始めるのがおすすめです。

AWS CDK を使ってソリューションをデプロイする

本稿の完全なソリューションは、GitHub の サンプルリポジトリ で公開されています。まずはリポジトリをクローンし、プロジェクトディレクトリに移動してください。

git clone https://github.com/aws-samples/sample-restaurant-telephony-ai-host-using-amazon-bedrock-agentcore-nova-sonic.git
cd sample-restaurant-telephony-ai-host-using-amazon-bedrock-agentcore-nova-sonic

まず、事前チェックを実行します。これにより、Node.js、AWS CLI、git、AWS CDK のブートストラップ設定、そして Amazon Bedrock モデルへのアクセス権限がすべて準備されているか確認され、不足しているものがあれば報告されます。

./scripts/preflight-check.sh

次に、デプロイ接頭辞を指定してデプロイスクリプトを実行します。この接頭辞はすべてのリソース名に付与されるため、同じ AWS アカウント内で複数回ソリューションを展開する際に識別子として利用できます。

./scripts/deploy-all.sh --deploymentPrefix qsr-tel

このスクリプトは、AWS CDK スack を順番にデプロイし、前のスタックの出力を次のスタックへ引き継ぎます。まずバックエンドを構築し、その背後に AgentCore Gateway を配置して API に接続します。続いて、AWS CodeBuild でエージェントのコンテナイメージをビルド・プッシュし、AgentCore Runtime 上にデプロイします。最後に、AWS Fargate 上で Amazon ECS を使って SIP ゲートウェイを起動し、Amazon Chime SDK Voice Connector とフリーダイヤル番号のプロビジョニングを行います。また、完了後にすぐに実機での注文テストができるよう、サンプルのメニューや店舗情報も初期データとして読み込まれます。なお、エージェントコンテナのビルドは初回実行時に数分かかるため、AWS CodeBuild が処理を行っている間はスクリプトの実行が一時的に停止する場合があります。

スクリプトが完了すると、通話先の電話番号が表示されます。

Your telephony agent is live at +1XXXXXXXXXX. Dial to test.

SIP ゲートウェイの仕組み

電話回線層には、たった一つの役割しかありません。それは通話を、エージェントが読み書きできるメディアストリームに変換することです。なぜこれが重要なのかというと、電話網とエージェントでは使われているプロトコルが異なるからです。

電話網は音声データを UDP 上の RTP パケットとして配信しますが、エージェント側は Amazon Nova 2 Sonic が理解する形式のフレームを WebSocket で受け取ることを前提としています。この間に翻訳層が存在しなければ、エージェント自身が SIP やコーデックネゴシエーション、ネットワークレベルのメディアルーティングについて理解している必要があり、結果的に単一のチャネルに縛り付けられてしまうことになります。

この変換処理を担当するのは、2 つのコンポーネントです。

Amazon Chime SDK の Voice Connector が着信通話を受け取り、SIP Media Application Lambda を呼び出します。Lambda 内で通話の経路が制御され、「SIP ゲートウェイに通話をブリッジする」という指示が返されます。同時にセッション識別子が付与されるため、次のステップで「この通話がどのセッションに属するか」を正しく認識できるようになっています。

SIP ゲートウェイは、AWS Fargate 上で動作する Amazon ECS 上に構築されています。SIP シグナリングには drachtio-server を使用し、音声のブリッジングには Node.js を活用しています。

このゲートウェイは通話に応答し、電話回線が使用する音声フォーマットと、Amazon Nova 2 Sonic が想定するフォーマットの間で変換を行います。高可用性（HA）を実現するため、2 つのタスクを異なるアベイラビリティゾーン（AZ）Availability Zones (AZs) に分散して実行しています。これにより冗長性が確保され、同時に Amazon CloudWatch への通話数メトリクスの公開先としても機能し、スケーリングの判断材料となります。

通話のシグナリングはネットワークロードバランサーを経由しますが、音声データそのものは Voice Connector と Fargate タスクの間で直接やり取りされます。これにより、メディアパスにロードバランサーを介在させる必要がなくなり、負荷分散の最適化を図っています。

通話中にエージェントをウォーミングアップする

音声通話は沈黙に対して非常に厳しいものです。通話者が接続して数秒間何も聞こえないと、システムは正常に動作しているにもかかわらず、通話が切断されたような不具合を感じさせてしまいます。

通話開始時の遅延要因となるのは、一度きりのセットアップ処理です。エージェントはこの通話者のためのシステムプロンプトを解決し、Amazon Nova 2 Sonic のストリームを開き、利用可能な MCP ツールを検出する必要があります。

通話者が待たされるのを避けるため、SIP メディアアプリケーションの Lambda は電話が鳴っている間に処理を開始します。着信と同時に、Lambda は通話用のセッション識別子を含むウォームアップリクエストを AgentCore Runtime へ送信します。これにより、AgentCore Runtime はマイクロ VM を割り当て、通話中の待ち時間（リングングウィンドウ）にセットアップを実行します。

数秒後、SIP ゲートウェイが同じセッション識別子を使って WebSocket 接続を開くと、AgentCore Runtime はそのリクエストを既にウォームアップ済みのマイクロ VM にルーティングし、エージェントは通話の準備が整います。

このセッション識別子が二つのリクエストをつなぐ鍵となります。Lambda は通話情報自体から識別子を計算するため、ウォームアップ要求と後の音声接続が追加の状態管理なしに同じマイクロ VM へ解決されます。以下の図は、通話が接続された時点でエージェントが準備完了しているように、この処理がリングングウィンドウとどのように重なるかを示しています。

メニューやカート、注文情報の保存

注文ワークフローを支えるのは、5 つの Amazon DynamoDB テーブルです。"Customers" テーブルには顧客のプロファイル（氏名、電話番号、ロイヤリティ情報など）を格納し、エージェントが通話者の再帰を識別できるようにしています。"Orders" テーブルでは注文履歴と受け取り場所を管理します。"Menu" テーブルには商品名、価格、在庫状況などを保存しており、店舗によって内容が異なる点も反映されます。"Carts" テーブルは進行中のカート情報を保持し、有効期限（TTL）を設定することで、放置されたカートを自動的に削除する仕組みになっています。また、"Locations" テーブルには座標や営業時間、税率といった店舗詳細を格納しており、エージェントが合計金額の計算や推奨を行う際に参照します。DynamoDB のオンデマンド容量モードを選んだため、トラフィックに応じて自動でスケールし、スループット管理の手間もありません。

受け取り場所の検索

Amazon Location Service を活用すれば、通話者は何も入力する手間なく、便利な受け取りスポットを見つけることができます。電話ではブラウザを使って位置情報を共有できないため、エージェントは ZIP コードや交差点名を聞き取り、それを Amazon Location Service で座標に変換します。取得した座標をもとに、バックエンドではいくつかの処理が可能です。まず、最寄りの店舗を検索したり、直線距離ではなく走行時間に基づいてランキング付けたりできます。これにより、通話者のルートに沿ったわずかな迂回を優先し、効率的なルートを提案できます。また、特定の住所を座標に変換するジオコーディングも可能です。

この仕組みのおかげで、エージェントは内部コードを読み上げるのではなく、「メインストリートにある店舗が最寄りで、約 5 分です」といったように、通話者がすぐに行動に移せる具体的な情報を伝えることができます。

Amazon Bedrock AgentCore と Amazon Nova 2 Sonic を活用した音声処理

エージェントは AgentCore Runtime 上で動作します。各通話は独立したマイクロ VM で実行されるため、ある利用者のセッションが他の利用者に影響を及ぼすことはありません。AgentCore Runtime がスケーリングを担当し、双方向のオーディオデータを伝送する WebSocket 接続も提供します。

エージェント内部では、エージェントフレーム