AWSが、飲食店にかかる電話をAIが受け、あいさつから注文確定までを自動でこなす音声AIシステムの構築手法を公開した。音声対話モデルNova 2 Sonicとエージェント基盤AgentCoreを組み合わせ、実装コード一式もGitHubで公開している。
AWSが、飲食店にかかる電話を受け、あいさつから注文確定までを自動でこなす音声AIシステムの構築手法を公開した。音声から音声へ直接応答する対話モデルAmazon Nova 2 Sonicと、AIエージェント基盤Amazon Bedrock AgentCoreを組み合わせ、電話網の音声はSIPゲートウェイ（Amazon ECSとAWS Fargate上で動作）経由でAIへ中継する構成だ。
背景には具体的な課題がある。飲食店は1店舗あたり月平均150件の電話を取りこぼし、うち約6割が注文・予約の客だとされる。メニューや注文などの店舗システムは標準手順Model Context Protocol（MCP）でツールとして接続し、注文ロジックと通話チャネルを分離する。
体験面では、通話ごとに独立した仮想環境（microVM）で会話を実行し、着信の呼び出し中にセッションを準備することで無音を防ぐ。システム全体はAWS CDKで一括構築でき、サンプルコードがGitHubで公開されている。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
飲食店では1店舗あたり月平均150件の電話を取りこぼしており、そのうち約6割が注文や予約の客だとされる。取りこぼしはディナー営業のピーク時に集中し、スタッフを電話対応に回しても客席と電話の両方の体験を損なう。アプリやWebでの注文は電話派の客には効果がない。そこで電話網からの音声を受け取り、そのままAIが対話して注文を処理する仕組みが求められていた。
電話という古い接点をそのままAIで自動化する実例であり、店側の追加負担なしに機会損失を減らせる点が実務的に効く。音声を直接扱うNova 2 Sonicと、外部システムを標準手順（MCP）でつなぐAgentCoreを使うことで、注文ロジックと通話チャネルを分離し、アプリやキオスク端末など別チャネルへ再利用しやすい設計になっている。電話が鳴っている間にAIの応答準備を先行させ、無音を避ける工夫も示されている。
AWSが公開したのは、飲食店にかかる電話をAIが受け、あいさつから注文確定までを自動でこなす音声AIシステムの構築手法だ。前提となる課題は具体的で、飲食店は1店舗あたり月平均150件の電話を取りこぼし、そのうち約6割が注文や予約の客だとされる。取りこぼしはディナー営業のピーク時に集中し、スタッフを電話対応に回せば客席の体験も損なう。
In this post, we show you how to build a voice ordering system that answers a phone number and takes the order from greeting to confirmation.
上の引用は「電話番号に応答し、あいさつから注文確定まで受け付ける音声注文システム」を作る手法だと述べている。アプリやWebでの注文は電話派の客には効かない。電話という古い接点をそのまま自動化する点が、この手法の実務的な核だ。
システムの構成は2つの新しい部品が中心になる。ひとつは音声から音声へ直接応答する対話モデル「Amazon Nova 2 Sonic」、もうひとつはAIエージェントを動かす基盤「Amazon Bedrock AgentCore」だ。電話網の音声はSIPゲートウェイ（電話回線とネット上のサービスをつなぐ中継装置）を経由してAIへ渡され、Nova 2 Sonicが対話を担う。
The system uses Amazon Bedrock AgentCore to host and run the agent and Amazon Nova 2 Sonic for real-time speech, connected to a restaurant backend through the Model Context Protocol (MCP).
引用中のMCP（Model Context Protocol）は、AIと外部システムをつなぐ共通の接続仕様のことだ。メニューや注文といった店舗システムをこのMCPでツールとして接続する。この分離によって、注文ロジックと通話チャネルが切り離され、アプリやキオスク端末など別チャネルへ同じ注文処理を再利用しやすくなる。SIPゲートウェイはAmazon ECSとAWS Fargate上で動く構成だ。
音声AIで体験を左右するのは応答の間だ。この手法は通話ごとに独立した仮想環境（microVM、通話ごとに切り離された小さな実行環境）で会話を実行し、着信の呼び出し中にセッションを先行して準備しておく。
It also warms the agent session while the phone is still ringing, so the caller never hears dead air.
引用は「電話が鳴っている間にエージェントのセッションを温めておくので、発信者が無音（dead air）を聞くことはない」と述べている。呼び出し音が鳴っている数秒を準備時間に充てることで、応答直後の待ちを消す。通話ごとに環境を分離する点は、複数の着信が同時に来ても会話が混ざらない前提になる。
最も直接得をするのは電話注文が多い飲食店だ。ピーク時に取りこぼしていた月平均150件・うち6割の注文/予約客に、スタッフを増やさず応答できる。実装側では、AWS CDKで全スタックを一括構築でき、SIPからNova 2 Sonicまでの参照実装がGitHubで公開されているため、AWSを使うエンジニアはゼロから設計せずに着手できる。
一方で競合が生じる領域もある。定型の注文・予約受付を店側の自前AIで完結できる範囲では、電話代行やコールセンター外注の受注機会と競合する。音声AIを独自開発してきたベンダーにとっては、SIP中継から注文確定までの参照実装が無償公開されたことで、同等機能の差別化余地が狭まる。
立場別、明日から動ける一手。
MCPで接続する店舗システム（メニュー・注文）の権限境界と、通話ごとのmicroVM分離が自社のデータ取り扱い要件を満たすかを確認する。
自店の月間電話取りこぼし件数と注文/予約比率を記録し、AWS提示の150件・6割という基準値との差を測る。
GitHubの公開サンプルをAWS CDKでデプロイし、着信呼び出し中のセッション準備で無音が防げるかを試す。
電話という既存の接点をそのまま自動化する実装例として、実装者から関心が寄せられている。
争点は、月150件・注文6割という取りこぼしの基準値がどこまで一般化できるか、通話ごとのmicroVM分離やMCP経由の店舗システム接続が自社のデータ取り扱い要件を満たすか、そして着信呼び出し中にセッションを準備して無音を防ぐ設計が実運用でどこまで効くかに集まっている。AWS CDKでの一括構築とGitHub公開サンプルにより、参照実装を手元で試せる点が評価されている。
※トレンド検出時刻付近の人気投稿を表示
