- はじめに
- セッション概要
- なぜ今「AI で顧客体験の質を上げる」が中心になるのか
- 「ただの問い合わせ対応」ではない「先回りして解決する体験」
- 実現の鍵となる 5 つの要素
- 効率化のために AI を使う❌ 顧客中心で使い分ける⭕️
- まとめ
はじめに
こんにちは、アプリケーションサービス本部ディベロップメントサービス 2 課の松下です。
AWS Summit Japan 2026 にて、セッション BIZ201「AI ネイティブで実現する、妥協なき顧客体験 - Amazon Connect Customer」を聴講しました。
このセッションは、Amazon Connect Customer の機能一覧を順番に紹介するものではありませんでした。
一貫していたのは、AI を入れるかどうかではなく、AI を使って顧客体験の質をどう引き上げるかを考える、というメッセージです。
デモと後半の整理を通して見えてきたのは、AWS が Amazon Connect Customer を単なる自動応答基盤としてではなく、問い合わせの前から先回りし、文脈を理解し、解決までやりきる顧客接点の土台として位置付けていることでした。
この記事では、特に次の 3 点に絞ってまとめます。
- なぜこのセッションが「AI で顧客体験の質を上げる」を中心に据えていたのか
- デモで AWS が何を主張したかったのか
- その体験を Amazon Connect Customer でどう支えるのか
セッション概要
| 項目 | 内容 |
|---|---|
| セッションコード | BIZ201 |
| セッション名 | AI ネイティブで実現する、妥協なき顧客体験 - Amazon Connect Customer |
| 登壇者 | 坂田 陽一郎 氏 |
| 所属 | アマゾン ウェブサービス ジャパン合同会社 |
セッション冒頭では、Amazon Connect Customer の個別機能を深く扱うのではなく、AI ネイティブな顧客体験の全体像をつかんでもらうことが目的だと明示されていました。
そのため、細かな設定方法や画面操作よりも、「これから顧客体験をどう設計すべきか」という設計思想の共有に重心が置かれていた印象です。
なぜ今「AI で顧客体験の質を上げる」が中心になるのか
セッション前半で登壇者がまず置いていた前提は、多くの企業がすでに顧客対応へ AI 投資を始めているということでした。
チャットボット、音声ボット、オペレーター支援など、形は違っても「AI を使うかどうか」の議論自体は、すでに次の段階に進んでいるという整理です。
その上で問題として挙げられていたのが、これまでのコンタクトセンターが抱えてきた「顧客体験の質」と「コスト」のトレードオフです。
質を上げようとすると人員や時間が必要になり、コストを下げようとすると、できるだけ安価なチャネルへ誘導したくなります。
その結果として重視されてきたのが Deflection でした。
ここでいう Deflection は、問い合わせを Web やボットに逃がし、電話や有人サポートから遠ざける考え方です。
もちろん企業側には合理性がありますが、顧客から見ると「問題が解決されないまま、次の窓口へ回される」体験になりがちです。
この指摘はかなり本質的だと感じました。
現場のオペレーター品質が高かったとしても、そこにたどり着くまでに疲れ切ってしまえば、顧客体験全体では負けてしまうためです。
実際、Web を見ても解決せず、チャットでも解決せず、電話しても待たされる、という流れは珍しくありません。
そこで AWS が示していたのが、AI ネイティブな顧客体験では、そもそもこの妥協を前提にしなくてよい、という考え方でした。
スライドでは次の 3 つが要点として整理されていました。
- すべてのインタラクションを質の高いものにする
- 誰も取り残さず、あらゆるチャネルで問題を即座に解決する
- 顧客ごとの状況に合わせてパーソナライズする
重要なのは、ここでの主語が「AI」ではなく顧客体験であることです。
AWS の語り口は、「AI でどこまで自動化できるか」ではなく、「顧客にもっとまっすぐ向き合うために AI をどう使うか」に徹していました。
つまり、このセッションの論理は次の順番で説明できます。
- 従来の顧客対応は、トレードオフの結果として
Deflectionに寄りがちだった - しかし、その構造は顧客体験全体を悪化させる
- AI ネイティブな設計なら、質と規模を両立しながらその妥協を崩せる
- その具体像を Amazon Connect Customer で示す
この順番がはっきりしていたので、単なる「生成 AI 活用事例」よりも、メッセージの芯が通ったセッションになっていたのだと思います。
「ただの問い合わせ対応」ではない「先回りして解決する体験」
中盤のデモは、海外出張中の宿泊客がフライト欠航に遭遇する、というシナリオでした。
全体像としては次のような流れです。
一見するとホテルの延泊手続きデモですが、実際に見せたかったのはもっと広い話です。
従来の「困った顧客が問い合わせてくるのを待つ」モデルから、状況を先に把握し、適切なチャネルで、必要な操作まで含めて解決するモデルへ変わる、という主張でした。
欠航を検知し、問い合わせ前にホテル側から提案
最初の転換点は、顧客がフロントに連絡する前に、ホテル側から延泊支援を提案していたことです。
ここで重要なのは、AI が単に会話するだけでなく、予約情報と運航情報を組み合わせて顧客の困りごとを推定していることです。
顧客が「困っています」と自己申告する前に、必要になりそうな支援を提案する。
この時点で、問い合わせチャネルの役割が「受付窓口」から「解決の実行点」に変わっています。
会話の冒頭から、前提情報が共有済み
次に印象的だったのが、AI コンシェルジュが最初に「ご用件は何でしょうか」と聞かなかったことです。
フライト欠航、振替便が空席待ちであること、現在の部屋は延泊できないことを前提に、いきなり本題に入っていました。
ここでは Agentic Voice による自然な音声対話も印象的でしたが、それ以上に大きいのは、会話の出発点が意図分類ではなく状況理解になっていることです。
顧客は一から事情説明をせずに済み、AI は不確定な状況に対して「金曜日チェックアウトを勧める」「早めに出発するなら未使用分は請求しない」といった提案までおこなっていました。
音声とアプリを同期させ、顧客の操作負荷を減らす
その後、顧客が「オーシャンビュールームの詳細を見せてもらえますか」と話すと、アプリの画面が自動的に切り替わります。
アプリ画面が自動遷移するマルチモーダル体験
この部分で紹介されていたのが、ノーコードで体験を構築する Agentic CX Designerと、会話とアプリの状態を同期させる Live Sync です。
従来なら、顧客は通話しながら画面を探すか、AI が長い説明を読み上げる必要があった一方、このデモでは、会話を続けながら、必要な情報だけを適切な UI に渡すことで、音声と画面を補完関係にしていました。
ここは単なるマルチチャネルではなく、チャネルをまたいでも体験が分断されない、という意味でかなり大きな違いだと思います。
返答だけで終わらず、予約確定まで完了
さらにデモ後半では、AI が部屋変更の提案を受けて確認フローへ進み、会員ランクや状況に応じてホテルクレジットまで自動適用していました。
最終的には、確認 SMS の送信まで含めて予約完了です。
顧客がギフトショップの場所を尋ねる割り込み質問を入れる
ここでの主張は明快で、良い AI は答えるだけではなく、解決まで完了させるということです。
FAQ を返すだけなら従来型ボットでもできますが、本人の状況に合わせて条件を判断し、特典を適用し、処理を実行するところまで踏み込むと、初めて「親身に対応された」と感じる体験になります。
加えて、途中で「ギフトショップの場所はどこですか？」と横道の質問が入っても、AI は脱線せずに答えた上で元の予約フローへ戻っていました。
これも、単発の応答ではなく、会話全体の状態を保ちながら進行していることを示しています。
右）予約完了と SMS による確認送信まで完了
このデモを通して AWS が伝えたかったのは、次の 3 点に集約できそうです。
- 顧客対応は「問い合わせが来てから始まる」とは限らない
- 良い体験は、最初の一言の前にどれだけ文脈をそろえられるかで決まる
- AI の価値は応答品質だけではなく、チャネル横断で解決まで完了できるかにある
つまり、ここで描かれていたのは「ボイスボットの進化版」ではなく、優秀なコンシェルジュのような体験を、より広い顧客接点へスケールさせる構想でした。
実現の鍵となる 5 つの要素
デモの後、登壇者は Amazon Connect Customer を支える考え方を 5 つの要素に整理していました。
中心に Act があり、それを Know、Design、Evolve が支え、全体の土台として Trust がある、という構図です。
この整理の良いところは、AI の性能だけを語っていない点です。
会話がどれほど自然であっても、顧客理解が弱い、体験を素早く作れない、改善ループが回らない、安全に運用できない、となれば本番では厳しいです。
以下、それぞれが Amazon Connect Customer でどう実現されるのか、セッション内容に沿って見ていきます。
Act: 顧客のあらゆる場面に対応する
Act は 5 要素の中心に置かれていました。
意味しているのは、顧客の質問に答えることではなく、顧客の問題を理解し、行動し、解決する AIです。
セッションでは、顧客は同じ説明を何度も繰り返したくないし、そのチャネルで解決してほしい、と繰り返し語られていました。
Amazon Connect Customer は、この Act を実現するために、音声、チャット、アプリなど複数チャネルで 1 つの AI を一貫して使える、という立て付けを取っています。
そのため、単に「部屋は空いています」と答えるだけでなく、次のような流れまで含めて実行対象にできます。
- 本人確認をおこなう
- 文脈に応じた情報を提示する
- 部屋変更や予約更新などの手続きを実行する
- 必要なら先回りして提案する
デモで見せた延泊提案、部屋変更、クレジット適用、確認 SMS 送信は、まさに Act の具体例です。
回答で終わらせず、処理完了まで持っていくことが、ここでの差分でした。
Know: すべての顧客を深く理解する
Know は、顧客理解を 1 つのプロフィールに統合する、という考え方です。
会話の途中で毎回情報を集め直すのではなく、あらゆる顧客接点で使える最新の統合プロフィールを前提にすることが求められていました。
セッションでは、顧客データはすでに企業の中にたくさんあるが、散在しているため AI から使いにくい、という話がありました。
Amazon Connect Customer は、そうした CRM、ナレッジベース、過去の問い合わせ履歴、業務システム上の情報を、AI がすぐに引ける形で扱えるようにする、という位置付けです。
ここで重要なのは、Know が単なる参照用データベースではないことです。
プロフィールがリアルタイムで更新され、そこからパーソナライズされた応答やプロアクティブなアクションに接続できるところまで含めて Know だと説明されていました。
フライト欠航を受けてホテル側が先回りできたのも、予約情報と運航情報を結び付けて、顧客の状態変化を把握していたからです。
知るだけで終わらず、次の行動につなげることが Know の価値なのだと思います。
Design: 価値ある体験を素早く構築する
Design は、こうした体験を「数か月かけて大規模開発するもの」から、「数日から数週間で試し始められるもの」へ変える要素として語られていました。
Amazon Connect Customer では、ドラッグ＆ドロップ中心で AI 体験を構築でき、細かな制御が必要な場合だけコードを組み合わせることができます。
さらに、エージェンティック AI、決定論的ワークフロー、プロアクティブなアウトバウンドキャンペーンなど、主要なユースケースはあらかじめ用意されている、という説明でした。
ここが現実的だと感じたのは、既存資産の置き換えを前提にしていなかったことです。
CRM やナレッジベースをすべて移行するのではなく、すでにあるシステムを活かしたまま接続できる。
つまり、体験を変えるためにシステム全体を作り直す必要はない、ということです。
デモで登場した Agentic CX Designer や Live Sync も、この Design の文脈にあります。
複雑な体験を素早く組み立てられるからこそ、顧客接点の再設計を繰り返し試せるわけです。
Evolve: すべての体験を向上し続ける
Evolve は、生成 AI を本番で使うなら特に重要な要素です。
セッションでは、AI エージェントも人間のオペレーターと同じように、モニタリングし、評価し、改善し続けなければならないと説明されていました。
Amazon Connect Customer で強調されていたのは、次の 3 点です。
- AI が処理したすべての顧客インタラクションを 100 % 評価できる
- リリース前に数千件規模の AI インタラクションをシミュレーションできる
- 本番開始後もダッシュボードやリアルタイム分析で改善点を追える
ここでのポイントは、生成 AI の導入を「作って終わり」にしないことです。
少しの条件差で振る舞いが変わる以上、テスト、評価、改善のループがなければ品質は安定しません。
Evolve は、AI を運用可能な顧客接点にするための仕組みとしてかなり重要だと感じました。
Trust: すべてを支える土台
最後の Trust は、5 要素の中でも土台として扱われていました。
AI が自律的に判断し、顧客データへアクセスし、返金や予約変更のような処理まで触るなら、安全性、統制、説明可能性が最優先になるのは当然です。
セッションで挙げられていたのは、次のようなポイントです。
- PCI DSS など各種認証やコンプライアンス対応
- PII マスキング、暗号化、有害コンテンツを止めるガードレール
- リスクが高い処理に対して決定論的な制御を組み合わせる仕組み
- どの判断でどの処理をしたかを追える説明可能性
- AI の回答が根拠から外れていないかを最大 99 % の精度で検出する仕組み
ここでの AWS の立場は明快で、生成 AI に全部を任せるのではなく、任せる部分と厳密に制御する部分を選べるようにするというものです。
エンタープライズ利用を考えると、この Trust が後付けではなく、最初から設計の一部になっている点は大きいと思いました。
効率化のために AI を使う❌ 顧客中心で使い分ける⭕️
セッション終盤では、AI ネイティブを「100 % AI 化」と同義にしないことも強調されていました。
スライドでは、100 % エージェンティック から 100 % 人間 までを連続的に捉え、その間に決定論的な AI や AI アシストを置いていました。
つまり、価値があるのは一律の自動化ではなく、顧客体験を良くするために最適な配分を選べることだというわけです。
これはかなり重要な整理です。
AI の話になると、つい「どこまで人を減らせるか」に引っ張られがちです。
しかし AWS の主張は逆で、人を排除することではなく、人と AI の組み合わせを顧客中心で再設計することにありました。
高リスクで厳密性が必要な処理は決定論的に制御する。
複雑で感情的な対応は人が担う。その一方で、事前整理、要約、推奨、ルーティング、簡単な手続き実行は AI に任せる。
Amazon Connect Customer は、その間の設計自由度を持たせるための基盤として描かれていたように思います。
だからこそ、このセッションのタイトルにある「妥協なき顧客体験」という表現が効いていました。
効率化は結果として得られるかもしれませんが、出発点はあくまで顧客中心です。
まとめ
このセッションを一言でまとめるなら、「AI を導入するか」ではなく「AI を使って、顧客体験の質をどう引き上げるか」を考えるセッションでした。
特に印象に残ったのは、次の 3 点です。
Deflectionの延長で AI を考えるのではなく、顧客体験の妥協そのものを無くすこと- デモが示していたのは、問い合わせ応答ではなく、文脈理解とチャネル連携による先回り型の解決であること
Act / Know / Design / Evolve / Trustをそろえて初めて、AI は本番の顧客接点として成立すること
Amazon Connect Customer の個別機能を詳しく知りたい場合は、別セッションや公式ドキュメントを見た方がよいかもしれません。
一方で、AI で顧客体験をどう再設計するかという観点を整理する入り口として、とてもよくまとまったセッションであったと感じています。
コンタクトセンターやカスタマーサポートの改善を考えている場合、「どこを自動化するか」より先に、「どの瞬間で顧客を疲れさせているのか」「どこまで先回りできるのか」を見直すと、このセッションのメッセージがより具体的に見えてくると思います。
