Amazon Bedrock AgentCore と Nova 2 で WhatsApp 注文アシスタントをデプロイ

本記事では、Amazon Bedrock AgentCore と Amazon Nova 2 を活用して構築した多機能 WhatsApp オーダーアシスタントのデプロイ方法を解説します。

多くのクイックサービスレストランでは、注文対応をアプリ、ウェブサイト、電話、店内カウンターと複数のチャネルに分散させています。それぞれのチャネルは独立したシステムとして設計・運用されるため、顧客の履歴も分断され、同じ顧客がチャンネルごとに別人のように扱われてしまう問題があります。

一方、顧客はすでにメッセージングアプリの中で生活しています。WhatsApp は世界で 20 億人以上の利用者を持つプラットフォームです。同じ会話内でテキスト送信や音声メモ、通話が可能であれば、顧客は何らかのアプリをインストールしたり、サインインしたりする必要はありません。

このアシスタントは、単一の WhatsApp Business 番号でホストされます。顧客はレストランに対して、テキストメッセージを送ったり、音声メモを残したり、直接通話をしたりできます。AI エージェントが挨拶から注文確認までを一貫して処理します。これら 3 つのチャネルはすべて共通のバックエンドと、チャネルを跨いだ記憶機能を共有しています。ある顧客が今日テキストで連絡し、明日電話してきた場合でも、システムはその人物を同一の顧客として認識します。

本ソリューションでは、顧客との接点として Meta WhatsApp Business Platform を活用します。エージェントは Amazon Bedrock AgentCore でホストされ、テキスト処理には Amazon Nova 2 Lite と Amazon Bedrock Converse API が担当します。一方、音声メッセージや通話におけるリアルタイム音声処理は Amazon Nova 2 Sonic が担います。

エージェントは Model Context Protocol (MCP) を経由してレストランのバックエンドに接続されます。システム全体は AWS Cloud Development Kit (AWS CDK) でデプロイします。チャネルと注文ロジックを分離しているため、チャネルの追加や削除を行ってもバックエンドを変更する必要はありません。

ソリューション概要

本設計では 3 つの要素を明確に分離しています。(1) WhatsApp レヤーが会話処理を担当し、(2) 各チャネルごとに 3 つのエージェントランタイムが会話を実行し、(3) バックエンドがメニュー、カート、注文、店舗情報を保持します。

着信トラフィックは単一の HTTPS Webhook に集中し、即座に 200 ステータスで応答を返した上で非同期処理を行います。これにより、リクエストがレスポンスをブロックすることはありません。この分離構造により、各層を独立してデプロイでき、システム全体の理解も容易になります。

顧客との接点となるフロントドアは、Meta WhatsApp Business Platform です。ここでは Cloud API の Webhook、Messages API、Media API、Calling API が公開されています。このサービスは Meta によって管理されており、本ソリューションがデプロイする対象ではありません。顧客側で設定を行い、接続を前提条件として整えておく必要があります。

一方、AWS 側のリソースはすべて AWS CDK によって用意されます。CDK は、Meta に登録する Webhook URL を生成して出力します。

AWS CDK を用いて、以下の AWS リソースを依存関係の順序に従ってスタックセットとしてデプロイします。機能ごとにグループ化されています。

• Amazon API Gateway は 2 つの REST API を提供します。1 つ目は AWS が管理する証明書を用いたリージョン内の HTTPS Webhook で、唯一公開されるエンドポイントです。2 つ目は注文ロジックの前に配置された IAM 認証付きのバックエンド API です。

• AWS Lambda は、Webhook の取り込み処理、Webhook ワーカー、メッセージ送信機能、そして注文ビジネスロジックを実行します。

• Amazon Simple Queue Service (Amazon SQS) は、インバウンドキューとデッドレターキューを提供し、迅速な応答処理とその他の処理を分離します。

• AgentCore runtime は Amazon Bedrock AgentCore の機能の一つで、3 つのエージェントをホストします。各会話は独立したマイクロ VM で実行され、セッションは完全に隔離されます。

Amazon Nova 2 Lite（Converse API を通じたテキスト処理）と Amazon Nova 2 Sonic（音声対話機能）は、Amazon Bedrock を経由して呼び出されます。

AgentCore Gateway は Amazon Bedrock AgentCore の機能の一つで、管理された MCP サーバーです。バックエンドの REST API を MCP ツールとして公開し、エージェントが名前を指定して呼び出せるようにしています。

AgentCore memory も Amazon Bedrock AgentCore の機能で、ハッシュ化された顧客 ID をキーに、チャネルを超えて共有される単一の記録です。

Amazon DynamoDB には、顧客プロフィール、注文履歴、メニュー項目、カート情報、店舗場所が保存されています。また、WhatsApp レイヤー向けの「直近の受信」ウィンドウテーブルも保持しています。

Amazon Location Service は、住所の地理座標変換（ジオコーディング）や最寄りの店舗検索を担当します。

Amazon Kinesis Video Streams (Amazon KVS) は、音声通話ランタイムが使用するためのシグナリングチャネルを提供し、NAT 透過リレー（TURN）で通話メディアを転送する際に必要な認証情報を発行します。

Amazon Virtual Private Cloud (Amazon VPC)（単一のネットワークアドレス変換ゲートウェイ付き）は、音声通話ランタイムのアウトバウンド経路です。VPC が必要となるのはこのランタイムのみです。

AWS Secrets Manager には、Meta のアクセストークン、アプリシークレット、検証トークンを格納します。これらは空のコンテナとして作成され、後から外部で値を設定します。また、AWS Systems Manager Parameter Store には顧客 ID のペッパーを保存します。

Amazon Elastic Container Registry (Amazon ECR)、AWS CodeBuild、Amazon Simple Storage Service (Amazon S3) を使用して、ARM64 対応のエージェントコンテナイメージをビルドおよび保管します。

Amazon CloudWatch はログとメトリクスを収集し、AWS Key Management Service (AWS KMS) が保存データの暗号化を担当します。

アーキテクチャ図

Figure 1 に全体のアーキテクチャを示します。この図では、リクエストパスを表すラベル付きのグループ A から G までを整理して配置しています。また、そのパスの外側に 2 つのサポート用グループがあり、デプロイ時に一度実行されるビルドパイプラインでエージェントイメージを作成し、ランタイム時にすべてのチャネルを支えるセキュリティおよび監視サービスを提供します。

Figure 1: AWS 上のマルチモーダル WhatsApp オーダーリングアーキテクチャ

• A. WhatsApp の取り込みと配信：Webhook API Gateway、イングエスト（ingest）、ワーカー、送信用 Lambdas、Amazon SQS キューです。イングエストは Meta の署名を検証し、メッセージをキューに格納します。ワーカーが残りの処理を担当します。Sender Lambda が返信を送信します。

B. エージェントランタイム：AgentCore ランタイム上で動作する 3 つのエージェントがあり、それぞれ ARM64 コンテナとして実装され、チャネルごとに 1 つずつ配置されます。チャット用には Amazon Nova 2 Lite を、音声メモ用には Amazon Nova 2 Sonic を使用します。また、Web Real-Time Communication（WebRTC）を介した音声通話にも Amazon Nova 2 Sonic が利用されます。なお、VPC 内で実行されるのは音声通話用のランタイムのみです。

C. 人工知能および機械学習（AI/ML）：Amazon Bedrock を経由して Amazon Nova 2 Lite と Amazon Nova 2 Sonic を呼び出します。また、チャネル間での継続性を確保するため、ハッシュ化された customer_id をキーとして共有される AgentCore メモリを活用します。

• D. MCP サーバー（管理型）：AgentCore Gateway は、バックエンドの REST API を検出可能な MCP ツールとして公開します。具体的には GetMenu、AddToCart、PlaceOrder などがあり、すべてのランタイムが名称を指定して呼び出します。

• E. API と計算リソース：ビジネスロジックを保持する注文用 Lambda 関数と、IAM で権限管理されたバックエンドの API Gateway です。

• F. データストレージ：Amazon DynamoDB は、顧客プロフィール、注文履歴、メニュー項目、カート情報、および店舗位置などのデータを保存します。

• G. ネットワークと位置情報：ジオコーディングや最寄りの場所の検索には Amazon Location Service を、音声通話のメディア中継には Amazon KVS 管理 TURN リレーを、また音声通話ランタイムの外部通信経路には NAT ゲートウェイ付き VPC をそれぞれ利用します。

リクエストパスの外部に 2 つのサポートグループが配置されています。ビルドパイプライン（AWS CDK、AWS CodeBuild、Amazon ECR、および Amazon S3）はデプロイ時に一度だけ実行され、ARM64 対応のエージェントイメージを構築して保存します。このパイプラインはリクエストパスには含まれません。セキュリティと監視（AWS Secrets Manager、AWS Systems Manager Parameter Store、Amazon CloudWatch、および AWS KMS）は、ランタイム時にすべてのチャネルを支えています。

以下の手順では、アーキテクチャを通じて単一のリクエストがエンドツーエンドでどのように処理されるかを追跡します。

• Meta から着信する Webhook（テキスト、音声メモ、または通話イベント）が、Webhook API Gateway と Webhook Ingest Lambda に配信されます。
• Ingest は Meta の署名を検証し、Amazon SQS へキューイングして、Meta が設定した時間枠内で 200 ステータスを返します。
• Webhook Worker は、AWS Systems Manager Parameter Store に保存されたペッパーを使用して、擬似的な customer_id を生成します。
• Worker は Meta Media API からメディアを取得し、Amazon Bedrock AgentCore ランタイム上で対応するエージェント（チャット、音声メモ、または通話）を呼び出します。この際、session_id = customer_id が設定されます。
• ランタイムはセッション開始時に、AgentCore メモリから顧客の長期的なインサイトを取得します。
• Amazon Bedrock を介して、Amazon Nova 2 Lite（テキスト用）または Amazon Nova 2 Sonic（音声用）で会話を処理します。
• AgentCore Gateway は管理された MCP サーバーであり、バックエンド REST API をエージェントが名前を指定して呼び出せる MCP ツールとして公開しています。
• ツールはバックエンド API Gateway を経由し、AWS Lambda、Amazon DynamoDB、および Amazon Location Service へルーティングされます。通話メディアには、VPC 内で動作する Amazon KVS TURN リレーが使用されます。

返信は、Sender Lambda（テキスト用）またはワーカー（音声用）を通じて送信されます。セッション終了時にはイベントがメモリに記録されます。

AWS CDK は AWS CodeBuild を通じて ARM64 イメージを構築し、Amazon ECR に格納します。Amazon CloudWatch が各コンポーネントのログを出力し、AWS KMS によって保存データの暗号化が行われます。

つまり、すべてのリクエストは Meta の Webhook から始まり、取り込み（ingest）、キュー、ワーカー、エージェントランタイムを経てバックエンドツールに到達し、最終的に WhatsApp を介して顧客へ返信されます。

チャネルフロー

3 つのチャネルはいずれも同じフロントエンド入口、バックエンドツール、メモリを共有しています。異なるのは通信媒体と、それを処理するランタイムです。

テキストメッセージ：Webhook にテキストメッセージが到着すると、ワーカーが customer_id を抽出し、チャットランタイムを呼び出します。ランタイムはメモリを読み込み、Converse API を通じて Amazon Nova 2 Lite をストリーミングし、必要に応じて MCP ゲートウェイ経由でバックエンドツールを呼び出します。返信は Sender Lambda を経由して送信され、セッション終了時にイベントがメモリに記録されます。

図 2 は、インバウンド Webhook から Converse API の Amazon Nova 2 Lite を経て、Sender Lambda によって配信されるまでのテキストフローを示しています。

図 2: Amazon Nova 2 Lite を用いたテキストフロー

音声メッセージ（音声対音声）：音声メッセージが到着すると、ワーカーが OGG Opus バイトをダウンロードし、音声メッセージ用ランタイムを起動します。メモリを読み取った後、音声は 16 kHz パルス符号変調 (PCM) にデコードされ、制限付きの Amazon Nova 2 Sonic 音声対音声セッションに投入されます。ツールは同じゲートウェイを通じて利用可能です。話された返信は WhatsApp の音声メッセージとして返されます。このパスには文字起こしサービスはなく、完全な音声入力・音声出力を実現しています。

図 3 は、音声メッセージのフローを示しています。これは制限付きの Amazon Nova 2 Sonic 音声対音声セッションであり、文字起こしを介さずに話された返信を返すものです。

図 3：Amazon Nova 2 Sonic を用いた音声メッセージのフロー

音声通話 (WebRTC)：顧客が「通話」を選択すると、Meta の Calling API が WebRTC セッション記述プロトコル (SDP) オファーを含む接続ウェブフックを配信します。ワーカーはパブリック IP を持たないため、これを turnOnly モードの音声通話用ランタイムに中継します。TURN 認証情報は Amazon KVS から取得されます。Meta はトリクル型 ICE (Interactive Connectivity Establishment) パスを提供しません。aiortc アナサーは ICE 収集を待機し、単一の SDP アナザーを返します。ワーカーはそのアナザーを Meta に配信します。その後、メディアは KVS が管理する TURN リレーを経由して Datagram Transport Layer Security (DTLS) および Secure Real-time Transport Protocol (SRTP) を通じて流れます。会話を駆動するのは Amazon Nova 2 Sonic です。

図 4 は、WebRTC メディアが Amazon KVS で管理される TURN リレーを介して中継され、Amazon Nova 2 Sonic が会話を駆動する音声通話のフローを示しています。

図 4: Amazon Nova 2 Sonic を用いた音声通話フロー

事前準備

このソリューションには、AWS アカウントと Meta WhatsApp の設定という 2 つの領域で事前準備が必要です。デプロイを実行する前に両方を完了してください。特定の WhatsApp 値を求められるため、それらが揃うまでエージェントは応答できません。

AWS の事前準備

Amazon Nova 2 Lite（amazon.nova-2-lite-v1:0）および Amazon Nova 2 Sonic（amazon.nova-2-sonic-v1:0）へのアクセス権限が、デプロイ先のリージョンで有効になっているアクティブな AWS アカウントが必要です。

AWS CDK スタックのデプロイと、このソリューションで使用するリソース（AgentCore ランタイム、ゲートウェイ、メモリなど）の作成には、適切な IAM ユーザーまたはロールの権限が必要です。ローカルマシンでは、Node.js 24.x 以降、認証情報を設定した AWS CLI 2.x、および git をインストールしてください。

最後に、ターゲットのアカウントとリージョンで AWS CDK をブートストラップします（npx cdk bootstrap aws:///）。

エージェントコンテナは ARM64 対応の AWS CodeBuild 内で構築されるため、ローカル環境に Python や Docker、音声処理ツールチェーンをインストールする必要はありません。デプロイ先には、Amazon Nova 2 Lite、Amazon Nova 2 Sonic、AgentCore のランタイム、ゲートウェイ、メモリ機能がすべて利用可能な AWS リージョンを選択してください。まずは US East (N. Virginia) リージョン（us-east-1）から始めるのがおすすめです。

リージョンごとのモデル利用状況については、Amazon Bedrock の AWS リージョン別サポートモデル を参照してください。

WhatsApp Business Platform (Meta) の事前準備

WhatsApp 側の設定は、このチュートリアルの手順の一部ではなく、事前に完了しておくべき前提条件です。AWS API で Meta アプリを自動作成することはできないため、まずこちらの手順を完了させ、必要な値を手元に用意してからデプロイを開始してください。

デモ用途であれば、追加費用なしで利用可能な Meta のサンドボックステスト番号で十分です。事業所の認証や本番用の電話番号は必要ありません。詳細な手順については、以下のセクションでリンクしている Meta 公式ドキュメントをご覧ください。

デプロイ前に、以下の項目を準備してください。

• WhatsApp プロダクトを追加した Meta Developer App を作成し、ビジネスポートフォリオに紐付けます。この操作により、WhatsApp Business Account (WABA) とサンドボックステスト番号が追加費用なしで発行されます。詳細は Cloud API の始め方 を参照してください。

• App ID と App Secret です。App Secret は、Meta が各 Webhook に署名するために使用する鍵であり、Webhook 用の Lambda 関数がその署名を再計算する際に必要になります。

アクセストークンが必要です。一時的なトークンは簡易テスト用として利用でき、約 24 時間で期限切れとなります。より長期間使用する場合は、whatsapp_business_messaging および whatsapp_business_management のスコープを付与した システムユーザーのトークン を作成してください。

ビジネスポートフォリオ ID も必要です。セットアップ CLI により、電話番号 ID や WABA ID は自動的に検出されます。

検証トークンは任意で設定する文字列です。これは一度限りの Webhook 検証ハンドシェイク の際に Meta が返す値として利用されます。

音声通話を利用する場合は、その電話番号に WhatsApp Calling API を有効化しておく必要があります。

これらの情報はソース管理システムには保存しないでください。アクセストークン、アプリシークレット、検証トークンは機密情報であり、デプロイ時には AWS Secrets Manager に格納し、CDK テンプレートには含めないようにしてください。

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

完全なソリューションは、GitHub のサンプルリポジトリ にあります。このリポジトリには 3 つのエージェントコンテナが含まれています。