2026年10月5日、AWSはリアルタイムな音声対話向けモデルである「Nova 2.5 Sonic」の一般提供開始を発表しました。発表によると、今回のリリースでは推論能力や指示への追従性、外部ツールを呼び出す精度が改善され、低遅延化によってより自然な対話が可能になったと説明されています。提供地域には、米国や欧州のリージョンに加えて東京リージョン（アジアパシフィック）も含まれます。

この発表の中で、顧客対応の具体的な用途例として挙げられているのが、エージェントが会話を続けながら「注文の照会」「返品条件の確認」「返品手続きの開始」を行うというシナリオです。ただし、これは提供元がモデルの活用イメージとして示した例であり、特定の企業での導入実績や運用の完了を報告したものではありません。電話や音声窓口での問い合わせ対応を自動化・省力化したい企業にとって、このシナリオを自社の業務へ落とし込むにはどのようなステップが必要になるかを整理してみます。

音声理解・生成の統合とツール呼び出しの役割

音声対話システムを構築する際、音声をテキストに変換し、大規模言語モデルで回答文を生成し、それを音声合成で読み上げるという多段階の構成をとる手法が考えられます。これに対し、AWSのモデル紹介ページであるAmazon Nova foundation modelsの説明によると、Nova 2.5 Sonicは音声の理解と生成を統合したモデルという位置づけです。また、今回の一般提供の告知では、同一セッション内での音声とテキストの併用や、非同期でのツール呼び出しに対応している点が引き継がれた特徴として挙げられています。

音声とテキストを同じセッションで扱える点は、実務において重要です。たとえば、音声対話だけで桁数の多い注文番号や英数字の混ざった型番を誤りなく聞き取るのは、難易度が高い場面もあります。画面やメッセージでのテキスト入力、あるいはチャットでの確認を併用できれば、聞き間違いによる手戻りを防ぎやすくなります。

一方で、モデルの役割は会話の音声理解と応答生成を行い、必要に応じてツールの呼び出しを判断することです。最新の注文状況を確認したり、返品の受付データを登録したりといった業務データの管理は社内システム側が担うため、実際の処理を進めるには自社の受注管理システムやデータベースとの連携が不可欠です。

Bedrock経由のリクエストと既存受注管理への接続

公式ドキュメントのWhat is Amazon Nova 2?では、Novaモデル全般の基本構成として、アプリケーションが入力と設定パラメータをAmazon Bedrockへ送信し、設定に応じて推論が適用された応答を受け取る流れが説明されています。なお、このドキュメントは一般的なリクエストと応答の構成を示したものであり、Nova 2.5 Sonic固有の音声接続手順を確定するものではありません。

この基本構成を前提にすると、音声窓口から既存の業務システムへつなぐ構造は大きく2つの処理に分かれます。一つは「データの照会（読み取り）」であり、もう一つは「データの更新（書き込み）」です。

AWSが示した用途例をもとに検討用の仮定例を考えると、注文照会や返品条件の確認は読み取り処理にあたる工程です。顧客から伝えられた注文番号をもとに既存システムのAPIを呼び出し、購入日や配送状況などの必要な情報を取得してモデルへ渡す流れが想定されます。返品条件の合致判定をモデル側で行うか、接続先システムの規程判定ロジックで行うかは業務設計によりますが、いずれにしても外部システムのデータを書き換えない参照の工程として整理できます。

対して、返品手続きの開始は更新処理です。自社の運用手順に応じて、受注管理側のステータス変更や伝票発行といった更新作業を伴うケースが考えられます。もし顧客の言い間違いや誤認識のまま更新処理が実行されると、誤った返品受付が発生し、現場の確認作業が増えてしまいます。そのため、実際の業務設計では「読み取り」と「更新」の間にどのような確認を挟むか、例外時にどう担当者へ引き継ぐかが焦点です。

国内通販での仮定例　照会から試作し、更新と引き継ぎを設計する

では、国内の通販事業者が自社の注文問い合わせ窓口への適用を検討する場合、どのように検証を始めればよいでしょうか。なお、今回の発表資料では東京リージョンでの提供は確認できるものの、7言語の対応対象に日本語が含まれているかは事前に確認が必要です。日本語対応が確認できた場合でも、実際の認識精度や業務用語への対応、電話回線との接続方式については個別の検証が前提となります。これらを踏まえた仮定の検討例として進め方を考えます。

最初に取り組むべきなのは、担当者が日常の問い合わせで参照している注文情報の項目と、返品規程の条件を整理することです。いきなり自動受付まで作ろうとせず、まずは「照会処理」に絞った試作から始めます。検証用の注文データを用意し、音声で伝えられた番号から該当する注文を正しく取得できるか、購入日や商品カテゴリに基づく規程判断をモデルが正しく行えるかをテストする形をとります。

照会と条件判定の精度が確かめられた段階で、次のステップとして「返品受付の更新条件」と「オペレーターへの引き継ぎ条件」を設計します。たとえば、以下のような例外的な場面をあらかじめ洗い出し、どこまでをAIの案内にとどめ、どこから人間の担当者へ回すかを決めておく必要があります。

注文番号の認識に複数回失敗した場合や、開封済み・セール品など規程上自動判定が難しいケース、あるいは連携先のシステム応答がタイムアウトした際には、無理に処理を完結させず、これまでの会話履歴を添えて担当窓口へエスカレーションする設計が求められます。また、返品受付の登録を行う直前に、注文内容と注意事項を顧客に再度読み上げ、明確な同意を得てから更新APIを実行するといった安全策も検討対象になります。

業務整理から個別連携のご相談

新しい音声モデルの登場によって、顧客との自然な対話を通じて業務システムを操作するハードルは下がりつつあります。しかし、実際の業務に組み込むためには、モデルの機能選定だけでなく、既存のEC・受注管理システムが持つAPI仕様の確認や、認証・更新権限、例外処理のルール化といった業務要件の整理が欠かせません。利用するシステムの標準機能や既存の設定で対応できる範囲を確認したうえで、どこに個別の実装が必要かを見極めることが重要です。

デノフのサービス案内でもご紹介しているとおり、デノフではECサイトや社内業務システムの設計・開発から、業務の整理、AIを活用する業務の選定、ツールの導入支援までを一貫して承っています。音声対話AIを使って自社の問い合わせ対応を効率化したいとお考えの際は、どの工程から試作を始めるべきか、既存のシステムとどう連携させるかという要件の整理から、デノフへの相談窓口までお気軽にご相談ください。