re:Invent 2025: PolyAIの音声AIエージェントを企業が大規模展開する3つの柱とPG&E事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025-How enterprises are deploying PolyAI's voice agents at scale to reduce handling..
この動画では、PolyAIのVP of Strategic AlliancesであるMichaelが、企業向け音声AIエージェントの実装について解説しています。2017年設立のPolyAIは、University of Cambridgeの研究者が創業し、現在100以上の企業で約2,000のAIエージェントを本番稼働させています。PG&Eの事例では、7,000のインテントをGen AIに移行し、67%のコール解決率と25%の顧客エフォート削減を達成しました。1,000人以上のFTE規模で運用するには、AIエージェント層（speech to textの精度、マルチモダリティ対応、LLMオーケストレーション）、プラットフォーム層（可観測性、監査証跡、同時進行ドラフト機能）、オペレーティングモデル層（フォワードデプロイドエンジニア、ソリューションコンサルタント、ダイアログデザイナー）の3つの柱が重要であると説明しています。AWSとのパートナーシップやAmazon Connectとの連携実績にも言及されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
PolyAIの音声エージェントによる労働時間削減とPG&Eでの実績
マイクチェック、よし。皆さんこんにちは。私はMichaelです。PolyAIでVP of Strategic Alliancesを務めています。今朝、お時間をいただきありがとうございます。このトークのタイトルは、企業がPolyAIの音声エージェントを導入してハンドリングタイムを75%以上削減する方法、となっていますが、これを少し言い換えたいと思います。つまり、ハンドリングタイムについては誰もが話していますよね。本当の目的は労働時間を削減することなんです。ですので、今日お話しするのは、PolyAIについて、そして私たちの企業のお客様が実際に何を目指しているのか、つまり約1,000FTEの仕事を本当に引き受けられるAIエージェントを持つために、それが実際にどのようなものなのか、ということです。
では、私たちについて少しお話しします。Fortune 500のお客様の事例の一つ、具体的にはガスと電力会社について説明し、彼らとどのようにAIエージェントを展開しているかをお話しします。そして、これらのAIエージェントを真に企業規模で運用するために重要だと考えているいくつかの機能についてお話しします。PolyAIについて少し説明しますと、私たちは2017年に設立されました。 大規模言語モデルとtransformerベースのアーキテクチャに取り組んでおり、特にユースケースとして企業のカスタマーサービスに焦点を当てています。3人の共同創業者、Sean、Eddie、そしてNicolaは、University of Cambridgeで対話システムと音声認識システムを研究していた研究者でした。彼らは、transformerモデルの発明を応用する方法を見つけたいと本当に考えていましたが、日常の人々の日常生活に触れられる方法で、そしてそれをカスタマーサービスとコンタクトセンターで見出したのです。
今日まで早送りしますと、現在100以上の企業ロゴに対して約2,000の個別のAIエージェントが本番環境で稼働しています。Nvidiaなどの投資家から1億2,000万ドル以上のベンチャーキャピタルを調達しました。今年のMagic Quadrantの会話型AIプラットフォームで認められており、現在はLondon、San Francisco、New Yorkに分散して約280から290人の規模になっています。 私たちとAWSについて簡単にお話ししますと、私たちはAWS上に構築されています。マーケットプレイスで利用可能です。Gen AIコンピテンシーパートナーの一つであり、他のコンピテンシーも持っています。そして、米国、英国、ヨーロッパ全体でAmazon Connectとの複数のライブデプロイメントをすでに行っています。他のコンタクトセンタープラットフォームとも連携しており、Zendeskの友人たちとも協力しています。はい、私たちとPolyAIについて少しご紹介しました。
業界アナリストや投資家から何度も何度も聞くことの一つは、本番環境で稼働している企業規模のデプロイメントという点で、私たちが本当に際立っているということです。では、今日はその一つ、PG&Eとのデプロイメントについてお話しします。PG&Eのような公益事業会社にとって、停電や請求に関する会話ほど重要なやり取りはありません。PolyAIが登場する前は、お客様にとってそれがどのようなものだったかというと、非常に予測不可能な期間、非常にセンシティブな期間に、おそらく1時間以上の待ち時間があったということです。これらは実際に公益事業会社が正しく対応しなければならない期間です。お客様とのコミュニケーションに関する多くの規制があり、彼らはレガシーなNuance IVRに苦労していました。それは変更を加えたり適応させたりすることが非常に難しいものでした。
では、実際にお客様とソリューションの非常に短いクリップを再生して、その後、影響についてお話しします。こんにちは、PG&Eにお電話いただきありがとうございます。私はPeggy、PG&Eのバーチャルアシスタントです。どのようにお手伝いできますか? こんにちはPeggy、請求書の期限が来ていると思うのですが、いくら支払う必要があるか教えてもらえますか? 電話で残高情報をお伝えすることもできますし、オンラインでアカウント残高を確認する方法をお伝えすることもできます。どちらがよろしいですか? そうですね、絶対に電話でお願いします。かしこまりました。今後の支払いプランの分割払いを含む現在の残高は29ドルです。
非常に短いクリップです。完全版のビデオへのリンクは後ほどお渡ししますが、まずはその影響について簡単にお話ししたいと思います。今ご覧いただいたのは私たちのお客様であるKristin Punterさんで、ソリューションがライブで本番稼働していることを語っていただきました。私たちがこのお客様に対して支援したのは、レガシーIVRに組み込まれていた7,000のインテントをGen AIソリューションに移行することでした。その結果、約67%のコール解決率と、全体的な顧客エフォートの約25%削減を実現しました。さらに、障害発生時には、このAIエージェントを5分以内に約50倍にスケールさせることで、中断のないサービスを提供し、CSATを約22%向上させることができました。
では、実際のデプロイメントがどのようなものかをお見せしましょう。私たちがこれを初日にすべて実現したとは申し上げません。これは旅なのです。特にエンタープライズ規模で、特に規制された業界においてはそうです。私たちは障害通知から始めました。
お客様がパフォーマンスのレベルに満足されたら、それを拡大してユースケースを追加していき、現在では年間約1,600万件のコールを処理する軌道に乗っています。ユースケースを追加するたびに、音声AIには常に予期しない課題が発生します。音声認識に関して異なるチューニングが必要になります。対処が必要なインテント、ナレッジベース、またはRAGの問題が発生することもあります。ですから、これは旅なのですが、私たちは複数のFortune 500企業とともに成功裏に歩んできた旅です。そうですね、こちらが完全版のビデオへのリンクです。 お客様から私たちの影響について語っていただいています。
エンタープライズ規模のAIエージェント運用に必要な3つの柱：アプリケーション、プラットフォーム、オペレーティングモード
それでは、AIエージェントが実際に1,000人以上のスタッフの仕事をこなし、その能力を持つために何が必要なのかについて触れていきます。 私たちはこの課題を主に3つのレンズで捉えています。第一に、アプリケーション、つまりAIエージェント自体です。これは顧客体験、ブランド体験に関するものです。第二に、プラットフォーム自体です。つまり、開発者にとって、コンタクトセンターマネージャーにとって、1,000人以上のスタッフ規模で運用する際の体験はどのようなものかということです。そして最後に、オペレーティングモード、つまりベンダー体験と、ソリューションの継続的改善に関する体験です。それでは、これらの柱それぞれについて少しお話しします。
第一の柱であるAIエージェントにおいて、私たちのソリューションのパフォーマンスを総合的に見たところ、生成AIソリューションによって提供される不十分な体験の約70%は、実際にはspeech to textのエラー、つまり文字起こしのエラーに起因していることがわかりました。必ずしもAIが答えを見つけ出すのに十分スマートでなかったわけではなく、音声認識エンジンから不正確なシグナルが与えられていたのです。 ですから、私たちにとって、音声言語理解のエンタープライズグレードとはどのようなものでしょうか。NVIDIAとのパートナーシップを通じて、私たちはspeech to textモデルのアンサンブルを構築しています。そして構築してきました。つまり、米国の話者向けのモデル、英国の話者向けのモデル、米国の郵便番号用のモデルがあり、それは英国のpostcodes用のモデルとは異なり、それはクロアチアのファーストネーム用のモデルとも異なります。ですから、speech to textを本当に最適化できることは、非常に、非常に重要なのです。
モデルを切り替えたり、特定の単語を強調したり、会話のどの時点でもガードレールを作成できることも非常に重要です。つまり、ソリューションの非常に特定のポイントでしか音声認識を適応させることができないというのは制限的なんですね。機械学習を通じて自動的に発信者に適応する音声アクティビティ検出も重要です。AIエージェントと少しタイミングがずれたときに起こる、あの中断のやり取りほどイライラするものはありません。ですから、独自の音声アクティビティ検出機能を持つことは、エンタープライズ規模にスケールする上で非常に重要でした。そして最後に、AWSを使った、瞬時にスケールできるアーキテクチャ、つまり自動スケーリングです。そして先ほど公益事業の停電のユースケースで述べたように、数分以内に通話量を50倍にできる能力です。
次に、AIエージェントにおいて、どのように顧客エンゲージメントを得るかということです。顧客が関与する意思がなければ、AIエージェントがどれほど賢くても意味がありません。特定の情報は音声会話を通じて伝えるのに適していますが、他の形式のデータも重要です。私たちは常に話すことで情報を提供するわけではありません。動画を共有したり、フォームを送信したり、スペルを伝えたり、位置情報や写真を共有することで情報を提供することもあります。ですから、私たちにとってエンタープライズグレードの顧客エンゲージメントとは、 音声を主要なものとして維持しながら、複数のモダリティに移行できる能力です。つまり、電話を切ることなく会話の途中でフォームを送信できる、電話はまだ繋がったままで、フォームを送信し、会話を続ける前に顧客がそのフォームを完了するのを待つということです。顧客に写真や動画、位置情報のピンを共有する能力を与えることです。これらすべてが、大規模に稼働する音声AIにおいて非常に重要なのです。
第三に、AIエージェントに関して、LLMレイヤーについてです。エンタープライズグレードのLLMオーケストレーションとはどのようなものでしょうか。私たちは独自のLLMを持っています。Ravenモデルと呼ばれるもので、AWS上でトレーニングされており、現在SageMakerやBedrockを通じてこれらのモデルを提供するプロセスを進めています。しかし、特定のユースケースに対してトレーニングされたLLM、つまりコンタクトセンターの会話、カスタマーサービスの会話のスタイルにファインチューニングされたLLMを持つことは、より自然で生き生きとした魅力的な応答を得るために本当に重要です。会話のどの時点でも、同期的または非同期的に関数呼び出しや統合をトリガーできることは、大規模なオペレーションを処理できるソリューションにおいて非常に重要な機能です。
推論のための専用インスタンスを持つこと、つまりインスタンスを共有せず、LLMと音声認識レイヤーに専用のものを持つこと、そして最後にアーキテクチャの柔軟性のレベルを持つことです。エンタープライズは当然ながら、データがどこで処理され、どこでホストされているかについて非常に懸念しており、そのためアーキテクチャの柔軟性のレベルを持つことも、私たちが顧客に提供しているものです。
次に、プラットフォームについてですが、何千人もの規模でAIエージェントを実行する前に、 一定レベルの可観測性が必要です。私たちが顧客に提供しているものの例をお見せすると、コアメタデータはかなり標準的です。また、カスタムメトリクス、つまりビジネスメトリクスも提供しています。コンテキストステート、つまり会話で何が起こっているかと履歴を追跡できること。会話において、すべての関数呼び出しを通じて、会話のすべてのステップでLLMに与えられた入力と出力を正確に追跡できること、そして最後にトランスクリプションと録音です。
また、開発者がデバッグやトラブルシューティングのために必要に応じて完全なLLMリクエストを詳しく調べることもできますし、レイテンシーの可視化も提供しています。AIエージェントの応答に少し時間がかかっている場合、そのレイテンシーが音声認識から来ているのか、LLMから来ているのか、関数呼び出しの書き方から来ているのか、それともテキスト読み上げプロバイダーから来ているのかを理解することが重要です。これらはすべてトラブルシューティングとデバッグにとって非常に重要です。
コラボレーション体験とAIオペレーショナルレイヤーの重要性
次はコラボレーション体験です。エンタープライズで運用する場合、ソリューションを管理するのは決して一人だけではありません。IT部門の人、コンタクトセンターの人、カスタマーエクスペリエンス部門の人がいます。複数のチームメンバーがソリューションに取り組み、同時にソリューションを評価することになります。
これを成熟度スケールのようなものだと考えてください。最も基本的な、まず最初にできる必要があることは、異なるユーザー、異なるレベルの権限、異なる環境に対応することです。そうすれば何も本番環境に直接プッシュされることはありません。作業しているAIエージェントプラットフォームでそれを提供できることが重要です。さて、異なるユーザーと異なる環境がある場合、次に必要になるのは監査証跡です。どのような変更が行われたのか、どのバージョンのエージェントがどの環境で稼働しているのか、誰がその変更を行ったのか、なぜその変更を行ったのか、メモを追加できること。これが私たちがこの旅を進める中でのステージ2でした。
ステージ3は、私たちがローンチできることを非常に楽しみにしているものですが、単一バージョンのソリューションの監査証跡を持つだけでなく、今度は同時進行のドラフトとマージプロセスを持つことです。全員が同時にAIエージェントに取り組むことができ、競合することなく、機能を破壊することなく、機能を失うことなく、異なるドラフトをマージする方法があります。これは私たちがプラットフォームに導入している非常に、非常に重要な変更です。
私たちが見ている最終的な目標、ここでの最終結果は、同時進行のドラフトを持ち、競合とマージを管理する能力を持ち、監査証跡を持ち、異なる環境を持つことができれば、それらがネイティブな開発者コパイロットを持つためのアンロックされたステップになるということです。開発者である必要はありません。最先端の音声AIエージェントを構築するために必ずしもPythonを書く必要はありません。CursorのようなCloudCodeのような体験のコパイロットにプロンプトを出せるようにすべきです。しかし、それを実現する前に、これらすべての他のピースを配置する必要があり、それが私たちがエンタープライズのお客様に提供しているものです。
次に、オブザーバビリティの先にあるのが、エージェントからの分析、アナリティクス、インサイトです。これらは私たちが提供している機能の一部のスクリーンショットです。自然言語を通じて、AIエージェントに追跡させたいアナリティクスを作成する機能があります。これは、さまざまなタイプのビジネスオペレーションにとって重要なカスタムメトリクスを実装する機能です。
下の方には、はい、ダッシュボードを提供しています。実際、私たちはダッシュボードソリューションとしてAmazon QuickSightを使用しています。しかし、今ではビジネスユーザー向けに、会話データと対話する、つまり本質的にはコンタクトセンターと対話する自然言語の方法も可能にしており、スマートアナリストタイプの機能を通じてそれを実現しています。ここではこのタイプのユースケースにBedrockとAnthropicモデルを活用しています。新しいパラダイムは、より会話的な、つまり自然言語による方法で、現在文字起こしされコンタクトセンタープラットフォームを流れている何百万もの電話とやり取りするものになると思います。
そして最後に、簡単に触れますが、
モデルとしてのフォワードデプロイドエンジニアリングについて多くの議論があります。私たちはエージェントについて、プラットフォームについて触れてきましたが、今度はオペレーティングモデルについてです。AIエージェントが千人分の仕事を引き継ぐとき、どのような姿になるのでしょうか。異なるタイプのAIオペレーショナルレイヤーが必要になります。フォワードデプロイドエンジニアだけの話ではありません、もちろん彼らは非常に重要ですが。
私たちはまた、クライアントに対してソリューションコンサルタントによるアーキテクチャコンポーネントにおける専門知識も提供しています。私たちには独自のプロダクトソリューションマネージャーがおり、エンタープライズがAIエージェントの改善サイクルについて考えるのを支援し、これが音声認識の修正なのか、LLMなのか、テキスト読み上げなのかについての専門知識を持っています。また、私たちには独自のダイアログデザイナーもおり、エンタープライズと協力してブランド体験をAIエージェントに実装しています。
本日ご用意したコンテンツは以上となります。改めて申し上げますと、AIエージェントに1000人分のFTE、あるいはそれ以上のスタッフの仕事を本当に担わせるためには、AIエージェントから、プラットフォームから、そしてベンダーやテクノロジープロバイダーとの間で持つオペレーティングモデルから、多くの新しい機能について考える必要があります。
あと数分ほど時間が残っています。もしご質問があれば、今ここのステージ上でお答えしますし、この後もこの辺りにおりますので、その時にでもお答えできます。PolyAIに対して会場の皆さんから何かご質問はありますでしょうか、お答えできるものがあれば。手を挙げていただければと思います。これは皆さんが1対1で質問に答えてもらえる時間です。遠慮なさらずにどうぞ。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion