本記事は 2026 年 9 月 17 日 に公開された「 Free Sandbox Environments for Amazon Connect Customer on AWS Builder Center 」を翻訳したものです。 はじめに Amazon Connect Customer の ワークショップ が、 AWS Builder Center の 無料サンドボックス環境 で利用できるようになりました。AWS アカウント・クレジットカード不要で、予期しない請求なく、あらゆる顧客接点で優れたカスタマーエクスペリエンスを実現するエージェンティック AI ソリューションの構築をハンズオンで体験できます。AI を活用したカスタマーエクスペリエンスを試したい開発者、コンタクトセンターソリューションを評価する IT リーダー、Amazon Connect Customer に関心のあるビルダー、どなたでもサンドボックス環境ですぐに始められます。 なぜ重要なのか Amazon Connect Customer は、あらゆる規模の企業が優れたカスタマーエクスペリエンスを提供するために使用するクラウドコンタクトセンターサービスです。これまで、ワークショップで Amazon Connect Customer を試すには、自分の AWS アカウントと支払い方法の設定が必要でした。この要件が、多くのビルダーにとって最初の障壁となっていました。 2025 年 11 月に Builder Center でワークショップが公開されて以来、2026 年 8 月時点で 167,000 回以上のページビューと 12,200 人以上のビルダーによるワークショップの閲覧があり、ハンズオン学習への明確なニーズが確認できました。しかし、多くのビルダーはアカウントのセットアップで離脱しています。AWS アカウントを持っていない、支払い方法を登録できない、セットアップの手間であきらめるなどの理由です。 Builder Center の無料サンドボックス環境により、この障壁がなくなりました。事前にプロビジョニングされた実際の AWS 環境で、コンタクトフローの構築やエージェントルーティングの設定などを試すことができます。 使い方 数回のクリックで始められます。 対象ワークショップを探す — AWS Builder Center にアクセスし、サンドボックスバッジが付いた Amazon Connect Customer ワークショップを探します。 サンドボックスをリクエストする — ワークショップカードの「無料サンドボックス環境をリクエスト」を選択します。アカウント作成も支払い情報も不要です。 構築を始める — 事前にプロビジョニングされた AWS 環境が 15 分以内に準備されます。8 時間、ハンズオンを利用できます。 自動クリーンアップ — セッション終了後、環境とすべてのリソースが自動的に削除されます。手動でのクリーンアップは不要です。 注意 : 同時に利用できるサンドボックスは 1 つまでで、リクエストは週 1 回 (毎週日曜日にリセット) です。 図: AWS Builder Center の Amazon Connect ワークショップで表示される「Request free sandbox environment (無料サンドボックス環境をリクエスト)」ボタン。 構築できるもの Amazon Connect Customer のサンドボックスワークショップでは、以下のような実践的なシナリオを体験できます。 コンタクトセンターのセットアップ — Amazon Connect Customer インスタンスの作成、電話番号の取得、営業時間の設定を行います コンタクトフロー の構築 — ドラッグ & ドロップのフローブロックで IVR (自動音声応答) エクスペリエンスを設計します AI によるセルフサービスの追加 — Amazon Lex チャットボットを統合し、自然言語によるインタラクションを実現します ルーティングの設定 — キュー、ルーティングプロファイル、エージェント割り当てを設定します 分析の有効化 — 会話分析機能でリアルタイム分析や通話後分析を確認します 各ワークショップはセルフペースで進められ、ファシリテーターなしで完了できる設計になっているため、自分のスケジュールに合わせて学習できます。 対象ユーザー ビルダーや開発者 — AWS アカウントなしで Amazon Connect Customer を実践的に体験したい方 ソリューションアーキテクト — 組織向けのコンタクトセンターアーキテクチャを評価している方 IT 意思決定者 — 導入の計画前に Amazon Connect Customer の実際の動作を確認したい方 学生やキャリアチェンジを目指す方 — 費用負担ゼロでクラウドスキルを習得したい方 セキュアな設計: 安心して体験 サンドボックス環境はサンドボックスレベルの権限で実行されます。ワークショップを完了するのに十分なアクセス権がありながら、セキュリティを損なう操作や過剰なコストが発生する操作は防止されます。各サンドボックスには以下の特徴があります。 時間制限あり — 8 時間のセッション後、自動的に削除されます 分離された環境 — サンドボックスは専用の環境であり、他の環境に影響しません。本番の AWS サービスやアカウントへの接続はありません コスト管理 — 引き下げられたサービス制限により、コストが予算内に収められています 安全性 — すべてのワークショップは、サンドボックス有効化の前にセキュリティスキャンを通過しています 一時的 — セッション中に作成されたすべてのデータは、サンドボックスの削除時に自動的に消去されます 今すぐ始めましょう AI を活用したコンタクトセンターの構築を始めましょう。 AWS Builder Center Workshops にアクセスし、 サンドボックスバッジ が付いた Amazon Connect Customer ワークショップを探してください。ワンクリックで無料のハンズオン学習をすぐに始められます。 AWS アカウント、クレジットカード、コストは一切不要です。すぐに構築を始められます。 関連リソース Amazon Connect Customer — 製品ページ AWS Builder Center Introducing Sandbox Environments on AWS Builder Center AWS Builder Center のサンドボックス環境は一部のワークショップで利用でき、対象は随時拡大されています。最新の対象ワークショップは builder.aws.com でご確認ください。 著者について Abhishek Pandey は、テキサス州ヒューストンを拠点とする Amazon Web Services のワールドワイドテックリーダーです。業界を問わずビジネスイノベーションを推進するクリエイティブなソリューションの設計に情熱を注いでおり、Amazon Connect および Applied AI ポートフォリオ全般を活用したエージェンティックなカスタマーエクスペリエンスソリューションの設計・実装を専門としています。AWS 全体の技術力向上を推進するプログラムを主導し、re:Invent のコンテンツリーダーおよびスピーカーとして AWS の主要イベントに貢献しています。 Ekta Vasa は、カリフォルニア州サンフランシスコを拠点とする AWS ワールドワイドパブリックセクターチームのシニアソリューションアーキテクトです。IT 分野で 10 年以上の経験とソフトウェアエンジニアリングのバックグラウンドを持ち、カリフォルニア州政府機関のクラウドモダナイゼーションを支援しています。支援範囲は、コンタクトセンターの変革、マイグレーション、生成 AI、データ分析、ハイブリッドネットワーキングなど多岐にわたります。Amazon Connect および AWS エコシステム全般を活用した AI 搭載コンタクトセンターソリューションの実装に専門知識を持っています。Ekta は、お客様が AWS クラウド上でセキュアかつスケーラブルでコスト効率の高いソリューションを構築できるよう支援することに情熱を注いでいます。 Vijay Chauhan は、イギリス・ロンドンを拠点とする AWS Applied AI のシニアワールドワイドソリューションアーキテクトです。コンタクトセンターの変革、AI を活用したカスタマーエクスペリエンス、エンタープライズ CX アーキテクチャに深い専門知識を持ち、EMEA の大手金融サービス企業が Amazon Connect を活用したインテリジェントな顧客エンゲージメントソリューションを設計・実装できるよう支援しています。Vijay は、クラウドネイティブな CX の適用範囲を従来のテレフォニーを超えて、エージェンティック 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 」を翻訳したものです。この記事はソリューションアーキテクトの夏堀京司が翻訳しました。

はじめに この記事は、BASEテックブログ夏のブログリレー11日目の記事です。 BASE Dept. Product Divにてバックエンドエンジニアをしている オリバ です。 ショップオーナーの発送領域を担当しており、バックエンドを中心に、フロントエンドやNew Relicなども触っています。 2026年5月、担当する「送り状一括印刷 App」の一部機能をリリースしました。しかし、リリース後に分かったのは、想定していた使われ方をされていないということでした。機能自体は動いていますが、開発チームが想定していた操作と、ショップオーナーの実際の操作が違っていました。 Appの概要や使い方は以下をご覧ください。 送り状一括印刷 App（BASE Apps） apps.thebase.com 発送作業の時間を大幅削減！「送り状一括印刷 App」の使い方解説（BASE U） baseu.jp 本記事では、顧客の声を開発の意思決定に組み込むために実践した3つの取り組みと、その効果について共有します。 顧客中心主義とは 私は仕事の中で「顧客中心主義」という考え方を心掛けています。『みんなでアジャイル』で知った言葉です。 この本では、組織全体でアジャイルを実践するための原則として、次の3つが紹介されています。 「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」 引用：みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた｜O'Reilly Japan www.oreilly.co.jp もともと私はDDDやクリーンアーキテクチャが好きで、設計に関心がありました。これらは変更容易性を高めるための手段でもあり、いわばHOWにあたります。ただ、HOWをいくら磨いても、何を作るかというWHATとなぜ作るのかというWHYが定まっていなければ成果にはつながりません。自分にはこのWHATが足りていないと感じ、顧客中心主義を実践しようと思いました。 とはいえ、言葉として知っていることと、日々の開発で実践できているかは別です。 なぜ顧客の声を聞きに行ったのか 以下の3点が理由です。 1. 開発チームだけではユースケースの想像に限界がある 新機能の開発時、その機能が使われるユースケースを開発チームだけで想像していました。しかし、ショップオーナーが発送作業の際にどの画面を見て、何を基準に判断しているのかは把握できていませんでした。 2. チームが向かう方向を決めるきっかけにしたかった 私は送り状一括印刷App開発のPJMを務めており、チームが向かっていく方向づけも担っています。「この機能を今すぐ開発すべきなのか、本来の趣旨から外れているから後に回すべきか」といった判断を、顧客の実態をもとに行いたいと考えました。 3. AIの導入で実装スピードが上がり、PDCAを回したかった 開発にAIを導入したことで、実装スピードが上がりました。ただし、作るスピードが上がっても、何を作るかの精度が上がらなければ効果は限定的です。リリース後の反応を早く拾い、次の改善につなげるサイクルを回したいと考えました。 実践① ユーザーインタビューに同席する PdM・デザイナーが実施するショップオーナーへのユーザーインタビューに、3〜4回同席しました。聞くだけではなく、私からもいくつか質問をしています。 想定していた動線と実際の動線が異なっていた 送り状一括印刷 Appでは、お届け先住所の初期値に購入者がカートで入力した住所情報が、送り主情報の初期値にAppの設定画面で登録した住所情報が設定されます。個別に変更したい場合は、注文画面の送り状印刷アイコンからモーダルを開いて変更できます。 しかしインタビューでは、このモーダルの存在に気づいてもらえておらず、「お届け先住所と送り主情報の初期値は変更できない」と認知されていることが分かりました。 注文画面の送り状印刷アイコン（2026年9月時点） 送り状印刷アイコンから開く「送り状内容」モーダル（2026年9月時点） 発送通知の失敗が把握しづらく、独自運用で補われていた 発送通知に失敗しても、ショップ側で後から把握しづらい状態になっていました。そのため、注文メモなどを使った独自運用で補っているケースがありました。 エラーの有無だけでなく、対象の注文・失敗理由・次に取るべき行動を後から確認できる必要があると考えています。 注文画面が発送判断の中心的な画面になっている インタビューを通じて、注文画面がショップの梱包・発送を判断するための中心的な作業画面になっていることが分かりました。メンバーシップ特典など、発送判断に必要な情報は注文画面上で確認・検索できるとよいと考えています。 発送判断の中心となる注文画面（2026年9月時点） 細かな改善でも現場の制約を解消できる 問い合わせで挙がっていた要望をもとに、送り状一括印刷 Appで印刷位置を指定できるようにしました。その後のユーザーインタビューでは、この改善についてショップオーナーから感謝の声をいただきました。大きな機能追加ではなくても、現場の制約を解消する改善には実用的な価値があると感じました。 同席して分かったこと 開発者には自明なアイコンや操作でも、初めて使うショップには意図が伝わらない場合がある UIだけでなく、ツールチップや画像付きヘルプなども含めて使い方を伝える必要がある ショップオーナーの利用実態や反応を直接知ることが、開発の目的と価値の再認識につながる 実践② 問い合わせ内容を定期的に確認する BASEのショップ管理画面には問い合わせフォームがあります。このショップオーナーから寄せられた問い合わせを、定期的に確認するようにしました。 開発中・リリース直後の機能は週に数回確認する 開発中の機能やリリースしたばかりの機能については、週に数回確認しています。ユーザーインタビューと違って日程調整が不要なため、リリース直後の反応をすぐに拾えます。 SLI/SLO振り返り会のアジェンダに組み込む 個人が気の向いたときに見るだけでは、見る人と見ない人が分かれ、チームの判断材料になりません。そこで、Order Sectionで月1回実施しているサービスレベル（SLI/SLO）振り返り会のアジェンダに、顧客の声を確認する時間を組み込みました。 SLI/SLOの数値は、システムがどれだけ安定して動いているかを示します。しかし、その数値が顧客にとって十分かどうかは、数値だけでは分かりません。同じ場で顧客の声を扱うことで、指標と実態を突き合わせて話せることを狙っています。 見つけた声はSlackでチームに共有する 送り状一括印刷 Appについては、PdMと私が問い合わせ内容を見て、気になった声をSlackでチームメンバーに共有しています。現状はこの形で回っており、メンバー全員がDBを見に行く状態にはなっていません。 実践して分かったこと 送り状一括印刷 Appにおいて、想定した使い方がされていないことをすぐに認知でき、改修からリリースまでのサイクルを短く回せた。アジャイルの利点が出た部分だと感じている SLI/SLOのエラーバジェットの数値が安定していても、ショップオーナーの希望を満たせているとは限らないことが分かった 実践③ CXチームにヒアリングする CXチームは、ショップオーナーと継続的にコミュニケーションを取りながら、ショップ運営の課題解決や「BASE」の活用を支援するチームです。このCXチームにMTGの時間をもらい、ヒアリングをしました。 非機能要件の課題を見つける目的で声をかけた CXチームが担当するショップオーナーの中には、規模の大きいショップも多く含まれます。注文・発送領域のパフォーマンスなど、非機能要件の課題を見つけられるのではないかと考え、声をかけました。 実践①のユーザーインタビューや、実践②の問い合わせ内容で拾えるのは、使い方や機能に関する内容が中心です。一方で、表示速度のような非機能要件の話は、問い合わせとして上がってこないこともあります。 開発チームからは見えていなかった課題を把握できた ヒアリングを通じて、開発チームからは見えていなかった非機能要件の課題を把握できました。具体的な内容はここでは割愛しますが、実践②で書いたとおり、SLI/SLOを見ているだけでは気づけない内容でした。 単発のMTGから継続的なやり取りへ ヒアリングのMTG自体は一度だけですが、その後もCXチームとのやり取りは続いています。 実践して分かったこと 非機能要件の課題は、ショップオーナーと日常的に接しているチームのほうが実態を把握している場合がある エンジニアから他部署に声をかけることで、一度のヒアリングだけでなく継続的な相談先ができる 何が変わったか 改善タスクの起票数が増えた Order Sectionには複数チームがあり、私が所属するチームでは、注文画面や発送領域に関する改善タスクの起票数は、以下のように変化しました。 2〜6月：月2〜4件 7月以降：月7〜8件 7月ごろにユーザーインタビューを実施し、そこで得た内容をもとに課題の洗い出しから起票、実装、リリースまでを行いました。顧客の声を聞くことで、これまで見えていなかった課題が可視化され、タスクとして起票できるようになったことが大きいと考えています。 エンジニアから提案してタスク化する場面が増えた これまでは、Bizチームや顧客問い合わせの多さを鑑みて、別部署から依頼された案件をタスク化していくことが多かったです。顧客の声を直接知るようになってからは、エンジニアからPdMやデザイナーに提案し、タスク化して改善につなげる場面が増えました。 職種を越境して、主体的に改善タスクを推進できるようになったことが、今回の一番大きな変化だと感じています。顧客の声が、何を作るかを決める際の材料として開発の意思決定に入るようになった、とも言えます。 うまくいかなかったこと 課題が可視化され、AIによって実装も速くなっていたため、タスクを並列で進めようとしてしまいました。結果、自身が疲弊しました。 顧客の声を聞くと、改善すべきことは確実に増えます。実装スピードが上がったことで、「やれるはず」と思ってしまったのも原因だと考えています。声を集める仕組みだけでなく、集まったものを絞る側の判断も必要だと感じています。 これからやりたいこと BASEコミュニティ Meetupに参加する 弊社ではショップオーナー向けのコミュニティポータルを運営しており、その一つの取り組みとしてBASEコミュニティ Meetupを開催しています。 BASEコミュニティポータル community.thebase.com 前回はこちら：BASEコミュニティ Meetup vol.15 大阪（2026年8月開催） community.thebase.com 今後は運営側としてこの場に関わり、ショップオーナーの声を直接聞いて発送領域の改善につなげていきたいです。 非機能要件の課題をもっと洗い出す CXチームへのヒアリングで、非機能要件の課題は開発チームから見えにくいことが分かりました。機能要件だけでなく、非機能要件の課題を洗い出して改善していきたいと考えています。 おわりに 本記事では、顧客中心主義を開発の意思決定に組み込むために実践した3つの取り組みを紹介しました。 開発チームの中だけで顧客の使い方を想像していた状態から、顧客の実態をもとに改善を提案できる状態に変わりました。ただし、可視化できてきたのは機能要件に関する要望が中心です。非機能要件の課題はまだ隠れているものが多く、これをどう見つけていくかが今後の課題です。 弊社では、顧客の声をもとにプロダクトを改善していくことに関心のあるエンジニアを積極採用しています。興味を持っていただけたら、ぜひ下記からご応募ください！ binc.jp 明日は、BASEテックブログ夏のブログリレーのラストを飾る、rerenoteさんの記事です。お楽しみに！