本記事は 2026 年 2 月 26 日 に公開された「 Improving order history search using semantic search with Amazon OpenSearch Service 」を翻訳したものです。 Amazon で買い物をしたことがあれば、 注文履歴 を使ったことがあるでしょう。この機能は 1995 年まで遡る注文履歴を保持しており、すべての購入を追跡・管理できます。注文履歴の検索機能では、検索バーにキーワードを入力して過去の購入品を見つけられます。商品を見つけるだけでなく、同じ商品や類似商品を簡単に再購入でき、時間と手間を節約できます。 Rufus や Alexa など、Amazon のショッピング体験を支えるさまざまな機能が注文履歴検索を活用し、過去の購入品を見つける手助けをしています。そのため、注文履歴検索には過去の購入品をできるだけ正確かつ迅速に見つける能力が求められます。 本記事では、Your Orders チームが Amazon OpenSearch Service と Amazon SageMaker を使い、既存のレキシカル検索システムにセマンティック検索機能を導入して注文履歴検索を改善した方法を紹介します。 レキシカル検索の限界 注文履歴検索では、 レキシカルマッチング を使って、検索キーワードの少なくとも 1 つの単語に一致する商品を顧客の注文履歴全体から取得しています。たとえば「orange juice」と検索すると、オレンジジュースだけでなく、過去に注文した生のオレンジや他のフルーツジュースも取得されます。レキシカルマッチングは検索キーワードに正確に一致する商品の 再現率 は高いものの、この例の「health drinks」のような関連キーワードや汎用的なキーワードではうまく機能しません。 Amazon の AI ショッピングアシスタント Rufus の登場以来、効率的で充実したショッピング体験を求める顧客が増え、Rufus で過去の購入品を検索するケースも増えています。「Show me healthy drinks」のように、「kombucha」「green tea」「protein shakes」といった長く正確な用語を気にせず検索できるようになりました。検索体験が会話的で意図ベースになり、商品をより直感的に見つけられるようになっています。Rufus が「Show me the healthy drinks I bought last year」のような注文履歴検索に同じ直感的な体験で応えるには、基盤となる注文履歴データストア (Your Orders) に、従来のレキシカルマッチングを超えて検索キーワードの意味を理解する セマンティック検索 機能が必要です。 セマンティック検索の実装における課題 この規模でセマンティック検索を実装するにあたり、次の技術的課題がありました。 スケール – 世界中の顧客の注文履歴に対応する数十億件のレコードでセマンティック検索を有効にする必要がありました。 ゼロダウンタイム – バックエンドでセマンティック検索を導入する変更を行う間も、システムの可用性を 100% 維持する必要がありました。 検索品質の低下防止 – セマンティック検索は検索品質の向上が目的ですが、逆効果になるケースもあります。たとえば、顧客が商品名を正確に覚えていてその名前に一致する商品だけを見つけたい場合、類似商品も表示すると結果が混雑し、目的の商品を見つけにくくなります。同様に、注文 ID のように固有の意味を持たない識別子で検索する場合、セマンティック検索は機能しません。このようなシナリオではレキシカル検索のみを使用します。 ソリューション概要 セマンティック検索は 大規模言語モデル (LLM) を基盤としています。LLM は主に人間の言語で学習されており、学習済みの言語のテキストを受け取り、入力テキストの長さに関係なく固定長のエンベディングベクトルを出力するように適応できます。エンベディングベクトルは入力テキストの意味を捉えるよう設計されており、意味的に類似した 2 つのテキストは、それぞれのエンベディングベクトルの コサイン類似度 が高くなります。注文履歴のセマンティック検索では、エンベディング生成と類似度計算の対象となる入力テキストは、顧客の検索フレーズと購入済み商品の商品テキストです。 ソリューションは 2 つのパートに分かれます。 大規模リクエスト処理に向けたスケーラビリティとレジリエンシーの向上 – セマンティック検索を実装する前に、増加する計算負荷に対応できるインフラストラクチャを確保する必要があり、 セルベースアーキテクチャ を採用しました。すべてのユースケースで必要ではありませんが、リクエスト量やデータ量が非常に大きいシステムでは、セマンティック検索のようなリソース集約型機能の実装前に大きな効果を発揮します。 セマンティック検索の実装 – まず利用可能なエンベディングモデルを評価し、 Amazon Bedrock のオフライン評価機能でさまざまなモデルをテストしました。モデルを選定した後、エンベディングベクトル生成のインフラストラクチャを構築しました。 システムのスケーラビリティとレジリエンシーの向上 スケーラビリティとレジリエンシーの向上には、 セルベースアーキテクチャ の設計パターンを採用しました。セルベースの設計では、システムを同一の小さな自己完結型のチャンク (セル) に分割し、各セルがシステム全体のトラフィックの一部のみを処理します。次の図は、注文履歴検索のセルベース設計の概要を示しています。 各セルは定義された顧客のサブセットを担当します。セル間で顧客リクエストを処理するための通信は不要です。各顧客はセルに割り当てられ、その顧客からのリクエストはすべて該当セルにルーティングされます。各セルの OpenSearch Service ドメインは、担当する顧客のサブセットのデータのみを保持します。セル数 (N) とセル間のデータ分散はビジネスユースケースに依存しますが、データとトラフィックをできるだけ均等に分散させることが目標です。 ルーティングロジックはユースケースに応じてシンプルにも高度にもできます。セル割り当て値はリクエストごとにランタイムで計算するか、一度計算して Amazon DynamoDB などのキャッシュや永続データストアに書き込み、以降のリクエストで参照する方法があります。注文履歴検索では、ロジックがシンプルで高速だったため、リクエストごとにランタイムで実行しました。永続データストアからセル割り当てを参照する方法は、一部のセルが時間とともに「重く」なるリスクがある場合に特に有効です。その場合、パーティショニングロジックを変更する代わりに、データストア内の特定キーのセル割り当て値を上書きするだけで、重いセルのデータを再分散できます。パーティショニングロジックの変更はすべてのセルのデータ分散に影響する可能性があります。 システムの負荷が増加した場合、セル数を増やして追加トラフィックに対応できます。セル数を増やさなくても、負荷の高いセルから軽いセルにキーを再割り当てすることで、既存の N セル間でデータを再分散し、負荷をより均等に分散させてインフラストラクチャをより効率的に活用できます。 セルベースアーキテクチャはシステムのレジリエンシー向上にも役立ちます。たとえば、1 つのセルが失われた場合、キャパシティの低下は 100% ではなく 1/N にとどまります。さらに、パーティショニングキーを 2 つ以上のセルに割り当てて複数のセルに書き込むことで、キャパシティ低下をさらに抑えられます。この場合、単一セルの喪失がデータ損失につながることはありません。 セマンティック検索の実装 注文履歴検索にセマンティック検索を実装するには、いくつかの重要な判断と技術的ステップが必要でした。まず利用可能なエンベディングモデルを評価し、Amazon Bedrock のオフライン評価機能でさまざまなモデルをビジネスドメインの要件に照らしてテストしました。この評価でユースケースに最適なモデルを特定し、選定後にエンベディングベクトル生成のインフラストラクチャを構築しました。エンベディングモデルをコンテナ化して Amazon Elastic Container Registry (Amazon ECR) に登録し、SageMaker 推論エンドポイントにデプロイして大規模なベクトル計算を処理しました。 検索インフラストラクチャには、セマンティック検索機能の実装に OpenSearch Service を選択しました。OpenSearch Service は、必要なベクトルストレージと、ユーザーに関連性の高い結果を提供する検索アルゴリズムの両方を備えていました。 最大の課題の 1 つは、既存の注文でセマンティック検索をサポートするために過去のデータを更新することでした。 AWS Step Functions でワークフローをオーケストレーションし、 AWS Lambda 関数でレガシーデータのベクトル生成を処理するデータ処理パイプラインを構築し、対象のすべてのレコードでセマンティック検索を提供できるようにしました。 次の図は、アーキテクチャの概要を示しています。 モデルの評価と選定 注文履歴検索では、Amazon 固有のデータで学習されたエンベディングモデルを使用しています。ドメイン固有の学習は、生成されるエンベディングベクトルがビジネスコンテキストで適切に機能し、質の高い結果を返すために不可欠です。 候補モデルの評価には、Amazon Bedrock 上の Anthropic Claude を使った LLM-as-a-judge 手法を採用しました。Anthropic Claude に、顧客の注文履歴から匿名化された商品テキストと検索フレーズを含むプロンプトを与え、関連性に基づいて商品をフィルタリングおよびランク付けしました。この結果を比較用のグラウンドトゥルースとして使用しました。 モデルの評価には標準的なランキング指標を使用しました。 Normalized Discounted Cumulative Gain (NDCG) – 理想的な順序に対するランキング品質を測定 Mean Reciprocal Rank (MRR) – 最初の関連アイテムの位置を考慮 Precision – 取得結果の精度を評価 Recall – すべての関連アイテムを取得する能力を評価 このプロセスにより最適なモデルを決定しました。 検索戦略: 顧客スコープの包括的検索 注文履歴検索には 2 つの重要な要件があります。 リクエスト元の顧客の注文履歴のみを検索する – ある顧客の注文履歴の商品が別の顧客の検索結果に表示されてはなりません。 その顧客の履歴をすべて検索する – 検索アルゴリズムが何らかの理由で評価しなかったために、顧客の検索フレーズに関連する商品が表示されないことがあってはなりません。 このアプローチでは、OpenSearch Service を使って検索クエリを発行した顧客のすべての商品を取得し、検索フレーズに対する各商品の関連性スコアを計算し、スコア順にソートして上位 K 件の結果を返します。各顧客に対して包括的な結果カバレッジを提供します。 OpenSearch Service によるベクトルストレージ 効率的なベクトルストレージと検索のために、OpenSearch Service の 2 つの機能を使用しました。 knn_vector データ型 – エンベディングベクトルを格納するための組み込みサポート。既存のドメインでもインデックスの再作成なしにこのフィールド型を追加でき、すべてのレコードに対する正確な kNN 検索が可能です。ほとんどの顧客のレコード数は正確な kNN でスケールできる範囲だったため、近似 kNN は不要でした。 スクリプトスコアリング – Painless スクリプトがサーバーサイドでベクトル類似度を計算し、クライアントの複雑さを軽減しつつ低レイテンシーを維持します。 ハイブリッド検索 ハイブリッド検索とは、レキシカル検索とセマンティック検索の結果を組み合わせ、それぞれの強みを活かすことです。OpenSearch Service のハイブリッドクエリ機能により、クライアントは単一のリクエストで両方のクエリタイプを指定でき、ハイブリッド検索の実装が簡素化されます。OpenSearch Service は両方のクエリを並列実行し、結果をマージし、サブクエリの関連性スコアを正規化し、指定されたソート順 (デフォルトは関連性スコア) で結果をソートしてからクライアントに返します。 両方の検索タイプの利点を活用できます。たとえば、顧客が orderId で検索する場合のように、検索フレーズに意味的な意味があまりないシナリオがあります。セマンティック検索はこのようなケースには適しておらず、キーワードマッチングが最適です。 ハイブリッド検索機能により、注文履歴検索の実装工数と潜在的なレイテンシー増加を抑えられました。 過去のデータの更新 インフラストラクチャのセットアップ後、新しく取り込まれるレコードは関連するエンベディングベクトルとともに永続化され、セマンティック検索をサポートします。しかし、顧客が検索する際は通常、以前に購入した商品を検索します。そのため、古いレコードにエンベディングがなければ、顧客体験の改善にはつながりません。バックフィルの方法はデータ規模に依存します。 潜在的な顧客影響を最小化するリリース 最後のステップは、問題発生時の影響を最小限に抑えながらクライアントに変更をリリースすることでした。具体的には以下の方法を採用しました。 セマンティック検索フローで一時的な問題が発生した場合、リクエスト全体を失敗させるのではなく、レキシカルのみの検索にフォールバックするよう実装する。セマンティック検索が実行されなくても、空の結果ではなくレキシカル検索の結果をクライアントに返せるようにする。 デフォルトの動作をレキシカルのみの検索とし、セマンティック検索機能が必要なクライアントはリクエストに追加フラグを渡す必要があるようにゲーティングする。これにより、該当リクエストのみでセマンティックまたはハイブリッドフローが実行される。 初期期間中は新しいフローをフィーチャーフラグの背後に配置し、重大な問題が検出された場合に完全にオフにできるようにする。 顧客体験の改善例 Rufus が注文履歴を照会して顧客の質問に答えた例を紹介します。 次のスクリーンショットは、「sustainable utensils」のクエリで木製スプーンが検出される例と、タイトルの説明に「charger」というキーワードがないウォールコネクターを含むさまざまな種類の充電器が検出される例を示しています。 次のスクリーンショットは、タイトルの説明にクエリキーワードが含まれていなくても、セマンティック検索が関連する結果を検出する例を示しています。 セマンティック検索機能の導入により、Rufus が関連商品を取得して顧客に表示できるようになりました。導入前は、こうしたクエリに対して結果を返せませんでした。 ビジネスへの影響 主なビジネス成果は以下のとおりです。 顧客体験の改善 – クエリの再現率が 10% 向上し、関連する結果を返す検索の割合が増加しました。また、過去の注文の検索に関するカスタマーサービスへの問い合わせも減少しました。 パートナー連携の成功 – Alexa と Rufus の自然言語処理能力が強化され、注文履歴クエリの解釈精度が向上しました。パートナーチームによるリランキングや後処理の必要性も軽減されました。クエリ成功率は 20% 向上し、より多くの顧客検索が少なくとも 1 つの関連商品を返すようになりました。また、結果カバレッジが 48% 向上し、レキシカル検索では見逃されていた関連する一致をセマンティック検索が一貫して検出するようになりました。 まとめ 本記事では、Amazon の注文履歴検索をセマンティック検索機能に対応させた方法を紹介しました。既存インフラストラクチャの制約の中で最先端の AI 技術を活用し、機能アップグレード中もサービスの中断を回避して SLA を維持するソリューションを開発しました。実装にはバックフィルも含まれ、通常の取り込み速度の数倍のレートで数十億のドキュメントを処理し、過去に購入された商品のエンベディングベクトルを計算しました。慎重なエンジニアリングが求められましたが、極端な負荷下でも OpenSearch Service のレジリエンシーを活用して対応しました。 この基盤を活かして、検索技術を継続的に進化させられます。エンベディングベクトルのフレームワークに改良モデルを組み込めるほか、パーソナライゼーションやマルチモーダル検索など新機能への拡張にも対応できます。 Exact k-NN search の手順に従って、正確な k-NN 検索を今すぐ始められます。OpenSearch クラスターのマネージドソリューションをお探しの場合は、 Amazon OpenSearch Service をご確認ください。 著者について Shwetabh Shwetabh は、Amazon のシニアソフトウェアエンジニアで、分散システムと機械学習に関心があります。仕事以外では、技術的な深掘りや示唆に富むノンフィクションを好む読書家です。 Harshavardhan Miryala Harshavardhan は、Amazon のソフトウェアエンジニアで、機械学習、特に情報検索と分散コンピューティングに関心があります。仕事以外では、ラケットスポーツやサッカー観戦を楽しんでいます。 Ayush Kumar Ayush は、Amazon のテックリーダーで、14 年以上の経験を持つビルダーです。Your Orders Search プロダクトをリードしています。余暇にはクリケット観戦や幼い子どもとの遊びを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。

本ブログは 2025 年 11 月 11 日に公開された AWS Science News “ Amazon launches private AI bug bounty to strengthen Nova models ” を翻訳したものです。 本日 (2025 年 11 月 11 日)、Amazon は Amazon Nova 基盤モデルを含む特定の Amazon AI モデルおよびアプリケーションを対象としたプライベート AI バグバウンティプログラムの開始を発表しました。このプログラムは、セキュリティ研究者やパートナー大学の専門家と連携し、潜在的なセキュリティ上の問題を特定して修正することを目的としています。この招待制プログラムは、Amazon の既存の パブリックバグバウンティプログラム を補完するものです。パブリックプログラムはすべての研究者に公開されており、Amazon AI アプリケーションにおいて 30 件以上の有効な脆弱性が報告され、55,000 ドル以上の報奨金が支払われています。 「モデルをより強力で安全にするための最善の方法は、より広いコミュニティと連携することだと考えています」と、Amazon の汎用人工知能担当シニアバイスプレジデントである Rohit Prasad 氏はコメントしています。「Nova を外部からのテストに開放することで、安全性、透明性、継続的な改善への取り組みを強化しています」 このプログラムは、アカデミックな研究とセキュリティの現場のギャップを埋めることに重点を置いています。2025 年 11 月 11 日に、Amazon の米国オースティンオフィスでライブイベントが開催され、プログラムがスタートします。このイベントでは、 Amazon Nova AI Challenge のトップ大学チームとプロフェッショナルなセキュリティ研究者が一堂に会し、実環境の AI セキュリティ課題に取り組みます。目標は、Nova モデルを含む Amazon AI モデルおよびアプリケーションのセキュリティを強化するとともに、次世代の AI セキュリティ研究者を育成することです。 セキュリティ研究者は、AI システムを調査・検証する重要な外部の専門家として、初期の開発やテストでは明らかにならない潜在的な脆弱性、バイアス、予期しない動作を特定します。このプログラムを通じて、研究者はサイバーセキュリティの問題や化学、生物、放射性物質、核 (CBRN: Chemical, Biological, Radiological, and Nuclear) 脅威の検出など、重要な領域で Nova モデルをテストします。参加資格を満たした参加者は、有効な脆弱性の報告に対して 200 ドルから 25,000 ドルの報奨金を獲得できます。 「セキュリティ研究者は、私たちの AI モデルとアプリケーションが独創的な攻撃にも耐えられるかを実際に検証してくれる、最も重要なパートナーです」と、Amazon Stores の CISO である Hudson Thrift 氏はコメントしています。「この新しいプログラムにとても期待しており、セキュリティコミュニティや大学・研究機関と連携して、AI システムをさらに安全にすることを楽しみにしています」 プログラムの重点領域 参加者に期待している調査の重点領域は以下です。 セキュリティに影響を与えるプロンプトインジェクションとジェイルブレイク 実環境での悪用の可能性があるモデルの脆弱性 モデルがセキュリティの問題や CBRN 関連の脅威など、有害な活動を意図せず手助けしてしまう手法 参加資格と参加方法 2025 年 11 月にオースティンで Amazon Bug Bounty が主催するライブイベントが、プログラムの開始を告げます。プライベートな継続的ライブプログラムへのより広い参加は、2026 年初頭にセキュリティ研究者および選ばれた研究チームに招待制で提供される予定です。プライベートプログラム外の研究者や Amazon のお客様は、 Amazon のパブリックバグバウンティプログラム を通じて、 .amazon の下にある「Gen AI Apps」を選択することで、Amazon AI アプリケーションの潜在的なセキュリティ問題を報告できます。 このプログラムが重要な理由 Nova モデルは、Alexa、Amazon Bedrock を通じた AWS のお客様、その他の Amazon 製品にわたる成長するエコシステムを支えており、そのセキュリティの確保は引き続き最優先事項です。この新しいバグバウンティプログラムは、研究コミュニティとプロフェッショナルなセキュリティコミュニティが協力することで AI の安全性が最も速く進歩するという Amazon の信念を反映しています。実践的な学習と脆弱性検出の機会を生み出すことで、Amazon は AI の次の時代を形作るシステムを守れる、新世代の研究者の育成を支援しています。 参加方法 参加に興味のある研究者は、 Amazon Science で最新情報をご確認ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Amazon Connect は、より低いコストで優れた成果を実現する AI を活用したカスタマーエクスペリエンスソリューションです。2017 年のパブリックローンチ以来、Amazon Connect は AI の活用を推進し、あらゆる種類の組織が顧客とやり取りする方法を変革してきました。 先週の Q3 2025 年決算報告で、Amazon は重要なマイルストーンを発表しました。Amazon Connect は年間換算売上高 10 億ドルのペース(ランレート)を達成し、AI が前年に 120 億分を超える顧客とのやり取りを最適化しました。このような成功が続く中でも、Amazon Connect はミッションに基づいて行動し続け、サービスのスタート時と同様に、最終的な顧客の満足、エージェントの満足、そしてビジネスリーダーの喜びを通じて結果を測定しています。 ここで Amazon Connect のストーリーを探ってみましょう。Amazon の内部ソリューションから AI のパイオニアとなるまでの道のりです。 ストーリーの起源 Amazon Web Services (AWS) と同様に、Amazon Connect は Amazon が内部ソリューションを業界をリードするサービスに変革した事例です。ストーリーは 2007 年に始まりました。内部のカスタマーサービスチームが、3 つのコンタクトセンターベンダーを置き換えるため、ゼロから新しい統合ソリューションを構築する提案を採用したときです。従来の方法では、ハードウェアアップグレードのための 300 万ドルの前払い投資に加えて、継続的なライセンスとメンテナンス料金が見積もられていました。一方、提案された内部ソリューションは、より安価であるだけでなく、地球上で最もお客様を大切にする企業であるという Amazon の明文化されたミッションを体現していました。 「当時、他のすべての製品を調べました。しかし魅力的な選択肢はみつかりませんでした」カスタマーサービスチームを設立し、Connect の最も上級なエンジニアリングリーダーの一人であり続けている Jon Jay 氏は述べています。「いずれも要件を満たすキャパシティを持っていなかったため、これらのコンタクトセンターソリューションでは十数個のインスタンスを管理する必要があったでしょう。それらは非常に高価でしたし、顧客を喜ばせるために対処したいと考えていた問題を解決しませんでした。」 Amazon Worldwide Consumer の元 CEO である Jeff Wilke 氏からの承認を受けた後、チームは 2007 年に最初のパイロット展開に成功し、2008 年に完全に展開されました。内部効率化プロジェクトとして始まったこのプロジェクトは、カスタマーサービスから人事、輸送まで、Amazon のさまざまな部門に何年もサービスを提供し続け、競合ソリューションと比較して推定年間 6,000 万ドルの節約を実現しました。Audible や Zappos など新たに買収された企業も、このソリューションを熱心に採用し、カスタマーエクスペリエンスに対する Amazon 独自のアプローチが、市場での需要があることを証明しました。 「私たちが構築したものを他の Amazon チームに見せると、これは急速に広がりました。Zappos、Audible – 彼らはみな同じく、従来のコンタクトセンターで頭痛の種を抱えていました。私たちのソリューションを見せた時、彼らは『ちょっと待って – あなたたちは私たちの最大の問題をすべて解決したのですか』と言ったのです」と Jay 氏は述べています。 製品ローンチと初期の成功 Amazon Connect を一般に利用可能にする決定は 2015 年第 3 四半期に行われ、当時の AWS CEO である Andy Jassy 氏の承認を得て、Pasquale DeMaio 氏が主導しました。 「潜在的な外部顧客と話すと、お客様も Amazon と同じ課題に直面していることは明らかでした」と Jay 氏は付け加えました。「実装が簡単で、イノベーションの速度を提供し、最大規模の企業が必要とする信頼性とセキュリティ、拡張性を提供できるクラウドベースのソリューションであった可能性が分かりました。私たちは Amazon の問題だけを解決していたのではないことを知りました。業界全体が何十年もの間行き詰まっていた問題を解決していたのです。」 外部サービスとしての開発から 1 年強後、Amazon Connect は Enterprise Connect 2017 でパブリックデビューを果たし、重大なスケーリングの課題に直面している大企業の間で急速に注目を集めました。また AWS サービスとの深い統合により、シームレスなスケーリングと迅速な機能開発が可能になり、Amazon Lex を通じて Alexa AI テクノロジーを早期採用したことで、Amazon Connect を際立たせる自然言語対話型音声応答 (IVR) 機能が提供されました。 Capital One、Hilton、GE など Amazon Connect を早期に採用したお客様は、Amazon Connect の独自の価値提案に魅力を感じました。それは従来の電話インフラストラクチャの必要性を排除したクラウドネイティブなアーキテクチャです。この革新的なアプローチにより、従来は 1 年間の構築プロセスだったものが、多くの組織にとって週末のプロジェクトに変わり、市場投入時間と運用の複雑さの両方を劇的に削減しました。 「最初、私たちのイノベーションの速度を求める組織が、Amazon Connect とのパートナーシップで成功を収めました」と Amazon Connect の VP である Pasquale DeMaio 氏は述べています。「組織は、私たちが非常にユニークな方法でカスタマーエクスペリエンスを理解していることを知っています。お客様へのこだわり・お客様を起点に考えることもその一つです。Amazon では、私たちは毎日そのように過ごしています。」 COVID-19 のパンデミックが発生したときも、Amazon Connect のクラウドネイティブ設計のメリットが発揮されました。セルフサービスセットアップとネイティブな在宅勤務のエージェントサポートは、組織がリモートワークの従業員でカスタマーサービス業務を維持しようと奔走する中で、重要な利点となりました。標準的なインターネット接続とヘッドセットだけで機能し、専用の電話機器の必要性を排除できるため、突然のリモートワークへの移行に理想的なソリューションとなりました。パンデミックの終わりまでには、Amazon Connect は数万の顧客を抱えていました。 カスタマーエクスペリエンスにおける AI 革命 Amazon Connect の進化は、2019 年に AI を活用した会話分析、感情分析などのローンチにより更なる飛躍を遂げました。これらに一般的な複雑な技術要件はありません。他のソリューションでは数週間の展開が必要なのに対し、Amazon Connect ではお客様がこれらの AI 機能を有効にするためにチェックボックスを選択するだけで済みました。 2023 年、Amazon Connect は 2 つの主要な業界レポートで初めてリーダーシップポジションを達成しました。 Forrester Wave for Contact Center as a Service と Gartner’s Contact Center as a Service Magic Quadrant です。Amazon Connect は、現在まで後続のレポートでこれらのリーダーシップポジションを維持しています。 追加の AI 機能は、カスタマージャーニー全体に対して迅速に提供されました。生成 AI の出現で、チームはロードマップを転換し、大規模言語モデル (LLM) テクノロジーを採用し、自動でのエージェントのラップアップ、通話要約、LLM ベースのセルフサービスエクスペリエンスなどの機能を可能にしました。 2024 年 12 月、Amazon Connect は 60 億分の顧客とのやり取りが AI によって最適化されたと発表、顧客が実際のシナリオで AI を活用されている規模を示しました。Amazon Connect が 2025 年 3 月にカスタマージャーニー全体で AI が有効になった「次世代の Amazon Connect」を発表したときも、お客様の反応はとても肯定的でした。現在、Amazon Connect は AI で 120 億分の顧客とのやり取りを最適化しており、これは 1 年足らず前に発表された数値の 2 倍です。 Amazon Connect は、エンタープライズ規模の革新的で統合された AI ソリューションを提供しています。最近も、複数のグローバルブランドが他のプロバイダーや新興の AI ネイティブプレーヤーよりも Amazon Connect を選択しています。これらの評価において、Amazon Connect は、インテント検出精度、AI エージェントの安全性、人間と AI のコラボレーション機能などの重要な領域で優れたパフォーマンスを実証しました。これらの結果は、単なる優れたデモではなく、技術的メリットと信頼性に基づいてミッションクリティカルなユースケースを可能にし、Amazon Connect がクラス内で最高レベルの AI ソリューションを提供する能力を実証しています。 今後の展望 Amazon Connect は 10 億ドルの収益ランレートというマイルストーンの達成により、従量課金ベースのカスタマーエクスペリエンスソリューションとしてのこの規模に到達した存在になりました。この従量課金制アプローチは、AI とエージェンティックな未来に向けて Amazon Connect を特徴づけています。 「転機が次々と訪れました。Amazon Connect はまず最初に、クラウドベースのコンタクトセンターを新しい標準にする主要な推進力となり、次に COVID 中に需要の大幅な変動を管理しながらリモートワークをナビゲートするビジネスを可能にし、最終的に生成 AI で実世界の結果を提供しました」と DeMaio 氏は述べています。「今、私たちはさらに 2 つのテーマに直面しています。エンタープライズ規模で安全で倫理的なエージェンティック AI を提供すること、受動的な顧客エンゲージメントから積極的な顧客エンゲージメントに進化すること – これらをすべて顧客の問題を解決する新しい機会領域に拡大しながら解決していくのです。」 Amazon 自身のカスタマーサービスの課題を解決する内部プロジェクトから、Amazon Connect は 8 年間で数万の顧客に信頼されるグローバルサービスに進化しました。これは、まだ Day 1 です。この創造を促したときと変わらず、好奇心と顧客体験を変革する使命を持って、チームは問題を解決し顧客を喜ばせることを目的とした AI を活用したソリューションの開拓を続けています。 Amazon Connect の詳細については、 Amazon Connect ページ をご覧ください。 Amazon Connect でカスタマーサービスエクスペリエンスを変革する準備はできていますか？ お問い合わせください。 この記事はテクニカルアカウントマネージャーの高橋が翻訳しました。原文は こちら です。