Amazon Web Services ブログ
構造化されたビジネスロジックとエージェンティック AI を組み合わせ、心地よい会話体験を届ける
顧客が本来受けるべきセルフサービス体験と、その作り方
Mateo Jackson は AnyCompany Internet で顧客体験 (CX) を統括しています。この 2 四半期、彼のチームは同じ光景を見続けてきました。顧客が状況を説明しても対応できないボットがいて、次のボットに同じ説明を繰り返し、最後は保留のまま待たされた末に、何も知らない担当者と一からやり直す。カスタマーエフォートスコアは悪化し、応対時間は伸び、そして二度目の問い合わせをした顧客は離脱していきます。
Mateo は理想の姿を分かっています。通信障害、請求への異議、機器の交換といったケースを AnyCompany がどう扱うべきか、その方針と応対スクリプト、エスカレーションのルールを何年もかけて書いてきました。ツールが追いついてくれれば世界水準のセルフサービスになると信じて投資してきたのです。ただ、その蓄積を会話型 AI の体験に落とし込む手段が、半年以上の開発プロジェクトを立ち上げる以外に存在しませんでした。
それが今月変わりました。障害対応の手順書はすでに文書化されていて、システム連携も整っていたため、Mateo は火曜日に最初のエージェンティックなセルフサービス体験を構築し、水曜日に数百件の模擬通話でテストし、木曜日には初版を本番稼働させました。彼が実現した体験を紹介します。
朝 6 時 40 分、嵐で町の北側の光ファイバーが切断されました。7 時 15 分には問い合わせが入り始めます。Sofía もその 1 人でした。応答した音声は彼女を名前で呼び、アカウント番号の下 4 桁を確認し、日頃の利用に感謝を伝えます。彼女の通りでは障害が確認済みで、作業員が現場に入っており、復旧見込みは 11 時 30 分です。音声は前夜から残っている別件の問い合わせにも自ら触れ、それがまだ未解決で今回とは別の案件であることを伝えます。さらに、モデムのランプが点灯しているのか点滅しているのかを尋ねます。それによって次の対応が変わるからです。クレジットが適用され、金額と適用条件が途切れずに読み上げられます。彼女のモデムは 3 世代前のものなので、交換の対象になります。通話を続けたまま、スマートフォンに通知が届きます。3 つのルーターの選択肢が並び、それぞれの横に月額料金が表示されます。彼女は真ん中を選びます。音声はその製品名を読み上げて確認し、当日出荷になると伝えます。3 月分の請求について異議を申し立てると、規定により担当者への転送が必要です。電話を取った担当者の画面には、通信障害の状況、クレジット、彼女が選んだルーター、3 月の請求の件がすべて表示されています。Sofía は同じ説明を一度も繰り返していません。最初から最後まで、3 分と少しでした。
この会話体験を構築したのは 2 人です。Nikki Wolf は AnyCompany の Amazon Connect Customer インスタンスの管理者で、システム連携、モデルと権限の設定、会話が動く基盤を担当しています。Mateo は Sofía が耳にする内容そのものを担当しています。どちらも相手の作業を待つ必要はありませんでした。
デモは簡単だ
Sofía の通話のように聞こえるものをデモとして作るなら、半日で足ります。プロンプトをいくつか書き、ドキュメントサイトを参照させ、声を選べば、よくある質問にはそれらしく答えてくれます。しかし同時に、それは本番稼働することのないバージョンでもあります。
先ほどの通話をもう一度確認してみてください。重要だった判断のほぼすべては、モデルが決めるべきものではありませんでした。
- Sofía には未解決の問い合わせがすでにあった。AI は 2 件目を新規に開始するのか、既存の 1 件を引き継ぐべきか。
- 彼女はクレジットの対象だったが、先月も受け取っている。それは認められるのか、認められるならいくらまでか。
- 彼女はまだ本人確認を済ませていなかった。確認前に AI はどこまで話してよいのか。
- クレジットの適用条件は途中で区切らず全文を読み上げなければならない。AI が要約して伝えることは許されるのか。
- 彼女は開始 3 語で担当者を呼ぶよう頼むこともできた。AI はもう一度自力で対応を試みるべきか、即座に転送すべきか。
これらには AnyCompany としての正解があり、Mateo は何年もかけてその答えに辿り着きました。「モデルに任せる」が答えになるものは 1 つもありません。一方でモデルが担う部分、つまり Sofía の苛立ちを読み取ること、通話が切断されたことに彼女が言及したときにトーンを合わせること、4 つの異なるシステムを横断しながら自然な会話を保つことも、同じくらい重要です。しかもそれらは、厳密さと共存した状態で自然に感じられなければなりません。デモが省略するのはまさにこの部分であり、会話型 AI のプロジェクトが止まるのは技術的な理由よりも構造的な理由によります。会話は 1 つのシステムに、業務ルールは別のシステムに、実行結果はさらに別のシステムにあり、実行経路の全体を 1 つのトレースで見られる人がいません。変更のたびに、業務側の要求を各ツールが受け付ける形に誰かが翻訳する必要があります。そうして数週間が過ぎます。出てくるのは可もなく不可もない体験か、あるいは何も出てきません。
Amazon Connect Customer のエージェンティックなセルフサービスの新機能
ここから Amazon Connect Customer で何ができるようになったかを説明します。会話、業務ルール、実行結果が 1 か所にまとまり、答えを知っている人がそれを所有します。
agentic CX designer が一般提供を開始しました。ノーコードのビジュアルキャンバス上で会話を構築できます。柔軟さが求められる部分 (意図の理解、会話の進行、ナレッジの検索など) は、エージェンティック AI が担い、正確さが求められる部分 (本人確認、クレジットの適用可否、法令・規約上の説明など) は、決定論的なルールベースのステップによって厳密に管理されます。エージェンティックなステップと決定論的なステップは同じキャンバス上に並び、AI が推論する箇所とポリシーが適用される箇所を目で確認できます。
Live Sync は、音声での会話とデジタルの画面表示をリアルタイムで同期させる、初の完全統合型エンタープライズ CX テクノロジーです。チャネルを切り替える必要はありません。顧客は通話を続けたまま選択肢を確認し、操作できます。
Touchpoint はデジタルチャネルで顧客が目にする画面を描画します。Amazon Connect Customer 向けの組み込み型クライアント SDK で、自社の Web サイトやモバイルアプリに埋め込みます。同一の会話の中で Web チャット、アプリ内音声、Live Sync のマルチモーダル機能を提供し、顧客が画面で操作した内容をフローに返します。
agentic voice は会話に声を与えます。50 を超える言語と 100 種類以上の音声に対応します。1 つの音声がその場面に応じて口調を変え、人間と同じように割り込みを処理し、顧客が言語を切り替えれば会話の途中でも追随します。別途の調達や個別のシステム連携は必要ありません。
この後は、Mateo がこの体験をどう構築したのか、そして顧客が使い始めた後に何に注目すべきなのかを解説します。
構築する
障害対応のプロセスはすでに文書化されています。障害をどう確認するか、どういう場合にサービスクレジットを適用するか、機器がどの条件で交換対象になるかが書かれています。構築はその文書から始まります。初版を立ち上げるためのラベル付き学習データも、学習させるインテントモデルも必要ありません。
ペルソナから始める
Mateo はペルソナから着手します。アシスタントがどう聞こえるべきか、最初に何をすべきか、何を提示してよいか、そしてどの時点で対応を止めて人につなぐべきか。これはプロンプトの設計であり、その中身は新しくチームに加わったメンバーに渡す指示書とよく似ています。
次にモデルを選びます。キャンバス上のエージェンティックなステップごとに、Mateo はドロップダウンからモデルを選び、そのタスクに合わせて調整します。速く自然な会話が必要なステップには応答速度重視のモデルを、複数のツールをまたいで推論し複数ターンにわたる解決策を組み立てるステップには思考の深さに向いたモデルを割り当てます。同じフローの中でも部分ごとに異なるモデルを使えるので、会話のその瞬間に本当に必要な性質に合わせられます。
Amazon Connect Customer はモデル単位やトークン単位の課金ではありません (料金ページ を参照してください)。したがって考えるべきことは、どのモデルが Sofía にとって最良の体験になるかだけです。
エージェンティックな推論と決定論的な制御を組み合わせる
続いて Mateo は、解釈の余地を残せない部分に取りかかります。顧客がクレジットの対象になるか、なるとしていくらかは、判断ではありません。それはルールであり、所有者が決まっており、その所有者はモデルではありません。
そこで彼は、会話と判断を別の方式で扱うことにします。
エージェンティックなノード (Generative Journey) は会話の文脈をもとに推論し、許可されたツール群の中から選択して、動的に応答を生成します。Sofía の通話では、Generative Journey ノードが彼女の話を聞き、必要としているものを解釈し、モデムについて確認の質問をし、障害の状況を説明します。彼女の口調やアカウントの個別事情にも自然に合わせます。
決定論的なノードは、明示的な検証ルールを持つスロットを使います。agentic CX designer には日付、メールアドレス、電話番号、英数字文字列といった値に対応する組み込みスロットタイプが用意されています。値の範囲が限られる場合は、はい/いいえ、料金プランの区分、有効な PIN の短いリストなど、独自のスロットタイプも作成できます。各スロットは正規表現による検証、リトライ回数の設定、検証に失敗した場合のエスカレーション経路を明示的に指定できます。Sofía のクレジットについては、決定論的なノードが彼女のアカウントを適用条件に照らして確認し、正確な金額を返します。曖昧さはなく、通話ごとのばらつきもありません。
2 種類のノードはキャンバス上で隣り合って配置されます。両者の接続は視覚的に確認でき、キャンバスは両者をまたいで会話の状態を完全に保持します。収集したスロット、設定した変数、呼び出したツール、そして顧客が手続きのどこまで進んでいるかです。この状態は会話がエスカレーションしても引き継がれ、文脈が担当者や別の AI エージェントに一緒に渡ります。
薬剤師を思い浮かべてください。あなたは薬剤師に話を聞いてもらい、他に何を服用しているか尋ねてほしいし、声から鼻づまりに気づいてほしいと思うでしょう。一方で用量をその場の思いつきで決めてほしいとは思わないはずです。それが決定論的な制御とエージェンティック AI を組み合わせるということです。各ステップで AI にどこまで判断させるかを選べて、同じワークフローの中でいつでも変更できます。
ナレッジ: アシスタントが知っていること
Sofía がインターネットが使えない理由を尋ねたとき、アシスタントは AnyCompany の障害対応手順に基づいて答えます。モデルの学習データからではありません。ナレッジはワークスペース内に置かれ、よくある質問には Q&A エントリ、参照量の多い資料には文書のアップロードという形で管理します。アシスタントは実行時にこの承認済みのコンテンツから情報を取得します。
アクション: 実際に処理を行うシステムにつなぐ
アシスタントは Sofía のアカウントを照会し、ネットワーク運用システムから障害の状況を確認し、サービスクレジットを登録する必要があります。ここで Nikki の担当範囲になります。
agentic CX designer のデータリクエストノードが外部システムを呼び出します。一般提供の時点で 2 つの連携方式が使えます。
REST データリクエストは、アクセス可能なエンドポイントを持つ任意の API を GET / POST / PUT / DELETE で呼び出します。Nikki はアカウント照会、障害状況の確認、クレジットの登録という 3 つを設定します。それぞれについてエンドポイント、認証、リクエストのペイロード、レスポンスのマッピングを定義します。呼び出しが失敗したときの挙動、つまりリトライするのか、代替経路に進むのか、エスカレーションするのかも定義します。
MCP 経由の呼び出し (MCP egress) では、リモートの Model Context Protocol エンドポイントが公開しているツールを呼び出します。すでに AgentCore Gateway でツールを公開しているなら、管理者がワークスペースの設定で MCP エンドポイントを一度登録するだけです。Lambda のラッパーも、間に挟む API Gateway も不要で、designer が MCP プロトコルで直接ツールを呼び出します。
いずれの方式でも、API キーやトークンといった秘密情報はワークスペースに保存し、ノードごとに直接書き込むのではなく、データリクエストのヘッダーから参照します。
この役割分担が重要です。Mateo は会話の 1 ステップとしてデータリクエストを配置するだけです。何を渡し (アカウント ID)、何が返ってくるか (クレジット額、障害状況) は見えますが、エンドポイントの URL や認証の設定を知る必要はありません。Nikki は会話の設計に手を触れずに、認証情報をローテーションし、エンドポイントを変更し、レスポンスのマッピングを直せます。一度設定すれば、複数のフローやアプリケーションで再利用できます。
音声を設定する
Mateo が構築している体験は音声で顧客に提供されるため、彼は Connect Customer のフロー内で「音声の設定」(Set Voice) ブロックを使って音声ペルソナを設定します。designer は会話を組み立て、Connect Customer はどの音声を使い、どう聞こえるかを制御します。
agentic voice は話者交代をリアルタイムで処理し、顧客が訂正のために割り込んでいるのか、考えながら声に出しているだけなのかを見分けます。音声は会話の展開に応じて感情を調整し、悪い知らせを伝えるときは穏やかに、解決を確認するときは明るくなります。顧客が文の途中で言語を切り替えても、音声は間を置かずに追随し、50 を超える対応言語と 100 種類以上の音声から使い分けます。
この役割分担によって、応答速度の調整、割り込みの挙動、フェイルオーバーといった音声配信の側面は基盤の所有者が持ち、会話のロジックは CX の所有者が持つ形になります。デプロイのサイクルも権限も別です。
聞かせるだけでなく、見せる — Live Sync
聞くよりも見るほうが分かりやすいものがあります。Sofía はルーターの交換対象で、月額料金の異なる 3 機種が候補にあります。3 つの選択肢を、しかも 2 度読み上げるのは、顧客を離脱させる典型的なやり方です。
Live Sync を使うと、アシスタントが通知を送り、3 つの選択肢が Sofía のスマートフォンに表示されます。通話は続いたままです。彼女が 1 つをタップすると、会話はそのまま進み、選んだ内容が会話に反映されます。別のアプリも、「一度切って Web サイトをご覧ください」も必要ありません。音声と画面をまたいだ 1 つの連続した体験になります。
Touchpoint が画面側を描画します。Web サイトやモバイルアプリに埋め込むクライアント SDK で、同一の会話セッション内に Live Sync のマルチモーダルなカードを表示し、タップやフォームの送信といった顧客の操作をフローに返します。
文脈ごと引き継ぎ、やり直させない
人につなぐこと、あるいは別の AI エージェントにつなぐことが正しい答えである場合もあります。そのとき、会話がそれまでに確定させた内容はすべて一緒に渡ります。アカウント、確認済みの障害、クレジット、顧客が選んだルーターです。収集済みのスロット、変数、ツールの実行結果を含むキャンバスの状態が、引き継ぎ先に渡ります。顧客に一からやり直させることはありません。
キャンバスは形になりました。次に Mateo が確かめるべきなのは、正しく動くかどうかです。
テストする
テストは 2 つの層で行い、互いを補完します。
設計しながらキャンバス上でテストする
designer には 4 つのテストモードがあります。会話全体を通すアプリケーションテスト、単一フローを試すフローテスト、発話とフローの対応を確かめるルーティングテスト、そして回帰テストとして保存しておくフローロジックのテストです。4 つはいずれもターンごとのデバッガー上で動き、会話が通過した各ノードについて次の内容を確認できます。入力と出力、蓄積されていくスロットと変数の値、Generative Journey / Generative Text / Transform ノードの推論内容 (モデルが何を検討し、どのツールを選び、なぜそうしたか)、ガードレールの判定 (何が評価され、何が通過し、何が遮断されたか)、ナレッジの検索結果 (どの Q&A エントリや文書の断片が取得されたか)、そしてデータリクエストの結果 (呼び出しのペイロード、レスポンス、発動したエラー処理) です。
変更は再デプロイなしでテストチャットに即座に反映されます。フローを保存し、テストを実行し、結果を見る、という流れです。クレジットが 30 ドルではなく 15 ドルで返ってきたとき、モデルが Sofía の意図を読み違えたのか、データリクエストがアカウントシステムから誤った値を取得したのかが分かります。バグの種類が違えば、直すべき担当者も違います。
まずは決定論的なステップと会話の出口をテストしてください。クレジットの金額、規約上の説明、エスカレーションの発動条件です。間違っていたときに損失が出るのはここです。ガードレールの判定結果はターン単位で確認できるため、プロンプトインジェクションの試行や方針違反が、実際のトラフィックが体験に届く前に捕捉されていることを確かめられます。CI/CD パイプラインを運用しているチームであれば、このテスト機構をデプロイの承認ゲートの前段で会話ロジックの検証に使えます。
トラフィックを流す前に、コンタクト全体の経路をテストする
designer がテストするのは会話です。Amazon Connect Customer のテストとシミュレーション機能は、コンタクト全体の経路をテストします。通話を振り分ける Connect Customer のフロー、「音声の設定」ブロック、Agentic CX ブロックの呼び出し、そしてエスカレーション先のキューの設定までが対象です。テストは自然な文章で記述し、実際には呼び出したくない外部システムはモックに置き換え、変更のたびに再実行されるようスケジュールできます。意味的な一致で判定するため、プロンプトの言い換えによって、本来通るべきテストが落ちることはありません。
テストとシミュレーション機能は、複数の会話をまたぐエンドツーエンドのテストケースに対応します。コンタクト属性の検証、Lambda や Agentic CX の挙動の上書き、キューや営業時間の上書き、顧客としてのテキスト入力や DTMF 入力の送信ができます。2 つの機能を併用してください。設計時の会話ロジックの検証には designer のキャンバスを、デプロイ後の組み上がった体験の検証には Connect Customer のシミュレーションを使います。
公開、デプロイ、そして変更
テストが通ったら、Mateo はビルドを作成します。ビルドはその時点のすべてのフロー、アプリケーションの設定、ガードレールの割り当てを固定した、変更不可のスナップショットです。2 つのビルドを比較すると、変更されたノード、更新されたガードレールの割り当て、新たに追加された連携といった差分が分かります。管理者は、レビュー済みのビルドだけが本番に到達するよう担保できます。
ビルドをデプロイすると本番稼働します。以前のビルドは保持されるため、本番で問題が起きた場合のロールバックは 1 操作で済みます。
Connect Customer のフローは Agentic CX ブロックを通じて designer のアプリケーションを呼び出します。このブロックをつなげば、同一のビルドが音声、チャット、SMS を担います。どのチャネルになるかは Connect Customer フローのチャネル設定で決まります。電話をかけた顧客は agentic voice を通して同じ内容を聞き、チャットで入力した顧客も同じロジック、同じ決定論的なガードレール、同じ結果を得ます。1 つのビルドで、サポート対象のすべてのチャネルに対応できます。
最適化する
いま、実際の顧客が既に利用しています。分析オーバーレイは、Mateo が構築したフロー上にトラフィックと離脱率を直接表示します。つまり、同じキャンバスに数値が表示されるということです。もし発信者の 3 分の 1 が同じステップで離脱していれば、どのステップかが分かり、その場で開けます。このフィードバックの循環によって、初版が良い版になるまでの時間が数か月ではなく同じ週の中に収まります。
ガードレールはターンごとに評価され、記録されます。顧客のプロンプトが方針の境界を押している状況を検知できます。モデルの出力が決定論的なノードと矛盾した場合 (業務ルールと一致しないクレジット額など)、決定論的なノードの結果が優先されます。権限を持つのはモデルではなくフローです。
会話分析では、個々のコンタクトを 1 回のやり取りとその背後にある推論の単位まで掘り下げて把握できます。モデルがなぜその経路を選んだのか、どのナレッジを取得したのか、どこで引き継いだのかを追跡できます。パフォーマンス評価は自社の品質基準に照らしてコンタクトを採点し、人手の抜き取り確認ではなく一貫した基準で評価します。ガードレールの評価結果と監査ログはコンプライアンス関連のツールに書き出せます。すべての書き込みと削除の操作は、実行者、時刻、対象リソースとともに記録されます。
翌週に起きたこと
翌週の月曜日、Mateo が分析オーバーレイを開くと、発信者の 28% がクレジットの説明のステップで離脱していることが分かりました。いくつかの会話を聞いてみると、顧客は「利用規約」という言葉を聞いて、担当者につながるまで待たされると受け取っていたのです。
彼はそのノードのプロンプトを書き直します。「これから利用規約を読み上げます」ではなく、「お客様のクレジットの詳細をご案内します。15 秒ほどで終わります」と言わせるようにしました。保存し、キャンバス上でテストし、新しいビルドを作成して、昼までにデプロイします。
水曜日には、そのステップの離脱率が 9% まで下がっていました。体験そのものは、2 週間前の火曜日に彼が構築したものと同じです。ただ良くなったのです。顧客にいちばん近い人が、端から端まで所有しているからです。
始めましょう
障害を確認する手順、サービスクレジットの適用方針、機器が交換対象になる条件といったプロセスがすでに文書になっているなら、いちばん時間のかかる部分はもう手元にあります。
体験を所有している方は、Amazon Connect Customer のコンソール を開き、agentic CX designer で最初のアプリケーションを作成してください。セットアップの手順は 管理者ガイド で確認できます。順を追って学びたい場合は AWS Skill Builder のコースも用意されています。
プラットフォームを所有している方は、同じ 管理者ガイド で連携のパターン、REST と MCP の設定、ワークスペースの管理、ビルドとデプロイのパイプラインを確認できます。
Web の体験を追加する場合は、Touchpoint のクライアント SDK を導入して、自社の Web サイトやモバイルアプリでチャット、音声、Live Sync を提供してください。
チームで評価する場合は、ガイド付きワークショップをリクエスト してください。アーキテクチャの解説と、自社のユースケースに沿ったハンズオンでの構築を体験できます。
著者について
Alex Schrameyer (he/him) は Amazon Web Services (AWS) の Worldwide Solutions Architect Lead for Agentic Experience で、シカゴ近郊を拠点としています。優れた応対担当者の体験こそが優れたカスタマーサービスの基礎であると考え、人間の担当者と AI エージェントの双方が滞りのない顧客体験を提供できるようにするソリューションの設計に取り組んでいます。世界各地を旅するのが好きで、地元の野球場やテーマパークで見かけることがあるかもしれません。
本記事は 2026 年 9 月 2 日に公開された「Blend structured business logic with agentic AI to deliver delightful conversational experiences 」を翻訳したものです。この記事はソリューションアーキテクトの夏堀京司が翻訳しました。