コーディングは不要 ― ビジネスユーザーこそが顧客体験の新たな設計者に

本記事は 2026 年 6 月 22 日に公開された「Business user is the new architect of customer experience. No code required」を翻訳したものです。

7月の夏、激しい雷雨により主要ハブ空港で航空便が欠航し、何百人もの旅行者が足止めを食らっている状況を想像してみてください。多くのホテルには宿泊客からの電話が殺到します。人々は、滞在の延長やチェックアウト日の変更、あるいは予定通りに到着できなくなった予約の取り直しのために、電話口で待たされることになります。

しかし、旅行者の一人、Lily は電話をかけません。ホテル側から先にテキストメッセージが届くからです。

彼女の航空会社は欠航のフラグを立てたばかりですが、彼女のフライト情報を共有されていたホテルはそれをすぐに把握します。プラチナ会員の Lily が予約していた午前 6 時発の便はもう存在しません。数秒以内に、Lily にメッセージが届きます。「Lily 様、フライトが欠航になったことを確認いたしました。つきましては、同じスイートルームをもう一泊確保しております（変更のご希望がない限り、お手続きは不要です）。滞在が延びましたので、明日の朝、いつもの担当者による30分間のスパ・セッションを無料でご用意しました。こちらをタップして担当者と話し、ご都合の良い時間をお選びください」

Lily がタップすると、即座に通話が始まります。担当者が空き時間を案内するのと同時に、その情報がリアルタイムで彼女の画面にも表示されます。「午前10時でお願いします」と伝え、タップして確定すると、チェックアウト日時の変更、新たな予約確認、そしてスパの予約情報が、航空会社からの欠航通知を閉じるよりも早く彼女のスマートフォンに届きます。会話と画面表示が完全に連動していたのです。

電話口で待たされることも、複雑な音声ガイダンス（メニューツリー）をたどることも、不安な状況下で一から事情を説明することもありません。ホテル側は、彼女が誰で、何が起き、何を求めているかを把握しており、彼女が依頼する前にすべてを処理してくれたのです。

ここで重要なのは、IT チームの誰もそのインタラクションの構築を行っていないということです。ビジネス部門の顧客体験運用責任者が、ある火曜日の午後にこれを設計し、テストを行い、同日に本番環境へリリースしたのです。

とはいえ、その裏側にはエンジニアリングが存在します。誰かが航空会社のデータフィードとの連携を構築し、誰かがロイヤリティ・プログラムのシステムを接続し、誰かが客室管理やスパ予約の API を組み込みました。そうしたインフラは実際に存在し、構築には高度な技術を要するものです。違いは、その基盤さえあれば、体験そのもの（「嵐を検知→ゲストが足止めされる→滞在延長・特典提供・確認」というロジック）を設計するのは、プログラミング言語を理解する人ではなく、顧客を理解する人であるという点です。

本記事の残りの部分では、この違いについて掘り下げていきます。

30 年にわたり顧客体験を規定してきた制約

顧客体験のリーダーなら誰でも、「顧客への徹底的なこだわり（カスタマー・オブセッション）」がどのようなものであるかを知っています。それは、あらゆる顧客とのインタラクションを、今まさに自分が対応すべき唯一の案件であるかのように扱うことです。相手が誰で、何が起き、次に何を必要としているかを把握し、相手から求められる前に対応するのです。

その原則に異論を唱える人はいません。問題はその数にありました。

ほぼすべての顧客体験業務は、ある共通の制約、すなわち「キュー（待ち行列）」に基づいて運営されています。

何人の顧客に対応できるか？どれほどの質で？どれほどの速さで？

Andrei Papancea 氏がある大手銀行で対話型 AI システムを構築した際、彼自身がボトルネックとなっていました。ビジネスチームは何を作るべきかを正確に理解していましたが、彼らはまずチケット（作業依頼）を起票し、エンジニアリングチームが優先順位を付けるのを待ち、さらにチームが自分たちの意図を正しく解釈してくれることを祈るしかなかったのです。これは AI の問題ではなく、組織の問題です。そしてそれこそが、30 年にわたり顧客体験を規定してきた制約なのです。

今、顧客体験のリーダーたちは CEO から同じ質問を投げかけられています。「AI を使って何をしているのか？」と。多くのリーダーは答えを持っていますが、それを実現するために適切な人材を主導的な立場に置く戦略まで持っている人はごくわずかです。

「すべての顧客、すべてのインタラクションに対して、今まさに自分が対応すべき唯一の案件であるかのように徹底的にこだわること。これまでそれは単なる理想に過ぎませんでしたが、今や実現可能なものとなりました。」

エージェンティック AI は、対応可能な顧客数や、一人ひとりの顧客への対応品質に対する限界を取り払います。それも、実際の運用環境において、エンタープライズ規模で、あらゆるチャネルにわたって実現するのです。しかし、このブレイクスルーの鍵は、AI が賢くなったことではありません。顧客に最も近い場所にいる人々が、自分たち自身にとっての待ち行列で待つことなく、体験を自ら設計し、リリースできるようになったことにあるのです。

この変化は注目に値します。

エージェンティック AI がもたらす変化と、企業が正しく取り組むべき 3つのこと

まず、現状を率直にお伝えします。エージェンティック AI が魔法のように一晩ですべての制約を消し去るわけではありません。モデルは依然としてハルシネーションを起こします。システム統合には依然としてエンジニアリングが必要ですし、ガバナンスには厳格さが求められます。もしそうではないと言う人がいれば、それは何かを売りつけようとしているだけです。

エージェンティック AI が変えるのは、その限界点です。いまや、同時に質の高いサービスを提供できる顧客の数は、もはや人間を何人採用し、教育し、シフトを組めるかという制約に縛られなくなりました。すべてのインタラクションを唯一のものとして扱うという願望が、アーキテクチャとして可能になりました。すべての顧客を、唯一の顧客であるかのように徹底的に大切にできるのです。

しかし、これを追求する企業の多くは、依然としてその裏側に存在するキュー（待ち行列）を前提とした仕組みを構築しています。いわば「キュー思考」です。「どうやって業務量を調整するか？」「ピーク時にどう人員を配置するか？」これらはもっともな業務上の問いですが、現在実現可能になった体験に対しては、視点が間違っています。

エージェンティックな思考は、全く異なる前提から始まります。それは、限界は存在しなくてよいという考え方です。

1. 特定の機能向けに整備された部分だけでなく、顧客のジャーニー全体を支援する

多くの企業の顧客体験システム群は、最初から統合的に構築されたものではありません。長年にわたり、ベンダーごとに個別のシステムを継ぎ接ぎして組み立てられてきたものです。音声対応は一つのシステム、チャットは別のシステム、デジタル対応はまた別の場所、そしてエージェント支援機能はさらに別のシステム、といった具合です。これらは文脈やデータを共有しておらず、顧客に対する共通の認識も持っていません。そのような断片化された環境の上にエージェンティック AI を導入しても、キューがなくなるわけではありません。単に、キューの処理が速くなるだけです。

真にエージェンティックなセルフサービスを実現するには、顧客ジャーニーの全体を理解する単一のシステムが必要です。つまり、インタラクションが始まる前の文脈、顧客が今必要としているもの、そして断絶されたツール群を経由することなく問題を完全に解決する方法を理解するシステムです。これには、単一機能のソリューション（ポイントソリューション）ではなく、統合されたアーキテクチャが求められます。そして、これこそが Amazon Connect Customer が当初からシステムを構築する際に重視してきた信念の一つなのです。

2. ブラックボックスを信用しない。エージェンティックな動作を安全にする構造を構築する

自律的に推論し行動するシステムは、本質的にリスクを伴います。特に、ガードレールがない場合や、規制の厳しい環境、あるいは顧客に直接的な影響が及ぶ場面ではなおさらです。

過去 30 年間、企業のシステム運用の定石は「支援（assisted）」という言葉を中心に構築されてきました。「AI 支援」「エージェント支援」「人間による支援」といった具合です。あらゆるシステムの根底には、AIはあくまで支援層であり、困難な部分は人間が担う、という前提がありました。

「目標は『支援』ではありません。『問題の解決』と『顧客の喜び』です。」

その目標を安全に達成するには、決定論的な処理とエージェンティックな推論が、同一のガバナンス（統制）下にあるフローの中で共存する必要があります。正確性が求められる手順（本人確認、コンプライアンス上の説明、決済処理など）は決定論的であるべきです。一方で、判断力や柔軟な理解、システムを横断する複雑な推論が求められる手順は、エージェンティックであるべきです。これら双方が、同じ会話の中で、同じガバナンス層の下で機能すること。それこそが、エージェンティック AI を単なるデモ用ではなく、実際の顧客対応に投入できるほど安全なものにするのです。

そして、そのシステムを長期的に信頼できるものにするのが可視性です。エンドツーエンドのオブザーバビリティとは、AI が具体的に何を発言し、なぜそう発言したのか、そして顧客体験のどこを改善できるかを正確に把握できることを意味します。本番環境から設計へとフィードバックを循環させるこの仕組みこそが、エージェント型の顧客体験を、当初の意図から逸脱させることなく、日々進化させ続ける鍵となります。

3. ビジネスユーザーに主導権を。彼らこそが顧客体験設計の主役です

顧客体験におけるボトルネックは、これまで AI の能力そのものではありませんでした。真の問題は、顧客を深く理解している人々と、顧客にサービスを提供する技術を管理する人々の間にある距離にありました。その距離を縮めれば、システム全体が変わります。

目指すべきは、開発者に逐一頼ることなく、自らの手で顧客体験を管理し、継続的に最適化したいと考えるビジネスユーザーにとって、エージェンティック AI の機能をより強力かつ扱いやすいものにすることです。それが実現すれば、すべてのビジネスユーザーがヒーローとなり、すべての顧客が VIP として扱われるようになります。つまり、問題が発生する前にニーズを先回りして満たし、プロアクティブかつパーソナライズされた対応が可能になるのです。

私たちが目指しているのは、毎朝席に着くなり AI のチームメイトと並んで業務に取り組み、継続的に成果を上げるビジネスユーザーの姿です。彼らは夜間に何が変わったかを確認し、顧客体験を調整し、テストを行い、そしてリリースします。これらすべてを、昼食前に行うのです。これは単なる試験的導入ではありません。素晴らしい顧客体験を提供し、成功を収めているビジネスチームにとっての「新しい当たり前」なのです。そして、彼らが職場に入るとき、もはや優れた仕事をするための許可を待つ必要はありません。それこそが、ビジネスチームが本来担うべきヒーローとしての役割なのです。

簡単な診断

自組織が「キューを処理するための仕組み」を作っているのか、それとも「その枠を超えた仕組み」を作っているのかを知るために、以下の質問をしてみてください。

稼働中のカスタマージャーニーを変更するのに、どれくらいの時間がかかりますか？ もし数週間かかるなら、あなたの組織はまだ「キューを処理する」という発想にとどまっています。
セルフサービス体験の設計は誰が主導していますか？ もしエンジニアリング部門なら、顧客に最も近い人々が主導権を握っていないことになります。
AI が限界に達し、人間が対応を引き継ぐとき、何が起こりますか？ もし担当者がゼロから対応を始める必要があるなら、そのアーキテクチャは「問題解決」を前提に構築されていません。

これらはどれも技術的な質問ではありません。組織に関する質問なのです。そして、それこそが重要な点なのです。

もう一つ、問うべき重要な問いがあります。それは、エージェンティック AI への期待が高まる中で、最も見落とされがちな点です。すなわち、「今日構築したシステムは、その基盤となるモデルが半年後に変更されたとき、どうなってしまうのか？」という問いです。

モデルは変化するものです。先四半期には最先端だったものが、今やコモディティと化すことも珍しくありません。もし顧客体験のアーキテクチャが、現在稼働している特定のモデルと密結合している場合、AI の進化は単なるアップグレードではなく、システムの再構築を意味することになります。それはイノベーションとは呼べません。いわば、あらかじめ組み込まれた技術的負債を抱えるようなものです。

基盤となる AI が変化するたびに投資価値が目減りするのではなく、むしろ投資効果が積み重なっていくような、強固な土台を築く必要があります。チームが設計するあらゆる体験、そして構築・展開したワークフローや連携（インテグレーション）の仕組みは、その基盤となるモデルが何であれ、そのまま維持され、機能し続け、さらに改善されていきます。成果は積み重なるものであり、リセットされることはありません。

AWS は、Amazon Bedrock を通じて、こうしたネイティブに統合された構造を提供しています。これこそが、単なるデモと当社のインフラストラクチャを決定的に分ける点です。

具体例：Agentic CX Designer と Live Sync のリリース

Agentic CX の実現において、最も困難だったのは AI そのものではありませんでした。ガバナンス、システム連携、セキュリティ体制、コンプライアンス管理といった周辺要素の構築こそが課題であり、多くの取り組みがそこで停滞してしまいます。Amazon Connect Customer は、すでに数千もの組織において、エンタープライズ規模でこうした本番環境のワークロードを処理しています。今回リリースされる自律型機能は、既存のシステムに後付けされた別製品ではありません。すでに稼働しているシステムの自然な拡張機能なのです。これまでに構築したものをすべて作り直す必要はなく、アップグレードするだけで利用できます。

AWS は今年初め、Amazon Connect Customer のエージェンティック CX 機能を強化するため、NLX社を買収しました。NLX 社は 10 年近くにわたり、エンタープライズ規模での自律型対話 AI の構築と堅牢化に取り組んできました。この買収は、ビジネスユーザーが自律型セルフサービスを数ヶ月ではなく、数日や数週間で設計、シミュレーション、テスト、展開できるようにするための大きな推進力となりました。

本日プレビュー版としてリリースされる Agentic CX Designer は、ビジネスチームがエンドツーエンドの対話型エクスペリエンスを視覚的に構築できるようにするものです。コードを書くことなく、エージェンティックな処理と決定論的な処理を組み合わせることができます。展開前にテストを行い、展開後には改善を重ねるという一連のライフサイクル全体を、顧客に最も近い担当者が一元的に管理・運用できます。

会話と視覚的な操作を同時に必要とするインタラクションにおいて、同じく本日プレビュー版としてリリースされる Live Sync は、他に類を見ない機能を提供します。これは、音声と画面上のデジタルインターフェースをリアルタイムで同期させる特許技術です。前述の例で Lily が体験したのは、まさにこの機能によるものでした。会話と画面が一体となったエクスペリエンスです。真の会話とは、単に音声やテキストをやり取りすることではありません。同じ文書を見ながら二人で問題を解決する際のように、文脈を共有することなのです。

Saks Fifth Avenue では、ビジネスアナリストが設計を主導し、わずか 6 週間で本番稼働を実現しました。これは、AI の技術的な高度さだけで決まるものではないのです。それは、誰が設計や改善を行う権限を与えられているか、そしてリリースに耐えうる堅牢なアーキテクチャを備えているかどうかにかかっています。高速な処理を行いつつも、インタラクションの品質を維持する必要があります。具体的には、読み上げやコンプライアンス上の開示事項におけるエラー率を 1 % 未満に抑え、会話のターンごとの応答時間を 2 秒以内にするということです。音声インターフェースにおいては、数字を一つ聞き間違えるだけで、顧客を一人失うことになりかねません。そのため、アーキテクチャにはスピードと正確性が求められるのです。

Pasquale が Deflection is Dead. Resolution is King. で述べているように、適切な指標は「封じ込め率」ではなく「問題解決率」です。自動化率 67 %とCSAT 90 % の両立は、決してトレードオフではありません。それは、もはやキューが制約要因ではなくなったことの証なのです。

CCW（Customer Contact Week）で私たちに会いに来てください。ユナイテッド航空やシチズンズ銀行といった顧客企業の声を直接お聞きいただけます

今後 10 年間にわたり顧客体験を定義づけるブランドとは、最も高度な AI を持つ企業ではありません。顧客体験チームに対し、すでに把握している知見に基づいて行動を起こす力を与えた企業こそが、その役割を担うでしょう。Amazon Connect Customer は、まさにこの瞬間のために構築されました。

「顧客を理解しているビジネスユーザーこそ、常に活躍の時を待っていた『ヒーロー』です。今、彼らはそのためのツールを手にしています。」

毎朝出勤するなり、AI のチームメイトと共に働き、何を変えるべきかを見極め、昼食前にはそれをリリースするビジネスユーザー。チケット管理も、スプリントも、待ち時間も必要ありません。これこそが、今日の顧客体験におけるヒーローの姿です。そして、これはもはや単なるビジョンではありません。今すぐ利用可能な現実なのです。

実際にその仕組みをご覧になりたい方は、6 月 22 日から 25 日までラスベガスで開催される Customer Contact Week (CCW) の会場へお越しください。ぜひスケジュールに加えていただきたいセッションが 2 つあります。

6 月 24 日（水）午後 4 時 30 分より、Academy Ballroom にて、Amazon Connect Customer 担当 VP の Pasquale DeMaio が、Citizens 銀行および United Airlines の代表者と共にメインステージに登壇します。世界的に著名なこれら 2 つのブランドがいかにして顧客体験を再構築しているか、そしてなぜ彼らが Amazon Connect Customer を選んだのかについて議論します。モデレーターは ABC ニュースのRebecca Jarvis 氏が務めます。
6月25日（木）正午より、Caesars Forum の Summit C にて、United Airlines のカスタマーサービスおよびテクノロジー部門が Amazon Connect Customer と連携し、高い自動化率と CSAT の向上を実現する「対話型 AI およびセルフサービス戦略」を構築した事例について解説します。特に、運航乱れ（IRROPs）発生時の対応に焦点を当てます。United Airlines は、Amazon Connect Customer の特許技術である Live Sync を導入した初の航空会社です。この技術は、音声ガイダンスと顧客のモバイルデバイス上のリアルタイムなビジュアル表示を組み合わせた、双方向かつマルチモーダルな体験を提供するものです。運航乱れ発生時の音声対応の自動化率を最大 50 % に引き上げることを目標に、同社がいかにしてコンテキストを完全に維持したまま AI からエージェントへシームレスに引き継ぐ仕組みを設計したか、そしてこの次世代テクノロジーを自社の顧客にどのように導入できるかについて学びます。United Airlines が、エンタープライズ規模でマルチモーダルなエージェント型自動化をどのように構築したかを、詳しく掘り下げてご紹介します。

詳細については、Amazon Connect Customer のウェブページをご覧いただくか、ドキュメントをご確認いただくか、AWS アカウントチームにお問い合わせください。

著者について

この記事は Solutions Architect の Yoichiro Sakata が翻訳を担当しました。原文はこちらです。

Amazon Web Services ブログ